Meanwhile over on Debian/Ubuntu/PopOS/Plasma, I can finally run the latest games (thank you Steam & Proton!), edit video with pro grade tools (thank you DaVinci) and I still have a great coding environment... Oh, and thanks to cloud based office software, that's no longer an issue.
For almost everything, Debian works just as well as Ubuntu, but it's more boring and has less drama.
So far, I have converted back to macOS, which is equally bad from UX perspective, especially the hardened security - I just don't want to opt into every program getting the permission to run, send notifications, access this and that. It's just too much.
I think I will give one of the more non-corporate Linux distros a try. Or, maybe it's Pop, but ideally it should be Debian based, just not with the "outdated" experience.
Had you chosen Fedora with KDE you'd probably have 0 problems. I'm using it without any drama for 11 years and I keep suggesting it to co-workers and friends.
Wayland has done so much harm in the Linux ecosystem and that gives me a lot of grief :(
What didn't help was probably the desire to force myself into liking GNOME, when normally, I fall naturally into the KDE camp, because it is beautiful without having to make things too simple, like GNOME does. Even though I agree with many of the things GNOME stands for, there is lots of stuff you wouldn't NEED to customise, or use.
Will consider KDE on my next attempt!
It would be nice if it were possible to avoid the compatibility issues with Wayland, but the design of X (and the reliance of applications on X11-specific APIs) is what makes this not really feasible.
Those some things are things, you shouldn't do in the first place, like snooping on windows and events that do not belong to your app or injecting events that end up being processed by other apps.
If you don't do that, Wayland is fine.
> That’s why folks reach for Mac OS ...
A conservative Linux distro choice is way more stable than Mac OS is in regards to "sudden" changes you need to deal with. And on the time scales we worry about CentOS or Debian, Windows has its pitfalls too.
In all cases, if you need a long-term strategy, it's always going to involve some level of preparedness to handle a change.
If you want to keep up with all the distros and their individual going-ons, that's your choice. You can use Linux just fine without doing so.
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 :)
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.
+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.
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?
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?
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.
LFS for the win!
Gentoo anyone?
Likewise on the Windows side, the SKUs vary from release to release, group policies come and go, and generally they've increased their push into seeing Windows as a way to promote their other services and don't really care what you want from it.
It's fun to try other things like NixOS and GuixSD, but also have the warm blanket of "just put Debian on it" to fall back to.
"Are you tired of your Linux distro being bought out and crushed by IBM exactly one time in history?" Cut to a big dopey confused person shrugging. "Well then try Apple!" Dopey person smiles. Star wipe.
https://www.businessinsider.com/red-hat-deal-talks-with-amaz...
https://arstechnica.com/gadgets/2020/12/centos-linux-is-gone...
At least for Windows, can't you just quickly compare the ethical universes? I'm assuming that Phil didn't embrace-extend-extinguish other distros, Phil didn't secretly change Skype to break the encryption for LE, and Phil didn't upgrade the distro to do constant, inescapable telemetry and update arbitrarily downloading Gigs of data such that it interrupted a user's live broadcast.
In other words, if your decision is between Phil's distro and Windows, Phil's distro wins so it's the end of the story. And if the HN trolls you're responding to aren't claiming a 1:1 feature correspondence with "ethical" distro vs. Manjaro, who cares?
As the saying goes, Linux is like democracy: it's the second worst (widely-used) system ever, because all of the others are tied for first.
It’s easy to get sucked in.
I mean, they have a command line program to report a bug. That and their monstrously complicated packaging apparatus would make me think someone at Debian considered the sucking-in of people to be unethical and thus designed their maintenance polices to prevent it.
Huh?
.debs are gzip'd tar file with predictable top-level folders and some manifest files. An APT server can be as simple as an FTP site, again with a predictable hierarchy and some manifest files.
Keysigning gets a bit messy but it is still relatively simple.
You can set up your own private package repository in minutes using nothing more than ftpd, gpg, mkdir, and vim.
The documentation is clear, comprehensive, and relatively easy to read.
How is this "monstrously complicated"?
If you are new to debian packaging, make a reservation in your calendar for several evenings, just to figure out what exactly you have to read through.
Like, you create a folder structure that mimics the final installation inside one of the two toplevel deb folders. The other folder had a manifest or two. Worked easy, and did not take long to figure out
https://blog.knoldus.com/create-a-debian-package-using-dpkg-...
I have a script which does various things with git to get a copy of the latest code, tag it, then runs something like
fakeroot dpkg-deb --build ./$packageName/src $packageName.deb
In that src file are things like "usr/whatver", "opt/whatever", "etc/whatever" and "DEBIAN"
In DEBIAN is a really simply control file and sometimes some scripts to do things on install.
Getting a package approved by the debian maintainers is an issue if you don't follow the guidelines (and lintian will help) - just like getting a package approved by the redhat maintainers, but to make your own deb is barely harder than creating a tarball.
That's why I qualified it "according to packaging guidelines".
And I don't want to comply with packaging guidelines because I want to get it into the upstream repo; no, I want it compliant so it is not broken at upgrade time and I don't want to have to solve several problems at once at the most inconvenient time.
With rpm it is both easy and piecemeal - you don't have to have the entire knowledge in your head upright, you can improve it continuosly. You start with spec file and rpmbuild, then find out about rpmlint, then you will find out about mock (so you can build package for Fedora-any version and CentOS-anyversion from any distribution, including Ubuntu or Debian, inside chroot or container) to koji (full blown distro-scale build system).
I haven't had to deal with any drama using Debian or the BSDs, personally speaking. Which I have been since 2000 or so.
That is the best example I can come up with. I do remember Debian libc being broken, as well as the cryptography, but I would not say that was drama.
The only real time I can think of where they caused any impact to the end users would probably be when they changed up a bunch of software because of licensing issues -around 2001 or so. That also led to them writing or re-writing a lot of software and gave us pf, too. So I'd call it a net gain, personally speaking.
On the linux front -libc6 and the elf change-over caused a lot of breakage; like you said -I'm not sure if I would call that "drama" or not.
You are on about direct user impact, where a project discontinuing is perhaps an ultimate one (EOL being moved 8 years in advance is almost that).
Regarding OpenBSD, that isn't the only occurrence. You can grep mailing list archives for some keywords. Look at how people like Daniel Hartmeier, Niels Provos, and Wim Vandeputte got treated. Sure, it did not cause OpenBSD to collapse but I would say it was controversy.
https://www.unixmen.com/freebsd-vs-openbsd/
and then the lawsuits:
https://www.freebsd.org/doc/en_US.ISO8859-1/articles/explain...
https://klarasystems.com/articles/history-of-freebsd-part-2-...
Mandatory must-care-about drama since then?
No, not really.
The ASLR patch comes to mind, as does the KSE / libthr thing.
Equally there have been some very grown up moments. The Matt Dillon / DragonflyBSD fork comes to mind.
hug
Folks don't go for proprietary systems like Windows and MacOS because of theatrics around distributions, they just choose one of those stolid long-time favourites like Debian, Ubuntu or Mint and ignore the squabbling. Those who want to get a more hands-on experience might go for Arch, Slackware or even LFS.
If you don't want drama, use software maintained by people who have a life and don't have time or energy for drama.
But in the the Microsoft world, you at some point had Windows Mobile and Windows phone, and developing apps for those is the true meaning of being alone.
Ignore the drama and the dramatists. The software works well, and better than the alternatives on that hardware.
The snap drama is a ideological purity contest by people who should know better (aka use something else than Ubuntu if that pisses them off that much).
It's not like OSS community would have rushed to provide alternative packages for Flatpak, AppImage, deb etc.
Snap automatic updates are still the fastest way to update servers with latest security etc updates, keeping servers secure. That's the reason usage of Snap packages is increasing.
With Docker, recent drama was Docker Hub rate limits, so I had to move Docker base images from Docker Hub to Quay.io, so that Docker images could be built successfully.
This would be the problem; you treat Linux as a platform that one is supposed to love or not love as a hole.
Linux is not a platform; it s a component shared between a great many different platforms that are often quite far apart from one another.
These platforms often also share other things, or not, and don't Windows and FreeBSD also share several components?
I've noticed a common belief that completely unrelated, independently started and operated platforms have an obligation to coöperate because they share a single component, which most of them also heavily patch and modify.
> Recently I moved to Apple Macbook Pro 2019 (FYI before that I was using Linux Mint for years without any drama). But after using this very expensive MBP, I am not happy at all. Hardware is the best in class while keyboard is the worst in the class. But my biggest complain is keyboard layout. It is not ergonomic at all. In windows/linux, WINDOW key manages window manager while CTRL, ALT can be used to manage applications. On internet, many places it is mentinoed that, use apple COMMAND key as control key and OPTION key as alt key. Ok thats fine. But this behaviour is not consistent at all across apps. Many apps use CTRL key to control application additional to COMMAND key(e.g. in chrome/vscode, toggling tabs can be done using CTRL+TAB, not COMMAND+TAB). And this CTRL key is only one side of spacebar, very very unergonomic. Additionaly if you are a touch typer powered with mechanical keyboard, you can press CTRL key on windows layout using wrist. This is not possible on Mac as its first left key is FN.
After using MBP for couple of weeks, my hand literally hurt like mentioned in video. I dont think I can operate MBP for hours without looking at keyboard. In Windows you can do everything with mouse only. In Linux you can do everything with keyboard only. In mac, you need both and your hand hurts.
You can do that? If I get my wrist anywhere near high enough to hit a key, my fingers are about two imaginary rows above the function keys.
The other day I commented that I took my Pinebook Pro off the toy shelf and loaded up Manjaro. I commented on HN about how much I liked the user experience. The first reply I got was something about the drama with some dude named Phil. Alternatively I’ll put my head down for a while and forget about the lineage of the various options and then something will crop up about this or that distro is going away, being repositioned or whatnot.
Why does this matter? Because I want to use it for real work and I don’t want to spend time planning a long term OS strategy. There are other things to worry about. I’m far from alone in this. That’s why folks reach for Mac OS and Windows.
Downvote away, but I really do want to love Linux. I just don’t want it to be so hard to love.