The problem is the stupid Microsoft's cicle release. That kind of fixes won't ve delivered via windows update unless they're really critical, but through service pack updates. IOW: You'll have to wait until 2007 (service pack 3 planned release date I think) if you're lucky. Notice that this bug was introduced by service pack 2 BTW
They usually tell you to "contact" Microsoft through a number phone to get a patch if you want to get it earlier, something like this:
To resolve this problem, contact Microsoft Product Support Services to obtain the hotfix. For a complete list of Microsoft Product Support Services telephone numbers and information about support costs, visit the following Microsoft Web site: http://support.microsoft.com/contactus/?ws=support (http://support.microsoft.com/contactus/?ws=suppor t) Note In special cases, charges that are ordinarily incurred for support calls may be canceled if a Microsoft Support Professional determines that a specific update will resolve your problem. The usual support costs will apply to additional support questions and issues that do not qualify for the specific update in question.
Which is really a really stupid way of doing things for a company that claims to be number 1
He's not "against" the new revision. He just made clear that the kernel will not, and probably can _not_ be switched to GPL v3. He just said that the linux kernel license has _aways_ been GPL 2 and that it's not going to change just to explain people that a GPLv3 kernel is not going to happen
And this is going to happen for ALL the projects that have not a "at your option, any later version...". What about commercial products, say QT, will trolltech license QT against GPL v2 like it does now or V3?
I agree with the top post. This is a non story. In the spanish/. equivalent (barrapunto.org), you can read today some crap like "GPL: Linus says no, Debian says yes". Linus doesn't even says he doesn't likes GPLv3 (except for the keys thing). What makes people think that he won't use it for other projects like he did with GIT or sparse?
Being Linus must suck. No matter what you say, there's people who misinterprets you even if you rejected jobs at redhat just to maintain neutrality WRT other linux distros. It's just like the BK history: When Linus started using bitkeeper he said that he'd never force people to use BK if they didn't like it, that it was a tool to help himself on the development and that he'd accept traditional patches from the people that didn't want to use BK. Other developers (lots of them) used also BK just because BK was good and saved them time, not because they were forced to get their patches in (alan cox, for one, didn't use BK). All the kernel releases and -rc patches where always available in diff format and in fact it was possible to get nightly snapshots GNU diff patches. But hey, even he didn't forced anyone to use BK everybody thinks he did - now everybody is starting to put him as a the "anti-GPLv3 bad guy"
The also announced that they've shipped 1M of core duo chips.
Obviously, both announcements are trying to stop the stock fall (which started when Intel announced that they haven't hit the sales predictions). Not that AMD doesn't do the same, they've used the same trick several times just like any company.
It's how capitalism works: People is free to invest were they want and do what they wan but what happens if we try to influence what people wants?
(By the way is ironic how capitalism is good because it allow companies to have more freedom to do things in their "system" but freedom is being limited in the US for "security purposes". I'd guess that if I'd propose to take away some of the freedom that capitalism has to fix some of the problesm the world has like poverty etc people would call me communist or something)
Corporations (and even some individuals) need strict control of their private data
I wonder how people plans to fix that with DRM. Once a DRM'ed document is loaded in word, you can jump the drm protection by....taking a screenshot? Oh well: The operative system may forbid to take screenshots of the windows that has DRM content (like mac os x does with DRm'ed videos I've been told). You may get your digital camera or even a vigilance camera could do it (you don't need to be 007 to do that).
But well, the operative system is also handling the data, so it has to be somewhere - what about a program that spies when you cut a piece of text?
Want to "secure your data"? Well, just use pgp to cypher it - hell there're guis for that - and store your private key in a usb key, nobody will be able to read your PGP'ed document. I don't see how DRM solves ANY problem.
I'd say that this is "relative": at the start of the COPYING file , I read: "GNU GENERAL PUBLIC LICENSE Version 2, June 1991". I'd say that it looks like Linus has modified the COPYING file on purpose just to _clarify_ the original intentions.
Oh well - so you don't like GPL, be it v2 or v3. I happen to think that the GPL is one of the few licenses that REALLY helps me to have free/open software. Other licenses (say, BSD) allow companies to relicense a copy of the software with another license or even close the code.
There's nothing wrong with that. But I happen to think that in this world companies are already having too many ways of getting money - DRM and software patents, for one - and they don't need help from hippy university students.
I laught when companies say "we don't like the GPL, it doesn't allows to use thousand of lines of code without forcing us to get back the changes", like being able to close the source were the one way to keep the company up. Then at the following day you see the financial results of that quarter and the company happens to have a couple of thousand of millions of dollars in cash but hey, GPL is "not free, it doesn't allow us to do what we want, it doesn't adapt to our needs". And the following day the company hires some lobbies to get software patents and DRM in Europe.
Is not that I hate companies - I love capitalism - I just don't understand this "ooh poor of us those free software coders are releasing code under the GPL license which is too restrictive and viral". Those companies have enought money to write a new operative system from scratch without using code from anyone else (I've nothing against that, I'd even bought and pay for it if it's a good product), stop pretending that GPL is "too restrictive". So uh, maybe companies and some people like you thinks that GPL is "too restrictive". I happen to think that is great, and I've only heard good things from the GPL v3 version.
And even if it could, it doesn't neccesarily means that GPL v3 would be useful for the kernel. Let me quote a mail from Linus on the matter from a couple of hours ago:
> This means that when the code went GPL v1 -> GPL v2, the transition was > permissible. Linux v1.0 shipped with the GPL v2. It did not ship with a > separate clause specifying that "You may only use *this* version of the GPL" > as it now does. (I haven't done any research to find out when this clause was > added, but it was after the transition to v2).
Bzzt. Look closer.
The Linux kernel has _always_ been under the GPL v2. Nothing else has ever been valid.
The "version 2 of the License, or (at your option) any later version" language in the GPL copying file is not - and has never been - part of the actual License itself. It's part of the _explanatory_ text that talks about how to apply the license to your program, and it says that _if_ you want to accept any later versions of the GPL, you can state so in your source code. The Linux kernel has never stated that in general. Some authors have chosen to use the suggested FSF boilerplate (including the "any later version" language), but the kernel in general never has.
In other words: the _default_ license strategy is always just the particular version of the GPL that accompanies a project. If you want to license a program under _any_ later version of the GPL, you have to state so explicitly. Linux never did.
So: the extra blurb at the top of the COPYING file in the kernel source tree was added not to _change_ the license, but to _clarify_ these points so that there wouldn't be any confusion.
The Linux kernel is under the GPL version 2. Not anything else. Some individual files are licenceable under v3, but not the kernel in general.
And quite frankly, I don't see that changing. I think it's insane to require people to make their private signing keys available, for example. I wouldn't do it. So I don't think the GPL v3 conversion is going to happen for the kernel, since I personally don't want to convert any of my code.
> If a migration to v3 were to occur, the only potential hairball I see is if > someone objected on the grounds that they contributed code to a version of the > kernel Linus had marked as "GPLv2 Only". IANAL.
No. You think "v2 or later" is the default. It's not. The _default_ is to not allow conversion.
We can always debate whether or not proprietary or open source development models produce better quality code, but proprietary formats are never good. All they do is hurt competition, which helps no one but the authors. Now that Adobe owns Macromedia, hopefully the Flash people will take a hint from PDF: open formats work. If SWF is opened, great
Shocking news: The SWF format IS open: Here you have a link. The license is quite similar to PDF. I think it's somewhat more restrictive to create tools which create SWFs or something but what the hell, stops saying that SWF is closed.
Just because the open source community hasn't managed to write a decent implementation of the PDF format doesn't mean. Actually, people has tried to write implementations (way before that GNU thingy by the way): Google for libswf. There's even a gstreamer plugin which uses libswf to draw flash animations (and it works for simple flash files, I've used it). Dude, in my machine nautilus shows me thumbnails of some flash files. Also, macromedia has written a linux flash player plugin for mozilla-based browsers, I wish all companies would do that.
Congratulations, a company who wins millions of dollars has bought your opinion and mind and free advertising force for a CPU which costs 40 dollars to produce (give/take 10 dollars for amd). In fact they may have given you one of those CPUs that doesn't pass all the quality tests.
Indeed! It's like you would say that it's much easier to find bugs just after the first release of the CPU and even easier when it's the debut of a completely new architecture like the Core Duo is!. It'd be like posting links to the AMD errata docs!
like bugs in CPUs are something new....I want to know how many bugs where found in the first 20 days of the release of other intel architectures and the opteron, otherwhise I can't know if the core duo is a bad CPU compared with others or not. This article just looks like anti-intel FUD from AMD fanboys (Intel made a good CPU even with the bugs, deal with it, AMD is not going to give away free CPUs to you for being a fanboy).
And let me doubt that there's any CPU manufacturer at all that releases CPUs without any "know bug", many CPU bugs are fixed with microcode updates via new bios versions. There's a reason why both amd and Intel CPUs allow to update the microcode, they don't include features for fun.
Makes sense... And after all, people porting code to run on other OS's *really* enjoy re-writing huge chunks of Linux specific junk...
Oh well. People porting code to run on other OSs enjoy when linux rewrites large parts of linux-specific junk; and users say linux it sucks because Linux keeps using the same useless standard crap that OSS is. I'd rather have a technoloy that doesn't sucks than one that sucks but is portable.
How you get to binary compatibility involves declaring certain structures off limit for direct access (use accessor routines), stabilizing at least parts of others, and possibly adding versioning interfaces in key places
You really need to read the numerous documents about why linux does not want a "stable abi". There ARE projects which have implemented a binary ABI. Everybody has ignored them.
Not likely, as long as the GPL fanboys/fangirls insist that binary device drivers are evil.
You really need to read why linux people does not want "stable abi". Linux is a operative system - just face it.
No, we should bitch the companies for allowing their cards to boost the TX power beyond a certain threshold. If the card can go beyond the limits, then the card should NOT pass the FCC regulations, period. Instead, they allow cards to go beyond the limits. And opensource drivers allow you modify the source to do it....news at 11.
Again (for about the third time, I realize)... that's not how businesses think. If you're going to support a given platform, you do it WELL. That means testing. That means QA engineers.
And exactly what is stopping businesses from supporting, testing, doing QA, and releasing the source of the driver to merge it in the main linux tree? That's how you do things "well" in the linux land. People like 3Com, Intel or adaptec are releasing AND maintaining drivers for their devices in the linux tree TODAY (there's a reason why I keep buying intel stuff...).
Let's stop this: Companies CAN support linux if they can. They're companies doing it (check the linux kernel mailing to see people from different hardware companies sending patches). Supporting linux is possible TODAY. Most of the companies just DON'T bother
Maintaining a database of all the hardware which works for linux is hard, it'd be asier to keep track of what hardware doesn't work. These days we have MODULE_DEVICE_TABLE: in every module: This exports the list of the IDs that every modules support. Recolect the IDs of all modules and you'd get a sort of automated database of all the devices supported by linux
Soundcard support is pretty decent, until you realize the OS often implicitly locks-out multiple apps from outputting audio.
Applications using alsa doesn't suffer such problems. Stop using apps that use/dev/dsp directly....
Linus (and others) *do* tweak the kernel API on a regular basis.
Well, "tweak the kernel API" is not the same than "tweak every API in the kernel"
Notice that the huge majority of the thousands of drivers inside the kernel doesn't have any changes at all between releases. It'd be crazy if the kernel needed to modify all the drivers for EVERY release. That's certainly not true. Some of them change, sure - when a given subsystem changes something. It doesn't happen every release. You can check it in the git web interface. Some drivers have not had any commit for MONTHS. In fact most of the commits you'll see in the changelogs are internal driver changes, not changes needed to make the driver work with a new api. Some drivers however (ej: the propietary nvidia driver) need changes. If they didn't put a entire opengl stack inside the driver things would be easier. Who knows.
Of course, that's source. At binary level, everything changes. You can't load a kernel module compiled for another kernel version: There're checks to avoid that: Even for the cases where it could work. Many plugin-based apps (drivers are more like plugins, not "programs built in top of the kernel api") require that too. Linux is not a closed source kernel and we don't want that it becomes one.
Windows XP maintains the compatibility, yeah. They've rewritten the USB stack 3 times or so (just like linux) and they maintain the compatibility for all the drivers supporting the 3 different stacks. Just imagine how horribly complex and hard to maintain and evolce the XP kernel has to be.
Linux has certainly come to a point where it's easier to make a list of hardware that doesn't work than making a list of hardware that works. From a historic POV, even with cases like this linux looks promising: Linux used to be a crappy OS made by students without support from big enterprises and well, it ended up supporting lots of things. These days it's a good OS made by professional programmers and support from big companies - future can't be as dark as the "build a stable api or linux won't be usable on the desktop!" people says.
Notice that vendors are not being asked to modify the drivers in each release. We're asking them to release open source drivers - "we" will do the neccesary job to integrate them and maintain them in the kernel. Hell, release drivers even if they're against a 2.4 kernel, people will port them to 2.6, it won't be easy but it's certainly easier than reverse engineering or writing the driver from scratch (unless the drivers is a complete crap)
So the "unstable API" has not sense. By the way, notice that the kernel API _is_ stable: for a single version. No, this is not a joke: The new development model implies that EVERY kernel release is a mini-development kernel which can be stabilized in ~2 months. In other words, make progress slowly, gradually, instead of big development releases which are a pain to manage and stabilize, because there're thousand of new things instead of just a couple: It's much easier to find bugs when there're few important changes. Also the new kernel development model forces people to test things and develop production-ready code after testing it in the -mm tree, in a typical development model people tends to care less about making things stable until the "stabilization period" starts. Call me stupid, but I like this model.
oh yes...that....was exactly what I wanted to say, sure. It was...ironic; we the intelligent people use that kind of things. It's a shame general_re didn't get it.
Slashdot Mirror
Maybe because this was a interview, not a friggin discussion on the technical aspects of space fuel tanks construction.
The bug probably has been fixed already
t (http://support.microsoft.com/contactus/?ws=suppor t) Note In special cases, charges that are ordinarily incurred for support calls may be canceled if a Microsoft Support Professional determines that a specific update will resolve your problem. The usual support costs will apply to additional support questions and issues that do not qualify for the specific update in question.
The problem is the stupid Microsoft's cicle release. That kind of fixes won't ve delivered via windows update unless they're really critical, but through service pack updates. IOW: You'll have to wait until 2007 (service pack 3 planned release date I think) if you're lucky. Notice that this bug was introduced by service pack 2 BTW
They usually tell you to "contact" Microsoft through a number phone to get a patch if you want to get it earlier, something like this:
To resolve this problem, contact Microsoft Product Support Services to obtain the hotfix. For a complete list of Microsoft Product Support Services telephone numbers and information about support costs, visit the following Microsoft Web site: http://support.microsoft.com/contactus/?ws=suppor
Which is really a really stupid way of doing things for a company that claims to be number 1
He's not "against" the new revision. He just made clear that the kernel will not, and probably can _not_ be switched to GPL v3. He just said that the linux kernel license has _aways_ been GPL 2 and that it's not going to change just to explain people that a GPLv3 kernel is not going to happen
/. equivalent (barrapunto.org), you can read today some crap like "GPL: Linus says no, Debian says yes". Linus doesn't even says he doesn't likes GPLv3 (except for the keys thing). What makes people think that he won't use it for other projects like he did with GIT or sparse?
And this is going to happen for ALL the projects that have not a "at your option, any later version...". What about commercial products, say QT, will trolltech license QT against GPL v2 like it does now or V3?
I agree with the top post. This is a non story. In the spanish
Being Linus must suck. No matter what you say, there's people who misinterprets you even if you rejected jobs at redhat just to maintain neutrality WRT other linux distros. It's just like the BK history: When Linus started using bitkeeper he said that he'd never force people to use BK if they didn't like it, that it was a tool to help himself on the development and that he'd accept traditional patches from the people that didn't want to use BK. Other developers (lots of them) used also BK just because BK was good and saved them time, not because they were forced to get their patches in (alan cox, for one, didn't use BK). All the kernel releases and -rc patches where always available in diff format and in fact it was possible to get nightly snapshots GNU diff patches. But hey, even he didn't forced anyone to use BK everybody thinks he did - now everybody is starting to put him as a the "anti-GPLv3 bad guy"
Well, pretty much any company that implemented a DRM-protection scheme for its documents is going to be banning cameras in the work place anyway.
Really? Could you give me the name and localization of some of those companies? I'd like to have a new computer for free...
The also announced that they've shipped 1M of core duo chips.
Obviously, both announcements are trying to stop the stock fall (which started when Intel announced that they haven't hit the sales predictions). Not that AMD doesn't do the same, they've used the same trick several times just like any company.
It's how capitalism works: People is free to invest were they want and do what they wan but what happens if we try to influence what people wants?
(By the way is ironic how capitalism is good because it allow companies to have more freedom to do things in their "system" but freedom is being limited in the US for "security purposes". I'd guess that if I'd propose to take away some of the freedom that capitalism has to fix some of the problesm the world has like poverty etc people would call me communist or something)
Corporations (and even some individuals) need strict control of their private data
I wonder how people plans to fix that with DRM. Once a DRM'ed document is loaded in word, you can jump the drm protection by....taking a screenshot? Oh well: The operative system may forbid to take screenshots of the windows that has DRM content (like mac os x does with DRm'ed videos I've been told). You may get your digital camera or even a vigilance camera could do it (you don't need to be 007 to do that).
But well, the operative system is also handling the data, so it has to be somewhere - what about a program that spies when you cut a piece of text?
Want to "secure your data"? Well, just use pgp to cypher it - hell there're guis for that - and store your private key in a usb key, nobody will be able to read your PGP'ed document. I don't see how DRM solves ANY problem.
I'd say that this is "relative": at the start of the COPYING file , I read: "GNU GENERAL PUBLIC LICENSE Version 2, June 1991". I'd say that it looks like Linus has modified the COPYING file on purpose just to _clarify_ the original intentions.
Oh well - so you don't like GPL, be it v2 or v3. I happen to think that the GPL is one of the few licenses that REALLY helps me to have free/open software. Other licenses (say, BSD) allow companies to relicense a copy of the software with another license or even close the code.
There's nothing wrong with that. But I happen to think that in this world companies are already having too many ways of getting money - DRM and software patents, for one - and they don't need help from hippy university students.
I laught when companies say "we don't like the GPL, it doesn't allows to use thousand of lines of code without forcing us to get back the changes", like being able to close the source were the one way to keep the company up. Then at the following day you see the financial results of that quarter and the company happens to have a couple of thousand of millions of dollars in cash but hey, GPL is "not free, it doesn't allow us to do what we want, it doesn't adapt to our needs". And the following day the company hires some lobbies to get software patents and DRM in Europe.
Is not that I hate companies - I love capitalism - I just don't understand this "ooh poor of us those free software coders are releasing code under the GPL license which is too restrictive and viral". Those companies have enought money to write a new operative system from scratch without using code from anyone else (I've nothing against that, I'd even bought and pay for it if it's a good product), stop pretending that GPL is "too restrictive". So uh, maybe companies and some people like you thinks that GPL is "too restrictive". I happen to think that is great, and I've only heard good things from the GPL v3 version.
And even if it could, it doesn't neccesarily means that GPL v3 would be useful for the kernel. Let me quote a mail from Linus on the matter from a couple of hours ago:
> This means that when the code went GPL v1 -> GPL v2, the transition was
> permissible. Linux v1.0 shipped with the GPL v2. It did not ship with a
> separate clause specifying that "You may only use *this* version of the GPL"
> as it now does. (I haven't done any research to find out when this clause was
> added, but it was after the transition to v2).
Bzzt. Look closer.
The Linux kernel has _always_ been under the GPL v2. Nothing else has ever
been valid.
The "version 2 of the License, or (at your option) any later version"
language in the GPL copying file is not - and has never been - part of the
actual License itself. It's part of the _explanatory_ text that talks
about how to apply the license to your program, and it says that _if_ you
want to accept any later versions of the GPL, you can state so in your
source code.
The Linux kernel has never stated that in general. Some authors have
chosen to use the suggested FSF boilerplate (including the "any later
version" language), but the kernel in general never has.
In other words: the _default_ license strategy is always just the
particular version of the GPL that accompanies a project. If you want to
license a program under _any_ later version of the GPL, you have to state
so explicitly. Linux never did.
So: the extra blurb at the top of the COPYING file in the kernel source
tree was added not to _change_ the license, but to _clarify_ these points
so that there wouldn't be any confusion.
The Linux kernel is under the GPL version 2. Not anything else. Some
individual files are licenceable under v3, but not the kernel in general.
And quite frankly, I don't see that changing. I think it's insane to
require people to make their private signing keys available, for example.
I wouldn't do it. So I don't think the GPL v3 conversion is going to
happen for the kernel, since I personally don't want to convert any of my
code.
> If a migration to v3 were to occur, the only potential hairball I see is if
> someone objected on the grounds that they contributed code to a version of the
> kernel Linus had marked as "GPLv2 Only". IANAL.
No. You think "v2 or later" is the default. It's not. The _default_ is to
not allow conversion.
Conversion isn't going to happen.
Linus
"Is a licensing fee required for access to the Macromedia Flash file format (SWF)?
There are absolutely no access or deployment fees required to use the Macromedia Flash File Format Specification."
Try reading the FAQ next time?
We can always debate whether or not proprietary or open source development models produce better quality code, but proprietary formats are never good. All they do is hurt competition, which helps no one but the authors. Now that Adobe owns Macromedia, hopefully the Flash people will take a hint from PDF: open formats work. If SWF is opened, great
Shocking news: The SWF format IS open: Here you have a link. The license is quite similar to PDF. I think it's somewhat more restrictive to create tools which create SWFs or something but what the hell, stops saying that SWF is closed.
Just because the open source community hasn't managed to write a decent implementation of the PDF format doesn't mean. Actually, people has tried to write implementations (way before that GNU thingy by the way): Google for libswf. There's even a gstreamer plugin which uses libswf to draw flash animations (and it works for simple flash files, I've used it). Dude, in my machine nautilus shows me thumbnails of some flash files. Also, macromedia has written a linux flash player plugin for mozilla-based browsers, I wish all companies would do that.
Congratulations, a company who wins millions of dollars has bought your opinion and mind and free advertising force for a CPU which costs 40 dollars to produce (give/take 10 dollars for amd). In fact they may have given you one of those CPUs that doesn't pass all the quality tests.
Indeed! It's like you would say that it's much easier to find bugs just after the first release of the CPU and even easier when it's the debut of a completely new architecture like the Core Duo is!. It'd be like posting links to the AMD errata docs!
like bugs in CPUs are something new....I want to know how many bugs where found in the first 20 days of the release of other intel architectures and the opteron, otherwhise I can't know if the core duo is a bad CPU compared with others or not. This article just looks like anti-intel FUD from AMD fanboys (Intel made a good CPU even with the bugs, deal with it, AMD is not going to give away free CPUs to you for being a fanboy).
And let me doubt that there's any CPU manufacturer at all that releases CPUs without any "know bug", many CPU bugs are fixed with microcode updates via new bios versions. There's a reason why both amd and Intel CPUs allow to update the microcode, they don't include features for fun.
Makes sense... And after all, people porting code to run on other OS's *really* enjoy re-writing huge chunks of Linux specific junk...
Oh well. People porting code to run on other OSs enjoy when linux rewrites large parts of linux-specific junk; and users say linux it sucks because Linux keeps using the same useless standard crap that OSS is. I'd rather have a technoloy that doesn't sucks than one that sucks but is portable.
How you get to binary compatibility involves declaring certain structures off limit for direct access (use accessor routines), stabilizing at least parts of others, and possibly adding versioning interfaces in key places
You really need to read the numerous documents about why linux does not want a "stable abi". There ARE projects which have implemented a binary ABI. Everybody has ignored them.
Not likely, as long as the GPL fanboys/fangirls insist that binary device drivers are evil.
You really need to read why linux people does not want "stable abi". Linux is a operative system - just face it.
No, we should bitch the companies for allowing their cards to boost the TX power beyond a certain threshold. If the card can go beyond the limits, then the card should NOT pass the FCC regulations, period. Instead, they allow cards to go beyond the limits. And opensource drivers allow you modify the source to do it....news at 11.
Again (for about the third time, I realize)... that's not how businesses think. If you're going to support a given platform, you do it WELL. That means testing. That means QA engineers.
And exactly what is stopping businesses from supporting, testing, doing QA, and releasing the source of the driver to merge it in the main linux tree? That's how you do things "well" in the linux land. People like 3Com, Intel or adaptec are releasing AND maintaining drivers for their devices in the linux tree TODAY (there's a reason why I keep buying intel stuff...).
Let's stop this: Companies CAN support linux if they can. They're companies doing it (check the linux kernel mailing to see people from different hardware companies sending patches). Supporting linux is possible TODAY. Most of the companies just DON'T bother
Maintaining a database of all the hardware which works for linux is hard, it'd be asier to keep track of what hardware doesn't work. These days we have MODULE_DEVICE_TABLE: in every module: This exports the list of the IDs that every modules support. Recolect the IDs of all modules and you'd get a sort of automated database of all the devices supported by linux
/dev/dsp directly....
Soundcard support is pretty decent, until you realize the OS often implicitly locks-out multiple apps from outputting audio.
Applications using alsa doesn't suffer such problems. Stop using apps that use
Linus (and others) *do* tweak the kernel API on a regular basis.
Well, "tweak the kernel API" is not the same than "tweak every API in the kernel"
Notice that the huge majority of the thousands of drivers inside the kernel doesn't have any changes at all between releases. It'd be crazy if the kernel needed to modify all the drivers for EVERY release. That's certainly not true. Some of them change, sure - when a given subsystem changes something. It doesn't happen every release. You can check it in the git web interface. Some drivers have not had any commit for MONTHS. In fact most of the commits you'll see in the changelogs are internal driver changes, not changes needed to make the driver work with a new api. Some drivers however (ej: the propietary nvidia driver) need changes. If they didn't put a entire opengl stack inside the driver things would be easier. Who knows.
Of course, that's source. At binary level, everything changes. You can't load a kernel module compiled for another kernel version: There're checks to avoid that: Even for the cases where it could work. Many plugin-based apps (drivers are more like plugins, not "programs built in top of the kernel api") require that too. Linux is not a closed source kernel and we don't want that it becomes one.
Windows XP maintains the compatibility, yeah. They've rewritten the USB stack 3 times or so (just like linux) and they maintain the compatibility for all the drivers supporting the 3 different stacks. Just imagine how horribly complex and hard to maintain and evolce the XP kernel has to be.
Some drivers are already implemented in userspace - see libusb.
Linux has certainly come to a point where it's easier to make a list of hardware that doesn't work than making a list of hardware that works. From a historic POV, even with cases like this linux looks promising: Linux used to be a crappy OS made by students without support from big enterprises and well, it ended up supporting lots of things. These days it's a good OS made by professional programmers and support from big companies - future can't be as dark as the "build a stable api or linux won't be usable on the desktop!" people says.
Notice that vendors are not being asked to modify the drivers in each release. We're asking them to release open source drivers - "we" will do the neccesary job to integrate them and maintain them in the kernel. Hell, release drivers even if they're against a 2.4 kernel, people will port them to 2.6, it won't be easy but it's certainly easier than reverse engineering or writing the driver from scratch (unless the drivers is a complete crap)
So the "unstable API" has not sense. By the way, notice that the kernel API _is_ stable: for a single version. No, this is not a joke: The new development model implies that EVERY kernel release is a mini-development kernel which can be stabilized in ~2 months. In other words, make progress slowly, gradually, instead of big development releases which are a pain to manage and stabilize, because there're thousand of new things instead of just a couple: It's much easier to find bugs when there're few important changes. Also the new kernel development model forces people to test things and develop production-ready code after testing it in the -mm tree, in a typical development model people tends to care less about making things stable until the "stabilization period" starts. Call me stupid, but I like this model.
This is a fake leak. AFAIK Microsoft has to release a "IE7 Beta 2" (a public beta, available for everybody). So this HAS to be a real beta version.
you english speakers keep changing all the words what did you expect :(
oh yes...that....was exactly what I wanted to say, sure. It was...ironic; we the intelligent people use that kind of things. It's a shame general_re didn't get it.