5 ms·

I think a lot of the arguments I’ve seen stem from “Unix philosophy” style arguments. Also, historically the systemd project has been quite hostile to user requ

by ratorx 2y ago

I think a lot of the arguments I’ve seen stem from “Unix philosophy” style arguments. Also, historically the systemd project has been quite hostile to user requests in some cases, which broke existing workflows for people. I personally think the basic “service manager” functionality works pretty well and I like systemd overall. However, the same is not true for a bunch of the more peripheral services (e.g. resolved, networkd, timesyncd). What’s particularly annoying is that there exist mature open source projects that can provide better functionality in a lot of cases which could be used, rather than bundling a half-assed attempt with systemd (eg. unbound, chrony).

gritzko 2y ago
So, systemd is like "doing Linux services the Microsoft way"
- teekert 2y ago
  Your remark may suggest that everything MS does is “wrong”. This is of course an extreme overstatement and all of their approaches should be evaluated on their own.
  - taurknaut 2y ago
    So far the argument for systemd seems to be "well it works so why are you complaining"
    - teekert 2y ago
      Sorry, I'm not deep enough into it to determine why systemd would be better. Perhaps it's not. I know it's less unix-y, but we shouldn't treat that as holy imho, it's a good guideline though, I try to follow the unix philosophy.
      - Vilian 2y ago
        And all the system managers that followed UNIX philosophy failed in being as straight forward as systemd, you know, the whole point of that Unix philosophy is to be more straight forward
        linksnapzz 2y ago
        Here, "system managers" and "straight forward" are pretty loaded terms...
      - teekert 2y ago
        Just saw Lennart Poettering speak at Fosdem and perhaps it’s even more Unix-y then system V init :)
    - VMG 2y ago
      it's a good argument
    - gf000 2y ago
      It's a declerative boot system, where units can declare their dependence on another unit/service, and they will be brought up in accord, with a potential for parallelization, proper error handling, proper logging, all while the user complexity is a trivial .ini-like file. It also has a good integration with Linux features, like cgroups, allowing easy user-isolation, has user-services that allow proper resource management, and many more.
      - formerly_proven 2y ago
        systemd is just much better for managing cross-cutting concerns. E.g. having the machine wake up from sleep for a timer and do a task (e.g. backup or updates) which delay sleep is trivial, portable and reliable with systemd and probably technically possible without it.
    - danudey 2y ago
      I'll elaborate on this if you like. It works, and it works well. It does what it says on the tin. It brings together multiple disparate functionalities to a level that most end users need, while also having the ability to replace a lot of those functionalities (systemd-resolved, systemd-networkd, systemd-timesyncd as examples) with other services if that's what your deployment needs. It replaces the old style of services being just a bunch of shell scripts that ran one after another. It provides a consistent interface to configure, start, stop, restart, enable, disable, and monitor those services. It allows dynamism by creating service templates, allowing you to launch six different variants of a service using the same base service configuration. It also allows you to take advantage of a lot of Linux's security features, by implementing service-level restrictions on filesystems, network access, user IDs, PIDs, and so on. It even provides the ability to listen on a socket and pass connections to a process, meaning you could have a network-listening daemon that doesn't even actually have access to your network. It provides cgroup integration so that you can limit the resources provided to an individual service so that you can prevent one process from causing issues with the rest of your hardware. It can even point a service at a separate root directory, essentially chrooting a service before it even starts. It provides tooling so that individual services can interact with one another, and so that user-space tooling (either theirs or a custom d-bus client) can interact with services, and provides functionality for validating whether or not the user has permissions to do so. It also provides functionality to easily override configuration in override files, allowing you to make local changes without changing the files that were distributed, making it easy to debug whether it's your changes or not that are causing an issue, or to test changes without worrying about putting things back. It eliminates the issues of having multiple different services, often either conflicting or overlapping, to provide the things it provides. Multiple separate configuration files, configuration syntaxes, and so on. It eliminates the need for distros to create config generation tooling to produce the right config files to tie each service together, and then write their own daemons or cronjobs to check each of them for changes. And all of this functionality is, essentially, optional. I can do a hundred different things with a service file, but I don't have to; I can basically write a service file in ten lines of ini-compatible configuration, using (and being aware of) none of that functionality, and it works fine, or I can write a service file that locks a service into its own network, with no access to the existing filesystem, only the most basic entries in /dev, only the files it needs in /etc, limited by seccomp filters, using systemd's watchdog functionality to restart it if it hangs or gets overloaded, limiting it to specific CPU cores and changing CPU and IO weighting, limiting the number of processes that it can create, and even filtering which system calls it's allowed to use. In short, it's a system that can be very easy to use and start working with, but provides more functionality and complexity than I think almost anyone realizes. It's the most capable and simplest way of handling system services, and the extra pieces just make it less complex to add functionality like network management, name lookups, boot management, and so on to your system if all you need is the basics.
  - egorfine 2y ago
    It comes down to a philosophy you choose. I personally think that most of the OS decisions done by Microsoft are wrong and should be killed with fire but also I'm far from thinking bad about the people who made these decisions. Perhaps these decisions make sense from their standpoint given the information they had a time. On the other hand on Linux I'd really wish for a centralized settings repository like Registry. But not from the systemd crowd, of course.
    - t43562 2y ago
      The registry is /etc If you want some more structure to it then you'll probably end up with the registry and whatever it is that people hate about it. IMO it would be enough to put the /etc into git so one can rollback bad changes.
      - Vilian 2y ago
        Don't registry get loaded on boot, making it heavier that just being /etc on the hard drive?, also yes, /etc can be view as some sort of registry, but the implementation is different and that's matter
        EasyMark 2y ago
        Parts of it do get loaded and unloaded as needed from disk to memory and back to disk. It's certainly not all loaded into memory
