4 ms·

It's a little funny. systemd has some great stuff in it. I have my nits to pick with it but, on the whole, it's better than what we had before. And, don't we a

It's a little funny. systemd has some great stuff in it. I have my nits to pick with it but, on the whole, it's better than what we had before. And, don't we all just want things to be a little better every day? I think it's all gonna work out fine in the end (and if not, we'll all be dead someday, anyway).

stuaxo 9y ago
I would say the same with pulseaudio; before this, there were a mess of audio servers (esd / ksd or none) - now things are definitely better.
- digi_owl 9y ago
  I have not required a audio server in years, and i have not adopted PA. What i did was enable dmix, that comes with Alsa. A behavior that is even default Alsa these days if it detect that you use sound hardware without mixing. The one "issue" that PA "fixed" was that of temporary audio devices (bluetooth, USB). But then i find the whole notion of USB headphones (a pair of headphones soldered to a minimal USB sound card) a massive abomination. and i fail to see why paired Bluetooth audio devices are exposed directly into the /dev tree rather than behind the Bluetooth dongle device.
MereInterest 9y ago
I use tmux and emacs --daemon constantly. My experience with systemd is that I need to check whether KillUserProcesses is enabled, or else systemd will kill my processes. My experience with init was nonexistent, because it never came up as an issue.
- SwellJoe 9y ago
  Most distros have set KillUserProcesss to no for the short-term. Fedora plans to make all of the obvious user programs aware of the change (and able to create a new systemd unit for the process) and turn it back on for Fedora 26. https://fedoraproject.org/wiki/Changes/KillUserProcesses_by_default https://fedoraproject.org/wiki/Changes/KillUserProcesses_by_... Their reasoning is pretty good, IMHO. It provides more control at low cost, and it's a one-line configuration change if you want the old behavior. But, everything I need it for (pretty much just screen and tmux) will already be aware and will handle setting up the new systemd unit automatically.
  - CJefferson 9y ago
    But, it breaks a standard Unix behaviour going back years, and it can't be configured by a non root user.
  - MereInterest 9y ago
    It is a one-line configuration change IF you know that it exists, and you have administrator privileges on the machine. If either of those conditions fail, systemd has broken your setup. Not only that, but there was an existing mechanism for this. On a disconnect, SIGHUP would be sent to all processes. A background process can explicitly ignore SIGHUP in order to remain running on disconnect. I would be fine if systemd were sending SIGHUP to processes, because that would fit with the existing method of opting out. Sending SIGKILL, and having to use systemd's API to opt out of being killed is ridiculous. This adds more complexity for no added benefit. My standard .bashrc now needs to have a line checking whether KillUserProcesses is enabled, so that I can bug the admin to disable that idiocy if it is.
    - MertsA 9y ago
      >A background process can explicitly ignore SIGHUP The problem with SIGHUP is that a background process can't explicitly ignore SIGHUP, it can only implicitly ignore it. If you send SIGHUP to a process and it doesn't exit you have no idea if it didn't exit because it wants to hang around or if it didn't exit because the process is hung. Part of the motivation for fixing that is to eliminate things like gnome-keyring-daemon hanging around after the user logs out.
      - MereInterest 9y ago
        Correct me if I am wrong, but I would call signal(SIGHUP, mysignalhandler) to be an explicit ignoring of SIGHUP. I have taken a non-default action in order to have a non-default behavior. Since gnome is the one that requires behavior and integration with systemd beyond what can be done with signals, a reasonable workaround would be to have the extra logic in systemd apply only to gnome. As it is, they are changing to a default that is entirely unreasonable outside of a desktop environment, and requiring others to work with the new system.

stuaxo 9y ago

I would say the same with pulseaudio; before this, there were a mess of audio servers (esd / ksd or none) - now things are definitely better.

digi_owl 9y ago
I have not required a audio server in years, and i have not adopted PA. What i did was enable dmix, that comes with Alsa. A behavior that is even default Alsa these days if it detect that you use sound hardware without mixing. The one "issue" that PA "fixed" was that of temporary audio devices (bluetooth, USB). But then i find the whole notion of USB headphones (a pair of headphones soldered to a minimal USB sound card) a massive abomination. and i fail to see why paired Bluetooth audio devices are exposed directly into the /dev tree rather than behind the Bluetooth dongle device.

MereInterest 9y ago

I use tmux and emacs --daemon constantly. My experience with systemd is that I need to check whether KillUserProcesses is enabled, or else systemd will kill my processes. My experience with init was nonexistent, because it never came up as an issue.

SwellJoe 9y ago
Most distros have set KillUserProcesss to no for the short-term. Fedora plans to make all of the obvious user programs aware of the change (and able to create a new systemd unit for the process) and turn it back on for Fedora 26. https://fedoraproject.org/wiki/Changes/KillUserProcesses_by_default https://fedoraproject.org/wiki/Changes/KillUserProcesses_by_... Their reasoning is pretty good, IMHO. It provides more control at low cost, and it's a one-line configuration change if you want the old behavior. But, everything I need it for (pretty much just screen and tmux) will already be aware and will handle setting up the new systemd unit automatically.
- CJefferson 9y ago
  But, it breaks a standard Unix behaviour going back years, and it can't be configured by a non root user.
- MereInterest 9y ago
  It is a one-line configuration change IF you know that it exists, and you have administrator privileges on the machine. If either of those conditions fail, systemd has broken your setup. Not only that, but there was an existing mechanism for this. On a disconnect, SIGHUP would be sent to all processes. A background process can explicitly ignore SIGHUP in order to remain running on disconnect. I would be fine if systemd were sending SIGHUP to processes, because that would fit with the existing method of opting out. Sending SIGKILL, and having to use systemd's API to opt out of being killed is ridiculous. This adds more complexity for no added benefit. My standard .bashrc now needs to have a line checking whether KillUserProcesses is enabled, so that I can bug the admin to disable that idiocy if it is.
  - MertsA 9y ago
    >A background process can explicitly ignore SIGHUP The problem with SIGHUP is that a background process can't explicitly ignore SIGHUP, it can only implicitly ignore it. If you send SIGHUP to a process and it doesn't exit you have no idea if it didn't exit because it wants to hang around or if it didn't exit because the process is hung. Part of the motivation for fixing that is to eliminate things like gnome-keyring-daemon hanging around after the user logs out.
    - MereInterest 9y ago
      Correct me if I am wrong, but I would call signal(SIGHUP, mysignalhandler) to be an explicit ignoring of SIGHUP. I have taken a non-default action in order to have a non-default behavior. Since gnome is the one that requires behavior and integration with systemd beyond what can be done with signals, a reasonable workaround would be to have the extra logic in systemd apply only to gnome. As it is, they are changing to a default that is entirely unreasonable outside of a desktop environment, and requiring others to work with the new system.