I have never heard the licensing of Rust being raised as a concern for the Linux kernel.

As Charles Babbage would say, “I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.”

The distro I use builds the entire Linux kernel with Clang which uses the same license as Rust. Linux is bound by the same modified GPL license regardless of what compiler I use to build it.

The compiler has no impact on the license applied to the code you build with that compiler. You can use closed source tools to build open source software and vice versa.

And, of course, the Rust license is totally open source as it is offered as both MIT and Apache. Apache 2.0 even provides patent guarantees which can matter for something like a compiler.

If you prefer to use GPL tools yourself, you may want to keep an eye on gccrs.

https://rust-gcc.github.io/

A legitimate concern about Rust may be that LLVM (Rust) supports a different list of hardware than GCC does. The gccrs project addresses that.

You do not have to. It has already won.

Look at the list of demands these guys make. It is basically “go back to before” because even they know the ship had sailed.

Very impressive. The M1 Macs at least seem to be quite functional at this point and everything either has been or is in the process of hitting the mainline.

Lots of work to do of course but many would have bet against getting this far. But there is a big difference between “could be better” and “stuff doesn’t work”. Getting the Rust based GPU driver into the kernel is a major achievement on its own and may do a lot to silence the “Rust isn’t used for anything real in the kernel” crowd as well.

With all the recent drama, I think some assumed the project was on the ropes. But the updates on the M2 and the reduced support burden of their past work leave me pretty hopeful that good progress will continue.

It just has to always be the first question in a big report or forum question. Have they verified their issue with the Flatpak version?

I prefer packages from the AUR myself but I do not expect the software authors to support me. Distros need to support their own packages but the AUR is not part of the Arch distro. Arch does not support the AUR. The only support I should expect would be from the package author (the AUR package) and they likely do not have the ability.

I think the right way to understand Flatpak is that it is essentially its own Linux distro without a kernel. You have to be running that version if you expect support. People think of Flatpak as a “sandbox” which it is. But it is also like running an app in a Docker container or Distrobox where you have to pick a distro to run in the container. With Flatpak, you are running on the “freedesktop” distro. It is not the same environment as the rest of your system (right down to the filesystem layout and C library).

It is not about it being public. He just wants it on the mailing list.

The people subscribed to the mailing list are all people involved in or specifically interested in kernel development. The hope is that the conversations there will be less technical and less political. What he does not want is a bunch of social or political pressure from drive by opinion holders on social media (like us).

It is fine for us to be discussing there discussion here. But he wants the discussion to be had “there”.

Um, yes. I would rather ally with Ukraine, regardless of who else my friends and enemies are.

It is currently written in C++. They are looking to switch to Swift.

They looked into Rust but decided that GUI work was a pain and that they wanted something more object-oriented.

They are working on a pipewire plugin for that

There has been lots of reporting the X Elite will use UEFI.

I have been playing around a bit with both Antix and Damn Small Linux 2 that is based on it. I have been quite impressed.

First, it is really just Debian curated to be light-weight. You have full access to all the Debian repositories.

The 32 bit versions also work great. I booted to a fully working desktop on a 32 bit system and only 84 MB of RAM was being used. On top of that I ran Firefox, LibreOffice, Scribis, GIMP, and I think other things and was still around 900 MB. It would be amazing on ancient hardware.

You could argue that Cinnamon is not really a “fork” per se. It is more of an alternative interpretation.

MATE is a true fork. When GNOME abandoned GNOME 2 for GNOME3 3, MATE picked up the GNOME 2 code and continued.

Cinnamon took GNOME 3 and built a different desktop experience on top of it. Specifically, they rejected the controversial GNOME Shell to present a more traditional desktop. The earliest attempts at Cinnamon tried to provide a traditional desktop in GNOME Shell itself. By the time Cinnamon 2 came out, GNOME Shell was completely gone.

Cinnamon also provides X-apps which is a suite of GNOME applications adapted to work with Cinnamon ( but also MATE and XFCE ). These really are forks.

Use a distribution with a large package library that is kept up to date and there is noting to miss.

Ubuntu is starting to push Snaps. So, that is becoming an unavoidable reality for Ubuntu users. For the most part though, Flatpaks remain optional for most distros.

The problem that Flatpaks solve is that the distro provided packages are out-of-date. If they are not, there is no real reason to prefer Flatpak.