Rust is a coding language that requires its own toolkit when building binaries with it (just as gcc is required for everything written in C). Rust of course won't magically fix every issue and changing the tooling won't be user-facing but this is for developers to make their job easier. If they will be able to fix stuff faster then it's a win for users as well.

There's time until March for the maintainers of the 3 niche architectures to organize and make rust available for them. Doesn't sound that abrupt to me

For package maintainers, it's reasonable to expect security updates are rolled out the same week that a vulnerability is found. If you can't deploy a new version of a package in 6 months, not maintaining the package is also a valid option.

The timeline is not super abrupt, especially for architectures where all he is asking is to ensure that your Rust toolchain is in order. That is especially true when you consider that Rust is already well maintained on all the Debian architectures that people actually use.

The abruptness (almost rudeness) is in the second part where he basically says that, if you cannot get Rust going in time, you should just stop releasing Debian for that architecture.

It is mostly just poorly worded though. Because none of these architectures have “official” support even now. This will not be the only way they are behind. So, there is not reason to be so dramatic.

And that would be my response to him. Another option here is that these alternative architectures just continue to ship an older version of APT for now. Emergency avoided. Few of them ship with up-to-date versions of APT even now.

Another solution is to use one of the multiple projects that is working to make Rust code build with the GCC compiler back-end. At least one of these projects has already announced that they want to work with these Debian variants to ensure that APT builds with them.

So, the 6 month timeline is a reasonable impetus to make that happen which would be quite a good thing beyond just APT.

There are many other useful tools written in Rust you are going to want to use on these architectures. It will be a fantastic outcome if this pressure from APT kickstarts that happening for some of these long abandoned architectures (by the mainstream at least).

Rust adds another layer of trusting the compiler isn't backdoored. All UNIX/Linux systems use the gcc toolchain, so having it written in C would mean less dependencies for the OS.

• paraphrased from someone who seemed to know more about this stuff in this unrelated discussion yesterday

Strange times.

Yeah, it's pretty good. But now that I've started studying, and don't have time for learning it (I've literally made a personal wiki with various documentation for myself), so I am thinking to switching to atomic distro instead (maybe KDE Linux).

Apt is written in more C++ than C, so it would be apt to select a language that is similar.

Compared to what?

I know redhat has a new package manager which name I can't recall now but before it was rpm with yum and holy crap that was molasses slow

Apt feels like one of the faster package managers. dnf is slow, yum is snail speed, zypper is slow as fuck too. Apt and Pacman is by far on the faster side

Are you migrating to Debian on a niche CPU architecture? If not, this doesn't affect you.