6 ms·

Honest question here: why do people hate systemd so much?

embedding-shape 8mo ago
Many of us starting using Linux before systemd was a thing, and you get used to what you use, so when something new appears that are trying (well, in this case "tried and succeeded at") to replace a bunch of stuff, there is a natural push-back against it. I think systemd also took a relatively non-unixy approach, where it's a big stack to adopt, rather than individual programs that work together well. Typically, we prefer the latter instead of the former, so some pushback is because of that too.
- blueflow 8mo ago
  Initially i hated systemd for the change it bought and lennarts behavior, but today I'm wiser. Today i hate systemd for its bad debugability (edit unit & daemon-reload loops), the lockups that happen whenever there is a fifo in the wrong place, and the processes that systemd spawns with no apparent related unit and without means to mask them. And the difficult to disable suspends on machines that never had any business suspending.
  - bandrami 8mo ago
    It's that lack of visibility that still makes me low-key hate it, though it's no longer the part of the modern Linux ecosystem that I hate most so I mostly just accept that it's part of watching a platform I used to really like enshittenate itself.
  - hiciu 8mo ago
    Could you please expand bit more about those processes that systemd spawns without units? Cgroups in Linux kernel, and systemd-cgls tool should let you trace every process to a source
    - blueflow 8mo ago
      ibus and goa both run under dbus.service. I ran into this problem because ibus runs later than setxkbmap and undoes the keyboard settings.
      - hiciu 8mo ago
        OK so those processes are launched not by systemd, but by dbus itself. There's probably a /usr/share/dbus-1/services/org.freedesktop.IBus.service file in your system and if dbus sees something that tries to talk to IBus, and IBus is not running yet, dbus will launch it for you as directed in that file. In it's own namespace unless directed otherwise. There's an optional integration between dbus and systemd, look for SystemdService in man dbus-daemon. IBus does not set it. Perhaps it should. I don't know. > I ran into this problem because ibus runs later than setxkbmap and undoes the keyboard settings. that must've been pain to debug :). I can see on my system that there's a systemd user service that I could launch with `systemctl --user start org.freedesktop.IBus.session.generic.service`, maybe that would work better than on-demand via dbus in your case.
  - direwolf20 8mo ago
    Same here.
- ErroneousBosh 8mo ago
  I started using Unix before Linux was a thing, and BSD-style rc scripts were a pain in the arse. Then along came Linux with its sysvinit-style init scripts, which were a pain in the arse. Now here's systemd with yet another form of init scripts, which are a pain in the arse. Each time there's been an evolutionary shift in how we do things, and systemd works pretty well for the way we use desktop systems now. They're also not terrible for servers once you get used to them. I still find them pretty annoying. Anyway the TL;DR is that computers suck and operating systems suck and init scripts suck and the whole thing sucks, and everything else we've tried is somehow worse than what we have. It makes me want to just go back to fixing tractors. People are really grateful when you show up in the middle of a muddy field at 10pm and fix their tractor.
  - direwolf20 8mo ago
    We should try runit. Too bad Debian relies on systemd...
karel-3d 8mo ago
It was very rough the first few years. It's fine now.
bandrami 8mo ago
Because "Stop Job Running For User 1001: (22s / 90s)" with no indication of which @$%^ing stop job it is is incredibly annoying. And the fact that "systemctl start blahd.service" exits successfully even if blahd didn't actually start because a misconfigured blahd not starting is "correct" makes me want to burn the server room down from time to time. And nondeterministic service initialization is absolutely Broken and Wrong. It's.... fine, mostly. It solved no problems I had and introduced some minor ones I didn't, and offers significantly less visibility, but it's no longer the worst offender in those regards (hello, Wayland!) so I just write it off as another of the many ways the Linux experience has gotten worse over time.
- PunchyHamster 8mo ago
  > And the fact that "systemctl start blahd.service" exits successfully even if blahd didn't actually start because a misconfigured blahd not starting is "correct" makes me want to burn the server room down from time to time. we had tens of thousands of init scripts where we fixed that exact problem with init scripts that were delivered with distro. It's not systemd problem and if anything systemd made it better. > And nondeterministic service initialization is absolutely Broken and Wrong. if your dependencies are wrong but init system works you were just lucky. If you gonna complain, complain about no option to tell machine to shut down in a given time interval which means "my UPS got 5 minutes left pls turn off" is unsolvable under systemd unless you go thru every single unit file in distro and override their timeouts.
  - bandrami 8mo ago
    I mean, 25 years ago I don't think any shop used the distro-supplied init scripts; those were just a skeleton you used to get the system into a state where you could edit them.
