timhh

Doom is so old you'd really have to go out of your way to find an MCU that can't run it.

> > and agents don't report bugs, they just work it around somehow.

Yeah I've definitely noticed this. On a project I'm working on Opus 5.5 found a bug in Smithay and another in Winit. It did tell me about them but its preferred solution was just to work around them locally. To be fair we don't really want agents going off and reporting bugs automatically...

I don't run any big open source projects but I think my preferred solution to AI PRs would be to get my AI to implement the same thing, and give then afterwards tell it to look at the PR for anything it missed. Then I at least know that I'm using a competent model and it reduces the danger of just blindly accepting someone else's code. (And obviously review the code if you have time and care, but that isn't always the case.)

Windows does raise on mouse down, in situations where you definitely want that. I'm sorry but it's clearly better.

What model though?

Yeah come on, that figure has been widely debunked.

Ha I reported that drag and drop bug 20 years ago. Windows does it in an even smarter way - it raises the window on mouse-down but only if the target isn't a drag source.

As I recall X11 doesn't really support that at all so there was no way to implement that on Linux. Doing it on mouse up seems sensible though. I couldn't find my bug report but I bet it was met with "I like it broken".

Great read. Thanks for not using AI to write it! (Or at least making it not read like the usual slop.)

I'm still trying to convince them that RISC-V assembly exists...

Yeah I always thought the whole architecture of PAM being a library is weird. A sane person would have made it a Daemon that processes talk to surely?

Really it should probably be part of SystemD, but I know that would anger the anti-SystemD zealots.

I'm vaguely considering rewriting PAM in Rust. It's definitely something that would benefit from Rust's extra security and the code quality isn't that great. Nor is the UX. What "among other things" were you thinking of?

Mostly the specification was just poorly written with many ambiguities. But also the design was complex, weird, invasive and IIRC not backwards compatible with standard RISC-V.

Why not what? Sorry I'm not sure which bit of my comment you are responding to.

There's no real need for LLVM, GCC or CUDA to be memory safe. POSIX libc is of course C by definition but libc's are normally extremely well tested, and it is possible to avoid libc entirely if you want.

V8 is actually a nice case for CHERI since you can easily sandbox the JIT'd code. If you were to just rewrite V8 in Rust then you wouldn't get that benefit (you can't run the borrow checker on generated assembly). I assume they have some other sandboxing methods instead though.

But in general if you think about things like V8, that's used on high performance application class consumer CPUs. It's going to be at least 10 years before anyone has one of those with CHERI (unless ARM changes its mind about Morello). I would not bet against V8 being ported to Rust before that.

As I said I think CHERI is great technology and I hope it does succeed, but it does seem like the business case for it is not as strong as it was just a few years ago.

Is it valuable enough though. Looking at Google's stats Rust has several orders of magnitude fewer memory vulnerabilities even with `unsafe` (kind of the point). If C was at that level there's no way CHERI would have ever been proposed.

There are two counter-arguments:

1. There's a lot of C/C++ code still out there. You can't rewrite it all. I'm not totally convinced by that though because, a) do you need to? Google has shown that just writing new code in Rust is very effective, and b) AI is actually pretty decent at porting from C/C++ to Rust so maybe you can?

2. CHERI also allows really strong and fine grained compartmentalisation. This is absolutely fantastic for robustness, supply chain security and so on. If you want the absolute 100% most secure code possible, then Rust + CHERI with compartmentalisation is basically the best thing you can do. (Though Rust compartmentalisation is still not actually ready yet; it's in progress though.) That's really great but I'm not sure that level of security is needed by most projects, and also I think you can get pretty good compartmentalisation (though definitely not CHERI level) by doing something like what Xous does (basically isolation with processes/virtual memory, combined with the ability to call functions in other processes; IIRC Hubris OS does something similar).

CHERI is clever tech though and it would definitely be a boon for RISC-V if it succeeds.