4 ms·

The Unix philosophy: Write programs that do one thing and do it well. Systemd doesn't observe the Unix philosophy and that bothers many people.

geofft 10y ago
It's baffling to see people insist that that's the UNIX philosophy when the UNIX philosophy has always been about monolithic kernels over microkernels, so "do one thing" is out the window, and about worse-is-better over do-the-right-thing (https://www.dreamsongs.com/RiseOfWorseIsBetter.html https://www.dreamsongs.com/RiseOfWorseIsBetter.html), so "do it well" is out the window. And the userspace tools don't follow this either. Quoting http://prog21.dadgum.com/139.html http://prog21.dadgum.com/139.html : > The UNIX ls utility seemed like a good idea at the time. It's the poster child for the UNIX way: a small tool that does exactly one thing well. Here that thing is to display a list of filenames. But deciding exactly what filenames to display and in what format led to the addition of over 35 command-line switches. Now the man page for the BSD version of ls bears the shame of this footnote: "To maintain backward compatibility, the relationships between the many options are quite complex." Why, for instance, does ls have its own sorting options if the sort command exists? If ls, the most quintessential UNIX command, can't do one thing and do it well, why should anything else?
- justin_vanw 10y ago
  Agree 100%. There isn't some magic potion that makes commands compose simply and efficiently.
  - justinsaccount 10y ago
    There is, but it involves using a standardized structured data exchange format instead of formatted text. powershell solves this by using structured data everywhere at the expensive of not working that well with plain text. You should be able to run something like ls -l | sort +date,-size but you can't :-)
    - geofft 10y ago
      Right, but the same people who keep advocating "do one thing and do it well" also keep advocating "Write programs to handle text streams, because that is a universal interface," and there's no way to handle that sort of things with text streams. A "universal interface," whatever that means, cannot carry that metadata.
      - justinsaccount 10y ago
        I know.. It's almost like the people who came up with these ideas 40 years ago didn't think of everything. There are plenty of ways to do things better with basic text interfaces - a more standardized header format for example. If most tools just output tabbed separated values with a header, or the same thing vertically.. ie.. foo bar baz 1 2 3 4 5 6 or foo 1 4 bar 2 5 baz 3 6 It would have been a lot easier to write more "universal" tools that worked with this data. Or at least more tools like 'ifdata' that is part of moreutils. $ ifdata -pa wlan0 192.168.1.2 Instead of the mess people come up with to parse ifconfig output. Bryan Cantrill even said in a presentation something like that it should be "Write programs to handle json text streams, because that is a universal interface" these days.
    - ddalex 10y ago
      Sure you can. 5th column of `ls -l` is size; sort can do numerical values > ls -tl | sort -k 5 -n
      - justinsaccount 10y ago
        Not the same thing, ls -l | sort +date,-size was to show how sorting by date ascending and size descending could work. 'sort' can sort by different fields in different orders, but to sort times properly you'd need to use ls with `--full-time` or --time-style=long-iso` which is in GNU ls but not the BSD ls on OS X. You'd end up with something like ls -l --full-time |sort -k 6,5rn But that doesn't quite work. Besides, the 'sort -k 6,5rn' instead of 'sort +date,-size' is exactly the kind of thing I was trying to show. We could have had a sort that let you do '+date,-size', instead we have a 'universal interface'.
- lasermike026 10y ago
  The Unix philosophy is most applicable in user space. It's a philosophy not a law. I didn't say Systemd was bad just that it doesn't observe the Unix philosophy. Crashing an init process is a very bad thing, is it not? Wouldn't less surface area be a better approach?
  - deleted 10y ago
    [deleted]
  - geofft 10y ago
    Yes, I argued in another comment that it would be a good idea to split systemd into two processes, where PID 1 does nothing other than reap children, send info to PID 2 actual systemd, and restart PID 2 if needed. But it seems to make sense for PID 2 to be as monolithic as systemd currently is (which is not very monolithic; udev, journald, D-Bus, etc. are separate daemons).
    - fridsun 10y ago
      You just described how daemontools family works. They are less monolithic than systemd because they didn't subsume udev.
    - JdeBP 10y ago
      That's a common misconception. The major task of process #1 with modern kernels is not, ironically, reaping children but receiving signals. Reaping orphaned children can be, and with several softwares is, the job of other processes. * https://news.ycombinator.com/item?id=8904429 https://news.ycombinator.com/item?id=8904429 * http://unix.stackexchange.com/a/197472/5132 http://unix.stackexchange.com/a/197472/5132 * https://news.ycombinator.com/item?id=8384251 https://news.ycombinator.com/item?id=8384251 * http://unix.stackexchange.com/a/177361/5132 http://unix.stackexchange.com/a/177361/5132
      - geofft 10y ago
        That makes no sense. Who's sending SIGWINCH to pid 1? Is it in a tty? Why is it in a tty? Why does it care about the size of its window? It is true that the userspace helper programs of some init system suites, such as sysvinit's telinit, work by sending signals to pid 1. But 1) they send signals to pid 1 because pid 1 is the service manager, not because it's the system manager, and 2) they could do something else other than sending signals (like sending D-Bus messages). The choice to use signals is a design decision of the init system suite, and not a part of the inherent requirements of being pid 1. It is also true that with prctl(PR_SET_CHILD_SUBREAPER) you can move reaping away from pid 1. But at that point, the proper function of pid 1 is nothing, except perhaps to respawn pid 2 if it wants to. And as I argued in the other comment in this thread https://news.ycombinator.com/item?id=12600734 https://news.ycombinator.com/item?id=12600734, that's silly and you should just make the kernel do it. I don't see any explanation in any of those links, or the things they link to, about why pid 1 is receiving signals. You claim twice that SIGINT, SIGPWR, and SIGWINCH are things that pid 1 can receive, but I have no idea why it might receive them. Can you explain?
