There are many reasons to not like systemd and the creator, who incidently after leaving the GNU/Linux is now working for the same company that sought to destroy it, Microsoft.
The above doesn't represent my personal opinion, it's a representation of what reasons people might have.
I only learned about that a few days ago, here on HN (some thread or some old comment).
It is completely insane and gives lots of fuel to the systemd haters.
I do run both Debian (systemd) and Devuan (a Debian fork with all the systemd stuff removed). I use Devuan on my main desktop PC and I've got exactly zero problem.
That's the thing: many "sell" systemd as some mandatory machinery but it simply ain't. Ultra-light containers (like Alpine-based ones) run fine (and faster) without systemd. Desktops do run fine without systemd (I'm running Devuan on my workstation and Debian on my laptop: it's basically the same experience). For certain types of servers I can understand some see benefits in running systemd.
Neither IBM / Red Hat nor Microsoft should be those setting the terms of what is or is not an acceptable "PID 1" for Linux.
The day Linux becomes "systemd Linux" is the day I'll switch to a BSD.
I don't mind that systemd exists as long as people still have the choice to run a non-systemd Linux. The kernel should be orthogonal to systemd and there should be Linux distros packaged without systemd.
And systemd proponents shouldn't go out of their way to try to prevent non systemd Linux from existing.
Sorry, what exactly is the issue with a bunch of Linux maintainers working for Microsoft? Is there still some sort of collective adjustment issue with Microsoft being a major backer of Linux now? If the maintainers themselves (people who have dedicated their lives to progressing Linux) are ok with it, why does anyone else have an issue?
And what kind of fuel would it add? That systemd has corporate backers?
Systemd was 100% created by redhat, so no, corporate backers aren't the problem.
The real problem is that Microsoft has historically tried to destroy linux, and beyond that, has a huge history of FUD and embrace and extinguish.
Many in the OSS community consider Microsoft to be pure evil.
And if their historical behaviour is any indication, nothing they do with/for Linux will turn out well, or good for the community.
And now they're one of the major backers. All the work is being done in the open, so it's not like there's a nefarious hidden agenda there (an agenda that would have needed to somehow stay dormant for 10+ years).
The idea that working for Microsoft is something dirty that should be shunned for open source just doesn't make practical sense.
And embrace and extend can exist in OSS models.
Microsoft is dirty, and it is dirt they cannot wash off in a mere few years.
If they behave correctly for 20 years, as long as they behaved in a literally evil fashion, then maybe they have reformed.
Just a reminder holding grudges isn't good for your mental health.
Microsoft has done many terrible things. Most companies of that size have. But they have also done a ton of good things. It’s impossible to take a group of tens of thousands of humans and not find rampant examples of both good and terrible things.
Sometimes one outweighs the other and that may sound like where you are but there is a wide gap between doing evil and saving lives, and most of us live somewhere in that gap.
But everything I see since Nadella has taken over, tells me that they aren't just paying lip service, that they have just realized nearly a decade ago that it's good business to embrace (loaded word) Linux if they have any chance for Azure to succeed, and their moves suggest that's a core part of their future.
systemd should be an optional package on all distros. Shoving it down throats is one of the valid major criticisms. What should have happened instead is systemd was optional on Debian at setup and Debian was forked to include it by default. It is simply backwards that Debian needed to be forked for purity. Duvuan shouldn't need to exist, but it very much does.
The entire ideology of openness and freedom has been turned on its head. Instead of "what is best for everyone is good enough for me," has become with entitlement "what is best for me is good enough for everyone." Maybe you like the way you do things, but would any here really insist on forcing everyone else to use your methods and no others?
systemd, among other valid criticisms, is unmistakably fascist. For anyone but parent, don't just be thin-skinned and downvote my comment because you have allowed yourself to be insulted. Be courageous and disagree with me if you can. How is systemd not fascist?
> a political philosophy, movement, or regime (such as that of the Fascisti) that exalts nation and often race above the individual and that stands for a centralized autocratic government headed by a dictatorial leader, severe economic and social regimentation, and forcible suppression of opposition
systemd has nothing to do with nation or race. There are much better words than fascism to describe Debian's prioritization of systemd.
Human systems tend to flourish when political and economic decision-making is relatively distributed throughout a given population. I believe this position is backed by a reasonable amount of empirical observation.
Machines are (as of this writing) programmed by humans. Unlike humans, machines are automated rule-followers. This is substantively different from decision-making, which is a uniquely human trait involving moral agency, free will, etc. (at least as I'm defining it for the purposes of my argument). If you try to turn humans into automated rule-followers by decree, they tend to become miserable. Fortunately, one does not have to take into account how machines feel about being absolved of all decision-making, making such control systems very effective (you don't have to kill / imprison the dissenters). But even though the machines might be more effectively programmed by a centralized, unified, top-down, "authoritarian" control architecture, you still need humans to build this controller. And since we know software projects end up mirroring the communication structure of the humans in charge of building them, it follows that authoritarian-minded software engineers would be a best fit for building such systems.
The converse is that libertarian-minded software engineers tend to recoil in horror when they encounter authoritarian software design, no matter how unified, elegant, or effective it may be. Such things are a moral transgression to the libertarian.
Why? Should glibc also be optional? What about the Linux kernel? What about apt-get? You can technically replace those things but it's a ton of extra work, almost like shipping a completely different distro. At the end of the day, a distro decides what packages it wants to support and what it doesn't. The specific choice of supported packages is often what defines a distro and sets it apart from the rest. If they have limited manpower and choose to save themselves time by picking only one init, or libc, or desktop environment, or anything, that's their decision.
>but would any here really insist on forcing everyone else to use your methods and no others?
No. There are hundreds of Linux distributions to choose from, and anyone can make more distributions any time they want. No one is forced to do anything. Also, using Linux is optional to begin with.
>systemd, among other valid criticisms, is unmistakably fascist. For anyone but parent, don't just be thin-skinned and downvote my comment because you have allowed yourself to be insulted. Be courageous and disagree with me if you can. How is systemd not fascist?
You should stop and think a bit more before making these comments that you appear to be acknowledging as histrionic and insulting. By this definition BSD is also "fascist" due to only shipping BSD init, and the Linux kernel is "fascist" due to only shipping one set of drivers, and Devuan is also "fascist" for not supporting systemd...
Libc and linux kernel are good solutions to well defined problems: a standard C library, and a kernel. They pretty much do what is expected, sometimes they do more, but not by much.
Systemd? It is not a good replacement for an init system for the users. Instead, it is an OS functionality accretion for the benefit of distributors, a baroque monstrosity that provides mediocre buggy solutions to too many problems that have nothing to do with init. It boots nondeterministically (socket activation is not such a universally great idea), sometimes hangs randomly, it disrespects the user when ignoring keyboard input while waiting 90s or indefinitely for some condition, or launching zillions of bogus hog processes for every user login event. Some of these can be mitigated on a production server, but bad taste remains.
That's subjective. I've talked to a lot of Windows users who all say Linux is a terrible solution for them. I don't think most Debian developers feel they should suddenly drop everything and start making Linux exactly like a copy of Windows just to please those people. They voted on this several times, they wanted systemd.
>it is an OS functionality accretion for the benefit of distributors
There's no problem with this. Most users don't touch the init system that much. They interact with it primarily through the package manager installing service files.
>solutions to too many problems that have nothing to do with init
Those are all optional add-ons for users who are having thoes problems.
>It boots nondeterministically (socket activation is not such a universally great idea)
This is also only an option. You don't have to use socket activation. It's there if you want it and you don't need to strictly order services.
>sometimes hangs randomly, it disrespects the user when ignoring keyboard input while waiting 90s or indefinitely for some condition
Not sure what this means or what keyboard input you were pressing. In systemd the keyboard shortcut to force reboot is pressing Ctrl+Alt+Del 7 times: https://www.freedesktop.org/software/systemd/man/systemd-sys...
>or launching zillions of bogus hog processes for every user login event
Not sure what this means either. You can disable those.
That's a different statement. I said those linux parts are good solutions to a libc library and unix kernel. Not good solutions to needs of Windows users.
> Most users don't touch the init system that much.
Most BFU users don't touch the init system. If you're a developer/administrator/power user, you do. Yes there is more BFUs (website users, android users) than power users, but that does not mean that the latter group should be pushed to not care about their init system.
> Those are all optional
Not in practice; some of those options are integrated and others are chosen by the distributions. It's hard to reconfigure the system to opt out of journald or user session control.
> You don't have to use socket activation. It's there if you want it and you don't need to strictly order services.
Yes, but that won't solve the problem entirely, systemd is non-deterministic init system where you can't fix the boot order reliably.
> Not sure what this means or what keyboard input you were pressing. In systemd the keyboard shortcut to force reboot is pressing Ctrl+Alt+Del 7 times
Ctrl+C, Ctrl+Z. I mean I don't always want to reboot because something went wrong in the boot process and systemd is stalling. I want info from my init what went wrong, and the option to fix the problem in the shell if possible. This is often not allowed by systemd when it could.
> Not sure what this means either. You can disable those.
It means systemd launches bogus processes slowing down the system. It's well known, it's in the trackers, yes I can and i do disable them.
The point is this sucks and neither the systemd developers neither the distribution(rhel and derivatives) care to fix this.
In my opinion, yes, they should absolutely be optional. Whether or not that is feasible today does not change the advantages of each component of the system being optional and replaceable. It is more failure tolerant both from a purely technical perspective, and also from an organizational perspective.
You're missing that these parts have to get replaced for a practical reason. Not just because someone vaguely feels it would be more fault tolerant. For example, think of some other libc that's optimized for a certain hardware. Distros that don't support that hardware would have no reason to ever use that libc. If you say all distros should support it, then your opinion is really "all distros should support this random hardware that might be rare, expensive, highly specialized, hard to develop for, etc" and now that's a much more complex and demanding task you're asking someone to do, for very little benefit.
What I am saying is that, ideally, every component in a distro (or any important software, really) should have at least two options, so that if one option fails for whatever reason, the user has a choice to swap it and keep working. This is already true with many components of a distribution.
This is how I am writing my application. It is not fully there yet, but I plan for every dependency to have an alternative. I also favor dependencies with long streaks of no breaking changes, having been previously affected by breaking changes in dependencies I was using.
All the changes to gnome, which depended 100% upon systemd at the time, were pushed by redhat, gnome contributers.
This one of the biggest reasons given, for getting systemd into debian at the time.
When systemd was being pushed origionally, fast boot times, predictable names, and a few other things were big reasons. Yet debian already had parallel init booting, and already had predictable interface names.
Systemd has done almost nothing for debian, and has many drawbacks, as you say.
Systemd was a redhat solution, to redhat issues, and redhat used its power in the community to force it through.
There were a lot of outright lies, politics, and more at implementation time. And you're right, part of it was redhat wanting to force systemd, and no other.
That makes me think, is there a way to know what are the projects with more open issues on Github?
* LLVM: 19,219 open issues
* Rust compiler: 8,580 open issues
* Python: 6,693 open issues
The number of open issues isn't a particularly good indicator of program quality.
Woah, I missed that news! I don't imagine he'll stop writing Linux software though.
Like when? Because I have interacted with projects where Lennart is part of the admin team and from where I stand it’s all in your head.
Both bugs and security are taken seriously.
> The above doesn't represent my personal opinion, it's a representation of what reasons people might have.
I admire the courage you display in standing for your opinion.
Latest example: I have a service I want running, so I set it to Restart=always. Read the long Restart= documentations - seems ok. Does it work?
Failure 1: Well.. you also need appropriate RestartSec/StartLimitInterval. Ok, I I set it up. Does it work?
Failure 2: Well.. restart doesn't actually apply to failed dependencies, so .. don't have dependencies that fail, ok? That's not a bug. [1][2]
[1] https://github.com/systemd/systemd/issues/1312 [2] https://unix.stackexchange.com/questions/213185/restarting-s...
Yeah, well... Microsoft is probably soon to be one of the bigger Linux developers out there. As the profit slowly drains out of the desktop their core business model is going to be increasingly dependent on open source and Linux.
Just in case anybody reading this is a big fanboy of Linux... This is what winning feels like.
It would be like going to the EV car dealership and being told the best modern EV they sell is a diesel pickup truck and they will unleash sophistry hell on anyone who doesn't go along with their meme that the best modern EV is obviously a diesel pickup truck but pointing that out in public is doubleplus ungood badthink.
Ironically, for a non-unix-like operating system, its not that bad and works some of the time, although not as well as a unix-like OS would work for someone who's engineering criteria is a unix-like OS. Most people would be technically better off with a unix-like OS than a systemd based OS, but thats not what the corporate marketing department is selling, so we all love systemd, uh huh.
That does seem to be like weirdly a thing with redhat projects. I once saw someone say that being anti-systemd was correlated with supporting trump on hackernews, and of course if you don't like gnome you hate accessibility and poor people (who apparently don't know how to use less hobbled/phone-like user interfaces).
Linux+GNU is either a Unix operating system or it is not. Having systemd on board changes exactly nothing, since there never was a system services interface anyway. Files in a directory you say? That's not an interface, it's a recipe for failure. Or why do you think that every distribution used to ship their own init scripts?
You EV car dealership is awfully flawed, especially with Linux+GNU you can even build you own car. So why are you complaining? Nobody is forcing you to use a distro with systemd. Nobody can force you. You're not a victim, you're privileged.
systemd is for the first time providing Linux+GNU with a sane system services management and finally gets it ahead of OSX or windows in terms of capability. Instead of unconstrained bash scripts (that require ridiculous template magic or fail for the first edge case) you need only a ten line service description that does things that an init script would not been able to deliver. Like the most basic thing ever; reliable restart. The amount of hacks that were necessary to get an init script to only semi-reliably restart are atrocious - and deamontools are just the beginning.
I've come to understand that the dislike of systemd has less to do with the technology at hand but more with human nature.
You're right that systemd provides useful things that sysvinit was not strong about. That is not enough to make systemd as distributed a good init system. It is a bloated C codebase with no definition of goals, instead it suffers never-ending mission creep.
In mainstream distros, while it does init, it also meddles in too many things it should not, like spawning zillions of needless user session processes hogging the system, mutilated system and service logging and others. It hangs randomly nondeterministically on boot too often, disrespects the user by ignoring keyboard input, etc.
The major point of critique of systemd push is to make people know that many don't like the offered product for its mediocre results as an init system, and uncalled for meddling in other business such as system logging. And we welcome new leaner init systems, such as s6.
https://0pointer.de/blog/projects/systemd.html
If there's an expansion of scope in the systemd project, that's because these use-cases were not sufficiently covered in the past. And while I wish you good luck with s6; how do you intend to replace all the functionality that systemd already delivers?
Let's pick an example; KDE and Gnome used to write their own session management software, to make sure certain applications and services that the desktop needs (like; e.g. accessibility tools). This is nowadays handled by systemd, since it - as a system services management layer - already implements all the required functionality. So instead of three half-backed systems (one by KDE, one by Gnome, one for the system, all incompatible and unable to talk to each other) we have one good implementation. User session are also now handled in systemd - one less component to be developed by the "Desktops" - yay!
Where you see feature creep I see consolidation. A consolidation that - in my opinion - is painfully necessary.
Many systems do not have those use cases. Everybody needs an init system, so that's where systemd could have been the fix to the deficiencies of sysvinit (as marketed). Instead, it merely kind of works as init, sometimes with random errors and disrespecting the keyboard input when things go wrong. And then instead of fixing and polishing that experience, developers expanded into million other directions, including DNS, container management and what not. Systemd is becoming a bad OS like Windows is.
> User session are also now handled in systemd - one less component to be developed by the "Desktops" - yay!
But systemd is used on servers too, and the user sessions and broken behaviour it introduces are a needless pain best to be disabled there. User sessions and related is really something Desktops should be handling, since it only makes sense on Desktops.
I have never experienced that kind of errors you describe and I use Linux+GNU on my private workstations, on my professional workstations, on various servers and some NAS devices. Is there a bug report that documents these failures?
> Systemd is becoming a bad OS like Windows is.
Systemd is a system management layer, the operating system is GNU+Linux.
> User sessions and related is really something Desktops should be handling, since it only makes sense on Desktops.
You can disable it, if for some reason you get errors. Never had issues with user sessions on servers either.
Good for you.
> Is there a bug report that documents these failures?
I didn't try to document these rare random events. I've learned to expect them, as part of the systemd feature.
But there are such reports, e.g.
Systemd ruined Debian for me, for example.
I'd been using Debian testing for years and years, on multiple systems. Despite its name, I'd always found Debian testing to be more reliable than the stable releases of other major distros.
When performing updates and upgrades during those many years of using Debian testing, I had only ever experienced trivial issues that I could easily resolve, usually just on my own with a few minutes of investigation.
Then systemd was forced onto Debian's users.
As soon as it ended up on one of my systems, the problems started. That very first update left my computer unable to boot. That was the first time in over a decade of using Debian that that'd happened. I also remember it taking far too long to diagnose and resolve whatever that initial problem was.
Subsequent updates involving systemd just caused me more and more problems. They usually weren't minor issues, either. They'd significantly impact the usability of my installation.
To make matters worse, I, as a user, didn't see systemd even bringing me any benefits.
Eventually, I lost my ability to trust in Debian and its reliability, even for Debian stable once systemd eventually made it there.
Now I completely avoid Debian and other systemd-using Linux distros whenever I can.
a) Poor documentation
b) Overly complex
c) Not a choice
I myself don't have a problem with the monolithic thing that replaced sysv init scripts. While the definition of sysv init scripts was attractively simple, the resulting implementation was not. Wading through many lines of boilerplate shell that's mostly accidental complexity is not my idea of a good time.
But I do hate how systemd splays its config and dependency graph throughout hundreds of tiny files and symlinks in multiple directories (and .ini files at that!), and then insists that this is no problem because you can "just" learn some bespoke commands to analyze them for you. With my sysadmin hat on, I'd much rather have a unit be a single file in a single well known directory, that specifies only the service properties and no dependency information. And then have the dependencies orchestrated by a single logical top-level file that pulls those units in and defines what depends on what. In general if I'm going to customize a distribution-supplied config file, I'd much rather overwrite the distribution file and completely own it going forward, rather than having the distro file and my file merged with some arbitrary rules.
Having said that, I've moved many of my machines to NixOS where systemd is just another thing to be mitigated and nixified. The expected on-disk format doesn't matter, because it's all generated from a single logical config file and then splayed out however systemd wants. The nix config looks a bit verbose and wonky, but at least it's contained. But it also feels like it would be quite easy to switch out down the line...
This means that anyone who relies on this feature is now tasked with all the extra work and cognitive load of finding replacements for those features, changing and testing their configuration, and the risk of deploying these changes.
To me, that is a "non-consensual" change, and I try to avoid any technology that has a history of these non-consensual changes, because I want my systems to run without extra maintenance.
Then stop using Linux. The Linux kernel replaces subsystems with different, incompatible subsystems all the time. For example packet filtering was once ipfwadm then ipchains followed by iptables and now nftables.