* Arch
* OpenSUSE Tumbleweed
* Others?
The "List of Rolling Linux Distributions" Wikipedia page was recently deleted (May 2024), but here is the most recent archive.org snapshot:
https://web.archive.org/web/20240503140631/https://en.wikipedia.org/wiki/Category:Rolling_Release_Linux_distributions
I ran Gentoo from around 2005-2010. Getting into Gentoo was highly educational and fun in it's own way, but it broke way too often and the fun wore off after fixing wifi the third or fourth time.
Coming from Gentoo, Arch has been extremely stable. In fact, in my experience Arch has been more stable and reliable than RHEL or even proprietary operating systems like Windows. I'm running the Sway window manager, so pretty minimalist. YMMV, especially if you're running a heavier desktop like KDE or GNOME.
Arch may be the highest profile mainstream rolling distro. Sometimes it's easier to go with the flow.
I started using it basically by accident. I got a new computer, tried installing Ubuntu and it just wouldn't boot. Someone told me maybe the drivers weren't in Ubuntu yet and I should try Arch.
Getting it installed took some work since I'd never really used Linux before, but the wiki is such an amazing resource, and by necessity you learn a lot about your machine.
Now after a decade of use it's very much _my_ distro, and I can understand the whole thing.
Also, the aur is such an amazingly useful resource. Everything in the main distro is also put together in a very sensible way.
I thought I should move to guix. I started that and ran into the non-free kernel / firmware zealotry, concluded that was deeply stupid and stayed put.
edit: Debian call their rolling release sid or unstable, the slower rolling testing is also fine.
It sounds like maybe not..
> From a software developer's point of view, Debian Sid and Arch are both "unstable" release streams. That means that they don't have versioned releases; they just have one indefinite release stream. There is no formal schedule or window for any class of changes.
If you follow "testing", you get a slightly strange cadence where things change quickly just after a stable release and gradually slows down until stable is created, then picks up pace again.
A reasonable choice is to follow whichever named release is currently in testing. Currently that's "trixie". It's identical to the testing release until the fork happens, at which point the local install will be an instance of stable. It's very easy to forget you've done that until you notice some program you're running is older than you expected, at which point upgrading to testing to find the newer one is straightforward.
The machine I'm writing this on is running debian unstable. Installed ~ four years ago when I bought the machine, expecting it to continue working until the nvme burns out.
A stable rolling distro with automatic snapshots. Packages are up to date without being bleeding edge. If an update breaks something, simply revert to an older snapshot.
Apart from that, it has been smooth sailing.
It's not "somehow", it's by design, Suse encrypts boot and root partitions and so you need to enter the password twice to unlock them both. The "fix" is to use an encrypted LVM for all partitions and so you enter the password only once.
Heck, the thing is so stable I use it on production servers. The combination of their automated QA plus your own QA on staging is the bomb.
Feels like it's very unopinionated about how I run my system, but to be fair I spent a lot of time fighting Ubuntu and Fedora back in the day, if you wanted anything custom you could often wind up breaking your entire system in strange and difficult to debug ways. Arch felt like "vanilla linux" in a way.
I have, however, recently broken it beyond repair after yay decided it couldn't update itself and some libraries vanished or became corrupted, ending my nearly 10 year installation. I installed Manjaro over the top to get going again quickly and am surprised at how useful Manjaro is out of the box.
Manjaro feels like "vanilla linux with some defaults to start from" which is nice too.
Tumbleweed is closer to where I am now, Fedora -- I've moved away from rolling releases. I appreciate a very light dance for planning upgrades.
All told: both OpenSUSE/Fedora invest in packaging that I also appreciate; mostly-binary but can easily opt into source-based installations
The time/skill required to run it simply isn't practical when some sort of business model is at stake.
I'd argue most shops could afford to relax a bit though. Not rolling releases... but newer ones.
Not to dismiss the boneheaded-ness of the change: I'd bet CentOS Stream is technically fine for most. Whatever 'point release' is probably fine.
That leads me to Fedora. Some predictability through the six-month release schedule yet still recent software... and no substantial change in the social contract.
Few caveats about snapper rollbacks though. First of all, you need grub working to be presented the read only snaptshot boot menu. If an update breaks grub, you'll be out of luck. How likely is this to happen? I don't know.
Second, /home is not part of snapshots by default. I would leave this as is. But this means if the update changes something in /home like a config file and you need to rollback, you'll end up in an inconsistent state. I believe this is what happened when people upgraded to plasma6 from within an existing plasma session. They could not rollback and fix the issue.
In my experience of a few years tumbleweed has been really stable until very recently. The plasma6 issue in my opinion was huge. Should never have happened. I belive they added extra checks into openQA to catch this class of errors in the future. However, if I am to speculate, I don't understand how not even one person from the whole org has not tried to upgrade plasma6 from within plasma and notice this issue. We've had another issue last week or so that hit users of a particular manufacturer's gpu. I don't remember which, but it's not intel which I am on. Last year there was an issue where they broke up networking packages in such a way that if install recommended packages was disabled, you'd lose your wifi. (install recommends is enabled by default for tumbleweed. Fair enough. But at the time it was not enabled for the variant called MicroOS.)
By the way, people who are considering Tumbleweed, can also look into Slowroll, which is tumbleweed at some point in time. It does not update as frequently as tumbleweed but as far as I know a slowroll update does not signify anything like a point in time were the packages were most stable or a security issue was just fixed. (By extension, you'll be less likely to have a broken system but also less likely to get security updates on day one. Something to keep in mind.)
Lest it sound like I am not recommending Tumbleweed, I'd like to explicitly recommend it. It really is great.
It was a MESA issue for AMD users. Intel users seem to have the best stability on Linux.
> why?
Live in the future. Compile your filesystem layout.
https://en.wikipedia.org/wiki/Category:Rolling_Release_Linux...
https://en.wikipedia.org/wiki/Category:Rolling_release_Linux...
And Arch itself is just pleasant. Packages with as few downstream modifications as possible, reasonable defaults, organized and thoughtful system layout, systemd integration everywhere but without forcing you to use it as anything other than an init and logging system.
I'm sure the experience is different on a laptop, but on a desktop PC, Endeavour has been the lowest-fuss Linux OS I have tried and I have no plans to switch to a different one. Helpful community forum too.
- Void Linux
- Chimera Linux
I can’t decide on a favourite, but they’re both very interesting projects.
From all I tested, it offers best synergy for all I wanted. Biggest package repo, every problem is nicely searchable and has nice community.
I always go with Testing and have had a few hiccups and issues along the way, but nothing unfixable in short time.
Wanting toget away from systemd, I attempted a Devuan install but bungled it and went back to deb.
I did Arch for a few years but am not a newfangled fanatic so gave up on that. As most say, the Arch documentation is tip top.
e.g.
Major:
* neovim 0 -> 1
Minor:
* jq 0.1 -> 0.2
https://pastebin.com/FeVg0kDU (expires 202408)
Definitely a case of something that started as Bash and wound up likely better as something else. It's not a clean script, bit of inconsistency - don't @ me :)
I do realize that the whole point of arch is that you're the one with the spice rack, but, I generally like what manjaro's doing. Not to say it's been all roses, just that it's been fun.
Once I installed Arch in my PC, I spent some hours configuring it according to what I like. After that, I looked it and thought "ok, now I have a Manjaro".
Manjaro is a little bit bloated, but it is faster for me to remove the bloat instead of configuring everything.
Other use cases (e.g. using in Lima, WSL or a local container) it doesn't matter, so I use Arch.
Using it for 4 years, both at home and at work (also have Raspberry Pi 4 under Arch Linux ARM).
I'm a bit perplexed why it is considered less stable than "your typical Linux distro". Never used Debian, but I used Ubuntu with KDE prior to Arch. It was very common to have problems, from constant messages about crashing staff (AppArmor hitting the record) to reinstalling the entire OS. During 4 years with Arch I had only a few tiny issues that required 5-10 minutes to fix (not least thanks to Arch Wiki).
Not sure though if this is because Arch is so nice by itself, or because with Arch I moved to more minimalist setups (which Arch endorses so naturally).
It could be Endeavour. I never used it, even though it looks like it would suit better my use case, but it has a smaller userbase than Manjaro.
Is very up to date. Is very stable/recoverable. Has many packages. Has reproducible packages. Has a great config system (I do not miss having to learn a new config syntax for each package). Allows for easy compartmentalization of packages.
Does Steam OS 3 count? They have a nice atomic update system, with an Arch base.
may not be recognized by most people as such, but
* debian testing ( atm its "trixie" :)
i use it for my "internal" systems - like backup, NAS, etc.etc...
yes, its not "your default" rolling distribution, but it rolls ... and breaks things from time to time ...
but this shouldn't be a big problem, if you know a thing or two about debian - otherwise: see this as yet another possibility to learn something use[full|less] about debian/linux/...
if you want debian testing but somewhat "moderated" - to avoid the biggest "riffs":
linux mint debian edition (LMDE):
* https://linuxmint.com/download_lmde.php
just my 0.02€
**But** Slackware Current is really a Alpha/Beta Test System for Slackware Release.
On the other hand, Arch was much easier to setup.
CentOS Stream?
No need to backup the system, only my data, config included, no need to keep a bug ridden giant homegrown install scrip to replicate (trying to) my system on hw changes or wasting time with Ansible and Salt YAML/python hell to do the same with no less bugs and real guarantee of successful replication.
I have an *nix background but a bit tired of GNU/Linux since MANY years, I've tried switching back to FreeBSD a bit of time ago, but it's modern hw support is not enough for my needs, orphaned of OpenSolaris/IllumOS (with zfs a bit integrated into the system, meaning installer/package manager able to produce boot environments and clones reliably and easily enough) I've found in NixOS a relief. The Nix langue for me is as digestible as Haskell, something close to digesting broken glass, but for my mere needs it's usable enough. I only dream the community find a relief of Guix start to care the desktop a bit more, since HPC is a nice thing but... To have a model spread we need the desktop, Microsoft know that very well...
Long story short: the point is not "avoiding regular painful fresh installs or dirty cross-release upgrades" but making upgrades NOT PAINFUL and easy to reverse without issues. All the time in all system an update can fail, that simply must be not a issue. A casual user have no reason to invest much time in his/her own production machines, investing to learn once, profit forever must be the model. Is something breaks the casual user just have to reboot and wait a bit of time if the breakage is caused by upstream changes of waiting for when he/she have time to see what's part of his/her own code needs to change. No issue meaning not much more than a simple reboot. No time wasted with zfs diff and so on to quickly fix your system because you need it tomorrow morning and you have updated late night on the go. Also there MUST BE NO REASONS to waste hw resources and running Babel's towers like docker and co just because some apps are damn complex.
In NixOS deploying a classic LAMP app is (if packaged) servicename.enable = true; in most cases. Few LoC otherwise, DB, NGINX, PHP, ... no matter what get set up issueless without downloading and running a Matryoshka of distros with lxc/d wrappers running binaries made by unknown people on internet, with often not updated dependencies, forgotten ssh authorized keys and so on.
NixOS and Guix are the classic IaC applied to the OS.