Defining the Rust 2024 edition

Posted Jan 30, 2024 17:08 UTC (Tue) by bluca (subscriber, #118303)
In reply to: Defining the Rust 2024 edition by atnot
Parent article: Defining the Rust 2024 edition

> There is one (1) notable linux distribution where packages are still added to the archives by semi-random people just uploading them to an FTP site from their personal computers as and when they please.

And which one distribution would that be? Because for sure it's not Debian, where all binary packages in a release must have been built on the distro build infrastructure since at least a few releases.

> But yes, maybe entirely new build and release tooling should be something to be look into.

Cool, when are you getting started and by which date can we expect to see the fully working result? Or alternatively, when are you going to wire the tens of millions required to pay for such work to happen?

Defining the Rust 2024 edition

Posted Jan 30, 2024 19:04 UTC (Tue) by atnot (subscriber, #124910) [Link] (5 responses)

> Because for sure it's not Debian, where all binary packages in a release must have been built on the distro build infrastructure since at least a few releases.

It's a good step, what about source packages.

> Cool, when are you getting started and by which date can we expect to see the fully working result? Or alternatively, when are you going to wire the tens of millions required to pay for such work to happen?

Look, there's plenty of people inside debian who have tried to do this. And the tens of millions figure doesn't get any less ridiculous the more you say it. There's single-person distros who manage this stuff. There's small teams inside debian that manage this (e.g. the go packaging team). The obstacle has always been political, down from the hermit maintainers that get upset and boycott a change if you meddle with their fiefdom by asking them to use a new version of a packaging tool, to the DPLs that run on a platform of not changing anything. Perhaps using your hypothetical tens of millions of dollars to bribe every developer with $10k would help that though.

Defining the Rust 2024 edition

Posted Jan 31, 2024 11:59 UTC (Wed) by bluca (subscriber, #118303) [Link] (4 responses)

> It's a good step, what about source packages.

What about them?

> Look, there's plenty of people inside debian who have tried to do this. And the tens of millions figure doesn't get any less ridiculous the more you say it. There's single-person distros who manage this stuff. There's small teams inside debian that manage this (e.g. the go packaging team). The obstacle has always been political, down from the hermit maintainers that get upset and boycott a change if you meddle with their fiefdom by asking them to use a new version of a packaging tool, to the DPLs that run on a platform of not changing anything. Perhaps using your hypothetical tens of millions of dollars to bribe every developer with $10k would help that though.

Yes, there are plenty of people who have tried and are trying, and they are all ultimately failing. Not their fault of course, they are fighting an unwinnable, uphill struggle against an hostile ecosystem that couldn't possibly care less about them. So yes, to actually make this viable it would cost tens of millions, because it would need a few dozens of FTE engineers to work on it forever, and labor costs money in this universe.

Defining the Rust 2024 edition

Posted Jan 31, 2024 14:11 UTC (Wed) by joib (subscriber, #8541) [Link] (3 responses)

> Yes, there are plenty of people who have tried and are trying, and they are all ultimately failing. Not their fault of course, they are fighting an unwinnable, uphill struggle against an hostile ecosystem that couldn't possibly care less about them.

So perhaps the issue here is that it's the traditional Linux distros that need to adapt to how language ecosystems and software ecosystems work outside the 1980'ies C world? You can tilt at the windmills and scream "CADT!!!" all you want, but the rest of the world is not going to drop whatever they're doing and go back to the good 'ole days of plain C and POSIX sh. There's a lot of crap ideas out there, but all ideas that are different than the 1980'ies C view of the world are not automatically bad.

Defining the Rust 2024 edition

Posted Jan 31, 2024 14:18 UTC (Wed) by pizza (subscriber, #46) [Link] (2 responses)

> So perhaps the issue here is that it's the traditional Linux distros that need to adapt to how language ecosystems and software ecosystems work outside the 1980'ies C world?

....Yeah, how dare folks want to be able to handle their traditional use cases. The same use cases that all of these other language ecosystems stand on top of.

I swear, this really does come off as a "I don't care about the plights of farmers; I get my food from a supermarket!" dismissal.

Defining the Rust 2024 edition

Posted Jan 31, 2024 14:33 UTC (Wed) by joib (subscriber, #8541) [Link]

Huh, where did I say that? By all means, keep the existing system working.

Just saying that trying to bludgeon the post-2000(-ish) software development world into the shape of the C & sh world is unlikely to be satisfactory to anyone. As there are orders of magnitude more non-distro developers out there, and the distros have little to no leverage over them, it seems this is a fight they're destined to lose.

Defining the Rust 2024 edition

Posted Feb 3, 2024 1:43 UTC (Sat) by jschrod (subscriber, #1646) [Link]

> I swear, this really does come off as a "I don't care about the plights of farmers; I get my food from a supermarket!"

This should go into LWN's quote section.