On Wed, Dec 26, 2012 at 4:19 PM, Kevin Chadwick <ma1l1i...@yahoo.co.uk> wrote: > On Tue, 25 Dec 2012 02:01:13 -0600 > Canek Peláez Valdés <can...@gmail.com> wrote: > > To the OP of this OT sub-thread. The main difference for me is OpenRC > removes some of the symlink mess and uncertainty compared to for > example debians init. I very much like OpenRC but my fav is still > OpenBSD that tries to minimise the number of files/folders to be > potentially locked down and is very transparent and quick to follow > through. > >> On Tue, Dec 25, 2012 at 1:38 AM, G.Wolfe Woodbury >> <redwo...@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 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). >> > > The usual statistic cited is 2 seconds but systemd can increase the > time dramatically or be a complete no go on embedded systems with > limited cpu and/or ram. Percentages of a section of the bootup is just > playing games like often used by annoying marketing departments. You > will save more boot time by switching to xfce from KDE/Gnome with > stronger arguments for doing so. > >> * 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. >> > > Not only that but is seen by many to be pointless except to minute > speed gains and a cause of various problems such as increased > difficulty in determining where a problem occurs. > >> * 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: >> > > But require reading documentation to understand with no other external > gain, unlike shell. > >> >> * 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. >> > > That explains why I see so many asking for help. The documentation may? > be complete but is terrible. Like LVM it is spread out into many > illogical files that would require a non existent sitemap to find. > OpenBSD is renowned for it's excellent documentation and note that it's > openssl pages are consolidated. > >> * 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. >> > > Nothing new, OpenBSD does similar. Completely aside from this > discussion. > >> * 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. >> > > The OpenBSD list pointed out the double forking argument to be > technically pointless. > > http://marc.info/?l=openbsd-misc&m=135314269712851&w=2 > >> * 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. >> > > So why was /etc/inittab removed for something that takes much more > effort to configure. > >> * 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). >> > > Then you don't have a great deal of experience in init systems. > >> 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). >> > > So basically you like systemd because it does not follow the unix > philosohy of many small independent tools to be more than the sum of > it's parts and systemd absolutely unarguably does complicate the code > **REQUIRED** to boot using many external and other questionably desired > features as justification. > >> 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. > > Enough time has been wasted on systemd including my own so start a new > thread that I can ignore from now on please or better still accept > that systemd is dividing and not unifying the unix community. Once you > realise that re-question everything else.
I didn't started the thread, Wolfe did. I just answered his question from my point of view. And, what community is being divided? Fedora,OpenSuse, and Arch use systemd by default. Gentoo derivative Exherbo recommends it as init system. It works great on Gentoo and Debian. I understand it even works in Ubuntu. systemd has done more to unify the Linux ecosystem than a lot of other projects in the last 20 years. And, really, I don't care about OpenBSD. I worked with it for three years; it's a nice toy Unix. But for serious work (server, desktop and mobile) I prefer Linux, and in my case (except for my phone, that uses Android) I run Gentoo+systemd in all my machines. You don't have to agree with that, is my personal preference. So it's great if you believe that the OpenBSD init system is similar in features to systemd; but even if it's true (which I seriously doubt), I care only about Linux, and from my point of view, systemd is one of the best things to happen to it. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
