Comment by pkkm | Hacker News Reader

Comment by pkkm | Hacker News Reader

Parent Full thread

> The core idea is "do one thing and do it well".

The historical "unix philosophy" was specifically about small programs communicating over pipes via plain text. If you retroactively change it to "do one thing and do it well", then it becomes a meaningless truism. "One thing" is so vague that you could argue Photoshop does one thing too; every large piece of software uses some kind of modularity; and who would deliberately write a program to do its job badly? The devil is always in the details that such cliches don't help us decide: how broad should our definition of "one thing" be, what should be the unit of modularity (processes, classes, Python modules?), what is the communication interface between the modules.

In the case of systemd, it's an umbrella project maintaining a bunch of medium-size C programs that communicate mostly over D-Bus, in ways that are extensively documented on systemd's website. I find it to be a big improvement in interoperability. Before systemd, most distros used the "simple" sysvinit in theory, but in practice sysvinit was so lacking in features and such a pain in the ass to program for that each distro usually shipped a bunch of helpers glued together with shell and Perl. So you would have to write distro-specific stuff, based on documentation that was less abundant than systemd's. That wasn't very good for interoperability.

Can you elaborate on how systemd doesn't let you use your system as a general purpose computer? Because that sounds ridiculous on the surface. There are several ways in which systemd is more general and hackable than sysvinit, for example having targets instead of runlevels. And in practice, after the introduction of systemd I've only found it easier to look into things on my system and tinker with it. journalctl's log formatting and filtering is a very useful addition to grepping when you need to investigate a problem quickly, and systemd user services have made it trivial for me to run my short Python scripts as full-featured daemons that write to my system's log and can be monitored.

Figuring what is "the one thing" is the art. It's like factoring code in separate functions that work well together and with others. There are no strict rules, criteria or methods to attain it.

Small programs communicating over pipes via plain text was/is the implementation. The philosophy is more general [1]. This one is more or less how I think of it:

"Even though the UNIX system introduces a number of innovative programs and techniques, no single program or idea makes it work well. Instead, what makes it effective is the approach to programming, a philosophy of using the computer. Although that philosophy can't be written down in a single sentence, at its heart is the idea that the power of a system comes more from the relationships among programs than from the programs themselves. Many UNIX programs do quite trivial things in isolation, but, combined with other programs, become general and useful tools."

"Medium sized" (systemd alone is around a million lines) C-programs are extremely difficult to debug or modify if you're not intimately familiar with the codebase. The code in them can't typically be used for any other purposes. Sysvinit as a program is very small, but the point is the protocol that allows multiple different kinds of programs to co-operate. Being able to glue things together with shell and Perl is a feature, not a bug.

Journalctl is a good example of violating the UNIX philosophy. It contains its own binary format, its own grep, its own head and tail, etc. With /var/log files you don't have separate cat, grep or tail to examine files and directory listings. That is the UNIX point. And this is what I mean by general purpose.

sysvinit had/has plenty of problems and systemd typically works better at least nowadays. I'm not singing any praises of sysvinit. But e.g. OpenRC manages initing without a million lines of code and taking control of more or less the whole OS.

[1] https://en.wikipedia.org/wiki/Unix_philosophy

This is just motte-and-bailey. You're shifting the definition of the "unix philosophy" between the general idea of interoperability, and the UNIX design of small programs that communicate via text and are glued together with the shell and pipes. The argument doesn't work if you actually use a consistent definition: the former is an obviously good thing but also an area where systemd scores well, and the latter isn't necessarily a good idea when you're doing something other than ad-hoc text manipulation.

I honestly don't understand why people want to do all these rhetorical backflips in order to maintain some kind of bizarre religious reverence for the "unix philosophy". UNIX's design was quite mediocre, it only looks brilliant when compared to the DOS lineage.

How about you make an actual technical criticism of systemd instead of hiding behind vague generalities? In particular, why is it bad that all the functionality needed to manage and monitor daemons is in one program? How would you split it into several programs in a way that maintains systemd's robustness for administrators and convenience for developers? What would be the practical benefits of this split to the users and developers (no "philosophies" please)? Can you justify that this proposed split would reduce systemic complexity (the complexity of the whole system) instead of actually increasing it by just shifting responsibilities onto daemon developers?

Reply on news.ycombinator.com