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 4ABF1138BF3 for ; Mon, 17 Feb 2014 12:25:06 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 64B0CE0AA5; Mon, 17 Feb 2014 12:24:46 +0000 (UTC) Received: from mahal.bihira.com (mahal.bihira.com [50.7.77.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6CBA0E0A84 for ; Mon, 17 Feb 2014 12:24:45 +0000 (UTC) Received: from 176.70-40-234.netnet.net ([70.40.234.176]:46578 helo=[192.168.1.144]) by mahal.bihira.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WFNFb-0018lO-Fn for gentoo-user@lists.gentoo.org; Mon, 17 Feb 2014 12:24:43 +0000 Message-ID: <5301FF8B.8080502@sporkbox.us> Date: Mon, 17 Feb 2014 06:24:43 -0600 From: Daniel Campbell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Debian just voted in systemd for default init system in jessie References: <52FF84CE.2050301@libertytrek.org> <53010ADB.2070708@yandex.ru> <201402161926.17796.michaelkintzios@gmail.com> <5301FDF0.6000408@libertytrek.org> In-Reply-To: <5301FDF0.6000408@libertytrek.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mahal.bihira.com X-AntiAbuse: Original Domain - lists.gentoo.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - sporkbox.us X-Get-Message-Sender-Via: mahal.bihira.com: authenticated_id: lists@sporkbox.us X-Source: X-Source-Args: X-Source-Dir: X-Archives-Salt: 2a6d0548-9aa7-4982-8a64-61aa11c37b43 X-Archives-Hash: bc023e8644f74bfeb5598285a6fa766b On 02/17/2014 06:17 AM, Tanstaafl wrote: > Thanks to all who chimed in... > > On 2014-02-16 3:27 PM, Canek Peláez Valdés wrote: >> On Sun, Feb 16, 2014 at 1:26 PM, Mick wrote: >> [snip] >>> You may have lost it in the link that Volker posted (thanks Volker), >>> but this >>> comment from HaakonKL probably sums it up: >>> >>> "... I will give Upstart this though: Should something better come >>> along, you >>> could replace upstart. I guess this holds true for OpenRC as well. >>> >>> You can't say that about systemd." > >> I had read that blog entry before. Is full of errors, like believing >> that everything that systemd does is inside PID 1. > > Maybe it is 'full of errors', but is the primary point true? > >> There is actually little code inside PID 1; > > The quoted text said nothing about this, so please stay on point. > > As to the point raised: > >>> Can you surgically remove systemd in the future without reverse >>> engineering >>> half of what the LSB would look at the time, or will its developers >>> ensure >>> that this is a one time choice only? > >> You guys talk about software like if it was a big bad black magical >> box with inexplicable powers. >> >> If someone is willing and able, *everything* can be "surgically >> remove[d]". We got rid of devfs, remember? We got rid of OSS (thank >> the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo, >> and ESD. KDE got rid of aRts (and who knows what more). > > I think you are being a little disingenuous here. > > The obvious unspoken meaning behind the 'can you surgically remove' was: > > Can you do it *easily*? I'm sure you would not suggest that getting rid > of the above were 'easy'? > > It simply doesn't matter if systemd boils down to one monolithic binary, > or 600, if they are tied together in such a way that they can not > *individually* be replaced *easily and simply* (ie, without having to > rewrite the whole of systemd). > > That said, it seems to me that, for now at least, it isn't that big a > deal to switch back and forth between systemd and, for example, OpenRC. > > So my main concern is - will it still be possible - *and* easy - in a > year? Three years? Five? If the answer to *any* of those is no, then I > think the best solution - for gentoo at least - is to make whether or > not systemd is to be used more like a *profile* choice - a decision that > you can make at install time, similar to choosing between hardened or > not (not easy/simple to switch to/from after a system is up and running). > > In fact, it seems to me that, since (from what I've read) the primary > reason that systemd was written in the first place was to provide > extremely fast boots *in virtualized environments*, having it be a > choice made by selecting a corresponding *profile* is the *ideal* > solution - at least for gentoo. At least this way everything could be > documented, and switching between a systemd and non-systemd profile can > be supported for as long as possible, understanding that at some point > in time it may have to become an install time choice - kind of like > choosing between hardened or not is mostly an install time choice now. > That's actually a really smart idea. It would allow for the integration that systemd-fans desire and still respect the choice of people that don't want systemd on their systems. Combined with USE flags and the PORTDIR_MASK variable (iirc), it should create a "best of both worlds" situation for Gentoo and a decision wouldn't need to be made. Despite my distaste for systemd, I think this is a great middle ground that everyone could, with some considerations or compromises, agree to.