From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-user+bounces-143779-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id EFD8B1381FB
for <garchives@archives.gentoo.org>; Tue, 25 Dec 2012 13:16:04 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 2897C21C0B7;
Tue, 25 Dec 2012 13:15:51 +0000 (UTC)
Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id C3E2321C093
for <gentoo-user@lists.gentoo.org>; Tue, 25 Dec 2012 13:14:42 +0000 (UTC)
Received: by mail-ob0-f174.google.com with SMTP id ta14so7266262obb.5
for <gentoo-user@lists.gentoo.org>; Tue, 25 Dec 2012 05:14:42 -0800 (PST)
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=jQ74hs35TQ3npwR5cVZ6VyR6hmT39nlFd+3VUlw/lWk=;
b=JjLkOlKAcGTnPZ6RlangM9ocHSoIZOWz24E44irnjPTPdg/GBQISfBtUS8ycKQEwGF
w0NKMqYBbWuEKJp6h2fAQwIEqxgPFi8JKj7LKrBgi0u92l2tcLpQASiHEuL+PxrAIFtu
lD+NGaWmOMwoUKziFMBmPI78oAAYwvanuDkEx0+zGpha8UUQHwHUzeM0QkIv8E+HHylO
AkMP0TAgE3qR/mk5G9Me4fxut/Erdph+h3auHK7NhN+Fbw6lrTLGsf9iVYqNNdP/NhD1
/MJVuOjqFizwCP4HOgNSipxuG2rFrNmVsM3uDfdHK1bUyT8Kwj5olUKu98FtzsHgHj8j
siqA==
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.60.6.226 with SMTP id e2mr8722385oea.56.1356441281908; Tue, 25
Dec 2012 05:14:41 -0800 (PST)
Received: by 10.76.20.243 with HTTP; Tue, 25 Dec 2012 05:14:41 -0800 (PST)
Received: by 10.76.20.243 with HTTP; Tue, 25 Dec 2012 05:14:41 -0800 (PST)
In-Reply-To: <CADPrc80d4ArycTCg8uNTExUp6zoky1x3sNEgrR8j9XxrmOJiMw@mail.gmail.com>
References: <50CB1942.3020900@gmail.com>
<CAK2H+ecMZ5JO+SGBAdwhGO0HnB8Za-6_EaS1OiQcEJ03a0iQVg@mail.gmail.com>
<50CB4A3C.1030109@gmail.com>
<CAK2H+ecBb-nJ-ZY1efRT+sNCq6v9xgWnwL4GVpY-2j-GNTpJeA@mail.gmail.com>
<50CB5406.7040404@gmail.com>
<CAK2H+efpby+2NnbjReXyGjN3=Xe63j_2K69kCZjDhZcHvjusdA@mail.gmail.com>
<8738z7hgsa.fsf@ist.utl.pt>
<20121216171043.71084070@khamul.example.com>
<CAG2nJkNDLDp2hkz34XXEen4SO1_Mm18G8NNDMZK6tqDr+ddWtA@mail.gmail.com>
<20121217104621.735bf43a@khamul.example.com>
<CA+czFiD+Yv_PXctATd6EYws8kpqb3WFesLZU47jMN5ZJmy3oww@mail.gmail.com>
<20121218163332.7956f31a@khamul.example.com>
<87txrd6pb3.fsf@ist.utl.pt>
<20121223182037.1553813f@khamul.example.com>
<87bodk7lb6.fsf@ist.utl.pt>
<20121224085528.56f535ec@khamul.example.com>
<50D85167.9060309@gmail.com>
<20121224204817.335033c6@khamul.example.com>
<CAA2qdGW+qyofuA-xyAiP4dpb6Ay5DUwYm=PJ8JXD_f2gFgf98w@mail.gmail.com>
<50D957F0.1060406@gmail.com>
<CADPrc80d4ArycTCg8uNTExUp6zoky1x3sNEgrR8j9XxrmOJiMw@mail.gmail.com>
Date: Tue, 25 Dec 2012 08:14:41 -0500
Message-ID: <CA+czFiA25=0+90bX3zJFKH-Wb2yGp0yOwKQow5z0qy+u4zE_uQ@mail.gmail.com>
Subject: Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron
with SysVInit?
From: Michael Mol <mikemol@gmail.com>
To: gentoo-user@lists.gentoo.org
Content-Type: multipart/alternative; boundary=e89a8fb2028cc44f9b04d1ad18f7
X-Archives-Salt: 7e5972cf-3164-48c6-9c75-d36466c40ca2
X-Archives-Hash: f59084477ead7a186dd4d8f51aa74ffd
--e89a8fb2028cc44f9b04d1ad18f7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Dec 25, 2012 3:04 AM, "Canek Pel=C3=A1ez Vald=C3=A9s" <caneko@gmail.com>=
wrote:
>
> On Tue, Dec 25, 2012 at 1:38 AM, G.Wolfe Woodbury <redwolfe@gmail.com>
wrote:
> [ snip ]
> > From what has been happening with the systemd stuff, I do not see what
> > advantages it really offers over the SysV scheme and its successors lik=
e
> > OpenRC. Someone enlighten me please?
>
> I wrote the following some months ago; I think nothing much has
> changed since then (I added a couple of comments):
>
> Take this with a grain (or a kilo) of salt, since I'm obviously
> biased, but IMHO this are systemd advantages over OpenRC:
>
> * Really fast boot. OpenRC takes at least double the time that systemd
> does when booting, easily verifiable. In my laptop systemd is twice as
> fast as OpenRC; in my desktop is three times faster. (With a solid
> state hard drive, my laptop now boots even faster).
>
> * Really parallel service startup: OpenRC has never been reliable on
> parallel service startup; its documentation says it explicitly. Some
> will tell you that for them "it works", but just like the guys who
> have a separate /usr and refuse to use an initramfs, they just haven't
> been bitten by the inherent problems of it (just ask kernel developer
> Greg Kroah-Hartman). The Gentoo devs recognize that OpenRC is just
> broken with parallel service startup.
>
> * Really simple service unit files: The service unit files are really
> small, really simple, really easy to understand/modify. Compare the 9
> lines of sshd.service:
>
> $ cat /etc/systemd/system/sshd.service
> [Unit]
> Description=3DSSH Secure Shell Service
> After=3Dsyslog.target
>
> [Service]
> ExecStart=3D/usr/sbin/sshd -D
>
> [Install]
> WantedBy=3Dmulti-user.target
>
> with the 84 of /etc/init.d/sshd (80 without comments).
>
> * Really good documentation: systemd has one of the best
> documentations I have ever seen in *any* project. Everything (except
> really new, experimental features) is documented, with manual pages
> explaining everything. And besides, there are blog posts by Lennart
> explaining in a more informal way how to do neat tricks with systemd.
>
> * Really good in-site customization: The service unit files are
> trivially overrided with custom ones for specific installations,
> without needing to touch the ones installed by systemd or a program.
> With OpenRC, if I modify a /etc/init.d file, chances are I need to
> check out my next installation so I can see how the new file differs
> from the old one, and adapt the changes to my customized version.
>
> * All the goodies from Control Groups: You can use kernel cgroups to
> monitor/control several properties of your daemons, out of the box,
> almost no admin effort involved.
>
> * It tries to unify Linux behaviour among distros (some can argue that
> this is a bad thing): Using systemd, the same
> configurations/techniques work the same in every distribution. No more
> need to learn /etc/conf.d, /etc/sysconfig, /etc/default hacks by
> different distros.
>
> * Finally, and what I think is the most fundamental difference between
> systemd and almost any other init system: The service unit files in
> systemd are *declarative*; you tell the daemon *what* to do, not *how*
> to do it. If the service files are shell scripts (like in
> OpenRC/SysV), everything can spiral out of control really easily. And
> it usually does (again, look at sshd; and that one is actully nicely
> written, there are all kind of monsters out there abusing the power
> that shell gives you).
>
> These are the ones off the top of my head; but what I like the most
> about systemd is that it just works, and that it makes a lot of sense
> (at least to me).
>
> Most of systemd features can be implemented in OpenRC, although the
> speed difference will never be eliminated if OpenRC keeps using shell
> files; however, Luca Barbato said that using reentrant busybox the
> speed difference is greatly reduced (I haven't confirmed this, since I
> haven't even installed OpenRC in months).
>
> Now, this set of (IMO) advantages of systemd over OpenRC pile up over
> the advantages of OpenRC over SysV: the most important one (I believe)
> is that OpenRC has dependencies, so a service starts only when another
> has already started. AFAIK, SysV has lacked this since always.
>
> I don't think I have ever heard anyone saying that we should keep
> using SysV; like a lot of Unix legacies, it should just die. OpenRC is
> much better, but it still uses a Turing-complete language (and a
> really slow one) to simply tell services when to start and when to
> stop, and it doesn't reliably keep track of what services are really
> still running (anyone who has ever used the "zap" command in OpenRC
> knows this).
>
> systemd of course has dependencies, a reliable tracking of service
> status (thanks in part to the use of cgroups), and its service files
> can't enter in an infinite loop.
>
> Hope it helps.
>
> Regards.
> --
> Canek Pel=C3=A1ez Vald=C3=A9s
> Posgrado en Ciencia e Ingenier=C3=ADa de la Computaci=C3=B3n
> Universidad Nacional Aut=C3=B3noma de M=C3=A9xico
>
Thank you. I think that may well be the cleanest set of favorable arguments
I've seen for systemd.
Now, question: could I not create a "/usr" service and make things
dependent on /usr come after it's been mounted? That seems the single, core
missing piece.
--e89a8fb2028cc44f9b04d1ad18f7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p><br>
On Dec 25, 2012 3:04 AM, "Canek Pel=C3=A1ez Vald=C3=A9s" <<a h=
ref=3D"mailto:caneko@gmail.com">caneko@gmail.com</a>> wrote:<br>
><br>
> On Tue, Dec 25, 2012 at 1:38 AM, G.Wolfe Woodbury <<a href=3D"mailt=
o:redwolfe@gmail.com">redwolfe@gmail.com</a>> wrote:<br>
> [ snip ]<br>
> > From what has been happening with the systemd stuff, I do not see=
what<br>
> > advantages it really offers over the SysV scheme and its successo=
rs like<br>
> > OpenRC. =C2=A0Someone enlighten me please?<br>
><br>
> I wrote the following some months ago; I think nothing much has<br>
> changed since then (I added a couple of comments):<br>
><br>
> Take this with a grain (or a kilo) of salt, since I'm obviously<br=
>
> biased, but IMHO this are systemd advantages over OpenRC:<br>
><br>
> * Really fast boot. OpenRC takes at least double the time that systemd=
<br>
> does when booting, easily verifiable. In my laptop systemd is twice as=
<br>
> fast as OpenRC; in my desktop is three times faster. (With a solid<br>
> state hard drive, my laptop now boots even faster).<br>
><br>
> * Really parallel service startup: OpenRC has never been reliable on<b=
r>
> parallel service startup; its documentation says it explicitly. Some<b=
r>
> will tell you that for them "it works", but just like the gu=
ys who<br>
> have a separate /usr and refuse to use an initramfs, they just haven&#=
39;t<br>
> been bitten by the inherent problems of it (just ask kernel developer<=
br>
> Greg Kroah-Hartman). The Gentoo devs recognize that OpenRC is just<br>
> broken with parallel service startup.<br>
><br>
> * Really simple service unit files: The service unit files are really<=
br>
> small, really simple, really easy to understand/modify. Compare the 9<=
br>
> lines of sshd.service:<br>
><br>
> $ cat /etc/systemd/system/sshd.service<br>
> [Unit]<br>
> Description=3DSSH Secure Shell Service<br>
> After=3Dsyslog.target<br>
><br>
> [Service]<br>
> ExecStart=3D/usr/sbin/sshd -D<br>
><br>
> [Install]<br>
> WantedBy=3Dmulti-user.target<br>
><br>
> with the 84 of /etc/init.d/sshd (80 without comments).<br>
><br>
> * Really good documentation: systemd has one of the best<br>
> documentations I have ever seen in *any* project. Everything (except<b=
r>
> really new, experimental features) is documented, with manual pages<br=
>
> explaining everything. And besides, there are blog posts by Lennart<br=
>
> explaining in a more informal way how to do neat tricks with systemd.<=
br>
><br>
> * Really good in-site customization: The service unit files are<br>
> trivially overrided with custom ones for specific installations,<br>
> without needing to touch the ones installed by systemd or a program.<b=
r>
> With OpenRC, if I modify a /etc/init.d file, chances are I need to<br>
> check out my next installation so I can see how the new file differs<b=
r>
> from the old one, and adapt the changes to my customized version.<br>
><br>
> * All the goodies from Control Groups: You can use kernel cgroups to<b=
r>
> monitor/control several properties of your daemons, out of the box,<br=
>
> almost no admin effort involved.<br>
><br>
> * It tries to unify Linux behaviour among distros (some can argue that=
<br>
> this is a bad thing): Using systemd, the same<br>
> configurations/techniques work the same in every distribution. No more=
<br>
> need to learn /etc/conf.d, /etc/sysconfig, /etc/default hacks by<br>
> different distros.<br>
><br>
> * Finally, and what I think is the most fundamental difference between=
<br>
> systemd and almost any other init system: The service unit files in<br=
>
> systemd are *declarative*; you tell the daemon *what* to do, not *how*=
<br>
> to do it. If the service files are shell scripts (like in<br>
> OpenRC/SysV), everything can spiral out of control really easily. And<=
br>
> it usually does (again, look at sshd; and that one is actully nicely<b=
r>
> written, there are all kind of monsters out there abusing the power<br=
>
> that shell gives you).<br>
><br>
> These are the ones off the top of my head; but what I like the most<br=
>
> about systemd is that it just works, and that it makes a lot of sense<=
br>
> (at least to me).<br>
><br>
> Most of systemd features can be implemented in OpenRC, although the<br=
>
> speed difference will never be eliminated if OpenRC keeps using shell<=
br>
> files; however, Luca Barbato said that using reentrant busybox the<br>
> speed difference is greatly reduced (I haven't confirmed this, sin=
ce I<br>
> haven't even installed OpenRC in months).<br>
><br>
> Now, this set of (IMO) advantages of systemd over OpenRC pile up over<=
br>
> the advantages of OpenRC over SysV: the most important one (I believe)=
<br>
> is that OpenRC has dependencies, so a service starts only when another=
<br>
> has already started. AFAIK, SysV has lacked this since always.<br>
><br>
> I don't think I have ever heard anyone saying that we should keep<=
br>
> using SysV; like a lot of Unix legacies, it should just die. OpenRC is=
<br>
> much better, but it still uses a Turing-complete language (and a<br>
> really slow one) to simply tell services when to start and when to<br>
> stop, and it doesn't reliably keep track of what services are real=
ly<br>
> still running (anyone who has ever used the "zap" command in=
OpenRC<br>
> knows this).<br>
><br>
> systemd of course has dependencies, a reliable tracking of service<br>
> status (thanks in part to the use of cgroups), and its service files<b=
r>
> can't enter in an infinite loop.<br>
><br>
> Hope it helps.<br>
><br>
> Regards.<br>
> --<br>
> Canek Pel=C3=A1ez Vald=C3=A9s<br>
> Posgrado en Ciencia e Ingenier=C3=ADa de la Computaci=C3=B3n<br>
> Universidad Nacional Aut=C3=B3noma de M=C3=A9xico<br>
></p>
<p>Thank you. I think that may well be the cleanest set of favorable argume=
nts I've seen for systemd.</p>
<p>Now, question: could I not create a "/usr" service and make th=
ings dependent on /usr come after it's been mounted? That seems the sin=
gle, core missing piece.<br>
</p>
--e89a8fb2028cc44f9b04d1ad18f7--