Linux the Kernel

When the Kernel went from 2.4.x to 2.6.x we saw a huge jump in the size of the sources. Of course a compiled kernel can be any size the compiler thereof wants it to be beyond the basics that get a usable kernel.

But, not only did the sources size change. Under the hood there were lot of other major tweaks like various sub systems.

As the Linux kernel has grown in size so the complexity of it has grown exponentially. And with complexity comes more and more errors. We can see this, given arbitrary hardware, if we compare kernel 2.4.x against 2.6.x compile time errors or kernel OOPS whilst running.

Given that we _need_ the kernel to grow because 1) We have more users of it now, 2) There is more hardware available now 3) 2*1 = more sources. All well and good. However, as good for Linux based operating systems as that obviously is it comes at a price due to ever increasing code complexity which creates errors/warnings at compile time and kernel OOPSES at run time.

As modular as 2.6.x kernels are, or rather can be, I think we, or rather the kernel coders, can take this modularisation further by splitting off basic kernel functions and hardware functions. I will admit my knowledge in this area is severely limited but that said I am sure this can be done.

What exactly am I talking about? The kernel, which _is_ linux, is the heart of all distributions. Without it distributions would neither function as we know them now nor indeed exist (witness GNU herd) but a radical rethink on how we perceive it is not only due but overdue.

As it stands now to get the latest all singing all dancing kernel sources one must:

1) download a huge archive.
2) build it. Assuming one knows their hardware and general requirements one can then build for oneself a new all dancing all singing kernel.

As far as it goes this is all well and good. But, the first step in that process is were changes could be made. Instead of downloading a huge archive one could:

1) download an archive of just the basics that enable the kernel, once built, to function.
2) Then one could download the various hardware sources, that would be split up into individual archives

As an example. On my main desktop workstation I would:

1) Download an archive of the basic kernel
2) download the driver for my SCSI hardware
3) Download the driver for my VIA hardware
4) Download the driver for my SATA hardware
5) Download the NetFilter sources

And so on.

All archives would extract to linux-2.6.x as they do now. Once everything has been downloaded then the configuration and build process can be done.

I know this all sounds more complex but the idea is to make the main kernel archive smaller and thereby hopefully make gcc spit out less errors/warnings and kernel OOPES less likely.

Oh how laughable!

In other blog posts here and here I have derided new, new as in springing up on the Slackware scene in the last 2-3 years, Slackware users for their attitudes. So, it was with much laughter I saw on one web site "Approved by..." as if that approval means anything to anyone except the person who deems him, or her, self important enough to give it.

I mean. Who gives a rats arse if some web site administrator deems him, or her, self important enough in the Slackware world that he, or she, gives his, or her, approval to something someone else has done.

What the fuck is that all about huh? Approval? Eh?

This particular web site administrator bursts onto the scene a couple of years ago pimping his web site at every given opportunity. Even today he pimps and pimps and pimps o such an extent that it is bloody annoying. Up until the time he came on the scene no-one had heard of the guy and now here he is giving his approval for something that someone has taken from elsewhere, adapted to fit in with this guys way of doing things then he deems it okay by giving his approval to it?

I do not give a flying one and I strongly doubt many long time Slackware users do either for his approval and that is why I will never, ever, submit anything to that web site even though I have hundreds of scripts that would expand his web site a hundred times over. I will never, ever submit anything because:

1) I don't like the way the his scripts are designed and I will not change my scripts to suit.
2) I don't need anyones approval to know my scripts are suitable for the purpose they were written and
3) I seek approval from no-one.

Damn Americans, not all of them obviously, seeking to dominate everything they touch. It does my head in it does and it is totally, utterly and laughably laughable in the extreme.

Emulation.

Or as the wine blarb goes "Wine Is Not (an) Emulator". Which is certainly true of both the Wine project and the Qemu project. Both can use full blown MS Windows installs and that is where the problem lays. As GNU/Linux adoption via a collection of a kernel and several applications commonly known as distributions continues almost unabated we have wine and Qemu which in my honest opinion are fighting the good fight and slowing down Linux adoption in several areas. How and why are wine and Qemu slowing down Linux adoption? Well, the answer to both questions are basically the same. Because people who install a distribution then go on to install wine and/or qemu and then go on to install MS Windows within one or both of those and then go on to install whatever MS Windows application they see as being unavailable under their choice of Linux based distribution are simply stopping the improvement of applications in the same field from growing as the good folks who create these programs don't see the need to create further as people who use wine and qemu are settled on whatever application they used under the MS Windows operating system. And that is the why and how answered. If only these people who dogmatically insist on using applications designed for another operating system on their distribution of choice used whatever search engine they prefer, or look at web sites like this one which shows The table of equivalents / replacements / analogs of Windows software in Linux they would see that in almost every single case there is an equivalent application that runs natively under a Linux based operating system. They could then remove the baggage known as wine and qemu and quite possibly at the same time have a more stable system.