I have quite a collection of ISOs.
One reason is that I have hardware that requires specific versions to boot (newer ones have removed support). Sometimes the distro still works just fine in that hardware but the live iso does not. So I can install with an older ISO and update.
Another is that use virtual machines regularly. I do not want to have to wait for the ISO to download every time.
There is always more.
Have you tried Chimera Linux?
I do not think it impacts that. Have you used GIMP3? Way better text handling.
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.
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.
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.
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.
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 think they mean use solar to keep the price of the electricity consumption down. It is probably a joke since old gear is going to drink a lot of juice cryptomining.
Turn them into a Kebernetes or a Proxmox cluster.
Most “stable” distros offer kernel version that update more frequently to accommodate new hardware.
Most “rolling” distros offer LTS kernels that remain essentially unchanged for long periods.
The kernel is one of the smallest differences between the two models.
Agreed. That is why I think Linux Mint Debian Edition (LMDE) is a better desktop than Debian Stable. The DE and everyday GUI tools stay fresh even if most of the distro is a time capsule.
It is funny. You and I landed in different places but for almost the same reasons.
I use a rolling release because I want my system to work. “Tinkering with my tech stuff” is an activity I want to do when I want and not something I want thrust upon me.
On “stable” distros, I was always working around gaps in the repo or dealing with issues that others had already fixed. And everything I did myself was something I had to maintain and, since I did not really, my systems became less and less stable and more bloated over time.
With a rolling distro, I leave everything to the package manager. When I run my software, most of the issues I read other people complaining about have already been fixed.
And updates on “stable” distros are stressful because they are fragile. On my rolling distro, I can update every day and never have to tinker with anything beyond the update command itself. On the rare occasion that something additional needs to be done, it is localized to a few packages at most and easy to understand.
Anyway, there is no right or wrong as long as it works for you.
UNIX was a proprietary operating system developed by AT&T that was originally shipped with source code.
BSD started as a set of enhancements to UNIX at Berkely University.
BSD developed into a fully independent UNIX distribution. BSD code was available for free and always non-proprietary.
In the early 90’s, AT&T launched a lawsuit to stop BSD from being distributed.
During that lawsuit, in 1991, Linus Torvalds created Linux. It was written from scratch to be like UNIX as Linus liked UNIX but could not afford it.
In 1993, BSD won its lawsuit and FreeBSD was born. But by then, Linux was already getting lots of attention. FreeBSD, while technically superior at the time, has never caught up in terms of popularity.
Linux uses the “design” of UNIX but is not UNIX. FreeBSD is considered “real” UNIX. Both implement the POSIX standard.
FreeBSD has always been focussed on servers. There are other BSD “distributions” that focus on different things: OpenBSD (security), NetBSD (portability), DragonFly BSD (innovation/performance). Some people consider macOS to be a BSD.
There are also “desktop” spins of FreeBSD like GhostBSD or MidnightBSD. FreeBSD recently has had more of a desktop push focussing on things like WiFi and power management. But it has nowhere near the hardware support that Linux has.
Linux, technically, is not a full operating system. It is just a kernel (the bit that talks to the hardware). The Linux kernel is released at kernel.org.
Linux “distros” collect a bunch of software to run on the Linux kernel to create a Linux distribution (full operating system). This includes key components like C library, core utilities, compilers, and init systems. Many Linux distros use software from the GNU Project for these components. But other Linux distros use non-GNU software for this, sometimes even software created by BSD.
As others have said, the BSD systems are built as an entire OS by a single team. FreeBSD 15 was just released. The entire software stack was created as a unit, including C library, utilities, compiler, and init system.
IRed Hat Linux is kind of developed as a full operating system as well as they are heavily involved in the kernel, are the primary contributors to the GNU tools, sheppard GNOME, and created Systemd. You could argue that Red Hat is the de facto Linux platform and that others distos build off that. But not everybody would agree.
So, Linux is more like UNIX but not UNIX (created in 1991) while BSD is UNIX (in continuous dev since the 70’s).
As a desktop OS though, Linux is substantially more popular than any BSD and so, these days, the tables have turned and the BSD variants often have to work to stay compatible with things that appear first on Linux.