[ltp] Linux kernel instability? (Rant/Panic/Cry-for-help!)

[Christoph Lechleitner]

Richard Neill wrote:
> Dear All,
> 
> I'm just wondering - am I just unlucky, or has the quality of the Linux
> kernel nosedived in the last 6 months?

I totally agree!

The first really bad thing was 2.6's lack of support for passive ISDN
cards and some other rock solid, useful, legacy hardware.
The kernel seemed stable up to 2.6.18, though.

>From 2.6.20 it got ugly.
Lots of half-finished filesystems, virtualization interfaces,
schedulers and other stuff have been introduced with every release.

More annoying, somewhere along the line 2.6.20 introduced some locking
problem with some dependency on timing, (W)LAN/disc/GPU/PCI load,
multicore CPUs, ..., and it was soon "supported" by bad GPU and LAN
drivers, bad ACPI and PCI/PCMCIA/... and USB implementations, buggy
hardware and so on.

Unfortunately, with the new fast development cycle (far too fast I
believe), it seems more and more impossible to get complicated problems
fixed (complicated as in highly situation dependend, interdependend,
difficult to reproduce or track).

Other open source projects seem to share that way of killing good
features and quality along the introduction of damn eye-candy and the
like: KDE, Firefox, OpenOffice, sound support, multimedia support,
64-bit support, Java, and others all evolved in similar bad ways.

So do ThinkPads - my current 1-year-old T61p still has problems I never
had with any of my prior 3 ThinkPads over almost a decade.

But perhaps we are lucky and kernel 2.6.27 becomes a turning point for
the better. Three facts around 2.6.27 give me hope:

1st, the locking problem seems to have been fixed, at least for most
users affected. This is according to reports in Ubuntu's launchpad.

2nd, a whole group of major distributions will (try to) use 2.6.27 in
their upcoming releases.

3rd, the current intel LAN debacle (don't even think about using
2.6.27-rc* if you value your Intel LAN card) really should finally shake
up all people involved with kernel development and force them to find
new ways to increase kernel quality to what it was from <1.0 up to 2.4
or perhaps even 2.6.18.

I think kernel development should be slowed down considerably to like 12
months per cycle, and all distributors and major hardware manufacturers
should invest vast time in testing and fixing every single kernel
release for at least 9 months, better more.
The same applies to new hardware, which should be tested _before_
becoming GA. Of course the kernel interfaces should become much more
stable and it should be made easy for hardware manufacturers to support
new hardware on all kernel releases already in the wild.

Perhaps the kernel should become far more replacable, i.e. the
kernelspace/userspace binary interface should be stabilized to a point
where one can switch between Linux, Solaris and BSD kernels like one can
switch text editors, browsers, mice, monitors, TV channels ...

Momentarily however, PC-BSD and even Windows, Mac OS and Solaris keep
smelling more interesting on a daily basis.

Kind regards,

Christoph Lechleitner