481–490 of 797 posts
Earlier quoted context omitted.
I wonder how much of that Perl support is simply regex and other parsing utilities. I’ve notice a lot of that in base OS systems Its a curiosity more than anything though
A substantial fraction of apt is written in perl. It's actually still pretty core to debian, even if applications are using it less.
Earlier quoted context omitted.
> In particular, our code to parse .deb, .ar, .tar, and the HTTP signature verification code would strongly benefit from memory safe languages > Critical infrastructure still written in C - particularly code that parses data from untrusted sources - is technical debt that is only going to get worse over time. But hasn't all that foundational code been stable and wrung out already over the last 30+ years? The .tar and…
> But hasn't all that foundational code been stable and wrung out already over the last 30+ years? Not necessarily. The "HTTP signature verification code" sounds like it's invoking cryptography, and the sense I've had from watching the people who maintain cryptographic libraries is that the "foundational code" is the sort of stuff you should run away screaming from. In general, it seems to me to be the cryptography f…
You don't want the core cryptography implemented in Rust for Rust's sake when there's a formally verified Assembler version next to it. Formally verified _always_ beats anything else.
I struggle to believe that this is really about a call to improve quality when there seem to be some other huge juicy targets.
Earlier quoted context omitted.
I think the Rust example’s biggest readability sin is using the full names of things like foo::bar::Baz instead of just Baz, but I get why they did that. When you import a lot of things into a file the latter way, it’s easy to get lost in “was that a foo Baz or a wiz Baz?” Sometimes it’s easier just to use the long names everywhere to be explicit. If I wanted to tweak the Rust project, I’d feel pretty confident I was…
That's a style choice that I think comes from former C++ devs. Java can potentially have the same problem. But because everyone uses an IDE and because it's rarely really an issue, everyone will simply import `Baz` rather than worry about the Foo::Baz and Bat::Baz collision. It does happen in java code, but I can't stress how infrequently it's actually a problem.
Earlier quoted context omitted.
Who is still using these machines? Genuine question, not trolling. It looks like the last machines of each architecture were released: Alpha in 2007 HP-PA in 2008 m68k in pre-2000 though derivatives are used in embedded systems sh4 in 1998 (though possible usage via "J2 core" using expired patents) This means that most are nearly 20 years old or older. Rust target triples exist for: m68k: https://doc.rust-lang.org/ni…
> Who is still using these machines? Genuine question, not trolling. Well, there are so many things were you could argue about the relevance of a userbase. If the size of a userbase would be the only argument, Valve could just drop support for the Linux userbase which is just 2-3% of their overall userbase.
Earlier quoted context omitted.
The Fil-C project ( https://fil-c.org/ ) seems like a more pragmatic way to deal with C security holes in old, well-loved userspace code. It effectively turns C into a managed language rather than a bare metal one, seems to remove a lot of the impetus to rewrite.
I really like the idea of Fil-C for derisking legacy code, but - It's not an option for debian core infrastructure until it supports at least the same platforms debian does (arm, riscv, etc) and it currently only supports x86_64. - It doesn't turn C into a modern language, since it looks like there's active development here getting the productivity benefits of moving away from C is likely still worth it.
Earlier quoted context omitted.
> Rust is explicitly designed to be what you'd get if you were to re-create C knowing what we know now about language design and code safety. I don't know about that. Look at the code for the COSMIC desktop environment's clock widget (the cosmic-applet-time directory under https://github.com/pop-os/cosmic-applets >), for example. It's pretty much unreadable compared to a C code base of similar complexity (GNU coreuti…
https://cgit.git.savannah.gnu.org/cgit/coreutils.git/tree/sr... I beg to differ.
The easiest way to see this is in US locales, which use 12-hour clocks in GNU 'date' but not other implementations:
$ date -d '13:00'
Sat Nov 1 01:00:00 PM PDT 2025
$ uu_date -d '13:00'
Sat Nov 1 13:00:00 2025
[1] https://github.com/coreutils/coreutils/commit/1066d442c2c023...
> This extends at first to the Rust compiler and standard library, and the Sequoia ecosystem. By Sequoia, are they talking about replacing GnuPG with https://sequoia-pgp.org/ for signature verification? I really hope they don't replace the audited and battle-tested GnuPG parts with some new-fangled project like that just because it is written in "memory-safe" rust.
Earlier quoted context omitted.
I've heard two arguments for these rewrites that don't always come up in these discussions. There are fair counterpoints to both of these but I think they add valuable dimensions to the conversation, or perhaps may explain why a rewrite may not seem justified without them. * It's becoming increasingly difficult to find new contributors who want to work with very old code bases in languages like C or C++. Some open so…
Yeah I get point for attracting young blood. But I wonder if the core utils which have been rewritten got rewritten by the original maintainers? And again the question why not simply write something new. With a modern architecture etc rather than drop in replacements. On your second part. I wonder how aviation and space and car industry do it. They rely heavily on tested / proven concepts. What do they do when introd…
Because of backwards compatibility. You don’t rewrite Linux from scratch to fix old mistakes, that’s making a new system altogether. And I’m pretty sure there are some people doing just that. But still, there’s value in rewriting the things we have now in a future-proof language, so we have a better but working system until the new one is ready.
Earlier quoted context omitted.
> But hasn't all that foundational code been stable and wrung out already over the last 30+ years? Not necessarily. The "HTTP signature verification code" sounds like it's invoking cryptography, and the sense I've had from watching the people who maintain cryptographic libraries is that the "foundational code" is the sort of stuff you should run away screaming from. In general, it seems to me to be the cryptography f…
Actual cryptography code, the best path is formally verified implementations of the crypto algorithms; with parsers for wrapper formats like OpenPGP or PKCS#7 implemented in a memory safe language. You don't want the core cryptography implemented in Rust for Rust's sake when there's a formally verified Assembler version next to it. Formally verified _always_ beats anything else.
The core cryptographic algorithms, IMHO, should be written in a dedicated language for writing cryptographic algorithms so that they can get formally-verified constant-time assembly out of it without having to complain to us compiler writers that we keep figuring out how to deobfuscate their branches.