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 52AA7138BF3 for ; Tue, 18 Feb 2014 00:35:49 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9F85FE0BB9; Tue, 18 Feb 2014 00:35:42 +0000 (UTC) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 4632FE0BA9 for ; Tue, 18 Feb 2014 00:35:36 +0000 (UTC) Received: by mail-lb0-f175.google.com with SMTP id p9so11781576lbv.34 for ; Mon, 17 Feb 2014 16:35:34 -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 :cc:content-type:content-transfer-encoding; bh=rg85tWEsRv0zBT4EsPLLvZ4ofzIWIIQYuyQsEVcP+uY=; b=IO2xLkFPBuAuW+p6+r9DYze+qEz9GF+cIatiBckayWxhRgYW/4R6Sdfn2A+8AsG4Qh Jmb0kGAYuUw1cjK/Lcsrt3P99KMlXxZHbyaUImC01Bb643vHt3m7gst1tz8h1NDLZBo+ x9sukDhdiO/J1sFSCfpL3RkBtkWL1kBg216CdKL8+cMTLVtH9HQQBgBwu3iqx9c4pKpR Y2vhQoYMaZPFuTJgsenYHHdF2emvJ51ZOgKP/1g2lL7YONjlzXPbRVTfFKJox1SK+Qb+ UF/Fz1gIh9LtC+k32I2BQNsw9XdGx3yM3STaNTGwVh5vktY4a2KkI6bR35+vCAj87fAV n9+w== 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.112.201.164 with SMTP id kb4mr18270041lbc.32.1392683734620; Mon, 17 Feb 2014 16:35:34 -0800 (PST) Received: by 10.114.170.67 with HTTP; Mon, 17 Feb 2014 16:35:34 -0800 (PST) In-Reply-To: <20140217215255.5766cb026df2f0b8002f8702@gmail.com> References: <52FF84CE.2050301@libertytrek.org> <52FF9D58.3000608@libertytrek.org> <201402152023.10543.michaelkintzios@gmail.com> <5300DD51.5060207@libertytrek.org> <53010A8E.2050909@googlemail.com> <53012691.6040503@googlemail.com> <20140217215255.5766cb026df2f0b8002f8702@gmail.com> Date: Mon, 17 Feb 2014 18:35:34 -0600 Message-ID: Subject: Re: [gentoo-user] Debian just voted in systemd for default init system in jessie From: =?UTF-8?B?Q2FuZWsgUGVsw6FleiBWYWxkw6lz?= To: Andrew Savchenko Cc: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 6844ac4b-b2d9-4c91-a278-87106739e830 X-Archives-Hash: 26ac6c8482cc0482711e07bffd3666a7 On Mon, Feb 17, 2014 at 11:52 AM, Andrew Savchenko wrot= e: > On Sun, 16 Feb 2014 15:16:36 -0600 Canek Pel=C3=A1ez Vald=C3=A9s wrote: >> On Sun, Feb 16, 2014 at 2:58 PM, Volker Armin Hemmann >> wrote: >> > Am 16.02.2014 21:08, schrieb Canek Pel=C3=A1ez Vald=C3=A9s: >> >> On Sun, Feb 16, 2014 at 12:59 PM, Volker Armin Hemmann >> >> wrote: >> >> [ snip ] >> >>> or it is an idiotic decision. Because features means complexity. >> >> Yeah, like the kernel. >> >> >> >>> Complexity means bugs. >> >> Bugs get reported, bugs get fixes. Life goes on. >> >> You didn't answered this, did you? > > Bugs are different. Bugs are bugs, period. And they get reported and fixed. > Bugs in the critical system components are > critical to the whole system. Yeah, that's why we have unit testing and QA teams and stable and unstable releases, etc. > If Libreoffice or browser > segfaults, some data may be lost and inconvenience created, but the > system will continue to run. If PID 1 segfaults =E2=80=94 everything is > lost, you have a kernel panic. And the world will end? The same happens if the kernel has an error. > That's why critical components should > be as simple and clean as possible. Like the kernel? You call that "simple"? I'm sorry, but you are (IMO) wrong: critical components should be thoroughly tested and debugged, and have integrated unit testing, and a large enough group of volunteers to test new releases before they go into the general public. > SysVinit code size is about 10 000 lines of code, OpenRC contains > about 13 000 lines, systemd =E2=80=94 about 200 000 lines. If you take into account the thousands of shell code that SysV and OpenRC need to fill the functionality of systemd, they use even more. Also, again, systemd have a lot of little binaries, many of them optional. The LOC of PID 1 is actually closer to SysV (although still bigger). > Even assuming > systemd code is as mature as sysvinit or openrc (though I doubt this) > you can calculate probabilities of segfaults yourself easily. I don't care about probabilities; I care about facts: FACT, I've been using systemd since 2010, in several machines, and I haven't had a single segfault. FACT: almost no bug report in systemd involves a segfault in PID 1. >> >> All of them are different tools providing one capability to systemd a= s >> >> a whole. So systemd is a collection of tools, where each one does one >> >> thing, and it does it well. >> >> >> >> By your definition, systemd perfectly follows "the unix way". >> >> >> > >> > no, it isn't. >> > >> > How are those binaries talk to each other? >> >> dbus, which is about to be integrated into the kernel with kdbus. > > And this is a very, very bad idea. Looks like you don't know matter at > all: to begin with kdbus protocol is NOT compatible dbus and special > converter daemon will be needed to enable dbus to talk to kdbus. kdbus uses a different wire protocol than dbus; but for clients that doesn't matter; libsystemd-dbus will offer a compatibility layer (talk about "standard" and "replaceable"), so if your application uses dbus today, it will work with kdbus. Of course, new applications will take advantage of the new features of kdbu= s. > The > whole kdbus technology is very questionable itself (and was > forcefully pushed by RH devs), Sorry, but it's you who doesn't know the matter at hand: kdbus was (and is) written by Greg Kroah-Hartman, Linus' right hand, and who works for the Linux Foundation. > anyway it is possible to disable this > stuff in kernel and guess what will be done on my systems. Good for you. Guess what will be done in mine? >> > Looks broken. Broken by design. The worst form of broken. >> >> By your opinion, not others. > > That is not just an opinion. There is a science and experience behind > system's design. Yeah, what do you think about Greg Kroah-Hartman, Linus' right hand, or Keith Packard of X.org fame? None of them works for Red Hat; both of them know more about Unix and Linux than you and me together, and both of them promote systemd. I mean, I myself know a thing or two about computing and Linux, and I promote systemd (and nobody pays me, BTW), but obviously you don't need to believe in my credentials. And, no offense, but I will always give more weight to the words of Greg Kroah-Hartman or Keith Packard (to name only two), instead of a random user in gentoo-user. There are knowledgeable people who are against systemd. But usually they don't give *technical* sound reasons. > And all that science was ignored during systemd > architecture process if there was any at all. You should read systemd-devel and Lennart's blog posts before saying something like that. I did. 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