Parce que

Mint is very boring and middle of the road, exactly as a default recommendation should be. They are also very protective of the user experience. They are unlikely to embarrass me.

Mint has a familiar UX if you are new to Linux. It is not nearly as foreign or locked down as GNOME. It is not as configurable and complex as KDE. There are good GUI tools for most common tasks.

Mint does not change too rapidly or have too many updates but the desktop and tools are kept up-to-date.

They are being very conservative with the Wayland transition. But nobody on Mint is moaning that Wayland is not ready. They are very protective about the user experience.

And there is really no desktop use case that Mint is not suitable for.

I do not use Mint but it is a very solid recommendation for “normal” users.

I think Pop!OS is back to being that too and COSMIC is Wayland only (so no future transition to manage).

It depends on the distro but generally yes. If you want to do this, choose a distro with up-to-date packages. I would recommend either EndeavourOS or CachyOS.

Why doesn’t anybody ever recommend Debian testing? It has stricter quality criteria than unstable while being almost as up-to-date.

I agree that Debian Stable is not a great fit for desktop as the packages get very old between releases.

What happens when you say that you do not use social media?

When anybody, anywhere in the world visits the US, the IQ goes up in both countries.

I think it is a smart play.

They are getting lots of press in the places where the people that care go.

On their website, they focus on the benefits of their platform for customers. From that perspective, the new COSMIC is just a refinement on what they were shipping before.

And this is just the beginning. COSMIC itself is still fairly basic. And the “new” Pop!OS is based on an LTS base that is already 2 years old. None of that is a problem but it is not a hand they want to overplay.

They may actually make a bigger deal about the benefits when 26.04 ships. Things will be a bit more “industry leading” by then.

Ya, it seems odd to be releasing a 24.04 in 25.12 for sure. That said, 24.04 is still the current LTS and so it is the version we would be on now if they had released earlier (even a year ago).

They plan on releasing a 26.04 LTS as well. So, Pop!OS is not lagging. It just feels strange now.

As I said in another comment, critical parts of Pop!OS 24.04 are also quite up to date including the kernel, Mesa, NVIDIA drivers, and of course COSMIC itself.

Moving forward, I expect the versions of COSMIC in 24.04 and 26.04 to be the same. If I was them, I would even consider syncing Mesa between the two. It will make support and testing so much easier and they are already shipping a newer Mesa in 24.04 anyway.

Fair enough.

But before you scare anybody off, it is worth pointing out that Pop!OS 24.04 is quite up-to-date in those areas.

• kernel 6.17
• Mesa 25.1
• NVIDIA 580 drivers
• current Wayland (COSMIC)

Those are what is going to drive your GPU and Wayland experience and they are about the same as you get in Kubuntu 25.10

A lot of the 24.04 packages will be older for sure but it is not fair to compare COSMIC in Pop!OS to the old KDE version you would have been using on Ubuntu 24.04 (Kubuntu).

And I expect Pop!OS 24.04 LTS to see steady COSMIC updates on the road to 26.04. It would kind of shock me if they do not harmonize the desktops between those two releases.

I find it pretty solid if a bit bare bones. With the basics in place, it should improve fairly quickly.

They are planning a 26.04 LTS release. We will see what it looks like by then.

CachyOS will work on older hardware as well. There are four repositories for x86-64 v1, v2, v3, and v4. If you have newer hardware, the v3 or v4 packages will theoretically give you better performance. That is probably what you are talking about.

That said, the v1 repos will work on x86-64 machines going back to 2003. Not exactly bleeding edge.

The only thing that I have noticed is that packages are not all in sync between repos with v1 lagging behind v3. For example, I think Cachy is already on the 6.18 kernel but the v1 repos still only have 6.17. I have seen svt-av1 lag as well.

I am not a CachyOS user so apologies if any of my info is dated.

I will never say anything bad about EndeavourOS.

Thank you for the suggestion. I am ashamed to confess that a temporary PATH variable had not occurred to me.

I first ran into these issues creating package templates. Chimera has a beautiful package build system where packages get built in containers and source code gets downloaded into the container and and built against a clean environment. As you point out, creating a package that creates the symlinks as a dependency (along with the GNU utils) could be a viable approach here. Maybe even just in /usr/local. The GNU utils get installed to /usr/bin in Chimera and the container gets recycled for every new package. The distro would never accept such hacky packages but I can use them myself.

For just generally working in the distro at the command-line, your temporary path idea could work well.

Thanks again. I appreciate it!

I am very curious to see what kind of uptake COSMIC gets.

It seems like a nice compromise between the overly locked-down simplicity of GNOME and the complexity of KDE. And it balances tiling with stacking really well.

Agreed.

What is even stranger, but great, is that they plan to release a 26.04 LTS in 4 months.

That will be the start of the real next generation for Pop!OS. We should get a real sense of where System76 wants to go with COSMIC then. Today is all about getting a minimally viable system into production so people can start to use it. Making 24.04 an LTS means that people do not have to hold off until next year.

It is not about how well it works. They can certainly disagree about that.

The problem was that they clearly have no idea how it works and “warned” people about a bunch of things that will not happen.

If posted a comment about Linux and told you not to use it because it would cause your hardware to disintegrate, the issue is not my level of Linux advocacy. The problem would be that I am peddling actual falsehoods.

