4 ms·

> I want to remind that, parallel sysV-init was pretty fast machinery and was very manageable. That does nothing for the fact that SysV init was a pile of she

> I want to remind that, parallel sysV-init was pretty fast machinery and was very manageable. That does nothing for the fact that SysV init was a pile of shell scripts inconsistent across distros and even individual packages. I'd take systemd's declarative, portable service definitions any day over that mess. SysV init did not take care of consolekit being an unmaintained mess either. systemd did. Besides, systemd can recognize that I had plugged in a specific kind of device that needs this sort of setup and do that for me automatically. Hence the 'manager' part. None of its supposed 'competitors' can do that themselves. > Kernel doesn't breach this principle either. It provides an interface between the hardware and software & lives in its own space; that's it. I don't know, eBPF for example is an entire complex beast of its own that could be argued to violate that, well beyond what's 'required'. If you take the view that as long as the system has a single defined job, (interfaces to hardware and exposes APIs to userspace for the kernel), systemd does have a definition like that too. It manages the system's dynamic resources during its lifetime. That's a 'single' job. It's not if you decompose it, but the kernel is in a similar situation at that point. > When systemd overtakes a part of the system with its module, it's very hard to discover it. systemd does not do that, sounds like you're blaming bad distro defaults (optional components being enabled by default) on systemd.

bayindirh 6y ago
> That does nothing for the fact that SysV init was a pile of shell scripts inconsistent across distros and even individual packages. I've never seen the inconsistencies, sorry. All the service files I've written were greatly portable around what I've used so far. > SysV init did not take care of consolekit being an unmaintained mess either. systemd did. No other service should hide the shortcomings of other services. This sounds like WoW's extreme tricks or Kubernetes' dockershim layer to keep compatibility. Now, doing this is wrong. > Besides, systemd can recognize that I had plugged in a specific kind of device that needs this sort of setup and do that for me automatically. Hence the 'manager' part. None of its supposed 'competitors' can do that themselves. That's the point. If that task can be handed over to another daemon (like udev) for setting it up, why systemd assumes that setting it up is its job? I'm not trying to say that doing this is flat out wrong but, when asked about why, getting "we're doing it , because why not?" as an answer leaves a bad taste in the mouth. > systemd does not do that, sounds like you're blaming bad distro defaults (optional components being enabled by default) on systemd. I think I failed to convey what I tried to say there. I wanted to say that there's no easy way to see whether a feature is managed by systemd or not and hence systemd tries to "self-heal" things sometimes, system management becomes a tug-of-war until one understands that systemd is managing that. If there was an easy way to understand that, it'd be an easier path. All in all, I personally don't oppose what systemd brings to a table and see the inspiration from macOS' launchd. However, the main thing I strongly oppose and criticize is the blind egg-throwing to other init systems, the overzealous protection of systemd and avoiding discussing its potential shortcomings and problems altogether. I want to reiterate that I'm not against change and evolution, I'm against forcing it with a stance of "we, only we know the best. now shut-up and use it!".
- AsyncAwait 6y ago
  > I've never seen the inconsistencies, I've seen plenty to convince me that having a full shell scripting language and not a very good one at that as your service definition language is a terrible idea. > No other service should hide the shortcomings of other services. I don't think you get it. It is not hiding the shortcomings of other services. It is implementing its own service because the other one was a pile of unmaintained crap. But I guess that kind of security risk is OK as long as it's a separate repo? What a weird dogma. > That's the point. If that task can be handed over to another daemon (like udev) for setting it up, why systemd assumes that setting it up is its job? It does hand it over to udev, but someone needs to notify udev stuff is happening. systemd has easy access to that information so it does the job. Also, you do realize that the people who maintain udev are the same who maintain systemd right? Again, because it was a hard job and nobody else, including other init systems, were willing to pick up the slack. > what I tried to say there. I wanted to say that there's no easy way to see whether a feature is managed by systemd or not I understand that but imo that should be on the distro to communicate. On Arch for example, the wiki always gives a clear indication of whether a thing like DNS can and is managed by a systemd component or not. A `systemctl component list --status=enabled` would perhaps be a nice addition, agreed. > I strongly oppose and criticize is the blind egg-throwing to other init systems, the overzealous protection of systemd and avoiding discussing its potential shortcomings and problems altogether. It's funny you say that because as a very early adopter of systemd I saw things up close and it was the exact opposite. People were literally threatening Lennart Poettering with violence for writing a (good imo) piece of free software. That he decided to stay on the scene despite that is honestly remarkable. But as for other init systems, I don't doubt there's some good ones, sysV init wasn't it, but the main problem is that all the others seem only interested in the init part and are happy to depend on rotten parts of the ecosystem. Unlike systemd, none of them were saying; 'ok, consolekit is unmaiintained, let's pick up the slack on session management' (maybe in a separate repo if you insist) or 'oh, udev is struggling, let's pick up the slack' - no they were like am going to do init and hope these other pieces don't come crashing down like a pile of bricks. Also, I've started using systemd-homed to make my setup portable across my machines. None of the supposed competitors of systemd offer that either. I like to compare it with PulseAudio; people suggest to me all the time how OSS, ALSA etc. are 'good enough' etc. but I have a fully FLOSS wireless audio house setup right now thanks to PulseAudio, none of the supposed 'competitors' offer that, so they're not competitors for me, (PipeWire eventually might by literally re implementing all of Pulse).

