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 49D01138E20 for ; Fri, 21 Feb 2014 22:19:32 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C33B5E0EB5; Fri, 21 Feb 2014 22:19:25 +0000 (UTC) Received: from mail-la0-f65.google.com (mail-la0-f65.google.com [209.85.215.65]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 780C2E0EA6 for ; Fri, 21 Feb 2014 22:19:24 +0000 (UTC) Received: by mail-la0-f65.google.com with SMTP id hr17so364019lab.4 for ; Fri, 21 Feb 2014 14:19:23 -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=/4zVsftcvcFDpPcXbR3sZtJagpjlTlaYN3+OtncW6o4=; b=OttUvsA1CVx0yugXCssAoZSROuY/Ml/mhgb5n4ORHkqeqfkPZreftdqk2ZEqMLRNhm 6OD1xnwbrPhtE54cyOOegDMvPXeSTTGh6CV+t97iJjlJIpKeYHmIu9YebPZWxPcYbIMr eVTtnNubkwJvtswcJfPMCFaUhn6HIYR1tclFDIN0a2446yfUC5yo2jKZI64FsUkH15ly v978WXB7AMndvB54sIUWYxppq9QJ8237hi5HzLYsiQiwZW8r9f4JmBx/VyyX3+/q0u/A kcougjl0bHXDFcLTcY+LI/MDRFWPnc2Br4FHqdNgd4FGXP/Qq4sOObr90UbX5ioQOK+c C3qA== 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.152.6.199 with SMTP id d7mr5653461laa.22.1393021162915; Fri, 21 Feb 2014 14:19:22 -0800 (PST) Received: by 10.114.170.67 with HTTP; Fri, 21 Feb 2014 14:19:22 -0800 (PST) In-Reply-To: <20140221114216.027ca1dbdb341884b3fded67@gmail.com> References: <52FF84CE.2050301@libertytrek.org> <52FF9D58.3000608@libertytrek.org> <52FFCE52.5060401@sporkbox.us> <5306990B.1030506@sporkbox.us> <20140221114216.027ca1dbdb341884b3fded67@gmail.com> Date: Fri, 21 Feb 2014 16:19:22 -0600 Message-ID: Subject: Re: [gentoo-user] Re: Debian just voted in systemd for default init system in jessie 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: 029fb824-305f-4356-b874-b268944a74e0 X-Archives-Hash: d056e6b8b12409585285c8dfd1e972fc On Fri, Feb 21, 2014 at 1:42 AM, Andrew Savchenko wrote= : > On Thu, 20 Feb 2014 18:08:43 -0600 Daniel Campbell wrote: >> It's marginally clever, but so clearly obvious at the same time. It's >> sad (to me) that the community didn't see it coming. Those who did have >> been written off as conspiracy theorists or FUDders. Time will reveal al= l. > > Indeed time reveals everything and part of this foiled plot > revealed itself two days ago. It was said earlier in the list by > systemd supporters, that this project is modular, fine split to > binaries and thus critical issues in the pid 1 are not that likely. > And just look at systemd-209 release notes: > > http://lists.freedesktop.org/archives/systemd-devel/2014-February/017146.= html > [quote] We merged libsystemd-journal.so, libsystemd-id128.so, > libsystemd-login and libsystemd-daemon into a a single libsystemd.so > to reduce code duplication and avoid cyclic dependencies (see below). > [/quote] > > So all talks about systemd being modular are nothing more than > nonsense. Guess what will happen on segfault in libsystemd.so? > Segfaults in pid 1 are so nice to bear... You have no idea what are you talking about, do you? The systemd binary (you know, PID 1) *DOESN'T LINK AGAINST libsystemd.so!* It's for consumers of systemd's APIs. > And Canek please talk no more about how "talented" systemd > programmers are or even about how "professional" they are, because > they're no longer. They failed a trivial textbook example: what should > one do when libraries A and B have some common code and cyclic deps? > Push common code to library C. That's the Unix way and secure way. > Creating single bloated library will help in neither fencing nor > debugging, nor code audit. This actually I'm even willing to discuss. They give the rationale in the notes you linked: "he reason for this is cyclic dependencies, as these libraries tend to use each other's symbols." It's true, they could have splitted even more the libraries, but they instead coalesced them. If the libraries used each other symbols, then they basically are functioning as a single module, and then it can be argued that coalescing them is a good move. I'm not saying I agree; I think I also would have preferred for them to split the cycles into another library. But I give the benefit of the doubt to the maintainers, and certainly would still think they are talented enough. (And again, it's a "normal" library, for third-party consumers, not PID 1). > It looks like to me that ultimate goal of systemd is to consume as > much system and user tools and interfaces as possible. Yeah, that's the idea. They have been pretty clear and honest about it. They want systemd to be the standard basic plumbing of Linux. > Perhaps, in the > ideal systemd world there will be nothing but linux-systemd kernel and > systemd-stuff userspace. I would call it "systemd-aware" userspace, but yeah, again, that's the ide= a. > Shell communication will extinct, all major > application and daemons will be converted to systemd "modules". Why would you disallow shell communication? It's pretty useful. But it will be complemented with dbus IPC and systemd controlled processes. It works pretty much like this with GNOME right now. If you don't want this, just keep using OpenRC. Nobody is forcing systemd on you. > Of > course this goal will be never achieved as-is, but one may consider > it as an asymptote of their actions. They want systemd to be the basic plumbing of Linux, yes. 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