Slashdot Mirror
Linux Kernel 2.6.31 Released
diegocgteleline.es writes "The Linux kernel v2.6.31 has been released. Besides the desktop improvements and USB 3.0 support mentioned some days ago, there is an equivalent of FUSE for character devices that can be used for proxying OSS sound through ALSA, new tools for using hardware performance counters, readahead improvements, ATI Radeon KMS, Intel's Wireless Multicomm 3200 support, gcov support, a memory checker and a memory leak detector, a reimplementation of inotify and dnotify on top of a new filesystem notification infrastructure, btrfs improvements, support for IEEE 802.15.4, IPv4 over Firewire, new drivers and small improvements. The full list of changes can be found here."
there is an equivalent of FUSE for character devices that can be used for proxying OSS sound through ALSA
That quote shows how much of a train wreck Linux audio is.
Enhancements should come as a part of the OS, not the kernel. The main function of a kernel is to get along with all the hardware devices on the system. Drivers should be given a high priority.
Face your daemons!
I personally think this is a real pity. So much time is being spent on getting drivers implemented that new features and other kinds enhancements are being pushed back.
I would assume that the people writing drivers and the people doing core stuff are not the same people, so there's no "pushed back". Ideally you'd have driver writers employed by all the various hardware manufacturers, while core stuff likely only interests a much smaller group of companies that live higher in the stack (probably just system and support vendors).
What evidence have you got that suggests driver development means other development is pushed back? Do you think the EXT4 developers take time off to write device drivers?
Lots of driver development means Linux has lots of driver developers. That probably suggests that hardware manufacturers actually try to get their stuff supported.
Great - now if I compile these lovely drivers will they work on my buddy's (or more importantly, a user's) system running kernel 2.6.1? 2.6.22? 2.6.31? 2.4.5?
Dividing the source and binary out into separate files doesn't make it modular. The infrastructure to move the binaries around needs to be in place so that a driver can be loaded with little regard as to kernel version.
"People who think they know everything are very annoying to those of us who do."-Mark Twain
I'd argue that drivers should be modular and have no business being directly in the kernel in the first place - but that's just me.
I don't anyone ever argued that drivers should not be modular, in fact that's why there's kernel modules. I'm guessing you're talking about one of the two general flamewars:
1) Monolithic kernel or microkernel
2) Stable ABI for drivers
The first is about making the kernel into a big message-passing daemon, which it turns out has a performance penalty and ultimately doesn't have big enough benefits because a kernel panic and a major subsystem hang/crash both are ugly and if the hardware is left in a borked state it might not really help.
The other is a stable ABI, which has been suggested about 234,533,458 times to date. My only real comment to that is that seeing how crappy many Windows drivers are, do you honestly want them making blobs for a 1% operating system which will get about as much priority, support and bugfixes? Drivers based on specs or donated source almost always suck less.
Live today, because you never know what tomorrow brings
Keeping binary compatibility limits infrastructure improvements that can be made. You're limited in what you can do to the kernel because of drivers that are sitting out there that expect binary compatibility. If we have drivers that can be loaded with little regard to the kernel version, we get into the quagmire that is Windows, where devices over 7 years old have a low chance of working. My scanner hasn't worked in Windows since XP SP1. It still works perfectly in the brand-spankingest new Linux distros.
My blog. Good stuff (when I remember to update it). Read it.
Far more likely is that companies will behave exactly like they do in Windows - not bother updating their drivers for new versions. There is a lot of old hardware that simply doesn't work in Vista etc because there's no incentive for the company to fix the drivers.
Whereas if it's in the kernel, all the drivers can be fixed at the same time.
Insightful?! You couldn't be more clueless.
How do you propose to fix the driver problem? The only way that gets fixed is when every hardware manufacturer writes their own drivers. That would only happen if Linux attained something like 10% market share.
In recent history (the last year or two) the majority (50.1-60%) of all commits to the kernel are drivers/driver update.
Also you forget that there isn't some company that dictates what work gets done on the kernel. There are many developers who work on areas they are want to work in. Are you telling me that linux should reject the FS brtfs because there is a non-name piece of hardware that isn't working yet?
Most kernel features will not directly effect us like driver issues.
Wrong again, My new hardware which I bought off newegg last week works fine in linux (yes I do a quick google search to make sure anyone isn't bitching about something major not working, but anyone who uses linux knows to do that). Because it works, any feature such as a file-system, scheduler improvement, or desktop memory management in low memory situations will improve my experience much more than adding a driver that I won't ever need or use.
That would make it easier to manage as the number of them increases.
One of the great advantages of Linux is that improvements can be implemented for lots of devices at once.
I guess a lot of manufacturers will release binary-only drivers, but even if they are buggy, that doesn't leave in any worse state than we are already - those manufacturers aren't releasing drivers for Linux in the first place.
It means people will look at the packaging, notice that it says Linux support, and then find out that it doesn't actually work, and will then blame Linux. Manufacturer-written drivers are fairly universally crap.
Finally! A year of moderation! Ready for 2019?