1y ago

i find it's a great tool.

206 comments

Having sniffed around the Linux community for years, I feel like whatever flaws SystemD has as a computer program are of tertiary importance when faced with the thing that really matters:
The developer of SystemD was mildly rude to some community members that one time. That means he is two hitlers and a stalin wearing a trenchcoat and everything he makes must be utter garbage.
- Yeah they seem to think he "took over" the Linux init process all by himself. Like distro maintainers aren't the ones who made the decision to move to systemd based on technical merits (presumably).
  
  I think people like that view Linux as some kind of fiefdom rather than a community of individuals.
  
  It is on technical merits as you don't see maintainers complaining about systemd, only users who just don't like it for number of randomly picked reasons.
- I interacted with him briefly in a forum but didn't realize who he was until later. He had that a bit of that programmer awkwardness going, but also having such a vocal abd sustained backlash against a major project you've been working on for years has to affect the poor dude pretty heavily.

It's a giant mess of interconnected programs that could theoretically still be disentangled, but in practice never are. It was very quickly and exclusively adopted by pretty much every major distro in a short period of time, functionally killing off any alternatives despite a lot of people objecting. Also, its creator was already pretty divisive even before systemd, and the way systemd was adopted kinda turned that into a creepy hate cult targeted at him.
There's nothing actually wrong with systemd. I personally wish there was still more support for the alternatives though. Systemd does way more than I need it to, and I just enjoy having a computer that only does what I want.
- Am not sure about "giant mess" but indeed it has a lot of moving parts. All that said, systemd is solving tangible problems which is why you will almost never see maintainers complain about it. It's mostly Linux users which by definition oppose any change, Firefox 4 → Firefox 5, Gnome2 → Gnome3, SysV → systemd
  
  "Giant mess" was maybe an uncharitable phrase to use, but it really is a lot of programs that are always used together because trying to mix and match it with other stuff or even just take pieces out is a massive pain in the rear. Again, I don't actually object to systemd. I use it myself because it's so much better supported. It is not always ideal for everything though, and I'm a little sad about the lack of support for other options.
  The idea that Linux users by definition oppose any change is just silly though. We almost all got here by making a big change in how we use computers. Almost any change will be opposed by at least some members of any group. That's just how people are. That's not a special thing about Linux users. Sometimes a change that is overall for the better causes some things to be lost, and saying the people who are unhappy with that "by definition oppose any change" is kinda creepy, if I'm being honest. In particular all of those examples you gave are times people were forced into a change that was not all for the better, especially in the short term, with little notice, and no opportunity to voice their concerns in a more constructive manner. Of course some people complained. It would be weird if they didn't.
- If there were better options then they would have been adopted.
  
  this is a Just World fallacy, assuming the best thing will always be adopted and therefore everything not adopted is worse than [current thing], when it is entirely possible that there are in fact better options
  
  I didn't say there were better options. I didn't say it shouldn't have been adopted. I said it has some drawbacks, wasn't rolled out very well, and I miss having other options even if they aren't as generally useful for everyone, and it is inevitable that some people would complain because of that. That isn't a problem. It's okay to complain sometimes. We all do it.

If you really want the short version:
Systemd was half baked literally when it came out and figuratively as an idea, so much so that there’s already a replacement for it in the works.
A longer version:
Systemd replaced the init script style of boot and process management, which had been in place for decades. init scripts were so simple they could be understood just by looking at the name: the computer is Initialized by Scripts. Systemd was much more complex and allowed many more tools to interact with the different parts of the computer, but people had to learn these tools. Previously all a person had to understand to deal with the computer was how to edit a text file and what various commands and programs did. After systemd a person has to understand how to use the dozens of invocations of systemctl and it’s variants and if they are dealing with a problem, —you know, the only reason a person would ever be dealing with initializing services— they gotta know what’s going on with the text files that systemd uses to run different commands and programs.
So a person who already understood what was going on might rightly say “hey, this systemd thing is just the same shit with different file locations and more to learn”.
People complain about the creator and maintainer of systemd, lennart poettering . Poettering is also the person behind pulseaudio, an powerful but complex audio management daemon in Linux whose name you only recognize because it’s caused you no end of trouble. Pulseaudio was also replaced relatively quickly by pipewire.
The argument could be made (and probably has) that poetterings work is indicative of the problems with foss developers working as employees of major companies with their job responsibilities inclusive of their foss projects. The developer in that situation has an incentive to make big sweeping changes, they’re being paid for it after all, instead of being more careful and measured.
When every big foss maintainer is trying to find a way to justify being paid for it, their projects are never done.
At least poettering is working for Microsoft, ruining windows now…
E: oh my god I forgot about the binary log files! So before (and now), the universal format for log files was plain text. You know, because it’s a log that’s text. Systemd uses binary log files that need a special tool to open and parse. So if you want to look through them on a computer without that tool you’re kinda screwed. Now systemd isn’t the only software package with binary log files, but many people have made the very persuasive argument that it’s not a trait to copy.
E2: actually spelled the man’s name right. Thanks @floofloof@lemmy.ca !
- Pulseaudio was also replaced relatively quickly by pipewire.
  I really wouldn't say that... PulseAudio has been around since like 2004, and PipeWire's initial release was in 2017 (13 years later). I don't think PulseAudio was incorporated into most distros by default until like 2007 or so, but that's still 10 years before PipeWire was even released. PipeWire is only recently becoming the default in popular distros. We've had to deal with Pulse for a long time.
  
  That’s horrifying. I was just writing from memory and resisting pulse for a few years after it was sort of the defacto standard.
