11 ms·

Without Systemd

81 points by pmoriarty 4y ago

egberts1 4y ago
Still cannot make systemd and FreeDesktop DBUS work together. Notably, Avahi and disabling thereof.
egberts1 4y ago
You do not want systemd for your critical server need. Some problematic things remaining are: - pull an Ethernet cable and watch weird state enter via systemd-networks - your long running custom-made daemon that spent many weeks building up cache goes down when Ethernet link state change It does not enable IP address to stay truly static IP when netlink device goes down. Nor does it leave the IP route table alone. Caveat emptor.
- ungamedplayer 4y ago
  If you are writing custom gear .. that one is entirely on you
egorfine 4y ago
The majority of the hate towards systemd comes from hating Pottering attitude.
capableweb 4y ago
Realistically, is there any better alternatives for a modern personal computer? I'm currently running systemd as I don't know better, and haven't hit any issues, but always keep an open mind for all the pieces in my setup, if there is some better alternative that would give me something better. But looking at the list of alternatives for the `init` (https://without-systemd.org/wiki/index_php/Init/ https://without-systemd.org/wiki/index_php/Init/), it seems like everything stopped updating after 2018, and if that's the case, I'll just go with systemd as it is still receiving updates. Edit: looking at the footer of the wiki, it says "This page was last modified on 17 March 2018" so I guess the jokes on me, the wiki is not being updated very frequently and that's why the release dates are not up to date.
- eesmith 4y ago
  Yes, https://without-systemd.org/wiki/index_php/Special_RecentChanges/ https://without-systemd.org/wiki/index_php/Special_RecentCha... shows the last edit on the site was 19 April 2018.
- LinuxBender 4y ago
  Many of the distros they link to are very much kept up to date. I can vouch for Voidlinux and Alpine Linux. Another one I like that they left off the list of Qubes OS [1] although that needs a fair amount of memory to take full advantage of. [1] - https://www.qubes-os.org/ https://www.qubes-os.org/
- flatiron 4y ago
  If it ain’t broke… If you are going to use Linux at work it will be system d. I use Linux both at home and work so I use systemd. I’ve had exactly 0 issues with systemd and if systemd has a solution for something (like ntp time or efi booting) I just use that. I understand it’s not everyone’s cup of tea and have nothing against peoples personal decisions. It’s just the ship has sailed regarding systemd regarding that most people use it and it’s the industry standard.
  - throw0101a 4y ago
    > If it ain’t broke… And then there's systemd-resolved…
    - vetinari 4y ago
      As if resolving wasn't traditionally broken in Linux and now people are relying on broken behavior.
    - SahAssar 4y ago
      I run resolved and it works for me. That is not to say that is fine for everyone so: resolved and networkd can be replaced if they do not work for you, right? Not sure how it is in ubuntu now (as an example), but when ubuntu started using systemd they did not use either resolved or networkd. They point against systemd would be resolved both being broken and being unable to replace it with another resolver.
unkn0wn_root 4y ago
I would appreciate if anybody would explain why there's so much hate against systemd. I don't get it but maybe I'm just cusual Linux user.
- fsflover 4y ago
  https://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_and_Do_It_Well https://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_a...
- christophilus 4y ago
  I really like systemd, but from what I understand, the folks who don’t like it have a number of gripes. The one that most resonates with me is that systemd is monolithic as opposed to the old Unix philosophy of small, simple tools that compose.
  - frutiger 4y ago
    > systemd is monolithic as opposed to the old Unix philosophy of small, simple tools that compose Isn't the typical Unix kernel that most users interact with a giant monolithic program with some runtime modules but mostly compile time configurability? I think this goes all the way back to the original Unix kernels.
    - rektide 4y ago
      Most users don't interact with the kernel. They interact with a posix (or posix-like) environment. And that is definitely a kalidescope of independent utilities. Most of which are at least somewhat portable across *nix/bsds. To the haters credit, previously the init system itself was also authored with posix-compatible tools. And could be hacked upon easily, readily, without compiling. By compare, you'd kind of need to attach gdb or what not to systemd's pid1 to see what's happening, and it'd be much more complex, and you'd need to be compiling your own systemd to make changes. I'm a huge systemd proponent, but to be honest, it's shocking to me that there's not a bunch of guides to running gdb, to watching systemd do it's thing: we largely are all consumers, accepting systemd's activities/behaviors on faith.
