:: Re: [DNG] Custom OS initiator. In n…
Startseite
Nachricht löschen
Nachricht beantworten
Autor: Steve Litt
Datum:  
To: dng
Betreff: Re: [DNG] Custom OS initiator. In need of some hints...
On Tue, 14 Jun 2016 05:44:27 +0100
KatolaZ <katolaz@???> wrote:

> On Mon, Jun 13, 2016 at 09:37:11PM -0400, Steve Litt wrote:
>
> [cut]
>
> >
> > Right now, Felker's PID1 is the acknowledged "Hello World" PID1.
> > But as I remember you have to add an #include to get it to work with
> > mainstream Linuxes, you have to get it to compile, and it's just
> > not as understandable to non-C programmers.
> >
> > Hackers who might not know C are more able to put their own commands
> > into the shellscript and see the result.
> >
>
> With all the due respect, anyone can put a few lines in a shell script
> or in a C code to create two devices and call rc. But we should be
> honest and tell Bartolo, and anybody else willing to go down this
> path, that this is not exactly "making a custom init", though, since
> what is normally intended as "init" needs to be a tad more complicated
> than that, if the intention is to make it useful outside a sandbox.


Not really. I'm pretty sure that runit is pretty much a Suckless Init
type PID1 spawning an rc file that runs a daemontools-like supervisor
system.

This is the whole point I've tried to get across to systemd
afficianados: It really IS that simple. IIRC I ran my Daily Driver
Desktop (DDD) for a couple days on Suckless Init PID1 plus a startup rc
file calling daemontools-encore, and a shutdown script I pretty much
made from scratch.

I have no doubt that a process supervisor isn't trivial to create, but
PID1 needn't contain a process supervisor: It can spawn a shellscript
that launches the supervisor.

SteveT

Steve Litt
June 2016 featured book: Troubleshooting: Why Bother?
http://www.troubleshooters.com/twb