modules, firmware, kernel size (was Re: systemd requires HTTP server and serves QR codes)
skvidal at fedoraproject.org
Wed Oct 17 16:54:48 UTC 2012
On Wed, 17 Oct 2012, Dave Jones wrote:
> On Wed, Oct 17, 2012 at 05:59:55PM +0200, drago01 wrote:
> > > 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;
> > use a compressed filesystem, don't use a kernel at all and some
> > container based approach instead of full virt for your cloud instances
> > (you could even base them on a btrfs subvolume and save more space
> > that way).
> > 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).
> > So there are lots of other ways to achieve what you want without
> > splitting the kernel into hundreds of sub packages. So while it is a
> > way it is not "the only way".
> As reluctant as I am to introduce new kernel packages, an ultra-minimal
> kernel package for use in cloud environments may make more sense than
> splitting up the one-size-fits-all packages into hundreds of sub-packages.
> But even this option is a lot of work, and isn't a panacea.
> With virtualised environments supporting pci/usb passthrough, where do you
> draw the line on what hardware to support in a hypothetical kernel-cloud package ?
You don't. More importantly I think the goal of shrinking the minimal
install is a bad one. We're chasing a size that is better suited by custom
spins or specific cloud installs. It should not be a goal of a
distribution provider to crreate something custom tailored for a specific
More information about the devel