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 4928C13838B for ; Mon, 22 Sep 2014 16:58:38 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 45FE9E099C; Mon, 22 Sep 2014 16:58:36 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 8B796E08F1 for ; Mon, 22 Sep 2014 16:58:35 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XW6jW-0000t4-T9 for gentoo-amd64@lists.gentoo.org; Mon, 22 Sep 2014 18:45:02 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Sep 2014 18:45:02 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Sep 2014 18:45:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: Boycott Systemd Date: Mon, 22 Sep 2014 16:14:11 +0000 (UTC) Message-ID: References: <20140921132548.d4ad54724473a2aeee688daa@comcast.net> <20140921143059.c3c16dfdeab6f65280b7caa6@comcast.net> <20140921192043.GA9652@crud> <20140921171301.5f008b3bd12c21c2f8fdd67e@comcast.net> <20140921202600.08d082d88014228172007477@comcast.net> <20140921220253.29b05782092a062c7148cbed@comcast.net> 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT d447f7c /m/p/portage/src/egit-src/pan2) X-Archives-Salt: eed389f7-2960-43ee-88ef-d3ba52651e65 X-Archives-Hash: afb32c0b9afc1aeeaeb48e1c26801c9b 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 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