Linux Kernel 2.6.31 Released 374
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."
Linux audio (Score:3, Insightful)
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.
Re:IPv4 over Firewire? (Score:3, Insightful)
Re:i'd just like to (Score:3, Insightful)
There really is a Linux, and these people are using it, but it is just a part of the system they use.
And that part is exactly what is being discussed here.
Linux is normally used in combination with the GNU operating system: the whole system is basically GNU with Linux added, or GNU/Linux. All the so-called "Linux" distributions are really distributions of GNU/Linux.
Or more properly, KDE/Xorg/GNU/Linux.
Re:70% drivers! (Score:0, Insightful)
You have it backwards, we want more drivers, otherwise we'll go back to the days of next to nothing working for any device you pick off the shelves. Kernels are boring, once you have file systems, memory managers, etc, there's little to get excited about, and even then, it's all under the hood. Devices are what real users use.
Re:70% drivers! (Score:5, Insightful)
Comment removed (Score:5, Insightful)
Re:70% drivers! (Score:4, Insightful)
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).
Re:70% drivers! (Score:3, Insightful)
Well driver problems are the real problem with Linux. It always has been. When push come to shove comparing Linux with other OS's even the Linux Zealots admit that it is a driver problem. Most kernel features will not directly effect us like driver issues. Once Linux fixes its driver problems then it should focus on getting more features in... However in the mean time, the kernel should be improved on what the kernel is supposed to do Manage Hardware interface with software. And Drivers help with the hardware interfacing.
Re:70% drivers! (Score:5, Insightful)
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.
Re:Linux audio (Score:3, Insightful)
I agree but the situation is getting better and better. Pretty much every distribution has standardized on Pulseaudio and while it caused lots of problems in the beginning, and it still causes some problems on certain setups (especially with legacy, badly coded applications/games/emulators), it is a good API and it IS the future of Linux desktop audio, whether you like it or not. When this transitional period we are currently in is over, everyone will be much better off.
Re:70% drivers! (Score:3, Insightful)
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.
Re:Linux audio (Score:3, Insightful)
Yes, because userspace sound daemons were invented by ALSA. We didn't have these with OSS, not at all....
Re:Linux audio (Score:4, Insightful)
For some time Alsa was the "new tech". Now PulseAudio. By the time it stabilizes, there will be something else.
Re:Linux audio (Score:4, Insightful)
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.
Re:Linux audio (Score:5, Insightful)
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.
Re:Linux audio (Score:3, Insightful)
As I wrote above: 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 30-50ms latency will play through PA to JACK, at the same time even.
With the very latest versions of Pulseaudio combined with a realtime kernel (soon to be merged into the mainline kernel), Pulseaudio won't give you much latency at all. It also uses MUCH less CPU than JACK so it's much better suited for standard desktop needs. PA won't drain your laptop's battery, JACK will.
Re:70% drivers! (Score:4, Insightful)
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.
Re:70% drivers! (Score:5, Insightful)
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.
Re:Linux audio (Score:5, Insightful)
"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.
Re:Linux audio (Score:5, Insightful)
Re:i'd just like to (Score:1, Insightful)
GNU 1984 ->
Linux 1991 ->
KDE 1996 ->
Xorg 2004 ->
GNU started it all. It provides the philosophy, the tools and the license. Linux is just a nice milestone along the way.
An open source person calls it Linux, while a free software person calls it GNU/Linux. [gnu.org]
Re:Linux audio (Score:2, Insightful)
Is there a reason that we can't now back up this crashed truck and point it in the right direction? Obviously the current approach doesn't work, can't we go to Linus, say "hey, we tried it your way and got nowhere, can we do it right now?"
If doing sound mixing in the kernel is the "right way", then I hope Linus is man enough to admit his error...
Re:70% drivers! (Score:5, Insightful)
Re:Linux audio (Score:4, Insightful)
You don't need them with OSS on FreeBSD and Solaris (for example), or on Linux with the out-of-tree OSS 4 implementation
You don't need them in ALSA either, because dmix is implemented in the ALSA library, not as a userspace daemon.
It's amazing the increible amount of FUD that has been spread about these topics...
Re:70% drivers! (Score:4, Insightful)
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.
Re:70% drivers! (Score:3, Insightful)
Because he is. Everyone can't be expected to be running the same version of the kernel I'm not running 2.6.1, but I do believe that my home system is running 2.6.28. Tieing driver development to a specific kernel release is insane. Look at the hoops Nvidia has to jump through to get drivers out. On Windows I download a driver - it works. For the last 14 years we've basically had three groups of drivers - Windows 9x, Windows 2k/XP, and Windows Vista/7. Outside of those broad groupings a manufacturer could release a driver and have it work on most any computer. Linux drivers have to be recompiled for every kernel release. Very, very few manufacturers are willing to stay on that treadmill, and so we get stuck with reverse engineered open source drivers that fall short of what the manufacturers could usually write themselves (just compare the open source Nvidia drivers to the Nvidia provided ones).
I Love new kernel day (Score:2, Insightful)
Re:Linux audio (Score:4, Insightful)
A bit buggy under certain conditions, yes, but that will be fixed in the future.
Except this is the exact excuse we get countless times when audio, video, etc don't work in Linux. Just give us more time! We swear it'll work in the future! Then you wait 6 months and all that previous work is scrapped and something new is built. Then we're told again: Just give us more time! We swear it'll work in the future! Lather, rinse, repeat.
Re:70% drivers! (Score:5, Insightful)
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.
Re:USB 3.0: better than Windows 7 (Score:3, Insightful)
It's quite difficult to get decent performance from USB2, because the design of the host controller is such that the CPU needs to be involved in the transfer. If the CPU doesn't respond fast enough (perhaps because you're trying to do actual work with the machine), performance suffers. The problem is less with quad-core CPU's, since you can just dedicate a core to USB when doing transfers.
Firewire and SATA controllers can handle transfers pretty much on their own. Supposedly USB3 can do the same.
Re:70% drivers! (Score:3, Insightful)
It would also mean that drivers would be stuck on 32-bit x86. Great.
Re:70% drivers! (Score:4, Insightful)
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.
Re:70% drivers! (Score:3, Insightful)
Everyone can't be expected to be running the same version of the kernel
Why not? Upgrades are free.
Look at the hoops Nvidia has to jump through to get drivers out.
The only hoop they really need to jump through is opening their source.
Re:Linux audio (Score:3, Insightful)
Insane Coding's Insane Plan for Networked Audio (Score:3, Insightful)
The article you're probably thinking of is State of Sound in Linux Not So Sorry After All [blogspot.com].
Good article, but I've got to point out one really bad piece of misinformation this damn fool made...
"If users need remote sound (and few do), one should just be easily able to map /dev/dsp over NFS, and output everything to OSS that way, achieving network transparency on the file level as UNIX was designed for (everything is a file), instead of all these non UNIX hacks in place today in regards to sound."
<sigh> OK, let's break this down. First, you can't export a character device over the network via NFS. Or rather, you can export the character device file - but if you then attempted to write to a remote machine's /dev/dsp this way, you'd instead wind up writing to the local sound card.
Second, a naive approach like that doesn't do anything to manage the timing issues inherent with audio over the network. In some cases you don't care about latency but you do care about having the sound play uninterrupted - for instance, a "shuffle" sound in a solitaire game. /dev/dsp accessed over a network filesystem wouldn't do that for you - it would play part of the file as soon as it got it, and then, if too much time passed before it received the rest of the sound, there'd be dead silence in there. And then, consider the case of a video player: if a packet or two is lost along the way it's not a big deal, but what you care about is that packets are played in the order that they're intended. You need to strike a balance between latency and packet loss. /dev/dsp over the network isn't going to do anything like this for you, as all the packets are likely to go via TCP.
It's true that most people probably don't need network-transparent audio anyway (I don't) - but suggesting shipping out /dev/dsp over NFS is just brain-dead...