As a write once read many system, the abandonment of systemd isn't a big deal I suspect. You don't write to the system area and expect it to persist, and so making modifications to the init system basically isn't going to happen. The modularity doesn't really make as much of an impact then. So any backlash from unhappy users who can't install xyz with one click and have init work properly, not a big deal. Anyone who uses something more complex like an overlay system with it likely has more of an interest in the internals anyway, particularly given the nicheness and age of the distribution.
I see a lot of hate about systems and I used to loathe it too.
Then I took a course on systemd specifically and it opened my eyes, and now I'm quite fond about it.
Systemd actually does ONE thing and does it well: it manages the system. It's the missing layer between kernel space and user space. It has quirks and bugs like all software, but I think it works very well, all things considered.
To those who say that it's complex and does a lot of things: it's complex because it does a complex work.
Knoppix is very installable and usable as a main operating system.
Knoppix claim to fame is automatic configuration. If your Xorg or sound was giving you grief after a fresh install, you'd live boot Knoppix and copy the configuration files back to your installation.
From this p.o.v. it makes sense for Knoppix' use case, because, as stated by Klaus Knopper: "This bypasses systemd's interference with many system components and reduces the complexity of the overall system."
> Knoppix claim to fame is automatic configuration. If your Xorg or sound was giving you grief after a fresh install, you'd live boot Knoppix and copy the configuration files back to your installation.
Is it really so? I would expect all distributions to have stolen that feature by now. Xorg works out of the box basically everywhere. I've had a glitch with a microphone on a 3-pin jack on a Ubuntu system, and I doubt Knoppix would have known that a modprobe config change was needed.
The problem is that it comes bundled with a whole bunch of other tools for handling networks, cron, ntp, etc which really ought to be separate projects. By bundling them with the successful init system they're not exposed to the usual Darwinian selection processes that shake out the best free software.
They're separate binaries, and can be easily unbundled.
That they're part of the same project is actually a win for me, it helps to make the various components work well together. Also there is a common thread or philosophy in how things are built, making learning easier.
In fact "the system is a single project" approach reminds me of the BSDs, which is arguably better than Linux as far as usability and security is concerned.
When you design a library you have to design a way to interact with it. Complaining about systemd because of that is basically saying 'I don't like the api you provide'.
People who hate systemd want traditional C API, systemd wants message passing.
If you don't like some of binaries, you can remove them and make your own package. If you don't like a particular implementation you can write your own subsystem that uses the same API (as many projects have done).
Basically its just people complaining that it does work exactly as they want, when in reality message passing is the exact right way to make system like that.
> In fact "the system is a single project" approach reminds me of the BSDs, which is arguably better than Linux as far as usability and security is concerned.
I've had this thought as well. The BSDs aren't afraid to go off and do their own thing, and it works for them. I feel like generally the Linux ecosystem is held back by reluctance to break free from ancient conventions and standards like POSIX and such, so I come into this systemd debate skeptical of arguments that it's not "the UNIX way" or that it's too Linux-specific or that it's stepping on other projects' toes, or that it's not the way things have been done before.
The systemd critics have legitimate criticisms which can be addressed through evolutionary improvements, but I don't buy the philosophical arguments that systemd is fundamentally flawed.
First of all, most of these systems are totally voluntary. You can simply not use them. And if you use them, you can replace them with other components that speak the same API if you want.
The binaries talk to each other with a message passing API and that is actually the proper way to make a replaceable component. This has been done quite a few times before for many different reasons.
1. you cannot not use them - the init binary doesn't gracefully degrade in the absence of the services provided by these APIs
2. the APIs are very complex and convoluted, with deep state maintained throughout the message exchanges; so complex it's effectively impossible to redo them without basically implementing everything exactly the same way
the fact that some binaries communicate through APIs doesn't mean the system is modular, if the "modules" of the system cannot be used independently for other purposes
Honestly, I much prefer systemd timers over cron. They work just like systemd units and shed all the odd special cases that cron accumulated over the years. They’re pretty well defined in how they behave in face of systems being down while a job was supposed to run (more a desktop thing, but relevant for some server cases as well). It makes sense to use the same config mechanism.
Still, systemd timers are exposed to the usual selection pressures: systemd the init does not rely on systemd timers. They’re a convenient addon that integrates well. But anything more convenient could replace them with no problem (as evidenced by cron still working on systemd enabled systems)
I concur with your characterisation of systemd as “doing one thing, and doing it well”. Those who seem to malign it most are those who are, for historical reasons, profoundly conversant with the myriad daemons, configurations, and init systems (generally) of “old UNIX/Linux”. They have a point and a genuine axe to grind, I’ll concede, but systemd is an enormous simplifier for those who are recent to the scene: learn systemd, and you’ve learnt how to manage (most) of your system at a very low level.
No it isn’t. Firstly: they weren’t the originators of systemd, they simply hired the guy who first developed it to continue developing it. Secondly: it: being open source and GPL, anybody can use it or fork it and not be due anything to Red Hat. Thirdly, it isn’t extinguishing anything as a business strategy; it’s just out-competing alternatives in the “mindshare” arena.
> they simply hired the guy who first developed it
If so, they aren't the originators, but it doesn't preclude them from using systemd to do EEE.
> open source and GPL, anybody can fork
While being OSS and GPL limits attainable power, controlling the development on ever changing software with increasing scope does yield quite significant power and makes practical forking quite hard if you with to remain compatible.
> out-competing alternatives
I remember distributions being forced to use systemd due to software dependencies and ensuing debacles. I think this might be classified as extend and extinguish.
> it being open source and GPL, anybody can use it or fork it
The entire point of the EEE strategy is to capture protocols or standards, such as software developed by other companies or free software developed under the GPL. Forking isn't a relevant option, because the other parties software is not changed (it's expected to not be able to change).
From Microsoft employee Ronald Alepin's sworn expert testimony[1] in Comes v. Microsoft:
Q. Okay. And now, again, for the Jury, what does embrace mean in
this context as used by Microsoft employees?
A. It's used to indicate a strategy where Microsoft will embrace
the standards or the specifications and interfaces of another
company's software.
Q. Okay. And what does extend refer to?
A. Once the specifications have been embraced, then Microsoft will
extend them and add additional interfaces proprietary to Microsoft.
Q. Okay. When you say add additional proprietary interfaces that
are Microsoft's, what impact does that have technologically to
other ISVs and OEMs?
A. Well, the result is or the impact is that what was once sort of
community development property, the work of the industry and
industry participants is appropriated essentially, is taken over
by Microsoft.
And then Microsoft takes it and with its proprietary extensions,
makes it essentially unavailable on a going-forward basis to the
industry participants who were responsible for first developing
the specifications and the standards.
Q. Okay. And when Microsoft makes those APIs unavailable to certain
ISVs and OEMs, what's the impact to those ISVs and OEMs of their
ability technologically to create products?
A. It reduces their ability to create products, especially products
that will interoperate with Microsoft's products.
Examples of this strategy include Mirosoft's attempts to capture the Kerberos protocol and Java. In both examples Microsoft first embraced existing software outside their control by writing their own implementation, then added non-standard features that were only available in their implementation and a clause in their EULA that forbid anybody that used their implementation from re-implementing the features in other (original) software. The GPL doesn't help here, because Microsoft never touched the original free/open implementation, which continued to exist but was now incompatible with Microsoft's software.
While the systemd situation is a little different (it isn't trying to take over "another company's" software, systemd de facto IS somewhat similar to the EEE strategy. They initially embraced existing open standards common in Linux distros, and then extended various parts of their implementation intentionally[2] incompatible changes that had the de facto effect of "reduc[ing] [the] ability to create [non-systemd distros], especially [distros] that will interoperate with [systemd]"[3]. It's not exactly EEE, but there are strong similarities with new features used as a barrier to interoperability.
Adding group SID's to an optional field in Kerberos was them using a standard to support their own system.
It was never incompatible with MIT or Heimdal. Those systems didn't use the group information in the optional field, but you could kinit and get a Kerberos ticket from a DC.
I know I'm not going to change your mind, but Kerberos isn't a good example.
Even if you grant some sinister motive on the part of Red Hat (which I do not), the analogy doesn't work. EEE requires some existing technology to embrace. Lennart Poettering built systemd from the ground up. And everything is open-source and done with the collaboration of the community anyway.
When upstream packages depend on systemd then other distros are forced to adopt systemd, which is a moving target. The goal is for everyone to just use RHEL to avoid the hassle.
E.g. Debian went systemd because they don’t have the resources to fix everything they get from upstream that requires it.
If that's the case, the strategy isn't working. The big-name non-RHEL distributions (Fedora/SUSE, Debian, Ubuntu, Mint) all run systemd by default. Users would have no reason to think that Red Hat would help them avoid any systemd-related hassle.
What's being embraced here is Linux and its standing as a preferred OS for running F/OSS itself, by wrapping everything into Windows-y abstractions (and .INI files even).
One existing technology Red Hat leveraged to achieve this was Gnome. A few years ago, the Gnome developers (many of whom were employed by Red Hat) decided to create a hard dependency on logind which was part of systemd. Other distros were mollified by being told that logind didn't really depend on systemd and they could just take it out and use it. Then, once that was safely ensconsed, Poettering declared that actually using logind without systemd wasn't supported, they shouldn't have done it, and he was going to completely break it. All the desktop distros were forced to abandon their own init systems and switch to systemd, with all the headaches and bugs that entailed.
Another technology they're using is to some extent the Linux kernel itself. The API used to create device nodes when drivers are loaded is undocumented and the only supported way to use it is udev; anyone else can expect to have their code broken by new kernel releases. That, in turn, is now part of systemd and using it outside of systemd is no longer supported. In effect, the only supported way of using the Linux kernel is with systemd and anyone else is on their own dealing with undocumented, backwards-incompatible changes that the developers have no interest in helping them with.
> A few years ago, the Gnome developers (many of whom were employed by Red Hat) decided to create a hard dependency on logind which was part of systemd.
Nobody was willing to maintain consolekit, the logind folks stepped up to provide a replacement and the gnome folks started depending on it. Everyone could have prevented that lock-in by maintaining consolekit or providing another replacement. Nobody did. To this day, tons of folks complain that gnome depends on logind.
ConsoleKit was a Gnome project which was abandoned when they decided to switch to logind. There was actually a fork of it called ConsoleKit2 for a few years but because everyone had to support logind anyway in order to support Gnome and systemd it was a second-class citizen that slowly died out. The distros shipped systemd+logind as default because that was the only option Gnome supported, and the other desktop environments did their testing with logind and let the ConsoleKit2 code bitrot because that's what all the distros used, and gradually it became less and less usable.
Nonsense conspiracy crap. Red Hat didn't even want systemd initially. The developers wanted it and basically just did it without cooperate actually backing the idea for a while.
But keep your lame conspiracy theory, it will surly get you much open-source street cred.
Yup. Reminder that RHEL 6 uses upstart. If this were a Red Hat conspiracy, why would they have switched from sysvinit to an incompatible competitor to systemd?
I think you are missing the point: Something like systemd has a good reason to exist. But the devil is in the creating team. We've seen pulseaudio, a good system in theory, but an untrustworthy unstable system in practice. And if it wont work, it is so complicated and non-transparent that you need a specialist. Taking a step backward from Alsa is hard, and they managed to do it.
Now that same team is messing with system critical stuff. We know from the kernel command line debug debacle they rather see the world burn down than admit they did something wrong. They are again creating a super-complicated incomprehensible half- documented mess, that puts it tentacles everywhere. But the stakes are a lot higher.
I am not saying they are incompetent. At a low level, the code works. But at a high level, something is very wrong. Bugs can be fixed, but arrogant architecture astronauts not listening to their users, messing with core infrastructure, that's where systemd keeps failing.
IIRC, they printed more messages to the console when booting Linux with a debug parameter than Linux could handle.
Systemd developers were like "nobody can tell us how much detail to print", until the kernel developers made clear that the boot console belongs to them and if systemd doesn't back down immediately they would take away all console access. Systemd then backed down.
So you are saying two teams maintaining two systems which are working together tightly had a conflict about how those systems are supposed to work together and resolved it after some heated discussion?
The amount of features and stuff they add to systemd is seriously impressive. They have bugs sometimes, but I have been running it in production for years and years and never had a real issue. Its an incredibly stable system. Sometimes a new version has a bug because systemd has to work in so many context, those get fixed very quickly generally.
I would challange anybody, to introduce a totally new system layer on linux with less issues.
And Pulse Audio was started by Pottering but he quickly moved on and since then it literally has nothing to do with the people who work on systemd. Blaiming him for the persistence of issues with Pulse is simply unfair and would be done if he was not called Lennart Poettering.
I think Poettering deserved his fair share of the blame for the problems in Pulse Audio. However, a guy writes an over ambitious project, has a lot of problems, has problems with interfacing with users, etc, etc, etc. This is the internet! Pick a random project an Github and you'll probably find similar issues. The real problem here was Red Hat -- and it was literally the same problem with systemd. They tied it so closely with the rest Gnome that you couldn't reasonably use Gnome without it. And since all of the distros were essentially riding on Red Hat's tail, everybody got strong armed into using this stuff before it was ready (to be fair, it was years and years and years before Pulse was stable at all).
I am not a fan of Poettering's code or his attitude, but people have treated him exceptionally badly. He's just doing his job. If these projects were allowed to compete for mind share fairly there would be no problem. If Red Hat had made sure that Gnome could work with alternatives then there would be no problem. Pulse audio would have died a rightful death. Systemd? I suspect that it would still have succeeded.
Agreed. This is Red Hat's mentality with a lot of it's product base. Poettering and Dan Walsh come to mind with regard to the elitist attitude in their respective corners. But just wait, this is going to get worse. Now that IBM owns them they will push this agenda even harder. The new game is controlling a majority of devs in well-known or strategic projects so the overarching enterprise can push an agenda. I don't think we're seeing the teeth quite yet, but give IBM a few years and my guess is it becomes very obvious.
Finally moving to an OS with systemd as the init system cost my team two months of platform stability. Every time we thought we had fiund the magic order or operations incantation and fire things up, we'd find a new poorly documented config item that had to be mucked with. Nothing so fundamental as starting a set of services should be that hard. SystemD has a few nice features but none of them are worth the headache. I applaud Knoppix for this move. I'm personally headed back to slackware, now that everything I work on is containerized anyway. SytemD won the war by persistence alone, not quality of work.
I hope that some of the other distros follow this move of Knoppix. I have had exactly the same experience with SystemD like you. The good parts of systems: standard simple format for describing unix services instead of shell scripts. Everything else they do is just crazy. The amount of CPU it uses also crazy.
> The amount of features and stuff they add to systemd is seriously impressive
That's exactly the problem, though. You don't want all that stuff in your privileged PID 1 process. Nor blowing up your prod servers and getting in your way to even examine log files afterwards.
> And Pulse Audio was started by Pottering but he quickly moved on
Which is pretty much what I blame him for.
He has a history of starting ambitious (maybe overly so) projects, doing all the fun stuff until it kinda sorta works, and then riding off into the sunset.
> We've seen pulseaudio, a good system in theory, but an untrustworthy unstable system in practice.
systemd has been out for so long that I'm pretty sure we can judge it by its own merits now. As someone who maintains a few thousand servers but only uses desktop Linux on one non-primary machine, I have a lot more well-informed opinions on the trustworthiness and stability of systemd than of PulseAudio.
(And besides, my recent experience of PulseAudio has been that it's fine, and IIRC in the late '00s the primary problem with PulseAudio was that Ubuntu ran it in a non-recommended mode. I haven't actually had any problems with it recently, it just works.)
It seems like the discussion would be more informative and less flamey if we talked about systemd itself. If the team is untrustworthy, there should be numerous examples of that about systemd itself by now.
IME talking with our sysadmins face-to-face, I think a lot of the initial hostility was caused by emotional reactions like: This is different, I don't like it! (Don't get me wrong, it's a behavioral pattern that makes sense up to a point.). I think everybody I've spoken to actually ends up appreciating a lot of things about systemd. (But in these situations, I happened to be their employer, so that definitely biases the conversation even if these conversations weren't really about anything related to their job situation, specifically.)
I also get the impression that a big part of this is due to a lack of 'patterns' or easy recipes to get as much info as possible from the journal. Everybody can intuit the workings and benefits of a text file, but text files have drawbacks that are very subtle and hard to intuit at a visceral level. I think this is partially a lack of good defaults for journalctl. I think it would be better if it (by default) showed much more information and allowed users to turn off unwanted info.
Pulse has been fine for ... I dunno, a decade or so now. I remember when it was problematic, and then one day I discovered I could do things like send sound to other computers, control different applications independently, turn on bluetooth headphones and just have them work. All the sort of things you'd expect a modern sound system (which ALSA certainly is not) to be able to do without having to edit configs or whatever.
Pulseaudio is definitely better at what it does than ALSA, it is not a step backwards.
Unless you use your computer for more than just consumption and you find out that latency wise pulseaudio absolutely sucks. And then you install jack, a bridge from pulse to jack and a whole raft of other fixes to be able to use the same desktop for regular work and audio work.
My main gripe with anything from that group of people is that they refuse to play nice with others, and by extension that their code refuses to work properly with code produced by others.
This is just my own experience, but sound works fine for me with just Alsa (no pulseaudio or apulse). Although even the Arch Wiki [1] says differently.
Pulseaudio is in the same park as SystemD today. It works as long as you don't demand too much of it and don't stray from whatever they deem to be The True Path. It is better for your simple needs. Believe me, those who have advanced professional needs don't think highly of it.
The support for this systems come from people that just use it as packaged and don't have specific needs. Which would be fine IF they weren't getting in the way when you really have specifics needs.
Even if some of the concepts are sound, execution is terrible. As the saying goes, the road to Hell is paved with good intentions.
> does ONE thing and does it well: it manages the system
"managing the system" is not "ONE [problem]". A big part of the problem with systemd is this presupposition that management of something as large and complex as a modern OS is a single monolithic[1] problem.
> it's complex because it does a complex work.
See, you agree that it's a complex problem! It's so complex with so many different use cases it isn't even possible to have one solution, because some of those use cases are mutually exclusive. Hench why a modular design is important, so it isn't too difficult to replace the management of different areas if needed.
> It's the missing layer between kernel space and user space.
That "missing layer" isn't well defined. There certainly wasn't any "missing layer" on my old server, or the compute boxen we used at ${research_lab}.
If you're talking about desktop system, I agree that there was a gap between traditional system management and the GUI, but that isn't really a new "layer" between kernal and user space (it might involve GUI userspace programs with perhaps some of them being SETUID or a privileged daemon).
[1] Any objections trying to claim systemd isn't a tightly coupled, monolithic design will be ignored. If you think the number of binary program files is in any way useful as an objection, see: https://news.ycombinator.com/item?id=19024256
You still have s6, openRC etc. as choices, but it's funny that nobody of the anti-systemd folk was willing to pick up the work needed to maintain consolekit, yet when logind came around, had lots of strong things to say.
How about picking up the work as well?
And none of the alternatives seem to really get away from the bash script paradigm & more towards the declarative side of things, which doesn't feel like much beyond keeping all that was terrible about sysvinit around in thin wrappers.
> nobody of the anti-systemd folk was willing to pick up the work needed to maintain consolekit
Why would I want to start working on software I don't use or need? Why do systemd advocates always insist that every implementation must include the features they think are important? The entire point of designing for modularity is that different people have different requirements; operating systems cannot be "one size fits all".
> yet when logind came around, had lots of strong things to say.
Yes, we had strong things to say about software requiring logind, because it is a terrible (and poorly documented, at least at the time) design. If you want to use logind, go right ahead, that's your choice. We were (and are) only angry about software that we used to be able to use adding dependencies to logind (or other systemd components).
> And none of the alternatives seem to really get away from the bash script paradigm
That probably won't happen, because shell scripting is the easiest/simplest solution for certain types of problems. Some of us have tried a lot of variatio9ns, and keep returning to openrc/bash because it's easier and has fewer problems, at least in some situations. However, on a traditional system (or openrc) nothing is stopping you from replacing the bash init scripts with another language or replacing the entire init subsystem with something else (like upstart, s6, something new?). The complaint isn't that your should use my favorite tools (like bash) instead of systemd; it's that we should strive for modular software so we can all use the components that work best for our different needs,
> Why would I want to start working on software I don't use or need? Why do systemd advocates always insist that every implementation must include the features they think are important?
If you don't care about multi-user session management, sure, but considering practically every window manager/DE relied on consolekit and now logind to provide that functionality, I find it hard to believe it's not desirable by a large majority of users, some of which would belong to the group I was talking about.
I love how people who are obliviously not the target audience feel the need to chime in.
> Yes, we had strong things to say about software requiring logind, because it is a terrible (and poorly documented, at least at the time) design.
I agree about the lacking documentation, but in terms of design it seems quite solid. Any technical specifics as to why it is terrible? It's interesting that systemd's detractors always seem to be rather vague in this regard, makes me suspicious as to whether they did more than have a knee-jerk reaction to a tool that is different than what they used before.
> because it's easier and has fewer problems, at least in some situations
Am going to need specifics, because in my experience, the bash scripts always ended up being a hot mess of variable quality as per the individual author's scripting skills with inconsistent behavior across scripts.
Not to mention that none of the alternatives give me the functionality I want, because their authors strictly focus on the init part, whereas systemd's much more useful even after the system is up and running due to its event driven nature.
Now I realize that not everybody needs some of the extra features, but for those of us that do, (like container management), s6, openRC etc. is even less of an alternative in a real sense.
> nothing is stopping you from replacing the bash init scripts with another language
The init system needs to be designed to support declarative services from the get go, am not simply talking about using Perl instead of bash here, am talking more along the lines of the Nix vs apt paradigm.
> or replacing the entire init subsystem with something else
And is something stooping you? This is my biggest gripe with the anti-systemd crowd, am personally happy with systemd, so it's not me who needs to look for alternatives. It's you. And there are plenty, so please pick one that suits you. The constant anti-systemd bashing every time the name is mentioned from people who seem to barely know much about what it's trying, (rather successfully), to do is rather annoying.
Not many users care about multi-user session management. An even tinier number of users care about multi-seat session management (which is when you have mutiple users on the same machine at the same time, with their own screen and input devices). Pretty much every desktop Linux user cares about being able to click options like "shutdown", "restart" and "suspend" in the user interface and have them work.
As it currently stands, anyone who wants that basic functionality on Linux - something that's been supported on all other platforms since forever - has to drag along all the baroque undocumented complexity of multi-seat, multi-user support. Why? Well, it seems Red Hat has some customers who sell solutions based on that, or at least used to once upon a time... With the current price of a docking station used to support a single seat in such a setup being comparable to that of a fairly decent refurbished SFF PC, I can't see a huge market for this.
I like the ranting about "multi-user" support in Linux. Coz hey let's all return the Windows days of "the user is always running as super-admin". What could possibly go wrong with that?
> The constant anti-systemd bashing every time the name is mentioned from people who seem to barely know much about what it's trying ... to do is rather annoying.
The constant misrepresentation and/or refusal to address the actual "anti-systemd" complaints by systemd advocates is also rather annoying.
> makes me suspicious as to whether they did more than have a knee-jerk reaction to a tool that is different than what they used before.
Resorting to accusations of incompetence only add toxicity to the discussion. You'll have to take my word for it, but I assure you I know what I'm talking about.
> but considering practically every window manager/DE relied on consolekit
Mine doesn't. Some of the special-purpose computer's I used to use didn't use a window manager. These may be uncommon use cases; so what? They solve the problems they are supposed to solve without any unnecessary overhead.
> I find it hard to believe it's not desirable by a large majority of users
So only popular need should be supported? The entire point I'm making is that there are many different reasons people use computers, including many that are unique or almost unique. I may use an older window manager, others might prefer to use consolekit or logind, someone else could be interested in developing a totally new post-window-manager design that doesn't even use metaphors like "desktop", "windows", "sessions", etc. All I'm arguing for is the freedom choose any of those options, which includes variations where consolekit isn't used even if it is used in popular configurations.
The alternative is to argue that one design must be used everywhere, even when it is inappropriate or unwanted.
> in my experience, the bash scripts always ended up being a hot mess
I disagree, but you're welcome to your own opinion. If other software works better for you, then great, use it. I'm not trying to convince you to write bash scripts; I'm trying to explain why a single "one size fits all" design isn't possible, because we may be trying to solve different problems or prefer different tools. If systemd wasn't tightly cou0led and instead played nice with the rest of the systemj, we simply replace parts of it when necessary and we wouldn't be having his argument.
> Not to mention that none of the alternatives give me the functionality I want
Which is why I want you to have the freedom to use the tools you prefer to use, even systemd. Shouldn't other people have the freedom to made different choices?
I think that you are missing the point. I was quite happy without systemd. What work has to be picked up really? You are trying to make it sound we could not live without systemd and we must replace the systems. If you want to write a better init system, go for it. Many people tried and succeeded none of them became the standard for linux (partially because there are no standards in linux).
As I said in other comments, if you want to replace inis scripts with systemd format service descriptors I will support your efforts becuase using shell script is broken. If you in the making of replacing init with something better also replace logging, ntp, dns, dhcp and a bunch of more then I will say no. This is exactly what systemd does. Rewriting rock solid, CPU efficient code with something shaky and CPU intensive. No thanks.
>>> And none of the alternatives seem to really get away from the bash script paradigm.
Good for you then. I am sure you were happy with X11's rotting core & didn't need Wayland in your life, you also likely weren't the one having to maintain its decades old codebase.
> If you want to write a better init system, go for it.
Am personally happy with systemd, thanks, if you're not, why don't you go ahead and write a better one, instead of complaining every time systemd's name is mentioned?
> This is exactly what systemd does. Rewriting rock solid, CPU efficient code with something shaky and CPU intensive.
That doesn't seem factual. systemd is a system manager, useful even after the system is booted up, I think people need to understand that first, it's not just an init system, because many modern services fit an event driven model these days. It's written in C and can run fine on tiny embedded systems.
> Factually incorrect. There are many init alternatives that got away from the shell script paradigm. Including SMF in Solaris.
Yeah, and launchd on macOS, by which systemd was literally inspired by, we're talking about Linux here, since that's where systemd runs, at least I was.
Hence it's pointless because it doesn't make things any simpler. All it does is making things monolithic and wrapping concepts that are perfectly fine by themselves, forcing third-party software to write to systemd's APIs.
> Systemd actually does ONE thing and does it well: it manages the system.
"Managing systems" is not what is meant by "doing one thing, and doing it well". Systemd takes over init scripting, logging, host names, IP, time, locale, and login, plus tens of more services. Making development of this software a Lennart Poettering/RH-only business rather than community-driven.
The trend to get rid of systemd and its metastasis into most of Linux is excellent news. Note that Slackware and Devuan are also systemd-free (and have been from the beginning).
As an end user, meaning a web app developer, I actually like systemd a lot. I perceive the software quality to be good enough. I've used it in production since 2014 and encountered zero bugs. It does seem to me to be vastly simpler compared to the old way of doing things.
I don't really feel strongly either way. I'll be pretty sad if Debian and redhat diverge.
I don't know what you're doing to start your web/app server, but for eg. apache httpd it's a matter of
sudo apachectl start
(and likewise for all SysV-like startup scripts). For node, it's
node <yourapp.js>
(or rather using node-forever or node-cluster in prod). If you want to have it started on boot automatically, you put that line into your startup script. It doesn't get any more simple and transparent than that.
Why would you be sad if Debian and RH diverge? Linux started as a one-man show and became a huge community effort because it could run a wealth of F/OSS software. If you want a single-vendor OS, there's Windows, Mac OS, the BSDs, and others. Or maybe IBM RHEL in the future.
If you do `sudo apache start` in production, how do you do it? Log in to the server and type it in?
What about log and metrics agents, how do you start and configure those?
Also why are you so judgemental? I don't want Debian and rhel to diverge because I have clients who use both and I don't want to have to do more work to support both.
Sorry I didn't want to sound judgemental. My point was that your argument, taken to the extreme, undermines having multiple Linux distributions in the first place. Which is exactly the embrace-extend-extinguish aspect being talked about elsewhere in this thread.
I just can't conceive of how init could be extinguished, or how life would be worse in any way for me if I was never forced to deal with init again. What's the bad angle? Do I actually have skin in this game I didn't realize?
Edit: I am super duper cool with having multiple Linux distributions. I am just not really excited about being forced to interact with vastly different distros specifically in the course of doing my job.
how do you make sure it's done at boot? what if the machines boots up unattended, maybe after a power loss? and where do you put the apachectl binary? And what would happen if for any reason apache crashes? will it stay crashed? will something restart it? if so, what thing will? and what if you need to run it in a restricted environment (let's say something easy, let's say a chroot) ? and what if you want to have upper limits to the resources that it's supposed to use? how do you check if it's running, and how much resources is it consuming ?
Systemd units make all of those things trivial, or at least not that hard.
And that is exactly the marketing card that have been played. The dev out numbers the sysadmin and ask for SystemD. Then it's to the sysadmin to live with the numerous bugs and non-standard and hardly documented ways of the Beast.
Yea, sysadmin is a shrinking job field. Dev ops is eating heavily with what they used to do with config driven management of servers be it kubernetes, docker, terraform, puppet, etc.
Some one is administering the system. Whatever its title. The grip I hear from those who _do_ (and I agree with them) administer SystemD servers (note I did not say desktop here) is that when it fails, it is often very hard to debug because of too much implicit and hardly documented.
"the system" is shrinking. Our ci/cd, logging, monitoring, and alerting infrastructure is outsourced, our databases our outsourced, and our apps are deployed on stateless vms, a couple steps away from a managed container platform as a service. The only reason we aren't all in on container platform as a service, is because we support clients who deploy on vms.
I mean, this is a laughable point. Like, seriously ? Before systemd every branch of the linux distro tree had its own way of managing stuff at startup, and distros in the same subtreee made things different enough that things like inits-cripts were not portable.
Heck, even with the same init system, some distros arranged runlevels differently. Do people even remember runlevel? Those were another complete way of mess things up.
Are you really playing the "non standard" card? Like, for real?
And seriously, what would be the standard? The Single Unix Specification? According to that spec even bash is not standard, and yet it's the de-facto standard for shell scripts across basically all the major distributions.
Simpler for simple things, which is great when it works, but more complicated for more complicated work, which is simply unacceptable when it prevents you from controlling the system. Good old bad design that matters more as you scale up. It isn't the point of systemd that is the problem, it is this particular case of horrible design.
Can you give an example of something more complicated in systemd? If I ever had to do anything like that, I would just do it in a different layer, like have a simple systemd unit pointing to a complicated init script that contains the logic.
Well yeah, you would have to. Might as well use initv then. That's the point. At least then you can debug and not have a black box you can't really see into. It is horrid design. Hacker News is getting worse, same thing horrid design . Horrid design is caused by the goals and abilities of the designer clashing with the goals and abilities of the user, and when designers are selfish and want ALL the control the product if useful to less and less people over time. Happens a lot because often the design goal is a hidden desire to wall off functionality to reserve it's usefulness to a select group deemed worthy.
However it's slowing changing. Knoppix has always been seen as a trend setter, and it still has a large influence where it matters - open source maintainers that are not corporate-driven (i.e. Debian).
Knoppix hasn't been seen as a trendsetter in an extremely long time that I know of. I remember it being a big deal before live CDs became a thing that everyone did, but that's about it.
> Hence it's pointless because it doesn't make things any simpler.
That is exactly my opinion too. Systemd managed to replace the nasty cruft pile that was SysV init with something even less transparent, more confusing, clunkier to use, and with a steeper learning curve to do simple things like add or change a system service.
There is too much to list, but let's start with the beginning: why name one of the most commonly used commands (for admins) on the system 'systemctl', which is even harder to type fast than 'service'?
That kind of total disregard for UX pervades the whole design. Its like no thought was paid to it at all. Everything is obtuse and clunky with long non-memorable names that give you carpal tunnel syndrome to type.
Most of the things you mention are side-components of systemd, not core stuff.
You could change the hostname the old way by just go ediding /etc/hostname or using the hostname command (or both). hostnamectl merely exposes you a handy command to do this in a consistent way across distributions.
One could probably take systemd, dropp all the non-init components and make it a minimal init system.
As an end user I don't mind SystemD for writing / managing service unit files. I often find the restart policies and one time only jobs useful especially in cloud with automated deployments. My feelings on SystemD as end user are neutral, it does have some useful things but I understand some of peoples grievances with it.
On the other side I have some OpenBSD systems and the simplicity of OpenBSD service management just being plain bash files is really pleasing to use if anything because of the simplicity and power/functionality it provides without actually doing much itself.
No, systemd does many other things than just managing the system. It provides time, dns, dhcp and other services. None of which is required for achiving what it is suppsed to do: managing unix services.
It manages the system in a way that not everybody needs or even likes. To the people who hate it, it solves problems that other people have but brings new problems that they now have. It's not so much about if it's good or bad but more about whom it was made for.
It has it's place but it doesn't work for everyone.
I mean,there's something called user-acceptance testing for software dev lifecycles right? (Not a pro dev myself) systemd obviously has an issue being accepted by a lot of users even after almost a decade now(?)
Even before systemd there were other init systems used by different distros. The fact that systemd demands other things to adopt to it instead od smoothly integrating with existing systmes is one pain. A bigger pain is how it is expected to work well for everyone. I mean, dislike for "one size fits all" solutions is a major reason why most Linux users became Linux users.
I used to be a sysadmin. I still hate systemd, and think a lot of who like it are suffering from Stockholm syndrome (joking, maybe :)). It's not that I don't understand it, or use it, because I've been forced to for years. It's that it made everything about my job harder, and abstracts or attempts to abstract everything. As an end user, I get liking it. It's fast, and mostly works. As a person who likes to poke and prod, it's a gross nightmare of inconveniences.
No, really. I, the system administrator, manage the system(s). Does Systemd make my life easy ? No, again. It's something I have to deal for. If I could, I would follow the example of Knoppix.
It's okay to flaunt your ignorance if you can claim that your peers are ignorant as well, I guess. Knoppix was one of the first, if not the first, popular live CD distributions.
The other day at the office, I was the only one that had heard of, let alone used, Slackware. I am also the oldest in the team, this is probably no coincidence.
I have worked at more than one place where I was the only one who had heard of Linux. I skip paraphrasing the 'let alone used' part, for of course everyone was using it in their routers and phones and proverbial toasters.
It is my clear impression that many Windows users would be hard pressed to explain what 'Windows' is and does.
Oh God. I've embarked on a project to try to relearn how Windows works again, and I'm actually having a terrifying time of it.
I"m starting to realize where so many holes in my understanding exist, and abhor how for so long I was just content to accept most things in Windows just happened.
Then I started actually digging into log files and various software distro's and tried to connect all the dots.
Long story short, nothing scares me more now than a computer program that I can't explain why it's doing what it's doing. SystemD falls into that trap for me. It may just be a case of sitting down and reverse engineering it until it clicks, but until then, I'd rather not trust anything important to it.
I started my Linux journey in ~2002 with Slackware to get ipchains ip masquerade (nat) working for multiple machines to share a modem connection. Today I prefer Arch or Debian but Slack will always be that first that popped the cherry.
No, actually it isn't straightforward. There a lot of artificial dependencies that you can't break. I mean, conceptually it's not difficult, but in practice it is.
>There a lot of artificial dependencies that you can't break.
You still need libsystemd0 which is a compatibility library. It's actually unfortunately named, as it isn't part of systemd itself.
I've been using sysvinit on my Debian workstations since systemd became the default. It takes me about 5 minutes to switch a new system over (admittedly I don't use Gnome or KDE). The stackexchange thread you linked is out of date and switching is getting easier. I recommend following the debian-init-diversity mailing list for further info.
I've been professionally maintaining large deployments (thousands of machines) using systemd for years now, as well running systemd on my Linux desktop for as long as upstream has defaulted to it, and I can't recall a single bug or a single negative business impact from tying too many features together. I recall on multiple times wanting to upgrade but I'm pretty sure it was always because I wanted fancy new features, not for a bug.
(That's not to say systemd has no bugs. I expect it does. We either just didn't run into them, or we tested whatever complex thing we wanted to do—far more than could be expressed in any other init system, process keeper, or systemd competitor—found it didn't work, and moved on. That would be indistinguishable from systemd intentionally not having some fancy feature, and it definitely didn't affect us in production.)
Meanwhile, I can remember numerous concrete bugs in the Linux kernel, concrete misfeatures, and downsides from having a monolithic kernel where if one thing goes south everything does. But nobody warns me to avoid Linux....
Well, systemd is great for responding to events (like devices and networks going up/down) so it seems like a good fit for embedded/IoT. If anything it'd be bad for servers since those are (usually) basically a couple of services and daemons brought up at boot and not changed during runtime, with a few interfaces that never change.
Systemd is not that heavy to run when configured correctly (which is what the distro should do).
The fact that we're still having _this_ conversation, after after a decade since being released and years after mass adoption, should say a lot. I can't think of any other software I have to use on a daily basis that gets so much heat, every time it comes up. One can make all the arguments for it they want but the continued public comtempt means something.
The list in the Linux desktop world is honestly pretty long and could be extended at will. Some examples:
Wayland, GNOME 3, KDE Plasma, Nvidia drivers, PulseAudio, DBus
Wayland is nearly vaporware, gnome 3 is optional, kde plasma is optional, nvidia drivers are optional and have functional FOSS replacements, pulse I'll grant you (and hope you see the irony) and dbus I can't honestly comment on because the little direct interaction I've had with it was fine but mostly I don't think about it. The flaw with your list is that half of it is optional and anyone who doesn't like those things doesn't have to use them. My daily driver is xfce on xorg.
Two of the three components in your list that are mearly mandatory came from the same engineer. Why we do we keep accepting his code?
FWIW, the desktop world is less important and I run Linux as a desktop. The nightmares I get from systemd are all about my servers. If we could have left servers alone, people like me wouldn't even have cared. As it is, I have to get out the kid gloves when I'm dealing with my service platform because Bad Decisions are now system standard.
Fedora has been defaulting to Wayland on fresh installs for at least two or three releases and generally it’s working okish. There’s still a lot of software lacking proper wayland support, though.
Perhaps it's just me but I haven't found an xorg problem in my life that's fixed in wayland but I've had a few problems in wayland that don't exist in xorg. My display needs are rudimentary though, so perhaps I'm not the target audience.
Putting wayland aside... is exactly what I've done. I don't need wayland, so I don't use it. With systemd, not only do many of us have problems but we don't really have a choice. I could run my world on Slackware but then I'd be a SPOF (much like systemd) and that's a bad way to build architecture.
Haven’t tried screen sharing, but wayland does fix problems. Mixing HiDPI screens and regular screens (think: laptop/desk screen) without having lego-block-sized pixels on at least one of them. Sadly apps without wayland support don’t support that properly yet.
I on the other hand have had good experiences on servers with systems. The services system has most of the basic needs for simple applications in a common way. Compared to init.d where everyone was rolling their own script in absurd ways.
Why do you think Wayland is vaporware? The concept, protocol, reference implementations are clear, done, the development of protocol extensions are chugging along nicely, and clients are shedding their legacy layers year-by-year (release-by-release). It was never going to be a quick and dirty hack.
Sure, you can use XWayland and just call it a day, but that doesn't really help.
The reality is that exactly due to the enormous legacy baggage of the "X ecosystem" it's not easy to just switch "to Wayland". GTK, Qt, and (again, due to the required hacks) all major apps (eg. Firefox) have to do serious work (as in finally implement something sane, now that it's an option) to work.
DBus is okay. Though bus1 might be an improvement, and having it in kernel would be a bit more efficient (zero copy, better security, etc).
> One can make all the arguments for it they want but the continued public comtempt means something.
It means that Linux community is full of people that refuse to give up on their gripes even after years. Those also tend to be the people who refuse to understand that "the old way" might not be the best way to do something and also fail to produce a viable alternative.
Linux audio was not usable for end users until PulseAudio stabilised. Init based on scripts was a trash fire. And yet, although SystemD and PulseAudio aren't perfect, noone managed to produce anything comparable except pages and pages and pages of whining.
These people need to let it go. This toxicity is unhealthy and it's just damn software.
The inability to let is why we also have an insane number of distros that continue to fragment Linux. While diversity of ideas is good, it kills user adoption by anything other than techies.
Been using systemd since whenever it became the default on Arch. I love it. It just works and I've never had any problems with it. I'd rather use it over any arcane bash-based system any day.
When I want to write a script that runs on startup, I expect that I can just put (or link) it in some directory where the scripts are that get started on startup. Or that there is one main script that calls all scripts that are intended to be startet on startup.
I do not want to write a "service" that has some "only run once and then discard" flag or whatever.
When I want to look at logs, I want to use the tools I like. less, grep, tail etc. I do not want to dabble with some binary format and its tooling.
When I want to start or stop a service, I want to call a script that does that. A script which I can look at and see what it does. Like /etc/init.d/apache2. I do not want to execute some magic command like "service apache start" which I have to guess or look up and which gives me no clue about what it does.
But there have been reasons given. They want to use standard tools to deal with the log. They want to see the scripts that manage the system and poke around in it, which has the implicit reason to learn about the system and being able to easily modify it.
> They want to use standard tools to deal with the log.
I have a little sympathy for this one as an old habit if you don't know any better. It's also an extremely inefficient way to work with logs. If you've used a system like Splunk seriously, the idea of going back and grepping through logs on a host with the shell is just frustrating.
> They want to see the scripts that manage the system and poke around in it, which has the implicit reason to learn about the system and being able to easily modify it.
I have no sympathy for this one. Scripts are a terrible place to define policy. They are nigh impossible to audit. They are brittle. They multiply complexity by making everything a special case. They make integration of different parts of the system nearly impossible.
Aren't systemd units simple text files with no hidden magic? In fact, all systemd configuration is plain text files and symbolic links. The only binary format is the journal.
> Aren't systemd units simple text files with no hidden magic?
Compared to something like a shell script, systemd unit files are magic because you have to know a lot about how systemd works to figure out how your config file translates into actual behavior.
Whenever systemd comes up, someone appears to counter any criticism with words suggesting you'll get left behind if you don't follow us. No justification beyond that.
Heck I hadnt used Linux for a few years and when I got back to it systemd was on every distro I use. I just use it. I dont see the big deal. I grep the piped output of services if I want to narrow things down more just as you would the output of cat or ls or anything on Linux.
> When I want to write a script that runs on startup, I expect that I can just put (or link) it in some directory where the scripts are that get started on startup
This is not very specific, have you never had any race-condition with this? There is a reason SystemD ask some informations regarding the service that needs to be launched. I don't see how ignoring those makes a good argument against SystemD.
I think my issue what binding Consul to docker0 while Docker is starting. Half the time the interface wasn't ready. I don't remember exactly how I fixed it but with SystemD you can just specify a dependency.
Hardly. I'm an OpenRC user. Booting OpenRC vs SystemD, desktop, server, VM. Near zero difference in boot time, neither side was a clear winner, nor always faster.
My favorite part is OpenRC still likes the old ways, has script extensions for new ways, and runs the same path every time.
That's just anecdotal. If it's a technical fact that SystemD does parallel upstarts where OpenRC for example does not, that just means you don't have a system where parallel upstart makes a difference.
They mean that you can specify dependencies. So start some service Y only after X has been started. I use this extensively in my home automation services. Can't start other services if the MQTT-Server hasn't started and that isn't done until the network is initialized.
> A script which I can look at and see what it does. Like /etc/init.d/apache2. I do not want to execute some magic command like "service apache start" which I have to guess or look up and which gives me no clue about what it does.
Interesting. I feel the other way. Unix failed to provide a real service management system early on, so we have layers of historical cruft (Fork, close all descriptors, fork again, escape process group? Really?), and ended up with all kinds of absurdity in shell scripts to handle it.
The right way is to have a strong system contract on what constitutes a service, and have no wiggle room so that 'service apache start' does a fixed, known thing.
Sadly, systemd has to support all kinds of legacy hacks. A nice way to chart a way forward might be to define a simple contract and require someone to mark a unit file as "legacy" to enable the other possibilities.
> When I want to write a script that runs on startup, I expect that I can just put (or link) it in some directory where the scripts are that get started on startup. Or that there is one main script that calls all scripts that are intended to be startet on startup.
AFAIK, systemd is compatible with sysv init scripts.
> I do not want to write a "service" that has some "only run once and then discard" flag or whatever.
Why? Writing one isn't so complicated.
> When I want to look at logs, I want to use the tools I like. less, grep, tail etc. I do not want to dabble with some binary format and its tooling.
Well, nothing prevents you from piping output from journalctl to whichever tool you prefer. In fact, people do it all the time.
> When I want to start or stop a service, I want to call a script that does that. A script which I can look at and see what it does. Like /etc/init.d/apache2. I do not want to execute some magic command like "service apache start" which I have to guess or look up and which gives me no clue about what it does.
I don't see how sysv init is any better than systemd in this regard. You'd still have to look at indidual scripts to see what it does. It's not like systemd hides the contents of the service files.
So I take it you've never used journalctl then at all? Because seeing as how it's default behaviour is to use the system pager, which on any system with `less` installed is less, I'm somewhat at a loss as to what you can't do with it that you can with files now.
Has anyone here used knoppix (or any other dedicated Live CD) recently?
In the early 2000's, distros didn't have live environments bundled. All debian used to have was a TUI installer and that's it. Ubuntu 4.10+ introduced a live sessions.
From 2004-now driver support and hardware detection has gotten much better. There are live session CD's that include "nonfree" drivers that further improve hardware support. You can pop in most popular distros and easily connect to WiFi and mount drives, often just as easily as knoppix did.
This complaint about systemd isn't a user-related, but the perspective of the live cd creator. Maybe it's true systemd doesn't help that case, but would systemd get in the way of a live cd user though? They're likely not going to be adding/removing/starting/stopping services, setting up users/groups, or anything else that'd be done in a permanent environment.
I wish voidlinux gained more attention from the community and got adapted to serious production stuff. It has all the good elements on paper except the maturity and user base.
If production is servers, then alpine is the better choice as it provides stable releases.
Void Linux is a nice desktop system and you can run it on single servers you personally take care of.
But I would rather not use it at scale for servers as updating rolling release can always lead to issues and not updating will leave security issues unfixed.
The one benefit would probably providing a glibc version if you require it.
I always considered Alpine to be that slim OS image that is used as Docker containers. I have never considered it as a serious bare-metal host. May be it is indeed better than void for that purpose.
I wrote about void because it “felt” like the philosophy of BSDs in the Linux land. Which is quite a draw for me. Binary packages, up-to-date kernel, and a sane init system felt fresh and in KiSS realm.
> If you want to start your own services at startup, you do not need to create any systemd units, but simply enter them in the text file /etc/rc.local, which contains explanatory examples.
Okay, but doesn't that remove a lot of functionality that is available with systemd units? In this whole systemd debate, I've never seen a really clear outline of how much complexity systemd covers, and whether the older alternatives were actually simpler or not. Granted, I haven't looked very hard. I use systemd with Arch and have no known issues with it.
I am a bit surprised that they (seemingly? not clear in the article) went back to sysv init rather than exploring other options. I assume they just wanted to go back to something with which they were very familiar (and for which they probably already had scripts). But after going to void linux, I've found runit [1] to be an excellent init system. I was able to sit down and read the documentation in under an hour and understand exactly how it works and how to add my own services (which is fairly trivial). The programs also seem very thoughtfully developed, taking into account specific circumstances and signals. I encourage others to take a look if you're interested; I believe a number of modern distros have support for using it rather than systemd (I know at least Arch does).
Knopper wrote his own init system called "knoppix-autoconfig" according to DistroWatch. [0] That information is not included in the release notes, though.
> Knoppix' Startvorgang läuft nach wie vor per Sys-V-Init mit wenigen Bash-Skripten, welche die Systemdienste effizient sequenziell oder parallel starten.
> Knoppix' boot sequence still uses Sys-V-Ini, with some bash scripts which start the system services efficiently sequential or in parallel.
So it has still all the downsides of sysvinit, except that might start sevices in a more efficient order or some in parallel.
I wish systemd would just die a fiery death. Every two years I replace my environment - by design, to force growth. I've been doing this on Linux since 1993. In my most recent go-around, I hunted for a Unix distribution that could meet my needs, and played with: Void, Solus, Manjaro, Fedora, Tumbleweed, TridentBSD, and GhostBSD. Heck were there docker support on *BSD I'd be back there happily for the first time since 2001.
SystemD needs to die because it violates Unix principles, not because of it's new key combinations. Unix is built on the notion that everything is a file, and that purpose built binaries make sense. SystemD breaks the latter - meaning it's now significantly more work to do the same things when it comes to log investigation, service analysis, and related events.
Perhaps the worst part is the extension of a subsystem for service initialization to everything other than that. The folks at suckless (https://suckless.org/sucks/systemd/) did the argument significantly more justice than I ever could.
190 comments
[ 4.7 ms ] story [ 243 ms ] threadThen I took a course on systemd specifically and it opened my eyes, and now I'm quite fond about it.
Systemd actually does ONE thing and does it well: it manages the system. It's the missing layer between kernel space and user space. It has quirks and bugs like all software, but I think it works very well, all things considered.
To those who say that it's complex and does a lot of things: it's complex because it does a complex work.
Knoppix is a live system, so all of the things systemd was designed for don't apply. I guess it can make sense for their knoppix's use case.
Knoppix claim to fame is automatic configuration. If your Xorg or sound was giving you grief after a fresh install, you'd live boot Knoppix and copy the configuration files back to your installation.
From this p.o.v. it makes sense for Knoppix' use case, because, as stated by Klaus Knopper: "This bypasses systemd's interference with many system components and reduces the complexity of the overall system."
Is it really so? I would expect all distributions to have stolen that feature by now. Xorg works out of the box basically everywhere. I've had a glitch with a microphone on a 3-pin jack on a Ubuntu system, and I doubt Knoppix would have known that a modprobe config change was needed.
The problem is that it comes bundled with a whole bunch of other tools for handling networks, cron, ntp, etc which really ought to be separate projects. By bundling them with the successful init system they're not exposed to the usual Darwinian selection processes that shake out the best free software.
That they're part of the same project is actually a win for me, it helps to make the various components work well together. Also there is a common thread or philosophy in how things are built, making learning easier.
In fact "the system is a single project" approach reminds me of the BSDs, which is arguably better than Linux as far as usability and security is concerned.
https://news.ycombinator.com/item?id=19024256
People who hate systemd want traditional C API, systemd wants message passing.
If you don't like some of binaries, you can remove them and make your own package. If you don't like a particular implementation you can write your own subsystem that uses the same API (as many projects have done).
Basically its just people complaining that it does work exactly as they want, when in reality message passing is the exact right way to make system like that.
I've had this thought as well. The BSDs aren't afraid to go off and do their own thing, and it works for them. I feel like generally the Linux ecosystem is held back by reluctance to break free from ancient conventions and standards like POSIX and such, so I come into this systemd debate skeptical of arguments that it's not "the UNIX way" or that it's too Linux-specific or that it's stepping on other projects' toes, or that it's not the way things have been done before.
The systemd critics have legitimate criticisms which can be addressed through evolutionary improvements, but I don't buy the philosophical arguments that systemd is fundamentally flawed.
No, they can't. The fact that they're compiled into separate binaries doesn't mean they're independent - they're completely dependent.
First of all, most of these systems are totally voluntary. You can simply not use them. And if you use them, you can replace them with other components that speak the same API if you want.
The binaries talk to each other with a message passing API and that is actually the proper way to make a replaceable component. This has been done quite a few times before for many different reasons.
2. the APIs are very complex and convoluted, with deep state maintained throughout the message exchanges; so complex it's effectively impossible to redo them without basically implementing everything exactly the same way
the fact that some binaries communicate through APIs doesn't mean the system is modular, if the "modules" of the system cannot be used independently for other purposes
Still, systemd timers are exposed to the usual selection pressures: systemd the init does not rely on systemd timers. They’re a convenient addon that integrates well. But anything more convenient could replace them with no problem (as evidenced by cron still working on systemd enabled systems)
> they simply hired the guy who first developed it
If so, they aren't the originators, but it doesn't preclude them from using systemd to do EEE.
> open source and GPL, anybody can fork
While being OSS and GPL limits attainable power, controlling the development on ever changing software with increasing scope does yield quite significant power and makes practical forking quite hard if you with to remain compatible.
> out-competing alternatives
I remember distributions being forced to use systemd due to software dependencies and ensuing debacles. I think this might be classified as extend and extinguish.
The entire point of the EEE strategy is to capture protocols or standards, such as software developed by other companies or free software developed under the GPL. Forking isn't a relevant option, because the other parties software is not changed (it's expected to not be able to change).
From Microsoft employee Ronald Alepin's sworn expert testimony[1] in Comes v. Microsoft:
Examples of this strategy include Mirosoft's attempts to capture the Kerberos protocol and Java. In both examples Microsoft first embraced existing software outside their control by writing their own implementation, then added non-standard features that were only available in their implementation and a clause in their EULA that forbid anybody that used their implementation from re-implementing the features in other (original) software. The GPL doesn't help here, because Microsoft never touched the original free/open implementation, which continued to exist but was now incompatible with Microsoft's software.While the systemd situation is a little different (it isn't trying to take over "another company's" software, systemd de facto IS somewhat similar to the EEE strategy. They initially embraced existing open standards common in Linux distros, and then extended various parts of their implementation intentionally[2] incompatible changes that had the de facto effect of "reduc[ing] [the] ability to create [non-systemd distros], especially [distros] that will interoperate with [systemd]"[3]. It's not exactly EEE, but there are strong similarities with new features used as a barrier to interoperability.
[1] http://www.groklaw.net/articlebasic.php?story=20070108020408...
[2] e.g. GNOME depending on the systemd-specific version of existing features that made running GNOME without systemd very difficult.
It was never incompatible with MIT or Heimdal. Those systems didn't use the group information in the optional field, but you could kinit and get a Kerberos ticket from a DC.
I know I'm not going to change your mind, but Kerberos isn't a good example.
E.g. Debian went systemd because they don’t have the resources to fix everything they get from upstream that requires it.
Being the primary developer of important system software does have benefits.
Another technology they're using is to some extent the Linux kernel itself. The API used to create device nodes when drivers are loaded is undocumented and the only supported way to use it is udev; anyone else can expect to have their code broken by new kernel releases. That, in turn, is now part of systemd and using it outside of systemd is no longer supported. In effect, the only supported way of using the Linux kernel is with systemd and anyone else is on their own dealing with undocumented, backwards-incompatible changes that the developers have no interest in helping them with.
Nobody was willing to maintain consolekit, the logind folks stepped up to provide a replacement and the gnome folks started depending on it. Everyone could have prevented that lock-in by maintaining consolekit or providing another replacement. Nobody did. To this day, tons of folks complain that gnome depends on logind.
But keep your lame conspiracy theory, it will surly get you much open-source street cred.
Now that same team is messing with system critical stuff. We know from the kernel command line debug debacle they rather see the world burn down than admit they did something wrong. They are again creating a super-complicated incomprehensible half- documented mess, that puts it tentacles everywhere. But the stakes are a lot higher.
I am not saying they are incompetent. At a low level, the code works. But at a high level, something is very wrong. Bugs can be fixed, but arrogant architecture astronauts not listening to their users, messing with core infrastructure, that's where systemd keeps failing.
Can you expand? I've not heard of this.
Systemd developers were like "nobody can tell us how much detail to print", until the kernel developers made clear that the boot console belongs to them and if systemd doesn't back down immediately they would take away all console access. Systemd then backed down.
Sounds like Open Source to me.
https://www.phoronix.com/scan.php?page=news_item&px=mty1mza
[1] Less blog spam, less click bait, better reporting.
I would challange anybody, to introduce a totally new system layer on linux with less issues.
And Pulse Audio was started by Pottering but he quickly moved on and since then it literally has nothing to do with the people who work on systemd. Blaiming him for the persistence of issues with Pulse is simply unfair and would be done if he was not called Lennart Poettering.
I am not a fan of Poettering's code or his attitude, but people have treated him exceptionally badly. He's just doing his job. If these projects were allowed to compete for mind share fairly there would be no problem. If Red Hat had made sure that Gnome could work with alternatives then there would be no problem. Pulse audio would have died a rightful death. Systemd? I suspect that it would still have succeeded.
Agreed. This is Red Hat's mentality with a lot of it's product base. Poettering and Dan Walsh come to mind with regard to the elitist attitude in their respective corners. But just wait, this is going to get worse. Now that IBM owns them they will push this agenda even harder. The new game is controlling a majority of devs in well-known or strategic projects so the overarching enterprise can push an agenda. I don't think we're seeing the teeth quite yet, but give IBM a few years and my guess is it becomes very obvious.
Don't forget Drapper
That's exactly the problem, though. You don't want all that stuff in your privileged PID 1 process. Nor blowing up your prod servers and getting in your way to even examine log files afterwards.
Which is pretty much what I blame him for.
He has a history of starting ambitious (maybe overly so) projects, doing all the fun stuff until it kinda sorta works, and then riding off into the sunset.
systemd has been out for so long that I'm pretty sure we can judge it by its own merits now. As someone who maintains a few thousand servers but only uses desktop Linux on one non-primary machine, I have a lot more well-informed opinions on the trustworthiness and stability of systemd than of PulseAudio.
(And besides, my recent experience of PulseAudio has been that it's fine, and IIRC in the late '00s the primary problem with PulseAudio was that Ubuntu ran it in a non-recommended mode. I haven't actually had any problems with it recently, it just works.)
It seems like the discussion would be more informative and less flamey if we talked about systemd itself. If the team is untrustworthy, there should be numerous examples of that about systemd itself by now.
IME talking with our sysadmins face-to-face, I think a lot of the initial hostility was caused by emotional reactions like: This is different, I don't like it! (Don't get me wrong, it's a behavioral pattern that makes sense up to a point.). I think everybody I've spoken to actually ends up appreciating a lot of things about systemd. (But in these situations, I happened to be their employer, so that definitely biases the conversation even if these conversations weren't really about anything related to their job situation, specifically.)
I also get the impression that a big part of this is due to a lack of 'patterns' or easy recipes to get as much info as possible from the journal. Everybody can intuit the workings and benefits of a text file, but text files have drawbacks that are very subtle and hard to intuit at a visceral level. I think this is partially a lack of good defaults for journalctl. I think it would be better if it (by default) showed much more information and allowed users to turn off unwanted info.
Pulseaudio is definitely better at what it does than ALSA, it is not a step backwards.
My main gripe with anything from that group of people is that they refuse to play nice with others, and by extension that their code refuses to work properly with code produced by others.
[1]: https://wiki.archlinux.org/index.php/Firefox#Multimedia_play...
Pulseaudio is in the same park as SystemD today. It works as long as you don't demand too much of it and don't stray from whatever they deem to be The True Path. It is better for your simple needs. Believe me, those who have advanced professional needs don't think highly of it.
The support for this systems come from people that just use it as packaged and don't have specific needs. Which would be fine IF they weren't getting in the way when you really have specifics needs.
Even if some of the concepts are sound, execution is terrible. As the saying goes, the road to Hell is paved with good intentions.
Maybe that fits RedHat's business model.
"managing the system" is not "ONE [problem]". A big part of the problem with systemd is this presupposition that management of something as large and complex as a modern OS is a single monolithic[1] problem.
> it's complex because it does a complex work.
See, you agree that it's a complex problem! It's so complex with so many different use cases it isn't even possible to have one solution, because some of those use cases are mutually exclusive. Hench why a modular design is important, so it isn't too difficult to replace the management of different areas if needed.
> It's the missing layer between kernel space and user space.
That "missing layer" isn't well defined. There certainly wasn't any "missing layer" on my old server, or the compute boxen we used at ${research_lab}.
If you're talking about desktop system, I agree that there was a gap between traditional system management and the GUI, but that isn't really a new "layer" between kernal and user space (it might involve GUI userspace programs with perhaps some of them being SETUID or a privileged daemon).
[1] Any objections trying to claim systemd isn't a tightly coupled, monolithic design will be ignored. If you think the number of binary program files is in any way useful as an objection, see: https://news.ycombinator.com/item?id=19024256
Could you elaborate? What of systemd’s use cases conflict with one another?
How about picking up the work as well?
And none of the alternatives seem to really get away from the bash script paradigm & more towards the declarative side of things, which doesn't feel like much beyond keeping all that was terrible about sysvinit around in thin wrappers.
Maybe GuixSD is the one exception to this.
Why would I want to start working on software I don't use or need? Why do systemd advocates always insist that every implementation must include the features they think are important? The entire point of designing for modularity is that different people have different requirements; operating systems cannot be "one size fits all".
> yet when logind came around, had lots of strong things to say.
Yes, we had strong things to say about software requiring logind, because it is a terrible (and poorly documented, at least at the time) design. If you want to use logind, go right ahead, that's your choice. We were (and are) only angry about software that we used to be able to use adding dependencies to logind (or other systemd components).
> And none of the alternatives seem to really get away from the bash script paradigm
That probably won't happen, because shell scripting is the easiest/simplest solution for certain types of problems. Some of us have tried a lot of variatio9ns, and keep returning to openrc/bash because it's easier and has fewer problems, at least in some situations. However, on a traditional system (or openrc) nothing is stopping you from replacing the bash init scripts with another language or replacing the entire init subsystem with something else (like upstart, s6, something new?). The complaint isn't that your should use my favorite tools (like bash) instead of systemd; it's that we should strive for modular software so we can all use the components that work best for our different needs,
If you don't care about multi-user session management, sure, but considering practically every window manager/DE relied on consolekit and now logind to provide that functionality, I find it hard to believe it's not desirable by a large majority of users, some of which would belong to the group I was talking about.
I love how people who are obliviously not the target audience feel the need to chime in.
> Yes, we had strong things to say about software requiring logind, because it is a terrible (and poorly documented, at least at the time) design.
I agree about the lacking documentation, but in terms of design it seems quite solid. Any technical specifics as to why it is terrible? It's interesting that systemd's detractors always seem to be rather vague in this regard, makes me suspicious as to whether they did more than have a knee-jerk reaction to a tool that is different than what they used before.
> because it's easier and has fewer problems, at least in some situations
Am going to need specifics, because in my experience, the bash scripts always ended up being a hot mess of variable quality as per the individual author's scripting skills with inconsistent behavior across scripts.
Not to mention that none of the alternatives give me the functionality I want, because their authors strictly focus on the init part, whereas systemd's much more useful even after the system is up and running due to its event driven nature.
Now I realize that not everybody needs some of the extra features, but for those of us that do, (like container management), s6, openRC etc. is even less of an alternative in a real sense.
> nothing is stopping you from replacing the bash init scripts with another language
The init system needs to be designed to support declarative services from the get go, am not simply talking about using Perl instead of bash here, am talking more along the lines of the Nix vs apt paradigm.
> or replacing the entire init subsystem with something else
And is something stooping you? This is my biggest gripe with the anti-systemd crowd, am personally happy with systemd, so it's not me who needs to look for alternatives. It's you. And there are plenty, so please pick one that suits you. The constant anti-systemd bashing every time the name is mentioned from people who seem to barely know much about what it's trying, (rather successfully), to do is rather annoying.
As it currently stands, anyone who wants that basic functionality on Linux - something that's been supported on all other platforms since forever - has to drag along all the baroque undocumented complexity of multi-seat, multi-user support. Why? Well, it seems Red Hat has some customers who sell solutions based on that, or at least used to once upon a time... With the current price of a docking station used to support a single seat in such a setup being comparable to that of a fairly decent refurbished SFF PC, I can't see a huge market for this.
The constant misrepresentation and/or refusal to address the actual "anti-systemd" complaints by systemd advocates is also rather annoying.
> makes me suspicious as to whether they did more than have a knee-jerk reaction to a tool that is different than what they used before.
Resorting to accusations of incompetence only add toxicity to the discussion. You'll have to take my word for it, but I assure you I know what I'm talking about.
> but considering practically every window manager/DE relied on consolekit
Mine doesn't. Some of the special-purpose computer's I used to use didn't use a window manager. These may be uncommon use cases; so what? They solve the problems they are supposed to solve without any unnecessary overhead.
> I find it hard to believe it's not desirable by a large majority of users
So only popular need should be supported? The entire point I'm making is that there are many different reasons people use computers, including many that are unique or almost unique. I may use an older window manager, others might prefer to use consolekit or logind, someone else could be interested in developing a totally new post-window-manager design that doesn't even use metaphors like "desktop", "windows", "sessions", etc. All I'm arguing for is the freedom choose any of those options, which includes variations where consolekit isn't used even if it is used in popular configurations.
The alternative is to argue that one design must be used everywhere, even when it is inappropriate or unwanted.
> in my experience, the bash scripts always ended up being a hot mess
I disagree, but you're welcome to your own opinion. If other software works better for you, then great, use it. I'm not trying to convince you to write bash scripts; I'm trying to explain why a single "one size fits all" design isn't possible, because we may be trying to solve different problems or prefer different tools. If systemd wasn't tightly cou0led and instead played nice with the rest of the systemj, we simply replace parts of it when necessary and we wouldn't be having his argument.
> Not to mention that none of the alternatives give me the functionality I want
Which is why I want you to have the freedom to use the tools you prefer to use, even systemd. Shouldn't other people have the freedom to made different choices?
https://unix.stackexchange.com/questions/5877/what-are-the-p...
As I said in other comments, if you want to replace inis scripts with systemd format service descriptors I will support your efforts becuase using shell script is broken. If you in the making of replacing init with something better also replace logging, ntp, dns, dhcp and a bunch of more then I will say no. This is exactly what systemd does. Rewriting rock solid, CPU efficient code with something shaky and CPU intensive. No thanks.
>>> And none of the alternatives seem to really get away from the bash script paradigm.
Factually incorrect. There are many init alternatives that got away from the shell script paradigm. Including SMF in Solaris. https://www.thegeekdiary.com/a-beginners-guide-to-service-ma...
Good for you then. I am sure you were happy with X11's rotting core & didn't need Wayland in your life, you also likely weren't the one having to maintain its decades old codebase.
> If you want to write a better init system, go for it.
Am personally happy with systemd, thanks, if you're not, why don't you go ahead and write a better one, instead of complaining every time systemd's name is mentioned?
> This is exactly what systemd does. Rewriting rock solid, CPU efficient code with something shaky and CPU intensive.
That doesn't seem factual. systemd is a system manager, useful even after the system is booted up, I think people need to understand that first, it's not just an init system, because many modern services fit an event driven model these days. It's written in C and can run fine on tiny embedded systems.
> Factually incorrect. There are many init alternatives that got away from the shell script paradigm. Including SMF in Solaris.
Yeah, and launchd on macOS, by which systemd was literally inspired by, we're talking about Linux here, since that's where systemd runs, at least I was.
It's a video from BSDCan, the Canadian BSD conference. Even some BSD people are realizing that systemd has a good point to exist!
Hence it's pointless because it doesn't make things any simpler. All it does is making things monolithic and wrapping concepts that are perfectly fine by themselves, forcing third-party software to write to systemd's APIs.
> Systemd actually does ONE thing and does it well: it manages the system.
"Managing systems" is not what is meant by "doing one thing, and doing it well". Systemd takes over init scripting, logging, host names, IP, time, locale, and login, plus tens of more services. Making development of this software a Lennart Poettering/RH-only business rather than community-driven.
The trend to get rid of systemd and its metastasis into most of Linux is excellent news. Note that Slackware and Devuan are also systemd-free (and have been from the beginning).
I don't really feel strongly either way. I'll be pretty sad if Debian and redhat diverge.
Why would you be sad if Debian and RH diverge? Linux started as a one-man show and became a huge community effort because it could run a wealth of F/OSS software. If you want a single-vendor OS, there's Windows, Mac OS, the BSDs, and others. Or maybe IBM RHEL in the future.
What about log and metrics agents, how do you start and configure those?
Also why are you so judgemental? I don't want Debian and rhel to diverge because I have clients who use both and I don't want to have to do more work to support both.
Edit: I am super duper cool with having multiple Linux distributions. I am just not really excited about being forced to interact with vastly different distros specifically in the course of doing my job.
how do you make sure it's done at boot? what if the machines boots up unattended, maybe after a power loss? and where do you put the apachectl binary? And what would happen if for any reason apache crashes? will it stay crashed? will something restart it? if so, what thing will? and what if you need to run it in a restricted environment (let's say something easy, let's say a chroot) ? and what if you want to have upper limits to the resources that it's supposed to use? how do you check if it's running, and how much resources is it consuming ?
Systemd units make all of those things trivial, or at least not that hard.
Anything I touch that requires sysadmins is outsourced one way or another, either via managed services like rds or in house dbas.
If aws or in house dbas have strong opinions about systemd it doesn't impact me.
I mean, this is a laughable point. Like, seriously ? Before systemd every branch of the linux distro tree had its own way of managing stuff at startup, and distros in the same subtreee made things different enough that things like inits-cripts were not portable.
Heck, even with the same init system, some distros arranged runlevels differently. Do people even remember runlevel? Those were another complete way of mess things up.
Are you really playing the "non standard" card? Like, for real?
And seriously, what would be the standard? The Single Unix Specification? According to that spec even bash is not standard, and yet it's the de-facto standard for shell scripts across basically all the major distributions.
I don't know where you're seeing this trend, really. For all major distros, it's been the opposite thus far.
That is exactly my opinion too. Systemd managed to replace the nasty cruft pile that was SysV init with something even less transparent, more confusing, clunkier to use, and with a steeper learning curve to do simple things like add or change a system service.
There is too much to list, but let's start with the beginning: why name one of the most commonly used commands (for admins) on the system 'systemctl', which is even harder to type fast than 'service'?
That kind of total disregard for UX pervades the whole design. Its like no thought was paid to it at all. Everything is obtuse and clunky with long non-memorable names that give you carpal tunnel syndrome to type.
I loathe stuff like that.
Most of the things you mention are side-components of systemd, not core stuff.
You could change the hostname the old way by just go ediding /etc/hostname or using the hostname command (or both). hostnamectl merely exposes you a handy command to do this in a consistent way across distributions.
One could probably take systemd, dropp all the non-init components and make it a minimal init system.
Yeah, except that the "one thing" it does is "everything".
As an end user I don't mind SystemD for writing / managing service unit files. I often find the restart policies and one time only jobs useful especially in cloud with automated deployments. My feelings on SystemD as end user are neutral, it does have some useful things but I understand some of peoples grievances with it.
On the other side I have some OpenBSD systems and the simplicity of OpenBSD service management just being plain bash files is really pleasing to use if anything because of the simplicity and power/functionality it provides without actually doing much itself.
Nit: OpenBSD uses ksh not bash
It manages the system in a way that not everybody needs or even likes. To the people who hate it, it solves problems that other people have but brings new problems that they now have. It's not so much about if it's good or bad but more about whom it was made for.
I mean,there's something called user-acceptance testing for software dev lifecycles right? (Not a pro dev myself) systemd obviously has an issue being accepted by a lot of users even after almost a decade now(?)
Even before systemd there were other init systems used by different distros. The fact that systemd demands other things to adopt to it instead od smoothly integrating with existing systmes is one pain. A bigger pain is how it is expected to work well for everyone. I mean, dislike for "one size fits all" solutions is a major reason why most Linux users became Linux users.
No, really. I, the system administrator, manage the system(s). Does Systemd make my life easy ? No, again. It's something I have to deal for. If I could, I would follow the example of Knoppix.
It is my clear impression that many Windows users would be hard pressed to explain what 'Windows' is and does.
I"m starting to realize where so many holes in my understanding exist, and abhor how for so long I was just content to accept most things in Windows just happened.
Then I started actually digging into log files and various software distro's and tried to connect all the dots.
Long story short, nothing scares me more now than a computer program that I can't explain why it's doing what it's doing. SystemD falls into that trap for me. It may just be a case of sitting down and reverse engineering it until it clicks, but until then, I'd rather not trust anything important to it.
And by the way - if you're doing something Debian-based - make it Devuan-based, it's pretty straightforward. http://www.devuan.org/
It's also pretty straightforward to switch Debian systems back to sysvinit.
See also: https://unix.stackexchange.com/a/433346/34868
You still need libsystemd0 which is a compatibility library. It's actually unfortunately named, as it isn't part of systemd itself.
I've been using sysvinit on my Debian workstations since systemd became the default. It takes me about 5 minutes to switch a new system over (admittedly I don't use Gnome or KDE). The stackexchange thread you linked is out of date and switching is getting easier. I recommend following the debian-init-diversity mailing list for further info.
But i was seeing that in Embedding Linux or IoT distributions that doesn't make sense since they're run on limited resources.
(That's not to say systemd has no bugs. I expect it does. We either just didn't run into them, or we tested whatever complex thing we wanted to do—far more than could be expressed in any other init system, process keeper, or systemd competitor—found it didn't work, and moved on. That would be indistinguishable from systemd intentionally not having some fancy feature, and it definitely didn't affect us in production.)
Meanwhile, I can remember numerous concrete bugs in the Linux kernel, concrete misfeatures, and downsides from having a monolithic kernel where if one thing goes south everything does. But nobody warns me to avoid Linux....
Systemd is not that heavy to run when configured correctly (which is what the distro should do).
Device have 256MB.
Two of the three components in your list that are mearly mandatory came from the same engineer. Why we do we keep accepting his code?
FWIW, the desktop world is less important and I run Linux as a desktop. The nightmares I get from systemd are all about my servers. If we could have left servers alone, people like me wouldn't even have cared. As it is, I have to get out the kid gloves when I'm dealing with my service platform because Bad Decisions are now system standard.
Fedora has been defaulting to Wayland on fresh installs for at least two or three releases and generally it’s working okish. There’s still a lot of software lacking proper wayland support, though.
Perhaps it's just me but I haven't found an xorg problem in my life that's fixed in wayland but I've had a few problems in wayland that don't exist in xorg. My display needs are rudimentary though, so perhaps I'm not the target audience.
Putting wayland aside... is exactly what I've done. I don't need wayland, so I don't use it. With systemd, not only do many of us have problems but we don't really have a choice. I could run my world on Slackware but then I'd be a SPOF (much like systemd) and that's a bad way to build architecture.
Sure, you can use XWayland and just call it a day, but that doesn't really help.
The reality is that exactly due to the enormous legacy baggage of the "X ecosystem" it's not easy to just switch "to Wayland". GTK, Qt, and (again, due to the required hacks) all major apps (eg. Firefox) have to do serious work (as in finally implement something sane, now that it's an option) to work.
DBus is okay. Though bus1 might be an improvement, and having it in kernel would be a bit more efficient (zero copy, better security, etc).
It means that Linux community is full of people that refuse to give up on their gripes even after years. Those also tend to be the people who refuse to understand that "the old way" might not be the best way to do something and also fail to produce a viable alternative.
Linux audio was not usable for end users until PulseAudio stabilised. Init based on scripts was a trash fire. And yet, although SystemD and PulseAudio aren't perfect, noone managed to produce anything comparable except pages and pages and pages of whining.
These people need to let it go. This toxicity is unhealthy and it's just damn software.
If you want to gain users again you should search for innovation, not abandon it.
When I want to write a script that runs on startup, I expect that I can just put (or link) it in some directory where the scripts are that get started on startup. Or that there is one main script that calls all scripts that are intended to be startet on startup.
I do not want to write a "service" that has some "only run once and then discard" flag or whatever.
When I want to look at logs, I want to use the tools I like. less, grep, tail etc. I do not want to dabble with some binary format and its tooling.
When I want to start or stop a service, I want to call a script that does that. A script which I can look at and see what it does. Like /etc/init.d/apache2. I do not want to execute some magic command like "service apache start" which I have to guess or look up and which gives me no clue about what it does.
This is fine, but you do have to accept that things are going to move on without you.
I explained, why systemd is a step in the wrong direction in mutiple ways. That has nothing to do with habbits.
I see a bunch of "I want X", but I don't see any "why"
I have a little sympathy for this one as an old habit if you don't know any better. It's also an extremely inefficient way to work with logs. If you've used a system like Splunk seriously, the idea of going back and grepping through logs on a host with the shell is just frustrating.
> They want to see the scripts that manage the system and poke around in it, which has the implicit reason to learn about the system and being able to easily modify it.
I have no sympathy for this one. Scripts are a terrible place to define policy. They are nigh impossible to audit. They are brittle. They multiply complexity by making everything a special case. They make integration of different parts of the system nearly impossible.
>I want to call a script that does that. A script which I can look at and see what it does
Compared to something like a shell script, systemd unit files are magic because you have to know a lot about how systemd works to figure out how your config file translates into actual behavior.
This is not very specific, have you never had any race-condition with this? There is a reason SystemD ask some informations regarding the service that needs to be launched. I don't see how ignoring those makes a good argument against SystemD.
My favorite part is OpenRC still likes the old ways, has script extensions for new ways, and runs the same path every time.
Then just use cron.
Interesting. I feel the other way. Unix failed to provide a real service management system early on, so we have layers of historical cruft (Fork, close all descriptors, fork again, escape process group? Really?), and ended up with all kinds of absurdity in shell scripts to handle it.
The right way is to have a strong system contract on what constitutes a service, and have no wiggle room so that 'service apache start' does a fixed, known thing.
Sadly, systemd has to support all kinds of legacy hacks. A nice way to chart a way forward might be to define a simple contract and require someone to mark a unit file as "legacy" to enable the other possibilities.
AFAIK, systemd is compatible with sysv init scripts.
> I do not want to write a "service" that has some "only run once and then discard" flag or whatever.
Why? Writing one isn't so complicated.
> When I want to look at logs, I want to use the tools I like. less, grep, tail etc. I do not want to dabble with some binary format and its tooling.
Well, nothing prevents you from piping output from journalctl to whichever tool you prefer. In fact, people do it all the time.
> When I want to start or stop a service, I want to call a script that does that. A script which I can look at and see what it does. Like /etc/init.d/apache2. I do not want to execute some magic command like "service apache start" which I have to guess or look up and which gives me no clue about what it does.
I don't see how sysv init is any better than systemd in this regard. You'd still have to look at indidual scripts to see what it does. It's not like systemd hides the contents of the service files.
In the early 2000's, distros didn't have live environments bundled. All debian used to have was a TUI installer and that's it. Ubuntu 4.10+ introduced a live sessions.
From 2004-now driver support and hardware detection has gotten much better. There are live session CD's that include "nonfree" drivers that further improve hardware support. You can pop in most popular distros and easily connect to WiFi and mount drives, often just as easily as knoppix did.
This complaint about systemd isn't a user-related, but the perspective of the live cd creator. Maybe it's true systemd doesn't help that case, but would systemd get in the way of a live cd user though? They're likely not going to be adding/removing/starting/stopping services, setting up users/groups, or anything else that'd be done in a permanent environment.
The one benefit would probably providing a glibc version if you require it.
(I'm a Void Linux contributor.)
I wrote about void because it “felt” like the philosophy of BSDs in the Linux land. Which is quite a draw for me. Binary packages, up-to-date kernel, and a sane init system felt fresh and in KiSS realm.
Okay, but doesn't that remove a lot of functionality that is available with systemd units? In this whole systemd debate, I've never seen a really clear outline of how much complexity systemd covers, and whether the older alternatives were actually simpler or not. Granted, I haven't looked very hard. I use systemd with Arch and have no known issues with it.
[1]: http://smarden.org/runit/
[0] https://distrowatch.com/index-mobile.php?distribution=knoppi...
From this German article[0]:
> Knoppix' Startvorgang läuft nach wie vor per Sys-V-Init mit wenigen Bash-Skripten, welche die Systemdienste effizient sequenziell oder parallel starten.
> Knoppix' boot sequence still uses Sys-V-Ini, with some bash scripts which start the system services efficiently sequential or in parallel.
So it has still all the downsides of sysvinit, except that might start sevices in a more efficient order or some in parallel.
[0]: https://www.golem.de/news/live-linux-knoppix-8-0-bringt-mode...
SystemD needs to die because it violates Unix principles, not because of it's new key combinations. Unix is built on the notion that everything is a file, and that purpose built binaries make sense. SystemD breaks the latter - meaning it's now significantly more work to do the same things when it comes to log investigation, service analysis, and related events.
Perhaps the worst part is the extension of a subsystem for service initialization to everything other than that. The folks at suckless (https://suckless.org/sucks/systemd/) did the argument significantly more justice than I ever could.