Quick notes

Posted Mar 27, 2025 17:19 UTC (Thu) by Conan_Kudo (subscriber, #103240)
In reply to: Quick notes by bunch
Parent article: A process for handling Rust code in the core kernel

Because that is how the Linux kernel will be built in practice. Linux is delivered through distributions, so if stuff doesn't work through distribution tooling, it won't get shipped. Rustup is a non-entity for Linux Rust development for this reason. It needs to work with conventional distribution-provided tooling.

Quick notes

Posted Mar 27, 2025 20:34 UTC (Thu) by pbonzini (subscriber, #60935) [Link] (9 responses)

The same in fact is true of anything that ships as a Deb or rpm (or whatever) package in a distro—foe example Firefox. They won't be using rustup.

It doesn't have to be used everywhere. It's totally fine if a project's CI wants to use rustup to get a heads up about e.g. new additions to nightly clippy; or if rustup toolchains are recommended to users of old frozen distros that won't package that code. For example, in QEMU we will probably start requiring a rustup toolchain for Debian bookworm since Rust usage is still experimental and there's no reason for distros to enable it.

Quick notes

Posted Mar 28, 2025 10:31 UTC (Fri) by dottedmag (subscriber, #18590) [Link] (8 responses)

Hear, hear.

We're no longer in 1996 when software was distributed in tarballs, libc interface has not yet solidified and distributions carried patches that caused C ABI incompatibilites. Many upstreams are competent to provide binaries nowadays.

Quick notes

Posted Mar 28, 2025 11:06 UTC (Fri) by pbonzini (subscriber, #60935) [Link]

And many others don't want to be in that business at all.

You still have cases where different distros of Linux carry different versions of glibc or musl (cue the history of Python manylinux/musllinux). You have projects that also care about Windows and perhaps the three BSDs (four if you count Dragonfly), or that would have to produce architectures other than x86. You also have macOS for which cross compilation is of doubtful legal status. And so on...

Quick notes

Posted Mar 28, 2025 15:09 UTC (Fri) by nim-nim (subscriber, #34454) [Link] (6 responses)

People keep saying that but no one has managed to produce a working upstream-binary-distribution yet.

Once you get to the point where you try to release the kind of full system users want (ideally, preinstalled) you quickly reinvent a distribution. Many is not all nor all the time, look up the trainwreck that OpenH264 proved and that’s a single binary component produced by a well-financed corporation.

If anything, the monorepo FAANGS favor is a return to a more centralised and more sourcecode-oriented distribution than the Debians and Fedoras provide.

Quick notes

Posted Mar 29, 2025 15:28 UTC (Sat) by surajm (subscriber, #135863) [Link] (3 responses)

If you look how projects like chromium or fuchsia are built, they maintain almost all of their third party dependencies as prebuilts which you download alongside the git repo. It's realistically the only way, short of creating a docker container, to ensure a consistent set of tooling and dependencies are available without needing to depend on potentially less trustworthy entities (eg crates.io, npm, or what have you) that might change the package contents when you try to fetch them.

Quick notes

Posted Mar 31, 2025 8:33 UTC (Mon) by nim-nim (subscriber, #34454) [Link] (1 responses)

Exactly like distributions that maintain a repository of trusted binary prebuilds in rpm or deb format then. Once you need to ensure a minimum amount of accountability, no one plays the direct binary download from the binary upstream game.

Quick notes

Posted Mar 31, 2025 8:49 UTC (Mon) by dottedmag (subscriber, #18590) [Link]

I do whenever I can. The solution is trivial, it's called "record a checksum and check it".

Quick notes

Posted Mar 31, 2025 8:48 UTC (Mon) by dottedmag (subscriber, #18590) [Link]

There are still packaging systems and repositories in 2025 that don't provide checksums of downloads and do at least automatic ToFU, really? If yes, then it's terrifying.

Quick notes

Posted Mar 31, 2025 23:55 UTC (Mon) by MrWim (subscriber, #47432) [Link] (1 responses)

> If anything, the monorepo FAANGS favor is a return to a more centralised and more sourcecode-oriented distribution than the Debians and Fedoras provide.

I wrote a bit about that here: https://blog.williammanley.net/2020/05/25/unlock-software... :

> By doing so the huge proprietary megacorp gains more of the benefits of the fact that the software is free (as in freedom) than the free-software distros can!

I’d love to see the major distros pursue the goal of becoming more sourcecode-oriented as you put it, unlocking the ability to modify the software they provide.

Quick notes

Posted Apr 1, 2025 8:29 UTC (Tue) by dottedmag (subscriber, #18590) [Link]

Yes, source-code oriented, or even just «useruser-modifications oriented».

It's a pretty sad state of affairs that the only games in town are Gentoo whose authors haven't even gotten around to compile ARM64 handbook, and NixOS with its horrendous language and NixPkgs repeating all the mistakes BitBake-based OpenEmbedded repository did, namely moving build logic from the build tool into the packages repository, thus making it less discoverable, underdocumented and changeable, diluting the contract between the package repository and the package description.