[roca]

All crate sources are stored in the crates.io package archive, which never deletes packages.

A dependency veering off in a direction you don't like is one of the risks of using someone else's code instead of writing it yourself. Cargo makes it easy to use forked dependencies, and forking a dependency is almost always less work than if you'd never used it and written the code yourself from the beginning. (And to be clear this is only a problem for future evolution; a crate author cannot remove or modify an already-published version of their crate.)

[marginalia_nu]

This is still fairly short sighted. Websites shut down, large websites with big storage demands are especially vulnerable to attrition. Who wants to pay the mounting bill for keeping decades of revisions of historical rust packages online?

I can grab the kernel sources from 1997 and build them today. Will I be able to build rust code from 2022 in 2047, because the 1997 kernel will still build at that date.

[pdw]

"I can grab the kernel sources from 1997 and build them today."

Where would you be grabbing it from? ...From a website? "Websites shut down, large websites with big storage demands are especially vulnerable to attrition. Who wants to pay the mounting bill for keeping decades of revisions of historical Linux kernels online?"

[humanrebar]

You make a copy, store it on your medium if choice, and put it in a filing cabinet. I gather that certain organizations use magnetic tape backups for especially important data. For some organizations and individuals, kernel source code could be that important.

[kibwen]

You can easily do this with Rust and Cargo as well.

[marginalia_nu]

There is a fairly large difference between archiving your own project's history for as long as you feel like, and archiving the complete history of every significant piece of code ever written in a particular programming language forever.

[kibwen]

Who claims that archiving the complete history of every significant piece of code ever written in Rust is necessary? It is easy to archive only the code that your project depends upon. Rust code is no different from C code in this regard.

[marginalia_nu]

From <https://mirrors.edge.kernel.org/pub/linux/kernel/>?

It's easy enough to keep your own website up as long as you want to, the liability is other projects and services, especially when the scope of those services is "archive everything for everyone forever".

[sophacles]

So your argument is you think the people who run the crates site don't want to do a good job but the people running kernel.org do? What info are you basing this random-seeming decision on? Do you have any actual data suggesting that the crates site will just disappear like you say?

I'd like to see that data if so -- I have pretty big doubts that your statement has merit without some sort of evidence.

[marginalia_nu]

As I said in a parallel comment, there is a fairly large difference between archiving your own project's history for as long as you feel like, and archiving the complete history of every significant piece of code ever written in a particular programming language forever.

Kernel.org's repository is also of major versions, not every minor release and patch. That really wouldn't do for cargo. If it has ever been released, it needs to be kept in storage for as long as the rust ecosystem exists. That's decades, maybe even centuries of passing on the torch and hoping the next guy accepts the responsibility. Hoping you can find a next guy.

[sophacles]

So vendor in the dependencies. it's a matter of cloning the dependencies repo and adding a handful of characters to your project's cargo file.

Now the lifetime of the dependency is that of your project. There's even tooling 'cargo-vendor' to help manage this setup.

Alternative of course is implementing it all yourself, which cargo doesn't prevent.

[varajelle]

> I can grab the kernel sources from 1997 and build them today.

Can you? Do they still compiler with current compiler? You'll probably need to find a compiler of that time... And also all the interpreter for all the build scripts. Was that using bash or some old Perl? Maybe something more esoteric like m4 or tcl?

The point is that it always had many external dependencies to bootstrap. And adding one is not such a big deal, it just add another thing to archive among the many other things. The crates.io archive is probably not even that big.

[marginalia_nu]

I'm not sure why that would be a problem given most of these languages and standards are older than the Linux kernel. The thing about mature technology is specifically that it doesn't have breaking changes every couple of months. This is the way it used to be for a fairly long time.

But even if it has broken, I can just download an old linux distro. They effectively form a cohesive snapshot of the state of the toolchain whenever they were assembled. Slackware 3.1 from 1996 might be appropriate.

[estebank]

> But even if it has broken, I can just download an old linux distro. They effectively form a cohesive snapshot of the state of the toolchain whenever they were assembled. Slackware 3.1 from 1996 might be appropriate.

You will also need era-appropriate hardware to get that software to install.

[scns]

I'd rather comment than downvote. Who cares about about a kernel build from 1997 (25 years ago)? What was the hardware back then, Pentium 2? Sorry for the snark in advance but: Why make mountains out of molehills? Life is hard enough as it is.

[marginalia_nu]

You may not own a Pentium 2, but someone might. This is only hard if you make it hard. My that an old Linux kernel, by design, can be built today. This is a feature it has for free, a consequence of not relying on flimsy network based dependency managers.

At any rate, we are indebted to the future to preserve the present, as our past has been preserved for our benefit.

[Gwypaas]

I would imagine the kernel would use cargo vendor, or similar, to lock all dependencies into their chosen source control and quality requirements.

https://doc.rust-lang.org/cargo/commands/cargo-vendor.html

[humanrebar]

"Never" is a long time, just saying. It'll be impossible to beat the "availability" guarantees of a local mirror (like a thumb drive) of a kernel source tarball.

What happens when a crate version has to be removed due to a critical CVE or court order (IP Law violation, perhaps)? There may come a day where crates.io becomes torn between not breaking Linux source and not hosting actively bad source code.

Note that some of those concerns do apply to vendoring source as well, but the additional download step also removes options that the kernel maintainers have as long as they ship all the source for the kernel in one tarball. Like more control over the timing of inevitable decisions.

[notriddle]

> What happens when a crate version has to be removed due to a critical CVE or court order (IP Law violation, perhaps)?

CVE = The Yank flag. Cargo will refuse to add new yanked packages to a lock file, but if a yanked package is already in the lock file, it will still build. The package is not actually deleted. https://doc.rust-lang.org/cargo/commands/cargo-yank.html

Legal = Hard delete. Nobody will go to jail just to avoid breaking your build. Of course, since crates.io and kernel.org are in the same legal jurisdiction, is there any actual difference here?

[mcherm]

What happens today when a kernel module has to be removed due to a critical CVE or court order?

That's not just a rhetorical flourish, I'm actually curious what the answer is. As far as I know, (1) it almost never happens and (2) when it does, the change is made in upstream repos and as a practical matter, everyone downloads those changes and their up-to-date local copies lose that code.

[humanrebar]

Fixing it in the future isn't the point. Breaking previous releases is.

The previous tarballs still work and contain the relevant code. Your build wouldn't rely on hosts complying with court orders in countries you might not live in.

If the code isn't vendored, just referenced with URLs, the old tarballs stop working.

[roca]

This hypothetical court-order situation is quite far-fetched. If crates.io was ordered to take down some or all versions of a package, an alternative mirror could easily be created elsewhere and you could configure cargo to use it.

But I think the kernel would vendor crate dependencies, partly so that people can build without accessing the network, simply because that's policy in many places.

[3836293648]

Does crates.io actively host any code? I thought it was all just readmes and links to github and docs.rs

[conradludgate]

They do host it. It's registry info is mirrored on github though