Distributions quote of the week
The Debian project's goal is not to make Rust folks happy, rather it is to make Debian users happy. Perhaps the way they packaged Rust was the best that they could do under the constraints (which are enormous, given the existing infrastructure, user base, and cultural expectations)? I would personally show some humility when criticizing a project like Debian which stood the test of time like very few other open source projects.
Posted Jan 23, 2025 5:48 UTC (Thu)
by PengZheng (subscriber, #108006)
[Link] (60 responses)
Posted Jan 23, 2025 12:07 UTC (Thu)
by intelfx (subscriber, #130118)
[Link] (59 responses)
Posted Jan 23, 2025 12:47 UTC (Thu)
by taladar (subscriber, #68407)
[Link] (58 responses)
I would be especially concerned that this is about some sort of expectation on Debian's side to stick to some old Rust compiler version just because compilers in other languages often have breaking changes in newer versions, similar to the misconceptions that exist in the Linux project about it.
Posted Jan 23, 2025 15:30 UTC (Thu)
by amacater (subscriber, #790)
[Link] (57 responses)
Fedora doesn't have long term support for the same length of time as Debian's standard (approximate) three year support. Fast moving software ecosystems Python with pip / pypi, NodeJS and Rust are all problematic to all distributions to one extent or another. There's no easy way to square the circle but a lot of people very much prefer the stability that Debian gives. Debian derivatives and other Linux distributions are always open to do things differently
Disclaimer: I'm a Debian developer and have less experience with Fedora or the Red Hat ecosystem. I have no relevant experience building and working with Rust projects.
Posted Jan 23, 2025 15:36 UTC (Thu)
by intelfx (subscriber, #130118)
[Link] (56 responses)
I don't dislike that. On the opposite, I can get behind Debian's ideals.
Rather, my comment hinted at the fact that the goal of "making Debian users happy" is unlikely to be furthered by sticking the proverbial head in the sand and shouting "la-la-la, Rust software that doesn't work within our packaging ideology doesn't exist". Quoting one of the downstream comments in the lobste.rs thread:
> Like you say, the goal is to make Debian users happy, so I wonder, as more and more software gets written in Rust, will Debian users be happy to either have to live with Rust software that’s buggy and doesn’t work, or live without a larger and larger share of software?
Posted Jan 23, 2025 16:52 UTC (Thu)
by bluca (subscriber, #118303)
[Link] (53 responses)
Or - and hear me out on this - the Rust ecosystem could stop being so unstable and broken all the time, become as mature as that of other languages, stop catering only to large corporations deploying single applications or the convenience of individual developers at the expense of everyone else, and get a stable ABI and first class dynamic linking support. Just a thought, eh!
Posted Jan 23, 2025 17:07 UTC (Thu)
by mb (subscriber, #50428)
[Link] (37 responses)
Yeah. Would even be better if it would be true.
Posted Jan 23, 2025 17:34 UTC (Thu)
by bluca (subscriber, #118303)
[Link] (36 responses)
Posted Jan 23, 2025 17:54 UTC (Thu)
by mb (subscriber, #50428)
[Link] (35 responses)
Posted Jan 23, 2025 18:33 UTC (Thu)
by bluca (subscriber, #118303)
[Link] (34 responses)
Also I gather from your non-answer that the Rust stdlib still doesn't have a stable ABI, thanks for confirming the ecosystem is still very far from maturity and stability.
Posted Jan 23, 2025 18:42 UTC (Thu)
by mb (subscriber, #50428)
[Link] (33 responses)
I'm just reading your texts here and basing my answers on that.
>Also I gather from your non-answer that the Rust stdlib still doesn't have a stable ABI
Rust has exactly as much of a stable ABI as C has.
You are asking for more stable ABIs? Why?
Posted Jan 23, 2025 19:04 UTC (Thu)
by bluca (subscriber, #118303)
[Link] (32 responses)
You might want to try and do that more carefully then, as you are not really doing a great job, so far.
> Rust has exactly as much of a stable ABI as C has.
I can link my C program against the glibc shared library from 5 years ago, and it will work with today's.
So yeah, you'll have to provide some pretty good evidence to back the assertion that these standard libraries have the same stable ABI, because it is pretty obvious they don't.
Posted Jan 23, 2025 19:14 UTC (Thu)
by mb (subscriber, #50428)
[Link] (19 responses)
>you'll have to provide some pretty good evidence to back the assertion that these standard libraries have the same stable ABI
Ok.
I can link my Rust program against the glibc shared library from 5 years ago, and it will work with today's.
Same level of ABI compatibility that C provides.
Posted Jan 23, 2025 19:41 UTC (Thu)
by bluca (subscriber, #118303)
[Link] (18 responses)
Posted Jan 23, 2025 19:48 UTC (Thu)
by mb (subscriber, #50428)
[Link] (17 responses)
You demand Rust to provide more.
Why don't you demand C to provide a stable macro ABI? In case you don't get it: That's about the same as asking Rust to provide a stable generics ABI. Or at least it's as close as one can get without assuming Rust knowledge.
>you can't link your Rust program against the Rust stdlib and have it work the day after
Sure you can.
This is all FUD you are spreading.
Posted Jan 23, 2025 20:01 UTC (Thu)
by bluca (subscriber, #118303)
[Link] (12 responses)
Exactly. It doesn't provide a Rust stable ABI.
> Why?
Because that's what a mature, stable ecosystem like a Linux distro needs.
> Why don't you demand C to provide a stable macro ABI?
Because you don't have a ~100 MB blob of C macros that implements all the functionality and that is embedded and used in every single one of the tens of thousands binary executables shipped by the distribution. The glibc implementation in its shared library(ies) is perfectly adequate and does its job well, and can be maintained sanely. And that's just the standard library, there's all the other deps which is an even more gigantic mess. I thought this would be quite obvious, but maybe you are not very familiar with how Linux distros work - fair.
> Why are C++ template headers not a problem for the adoption of C++?
Who says they aren't?
> Why do you think a Rust program stops working after one day?
Because the Rust stdlib changes its hash from 123456789 to abcdefghi and the dynamic loader fails to find the dso that the program was linked to. Meanwhile, glibc has been libc.so.6 since what now, 20 years?
Posted Jan 23, 2025 20:10 UTC (Thu)
by mb (subscriber, #50428)
[Link] (1 responses)
Ok.
>Because you don't have a ~100 MB blob of C macros that implements
One byte is enough to break the expected ABI of the applications.
> Because the Rust stdlib changes its hash from 123456789 to abcdefghi
The stdlib is linked statically.
>Meanwhile, glibc has been libc.so.6 since what now, 20 years?
You can implement a shared library in Rust that just exposes C ABI and do exactly the same thing.
Posted Jan 24, 2025 12:17 UTC (Fri)
by bluca (subscriber, #118303)
[Link]
https://lwn.net/Articles/1005986/
> One byte is enough to break the expected ABI of the applications.
What? No?
> The stdlib is linked statically.
Did you miss that this is about dynamic linking? It's literally in the first post, that you are replying to: https://lwn.net/Articles/1005961/
> You can implement a shared library in Rust that just exposes C ABI and do exactly the same thing.
So the answer is, each distro has to reimplement their own standard library from scratch? I mean, it's _an_ answer for sure, but it's also a sad joke, which perfectly describes the current state of the whole ecosystem, and why it's completely unsustainable
Posted Jan 28, 2025 10:32 UTC (Tue)
by taladar (subscriber, #68407)
[Link] (9 responses)
I wouldn't exactly call what long term support distros do mature. It is more along the lines of childishly pretending that you can stop the world around you from changing because you want to really, really hard.
Posted Jan 28, 2025 13:14 UTC (Tue)
by pizza (subscriber, #46)
[Link] (5 responses)
Yet.. that's what its paying customers want. And those customers are, by definition, correct.
Posted Jan 28, 2025 13:29 UTC (Tue)
by taladar (subscriber, #68407)
[Link] (4 responses)
A plumber wouldn't say the customer is correct if they want pipes that are half as strong as the water hammers occurring will need to contained or made out of cardboard or some other material that couldn't contain water.
An engineer wouldn't say a city mayor is correct if they want a bridge that weighs half as much as it needs to be structurally sound.
An apple farmer wouldn't say the customer is correct if they want apples that don't spoil for ten years.
And yet software companies regularly promise their customers things that are impossible to deliver and just hope the customer isn't competent enough to notice or won't come back by the time they notice.
Posted Jan 28, 2025 14:19 UTC (Tue)
by pizza (subscriber, #46)
[Link] (3 responses)
...excuse me?
Safety-critical (and to a somewhat lesser extent, financial) environments epitomize this more than anyone else.
Any code change risks _new_ bugs being introduced. So only change the absolute minimum that is necessary to achieve what you need. So fixes are backported (if not outright re-implemented) instead of wholesale update to "the latest".
As for your "comparisons":
> A plumber wouldn't say the customer is correct if they want pipes that are half as strong as the water hammers occurring will need to contained or made out of cardboard or some other material that couldn't contain water.
Or... you could use the pipes that are already there, and only add/alter what you need instead of ripping out the whole building's plumbing every time a faucet needs replaced? (you know, the "LTS" approach that your example was claiming to refute)
> An engineer wouldn't say a city mayor is correct if they want a bridge that weighs half as much as it needs to be structurally sound.
Uh... this is _new_ construction? By definition you can't re-use anything that exists. Meanwhile, what you're actually describing is the classic engineering priority tradeoffs that apply in _any_ field of endeavor.
And your example is quite flawed in other ways -- instead of stone they could use steel (or something more exotic) that is much lighter while being more than capable of withstanding the design loads. Perhaps that lower weight is necessary due to site considerations (eg ruinously high transport costs) but those other materials may cost more. Again, classic engineering tradeoffs.
> An apple farmer wouldn't say the customer is correct if they want apples that don't spoil for ten years.
Code doesn't "spoil"; it meets the design requirements to which it was written tomorrow as well as a decade later.
(Hint: a change in runtime environment is a change in _requirements_)
Every time I get into my vehicle, my life depends on nearly forty-year-old software (on 30-year-old hardware!) operating as designed. The reason it can do that is because its runtime environment is truly _fixed_.
> And yet software companies regularly promise their customers things that are impossible to deliver and just hope the customer isn't competent enough to notice or won't come back by the time they notice.
Red Hat's (and Ubuntu's, and heck, even Microsoft's) continued corporate existence begs to disagree.
Things don't ahve to be _perfect_. They just have to be _good enough_ to get what you actually care about accomplished.
Posted Jan 28, 2025 15:33 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
> Code doesn't "spoil"; it meets the design requirements to which it was written tomorrow as well as a decade later.
And actually, I'd say the customer IS correct to *want* apples that don't "spoil" for ten years. Just because they're right to want it, doesn't mean nature will oblige. I want a "perpetual motion machine", that'll give the world free, pollution free electric. Just because I *want* it, doesn't mean I can *have* it.
You need to distinguish wants, needs, and possibilities. The world is in a big mess right now because (a) too many people can't tell the difference between "want" and "need", and too many people "need" the impossible and won't take "no" for an answer ...
Cheers,
Posted Jan 28, 2025 16:45 UTC (Tue)
by pizza (subscriber, #46)
[Link] (1 responses)
Here's a great example:
https://www.theregister.com/2025/01/28/microsoft_admits_t...
A recent (January 14) update to Windows (affecting all supported versions of 10 and 11) broke bog-standard USB audio devices.
...Which notably includes the likes of USB headsets that many folks depend on for their jobs.
Posted Jan 30, 2025 10:49 UTC (Thu)
by taladar (subscriber, #68407)
[Link]
Posted Jan 28, 2025 15:04 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (2 responses)
Each generation of hardware, going back to the 360 if not earlier, runs as an emulator on the newer hardware, so it's no problem to run a 360 application on the latest Z8000 or whatever they are nowadays. And even with your virtual 360 running on a virtual 370 running on a virtual ... running on real Z8000, it's probably running faster than the original.
There's actually a massive downside to all this change, and as I get older I feel it more and more keenly - "stop the world I want to get off!" Our latest problem is now the NHS has decided you have to interact with them via the app ... how on earth are the major consumers of the service - the elderly and disabled - going to cope with a smartphone they don't understand, can't read anything because the screen's too small, and fat-finger everything because not only can they not see what they're aiming at, but they can't aim straight because they've got a tremor, or poor co-ordination, or or or.
Still, I guess it's a good way of getting rid of all your most troublesome "customers" and saving shit-loads of money. Until they end up in A&E instead.
Cheers,
Posted Jan 28, 2025 15:14 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (1 responses)
Cheers,
Posted Feb 1, 2025 23:28 UTC (Sat)
by mrugiero (guest, #153040)
[Link]
Posted Jan 24, 2025 18:29 UTC (Fri)
by zdzichu (guest, #17118)
[Link] (3 responses)
To be equal with C, Rust would have to provide a stable RUST ABI. The lack of it is the crux of the discussion, isn't it?
Rust has to provide stable ABI to fit in with how the software is distributed nowadays (by Linux distributions). Without stable ABI it's just immature curiosity, working against decades of good practices.
Posted Jan 24, 2025 18:57 UTC (Fri)
by mb (subscriber, #50428)
[Link] (1 responses)
Nope. The lack of knowledge about Rust and at the same time the presence of very verbose FUD spreading is the crux of the discussion.
> Without stable ABI it's just immature curiosity, working against decades of good practices.
FUD, once again.
Please educate yourself about what ABI means w.r.t. modern languages like Rust and why decades of "good practices" mean nothing for modern languages.
Posted Jan 24, 2025 19:08 UTC (Fri)
by daroc (editor, #160859)
[Link]
Posted Jan 25, 2025 9:36 UTC (Sat)
by farnz (subscriber, #17727)
[Link]
Posted Jan 24, 2025 8:49 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (11 responses)
You have to do a lot of work to keep a C program working if it's dynamically linked against a C library - it just happens that if you use glibc, they do that work for you.
Posted Jan 24, 2025 12:19 UTC (Fri)
by bluca (subscriber, #118303)
[Link] (10 responses)
Posted Jan 24, 2025 12:22 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (9 responses)
Not that that should be a problem - after all, if C has a stable ABI, then I should be able to take a binary built against any libc and run it against glibc.
Posted Jan 24, 2025 12:44 UTC (Fri)
by bluca (subscriber, #118303)
[Link] (8 responses)
Nobody is saying that Rust should provide multiple independent and compatible standard libraries. At least one though would be nice...
Posted Jan 24, 2025 12:57 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (7 responses)
Posted Jan 24, 2025 13:11 UTC (Fri)
by bluca (subscriber, #118303)
[Link] (6 responses)
Posted Jan 24, 2025 13:16 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (5 responses)
Or I can use a language that also doesn't have a stable ABI of its own, and rely on the promises it makes, rather than digging through what "C has a stable ABI" means when you're not immersed in C on Linux day-in, day-out.
Posted Jan 24, 2025 13:46 UTC (Fri)
by bluca (subscriber, #118303)
[Link] (2 responses)
Posted Jan 24, 2025 13:47 UTC (Fri)
by bluca (subscriber, #118303)
[Link]
Posted Jan 24, 2025 13:51 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
Posted Jan 24, 2025 18:01 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
It's a stable ABI if you don't update it. See? Very easy!
Posted Jan 24, 2025 19:01 UTC (Fri)
by daroc (editor, #160859)
[Link]
Posted Jan 23, 2025 17:10 UTC (Thu)
by intelfx (subscriber, #130118)
[Link] (2 responses)
> Or - and hear me out on this - the Rust ecosystem could stop being so unstable and broken all the time
“Have you stopped beating your wife yet?”
Posted Jan 23, 2025 17:49 UTC (Thu)
by jzb (editor, #7867)
[Link] (1 responses)
OK, let's bring it down several notches or stop here. There is a reasonable conversation to be had about Rust's ecosystem and that would be on-topic, but this is going in an unproductive direction. Please keep it civil.
Posted Jan 23, 2025 21:30 UTC (Thu)
by intelfx (subscriber, #130118)
[Link]
Posted Jan 23, 2025 18:58 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (11 responses)
Yeah. Everything is broken. Just look at systemd. It's so broken, it had to invent a new ABI for library loading, modeled after ancient macOS mis-feature that had long ago been removed (for being broken).
Rust's stdlib has been stable for close to a decade, via the "editions" mechanism. It does not have a stable _ABI_, because it's mostly useless in a language that is dependent on monomorphisation.
Posted Jan 23, 2025 19:06 UTC (Thu)
by pizza (subscriber, #46)
[Link]
You should have stopped there, nobody would disagree.
The point here isn't that "Debian is broken" or "Rust is broken" (or even "systemd is broken") but that each of those has different underlying principles/goals that often wildly diverge.
Posted Jan 23, 2025 19:40 UTC (Thu)
by bluca (subscriber, #118303)
[Link] (9 responses)
Wait, is it "newly invented" or is it "ancient"? Seems like an either/or proposition, and yet you are asserting it's both
> Rust's stdlib has been stable for close to a decade, via the "editions" mechanism. It does not have a stable _ABI_, because it's mostly useless in a language that is dependent on monomorphisation.
It's useless in an immature, experimental ecosystem, sure. In a stable distribution it is very useful to have a stable ABI, so that for example you do not ship hundreds of gigabytes of binaries, and for example you don't multiply the memory footprint by x10000 as the dso are shared among all processes, and for example so that a security bug has to be fixed only once instead of ten thousand times, and more. Of course none of this matters for developers playing with toy projects, or for mega-corps shipping single-binary proprietary applications. But it matters a lot for a distribution - which is the subject of the thread.
Posted Jan 23, 2025 19:57 UTC (Thu)
by mb (subscriber, #50428)
[Link] (4 responses)
Why is that not exactly the same problem for C++ template libraries?
Why isn't this a problem for C++?
What happens, if there's a bug in your C macro from your C header?
Why isn't this a problem for C?
Also see this, if you want to learn something about Rust:
Posted Jan 23, 2025 20:06 UTC (Thu)
by bluca (subscriber, #118303)
[Link] (3 responses)
Who said it isn't?
> Why isn't this a problem for C?
Because nobody in their right mind ships hundreds of MBs of C macros that needs to have such updates in the first place in every single executable binary in the distribution. I'm sure there are extremely bizzarre corner cases of some weird libraries that have 3 users, 2 of which are crazy, but not in glibc, I cannot remember a single time were there was a glibc CVE that affected its macros.
Posted Jan 23, 2025 20:19 UTC (Thu)
by mb (subscriber, #50428)
[Link] (2 responses)
Ok. So C macros are not a stable ABI. It depends on the developer not to do stupid things.
Rust provides exactly the same guarantees and breaks exactly where C breaks.
If you want to create a shared library, why do you suddenly need more than what C provides?
Normal Rust crates are not libraries in the sense of '.a' or '.so'. That's not because Rust developers are just too lazy to provide a "stable ABI". It's because it doesn't even make sense. Just like it doesn't make sense to demand a stable ABI for C macros and C++ template headers.
Posted Jan 24, 2025 12:56 UTC (Fri)
by bluca (subscriber, #118303)
[Link] (1 responses)
glibc macros are not an _ABI_ period, as they are not in the shared object, the ELF loader doesn't even know they exist when your program is loaded. They are a stable API though, unlike Rust's. You can prove me wrong at any time by pointing out any change in glibc that broke programs because a macro in a glibc header changed.
> Rust provides exactly the same guarantees and breaks exactly where C breaks.
No, it doesn't. Every build of the Rust standard library has a different SONAME and is thus incompatible with the previous. Every build of the glibc standard library has the same SONAME and is thus compatible with all previous versions going back ~20 years or so.
Posted Jan 24, 2025 13:35 UTC (Fri)
by daroc (editor, #160859)
[Link]
So let's stop the discussion here — all the branches across the comments, please, not just this one.
Posted Jan 23, 2025 22:35 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
Yeah, new-fangled stuff introduces half-brained ideas that have not been vetted and tried in practice.
> It's useless in an immature, experimental ecosystem, sure.
Like all the new systemd tools? E.g. resolved breaking mDNS that has been working for decades. Or mount units that break with systemd's own philosophy of job supervision and don't support retries.
> In a stable distribution it is very useful to have a stable ABI, so that for example you do not ship hundreds of gigabytes of binaries, and for example you don't multiply the memory footprint by x10000 as the dso are shared among all processes
We actually have numbers. Alpine is mostly statically linked, and it's not that much larger in practice.
We also have a pretty good experience with Rust for large projects. I've been using it myself since before it was cool, and my project from 2016 still compiles fine. API stability is great, and Cargo works well to create reproducible environments. I don't have to tear out my hair because the newest distro lacks the old version of OpenSSL that is not backwards compatible with the one that I used.
And dynamic linking can't reasonably work with languages like Rust or C++ with templates. The most advanced language that even tries that is Swift.
Posted Jan 24, 2025 12:42 UTC (Fri)
by bluca (subscriber, #118303)
[Link] (2 responses)
So it's new according to you? That's funny, because according to the rest of the universe dlopen is so incredibly old that even ancient and dusty parchments known as POSIX mention it: https://pubs.opengroup.org/onlinepubs/009695399/functions...
But don't let facts get in the way of a good old baseless rant, by all means
> E.g. resolved breaking mDNS that has been working for decades
Works fine here, have you tried turning it off and on again?
> Or mount units that break with systemd's own philosophy of job supervision and don't support retries.
We use the interfaces that we are given, and proc/self/mountinfo was an absolutely horrid interface to work with, that doesn't work at any scale beyond trivial fixed mounts and is inherently racy. Now we got new and shiny APIs in the kernel, and as libmount from util-linux switches to it, the situation with mounts tracking should massively improve, especially in complex deployments. Yeah the situation sucked until now, no argument there.
> We actually have numbers. Alpine is mostly statically linked, and it's not that much larger in practice.
Yeah, because it ships nothing, it's basically busybox and a bunch of symlinks...
> I don't have to tear out my hair because the newest distro lacks the old version of OpenSSL that is not backwards compatible with the one that I used.
So the epitome of the Rust ecosystem can be summarized with "Let's use an old OpenSSL choke full of CVEs and with no security support whatsoever, that will surely cause no issue at all". That's a great advert. And then Rust fanboys wonder why people who need actually stable, secure and maintainable distributions have a problem with all of this...
> And dynamic linking can't reasonably work with languages like Rust or C++ with templates. The most advanced language that even tries that is Swift.
You say that it can't reasonably work, and then provide an example where it does reasonably work. That seems odd. But anyway it's an entirely self-inflicted problem: after the whole horrid mess of C++ templates, why oh why would anyone look at that and say "more please!" is something I cannot possibly fathom. But de gustibus, I guess.
Posted Jan 24, 2025 18:31 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Yeah. My dlopen()-less Alpine Linux now has dlopen() calls all over the place.
> Works fine here, have you tried turning it off and on again?
Yeah. And it changed the hostname behind my back: https://github.com/systemd/systemd/issues/35780
> We use the interfaces that we are given, and proc/self/mountinfo was an absolutely horrid interface to work with, that doesn't work at any scale beyond trivial fixed mounts and is inherently racy.
I don't really see what the lack of retries on positively indicated mount failures has to do with this API.
> Yeah, because it ships nothing, it's basically busybox and a bunch of symlinks...
And a libc that doesn't suck. And actually a quite complete distro with a fast package manager (apk routinely finishes installation while dnf/apt is still starting).
> So the epitome of the Rust ecosystem can be summarized with "Let's use an old OpenSSL choke full of CVEs and with no security support whatsoever, that will surely cause no issue at all".
In my case, I was using OpenSSL for encryption primitives that were not affected by any CVEs. Of course, having only crude C-style ABI it's not possible to have finer-grained libraries that only contain a subset of functionality. Just look at what systemd had to suffer through, they couldn't just split the utility library into a small "core" subset and a larger "journal" subset. They had to invent a whole new dynamic linking mechanism to paper over the insufficiencies of C.
> You say that it can't reasonably work, and then provide an example where it does reasonably work.
Yes, and Swift generics do not provide the functionality needed for Rust. In particular, they rely on runtime-linking (basically, a fancy vtable and autogenerated getters/setters) that makes it impossible to write high-performance code with dynamically-linked generics.
Posted Jan 24, 2025 19:03 UTC (Fri)
by mb (subscriber, #50428)
[Link]
No. Rust people rewrite critical CVE-ridden libraries in safe Rust and get entirely rid of the entire class of bugs that caused the most severe OpenSSL bugs in the past decades.
https://crates.io/crates/rustls
Posted Jan 23, 2025 19:22 UTC (Thu)
by ballombe (subscriber, #9523)
[Link] (1 responses)
What the lobster is actually asking is for Debian volunteers to align their goal with the rust project.
Posted Jan 23, 2025 19:28 UTC (Thu)
by mb (subscriber, #50428)
[Link]
That doesn't work for low level software that integrates into the system.
Posted Jan 23, 2025 12:46 UTC (Thu)
by liw (subscriber, #6379)
[Link]
Posted Jan 23, 2025 14:49 UTC (Thu)
by ejr (subscriber, #51652)
[Link] (1 responses)
There's nothing fundamentally wrong with /usr/local, /opt, or even just your home directory (except if it's shared across architectures / OSes). Plus there's appimage, singularity, flatpak...
This particular discussion is about low-level tools. Please don't make *those* change quickly if a system must rely on them. That is horrible to administer. If they absolutely must change quickly, well, I would try to avoid using the systems they manage.
I used to complain that applications I didn't want to compile myself moved too slowly in Debian. Then all the alternatives happened, and many of those applications have moved to them. (Except I still compile Emacs to ensure I **know** the base isn't going to change.)
Posted Jan 28, 2025 10:40 UTC (Tue)
by taladar (subscriber, #68407)
[Link]
As a sysadmin I desperately long for a time when they do change more quickly because the bane of my existence are LTS distros that need me to support ten year old stuff and brand new stuff at the same time. Because oddly enough nobody who runs those distros ever wants to stick to just software released back in the ancient times when that distro major version was first released. if you told me tomorrow that every distro stopped providing support for longer than 2 years or even 1 year that would be amazing for my stress levels.
Possible Distributions quote of the year
Possible Distributions quote of the year
Possible Distributions quote of the year
Possible Distributions quote of the year
I believe that Fedora has a similar approach to prefer single versions of libraries wherever possible.
That does make it easier to work out where some security problems lie - they'll be in one library version rather than many disparate versions on the system.
Possible Distributions quote of the year
Possible Distributions quote of the year
Possible Distributions quote of the year
Please use Rust once before commenting on it. It's obvious that you didn't.
Possible Distributions quote of the year
Possible Distributions quote of the year
I'm not going to explain Rust to you here.
But I would just suggest to stop making assertions about things you don't know.
Ok?
Too much to ask?
Possible Distributions quote of the year
Possible Distributions quote of the year
Possible Distributions quote of the year
Meanwhile, if I link a Rust program against the Rust stdlib from 5 years ago, it won't even work with the one from 4 years and 364 days ago, as it doesn't even have a stable SO version and its name contains a hash that changes with every build, so unstable it is. I do not believe this has changed at any point in the recent past.
Possible Distributions quote of the year
C provides no more than that.
Possible Distributions quote of the year
Possible Distributions quote of the year
Rust provides a stable C ABI.
Why?
Why are C macros not a problem for the adoption of C?
Why are C++ template headers not a problem for the adoption of C++?
Why do you think a Rust program stops working after one day?
Possible Distributions quote of the year
Possible Distributions quote of the year
Why do distros need that?
> and the dynamic loader fails to find the dso that the program was linked to.
So, why does it stop working after one day?
Was I right that this was all FUD?
Where is the problem?
Possible Distributions quote of the year
Possible Distributions quote of the year
Possible Distributions quote of the year
Possible Distributions quote of the year
Possible Distributions quote of the year
Possible Distributions quote of the year
Wol
Possible Distributions quote of the year
Possible Distributions quote of the year
Possible Distributions quote of the year
Wol
Possible Distributions quote of the year
Wol
Possible Distributions quote of the year
Possible Distributions quote of the year
Possible Distributions quote of the year
And by "modern languages" I mean C++ with templates, for example.
Possible Distributions quote of the year
Note that what Rust calls the "C" ABI isn't actually the C ABI; rather it's a sane interpretation of the psABI for your platform in terms of Rust constructs, chosen so that where there's multiple choices, the chosen option maps to what most C compilers for that platform will choose. It's just that if you called it the psABI, people would get confused (most of us don't look into this level of detail), whereas calling it the "C ABI" helps people's intuition, even though it's as accurate as calling Linux a Solaris-alike.
Meaning of "C" ABI
I have a C program linked against libc from 5 years ago that doesn't run on my modern system, because the C ABI is unstable, and I only have glibc's variant on the C ABI, not the one that the program from 5 years ago used (musl, I think, but I'm not sure).
Possible Distributions quote of the year
Possible Distributions quote of the year
getaddrinfo is the symbol that the dynamic linker complains about - there's something different about the glibc implementation to whichever libc this was linked against.
Possible Distributions quote of the year
Possible Distributions quote of the year
Why should it be obvious that, in a language with a "stable ABI", I can't pick and choose implementations of that "stable ABI", but have to limit myself to the glibc ABI, not the C ABI?
Possible Distributions quote of the year
Possible Distributions quote of the year
So what you're saying is that if someone accepts your definitions of what "C" is (after all, the standard library is part of C), then by your definitions, C has a stable ABI, as long as I limit myself to a single platform. But only if I limit myself to the subset of C that has a stable ABI on that platform, and don't try to use the parts of C that don't have a stable ABI on that platform, and then take care to use an implementation of the bits of C that don't have a stable ABI that, as an implementation issue, also promises a stable ABI on that platform, rather than an implementation with a different ABI, or even an unstable ABI.
Possible Distributions quote of the year
Possible Distributions quote of the year
Possible Distributions quote of the year
Changing to "the glibc ABI is stable" is not what you said, though. You promised me that the C ABI is stable, and it's, as a practical matter, not, since I have a binary written in C using just a POSIX libc that I cannot run, because I no longer recall which specific C it depends upon.
Possible Distributions quote of the year
Possible Distributions quote of the year
Possible Distributions quote of the year
Possible Distributions quote of the year
Possible Distributions quote of the year
Possible Distributions quote of the year
Possible Distributions quote of the year
Possible Distributions quote of the year
Possible Distributions quote of the year
Possible Distributions quote of the year
Think about what happens, if there's a bug in the boost template headers.
Think about what that means for all the applications that use your C library.
https://crates.io/crates/cargo-audit
https://crates.io/crates/cargo-auditable
Possible Distributions quote of the year
It doesn't matter if it's _theoretically_ possible, if it doesn't happen in reality.
Possible Distributions quote of the year
Glad you found out by yourself.
If you restrict yourself to the guaranteed C ABI, just like you have to do with your C library too, then everything is fine.
Possible Distributions quote of the year
Possible Distributions quote of the year
Possible Distributions quote of the year
Possible Distributions quote of the year
Possible Distributions quote of the year
Possible Distributions quote of the year
> "Let's use an old OpenSSL choke full of CVEs and with no security support whatsoever,
> that will surely cause no issue at all".
Possible Distributions quote of the year
It does not prevent you to use other way to install software.
In fact it even make that easier by providing cargo.
Debian only offer more options, it does not remove existing options.
Possible Distributions quote of the year
>In fact it even make that easier by providing cargo.
Why is Debian the way it is?
A stable baseline assists more rapid extensions.
A stable baseline assists more rapid extensions.