I'm just a user...

OpenSource began as a philosophical response to a mindset that was regarded as unhealthy and incompatible with freedom. The software is an expression of that philosophical response. So any new software that disregards, or appears to disregard that philosophy, is immediately suspect. It's no surprise, given the corruption of OpenSource in recent years, that we now have a generation of users and developers who don't care about freedom, or security, or simplicity. But it is rather sad.

The KISS principle is fundamental. Adding a new and very complex gadget in order to replace an older, simpler but perfectly functioning gadget, breaks every principle of good design and engineering.
Take GRUB2 (please, it's hideous), GRUB1 was fine, LILO is awesome. Linux had 2 perfectly working boot loaders so what happens? Replace one of them with a far more complex system. It's files have different names, the lines of code are much more complex and long winded. Editing it is not as easy as it was. This is not progress.
This appears to be not about anything other than developer's egos.

I see Linux being dragged into the same muddied waters that Windows and OSX inhabit, in order to placate the same greedy amoral Corporations or the same mindless squawking "journalists", and all to please a mass of people who don't give a damn what OS they run as long as they can gain access to their stuff without having to think/learn/read.
Think of it this way, it's a bit like taking the Mona Lisa down and drawing breasts on it and putting an ipod in one hand so that the masses can "appreciate it", or taking a Mozart symphony and remixing it into a 4 minute drum and bass track but insisting that "it's still a Mozart symphony and classical music lovers can rest assured". It's a tragedy for art lovers and the masses don't care anyway. So you end up trashing your own treasure in the pursuit of the appreciation of those who don't understand what treasure is and would trample it in sheer ignorance if they came near it.

So for me, a mere user, I don't understand the technical arguments, but I understand philosophy and I see the philosophy behind Linux/OpenSource being strangled, slowly and deliberately, by people who either harbour hidden agendas or who don't care about philosophy.

"This appears to be not about anything other than developer's egos."

Ding! Ding! Ding! We have a winner.

Sievers & Poettering (and i'll throw gregkh in for good measure) are behaving like vandals. This is an indicator of being a psychopath -- they don't care how many people are harmed, and to what extent, as long as they get what they want. I believe we have a pretty good idea from 20th Century European history of where that sort of "will to power (and screw anybody who doesn't have the means to stop me immediately)" mentality leads to. Do I think it will cause 50 million dead like the last incarnation of this that came out of Germany? No. Will it cause a lot of needless misery, and pointless wasting of resources: Yes.

Their ego is one thing. They are bullies but that is only one side.

The other side is that they want to sell a service - the code they write.

This is pure egoism.

See this entry line:

https://github.com/systemd/...

In the event that it is changed, here is the copy/pasted variant:

ENGINEERING AND CONSULTING SERVICES:
Kinvolk (https://kinvolk.io) offers professional engineering
and consulting services for systemd. Please contact Chris Kühl
<chris@kinvolk.io> for more information.

A system so complex that you need to pay for consulting how to
debug it. :\

Everything you said here is "debunked" by the well written answers in the same thread:
https://sourceware.org/ml/l...
https://sourceware.org/ml/l...
The main method used by systemd to monitor processes is not by monitoring PIDs, it's by using cgroups.
You need to put your hatred aside, and really start reading what's actually done by systemd to understand how it works, because those posts clearly show you don't.
Yes it is significantly different that what was here before, and yes those changes are somewhat disruptive. This is what makes it interesting.

I do not want my software to be "interesting." I want it to be reliable. Part of reliability is that it does not depend on the specific operating system I run it on. Cgroups are linux-specific and not suitable for portable software.

I'm genuinely curious: What about init systems makes cross-platform portability desirable?

Worded another way: Why would I want to use a Unix init system on Windows?

I sincerely cannot comprehend why using the native features of the kernel an init system is written for is a bad thing, especially when it enables the init system to (potentially) do a better job? (Let's ignore for the moment whether systemd is actually doing a good job. This is a general question that would apply even if we weren't talking about systemd specifically.)

Uh, Dude, the problem is that systemd is going to make deamons non-portable between Linux and the rest of the Unix world.

That's not a feature, it's a very, very, very, very, very, very serious bug.

systemd's socket activation support relies on features that have been available on every decent Unix-like system for ages. So does its readiness notification support (as outlined above). Therefore they can both be implemented on *every* Unix with a minimal amout of fuss. How exactly is this supposed to make a daemon unportable?

Socket activation is a misfeature, it doesnt matter if it can be done cross-platform, it's still just dumb. It leads to a system appearing to boot a tiny bit faster, but you can no longer guarantee that everything is actually *up* at that point. I dont care much about speeding up boot times but I would still call that a win - IF it wasnt achieved at the cost of making the entire boot process unreliable, but it's not worth anything like the price you pay here.

... Why is that an issue? Almost every Linux distro and most of the BSDs have been shipping _their own_ init scripts for years, even when a given daemon includes its own. I don't see how this makes daemons non-portable.

Because every deamon is now going to have to have TWO versions -- the Linux systemd compatible version, and the sane one used by BSD and the rest of the unix world.

Poettering summed up his attitude -- Linux isn't unix, so don't give a shit about breaking everything and anything, as long as it feeds his narcisstic craving to control every damned thing. Basically, he's not improving Linux, he's turning it into Windows. If he wants to work on creating a system that's compatible with the Windows philosphy (it's just fabulous write huge, unstable programs with murky boundaries that do lots and lots of things poorly and don't play well with others) then he should get out of Unix and write for the ReactOS people.

It's obvious that Sievers and Poettering want to be the big fish in the pond... so w should encourage them to go to ReactOS... ReactOS needs people like Sievert and Poettering -- the Linux world doesn't. All of this crap of moving tons of things out of /bin to /usr/bin, etc (and then putting in soft links from /bin to /usr/bin, rather than, oh, I don't know, doing something SANE like putting the soft link in /usr/bin pointing at /bin) is an example of the absolute CONTEMPT these two have for the entire Linux community. Things that have worked well for almost half a century should not be thrown out like a baby with the bathwater, for the (dubious) goal of shaving 5 seconds (and usually not even that) off of boot-up time --- because what, we don't use our computers to get actual work done, we just sit around all day rebooting !?!?!?!?!?!??! Who the hell cares if a computer takes 10 seconds or 2 minutes to reboot -- it's not something you do that often. And the only computers which ARE booted up frequently (laptops) aren't running dozens upon dozens of system services to make for a long boot-up anyways.

Even my laptop, I only reboot once every couple of weeks.

Frankly, I regard Sievers and Poettering as nothing less than vandals, because they are breaking far more than fixing. For a pair who profess to be systems programmers, they seem to be utterly clueless about issues and mechanisms directly linked to system stability vs. instability.

Overly complicated PID 1 is a perfect example.

I'd opine that neither are really systems programmers. This is evidenced by at least Pottering's partial failures over time, including PulseAudio which honestly breaks more than it fixes and is really solving problems you and most everyone else (99.9999...%) don't have, nor will they ever have.

This is something that is very much *MISSION CRITICAL*, meaning it really needs to be this largely armor-plated, can't really ever fail, piece of software. So far, Lennart has yet to write a piece of software like this. He's got...interesting...notions... But they should've never been given the time of day in most of the cases, mainly because if you'd done the mental exercises most actual systems developers do, you'd realize that they're all solutions looking for a problem to fix.. Remote network audio is, quite frankly, something already solved and his "solution" added issues including needless latency in things.

His logging solution in systemd is excreable- and this massive mission/function creep abortion they call systemd is, quite simply, too complex- it's attempting to build an OS abstraction on top of an...heh...OS abstraction already there. It's almost like the One Ring. That's not a systems programmer there. It's a wannabe.

You have summed it up very well. These guys are applications programmers posing as systems programmers.

Honestly i dont think Poettering and crew is gunning for Windows. They are trying to create OSX without the Apple hardware dongles. But then they also work for a company that is likely trying to supplant Sun Solaris. Just about everything that comes out of RH these days are gunning for some kind of "secure" workstation for government/corporate work. Maybe with a solid dose of cloud thrown in on top to spite Oracle (who owns Sun these days).

OS X is BSD underneath. They are certainly NOT trying to create BSD. BSD's init system is even more simplistic than SysV init

OSX use Launchd, and some want to see that transfered to the BSDs. But at this point Systemd is much more than Launchd, never mind SUN's SMF.

At this point it may be as relevant to talk about Systemd/Linux as it is to talk about GNU/Linux.

But look at the projects Poettering has initiated and they are all more or less inspired by OSX. He pretty much admitted as much in an interview some years back.

The problem is...everything that they're doing ensures that it won't BE secure. That's the most laughable thing about this cruelty joke Red Hat's inflicting on us. They used to be friends...but with friends like that, who needs enemas...

It's an issue because it's more akin to the welded shut hood of your vehicle versus what you currently have. If a *BSD variant wants something resembling systemd, the best they can hope for is the winnowed down fork labeled uselessd that does NOTHING but handle the boot dependencies, etc.

With the old way, while it was clunky and "slow" (I'd opine that "fast" is only relevant in the *EMBEDDED* and *CONSUMER DEVICE* spaces, not the server spaces- you shouldn't NEED fast boot times for a server...) you could "port" it in the large to your system or at least HACK your needed daemon start script into the system. With systemd, you don't get that luxury. It needs to be systemd-ed and you can just pretty much kiss anything other than Linux support goodbye- or support the "old" way and the "new" way at the same time.

It's stupid. It's a damned waste of valuable time. And better yet, this doesn't even get into the lack of actual mission-criticalness that is needed in the server and embedded spaces- that this damn thing DOES NOT AND CAN NOT HAVE because of it's poor design decisions. I keep questioning why in the hell Red Hat keeps the man on their payroll, this is that bad.

Your argument is one that doesn't seem, to me, to support your case.

Why would BSD want systemd? That's the core of my main objection to the argument that systemd's lack of portability is bad: It's a Linux init system that uses Linux kernel features to do its more interesting jobs, so why would any other platform want it?

Why would you have to hack your daemon? Systemd supports launching daemons via init script, and with an extension, supports sysvinit-style scripts. The systemd-specific code that enables systemd optimization for a daemon amounts to an #ifdef for a few lines of code and a single C file that can be simply excluded from your build to support non-systemd systems. How does this mean that you have to "kiss anything other than Linux support goodbye"?

You are, to be blunt, merely regurgitating the same long-debunked arguments I've seen discussed a hundred times, and still not answering my question.

The reason BSD doesn't want systemd is because systemd is a steaming pile of excrement. NO SANE PERSON wants systemd.

Thats the problem with Systemd, is it's not a Unix init system, its a linux init system. If it were a unix init system, it wouldn't depend on things like cgroups existing. cgroups aren't part of the posix spec, they don't exist on FreeBSD, OpenBSD, NetBSD, Solaris and really any others. There are numerous other problems with the nested dependencies of systemd, its not friendly with running inside containers. I'm sure most people who don't like systemd would have less issues with it, if the pid 1 portion of systemd were smaller and less complex. The problem is if pid 1 dies, or needs to be updated, this results in a crash or reboot.

Anyway, the feature creep of systemd is the scary part to many of us. Why does my init process need to be my automounter, my syslog, my inetd?

Personally, I'm just horribly upset about them changing the ordering of the start/stop/restart arguments for no good reason. what advantage does systemctl start apache have over systemctl apache start?

This does not answer my question. Why is it a bad thing for it to be a Linux init system? Why does conforming to the POSIX spec matter for a Linux init system?

We can talk about dependencies and argue about features, sure. But what I don't understand is this fetishistic obsession with POSIX when we're talking about a freaking init system. I'm not aware of POSIX imposing any requirements on the init system other than a small subset of interactions with it, so why is this such a big deal? Why do you even care?

I understand, and to some degree, agree with the concerns about feature creep. But the rest of your arguments are little more than bikeshedding, and don't really explain why systemd is objectively bad.

Technically your question was about running a "unix" init system on windows. My point which did answer that question was that it isn't a "unix" init system, it is a Linux init system. While POSIX isn't some sort of panacea it does imply some level of portability across unix and unix like systems, and for an init system that is important to a lot of people. Especially when systemd apparently provides non-portable (dbus and sd_notify) ways for daemons to implement some concept of service activation.

From a desktop perspective, systemd looks fantastic, it has a ton of neat features that will make a linux laptop boot up faster, and use less resources on startup these are good things, it is also substantially more usable than the usability nightmare that is launchd which is where the systemd authors got a lot of their ideas. I'm not really against sytemd on the desktop, on the server however, where security and stability matter it leaves some things to be desired.

Objective problems with systemd on the server:
1) PID 1 is arguably the most important process, if it halts your sever halts, ideally PID 1 should be the simplest, most tested program you have running so that it won't halt ever, and never needs to be upgraded.
2) It depends on too many libraries for such a critical program. I understand that many of those libraries are well tested, best of breed, but each library increases the attack surface of critical parts of a servers infrastructure. This increased attack surface makes it more likely that there will be root exploits available for it, and decreases the overall security and stability of a system.
3) AutoFS systems suck in general, and when the automounter doesn't work correctly, services and systems hang, and this is not a good thing.
4) Not that I've spent a lot of time trying to get it to work in a docker container, but evidently it is non-trivial to get systemd to work as PID 1 in a container due to dbus and cgroup dependencies, so I end up with an init process for my overall system, and a separate init process for my containers.
5) Because it is tied so directly to Linux, I end up with one init system for my workstations (Fedora based due to external vendor requirements), and my other servers FreeBSD based.

