Well Apache, OpenOffice and PostgreSQL are perhaps not the prime examples of the Unix philosophy however...
Apache stores all its logs and configuration, as well as much of its data in text files. It has one function and one function only, to reply to HTTP requests.
OpenOffice isn't really Unix software, it's an office package. People following the Unix philosophy see those as a violation of it.
PostgreSQL also does one thing. It processes SQL databases... and while it's using a binary format internally, all the interfaces are text based... in fact even the backup format is text.

But let's refute Poetterling while we are there:

"If you build systemd with all configuration options enabled you will build 69 individual binaries.":
Yes, but how are the dependencies? Do they share the same huge set of bloated libraries? What will happen if, for example the DBUS library gets corrupted for some reason? How many vital libraries are there?

"Myth: systemd's fast boot-up is irrelevant for servers." He refutes that himself a few lines down: "Of course, in many server setups boot-up is indeed irrelevant"

I stopped reading there. Seriously Poetterling hasn't understood Unix, if he would he would understand that binary software is something only to be done if there's a serious reason for it.

1. Ever had to use AIX, Solaris or MacOSX? Do you know why so comparatively few people use those systems by choice?

2. Well yes, it's about the opinion that systems should be working well. So far there have been few systems getting you as much "bang for the buck" as Unix. And none of those use binary data formats with C or C++.

Well I can read a text format with cat. With a binary format I need to use special tools which may or may not be available depending on the state of brokenness. It's much more likely to get cat to run than whatever binary tool there is.

Well standard SysV init will only fail unless there are some serious problems... like being unable to mount the root file system... in those cases it will give you a helpful message on the console.
And even if it fails, you are still typically left with /bin/sh if that can be loaded. That's good enough to diagnose and fix any SysV init problem.

The problem with systemd is that it is going back to the time when there were complex systems talking via binary interfaces. It introduces complexity without benefit. For example why does systemd have to be a binary? What advantage does that bring?

In a way systemd is the line that has to be drawn when it comes to useless bloat. People did tolerate pulseaudio and DBus to some degree, those are absolutely non essential services, but booting and logging is something essential. If your system won't boot and you won't have a decent way to fix it, you'll have a serious problem.

It's not Linux, it's the runtime system, so there is no need to fork... but I think it's about time for a distribution to actually take the Unix philosophy to heart and to throw out all that new crap.

The time when people who had no idea started to believe they could create something better then UNIX.
This created the mess we had in the 1990s when it was OK to have log files in binary files and you could only view them through a small non-resizable window. A time when you could display the owners of open files on your network share... but you couldn't do anything with that info except for writing it down and manually act upon it. Of course that data was also displayed in a small non-resizable window.

There is a reason why normal init is based on shell scripts, and that reason is simply because there is no reason against it. Shell scripts are perfectly adequate for that job. Binaries on Unix however make it much more difficult to deal with them. If you want to edit a binary you have to get the source code, edit it, make it compile, and then hope it'll run. It's even worse when you have dynamically linked binaries since they depend on other files, particularly for init.

Binaries are just a botched solution to somehow get faster execution. The whole design of Unix doesn't require them. Unlike Windows you shouldn't need to link in a library to have some API you should instead have a little program you can call. (actually Windows now has a little wrapper allowing you to make arbitrary calls to DLLs since even Microsoft has recognized the problem)

Dynamically linked libraries are just a botched solution for the problem of library bloat. You shouldn't need them, if you want some feature you should just call the program implementing it. That's how bc worked originally. All the calculation functionality was in dc and bc just re-formated its input to what dc expects. The problem why this doesn't work well any more is long startup times caused by library bloat.

So long as you don't blame it on Tesla, Bitcoin, or Starts with a Bang, everyone here will cool with it.

FWIW, windmills and skyscrapers kill a lot of birds too.

And automobiles, for that matter.

Why not skip all the expensive equipment and just use birds for fuel?

Apparently they think it's ok to put your fingers in, so long as you pay.

Does it say when we can start looting?

Yes! At Tunguska, even before they existed!

I wasn't particularly worried about a 2880pocalypse to begin with.

What chemicals spilled, other than all the radioactive water?

And since when have people not been interested in the effects of chemical spills, genetic or otherwise?

Bah, you're making the radical assumption that scientists have a clue about the things they study.