GauntletWizard 4y ago
I'm an SRE, I've done Linux from scratch, and I've built my own alternatives to system management, including "Service Managers" and "Container runtimes" (a fuzzy distinction if ever there was one) Systemd badly needs alternatives. Upstart was a good one, and I wish it hadn't been abandoned. It had a lot of things wrong around it, but Upstart was not all-consuming and it did the one job it was supposed to do - Keep a set of processes alive - well. Systemd is opinionated in every way, and that's fine. But it needs something out there to challenge those opinions. It needs something that will force it to evolve the way users want and not just how it's developers want. Most importantly, it needs the egos involved to be shut down.
- midislack 4y ago
  The alternatives all exist and work fine. Init still works great too. And if you need auto "healing" daemons and such you can even use daemontools. There are a slew of actively developed well supported alternatives you can use today. And it's not so much the opinionated nature of the systemd pushers that's obnoxious, it's the fact that the software is enormous, buggy, and insecure.
  - GauntletWizard 4y ago
    Have you ever read an old init.rc? I suggest you go do so. Daemontools was a reaction to the deficiencies of systemv init, and that it was not getting updated. Initrc has always supported "Run this, and run it again if it exits". That's not quite enough for a modern init system, but it's also not far off. Upstart and systemd capture the few additional things that are necessary. It should be in init's job to run daemons. Perhaps pid 1's only job - all the one-time setup that is required should be executed by another pid1 process before daemons start at all, and then you exec into a parallel daemon runner process.
    - midislack 4y ago
      I've been a Unix user since 1990 kiddo.
dang 4y ago
Related: Without Systemd - https://news.ycombinator.com/item?id=14875452 https://news.ycombinator.com/item?id=14875452 - July 2017 (49 comments) Without Systemd - https://news.ycombinator.com/item?id=9515125 https://news.ycombinator.com/item?id=9515125 - May 2015 (88 comments)
midislack 4y ago
Here's my experience with removing systemd from Debian - DO NOT ATTEMPT. There's a reason the Devuan people have made significant changes to the system and packages. If you don't want systemd it's important to choose a distribution that doesn't increasingly expect it. Don't try to rip it out, that just causes pain to the host (you). You need to treat it by avoiding it.
- b112 4y ago
  I've been running systemd free debian for years. It may be that you hit an edge case, and I bet that was with a display manager most likely? I run sawfish, and trinity, no problems with either...
  - midislack 4y ago
    There has been a difficulty with hibernate to disk with it missing among other issues.
    - b112 4y ago
      There is indeed a conflict between two different packages being used for acpi type stuff. For me, I had to sort it out, to get suspend to ram to work(S3) with my laptop. I'll have a look at my notes shortly...
      - midislack 4y ago
        I have Debian still on my old Thinkpad X40 with systemd removed, it's usable but there are niggles like with ACPI so that it's not useful as a laptop per se. Love that machine. It was my first Thinkpad.
- zajio1am 4y ago
  I use Debian without systemd on both my desktop and some routers/servers and have no issues.
bee_rider 4y ago
I was averse to systemd initially, and held on to my legacy init for as long as I could until my distro totally switched over and just stopped supporting the legacy stuff. At that point, I realized I don't actually want to manage an init system. Which further lead me to the realization that I wasn't actually working with the thing very often, and brought into question my qualifications for having strong opinions on the topic. I see lots of arguments against systemd that, to my untrained eyeball, seem pretty compelling, and lots of groups who are doing the actual, non-hypothetical work who seem to've ignored the arguments and switched over.
- irthomasthomas 4y ago
  I use and develop on devuan. I can't see any reason to add systemD, a so-called init system that uses binaries and extends it's tenticals in to every part of the OS. You aren't running linux anymore, you are running systemD. It is an abomination, and I will never adopt it.
  - kaba0 4y ago
    You didn’t mention any single factual reason to not adapt it. Isn’t the usual unix tools just little binaries? Also, IPC can very easily bloat the problem domain to much harder levels because now you have to deal with (de)serialization as well. So doing the same thing what systemd does with pipes would be an unholy mess.
    - irthomasthomas 4y ago
      I mentioned two, the binaries and the long tentacles. To be clear, I was talking about systemd using binaries in place of plain text LOG files. Both those choices are a huge break from linux philosophy. I expected systemd pros would know I was talking about that. Enjoy your systemd. But don't hate on me for prefering linux.
      - kaba0 4y ago
        What are long tentacles? As for log files, I don’t see how is it different than a pdf or any other standard.
