Manjaro may have some hope: it's received a lot of criticism for the odd way the maintainers have set up some aspects of the distro, especially from Arch users. I've seen HN threads full of comments saying things like "why on earth would anyone use Manjaro when you can use Arch?". Those commenters miss the selling point of Manjaro: it's a rolling release for Ubuntu's target audience, and that target audience want one important thing Arch does not offer:
- an officially supported, opinionated installer of a fully configured Desktop environment
Unless something major changed, you're dropped to a terminal as soon as you boot the install image, and have to either have advanced knowledge on what to do from there, or have the wiki side-by-side on another device. And unless you're taking incredible notes at the same time, good luck replicating the set-up if you need to reinstall.
Ubuntu, openSUSE, Fedora, and most other mainstream distros at least boot you into a GUI to install.
I once had my computer crash during a kernel update and this left the system unbootable. All you have to do is use the arch iso and arch-chroot into your system to rerun/undo the kernel update or whatever other update broke your system. The thing is, even a "reinstall" is merely about deleting packages and then rerunning pacman and reinstalling your bootloader. Your /home and /etc stay untouched. You can take the list of installed packages and then install those. I mostly needed that when moving from an old laptop to a new one.
I'd rather nuke from orbit and rebuild than duct-tape holes :p If my system became unbootable for some reason, I'd fix it and ideally find out what happened, backup stuff, and reinstall. Best-case, everything is fine (although I'd change distros if it ever broke because of a clearly untested updated). Worst-case, the system becomes unbootable again because of the same issue and I can report it upstream with more confidence.
Say my enterprise application is built upon the API (in an abstract sense, if you will) of package xyz, version 1.0. And then xyz, version 2.0 comes out.
I would have to rebuild my enterprise application to be compatible with API 2 and I don't have the resources nor the incentive for that because I don't need API 2. Then a vulnerability gets reported in both xyz version 1.0 and 2.0 but xyz's maintainers only patch 2.0 (as 2.0.1).
In that case I am very happy that non-rolling (enterprisey) distro's like Ubuntu, CentOS, Redhat etc backport that security patch so I can keep running xyz version 1 (or rather 1.0.0-1 or something like that). Where most rolling distro's would just 'force' you to upgrade to 2.0.1.
Hope my explanation makes sense.
People go on and on about backported security patches and stability, but I’ve had to handle so many buggy patches or issues that never got a backported fix that I now think this is basically a fantasy. The distro maintainers just don’t have the time (or experience with all the software they ship!) to backport patches for every single issue. I’d really rather get a fix by the actual software maintainer than a year-old mystery meat version that still has a bunch of known non security bugs fixed in upstream that the distro maintainers don’t care about.
Even worse, being able to stay on essentially outdated software puts a lot of organizations into a tough spot when their LTS version finally becomes unsupported. Practice makes perfect, and I think lots of small, regular updates result in a lot less pain than a mega-update every few years (really: I’ve had to manage one of these more than once, and it’s a total nightmare figuring out which of 1000 changes in the new LTS version caused a performance regression or something).
Well yes, the testing is of course part of the 'as fast as possible' part. But I could've made that more clear indeed.
> many buggy patches or issues that never got a backported
I have yet to see those in CentOS. But I guess we won't be seeing a lot of CentOS at all in the foreseeable future :p
> many buggy patches or issues that never got a backported
I feel like thats mostly on them. There is a huge temporal overlap between LTS versions and you should have plenty of time to test. I think I'd rather dedicate one month every year to fully test and then roll out a new LTS version than be interupted by unexpected updates at random intervals.
That being said: What a boring job it must be to backport security patches all day.
Regardless, I solve all my OpenSUSE problems using the Arch wiki since they're both rolling-release, modern software stacks, systemd, etc distros, so I'm always grateful that Arch exists.
I use Fedora primarily because of SELinux, and apparently Arch doesn't even use a MAC by-default and expects manual-setup.
openSUSE Tumbleweed is a better rolling-release implementation imo and has even been more up-to-date than Arch when it came to some major GNOME, KDE and kernel updates.
But, just like point release distros, people are going to want to try new things, and for some things they want to try, it’ll be easier to start a new project rather than somehow convincing the whole Arch community to try their thing. Arch is pretty conservative and sticks fairly close to upstream.
So, we’ll keep seeing new rolling release distros, and some of them will have good ideas, so they’ll stick around. Which is great, diversity is a sign of a strong ecosystem.