A word about systemd (2016)

https://skarnet.org/software/systemd.html

by tosh • 2 years ago

36 182 2 years ago

skarnet.org

chris_wot• 2 years ago

A central point of their thesis is that Systemd folks bullied others into accepting it.

That's not really the case, though. The Debian folks had a very transparent discussion and vote about using it:

https://www.debian.org/vote/2019/vote_002

o11c2• 2 years ago

Related, it's also blatantly ignoring that it's the first software that even allows interoperability in its space, and was thus in huge demand by both developers and administrators.

(Edit: Other anti-systemd rant sites sometimes mention these obliquely as "upstream dependencies" and "workplace-mandated", while ignoring the fact that those people have reasons to demand those things)

But HN really doesn't need to litigate this all again.

unsnap_biceps• 2 years ago

what do you mean by interoperability?

michaelmrose2• 2 years ago

Upstart and OpenRC both came years prior. As a matter of course anything which was self contained and standardized could have allowed interoperability. Systemd just actually convinced everyone to standardize not least because its integration with other parts of systemd provided both a carrot: standardization and simplicity for distro maintainers and a stick: the extra work required to use only part of it or especially if one used none of it and was expected to both write ones one unit files AND integration with stuff like gnome which was and remains the most popular singular GUI.

yjftsjthsd-h3• 2 years ago

Conformity is not interoperability. If anything, systemd is like Chrome, so popular that it persuades people to drop interoperability outright and just run with its nonstandard APIs.

akerl_15• 2 years ago

I have to wonder if this is some kind of statistical bias based on the type of engagement.

There are some people who are vehemently opposed to systemd, for a variety of reasons with varying degrees of merit. I think it's fair to say that systemd's developers broadly ignored those people, figuring out (correctly) that if they convinced a majority of distribution maintainers, and made the user experience for the average user smooth enough, that was actually going to be successful. As it should be: distro maintainers get to pick how their distros work, and users determine which distros they use.

And systemd has a clear sell for those groups: distro maintainers can standardize their service scripts, often just using what an upstream package author can write agnostically to distro, and users can handle the majority of base system functionality without having to pick things like "which of these cron daemons should I install".

theamk4• 2 years ago

I'd also add that systemd appeals to application developers (no daemon code, one file for all distros). And it appeals to sysadmins too (no more /etc conflicts on any package update! Modify any system service! etc..)

Which brings me to the question of which category systemd does not appeal to? I am guessing "minimalists" and "people who like things done the old way" - and those are simply not that numerous compared to others.

egorfine21• 2 years ago

broadly ignored those people, figuring out (correctly) that if they convinced a majority

So, politics at its worst. Being ignored on a matter, especially when there is merit involved, can make someone a highly motivated hater.

egorfine21• 2 years ago

pick things like "which of these cron daemons should I install".

And we're back at it: systemd seemingly has plans to eliminate cron. I was not impressed when I have been pulling my hair out on why certain jobs in Ubuntu still run despite being removed from cron files. Turns out, systemd now has 'timers'.

So, mark my words: a few Ubuntu releases down the line, cron will become an optional package and after a couple more it won't even be available.

Up next: sudo.

happymellon2• 2 years ago

Didn't Arch also adopt it as the defaults before anyone else.

I can't see that being a project that would be bullied easily. Especially not "bullied so that it was adopted before almost everyone else".

kemotep3• 2 years ago

If you haven’t seen this talk[0], I think it covers in a fair shake the positives, negatives, and what even a post-systemd world would have to deal with.

[0] https://youtu.be/o_AIw9bGogo

favorited2• 2 years ago

It wouldn't surprise me if Benno Rice wrote that talk in response to this exact blog post – though there were enough posts in this same genre at the time, and he could have been responding to any/all of them.

inferiorhuman4• 2 years ago

  a fair shake

Benno's entire argument is that Linux is the only operating system that matters and whatever problems systemd has are irrelevant. Everything else is obsolete. Especially when couched as "look at what this BSD guy thinks of systemd" it's a disingenuous argument. That talk is no more a fair shake than anything to come from Lennart's mouth.

kemotep3• 2 years ago