- belorn 8mo ago
  In the old time with init scripts you had to figure out where to put all those sleep(10) based on the servers specific hardware and software stack. Far from everything in the initi script blocked execution until they completely finished, and things that previously worked could suddenly stop working if you changed hardware or software. The big difference that created deterministic servers in the past is that you could install the server once and then leave it for 10+ years without doing any updates. People were proud of servers and services with massive uptimes with no patches and no reboots. I only see those now if they either have no internet connection or are locked down containers with very restricted network access.
graemep 8mo ago
Its a new thing to learn. A lot of people like the do one thing well philosophy and systemd is intended to be an entire additional OS layer. People like systemd if they want more uniformity between distros. The systemd developers are not exactly open to suggestions and criticism. Have a look through their issues!
ValdikSS 8mo ago
As my friend said: >If the old h4xx0rs make it easy and convenient so that there is no effort working with the system, their ass will fall off.
noirscape 8mo ago
Ignoring the more stupid reasons why people dislike systemd; there's really only three reasons. The first is just the simple fact that most people don't want to administer their distro as a hobby. Similarly, distro maintainers primarily care about shipping a complete package that they don't need to mess around with too much. Before systemd, every distro had its own bespoke choices in tools and utilities that were wired to work together. Systemd however effectively homogenized all those choices, since almost every major distro settled on systemd. The main difference between distros now is as a result not necessarily the choices the maintainers made, but things like the package manager and the release schedule, so there's less of an incentive to use other distro's. (This isn't some sort of conspiracy, which the dumber arguments against systemd tend to assume; it's just a case where systemd winds up as the easiest choice - systemd has Red Hat backing, wires complicated things together in a way where it works on most novel PC environments that usually require config fiddling when not using systemd and it's just one upstream maintainers have to submit bugs to rather than a ton of different ones. The reasons to pick systemd as opposed to "one million tools" mostly just comes down to systemd being less of a headache for maintainers.) The second is that systemd violates some assumptions on how Linux software is "traditionally" designed. systemd is a PID 1 process, meaning it's job is to start every other process on the system. In regular Linux software design, this would be the only thing systemd does. Systemd does this, but it also provides a massive suite of services and tools for things that, historically, have been relegated to separate tools. It's a big bulky program, that while it is modular, is essentially competing with a bunch of other Linux utilities in ways that aren't really standardized. This combines with point 1, where distro maintainers near universally settled on systemd, and what happens is that a lot of non-systemd tools that do what systemd used to do aren't really being used anymore even though the systemd implementation isn't necessarily better. Finally there is a legitimate, albeit niche, case to avoid systemd. Because it's massive and distro maintainers tend to enable a lot of things in systemd, using it means you're getting a lot of random background processes that use up CPU/memory. If you're constrained by that sort of thing, systemd becomes a pretty inefficient hulk of a program you need to tear out. I do think a lot of the headaches involving systemd would be simplified if the Linux space had any sort of standardization on how to wire it's tooling together, but outside of the POSIX standard (which doesn't really cover this side of things; POSIX is mainly about userspace utilities and APIs, not "how should an OS's system services behave"), there isn't any. People have rose-tinted glasses about wiring together different tiny tools, when the reality is that it was usually a pain in the ass and reliant on config flags, outdated manpages and so on. Just look at the seemingly simple question of "how do I configure DNS on Linux" and the literal 5 different ways in which it can be set since the "standard" proved to be inefficient the moment things get even a little bit more complex than a single network device handling a single connection. (Which sounds like it'd be the case, but may I introduce the concept of wifi?) Systemd being a big program avoids a lot of these issues.
account42 8mo ago
The "my way or the highway" approach. Both how it works and how it was pushed.
ralferoo 8mo ago
For me, I guess several reasons: * Log files aren't where I expect them. I can't just tail the right log file, I have to figure out a load of options to journalctl instead. Its defaults are annoyingly bad and I usually end up having to type long things to limit the range to something useful. * The journal grows massively and is unbounded by default. Many times I set up a machine, and then it runs out of disk space. It's now instinctive for me to now check whether it's /var/log/journal that's using it all. In fact, I just double checked on the machine I happened to be using now, and the journal was 2.2GB. * It's terribly documented, or at least not in the way that's familiar to older UNIX folks. It took me about 30 minutes of googling to figure out how to change the name recorded in the journal, which defaults to the command name in ExecStart (and so was really usefully just unshare in multiple of my services). For anyone that's wondering it's SyslogIdentifier - good luck finding that yourself. It makes sense, but it's woefully under documented anywhere. * Whenever you change files that used to be the end of it, e.g. /etc/fstab, now you have to remember to `sysctl restart systemd-mount` - why can't whatever needs it just watch the file for changes instead? * Too many things just happen in the background that never used to. Just now for instance, I manually unmounted a drive to resize2fs it because I wanted to move the underlying data. Between running e2fsck and resize2fs, systemd had already re-mounted it read/write. Luckily, resize2fs is smart enough to tell you. If I'd been doing the actual task using dd to copy the data elsewhere, I'd have ended up with a corrupted copy. * Just yesterday, I discovered that edits under /etc/network/interfaces.d were just silently ignored, and I had to learn the new systemd way of doing it. I never did figure out how to set the MTU in the configuration either. * The configuration files feels Windows-like and not UNIX-like That said, I've reluctantly started creating systemd services instead of rolling my own init scripts, and it's quite nice not having to copy all the boilerplate from elsewhere and just having a handful of lines of config. But most of the time, I feel like I'm fighting systemd rather than working with it.
- teddyh 8mo ago
  > The journal grows massively and is unbounded by default. Wrong. By default, the journals aren’t even saved to disk. And if you do configure them to be saved to disk, they are limited by default to 10% of the file system size, and at the most 4GiB. > It took me about 30 minutes of googling Just read the manual. Start with systemd.directives(7) and search for what you want, which will direct you to the correct manual page for that setting. > Too many things just happen in the background that never used to. The world is changing. Mounts aren’t static anymore; you must treat a mount just as a running service; run “systemctl stop srv-foo.mount” instead of just yanking out a file system from underneath the feet of any and all services which depended on that mount point. > I never did figure out how to set the MTU in the configuration either. “man systemd.directives”, search for “MTU”. Took maybe two seconds. > Log files aren't where I expect them. > I had to learn the new systemd way of doing it. This, I strongly suspect, is your real problem.
