Live data from Hacker News

Don't panic and keep forking Debian

lists.dyne.org

121–130 of 135 posts

Re: Don't panic and keep forking Debian

#121
post #56

Earlier quoted context omitted.

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/ Other books include The Unix Programming Environment by Pike et. al., though it's less explicit about the ph…

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/InterfacePo... which looks like reasonably well-defined interfaces? Also not really seeing the problem with a binary protocol, works fine for tcp/ip.

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.

Re: Don't panic and keep forking Debian

#122
post #50

Earlier quoted context omitted.

You seem like someone who's used a variety of init systems, so I have some questions: 1. Why is systemd considered "un-unix"? 2. Why is sysv considered to "follow unix"? 3. Can you provide or point to some explanations on the ideologies that motivate the difference of opinions regarding sysv/systemd? 4. Really, can someone provide some context and history for all this?

With the caveat that I haven't kept up closely with systemd 1. It is attempting to unify a bunch of previously disconnected functionality into a single program. Typically unix is composed of small single-purpose utilities that perform a single function, rather than a giant monolithic blob of code (with obvious exceptions, like emacs). 2. Partially because it has been around for so long and has so much history, and pa…

>and don't hesitate to re-implement functionality (like logging) if it makes is easier to interoperate with their other code.

And in the process makes old mistakes.

http://seclists.org/oss-sec/2014/q4/592

What is the saying again? Those that don't learn from history is doomed to repeat it?

Re: Don't panic and keep forking Debian

#123
post #23

Can someone TL;DR the problem with systemd?

systemd replaces a large number of startup and utility programs (specifically: sysvinit, pm-utils, inetd, acpid, syslog, watchdog, cron and atd). It also adds new daemons for logs, logins, locales, hostnames and a few other services. Most of this is a good thing. Faster. Newer code that is easier to maintain. Less reliance on shell scripts favoring declarative config files instead. But change has lots of difficulties…

> Newer code that is easier to maintain.

It also brings "new" bugs.

http://seclists.org/oss-sec/2014/q4/592

Re: Don't panic and keep forking Debian

#124
post #29
post #23

Can someone TL;DR the problem with systemd?

Many people complaining about it is that it doesn't follow the Unix philosophy. I think that it's not so much that systemd is un-UNIX like (after all, it could be argued that X-windows is un-UNIX like too). I think the problem that people are having with it is that it is a cathedral that is getting erected right in the middle of their bazaar. (personally, I don't mind systemd, but I also didn't mind SysV, or BSD init…

>it is a cathedral that is getting erected right in the middle of their bazaar.

That is a beautiful mental image.

Re: Don't panic and keep forking Debian

#125
post #56

Earlier quoted context omitted.

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/ Other books include The Unix Programming Environment by Pike et. al., though it's less explicit about the ph…

> 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 pos…

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.

Re: Don't panic and keep forking Debian

#126
post #76

Earlier quoted context omitted.

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

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.

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 is the review that got me to read it).

Re: Don't panic and keep forking Debian

#127
post #56

Earlier quoted context omitted.

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/ Other books include The Unix Programming Environment by Pike et. al., though it's less explicit about the ph…

> 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 pos…

This is the dbus post I'm referring to: 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.

Re: Don't panic and keep forking Debian

#128
post #126

Earlier quoted context omitted.

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.

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…

Of course I haven't only used unices, how is that even possible in this world.

Re: Don't panic and keep forking Debian

#129
post #21
post #6

there was a lot of discussion on /r/linux about this yesterday. concessions seemed to be that Devuan seems fishy, but I'll let you read for yourself. http://www.reddit.com/r/linux/comments/2nm2u9/theyre_going_t...

consensus?

thanks, dunno how I missed that typo.

Re: Don't panic and keep forking Debian

#130
post #127

Earlier quoted context omitted.

> 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 pos…

This is the dbus post I'm referring to: 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…

> This is the dbus post I'm referring to: https://news.ycombinator.com/item?id=8648437

Oh right, somebody looked at the spec for 15 minutes, mis-read it completely (confusing the authentication protocol with the actual IPC protocol) and wrote a blog rant about their failure in reading comprehension. Very compelling.

> The fact that you even NEED a (crappy) doc is a sign it doesn't use the Unix design philosophy.

So HTTP is against the UNIX philosophy too? Or did you also happen to implement that without ever looking at the specification?

> In contrast, look at the Debian Control File format, which apt metadata is stored in.

In other words, apples make better apple juice than oranges.

> That reason being: you simply end up with less code when your systems are modular and composable.

You seem to be under the mis-apprehension that monolithic is somehow an antonym of modular. systemd is both modular and monolithic (in your meaning of that term).

Post reply on HN