From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 108E313838B for ; Mon, 22 Sep 2014 12:47:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 51629E09F0; Mon, 22 Sep 2014 12:47:32 +0000 (UTC) Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A412EE09DB for ; Mon, 22 Sep 2014 12:47:31 +0000 (UTC) Received: by mail-qg0-f41.google.com with SMTP id j107so1563833qga.14 for ; Mon, 22 Sep 2014 05:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=R/OFp3Sy4vYuVMcMoyAI8EpNEhliM0HkG4Xowz9Yo2U=; b=AY/FupxLsEZRwpb8yXV7s79AeJ5RXLVHe8PhcJTRmQVhtHPws24dKcg899VW7aOZJb AUK3aPG5crEK6ol27ap1MS+wHOzauJqJxJzl1P/pId051B0XQrfPVGA0wsUG2Q+wd4OY bFj/bxUJJCqXieYmv3ysRoXMrZVAFZWXHl3dOErYPpzEpEY2XB3FmmplQ3oi1Q0wUirZ JgpS+axUImf3ehAILqxBZUbUmarAgkpoiu2PhREJwVAjGnsBDB3oOC4h6ZDKF1e7/PUb x57Y8xROOO1qVKxqrOmgrat0T+EbAnNJ0mdMvKzKwGtJKQq1Us24sqZ1qlvarC+Z82W5 yQLA== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.140.47.108 with SMTP id l99mr21501356qga.45.1411390050790; Mon, 22 Sep 2014 05:47:30 -0700 (PDT) Received: by 10.96.182.68 with HTTP; Mon, 22 Sep 2014 05:47:30 -0700 (PDT) In-Reply-To: References: <20140921132548.d4ad54724473a2aeee688daa@comcast.net> <20140921143059.c3c16dfdeab6f65280b7caa6@comcast.net> <20140921192043.GA9652@crud> <20140921171301.5f008b3bd12c21c2f8fdd67e@comcast.net> <20140921202600.08d082d88014228172007477@comcast.net> <20140921220253.29b05782092a062c7148cbed@comcast.net> Date: Mon, 22 Sep 2014 08:47:30 -0400 Message-ID: Subject: Re: [gentoo-amd64] Re: Boycott Systemd From: Harry Holt To: gentoo-amd64@lists.gentoo.org Content-Type: multipart/alternative; boundary=001a11c173849df5490503a6daca X-Archives-Salt: 80aba5d9-48e1-47c4-81c4-a4a737a4f787 X-Archives-Hash: 453b597a8a3c817e8062b8d24366975d --001a11c173849df5490503a6daca Content-Type: text/plain; charset=ISO-8859-1 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: > > > 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? > > [snip] > > 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 > > > 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: "Key, I'm f*cking tired of the fact that you don't fix problems in the code *you* write, so that the kernel then has to work around the problems you cause. Greg - just for your information, I will *not* be merging any code from Kay into the kernel until this constant pattern is fixed. This has been going on for *years*, and doesn't seem to be getting any better. This is relevant to you because I have seen you talk about the kdbus patches, and this is a heads-up that you need to keep them separate from other work. Let distributions merge it as they need to and maybe we can merge it once it has been proven to be stable by whatever distro that was willing to play games with the developers. But I'm not willing to merge something where the maintainer is known to not care about bugs and regressions and then forces people in other projects to fix their project. Because I am *not* willing to take patches from people who don't clean up after their problems, and don't admit that it's their problem to fix. Kay - one more time: you caused the problem, you need to fix it. None of this "I can do whatever I want, others have to clean up after me" crap. Linus " And it's not just Linus. Something so pervasive, so entrenched into the base of the system, AND that is causing problems for kernel devs to the point that they have to implement work-arounds really needs to be reigned in and forced to be more responsive to the needs of the OS / Linux community as a whole, rather than the all-too-often response of "We don't care that we've broken things you used to do in the past - this won't be fixed and it's YOUR problem." That is the pervasive attitude of Kay Sievers, Red Hat, and others involved in systemd development. Here's another take from Christopher Barry, in a mailing list post from just last month: systemd is a coup. It is a subversive interloper designed to destroy Linux as we know it, foisted upon us by the snarky we-know-better-than-you CamelCase crowd. They just don't get it down deep where it matters. systemd is not pointing in a direction that we should be going. It does not encourage freedom. It does not encourage choice. It does not display transparency. It does not embrace simplicity. It seizes control and forces you to cede it. It makes applications and major system components depend on it, and they cannot function without it. It's gaining speed by luring naive or lazy or just plain clueless developers into the fold with the promise of making their lives easier. Buying into this way of thinking ignores the greater dangers that systemd represents. https://lkml.org/lkml/2014/8/12/459 When someone wants to take away my freedom, I get concerned. --001a11c173849df5490503a6daca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


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:


