4 ms·

> tmux IMHO is important enough that talking to them beforehand would have been the decent thing to do five years ago: http://tmux-users.narkive.com/LXp72CHV/

> tmux IMHO is important enough that talking to them beforehand would have been the decent thing to do five years ago: http://tmux-users.narkive.com/LXp72CHV/pam-support-in-tmux http://tmux-users.narkive.com/LXp72CHV/pam-support-in-tmux

tremon 10y ago
It seems obvious - if users leave stuff running in the background they should stay running, unless the admin has prevented it or kills it. Seems pretty standard? I don't follow why this is different for systemd. I'm not wildly happy about adding more OS-specific code to tmux for something it already does perfectly well everywhere (including Linux right now). If it has to be done differently then - glibc has the daemon() function, and tmux uses it on Linux. Shouldn't this code be part of glibc instead of tmux? There doesn't seem to be any discussion following these additional questions from the tmux side. So what you're really saying is that systemd has been aware of the architectural issues with their design for five years, yet have not bothered to fix their end?
msbarnett 10y ago
This seems to be a good example of the Systemd team disregarding user-space developers, if anything. tmux dev asks: > If it has to be done differently then - glibc has the daemon() function, and tmux uses it on Linux. Shouldn't this code be part of glibc instead of tmux? Which is a perfectly sensible question. After all, what value is there in the systemd team being so resistant to maintaining user space contracts? What technical gain is there in pushing low-level systemd dependencies high up into user space? Wouldn't sane engineering be to encapsulate this kind of low-level platform detail behind libc interfaces like daemon(3), which exist precisely to abstract away this platform-specific knowledge? If the daemon(3) infinite lifetime semantics aren't desirable in all cases, why not add a second call, say user_daemon(3), to address those cases without breaking everyone else? Zero response from the systemd devs, and 5 years later they change the default to break everyone without following up on these obvious critiques of their design.
- justinsaccount 10y ago
  If systemd tried to change daemon: "systemd is breaking linux and not everyone runs systemd!" If systemd tried to add user_daemon: "systemd is trying to add systemd specific patches to everyones software!" They can't win. Haters gonna hate.
  - msbarnett 10y ago
    > If systemd tried to change daemon: "systemd is breaking linux and not everyone runs systemd!" This critique makes zero sense. Encapsulating this kind of thing is exactly what libc is for. What daemon(3) has to do to achieve it's semantics varies by platform. daemon(3) abstracts that away. That's the point of it. Ditto everything else in libc. Nobody would complain about libc doing system-specific things. That's precisely what it's for. That's what it already does to do its job. > If systemd tried to add user_daemon: "systemd is trying to add systemd specific patches to everyones software!" Again, you seem to not understand the concept of libc and its abstractions. THere's nothing Systemd-specific about the idea of a user_daemon(3) call. On systemd-using systems it could be implemented using systemd-specific code, whereas on other platforms it could be implemented via OpenBSD specific code or FreeBSD specific code, etc. It could simply be a pass-through to daemon(3) on platforms that don't care about limiting the lifetime of some but not all daemons. That's what libc is for. It exists to hide the low-level details of the platform from user-space. Circulating a proposal to extend libc with a new call is exactly what you'd expect from a good citizen in the Open Source community. From a user-space developer's perspective, abstracting away hundreds of lines of dbus calls to systemd-specific endpoints is unequivocally The Right Choice. That Red Hat seeks instead to push the systemd dependencies as high into user space as possible suggests that technical concerns are not their primary motivation, because Big Ball of Mud style of engineering is bad from any perspective. > They can't win. Haters gonna hate. It's reasonably clear that you simply don't understand the critiques being presented here.
    - justinsaccount 10y ago
      > Nobody would complain about libc doing system-specific things. That's precisely what it's for. That's what it already does to do its job. Unless those system specific things are systemd specific things, then all people do is complain. A reply to one of my other comments: > Systemd is not a platform. And not every Linux runs systemd. Another reply: > Didn't know linux also means systemd. You're not wrong, updating daemon WOULD make perfect sense and solve this problem in a single place. People would rather argue and fight than solve real problems though. > There's nothing Systemd-specific about the idea of a user_daemon(3) call True, but as soon as a systemd developer proposed adding user_daemon it would immediately become a "systemd" function. As soon as they propose modifying daemon to work with systemd, systemd would be accused of trying to take over libc. One of the BSDs could modify daemon and no one would bat an eye, apparently OS X did so to play nice with launchd. But "linux is not systemd", so they can't win.

