From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-user+bounces-136482-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1S95l0-00024c-4i
for garchives@archives.gentoo.org; Sun, 18 Mar 2012 02:22:06 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 9A6E2E0802;
Sun, 18 Mar 2012 02:21:42 +0000 (UTC)
Received: from svr-us4.tirtonadi.com (svr-us4.tirtonadi.com [69.65.43.212])
by pigeon.gentoo.org (Postfix) with ESMTP id A6D5EE07C7
for <gentoo-user@lists.gentoo.org>; Sun, 18 Mar 2012 02:20:05 +0000 (UTC)
Received: from mail-vx0-f181.google.com ([209.85.220.181])
by svr-us4.tirtonadi.com with esmtpsa (TLSv1:RC4-SHA:128)
(Exim 4.69)
(envelope-from <pandu@poluan.info>)
id 1S95j4-002tkX-0Y
for gentoo-user@lists.gentoo.org; Sun, 18 Mar 2012 09:20:06 +0700
Received: by vcge1 with SMTP id e1so6521744vcg.40
for <gentoo-user@lists.gentoo.org>; Sat, 17 Mar 2012 19:20:02 -0700 (PDT)
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.52.17.82 with SMTP id m18mr3397537vdd.89.1332037202607; Sat,
17 Mar 2012 19:20:02 -0700 (PDT)
Received: by 10.220.58.200 with HTTP; Sat, 17 Mar 2012 19:20:02 -0700 (PDT)
Received: by 10.220.58.200 with HTTP; Sat, 17 Mar 2012 19:20:02 -0700 (PDT)
In-Reply-To: <CADPrc80qcOhyQy8SPmpYbp8vrO6y_H2hg6x594fjoub7hWEvkg@mail.gmail.com>
References: <709768995.843751.1331957483491.JavaMail.open-xchange@email.1and1.com>
<jk1apk$b2o$1@dough.gmane.org>
<20120317115300.GB3615@acm.acm>
<jk3bd5$rp6$1@dough.gmane.org>
<CADPrc80qcOhyQy8SPmpYbp8vrO6y_H2hg6x594fjoub7hWEvkg@mail.gmail.com>
Date: Sun, 18 Mar 2012 09:20:02 +0700
Message-ID: <CAA2qdGUf8JDopUoFjs_zce2xHh0PDy36Qfdzr1kXTJ=GmoEbGA@mail.gmail.com>
Subject: Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ]
From: Pandu Poluan <pandu@poluan.info>
To: gentoo-user@lists.gentoo.org
Content-Type: multipart/alternative; boundary=bcaec50405d649fdea04bb7b142c
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - svr-us4.tirtonadi.com
X-AntiAbuse: Original Domain - lists.gentoo.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - poluan.info
X-Archives-Salt: 623d6b53-cb01-4df6-9d59-f14a0669a8b4
X-Archives-Hash: 13b3f866855d5ec21583021107beabe3
--bcaec50405d649fdea04bb7b142c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Mar 18, 2012 8:48 AM, "Canek Pel=C3=A1ez Vald=C3=A9s" <caneko@gmail.com>=
wrote:
>
> On Sat, Mar 17, 2012 at 6:48 PM, Nikos Chantziaras <realnc@gmail.com>
wrote:
> > On 17/03/12 13:53, Alan Mackenzie wrote:
> >>
> >> Hello, Nikos.
> >>
> >> On Sat, Mar 17, 2012 at 08:25:48AM +0200, Nikos Chantziaras wrote:
> >>
> >>>> Happy Computer Users, systemd is on your horizon.
> >>
> >>
> >>> No, we don't. I hope systemd arrives soon. It's the best init
system I
> >>> ever saw.
> >>
> >>
> >> What's so good about it? What will it do for me?
> >>
> >> I have this horrible sneaking suspicion that it will be more
complicated
> >> than /sbin/init + OpenRC, just like udev + initramfs is more
complicated
> >> than udev, and CUPS is more complicated than classical lpr.
> >>
> >> Why do you find it so good?
> >
> >
> > No idea. I only posted this because the OP didn't say what's bad about
> > systemd :-) I really don't know I should care whether my system runs
OpenRC
> > or systemd.
>
> 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.
>
> * Really parallel service startup: OpenRC has never been reliable on
> parallel service startup; its documentation says it explicitly.
>
> * 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). My question is: why bother? systemd is already here, it
> already works, and it's actually supported in Gentoo.
>
> But again, remember that I'm biased: I keep an overlay to run Gentoo
> systems with only systemd; no OpenRC, no baselayout, no SysV. You guys
> can try it if you want:
>
> http://xochitl.matem.unam.mx/~canek/gentoo-systemd-only/
>
> Usual disclaimer: I take no responsibility if using my overlay results
> in your systems asploding. That said, I'm using it on all my machines
> without a hitch.
>
> Regards.
Interesting...
However, what if the service is complex? For example, I created a
"gatewall" service which, upon boot, initializes :
* Routing tables and the RPDB
* ipset
* iptables
while ensuring that upon shutdown, the settings of the above are
(optionally) saved.
How do I specify such intelligence?
Rgds,
--bcaec50405d649fdea04bb7b142c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p><br>
On Mar 18, 2012 8:48 AM, "Canek Pel=C3=A1ez Vald=C3=A9s" <<a h=
ref=3D"mailto:caneko@gmail.com">caneko@gmail.com</a>> wrote:<br>
><br>
> On Sat, Mar 17, 2012 at 6:48 PM, Nikos Chantziaras <<a href=3D"mail=
to:realnc@gmail.com">realnc@gmail.com</a>> wrote:<br>
> > On 17/03/12 13:53, Alan Mackenzie wrote:<br>
> >><br>
> >> Hello, Nikos.<br>
> >><br>
> >> On Sat, Mar 17, 2012 at 08:25:48AM +0200, Nikos Chantziaras w=
rote:<br>
> >><br>
> >>>> Happy Computer Users, systemd is on your horizon.<br>
> >><br>
> >><br>
> >>> No, we don't. =C2=A0I hope systemd arrives soon. =C2=
=A0It's the best init system I<br>
> >>> ever saw.<br>
> >><br>
> >><br>
> >> What's so good about it? =C2=A0What will it do for me?<br=
>
> >><br>
> >> I have this horrible sneaking suspicion that it will be more =
complicated<br>
> >> than /sbin/init + OpenRC, just like udev + initramfs is more =
complicated<br>
> >> than udev, and CUPS is more complicated than classical lpr.<b=
r>
> >><br>
> >> Why do you find it so good?<br>
> ><br>
> ><br>
> > No idea. =C2=A0I only posted this because the OP didn't say w=
hat's bad about<br>
> > systemd :-) =C2=A0I really don't know I should care whether m=
y system runs OpenRC<br>
> > or systemd.<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.<br>
><br>
> * Really parallel service startup: OpenRC has never been reliable on<b=
r>
> parallel service startup; its documentation says it explicitly.<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). My question is: why bother? systemd is already here, it<br>
> already works, and it's actually supported in Gentoo.<br>
><br>
> But again, remember that I'm biased: I keep an overlay to run Gent=
oo<br>
> systems with only systemd; no OpenRC, no baselayout, no SysV. You guys=
<br>
> can try it if you want:<br>
><br>
> <a href=3D"http://xochitl.matem.unam.mx/~canek/gentoo-systemd-only/">h=
ttp://xochitl.matem.unam.mx/~canek/gentoo-systemd-only/</a><br>
><br>
> Usual disclaimer: I take no responsibility if using my overlay results=
<br>
> in your systems asploding. That said, I'm using it on all my machi=
nes<br>
> without a hitch.<br>
><br>
> Regards.</p>
<p>Interesting... </p>
<p>However, what if the service is complex? For example, I created a "=
gatewall" service which, upon boot, initializes :</p>
<p>* Routing tables and the RPDB<br>
* ipset <br>
* iptables </p>
<p>while ensuring that upon shutdown, the settings of the above are (option=
ally) saved.</p>
<p>How do I specify such intelligence? </p>
<p>Rgds, <br>
</p>
--bcaec50405d649fdea04bb7b142c--