modeless

Opus 5.5 came out right at the end of the quarter, September 22. I'm confident that it caused more usage growth since then. I'm sure there are a lot of people rooting for their IPO to fail but they are still clearly in the lead on coding and will continue to do well until someone definitively passes them.

Yeah, like on web the default-on "Ambient Mode" feature has horrific banding artifacts, which could be completely fixed by a bit of dithering. I doubt it will ever be fixed. Completely pointless feature anyway that should never have been enabled by default. How many gigawatt-hours have been wasted rendering it?

Youtube desperately needs a holistic redesign of history and watch position. Watch position needs to be instantly synchronized down to the frame across devices, and it needs to be able to save more than one watch position per video for you to manually select in ambiguous cases (like if you watched offline and online on different devices). It should also show the difference between a video you stopped after one second and a video you watched completely but rewound to the beginning. The seek bar should show which parts you've watched regardless of your current watch position.

The "Watch Later" feature also needs a lot of love. The button for it constantly moves around and works in different ways.

They do occasionally fix things! One thing they fixed recently is that advancing to the next video in a playlist would always start from the beginning, irreversibly clobbering your watch position for that video. Now it seems to (most of the time) start from your watch position.

They ought to reserve a very small amount of quota exclusively for chatgpt so it doesn't just shut off if you exhaust your quota using codex. If they don't it would make more sense to keep codex and chatgpt usage on different accounts, which I'm sure OpenAI doesn't intend to incentivize.

I found it surprisingly compelling. Maybe not enough to justify forcing a bunch of people to wear a Quest for an hour, but there was definitely something there beyond what a Zoom call gives you. It was too early, but with much more comfortable glasses like this, and better face/body tracking, I could see people preferring it over Zoom.

AAAA studios don't take risks. Financing a top game is way too expensive to gamble on. Only indies and small studios working on cheaper games can risk trying unproven ideas.

Luckily you don't need to be infected by parasites to have a good immune system. What seems to work best is exposure to bacteria and viruses and fungi and parasites that don't infect humans. Things associated with other plants and animals. The immune system learns better from the things that it is effective at protecting you from than the things that outsmart it. So let's not bring back the human parasites.

It's true that Meta hasn't provided much software support for productivity use cases. At least the Meta VR Glasses will have DisplayPort support. So if you don't like the software on the device it will still work as a portable monitor setup for your other devices.

Based on this video I would believe you if you told me he was 69. This is unbelievable for 95. https://www.youtube.com/watch?v=TaButvSxPWQ

Resolution matters a lot for productivity, and Meta's displays have more than twice the number of pixels. Image quality for the display will be much better on the Meta VR glasses because of the lack of interference from outside light. See-through displays sound good in theory but require too many compromises IMO. There's no such thing as "black" on a see-through display, only "transparent". Definitely try before you buy.

I feel like Meta's track record of VR device support has been decent enough. Quest Pro still gets updates even though it was discontinued almost two years ago. When they ended support for Oculus Go they released an update that unlocked the device and granted root access. I'm sure you can find some complaints on Reddit but looking at what they've actually done I think it looks pretty good.

They may not recommend disabling Tailscale SSH but I do. It interferes with sshd features and adds to your attack surface. Distribute your SSH keys the old-fashioned way and disable Tailscale SSH.

Which is fine for a video game. Not at all fine if you want to train robots with it. Trying to combine both use cases into a single model is doomed to failure IMO.

TL;DR because WebGL 2 is basically equivalent to OpenGL ES 3.0, making it the most portable GPU API in the world by far, running on everything from laptops and phones to smart fridges and car head units.

Web browsers have also done a lot of behind-the-scenes work on compatibility. The behavior of WebGL 2 is much, much more consistent across platforms than native OpenGL [ES] ever was.

It's mostly hardware design limitations. GPU hardware is way more diverse than CPU hardware, so you need to distribute shaders as either source code or a portable intermediate representation, in both cases compiled at runtime for the user's actual GPU. There are also many fixed function parts of the graphics pipeline with wildly different behavior on different hardware which you need to abstract over. And it all runs in parallel with the CPU, often with a separate pool of RAM, so you need implicit or explicit synchronization and data transfer which adds a lot of complexity especially in error cases.

