> Remember that udev and sysfs are written by the same people, working together off-list. They're free to break the exported data format on a whim, because they write the code at both ends and fundamentally they're talking to themselves. They honestly say you can't expect a new kernel to work with an old udev, and they say it with a straight face. (To me, this sounds like saying you can't expect a new kernel to work with an old version of ps, because of /proc.)

> Documentation is a threat to this way of working, because it would impose restrictions on them. A spec is only of use if you introduce the radical idea that the information exported by sysfs exists for some purpose _other_ than simply to provide udev with information (and a specific version of udev matched to that kernel version, at that).

http://lkml.iu.edu/hypermail/linux/kernel/0707.2/4230.html (http://www.landley.net/notes-2015.html#05-07-2015)

The software hierarchy in order of importance, starting with most important:

1. User's needs/wants

2. User's applications

3. User's operational environment

4. application APIs

5. OS services

6. OS Kernel.

The point of a OS is to make it easier to write and run applications. That is it.

The 'kernel on up' design is fantasy and is NEVER how it was done in Linux or GNU or anywhere.

GNU knew that User/User applications were primary importance. This is why they designed the OS following established APIs designed to help with application compatibility. Those APIs and GNU environment dictated the design of the kernel. Now as the requirements on OS rise so does the complexity. New needs/wants/desires dictate new design choices, of which filter from application on down.

Besides that it is pretty obvious that the standardization of systemd and the elimination of distribution-specific scripts and services has resulted in massive reduction of bugs and complexity in the Linux OS. Accounting for each distribution individually, counting those bugs up, adding all them into one lump sum... I am willing to bet that for every 1 bug that systemd introduces into the OS it has resolved at least a 1000.

I can boot a current day kernel with init=/bin/sh just fine.

What’s typical for Unix, for example, is that all the tools, the C library, the kernel, are all maintained in the same repository, right? And they’re released in sync, have the same coding style, the same build infrastructure, the same release cycles – everything’s the same. So you get the entire central part of the operating system like that. If people claim that, because we stick a lot of things into the Systemd repository, then it’s un-Unixish, then it’s absolutely the opposite. It’s more Unix-ish than Linux ever was!

Pid Eins goes through his own "mythbusting" around the concept that systemd is not consistent with the Unix philosophy: http://0pointer.de/blog/projects/the-biggest-myths.html

But Ken Thompson and the people who were around him had a different view. http://www.catb.org/esr/writings/taoup/html/ch01s06.html

(Doug McIlroy) (i) Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.

If you look through the abstracted rules esr proposes, they are often in complete contravention of the philosophy of systemd.

The number of things systemd has broken by design or accident is quite substantial. The amount of things it touches in Linux is significant. It's pretty stunning to me that even experienced developers don't see anything wrong with systemd - it has had profound effects on system reliability, performance, usability, etc, most of them extraordinarily negative, for a benefit that is unclear.

I think if the scope had been smaller, the vehement disagreement with the implementation/principles behind systemd would probably have been mitigated quite a bit.

We are where we are. For better or for worse, systemd is taking over many Linux distributions, put there by people who have a very different view of what Unix is about. The people that support systemd are more or less supporting similar principles as Microsoft espoused for many years - an integrated system so tightly put together that it becomes difficult to tease things apart or to understand the working of the system, and an additional giant SPOF - something early Linux advocates protested about so vehemently. Those of us who know the difference use alternative distributions or BSD, the former of which is becoming harder as package maintainers and software authors are relying on systemd more and more.

To be fair, commercial Linux is where the money is, and all this plays directly into Red Hat's business model.

Funny, how in the end we adopt the same methods and principles we so vociferously argued against.

I really dislike systemd as much as the next person, but this is not an issue with systemd as far as the maintainers know.

[1]https://news.ycombinator.com/item?id=11797075