The Increasing Size Of The Linux Kernel

[DeepDayze]

I didn't explain it well enough. You'd have a core tarball that everyone needs, and then tarballs for individual drivers, or driver sets, that you could download as needed for your machine or architecture. It would be not unlike what binary distros do already with separate RPMs for modules.

Precisely what is meant

[amphigory]

It would be a pain in the ass having separate tarballs. No thanks. I well remember the days of building separate modules (Atheros (madwifi) or Prism54, etc) and do not miss them. Having the kernel and drivers in one tree makes things much easier.

[Ex-Cyber]

I'm not sure how you'd get useful granularity with multiple driver tarballs. It seems like no matter how you split it, you'd run into the problem of "80% of the users use 20% of the code, but it's never the same 20%".

[leeenux]

Ah, the joy of statistics.

I don't care if the sources hit 1GB, to be quite honest. I'll take the increase in size to mean that they've been busy fixing the various shortcomings the kernel has had over the years, and adding support for even more oddball architectures I'll never use.

The size of a compiled and packaged kernel still tends to be between 1MB and 100MB depending on what you've included. Come and alarm me when a compiled kernel hits 100GB and I no longer have the hard drive space to install it.

[yogi_berra]

Also, if the kernel developers go for amd64 only, then we'll be back in the internet-less world, since Linux won't support that MIPS processor in your modem and router anymore.

Linux doesn't have to support MIPS, busybox has to. There is no reason, beyond sheer laziness or incompetence, that the busybox people can't role their own code for MIPS.

[siride]

I'm not sure how you'd get useful granularity with multiple driver tarballs. It seems like no matter how you split it, you'd run into the problem of "80% of the users use 20% of the code, but it's never the same 20%".

Any given user, however, would only need to use a small part and thus would only need to download a small part. That's for the hobbiests who actually need to download the kernel source, and distros to build their own binaries. For most end-users, this is entirely a non-issue.

[chenxiaolong]

MIPS isn't i386. and also you don't count the drivers from old i386 only hardware.

be sure its more than 8mb.

i don't call for deleting all 32bit stuff only the intel 32bit stuff.

Got it Thanks for clarifying.

[chenxiaolong]

Linux doesn't have to support MIPS, busybox has to. There is no reason, beyond sheer laziness or incompetence, that the busybox people can't role their own code for MIPS.

But BusyBox requires the Linux kernel to run right?

From the busybox about page:

To create a working system, just add some device nodes in /dev, a few configuration files in /etc, and a Linux kernel.

From the serial console on my router, I see that the kernel boots and then BusyBox loads later in the boot sequence. I don't quite understand how the kernel can boot if it doesn't support MIPS.

[mrugiero]

I can't really see the problem with the size. It's 100MB, anytime you see an HD movie online you download at least 400MB.
You don't usually compile the kernel everyday, and if you do, it's more useful to just clone a git repo and pull everyday, and that way the download doesn't take that long.
And about the hard disk space, with a 1TB drive (which is not that unusual right now) I can't see how 1 or 2GB of uncompressed kernel could be a problem.

Cutting features and dropping drivers to get more advanced capabilities is one thing, and I support it in mesa even considering I use an Unichrome IGP in one of my boxes, but cutting it just because 100MB sounds big, is another thing.
I think it's a pretty bad idea.

[Cyborg16]

The other way of looking at this data is that version numbers increase logarithmically with respect to time... right?