Amazing! Thank you for diagnosing this issue for the rest of us.

This is exactly why Open Source works and why even huge companies cannot keep up with Open Source software once it has taken hold. The users drive it forward in a way that money alone cannot match.

The NVIDIA problems are almost entirely legacy at this point. Unless you are using something that ships ancient packages (looking at you Debian Stable), you should be fine.

I use KDE with Chimera Linux which is only in beta. Rock solid.

I have never had anything in Arch take months to fix. One tip I would have is to use both the latest kernel and an LTS. If something “breaks” with a kernel module, just boot into LTS and it is probably fine there. I also had an issue with WiFi for about a week but a quick reboot into LTS and I was good to go immediately. When I tried the latest kernel two weeks later, it had been fixed there. Something similar happened with my FaceTimeHD camera. Same solution.

Just recently repartitioned my MacBook:

1 GB for EFI (vfat)

2 GB for /boot (ext4)

11 GB for swap

224 GB for / (bcachefs)

Grub cannot load a kernel off bcachefs so I need ext4 to bridge the gap. Once the kernel is loaded, it has no problem using bcachefs as root.

This is a laptop. On a desktop that can handle more drives, I would split /home onto a drive of its own.

My current distro uses APK 3 as a package manager and that is already atomic. So I guess my current setup works fine, without any of the other hassles and limitations.

To understand how to interpret these complaints, we need to understand that Flatpak works by essentially installing a second set of libraries for your apps to run on. The apps run in a container (much like Docker) on top of these libraries. Flatpak uses the kernel and display server from your main distro but otherwise Flatpak is like a second distro unto itself.

So, if you only install a Flatpak app or two, it is very true that they will require quite a large number of support libraries to run (just like running one app on your distro is more distro than app space wise). However, as you add more apps, they they resuse the libraries that the first apps installed.

Because Flatpak installs all its own support libraries, the apps run the same on all distros (which is the point).

So, Flatapak does duplicate the libraries on your system out of necessity. Because your Flatpak apps does not use any of the libraries from your host system. However, they are only installed once inside the Flatpak environment.

The comments about vulnerabilities are neither here nor there. You have to trust your distro. You have to trust Flatpak (as a second distro). Both are subject to vulnerabilities and supply chain attacks but neither more than the other. Flatpaks are technically after as the container environment they run in “sandboxes” your Flatpak apps. In practice though, they require enough permissions that the sandbox is trivial to escape. So not much difference.

Flatpak is literally installing a second Linux distribution on your machine, just without a kernel. All the dependencies right down to the C library are installed in the Flatpak environment. This why you can run a Glibc Flatpak on a musl distro.

Microsoft could support Flatpak “natively” on Windows. It could use the same kernel and GUI glue that WSL uses but you have no need of specifying a distro or getting to the command-line. The experience could just be that you go into Flathub, install and remove apps, and everything would just work.

Apple could do the same with macOS.

If they did that, Flatpak could be a universal app distribution method on all three systems. Devs would only have to create and maintain a single version if they wanted.

Microsoft will not do that of course. If it really was a brainlessly simple alternative application store, they could OS/2 themselves and loose control of the platform.

Too bad though. It would be cool. No reason it could not be done independent of Microsoft of course but it would never be as popular if it was not built in.

I favour Arch because I prefer everything I want to install to be in the package repo and for it to be a version actually new enough to use.

But I actually use EndeavourOS because it is 99% Arch but installs easily with full hardware support on everything I own (including a T2 Macbook). It never fails me.

And now I have realized that I can use Distrobox to get the Arch repos and the AUR on any dostro I wish.

So, I now have Chimera Linux on 4 machines because it is the best engineered distro in my view. The system supervisor, system compiler, and C library matter to me (not to everyone). All these machines have the AUR on them (via distrobox). Best of all worlds.

With the AUR, there is an “it depends” since AUR packages are unofficial and variable in quality.

That said, I have a strong bias for installing the distro package over using AppImage or Flatpak.

There are three reasons not to use the distro package:

• the package is not available
• the package is too old
• the package maintainer cannot be trusted

My #1 reason for using Arch is to eliminate 1 and 2. In my experience, the AUR is almost always fine for #3.

Even when I use another distro, I put Distrobox with Arch on it and get any of the packages that the distro does not have from there.

The only Flatpak I have had to install has been pgAdmin.

It is a shame this was so obvious. Even though I saw it a week late, it was so obviously an April Fool’s joke that it was not worth reading past the headline.

I feel bad for whoever put the work in.

I love that RiSC-V is already so well supported in the Linux kernel even though the hardware is not really out there yet. When decent hardware does arrive, a fairly mature ecosystem will be waiting for it.

Compare that to ARM which took quite a while. There is already more of a culture of getting device support into the mainline for RISC-V than for ARM even now.

I do think decent RISC-V kit is coming. The existing players like SciFive are getting there, we know big players like Qualcomm and Samsung have projects, and future disruptors like AheadComputing see RISC-V as their attack vector on the current industry. And for sure China is going to surprise with a decent RISC-V offering at some point—maybe Alibaba, maybe Huawei, or maybe someone else.

The only issue with LFS is maintenance. It is one thing to set it up but having to manually keep it all up to date does not sound like fun.

I use Chimera Linux which is musl based. Compatibility is great. If you have the source, you are probably fine.

It can be a pain for projects that ship binaries as part of the build. Two examples that I have run into:

• The Ladybird browser uses vpkg and the version their scripts download assumes Glibc. You can build vpkg itself on musl but the whole process is a pain.
• dotnet requires a binary build of dotnet to bootstrap from. There are musl builds available but they assume GCC and Chimera uses Clang. Not really a musl problem now that I think of it.

Anyway, I use a Distrobox of Arch on Chimera. If I do run into something (like the two above), I just pop into that and problem solved.

Flatpak is essentially the same solution as they run in a container and the freedesktop base is Glibc based.

Not only is musl not generally a problem but, these days, it is trivial to work around it.

You are using Turnstile on Void? Cool.

Older MacBooks and MacBook Airs (pre-2018 or so) make awesome Linux machines and have really come down in price. If you can find one cheap, I highly recommend them.

Intel machines later than that have T2 chips and are still good but take a bit more research.

M1 Macs are pretty well supported now but that is a different universe.

I believe that NTsync delivers better compatibility. I do not remember the details but Fsync can cause problems sometimes. So this is more like performance without compromise.

Now that it is in the kernel, I would expect Wine to move to it and for Proton to follow suit.

One less hack to maintain.

Most of it is historical momentum. Regardless of relative quality, far more people try Fedora and so far more people stick with it.

As for Tumbleweed specifically, many people do not like rolling distros. I do.

You said “full”. So the short answer is no.

You can import and export to CMYK and handle CYMK in some tools but, internally, GIMP is still sRGB.

I think one of the devs wants to add full CMYK and Lab colour fairly soon after 3.0 but it is hard to say how fast dev will go. Getting to 3.0 has take forever but a lot of the plumbing is there now. There were big features only appearing in 2.99 for years. I do not think they will need to hold back like that again, so perhaps things will seem to go faster now.

The other big thing that is only “partial” is non-destructive editing.

As unfortunate as this whole episode has been, it is great to have this clarity from Linus. It feels like quite a straight-forward guideline to apply to future situations. Hopefully it will really cut down on the noise and drama between the pro-Rust and anti-Rust camps in the kernel.

As long as Linus stays consistent with the stance he outlined here, things should go well.