I wonder when we will move onto harder tasks -- I remember around 2007 people were using Crysis (also a first-person shooter) as a test of new computers as when it was released hardly any computer could run it without turning down all the settings. These days I'd expect most (although not all) low end hardware could run that well.
Must have been on the first attempts, right? As the name suggests, a meme (mimesis) is about imitation but also propagation at scale, otherwise everything would be a meme. The first attempts count as original. Once it gets traction others could very well be genuine technical achievements but in an "also ran" format.
It's like a series where every episode follows the exact same blueprint with very minor changes to the details. It doesn't get old from the first couple of episodes, but it sure does in a few more.
And I was thinking exactly of the "Doom on pregnancy test" example myself but that's worse than average. If my memory serves me, that was a case of using just the plastic shell of a pregnancy test and replacing all the hardware.
> > 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.)
Yes the default behavior of working around the bug is good, that’s what everyone was doing anyway pre-LLMs. The good practice is to report the bug. Simply add instructions to your agents to report you the bugs it found in the summary, so you can check the bug and report it correctly upstream.
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".
I've avoided that bug throughout more than 20 years of Linux usage just by disabling raise-on-click.
(Except of course the Gnome folks did they utmost to make that option unavailable back in the Gnome 2 days: Metacity's raise-on-click gconf setting was hobbled so that it could only be disabled in focus-follows-mouse mode. That bit of idiocy was patched out years ago, but the obnoxious text that accompanied it survived in Marco until earlier this year!)
> I couldn't find my bug report but I bet it was met with "I like it broken".
Which is an appropriate response when you yourself don't even want to recognize that others might prefer raising on mouse down, e.g. for lower latency in a much more common operation.
I don't have a Cameo Pro 4 to test, but I have reverse engineered software to control some of their other devices. It's a little janky but if you want to help I'd appreciate it!
I believe there is (or once was) also an Inkscape plugin somewhere but I never tried it.
As for how I reverse engineered it, I just used a USB sniffer and wireshark. I don't think there's a big risk of bricking these devices - I don't think they even have non-volatile storage, so worst case you turn it off and on again.
I would like to reverse engineer my solar power inverter too, but that is definitely brickable (the first one they shipped me came pre-bricked!) and is a lot more expensive so I've had to resist. :/
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?
Implementation language is incidental. Rust is... fine, I guess? But I wouldn't mandate modules use it. What's important is to move PAM out of process and sandbox the process host (using landlock, namespaces like bwrap, whatever) so we can run sensitive code with least-privilege on both ends.
It's confusing how they want a custom protocol that seems to be converging from JSON-RPC, just spelled differently. They should just use JSON-RPC. In any case, it'd essential to retain PAM's customization ability even if the bulk of the work is moved out-of-process.
Not everything has to be a "daemon". It's a bad trend in current programming zeitgeist to want to make everything into one. (sccache, no, you do NOT need a daemon to behave like ccache.)
For a PAM replacement, you want a separate process. It doesn't have to be a persistent separate process.
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.
The problem is that with LLVM, GCC, CUDA, Vulkan, POSIX, V8 and co, there will be lots of new C and C++ getting written as well.
Even on OpenJDK and CLR side, as new language features allow to rewrite even more runtime code from C++ into Java and C#, there is still new runtime code getting written in C++.
There is already clever tech for hardware memory tagging (SPARC ADI, and ARM MTE), CHERI is yet another way to tame unsafety on our computing stacks.
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.