- regularfry 10y ago
  Because that specific thing is crufty and bad, and now can't be fixed for back-compat reasons. Neither of these are justifications for introducing more crufty badness.
- wruza 10y ago
  Probably because sorting human-oriented dates is not a trivial task, as it is for recursive listings.
- thescribe 10y ago
  Instead of talking about Unix philosophy let me put it this way. I love whitebox components I can swap out for competing components. Systemd threatens that for me.
justin_vanw 10y ago
So why not break systemd down to components that can follow that philosophy? Or replace it with something that does, but is borderline systemd compatible so it can be swapped in? Why not submit a patch that fixes the umask issue the author talks about, or if they won't merge the patch, fork systemd? This is open source, writing a circle-jerk blog post isn't going to help anything.
koffiezet 10y ago
I'm not that strict on the "unix philosophy". It tends to work, but sure there are exceptions. But if you happen to write something like that does many things, you should also make sure you do every single of those many things well. What bothers me is that systemd doesn't do that, and that somehow this "unix philosophy" criticism seems to be an excuse/defense for crappy design and code.

geofft 10y ago

It's baffling to see people insist that that's the UNIX philosophy when the UNIX philosophy has always been about monolithic kernels over microkernels, so "do one thing" is out the window, and about worse-is-better over do-the-right-thing (https://www.dreamsongs.com/RiseOfWorseIsBetter.html https://www.dreamsongs.com/RiseOfWorseIsBetter.html), so "do it well" is out the window. And the userspace tools don't follow this either. Quoting http://prog21.dadgum.com/139.html http://prog21.dadgum.com/139.html : > The UNIX ls utility seemed like a good idea at the time. It's the poster child for the UNIX way: a small tool that does exactly one thing well. Here that thing is to display a list of filenames. But deciding exactly what filenames to display and in what format led to the addition of over 35 command-line switches. Now the man page for the BSD version of ls bears the shame of this footnote: "To maintain backward compatibility, the relationships between the many options are quite complex." Why, for instance, does ls have its own sorting options if the sort command exists? If ls, the most quintessential UNIX command, can't do one thing and do it well, why should anything else?

justin_vanw 10y ago
Agree 100%. There isn't some magic potion that makes commands compose simply and efficiently.
- justinsaccount 10y ago
  There is, but it involves using a standardized structured data exchange format instead of formatted text. powershell solves this by using structured data everywhere at the expensive of not working that well with plain text. You should be able to run something like ls -l | sort +date,-size but you can't :-)
  - geofft 10y ago
    Right, but the same people who keep advocating "do one thing and do it well" also keep advocating "Write programs to handle text streams, because that is a universal interface," and there's no way to handle that sort of things with text streams. A "universal interface," whatever that means, cannot carry that metadata.
    - justinsaccount 10y ago
      I know.. It's almost like the people who came up with these ideas 40 years ago didn't think of everything. There are plenty of ways to do things better with basic text interfaces - a more standardized header format for example. If most tools just output tabbed separated values with a header, or the same thing vertically.. ie.. foo bar baz 1 2 3 4 5 6 or foo 1 4 bar 2 5 baz 3 6 It would have been a lot easier to write more "universal" tools that worked with this data. Or at least more tools like 'ifdata' that is part of moreutils. $ ifdata -pa wlan0 192.168.1.2 Instead of the mess people come up with to parse ifconfig output. Bryan Cantrill even said in a presentation something like that it should be "Write programs to handle json text streams, because that is a universal interface" these days.
  - ddalex 10y ago
    Sure you can. 5th column of `ls -l` is size; sort can do numerical values > ls -tl | sort -k 5 -n
    - justinsaccount 10y ago
      Not the same thing, ls -l | sort +date,-size was to show how sorting by date ascending and size descending could work. 'sort' can sort by different fields in different orders, but to sort times properly you'd need to use ls with `--full-time` or --time-style=long-iso` which is in GNU ls but not the BSD ls on OS X. You'd end up with something like ls -l --full-time |sort -k 6,5rn But that doesn't quite work. Besides, the 'sort -k 6,5rn' instead of 'sort +date,-size' is exactly the kind of thing I was trying to show. We could have had a sort that let you do '+date,-size', instead we have a 'universal interface'.
lasermike026 10y ago
The Unix philosophy is most applicable in user space. It's a philosophy not a law. I didn't say Systemd was bad just that it doesn't observe the Unix philosophy. Crashing an init process is a very bad thing, is it not? Wouldn't less surface area be a better approach?
- deleted 10y ago
  [deleted]
- geofft 10y ago
  Yes, I argued in another comment that it would be a good idea to split systemd into two processes, where PID 1 does nothing other than reap children, send info to PID 2 actual systemd, and restart PID 2 if needed. But it seems to make sense for PID 2 to be as monolithic as systemd currently is (which is not very monolithic; udev, journald, D-Bus, etc. are separate daemons).
  - fridsun 10y ago
    You just described how daemontools family works. They are less monolithic than systemd because they didn't subsume udev.
  - JdeBP 10y ago
    That's a common misconception. The major task of process #1 with modern kernels is not, ironically, reaping children but receiving signals. Reaping orphaned children can be, and with several softwares is, the job of other processes. * https://news.ycombinator.com/item?id=8904429 https://news.ycombinator.com/item?id=8904429 * http://unix.stackexchange.com/a/197472/5132 http://unix.stackexchange.com/a/197472/5132 * https://news.ycombinator.com/item?id=8384251 https://news.ycombinator.com/item?id=8384251 * http://unix.stackexchange.com/a/177361/5132 http://unix.stackexchange.com/a/177361/5132
    - geofft 10y ago
      That makes no sense. Who's sending SIGWINCH to pid 1? Is it in a tty? Why is it in a tty? Why does it care about the size of its window? It is true that the userspace helper programs of some init system suites, such as sysvinit's telinit, work by sending signals to pid 1. But 1) they send signals to pid 1 because pid 1 is the service manager, not because it's the system manager, and 2) they could do something else other than sending signals (like sending D-Bus messages). The choice to use signals is a design decision of the init system suite, and not a part of the inherent requirements of being pid 1. It is also true that with prctl(PR_SET_CHILD_SUBREAPER) you can move reaping away from pid 1. But at that point, the proper function of pid 1 is nothing, except perhaps to respawn pid 2 if it wants to. And as I argued in the other comment in this thread https://news.ycombinator.com/item?id=12600734 https://news.ycombinator.com/item?id=12600734, that's silly and you should just make the kernel do it. I don't see any explanation in any of those links, or the things they link to, about why pid 1 is receiving signals. You claim twice that SIGINT, SIGPWR, and SIGWINCH are things that pid 1 can receive, but I have no idea why it might receive them. Can you explain?
regularfry 10y ago
Because that specific thing is crufty and bad, and now can't be fixed for back-compat reasons. Neither of these are justifications for introducing more crufty badness.
wruza 10y ago
Probably because sorting human-oriented dates is not a trivial task, as it is for recursive listings.
thescribe 10y ago
Instead of talking about Unix philosophy let me put it this way. I love whitebox components I can swap out for competing components. Systemd threatens that for me.

justin_vanw 10y ago

So why not break systemd down to components that can follow that philosophy? Or replace it with something that does, but is borderline systemd compatible so it can be swapped in? Why not submit a patch that fixes the umask issue the author talks about, or if they won't merge the patch, fork systemd? This is open source, writing a circle-jerk blog post isn't going to help anything.

koffiezet 10y ago

I'm not that strict on the "unix philosophy". It tends to work, but sure there are exceptions. But if you happen to write something like that does many things, you should also make sure you do every single of those many things well. What bothers me is that systemd doesn't do that, and that somehow this "unix philosophy" criticism seems to be an excuse/defense for crappy design and code.