Re: initrd on installed kernels
-------------------
> On Wed, Jun 23, 2004 at 10:21:23PM +0200, Thibaut VARENE wrote:
>
> Well, we almost reached 4Mo of compressed kernel image on powerpc
with
> the non-initrd thingy, and it broke on some subarches (like prep).
So
> there is obiously a limit to the non-initrd kernels.
agreed, though "it used to work".
>
> Maybe you just need to build your own non-initrd kernel, don't you ?
You
> just take the kernel-source and config of the debian kernel,
> unmodularize what you know you will want (mostly filesystem and ide
> modules probably) and build the resulting kernel.
Very "user friendly" indeed.
Of course I can (and I do) build my own custom kernel (without
initrd).
My point is that I was switching a friend from MSWin to Linux (which
is quite nice already), and I didn't want to get him into the pain of
having to install a complete toolchain and learning how to build his
own kernel in order to be able to update it when needed (in particular
for security reasons).
That was pretty interesting to me, because that friend is a complete
newbie to the *nix world, so I could gather interesting remarks about
what's intuitive and what's not, btw.
I was pretty happy that the stock woody kernel (2.4.18-bf24) was
working find and loading fast, but I was quite bothered (and so was
he) noticing that after apt-get installing 2.4.26-686, the box boot
was significantly slowed...
RE Jens' mail: the initrd used is the stock one, I didn't change
anything (yet).
If you consider the fact that he switched because he was tired of the
slowlyness of MSWin (and the virus stories), boot speed is quite a
point for a "basic" user who doesn't keep its box running when he
doesn't use it (read: boots several times a week, if not a day).
I do agree that having tons of unused drivers builtin isn't a Good
Thing, but I was wondering whether some kind of compromise between
what we had (non-initrd, "quick" boot) and what we have (initrd,
"slow" boot) could be found.
I thought that this "real end user experience report" might be of any
use to us kernel hackers/packagers.
HTH,
Thibaut VARENE
PA/Linux ESIEE Team
http://www.pateam.org/
Reply to: