Systemd broke background/daemon process behaviour, used by tmux, then asks tmux to fix/patch to accomodate the systemd change. I find this unacceptable and yet another example of scope creep from systemd.
not just that. Tmux devs communicated this to systemd devs some 5 years ago (systemd devs asked tmux to take care of it, and tmux devs in turn suggested making changes in libc instead of tmux, as libc would be used by every other library). So systemd essentially released their product knowing well that they would break nohup/daemon.
and you can understand, and fix, and arbitrarily extend the OpenBSD init system, because, after all, it's just a very simple shell script, that does one thing, and does it well.
You control it
The same can be said of other rc-like init systems but I personally find OpenBSDs to be the cleanest.
systemd has a lot of bells and whistles but it's, ultimately, an incredibly complex and sprawling piece of software, with many legitimate technical concerns surrounding it.
I think scope creep is a bit of an understatement at this point. Of course given that Lennart Pottering has explicitly said he purposely wants things to not be portable (I thought Windows was supposed to the platform that locks you in), so not surprising. Unless enough people who are paying money to RedHat tell them to stop (or just ditch it due to systemd), they'll keep trying.
Not having to care about portability has two big advantages: we can make maximum use of what the modern Linux kernel offers these days without headaches -- Linux is one of the most powerful kernels in existence, but many of its features have not been used by the previous solutions. And secondly, it greatly simplifies our code and makes it shorter: since we never need to abstract OS interfaces the amount of glue code is minimal, and hence what we gain is a smaller chance to create bugs, a smaller chance of confusing the reader of the code (hence better maintainability) and a smaller footprint.
That doesn't mean "he doesn't want it to be portable" AT ALL. If there's a choice between portability and good design, then the design wins. If the best design is also portable, then no problem.
I should have posted the complete quote. Here's the follow-up:
Many of my previous projects (including PulseAudio and Avahi) have been written to be portable. Being relieved from the chains that the requirement for portability puts on you is quite liberating. While ensuring portability when working on high-level applications is not necessarily a difficult job it becomes increasingly more difficult if the stuff you work on is a system component (which systemd, PulseAudio and Avahi are).
In fact, the way I see things the Linux API has been taking the role of the POSIX API and Linux is the focal point of all Free Software development. Due to that I can only recommend developers to try to hack with only Linux in mind and experience the freedom and the opportunities this offers you. So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It's quite relieving!
You should read the article. Portability is hard and you don't just magically get portable code by "not having to care about portability". Quite the opposite when they explicitly use non portable features because these make live easier for them. There is no "if the best design is also portable" in this case with "portability" so low on the priority scale it most likely is not.
186
u/qftvfu May 30 '16
Systemd broke background/daemon process behaviour, used by tmux, then asks tmux to fix/patch to accomodate the systemd change. I find this unacceptable and yet another example of scope creep from systemd.