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 ) 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 ; 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 ) 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 ; Sat, 17 Mar 2012 19:20:02 -0700 (PDT) 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 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: References: <709768995.843751.1331957483491.JavaMail.open-xchange@email.1and1.com> <20120317115300.GB3615@acm.acm> Date: Sun, 18 Mar 2012 09:20:02 +0700 Message-ID: Subject: Re: [gentoo-user] Re: systemd? [ Was: The End Is Near ... ] From: Pandu Poluan 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" = wrote: > > On Sat, Mar 17, 2012 at 6:48 PM, Nikos Chantziaras 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


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 w= rote:
> >>
> >>>> Happy Computer Users, systemd is on your horizon.
> >>
> >>
> >>> No, we don't. =C2=A0I hope systemd arrives soon. =C2= =A0It's the best init system I
> >>> ever saw.
> >>
> >>
> >> What's so good about it? =C2=A0What 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. =C2=A0I only posted this because the OP didn't say w= hat's bad about
> > systemd :-) =C2=A0I really don't know I should care whether m= y 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<= br> > small, really simple, really easy to understand/modify. Compare the 9<= br> > 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.<= br> >
> * 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<= br> > 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<= br> > (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<= br> > 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 Gent= oo
> systems with only systemd; no OpenRC, no baselayout, no SysV. You guys=
> can try it if you want:
>
> h= ttp://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 machi= nes
> 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 (option= ally) saved.

How do I specify such intelligence?

Rgds,

--bcaec50405d649fdea04bb7b142c--