Systemd, ten years later: a historical and technical retrospective

https://blog.darknedgy.net/technology/2020/05/02/0/

by vezzy-fnord • 6 years ago

381 423 6 years ago

blog.darknedgy.net

ratsmack• 6 years ago

systemd still remains poorly understood and understudied from both a technical and social level despite paradoxically having disproportionate levels of attention focused on it.

This statement makes no sense. It is well understood and has been studied and critiqued by many, including me. Also, I don't know what "social level" has to do with anything here. It was just created for the commercial aspect of Linux and forced into the relevant distro's by commercial interests... it's just that simple.

JChase24• 6 years ago

I'd say software doesn't always win out on it's merits, there's almost definitely some social aspects regarding what does and does not get adopted. I do agree the commercial interests probably played the largest role, though. I think beyond the initial knee-jerk one might have towards this it's pretty comprehensive and there's interesting points here that are at least worth exploring.

acdha4• 6 years ago

Aren’t those social aspects part of their merits? A big part of why systemd won widespread adoption was by stepping up – the number of people working on the others wasn’t enough to be more competitive. I lost track of the number of Upstart bugs we avoided by switching to systemd, and that had the backing of one of the most popular Linux distributions.

Jonnax• 6 years ago

I think on the social level there's a lot of people that go "urgh systemd" because that's the popular opinion but overestimate their actual technical knowledge to comment on the matter.

I remember reading some advice about not doing rm -rf / on UEFI systems and looking that up, it looked like some MSI laptops would brick if certain UEFI variables were wiped.

I found an issue in systemd's issue tracker. And from what I could tell the ability to write to these variables was required to perform certain functions like rebooting into the UEFI system.

But it looked like that some forum or another had linked to the issue. And plenty of people were up in arms about it without anything substantial to say.

dijit13• 6 years ago

This is a hard point to refute because it's basically "some unknown number of people who don't like systemd are possibly technically illiterate" which is always going to be true but to an unknown extent.

If we're going on technical credentials, I have a few minor ones. I'm not writing dozens and dozens of lines of C every day, and I'm definitely not writing kernel components- but I've been doing low level technology stuff for 15 years now.

Everything from watching access patterns on drives and recombining data to writing/patching memory allocators and aggressively tuning system internals. I'm currently responsible for automating the deployment of the largest always online game my publisher has ever known. I'm relatively technical and highly regarded for my technical competence.

When it comes to systemd; you could argue that I'm "stuck in my ways"; but I've used systemd since fedora 21, I saw bugs you couldn't imagine, I read the code, I saw the hostility of the developers (maybe it's just defensiveness?) and I was a little worried, but ok, it's just fedora, it'll be better in RedHat when it releases... and while a lot of the lower hanging bugs went away for most use-cases; many remained in the edges. Instead of them being fixed though there's been a propensity to build a software eco-system and "system layer" to the OS.

