When is Rust going to have a stable distro experience? [LWN.net]

When is Rust going to have a stable distro experience?

Posted Jun 26, 2025 20:59 UTC (Thu) by Kamilion (subscriber, #42576)
In reply to: When is Rust going to have a stable distro experience? by Kamilion
Parent article: Getting extensions to work with free-threaded Python

Sorry, should have noted: the python cryptography error message is posted at https://ft-checker.com/ as part of their free-threading compatibility matrix. It's evident that their buildbox/CI system is using some ancient version of rust "from 2022".

I am not running into the problem myself; just found it mildly annoying to see.

NYKevin: Yes, your assumptions were correct on openssh; and apparently I'm not allowed to build it myself. I'm not clear on it myself, our auditor basically told us we couldn't use Alpine, Arch, or Gentoo, It's something dumb with the way they certify things.
I'm just the sysadmin, I don't make the rules, I just do my best to blindly follow them.

I can migrate our frontend server to unstable/testing Debian, but that just seems insane to put on the public internet. I could mix unstable packages on top of Bookworm, but that's a recipe for future disaster. "If I was still running ubuntu, i could have used a PPA." but canonical burned me too many times.

> But that's not the problem if Rust ABI: these packages don't expose anything with Rust ABI.
Khim: Perhaps we're speaking past eachother. The ABI to me, is the versioned symbols exposed in the libraries (including the stdlib bindings) so anything dlloading from a rust .so by necessity, exposes an ABI. The problem, is that rust's keeps churning for no apparent reason. I see version number go up, but I don't see the benefit. I'm not slapped with a release notes like Python3 that informs me of the major differences. If there is such a thing, I must have missed it, apologies in advance.

> P.S. I wonder where the conflation of “something is supported for X years” and “something may be used for X years without software upgrade” comes from. People often conflate these even if they are clearly very different.

"supported" is an overloaded term. Most normal people assume "support" means it will continue to operate as intended, and some communication facility is in place to make inquiries/request replacement. ("If it breaks, you get to keep *both* pieces.")

In computer science, it has a completely different meaning, indicating if a facility is available or unavailable. ("Ethernet/Wifi/Bluetooth support")

In open source, "supported" also has a different connotation: Is the original author willing to make changes based on consumer feedback? If the answer is no, then the software is considered "unsupported" but remains operational.

Average humans are rather bad at unwinding overloaded terms. It takes a nerdling to stop and think and disambiguate their meanings on the fly, or so it seems. (No offence intended, nerd is a positive attribute to me.)

> No. It mandates that whatever has shipped has gone through extensive certification processes. Changes are permitted but each (no matter how minor) has to be separately justified, documented, and extensively tested.

> ...As the saying goes, safety regulations are written in blood.

pizza: Just curious, in this context, what does "shipped" mean? Providing new downloads? Mailing a storage device? Exchanging a 1U rack appliance?

to post comments

When is Rust going to have a stable distro experience?

Posted Jun 26, 2025 21:39 UTC (Thu) by pizza (subscriber, #46) [Link] (13 responses)

> pizza: Just curious, in this context, what does "shipped" mean? Providing new downloads? Mailing a storage device? Exchanging a 1U rack appliance?

As in the sale/delivery of a physical product from a manufacturer to its customer[1]. If that customer eventually resells said product to a third party, the original manufacturer's obligations transfer over to the new owner.

(Think medical devices, automobiles, or anything else that could be considered safety-critical or whose behavior is highly regulated)

[1] More often than not, this is the date of the _final_ sale/delivery of a given product.

When is Rust going to have a stable distro experience?

Posted Jun 27, 2025 1:49 UTC (Fri) by Kamilion (subscriber, #42576) [Link] (12 responses)

Noted. Appreciate your term expansion within that domain of expertise.

Disregard the following, if you would.
<rant>
Although, just from your shortlist, I already "know" some corner cases.

Medical Devices? *shudder* Last time I was in a hospital, I witnessed several patient monitoring devices clearly operating on top of Android. I doubt they have Playstore available on them, but I assume they've bodged up some other OTA mechanism, as there's no way they could have gotten things right the first time.

Automobiles? *shudder* My 1996 honda civic has never required a firmware update to my knowledge. My acquaintances' modern vehicles seem to defy this concept, requiring frequent OTA pushes (with no apparent oversight) that can affect safety-critical devices on the CAN busses. Generally they have some sanity interlocks, but the telematics system is in full control over all of the other busses in the automobile. Blessings upon SocketCAN, my beloved userspace problemsolver. Why yes, I *can* change the configuration of your daytime running lights after an interstate move.

Aviation? *shudder* I'll take my chances on a train. They won't fall out of the sky if something goes wrong. Sure, there's plenty of other problems with rail, but it's still a lot safer than automotive statistics. Boeing isn't exactly winning any favors recently; anyone remember how proud they were to use ADA/Spark? Meanwhile the whole geolocking from newag just reinforces my point. Give them a picometer, and they'll take a kilometer.

I respect MISRA as much as the next guy, but I also interact with a lot of code artifacts that are the absolute inverse of mission critical. Entertainment code is... Yeah, there's an XKCD about voting machines? That one. Take it into the desert and burn it. Wear gloves.

When *IS* the date of the final sale/delivery of a product in this era? (this is rhetorical, and doesn't require a serious answer, I've got plenty of purchase orders and invoices to reference.)
And at what point do we get a warranty extension from a vendor's update? (At their discretion, of course. Which is, basically never, unless the consumer recalls twists their arm. How many recalls is GM up to for a single model now? 13? 14?)
Is anyone going to bother getting that in law, or are we going to continue waffling about generative AI for the next decade? (D: All of the above.)

I'm seriously tired with the obsequious Terms of Service that I *must* agree to, in which the other party has demarked the ability to change the rules at any time, and denied me the same. It's not that I generally *want* to change the contract, it's just become so one-sided these days that consumer rights have almost become a joke like military intelligence, canning jars, jumbo shrimp, or advanced BASIC.

That's part of the reason why, despite all the pain and vitriol, I remain committed to the GPL; which appears during the process of copying, and vanishes as soon as the copy has concluded.

</rant>

When is Rust going to have a stable distro experience?

Posted Jun 27, 2025 11:41 UTC (Fri) by pizza (subscriber, #46) [Link] (2 responses)

> When *IS* the date of the final sale/delivery of a product in this era? (this is rhetorical, and doesn't require a serious answer, I've got plenty of purchase orders and invoices to reference.)

Generally, it's when the manufacturer ceases selling the device, or delivers the final example if those two dates are not the same.

> And at what point do we get a warranty extension from a vendor's update?

Warranties universally kick in at the time of sale, with a fixed scope and duration, and may or may not be transferable upon resale. Repairs _may_ yield extensions to the general warranty, but it is rare that the extension covers anything other than what was scoped in the repair. But warranties are generally a contractual term that can be altered or waived. Laws/regulations transcend that.

Let's say I have a 3 year warranty on a car; I get a repair done at 2.5 years; that repair has a 1yr warranty. If the repaired part breaks at year 3.1, they have to fix it for free, but if anything else breaks, I have to pay if I want it fixed. Let's also say that my specific car was was manufactured and sold in 2020, and was sold until early 2021. This means the manufacturer is on the hook to supply certain spare parts and perform safety-related recalls at no charge for my specific car until until 2031 (ten years after the final unit was sold, but eleven after I purchased it)

This is an oversimplification but I hope it offers some clarification.

> I respect MISRA as much as the next guy, but I also interact with a lot of code artifacts that are the absolute inverse of mission critical.

If you *shudder* so much thinking about the state of code in automotive, medical, or aviation, consider that those are overwhelmingly superior in quality to everything else in your life. It's quite depressing.

(But I'd also caution you to recognize that not every bit of code in a car, airplane, or medical device has "life or death" safety implications. There are strict redundancy, robustness, and isolation requirements for the latter..)

When is Rust going to have a stable distro experience?

Posted Jun 28, 2025 2:57 UTC (Sat) by NYKevin (subscriber, #129325) [Link] (1 responses)

> (But I'd also caution you to recognize that not every bit of code in a car, airplane, or medical device has "life or death" safety implications. There are strict redundancy, robustness, and isolation requirements for the latter..)

Indeed, the amount of code that has safety implications in aviation is probably dwarfed by the amount of code that's just there to make the seat-back entertainment system work.

(And no, that's not a problem. The entertainment system is or should be fully air-gapped from the avionics. It's really just an elaborate HTPC-like-thing with a lot of screens and a terrible bespoke UI. If it breaks, oh well, the passengers can't watch movies, and maybe we have to do the safety presentation the old-fashioned way instead of playing the fancy video that marketing told us we're supposed to play for that purpose.)

When is Rust going to have a stable distro experience?

Posted Jun 28, 2025 22:13 UTC (Sat) by SLi (subscriber, #53131) [Link]

Eh, yes, should be. Cost cutting always results in "there's an obviously idiot proof software solution, nothing can go wrong." 🙈 Which might even work well enough absent hostile attacks. In practice, although I don't know all the safety critical domains, I'm afraid it's more like VLANs instead of physically separate networks. And that... probably works, absent malice, which the industries are only learning to think about.

When is Rust going to have a stable distro experience?

Posted Jun 28, 2025 22:09 UTC (Sat) by SLi (subscriber, #53131) [Link] (8 responses)

> Medical Devices? *shudder* Last time I was in a hospital, I witnessed several patient monitoring devices clearly operating on top of Android. I doubt they have Playstore available on them, but I assume they've bodged up some other OTA mechanism, as there's no way they could have gotten things right the first time.

Having worked in that and other safety critical domains I can say the needed shift of mindset is not easy coming from a normal world. But no, I don't think running on Android is a problem, especially if it's an old version of Android.

The big principle here is that you've supposedly thoroughly verified that your product does what it should, in a way that avoids danger. You want to guarantee that it will keep behaving _exactly that way_, down to having the same buggy behavior, unless there's a really good reason to make a change—and be prepared to justify that well.

That means you don't upgrade your Android. That would be madness. It worked in 2014 and doesn't kill anybody; why would it suddenly have stopped working if used the same way? As a general rule, you're not supposed to expose these things to anything hostile, and I find that's one place where the safety critical industry is still coming to the realization that they need to be able to do better than to wave hands around "the hospital network is a secure private network", but "doesn't kill the patient in a non-malicious context" still by far trumps that. The human hardware and software hasn't changed much since 2014, and you don't connect it to anything fancy new uncertified.

It's also my understanding that modern airplanes come with erratas that are much thicker than the manuals. That's all known bugs that are seemed not severe enough to warrant fixing given they do not endanger humans or prevent operating. As an example, one plane model had a bug where a landing system would reboot (we avoid the word "crash" here) if you tried to land on a runway with a heading of 0.0°. Then it would reboot and quickly come back online.

The errata gives a workaround: You set it to 0.0° and, if needed, land slightly off the middle line to compensate.

Do you really think that an industry that prefers this to fixing the software to jump happily when you tell them "just upgrade the compiler"? It probably won't even run on the computers they're allowed to use to build that software from 2014 :D

When is Rust going to have a stable distro experience?

Posted Jun 28, 2025 22:35 UTC (Sat) by mb (subscriber, #50428) [Link] (7 responses)

> Do you really think that an industry that prefers this to fixing the software to jump happily when you tell
> them "just upgrade the compiler"?

No.
Just don't upgrade *anything*.
It will keep working and compiling.

Expecting to be able to upgrade random A while avoiding upgrading fundamental B is beyond my understanding.

When is Rust going to have a stable distro experience?

Posted Jun 28, 2025 22:47 UTC (Sat) by Wol (subscriber, #4433) [Link] (6 responses)

> It will keep working and compiling.

I think North American Air Traffic Control would beg to differ. They can no longer find a reliable source of 5 1/4" floppy disks, I believe ...

Cheers,
wol

When is Rust going to have a stable distro experience?

Posted Jun 28, 2025 22:52 UTC (Sat) by mb (subscriber, #50428) [Link] (5 responses)

I was obviously talking about software.

When is Rust going to have a stable distro experience?

Posted Jun 30, 2025 10:39 UTC (Mon) by taladar (subscriber, #68407) [Link] (4 responses)

Even with software achieving the state where you don't upgrade anything at all can be hard due to changes in your environment (e.g. systems you need to talk to change, legal requirements change, the hardware you run on changes because the old version is no longer available).

The really big flaw, however, is the idea that changing a few things is almost as good as not changing anything, especially when changing those few things results in a version that is much less tested than the latest upstream stable version of a piece of software (e.g. backporting just security fixes). All you get is a changed version, often changed by people with a lot less experience with the software, that is less tested and immediately sent to the people with the highest stability requirements as the first users to discover all the newly introduced bugs.

When is Rust going to have a stable distro experience?

Posted Jun 30, 2025 11:03 UTC (Mon) by pizza (subscriber, #46) [Link] (3 responses)

> The really big flaw, however, is the idea that changing a few things is almost as good as not changing anything, especially when changing those few things results in a version that is much less tested than the latest upstream stable version of a piece of software (e.g. backporting just security fixes).

You forget that (1) upstream's tests don't cover *your* code, (2) upstream may *intentionally* change how something behaves vs an older version, introducing a regression that upstreams do not consider a bug (this is the unfortunate norm for Python, for example), and (3) most upstreams don't have "stable" vs "unstable" distinction, freely mixing fixes for old problems in with new development.

RHEL covers all three situations -- they backport fixes to their own "stable" branches, run all upstream tests, and also have a comprehensive in-house test suite (often including [propritary] customer software) that includes looking for ABI/API changes. Actual RHEL customers pay a lot of money for this work because they find it valuable (And as an aside, everyone who uses CentOS, Alma, Rocky, or any of the zero-cost RHEL rebuilds also finds it quite valuable, but for some reason feel entitled to get it all for free..)

When is Rust going to have a stable distro experience?

Posted Jul 1, 2025 8:57 UTC (Tue) by taladar (subscriber, #68407) [Link] (2 responses)

> Actual RHEL customers pay a lot of money for this work because they find it valuable

Because they find it valuable to have someone to blame, not because the actual work is valuable. RHEL is one of the most painful distros to use and administer out of all I have ever used and things break much more often than on e.g. Debian despite RHEL having a small fraction of the packages.

> And as an aside, everyone who uses CentOS, Alma, Rocky, or any of the zero-cost RHEL rebuilds also finds it quite valuable, but for some reason feel entitled to get it all for free

Mainly because they need to be compatible with RHEL for some requirement dictated externally (e.g. build some binary to run on RHEL, some driver is only developed for RHEL,...) not because those distros are easy to use or even particularly stable.

When is Rust going to have a stable distro experience?

Posted Jul 1, 2025 14:03 UTC (Tue) by pizza (subscriber, #46) [Link] (1 responses)

> Because they find it valuable to have someone to blame, not because the actual work is valuable.

Make up your mind; either what they provide is valuable, or it's not.

Keep in mind Red Hat is bringing in about $6.5 billion in annual revenue; that works out to somewhere between 2.3 million and 32.5 million individual RHEL licenses (using the $200->$2800/yr fees they list on their web site).

> Mainly because they need to be compatible with RHEL for some requirement dictated externally (e.g. build some binary to run on RHEL, some driver is only developed for RHEL,...) not because those distros are easy to use or even particularly stable.

There you go redefining terms again. ISVs and end-users clearly find that multi-year supported "stable" target to be quite cost-effective, and definitely more so than the alternatives.

When is Rust going to have a stable distro experience?

Posted Jul 3, 2025 8:14 UTC (Thu) by anselm (subscriber, #2796) [Link]

Keep in mind Red Hat is bringing in about $6.5 billion in annual revenue; that works out to somewhere between 2.3 million and 32.5 million individual RHEL licenses (using the $200->$2800/yr fees they list on their web site).

Sure, but presumably a certain number of these licensees run RHEL not because they think RHEL and its policies are the bee's knees, but because they're really interested in running something else that requires them to have RHEL underneath it, so they don't really have a choice in the matter (and the “something else” is so expensive that the RHEL licenses disappear in the noise floor).