If you really want to see why all the cruft is there, and how much you could remove if you dropped support for older hardware, look no further than Sebastian Aaltonen's "No Graphics API" blog post (which he actually implemented too): https://www.sebastianaaltonen.com/blog/no-graphics-api/

Answering my own question, FP8 with BF16 accumulate is double rate already, but FP8 with FP32 accumulate is half rate, and this hack doubles it to match BF16 accumulate.

They don't need to monopolize everything to justify a valuation of $1.5 trillion. That's still relatively normal company territory. Not even top 10.

Is this relevant for 4090? It has FP8 which is already double the rate of FP16. Can this hack double the rate for FP8 too?

If you look at what they actually demonstrate, zero-shot embodiment generalization is limited to controlling two-finger grippers on two arms with a fixed base. The embodiments are all very similar, and when they're slightly different (as in the Sharpa hand demo) they can't zero shot it. But there's no real reason to do zero-shot embodiment generalization in practice, as it's trivial to collect a small amount of data on a new embodiment to get significantly improved performance. It's not an important problem to solve and doesn't necessarily indicate progress on the important problems.

What's hard and unsolved in general-purpose robotics is doing real tasks in real workplaces with high success rates. I guess there's just a lack of understanding generally about what's actually hard and useful in robotics.

It does seem weird. In my experience HN generally shows little interest in robotics research, so I'm surprised to see this up top. I'm biased but I think Physical Intelligence's recent announcement is more impressive, with greater diversity of robot embodiments and more impressive real-world tasks in real workplaces. https://www.pi.website/blog/api-beta

If you're an amazing, top 1% software engineer, and you switch jobs to become a penetration tester, you're not going to be top 1% day one. There's knowledge specific to penetration testing you'll need to research and absorb and practice before you're good.

For the models, it's always day one. They don't learn from experience. Whatever they know after training is all they'll ever know. So if you don't teach them penetration testing in training, they won't know it. Maybe they could theoretically derive everything from first principles, and so could a top 1% software engineer, but that's a very slow and inefficient way to do things.

They will. Just not in the version they release to you.

Yeah, the daemon is the real problem with Docker.

Seems unlikely to resolve their legal issues, as the French lawyers will use the same tactic as the German ones, using a VPN to access the services from France to justify continuing their lawsuits. Perhaps they should consider relocating out of Europe.

The problems you describe in your first post are only problems when you can't reproduce your build process locally. With a local build you can always do it in private for free.

The problems you bring up here are eminently solvable too. Yes there are many solutions for building for multiple architectures and versions. Cross builds, containers, VMs, or just having more than one computer locally. You can address building the wrong thing with reproducible builds, but for a one off patch like this it's not the most likely problem and relying on a trusted maintainer temporarily during an emergency is better than waiting for a glacially slow cloud build while exploits spread. Pushing builds to the cloud is inherently a cloud step, so it's fine to leave keys for that in the cloud, but there should be a process for publishing local builds and it should be essentially instant when the build is already done.

You should always have a local build process that replicates CI. There is no excuse.

Large, well-optimized services are running at high CPU utilization all the time. But there's a long, long tail of services that are running well below 100% utilization almost all or all of the time, and it's not just hobby stuff. Vulnerabilities in those services are still real and can be very important, and trading some otherwise idle CPU time for an absolute shield against memory safety issues is a good idea. Even for some services that do have high CPU utilization it may be a good trade to pay for more CPU to get that shield in this new world.

Making a cloud CI/build/release system whose behavior can't be reproduced locally requires some kind of brain damage. I can't believe people tolerate this.

There is now an iron clad defense against all memory safety bugs leading to RCE that is actually practical to use in production in many cases, and people should start taking it seriously. Any PHP install that has ~2x CPU headroom should be switched to a memory safe Fil-C build immediately. More generally, anyone running network-exposed C/C++ code that is not routinely pegging the CPU should recompile with Fil-C ASAP.

Still, all instances of Opus are identical and do not learn. As long as the rate of mistakes is nonzero, my point stands.

In the list of purposes for education he left out "Daycare for children of working parents".