You seem to be massively overcomplicating things. If you don't want to worry about the "distro drama", then don't. Just use one of the major distros (e.g. Debian or Ubuntu) and move on.
In principle, there's no reason why another-CentOS couldn't come about in the same way as CentOS came about originally.
...but now that CentOS has been professionally funded for so long, the bar is higher than it used to be.
With the number of changes that have happened with Apple's, Microsoft's and Google's various OSes over that period it's hard to say that GNU/Linux isn't being held to a higher standard here. CentOS being the trademark-stripped knockoff of a corporate OS is the reason for the instability - when you deal in corporate OSes, you're subject to the business strategies of their sponsors. Some would say (weasel words) that the strategies of the sponsor of CentOS have been the source of instability and conflict across Linuxen for a long time now.
Isn't stability and dependability the precise reason of CentOS popularity? Do you have any source on it not being stable and/or dependable?
Still, you seem to be missing the larger point. Suddenly, CentOS is dead. Maybe I'm an outlier, but that seems like a disruption in its stability and dependability.
> [fails to be stable] for more than a decade and a half
CentOS was stable for more than a decade and a half. Whether it continues to be stable or not, that remains to be seen, unless you're an oracle :)
+1 on Debian. It's as drama-free as it gets. I mean, the distro is criticized for being too boring and too stable and too rock-solid and too unsurprising. Those descriptions are also used to describe power lines and sewer lines, i.e., reliable infrastructure.
Don't get me wrong, I think the authors are and we're probably the best authorities on what is and was needed in an init system, but the problem space was so poorly documented and understood because of all the crazy custom she'll init scripts people were using that they just kept having to tack on weird directives in piecemeal ways, until were left with what we have now.
What the world needs is for the systemd authors to take all that knowledge an apply it to a new init system in a sane way, but nobody had the will to go through that again, most likely especially them.
Me?
> Either you believe systemd is fine
I don't think anyone really believes that. They just believe the benefits it provides over sysvinit are real and generally worthwhile in most cases. Systemd has many warts. I'm not sure anyone refuses to believe that.
> or you believe sysvinit never should have been replaced
Yep, there's plenty of people that believe that. I've had discussions with them here.
> or should have been replaced with something totally different than systemd with a much smaller scope.
I'm sure there are people that believe this. Personally I think it's mostly due to being unaware of some facets of the situation. Systemd itself was much smaller in scope originally. The scope increased as they ran into things that it really made more sense to combine than leave separate. A different project may have chosen to leave those things out when encountered, but then it would have all the problems systemd tried to avoid.
That actually aligns quite a bit with my argument. With time and foresight (which wasn't necessarily possible the first time, since this is the first time an init system has tried to accomplish these goals that wasn't already intended for a tightly coupled system like Windows or MacOS), they could plan:
1) A more sane unit file syntax that wasn't ambiguous and confusing because of accreted features (After vs Wants, etc).
2) A sane API for subsumed services so if someone doesn't want to use the reference version provided by systemd, it's straightforward to drop in something else as long as you an make it talk systemd (or provide an interop layer). E.g. DHCP client, login managers, etc. This may or may not be done to some acceptable level currently, I'm not sure (but I suspect it depends on the service).
3) Take advantage of even more new kernel features for additional benefits (it's eBPF all the way down).
But here's the thing, while I think everyone would agree that something like systemd that's more modular in a well defined way and more sanely configured and documented would be preferable to systemd (I mean why not, it's basically "systemd but better" which is preferably even if you don't like systemd), I don't think anyone really wants to go through the process of either developing, integrating, or learning a new system at this point. We're all too exhausted.
And that's a shame, because what we all have now is the mad scientist's awesome flying car. Sure, it does amazing things, and you can do things that would be near impossible in the past, but you control part of it with your thighs and elbows and there are two steering wheels, and the one on the ceiling is the one that steers it like a car.
If we ignore similar systems on big iron UNIX and mainframes.
I'm happy to hear of them, because I'm ignorant of them if they exist.
https://en.wikipedia.org/wiki/Launchd
https://en.wikipedia.org/wiki/Service_Management_Facility
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_74/rza...
Launchd doesn't count, I already mentioned MacOS specifically to account for it. :)
SMF has some features beyong sysvinit that systemd also provides, but I'm not familiar enough with it's advanced usage to know how much beyond the obvious ones (service restart, etc) it does, so I'll try to take a look.
I don't know anything about the IBM one, so that's worth taking a look at. Thanks!
I think the best and most thorough explanation of this is gotten through reading the systemd retrospective[1] that someone posted earlier this year. What becomes abundantly clear when reading it is what I think I was trying to express above, that there is so much that could be better in systemd but that it's hampered by it's own legacy baggage, which accumulated very quickly and very soon after the first implementation was released.
That link is a long read, but if you have any time or effort invested into systemd and systems that use it, and find yourself having to create unit files or diagnose weirdness with services, it's very worthwhile to read if you haven't already.
Whats the worst case scenario? You find that you don't like the choice you made and spend 2 hours switching to the other option?
Red Hat wasn't involved in any of the drama outside of being the ones writing and funding OSS software for themselves.
https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logind...
Slightly more recently:
https://digitizor.com/gnome-linux-only/
This was an eternity ago in internet time, and I'm not all up and up on BSD development, but maybe enough folks are keeping it going on BSD nowadays?
LFS for the win!
That's absolutely a reasonable point of view -- for your use case.
From the perspective of a variety of folks, including corporate IT, makers/vendors of drop-in appliances and other folks, the changes to the CentOS product will be disruptive.
This is because production servers and appliances generally need to run, for extended periods (measured in years) the application set specifically designed and implemented for the particular set of software versions on a particular OS/distro.
For many of the above folks, CentOS fit that bill nicely, as it reliably tracked (that is, was slightly behind) a commercial (i.e., you need to purchase a support contract to access updates and support from the vendor) Linux distro (Red Hat Enterprise Linux -- RHEL), but did not require any support contracts or fees above those for hardware, installation and administration.
The problems for the above implementation/management/administration strategy comes out of changes to the CentOS long term support policy.
CentOS (with versions 6 and 7) provide(d) a ten year support window for those versions and promised the same for CentOS 8 (released in 2019).
Many of those who had chosen CentOS for it's free (as in gratis[0]) access to the commercial RHEL platform took CentOS (whose developers/maintainers were hired by RedHat[1] to continue that work in 2014) at its word that support for CentOS 8 would also be supported for that same ten year span, updated their environments and applications to the latest version.
That promise of support has now been rescinded, as CentOS will now be the gamma/release candidate version of RHEL and will lead RHEL slightly rather than trail it.
AIUI, there are many reasons for this change to CentOS development, the biggest being that Fedora (the community project that RHEL used as its Beta platform) is now so far ahead (via its rolling release schedule -- for example the RHEL/CentOS 8 kernel is v4.18 vs. Fedora 33 kernel v. 5.9 -- more than two years) that it's no longer providing that utility.
I absolutely understand why some folks are upset, but claims that "CentOS is dead" and the like are rather hyperbolic in my estimation.
Disclosure: I have no financial interest in IBM or Red Hat, nor am I a user of CentOS
[0] https://en.wikipedia.org/wiki/Gratis_versus_libre
[1] https://lists.centos.org/pipermail/centos-announce/2014-Janu...
I think we were shelling out around $300 a RHEL license, which was a significant percentage of the docker boxes we started putting together with some low end hardware.
Anything run-the-business should have support. Anything used by developers for R&D / messing about can be unsupported.
Gentoo anyone?