My argument has never really been that "systemd totally sucks" it's that the conversation surrounding it is very hostile.. If you say that you don't like journald (because it's very easy to corrupt and has access drawbacks, encoding issues, tooling is sub-par etc) then people shout at you: "YOU CAN USE OTHERS", but you can never turn journald off.. it's wasted IOPs, IOPs are not free.

The biggest issues I had with systemd is the fact that (unlike Solaris' SMF, which is great btw) it will hide failure from you, and failure can happen relatively randomly because nothing is deterministic. This is not a holdover from being multi-threaded, there is actually a dependency graph that gets generated. But I've never been able to access that. (Maybe that's changed?)

My argument has always been, instead: "systemd's tight coupling of so many components means that we will never be able to have an alternative or successor to systemd". Because re-implementing single components is next to impossible and the sheer scope of the "system layer" is many times more lines of code than the kernel itself.

Anyway the conversation is steeped in some level of tribalism.. Which I truly hate.

You can't talk about systemd without being "pro" or "against" and then people take extreme stances, like "systemd saved my baby" and "sysvinit was trash" (and on my side: "unix philosophy!", and "systemd ate my utility!")

xani• 6 years ago

Pretty much. If it was just some guys project nobody would give a shit until it was actually well tested and proven.

But it was made by guy hired by Red Hat so instead of maturing and having to take actual user feedback before being used in anything significant it was pushed by a guy that vision is limited to "It works fine on my laptop".

Who then decided to reinvent everything along the way like log storage that still takes over hundred of file opens (and tens of seconds) to get "the last 5 log lines of a command" ( https://github.com/systemd/systemd/issues/2460 ), because why the fuck use say SQLite when you can have fun evening inventing your own shitty binary journal format.

I do find a lot of stuff behind systemd useful but the ever-present half-assness of its solutions is annoying. Half-assed logging here, half-assed dhcp client there, quarter-assed ntp client elsewhere, all while basic functionality is still riddled with edge cases.

Still a net positive over having to fix yet another fucked up init script...

Spivak10• 6 years ago

This has not been my experience at all. The systemd project seems to take extreme care to adhere to the spec when implementing features. They don’t adhere to “this is how it used to work” which is where the bulk of the issue seems to be. The big controversy was when systemd-resolved implemented the spec to the letter and broke people’s assumption that listing DNS servers in order means they’ll be queried in that order.

Supermancho3• 6 years ago

you can have fun evening inventing your own shitty binary journal format.

I thought the reasoning was to make logs harder (or impossible) to tamper with.

Something something about trading freedom for security.

vezzy-fnord9• 6 years ago

Well, my point is that (for instance) the specifics of its dependency model are still fairly obscure and undocumented knowledge. So I would say the statement is quite justified. And it also has a fascinating history that often gets reduced to culture war-related soundbites, which too deserved to be told.

josteink3• 6 years ago

It is well understood and has been studied and critiqued by many, including me.

It seems a lot of people simply don’t want to understand systemd, and go out of their way to avoid learning anything about it.

Could that be considered a social factor?

acdha4• 6 years ago

I think this really sums this article up:

One thing I’m certain of is that this shift cannot emerge from dilettantes, outsiders and proverbial basement hackers. One does not unseat a platform without already being part of the patriciate that calls the shots on what gets integrated where across the largest nodes in the ecosystem.

It’s a long, turgid “why wasn’t I consulted?” complaint which really just comes back to the question of how open-source projects work. An init system is harder than it might seem at first and requires buy-in from an unusually large number of parties since it affects the OS, everyone shipping daemons, and the operators. If you’re not going to invest that level of engineering time, I don’t see how it’s reasonable to expect an equal voting share with those who do.

gens2• 6 years ago

Voting share ? There is no vote unless you work for RH. And even then.

An init system is harder then it seems ? You and Jonnax seem to think that unless you made it you have no right to say anything. Have you ever made an init system ? Researched what exactly goes into it ? Sure, there's more then just starting programs. But not much more. The only really complicated thing about getting a [linux] computer from kernel boot to firefox is setting up devices. And even that [udev,"hotplug"] is not complicated as much as it is.. obscure. I know about these stuff, do you ?

I'l defend a newbies right to say anything. Nobody was born with all the knowledge of the world. I will not have compassion for your kind of ignorance.

SystemD is about as much an init as my foot is me. That is the problem that most of those you so casually dismiss have with it. That and that it wants to become mandatory. Could they have just extended udev instead of integrating it ? An i wrong to say that ? Is my opinion wrong because i don't have "Red Hat senior engineer" next to my name ? Programming is just a hobby for me. I don't even have a degree in it. So i'm ignorant on the subject ?

Funny thing.. most of those on teh internets who are vehement in favor of systemD don't know much about how a computer system boots and what goes into that.

edit: Never mind. I see feelings and fancy words are still more valuable then knowledge or thinking. Maybe one day, when computing is not as young of a science as it is now.

acdha4• 6 years ago

An init system is harder then it seems ? You and Jonnax seem to think that unless you made it you have no right to say anything. Have you ever made an init system ? Researched what exactly goes into it ? Sure, there's more then just starting programs. But not much more. The only really complicated thing about getting a [linux] computer from kernel boot to firefox is setting up devices. And even that [udev,"hotplug"] is not complicated as much as it is.. obscure. I know about these stuff, do you ?

I know enough to know that you left out networking and authentication, network service dependencies, filesystems, volume encryption, etc. – not to mention automatic restarts, conditional behavior based on the network or other devices (stuff needs to happen when I leave the office), and the various edge cases which I’ve seen in three decades running Unix systems. Every other operating system Linux is competing with has a much better model than SysV init (Windows has since the early 1990s!), and the world changed from static servers which rarely changed to most systems needing dynamic behavior – what worked in an old server room isn’t a good fit for a laptop!

Again, I’m not saying that systemd is perfect but that most of the complaints tend not to acknowledge the many problems it solved and a decade of angry forum threads doesn’t seem to have resulted in any concerted effort to build a serious competitor. The Debian community had a deep examination of the alternatives and picked systemd because it made sense, not because Red Hat has some brainwashing program.

bsder• 6 years ago

As a FreeBSD and Mercurial user, I get more than a little schadenfreude when Linux users complain about something being foisted on them by someone with a more dominant mindshare or marketshare.

Linux users spoke and set the system up to do exactly what it does--use a dominant position to drive out alternatives. They only complain when they suddenly wind up on the receiving end.

Perhaps if you don't like getting the pointy end of the stick, maybe you shouldn't sharpen it in the first place?

Accacin• 6 years ago

Funny thing.. most of those on teh internets who are vehement in favor of systemD don't know much about how a computer system boots and what goes into that.

Why can't you have a discussion without childish insults?

throw0101a10• 6 years ago

An init system is harder than it might seem at first […]

systemd-as-init-system is not the problem. systemd-as-kitchen-sink is the problem.

It's the tight coupling that annoys many people.

Does udevd really need to be in the same repo? While there may be some nice things about journald, does it really have to be in the same source package? (And why can't it support remote logging with the industry standard syslog protocol? Now I have to run journald and rsyslog. And why doesn't it have an ACID file format that doesn't self-corrupt at times? Why couldn't they just use SQLite or OpenLDAP's LMDB?)

What does systemd 245's systemd-homed have to do with an init replacement?

* https://www.techrepublic.com/article/linux-home-directory-ma...

ArchD• 6 years ago

Yeah, don't get me started on the fragile glass test tube called systemd-resolved that fails in mysterious ways when I use wicd on Ubuntu and the WiFi gets momentarily disconnected. I don't see the sense behind treating name resolution as something so special that it has to be part of an init system.

I like the overall theoretical concept of systemd but it has ugly implementation details like this.

blibble2• 6 years ago

So, for the simple act of logging in, three mechanisms are required (systemd, /etc/shadow, /etc/passwd). This is inefficient, and Poettering has decided to make a drastic change. That change is homed. With homed, all information will be placed in a cryptographically signed JSON record for each user.

10 years ago this would have been considered satire

pas6• 6 years ago

systemd is not an init system. That it has one, it out of necessity. To manage a system you have to manage what runs on it, to manage that you have to manage what gets started and stopped, and so you have to manage boot and shutdown. And now, here's your nametag, there's the counter, don't forget to smile, you're the new init system!

udev doesn't have to be there, but when a handful of people maintain critical parts of the Linux ecosystem and they saw ways to make their maintenance work more effective, they went ahead and made their work more efficient.

I mean, criticizing systemd/udev/Debian/Ubuntu/Arch on how they did stuff, and the technical merits of how things are is completely fair, but criticizing "why" is strange. They did because they saw that it will help them, their projects, their users. (And they probably understood very well that it won't please all of their users.)

sergeykish3• 6 years ago

Syntax wars are harder than it might seem at first. If you're not going to invest that amount of time, I don't see how it’s reasonable to expect an equal voting share with those who do.

Sometimes vocal minority is just that.

nisa• 6 years ago

It’s a long, turgid “why wasn’t I consulted?” complaint which really just comes back to the question of how open-source projects work.

I've read it more as a quirky history writup with some technical and idiology discussions.

FWIW I still think the technical criticism in the article has a lot of merit and what seems "turgid" to you is a nice link collection to learn about systemd minutiae...

cat199• 6 years ago

how open-source projects work

they work differently depending on the project.

so this statement:

requires buy-in from an unusually large number of parties since it affects the OS, everyone shipping daemons, and the operators.

is only true in some cases.

c.f. rcng, which was developed by a very small few people, and is a generally sane improvement on previous BSD init that i've really never heard any complaints against vs the previous method.

same could have been true here. it was not - and the need for 'consensus' was largely sidestepped by the 'market pressure' of gnome being dependent on systemd features, and the leading core desktop environment that people had already attached themselves to, esp in the enterprise market.

pas6• 6 years ago

Debian voted on the issue, and there was a very lengthy discussion. I don't think the Gnome dependency was the linchpin, at all. Debian developers wanted to get rid of thousands of silent but deadly shell scripts shipped in every package doing service management (rc scripts), they wanted nice cgroup integration, and that's it. At least this was my impression.

zozbot2346• 6 years ago

Systemd is an amazingly clear example of the second-system effect, as described in The Mythical Man Month. I fully expect it to be replaced down the line by something dramatically simpler and more intuitive, but that might take some time. Nonetheless, it does seem to solve some real problems with the earlier, rc-scripts approach.

0zymandiass• 6 years ago

It's dramatically simpler and more intuitive than what it replaced, so I'm super excited when someone comes up with something even better!

downerending2• 6 years ago

Systemd has many pluses, but simplicity and intuitiveness are most certainly not among them.

rleigh3• 6 years ago

It's dramatically simpler and more intuitive than what it replaced

I hope you're being deeply ironic.

It's several orders of magnitude more complex. It's more difficult to understand and reason about because its internal state is a black box, and the number of interfaces and file formats to understand is again orders of magnitude more complex.

sysvinit had a socket interface with a single message type. It had a single and very simple configuration file (inittab). Everything else was delegated to higher levels. Simple, flexible, and extensible. But above all, understandable in its entirety, and completely predictable.

bdavis__• 6 years ago

i hope you are correct.

it is so easy to deprecate someone else's skills and knowledge with massive change like this. would it be that hard to respect some of the users?

ttctciyf6• 6 years ago

As a somewhat dilettante and casual home sysadmin (currently) I was messing around with screen on a box downstairs and ran into this:

https://www.reddit.com/r/programming/comments/4ldewx/systemd...

Namely that systemd doesn't allow persistent processes started from the shell by default, preferring to terminate them when the user logs out.

This would include processes like "screen" whose entire raison d'etre is to persist after the user logs out. (Well, it has other uses, but this is the main one IMO.)

The stated workarounds - fiddling with some options like "KillUserProcesses=no" in logind.conf &co. - have so far failed.

I don't know whether this situation is a problem with systemd or the distro, but it seems very much a problem with the culture summarised by the top commenter in the above thread, of (paraphrasing) glibly breaking existing workflows then casually brushing away criticism with arguments often boiling down to: "this is the right way, I don't care about tradition or protecting 'incorrect' usage."

dmurray• 6 years ago

Does nohup work? That's what I would expect to be the standard solution, as the Unix tool that "does this one thing and does it well".

catalogia• 6 years ago

No. SystemD defaults to breaking nohup, tmux, screen, emacs server, etc.

gerdesj• 6 years ago

Screen still works. I use it all the time.

Do you have decent examples of it failing to work? If so, then that sounds like a bug against screen. The link you provide is absolutely huge and from three years ago.

Please give me a simple "stages to reproduce ..." style report. Please keep it simple and short and I'll fill in the blanks if I can and only trouble you for stuff I'm too daft to work out.

fao_2• 6 years ago

Maybe you should offer to move this bug report conversation somewhere more appropriate? It seems that this is better suited to a github issues thread

ttctciyf6• 6 years ago

To answer your question:

remote login, start screen, ctl-A d (detach), log out, log back in, screen -r (resume) - there is no screen session because it was killed by systemd immediately after log out.

(syslog entry: May 3 09:01:25 $HOSTNAME systemd[1]: session-6.scope: Killing process 3290 (screen) with signal SIGTERM. )

But that's hardly the point, the point is the toxic "you're doing it wrong" mentality that infests the systemd project and its adherents. I've run into this in so many ways since ceding defeat and allowing it onto my systems. This is just the latest in a long line of examples.

e12e• 6 years ago

See:

https://www.pcworld.com/article/3078732/debian-and-fedora-us...

https://unix.stackexchange.com/questions/420594/why-process-...

https://askubuntu.com/questions/1169211/how-can-i-fix-nohup-...

throw0101a10• 6 years ago

Do you have decent examples of it failing to work?

Poettering:

Note that in some cases it might be a good thing to kill screen sessions when the user otherwise logs out […]

* https://lists.freedesktop.org/archives/systemd-devel/2011-Ju...

detaro• 6 years ago

The link you provide is absolutely huge

The first message in the bugtracker already has the context of whats happening.

zozbot2346• 6 years ago

This is yet another example of pointless incidental complexity in systemd. The whole point of "nohup"-based tools like tmux and screen is to cleanly separate the management of user sessions from the incidental mechanism of whether a remote connection is being closed (the 'HUP' in nohup is short for "hang up" i.e. close a [possibly remote] connection). Systemd should simply acknowledge this fact and keep the user session going when a program has been launched under nohup, instead it tightly couples its own "session" concept to the remote connection and then adds a totally ad-hoc, hacked-together feature called EnableLinger to somehow make nohup work anyway. It's amazing.

pknopf2• 6 years ago

I'm not seeing a lot of hope here. There is an incredible investment in systemd by distributions, there is no turning back.

Help me..

thristian• 6 years ago

The trouble is that 'nohup' is not a particular state that specifically marks processes that want to survive logout. Instead, the rule is that processes running inside a particular terminal are killed when that terminal closes, and processes running outside any terminal run as they please. If you SSH to a server, or telnet, or login on the text console, or via a serial port, you get a terminal and everything you run runs inside it, and the system works.

However, if you login to a graphical desktop, that is not a text terminal, and therefore everything is effectively nohup'd: your browser, your chat program, your media player, all the miscellaneous helper processes they spawn, etc. Most people do want that stuff to be automatically shut down when they log out.

Since the kernel's idea of "a login session" is wrong (it only includes text-terminals), and it can't easily be changed for compatibility reasons, systemd implements its own idea of "a login session" that works the way most people (who aren't experts on POSIX job control) expect.

pas6• 6 years ago

No, it has nothing to do with remote and such.

systemd uses cgroups (kernel namespaces), and if you want something to remain after you log out, then start it in a separate cgroup.

cgroups are control groups, you know, to control processes. Which was simply missing for decades in Linux.

nohup should be enhanced to support systemd, or systemd should provide a nohup wrapper, and just start a new scope (cgroup) for whatever the user launches with nohup.

...

Now, that said, I have no idea why distros and systemd did what they did without much communication, but ... that's usually the Linux way :/

yawaramin4• 6 years ago

That thread also mentions the solution that will work: https://askubuntu.com/a/904125

I.e.,

    systemd-run --scope --user screen

MereInterest• 6 years ago

I know that there is a separate command that can be used to tell systemd to allow a program to live. I know that there are systemd libraries that an executable can link against in order to opt out of the new behavior. These do not matter, because they shows that systemd is willing to break existing programs, and to break specified conventions. Systemd developers cannot be trusted to provide a foundation to build upon.

hedora5• 6 years ago

Why should I be forced to prepend all of that to every command I want to survive terminal hang ups? The old mechanism was more user friendly, and better documented.

It’s just another example of systemd making everything on the system worse.

ttctciyf6• 6 years ago

Nope:

[user]@[host]:~$ systemd-run --scope --user screen

Job for run-r0b2a43d19a564e2c9f36b5c9b934420f.scope failed.

See "systemctl status run-r0b2a43d19a564e2c9f36b5c9b934420f.scope" and "journalctl -xe" for details.

[user]@[host]$ journalctl -xe | cat

May 04 03:02:54 [host] systemd[918]: Failed to start /usr/bin/screen.

-- Subject: Unit UNIT has failed

-- Defined-By: systemd

-- Support: http://www.ubuntu.com/support

-- Unit UNIT has failed.

-- The result is RESULT.

May 04 03:02:54 [host] polkitd(authority=local)[879]:

Unregistered Authentication Agent for unix-process:1504:595444 (system bus name :1.25, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_GB.UTF-8) (disconnected from bus)

----------------------------

I changed my user and hostname to "[user]" and "[host]" respectively, the rest is verbatim.

It's interesting to note that to even see the error report (such as it is) I'm instructed to invoke a special command rather than just look at logs where I might expect to find it, and that when I do so I am locked into some dysfunctional pager requiring me to pipe through "useless cat" in order to cut and paste the uninformative details on long lines.

While the consistent boorishness of my systemd install continues to amuse, the details of this issue and the fact of its resolvability or otherwise by invoking recondite special systemd functionality are beside the point.

Why should I need to know how to run normal and trusted software in special systemd compatible ways that I've previously had no issues with for decades?

As I opine below, the point is the toxic "you're doing it wrong" mentality that infests the systemd project and its adherents. I've run into this in so many ways since ceding defeat and allowing it onto my systems. This is just the latest in a long line of examples.

erik_seaberg• 6 years ago

This is severe scope creep for an init replacement. I don't exactly know what "the service manager of the calling user" is meant to actually do (that's way the hell outside POSIX), but if a user wants one they should be able to choose, and it shouldn't matter to them how the sysadmin chose to create routing tables and mount filesystems.

oconnor6632• 6 years ago

Have you tried `sudo loginctl enable-linger [username]`? This used to be well-documented, but I don't see much about it now. It's possible things have changed since the last time I had to deal with this?

majewsky5• 6 years ago

What do you mean? I still see it in `man loginctl`.

enable-linger [USER...], disable-linger [USER...]
Enable/disable user lingering for one or more users. If enabled for a specific user, a user manager is spawned for the user at boot and kept around after logouts. This allows users who are not logged in to run long-running services. Takes one or more user names or numeric UIDs as argument. If no argument is specified, enables/disables lingering for the user of the session of the caller. See also KillUserProcesses= setting in logind.conf(5).

thayne2• 6 years ago

The stated workarounds - fiddling with some options like "KillUserProcesses=no" in logind.conf &co. - have so far failed.

Strange, KillUserProcess=no worked fine for me

yrro3• 6 years ago

In addition I'm pretty sure every distribution ships with it disabled anyway.

cyphax• 6 years ago

I read this comment, thought after having recently installed Debian replacing Slackware I'd wipe it again because that's unacceptable. So I ssh'd into the machine, started a screen session, detached it, killed ssh session, ssh back in and the session was still there. Is this an older problem? So far, after coming from Slackware, systemd hasn't been in the way so much, thankfully.

grandinj• 6 years ago

Given the insanely vitriolic level of personal criticism leveled at the systemd people on an ongoing basis, some degree of glibness is an unfortunate byproduct.

How about we give them some benefit of the doubt, that they are mostly trying to make things better, and instead ask them "what is the technically correct way, in the systemd world, of implementing this functionality?"

I suspect the answer, for screen, would probably require some degree of messing with the user manager daemon.

ttctciyf6• 6 years ago

"what is the technically correct way, in the systemd world, of implementing this functionality?"

In the case of terminating programs left running in an ssh shell by a logged out user, it's a pretty simple answer IMO: just leave it alone - if the admin of the ssh server wants to terminate user processes on logout I think that's where the burden should lie and there's no good reason for systemd to get involved, that I can see.

lidHanteyk• 6 years ago

The author sounds distressingly prescient with their prediction that BPF will be the next venue for this sort of farce.

nn3• 6 years ago

The dependency problems he's describing sound like they could be relatively easily fixed with some new systemd keywords?

Of course it would take some time to migrate existing unit files.

It doesn't sound like a fundamental critique. Would be nice to turn this into a constructive proposal to fix systemd.

kelnos7• 6 years ago

It feels like a lot of the existing keywords were added in order to paper over previously-discovered dependency issues. And the result has been a) confusion, and b) more dependency issues. I don't think adding more is going to help the matter.

meddlepal2• 6 years ago

Oh good, the monthly HN systemd 5 minute hate is upon us once again.

gjvc4• 6 years ago

It's worth considering why the topic makes such a regular appearance. I suggest it might be because that so many users of this website find it to be a remarkable example of not only how something so widely unpopular can become so widely established, but also being something that they have to contend with frequently.

sneak5• 6 years ago

It would appear from distribution adoption that systemd is a lot more popular than it is unpopular.

Nextgrid• 6 years ago

Is it actually unpopular or is there just a vocal minority constantly complaining about it while a much larger part of the user base is happily using it?

gjvc4• 6 years ago

If you don't like something, put your energy into implementing it the way you do. With any luck, the ensuing distraction will be more effective at weakening the original than simply complaining about it.

Karunamon2• 6 years ago

Sadly, systemd has corporate backing, which is a very hard fight to win for a ragtag bunch of nerds with dayjobs who have the completely unreasonable expectation of not having their shit broken, regardless of how much energy we have. Money and full-time devs beats energy every day of the week.

gjvc4• 6 years ago

My point was that there is nothing (no competing implementation) to be judged against, so it rather wins de facto.

whereistimbo2• 6 years ago

vezzy-fnord! I have always enjoyed your commentary and perspective of operating system, it's nice to see you back again!

vezzy-fnord9• 6 years ago

it's nice to see you back again!

Not for long, probably. I drifted out of this sphere years ago, and came back specifically for systemd's 10 year anniversary, as I felt obligated to at least do that.

Judging by the tone of the comments, 10 years later is still too soon to discuss systemd dispassionately, but when I come back in 10 more years I'll see if things have changed.

whereistimbo2• 6 years ago

Would you like to tell me what OS are you currently using? Are you still keeping pace on OS research?

majewsky5• 6 years ago

Honest question: Which relevant technology is ever discussed dispassionately?

bepvte• 6 years ago

Interesting comparisons of a GNOME volunteer to Stalin. Also found it very interesting that the author put inclusivity in quotes.

vezzy-fnord9• 6 years ago

Oh, but it is a good comparison.

Many people have compared free software to communism. I always used to dismiss it. But, in a way, they were right. Both are movements with a self-conceited historicist endeavor to eliminate exploiting classes ('it is inevitable that the tendency for the rate of profit to fall to produce immiseration as capitalists can no longer profitably invest, leading to a proletarian seizure of power' versus 'it is inevitable that proprietary walled garden development models stagnate as they're overtaken by decentralized communities pooling their knowledge and labor into the most optimal end' and create a perfectly equitable free association of producers no longer having their surplus value be seized by exploiters.

One degenerates into a repressive bureaucratic collectivist (I'm not a Trotskyist, but it's a good term) mechanism for reproducing surplus through either direct requisition or coercive planning. The other degenerates into a way for large-scale cloud providers to appropriate the free labor of volunteers so as to reinvest it back in their walled gardens.

Stalin represented the Leninist wing against ultra-leftists, anarchists and other factions who were against tight top-down organization in favor of 'spontaneous' organizing, and the GNOME/Freedesktop/Red Hat nexus is against the faction in free software that insists on a loosely coordinated and loosely coupled bazaar without a central vision. But in no sense has systemd abolished this, it has only reduced a few nodes at best.

EDIT: Actually I should point out that 'free software' per se is a deontological argument, and it's 'open source' specifically which specifically uses these historicist arguments to justify itself. But then open source was unabashedly an effort for corporate sanitization of free software, which most people forgot after it mostly crowded out 'free software.'

nine_k5• 6 years ago

My beef with systemd is not its reinventing things. That part may actually be good.

One problem is that a number of reinventions were poorly made.

E.g. the log format. Yes, unstructured logs have a ton of drawbacks. Can we take some ridiculously well-tested, reliable embedded database or serialization format (like sqlite) and use it as log storage? Alas.

Another problem is the "I know better" attitude.

Are user processes allowed to run after logout? Which DNS to use during startup? What logging in should look like? In each such case, existing behavior which was widely considered as not broken was replaced by a different behavior, often even without an escape hatch. The new behavior(s) in such cases should be made possible, but the default should be the old behavior.

No wonder I don't run systemd on my desktops / laptops.

m45t3r3• 6 years ago

Are user processes allowed to run after logout? Which DNS to use during startup? What logging in should look like? In each such case, existing behavior which was widely considered as not broken was replaced by a different behavior, often even without an escape hatch. The new behavior(s) in such cases should be made possible, but the default should be the old behavior.

All those examples you gave are possible to disable in systemd, and in the case of DNS and user process after logout, they are not even the default.

: Killing of user process are enabled by default in upstream but disabled by default in every distro that I know. And systemd-resolved, even if it is build by default, is not enabled by default even in upstream.

nine_k5• 6 years ago

Good thing sanity prevails in distro maintainers! But not in upstream, as you duly note.

I also remember that even 2-3 years ago the situation was not as nice yet.

I think what became systemd could have been great software, if not for the, mmm, cavalier attitude of its creators (not necessarily personal; it might be amended by RH corporate deadlines).

TingPing• 6 years ago

resolved has been enabled in Ubuntu for years and in the next Fedora.

sneak5• 6 years ago

It's astounding to me the issues people have with this. systemd's existence doesn't preclude anyone from using the old, pre-systemd ways of doing things. There are thousands of linux distributions, and afaik there are at least a dozen which are primarily defined as never-using-systemd.

Face it: the linux userspace has always sucked. Linus punted on it way-back-when (to be fair, he was a solo dev working on a kernel, he had his hands full) and opted for the gnu tools, but those (other than the compiler and libc and a few other spots like grep) have never been best-in-class. It was always just sort of "good enough" to avoid swimming upstream (no pun intended) and trying to swap them out.

Someone decided to make an attempt at making the situation better in one way, doing things differently. Perhaps it was a mediocre attempt, even. (I'm just speaking for sake of discussion here; I haven't read the systemd code, just making a point.). Still, nobody was forced to use it, and indeed many options for avoiding it exist.

Somehow, this ended in a holy war and corresponding schism. It makes no sense to me. Are linux users upset that someone dared question their decades of suffering under a poorly-designed userspace? Agree or disagree with systemd's decisions, it's hard to fault someone for making and releasing software and offering it as an alternative, even if it sucks.

I'm all for experimentation in this space. The old way of doing things was super janky, and I think systemd is an improvement in a lot of ways. I (thanks to a lot more time stuck in my house) have two recent Gentoo installs, one with systemd and one without. They both work, but one works better.

"This is the way we've always done it" seems in opposition to the hacker ethos, to me. Doing things differently to see if there might be a better way seems like it's always valuable, considering that nobody's deleting /etc/init.d/* from your system if you don't participate.

Traditions are not always inherently valuable. Try new things. Discard the ones that don't work for you.

AnthonyMouse7• 6 years ago

Traditions are not always inherently valuable. Try new things. Discard the ones that don't work for you.

But that's the trouble. The people who make systemd keep integrating it with everything else they make and vice versa, which makes it harder to try new things because instead of things coming in pieces you might replace, it comes as one big interdependent blob.

nine_k5• 6 years ago

I mostly agree with you. I see two sad things:

* Systemd was not exactly great when it had to be considered "the" replaecment for SysV init (which does suck), and happened to be much more than an init system;

* The big distros like CentOS and Debian (and then many smaller) had little choice but to adopt systemd, because Gnome had it as a hard dependency.

It's unfortunate that of all SysV init replacements, the evolution chose systemd. By its spirit, it's very anti-Linux: it's often seen as "monolithic" even though it technically isn't, because it tries to control nearly everything, and it does not mind breaking the old ways when it sees fit (and not when the old ways are broken).

Quite likely, we're stuck with it as a mainstream solution for another decade, or two, much as we're stuck with X. (And in two decades, Linux the kernel may become irrelevant, due to hardware and OS research progress.)

lmm10• 6 years ago

Face it: the linux userspace has always sucked. Linus punted on it way-back-when (to be fair, he was a solo dev working on a kernel, he had his hands full) and opted for the gnu tools, but those (other than the compiler and libc and a few other spots like grep) have never been best-in-class.

Which userspace are you claiming is better then? Linux used to offer the best userland experience in the world, because you had control over every part of it, and since things were loosely coupled you could mix and match at will (e.g. prefer BSD grep or Solaris tar? No problem, install them).

Somehow, this ended in a holy war and corresponding schism. It makes no sense to me. Are linux users upset that someone dared question their decades of suffering under a poorly-designed userspace? Agree or disagree with systemd's decisions, it's hard to fault someone for making and releasing software and offering it as an alternative, even if it sucks.

They didn't build a better alternative and let users choose to adopt it organically. They made a wilfully incompatible, tightly coupled thing, and then pressured other projects to hard-depend on it (e.g. Gnome).

This is quite literally the antithesis of everything that Linux and Unix stands for. The whole reason people were able to use the GNU tools with the Linux kernel is because they are loosely coupled and communicate through standardised interfaces. Systemd by contrast doesn't run anywhere but linux, and you need closely matched versions of everything: your linux has to match your udev has to match your systemd has to match your dbus has to match your gnome has to match your...

If systemd had been around when GNU and Linux were starting out, the whole project would have been literally impossible. It's a betrayal of everything those projects stand for.

novok• 6 years ago

Linux types I've noticed tend to be more holy war orientated. Where did the classic vim vs emacs holy war come from also?

theamk9• 6 years ago

You don't want to use sqlite for logs -- it is way too complex, and in particular, it may roll back (=lose log entries) if it is low on space, and permanently damage data when writing onto disks with errors. It also makes wrong performance tradeoffs for logging -- your choices are either sync() all the time, or roll back on unexpected termination.

I don't like the that journald goes backwards in space and updates indices -- I like "append-only" attribute -- but at least it writes data sequentially one after another, which makes it pretty tolerant of data loss.

As for "without escape hatch", I don't remember any functionality like that? In fact, systemd is full of escape hatches which are documented and supported. Just recently, I had to modify "is computer online" check -- it was amazingly easy, all I had to do was to drop-in a fragment file for the right service. I remember doing the same in upstart -- it was a total pain, requiring reading the source code spread over dozens of undocumented files.

realusername3• 6 years ago

Sqlite is battle-tested though, it has one of the most comprehensive test suite and is used on billions of devices already.

What systemd is doing with this log storage system is reinventing sqlite, because systemd has a fairly new and not battle-tested database implementation, it has shortcomings.

I would argue that either they use plain text logs like before or use sqlite but they should not reinvent a new db.

saati2• 6 years ago

No local logging will work without disk space, and if the disk is bad anything can get corrupted.

pas6• 6 years ago

Linux desktop security was (and largely still is) in shambles. Logind at least tried to force some sanity.

Was is executed well? No, not at all. In typical FOSS fashion it just changed from one release to the other, and that's it.

Yes, there were probably notes about it somewhere in a long forgotten changelog deeplinked 4-5 clicks below the surface of Debian's and Ubuntu's homepage.

Should have they introduced a deprecation period? I don't know, maybe, probably. (But who are "they"? systemd maintainers? Debian/Ubuntu?)

sjwright5• 6 years ago

Another problem is the "I know better" attitude.

All good software is based on this attitude. Wait, I hear you interject. You have examples to disprove this. Well whatever it is you might think isn't the "I know better" attitude is probably just the same "I know better" attitude with one layer of abstraction.

deathcakes• 6 years ago

This, exactly this - I remember one of the most bandied about reasons for the binary log format was that it made replication over the network easier, or something.

Fast forward 10 years and I still cannot find a reliable way to do this with journald, apart from forcing it to output to syslogd and then shipping the syslog logs.

stouset• 6 years ago

I had to build something on top of systemd-journald recently for work. I was prepared for the worst after hearing all of the gripes people have with systemd.

And you know what? It’s fucking awesome. Structured logging is just baked in. I don’t have to parse fields back out that have been smashed into a string. I get full timestamps, machine IDs, pid, uid, gid, and all the rest. I get a cursor that I can use to durably resume consumption of logs between restarts. Shit, the cursor even lets me ensure that I’ve consumed logs even when they’re being aggregated from multiple machines, without a single change to my code.

Sure there are a few warts here and there. Everything has them. But it took less than a week for me to be convinced that it’s past time for plaintext logs to die.

aganame4• 6 years ago

I wish systemd haters would make a public petition to remove systemd from this world. I would absolutely use such a list to make sure I never accidentally hire any one of them for any system administration positions.

dman• 6 years ago

As a person who does not work as a system administrator professionally but does use self administered linux machines as workstations systemd has not brought any new productivity gains but it sure has increased the learning curve.

aganame4• 6 years ago

As a person for whom Linux and BSDs have been a hobby since 1996, I have no idea what you're talking about.

gorgoiler2• 6 years ago

When writing software, it’s comparatively easy to come up with grand new ideas and turn them into lines of code and files filled with modules.

What’s much harder is (1) to expand ones code without coupling everything together (2) present it in a persuasive way that naturally builds a user base.

SystemD feels like the new grad hire who decided the first thing the would do after joining — the opening power play — is to convince the PHB we should rewrite everything in Haskell.

At this point the gentler folk start quietly honing their CVs and sneaking their personal belongings off their desks, one night at a time, in the hope no one notices they are all about to quit.

It felt like Unix systems administration was a haven from this sort of politics — I don’t remember tmux, git, or python trying to push behavior changes on upstream components of the OS[1]. I’m sure it’s why Unix attracted a certain type of personality for so many years and I’m sad to see that changing.

[1] If you are thinking “but those are command line utilities, whereas the init process is a much more specialized case” then I’d encourage you to revisit the Unix principles of every component being a small and simple program! Even init, cron, and login! It’s not some grand ideal to be zealously adhered to: it’s the principles of small components that mean the same OS can run on a quad core Xeon as runs on a $45 network switch.

theamk9• 6 years ago

I think you underestimate how badly the old sysvinit sucked in the world with many good distribution-provided packages.

It was pretty good in the good, old days, where a sysadmin could list every daemon the system runs by heart, but it was breaking apart when you had tons of random packages:

Package X uses "start-stop-daemon" in ini file, so there is no way to get error messages if config file is incorrect. Package B has no disable switch, so you get to stick "exit" in /etc/default. Package C has this weird logging format which cannot be rotated daily, and is not integrated with anything. Package D likes to die and leave PID file around, and then it fails to restart because of that. Package E likes to bury its settings in /etc/init.d/ file, so there are conflicts every time it updates. User A likes to leave their executables on their machine after logout, so we need a cleanup script.

This was seriously getting old -- after you apply a hack after hack, you start wanting something better. There were a few candidates -- upstart, daemontools/runit, systemd. Only two of them actually did the work to add backward compatibility and integrate with upstream. Upstart sucked even worse than systemd. This left only one candidate.

Remember, even if you can claim for Fedora that someone "convinced the PHB", this does not apply to other distros. Debian, Ubuntu, Arch all chose the systemd voluntarily. This is because sysvinit sucks, and no one came up with a better option.

AnthonyMouse7• 6 years ago

What you are missing is that it is possible for two things to be true at once. It is possible for sysvinit to suck and for systemd to suck in entirely different and potentially much worse ways.

It's as though someone is complaining about having to live under the USSR and how bad things are, and then someone responds that the German rocket program has been dismantled and the British never really had much of one and the Americans are doing okay but the fact is that the USSR was the first to put a man into space. As if that justifies everything else they did.

gorgoiler2• 6 years ago

A lot of init problems you describe are very real, but it felt like by the late 00s they had mostly been solved with efforts like linting and standards, as well as LSB init shell functions making init a much more standardized process.

PAM was and still is quite hard to understand but, again, it had enough power and flexibility with @ based includes to allow individual distributions to lay things out sensibly and allow new packages to follow a coherent standard that emerged rather than being forced.

Concurrent init systems helped drive a lot of this, back when there was a sweet spot of Linux complexity increasing faster than processing power could handle. (Nowadays I feel like boot speed is less important, given how many more resources a modern machine has, though it’s still a concern for low resource platforms.)

I guess I’ve just never seen revolution as a solution to hacks and untidiness. Linting, guidelines and policy, with technically compelling reasons to encourage people to follow them have seen much more success, where I’ve seen them deployed, than centralized authority.

jbverschoor• 6 years ago

Exactly. I was immensely frustrated with sysvinit for over 15 years. Jumped over to systemd as soon as it was available on Debian, never looked back, only one had a problem due to symlinking.

kelnos7• 6 years ago

Debian, Ubuntu, Arch all chose the systemd voluntarily.

My understanding (I believe detailed in the article) is that Debian, at least, chose systemd because they were forced to if they wanted a reasonable default GNOME experience for their users. If they hadn't, GNOME would have been missing some features that would have been obvious and jarring.

You can certainly argue that they made the wrong call there, and that they should have pushed back (though arguably by the time Debian got there, that ship had already sailed), but "chose systemd voluntarily" is an incorrect simplification.

vezzy-fnord9• 6 years ago

The problem with this straightforward thesis is twofold: firstly, distribution developers did not have any coherent position on the disadvantages of sysvinit or initscripts; secondly, the problem was mostly an iatrogenic one, as the very attempts to 'solve' or 'reform' it made things even less sustainable.

When it comes to Upstart, it was almost never used except as a wrapper around initscripts. Effectively you booted from Upstart which greedily synthesized all of its 'events' on startup that in turn triggered initscripts, which brought some degree of parallelism and that was about it. The reverse-dependency 'start/stop on' model was too esoteric, and Upstart's state machine brittle. Hilariously enough, the only system to actually use Upstart to its fullest (still does) is ChromeOS.

Prior to systemd and Upstart, as I discuss in chapter 1, distro developers either simply added various preprocessors for initscripts to introduce dependency headers, or they had these vague hunches of 'waiting for Godot' that we could either replace init entirely with D-Bus, put D-Bus interfaces in initscripts, or some other roundabout way that involved grafting D-Bus. Much of this was owing to the 'irrational exuberance' of Linux developers wanting to hotplug the world after 2003-4, but it always remains an on-and-off effort with the people behind it never certain what they want.

Indeed, besides grunt work of optimizing initscripts, I point out that as late as 2009 distros like Debian were still very concerned about LSB-compliance, and that even when they were willing to adopt a new fancy event-driven init like Upstart, it was conditional on reusing tools like insserv to parse LSB headers, and on incorporating initscripts for service management. Also the entire bizarre diversion that the Debian group had of using a Perl script to generate initscripts.

So far as I know, the daemontools approach was never influential. The available dichotomy was between putting lipstick on a pig, and utopian dreaming.

The paradox remains: how can we trust that the same people who did the Wrong Thing so persistently then suddenly turned out and did the Right Thing like they hit jackpot? If anything, 'jackpot' is the right analogy -- it was a fluke. And the same integration failures that were had with sysvinit have now been shifted into wrestling systemd's job model.

"Unification" was a folly, as the distro is still the place that gets its finger pointed at if upstream can't deliver, and upstream insists it's "just" offering a bunch of "modular tools," which ironically was supposed to be the problem to be addressed! Besides, there is still a whole world of Linux devices out there running Busybox, musl, OpenWrt, etc. that are outside the systemd bubble. Or think of all the container images running Alpine (which is also the basis of postmarketOS). Linux is still the same bazaar it always logically must be, but with a new class distinction added to the mix.

Conan_Kudo4• 6 years ago

Remember, even if you can claim for Fedora that someone "convinced the PHB"

If you looked at the discussions that happened during that time (I was there as a Fedora contributor back then, and wow that was a long time ago!), you'll see that we mostly did the change out of weariness of trying to use Upstart features well and failing. And even with that, we delayed it by one release because it wasn't ready during the Fedora 14 development timeframe (it was supposed to be in Fedora 14, we actually launched it in Fedora 15).

StreamBright• 6 years ago

You are describing the downside of bazaar-style development. Init had very little to do with it. The real problem was a non-standard way of writing init scripts. That is the _only_ part that systemd was supposed to solve.

dvfjsdhgfv2• 6 years ago

User A likes to leave their executables on their machine after logout, so we need a cleanup script.

Of all examples you gave, this one is the least convincing reason to introduce this Behemoth on our systems.

x3blah• 6 years ago

Sounds more like the problem is with the packages and a general lack of quality control with respect to the userland than with GNU init. Perhaps that is why BSD projects, which do have some quality control over userland, can still use BSD init.

voldacar• 6 years ago

The parent comment is criticizing systemd, not upholding the virtues of sysvinit. There are more than two init systems out there, and it is possible for sysvinit and systemd to both be bad in their own ways

jiggawatts• 6 years ago

rewrite everything in Haskell.

Yes please!

Pure functional languages are very well suited to declarative configuration, especially where you need significant flexibility not afforded by purely static "data" formats such as YAML or JSON.

ChuckMcM• 6 years ago

The other component here is "where you came from." When I joined Sun there were two very distinct programmer/hacker cultures; the PC and its spawn and "real" computers (mini and mainframe computers) and their OSes.

The cultures were very different, I straddled them with my hobby working being CP/M->PC->Amiga, and my professional work being RSX-11M->TENEX->TOPS20->UNIX.

Linux (and Minix) started out very much being a PC version of UNIX and PC-BSD jumped in there too. But Linus ceded userland to the community and as the community's membership has grown the people who wanted Linux to be the perfect UNIX lost out to the people who wanted Linux to be an open source version of Microsoft Windows.

It appeared to me that the folks who liked UNIX semantics fled to MacOS, although the complaints on that front are getting louder as well. So here we are.

anewvillager• 6 years ago

Why do systemd detractors keep styling it as SystemD? I'm honestly curious.

You know it's written all lowercase, right?

lorenzhs2• 6 years ago

Revelling in their rejection of systemd. It's childish nonsense and a pretty reliable indicator that a person is bitter about it and their comment most likely not worth reading.

BiteCode_dev2• 6 years ago

SystemD feels like the new grad hire who decided the first thing the would do after joining — the opening power play — is to convince the PHB we should rewrite everything in Haskell.

I've seen this scenario played out, and it always fails. The product never ships, of ships in such a bad shape the users have a terrible user experience.

That's not what happened with systemd. It shipped. And after a few iterations, it actually provided a better user experience.

I don't know about sysadmins, but as a simple end user of Ubuntu, systemd is the best user experience I ever had for what matters to me: setuping my services.

It's quite easy to create your unit files, declare service dependencies, stop, restart, and so on. It's declarative, conf is reasonably straighforward to read an understand, documentation is there, and my system boot is stable on laptop and on my servers.

Maybe for "advanced case X", there is problem. Apparently, a lot of power users say there is. But I also know the FOSS community has some people advocating purity over practicality, don't care much about the people with less skills than them, don't understand user friendliness or will fight for their ego. So I have no way to be sure if the problem is real, or just another free software drama.

But at this point I don't care: for the average Joe like me, it's great, and I'm very happy it has been chosen by Centos and Debian as the default.

Apparently nobody in the entire history of init system have managed to provide something decent for, you know, initializing the system. I never heard a herd of devs claiming that one is the fantastic, and they were all terrible to use when I tried.

Well, I don't care for choice in my init system. I want it to work.

And systemd works fine for me.

dijit13• 6 years ago

Well, I don't care for choice in my init system. I want it to work.

We Agree.

And systemd works fine for me.

But it doesn't for me, and I am left with no choice but to suffer with it.

AsyncAwait7• 6 years ago

SystemD

I don't know why, but it bothers me when someone's trying to criticize systemd, without even bothering to get the case right. It smells of not having looked at it any more than to form the run of the mill opinion on systemd, while looking at what came before with healthy dose of romantic nostalgia.

I don't want my init system to be a series of garage-quality bash scripts with slightly different error rate tolerances etc, systemd solves that. I don't want my system to just blindly shut down, even if it's not necessarily safe to do so immediately, systemd solves that.

What systemd critics often miss is that it's also a rather valuable resource manager in general. I know that many would say this should not be part of systemd, but the thing is while that sounds nice, nobody built anything remotely as convenient for Linux as systemd in this area.

It's nice to say what systemd got wrong, but I haven't seen anything actually built that can seriously compete with it.

I now actively avoid distros without systemd, because the admin experience of those distros has generally been much less consistent.

We can all talk about the right way to do things, but unless there's code that's clearly superior to what systemd offers me today, am not interested.

noitpmeder• 6 years ago

My worst gripe with systemd is that I cannot find reliable docs for older versions.

nineteen999• 6 years ago

Right. All we need now is systemd-selfupdated, so that it constantly keeps itself up to date, even through egress filtering firewalls.

fsh3• 6 years ago

Your manpages should match the installed version.

reacharavindh• 6 years ago

God I wish more people used VoidLinux and packaged more and more stuff without needing Systemd. Systemd may be good for some, bad for some. But, it certainly should not be the only way to get things done. We need alternatives.

It’s as if web developers were told now that there is IE, that is prevalent, we can write web apps that only work there ;-)

nyanpasu64• 6 years ago

I don't fully understand systemd, but the technical critique looks interesting and seems to indicate systemd is poorly designed (but I don't understand it all). Anyone else commenting on that?

JdeBP3• 6 years ago

Enjoy https://blog.darknedgy.net/technology/2015/10/11/0/ , by the same author.

k_bx• 6 years ago

Can I just say, from a non-sysadmin perspective, how happy am I that these days I don't have to install something like Supervisord and just use the systemd + journald toolchain. Setup script is just one cp and few systemctl commands (start/stop/enable).

dijit13• 6 years ago

Yeah, that's nice.

I think there's a lot of people who get caught up in the merits of systemd and assume that there's nothing better. Or that the alternative is the old sysvinit which was in dire need of being replaced- but that's not true.

Process supervision is totally feasible in init (just look at runit, Solaris' SMF and MacOS's launchd) even Windows has one.

dvfjsdhgfv2• 6 years ago

A key quote:

As it turns out, there was a little-known Freedesktop-affiliated project called xdg-hostname in 2009 which was a start towards creating such D-Bus “utility daemons” for use in desktop widgets and others, all as a standalone project. Had this been followed through instead of having the utility daemons end up being part of the systemd source tree, a good deal of political acrimony could have been avoided – though at the cost of reducing systemd’s leverage.

That is, if they used xdg-hostname instead, SystemD wouldn't be tightly coupled with Gnome, so users could choose between SystemD and InitV, and all this mess could have been avoided.

Stierlitz• 6 years ago

TLDR: down with sYstemd :]

arh68• 6 years ago

PulseAudio is the only program I've seen really stress my Ryzen. I recommend fixing the default sampling config if you have similar issues.

This is a really entertaining writeup, given the subject matter.

Koshkin2• 6 years ago

My biggest gripe with it is that its name is not ‘sysd.’

keymone• 6 years ago

One thing I’m surprised about in the init wars of past decade(s?) is that in almost half a century of Unix nobody got up and said “why don’t we, instead of bickering about implementation details, come up with single format to declare desired system startup behavior, and then users can pick whichever implementation they like to read and execute that format”?

Can’t be impossible to distill some basics about service startup configuration and dependencies, can it?

Then make it extensible and cry about differences in extension support like we do about per-browser css options, but at least converge on some basics.

AndrewStephens• 6 years ago

I do really appreciate this type of long form, researched blog post. I have no strong opinions on systemd, I've made simple service units and it has worked well enough. Having the history behind the design is a great aid to understanding.

JdeBP3• 6 years ago

Then you will probably enjoy these:

* https://blog.darknedgy.net/technology/2015/10/11/0/

* https://blog.darknedgy.net/technology/2015/09/05/0/

* https://blog.darknedgy.net/technology/2016/01/01/0/

* https://blog.afoolishmanifesto.com/tags/supervisors/

bandrami5• 6 years ago

10 years ago I never had shutdowns hang with "Stop job waiting for PID 10834: 30 seconds... 90 seconds..."

I do now. Regressions are a bad thing.

Systemd, ten years later: a historical and technical retrospective

Related Stories