Great write-up. And, thanks mitchellh for Ghostty, I switched to it last year, and have not regretted it.
However, I am a somewhat surprised that the fix is reserved for a feature release in a couple of months. I would have expected this to be included in a bug fix release.
I guess thats arguable, a memory leak can make a system unpleasant to use although I accept it can be solved by repeatedly restarting the offending app.
SSH was around, but not nearly as pervasive it is today. I have memories of having to shake my mouse around during the windows client installation to generate entropy. Fun times
I believe your recollection is off by several years...
What you're describing is PuttyGen. According to Wikipedia, the first Putty release was in 1999. Archive.org doesn't have any snapshots of the Putty website before 2000, so that checks-out.
The RSA patent didn't expire in the US until September 2000, so that's when free implementations like OpenSSH first became widely available. That's precisely when I started using it...
The original SSH was first released mid-1995. There would have been a small number of installations in 1996, but absolutely negligible. It was not well-known until later, circa 2000.
> There would have been a small number of installations in 1996, but absolutely negligible.
On HN there's always a good chance you're talking to some of the people involved in those "negligible" installations. I know that I submitted some patches to Tatu Ylönen for Ssh to compile on Ultrix, so that must have been in 1995 or early 1996 because after that I didn't have access to any Ultrix machines. I may have been an early adopter, but it didn't take long for ssh to take over the world, at least among Unix system administrators; at Usenix within a year everybody was using ssh because there wasn't any alternative and in terms of security it was a life-saver.
As for the RSA patent... I don't know what license the original Ssh was released under, but it was considered "freeware" when it came out and nobody cared about the US RSA patent. Maybe technically in the USA you shouldn't have used it? Nobody cared.
And the mouse-jiggling thing... not specifically a PuttyGen thing. On linux /dev/random device gave you a few bits at a time stingily, only after it had enough entropy, so it was common for programs that needed good randomness to ask you to jiggle the mouse because that was one of the sources of entropy, so bits random bits would come faster. I'm pretty sure that was still the case well into the Zips.
so I was running a SVN server in a decommissioned PC somewhere in a startup as an intern. whole company ends up using it and out of nowhere it used to freeze, I would go to check if it had rebooted or crashed and everything was fine.
it fixed by itself, without any fixes from my part. happened many times.
asked for help to a senior, guy ran strace and found a read waiting in /dev/random. and of course it solved by itself any time I checked because I was moving the mouse!
controversially but acceptably, we had linked it to urandom and move on
how fast that guy used strace and analyzed the syscalls inspired me to be better at linux
> it didn't take long for ssh to take over the world
That doesn't seem to be accurate. Wikipedia says, by the end of "2000 the number of users had grown to 2 million"
> everybody was using ssh because there wasn't any alternative
I already listed TWO of the most popular alternatives.
> the mouse-jiggling thing... not specifically a PuttyGen thing. On linux
Parent specifically said "windows client installation." Putty was very common on Windows. PuttyGen specifically and prominently told the user to move their mouse... etc. etc.
The typestate pattern common in Rust applications allows the compiler to verify that the operations are executed in the right order and that previous states are not accidentally referenced. Here’s a good description: https://cliffle.com/blog/rust-typestate/
Thanks for the link - typestate is exactly the kind of compile-time guarantee I wish we had in JS/TS land. The pattern would be perfect for enforcing "you can't call postToAccounting() until validateTotals() has been called" at the type level.
We're in Node.js so the best we can do is runtime checks and careful typing. I've experimented with builder patterns that sort of approximate this - each method returns a new type that only exposes the valid next operations - but it's clunky compared to proper typestate.
The real benefit isn't just preventing out-of-order calls, it's making invalid states unrepresentable. Half our bugs come from "somehow this transaction reached step 9 without having the field that step 5 should have populated."
Fil-C is an innovative approach and a great technical achievement. However, I wouldn't suggest that it is an universal solution without caveats. For instance, the performance penalty of up to 4x is not acceptable in a lot of cases.
bzip2 is tiny, has relatively low overhead in Fil-C (forget exactly what it is but not 4x), and last I checked this Rust version still has >100 uses of unsafe.
Fil-C doesn't stop the data race problems the borrow checker would catch does it?
Has anyone tried pointing an agentic ai at recreating a c utility by looking only at the man page and using differential fuzzing? It isn't a port, so no licensing issues, and the code would use unsafe, and presumably be more idiomatic. I have no idea if it would ever complete, or just get stuck in an endless loop. Or even if it did succeed, how many joules it would use.
I'm sure when you try to get a AI to recreate such a tool, ths code would be unmaintainable, bloath, slow and shitty, but in the end it would work in some way. Interesting topic, but nothing to go productive with.
Even if it wasn't single threaded, it would probably have been fine grained OMP style multithreaded which runs into far fewer issues. I was just making sure I understood what Fil-C was doing. I hadn't heard of it. It seems like a great thing.
Great write up, focusing on facts without fingerpointing.
But I must admit I was somewhat surprised Cloudflare was not already proactively monitoring and tuning the generation sizes. Configuring the generation sizes was table stakes for JVM performance tuning back in the day.
We choose to be transparent when we fix stuff, even if it makes us look a bit silly :-) . We are certainly installing more logging and tracking of this sort of thing!
In general I think the GC should auto-adapt as much as possible. It's a bit of an admission of defeat for the GC author if the users have to spend a lot of time tuning the parameters. What we are doing here is removing the tuning that was no longer correct, and allowing V8 more latitude to pick its own young gen size.
I am curious, does anyone know what is the use case that mandates the use of git on NonStop? Do people actually commit code from this platform? Seems wild.
reply