- Init scripts were simple? Man you haven't seen a bunch of shitty init scripts then.
  
  Oh man you reminded me of bad init scripts that would prevent you from getting to multi-user login. I hope you remembered your root password so you can get into single user mode!
  
  Simple doesn't mean well done. Badly written code can be simple but still bad
- gayHitler420 taught me something today. thank you for this informative comment
  
  Except it is clearly written by someone who just despises it, and doesn't really know what they are talking about.
  Init scripts were awful... they varied by distro and frequently were the source of odd problems.
  There's a good reason the Linux industry moved away from them to other ways to handle initialisation of the system and service management.
- pulseaudio, an powerful but complex audio management daemon in Linux whose name you only recognize because it’s caused you no end of trouble. Pulseaudio was also replaced relatively quickly by pipewire.
  PulseAudio never gave me trouble but I guess I'm just lucky or some shit. Also PipeWire took forever to come out.
  
  In games after I press button to shoot, animation plays and then eternity later comes shooting sound when animation ends. JACK compared to PA is super responsive in games, direct ALSA reduces lag by additional 15ms.
- init scripts were so simple they could be understood just by looking at the name: the computer is Initialized by Scripts. Systemd was much more complex and allowed many more tools to interact with the different parts of the computer, but people had to learn these tools. Previously all a person had to understand to deal with the computer was how to edit a text file and what various commands and programs did.
  It's complex because it solves a complex problem. before people had to hack that together with complex init scripts, now they can let systemd do the hard work.
  A comment from an Arch Linux' init script maintainer: https://www.reddit.com/r/archlinux/comments/4lzxs3/comment/d3rhxlc/
- lineart pottering
  Lennart Poettering
  
  Ty I’ve spelled his name probably every wrong way in the past.