Wilya 8mo ago
In 2015, systemd was a giant, immature and complex galaxy of tools, that came to replace a hacky-but-mostly-stable bunch of shell scripts. It was pushed fast. It came with good ideas and innovations. It also came with security issues, bugs, and lost productivity. The fact that the main guy behind the project has a very... abrasive personality, and that the project got to widespread adoption through political moves more than through technical superiority, turned that dislike into hate. But it's 2025 now, systemd has stabilized now, and I don't really see the point of all this anymore.
- t43562 8mo ago
  That's the way open source works. The people that think there's a point go and fork and those that don't stay put. Linux distros have become extremely complicated IMO. Systemd is not the worst example of this - the packaging systems are hard, things like SeLinux are very annoying. The stability is because companies have spent to make it so. There are enterprise features all over the place etc. This just isn't what all of us necessarily want. I think there's room for distros which can be understood at a technical level - which are composed of units that can be easily replaced that have defined functions.
JCattheATM 8mo ago
I don't hate it but I certainly wish to avoid it for as long as possible. I see no advantages over alternative modern init systems and a ton of disadvantages. I think it's bloated, even if you can disable much of it, I don't care for the binary log format, and I don't want to support something that is encouraging so much dependency and unnecessary inter-connectedness. Not to mention it doesn't have the best security history. In another sense, it seems like Windows at some of its worse. The very same people who used to bitch about the registry now advocate for systemd, which I think is kind of weird.
- direwolf20 8mo ago
  What's your favorite init system?
  - JCattheATM 8mo ago
    I use OpenRC because it's fine and works, I have no issues with it. It has limitations, from memory it can't do parallelization - I'm waiting for s6 to mature so it can work with Alpine, but that's current a work in progress, at least last I checked.
