Forgot your password?
typodupeerror
Operating Systems Linux

Linux Kernel 2.6.31 Released 374

Posted by CmdrTaco
from the download-compile-reboot-repeat dept.
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."
This discussion has been archived. No new comments can be posted.

Linux Kernel 2.6.31 Released

Comments Filter:
  • by Anonymous Coward on Thursday September 10, 2009 @08:59AM (#29377307)

    Windows 7 will ship without USB 3.0 support [cnet.com].

  • by DavidpFitz (136265) on Thursday September 10, 2009 @09:06AM (#29377373) Homepage Journal

    I have yet to see a Firewire device and only have seen a few PCs with Firewire ports.

    You've never seen a MiniDV camera, then?

  • by uhmmmm (512629) <uhmmmmNO@SPAMgmail.com> on Thursday September 10, 2009 @09:14AM (#29377473) Homepage

    I haven't looked at the official changelog or the code yet, but I'm just as confused as you about that item. Moreso perhaps, as I have used IPv4 over firewire with two linux machines before. That was probably 5 years ago or so.

  • Re:70% drivers! (Score:4, Informative)

    by walshy007 (906710) on Thursday September 10, 2009 @09:21AM (#29377541)

    Not really, the driver people aren't really the same as those who would be researching new and exciting ways to do what we already do. For quite a long time now driver development has been the majority of what the linux kernel development is.

    Of course, every now and then they make something new like mac80211, but all that really achieves is more efficient code re-use and testing, which is always good but is still just driver development.

    All the simple things an operating system kernel has to do hasn't changed over the last ten or so years, just the hardware has. Operating system theory was pretty much perfected back in the 60's

  • by Anonymous Coward on Thursday September 10, 2009 @09:23AM (#29377563)

    From the changelog

    *The new firewire driver stack is no longer considered experimental, and distributors are encouraged to migrate from the ieee1394 stack to the firewire stack
    *Added IP networking to the new FireWire driver stack

    It does add up. It's just added to the new stack, old stack has it already.

  • Re:70% drivers! (Score:4, Informative)

    by Anonymous Coward on Thursday September 10, 2009 @09:28AM (#29377611)

    The fact that, with a modern Linux distro, I can plug in pretty much any hardware at least a year old and have it just work no questions asked is a pretty damn spiffy feature.

  • by Anonymous Coward on Thursday September 10, 2009 @09:40AM (#29377777)

    USB is not a multi master bus like FireWire, you'd need special hardware between each of the computers usb ports in order to even begin to do any networking. By that point you might as well just go and get a crossover cable and a few NICs (assuming said computers have none).

  • Re:Linux audio (Score:5, Informative)

    by bcmm (768152) on Thursday September 10, 2009 @09:41AM (#29377793)

    amen. OSS, alsa, pulseaudio, for christsake just give me sound that works without having a million handler processes.

    So just use ALSA!

    The situation on Linux is that there used to be OSS, and now there is ALSA. ALSA works fine, for pretty much everybody. There are a few legacy apps which use OSS because no one is updating them, and obviously, it would be nice if they would play nice. Pulseaudio is a bit strange, but nothing requires it's use, and IMHO there is no real reason for it to be used unless you want to do somewhat strange things (that you generally can't do on any other type of OS). Don't use pulseaudio if you don't want to; if your distro forces it on you, use a sane one.

    This scary graph [adobe.com] and related ideas tends to get mentioned in connection with this: this conflates libraries, sound servers, and drivers to some extent. One could draw a similar graph for windows, featuring programs using the Quicktime library, the WMP library, MME, DirectSound, WASAPI and various other APIs and libraries (and I haven't even gone into the changes to the audio driver model). WMP would have plenty of in arrows from applications using its libraries, and plenty of out arrows because it supports more than one API. And don't forget that there are still legacy applications which need to be the only app playing audio, just like on Linux.

    Here is why I can't be bothered to learn enough about the driver layer to give examples: "UAA is intended to be a complete replacement for developing WDM Audio Drivers; however, in some cases it may be necessary for an otherwise UAA-compliant audio device to expose capabilities that cannot be done through UAA. Windows will continue to fully support audio drivers that use the PortCls and AVStream drivers. [wikipedia.org]

    Audio technology has evolved, lots. Having backward compatibility requires that things get slightly complex. Everybody is doing this. I think Linux is doing it rather well, although certain distros make some odd choices.

    OSS was okay.

    OSS made it impossible to play more than one stream at once on a lot of hardware.

  • Re:Linux audio (Score:3, Informative)

    by walshy007 (906710) on Thursday September 10, 2009 @09:47AM (#29377839)

    OSS was okay

    It really wasn't, depending on your needs of course. If oss were good enough alsa would not have been invented.

    Pretty much all cards are handled by alsa in the kernel back end of things, that is pretty standardised etc, the whole problem is the sound server or userspace demon that handles mixing and other bits. PulseAudio was a band aid with horrible latency, Only professional apps tend to support jack. aRts and esd at least seem to have died out when most popular kde and gnome distro's both went to pulseaudio though.

    But more or less, nothing in the kernel will fix sound, it's a userland problem.

  • by Lemming Mark (849014) on Thursday September 10, 2009 @09:52AM (#29377923) Homepage

    Before we all moved on to worrying about PulseAudio it was traditional for us to complain about legacy apps using OSS, the difficulties associated with wrapping them, the nastiness associated with OSS emulation being implemented in the kernel, etc. Those apps won't have gone away.

    Previous attempts to emulate OSS using ALSA have included the aoss tool, which I believe did some mildly ungodly tricks to intercept calls that would usually go to the OSS APIs. It didn't always work, for me, as it depends on what the (often weird and proprietary) app is doing to access the OSS API in the first place. PulseAudio has to provide a tool to help you redirect legacy OSS apps to talk to PulseAudio instead. It's all Made Of Ick.

    CUSE (character devices in userspace) allows a userspace program to provide a character device node in /dev and implement it using custom code, rather than relying on an in-kernel driver. When apps open the device node they'll *really* be talking to the userspace daemon implementing the device emulation, rather than to an in-kernel driver (though, of course, the kernel will be involved in relaying the communications through the device interface). This is very similar to what FUSE does for filesystems. The neat thing here is that weird tricks to catch OSS accesses by applications are not needed - the OSS device can simply be "faked" by the real sound daemon. Because it's implemented at device level, it doesn't matter what nasty hacks the OSS application is doing to access the soundcard - you'll *always* be able to grab its sound output from the fake device and do the right thing. No more running legacy apps with an OSS-related wrapper - and no more having the wrapper fail to work!

    The end result should be that sound Just Works, even for awkward proprietary apps. CUSE will not automagically fix this on it's own, though - we need to wait for the sound daemons like PulseAudio to catch up and implement the emulation. This might also allow OSS emulation to be removed from the kernel, which AFAIK also supports some variant of OSS-on-ALSA.

  • Re:70% drivers! (Score:4, Informative)

    by schon (31600) on Thursday September 10, 2009 @09:54AM (#29377947)

    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.

    $ find /lib/modules/2.6.27.7-smp/kernel/drivers/ -type f|wc -l
    1499

    Looks like you're in luck!

  • by Motormouz (648619) on Thursday September 10, 2009 @10:04AM (#29378075)
    They've added IPv4 to the new firewire stack. You know, the one they put in the kernel some time ago in favor of the old one and caused some headaches to firewire users.
  • by Anonymous Coward on Thursday September 10, 2009 @10:22AM (#29378283)

    Firewire 3200 = 3.2Gbps.

  • OSS is the unix way (Score:3, Informative)

    by jabjoe (1042100) on Thursday September 10, 2009 @10:27AM (#29378371)
    Here we go again. I see the normal old OSS arguments that only apply to the old OSS Linux has.
    If ALSA is so great, why did it never get copied out side of Linux?

    Anyone else prefer having proper file interfaces for things like, Unix should do?
    If I want to write sound I write to /dev/dsp1 if I want to read sound I read from /dev/dsp1.
    If I want to write sound out to a second sound card, I write to /dev/dsp2. Nice simple device addressing system.
    Now I use ASLA, because the Linux support is all geared that way, and it has always worked for me, but every time I have to deal with it directly, even addressing the right device, I recoil from it's ugly complexity.

    ALSA can't kill OSS because Linux isn't the only open Unix platform and the others won't willingly take ALSA.
    I have no doubt that ALSA can do things OSS can't, but how many users need those things? Don't mess up the whole design to nicely support a few fringe cases. I want to go back to Unix fundamentals. ALSA is like something from the Windows world, not the Unix one. Plan9 still looks like the future to me, and ALSA is going the the wrong way. ALSA depresses me. :-(
  • Re:Linux audio (Score:4, Informative)

    by TheRaven64 (641858) on Thursday September 10, 2009 @10:28AM (#29378383) Journal
    You don't need them with OSS on FreeBSD and Solaris (for example), or on Linux with the out-of-tree OSS 4 implementation because they supported sound mixing so the kernel actually does what it is meant to do - lets the userspace apps ignore the differences between hardware implementations. The mixing is either done in hardware if the hardware supports it or software if it doesn't.
  • Re:Support for what? (Score:3, Informative)

    by PitaBred (632671) <slashdot@pitabre ... rg minus painter> on Thursday September 10, 2009 @11:11AM (#29378917) Homepage
    Drivers can be updated. The standard is almost there. There are a number of things that will NOT change with it. The problem is that USB has always been just "tacked on" to Windows. It's never been really well supported.
  • by Hurricane78 (562437) <deleted@s l a s h dot.org> on Thursday September 10, 2009 @11:23AM (#29379085)

    [...] only certain combinations of endpoints can possibly work. You can't plug the host controller of one PC into another, since they're only expecting to talk to devices, not another controller.

    Not so with Linux. You can enable the "USB gadget" driver in the kernel. Now if you have a device connector in your system, it can act like any other device. That is how Linux on small devices connects to their hosts via USB. And actually, the way they communicate is plain and simple TCP/IP. :)

  • by anonieuweling (536832) on Thursday September 10, 2009 @11:38AM (#29379267)
    http://btrfs.wiki.kernel.org/index.php/Main_Page [kernel.org] has the info, answers, etc
  • by Lemming Mark (849014) on Thursday September 10, 2009 @11:51AM (#29379469) Homepage

    Yes, that's true, I should have mentioned that. But you still can't plug a normal host controller into another, regardless of the software stack you're running. You need special hardware that most PCs won't have that implements the device end of the channel. I think that it's something of a shame that PCs don't include this hardware but I imagine it wouldn't be that useful, given they all include ethernet ports these days.

  • native xfi support (Score:4, Informative)

    by hyperion2010 (1587241) on Thursday September 10, 2009 @11:52AM (#29379479)

    Finally ALSA adds in kernel support for creative X-Fi after 4 years, fuck creative.

  • Re:70% drivers! (Score:3, Informative)

    by JohnFluxx (413620) on Thursday September 10, 2009 @11:54AM (#29379521)

    Ah so now you're arguing that they should freeze the interface, and prevent any more improvements.

    Read http://www.mjmwired.net/kernel/Documentation/stable_api_nonsense.txt [mjmwired.net]

  • Re:Support for what? (Score:1, Informative)

    by Anonymous Coward on Thursday September 10, 2009 @12:14PM (#29379769)

    Support for what? A quick search of newegg tells me I can't buy a motherboard, add-on card, or peripheral that supports USB 3.0 today

    Intel release specs to developers. Just because lowly consumers like yourself can't get access to the modern devices, it hardly means box designers aren't already bashing away on them. Linux has Intel chipset support before any other OS generally, simply because Intel let the devs at the docs and have internal people contributing. Getting their code into the kernel now means they hit the ground running. Why do you think linux kernel supports chipsets that have only been on the market a few days, even if the kernel could be months old?

    People like you are probably the first to cry when you buy a new box but your OS doesn't support it. Try thinking for once.

  • by amorsen (7485) <benny+slashdot@amorsen.dk> on Thursday September 10, 2009 @12:51PM (#29380163)

    A basic firewire controller with pass-through is cheaper than a 2-port 1000baseTX switch

    In this day and age, what do you use a 2-port switch for? You don't know that plugging the cable directly between cards just works?

  • Re:70% drivers! (Score:5, Informative)

    by amorsen (7485) <benny+slashdot@amorsen.dk> on Thursday September 10, 2009 @01:56PM (#29380779)

    There may have been a driver problem years ago, but today the problem is pretty much limited to graphics. And DVB, but the competition is doing just as badly there. Overall, Linux driver support is more complete than at least that of Windows Vista.

  • Re:Linux audio (Score:3, Informative)

    by Per Wigren (5315) on Friday September 11, 2009 @03:36AM (#29386803) Homepage

    How about keeping PA and JACK but skipping the ALSA layer, then

    But how should PA/JACK talk to the sound card? ALSA (not counting the userland plugin system) is pretty much an API and a collection of drivers.

    (especially since non-Linux systems apparently manage without it)?

    Because they use something else instead of ALSA, like OSS, Core Audio or Direct Sound.

"A mind is a terrible thing to have leaking out your ears." -- The League of Sadistic Telepaths

Working...