I would think a BSD developer has a good idea of the challenges facing OS development and the implementation of an init system.

I do not think it is charitable to them to say they think only Linux matters. If that’s the case why are they a FreeBSD developer?

niobe• 2 years ago

This old chestnet eh?

andrewstuart• 2 years ago

> The single, overarching problem with systemd is that it attempts, in every possible way, to do more instead of less.

The more systemd does, the better I like the power, features, consistency and functionality my linux systems have.

systemd is a beautiful work of art.

Software developers owe it to themselves to full understand what systemd has to offer, because if you really understand it then you'll find you can architect your systems around systemd and often let it to the hard work for you.

If anything, the old gnu/linux name should be dropped and replaced with linux/systemd to illustrate that in fact systemd is really a major part of what Linux is.

viraptor2• 2 years ago

I can't tell if it's sarcasm or genuine, but I 90% agree. There's a lot of things that it makes easier. But there are areas which are just weird and overengineered and overcomplicated - for example resolved interacting with old files and creating lots of possible ways it can run. If you look at forums / SO it's obvious people are confused about what it tries to achieve. Instead of creating a whole new system, they could've started by implementing and standardizing the multi-interface behaviour in established projects like dnsmasq. Instead of that they went with NIH where it really wasn't necessary.

theamk4• 2 years ago

For resolve.conf, I think it is fundamentally bad design that is hard to get right. Before systemd, I've spent plenty of time trying to get networkmanager and resolvconf to play together. And then there was those dhcp scripts which would edit the files directly.

Also, what do you mean my "standardizing dnsmasq behaviour?" From my recollection of using it (and from manpage[0]), it's pretty basic. You (1) manually edit /etc/resolve.conf to point to localhost dnsmasq instance (2) use app-specific ways to configure nameservers, in dnsmasq's case it's an ad-hoc list of secondary resolv.conf files specified on command line, with no defaults. I don't think this is worth standardizing, as this scheme cannot even represent network interface -> dns entry associations.

https://thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

vetinari20• 2 years ago

If you look at forums / SO it's obvious people are confused about what it tries to achieve.