Bender 8mo ago
Those that love it will fight for it. Those that hate it will simply avoid using it. There may be some commercial incentives for IBM/Redhat to push for it. Either way it will always be divisive for a myriad of reasons listed below. Some sysadmins will begrudgingly support it at work and some absolutely love to support it. I have supported it in the enterprise and I use it on gaming machines at home. (CachyOS / Bazzite). My daily drivers, servers both physical and VM will always be without it. (MX Linux / Void Linux / Alpine Linux). I only use mini-PC's these days and all the games I play work great on CachyOS. All the other daily stuff works great on MX/Void and of course running firewalls, NAS and servers on Alpine is about as simple as it gets for me anyway. Bazzite on my laptop found my Brother laserjet instantly and without adding drivers. - Some discussion on the matter [1a][1b][1c]. - Operating systems without systemd [2] [1a] - https://unixdigest.com/articles/the-real-motivation-behind-systemd.html https://unixdigest.com/articles/the-real-motivation-behind-s... [1b] - https://nosystemd.org/ https://nosystemd.org/ [1c] - https://without-systemd.org/wiki/index_php/Arguments_against_systemd/ https://without-systemd.org/wiki/index_php/Arguments_against... [2] - https://without-systemd.org/wiki/index_php/Main_Page/ https://without-systemd.org/wiki/index_php/Main_Page/ P.S. - One Windows machine left and I think it can sense what is coming...
WhereIsTheTruth 8mo ago
If you don't use rust, i hate you, you should use rust, and i'll force rust on you If you don't use systemd, i hate you, you should use systemd, and i'll force systemd on you If you don't use wayland, i hate you, you should use wayland, and i'll force wayland on you If you don't use gnome, i hate you, you should use gnome, and i'll force gnome on you See the pattern?

Many of us starting using Linux before systemd was a thing, and you get used to what you use, so when something new appears that are trying (well, in this case "tried and succeeded at") to replace a bunch of stuff, there is a natural push-back against it. I think systemd also took a relatively non-unixy approach, where it's a big stack to adopt, rather than individual programs that work together well. Typically, we prefer the latter instead of the former, so some pushback is because of that too.

blueflow 8mo ago
Initially i hated systemd for the change it bought and lennarts behavior, but today I'm wiser. Today i hate systemd for its bad debugability (edit unit & daemon-reload loops), the lockups that happen whenever there is a fifo in the wrong place, and the processes that systemd spawns with no apparent related unit and without means to mask them. And the difficult to disable suspends on machines that never had any business suspending.
- bandrami 8mo ago
  It's that lack of visibility that still makes me low-key hate it, though it's no longer the part of the modern Linux ecosystem that I hate most so I mostly just accept that it's part of watching a platform I used to really like enshittenate itself.
- hiciu 8mo ago
  Could you please expand bit more about those processes that systemd spawns without units? Cgroups in Linux kernel, and systemd-cgls tool should let you trace every process to a source
  - blueflow 8mo ago
    ibus and goa both run under dbus.service. I ran into this problem because ibus runs later than setxkbmap and undoes the keyboard settings.
    - hiciu 8mo ago
      OK so those processes are launched not by systemd, but by dbus itself. There's probably a /usr/share/dbus-1/services/org.freedesktop.IBus.service file in your system and if dbus sees something that tries to talk to IBus, and IBus is not running yet, dbus will launch it for you as directed in that file. In it's own namespace unless directed otherwise. There's an optional integration between dbus and systemd, look for SystemdService in man dbus-daemon. IBus does not set it. Perhaps it should. I don't know. > I ran into this problem because ibus runs later than setxkbmap and undoes the keyboard settings. that must've been pain to debug :). I can see on my system that there's a systemd user service that I could launch with `systemctl --user start org.freedesktop.IBus.session.generic.service`, maybe that would work better than on-demand via dbus in your case.
