6 ms·

You can use systemd without almost all of the sideparts. No need to use networkd for example, networkmanager works great along systemd. Actually most my syste

by bipson 7y ago

You can use systemd without almost all of the sideparts. No need to use networkd for example, networkmanager works great along systemd. Actually most my systems use only systemd and journalctl to my knowledge. I prefer my established tools for all other jobs.

ohazi 7y ago
But you can't use many of the sideparts without systemd. I think systemd actually won when they absorbed udev.
- bipson 7y ago
  That was not the argument though
  - dredmorbius 7y ago
    If the answers are more insightful than the question, perhaps the question was incorrect.
- jakeogh 7y ago
  https://wiki.gentoo.org/wiki/Eudev https://wiki.gentoo.org/wiki/Eudev works perfect
yc12340 7y ago
> You can use systemd without almost all of the sideparts. Can you? The whole premise of systemd revolves around ability to use existing init files, written by upstream developers. Upstream init files are going to use arbitrary parts of systemd functionality, which may include network and container management, timers and God knows what else. So in effect you HAVE to use those parts of systemd — unless you are insisting on writing all your init files from scratch (at which point you may as well use any of systemd alternatives).
- bipson 7y ago
  For one, have you ever written an unit file? It literally takes 3 minutes. And unless you are working with e.g containerized services (which you create yourself), why would a service need anything from networkd? I have never encountered a unit file like that on my system, and I don't run anything apart from systemd and journalctl. No networkd (I prefer NetworkManager), no systemd containers, no systemd ntp. I wonder if I even have those installed, why should I? And all my services run just fine.
  - flukus 7y ago
    I've tried, it was more like 3 hours before I gave up and I was only writing it in the first place because systemd got involved where I didn't ask it too. All I did was mount a network drive from a shell script and systemd decided that it didn't know how to unmount it and instead hang for 90 seconds when the system shutdown. It leaks into user land.
    - pritambaral 7y ago
      Systemd defaults to the kernel's standard way of unmounting filesystems (i.e., umount(2)). You would have to write a .mount file only if your filesystem _couldn't_ be unmounted the normal way. The alternative for systemd would've been to shutdown the system without waiting for a clean unmount, which can lose data, which is what used to happen with SysV. The alternative for you would be to unmount your filesystem yourself before shutdown, which is what people used to do with SysV. Some SysV distros even had scripts that tried to automatically clean up mounts before shutdown, which is exactly what systemd does now, and your 90-second hangs would've shown up there too. > It leaks into user land. Init has always been in user land.
- pritambaral 7y ago
  > The whole premise of systemd revolves around ability to use existing init files, written by upstream developers. There are many premises for which systemd was designed, but this is not one of them, let alone "the whole premise". 1. Before systemd, upstream developers were never precluded from supplying their own init files, and many often did. 2. Even in systemd, downstream maintainers and users were never precluded from modifying, overriding, or even completely replacing upstream-supplied init files. The difference is that with SysV upstream-provided init files were often bad because upstream developers had to use a bunch of hacks in shell scripts to (necessarily reinvent and) supply features that were essential but SysV couldn't provide. The distro maintainers and users were thus sometimes _forced_ to try and fix upstream-supplied init files, but even they could do only so much because ... shell scripts on SysV. Systemd allows everyone (upstream and downstream) to write better, cleaner, more maintainable init files. > which may include network and container management, timers and God knows what else. 1. Timers are a core requirement of service management, and they're correctly a part of the service manager that is systemd. 2. network management (systemd-networkd, systemd-resolved, and .link, .network units) and container management (/var/lib/machines, machinectl etc) are _not_ service management features and are _not_ implemented in pid-1 systemd. I have also not seen any upstream package that used them. In fact, these features _cannot_ be used from service unit files. > ... unless you are insisting on writing all your init files ... It's not an all-or-nothing affair. It never was, not with systemd not with SysV. > ... at which point you may as well use any of systemd alternatives Only if you mistakenly believe that the "whole premise" of systemd was to disallow downstream of touching any unit files at all, which is false.

by bipson 7y ago

ohazi 7y ago

But you can't use many of the sideparts without systemd. I think systemd actually won when they absorbed udev.

bipson 7y ago
That was not the argument though
- dredmorbius 7y ago
  If the answers are more insightful than the question, perhaps the question was incorrect.
jakeogh 7y ago
https://wiki.gentoo.org/wiki/Eudev https://wiki.gentoo.org/wiki/Eudev works perfect

yc12340 7y ago

> You can use systemd without almost all of the sideparts. Can you? The whole premise of systemd revolves around ability to use existing init files, written by upstream developers. Upstream init files are going to use arbitrary parts of systemd functionality, which may include network and container management, timers and God knows what else. So in effect you HAVE to use those parts of systemd — unless you are insisting on writing all your init files from scratch (at which point you may as well use any of systemd alternatives).

bipson 7y ago
For one, have you ever written an unit file? It literally takes 3 minutes. And unless you are working with e.g containerized services (which you create yourself), why would a service need anything from networkd? I have never encountered a unit file like that on my system, and I don't run anything apart from systemd and journalctl. No networkd (I prefer NetworkManager), no systemd containers, no systemd ntp. I wonder if I even have those installed, why should I? And all my services run just fine.
- flukus 7y ago
  I've tried, it was more like 3 hours before I gave up and I was only writing it in the first place because systemd got involved where I didn't ask it too. All I did was mount a network drive from a shell script and systemd decided that it didn't know how to unmount it and instead hang for 90 seconds when the system shutdown. It leaks into user land.
  - pritambaral 7y ago
    Systemd defaults to the kernel's standard way of unmounting filesystems (i.e., umount(2)). You would have to write a .mount file only if your filesystem _couldn't_ be unmounted the normal way. The alternative for systemd would've been to shutdown the system without waiting for a clean unmount, which can lose data, which is what used to happen with SysV. The alternative for you would be to unmount your filesystem yourself before shutdown, which is what people used to do with SysV. Some SysV distros even had scripts that tried to automatically clean up mounts before shutdown, which is exactly what systemd does now, and your 90-second hangs would've shown up there too. > It leaks into user land. Init has always been in user land.
pritambaral 7y ago
> The whole premise of systemd revolves around ability to use existing init files, written by upstream developers. There are many premises for which systemd was designed, but this is not one of them, let alone "the whole premise". 1. Before systemd, upstream developers were never precluded from supplying their own init files, and many often did. 2. Even in systemd, downstream maintainers and users were never precluded from modifying, overriding, or even completely replacing upstream-supplied init files. The difference is that with SysV upstream-provided init files were often bad because upstream developers had to use a bunch of hacks in shell scripts to (necessarily reinvent and) supply features that were essential but SysV couldn't provide. The distro maintainers and users were thus sometimes _forced_ to try and fix upstream-supplied init files, but even they could do only so much because ... shell scripts on SysV. Systemd allows everyone (upstream and downstream) to write better, cleaner, more maintainable init files. > which may include network and container management, timers and God knows what else. 1. Timers are a core requirement of service management, and they're correctly a part of the service manager that is systemd. 2. network management (systemd-networkd, systemd-resolved, and .link, .network units) and container management (/var/lib/machines, machinectl etc) are _not_ service management features and are _not_ implemented in pid-1 systemd. I have also not seen any upstream package that used them. In fact, these features _cannot_ be used from service unit files. > ... unless you are insisting on writing all your init files ... It's not an all-or-nothing affair. It never was, not with systemd not with SysV. > ... at which point you may as well use any of systemd alternatives Only if you mistakenly believe that the "whole premise" of systemd was to disallow downstream of touching any unit files at all, which is false.