- Yep, to add on as well as summarized this... Linux has historically had a design methodology of "everything is a file". If your not familear with the implications of this, it means your command line tools just kind of work with most things, and everything is easy to find.
  For instance, there's no "registry / regedit" on Linux... There's just a folder with a config file that the application stores settings in. There's no control panel application to modify your network settings... Just a text file on your OS. Your system logs and startup tasks were also (you guessed it) sinole filea on the system. Sure there might be GUI apps to make these things easier for users, but under the hood it reads and writes a file.
  This idea goes further than you might assume. Your hard drive is a file on the file system (a special file called a block device). You can do something like "mount /dev/sda1 /home/myuser/some_folder" to "attach" the drive to a folder on the system, but that special block device (dev/sda1 in this case) can be read and written to byte by byte if you want with low level tools like dd.
  Even an audio card output can show as a file in dev (this is less the case now with pipewire and pulse), but you used to be able to just echo a raw audio file (like a wav file) and redirect the output to your audio device "file" and it would play out your speaker.
  Systemd flipped this all around, and now instead of just changing files, you have to use applications to specify changes to your system. Want to stop something from starting? Well, it used to be that you just move it out of the init directory, but now you have to know to "systemctl disable something.service", or to view logs " journalctl -idk something.service" I dont even remember the flags for specifying a service, so I have to look it up, where it used to just be looking at a file (and maybe use grep to search for something specific)
  
  Want to stop something from starting? Well, it used to be that you just move it out of the init directory, but now you have to know to “systemctl disable something.service”,
  That is still the case, nothing stops you from manually moving a file and its dependencies into or out of /etc/systemd/system/
  
  Systemd flipped this all around, and now instead of just changing files, you have to use applications to specify changes to your system. Want to stop something from starting? Well, it used to be that you just move it out of the init directory, but now you have to know to “systemctl disable something.service”, or to view logs " journalctl -idk something.service" I dont even remember the flags for specifying a service, so I have to look it up, where it used to just be looking at a file (and maybe use grep to search for something specific)
  not true, SystemD still uses files for this very reason....
  and what is the last time you used the text version of a syslog.8.xz file?
  you are basically complaining that you need to learn how your system works... before you can use it. and there is nothing preventing you from making your own distro that doesn't uses SystemD, or using rSyslog instead of systemd-journal for logging.
  incidentally, to just view the logs its journalctl -xef (see https://man7.org/linux/man-pages/man1/journalctl.1.html for what that means) it will be like the syslog you know.
  want to see the status of a daemon : systemctl status want it for the system systemctl status want to see the logs of only a specific daemon journalctl -xefu . this all, means that its easier to find the logs for diffrent services since there not scattered somewhere in the /var/log dir... (is it in the syslog, does it have its own log file, is it in the kernel log)...
  You are free to setup your system in whatever way you like... but whining about that something works differently is "Microsoft mentality"... lets leave that with them.
  
  Systemd flipped this all around, and now instead of just changing files, you have to use applications to specify changes to your system. Want to stop something from starting? Well, it used to be that you just move it out of the init directory...
  Enable and disable just create symlinks of the "just changing files" files in your example. It tells you this every time you install something that enables a service.
  Want to do it manually? ln -s (or rm the link to "disable" it).
  Want it to happen later in the init sequence? Put the link in a different .target directory.
  All "systemctl enable" does is put the symlink in the target directory that's specified in the Install section of the unit file.
  As for "specifying a service"... Everything is a unit file (yes, file), journalctl -u just means "only show me logs for this unit".
  There's no flag for "specifying a service", you just type in the service name. If there's any ambiguity (eg. unit.service and unit.socket), you type the service name followed by .service
  A flag you might find useful is -g, which means "grep for this string". You can combine this with -u to narrow it down.
  
  Not the really the point of your post but I personally tend to use journalctl -fu something.service. That brings you to the end of the logs for that unit and I get to smile about flipping off systemd.
- The log files only have binary markers within the text. You could run the raw log files through strings and get the plain log files with everything important intact.
  
  Ty! That’s really good to know!
- Pulseaudio was also replaced relatively quickly by pipewire. lets check that, shall we:
  PipeWire: Initial release 20 June 2017; 6 years ago source: https://en.wikipedia.org/wiki/PipeWire
  PulseAudio: Initial release 17 July 2004; 19 years ago source: https://en.wikipedia.org/wiki/PulseAudio
  so "relatively quickly" is a time span of 13 years in your idea.... or the difference between 2004 and 2017.
  if that's your level of detail... your whole "rant" is worthless...
  But lets be generous and look into it,
  init scripts were so simple they could be understood just by looking at the name
  this is blatantly false, for the old system you need to know about runlevels, what they mean, how the half backed init annotations work, and its dependency check works.
  bash
  
  ### BEGIN INIT INFO # Provides: myrec # Required-Start: $all # Required-Stop: # Default-Start: 2 3 4 5 # Default-Stop: # Short-Description: your description here ### END INIT INFO
  you needed special tools to watch if an application actually was running and not crashed, and to keep it running.
  add to that that the difference between systemd.service file and a sysv / init / initd script is more or less the same complexity (just different standards).
  the universal format for log files was plain text false, the universal format for logging was plain text..
  which is currently (slowly) getting replaced with structured logging. (which is objectively better, imho). there are a number of different log formats, most use a binary (compressed) format. logging to plain text was generally only used for the most recent log entries. a binary format for logging, as long as there's is tooling to get it to a (structured) textual output, is better than a pure text log. I mean, if its good enough for MySQL / MariaDB it ought to be good enough for you....
- What is the systemd replacement you mention?
  
  There’s both runit and system6.
- Pottering is also the person behind pulseaudio, an powerful but complex audio management daemon in Linux whose name you only recognize because it’s caused you no end of trouble. Pulseaudio was also replaced relatively quickly by pipewire.
  Powerful? No, JACK is more powerful and was created 2 years before pulseaudio.
  For context back then OSS was primary audio api, and unlike ALSA it did not have software mixing. So sound servers were created. Lots of sound servers, so it was and still it yet another sound server without extra functionality. Meanwhile dmix existed since at least 2001 and JACK allowed route output of one application to input of another.
  At least pottering is working for Microsoft, ruining windows now…
  You know what? I wich him luck.
- Simple fails when complex problem arrives. Declarative approach of systemd daemons allows for more versatile solutions in unified format.

i will never grow tired repeating this: systemd is the best thing that happened to linux in the 10s
- Yeah I agree. It was rolled out pretty early in its development maturity so it undoubtedly left a bad taste in some people's mouths. Overall it's a net positive though. I don't want to go back to the old way.
  
  The.. Old way? remembers back to x86 task segment register documentation while sweating profusely
  
  There are other ways than systemd and initrc

Does too much for one tool (against unix philosophy) and has poor interop with other tools (binary logfiles).
- That's not really true. systemd is split up into many different, independent binaries, and each of those does one job and does it well.
- Linux User when their program does more than IO text streams:
  
  Piping xz into tar is not text stream
- That's not really true. systemd is split up into many different, independent binaries, and each of those does one job and does it well.
  
  Does it really matter if you can't use those independent binaries with any other init system? If you want to use systemd, you pretty much have to take the whole ecosystem.
  
  If I remember correctly, there was a ton of pain configuring a minimal systemd. I am unaware if that has changed much in recent years.
  Here is an old thread talking about it: https://unix.stackexchange.com/questions/150975/what-is-needed-for-a-minimal-systemd-boot-to-launch-getty-on-a-virtual-console
- Btw. The Linux kernel does more than one thing. But monolithic kernels are much better for small student projects that won't be relevant anymore, when Gnu Hurd comes out
  
  when Gnu Hurd comes out
  Any day now...
  
  Monolithic kernels are also generally more performant, compared to micro-kernels, it turns out. A bit counter-intuitive at first but, makes sense when you think about it.
  Micro-kernels in general-purpose OSes suffer from a death of a thousand cuts due to context switching. Something that would be a single callback to the kernel in a monolith turns into a mess of calls bouncing between kernel and user space. When using something like an RTOS where hardware is not likely intended for general-purpose computing, this is not an issue but, when you start adding all of the complexity of user-installable applications that need storage, graphics, inputs, etc, the number of calls gets huge.
  
  Too thick
- Binary log files is my only significant complaint
- Does too much for one tool (against unix philosophy)
  This tired, old argument needs to die already.
  Do you use browser extensions? That breaks unix philosophy too.
  
  You just compared a browser extension and an init system that takes proc id 1. The unix philosophy is about what runs as processes at the system level.
  
  You just compared a browser extension and an init system that takes proc id 1. The unix philosophy is about what runs as processes at the system level.
  
  Adblock does only one thing: blocks ads. Doesn't sound phylosophy-breaking.

I find it incredibly useful - instead of needing to learn a million quirks about the init of every distro they all use the same predictable system now, you learn it's quirks once and those skills transfer everywhere. Hopping from Ubuntu to Debian to Arch to Fedora is trivial now compared to the old days.
That and systemd-boot and systemd-nspawn are awesome.
- Hopping from Ubuntu to Debian to Arch to Fedora is trivial now compared to the old days.
  Another take of this is we're losing diversity which might have some consequences in the future.
  
  Linux has also overshadowed BSD. Diversity matters, but so do standards. Code interaction contracts (think APIs and syscalls) are the glue to make a program that will run on a lot of diffrent software/hardware stacks (like diffrent OSes and hardware combinations). Sadly specific implementation diffrences make the genaric contracts (like UNIX/POSIX) unable to be implemented pefectly.

I LOVE systemd, flatpaks, appimages, wayland, and pipewire. The desktop environment feel way more managed!
Sure, wayland is not complete yet (HDR), flatpak is missing some things (some portals), but the whole ecosystem is way more mature than before.
This is from someone who used init.d scripts, apt-get and dpkg, x.org, and alsa/pulseaudio/gstreamer.
- first sentence i thought you were being ironic
  
  Same, it read like a shitpost on /g/
  
  I agree that Wayland is better than X, but only because X is worse than Satan. If you like X11 better than Wayland, you don't know anything about X.
- Same. It just felt way better than plain old sysvinit and X11.
  
  Liking X11 is illegal here.
- What is gstreamer doing here? Isn't it just a library?
  
  I just remember the problems it gave me back in the day. So much so it earned a spot there.

Binary logs are annoying, but once you get the hang of journalctl, it's not so bad. That is about my only remaining hate for it.
In its early days, it was a serious pain. Its service management was annoying and is still a bit scattered to this day. It has improved a ton, for sure.
Then there was PID 1. Here is a legacy discussion about it as I refuse to talk any more about it these days: https://news.ycombinator.com/item?id=10485131
Above all else, it was kinda forced on us. Most of us were comfortable with sysv already. If I remember correctly, people often said the main dev for systemd could be a real jackass. I have no judgement or experience regarding that though.
- Above all else, it was kinda forced on us. Most of us were comfortable with sysv already.
  And at least for me it solved a problem which didn't exist. Sure, there's some advantages, but when it rolled out it was a huge pain in the rear and caused various problems and made things more complicated for no apparent reason.
- Yeah, I can easily remember the commands to tail the logs because it’s journalctl -fu and I always think “fuck you” as I’m typing that.
- Most of the bolted on services are rather shitty. ResolveD in particular is straight up hot garbage unless the only thing you are comparing it to is nscd. I like shipping all my logs to a centralized service and journald just gets in the way. It feels like they took upstart, bolted on some really crappy daemons,

ya see, when i ssh into a server and i run some commands, sometimes i mess up, see, and i wanna reboot to get the system back to a known state, right
and even if the system is in an unknown or invalid state, right,
i don't wanna wait half a bloody hour for systemd to get tired of waiting for 1m30s countdowns and actually bounce the damn machine, if it bounces at all
and i can't just hold the power button, see, because i'm 2000 miles away from the bloody box
(I did not make that number up, by the way. I once has a hard drive get hot removed while it was mounted, couldn't umount it so I had to reboot, and it confused systemd so bad it took 27 minutes to shut down)
EDIT: aw come on, are you really gonna downvote without leaving a reply?
- how is this any diffrent from SysV scripts hanging and preventing a reboot that way....
  you are blaming SystemD for an issue not part of SystemD, but a generic computing issue...
  and yes, you can still just hard reboot your system with SystemD as @elscallr@lemmy.world has point out....
- Check out systemd's userspace reboot feature, they implemented it to avoid long reboot times on server hardware.
  https://www.phoronix.com/news/systemd-254-Released
  
  That version is too new to be in any stable server distro yet.
- Raising Skinny Elephants Is Utterly Boring.
  It can be done remotely, even over SSH by writing to /proc/sysrq-trigger
- I was wondering why my fedora install took ages to shutdown sometimes and the little googling I did got me nothing. Do i hate systemd now?
  
  Do I hate systemd now?
  No, because that's not specific to systemd.
  I can quite clearly remember the long shutdown times back when Ubuntu was still using Upstart.
  Generally speaking, long shutdown times are an indication of a system issue (e.g. HDD going bad or slow network) or just scripts being written poorly, and could be worked around by changing the timeout value. Systemd defaults to 90 seconds, but you can change that to 30 secs or lower.
  
  Heads up that you can hit [escape] key while booting or shutting down in order to see the console and tell what the computer is actually doing.
  
  I mean. You can fix those with a bit of effort.
- I want init 6 back! It's a reflex to type that.

I use runit on Artix. I wasn't around for the init wars, but dove into the rabbit hole of Debian email exchanges, where lots of shade was thrown around because of suspicions over corporate influence on Linux, and Canonical dropping the ball because of their Licensing on their competitor init, Upstart.
I reviewed videos of Poettering going on about it, adamently placing systemd as the hill he was willing to die on.
I read the Torvaulds email complaining about Kay Sievers being an asshole. Looked at how Kay Sievers famously refused to fix early boot problems with systemd. Read Laurent Bercot's technical break down of why even from a software design level, systemd should be called into question.
Its all interesting, and on my home desktop, I decided to only use Artix, Void, Gentoo, or Devuan over any of the others for as long as I can.
At work, I don't care. Do I wish that runit or s6 was more predominant and widely used? Absolutely. Imho both init systems are just more minimal and their implementations are so solid, they are two of the very few pieces of software I can say are finished. No notes, no new features, and because of the minimal attack surface, barely any security patches have been necessary.
Due to their following of the UNIX Philosophy, both runit and s6's source code can be reviewed in an afternoon, as opposed to systemd which has taken me considerably more time to parse through (though I'll admit systemd has some decent comments in their code that helps out).
But at work, while I have my preferences and opinions, the systemd debate isn't even close to the top of my list on arguments I'd like to have at the work place.
On Lemmy otoh, lol. 😁

Are you using Linux for ordinary daily tasks like browsing, gaming, and coding? Then SystemD is perfect for such systems. No need to use distros that sell the lack of SystemD as their main selling point—it's more trouble than it's worth. Avoid SystemD haters like the plague.
Do you use Linux for enterprise servers? Then SystemD is just one of the options for you, go try all of them out to see what's best for such workflow.

A stop job is running ... 3/180 s
- Then when it gets to 180 it just adds 180 more seconds.
- This is giving me PTSD flashbacks...
- Lol virgin systemd can't even properly kill -9
- Wooow, 180 seconds (which probably won't even get to timeout) when shutting down my computer. My life is ruined forever because I had to wait sooooo much. /sarc
  
  Tell that to my ups battery

Everything everybody else said plus everything with Systemd is just... more complex. With OpenRC, it felt like I could keep all the information I needed to use and administrate it in my head. With Systemd, I have to look stuff up all the time.

I don't get the hate as well. It's great for running services and system administration.

It does things in a way that it's hard to use other init without banning Systemd completely from your repo. And because it has feature and scope creep and causes dependencies to it everywhere, that does not happen once you're on it, too much work. Which most distros are, because at it's time it was either Systemd or SysV scripts.

I simply don't care. I am in a position lucky enough that I can trust distro maintainers, without the need to care about the details, as long as my system behaves as I expect, satisfying my requirements of reliability and stability
- Same, I interact with it so rarely that it could work with fairies and unicorns for all the difference it makes to me.
  I don't know what people do with their machines that they keep poking at the damn thing anyway. For the most part I stay out of systemd's way, it stays out of mine and we're both happy.
  
  it could work with fairies and unicorns
  
  It's C code. There's no fairy dust or rainbow magic involved. You can check the commit logs...
  rapid typing of git rebase and git push --force commands to alter the code history...
- Unless you want to play games. PulseAudio sucks for games.

Roughly speaking, it is because it does not follow the Unix philosophy and proposes to do several tasks making the code very complex and therefore more susceptible to bugs.
- But systemd is not a single tool, nor a single binary, it's a collection of tools.
  
  I believe their retort would be "name one thing systemd does well"
- Don't the Linux kernel or the GNU core utils violate unix philosophy too? Philosophical ideas become outdated, there aren't many presocratics around.
  
  The linux kernel unfortunately does not follow unix philosophy.
  It would be better in various ways if the linux kernel used a micro kernel architecture following the unix philosophy, something Torwalds acknowledged in the past.
  Philosophical ideas being lost does not mean they're outdated.
- As opposed to which other tools that respect Unix philosophy. Philosophy which I might add is severely outdated. That could have been a thing when you have simple command line interfaces but pretty much every application today violates that philosophy and nothing of value was lost.

I'd argue systemd has bad, borderline incorrect design. I didn't like SysV because it caused inconsistencies and hard to understand processes. systemd fixed the inconsistencies but the rest is sort of hacked together bullshit that developers play wackamole with. That hackery is the reason it can't be used in Docker for example. It has a complicated parser for a language that's basically a DSL that doesn't really solve the problem of complexity for the user. It requires a whole slew of random non-sense to work and it feels like stars have to align perfectly for things to function. It encourages bad behavior like making everything socket activated for literally no reason.
Compared to SysV, I'll take systemd. I don't find it ideal at all though. It's serviceable... much like how Windows services are serviceable. S6 is I think what the ideal init would look like. I'm more impressed with it's execline and utilities suite but that's another story.
The only thing I think systemd did right is handling cgroups.
- Struggling to think of what purpose systemd would serve in docker..
  
  https://github.com/just-containers/s6-overlay#the-docker-way
- Some docker containers come with systemd. Of note, the RedHat ubi8-init and ubi9-init containers. Not that they're wonderful and perfectly open, but that it is possible and available.
- OpenRC handles cgroups too AFAIK
- If you think you need systemd in a container, then you don't understand containers
  
  Container is not a chroot

I underatand, but I just don't care. Give me a functioning linux desktop and I will also run your garbage proprietary nvidia software. The alternative is windows, so I have to take what I can get.

For a desktop it's suitable for 99% of what you'd want to do. Might not be the best tool for large servers or something (I really don't know) but I'm sure all that depends on use case.

I don't have anything against systemd that is until I tried void linux for the first time. The working of runit seemed very simple and efficient compared to the complexity of systemd.
I still don't hate systemd, but I just wish it was simpler.
- To be honest systemd is much simpler to me. Create a unit file, define what it depends on, accesses, etc. And you are done.
  
  And most importantly you don't have to deal with things like environment variables or other session state leaking into your startup scripts as you had with all the init script based init systems.
  I seriously do not miss services that worked when starting them from an ssh session but did not work on startup (because e.g. PATH had fewer directories).

I feel like, at this point, it has more than proved itself as a general purpose desktop scheduler. But there are situations where you would want something different but a lot of software depends on it anyway.
I also kinda don't understand the hate toward the project itself, other than hearing some of the technical guidance on it has been a bit arrogant in the past or something. Sounds like sily open source drama to me honestly.

The arguments against systemd come from the same people that love IRC, mailinglists, tiling window managers, split keyboards, don't have a mouse, debug with printf, main arch or gentoo, unironically write RTFM|LMGTFY, call users "lusers", play DnD, think Startrek and/or Star Wars cannot be topped, identify with the portrayed super hackers in media, and are proud of doing things the hard way just to feel some kind of superiority in their life.
Edit: for those who don't get it, I'm obviously not being serious. If you fit this mythical, stereotypical person... uh... good job?
- I doubt there are many (if any) people that fit this oddly specific criteria.
  
  Omega surprising that absolutely nobody in the universe fits the hyperbole.
- hey don't go bundling up us Arch users with Tiling window managers with superhackers. I can hardly spell DNS
  
  Hey, I use hyprland on Arch, and I can spell DNS just fine thank you. Don't bundle me with the systemd haters or any haters for that matter
  
  Lol
- Why are you attacking so many loud majorities at once? Not everyone that likes some of those hates systemd or belittles users for
  
  Except mailinglists lovers. Linux kernel developers hate systemd with every neuron.
- Just because I ran arch with ratpoison and firefox with Vim keybindings because I didn't have a mouse wasn't out of superiority, twas cause I was too poor to afford a mouse at the time.
- Well, I like IRC, ergonomic keyboards, sometimes debug using print commands, use Gentoo (Happy birthday!), play DnD and sometimes have to do things the hard way, and I like systemd, especially as a developer, I can test services right from my user account.
  I think the hate comes from people who just want something to hate.
  
  I meh IRC(no history without bouncers), rarely debug using printf, mostly debug in some GUI, but sometimes in GDB TUI, use Gentoo(HB, Larry the Cow), don't even know DnD rules, don't use systemd and really hate pulseaudio.
- This description literally fits everyone in my team at work and i love it. I m the least nerdy one there and its beautiful.
- debug with printf
  I feel personally attacked.
- It mostly fits me, except the split keyboard and "super hacker". I started with un*x in the 80s and looks more like a 50s yo bearded guy 😂

I only hate it because I can't figure out how to run a blocking script before everything else when a suspend is initiated.
- Do scripts in /usr/lib/systemd/system-sleep/ not block? I've never had one fail to complete before suspend. I had to use one last year to dump debug stats before and after sleep while we were helping debug Cezanne sleep issues.
  
  I guess not because in my attempts to get this working I did put a script there. Does * expansion not work in these scripts? Mind sharing your script if you still have one? I have 3 tabs open to learn systemd when I have time, I did watch a video so far :)

Linux power-users hate it when a tool tries to become a platform.
It breaks the principle of single responsibility and becomes a threat to the evolution of alternatives.
It's pros and cons. Having a platform is better because everyone works together on a single effort. But it also becomes a risk because now everyone depends on a single thing that does too much.
- I can't agree with this comment more.
  A lot of Unix philosophy, at least in the early days, was KISS. Keep it simple stupid.
  Lots of interlocking components, doing one thing, doing it well.
  Systemd turns that philosophy on its head.

You're 10 years too late. We're all on the systemd bandwagon today.
- I've seen some modern hate 🧐
  
  Right, but is it just residual? This topic is interesting but mostly in a historical way now. Of course if you want drama, there's always drama to be found.
  
  I don't know a single admin/devops person working in the field who gives much of a shit anymore, it's just part of the landscape at this point.
- I'm using Devuan on my servers, dont trust systemd there.
  But I live with systemd on the desktop because it's "just" the desktop and there's less logs to analyze.
- OpenRC

It's a pretty bridge, they'd say, but be careful you don't look at the supports. It was built using bad techniques, bad procedures, no coordination and no inspection.
Just cross your fingers as you drive over and hope it doesn't blow up because of its flawed construction.
I find it's a great way to cross the river, today.
- In a quiet village, two monks stood on the bank of a wide river. The older monk asked the younger, "How do you cross this river?"
  The younger monk pointed at the grand bridge a short distance away, "Through that bridge, master."
  The older monk shook his head, "You see a bridge, yet the river flows beneath. In seeking to cross, you are already on the other side. Tell me, where is the true bridge?
  At that moment, the young monk became enlightened, supposedly, because that's how most zen koans end.

What else are you going to do? runnit? 😭

Every new tools (especially those being pushed by big corporations) meets resistance and suspicion. It's a new thing to learn instead of something proven to work, usually more resource-hungry...

I find everything so complicated with systemd.
SysV was just intuitive for me and my knowledge. There was just one directory with all the startup scripts in it. And they were run in their alphanumerical ordner. Just that simple. If I wanted to change the order in which the scripts started, I just had to rename the file. You don't want a script to run at all? Just remove it.
I assume, systemd has many advantages for a knowledged user. But for me, it still is just a hassle.
- I haven't had to debug a bash script since systemd became a thing, so I have a vastly different experience from you.
- And what happened if one of those scripts failed?
  How did your express a dependency of a service on data being mounted?
  Did you ever have to face debugging failing networking via scripts?
  
  I just debuged it like every other of my scripts that failed. Again, I didn't need any special knowledge of the init process, just general (and for me: very limited) knowledge.
  The answer to your other questions: I don't thing I ever did that.
- I think the main difference is that one option is easier for the end user to occasionally take a look at what's happening and debug without needing much context or previous knowledge, while the other is much easier for the actual maintainer to actually keep the thing working properly and predictably, as well as supporting every sort of edge case for their users in advance.
  An exaggerated stupid analogy: "back in the day we had horse carts and if it wasn't moving we could just look at the tires to check if they were stuck in a hole or blocked by some rock, but now with cars there are so many things going on that the tires depend on some internal parts that are connected to an engine that depend on some fuel and there are so many elements that can go wrong in-between that often if the car is not moving it requires someone with very specific expertise to diagnose"
  (analogy is extra stupid because the horse cart is by nature inferior to the car and this is not the case with the init files and systemd, analogy would work better if the cart still had engines and fuel but that operated with the same simplify as the carts tires).

What's up with the username?
- Welcome to the Internet
- They're simply trying to express what an extremely weird and disgusting person they are
  
  Did I do something to personally offend you?

Its overly complicated for some use cases. Its also annoying that some software depends on it.

Pros: Really useful AIO program that does everything Cons: Really useful AIO program that does everything
Great example:
Systemd makes it very easy to bring up DNS with systemd-resolved, and it bridges a gap from the old resolv.conf file and newer DNS standards n stuff.
But then it also means that any alternative DNS clients have to tell resolvd to go away if they want to run, or often times make a systemd service to autostart with systemd and ensure it works perfectly with every possible systemd setup.
There's nothing inherently wrong with this method of having a centralized AIO thing that handles a a lot of stuff for you, but lots of early Linux people preferred the hardcore KISS principle and found it very beneficial to have everything neatly separated and modular with the service manager's job to only start and stop services.
Overall, systemd has been remarkably (and relatively) stable and beneficial which people thought would be impossible back when it became initially popular.

I already know all the fixes and commands for systemd from years if using it.

Good talk on the subject Benno is very engaging
- Here is an alternative Piped link(s):
  Good talk on the subject
  Piped is a privacy-respecting open-source alternative frontend to YouTube.
  I'm open-source; check me out at GitHub.

soystemd lol

As far as i have heard it is because it doesn't adhere to unix philosophy and trie to be more than an init system.
I don't really care as long as it doesn't try to spy and/or force features/settings onto me

I just find it too difficult to use. Id rather learn five well connected simple tools than one massive tool that accomplishes the same thing anyways.

206 comments