jchw 4y ago
A lot of the arguments about systemd are annoying because they’re either based on things that are simply inaccurate (like many of the jabs about stuffing things into PID 1, done by people who don’t realize systemd-init is just one component,) are based on a super luddite mindset (I really don’t think shitty Bourne shell sysvinit scripts are better than systemd units, TYVM,) or hyperfocus on relatively small points of contention (Usually Poettering’s attitude, which does suck sometimes. Sometimes more specific things like the UID fail-open bug. Sometimes valid but contentious design choices like binary log storage.) Granted. There is plenty of valid criticism against systemd, and when it was first pushed on all of us I was among the angsty annoyed people. However, I also don’t care that much about init systems, so if it was gonna work it was gonna be fine for me. Systemd today works quite well. It’s a more complete replacement for many of the components it replaces. It has a handful of annoying behaviors, but it also does a lot of things quite well. I really like socket-activated units. User systemd works OK for me too. systemd-networkd is pretty good for systems that don’t need NetworkManager. I initially had some issues with logind, but today it does roughly what I want it to. (Desktop Linux is the only OS that gives me the actual behavior I want with sleep on lid close: it does it only when the last external display is disconnected. I have written software to try to get similar behavior in Windows.) My remaining complaints: - I dislike the way systemd is pushing the world towards dbus even more. Not every UNIX like ships dbus by default and not everyone wants it. It is flawed in some ways and it is terrible that it is being imposed as a boundary for all kinds of system services in a way that will take ages to break free from. - I dislike that instead of building more generalized interfaces or working into existing frameworks, systemd’s interface is quickly becoming a major part of the desktop Linux ABI. Major projects increasingly depend on it, working poorly or not at all without it. - Generally just RedHat not caring about the former concerns as a whole makes me not like their control over the ecosystem. I’m glad somebody takes the mantle of trying to push desktop Linux forward, but I really have a strong dislike towards RedHat in general, and things that are perceived as highly influenced by RedHat. GNOME’s CSD initiative is the worst thing that has ever happened to desktop Linux and libdecor is an ongoing failure of a solution years later. No offense to the folks who painstakingly work to make it happen, but I’m not sorry, it’s crap. My opinion hasn’t changed even slightly since day one. (Though almost all Wayland compositors outside of GNOME’s support server side decorations, so you could always give GNOME users decorations that let them know how you feel ;)
linsomniac 4y ago
From list of reasons: "immaturity and instability" I dunno, I've been running systemd on Ubuntu across over 100 machines for ~5 years and I can't agree with either of those points.
- d0mine 4y ago
  It is likely phrase from years ago 2015? when it may have been true https://news.ycombinator.com/item?id=9515125 https://news.ycombinator.com/item?id=9515125
sylware 4y ago
I run my own custom linux based distro. I run a minimal init process and my desktop rig is inited by a brutal and beyond idiotic sh script. What's long is the EFI bios init, and displayport programing, namely everything is done in a matter of very few seconds. Anything more complex would be grotesque.
deleted 4y ago
[deleted]
akagusu 4y ago
I really sympathize with people who try to avoid systemd but I think it is a futile exercise. Every piece of software these days assume you are running systemd and make your life miserable when you try not rely on systemd, and sometimes, it is even not possible to run without systemd at all. Unfortunately, people don't remember how was the systemd adoption and why it was so controversial. systemd was promoted as a init system, but in reality, it is more than that, it is a suite of software; we have journald, firewalld, udevd, logind, networkd, resolved and many more. People forgot how systemd was forced to everybody when Gnome made systemd-logind a hard dependency and logind was extracted to elogind so people could initialize their desktop without using systemd. The same happened with udev, forcing Gentoo to fork it into eudev to avoid systemd dependency. People complaint about portability and compatibility because you cannot interact with systemd-* without systemd; you are coupled. The problem is not systemd as a software, is the attempt to hijack the entire ecosystem, replacing existing services with services dependents of systemd, forcing systemd adoption. And the question I ask to you is: who is behind this?
- kaba0 4y ago
  You forget the tiny bit of detail how the absolute majority of the linux world voted in favor of systemd, often literally. Debian for example had multiple votes (in a system much more democratic than what we are used to in politics) on the issue where systemd won hands down in each case. Arch got to the same conclusion independently. You know, the actual people that have to maintain packages, so they actually know what does it entail. So you can’t even claim that they don’t know what they voted on. So if you call the democratic absolute majority’s choice hijacking, I have to believe you are the one doing the pushing.