- direwolf20 8mo ago
  Same here.
ErroneousBosh 8mo ago
I started using Unix before Linux was a thing, and BSD-style rc scripts were a pain in the arse. Then along came Linux with its sysvinit-style init scripts, which were a pain in the arse. Now here's systemd with yet another form of init scripts, which are a pain in the arse. Each time there's been an evolutionary shift in how we do things, and systemd works pretty well for the way we use desktop systems now. They're also not terrible for servers once you get used to them. I still find them pretty annoying. Anyway the TL;DR is that computers suck and operating systems suck and init scripts suck and the whole thing sucks, and everything else we've tried is somehow worse than what we have. It makes me want to just go back to fixing tractors. People are really grateful when you show up in the middle of a muddy field at 10pm and fix their tractor.
- direwolf20 8mo ago
  We should try runit. Too bad Debian relies on systemd...

karel-3d 8mo ago

It was very rough the first few years. It's fine now.

bandrami 8mo ago

Because "Stop Job Running For User 1001: (22s / 90s)" with no indication of which @$%^ing stop job it is is incredibly annoying. And the fact that "systemctl start blahd.service" exits successfully even if blahd didn't actually start because a misconfigured blahd not starting is "correct" makes me want to burn the server room down from time to time. And nondeterministic service initialization is absolutely Broken and Wrong. It's.... fine, mostly. It solved no problems I had and introduced some minor ones I didn't, and offers significantly less visibility, but it's no longer the worst offender in those regards (hello, Wayland!) so I just write it off as another of the many ways the Linux experience has gotten worse over time.

PunchyHamster 8mo ago
> And the fact that "systemctl start blahd.service" exits successfully even if blahd didn't actually start because a misconfigured blahd not starting is "correct" makes me want to burn the server room down from time to time. we had tens of thousands of init scripts where we fixed that exact problem with init scripts that were delivered with distro. It's not systemd problem and if anything systemd made it better. > And nondeterministic service initialization is absolutely Broken and Wrong. if your dependencies are wrong but init system works you were just lucky. If you gonna complain, complain about no option to tell machine to shut down in a given time interval which means "my UPS got 5 minutes left pls turn off" is unsolvable under systemd unless you go thru every single unit file in distro and override their timeouts.
- bandrami 8mo ago
  I mean, 25 years ago I don't think any shop used the distro-supplied init scripts; those were just a skeleton you used to get the system into a state where you could edit them.
belorn 8mo ago
In the old time with init scripts you had to figure out where to put all those sleep(10) based on the servers specific hardware and software stack. Far from everything in the initi script blocked execution until they completely finished, and things that previously worked could suddenly stop working if you changed hardware or software. The big difference that created deterministic servers in the past is that you could install the server once and then leave it for 10+ years without doing any updates. People were proud of servers and services with massive uptimes with no patches and no reboots. I only see those now if they either have no internet connection or are locked down containers with very restricted network access.

graemep 8mo ago

Its a new thing to learn. A lot of people like the do one thing well philosophy and systemd is intended to be an entire additional OS layer. People like systemd if they want more uniformity between distros. The systemd developers are not exactly open to suggestions and criticism. Have a look through their issues!

ValdikSS 8mo ago

As my friend said: >If the old h4xx0rs make it easy and convenient so that there is no effort working with the system, their ass will fall off.

noirscape 8mo ago

