Gilboa Davara wrote:
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.
Please, keep your pxe rescue. Just add /usr to it.
You say: If I must use a rescue CD, that everybody else must do it also.
Not at all. I'm all for flexibility, except when it encourages stagnation.
I'm saying we should move boot-time flexibility from /bin to initrd.
initrd is a fact of life in module-based kernels. By making it a little
smarter and more flexible, we remove a development bottleneck: the ban
on /usr (and C++, python, and a zillion other goodies) during boot.
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,
I want to reuse that effort. By writing in python I can concentrate on
the application, not the plumbing. The boot process is an excellent
candidate for python since it requires flexibility.
and most of your boot
process is in bash.
bash sucks as a programming language. it is impossible to write a
correct program with it.
even a simple
if proggy | grep -q something; then echo boo; fi
has three bugs in it.
and it's horribly slow. not bash itself, but forking/execing a new
binary every other line.
Somehow, I don't see Cpp project such as Mozilla, KDE and OO to show
better stability then the kernel that boots my machine.
Writing something like OO or KDE in C is masochism.
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!)
I guess python tracebacks with "your bug here" in the end aren't for you.
But we are going way-OT here.
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?
[root@blast ~]# time python -c 'print 1'
1
real 0m0.029s
user 0m0.016s
sys 0m0.012s
.028 sec overhead, and you can complete the entire boot process with a
single python instance (/sbin/init.py :) which stays around and monitors
your services.
I measured 'service network restart' at 1.4 sec cpu time. I'm sure it
can be reduces to 50ms or less in readable python.
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?
Most CDs are 700MB in size. Most networks have gigabytes or terabytes of
storage.
(And I'm sure it can fit into 50MB compressed image - the binary RPM is
20MB)
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!
You are ruining a perfect record of disagreement here.
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.
Well, you did say some words to that effect.
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/.
It's possible to write slow programs in any language. Usually the
problem lies with the algorithms, not the language. Writing in C makes
the algorithms more difficult to improve.
Consider that the boot sequence is really just a few hundred steps. All
that is needed (performance wise) is to hide I/O latencies and not
fork/exec every binary under /bin and /sbin. But there is a lot that is
needed in terms of features, and a high-level language is the easiest
way to achieve that.
(and of course boot should have text output, gui, and blinkenlights
plugins so every one of us can enjoy it in their own way)
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
