Linked by Thom Holwerda on Tue 22nd Sep 2009 15:34 UTC, submitted by google_ninja
During the roundtable discussion at LinuxCon this year, Linus Torvalds made some pretty harsh remarks about the current state of the Linux kernel, calling it "huge and bloated", and that there is no plan in sight to solve the problem. At the same time, he also explained that he is very happy with the current development process of the kernel, and that his job has become much easier.
Thread beginning with comment 385516
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
RE: Bloat != ABI problem
by nt_jerkface on Tue 22nd Sep 2009 20:00
in reply to "Bloat != ABI problem"
Member since:2009-08-26
For binary blobs which in existance, it's a minor problem to port their code to a new kernel release. In fact, no-ABI forces them to mantain it to support new OS features. Fortunately we have in-kernel drivers for most relevant hardware, minus some graphic cards.
And who really needs graphics cards anyways? When Linux is such a roaring success at 1% of the desktop market I can't believe that people still question the unstable abi approach. Hardware companies just absolutely love it and consumers don't mind waiting months for a driver to appear in the kernel. Did I mention how open source drivers are always high quality compared to proprietary drivers? There's never any missing functionality.
Now excuse my while I go fly my magical pony around the block.
RE[2]: Bloat != ABI problem
by CrLf on Tue 22nd Sep 2009 22:32
in reply to "RE: Bloat != ABI problem"
Member since:2006-01-03
And who really needs graphics cards anyways? When Linux is such a roaring success at 1% of the desktop market I can't believe that people still question the unstable abi approach.
Actually, who cares about Linux on the desktop? No matter what it's still stuck at that 1%. The real deal for Linux is, well, everything _but_ the desktop.
The kernel development model reflects this, and the reliability and performance on servers, and the flexibility on embedded devices, is the result. It is a success really.
Member since:2006-03-01
No stable ABI, please. When in-kernel ABI changes, there is a good reason. We don't nees only badly mantained or abandoned binary out-of-tree drivers that don't get modified for months/years to support e.g. power management improvements when a new kernel revision is released.
a driver shall be updated (meaning : the user shall have to update his installation of a certain driver) only when it exhibits stability, functional or performance deficiencies on the system it's designed for (assuming the same system doesn't show deficiencies with other drivers and devices, in that case the driver is not the culprit )
that's a tenet of sane os design (and sw design in general, since it has to do with correct code and data encapsulation and isolation) and that's how things are done on every os - except linux
It's not hard to keep up with linux driver ABI changes because improvements are incremental, tested each iteration and that way a few if any new bugs are introduced.
it's not hard to grasp the concept that the kernel project's license, and the way it's designed and structured are ORTHOGONAL matters, and having a stable in kernel ABI does NOT inherently keep drivers from remaining open source, either...
or, maybe one should assume that, since the system itself is -admittedly!- more a sw freedom promotion vehicle, needing only to "work" somehow, than a masterpiece of elegant top down sw design, that by the way happens to be free and open source - the above is a too difficult concept to grasp for advocates of such system?
In fact, no-ABI forces them to mantain it to support new OS features.
(paraphrase) in fact, no-abi forces users to upgrade the whole kernel, including external compiled drivers, when a new kernel relase with new features -related or unrelated to the i/o model and subsystem- appears and is shoved down the users' throats downstream
the driver code base could just be a separate project, or just a separate tree subfolder, from the kernel proper's code base
and although this may seem like a minor feat, it would make a whole world of difference for users and sysadmins (who can install kernel updates without fear already installed and working drivers need be updated too, nor) and also distributions (who don't have to backport drivers and features to the relatively stable kernel they em- and de- ploy )
Member since:
2006-01-17
No stable ABI, please. When in-kernel ABI changes, there is a good reason. We don't nees only badly mantained or abandoned binary out-of-tree drivers that don't get modified for months/years to support e.g. power management improvements when a new kernel revision is released.
It's not hard to keep up with linux driver ABI changes because improvements are incremental, tested each iteration and that way a few if any new bugs are introduced. For binary blobs which in existance, it's a minor problem to port their code to a new kernel release. In fact, no-ABI forces them to mantain it to support new OS features. Fortunately we have in-kernel drivers for most relevant hardware, minus some graphic cards.