@toadie Usually I update whatever Arch Linux derivative I have WHEN they’re on my main system; otherwise I update them when I’m using the system they’re on. I’ve gone with two of them; the other one I’ve used in the past seemed Okay but it would frequently mess up, so after a couple of strike outs, I moved on: the casualty? Manjaro Linux.
The one surprisingly that’s worked as long as I keep up with it is Cachy OS. I have found, however, IF I happen to install or reinstall a fairly old ISO image containing Cachy OS, it wants me instead to download the latest image instead of doing a large over the air update.
The other one that USUALLY works really well for me is Endeavour OS. Unfortunately I’ve found a couple of exceptions to that too. For almost two years it was beautiful then something funky happened, probably in the middle of a significant update and it more or less trashed my really nice setup, so I moved on for a while.
Not long ago I returned with a new image and it was (and is) mostly fine, EXCEPT that yay was having some issues with the AUR packages, so I reverted to pacman for a daily update, then ran the EOS versions from their Welcome screen to 1) do the equivalent of the pacman update (and that worked), THEN I did the EOS equivalent of yay -Syu with their EOS update + AUR, and that took care of my issues, so IF I run into problems again I’m going to go to their two tools, which seem to do a really good job of correcting any oddities that occasionally surface, so HUGE kudos to the EOS team for their tools, which appear to tame both pacman and any AUR additions to the standard configuration!
Arch-based setups tend to reward staying current, and the tooling really matters. The EndeavourOS helpers doing a clean pacman pass first, then AUR, feels like a sensible safety net. It’s good to see distros adding guardrails instead of assuming everyone wants to babysit pacman and yay manually.
Well, for me, it makes no difference whether I have a problem with pacman once a year or a problem with an upgrade on Ubuntu/Mint or whatever once a year.
At some point, there will be a problem everywhere.
With Arch, I don’t feel like I’m going to end up in dependency hell, as can happen with Debian, for example.
My opinion is simple. Anyone who breaks Debian has done something wrong, and anyone who breaks a rolling release has also done something wrong
It’s true that human error is the most common cause of breakage across all distros. Rolling releases amplify that risk because maintenance is more involved than fixed releases like Debian or Ubuntu. Arch’s KISS philosophy also means fewer guardrails and many valid system layouts, which increases the chance that a transition can break some setups even when users read the news and act correctly.
There have been real cases where Arch systems broke through no obvious fault of the user (glibc toolchain transition, Python 3.10 rebuild, GRUB 2.06 update issues) with fixes emerging via forum coordination. That risk is part of the rolling-release tradeoff.
This is part of what makes running Arch and other rolling release distros more rewarding, especially when you are able to do so for years without issues.
I’m mostly a Debian/Ubuntu main, but I did have a laptop where I used Solus for about a year and and a half. I’ve never used Arch or any flavors/distributions based on it. I say this to say, take my opinion with a grain of salt…
Solus still felt pretty “normal” to me. The eopkg package manager did everything I needed it to, and I got pretty comfortable compiling software that wasn’t in the repository. I can’t say I put any more or less time into maintaining Solus than I have any other distro and it served me well.
I found Zorin and what made me switch where two things:
Most of the software I was compiling on Solus was available via apt, so less effort. (NOTE: Thinking about it now, I probably could’ve used Flatpak but I don’t think I knew about that at the time I was using Solus)
I found it easier to find articles/guides on Zorin than on Solus. Maybe that is a me problem?
I like Solus and would try it again (it’s been a few years since I had it installed), whereas I’m still a bit “fearful” of trying Arch because I don’t trust myself not to break something haha.
I’ve been, and I still am, MOSTLY a Debian-based user, BUT these are a few that I visit often:
Slackware - two reasons, the first is that it was my FIRST distribution, and the second is that a full installation comes with a complete collection of software, enabling me to compile and build any application that I may have difficulty finding or building somewhere else; with either a binary or the source code, I can build it on Slackware. I don’t have a Slackware image installed at the moment, but I DO have a Flash Drive with Slackware on it that I can build at a moment’s notice - or go out and grab a new instance of Slackware CURRENT.
Endeavour OS - despite the fact that it’s a constantly changing distribution, I find it has a VERY good capacity of remaining solid and available. Cachy OS is also VERY good and offers a few different models - rolling but steady or cutting edge and still quite usable, but Endeavour OS out of the box has a few nicer looking options and is slightly easier to run a command or two and keep it up to date.
For both of these, despite the fact that the standard tools are pretty easy, I always create alias commands for whatever distribution I am using - often just alias u, so typing u Enter allows me to update them. So when I run various distributions I modify my u alias on whatever the system is to create a two keystroke package updating command - u ENTER!
My every day distribution is antiX. Because they are almost ready to release a new version, I have THREE instances of antiX right now - the current stable release, a “Trixie-based” Xfce respin created by a forum member, and a “Trixie-based” upcoming release candidate - my image is Beta 2+ - the Beta 2 image updated regularly, and it’s ALMOST ready for a release. They’re talking about building a Release Candidate with the antiX 26 release label, then they’ll fix remaining defects and it’ll actually become the next release - clever way to avoid building 5 to 10 different ISO images.
I’m on MX Linux, which has already finished their release, so theirs is MX Linux 25, and early in 2026, they have updates that are 25.1; that happens to be what I’m using right now.
How’s that for a distro collection? I have LOTS of others, but these are the main ones I’m using. Just as an example though I downloaded a copy of KDE Neon, put it on a flash drive; I’ve used it a couple of times too. Don’t need all of the stuff that’s in KDE Plasma, but I do like to check it out every so often. For KDE Plasma users who love the cutting edge latest for KDE, Neon is THE ONE to get. I know this because I tried it and also because one of my single geek friends always has AT LEAST eight cutting edge laptops at a time and he loves the latest stuff - he’s moved to KDE Neon to get it; that was one reason I took a look - and I agree - for those who love that stuff Neon is the way to go. For me? Not so much; not because there’s anything lacking, more because I just don’t need it.
Have any of you build software on a Slackware system? It’s surprisingly easy. If you have a tar (.tgz) Slackware package that you want to build, first decompress the .tar.gz or .tgz file. Some .tgz files can be directly built with a Slackbuild tool; others are source code. If it’s only source code, once it’s been decompressed (tar xvf file), here’s how to build the application:
cd uncompressed package
./configure ( may require arguments; often this is enough)
make (might be make all, make linux, check the doc; usually there is either a README file or some other build document).
make install (should be after su root)
verify results; small apps build pretty quickly; browsers can take hours to build. Something like a notepad editor take a minute to five minutes depending on their size.
Check it out sometime; it’s one of my favorite reasons for using Slackware. Often these self-contained images can be copied to other systems and they work great.
Arch-based systems have AUR packages, but if they don’t work, sometimes a manual approach like this work for Arch too!
