From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1069 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Vision for new platform Date: Sun, 10 Jun 2012 15:33:48 -0400 Message-ID: <20120610193348.GK163@brightrain.aerifal.cx> References: <20120610132246.GF163@brightrain.aerifal.cx> <20120610225226.137363d0@sibserver.ru> <20120610151311.GH163@brightrain.aerifal.cx> <20120610235125.31f38cd7@sibserver.ru> <20120610163359.GJ163@brightrain.aerifal.cx> <20120611015349.701fa061@sibserver.ru> <20120611022606.303f6d07@sibserver.ru> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1339357101 30656 80.91.229.3 (10 Jun 2012 19:38:21 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 10 Jun 2012 19:38:21 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1070-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jun 10 21:38:20 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Sdnxr-00046d-Jv for gllmg-musl@plane.gmane.org; Sun, 10 Jun 2012 21:38:19 +0200 Original-Received: (qmail 27850 invoked by uid 550); 10 Jun 2012 19:38:19 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 27842 invoked from network); 10 Jun 2012 19:38:19 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1069 Archived-At: On Sun, Jun 10, 2012 at 08:38:57PM +0200, Daniel Cegiełka wrote: > > The problem with systemd is that it is not only bloated > > all-in-pid-number-1 thing that depends on dbus, it *comes* from > > freedesktop, which reputation is not so good at software engineering. > > And udev is going to be merged with that codebase. > > And important thing: not to repeat already repeated mistakes. > > I understand that and instead systemd I prefer to stay with > sysvinit+openrc... sysvinit is really not a rational design. It does a lot of the same stupid stuff as systemd (controlling process lifetime from pid 1, but in this case it's only used for legacy console gettys, not for daemons). And runlevels never really made any sense to me; they just made init scripts a lot more complex and difficult to maintain by having to handle the additional case of switching between runlevels with different things in them and getting the order of stop/start right.. > but the only solution is to prepare a new init > stuff from scratch (systemd+udev+dbus alternative). Do you see another > solution? I think it's a mistake to think in terms of needing a replacement for X+Y+Z instead of needing a solution to problems A,B,C. Especially when X+Y+Z are poorly designed and it's not even clear what problems they were intended to solve. Let's instead start from the perspective of problems to solve: 1. Initiating/controlling the boot process. 2. Providing login prompts on console ttys. 3. Managing system daemons. 4. Handling insertion and removal of hardware. 5. Handling changes to hardware status. 6. Shutting down/rebooting the system. I'm generally of the opinion that trying to tightly integrate these (largely unrelated) tasks just creates a lot of complexity and lock-in with little or no benefit. In contrast, for problems #1 and 2, I have a 22-line (C) init program that does nothing but run the boot script and reap orphaned zombies, and a 34-line (C) program that repeatedly re-runs a program in a new session every time it exits. The latter, combined with a 14-line (shell script) getty program, is sufficient to handle all console logins. I hope this doesn't come across as a claim that ALL of the above tasks are trivial; indeed, they're not. But I think it is a motivation for highly factoring different tasks... Rich