Subjective problems with systemd.
1) It violates the unix philosophy "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."
2) Hubris, obviously we know better than the syslog/syslog-ng/rsyslog/inetd/xinetd/autofs/automounter/amd people... They are experts in their domain, who cares, we can do better, and include it in the init process.
3) The main developers of systemd appear to be jackasses.
- Lennart Poettering (https://archive.fosdem.org/... "In fact, the way I see things the Linux API has been taking the role of the POSIX API and Linux is the focal point of all Free Software development. Due to that I can only recommend developers to try to hack with only Linux in mind and experience the freedom and the opportunities this offers you. So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It's quite relieving!" (Obviously Linux is the whole of the unix universe).
- Kay Sievers (https://bugs.freedesktop.or... The whole kernel debug argument being parsed by systemd and screwing things up for the kernel blowup from a couple of months back.

4) The systemd dev's seem to have the worst case of NIH (Not invented here) Syndrome I've ever seen. We are creating an init system.. need to make sure it has AutoFS, xinetd, Syslog, DHCP, Device Detection
5) The whole boot speed at the cost of sanity attitude drives me nuts.

Anyway, to address your bikesheding accusation, an init system SHOULD more resemble a bike shed than a nuclear power plant, but systemd seems to be aiming for kernel level complexity vs. bike shed level simplicity.

