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.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
