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 C1A781381FB for ; Tue, 25 Dec 2012 08:02:37 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1746521C06A; Tue, 25 Dec 2012 08:02:23 +0000 (UTC) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 9007F21C010 for ; Tue, 25 Dec 2012 08:01:14 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id c13so9670293ieb.3 for ; Tue, 25 Dec 2012 00:01:13 -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:content-transfer-encoding; bh=SmHlnTzy4DCdfZvpzxx4v3QpOrok8ppQtQmgAohNgPE=; b=B52Qlsc74u+zpRTteN9ditqoWC8gsSzAkHXKQMUeK6t4qT4ggy7nB/Dyy1+PNKv/Za De7SrF+blB4LAUkGvAx8qnogncKsxsdXOeQt4UvG/igOjGptNu/G5MSoSKke7Zywmjws xUE2VdOriVvd1VRR9ve4Bs+g6eP4iRcXs6RMfNVViyh4ctf0o0LsF8V/fZVKJsE7jde0 PzU2Of1g5A5gcRfQhQFMthMgfFvnwYzWtM1YxrjCDCrXRUHkOBaf6pcssew/ofrIKV5/ cBJS09Vi6c5Hv1MdMErAODyKy+cf0NqGClc2VvZIojC9gGeEhfpkym+8Clf9pVX4rsvd kvXA== 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.50.190.199 with SMTP id gs7mr12238707igc.89.1356422473331; Tue, 25 Dec 2012 00:01:13 -0800 (PST) Received: by 10.64.32.195 with HTTP; Tue, 25 Dec 2012 00:01:13 -0800 (PST) In-Reply-To: <50D957F0.1060406@gmail.com> References: <50CB1942.3020900@gmail.com> <50CB4A3C.1030109@gmail.com> <50CB5406.7040404@gmail.com> <8738z7hgsa.fsf@ist.utl.pt> <20121216171043.71084070@khamul.example.com> <20121217104621.735bf43a@khamul.example.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> <50D957F0.1060406@gmail.com> Date: Tue, 25 Dec 2012 02:01:13 -0600 Message-ID: Subject: Re: [gentoo-user] Re: Anyone switched to eudev yet? -> what was wron with SysVInit? From: =?UTF-8?B?Q2FuZWsgUGVsw6FleiBWYWxkw6lz?= To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: b2e13a6c-3d7b-47fe-bd5c-cdaa73cd9951 X-Archives-Hash: 869c99a6b57d7312a84f8156b7850231 On Tue, Dec 25, 2012 at 1:38 AM, G.Wolfe Woodbury wrot= e: [ 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 like > 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. --=20 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