Ignoring the more stupid reasons why people dislike systemd; there's really only three reasons. The first is just the simple fact that most people don't want to administer their distro as a hobby. Similarly, distro maintainers primarily care about shipping a complete package that they don't need to mess around with too much. Before systemd, every distro had its own bespoke choices in tools and utilities that were wired to work together. Systemd however effectively homogenized all those choices, since almost every major distro settled on systemd. The main difference between distros now is as a result not necessarily the choices the maintainers made, but things like the package manager and the release schedule, so there's less of an incentive to use other distro's. (This isn't some sort of conspiracy, which the dumber arguments against systemd tend to assume; it's just a case where systemd winds up as the easiest choice - systemd has Red Hat backing, wires complicated things together in a way where it works on most novel PC environments that usually require config fiddling when not using systemd and it's just one upstream maintainers have to submit bugs to rather than a ton of different ones. The reasons to pick systemd as opposed to "one million tools" mostly just comes down to systemd being less of a headache for maintainers.) The second is that systemd violates some assumptions on how Linux software is "traditionally" designed. systemd is a PID 1 process, meaning it's job is to start every other process on the system. In regular Linux software design, this would be the only thing systemd does. Systemd does this, but it also provides a massive suite of services and tools for things that, historically, have been relegated to separate tools. It's a big bulky program, that while it is modular, is essentially competing with a bunch of other Linux utilities in ways that aren't really standardized. This combines with point 1, where distro maintainers near universally settled on systemd, and what happens is that a lot of non-systemd tools that do what systemd used to do aren't really being used anymore even though the systemd implementation isn't necessarily better. Finally there is a legitimate, albeit niche, case to avoid systemd. Because it's massive and distro maintainers tend to enable a lot of things in systemd, using it means you're getting a lot of random background processes that use up CPU/memory. If you're constrained by that sort of thing, systemd becomes a pretty inefficient hulk of a program you need to tear out. I do think a lot of the headaches involving systemd would be simplified if the Linux space had any sort of standardization on how to wire it's tooling together, but outside of the POSIX standard (which doesn't really cover this side of things; POSIX is mainly about userspace utilities and APIs, not "how should an OS's system services behave"), there isn't any. People have rose-tinted glasses about wiring together different tiny tools, when the reality is that it was usually a pain in the ass and reliant on config flags, outdated manpages and so on. Just look at the seemingly simple question of "how do I configure DNS on Linux" and the literal 5 different ways in which it can be set since the "standard" proved to be inefficient the moment things get even a little bit more complex than a single network device handling a single connection. (Which sounds like it'd be the case, but may I introduce the concept of wifi?) Systemd being a big program avoids a lot of these issues.

account42 8mo ago

The "my way or the highway" approach. Both how it works and how it was pushed.

ralferoo 8mo ago

For me, I guess several reasons: * Log files aren't where I expect them. I can't just tail the right log file, I have to figure out a load of options to journalctl instead. Its defaults are annoyingly bad and I usually end up having to type long things to limit the range to something useful. * The journal grows massively and is unbounded by default. Many times I set up a machine, and then it runs out of disk space. It's now instinctive for me to now check whether it's /var/log/journal that's using it all. In fact, I just double checked on the machine I happened to be using now, and the journal was 2.2GB. * It's terribly documented, or at least not in the way that's familiar to older UNIX folks. It took me about 30 minutes of googling to figure out how to change the name recorded in the journal, which defaults to the command name in ExecStart (and so was really usefully just unshare in multiple of my services). For anyone that's wondering it's SyslogIdentifier - good luck finding that yourself. It makes sense, but it's woefully under documented anywhere. * Whenever you change files that used to be the end of it, e.g. /etc/fstab, now you have to remember to `sysctl restart systemd-mount` - why can't whatever needs it just watch the file for changes instead? * Too many things just happen in the background that never used to. Just now for instance, I manually unmounted a drive to resize2fs it because I wanted to move the underlying data. Between running e2fsck and resize2fs, systemd had already re-mounted it read/write. Luckily, resize2fs is smart enough to tell you. If I'd been doing the actual task using dd to copy the data elsewhere, I'd have ended up with a corrupted copy. * Just yesterday, I discovered that edits under /etc/network/interfaces.d were just silently ignored, and I had to learn the new systemd way of doing it. I never did figure out how to set the MTU in the configuration either. * The configuration files feels Windows-like and not UNIX-like That said, I've reluctantly started creating systemd services instead of rolling my own init scripts, and it's quite nice not having to copy all the boilerplate from elsewhere and just having a handful of lines of config. But most of the time, I feel like I'm fighting systemd rather than working with it.