tremon 10y ago

It seems obvious - if users leave stuff running in the background they should stay running, unless the admin has prevented it or kills it. Seems pretty standard? I don't follow why this is different for systemd. I'm not wildly happy about adding more OS-specific code to tmux for something it already does perfectly well everywhere (including Linux right now). If it has to be done differently then - glibc has the daemon() function, and tmux uses it on Linux. Shouldn't this code be part of glibc instead of tmux? There doesn't seem to be any discussion following these additional questions from the tmux side. So what you're really saying is that systemd has been aware of the architectural issues with their design for five years, yet have not bothered to fix their end?

msbarnett 10y ago

This seems to be a good example of the Systemd team disregarding user-space developers, if anything. tmux dev asks: > If it has to be done differently then - glibc has the daemon() function, and tmux uses it on Linux. Shouldn't this code be part of glibc instead of tmux? Which is a perfectly sensible question. After all, what value is there in the systemd team being so resistant to maintaining user space contracts? What technical gain is there in pushing low-level systemd dependencies high up into user space? Wouldn't sane engineering be to encapsulate this kind of low-level platform detail behind libc interfaces like daemon(3), which exist precisely to abstract away this platform-specific knowledge? If the daemon(3) infinite lifetime semantics aren't desirable in all cases, why not add a second call, say user_daemon(3), to address those cases without breaking everyone else? Zero response from the systemd devs, and 5 years later they change the default to break everyone without following up on these obvious critiques of their design.

justinsaccount 10y ago
If systemd tried to change daemon: "systemd is breaking linux and not everyone runs systemd!" If systemd tried to add user_daemon: "systemd is trying to add systemd specific patches to everyones software!" They can't win. Haters gonna hate.
- msbarnett 10y ago
  > If systemd tried to change daemon: "systemd is breaking linux and not everyone runs systemd!" This critique makes zero sense. Encapsulating this kind of thing is exactly what libc is for. What daemon(3) has to do to achieve it's semantics varies by platform. daemon(3) abstracts that away. That's the point of it. Ditto everything else in libc. Nobody would complain about libc doing system-specific things. That's precisely what it's for. That's what it already does to do its job. > If systemd tried to add user_daemon: "systemd is trying to add systemd specific patches to everyones software!" Again, you seem to not understand the concept of libc and its abstractions. THere's nothing Systemd-specific about the idea of a user_daemon(3) call. On systemd-using systems it could be implemented using systemd-specific code, whereas on other platforms it could be implemented via OpenBSD specific code or FreeBSD specific code, etc. It could simply be a pass-through to daemon(3) on platforms that don't care about limiting the lifetime of some but not all daemons. That's what libc is for. It exists to hide the low-level details of the platform from user-space. Circulating a proposal to extend libc with a new call is exactly what you'd expect from a good citizen in the Open Source community. From a user-space developer's perspective, abstracting away hundreds of lines of dbus calls to systemd-specific endpoints is unequivocally The Right Choice. That Red Hat seeks instead to push the systemd dependencies as high into user space as possible suggests that technical concerns are not their primary motivation, because Big Ball of Mud style of engineering is bad from any perspective. > They can't win. Haters gonna hate. It's reasonably clear that you simply don't understand the critiques being presented here.
  - justinsaccount 10y ago
    > Nobody would complain about libc doing system-specific things. That's precisely what it's for. That's what it already does to do its job. Unless those system specific things are systemd specific things, then all people do is complain. A reply to one of my other comments: > Systemd is not a platform. And not every Linux runs systemd. Another reply: > Didn't know linux also means systemd. You're not wrong, updating daemon WOULD make perfect sense and solve this problem in a single place. People would rather argue and fight than solve real problems though. > There's nothing Systemd-specific about the idea of a user_daemon(3) call True, but as soon as a systemd developer proposed adding user_daemon it would immediately become a "systemd" function. As soon as they propose modifying daemon to work with systemd, systemd would be accused of trying to take over libc. One of the BSDs could modify daemon and no one would bat an eye, apparently OS X did so to play nice with launchd. But "linux is not systemd", so they can't win.