I don't. And that means a whole range of software does not run on my system.

Which is the opposite of any UNIX way ever.

Most of all, and most seriously and utterly broken, you can't replace journald. Ever. And you can't replaced udev. Or logind, if you wish to run Gnome.

In fact, apart from networkd which isn't finished, I don't know of any part of systemd which you can replace with an alternative yet have systemd work with it as if systemd was actually a piece of UNIXy software.

Mostly because systemd is not a piece of UNIXy software.

Congratulations on your complimentary Cool Aid. But did you have to drink it all in one go?

If you want to get shafted, be my guest. Just don't expect me to thank you, because when you ask for a shafting you reduce *my* freedom by making it that much harder to get rid of DRM.

"Freedom" to watch DRM'ed content?

You're asking for the freedom to be shafted.

RMS is asking you to reconsider.

The choice is yours.

He does, however, hold 14 honorary doctorates, several from schools which do not mind him using Dr.

I know how to do this, as it is part of my job. I prepare and speak, and people listen and (as apparent from their actions afterwards) understand.

Does that mean I could do so on any subject to any audience? No, not at all. I can do it in subjects I know well, when presenting them to a motivated audience. And I can do it without choked powerpoints or flashy graphs.

I find it astounding that not all high tech professionals can do this, but I have experienced so many truly horrid presentations that it appears to be a rare skill.

This is not even remotely true, as you would know had you actually bothered to read Stallman's arguments instead of only watching this intentionally simplified video.

It is, in fact, one of the main dangers Stallman sees with mixing proprietary software in distributions. Your myopia blinds you to that insightedness of his though, which is an irony in itself.

As to that it will "never affect most users", I will simply let Stallman's record speak for itself.

If you had any actual interest at all in learning this instead of trying to use it as a bat of some kind, you would already know the answer. But for the edification not of you, dear AC, but of anyone who might stumble on this:

http://www.linuxtoday.com/infr...

You have the "linux way" (it is actually the Unix philosophy) completely wrong. It is not "one program for one task". It is:

"Developers should build a program out of simple parts connected by well defined interfaces, so problems are local, and parts of the program can be replaced in future versions to support new features. This rule aims to save time on debugging code that is complex, long, and unreadable."
-- Eric S. Raymond

"Developers should design their programs to be flexible and open. This rule aims to make programs flexible, allowing them to be used in other ways than their developers intended."
-- Eric S. Raymond

"This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."
-- Doug McIlroy

What systemd does wrong is abandoning this and using API's internally - API's it does not even lock down. It's a morass.

"Everything was small... and my heart sinks for Linux when I see the size of it. [...] The manual page, which really used to be a manual page, is now a small volume, with a thousand options... We used to sit around in the Unix Room saying, 'What can we throw out? Why is there this option?' It's often because there is some deficiency in the basic design â" you didn't really hit the right design point. Instead of adding an option, think about what was forcing you to add that option."
-- Doug McIlroy

"Developers should design for the future by making their protocols extensible, allowing for easy plugins without modification to the program's architecture by other developers, noting the version of the program, and more. This rule aims to extend the lifespan and enhance the utility of the code the developer writes."
-- Eric S. Raymond

Yes, systemd IS the end of the world that many people want you to believe.

Any daemon manager solves the problems you listed. And the whole point of having an init that basically does nothing is - that init does basically nothing. That is what it is SUPPOSED to do, hand over to other processes.

And I do not want my daemon manager to do "all the stuff". I want it to obey my commands on starting and stopping daemons. Period. You may want yours to do more, and then you can use another daemon manager. That's what's called the UNIXy way. Ever hear of it?

I do not want parallelization; I hardly ever reboot my desktop/laptop systems, and on servers it makes no difference since the main time is spent waiting for IO to configure itself.

I do not want socket and/or D-Bus to start the few services I need started. I see no point to that. And I most definitely do not want on-demand starting of daemons! That removes determinism from my system and will make bug hunting a chore.

Ok, I want processes managed using control groups. But not by init. I want a daemon not connected to init to do that.

I am completely unmoved by the "system state" snapshot talk, since if I wanted that I'd be on Xen or VMware. I don't have use for that.

I have fstab for my mount points, and the only automount I do is the occasional USB stick which mounts from a specific user, using a simple script.

I absolutely DO NOT need an "elaborate ... logic" for ANYTHING related to init!

So far I have seen no reason to read any more about this, nor any reason why I'd want it anywhere near any of my systems.

The point is that they're API's. That is what makes systemd a fragile monolith. And the solution to this is to not allow anything to replace a part of systemd; if you want an alternative it will run in parallel with the systemd equivalent.

That is pasting over the fragility instead of fixing it. It's a huge mess. Sure, it was required, because it will make sure someone writes a sane solution instead, but right now it's a huge pain.

The problem with logind is that you do not communicate with it like you communicate with everything else in a UNIXy system. It has an API, which is not fixed, and logind in turn relies on API's to communicate with other parts of systemd.

None of the chunks in systemd do one thing, do it will and provide a UNIXy way to assemble them together. They're a huge blob of interdependent API's.

And yes, if it wasn't part of this API infested mess people would indeed be arguing that systemd should be more like it. But unfortunately that is not the case.

It's not supposed to do that. It's an INIT system. If you want a daemon manager, the init system can start one for you.

11:25 The answer is do the best you can. Support those who are the least closed.

12:48 If you are paid to write software, do what you can to have that software under GPL license. If you develop video games, do what Id Software does, and release the code as GPL when it's feasible to do so. It's not perfect, but it's a lot better than not releasing anything ever.