You know what makes a laptop really boot faster? Without breaking anything?

Suspend to disk.

Only idiots who spend all their time rebooting and doing nothing else value boot-up times above all else.
REAL people, however, have other concerns, such as system security, system integrity, and system brittleness (systemd's mandate that all deamons become dependent upon systemd makes ALL deamons brittle), which destroys longterm system stability.

Again, you have not addressed my question.

I pointed out myself that it's not a Unix init system, and that it has no reason to be one. My point about portability to Windows was to highlight that although it has some POSIX compatibility, there's no rationale for bringing a Unix init system to it. And that highlights my core question: Why does it matter that it be a POSIX init system? It's not meant to be portable, so there is no rationale I can find to justify making it portable. (Why would you even want to use systemd on BSD?) I wasn't asking if it should be portable to Windows, I was asking *WHY* it should ever be portable to anything other than Linux. You have dodged this question four times now.

I have already conceded twice that there are valid objective problems. Your points 1 and 4 (and to a lesser degree 2) are among them. 3 I will not address, because I have not encountered such problems, and have not seen them documented. Your "objective" point 5 is what I accuse of bikeshedding, as you have not presented a case as to why a least common denominator, featureless, aging, limited init system is preferable to having an init system which takes advantage of the features a platform has to offer. I would take the same position if we were talking about some new hypothetical FreeBSD init system: If it takes advantage of FreeBSD-specific features, why should it be portable to, say, OpenBSD?

To your subjective points:
1) I disagree with taking a dogmatic stance on the Unix philosophy. All philosophies have limits to their applicability (there is no universal philosophy, IMO), and there are numerous reasonable rationales for having a more complex communication protocol between subprocesses than a text stream. I do not find this a convincing argument.
2) This appeal to authority is much less convincing. It is hubris, I would claim, to think that someone else *can't* do it better than you.
3) I can make the same accusation of Linus (Why would you use Linux? Linus is an asshole!), Theo de Raadt (Why would you use OpenBSD or OpenSSH? Theo is an asshole!), Dan J. Bernstein (Why would you use djbdns or qmail or...) and on and on. For every amazing piece of software, there's a raging asshole behind it. This argument is unconvincing, and tells me that you're scrambling for justification.
4) On balance, there are problems with the most commonly-used variants of each of those tools. hid-dbus, xinetd, syslog-ng, dhcpcd, and several others have all sent me flying into a rage about some silly thing at one time or another, and I, for one, *welcome* more alternatives. If you think you can do better, by all means, *please do.* I think you're an asshole, but I'll at least give it a shot.
5) The whole POSIX-or-nothing attitude drives me nuts. What's your point?

