4 ms·

Those are good questions, but answering them won't fit in a comment. It takes more like a book. One of the best books on the Unix philosophy is "The Art of Un

by chubot 12y ago

Those are good questions, but answering them won't fit in a comment. It takes more like a book. One of the best books on the Unix philosophy is "The Art of Unix Programming", which is available for free. (I recommend getting a hard copy and reading the whole thing.) http://www.catb.org/esr/writings/taoup/html/ http://www.catb.org/esr/writings/taoup/html/ Other books include The Unix Programming Environment by Pike et. al., though it's less explicit about the philosophy. Here's one part of the argument: systemd breaks the Unix design style because it's monolithic: http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2877537 http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2... But then systemd developers claim it's not monolithic because it's actually composed of multiple processes. They say there is a misconception that all code is contained in PID 1. There are many executables and many processes, so they would say systemd is modular. But the problem is that all the binaries are released together, without well-defined interfaces. Moreover they are also tightly coupled to kernel features. If you have 2 binaries A and B, but the interfaces between them is not documented or stable, then it's not really modular, because you can't write your own B' to work with A or A' to work with B. The recent thread here about dbus is a good example. Traditional Unix is simple text protocols. dbus is this weird text/binary RPC-ish mix which is not documented. There are lots of other issues with systemd and the Unix philosophy, but that should give you a flavor.

GFK_of_xmaspast 12y ago
Eric Raymond is not worth taking seriously except as a bad example. That aside, poking around I found this: http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ http://www.freedesktop.org/wiki/Software/systemd/InterfacePo... which looks like reasonably well-defined interfaces? Also not really seeing the problem with a binary protocol, works fine for tcp/ip.
- deleted 12y ago
  [deleted]
- chubot 12y ago
  If you don't think the content of that book is relevant to the systemd debate, then you haven't read it. I'd like to see you point to a better book about the Unix philosophy. http://en.wikipedia.org/wiki/Ad_hominem http://en.wikipedia.org/wiki/Ad_hominem
  - GFK_of_xmaspast 12y ago
    I've been using unices for over 20 years now (first was ultrix, then truos, sunos, solaris, hpux, aix, linux, netbsd, freebsd, osx) and I don't believe there is such a thing as a unix philosophy.
    - chubot 12y ago
      Give the Art of Unix Programming and honest read, and I'm sure you will come around. If you have ONLY used Unices, then I could understand why the philosophy is invisible. If, like me, you had used Windows exclusively for a decade, and then Unix for a decade, then the Unix philosophy would knock you up side the head. The systems could not be more different. (Despite the fact that they run mostly the same applications. http://www.joelonsoftware.com/articles/Biculturalism.html http://www.joelonsoftware.com/articles/Biculturalism.html is the review that got me to read it).
      - GFK_of_xmaspast 12y ago
        Of course I haven't only used unices, how is that even possible in this world.
- digi_owl 12y ago
  That is the interface between the systemd sub-daemons and third party code. There is no such promise about the interfaces between said sub-daemons and systemd-init.
the_why_of_y 12y ago
> systemd breaks the Unix design style because it's monolithic: > But the problem is that all the binaries are released together, without well-defined interfaces. So are Xorg and Apache HTTPD, which break module ABI with every release. Postfix and qmail are also monolithic (according to your reasoning), with a modular implementation of multiple processes but no stable interface between them. If you replace of the postfix processes with one of the qmail processes you won't get a working MTA. Not to mention the Linux, FreeBSD, Solaris etc. kernels themselves. Why is it then that we see this argument only used against systemd, when your average Linux distro install is primarily composed of software systems that you would consider to be monolithic? > Moreover they are also tightly coupled to kernel features. sysvinit is also tied to kernel features: it won't work without Linux procfs. > dbus is this weird text/binary RPC-ish mix which is not documented. No idea where you got that idea, is this D-Bus protocol documentation is a figment of my imagination? http://dbus.freedesktop.org/doc/dbus-specification.html http://dbus.freedesktop.org/doc/dbus-specification.html
- dandelion_lover 12y ago
  Not the parent, but willing to answer. > Why is it then that we see this argument only used against systemd WIth systemd we see the changes against Unix design, whereas your other examples already exist.
- chubot 12y ago
  This is the dbus post I'm referring to: https://news.ycombinator.com/item?id=8648437 https://news.ycombinator.com/item?id=8648437 Here's a nice quote right from the doc you linked: The D-Bus protocol is frozen (only compatible extensions are allowed) as of November 8, 2006. However, this specification could still use a fair bit of work to make interoperable reimplementation possible without reference to the D-Bus reference implementation. The fact that you even NEED a (crappy) doc is a sign it doesn't use the Unix design philosophy. In contrast, look at the Debian Control File format, which apt metadata is stored in. I parsed and wrote a dependency resolver for it WITHOUT any reference to docs. The format is self-documenting text. X is Unix style in the sense that you can plug in different window managers, but not Unix style in other ways. Shared library extension modules (e.g. Apache, Python, etc.) are not "classic" Unix. Classic Unix simply didn't have shared libraries (or threads). Plan 9 and Go explicitly have this heritage; they don't support shared libraries. Apache is Unix style because it uses stable protocols between application and server, like CGI, FastCGI, etc. It also uses textual logs, unlike systemd. I would also argue that systemd encompasses more diverse functionality than either X or Apache, which is saying a lot. The bigger a system is, the worse a monolithic architecture is. But you're right that modern Unix doesn't follow Unix style in many ways. I am not arguing for purity -- shared libraries are useful, and graphics don't fit well within Unix style. But I do think it is worth understanding the Unix style, for very a practical reason. That reason being: you simply end up with less code when your systems are modular and composable.