First, I use either Niri or KDE Plasma on Chimera Linux. Both are just an “apk add” away. You do not have to use GNOME. There is even a KDE live image so you do not even have to run GNOME once to install if you do not want.

I really like the BSD utils and have come to prefer them. Well written. Sleek. Well documented. The man pages are a walk through UNIX history. They feel “right” to me.

That said, the BSD userland is frequently a pain when interacting with the rest of the Linux universe. You cannot even build a stock kernel.org kernel without running into compatibility problems. The first time I built the COSMIC desktop on Chimera, I had to edit a dozen files to make them “BSD” compatible.

Sed, find, tar, xargs, and grep have all caused me problems. And you need bash obviously. But bash is no big deal because it has a different name.

The key GNU utils are available in the Chimera repos. But you get files named gfind, gtar, gxargs, gsed, etc. so scripts will not find them.

You often have to either add the ‘g’ to the beginning of utilities in scripts or edit the arguments to work with the BSD versions.

I mean, most things are compatible and I bet most of the command-line switches you actually use will work with the BSD utils. But I would be lying if I did not say third-party scripts are a hassle.

If I could do Chimera all over again, I would make it bsdtar and bsdsed (or bsed maybe) for the BSD versions.

Maybe the regular names could be symlinks with sed pointing to bsdsed by default but you could point it to gsed instead of you want. The system Chimera scripts and tools could use the longer names (eg. bsdsed) instead of the symlinks. The GNU tools could be absent by default like they are now. That would be the best of both worlds. The base system would have the advantages of the BSD tools (like easier builds as outlined on the Chimera site), the system could be GNU free if you want, and you could have a system that actually works out of the box more often with third-party scripts.

It pains me to say this. I would prefer not to use the GNU stuff but the GNU tools are the de facto standard on Linux and many, many things assume them. No wonder UUtils aims for 100% compatibility.

Anyway, even with what I say above, Chimera is my favourite distro. The dev can be a little prickly, but they do nice work.

Chimera Linux is great. APK and cports are so good I cannot imagine going back to anything else.

Bash is not the default shell though. Chimera uses the Almquist Shell from FreeBSD. Other Linux distros have “dash” which is basically an Almquist variant.

Almquist is lighter than fish and fish is not POSIX compatible.

Bash is available in the Chimera Linux repos of course and is required for many common scripts.

“Not run by fascists”. Sometimes I wonder.

This is a dramatically misinformed comment. You have clearly never used Distrobox.

1. The first bullet is the worst. This is like saying that Flatpak will break your host. It will not break the host OS. Learn what a container is.

2. It is not tools on top of tools. It is tools in a container that you can optionally create entries for in your app menu. Apps in the container execute directly on the host kernel in the container. If you are in a shell, you are either in the container or out and the full environment will reflect that.

3. It is not for “new users”. That said it dramatically simplifies many intermediate ones and make some advanced things possible. Once again though, there are no “stacks on stacks”.

4. The exact opposite. Containers do not change the host. If something goes wrong in the container, you can purge it completely without impacting the host.

In fact, one of my core uses for Distrobox is to keep my host system clean. I use Distrobox to setup dev environments, to try out new software, to work around Distro constraints, and a host of other tasks. It is great.

There seems to be quite a fundamental misunderstanding of what a container is. Everything runs directly on the host kernel. Apps outside the container run on the host OS and do not interact with the container. Apps in the container run in the environment inside the container. The only interaction apps in the container have with the host is the kernel, the filesystem, and via servers like Wayland, Pipewire, and XDG portals.

The entire point of a container is to create an application environment that looks exactly like an application expects regardless of system it is running on. It is clean and consistent between deployment. This is the exact opposite of what the above comment implies.

In practice, it “feels” like apps in Distrobox are running native on the host OS but in fact everything above the kernel is running inside the container and each container is distinct from the others.

The “example” is totally wrong. GCC is either on the host or it is not (from the host). GCC is either in the container or it is not. They do not interfere with each other. They do not even share C libraries. However, the can see the same source files.

Distrobox is absolutely nothing like Homebrew. Homebrew is a package manager. If you are using a package manager in Distrobox, it will be the one intended to work with whatever distro you are running in Distrobox. This is a fantastic illustration of the confusion of ideas at work here.

If you have to compare Dostrobox to something, compare it to Flatpak.

Ah thank you. You likely guessed the reason for the question.

Many popular projects written in Rust, including the UUtils core utils rewrite, are MIT licensed as Rust is. There have been people that purposely confuse things by saying that “the Rust community” is undermining the GPL. I can see how that may lead somebody to believe that there is some kind of inherent licence problem with code written in Rust.

Code written in Rust can of course be licensed however you want from AGPL to fully proprietary.

I personally perceive a shift in license popularity towards more permissive licenses at least with the “younger generation”. The fact that so many Rust projects are permissively licensed is just a consequence of those kinds of licenses being more popular with the kinds of “modern” programmers that would choose Rust as a language to begin with. Those programmers would choose the same licenses even they used the GCC toolchain. But the “modern” languages they have to choose from are things like Rust, Swift, Zig, Go, or Gleam (all permissively licensed ). Python and TypeScript are also still trendy (also permissively licensed).

Looking at that list, it is pretty silly to focus on Rust’s license. Most of the popular programming languages released over the past 20 years are permissively licensed.