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."
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!
amen. OSS, alsa, pulseaudio, for christsake just give me sound that works without having a million handler processes.
OSS was okay.
Good people go to bed earlier.
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.
What bothers me here is that I read "Oh, change this, do that turn this knob and sound will work for you." Then it works until there's a new kernel update (I use Ubuntu) and it breaks again. Or it just stops working after too many applications use it.
Then you read how fabulous PulseAudio is and how wonderful it is, but it just plain does not work. By working, it should work every time, all the the time without knob turning. It's embarrassing that in this area, Windows 95 is superior to Linux in almost every respect.
All this effort is put into chrome polishing the kernel for faster SMP with 64 CPU systems and the dang box can't even play music without having some sort of brain failure.
PA is for desktop audio. For pro audio production you'll run JACK and have PA output its audio to JACK instead of directly to ALSA. That way your pro audio apps will get their super low latency and all of the apps that can get away with 50ms latency will play through PA to JACK. You get the best of both worlds.
My other account has a 3-digit UID.
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
"Pretty much every distribution has standardized on Pulseaudio" is the very definition of regress. What you said was getting better and better? I installed Debian unstable on my laptop, with KDE desktop, and it also installed and enabled this trainwreck called "PulseAudio", which serves as only purpose to disable the audio of an already working system. Sound has worked for me in Linux since forever, never had any problems with it until PulseAudio came around.
During the early days I had been using a sound card with hardware mixing. Back then even Windows wasn't coping well with several streams and a card supporting only one, so what OSS offered back then was good enough for me, and on par with other operating systems. Then came ALSA, which offered dmix and dsnoop to do it software. Now, dsnoop has never worked for me, but I don't know any other operating system that supports such a feature so I guess I don't have much ground to complain.
Then PulseAudio came around, and that is the first time when I had any problem with sound on Linux. Sound started to be skippy, jumpy, choppy, and not working in some applications. Why would anyone think that PulseAudio would be a good idea? Now, don't get me wrong, I like PulseAudio, I even use it for some tasks. Namely playing music from my laptop on the soundcard of my desktop. But thanks to the brilliant idea that PulseAudio should be used everywhere I couldn't really do that anymore, because I had to eradicate PulseAudio to have sound again, so I couldn't use it for *my* needs. Fuck me.
Disclaimer: I'm not sure I'm chronologically correct above, the sound might have been in a better state in Windows than in Linux during OSS times, I just mean that I was already used to being able to play only *one* sound at a time when I first came to use Linux, so it seemed pretty normal thing to me.
OSS 3 did on FreeBSD too. It's not a technical limitation of the hardware or the interfaces, it's a symptom of the NIH mentality on Linux. FreeBSD has supported software sound mixing with OSS since around 2000. I you want to play sound, just open /dev/dsp and write data there (on FreeBSD 4 and earlier you had a different device node for each virtual channel, so you needed to tell xmms, aRts and so on to each use a different one, with 5 and later the kernel does this for you). The problem with Linux sound is that, when 4Front decided to make the next OSS release proprietary, they decided to deprecate it in the kernel, rather than just maintain the open source fork. The FreeBSD folks kept developing their version and adding features, maintaining parity with the proprietary version. Now OSS4 is open source it's merged into OpenSolaris and FreeBSD has pulled in the relevant features ALSA looks both dated and nonportable, but the Linux devs have invested a lot in it so they don't want to throw it away.
I am TheRaven on Soylent News
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.
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.