Your original statement was "I'm genuinely curious: What about init systems makes cross-platform portability desirable? Worded another way: Why would I want to use a Unix init system on Windows?", maybe I'm reading that wrong, but it really does seem like you called it a UNIX init system there and asked why it should be portable to Windows. If your point about windows was that it has some POSIX compatibility then I failed at reading between the lines there, because what I read was 1) an assertion that it is a Unix init system which to me implies some degree of portability to other Unix / Unix like systems, and 2) a question about why you would want to use it on windows. Yes, in retrospect it probably should have been obvious that you were making an intentionally absurd statement about using a unix init system on windows, but I missed that point and for that apologize. My first response was more about correcting the assertion that it was a Unix init system, which is a factually incorrect statement. I don't think anyone really cares whether its POSIX or not, some people care about the byproduct of it being POSIX or not and that byproduct is some degree of portability, personally for me, whether its portable or not doesn't matter at all, I was wrong in including portability in my list of objective problems with systemd, as its definitely a subjective problem with it, and a subjective problem that I don't have with it, but some others do. I evidently got carried away with my second response (https://xkcd.com/386/), sorry. I really haven't been dodging the portability question, I just don't care whether its portable or not as far as problems with systemd go, portability is about as close to the bottom of the list as it gets for me.

That said, I've never asserted that SysV init is better or that I prefer it in any way shape or form, should it be replace, absolutely, is systemd the answer? I hope not, but evidently most people disagree with me on this one. And to be fair I'm not a developer of any init system, so everything I say should be taken with a grain of salt. Is my point 5 bikeshedding, probably because upon further reflection, I don't care if its portable or not.

For my subjective points, great, you disagree with me on my opinion and think I'm an asshole, good for you. Have a lovely day.

I'm sorry my original question caused confusion. I was trying to make the point that if portability of systemd to a *BSD is desirable, then logically that means that for the same reasons an init system for a genetic Unix should be in turn portable to Windows. I wasn't calling systemd a Unix init system, just pointing out the consequences of the logic, as it applies to init systems in general.

And please don't take my tone as confrontational. I'm just trying to get rational explanations for the animosity towards systemd, many of which seem to me to be completely baseless complaints. (Though, as I said, there are valid complaints and I try to acknowledge them when they're mentioned, but they're few and don't really support the case that systemd is somehow bad.)

Systemd's portability isn't really that important, the only place where it causes issues is when it makes other daemons depend on systemd specific functions like the sd_notify function. That said, thats really only a #ifdef away from not being an issue if you are on a system that doesn't support sd_notify which to me makes it a pretty trivial issue and relatively easy to port around.

As for taking your tone as confrontational, its really difficult to read identify tone in a string of text, that said, you did say you think I'm an asshole, and I'm not sure that being called an asshole can ever be interpreted as non-confrontational between strangers on the internet.

Any personal animosity (probably an overly strong word for a feeling about an init system) I have for it comes down to the simple statement that it trades stability, security and simplicity for features that I don't care much about in a server operating system. And the absolutely stupid annoying %$^#&^$^%%$# change of the location of start/stop/restart in the systemctl command as compared to the service command. (Yes I'm aware that service is still available but its less informative than systemctl).

The "asshole" bit was an illustrative response. I'm sorry. You depicted these developers as unsavory people, and I was trying to point out that that is a ludicrous point to be making in matters of software - plenty of assholes (many of whom I like) write great software, so demeaning the software based on their personality is simply wrong.

On a lighter note, it may not be a bad idea to add a set of functions to your shell .rc scripts to wrap the functionality of service management in a way that's more sensible to you. I agree the differences are annoying, but short of proposing changes upstream, there's little you can do about it.

"(Why would you even want to use systemd on BSD?)"

I would not want to run systemd on my system, regardless of kernel. But the pressure to do so, again regardless of kernel, is simply to get a program that depends on it to run. To the degree the systemd cabal gets more and more software to depend on this more and more people will be inconvenienced by it.

More generally, why would I not want to run a 'linux only' init system? The same reason I dont want to run 'linux only' anything. I have been using *nix for over 20 years, I have migrated distributions, I have migrated kernels, and having the freedom to do that again whenever necessary is important.

You're not the first to make this point, and I'm still frustrated by it, because it makes little sense, and still fails to answer my question.

Swapping out a kernel in an environment is not so trivial a matter. Switching between different versions of Linux is fine, since the ABI hasn't changed all that much over the years, and so there's little worry about a software distribution working across several kernel versions. But swapping out a Linux kernel for something entirely different is another matter. I understand that the BSD emulation of the Linux ABI is incomplete, and so swapping out Linux for a BSD kernel is going to cause a great number of headaches - the init system is the least of your concerns.

But I do not understand why you're so concerned about being able to do such a thing, especially when doing so necessarily means a substantial change in the operating environment, let alone binary loader behavior differences and ABI differences that will inevitably break a number of core features.

It's fine if you want to just use a software distribution where systemd is unsupported, but making such drastic changes to a running system is at best inadvisable, even ignoring the matter of the init system or the difficulties in changing libc.so or other critical infrastructure.

your points have been addressed repeatedly.

If you don't want to listen, tha'ts your problem. Now, sit the hell down and shut the hell up, and LISTEN, Lennart.

And it doesn't even deliver the faster bootup time which is supposedly the justification for all of this BS.

BS, Grayfade. We have answered your question repeatedly. Stop being a concern troll.

No, you really haven't. I asked why portability and POSIX-compliance is so important for systemd. I have never gotten an answer. I asked why anyone would want systemd portable to systems like BSD. All I get is complaints that no one would because it sucks. That doesn't answer my questions. If you're going to say systemd sucks and then give me reasons it sucks, I'm going to expect your reasoning to make sense.

But you don't have reasoning that I can see. All you're doing is complaining that it sucks. Well, that's useless.

And then you keep bugging me several months after I've long forgotten about this post and call *me* a troll?

Please, just drop the subject. You're clearly not interested in conversation or reasonable discussion, so please don't reply to me again unless you have actual, reasoned answers to my questions.

It matters because a dev doesn't want to have to maintain separate daemon codebases to support both Linux and BSD. That might seem like an edge case, but if you write something to use all of the systemd interfaces because you aren't concerned about having to run it on other UNIX systems, the people who want to use your project on BSD will be left to reimplement daemonization themselves.

They don't have to maintain a separate daemon codebase. They can continue to use their old rc script and the systemd compatibility layer can run that script just fine. Or, a simple unit file can run the daemon directly.

It's only if the daemon needs to directly manage systemd services or take advantage of systemd-specific features that maintaining additional code becomes a concern.

Now, if a daemon uses systemd libraries, I have to question the motivation for porting that daemon to another OS. Clearly, if the daemon performs some task relevant to systemd, what reason is there for it to perform the same task on a system with no systemd?

Conversely, if a daemon does not rely on systemd, but just links the libraries, I have to question the motivation for linking to those libraries. If they're not needed, why link?

I still don't see the argument.

Yes, we have.
Now shut up about it.

I'm not the one that resurrected the conversation after 4 months of silence. You are.

But it's clear you don't have an answer for me. Very well. But throwing a fit will not serve your argument.

You are, once again, spreading factual falsehoods. When systemd needs to be upgraded, it will serialize its state and re-exec itself. There is no need to reboot.

Really, try harder.

Interestingly, that's not true. See https://bugzilla.novell.com...

And what if it crashes in the process?
What if there's a bug in the serialization?
What if there's a bug in the de-serialization in the upgraded version of systemd that just got exec()ed by the old version of systemd?

I can tell you what happens when (not if) it crashes: https://bugzilla.novell.com...

And you can promise that, regardless of any and all future code changes, that it will always crash this way, and ONLY this way?

Dude, whatever you're smoking, I'm sure there are entire ghettos in Detroit that would literally kill for it.

Yes, I know. It's that Someone With[OUT] a Clue doesn't seem to understand how systemd's pid 1 is overly complex, and by that, I mean, anything more complex than a process which spawns off the rest of the init system, and then sits around reaping orphans.

It's fragile. If the cgroup implementation changes (aka, Linus feels like it) then we all feel the pain.

Option #1 above relies only on the guaranteed behavior on compliant POSIX systems. It's anti-fragile.

That's a completely ridiculous argument. One need only look at the last few months of LKML discussion to see that Linus is absolutely dogmatic about never, under any circumstances, breaking userland. He has gone on dozens of long rants at people for changing something that broke a userland program, shouting obscenities for days about it.

If you think the cgroups ABI changing is at all a problem, then you clearly haven't paid one whit of attention to kernel development. Kernel ABIs that are in use never change without massive cooperative efforts.

Considering that they were considering hiding some kernel arguments from systemd because it was screwing up their ability to debug the kernel, http://www.phoronix.com/sca... I think you may be overestimating Linus's feelings about breaking systemd.

Is there a normative document spelling out the specifications and contract for cgroups, equivalent to the POSIX spec for socket writes?