- danudey 2y ago
  Given that it was based off of the design of OS X's launchd, I think it's probably more accurate to say it's "doing Linux services the Apple way".
  - growse 2y ago
    Isn't MacOS a UNIX?
- rkeene2 2y ago
  It's more like doing Linux services the UNIX(TM) way since it's more similar to other UNIX service managers like SMF from Solaris or SRC from AIX in the integration -- NT's service manager requires an active event loop which responds to messages. As an aside, the reason I don't like systemd is because it's inferior to its UNIX counterparts -- especially SMF -- for system management.
  - growse 2y ago
    Maybe someone should port smf or launchd to Linux?
bonzini 2y ago
> resolved, networkd, timesyncd None of these are mandatory though. It's up to the distros whether to use them. For example at this point resolved is pretty commonly enabled by default, networkd not at all, and timesyncd is perhaps 50-50 with chrony.
- graemep 2y ago
  Yes, but not using those seems to defeat the point of using systemd. The most convincing advocacy I have seen for systemd (by a BSD developer, its fairly well known) is that it provides an extra layer of the OS (on top of the kernel) to standardise things.
  - rcxdude 2y ago
    If you don't use them, you still have a standardized way of managing system services, including scheduled batch jobs. The other services are a convenient and integrated way of getting a basic version of that functionality, but they are by no means the entire point of systemd.
    - immibis 2y ago
      Of course. That standardized way is runsvdir, yes?
      - CoolCold 2y ago
        I remember that on one of the $dayjobs around 2014 we have used runit, but I honestly don't remember why and what it gave us. Very likely just as auxiliary tool, not main init system. Really curious now what it was so.
    - actionfromafar 2y ago
      At this point, I am willing to believe the point of systemd is to be the new way to do anything. "If you want to talk to the kernel, go through me". It's a new (ill specified, non standard) runtime to target. It's like what Win32 is to the raw NTDLL, or the dotnet or Java API. It hides the OS.
