gccrs, the Rust compiler for GCC, is written in C++. If you can compile GCC, it will build the Rust compiler for you.

Presumably the NetBSD project can bootstrap to GCC.

I think they use LLVM rather than GCC, which makes it even easier.

> There are many architectures that NetBSD supports where Rust is not available

Are there many architectures that NetBSD supports where GCC is not available?

The rustc_codegen_gcc project allows using the rustc compiler to target any architecture that GCC supports. I think it is pretty far along.

https://github.com/rust-lang/rustc_codegen_gcc

> getting a Rust compiler running in the first place is hard

> bootstrap relies on a binary package

> the compiler would also have to be part of the base system

The gccrs project aims to make Rust a fully supported language in GCC. It is fully self-hosting and can be built from source. Once accepted, it will be one of the languages you get when you build GCC.

https://github.com/Rust-GCC/gccrs

When gccrs is ready, it will address all the above objections.

Linux faces the same issues. Today, Rust is optional in Linux and can be skipped on any platform not supported in LLVM and rustc. For Rust to become mandatory in Linux, gccrs is going to be required (for some platforms).

> the release cycles of Rust are not compatible with the NetBSD ones

I do not fully grasp the objection here. Obviously NetBSD would not be forced to use any Rust features they cannot compile. And using gccrs for the NetBSD kernel would not prevent them from bundling LLVM and rustc as well if they want.

Anyway, I am not advocating the use of Rust in NetBSD. I am merely pointing out that solutions to the issues raised are being worked on.

I just noticed that rustc_codegen_gcc has been accepted into the mainline Rust compiler, or at least the nightly builds.

https://github.com/rust-lang/rust/pull/151156

This means that you will be able to use either GCC or LLVM to build your Rust code with rustc (the main Rust compiler). That means you can compile your Rust for any platform that GCC supports.

This only addresses the first point in the blog post (architecture support) but it is an interesting development.

> the Rust for Linux project wants to use the newly prototyped features right away > they depend on not-yet-released features from unstable nightly versions of Rust

This is not true. Since kernel 6.11 they have specified a minimum version that is already stable. The strategy for the Rust kernel is to use the version of Rust that ships with Debian Stable. That is very far from using "the newly prototyped features right away".

https://rust-for-linux.com/rust-version-policy

Of course, the kernel continues to inform Rust evolution. But you do not need an unstable version of Rust to compile Linux.

How does space solve cooling?

It's much more difficult to cool things in space than on earth.

I'd be more interested in how they'll deal with radiation hardening than the cooling factor when compared to how the JWST currently handles it.

Just call it the Red Hat Linux Platform. Both GNU (glibc, binutils, GNU utils, GCC, etc) and Systemd are primarily maintainted by them. Same with Wayland and GNOME.

Red Hat defines what "Linux" is these days.

The whole GNU / Red Hat platform is this way. Try switching out Glibc. You get the same "you have to use all our stuff" dependencies.

Switching out glibc is pretty easy compared to systemd. That's the thing peoplle don't get. systemd is seriously insidius, like a virus.

I've personally run Gentoo with OpenRC+glibc and OpenRC+musl on my laptop. I assure you ditching systemd was easier than ditching glibc. The OpenRC system mostly just works (tbh thanks to a lot of great work by Gentoo devs). The musl system required probably a couple dozen patches to various packages to get a basic fully working desktop (most of which were relatively straightforward, but still needed manual intervention).

Musl mostly works. I had more trouble taking out bash, because of all the random bashisms.

On my system I forked dash to create 'bolderdash.' Right now it's pretty basic, I have changed little (just did some cleanup), but I did add in a couple tweaks to enhance bash compatibility. The goal is a complete refactor, more compatibility with bash, and much better command line editing etc, while still remaining sleek and lightweight.

I'm also forking musl to create 'powrlibc.' It will have a lot better glibc compatibility, as well as better optimizations and some other improvements.

This one bothers me too.

Systemd and Xorg are very similar in many ways. I do not know how you hate Systemd and love Xorg unless your real problem is just change.

And, while I like Wayland, I think that liking the Wayland architecture should have you disliking Systemd. But that is just me.

I'm in the same boat. Systemd is an unpricipled mess and ships some quite shoddy replacements for pre-existing components. Wayland is super clean, it just takes for-everrr to add the features that users (and developers) expect. It could seriously have been done over 10 years ago not by heroic development effort, but by not being pathologically obstructive about features.

The two projects are complete opposites except in one way, they replace older stuff.

> I’m sure there’s more to the story than just ABI compatibility

The number one goal for the Xwayland / Xorg devs is stability. Breaking ABI compatibility is a pretty big problem if stability is your goal.

> Freedesktop wants to kill X11

There is a difference of opinion. Freedesktop wants to "stabilize" X11. That does mean that they do not want to evolve Xorg. However, it does not mean that you cannot keep using it or that they are going to take it away. In fact, it is still being maintained and will be for a long time.

You can interpret the rejecting of patches and banning of developers as political. However others see the rejection and banning as protecting the stablity that is the goal.

If your goal is for Xorg to evolve and not to stabalize (fair), you may prefer Xlibre as a project.

Phoenix looks pretty cool too.

KDE Plasma and GNOME are trying to kill X11. Or, at least, they do not want to maintain support for it in their projecs. And COSMIC did not bother to add support for X11 at all. That will probably be the trend on desktop Linux.