4 ms·

> If systemd tried to change daemon: "systemd is breaking linux and not everyone runs systemd!" This critique makes zero sense. Encapsulating this kind of thin

> 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.
- msbarnett 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. According to you. Although, again, I continue to assert that most people understand that libc is the correct place for this. >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. Again, libc is not a homogenous library. glibc need not be implemented the same on all linux systems. Implementing daemon(3) semantics could be done either via systemd or not, as makes most sense on a given linux platform. glibc already does this for other things. The criticism that this makes or assumes all of linux == systemd doesn't apply. Either way, we'll never know, because the systemd devs did not even bother to try being good actors, here. They're ignoring libc entirely in favor of pushing systemd dependencies up the stack. edit: I want to take this a little bit farther: The idea that systemd devs have to push a bad engineering decision (to tightly couple low-level platform details) onto upstream code with no abstractions, which they are being heavily criticized for, was somehow necessary to avoid misguided criticism they might have received for trying to do this the right way, is simply a wrong argument that doesn't make sense.
  - justinsaccount 10y ago
    I don't disagree with you. I look forward to tomorrows systemd hate post: Systemd developer asks libc to add systemd specific code
    - dingo_bat 10y ago
      But then the haters would be wrong and systemd would be right. Opposite of the current situation.

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.

msbarnett 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. According to you. Although, again, I continue to assert that most people understand that libc is the correct place for this. >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. Again, libc is not a homogenous library. glibc need not be implemented the same on all linux systems. Implementing daemon(3) semantics could be done either via systemd or not, as makes most sense on a given linux platform. glibc already does this for other things. The criticism that this makes or assumes all of linux == systemd doesn't apply. Either way, we'll never know, because the systemd devs did not even bother to try being good actors, here. They're ignoring libc entirely in favor of pushing systemd dependencies up the stack. edit: I want to take this a little bit farther: The idea that systemd devs have to push a bad engineering decision (to tightly couple low-level platform details) onto upstream code with no abstractions, which they are being heavily criticized for, was somehow necessary to avoid misguided criticism they might have received for trying to do this the right way, is simply a wrong argument that doesn't make sense.
- justinsaccount 10y ago
  I don't disagree with you. I look forward to tomorrows systemd hate post: Systemd developer asks libc to add systemd specific code
  - dingo_bat 10y ago
    But then the haters would be wrong and systemd would be right. Opposite of the current situation.