Possible Distributions quote of the year

Posted Jan 23, 2025 19:14 UTC (Thu) by mb (subscriber, #50428)
In reply to: Possible Distributions quote of the year by bluca
Parent article: Distributions quote of the week

>I can link my C program against the glibc shared library from 5 years ago, and it will work with today's.

>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.
C provides no more than that.

Possible Distributions quote of the year

Posted Jan 23, 2025 19:41 UTC (Thu) by bluca (subscriber, #118303) [Link] (18 responses)

And you can't link your Rust program against the Rust stdlib and have it work the day after, let alone after 5 years. Thanks for confirming my point.

Possible Distributions quote of the year

Posted Jan 23, 2025 19:48 UTC (Thu) by mb (subscriber, #50428) [Link] (17 responses)

C provides a stable C ABI.
Rust provides a stable C ABI.

You demand Rust to provide more.
Why?

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.
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++?

>you can't link your Rust program against the Rust stdlib and have it work the day after

Sure you can.
Why do you think a Rust program stops working after one day?

This is all FUD you are spreading.

Possible Distributions quote of the year

Posted Jan 23, 2025 20:01 UTC (Thu) by bluca (subscriber, #118303) [Link] (12 responses)

> Rust provides a stable C ABI.

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?

Possible Distributions quote of the year

Posted Jan 23, 2025 20:10 UTC (Thu) by mb (subscriber, #50428) [Link] (1 responses)

> Because that's what a mature, stable ecosystem like a Linux distro needs.

Ok.
Why do distros need that?

>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
> and the dynamic loader fails to find the dso that the program was linked to.

The stdlib is linked statically.
So, why does it stop working after one day?
Was I right that this was all FUD?

>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.
Where is the problem?

Possible Distributions quote of the year

Posted Jan 24, 2025 12:17 UTC (Fri) by bluca (subscriber, #118303) [Link]

> Why do distros need that?

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

Possible Distributions quote of the year

Posted Jan 28, 2025 10:32 UTC (Tue) by taladar (subscriber, #68407) [Link] (9 responses)

> Because that's what a mature, stable ecosystem like a Linux distro needs.

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.

Possible Distributions quote of the year

Posted Jan 28, 2025 13:14 UTC (Tue) by pizza (subscriber, #46) [Link] (5 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.

Yet.. that's what its paying customers want. And those customers are, by definition, correct.

Possible Distributions quote of the year

Posted Jan 28, 2025 13:29 UTC (Tue) by taladar (subscriber, #68407) [Link] (4 responses)

This is such a weird view that only really seems to exist in industries where safety isn't taken seriously and natural constraints are less obvious.

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.

Possible Distributions quote of the year

Posted Jan 28, 2025 14:19 UTC (Tue) by pizza (subscriber, #46) [Link] (3 responses)

> This is such a weird view that only really seems to exist in industries where safety isn't taken seriously and natural constraints are less obvious.

...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.

Possible Distributions quote of the year

Posted Jan 28, 2025 15:33 UTC (Tue) by Wol (subscriber, #4433) [Link]

> > 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.

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,
Wol

Possible Distributions quote of the year

Posted Jan 28, 2025 16:45 UTC (Tue) by pizza (subscriber, #46) [Link] (1 responses)

> 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".

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.

Possible Distributions quote of the year

Posted Jan 30, 2025 10:49 UTC (Thu) by taladar (subscriber, #68407) [Link]

In what way does an issue that occurred in all of the supported versions, including the ones with backports of the fixes, support your argument? This would have occurred in exactly the same way if everyone had used the latest version without any LTS versions.

Possible Distributions quote of the year

Posted Jan 28, 2025 15:04 UTC (Tue) by Wol (subscriber, #4433) [Link] (2 responses)

I don't know whether it's still true, or even was ever 100% true, but what you really want is something along the lines of the IBM mainframe maturity.

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,
Wol

Possible Distributions quote of the year

Posted Jan 28, 2025 15:14 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

And forgot to add the real big stupidity in this ... a lot of this is happening in the name of "privacy" - but it's making it impossible for the elderly compos mentis to retain privacy, because their ability to use the prescribed tools is fading ...

Cheers,
Wol

Possible Distributions quote of the year

Posted Feb 1, 2025 23:28 UTC (Sat) by mrugiero (guest, #153040) [Link]

Given how much of the current trend in politics is "stop spending money on the elderly", all this sounds more like a life hack than stupidity. Can't blame them for not paying for healthcare if the target audience can't ask for it.

Possible Distributions quote of the year

Posted Jan 24, 2025 18:29 UTC (Fri) by zdzichu (guest, #17118) [Link] (3 responses)

Strange argument about Rust providing stable C ABI. C provides C ABI, because it is C. No one is talking about C providing, let's say, stable Pascal ABI.

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.

Possible Distributions quote of the year

Posted Jan 24, 2025 18:57 UTC (Fri) by mb (subscriber, #50428) [Link] (1 responses)

> The lack of it is the crux of the discussion, isn't it?

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.
And by "modern languages" I mean C++ with templates, for example.

Possible Distributions quote of the year

Posted Jan 24, 2025 19:08 UTC (Fri) by daroc (editor, #160859) [Link]

This branch of the discussion too.

Meaning of "C" ABI

Posted Jan 25, 2025 9:36 UTC (Sat) by farnz (subscriber, #17727) [Link]

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.