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 49AE313838B for ; Mon, 22 Sep 2014 02:03:02 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9E5C0E0916; Mon, 22 Sep 2014 02:02:59 +0000 (UTC) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [69.252.207.38]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id F36A0E0841 for ; Mon, 22 Sep 2014 02:02:58 +0000 (UTC) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by resqmta-ch2-06v.sys.comcast.net with comcast id u22T1o0041HzFnQ0122y8l; Mon, 22 Sep 2014 02:02:58 +0000 Received: from ajax ([24.11.47.14]) by omta14.westchester.pa.mail.comcast.net with comcast id u22x1o00S0JMh7c3a22yNu; Mon, 22 Sep 2014 02:02:58 +0000 Date: Sun, 21 Sep 2014 22:02:53 -0400 From: Frank Peters To: gentoo-amd64@lists.gentoo.org Subject: Re: [gentoo-amd64] Boycott Systemd Message-Id: <20140921220253.29b05782092a062c7148cbed@comcast.net> In-Reply-To: References: <20140921132548.d4ad54724473a2aeee688daa@comcast.net> <20140921143059.c3c16dfdeab6f65280b7caa6@comcast.net> <20140921192043.GA9652@crud> <20140921171301.5f008b3bd12c21c2f8fdd67e@comcast.net> <20140921202600.08d082d88014228172007477@comcast.net> X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.24; x86_64-unknown-linux-gnu) 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1411351378; bh=5PU3mLxADhEo3oi5ZggIB1VKrdotcgKDfpuBz1qMlLc=; h=Received:Received:Date:From:To:Subject:Message-Id:Mime-Version: Content-Type; b=HB5kuoubKP+d8oXaXE6U6uAFCQlZGUeTS+aMoVunXDQTVZel1TOCniVPXppRiRJBI PVSdfP8QO6K12sYtES1SFMhUOakOhwz27t4uM0uu4adh5sdU9fI4rAeWC1V10bohyc feUKgy2et9E6dZz3oK2vs6SJWKv7EUwB2TWmrNaOzU8JINN25RqI2+7VH2NWvCPt+H GRaxXJAC5EXJG8tHdvBdc/mEIoNFl1o6APB4jEg02sC5GIYB7bp4JEmIfzq4S4KVTs eG0AZ4QCTxA1BVt2wl2IZqQ1u98jfP8MFmp9+vvXvQtVeRDZlgKYyubRqKusXu8Vj9 3DX3KUipojeAQ== X-Archives-Salt: 4a2ad5ea-e5cc-4a8d-9c08-94f5999fdd12 X-Archives-Hash: fd118407c81c4871847bc914a625bc7a 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. > > 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. > > 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). I am not that familiar with systemd components, but it is not too unrealistic to consider many more applications in the future making at least some components mandatory. It is obvious that the Linux of 10 years ago is no longer appealing to many people and there will be mounting pressure to introduce changes just for the sake of having changes. If I have to adapt then I will certainly adapt, but it would be better to keep current options.