Hacker News new | past | comments | ask | show | jobs | submit login

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.




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.


> 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.


> 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.


>> 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.


I don't disagree with you. I look forward to tomorrows systemd hate post:

Systemd developer asks libc to add systemd specific code


But then the haters would be wrong and systemd would be right. Opposite of the current situation.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: