kg

Software robustness, at least in terms of "has the app crashed on any client machines today", is achievable. It's just expensive enough to achieve that most people (rightly or not) don't prioritize it, and the more moving parts (like third party libraries or language runtimes) your application has the harder it is to achieve. Maybe AI will lower the cost of achieving that.

When I worked on Guild Wars every server or user crash went to a shared inbox and was bucketed so we could identify and act on new crashes. IIRC we maintained very, very low production crash rates and could prove that many of the crashes were due to hardware faults.

Similarly, Mozilla tries to analyze and act on every crash report they get in the field. If a webpage visited by even a small % of the customer base was causing crashes, the team worked to try and fix the crash to deliver stability. If it was a high-traffic webpage it got treated as a high-priority task - I remember Farmville breaking was basically a 3-alarm fire back when it was extremely popular.

"No bugs at all" is an even higher bar, but it probably is possible for simpler applications with the use of stuff like theorem provers. I'd love to see someone try it in production but I think the return on investment for that is probably super super negative.

This from that tweet stood out to me: "In general, we've seen that OpenAI's models game their own checks"

In the past when working on agentic stuff I've observed models gaming checks aggressively, to the point that when we were validating log files to see what the agent had done, the agent responded by editing the log files to pass validation. I can only imagine how bad that kind of behavior is at scale, and it sounds like they ran into it.

What's the alternative? Invisible algorithmic fuzzy recognition on the server side that just randomly bans you if you look like a bad bot, with no recourse? At least if you solve a captcha and dismiss the cookie banner you can access the website.

> No, I don't think network booting is even all that common outside of extremely niche scenarios.

It's incredibly common though? I've run across it and I work on games and client software, not server stuff.

You'd still need a spec for this because of cross-language considerations, but that doesn't make it a bad idea.

i.e. if an app is written in javascript and running on mac there are potentially 4 different languages all running inside the executable that need to cooperate to handle the BOM signal and report their deps - C/ObjC, Swift, C++ and JS. Presumably you'd want to report not only the native libraries being used in the process but also things like npm packages.

> When you can equally reasonably make the opposite argument - that AI is going to open up scientific exploration and contribution to a wider range of participants than ever before

Is typing a prompt into ChatGPT "science"? It's an experiment, I guess, to find out whether you get a useful response out of it, and your hypothesis is that the model is able to answer your question correctly? How do you falsify that if you don't have the academic foundations to verify its answer?

I'm pretty sure this class of problem would exist in GC'd environments too unless they're configured to abort on OOM, in which case you'd still be dealing with denial-of-service.

In some environments OOM is a trappable exception, so it's possible that incorrectly authored code would trap the OOM and 'recover' with partially initialized data sitting on the heap. Hopefully it's a memory-safe language so that partially initialized data isn't RCE...

Ignored is a little unfair to the Wasm committee, the Wasm GC is constrained by what is possible to ship in existing Wasm runtimes and the stuff needed by many languages is way beyond what those existing runtimes have available to them.

I think it made sense for them to compromise, at least on the initial version of Wasm GC, to get it out the door. I say this as someone who wants the features that got left out, like interior references :)

They're free, so I don't see how they're relevant. Do you mean the in-app purchases?

Doesn't Java have an AOT solution too? Is it not ready for prime time?

Most likely nobody complained and startup time isn't an important metric for them. The typical user may have Steam launch at startup or launch it once after booting their PC and then leave it running for days or weeks.

GC generally only results in the occasional missed frame, it doesn't negatively impact overall frametimes in a meaningful way if it's implemented correctly. GC malloc() and free() are both fast.

I think the average player would not appreciate hourly crashes, especially in games without aggressive autosave - that potentially means having to replay 10+ minutes worth of gameplay on a regular basis because your timing was bad, when you consider how a typical game is built. You could compensate for this in some game types I guess, like in a competitive FPS you'd restart the client software between matches and hope a match never lasts long enough to crash. But that's no substitute for real robustness, IMO.

Though it's not what happened in this case, you could tamper with a crypto wallet to make it emulate a USB keyboard and once connected, send a series of keystrokes to download and run an exploit.

For anything with recorded replays or multiplayer you need to preserve known and unknown bugs for compatibility reasons, not just for cheating.

I know a considerable number of people who abandoned Twitter for either Mastodon or Bluesky and haven't gone back. It probably depends on what circles you run in. There are some people I know who keep Twitter accounts because it's used for professional networking, for example, but they're in specific fields.