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.

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.

I used to think the problems with Manjaro stemmed from Arch. The I tied EndeavourOS and I thought that EOS was fixing the Arch problems.

Then I tried Arch and realized that all the problems are the result of Manjaro. Arch does not have them. None of the other derivatives have them either.

Manjaro is a Trojan Horse.

It has gotten better in Wayland. I am looking forward to the near future when we can finally stop appending “on Wayland” to everything.

You should use what you like.

COSMIC may offer a middle ground if you did want to try something else though.

And KDE is very configurable. It does not have to look like Windows.

The GNU projects that people actually use are primarily hosted, maintained, and developed by Red Hat (IBM). They are the primary code contributors. Not just GPL, GNU specifically.

This is just a fact.

https://sourceware.org/ (Previously known as sources.redhat.com)

There is more permissively licensed code in most Linux distributions than there is GPL code. Not only is that permissive code not being “stolen” by “mega corps” but the majority of it is corporately funded.

Again, just facts. All pretty easy to verify if facts matter at all to you.

What part did not make sense? Just that the facts do not agree with your opinion?

The comment I responded to was stating things that sounded like facts that are not at all supported by the evidence. And if I ask for some, I am pretty sure the cherry-picked examples will be mostly companies “stealing” projects that they wrote to begin with.

The thesis that permissive licenses result in less Open Source code is wrong. In fact, they lead to greater corporate participation and employees write more code than unsponsored individuals. That is what the evidence shows.

Use whatever licenses you want. Not wanting companies to use code you wrote is a totally valid choice. But you should not have to misrepresent reality to convince other people to do the same.

You are in luck. COSMIC launches in 3 days.

I am also interested to see what kind of adoption COSMIC gets. From the comments I have seen, I looks like it may pull-away a fair number of GNOME users.

Nor sure that COSMIC calendar will have all the features you want. COSMIC is a pretty good base for GNOME apps though. It does not have to be either / or.

If you ever want to try Wayland, check out LabWC.

I am also loving Niri

Sort of.

Everything is Wayland compatible but there is no XFWM for Wayland. So, you use a Wayland compositor like LabWC with the rest of XFCE running on top of it. This is the default XFCE config on SUSE Leap for example.

XFCE is not quite as far along on portal support as GNOME or KDE though. Depending on your use case, you may still prefer running on Xorg.

You can run the XFCE apps on any Wayland desktop.

Hundreds of billions of years should be sufficient t