| 1 |
On Mon, Sep 22, 2014 at 2:00 AM, Duncan <1i5t5.duncan@×××.net> wrote: |
| 2 |
|
| 3 |
> Rich Freeman posted on Sun, 21 Sep 2014 22:34:23 -0400 as excerpted: |
| 4 |
> |
| 5 |
> |
| 6 |
> As for the loss of the usb static device nodes, did you (Frank) file a |
| 7 |
> bug about it breaking your userspace? That's one of Linus' most firm |
| 8 |
> kernel rules -- you do *NOT* change the userspace/kernelspace API/ABI and |
| 9 |
> break userspace. However, there's a known exception. Rather like the |
| 10 |
> old philosophical question as to whether if a tree falls in the forest |
| 11 |
> and nobody hears/sees it, did it actually fall at all, if nobody notices |
| 12 |
> the userspace/kernelspace ABI breaking, did it really break at all? |
| 13 |
> |
| 14 |
> [snip] |
| 15 |
> |
| 16 |
|
| 17 |
|
| 18 |
> And Linus and the other kernel devs are constantly pointing out that if |
| 19 |
> they break userspace, report it as soon as possible so it can be fixed. |
| 20 |
> Those who fail to do so, unfortunately very occasionally have to live |
| 21 |
> with the resulting breakage, at least to some extent, tho they still go |
| 22 |
> to rather extreme lengths to finesse things if and when they can. |
| 23 |
> |
| 24 |
> So if your userspace breaks due to a kernel change, report it as soon as |
| 25 |
> you detect it and ask that it be fixed. Linus is very likely to make |
| 26 |
> sure it happens. If you didn't do that, well... |
| 27 |
> |
| 28 |
> -- |
| 29 |
> Duncan - List replies preferred. No HTML msgs. |
| 30 |
> "Every nonfree program has a lord, a master -- |
| 31 |
> and if you use the program, he is your master." Richard Stallman |
| 32 |
> |
| 33 |
> |
| 34 |
> |
| 35 |
There are, in fact, a number of things that systemd breaks, and that the |
| 36 |
devs refuse to fix, that even Linus has complained about. To quote: |
| 37 |
|
| 38 |
"Key, I'm f*cking tired of the fact that you don't fix problems in the code |
| 39 |
*you* write, so that the kernel then has to work around the problems you |
| 40 |
cause. |
| 41 |
|
| 42 |
Greg - just for your information, I will *not* be merging any code from Kay |
| 43 |
into the kernel until this constant pattern is fixed. |
| 44 |
|
| 45 |
This has been going on for *years*, and doesn't seem to be getting any |
| 46 |
better. This is relevant to you because I have seen you talk about the |
| 47 |
kdbus patches, and this is a heads-up that you need to keep them separate |
| 48 |
from other work. Let distributions merge it as they need to and maybe we |
| 49 |
can merge it once it has been proven to be stable by whatever distro that |
| 50 |
was willing to play games with the developers. |
| 51 |
|
| 52 |
But I'm not willing to merge something where the maintainer is known to not |
| 53 |
care about bugs and regressions and then forces people in other projects to |
| 54 |
fix their project. Because I am *not* willing to take patches from people |
| 55 |
who don't clean up after their problems, and don't admit that it's their |
| 56 |
problem to fix. |
| 57 |
|
| 58 |
Kay - one more time: you caused the problem, you need to fix it. None of |
| 59 |
this "I can do whatever I want, others have to clean up after me" crap. |
| 60 |
|
| 61 |
Linus |
| 62 |
" |
| 63 |
|
| 64 |
And it's not just Linus. Something so pervasive, so entrenched into the |
| 65 |
base of the system, AND that is causing problems for kernel devs to the |
| 66 |
point that they have to implement work-arounds really needs to be reigned |
| 67 |
in and forced to be more responsive to the needs of the OS / Linux |
| 68 |
community as a whole, rather than the all-too-often response of "We don't |
| 69 |
care that we've broken things you used to do in the past - this won't be |
| 70 |
fixed and it's YOUR problem." That is the pervasive attitude of Kay |
| 71 |
Sievers, Red Hat, and others involved in systemd development. |
| 72 |
|
| 73 |
Here's another take from Christopher Barry, in a mailing list post from |
| 74 |
just last month: |
| 75 |
|
| 76 |
systemd is a coup. It is a subversive interloper designed to destroy |
| 77 |
Linux as we know it, foisted upon us by the snarky |
| 78 |
we-know-better-than-you CamelCase crowd. They just don't get it down |
| 79 |
deep where it matters. systemd is not pointing in a direction that we |
| 80 |
should be going. It does not encourage freedom. It does not encourage |
| 81 |
choice. It does not display transparency. It does not embrace |
| 82 |
simplicity. It seizes control and forces you to cede it. It makes |
| 83 |
applications and major system components depend on it, and they cannot |
| 84 |
function without it. It's gaining speed by luring naive or lazy or just |
| 85 |
plain clueless developers into the fold with the promise of making |
| 86 |
their lives easier. Buying into this way of thinking ignores the |
| 87 |
greater dangers that systemd represents. |
| 88 |
|
| 89 |
https://lkml.org/lkml/2014/8/12/459 |
| 90 |
|
| 91 |
When someone wants to take away my freedom, I get concerned. |
Archives