init: API

[Avi Kivity]

Gilboa Davara wrote:

>On Sun, 2005-11-20 at 18:32 +0200, Avi Kivity wrote:
>  
>
>>I object. This requirement will keep us in the 1970s forever. It has 
>>already inflicted enough damage in forcing untold millions to learn vi.
>>    
>>
>
>Don't want to lean VI?
>Get a knpppix rescue CD and use what-ever-GUI-editor-you-like.
>Nobody is forcing you.
>  
>
You're forcing me to /bin during the boot process. I already wasted some 
of my dwindling neuron supply on that excuse for an editor.

>I am asking that you don't blow thing up just so you can enjoy that
>GUI-editors of your more.
>  
>
What about the other gazillion of thing in /usr? I want to use them in 
my boot process, so I don't have to write it in C or bash (what a pair: 
one runs fast bu produces buggy code and is slow to develop, the other 
is fast to develop but is very slow, and is even more buggy).

>  
>
>>This distinction between /bin and /usr/bin is completely artificial. If 
>>initrd (or whatever) was able to find our /, it should be able to find 
>>our /usr.
>>
>>    
>>
>
>Umm?
>A. Who said that both / and /usr are on the same partition? (Or on the
>same machine for that matter?)
>  
>
I sure didn't.

initrd can mount / from local disk and from the network. Surely it can 
be extended to mount /usr from another partition or from another server.

>B. I usually create a backup of /bin and /sbin inside my /boot which
>usually sits on the separate software RAID1 partition, while my main
>root is partition(s) are on a RAID5 software raid with LVM. I assume
>that I'm now forced to create a full backup of my /usr just so I can get
>the service manager to work in case of disaster?
>  
>
Put the rescue image into some partition. It's a bit more space, sure, 
but still very small compared to disk sizes.

Hey, that might be a good idea for the installer.

>There's more at stake here then the configuration file itself.
>In my view, the service manager should be simple, bash-based (if
>possible), and fully contained within /bin (initrd-able is even better).
>  
>
The problem is that this type of solution is development-intensive, 
which leads to fewer features and more bugs. C isn't very suitable for 
this sort of thing.

>You (as in "XML-people")
>
Actually I'm python-people. I don't have a strong preference for XML.

> want to create a monster, with XML parsing
>libraries, GUI, and god-knows-what, that may (or-may-not) improve
>performance. In essence, you are about to create a Windows like service
>manager.
>I'd suggest you re-read my first statement on why Microsoft's service
>manager sucks.
>  
>
Learning from their mistakes in fine, but that has nothing to do with 
restricting boot to /bin.