[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120610193348.GK163@brightrain.aerifal.cx>
Date: Sun, 10 Jun 2012 15:33:48 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Re: Vision for new platform
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