teddyh 8mo ago
> The journal grows massively and is unbounded by default. Wrong. By default, the journals aren’t even saved to disk. And if you do configure them to be saved to disk, they are limited by default to 10% of the file system size, and at the most 4GiB. > It took me about 30 minutes of googling Just read the manual. Start with systemd.directives(7) and search for what you want, which will direct you to the correct manual page for that setting. > Too many things just happen in the background that never used to. The world is changing. Mounts aren’t static anymore; you must treat a mount just as a running service; run “systemctl stop srv-foo.mount” instead of just yanking out a file system from underneath the feet of any and all services which depended on that mount point. > I never did figure out how to set the MTU in the configuration either. “man systemd.directives”, search for “MTU”. Took maybe two seconds. > Log files aren't where I expect them. > I had to learn the new systemd way of doing it. This, I strongly suspect, is your real problem.

Wilya 8mo ago

In 2015, systemd was a giant, immature and complex galaxy of tools, that came to replace a hacky-but-mostly-stable bunch of shell scripts. It was pushed fast. It came with good ideas and innovations. It also came with security issues, bugs, and lost productivity. The fact that the main guy behind the project has a very... abrasive personality, and that the project got to widespread adoption through political moves more than through technical superiority, turned that dislike into hate. But it's 2025 now, systemd has stabilized now, and I don't really see the point of all this anymore.

t43562 8mo ago
That's the way open source works. The people that think there's a point go and fork and those that don't stay put. Linux distros have become extremely complicated IMO. Systemd is not the worst example of this - the packaging systems are hard, things like SeLinux are very annoying. The stability is because companies have spent to make it so. There are enterprise features all over the place etc. This just isn't what all of us necessarily want. I think there's room for distros which can be understood at a technical level - which are composed of units that can be easily replaced that have defined functions.

JCattheATM 8mo ago

I don't hate it but I certainly wish to avoid it for as long as possible. I see no advantages over alternative modern init systems and a ton of disadvantages. I think it's bloated, even if you can disable much of it, I don't care for the binary log format, and I don't want to support something that is encouraging so much dependency and unnecessary inter-connectedness. Not to mention it doesn't have the best security history. In another sense, it seems like Windows at some of its worse. The very same people who used to bitch about the registry now advocate for systemd, which I think is kind of weird.

direwolf20 8mo ago
What's your favorite init system?
- JCattheATM 8mo ago
  I use OpenRC because it's fine and works, I have no issues with it. It has limitations, from memory it can't do parallelization - I'm waiting for s6 to mature so it can work with Alpine, but that's current a work in progress, at least last I checked.

Bender 8mo ago

Those that love it will fight for it. Those that hate it will simply avoid using it. There may be some commercial incentives for IBM/Redhat to push for it. Either way it will always be divisive for a myriad of reasons listed below. Some sysadmins will begrudgingly support it at work and some absolutely love to support it. I have supported it in the enterprise and I use it on gaming machines at home. (CachyOS / Bazzite). My daily drivers, servers both physical and VM will always be without it. (MX Linux / Void Linux / Alpine Linux). I only use mini-PC's these days and all the games I play work great on CachyOS. All the other daily stuff works great on MX/Void and of course running firewalls, NAS and servers on Alpine is about as simple as it gets for me anyway. Bazzite on my laptop found my Brother laserjet instantly and without adding drivers. - Some discussion on the matter [1a][1b][1c]. - Operating systems without systemd [2] [1a] - https://unixdigest.com/articles/the-real-motivation-behind-systemd.html https://unixdigest.com/articles/the-real-motivation-behind-s... [1b] - https://nosystemd.org/ https://nosystemd.org/ [1c] - https://without-systemd.org/wiki/index_php/Arguments_against_systemd/ https://without-systemd.org/wiki/index_php/Arguments_against... [2] - https://without-systemd.org/wiki/index_php/Main_Page/ https://without-systemd.org/wiki/index_php/Main_Page/ P.S. - One Windows machine left and I think it can sense what is coming...

WhereIsTheTruth 8mo ago

If you don't use rust, i hate you, you should use rust, and i'll force rust on you If you don't use systemd, i hate you, you should use systemd, and i'll force systemd on you If you don't use wayland, i hate you, you should use wayland, and i'll force wayland on you If you don't use gnome, i hate you, you should use gnome, and i'll force gnome on you See the pattern?