Well, many people are confused about how DNS resolving works. Many of do not consider a problem, when they configure their resolv.conf to two different upstreams, each returning different answers (i.e. one responding for domains that the other doesn't) and then wondering, why stuff is broken.

NewJazz• 2 years ago

Is this a bit?

ebcode• 2 years ago

Of course that's a bit of a troll comment at the end there. There are plenty of Linux distros still not using systemd. https://www.devuan.org/ as one example.

egorfine21• 2 years ago

systemd is a beautiful work of art.

This reminds me of teenagers of the last generations who preferred distorted mp3 sound to original because that's the sound they have grew up with. Teenagers of today prefer distorted wide-angle selfies instead of properly shot faces because again that's what they have grew up with.

Calling systemd a work of art gives me the same vibe.

taf2• 2 years ago

I was a systemd hater. I agree with a lot of the post but in practice I need a whole lot less custom scripts, forking code, etc to maintain a simple service whether it’s a custom c binary, go, rust, nodejs , ruby , python… I don’t need to mess with monit(for most things) and yeah in less words then my post here I could have a working service that would both restart on crash and on reboot…. Do I miss the init.d scripts and writing pid files forking twice to change user … no

matheusmoreira6• 2 years ago

writing pid files forking twice to change user

No idea why software tries to "daemonize" anyway. Seems to be some kind of weird tradition. It's always been the wrong thing to do. They should just run normally and output to standard streams even if it's connected to a terminal. The reasons are outlined here:

https://mywiki.wooledge.org/ProcessManagement

Ironically, systemd is one of few service managers which can properly track those weird "daemonizing" processes. It uses Linux's cgroups. It doesn't matter how many times they fork, they can't hide from systemd.

theamk4• 2 years ago

Not sure what exactly you were pointing to, but section "Doing it right" (4.3.1) recommends:

       mydaemon & daemonpid=$!

This is a terrible advice - that's how you end up with all sorts of bad things:

- you ssh'd into server, restarted server, checked it worked. Then you logged out and server got killed.

- your server runs as root or power user

- your server output/error goes somewhere, not clear where

- your server's process got paused by SIGTTOU, because it was trying to write to console

etc...

The complex daemonization dance, with double-forks, closing random FDs, etc.. was required to avoid all this bad stuff before systemd days. Sysvinit/openrc folks came up with "start-stop-daemon" helper, but it was pretty terrible in general, especially in logging department (it had none).

troad• 2 years ago

I get frustrated when people misstate the Unix philosophy.

The Unix philosophy is about function, not form. Say you have a tool to send something over a network. In 1993, that tool can get by being quite simple. In 2024, that same tool now needs to be more complex, just to do the same 'one job' and to 'do it well'.

It's a consistent insistence that the 'single job' be defined today just as it was in 1980 that results in Linux requiring hundreds of packages to be even remotely usable. Oh, you want Wi-Fi? Well, that's not really the job of the networking stack, the job of the networking stack is to connect PDP-11s together...

smaudet3• 2 years ago

The single major flaw with systemd...

Linux was(is?) the system. Shell scripts could configure the system, reasonably well. Systemd meant it was no longer possible to simply fix a linux distro that had it...a massive recompile and intricate understanding of many low level systems was needed.

No, you shouldn't need to know about PDP-11s to fix your buggy wifi, neither should you need to know a massive binary subsystem to configure your wifi either...

So as far as doing its "one job", it did/does it fairly poorly, even today. It is a lot more standard and it does get points from me in that respect, but it fails at being a configurable system completely.

akerl_15• 2 years ago

I've fixed a lot of problems on a lot of systems and never needed to recompile systemd. The majority of them I've fixed by editing text files.

What kinds of problems are you hitting where you need to recompile systemd?

eternityforest3• 2 years ago

I don't think systemd is meant to be fixed or modified, unless you are actually contributing to the upstream systemd project and have accepted that it will be a time consuming project.

It seems to be made for, and works well for, a modern ephemeral infrastructure workflow.

Build stuff to work with an unmodified distro, wipe it and reinstall if it goes wrong.

inferiorhuman4• 2 years ago

  The Unix philosophy is about function, not form. Say you have a tool to send
  something over a network. In 1993, that tool can get by being quite simple.
  In 2024, that same tool now needs to be more complex, just to do the same
  'one job' and to 'do it well'.

Even by that standard scope remains a problem with systemd, it makes emacs look svelte. It's absorbed big pieces like time management and logging that ought not be part of a purported init system.

yjftsjthsd-h3• 2 years ago

Oh, you want Wi-Fi? Well, that's not really the job of the networking stack, the job of the networking stack is to connect PDP-11s together...

WiFi absolutely should be a separate component; the unix philosophy is an excellent defense against servers in a datacenter trying to install a WiFi stack.

vetinari20• 2 years ago

wifi happens to be a separate component; wpa_supplicant or iwl are separate user space tools that network management tools call into; on the kernel side, the drivers and their stack are separate modules.

lotharcable• 2 years ago

There is systemd the init and there is systemd the project.

I counted no less then 64 related executables related to systemd on my system.

Accusing systemd of "not doing one thing and doing it well" is like accusing the GNU project of not following the Unix philosophy.

traverseda• 2 years ago

You think systemd-resolvd does its job well? :p

eesmith• 2 years ago

In 1993, that tool can get by being quite simple. In 2024, that same tool now needs to be more complex, just to do the same 'one job' and to 'do it well'.

1993's sendmail is more complex than qmail. The latter uses a modular system, where each subtool does its job well, rather than sendmail's monolith design.

caeril• 2 years ago

A core part of the Unix philosophy is being able to pipe standard streams between processes, files, sockets, etc, as the user sees fit.

Systemd, particularly journald, violates this severely by snarfing any stream you want to send to /var/log or wherever and locking it in a binary database somewhere, that you have to use journalctl to access.

I have no problem with journald as an idea, but the audacity that it knows better than the user what to do with stdout/stderr is insane, and 100% anti-Unix.

mike_d• 2 years ago

Systemd being one big monolithic system locks you in to, frankly, just a lot of shitty decisions. Take for example the fact that it decides to bind to port 53 on localhost, for absolutely no good reason. Now if your response is that is not a big deal, or you push your glasses up on your nose and want to explain why its important, imagine for a second if it was port 80 or 443.

jdenning• 2 years ago

Exactly - this is a perfect example of what has always bothered me about systemd.

rerdavies3• 2 years ago

Binding a DNS server to 127.0.01:53 is a perfect example of what has always bothered you about systemd? Seriously not getting it.

Providing DNS services on 127.0.0.1:53 has nothing to do with systemd. It's a convention used by NetworkManager, and associated network services. The very good reason being that network interfaces that are being brought up and down can choose to forward their DNS requests to 127.0.0.1, and allow a completely separate unit (resolved?) to deal with the details of where DNS requests get forwarded from there. (Or not, if they so choose).

Was there some OTHER burning compelling use-case that makes you want to use 127.0.0.1:53 for some other purpose?

jauntywundrkind4• 2 years ago

Systemd doesn't.

The systemd monorepo also provides systemd-resolvd which does, but this is optional and last I checked not included or at least started by default on Debian, for example.

the_real_cher12• 2 years ago

Systemd-resolvd is started by default on my Ubuntu distro v24.

wongogue• 2 years ago

Stub resolver for systemd-resolved? Maybe check with what your distribution is shipping.

egorfine21• 2 years ago

I believe systemd-resolved being the absolute worst part of the whole systemd ecosystem and especially the way it's packaged into Ubuntu.

favorited2• 2 years ago

You're right – if I imagine systemd doing something else than what it does, I don't like it!

bigfatkitten4• 2 years ago

I have no real complaints about systemd as an init system. I have plenty to say about systemd not staying in its lane.

systemd's developers have formed a habit of deciding to implement something like an NTP client or DNS resolver, bringing a healthy dose of ignorance of how those services actually work, and then doubling down on their poor design decisions when problems are brought to their attention.

tapoxi• 2 years ago

But that's systemd the project, not systemd the init system. You don't need to use any of those components to use systemd, which has no dependencies on them. Those services can live and die on their own merits.

the_real_cher12• 2 years ago

resolvd was running by default on Ubuntu 24.

I was struggling with it while trying to troubleshoot a VPN connection because resolvd automates resolve.conf into a generated file from several other files and will overwrite any other functionality trying to add resolvers to resolve.conf, like an internal VPN company resolver for example.

Why is systemd even touching DNS?

Seems a little outside of it's scope.

This is kinda crazy to me personally when I found out resolvd was doing this.

https://www.man7.org/linux/man-pages/man8/systemd-resolved.s...

tuna742• 2 years ago

"Why is systemd even touching DNS?"

resolvd != systemd. It seems like you are mad that Ubuntu changed DNS resolver, but isn't that the actual job of a Linux distro?

egorfine21• 2 years ago

I believe systemd-resolved is easily the absolute worst piece of systemd infrastructure. And especially so in Ubuntu! In 24.04 you can get away by uninstalling it then creating a sane /etc/resolv.conf; previous Ubuntu distros required a bit more than that.

vetinari20• 2 years ago

Ideally, with systemd-resolved, you would have only 127.0.0.53 in your resolv.conf. (Anything that reads it directly is broken anyway).

Then you configure your DNS using NetworkManager, on respective connections. I.e. on your VPN, you configure the DNS on the other side of the connection, and (optionally) which zones it is supposed to resolve. (NetworkManager then configures systemd-resolved accordingly). The usage of this DNS then goes up and down together with your VPN connection. That's it.

chasil• 2 years ago

As a previous user/exploiter of SysV init, I really like systemd.

-I can spawn/respawn daemons as someone other than root. SysV inittab runlevels are root-only.

-I used runlevel 4 for all my magic. Now I can have so much more magic.

-nspawn has let me craft containers from day 1.

-Path units are so much better than inotifywait (and somewhat better than incron).

-Do I prefer socket units to inetd? Mostly.

-Free automounter! Yes, crazy syntax, but gratis!

Do I wish it worked on BSD? Yes.

m4634• 2 years ago

I think there are two parts of systemd - the functionality and the implementation.

It IS functional - it does things that are helpful and important.

But the implementation is hard to swallow. It is just so far away from elegant, understandable and usable.

akerl_15• 2 years ago

Can you give some examples of implementation that are hard to understand and use?

miller_joe• 2 years ago

As a declarative process supervisor i really like systemd. I don't like all of the other things it wants to do though.

paradox460• 2 years ago

I was indifferent to systemd until podman shipped quadlet. Now being able to bring up containers, tied to the system, in a reliable and efficient manner, without docker compose or big bespoke commands, has been incredible

rerdavies3• 2 years ago

Trying to compare Windows updates favorably to updates on systemd seems a bit bizarre. I can't ever remember seeing an upgrade ask for a reboot on Raspberry PI OS (debian 12). And I can't ever remember seeing a Windows update that didn't reboot the system.

As a long-time Windows developer (both apps and device drivers) substantially coming to Linux long after the decision to use systemd was made, I am impressed as heck by Systemd.

And was completely horrified by my very limited experience, as a user, with pre-systemd Linuxes. That was insane. Manually edit what in to which system file? And my system invariably didn't even HAVE that file.

Even writing systemd units is virtually effortless.

wannacboatmovie• 2 years ago

systemd is bringing Linux feature parity to Windows NT in the mid-90s. That's 30 years ago for those of you keeping score at home.

Funny the author mentions Solaris because Solaris has SMF and other systemd-similar tools.

Linux pre-systemd looked like a kernel duct taped to a bunch of random thrown-together shell scripts... because it was. A sorry state of affairs that a bunch of very stubborn people were afraid to let go.

The simple fact that configuring networking out of the box is completely different on every distro and sometimes within distros depending on which tools were loaded, in 2024, is simply insane.

wmf• 2 years ago

If you allow distros it's going to lead to diversity. Even Solaris has multiple incompatible distos since they hired Ian Murdock.

matheusmoreira6• 2 years ago

That's what makes Linux great. The entire Linux user space is replaceable. You can trash it all and make your own if you want to. You can trash systemd, write your own program and boot Linux directly into it if that's what you want. And people do, myself included. Not a single other operating system lets you do this. There's always some component that you cannot touch.

I'd rather have the chaos of Linux distributions than the tyranny of "standard" ways of doing things.

vetinari20• 2 years ago

You can trash it all and make your own if you want to.

It is important to note, that if you want to do it, you have to roll up your sleeves and do it. Not to expect free manpower of others to provide it to you.

Or in another words: http://islinuxaboutchoice.com/

egorfine21• 2 years ago

Configuring networking is different not only between distros but also between different versions of a single distro, say, Ubuntu. Every major release lately brings new networking configuration method while abandoning the previous. Is it frustrating? You bet. Thankfully I can still `apt install ifupdown` and it works, but who knows for how long? systemd was optional for a couple of releases as well (`apt install upstart`) but of course not anymore.

vetinari20• 2 years ago

Funnily enough, the network configuration problem is not due to systemd -- which has nothing to do with it -- but with Canonical being Canonical. Someone here has a new toy (netplan), so why not force it on users, with some excuse.

For the same reason, why Canonical forces netplan (consistency between desktop, using NetworkManager and server, using systemd-network), Redhat standardized on NetworkManager instead.

gavinhoward• 2 years ago

I don't like systemd, but I don't like s6 either.

What we need is something simple that uses something easy like unit files. (Though I wouldn't choose the systemd unit file syntax.)

drdaeman• 2 years ago

Unfortunately, there aren't any concrete examples (unless I skipped something accidentally), so it's hard to tell what exactly is meant as "does more" or that it doesn't "stand out of the way" etc.

Yes, systemd services can do a lot of things. Except that before rc scripts did all those things, but without any unified and standardized primitives. systemd provides those for a lot of common use cases - and that's how it ended up doing so much - because our rc scripts used to do that. systemd actually does less because unit files are not scripts (but one can hook any external program in a lot of places, if they need to).

Also, as I understand it, systemd isn't a single piece of software either, it's a whole project with a bunch of semi-autonomous pieces, tied with common conventions and assumptions. It's difficult to define the scope for an umbrella project, and I believe individual pieces all have their scopes relatively well-defined.

matheusmoreira6• 2 years ago

It's basically an integrated redesign of all the low-level userspace of a Linux system

Yes, and that's okay. Whatever it is that came before it sucked so much I don't even remember what life was like before systemd.

Also, it's amazing that we even get to redesign Linux user space like that. That's something special. Not a single other operating system allows you to do this. You could boot Linux straight into your program if you want, without any user space at all. Linux is such a solid foundation it lets you swap out the entire user space, you can trash systemd and even the entire GNU stuff and just do your own thing. It's inspired me to start working on a redesign of my own.

egorfine21• 2 years ago

You could boot Linux straight into your program if you want, without any user space at all.

That was possible from around day one of linux kernel existence.

matheusmoreira6• 2 years ago

Yes. However it's not at all obvious that there is a clean separation between Linux and user space.

You look up the manual entry on some Linux system call and it gives you the glibc documentation. You look up the init system in the manual, expecting details on what the kernel requires of PID 1, and it just gives you systemd documentation. This stuff is completely mixed up.

You look Linux up on Wikipedia and the article eventually starts telling you about standard C libraries as if they were part of Linux. In some articles there's even a diagram showing glibc wrapping the kernel, as if it was Linux's equivalent to the Win32 API.

https://upload.wikimedia.org/wikipedia/commons/4/45/Linux_ke...

In reality, you can trash that entire thing and remake the entire user space in Rust or Zig or Lisp if you want. No libraries are necessary.

rendaw6• 2 years ago

Kind of a non-sequitur, but what is actually the point of systemd (and other similar tools)? Like compared to just spawning a bash processes that run a critical commands in a loop.

I can come up with a couple functions, but none of them seem like core things, more like tangential benefits:

- Startup ordering means you don't get log spam with "can't connect to X" until X starts

- Certain dependencies like mounts look the same whether they're "running" or not, so not starting before the mount is important. Or like, if a program enumerates interfaces or something, making sure all the interfaces exist first (via a dependency). Of course, a program could do its own checks and possibly be more stateless about it.

- As a standard, for packaging - you can distribute a service/socket file with your program and most distros can just plug it in and expect it to work (also thanks to having standard targets and directories).

Otherwise it seems like an ugly declarative DSL for gluing programs together, which you could do in bash or python or whatever other language too. Is reducing log spam really the point? FWIW I do think systemd is better than the alternatives ATM...

akerl_15• 2 years ago

I'm not sure what you're asking.

On any system, something has to start "first", and be in charge of figuring out what the heck happens next. On modern Linux systems (and I'm oversimplifying massively), the hardware hands off to the kernel which launches some kind of init system the first userspace thing. That could be sysvinit or upstart or s6 or systemd or any number of other things. You could write it in any language, though the nature of when it has to launch strongly incentivizes writing it in some kind of compiled language so you aren't having to make sure the right interpreter bits are in place first.

That thing then, depending on its level of complexity, gets to handle things like "what else do I launch" and "what order to I launch it in" and "what do I do if a service I started stops on its own".

Beyond that, your life is way easier if more than one distro uses the same thing to do this, so that an upstream package author can write "this is how an init system launches my service" and distro maintainers can use that, vs having to create and maintain their own scripts for how their init system launches a service.

So, the "point" of init systems is "something has to be in charge of userspace".

rendaw6• 2 years ago

Sorry, I guess my question wasn't "why does the tree need a root process" but "what is the critical feature that makes it worth using these tools instead of the dumbest possible alternative?"

So the dumb response to your questions is if I have a list of services: "what else do I launch?" everything, "what order do I launch it in?" launch it all at the same time, "what do I do if a service I started stops on its own?" restart it. I typoed, but I really meant my first sentence verbatim: suppose init is a bash script that just does:

    (while true; do service1 &> log1.txt ; sleep 5; done) &
    (while true; do service2 &> log1.txt ; sleep 5; done) &
    (while true; do service3 &> log1.txt ; sleep 5; done) &

On a desktop I'm not starting/stopping systemd services ever. Every process I launch is managed by the window manager. On servers it's mostly the same: start everything at boot, then the server does its thing until shutdown. On more traditional mutable SMB shared servers I can imagine sysadmins going in and stopping/starting/adding new systems, but I feel like that use case is gradually growing less important.

It's largely touted that systemd's killer feature is that it represents services as a graph. But why is it important that it operates as a graph? Why is ordering startup important? Or does that not matter, and the real reason systemd matters is that it makes packaging easier (as you said, and as I said) and it has lots of built in conveniences? I have my guesses, but I'd like outside opinions.

slater• 2 years ago

Server seems to have received the ol' HN hug. Archive:

https://web.archive.org/web/20240917143933/https://skarnet.o...

smitty1e• 2 years ago

The author seemed to be arguing at length about some sort of technical shortcomings, as though an argument had been made.

kreetx• 2 years ago

The author also makes it sound like something has been taken away from them - one can rip it out if they really want to. It's just that most of us have our focuses elsewhere and have no need to tinker with systemd.

dang• 2 years ago

A word about systemd - https://news.ycombinator.com/item?id=19077561 - Feb 2019 (17 comments)

LinAGKar• 2 years ago

when said software is process 1 and basically the whole low-level userland layer, it is frightening.

So this is yet another person who apparently thinks all the different daemons made by the systemd project runs in the same process.

Remember sendmail, BIND, INN, and, definitely a better analogy, the early days of Microsoft Windows ?

Honestly, no, I know next to nothing about any of these. Someone wanna fill me in?

raspyberr• 2 years ago

Every time systemd comes up everyone says it's great and how much better it is than SysVinit. No one EVER talks about the actual alternatives that people use like OpenRC, runit, s6.

tmtvl2• 2 years ago

By all means, be the change you want to see. All I know about OpenRC is that it doesn't support user services the same way systemd does. I know even less about runit or s6, so I'd love to hear more from people who use them in their daily computing. Because unfortunately the impression I get from never seeing anyone talk about OpenRC, Shepherd, Upstart, et cetera; is that either nobody uses them, or they don't add anything worth noting over SysVinit.

Though I'm surprised that you say:

Every time systemd comes up everyone says it's great and how much better it is

When my experience is usually that people complain about systemd and it being over-engineered and doing too much and having too many components (yes, I know that those projects are related to systemd, not part of it, I'm just saying what I see people mention as downsides).

graemep• 2 years ago

unfortunately the impression I get from never seeing anyone talk about OpenRC, Shepherd, Upstart, et cetera; is that either nobody uses them

People do use them. Multiple distros either default to one of those, or support it: Alpine, Devuan, MX Linux, Slackware, Void, Guix, Gentoo and others.

or they don't add anything worth noting over SysVinit.

Not looked at this myself, but do they mostly not add something - dependencies, easier config or something?

skydhash• 2 years ago

OpenRC just works for me (Alpine) there’s a declarative side that’s more than enough for simple services, but you can override logic for starting, stopping, reloading,… as it’s just a shell script.

egorfine21• 2 years ago

Here we go again.

I hate systemd. I sincerely and strongly believe it to be the worst thing that happened to the world of Linux. Note: this is just my opinion, of course I'm obviously wrong, can I have it please?

Having said that I have to admit that the battle has been lost and there are no practically suitable server distributions clear from it, let alone desktop. So the only fight worth fighting is to delay destruction of other parts of the OS. In Ubuntu you can easily remove systemd-resolved, get rid of ssh socket activation, bring back cronjobs to crond and install a sane NTP client. Hopefully, we will still have sudo available for many more years at least as an optional package and then as a third-party deb. And thankfully we still have logs in /var/log and journald is not a hard requirement for anything. Yet.

Otherwise resistance is futile as systemd people excel at politics and seemingly no opinion or input has any influence their decision making process.

Again: I'm totally wrong here and systemd is good.

toasteros• 2 years ago

My issue with the "systemd violates the unix philosophy" argument is that it... doesn't. I see systemd-resolved touted as an example of this. systemd-resolved is a different tool to systemd; it does one thing and does it well.

Might as well say GNU violates unix philosophy because it has text processors AND a shell.

A word about systemd (2016)

Related Stories