init: API

[Gilboa Davara]

On Sun, 2005-11-20 at 19:17 +0200, Avi Kivity wrote:
> >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.

My heart goes to your dwindling supply of neurons, but you-yourself
suggest I use a rescue CD to save my precious Linux.
I just followed suit.

I say: Use rescue CD if you want to, but don't force me to dump my
network-based BootPXE rescue image for that.
You say: If I must use a rescue CD, that everybody else must do it also.

> 
> 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).
> 

Should I remind you that your kernel and most libraries on that Python
coding machine of yours are build written in C, and most of your boot
process is in bash.
Somehow, I don't see Cpp project such as Mozilla, KDE and OO to show
better stability then the kernel that boots my machine.

I will accept that writing a kernel module in C is much more difficult
then writing a user-land application in Python. (But, on that other
hand, nothing beats spending your nights looking at meaning less oops
with trashed calling stack... Pure joy!)

But we are going way-OT here.

> >
> >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.

... And all of this just to add python with its 100,000 libraries to the
boot processes?

> 
> >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.

On my machine Python alone, is around 100MB, let alone required
libraries and dependencies.
How could I possibly stick that in my rescue image and/or BootPXE image?

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

I second that.
Actually, it'll be a good idea to create a RFE in the bugzilla.
Nice catch!

> 
> >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.
> 

I'm not trying to restrict boot  to bin.
I am trying to persuade against creating a GUI-only monster, that will
end up slower and 100 times more complex (and 100,000 times bigger) then
our current solution.

Speaking of performance, yum is dog slow, even on my dual Opteron
FC4/x86-64 workstation.
Compare that to apt-rpm, and you'll see why I consider a python based
service manager to be a /bad-idea/.

Gilboa