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 81241138BF3 for ; Mon, 17 Feb 2014 18:24:49 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C7D5BE0ADF; Mon, 17 Feb 2014 18:24:35 +0000 (UTC) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5CD0FE09FE for ; Mon, 17 Feb 2014 18:24:34 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id b8so11401290lan.19 for ; Mon, 17 Feb 2014 10:24:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type; bh=8FRS1rC7RB0LyfC8QWt9mRZPop24dorXc459DpmXUyQ=; b=04ypx3MQSGojDBb5YQMhabRyE0PU5Myjb8XEfjyITPHSE1aozx+qt+bgTOyS11bXuk zbw9PE3TQ959DoakN/Fn5wJqOeLD1hLwaRL/4QeSG+8Hn+umtmRGBw6jy5W1FmcgXEyH cJ3cthIb9pqYXftKsE3K+j5bTrPge7XOcuTpFC7dDpIxmSqgQVwcdhHPF5dpW0Ve7n37 1nHz1ekr7eyvvUF4ZnEhUt3pUGj0eNOaf9AgyvvpUaGFYUrX/0ua6aNzLmlc7Rz8viwC T5JsPBRH+dvu4GJjhfAjGJ8CnSXH5XtGv2GIjiDP6RzJOmHpZmYKWXXDvQOh6Hy6LiwS krqw== X-Received: by 10.112.73.100 with SMTP id k4mr17703526lbv.25.1392661472532; Mon, 17 Feb 2014 10:24:32 -0800 (PST) Received: from localhost ([198.46.152.80]) by mx.google.com with ESMTPSA id e1sm27032135laa.8.2014.02.17.10.24.28 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Feb 2014 10:24:31 -0800 (PST) Date: Mon, 17 Feb 2014 22:24:13 +0400 From: Andrew Savchenko To: gentoo-user@lists.gentoo.org Cc: Canek =?UTF-8?B?UGVsw6FleiBWYWxkw6lz?= Subject: Re: [gentoo-user] Debian just voted in systemd for default init system in jessie Message-Id: <20140217222413.ccc05cf970cc85a2b600481e@gmail.com> In-Reply-To: References: <52FF84CE.2050301@libertytrek.org> <53010ADB.2070708@yandex.ru> <201402161926.17796.michaelkintzios@gmail.com> <5301FDF0.6000408@libertytrek.org> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; i686-pc-linux-gnu) 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 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA512"; boundary="Signature=_Mon__17_Feb_2014_22_24_13_+0400_3.usrj8OoQm_lc8P" X-Archives-Salt: c1e08af1-241e-4dbe-b3d4-c765427c2191 X-Archives-Hash: a552b2066a1942b1a6b998828f012e1c --Signature=_Mon__17_Feb_2014_22_24_13_+0400_3.usrj8OoQm_lc8P Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 17 Feb 2014 11:13:39 -0600 Canek Pel=C3=A1ez Vald=C3=A9s wrote: > > 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). >=20 > You are setting a group of conditions that preemptively wants to stop > adoption of anything that is tightly integrated. That is a losing > strategy (different projects actually *want* tight integration), and > besides the burden of work should not fall on the people wanting to > use a tightly integrated stack. >=20 > You want individual modules that are "easily and simply" replaced? > Then WROTE THEM. Don't expect the systemd authors (or any other) to do > it for you. And here we have a small problem: for modules to be replaceable the core system should be designed to support replaceable modules, but systemd is not. The whole deep integration approach and lack of inter-module boundaries doesn't allow one to write replaceable blocks without crazy hacking. Just imagine that one have PCI-E bus and this bug is being replaced with some other PC-systemd bus, where one have to interface each component differently. And if one removes e.g. audio card some other seemingly independent component e.g. network controller becomes broken. That is the nature of systemd and that is many people dislike this technology. > > That said, it seems to me that, for now at least, it isn't that big a d= eal > > to switch back and forth between systemd and, for example, OpenRC. >=20 > It depends; right now you can't switch back and forth between OpenRC > and systemd without reemerging some stuff. Some of those packages > *could* be made to switch functionality at run time instead of compile > time, but SOMEONE has to write that support, and it's probably that > the upstream for the package will not accept those changes, since for > binary distributions it makes no sense to have the complexity on the > code of switching behavior at runtime when doing at compile time is > easier and the distribution generates one binary per architecture for > all its users. The most sane and fair solution was already proposed: create a systemd profile for those who need it. I personally highly dislike systemd technology, but I respect the right of other to shoot them in the leg (or head) as much as they want to. This is Gentoo: a universal constructor providing people means to build any system in any shape they need. Unfortunately chances are that in future some software may become unusable or unsupported outside of systemd profile. But patches may be created and other profiles will continue to live the same way hardened exists now and will continue to exist later. BTW it was shown at the recent LVEE Winter 2014 conference that GDM can be easily freed from systemd and OpenBSD guys have an interesting idea for faking systemd presence for applications requesting one mandatory. Though IMO any end-user application strictly dependable on any init system is broken by design: for a daemon there should be no difference by which tool it was started. > > In fact, it seems to me that, since (from what I've read) the primary r= eason > > that systemd was written in the first place was to provide extremely fa= st > > boots *in virtualized environments*, >=20 > You are wrong; systemd was created because Upstart had the silly CLA > from Canonical[1], and because its authors wanted a novel init system > for Linux (and Linux only) that used all the cool technologies the > kernel provides, and that it could solve problems like: how to easily > and consistently start daemons with well defined semantics for its > dependencies; how to easily and consistently apply resource quotas to > them; how to deal with modern computers where hardware comes and goes > (including CPUs) all the time, etc. [2]. Excuse me please, but what you wrote above is very naive. All that reasons are just an excuse. The real reason is money: systemd is a Red Hat project (despite being formally open for everyone) and is their tool^Wweapon to fight with Canonical for a sales market. It the last years RH was pushed near even in a server market and now they are fighting back. They were lucky enough to acquire Poettiring guy and create from a simple and sound sysvinit (which is an important but not dictating peace of software) a key component where they can dictate their own line, where they can lead all Linux community in a way they need. That the real reason I despise systemd: in replaces the freedom of choice by a dictatorship of a small bunch of managers of a single corporation (yes, managers, not developers). And all this is under the veil of GPL and technical merits. This is the poison in the well of FOSS. Best regards, Andrew Savchenko --Signature=_Mon__17_Feb_2014_22_24_13_+0400_3.usrj8OoQm_lc8P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJTAlPZAAoJEFZZU7lTcnVsnZ8P/2+QKNcYKCgqLqVeROO1DAno Ee6EpCKJRlIKGFooUZxSHgtrGsf7FShS4s8UC4SNp0Yv2TQa0PrzYzGlI54XBEco edpV/iVMHXP6QnFn8g74IeJOjgOXiQZpxgUgBWlQIFnGb63gq2UdJvtpCQqVeqHK zTmwKyH/+eEjHiHYEbUivLVtaLkLzVEt0uCTQMM4e0FM0fxS/sqWt+S+ecIWgfJs v+RVI6y5Iu0jcP1+awLZcHsPNUEK0McBlZubjVVCNPj94cJUkemgmulWV4pN0kMu 4rxgVpx1neJvNnxS82gKKns1kPl/0RN1WyHbxpKas/UTzUleLdKFQpsVz1banlhj V0VX1x2wwnNqv4Kml1M7a+UiF3z6fnE8jF204n+Q3mKsN7/n+4oc+u6pf0RohAun EF3Y3I0ywD+Dc8n6K+7pF/FuG7yfR87Qf6qK6q3meWShBkEsZo2+3JHLBOazjuhi CHNPE6re/ROo4qYVjZi1T1rvq5jxm9tvWy/is8yiUAwXR3w/q32wZR7Sw8yDjd65 m/gCoZsSCUCANo34fuOK2P6sOtdzBhciDHclW0J3Y0utuC+aMzTRel8IiBmIAf9m JHFyI5m/81LP+V7SSQUEnN5lhWuS8GSIrG67unWttlSKbc5gFOX/KNRQra416vpe 1fAdu6zikdY93DN2Gboq =jAsJ -----END PGP SIGNATURE----- --Signature=_Mon__17_Feb_2014_22_24_13_+0400_3.usrj8OoQm_lc8P--