egorfine 2y ago
resolved and timesyncd are intended to be removed by the end user of the operating system. Sort of like a transparent peel is intended to be removed by the buyer of a new shiny device. I haven't seen anything worse than those two from systemd crowd.
- eadmund 2y ago
  Resolved is useful if you frequently change networks (e.g. a laptop), particularly if you’re also using an overlay such as Tailscale. Unfortunately, like anything related to systemd it is flakey and buggy and the solution to most things is to restart it. I started using Linux because I liked stability. Systemd makes a Linux system as dynamic as a Windows one (which is nice) at the price of making it as stable as a Windows one (which is not). I believe that part of the problem is that it is written in C, which is an absolutely terrible language for reasoning in. Writing it in Lisp would have been smart. Writing it in Go nowadays would probably be okay. But C is just an unmitigated disaster. Also, bringing INI to Linux is unforgivable.
  - egorfine 2y ago
    > Resolved is useful if you frequently change networks (e.g. a laptop) I can see the case. I use it myself on a laptop. And by "use" I mean that I just gave up looking into Linux desktop networking like a decade ago. It works, fine. > I believe that part of the problem is that it is written in C, which is an absolutely terrible language for reasoning in. Writing it in Lisp would have been smart. Writing it in Go nowadays would probably be okay. But C is just an unmitigated disaster. ... this is ... incredibly wrong. Hardest disagree on all points here.
  - danudey 2y ago
    > Unfortunately, like anything related to systemd it is flakey and buggy and the solution to most things is to restart it. For what it's worth, I have never found this to be the case. systemd's functionality has been far more reliable to me than the old methods of using `ifupdown` and dhcpd. > I believe that part of the problem is that it is written in C, which is an absolutely terrible language for reasoning in. I'd love to know what you've seen from systemd that indicates that this is the case. > Writing it in Lisp would have been smart. Hard disagree here. You need a language that more people know if you want contributors, and you need to be able to interact as well with other libraries/languages in ways that are understandable to the typical user. Lisp is, at best, an obscure edge case in the context of mainstream programming, and would severely hamper its adoption as an open-source project. > Writing it in Go nowadays would probably be okay. Ehh, I agree with this only because you're so noncommital about it. I agree that it would probably be okay. Rust would be far better, in my opinion, if we're looking for a modern language with far more memory safety guarantees (which IMHO is very important for low-level system services). > Also, bringing INI to Linux is unforgivable. I'd love to know what you'd recommend that would meet the criteria that INI provides: 1. Simple to read, simple to write (for users) 2. Simple to parse, simple to generate (for software) 3. Uncomplicated syntax that isn't prone to errors when being written or generated (e.g. wrong indentation in YAML, missing brackets in JSON) I can't think of any options off the top of my head that don't end up introducing additional complexity with little to no benefit, but I'd be happy to be wrong.

by ratorx 2y ago

gritzko 2y ago

So, systemd is like "doing Linux services the Microsoft way"

