Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Linux Kernel 2.6.31 Released

CmdrTaco posted more than 5 years ago | from the download-compile-reboot-repeat dept.

Operating Systems 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."

Sorry! There are no comments related to the filter you selected.

Does it support (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#29377195)

Does it support first post?

Re:Does it support (-1, Offtopic)

PincushionMan (1312913) | more than 5 years ago | (#29377239)

No, but it insures those that try to get first end up last.

Linux audio (3, Insightful)

Anonymous Coward | more than 5 years ago | (#29377211)

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:Linux audio (4, Insightful)

nimbius (983462) | more than 5 years ago | (#29377471)

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

OSS was okay.

Re:Linux audio (1)

Lusixhan (1491267) | more than 5 years ago | (#29377555)

What I've never been able to get my mind around is how Audigy sound cards frequently work out of the box in Ubuntu (for output and input), but I've never once been able to successfully capture external audio on a motherboard's onboard chipset (VIA VT1708S). Without a sound card slot available (long story) it's infuriating to have to boot into Windows every time I want to record external audio.

Re:Linux audio (2, Insightful)

diegocgteleline.es (653730) | more than 5 years ago | (#29377789)

Yes, because userspace sound daemons were invented by ALSA. We didn't have these with OSS, not at all....

Re:Linux audio (5, Informative)

bcmm (768152) | more than 5 years ago | (#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 (1, Interesting)

Anonymous Coward | more than 5 years ago | (#29377989)

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.

Except Windows apps usually don't break just because there is a new flavor of the month in terms of audio. You can't argue that this is a good thing. The only reason it is OK in Linux is because most apps have source available. As usual, Windows makes the less pure choice (in terms of engineering), Linux does the right thing by abandoning the technology.

The fact that it is 2009 and there are still audio issues on Linux is telling, however.

Re:Linux audio (4, Interesting)

walshy007 (906710) | more than 5 years ago | (#29378033)

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

With a standard configuration, alsa does also, you have to load the dmix module in your config to act as a software mixer on cards that don't do hardware mixing (most on board bits).

This is where the userspace demons enter it all, most of them just started out as another layer that does software mixing, but every man and his dog came up with his own invention.

As for just using alsa, that's great if you don't mind not having certain functionality, some of the sound demons do add some nice features (jack is the only one I've found worth using though). It could be argued the driver layer shouldn't have to deal with some of that advanced functionality though, another reason why these demons were made.

Re:Linux audio (1)

diegocgteleline.es (653730) | more than 5 years ago | (#29378147)

With a standard configuration, alsa does also

All the relevant desktop distros enable dmix by default...

Re:Linux audio (2, Interesting)

Timmmm (636430) | more than 5 years ago | (#29378277)

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

That was OSS 3. OSS 4 apparently allows you to do this on all hardware and is apparently much nicer than ALSA. It's also open source again. I read a good article about this situation a while ago but can't find it now.

Re:Linux audio (2, Informative)

walshy007 (906710) | more than 5 years ago | (#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.

Re:Linux audio (1)

Per Wigren (5315) | more than 5 years ago | (#29377857)

Please define "works". After that, imagine that some people have other needs and what the definition of "works" is in their case. Think about multiseat setups, have one users X session play audio on the front speakers and another users X session play on the rear speakers, and they have separate master volume controls. Think about using one microphone to record to several different applications at the same time. Think about logging in to a remote computer and the audio of the applications you start play on your local speakers.

Plain OSS was okay only if your needs were within OSS' very limited feature set.

The "million handler processes" are for backwards compatibility. Pulseaudio only use a single one.

Re:Linux audio (1)

miknix (1047580) | more than 5 years ago | (#29377909)

I'm using OSS4 with my Intel HDA (Conexant) Chip. I started using it to have proper audio mixing, ALSA can also do it but not every app out there is written to use the dmix plugin. In OSS4, every app that uses the (legacy) OSS API will work perfectly.

http://cafe-ti.blog.br/wordpress/wp-content/uploads/2009/02/ossxmix.png [cafe-ti.blog.br] (See VMIX0 for audio mixing)

The only problem I found is that the phone jack sensing doesn't work. When I connect my phones, I'll have to manually cut-off the speakers sound in the mixer.

Re:Linux audio (1)

diegocgteleline.es (653730) | more than 5 years ago | (#29378189)

not every app out there is written to use the dmix plugin.

The dmix plugin is used transparently in the ALSA libs, apps don't need to be rewritten to use it...

Re:Linux audio (1)

ChienAndalu (1293930) | more than 5 years ago | (#29377931)

It still is. I use it on archlinux after alsa farked up unexpectedly and it works fine.

Well, actually, not quite, the mixer is broken. But I like to pretend it isn't.

Re:Linux audio (0)

Anonymous Coward | more than 5 years ago | (#29378325)

Linux was always about choices, competing technologies. If you want to be just 'given' things other OSs come to mind.

Re:Linux audio (2, Insightful)

Per Wigren (5315) | more than 5 years ago | (#29377623)

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:Linux audio (1)

clang_jangle (975789) | more than 5 years ago | (#29377801)

it IS the future of Linux desktop audio, whether you like it or not

As someone who does pro audio production (and has to reboot into OS X to do most it properly) that sounds like a threat to me. We've waited long enough, can we please just get back to OSS. There is no good reason not to at this point.

Re:Linux audio (4, Insightful)

Per Wigren (5315) | more than 5 years ago | (#29377925)

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 (3, Insightful)

someone1234 (830754) | more than 5 years ago | (#29377817)

For some time Alsa was the "new tech". Now PulseAudio. By the time it stabilizes, there will be something else.

Re:Linux audio (1)

amn108 (1231606) | more than 5 years ago | (#29378341)

They have two different goals. ALSA aims to be a generic API for interfacing a sound card. PulseAudio is a "sound server" - another layer on top of whatever API (ALSA usually) is underneath it, to provide more fine grained and desktop-worthy API to modern applications, like per-app volume control and seamless sound redirection. I welcome ideas of both, they are not competitors unless either decides to "extend" their functionality.

Re:Linux audio (2, Interesting)

walshy007 (906710) | more than 5 years ago | (#29377921)

it is a good API and it IS the future of Linux desktop audio,

The future of linux audio it may be.. but good is questionable, no person using their linux machine for synths or midi would touch pulseaudio with a ten foot pole, jack is far superior with a lot less latency, but only applications designed for pro audio use tend to utilize it.

When this transitional period we are currently in is over, everyone will be much better off.

The latency incurred by pulse audio is horrendous, for youtube or movies that's fine, for gaming it's questionable, for music production it's nasty. These days completely removing pulseaudio and getting it all going again is quite an effort.

I can't imagine everyone being much better off, only those who want sound who don't care about the latency or from the music peoples perspective functionality.(jack can do a lot of things pulse can't do)

Re:Linux audio (2, Insightful)

Per Wigren (5315) | more than 5 years ago | (#29378057)

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:Linux audio (4, Funny)

Hatta (162192) | more than 5 years ago | (#29378089)

it is a good API and it IS the future of Linux desktop audio,

It may be a good API, but it's not a good implementation. But yeah, I can agree that glitchy, high latency audio is the future of Linux desktop audio.

Re:Linux audio (2, Funny)

Per Wigren (5315) | more than 5 years ago | (#29378183)

You know what? Maybe in the future Jack will implement the Pulseaudio API and be able to function as a drop-in replacement to Pulseaudio. It's not THAT unfeasible. Also, the PA implementation is getting better and the latest versions don't have that high latency if run on a -rt kernel with realtime privileges. A bit buggy under certain conditions, yes, but that will be fixed in the future.

Re:Linux audio (4, Insightful)

impaledsunset (1337701) | more than 5 years ago | (#29378171)

"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 (1)

Per Wigren (5315) | more than 5 years ago | (#29378299)

Yes, this transitional period is pretty harsh to us who wants to run some older software that use bad coding practices. :( Thankfully, it will only get better as applications are fixed and backwards compatibility interfaces, like CUSE+ossp mentioned in the article summary, get better.

Yo dawg (3, Funny)

Lemming Mark (849014) | more than 5 years ago | (#29377721)

We heard you like your audio to work, so we put a sound API in your sound API, so you can have silence whilst you listen!

Re:Linux audio (0)

Anonymous Coward | more than 5 years ago | (#29377739)

Duh. Exactly why?

I could understand it if we were speaking about ALSA, Pulseaudio, etc; but I don't understand why you would tell that about CUSE+OSS proxying. In the linux world OSS is an outdated API, most apps use ALSA. The in-kernel OSS compatibility layer has problems, like for example not allowing to use OSS emulation + ALSA at the same time. This compatibility layer fixes that problem, could allow to remove a lot of kernel code that didn't belong there anyway, and allows extra features that OSS traditionally can't do, like proxying the sound through the network.

So where is the train wreck? This feature not only solves a real problem, it also adds features that the 4Front stack can't do. The one people I know they will not like this are the OSS fans that hate this because it makes OSS even more irrelevant and makes their "sound mixing should be in the kernel!" argument look even more stupid.

Re:Linux audio (0)

Anonymous Coward | more than 5 years ago | (#29377897)

Fscking n00bs. Please see the OSS implementation in FreeBSD for a lesson in how sound should be done.

Re:Linux audio (1)

diegocgteleline.es (653730) | more than 5 years ago | (#29378103)

Please see the OSS implementation in FreeBSD for a lesson in how sound should be done.

Yeah, FreeBSD. And instead, why not take a look at how OS X and Windows (Vista and ahead) implement their sound systems? Hint: Both mix audio in userspace, and Pulseaudio is the closest thing to them in Linux land.

But hey, what do OS X and Windows know about desktops and professional sound systems? Nothing. That's why we all should follow the lead and use cutting-edge technology like OSS and in-kernel sound mixing.

.

Re:Linux audio (2, Funny)

sarhjinian (94086) | more than 5 years ago | (#29377785)

It's no worse than video is, really. The four-second PulseAudio lag* matches nicely with the lack-of-vsync-based tearing in X.**

Actually, I take that back: video is worse. At least with PulseAudio I can see how it's eventually supposed to work if it didn't crash periodically. The clusterf_ck that is video playback doesn't look like it'll get fixed anytime soon, what with the six-party fight between all the various components.

You can really tell that the bills for Linux's development are being paid by server manufacturers.

* "Use jack" is not an option. Not everything works with jack.
** Yes, I know I can use OpenGL for video playback. That introduces it's own set of issues.

Re:Linux audio (4, Insightful)

jw867 (97358) | more than 5 years ago | (#29377893)

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 (1)

amn108 (1231606) | more than 5 years ago | (#29378229)

Why mod this insightful? Just because ALSA proxies OSS, does not mean it HAS to. It is your choice, and choice is part of Linux philosophy. ALSA works fine with its own hardware drivers, without OSS involved at all. Which it usually does too. You are complaining that somebody gave you an option to use a soundcard with OSS-only mixer with ALSA applications. Where is the logic in that? It is like complaining that PulseAudio should be removed and buried because you don't use it, even though many find it convenient enough, even at the cost of increased system complexity and slightest resource usage increase.

Re:Linux audio (0)

Anonymous Coward | more than 5 years ago | (#29378297)

That quote shows how much of a train wreck Linux is.

FTFY. OS X and Windows 7 *FOR THE WIN*!!!! Once again, closed source beats open source. Suck it, freetards.

IPv4 over Firewire? (3, Interesting)

0100010001010011 (652467) | more than 5 years ago | (#29377245)

I guess I really wasn't into linux until the last 3-4 years, but hasn't OS X done this since the start? And I think my XP machine at work tries to use Firewire as a network adapter.

What took so long, honest question.

Re:IPv4 over Firewire? (2, Insightful)

FinchWorld (845331) | more than 5 years ago | (#29377305)

It never took off? I've only ever used firewire for networking once, and that was for the sheer novelty of seeing if it could be done.

Re:IPv4 over Firewire? (3, Interesting)

muckracer (1204794) | more than 5 years ago | (#29377479)

Networking over USB would be awesome. Link 2 PC's with USB cable and voila! Hell, even being able to mount an internal drive that way on the other machine would be cool. Anything like that in the works (haven't checked)?

Re:IPv4 over Firewire? (0)

Anonymous Coward | more than 5 years ago | (#29377581)

What about using a CAT5 cable between two USB NICs?

Re:IPv4 over Firewire? (0)

Anonymous Coward | more than 5 years ago | (#29378079)

What about using a CAT5 cable between two USB NICs?

Now that's just crazy talk.

Re:IPv4 over Firewire? (1, Informative)

Anonymous Coward | more than 5 years ago | (#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:IPv4 over Firewire? (3, Interesting)

Lemming Mark (849014) | more than 5 years ago | (#29377819)

How was the parent modded troll, it's completely valid!

It's a good idea. There have been networking over USB devices (by which I mean plugging both machines USB ports into the device, not "merely" a USB ethernet adaptor). The problem with doing this with USB, rather than Firewire is that USB has a really strong concept of "host" and "device". The cables are made to only plug into certain combinations of endpoints because, sadly, 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. This is in contrast to Firewire, which is peer-to-peer and (in principle) anything could talk to anything over it.

The unfortunate consequence is that you don't just get to do networking over a nice, cheap cable as you do with Firewire. You actually need a little device box in between so that both hosts can believe they're talking to a peripheral, not another host. This approach, on its own, wouldn't let you plug in "remote" devices either so you'd have to set some other protocol up (plenty of existing options here) to talk to devices at the other end. You have to be a bit careful because most devices would barf horribly if there are multiple users - uncontrolled shared access to a disk device is a good way to lose all your data, for instance.

Although it's fun to do IP over Firewire, I'm not familiar with exactly how it's implemented. What intrigues me is the prospect of running increasingly sophisticated high-performance protocols over Firewire. As I understand it you can basically get remote DMA access to the "other end's" memory. This obviously has severe security implications but it could be quite nice in a mutually-trusting cluster. There are various protocols (e.g. used by Infiniband) for having communications over remote DMA. I wonder if anyone could put together an "infiniband lite" that just ran over Firewire. It'd be cool, though I don't know if it would be particularly useful ;-) (plus it would lack the user accessible networking Infiniband has)

Re:IPv4 over Firewire? (0, Troll)

tecnico.hitos (1490201) | more than 5 years ago | (#29377315)

Other priorities, I think.

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

Re:IPv4 over Firewire? (2, Informative)

DavidpFitz (136265) | more than 5 years ago | (#29377373)

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?

Re:IPv4 over Firewire? (1, Troll)

tecnico.hitos (1490201) | more than 5 years ago | (#29377439)

Actually, no.

Re:IPv4 over Firewire? (1)

MMC Monster (602931) | more than 5 years ago | (#29377811)

How the heck can you reliably pump video from a video camera to a PC? While USB3 has similar bandwidth, the overhead of the protocol, especially when there are other USB items in the chain, slow down the real throughput.

I know, . Anyone pull up a good comparison on google?

Re:IPv4 over Firewire? (3, Informative)

uhmmmm (512629) | more than 5 years ago | (#29377473)

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:IPv4 over Firewire? (2, Informative)

Motormouz (648619) | more than 5 years ago | (#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.

Re:IPv4 over Firewire? (5, Informative)

Anonymous Coward | more than 5 years ago | (#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:IPv4 over Firewire? (0)

Anonymous Coward | more than 5 years ago | (#29377757)

I don't get you folks. What a weird router you have there playing network via firewire?
In fact, this stupid network over firewire driver came as default network interface messing up my ethernet connection!
And that was a few years a go.
Seriously. What's this craze about firewire? 1Gbit via ethernet is not enough??

Re:IPv4 over Firewire? (1)

tagno25 (1518033) | more than 5 years ago | (#29377809)

Seriously. What's this craze about firewire? 1Gbit via ethernet is not enough??

Firewire networking came about before Gb network cards (in consumer equipment)

Re:IPv4 over Firewire? (1, Informative)

Anonymous Coward | more than 5 years ago | (#29378283)

Firewire 3200 = 3.2Gbps.

Re:IPv4 over Firewire? (0)

Anonymous Coward | more than 5 years ago | (#29378049)

this is ipv4 over the new firewire stack, the old stack had another implementation. but still, ip over firewire is rarely supported out of the box on linux, for example i don't think network manager deals with it.

More FUSE-like stuff (0, Troll)

miketheanimal (914328) | more than 5 years ago | (#29377273)

OMG. It might become a micro-kernel!!!

i'd just like to (-1, Troll)

Anonymous Coward | more than 5 years ago | (#29377291)

I'd just like to interject for a moment. What you're refering to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.

Many computer users run a modified version of the GNU system every day, without realizing it. Through a peculiar turn of events, the version of GNU which is widely used today is often called "Linux", and many of its users are not aware that it is basically the GNU system, developed by the GNU Project.

There really is a Linux, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine's resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system. 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.

Re:i'd just like to (4, Funny)

Lord_Frederick (642312) | more than 5 years ago | (#29377355)

Give it up already, Richard.

Re:i'd just like to (0)

tecnico.hitos (1490201) | more than 5 years ago | (#29377397)

There really is a Linux, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine's resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system.

If the body is GNU, but the brain is Linux, what is the identity of the creature?

Re:i'd just like to (2, Insightful)

Timothy Brownawell (627747) | more than 5 years ago | (#29377419)

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:i'd just like to (0)

Anonymous Coward | more than 5 years ago | (#29377703)

Or more properly, KDE/Xorg/GNU/Linux.

Or more properly, (KDE||Gnome||XFCE||etc.)/[conky]/Xorg/Linux/GNU.

Re:i'd just like to (0)

Anonymous Coward | more than 5 years ago | (#29377849)

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.

Okey, so it works that way... Just to see if got this right: I'm now using IE/Windows/VMWare/KDE/Xorg/GNU/Linux system. Later on, I plan on using Eclipse/Gnome/Xorg/GNU/Linux system. And so on...

Re:i'd just like to (1)

Kjella (173770) | more than 5 years ago | (#29378181)

You fed the troll. You lose.

Re:i'd just like to (0)

Anonymous Coward | more than 5 years ago | (#29377461)

Yeah, we all know that (Richard?), but "GNU/Linux" is cumbersome and dorky. I'd find another pet peeve--you won't find contemporary usage beating a path to your pedantic door.

Heck, when I mention Linux to my mainstream friends, a blank look is all I generally get, anyway. Why make life more difficult?

Re:i'd just like to (1)

C0vardeAn0nim0 (232451) | more than 5 years ago | (#29377813)

dumbass... TFA is _specifficaly_ refering to the kernel. if people want to use "linux kernel" to refer to linus' piece of code they're free to do so, just like some people call MS's operating system "microsoft windows", so just shut the fuck up.

Re:i'd just like to (1, Funny)

Anonymous Coward | more than 5 years ago | (#29378175)

I run Cygwin or, as I like to call it, GNU/Windows(tm).

USB 3.0: better than Windows 7 (1, Informative)

Anonymous Coward | more than 5 years ago | (#29377307)

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

Re:USB 3.0: better than Windows 7 (0)

Anonymous Coward | more than 5 years ago | (#29377841)

You're assuming there won't be a patch out before USB 3.0 devices take off. The devices have to come with Windows support else they're useless.

Re:USB 3.0: better than Windows 7 (1)

sammydee (930754) | more than 5 years ago | (#29377957)

Sadly this lack of support probably just means that no USB3 devices or chipsets will actually be produced until the next version of windows comes out that DOES support it.

Support for what? (5, Interesting)

saleenS281 (859657) | more than 5 years ago | (#29377969)

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. What exactly was windows 7 going to support? An unreleased chipset?

From your own article:
Jeff Ravencraft of Intel said that he expects the final specification to be announced in San Jose, Calif., on November 17.

Wait, so I'm supposed to be upset that Microsoft didn't ship experimental drivers for an unratified standard in their new OS?

Re:Support for what? (1)

rastilin (752802) | more than 5 years ago | (#29378331)

Wait, so I'm supposed to be upset that Microsoft didn't ship experimental drivers for an unratified standard in their new OS?

What's really telling is that the previous comment got modded +4 Informative without anyone noticing this at all.

70% drivers! (3, Interesting)

millwall (622730) | more than 5 years ago | (#29377363)

Lots and lots of driver work. Over 70% of all of the 2.6.30 to 2.6.31 patch is under drivers/, and there's another 6%+ in firmware/ and sound/. That's not entirely unusual, but it does seem to be growing. My rough rule of thumb used to be "50% drivers, 50% everything else", but that's clearly not true any more (and hasn't been for a while - we've been 60%+ since after 2.6.27

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.

Re:70% drivers! (0, Insightful)

Anonymous Coward | more than 5 years ago | (#29377445)

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! (-1, Troll)

Anonymous Coward | more than 5 years ago | (#29377449)

Which enhancement in Linux kernel are you missing? Believe me, ONLY feature which many people are missing on Linux is support for their dumb scanner made 10 years ago.

Re:70% drivers! (1)

tecnico.hitos (1490201) | more than 5 years ago | (#29377469)

Which will hardly work in a new Windows system.

Re:70% drivers! (1)

MrMr (219533) | more than 5 years ago | (#29377529)

Odds are Linux is the only system where it still works, like my old canoscan device: No Mac OS > 10.3 no windows > XP. But perfectly ok with the generic twain stuff...

Re:70% drivers! (5, Insightful)

von_rick (944421) | more than 5 years ago | (#29377455)

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.

Re:70% drivers! (2, Insightful)

MBGMorden (803437) | more than 5 years ago | (#29377661)

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:70% drivers! (3, Informative)

schon (31600) | more than 5 years ago | (#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!

Re:70% drivers! (3, Insightful)

MBGMorden (803437) | more than 5 years ago | (#29378061)

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! (1)

gnud (934243) | more than 5 years ago | (#29378263)

That's a valid point of view, but it directly contradicts OPs argument for less focus on drivers and more on other enhancements.

Re:70% drivers! (0)

Anonymous Coward | more than 5 years ago | (#29378095)

And yet those drivers are developed and distributed with the kernel project at large. Out of necessity, really, given the hostility of the kernel developers to external drivers, and the constantly changing interfaces.

Re:70% drivers! (4, Insightful)

Kjella (173770) | more than 5 years ago | (#29378091)

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:70% drivers! (1)

Timmmm (636430) | more than 5 years ago | (#29378327)

I totally agree, but it seems the linux devs don't want to have to maintain a stable driver ABI. I think that's a pretty silly position to take; hopefully they'll change their minds at some point.

Re:70% drivers! (1)

kestasjk (933987) | more than 5 years ago | (#29377481)

Enhancements like what?

Re:70% drivers! (3, Insightful)

Timothy Brownawell (627747) | more than 5 years ago | (#29377495)

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! (2, Insightful)

jellomizer (103300) | more than 5 years ago | (#29377521)

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! (3, Informative)

walshy007 (906710) | more than 5 years ago | (#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

Re:70% drivers! (4, Insightful)

MrHanky (141717) | more than 5 years ago | (#29377547)

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:70% drivers! (4, Informative)

Anonymous Coward | more than 5 years ago | (#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.

troll (0)

Anonymous Coward | more than 5 years ago | (#29377865)

Last I checked, drivers were a good thing, and people working on things that you don't care about doesn't hurt you (contrary to commonly held republican beliefs.)

enhancements are being neglected (1)

viralMeme (1461143) | more than 5 years ago | (#29377907)

"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 though the main bugaboo was the lack of hardware support in Linux. What other features and enhancements are being neglected?

Re:70% drivers! (1)

Skatox (1109939) | more than 5 years ago | (#29377915)

Well that's something i love from this release, the fixed a lot of drivers problem that my laptop uses.

Linux is dying (0, Troll)

For a Free Internet (1594621) | more than 5 years ago | (#29377423)

It is a bunch of legacy cruft piled on compatibility and emulation layers. I have created a kernal so small and so efficient that it can fit in the nostril of a piglet while still supporting full IPv6 and Perl. Furthermore why are all Linux users fat hairy men?There is something wrong with a culture that worships regurgitating antarctic waterfowl. Something seriously wrong that requires some good old fashioned sunshine and country fresh air and fried chicken.

Horray! (0)

Anonymous Coward | more than 5 years ago | (#29377571)

I've been waiting for this land-mark release since v2.6.30!!!

TTY? (0)

Anonymous Coward | more than 5 years ago | (#29377681)

How about the TTY "hacks", did those make it to this release?

Using CUSE for sound devices is The Right Way (4, Informative)

Lemming Mark (849014) | more than 5 years ago | (#29377923)

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:Using CUSE for sound devices is The Right Way (1)

raddan (519638) | more than 5 years ago | (#29378207)

So... from what I gather from your post, you can't just graft an OSS API on top of ALSA (or PulseAudio for that matter) because ALSA and PulseAudio run in userspace? Why are we putting sound daemons in userspace anyway?

Yay! (4, Funny)

British (51765) | more than 5 years ago | (#29377945)

Improved acronym support!
Numbers higher than the last version!
greater infusion processor link array warp drive systems!

Remote device fun (1)

Lemming Mark (849014) | more than 5 years ago | (#29377997)

How long until the APIs provided by CUSE are used to implement an arbitrary-character-devices-over-network protocol? That would be pretty cool and useful. Should be doable, from what I understand of how it works.

The description of the in-kernel changes on LWN's article on the subject (http://lwn.net/Articles/308445/) made it sound like the infrastructure could also be used for stuff like network filesystems whose /dev contains *remote* character devices (currently NFS device nodes are always serviced by local device drivers, so you can't use NFS to export devices). This might be especially useful for 9P, which is actually designed for device remoting since that's what Plan 9 did as a matter of course.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?