On Wed, Oct 17, 2012 at 6:58 PM, Richard W.M. Jones <rjones(a)redhat.com> wrote:
On Wed, Oct 17, 2012 at 05:59:55PM +0200, drago01 wrote:
> On Wed, Oct 17, 2012 at 5:46 PM, Matthew Miller
> <mattdm(a)fedoraproject.org> wrote:
> > On Wed, Oct 17, 2012 at 05:38:55PM +0200, drago01 wrote:
> >> > Basically: it's hard,
> >> it is a mess.
> >> > but the only way we're going to get to a
> >> > reasonably-small minimal image,
> >> not true.
> >
> > Given that the kernel is currently a full quarter of the current image, I
> > think it has to be.
>
> No you could also use a different kernel image;
> build your own kernel;
[I'll treat these two the same, because they amount to the same thing]
No the one means we ship a kernel-foo (like kernel-minimal or whatever
we call it) and the other is you build your own kernel.
It's a considerable amount of work for everyone if people
building
minimal images have to use a different kernel.
If it is all about using kernel-minimal (or whatever it is called)
instead of kernel there is no extra work for the ones that build
minimal images at all.
By using the same kernel as everyone else, it means that bug reports
against the normal kernel package are relevant, and it means that the
regular kernel gets more testing.
They can be built from the same srpm (same version, same patches
applied just some modules stripped).
Also it's a lot of work to compile another kernel, when we've
already
got a team of (apparently 3) people doing this.
I'd argue it is less work then building a subpackage for every kernel module.
> use a compressed filesystem,
Every minimal image I've ever seen has been compressed to the max.
The image itself might be the installed system isn't ... which is the
think I was talking about (i.e this would allow you to save disk space
after installation).
The smaller image would just save bandwidth for the initial download
and/or space on mirrors.
> don't use a kernel at all and some
> container based approach instead of full virt for your cloud instances
Unfortunately containers don't work for every application out there.
Obviously *if* you can use a container, then you should, and you
probably are already.
That might be true but I can't think of such applications right now.
Couldn't the applications you have in mind be modified / fixed to work
in such an environment?
> Outside of the cloud use case the disk space added by modules
and
> firmware does not matter a bit (so I am ignoring this cases).
It's partly disk space, it's more often the time taken to copy these
images over the network (eg. when users download minimal images, or
when they are PXE-booted).
In that case you should place the image on your internal network. I
doubt anyone uses a cloud infrastructure where you download the images
over the internet using a 56k modem.
> So there are lots of other ways to achieve what you want without
> splitting the kernel into hundreds of sub packages.
I don't think we're talking "hundreds" of sub packages. Most people
seem to be discussing a split into between 2 and 5 packages.
People where talking about splitting each module ("driver") into its
own package. This are far more then 5.