Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hard Rust requirements from May onward

lists.debian.org

Post reply on HN
Print view View original

491–500 of 797 posts

Re: Hard Rust requirements from May onward

#491

Post by julian-klode »

einpoklum wrote: post #40

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…

Keep in mind APT is using the GNU dialect of C++, particularly C++ 17, shortly C++ 23. And it always exploits the latest C++ features while at the same time still having workarounds in the code for a lack of namespaces in C++ compilers prior to the C++ standardization...

Re: Hard Rust requirements from May onward

#492

Post by julian-klode »

tialaramex wrote: post #78
IshKebab wrote: post #51

Earlier quoted context omitted.

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.

Indeed. Four targets are identified as potentially affected: alpha, hppa, m68k and sh4 To be fair, lots of people did use Motorola 68xxx CPUs when those were new, it's just that it was 40+ years ago in products like the Commodore Amiga. The SH4 is most popularly connected to the Dreamcast, Sega's video game console from back when Sega made video game consoles. The Alpha and PA Risc were seen in relatively recent and…

Alpha and PA Risc where the predecessors of Itanium fwiw if you want to feel old in an easy to understand way.

Re: Hard Rust requirements from May onward

#493

Post by burntsushi »

larusso wrote: post #468
MerrimanInd wrote: post #448

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…

> And again the question why not simply write something new.

The world isn't black or white. Some people write Rust programs with the intent to be drop-in compatible programs of some other program. (And, by the way, that "some other program" might itself be a rewrite of an even older program.)

Yet others, such as myself, write Rust programs that may be similar to older programs (or not at all), but definitely not drop-in compatible programs. For example, ripgrep, xsv, fd, bat, hyperfine and more.

I don't know why you insist on a word in which Rust programs are only drop-in compatible rewrites. Embrace the grey and nuanced complexity of the real world.

Re: Hard Rust requirements from May onward

#494

Post by oofbey »

julian-klode wrote: post #482
jcranmer wrote: post #467

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.

Sure. But assembly implementations by definition are not portable. And I don’t know what it takes to write a formally verified library line this, but I bet it’s very expensive.

In contrast, a rust implementation can be compiled into many architectures easily, and use intrinsically safer than a C version.

Plus cryptography and PKI is constantly evolving. So it can’t benefit from the decades old trusted implementations.

Re: Hard Rust requirements from May onward

#496

Post by themafia »

lambdaone wrote: post #161

It's about time. 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. It's not as if Rust is that much more difficult to write than C. 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. If 32-bit x86 support can be dro…

> It's not as if Rust is that much more difficult to write than C

According to what?

> Rust is explicitly designed

There is no standard. It's accidentally designed.

> knowing what we know now about language design and code safety.

You've solved one class of bugs outside of "unsafe {}". The rest are still present.

Re: Hard Rust requirements from May onward

#497

Post by julian-klode »

blub wrote: post #393
coderjames wrote: post #368

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…

Recently the rust coreutils had a bug and this essentially disabled auto-updates on Ubuntu. :) Seeing this tone-deaf message from an Ubuntu employee would be funny if I didn’t actually use Ubuntu. Looks like I have to correct that…

Isn't it also funny that all of these things are done by the same person?

In all seriousness though, let me assure you that I plan to take a very considerate approach to Rust in APT. A significant benefit of doing Rust in APT rather than rewriting APT from scratch in Rust means that we can avoid redoing all our past mistakes because we can look at our own code and translate it directly.

Re: Hard Rust requirements from May onward

#498

Post by kelnos »

throwaway2037 wrote: post #413
jcranmer wrote: post #316

Earlier quoted context omitted.

Right now, there are approximately five languages that are presumed to be acceptable for core applications in the base system: C, C++, Shell (which probably means specifically bash), Perl, and Python. The most recent language to be added to that list is Python, about 20 years ago. That's not to say that everybody likes those languages (indeed, there's quite a few commenters here who I think would be surprised to lear…

Is X11/KDE considered part of the "base system"? If yes, then: > indeed, there's quite a few commenters here who I think would be surprised to learn that not only is C++ on this list, but that it's been on it for at least 25 years ... isn't so surprising.

I'm sure the Debian base system doesn't include GUI stuff at all.

Re: Hard Rust requirements from May onward

#499

Post by bgwalter »

jeroenhd wrote: post #437
teh64 wrote: post #403

Interesting how a person's opinion can change: https://news.ycombinator.com/item?id=27594688

If only more people were willing to let their opinions be changed over time like that, rather than clinging onto them.

If only a reason were given. This is the original:

> Rust is a security nightmare. We'd need to add over 130 packages to main for sequoia, and then we'd need to rebuild them all each time one of them needs a security update.

What has changed? Why is 130 packages for a crypto application acceptable?

Re: Hard Rust requirements from May onward

#500

Post by 4bpp »

fishmicrowaver wrote: post #401
4bpp wrote: post #192

Earlier quoted context omitted.

That is a crude and politically inept way of putting it, but do you not think there is some grain of truth to it? If you opt into something with as high a barrier to entry and necessary time commitment as a programming language, you naturally also opt into the existing community around that language, because that will be where the potential contributors, people to help you solve issues, and people you have to talk to…

Is that stuff still going on? People were rather intense about certain politics during COVID, but outside of some furries on the Rust discord I haven't noticed anything outwardly political?

I don't know how you would measure it, though I would assume that there is no particular reason for the people who use the language or their preferences to change? A quick search brought up that they apparently renamed their master branch to "main" very recently (https://blog.rust-lang.org/inside-rust/2025/10/16/renaming-t...) (context: https://sfconservancy.org/news/2020/jun/23/gitbranchname/), to the point I was more surprised that it hadn't already happened earlier.

The general temperature of politics in FOSS, I think, is not obviously lower than before: just in terms of things that made it onto HN, in the past month or so alone we have seen the aforementioned kerfuffle about dhh (the leader? founder? of Ruby on Rails), his projects and their detractors, and the wrestling over control between NixOS's board and its community moderators who were known for prosecuting political purges and wanted to assert formal authority over the former.

Post reply on HN