3 ms·
One of the primary use cases of tmux/screen is to act as a base for Process Groups so that this does not happen. There was a case for the init system doing thi
by cturner 10y ago
One of the primary use cases of tmux/screen is to act as a base for Process Groups so that this does not happen.
There was a case for the init system doing this when unix was young. But changing it now breaks convention, and compat with other distros, without good cause.
Let me explain where I come from. At times I write distributed systems that expect to be based in a non-specific unix.
Whenever I mess around in an area such as process control, I carefully read the relevant section of Stevens and my distro's own docs (usually linux and until now I have tried to avoid caring about choice in init system). And - in these phases - I write in C because I don't trust that runtimes like python won't have wacky defaults that make the system hard to reason about.
This issue is a groaner, because it suggests that mainstream linux is becoming harder to reason about during development and debugging. Instead of being able to think clearly and tell the computer what to do, you will be constantly looking over your shoulder for unnecessary vagueries of your local systemd configuration and whatever quirks have been introduced by the neckbeard who owns commit rights to its default behaviours.
This bug and the abrasive german's response in the ticket suggest to me that there is a point in the near future where people who care about developing against the unix api will Bozo-bit systemd-affected distros altogether. Which would be a shame for all the good citizens who have steadily done low ego work towards those distros.
- AnonymousPlanet 10y agoIn an earlier version of your post you said > This reminds me of a character of windows-based development that I find exhausting: opaque layers of unnecessary complexity. This is pretty much exactly how I feel about this whole thing. While designing NT, MS made a number of assumptions and decisions that were sensible from an engineering point of view back then. Especially if you're very much into OO (wich was the new rage back then). But from an administrator or system programmer point of view, these byzantine structures get more in the way than they help. On top of that, it makes integrating new ideas harder and you end up with layers and layers of API sediment. The people behind systemd are making very similar decisions and assumptions, deviating from the very principles of Unix that prevent this short sightedness.
- cturner 10y agoThanks. I removed this because I felt it was unfair on Windows. Windows has strange things in it, but then Raymond Chen will write a post clearly explaining it, and they are strong on backwards compatibility. Everything you say is true. But you can read docs and write in C and work to a conclusion. Systemd is shaping up to be a layer of complexity that constantly shifts underneath you. It is going to be a nightmare for people who build on unix. The unix api and conventions are our bedrock. This is not sustainable.
- AnonymousPlanet 10y agoSystemd might become stable at some point, but I'm more and more getting the idea that yanking Linux away from that Unix bedrock is the very purpose of it.
- digi_owl 10y agoIt may well be. Not sure if i can produce a link off hand. But Poettering seems to be on record about having no interest in unix.