teekert 2y ago
Your remark may suggest that everything MS does is “wrong”. This is of course an extreme overstatement and all of their approaches should be evaluated on their own.
- taurknaut 2y ago
  So far the argument for systemd seems to be "well it works so why are you complaining"
  - teekert 2y ago
    Sorry, I'm not deep enough into it to determine why systemd would be better. Perhaps it's not. I know it's less unix-y, but we shouldn't treat that as holy imho, it's a good guideline though, I try to follow the unix philosophy.
    - Vilian 2y ago
      And all the system managers that followed UNIX philosophy failed in being as straight forward as systemd, you know, the whole point of that Unix philosophy is to be more straight forward
      - linksnapzz 2y ago
        Here, "system managers" and "straight forward" are pretty loaded terms...
    - teekert 2y ago
      Just saw Lennart Poettering speak at Fosdem and perhaps it’s even more Unix-y then system V init :)
  - VMG 2y ago
    it's a good argument
  - gf000 2y ago
    It's a declerative boot system, where units can declare their dependence on another unit/service, and they will be brought up in accord, with a potential for parallelization, proper error handling, proper logging, all while the user complexity is a trivial .ini-like file. It also has a good integration with Linux features, like cgroups, allowing easy user-isolation, has user-services that allow proper resource management, and many more.
    - formerly_proven 2y ago
      systemd is just much better for managing cross-cutting concerns. E.g. having the machine wake up from sleep for a timer and do a task (e.g. backup or updates) which delay sleep is trivial, portable and reliable with systemd and probably technically possible without it.
  - danudey 2y ago
    I'll elaborate on this if you like. It works, and it works well. It does what it says on the tin. It brings together multiple disparate functionalities to a level that most end users need, while also having the ability to replace a lot of those functionalities (systemd-resolved, systemd-networkd, systemd-timesyncd as examples) with other services if that's what your deployment needs. It replaces the old style of services being just a bunch of shell scripts that ran one after another. It provides a consistent interface to configure, start, stop, restart, enable, disable, and monitor those services. It allows dynamism by creating service templates, allowing you to launch six different variants of a service using the same base service configuration. It also allows you to take advantage of a lot of Linux's security features, by implementing service-level restrictions on filesystems, network access, user IDs, PIDs, and so on. It even provides the ability to listen on a socket and pass connections to a process, meaning you could have a network-listening daemon that doesn't even actually have access to your network. It provides cgroup integration so that you can limit the resources provided to an individual service so that you can prevent one process from causing issues with the rest of your hardware. It can even point a service at a separate root directory, essentially chrooting a service before it even starts. It provides tooling so that individual services can interact with one another, and so that user-space tooling (either theirs or a custom d-bus client) can interact with services, and provides functionality for validating whether or not the user has permissions to do so. It also provides functionality to easily override configuration in override files, allowing you to make local changes without changing the files that were distributed, making it easy to debug whether it's your changes or not that are causing an issue, or to test changes without worrying about putting things back. It eliminates the issues of having multiple different services, often either conflicting or overlapping, to provide the things it provides. Multiple separate configuration files, configuration syntaxes, and so on. It eliminates the need for distros to create config generation tooling to produce the right config files to tie each service together, and then write their own daemons or cronjobs to check each of them for changes. And all of this functionality is, essentially, optional. I can do a hundred different things with a service file, but I don't have to; I can basically write a service file in ten lines of ini-compatible configuration, using (and being aware of) none of that functionality, and it works fine, or I can write a service file that locks a service into its own network, with no access to the existing filesystem, only the most basic entries in /dev, only the files it needs in /etc, limited by seccomp filters, using systemd's watchdog functionality to restart it if it hangs or gets overloaded, limiting it to specific CPU cores and changing CPU and IO weighting, limiting the number of processes that it can create, and even filtering which system calls it's allowed to use. In short, it's a system that can be very easy to use and start working with, but provides more functionality and complexity than I think almost anyone realizes. It's the most capable and simplest way of handling system services, and the extra pieces just make it less complex to add functionality like network management, name lookups, boot management, and so on to your system if all you need is the basics.
- egorfine 2y ago
  It comes down to a philosophy you choose. I personally think that most of the OS decisions done by Microsoft are wrong and should be killed with fire but also I'm far from thinking bad about the people who made these decisions. Perhaps these decisions make sense from their standpoint given the information they had a time. On the other hand on Linux I'd really wish for a centralized settings repository like Registry. But not from the systemd crowd, of course.
  - t43562 2y ago
    The registry is /etc If you want some more structure to it then you'll probably end up with the registry and whatever it is that people hate about it. IMO it would be enough to put the /etc into git so one can rollback bad changes.
    - Vilian 2y ago
      Don't registry get loaded on boot, making it heavier that just being /etc on the hard drive?, also yes, /etc can be view as some sort of registry, but the implementation is different and that's matter
      - EasyMark 2y ago
        Parts of it do get loaded and unloaded as needed from disk to memory and back to disk. It's certainly not all loaded into memory
danudey 2y ago
Given that it was based off of the design of OS X's launchd, I think it's probably more accurate to say it's "doing Linux services the Apple way".
- growse 2y ago
  Isn't MacOS a UNIX?
rkeene2 2y ago
It's more like doing Linux services the UNIX(TM) way since it's more similar to other UNIX service managers like SMF from Solaris or SRC from AIX in the integration -- NT's service manager requires an active event loop which responds to messages. As an aside, the reason I don't like systemd is because it's inferior to its UNIX counterparts -- especially SMF -- for system management.
- growse 2y ago
  Maybe someone should port smf or launchd to Linux?

bonzini 2y ago