bayindirh 6y ago

> That does nothing for the fact that SysV init was a pile of shell scripts inconsistent across distros and even individual packages. I've never seen the inconsistencies, sorry. All the service files I've written were greatly portable around what I've used so far. > SysV init did not take care of consolekit being an unmaintained mess either. systemd did. No other service should hide the shortcomings of other services. This sounds like WoW's extreme tricks or Kubernetes' dockershim layer to keep compatibility. Now, doing this is wrong. > Besides, systemd can recognize that I had plugged in a specific kind of device that needs this sort of setup and do that for me automatically. Hence the 'manager' part. None of its supposed 'competitors' can do that themselves. That's the point. If that task can be handed over to another daemon (like udev) for setting it up, why systemd assumes that setting it up is its job? I'm not trying to say that doing this is flat out wrong but, when asked about why, getting "we're doing it , because why not?" as an answer leaves a bad taste in the mouth. > systemd does not do that, sounds like you're blaming bad distro defaults (optional components being enabled by default) on systemd. I think I failed to convey what I tried to say there. I wanted to say that there's no easy way to see whether a feature is managed by systemd or not and hence systemd tries to "self-heal" things sometimes, system management becomes a tug-of-war until one understands that systemd is managing that. If there was an easy way to understand that, it'd be an easier path. All in all, I personally don't oppose what systemd brings to a table and see the inspiration from macOS' launchd. However, the main thing I strongly oppose and criticize is the blind egg-throwing to other init systems, the overzealous protection of systemd and avoiding discussing its potential shortcomings and problems altogether. I want to reiterate that I'm not against change and evolution, I'm against forcing it with a stance of "we, only we know the best. now shut-up and use it!".

AsyncAwait 6y ago
> I've never seen the inconsistencies, I've seen plenty to convince me that having a full shell scripting language and not a very good one at that as your service definition language is a terrible idea. > No other service should hide the shortcomings of other services. I don't think you get it. It is not hiding the shortcomings of other services. It is implementing its own service because the other one was a pile of unmaintained crap. But I guess that kind of security risk is OK as long as it's a separate repo? What a weird dogma. > That's the point. If that task can be handed over to another daemon (like udev) for setting it up, why systemd assumes that setting it up is its job? It does hand it over to udev, but someone needs to notify udev stuff is happening. systemd has easy access to that information so it does the job. Also, you do realize that the people who maintain udev are the same who maintain systemd right? Again, because it was a hard job and nobody else, including other init systems, were willing to pick up the slack. > what I tried to say there. I wanted to say that there's no easy way to see whether a feature is managed by systemd or not I understand that but imo that should be on the distro to communicate. On Arch for example, the wiki always gives a clear indication of whether a thing like DNS can and is managed by a systemd component or not. A `systemctl component list --status=enabled` would perhaps be a nice addition, agreed. > I strongly oppose and criticize is the blind egg-throwing to other init systems, the overzealous protection of systemd and avoiding discussing its potential shortcomings and problems altogether. It's funny you say that because as a very early adopter of systemd I saw things up close and it was the exact opposite. People were literally threatening Lennart Poettering with violence for writing a (good imo) piece of free software. That he decided to stay on the scene despite that is honestly remarkable. But as for other init systems, I don't doubt there's some good ones, sysV init wasn't it, but the main problem is that all the others seem only interested in the init part and are happy to depend on rotten parts of the ecosystem. Unlike systemd, none of them were saying; 'ok, consolekit is unmaiintained, let's pick up the slack on session management' (maybe in a separate repo if you insist) or 'oh, udev is struggling, let's pick up the slack' - no they were like am going to do init and hope these other pieces don't come crashing down like a pile of bricks. Also, I've started using systemd-homed to make my setup portable across my machines. None of the supposed competitors of systemd offer that either. I like to compare it with PulseAudio; people suggest to me all the time how OSS, ALSA etc. are 'good enough' etc. but I have a fully FLOSS wireless audio house setup right now thanks to PulseAudio, none of the supposed 'competitors' offer that, so they're not competitors for me, (PipeWire eventually might by literally re implementing all of Pulse).