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 F3442138E66 for ; Mon, 24 Feb 2014 14:33:40 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 04922E0B3D; Mon, 24 Feb 2014 14:33:35 +0000 (UTC) Received: from mail-ie0-f196.google.com (mail-ie0-f196.google.com [209.85.223.196]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id AEBC9E0B2E for ; Mon, 24 Feb 2014 14:33:33 +0000 (UTC) Received: by mail-ie0-f196.google.com with SMTP id rd18so1959138iec.3 for ; Mon, 24 Feb 2014 06:33:33 -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=j8Mze8f2iaR8PqTH1yA0Do1AxTIwq+22AbBnjWHWUmw=; b=GpPcq65GChnD5L7KXSUCEnIKb6hmBbZ6pibMZDCTjqLqn9pQZhyKni+yj7yHzEVLD4 P+UnfMGIe5Tf5jZ4IOe2X9ZIZSQcgeiyhP70apuxq10aHsHMDrbNpFMbvuf17Lg+XaiA y2ZZJcF7CKmb+ctc6eS/53I4R7waiyVwspteui+PZGlVm0HtBigfUjWCOfvu887HFTse lXw6j9WmIL9KlharMMkNmdLFnUu/usTzzLVc3hkcV/IVWDAzDV/nw799N1Np87neY1VY w87XMvUPwCdYQ08tNZ4HR6S9hVjeXygXSxgGZ5ujPkgDo8svOgA92ao/5xUo609bHwYG qykA== 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 X-Received: by 10.43.138.8 with SMTP id iq8mr14539277icc.37.1393252404086; Mon, 24 Feb 2014 06:33:24 -0800 (PST) Received: by 10.50.122.37 with HTTP; Mon, 24 Feb 2014 06:33:23 -0800 (PST) In-Reply-To: <530B4C29.5080406@yandex.ru> References: <52FF84CE.2050301@libertytrek.org> <5301B3E1.3000007@yandex.ru> <201402231335.31992.michaelkintzios@gmail.com> <530A7700.4030809@gmail.com> <530AF085.1000206@yandex.ru> <530B4C29.5080406@yandex.ru> Date: Mon, 24 Feb 2014 22:33:23 +0800 Message-ID: Subject: Re: [gentoo-user] Debian just voted in systemd for default init system in jessie From: Mark David Dumlao To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 7f49b56b-19f0-4a11-bf69-95614dc4042b X-Archives-Hash: 275b58e2502b56006ee3bd53a1496022 On Mon, Feb 24, 2014 at 9:42 PM, Yuri K. Shatroff wrote= : > > > 24.02.2014 16:39, Mark David Dumlao =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >> On Mon, Feb 24, 2014 at 3:11 PM, Yuri K. Shatroff >> wrote: >>> >>> 24.02.2014 02:32, Alan McKinnon wrote: >>>> >>>> [1] For lack of a better term, let's just call systemd here a "system >>>> controller". What is this ONE thing a system controller should do and = do >>>> it well? >>> >>> >>> >>> An init daemon generally does one thing well. >> >> >> it's obvious you haven't thought this through. >> >> consider, for a moment, that the "one thing well" that an init daemon >> is supposed to do is >> "run programs that do arbitrary things to get the system to an arbitrary >> state". >> >> do you not see a problem? > > > No. As you say, ``an init daemon is supposed to do is "run programs``, un= til > here you're right, but then you start talking about things the init doesn= 't > do but the programs do. In your wording, an init daemon is also a DBMS, a= n > MTA, a network startup daemon, a firewall, a getty and whatever program r= uns > on the system. Let's try to talk you through to a soft landing here. When we say init, are we just referring to pid 1, or are we referring to something else entirely? OpenRC is often spoken of in the same breath as systemd, as if they were the same kind of thing. That sounds fair but think about it for a second: openrc - as most people talk about it - isn't even pid 1. as most people talk about it, openrc includes the functions.sh, the net.eth0 scripts, the script for starting your /sys, /proc, mounting local and network filesystems, sett= ing the hostname and so on. They may be written in a different language from pid1, but when people talk about openrc, they are talking about that whole ball of wax. From a systems perspective - they're parts of the same thing. Even discounting the parts that you think are ridiculous, like databases an= d loggers, there are clearly more parts in there above than can be cleanly de= fined as "one thing". Who gets to decide which is the "one thing" or not? You? Don't you rely on openrc to set your hostname? Load your kernel modules? Run your sysctl? Set any miscellaneous options in /sys? Mount your filesystems? Go ahead, define for everyone, once and for all, what this "one thing" is. Does this one thing init include a subsystem for reading separate environment files per-service? Isn't this just feature creep? Can't you jus= t edit the init scripts to add those in? I mean, they are already scripts after all. And they're in /etc, they're meant to be configured. Does this one thing include service dependencies? Why sysv has gone for a LONG time without them, just a sequencing, and that works fine for almost all cases anyways. Isn't this just feature creep? Can't you just edit the i= nit scripts to start any dependent services? Point is - go look at any arbitrary feature that's part of your "init system" and you could cry to hell and high water that it's violating the "one thing", whatever that "one thing" is that doesn't seem to be defined. At least with systemd the parts are cleanly split off into separate executa= bles. Yes, it's technically not needed for pid 1 to create tempfiles for other programs. That's why systemd-tmpfiles is its own tiny program, that does one "one thi= ng" (create tempfiles for other programs) and nothing else. Yes, it's technical= ly not needed for pid 1 to check your filesystems. That's why systemd-fsck is once again, a separate utility, that does "one thing" (run fsck) well. Yes, it's technically not needed for pid 1 to remount your filesystems readwrite= . Again there's a separate utilty for that, that does nothing but just that. It's clear to me that there's an analogue between the different parts of a full openrc system - that just happen to be implemented in scripts - and the different parts of a systemd system - that just happen to be implemente= d in small binaries. Every time people complain about systemd having too many features, they just _casually_ forget to mention that, for instance, their init actua= lly asks them if they want to run interactive (why do that when you can specify from the boot loader?) or checks the configuration files of their daemons to see if they're valid and prompts the user to config if not. They just _casually_ fail to mention that their init has plugins for NetworkManager and ifplugd, that it comes with scripts for setting the consolefont. Meanwhile systemd does those same things, and it's bloated, theirs isn't. Oh you're going to say that that's not fair, it's external optional stuff, it's not _really_ part of openrc, but that's not intellectually honest is i= t? Heck, I could do that same. I could control my bootup process so that I run my own stuff instead of systemd-fsck, systemd-tmpfiles, systemd-mount and all that jazz and run plain old init scripts in their place. Why bother? The reality is that - init scripts don't do just one thing, and don't even do it well. --=20 This email is: [ ] actionable [ ] fyi [x] social Response needed: [ ] yes [ ] up to you [x] no Time-sensitive: [ ] immediate [ ] soon [x] none