- viraptor 4y ago
  > Every piece of software these days assume you are running systemd and make your life miserable when you try not rely on systemd This is silly. Apart from desktop environments, barely anything cares about what session manager is being used. There's no connection between almost every software these days and the init system.
- eternityforest 4y ago
erulabs 4y ago
I think the anti-systemd crowd hurts its arguments (which I tend to agree with at least in spirit) when they throw out stuff like accusing the authors of systemd of being "Ignorant of fundamental operating system concepts" (https://without-systemd.org/wiki/index_php/Arguments_against_systemd/#Ignorance_of_fundamental_operating_system_concepts https://without-systemd.org/wiki/index_php/Arguments_against...). You can dislike the author and the project and the design, but that's just a foolish thing to say that makes it difficult to take any of the other (potentially valid) arguments seriously.
- gnulinux 4y ago
  I checked both of those arguments and wasn't convinced. First link demonstrates an email by Poettering claiming checksums won't fix anything useful. Clearly he's talking about a specific usecase of checksums and not talking about the whole idea of using checksums to recover data. He was asked about a specific feature in systemd, there is no reason to believe he'd want to bring up anything bigger. So implying he doesn't know RAID... is simply absurd and childish. He could have referred that person to RAID; but that'd be completely off-topic. Second link is about a feauture request where someone wants a complete machine login functionality from machinectl unlike su. Then, Poettering explains why this situation exists (because su doesn't inherit cgroups) and then they go ahead and implement the desired feauture. Original user says "it works perfectly". Now, the criticism seems like Poettering calling "su" broken since cgroups were introduced after su. This doesn't make any sense. Of course this is a problem of su. If there are two tools: ssh and su, and they perform a certain task differently and one of the behaviors causing problem, clearly it's relevant to mention su's method is flawed and a more complete implementation can be written (and then they went ahead an wrote it). Bizarre. Another day of reading tons of anti-systemd material for me, and another day of realizing systemd is a perfectly ok piece of software yet there is an odd internet obsession against it.
my69thaccount 4y ago
Even if systemd was great software it would be a bad idea to use it. It's just an attempt for Red Hat to corner the market with embrace, extend extinguish.
codedokode 4y ago
I don't think the idea of systemd is wrong. Long time ago out of curiosity I decide to learn how the boot process works and examined the code. It turned out, the init system was written as a bunch of shell scripts. Its creators probably tried their best to write it, gave functions good names, left comments sometimes, but still it was bad. Running several subprocesses to split a string into parts. Parsing text output of subprocesses. Creating unnecessary temporary files. This style of programming leads to extremely fragile systems. If the command slightly changes its output, scripts will break. If the command output depends on locale, scripts will break. Futhermore, there is no sane options for error handling in shell scripts. There is only a relatively sane option - crash on any error and an insane option - ignore any erros and continue. For example, we failed to backup a file, but ignore this error and delete the original. No way one can write something reliable using such tools. So if you want to write an init system, I think there are better languages that a shell script. It is difficult to build a graph of services and find an optimal sequence to start them using shell scripts. Or implement lazy startup of non-critical services. Init system is not only a program to boot the system, but it should provide some runtime services, like management of background processes, logins and other things. Again, a properly written daemon with an API is better than a bunch of shell scripts. Regarding languages, I am not sure if C is good for this purpose, it's pretty awful too. To illustrate this, consider a C function declaration: int set_working_directory(char *new_directory, char **error); You cannot figure out how to call this function properly without documentation or examining the code. Instead of C I would choose something like Swift, D, Go (but it has pointers), maybe Rust (but writing in Rust for me is mostly struggling against borrow checker). I would choose something that's easy to read, test and verify and has a package manager. So if you don't like systemd, consider writing your init system using one of the languages above. But please don't use shell scripts anymore.
- d0mine 4y ago
  Shell is not the best language for complex programs but it does not justify the kitchen sink approach taken by systemd. It looks like an example of corporate bullying vs. open-source community and the corporate won.
  - 4y ago

81 points by pmoriarty 4y ago

Still cannot make systemd and FreeDesktop DBUS work together. Notably, Avahi and disabling thereof.

You do not want systemd for your critical server need. Some problematic things remaining are: - pull an Ethernet cable and watch weird state enter via systemd-networks - your long running custom-made daemon that spent many weeks building up cache goes down when Ethernet link state change It does not enable IP address to stay truly static IP when netlink device goes down. Nor does it leave the IP route table alone. Caveat emptor.

ungamedplayer 4y ago
If you are writing custom gear .. that one is entirely on you

egorfine 4y ago

The majority of the hate towards systemd comes from hating Pottering attitude.

capableweb 4y ago

Realistically, is there any better alternatives for a modern personal computer? I'm currently running systemd as I don't know better, and haven't hit any issues, but always keep an open mind for all the pieces in my setup, if there is some better alternative that would give me something better. But looking at the list of alternatives for the `init` (https://without-systemd.org/wiki/index_php/Init/ https://without-systemd.org/wiki/index_php/Init/), it seems like everything stopped updating after 2018, and if that's the case, I'll just go with systemd as it is still receiving updates. Edit: looking at the footer of the wiki, it says "This page was last modified on 17 March 2018" so I guess the jokes on me, the wiki is not being updated very frequently and that's why the release dates are not up to date.

eesmith 4y ago
Yes, https://without-systemd.org/wiki/index_php/Special_RecentChanges/ https://without-systemd.org/wiki/index_php/Special_RecentCha... shows the last edit on the site was 19 April 2018.
LinuxBender 4y ago
Many of the distros they link to are very much kept up to date. I can vouch for Voidlinux and Alpine Linux. Another one I like that they left off the list of Qubes OS [1] although that needs a fair amount of memory to take full advantage of. [1] - https://www.qubes-os.org/ https://www.qubes-os.org/
flatiron 4y ago
If it ain’t broke… If you are going to use Linux at work it will be system d. I use Linux both at home and work so I use systemd. I’ve had exactly 0 issues with systemd and if systemd has a solution for something (like ntp time or efi booting) I just use that. I understand it’s not everyone’s cup of tea and have nothing against peoples personal decisions. It’s just the ship has sailed regarding systemd regarding that most people use it and it’s the industry standard.
- throw0101a 4y ago
  > If it ain’t broke… And then there's systemd-resolved…
  - vetinari 4y ago
    As if resolving wasn't traditionally broken in Linux and now people are relying on broken behavior.
  - SahAssar 4y ago
    I run resolved and it works for me. That is not to say that is fine for everyone so: resolved and networkd can be replaced if they do not work for you, right? Not sure how it is in ubuntu now (as an example), but when ubuntu started using systemd they did not use either resolved or networkd. They point against systemd would be resolved both being broken and being unable to replace it with another resolver.

unkn0wn_root 4y ago

I would appreciate if anybody would explain why there's so much hate against systemd. I don't get it but maybe I'm just cusual Linux user.

fsflover 4y ago
https://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_and_Do_It_Well https://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_a...
christophilus 4y ago
I really like systemd, but from what I understand, the folks who don’t like it have a number of gripes. The one that most resonates with me is that systemd is monolithic as opposed to the old Unix philosophy of small, simple tools that compose.
- frutiger 4y ago
  > systemd is monolithic as opposed to the old Unix philosophy of small, simple tools that compose Isn't the typical Unix kernel that most users interact with a giant monolithic program with some runtime modules but mostly compile time configurability? I think this goes all the way back to the original Unix kernels.
  - rektide 4y ago
    Most users don't interact with the kernel. They interact with a posix (or posix-like) environment. And that is definitely a kalidescope of independent utilities. Most of which are at least somewhat portable across *nix/bsds. To the haters credit, previously the init system itself was also authored with posix-compatible tools. And could be hacked upon easily, readily, without compiling. By compare, you'd kind of need to attach gdb or what not to systemd's pid1 to see what's happening, and it'd be much more complex, and you'd need to be compiling your own systemd to make changes. I'm a huge systemd proponent, but to be honest, it's shocking to me that there's not a bunch of guides to running gdb, to watching systemd do it's thing: we largely are all consumers, accepting systemd's activities/behaviors on faith.

GauntletWizard 4y ago

I'm an SRE, I've done Linux from scratch, and I've built my own alternatives to system management, including "Service Managers" and "Container runtimes" (a fuzzy distinction if ever there was one) Systemd badly needs alternatives. Upstart was a good one, and I wish it hadn't been abandoned. It had a lot of things wrong around it, but Upstart was not all-consuming and it did the one job it was supposed to do - Keep a set of processes alive - well. Systemd is opinionated in every way, and that's fine. But it needs something out there to challenge those opinions. It needs something that will force it to evolve the way users want and not just how it's developers want. Most importantly, it needs the egos involved to be shut down.

midislack 4y ago
The alternatives all exist and work fine. Init still works great too. And if you need auto "healing" daemons and such you can even use daemontools. There are a slew of actively developed well supported alternatives you can use today. And it's not so much the opinionated nature of the systemd pushers that's obnoxious, it's the fact that the software is enormous, buggy, and insecure.
- GauntletWizard 4y ago
  Have you ever read an old init.rc? I suggest you go do so. Daemontools was a reaction to the deficiencies of systemv init, and that it was not getting updated. Initrc has always supported "Run this, and run it again if it exits". That's not quite enough for a modern init system, but it's also not far off. Upstart and systemd capture the few additional things that are necessary. It should be in init's job to run daemons. Perhaps pid 1's only job - all the one-time setup that is required should be executed by another pid1 process before daemons start at all, and then you exec into a parallel daemon runner process.
  - midislack 4y ago
    I've been a Unix user since 1990 kiddo.

dang 4y ago

Related: Without Systemd - https://news.ycombinator.com/item?id=14875452 https://news.ycombinator.com/item?id=14875452 - July 2017 (49 comments) Without Systemd - https://news.ycombinator.com/item?id=9515125 https://news.ycombinator.com/item?id=9515125 - May 2015 (88 comments)

midislack 4y ago

Here's my experience with removing systemd from Debian - DO NOT ATTEMPT. There's a reason the Devuan people have made significant changes to the system and packages. If you don't want systemd it's important to choose a distribution that doesn't increasingly expect it. Don't try to rip it out, that just causes pain to the host (you). You need to treat it by avoiding it.

b112 4y ago
I've been running systemd free debian for years. It may be that you hit an edge case, and I bet that was with a display manager most likely? I run sawfish, and trinity, no problems with either...
- midislack 4y ago
  There has been a difficulty with hibernate to disk with it missing among other issues.
  - b112 4y ago
    There is indeed a conflict between two different packages being used for acpi type stuff. For me, I had to sort it out, to get suspend to ram to work(S3) with my laptop. I'll have a look at my notes shortly...
    - midislack 4y ago
      I have Debian still on my old Thinkpad X40 with systemd removed, it's usable but there are niggles like with ACPI so that it's not useful as a laptop per se. Love that machine. It was my first Thinkpad.
zajio1am 4y ago
I use Debian without systemd on both my desktop and some routers/servers and have no issues.

bee_rider 4y ago

I was averse to systemd initially, and held on to my legacy init for as long as I could until my distro totally switched over and just stopped supporting the legacy stuff. At that point, I realized I don't actually want to manage an init system. Which further lead me to the realization that I wasn't actually working with the thing very often, and brought into question my qualifications for having strong opinions on the topic. I see lots of arguments against systemd that, to my untrained eyeball, seem pretty compelling, and lots of groups who are doing the actual, non-hypothetical work who seem to've ignored the arguments and switched over.

irthomasthomas 4y ago
I use and develop on devuan. I can't see any reason to add systemD, a so-called init system that uses binaries and extends it's tenticals in to every part of the OS. You aren't running linux anymore, you are running systemD. It is an abomination, and I will never adopt it.
- kaba0 4y ago
  You didn’t mention any single factual reason to not adapt it. Isn’t the usual unix tools just little binaries? Also, IPC can very easily bloat the problem domain to much harder levels because now you have to deal with (de)serialization as well. So doing the same thing what systemd does with pipes would be an unholy mess.
  - irthomasthomas 4y ago
    I mentioned two, the binaries and the long tentacles. To be clear, I was talking about systemd using binaries in place of plain text LOG files. Both those choices are a huge break from linux philosophy. I expected systemd pros would know I was talking about that. Enjoy your systemd. But don't hate on me for prefering linux.
    - kaba0 4y ago
      What are long tentacles? As for log files, I don’t see how is it different than a pdf or any other standard.

jchw 4y ago

A lot of the arguments about systemd are annoying because they’re either based on things that are simply inaccurate (like many of the jabs about stuffing things into PID 1, done by people who don’t realize systemd-init is just one component,) are based on a super luddite mindset (I really don’t think shitty Bourne shell sysvinit scripts are better than systemd units, TYVM,) or hyperfocus on relatively small points of contention (Usually Poettering’s attitude, which does suck sometimes. Sometimes more specific things like the UID fail-open bug. Sometimes valid but contentious design choices like binary log storage.) Granted. There is plenty of valid criticism against systemd, and when it was first pushed on all of us I was among the angsty annoyed people. However, I also don’t care that much about init systems, so if it was gonna work it was gonna be fine for me. Systemd today works quite well. It’s a more complete replacement for many of the components it replaces. It has a handful of annoying behaviors, but it also does a lot of things quite well. I really like socket-activated units. User systemd works OK for me too. systemd-networkd is pretty good for systems that don’t need NetworkManager. I initially had some issues with logind, but today it does roughly what I want it to. (Desktop Linux is the only OS that gives me the actual behavior I want with sleep on lid close: it does it only when the last external display is disconnected. I have written software to try to get similar behavior in Windows.) My remaining complaints: - I dislike the way systemd is pushing the world towards dbus even more. Not every UNIX like ships dbus by default and not everyone wants it. It is flawed in some ways and it is terrible that it is being imposed as a boundary for all kinds of system services in a way that will take ages to break free from. - I dislike that instead of building more generalized interfaces or working into existing frameworks, systemd’s interface is quickly becoming a major part of the desktop Linux ABI. Major projects increasingly depend on it, working poorly or not at all without it. - Generally just RedHat not caring about the former concerns as a whole makes me not like their control over the ecosystem. I’m glad somebody takes the mantle of trying to push desktop Linux forward, but I really have a strong dislike towards RedHat in general, and things that are perceived as highly influenced by RedHat. GNOME’s CSD initiative is the worst thing that has ever happened to desktop Linux and libdecor is an ongoing failure of a solution years later. No offense to the folks who painstakingly work to make it happen, but I’m not sorry, it’s crap. My opinion hasn’t changed even slightly since day one. (Though almost all Wayland compositors outside of GNOME’s support server side decorations, so you could always give GNOME users decorations that let them know how you feel ;)

linsomniac 4y ago

From list of reasons: "immaturity and instability" I dunno, I've been running systemd on Ubuntu across over 100 machines for ~5 years and I can't agree with either of those points.

d0mine 4y ago
It is likely phrase from years ago 2015? when it may have been true https://news.ycombinator.com/item?id=9515125 https://news.ycombinator.com/item?id=9515125

sylware 4y ago

I run my own custom linux based distro. I run a minimal init process and my desktop rig is inited by a brutal and beyond idiotic sh script. What's long is the EFI bios init, and displayport programing, namely everything is done in a matter of very few seconds. Anything more complex would be grotesque.

deleted 4y ago

[deleted]

akagusu 4y ago

I really sympathize with people who try to avoid systemd but I think it is a futile exercise. Every piece of software these days assume you are running systemd and make your life miserable when you try not rely on systemd, and sometimes, it is even not possible to run without systemd at all. Unfortunately, people don't remember how was the systemd adoption and why it was so controversial. systemd was promoted as a init system, but in reality, it is more than that, it is a suite of software; we have journald, firewalld, udevd, logind, networkd, resolved and many more. People forgot how systemd was forced to everybody when Gnome made systemd-logind a hard dependency and logind was extracted to elogind so people could initialize their desktop without using systemd. The same happened with udev, forcing Gentoo to fork it into eudev to avoid systemd dependency. People complaint about portability and compatibility because you cannot interact with systemd-* without systemd; you are coupled. The problem is not systemd as a software, is the attempt to hijack the entire ecosystem, replacing existing services with services dependents of systemd, forcing systemd adoption. And the question I ask to you is: who is behind this?

kaba0 4y ago
You forget the tiny bit of detail how the absolute majority of the linux world voted in favor of systemd, often literally. Debian for example had multiple votes (in a system much more democratic than what we are used to in politics) on the issue where systemd won hands down in each case. Arch got to the same conclusion independently. You know, the actual people that have to maintain packages, so they actually know what does it entail. So you can’t even claim that they don’t know what they voted on. So if you call the democratic absolute majority’s choice hijacking, I have to believe you are the one doing the pushing.
viraptor 4y ago
> Every piece of software these days assume you are running systemd and make your life miserable when you try not rely on systemd This is silly. Apart from desktop environments, barely anything cares about what session manager is being used. There's no connection between almost every software these days and the init system.
eternityforest 4y ago

erulabs 4y ago

I think the anti-systemd crowd hurts its arguments (which I tend to agree with at least in spirit) when they throw out stuff like accusing the authors of systemd of being "Ignorant of fundamental operating system concepts" (https://without-systemd.org/wiki/index_php/Arguments_against_systemd/#Ignorance_of_fundamental_operating_system_concepts https://without-systemd.org/wiki/index_php/Arguments_against...). You can dislike the author and the project and the design, but that's just a foolish thing to say that makes it difficult to take any of the other (potentially valid) arguments seriously.

gnulinux 4y ago
I checked both of those arguments and wasn't convinced. First link demonstrates an email by Poettering claiming checksums won't fix anything useful. Clearly he's talking about a specific usecase of checksums and not talking about the whole idea of using checksums to recover data. He was asked about a specific feature in systemd, there is no reason to believe he'd want to bring up anything bigger. So implying he doesn't know RAID... is simply absurd and childish. He could have referred that person to RAID; but that'd be completely off-topic. Second link is about a feauture request where someone wants a complete machine login functionality from machinectl unlike su. Then, Poettering explains why this situation exists (because su doesn't inherit cgroups) and then they go ahead and implement the desired feauture. Original user says "it works perfectly". Now, the criticism seems like Poettering calling "su" broken since cgroups were introduced after su. This doesn't make any sense. Of course this is a problem of su. If there are two tools: ssh and su, and they perform a certain task differently and one of the behaviors causing problem, clearly it's relevant to mention su's method is flawed and a more complete implementation can be written (and then they went ahead an wrote it). Bizarre. Another day of reading tons of anti-systemd material for me, and another day of realizing systemd is a perfectly ok piece of software yet there is an odd internet obsession against it.

my69thaccount 4y ago

Even if systemd was great software it would be a bad idea to use it. It's just an attempt for Red Hat to corner the market with embrace, extend extinguish.

codedokode 4y ago

I don't think the idea of systemd is wrong. Long time ago out of curiosity I decide to learn how the boot process works and examined the code. It turned out, the init system was written as a bunch of shell scripts. Its creators probably tried their best to write it, gave functions good names, left comments sometimes, but still it was bad. Running several subprocesses to split a string into parts. Parsing text output of subprocesses. Creating unnecessary temporary files. This style of programming leads to extremely fragile systems. If the command slightly changes its output, scripts will break. If the command output depends on locale, scripts will break. Futhermore, there is no sane options for error handling in shell scripts. There is only a relatively sane option - crash on any error and an insane option - ignore any erros and continue. For example, we failed to backup a file, but ignore this error and delete the original. No way one can write something reliable using such tools. So if you want to write an init system, I think there are better languages that a shell script. It is difficult to build a graph of services and find an optimal sequence to start them using shell scripts. Or implement lazy startup of non-critical services. Init system is not only a program to boot the system, but it should provide some runtime services, like management of background processes, logins and other things. Again, a properly written daemon with an API is better than a bunch of shell scripts. Regarding languages, I am not sure if C is good for this purpose, it's pretty awful too. To illustrate this, consider a C function declaration: int set_working_directory(char *new_directory, char **error); You cannot figure out how to call this function properly without documentation or examining the code. Instead of C I would choose something like Swift, D, Go (but it has pointers), maybe Rust (but writing in Rust for me is mostly struggling against borrow checker). I would choose something that's easy to read, test and verify and has a package manager. So if you don't like systemd, consider writing your init system using one of the languages above. But please don't use shell scripts anymore.

d0mine 4y ago
Shell is not the best language for complex programs but it does not justify the kitchen sink approach taken by systemd. It looks like an example of corporate bullying vs. open-source community and the corporate won.
- 4y ago