by chubot 12y ago

GFK_of_xmaspast 12y ago

Eric Raymond is not worth taking seriously except as a bad example. That aside, poking around I found this: http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ http://www.freedesktop.org/wiki/Software/systemd/InterfacePo... which looks like reasonably well-defined interfaces? Also not really seeing the problem with a binary protocol, works fine for tcp/ip.

deleted 12y ago
[deleted]
chubot 12y ago
If you don't think the content of that book is relevant to the systemd debate, then you haven't read it. I'd like to see you point to a better book about the Unix philosophy. http://en.wikipedia.org/wiki/Ad_hominem http://en.wikipedia.org/wiki/Ad_hominem
- GFK_of_xmaspast 12y ago
  I've been using unices for over 20 years now (first was ultrix, then truos, sunos, solaris, hpux, aix, linux, netbsd, freebsd, osx) and I don't believe there is such a thing as a unix philosophy.
  - chubot 12y ago
    Give the Art of Unix Programming and honest read, and I'm sure you will come around. If you have ONLY used Unices, then I could understand why the philosophy is invisible. If, like me, you had used Windows exclusively for a decade, and then Unix for a decade, then the Unix philosophy would knock you up side the head. The systems could not be more different. (Despite the fact that they run mostly the same applications. http://www.joelonsoftware.com/articles/Biculturalism.html http://www.joelonsoftware.com/articles/Biculturalism.html is the review that got me to read it).
    - GFK_of_xmaspast 12y ago
      Of course I haven't only used unices, how is that even possible in this world.
digi_owl 12y ago
That is the interface between the systemd sub-daemons and third party code. There is no such promise about the interfaces between said sub-daemons and systemd-init.

the_why_of_y 12y ago

> systemd breaks the Unix design style because it's monolithic: > But the problem is that all the binaries are released together, without well-defined interfaces. So are Xorg and Apache HTTPD, which break module ABI with every release. Postfix and qmail are also monolithic (according to your reasoning), with a modular implementation of multiple processes but no stable interface between them. If you replace of the postfix processes with one of the qmail processes you won't get a working MTA. Not to mention the Linux, FreeBSD, Solaris etc. kernels themselves. Why is it then that we see this argument only used against systemd, when your average Linux distro install is primarily composed of software systems that you would consider to be monolithic? > Moreover they are also tightly coupled to kernel features. sysvinit is also tied to kernel features: it won't work without Linux procfs. > dbus is this weird text/binary RPC-ish mix which is not documented. No idea where you got that idea, is this D-Bus protocol documentation is a figment of my imagination? http://dbus.freedesktop.org/doc/dbus-specification.html http://dbus.freedesktop.org/doc/dbus-specification.html

dandelion_lover 12y ago
Not the parent, but willing to answer. > Why is it then that we see this argument only used against systemd WIth systemd we see the changes against Unix design, whereas your other examples already exist.
chubot 12y ago
This is the dbus post I'm referring to: https://news.ycombinator.com/item?id=8648437 https://news.ycombinator.com/item?id=8648437 Here's a nice quote right from the doc you linked: The D-Bus protocol is frozen (only compatible extensions are allowed) as of November 8, 2006. However, this specification could still use a fair bit of work to make interoperable reimplementation possible without reference to the D-Bus reference implementation. The fact that you even NEED a (crappy) doc is a sign it doesn't use the Unix design philosophy. In contrast, look at the Debian Control File format, which apt metadata is stored in. I parsed and wrote a dependency resolver for it WITHOUT any reference to docs. The format is self-documenting text. X is Unix style in the sense that you can plug in different window managers, but not Unix style in other ways. Shared library extension modules (e.g. Apache, Python, etc.) are not "classic" Unix. Classic Unix simply didn't have shared libraries (or threads). Plan 9 and Go explicitly have this heritage; they don't support shared libraries. Apache is Unix style because it uses stable protocols between application and server, like CGI, FastCGI, etc. It also uses textual logs, unlike systemd. I would also argue that systemd encompasses more diverse functionality than either X or Apache, which is saying a lot. The bigger a system is, the worse a monolithic architecture is. But you're right that modern Unix doesn't follow Unix style in many ways. I am not arguing for purity -- shared libraries are useful, and graphics don't fit well within Unix style. But I do think it is worth understanding the Unix style, for very a practical reason. That reason being: you simply end up with less code when your systems are modular and composable.