As for the loss of the usb static device nodes, did you (Frank) file a
bug about it breaking your userspace?=A0 That's one of Linus' most = firm
kernel rules -- you do *NOT* change the userspace/kernelspace API/ABI and break userspace.=A0 However, there's a known exception.=A0 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?

[snip]
=A0
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.=A0 Linus is very likely to make
sure it happens.=A0 If you didn't do that, well...

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


T= here are, in fact, a number of things that systemd breaks, and that the dev= s refuse to fix, that even Linus has complained about.=A0 To quote:

= "Key, I'm f*cking tired of the fact that you don't fix problem= s in the=20 code *you* write, so that the kernel then has to work around the=20 problems you cause.

Greg - just for your information, I will *not* be merging any code=20 from Kay into the kernel until this constant pattern is fixed.

This has been going on for *years*, and doesn't seem to be getting= =20 any better. This is relevant to you because I have seen you talk about=20 the kdbus patches, and this is a heads-up that you need to keep them=20 separate from other work. Let distributions merge it as they need to and maybe we can merge it once it has been proven to be stable by whatever=20 distro that was willing to play games with the developers.

But I'm not willing to merge something where the maintainer is know= n to not care about bugs and regressions and then forces people in other=20 projects to fix their project. Because I am *not* willing to take=20 patches from people who don't clean up after their problems, and don= 9;t=20 admit that it's their problem to fix.

Kay - one more time: you caused the problem, you need to fix it.=20 None of this "I can do whatever I want, others have to clean up after= =20 me" crap.

Linus
"

And it's no= t just Linus.=A0 Something so pervasive, so entrenched into the base of the= system, AND that is causing problems for kernel devs to the point that the= y have to implement work-arounds really needs to be reigned in and forced t= o be more responsive to the needs of the OS / Linux community as a whole, r= ather than the all-too-often response of "We don't care that we= 9;ve broken things you used to do in the past - this won't be fixed and= it's YOUR problem."=A0 That is the pervasive attitude of Kay Siev= ers, Red Hat, and others involved in systemd development.

Here's another take from Christopher Barry, in a= mailing list post from just last month:

systemd is a coup. It is a subversive interloper designed to destroy
=
Linux as we know it, foisted upon us by the snarky
we-know-better-than-y=
ou CamelCase crowd. They just don't get it down
deep where it matter=
s. systemd is not pointing in a direction that we
should be going. It do=
es not encourage freedom. It does not encourage
choice. It does not disp=
lay transparency. It does not embrace
simplicity. It seizes control and =
forces you to cede it. It makes
applications and major system components=
 depend on it, and they cannot
function without it. It's gaining spe=
ed by luring naive or lazy or just
plain clueless developers into the fo=
ld with the promise of making
their lives easier. Buying into this way o=
f thinking ignores the
greater dangers that systemd represents.

<=
a href=3D"https://lkml.org/lkml/2014/8/12/459">https://lkml.org/lkml/2014/8=
/12/459

When someone wants t=
o take away my freedom, I get concerned.


--001a11c173849df5490503a6daca--