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 91251138BF3 for ; Sun, 16 Feb 2014 18:32:13 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 19BECE0B26; Sun, 16 Feb 2014 18:32:09 +0000 (UTC) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 42537E0B0E for ; Sun, 16 Feb 2014 18:32:07 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id cc10so1751043wib.11 for ; Sun, 16 Feb 2014 10:32:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:reply-to:to:subject:date:user-agent:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=QqbFQdDO8THD28rO2TlsN1v/vOtoeEhVsKc7//lcJZ8=; b=cEiLLOA6+xKGFEp+WpZoBjKDfPoQZZWEXrMO94Sc/oipgtUkRedr3xPFfWS03Segq9 +Tzbdz2xaHo0EGXPnjAJl+NTTQtcIMt6nqhVY5kUIMcbX5fCcwqoa6mx5yQLr8F/Aagw T5hucInDO0zI+FVJow3WaEkC3wMS04srKENqmhmjyp/ql0jILeaG2+xAAtka4d4FF0c5 meSbzjtk+sfaO5Oes7qZ+i+RHLnzZNJRPi+vqH7EK5w/q/OJDcGJeMnq41vrG0eI2I5l h/CIPwjR4yeokb1lqkJwYdjmjnFfa6GmTVuR39hKPAgDSenQmJhdpxvfY+nsm2n+49uT Igjw== X-Received: by 10.180.189.10 with SMTP id ge10mr9804458wic.47.1392575526031; Sun, 16 Feb 2014 10:32:06 -0800 (PST) Received: from dell_xps.localnet (230.3.169.217.in-addr.arpa. [217.169.3.230]) by mx.google.com with ESMTPSA id bm8sm30346165wjc.12.2014.02.16.10.32.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Feb 2014 10:32:04 -0800 (PST) From: Mick To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Debian just voted in systemd for default init system in jessie Date: Sun, 16 Feb 2014 18:31:41 +0000 User-Agent: KMail/1.13.7 (Linux/3.10.17-gentoo; KDE/4.11.5; x86_64; ; ) References: <52FF84CE.2050301@libertytrek.org> <5300DD51.5060207@libertytrek.org> In-Reply-To: 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; boundary="nextPart2139394.hDdg7lvzcz"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201402161831.51235.michaelkintzios@gmail.com> X-Archives-Salt: d8919912-210b-495d-b9fc-aae34d9628a4 X-Archives-Hash: 350a2a626cb4dba94809e9a7007eceaf --nextPart2139394.hDdg7lvzcz Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sunday 16 Feb 2014 16:50:26 Canek Pel=C3=A1ez Vald=C3=A9s wrote: > On Sun, Feb 16, 2014 at 9:46 AM, Tanstaafl =20 wrote: > > On 2014-02-15 3:32 PM, Canek Pel=C3=A1ez Vald=C3=A9s = wrote: > >> For Slackware, I have no idea. For Debian, no the only options were[1]: > >>=20 > >> 1. sysvinit (status quo) > >> 2. systemd > >> 3. upstart > >> 4. openrc (experimental) > >> 5. One system on Linux, something else on non-linux > >> 6. multiple > >>=20 > >> It should also be noted that no one in the TC voted OpenRC above > >> systemd AND upstart, and that while a couple voted systemd below > >> everything else, it can be argued that it was a tactical vote. > >>=20 > >> Regards. > >>=20 > >> [1]https://wiki.debian.org/Debate/initsystem/ > >=20 > > I would really, really, REALLY like to see a thorough, civil debate > > involving those far more knowledgeable than I on the pros and cons of > > systemd vs OpenRC... >=20 > Well, that's the pickle, isn't it? We have the usual stuff: >=20 > =E2=80=A2 OpenRC wasn't able (until very recently) to properly do parallel > execution of daemons. There will be someone who will say "that isn't > important". >=20 > =E2=80=A2 Then there is the inability of OpenRC to properly stop/monitor > daemons (everybody here had to use "/etc/init.d/daemon zap" at some > point, I suppose). Someone will say that there is experimental cgroups > support for OpenRC... "experimental" being the important word, and > there is also the little matter of that not being integrated into the > official package (AFAIU). Also, with that OpenRC loses the "advantage" > of being portable to FreeBSD and/or Hurd. >=20 > =E2=80=A2 And of course, OpenRC is slow as hell compared to systemd (alth= ough > there are reports of being really fast using reentrant busybox... I > never used that way, so I don't know). Which again, someone will say > that "that doesn't matter because I never reboot my machine". Great. >=20 > But then we have the whole load of features that systemd provides that > no other init system does (OpenRC included). That is an advantage if > you believe that having an standardized plumbing in all "mainstream" > Linux distributions has technical merit and is a good design. If you > believe so (like I and many others do), then systemd is several orders > of magnitude better than OpenRC. If you don't believe so (like many... > although apparently they are less and less as time goes by), then > systemd is the spawn of the devil and it should be killed with fire. >=20 > For General Purpose Linux distributions, systemd is a godsend since it > solves and centralizes a lot of stuff that matters to a lot of people. > It's fast and small (if you remove the optional dependencies), so the > embedded guys like it. It offers (for the first time ever) proper > daemon control and management and O(log n) access logs, so the server > guys like it. And if offers proper session monitoring and seat > control, so the desktop guys like it too. >=20 > But all those advantages only will be so, if you agree with having a > tightly integrated plumbing interface directly above the kernel and > below PAM and/or X (soon Wayland) sessions. It gets kind of > philosophical, which is why a lot of people taunts the fuzzy term > "UNIX philosophy" so much when they rave against systemd. >=20 > > As it seems to me, the Debian OpenRC page says that the cons are not > > nearly as large as the systemd proponents would have us believe. > >=20 > > https://wiki.debian.org/Debate/initsystem/openrc >=20 > It's because they are cons only if you agree with systemd's view of the > world. >=20 > I do. I think what people primarily object to is not the parts that systemd does= =20 well or does better than other init process start up systems. The main=20 objection from what I understand is the removal of choice that systemd=20 developers have forced upon users, by making certain architectural decision= s. =20 These are decisions which may look optimal for RHL, but appear to be less s= o=20 for the rest of the *nix ecosystem given the objections to systemd across t= he=20 populace. =46or some Gentoo users in particular, removing the choice of running /usr = on a=20 separate partition (without *forcing* the use of initramfs) created the fir= st=20 pain point, or wakeup call. Many complaints were posted on this M/L,=20 centering on this removal of choice. Unlike binary distros Gentoo is all=20 about choice, so the complaints were perhaps louder than elsewhere. People speaking of *nix design philosophy are not necessarily having a rant= ,=20 but can be legitimately concerned that architectural decisions to hardwire= =20 systemd into Linux will remove choice from its wider user base. I am=20 similarly concerned that a monoculture has less success of survival. The f= act=20 that Debian decided to embrace the systemd option will no doubt have an imp= act=20 on what Gentoo follows. I am not educated in init start up systems to know why other options were n= ot=20 considered as part of the Debian debate. Is it that runit, or epoch or wha= t- else are not even close in terms of functionality, versatility and choice? = =20 =46raming a question can narrow the answers. I hope that whatever the Gentoo decision may be one day, it will not=20 irreversibly remove choice from us Gentoo-ers. =2D-=20 Regards, Mick --nextPart2139394.hDdg7lvzcz Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAABAgAGBQJTAQQXAAoJELAdA+zwE4Ye1A0H/Aodpg8JIQJcecStr+60q1L0 zfBRX5a1vBaOc/ltVqCfg5od2mg7n2HMdUUeRVq25AGKRIkpRb+0Z7+TjVLWmGqo vEUlBHvUNE/NiPe5R2p0Y4iLC/5+RiwM+KSh1fSY9W4YRWx0F8s9TTUmn1Go3BhS zWqCm3wlrjY1Ut6AraEfuZsA1tdFKrDNUZhgiz1DTZwYOa+10cGn6mI7jxH1nPQo pnt6NbWGQmtwAADzYT/MsXoCqJbKy4fxCll2FAieCj8e0WrTLQGLpaR+d7v/kDPE XPWADPoGHjwrrI9y+DH7dAlzjx3r/3TQP+0RujYbxvwm/YcYwlMvpPl6Jf2C5VY= =PMyl -----END PGP SIGNATURE----- --nextPart2139394.hDdg7lvzcz--