[gentoo-amd64] Re: Boycott Systemd

[Duncan]

Rich Freeman posted on Sun, 21 Sep 2014 22:34:23 -0400 as excerpted:

> On Sun, Sep 21, 2014 at 10:02 PM, Frank Peters
> <frank.peters@×××××××.net> wrote:

>> There are things which are not system calls that could easily be
>> changed.  It is not too far fetched to consider a time if and when
>> systemd became so popular and entrenched that the kernel would be
>> hard-coded to pass control only to systemd and nothing else.
>
> That seems extremely unlikely.  How many people ran anything other than
> sysvinit as their init for the 15 years or so before upstart came along?
>  Making the kernel dependent on systemd would defeat the whole purpose
> of having a separation between userspace and kernelspace.

Agreed.  There's far too many and too broad usages of the Linux kernel 
for that sort of hard-coding, at least without at least a kconfig option 
for it.

Is android suddenly going to switch to systemd?  Unlikely, and it's 
generally acknowledged to be the biggest usage of the Linux kernel out 
there these days, so hard-coding android breakage isn't going to happen.

Plus even if it did, we're dealing with open source here and Google would 
simply patch that out and their own solution in as they do with a bunch 
of other stuff.  And if google could do that, so could anyone else.

Then there's the tivos and the embedded medical devices and the multiple 
automotive systems likely running their own little embedded Linux 
kernels.  Hard-coding systemd for all of that?  Not going to happen.

As for the loss of the usb static device nodes, did you (Frank) file a 
bug about it breaking your userspace?  That's one of Linus' most firm 
kernel rules -- you do *NOT* change the userspace/kernelspace API/ABI and 
break userspace.  However, there's a known exception.  Rather like the 
old philosophical question as to whether if a tree falls in the forest 
and nobody hears/sees it, did it actually fall at all, if nobody notices 
the userspace/kernelspace ABI breaking, did it really break at all?

Unfortunately, for support for stuff like the big databases, etc, the big 
users all tend to be on enterprise distros with years-old kernels and 
sometimes the changes that break that don't get noticed for years simply 
because nobody running those apps is running anything close to current 
kernels, or if they do, they aren't reporting the problem.  Bu the time 
the breakage is actually noticed and reported two years later, other 
userspace may depend on the new behavior and it can become a choice of 
which userspace to break, the newer stuff depending on the new behavior 
or the older stuff that was broken but that nobody noticed or reported 
for years.  That can cause problems, particularly when those old and now 
broken userspace programs are big-dollar enterprise users, but sometimes 
it happens.

And Linus and the other kernel devs are constantly pointing out that if 
they break userspace, report it as soon as possible so it can be fixed.  
Those who fail to do so, unfortunately very occasionally have to live 
with the resulting breakage, at least to some extent, tho they still go 
to rather extreme lengths to finesse things if and when they can.

So if your userspace breaks due to a kernel change, report it as soon as 
you detect it and ask that it be fixed.  Linus is very likely to make 
sure it happens.  If you didn't do that, well...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman