[gentoo-amd64] Re: Boycott Systemd

[Duncan <1i5t5.duncan@cox.net>]

Rich Freeman posted on Mon, 22 Sep 2014 08:53:44 -0400 as excerpted:

> On Mon, Sep 22, 2014 at 8:47 AM, Harry Holt <harryholt@gmail.com> wrote:
>>
>> On Mon, Sep 22, 2014 at 2:00 AM, Duncan <1i5t5.duncan@cox.net> wrote:
>>>
>>> Rich Freeman posted on Sun, 21 Sep 2014 22:34:23 -0400 as excerpted:
>>>
>>> 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.
>>
>> There are, in fact, a number of things that systemd breaks, and that
>> the devs refuse to fix, that even Linus has complained about.  To
>> quote:
> 
> Duncan was talking about linux, you're talking about systemd.  If Kay
> broke the kernel Linus wouldn't be complaining about it, he would be
> doing something about it.

Exactly.  If a kernel change broke userspace, by Linus' definition, that 
kernel change is broken, full-stop.

If they find out about it in the same kernel cycle, it's reverted, and 
that's about as hard and fast a rule as it gets.  (The only exception 
would be if there's a break of userspace either way and no way to finesse 
it, in context, if that break was fixing a previous break, then Linus 
gets to call which break to fix.)

But of course it can only be found out about in the same kernel cycle if 
someone affected is testing kernel rcs and reporting breakage.

If the breakage is found later, it's still breakage and still subject to 
revert.  Only by then some other userspace may be depending on the new 
behavior, in which case there's a problem.  Obviously this is more likely 
the longer the "broken" behavior has remained in the kernel.  They'll try 
to finesse this case and it really is amazing sometimes the extents 
they'll go to do it (one case was a special-casing of the behavior to the 
specific usage in question, they were able to detect that specific usage 
and special-case the specific otherwise broken behavior around it), but 
if that's not possible and it has only been a kernel cycle (people only 
tested the release, not the rcs, so only the single release kernel has 
that behavior), they'll probably still revert it, in part because there's 
relatively little released userspace that will depend on it that quickly 
and very likely it'll not have made a major distro release yet.

But if the broken behavior isn't reported for several kernel cycles, say 
a year (about five kernel cycles), then it really is a tough call, 
particularly when there's established and widely used software already 
depending on the new behavior.

Again, bottom line, report kernel breakage of userspace, the same kernel 
cycle that breakage happens if at all possible, which means testing an 
early enough kernel rc (rc3 is good), and it'll normally either be fixed 
or the commit introducing the change reverted.  The longer you wait 
beyond the kernel cycle it was introduced, the more likely other 
userspace depends on the new behavior, with a revert becoming 
correspondingly more problematic.

And again, if it's not reported, was it a break in the first place?  Just 
make sure it's reported!

-- 
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