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 E39AD13838B for ; Mon, 22 Sep 2014 02:34:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 06263E0916; Mon, 22 Sep 2014 02:34:25 +0000 (UTC) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 52A81E08F9 for ; Mon, 22 Sep 2014 02:34:24 +0000 (UTC) Received: by mail-vc0-f181.google.com with SMTP id ik5so2438524vcb.40 for ; Sun, 21 Sep 2014 19:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=MMTTz6iC2bBzbmsBpdkwXXP8nZ+EeR4OQyB1ehF2H5A=; b=yGFhTivPP9siWestSDgSO7yWSKVrQWWNBzwGm7wydx6UeEWCBFhqZsCOLn6HcGaOWF f/SnNEA4oo+ZsBbUOeYppkq+ydYtk345D2HfRG7DEcubWefDfBp7Je9eBTVnwU13hKVU /fLy0L4Ovc42skcT934JNUmgIZ+Hoqj054JphqwPSX2NVSp6uuzUrw6ryufYpY+T3i+W OQBd7VV8Oq8vywkybisH5t/hhNK2NoN9zsYXjHTfr1rto78ePB8GD+K11UAbtq8/JjeM MHXXPzpBQUSJUSZ39kcWRJctBzn1di+BcxGbblc+zuTj9KHYQk6wg8IyrVbsVNiE2rc1 qQ1A== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.52.145.199 with SMTP id sw7mr6836668vdb.33.1411353263356; Sun, 21 Sep 2014 19:34:23 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.8.229 with HTTP; Sun, 21 Sep 2014 19:34:23 -0700 (PDT) In-Reply-To: <20140921220253.29b05782092a062c7148cbed@comcast.net> References: <20140921132548.d4ad54724473a2aeee688daa@comcast.net> <20140921143059.c3c16dfdeab6f65280b7caa6@comcast.net> <20140921192043.GA9652@crud> <20140921171301.5f008b3bd12c21c2f8fdd67e@comcast.net> <20140921202600.08d082d88014228172007477@comcast.net> <20140921220253.29b05782092a062c7148cbed@comcast.net> Date: Sun, 21 Sep 2014 22:34:23 -0400 X-Google-Sender-Auth: QxcyWu4zc6VKmecHvSiAuVVLae4 Message-ID: Subject: Re: [gentoo-amd64] Boycott Systemd From: Rich Freeman To: gentoo-amd64@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: ece83a79-e180-431e-a1a9-8b53c1538d46 X-Archives-Hash: 334a022ffa34d0eb264480035e82ee96 On Sun, Sep 21, 2014 at 10:02 PM, Frank Peters wrote: > On Sun, 21 Sep 2014 20:45:17 -0400 > Rich Freeman wrote: >> You can create device nodes using mknod, and I'd be >> shocked if that ever went away. >> > > But now certain static USB nodes, in particular those for > scanners, have been removed in favor of dynamic allocation > using udev or its equivalents. When this happened I was > certainly shocked, and it could be the beginning of a trend. Fair point, although to some extent this reflects the nature of how modern devices work. Back in the day you had a few serial/parallel ports and you could tell which one was which because they all used different IO ports or IRQs that were hard-coded into the designs. Now you just have one USB host controller which is really the only actual true hardware device on the system and everything that is hooked up to it is virtualized. Plug-and-play really did away with the way device nodes tended to work, and systems like udev are probably the cleanest solution. I for one am happy that I haven't had to configure an IRQ since the 90s. > >> >> Just what is it that you actually >> need the kernel to do for you that you don't think will still be >> around in 20 years? Linus is VERY conservative about removing system >> calls. >> > > There are things which are not system calls that could easily be > changed. It is not too far fetched to consider a time if and when > systemd became so popular and entrenched that the kernel would be > hard-coded to pass control only to systemd and nothing else. That seems extremely unlikely. How many people ran anything other than sysvinit as their init for the 15 years or so before upstart came along? Making the kernel dependent on systemd would defeat the whole purpose of having a separation between userspace and kernelspace. > >> >> If the whole world moves to systemd the biggest problem you'll have is >> that you'll have to write your own service startup scripts, but from >> the sound of things you're doing that anyway. Most of the services >> you probably run aren't linux-exclusive either, so while it seems >> likely that many will start reporting their status to systemd it seems >> unlikely that they will refuse to work without it. >> > > There are a growing number of applications that will no longer compile > without either dbus or udev. In fact, even though I don't use them, > I had to install both eudev and dbus in order to be able to use certain > applications (I just substituted a symlink to /bin/true in place of > dbus-launch to keep that unnecessary daemon from starting). Well, it seems likely that dbus will be a kernel module before long, so it will be readily available. I'm sure there are plenty of programs that don't work if you don't have any number of kernel options disabled. Kdbus is viewed as the future standard mechanism for linux inter-process communication, so programs relying on it should be as surprising as programs that rely on ptys. Much of the issue boils down to the linux world becoming more complex/functional. Back when you could assume that your printer was attached to a parallel port and spoke postscript things were simpler. Today people want to plug in their USB headset and have the computer know to use the USB headset for their teleconference and put the output in the speakers when the phone rings. That just isn't going to work with a world where you output a sound by directing a .au file to a device node. -- Rich