Feels accurate to me. He's clearly anticipating the "but how will I run Debian on my PDP-11??" naysayers that always try to derail things.
Or those annoying nagging "well, what if I don't have an X86_64 CPU that was made in the last five years?", to which obviously our response should be: "get different hardware LOL, closedwontfix"
No, supporting 5 year old mainstream hardware is a very reasonable thing to do. Supporting 20 year old hardware that barely anyone used even when it was new is not.
The language is tough love, and I think it's important despite what the first respondent has said. Much of the language used seems to stem from nauseating interactions that have occured in kernel world around rust usage. I'm not a big fan of rust for reasons that were not brought up during the kernel discussions, but I'm also not an opponent of moving forward. I don't quite understand the pushback against memory safe…
[flagged]
Ironically, the people hating on it (and usually without any technical arguments) act way more cultish.
At least it looks that way to my not-rust-using self
If anyone has a problem with the language used in the email, I would remind you that this is the same person who is maintainer for debian's keepassxc packages.
Yes, but we're not making a push to make everything a bilingual c/lisp code base. Rust people for some reason are.
Not a Rust or even a systems language guy but it’s not “for some reason”. The reason is actually incredibly clear and about removing the single largest surface area of security problems in the entire history of Linux.
> The reason is actually incredibly clear
There is no guarantee that other bugs do not flurish in the rust echosystem.
There are no publicly known quality code checks of rust programs except a big "trust us"(see firefox with all its CVEs, despite "rust"). And combined with the Cargo echosystem, where every malicious actor can inject malware is a big warning sign.
The language is incredibly frank, and I agree with it completely. The retro-computing hobby doesn't need the ability to run contemporary operating systems. It's insane that x86 Debian is still compiling all software targeting Pentium Pro (from 1995!). x64 Debian is a bit more modern, and you must splurge for a CPU from 2005 (Prescott) to get the plethora of features it requires
Is it just the "retro-computing hobby"? There could still be businesses who might need support for old machines, especially in developing countries. I don't know the actual situation though, I'm open to the idea that my suggestion is insane.
It's much more common to find businesses running on very old hardware in developed countries, not in developing ones. Developing nations basically didn't use computers 20-30 years ago, there's no random remnants from that era beyond some extreme tail end. And, given how the PC & server market evolved in the 2000s and 2010s, it was cheaper to buy a then-current x86 than to import some ancient Alpha system from wherever. Especially so since software licenses didn't really exist in those days in developing countries - even government institutions often ran pirated software without a second thought.
The language is tough love, and I think it's important despite what the first respondent has said. Much of the language used seems to stem from nauseating interactions that have occured in kernel world around rust usage. I'm not a big fan of rust for reasons that were not brought up during the kernel discussions, but I'm also not an opponent of moving forward. I don't quite understand the pushback against memory safe…
> I don't quite understand the pushback against memory safe languages
As far as i read on HN, the only memory safe language discused on HN is rust and mostly with childish pro arguments.
For me it actually is the language. While a little pushy at times I think the arguments for rewriting certain things in a safer language is well founded. If the apt tool chains is one of those places I'll leave for the Debian developers to determine, but for decompression tools I can see a benefit. If Rust should be the language of choice, preferably not. The syntax is awful, the language is complicated and Rust prog…
> While a little pushy at times I think the arguments for rewriting certain things in a safer language is well founded.
Yes. It is. Just write the code and show us that it is good.
That seems like a bad idea to me: Dependencies will be added, for very basic system utilities, on (parts of) a software ecosystem which is still a "moving target", not standardized, and IIANM itself has further dependencies. I wonder whether platform compatibility won't be jeopardized, either. I would be worried if even C++ dependencies were added for basic system utilities, let alone something like Rust. Now, grante…
> Dependencies will be added, for very basic system utilities, on (parts of) a software ecosystem which is still a "moving target", not standardized,
This is the status quo and always has been. gcc has plenty of extensions that are not part of a language standard that are used in core tools. Perl has never had a standard and is used all over the place.