> resolved, networkd, timesyncd None of these are mandatory though. It's up to the distros whether to use them. For example at this point resolved is pretty commonly enabled by default, networkd not at all, and timesyncd is perhaps 50-50 with chrony.

graemep 2y ago
Yes, but not using those seems to defeat the point of using systemd. The most convincing advocacy I have seen for systemd (by a BSD developer, its fairly well known) is that it provides an extra layer of the OS (on top of the kernel) to standardise things.
- rcxdude 2y ago
  If you don't use them, you still have a standardized way of managing system services, including scheduled batch jobs. The other services are a convenient and integrated way of getting a basic version of that functionality, but they are by no means the entire point of systemd.
  - immibis 2y ago
    Of course. That standardized way is runsvdir, yes?
    - CoolCold 2y ago
      I remember that on one of the $dayjobs around 2014 we have used runit, but I honestly don't remember why and what it gave us. Very likely just as auxiliary tool, not main init system. Really curious now what it was so.
  - actionfromafar 2y ago
    At this point, I am willing to believe the point of systemd is to be the new way to do anything. "If you want to talk to the kernel, go through me". It's a new (ill specified, non standard) runtime to target. It's like what Win32 is to the raw NTDLL, or the dotnet or Java API. It hides the OS.

egorfine 2y ago

resolved and timesyncd are intended to be removed by the end user of the operating system. Sort of like a transparent peel is intended to be removed by the buyer of a new shiny device. I haven't seen anything worse than those two from systemd crowd.

eadmund 2y ago
Resolved is useful if you frequently change networks (e.g. a laptop), particularly if you’re also using an overlay such as Tailscale. Unfortunately, like anything related to systemd it is flakey and buggy and the solution to most things is to restart it. I started using Linux because I liked stability. Systemd makes a Linux system as dynamic as a Windows one (which is nice) at the price of making it as stable as a Windows one (which is not). I believe that part of the problem is that it is written in C, which is an absolutely terrible language for reasoning in. Writing it in Lisp would have been smart. Writing it in Go nowadays would probably be okay. But C is just an unmitigated disaster. Also, bringing INI to Linux is unforgivable.
- egorfine 2y ago
  > Resolved is useful if you frequently change networks (e.g. a laptop) I can see the case. I use it myself on a laptop. And by "use" I mean that I just gave up looking into Linux desktop networking like a decade ago. It works, fine. > I believe that part of the problem is that it is written in C, which is an absolutely terrible language for reasoning in. Writing it in Lisp would have been smart. Writing it in Go nowadays would probably be okay. But C is just an unmitigated disaster. ... this is ... incredibly wrong. Hardest disagree on all points here.
- danudey 2y ago
  > Unfortunately, like anything related to systemd it is flakey and buggy and the solution to most things is to restart it. For what it's worth, I have never found this to be the case. systemd's functionality has been far more reliable to me than the old methods of using `ifupdown` and dhcpd. > I believe that part of the problem is that it is written in C, which is an absolutely terrible language for reasoning in. I'd love to know what you've seen from systemd that indicates that this is the case. > Writing it in Lisp would have been smart. Hard disagree here. You need a language that more people know if you want contributors, and you need to be able to interact as well with other libraries/languages in ways that are understandable to the typical user. Lisp is, at best, an obscure edge case in the context of mainstream programming, and would severely hamper its adoption as an open-source project. > Writing it in Go nowadays would probably be okay. Ehh, I agree with this only because you're so noncommital about it. I agree that it would probably be okay. Rust would be far better, in my opinion, if we're looking for a modern language with far more memory safety guarantees (which IMHO is very important for low-level system services). > Also, bringing INI to Linux is unforgivable. I'd love to know what you'd recommend that would meet the criteria that INI provides: 1. Simple to read, simple to write (for users) 2. Simple to parse, simple to generate (for software) 3. Uncomplicated syntax that isn't prone to errors when being written or generated (e.g. wrong indentation in YAML, missing brackets in JSON) I can't think of any options off the top of my head that don't end up introducing additional complexity with little to no benefit, but I'd be happy to be wrong.