Slashdot Mirror

Lol, right. I mean, companies would just love spending billions of dollars to develop something and then having a rival just pick it up and copy it. That would _totally_ spur innovation, dude!

Yeah, you're right. The concept of open sharing sure hasn't spurred innovation in the past...

Linux has been rock-solid from version 1. Version 3 isn't being planned yet.

Saying that linux is at version 2 is disingenuous at best. If you're going to play at that, let's start by saying that Linux (the OS) doesn't /do/ mail. Exchange (not an OS) would be competing against a variety of MTA and mailbox formats and protocols -- sendmail, qmail, postfix, exim, mbox, imap, pop3.

PS if you think anything running the linux kernel v 1.0 was rock-solid, chances are you weren't using it then (but you're welcome to rock it like it's 1994 again: here. NB that only single-cpu i386 machines need apply; nothing else was supported until 1.2 in 1995.)

in the press release there is no mention of support for the 5007 chipset built in to the eee :(

however, look here: http://wireless.kernel.org/en/users/Drivers/ath5k for more information.

Belkin
* N1 Wireless Notebook Card

D-Link
* DWA-642 RangeBooster N Notebook Adapter
* DWA-645 RangeBooster N650 Notebook Adapter
* DWA-542 RangeBooster N Desktop Adapter
* DWA-547 RangeBooster N650 Desktop Adapter
* DWA-652 XtremeN Notebook Adapter
* DWA-552 XtremeN Desktop Adapter
* DWA-643 Xtreme N ExpressCard Notebook Adapter
* DWA-556 Xtreme N PCIe Desktop Adapter

Linksys
* WPC300Nv2
* WMP300Nv2
* WPC100N
* WMP110N

NEC
* WL300NC

Netgear
* WNHDE111 Video Bridge
* WN711, Wireless-N eXpresscard adapter

actually, this problem comes up now and then, and as can be seen on the bugreport, there was another person reporting very similar symptoms. which can be observed by reading it.

Accelerated framebuffer on console is not an essential feature -- it may be nice to have, but you can't expect every piece of hardware to have it. On general-purpose computers now used for two purposes -- last-resort fallback X driver (that is only necessary if there is no usable native driver) and for boot splashes.

rrright, because in this context we are talking only about "worksforme" things. this is a quite perfect example of the attitude this very same article/discussuion is about. if somebody reports a problem, a lot of energy is wasted to dismiss it, starting with blaming the person as just having googled the bits, then attempting to invent explanations why, you know, there is no problem actually !

Your bug report does not contain anything related to BIOS, kernel messages that would shed some light on possible ACPI or driver misbehavior, etc. I am surprised that it was accepted as a bug report at all, because it does not follow the format of a kernel bug report ( http://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html ).

i don't see such attitude that often, so i was a bit surprised about the amount of complaints - but i guess there are a lot of people who will never admit there is a problem. it all depends on what kind of a person user initially stumbles upon... being ridiculed for reporting problems will surely increase testers for the project.

Again, if no one can reproduce it, no one can fix it. On the other hand, it's well known that many laptops shipped with faulty ACPI BIOSes that only kinda work with Windows ACPI implementation (it was encouraged by Microsoft), and manufacturers provided fixed BIOS versions later. You didn't mention the BIOS vendor and release, and did not try to find the updates that could be released by the laptop manufacturer.

After a minute of googling I have ended up at Fujitsu FAQ page for that laptop -- complete with typical broken-ACPI-related problems and with urging the users to update their BIOS to the latest version.

Again, this brings me to my initial point "people who want to 'fix' Linux advocate for a worse Linux" for me a Linux with a fixed API this this argument: http://www.kernel.org/pub/linux/kernel/people/gregkh/misc/2.6/stable-api-nonsense-2.6.10-rc2.patch

(Why does every line start with a +? It's unreadable. Is that someone's weird-ass quoting email client?)

If you want to take that position, that's fine. But that position is incompatible with having lots of drivers on Linux, full stop. Asking hardware developers to document every single bit of their hardware is a gateway to litigation for them; they'll get sued. Your wifi card maker does it? The FCC puts them out of business. ATI or NVidia does it? The software companies they've licensed from sues them to the stone-age.

You're welcome to think that only open source drivers are ok, but if you do, you'll never have a lot of drivers, and you need to simply accept that fact and stop complaining about it. No amount of Linux goodwill will get a company past, "not only are Linux drivers harder to make and maintain, but you'll get sued or fined too!"

In any case, I wish you'd said this right off the bat, as it indicates that you do not, in fact, want Linux to have more driver support. Much like anybody saying they oppose nuclear power is communicating to me that they aren't actually environmentalists.

Again, this brings me to my initial point "people who want to 'fix' Linux advocate for a worse Linux" for me a Linux with a fixed API this this argument: http://www.kernel.org/pub/linux/kernel/people/gregkh/misc/2.6/stable-api-nonsense-2.6.10-rc2.patch

It's a trade-off that Linux people are willing to take. People who want something else can use BSD or some other operating systems... or they can continue to bitch. BTW, I think BSD has fixed API... what good did that do to BSD, I haven't heard of people saying "I'm going to use BSD instead of Linux because it has more drivers"

Only happens on NON-LAPTOP computers with analog LCD monitors (solution: press "Auto-Adjust" and "Save" on your monitor while console text is displayed).

http://bugzilla.kernel.org/show_bug.cgi?id=6523

Only happens on LAPTOP computers (who hibernates a desktop?, solution: update BIOS to a non-broken version).

http://bugzilla.kernel.org/show_bug.cgi?id=5621

Now, please, tell me, how did you encounter both "problems" at the same time, and if they aren't in fact the result of a google search for "linux problem"?

now, tell me, are you just trying to give us all an example of how arrogant and useless some persons can be ?
as one can see from the above reports, i encountered both of these issues on a single machine. i reported them in the kernel tracker (as good as i could), i was ready to patch, compile and debug as much as required. and that's way more than the average user is willing or able to do, especially if met with such an attitude.

Only happens on NON-LAPTOP computers with analog LCD monitors (solution: press "Auto-Adjust" and "Save" on your monitor while console text is displayed).

http://bugzilla.kernel.org/show_bug.cgi?id=6523

Only happens on LAPTOP computers (who hibernates a desktop?, solution: update BIOS to a non-broken version).

http://bugzilla.kernel.org/show_bug.cgi?id=5621

Now, please, tell me, how did you encounter both "problems" at the same time, and if they aren't in fact the result of a google search for "linux problem"?

now, tell me, are you just trying to give us all an example of how arrogant and useless some persons can be ?
as one can see from the above reports, i encountered both of these issues on a single machine. i reported them in the kernel tracker (as good as i could), i was ready to patch, compile and debug as much as required. and that's way more than the average user is willing or able to do, especially if met with such an attitude.

Scanners
http://www.sane-project.org/sane-supported-devices.html

wireless NICs
http://wireless.kernel.org/en/users/Devices/USB

digital cameras
http://www.gphoto.org/proj/libgphoto2/support.php Note that any camera that works as a USB storage device (most these days) will work also.

3D video cards
AFAIK, there are no sites anymore, but all current cards along with any card AGP, PCI, or PCI Express card made within the last 5-8 years or so that have ATI or NVIDIA chipsets will certainly work on any x86 Linux PC with the appropriate slot available. The support for many on-board video cards that are not NVIDIA or ATI, such as the popular VIA Chrome9 and Unichrome chipsets is available, but the support for it is sketchy at best unless you're willing dive into CVS or SVN repositories and grab in-development drivers. Even then, last I checked (about 6 months ago), these drivers were unstable as hell.

other hardware
check the forums on http://linuxhardware.org.

This list is hardly complete. In the next week or so, look for me to compile a more complete resource guide and post it at http://rob.shinn.googlepages.com/ . I'm doing it because I get tired of answering questions like "Where do I go to find out what [printers|scanners|alien mothership interfaces|...] work on Linux?"

Shotgun:

    It's his toy. He can call it whatever he wants.

    You know it's called Linux ... right? That's because his name is Linus ... yup that Linus the one man who started all this.

    At ftp://ftp.kernel.org/pub/linux/kernel you'll find em' all with dates etc.

    We will all happily go along with whatever he wants or I will hunt the dissenters down and ........ oh I dunno, geotag em' with a lawn dart.

      "Users" was once an insult but I digress.

(because surely someone must care)

If the 2.6 is not going to change, drop it, it's redundant.

So we're down to 26. I personally find a name like "Linux 28" to be cool. "Linux 41 was released today...". There's nothing wrong with big numbers: see udev.

The problem with date-based numbering is that when you go from 2008.4 to 2008.10, it looks like you missed a few releases. And if you pre-announce a release, you have to meet your deadline or else rename the release.

So they could do what Gentoo does - 2007.0, 2007.1, 2008.0, 2008.1, etc. But you still have the problem that every year, you lose count of how many releases have happened. Was there a 2007.2 or did we just go to 2008.0 because we missed the Christmas deadline due to that last-minute security bug?

They could reduce the problem by using a longer period, such as a decade. (At 6 months for a release, for example, the number will only reach 20, which is not large.) But that's somewhat arbitrary. Plus, being in the 0th decade, we don't want to have 2.6.30 be called 0.3.

To reduce the complexity on all that, just drop the dates, and what's left is a single big number. No dots, no multiple numbers, easy. Linux 112 is fine by me.

I just ran across this nice example for a damaged packet - packet drops outside of the IP world can end pretty bad:

http://userweb.kernel.org/~warthog9/damaged_server/

According to the frontpage, this is git.kernel.org

Defensive fanboi bitch.

http://bugzilla.kernel.org/show_bug.cgi?id=9489
Hand over your mod points.

the wakeups been there from long time ago. at least since 2.6.23 or something, the bug's here:

http://bugzilla.kernel.org/show_bug.cgi?id=9489

There was a neat study that Greg KH did about corporate contributions to the kernel, which has us at a not-too-shabby 13th.

Any word on when they're going to fix the even older "Too many arguments" bug?

Use linux instead.
CHANGELOG
git commit

It's both. The kernel is responsible for setting up the execution environment, and in the past it used a fixed 32 pages for the arguments. 32 pages on an ordinary PC is 128KiB, which is the old limit. The new limit is that any one argument can be up to 32 pages, and all the arguments taken together can be 0x7FFFFFFF bytes, which is ~2GiB.

Here's the diff: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b6a2fea39318e43fee84fa7b0b90d68bed92d2ba;hp=bdf4c48af20a3b0f01671799ace345e3d49576da

After that, it was up to libc people to fix the globbing routines. Ulrich Drepper, taking some time off from his full-time job of being an asshole on mailing lists, managed to work this into glibc 2.8:

http://sourceware.org/ml/libc-alpha/2008-04/msg00050.html

*Ctrl-Alt-Delete
http://www.cad-comic.com/rss/rss.xml
Stupid webcomic
*Looking for Group
http://feeds.feedburner.com/LookingForGroup?format=xml
Webcomic.
*Least I Could Do
http://feeds.feedburner.com/LICD?format=xml
Webcomic.
*Linux Kernel
http://www.kernel.org/kdist/rss.xml
(no explanation)
*NationStates
http://69.60.14.82/cgi-bin/rss.cgi?nation=windhelm
A sort of game where you have to govern a nation. I develops based on the laws you vote.
*Questionable Content
http://www.questionablecontent.net/QCRSS.xml
Webcomic
*The Book of Biff
http://feeds.feedburner.com/TheBookOfBiff
Webcomic
*The Perry Bible Fellowship
http://pbfcomics.com/feed/feed.xml
Webcomic (not updated i a looong time)
*VG Cats
http://www.vgcats.com/vgcats.rdf.xml
Stupid and bad webcomic
*xkcd
http://www.xkcd.com/rss.xml
FANTASTIC webcomic
*Linux Journal
http://feeds.feedburner.com/linuxjournalcom
I dunno why it's in there. I like the articles
*Slashdot
http://rss.slashdot.org/Slashdot/slashdot
I guess that's about it. I'm going to delete a couple of webcomics though. Some are just too awful.

Are you shitting me?
Linux Kernel version 2.0
http://www.kernel.org/

Well, Linux (at least the kernel) is mainly analyzed with Sparse, a tool started by Linus himself.

The linux kernel developers use a tool originally written by Linux Torvalds for static analysis - sparse.

http://www.kernel.org/pub/software/devel/sparse/

Sparse has some features targeted at kernel development - for instance spotting mixing up kernel and user space pointers and a system of code annotations.

I haven't used it but I do see on the kernel mailing list that it regularly finds bugs.

It's hard to test whether you've broken a driver when you don't have the hardware to test with. Perhaps the future will be Qemu emulation of all the different hardware in your system : )

This is not to say that there need to be tests for things that can be caught at compile time or run time regardless of hardware but there is only so far you can take it.

It's not like the kernel doesn't have any testing done on it though. There's the Linux Test Project which seems to test new kernel's nightly. If you ever look in the kernel hacking menu of the kernel configuration you will see tests ranging from Ingo Molnar's lock dependency tester (which checks to see locks are taken in the right order at run time), memory poisoning, spurious IRQ at un/registration time, rcu torture testing, softlockup testing, stack overflow checking, marking parts of the kernel readonly, changing page attributes every 30 seconds... Couple that with people like Coverity reporting static analysis checks on the code. Tools like sparse have been developed to try and so some of the static checks on kernel developer machines while they are building the code.

But this is not enough. Bugs STILL get through and there are still no go areas of code. If you've got the skills to write tests for the Linux kernel PLEASE do! Even having more people testing and reporting issues with the latest releases of the kernel would also help. It's only going to get more buggy without help...

I didn't read all of the kerneltrap stuff, but isn't it true that the CONFIG_PREEMPT_RT folks have made some good headway here?

I don't believe the -rt patch is expected to perform well as a drop-in replacement everywhere, or on systems that have management interrupts, but I think for people interested in real-time programming, the rt patch is a good starting point.

Uh...you can read the code. People has read the code and there's nothing "hidden" on it. People who thinks that SELinux allows the NSA to enter your computer are just clueless.

But unless that mystery instruction sync's all the processors' caches (and registers, if your compiler decided to put your variable in a register), you will still have these errors.

Mystery instruction? It's well documented.

I was hinting at the fact that we are talking of an unnamed system with unnamed processors. It makes it harder to give a qualified answer

Also, anything you need communicated to other threads needs to be put into what C++ would call a "volatile" variable. You can't expect randomly-architected code to just magically work in a multithreaded context.

Volatile won't help you. Volatile just disables some optimisations, and does not sync the caches in the processors - which I admit your mystery instruction might, though I find it unlikely. Try reading volatile considered harmful - I know it is for the linux kernel dev, but it does a fair job of explaining the issues at hand. As an extract

In short, you almost never want to use volatile, unless you are manipulating memory mapped IO through a pointer or similar strange tasks. The key point is that volatile does *not* sync caches in any way.

At the risk of sounding "uptight", you sound like a very lazy programmer. You don't understand the subject of multithreading, you don't even read what I write, and yet you act as if your opinion has merit.

lol. You are cute.

First of all, Reiser4 is not dead at all. The namesys.com website is still down because it is hosted in the US and the developers are on the other side on the globe. Who cares. There is a new location here and here.

Reiser4 development didn't stall at all! the mailing list is not particular noisy but there are bug fixes on a regular basis and new patches generally come out some days after a new kernel release.

It still is in the mm tree and gets updated regularly. Public GIT repositories are also to come very soon. Due to its modular design (*cough* plugins *cough*) reiser4 could be particularly interesting for new coders and specialized tasks. We'll see...

My personal note: Reiser4 is surprisingly stable. I have it on several machines since it was officially released. Of course I run daily backups but I didn't have to use them once. Occasionally I saw corruptions but these were fixed by an excellent fsck (all this might as well be personal luck though ;).

Recently a show stopper bug in the (not yet officially released) compression code has been fixed. This not only gave me lots of extra disk space but actually a performance boost - disk io is the bottleneck here. Better not get me started on comparing performance to the zfs counterpart on fuse or freebs).

First of all, Reiser4 is not dead at all. The namesys.com website is still down because it is hosted in the US and the developers are on the other side on the globe. Who cares. There is a new location here and here.

Reiser4 development didn't stall at all! the mailing list is not particular noisy but there are bug fixes on a regular basis and new patches generally come out some days after a new kernel release.

It still is in the mm tree and gets updated regularly. Public GIT repositories are also to come very soon. Due to its modular design (*cough* plugins *cough*) reiser4 could be particularly interesting for new coders and specialized tasks. We'll see...

My personal note: Reiser4 is surprisingly stable. I have it on several machines since it was officially released. Of course I run daily backups but I didn't have to use them once. Occasionally I saw corruptions but these were fixed by an excellent fsck (all this might as well be personal luck though ;).

Recently a show stopper bug in the (not yet officially released) compression code has been fixed. This not only gave me lots of extra disk space but actually a performance boost - disk io is the bottleneck here. Better not get me started on comparing performance to the zfs counterpart on fuse or freebs).

First of all, Reiser4 is not dead at all. The namesys.com website is still down because it is hosted in the US and the developers are on the other side on the globe. Who cares. There is a new location here and here.

Reiser4 development didn't stall at all! the mailing list is not particular noisy but there are bug fixes on a regular basis and new patches generally come out some days after a new kernel release.

It still is in the mm tree and gets updated regularly. Public GIT repositories are also to come very soon. Due to its modular design (*cough* plugins *cough*) reiser4 could be particularly interesting for new coders and specialized tasks. We'll see...

My personal note: Reiser4 is surprisingly stable. I have it on several machines since it was officially released. Of course I run daily backups but I didn't have to use them once. Occasionally I saw corruptions but these were fixed by an excellent fsck (all this might as well be personal luck though ;).

Recently a show stopper bug in the (not yet officially released) compression code has been fixed. This not only gave me lots of extra disk space but actually a performance boost - disk io is the bottleneck here. Better not get me started on comparing performance to the zfs counterpart on fuse or freebs).

It has been addressed, and "the fix" will be in the point release.

I'd like to mention http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e2df9e0905136eebeca66eb9a994ca48d0fa7990, too.

Never mind. Found it on kernelnewbies, under "ath5k", I was searching "atheros".
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fa1c114fdaa605496045e56c42d0c8aa4c139e57

Most everybody moved to network printing years ago. It's working out fine.

In fact, a lot of direct attached peripherals can go away. Gigabit networks are fine for most stuff you used to attach devices directly to your PC for.

HP's linux support isn't really all that good. Most of what I've seen has been developed by third-parties.

HP supports linux. They have for a long time. Kernel.org runs on servers donated by HP and they have since 2001. Third party support for HP gear is also strong as you note. I only wish they'd wake up and start using it for their web server. Their site is hideous and slow, and for the most part their web stuff is IE only. Other than that, good on them.

Let me quote for you from a history article:

Fourth Generation:

As it become more apparent that the hardware needed an upgrade, Peter began to think about preparing a request to Hewlett-Packard for new hardware. Before he even made his request, HP contacted him basically saying, "hey, we noticed that you guys have been kind of struggling lately, what do you need?" Peter provided them with his wish list, and within two weeks the decision was made and new hardware was on the way. Peter noted, " HP came to us from a quite high level. They have been absolutely great."

Matt Taggart, part of the R&D lab within HP's Open Source & Linux Organization, noted that HP is a large company and that the different donations to kernel.org actually came from different divisions. "There are plenty of people in HP that recognize the value that kernel.org provides and that benefit (both directly and indirectly through HP's customers) from having it perform well," he explained. "This time the donation came for HP's Open Source and Linux Operation R&D Lab, but in the past they have come from other places such as the Industry Standard Server Division (the folks that do ProLiant)." He went on to add, "HP's IT organizations also use Linux and are big users of kernel.org, so it benefits them as well."

As for why HP has made these donations, Matt explained, "when possible, HP likes to help Free and Open Source software projects at the source. For example, if HP wants to contribute driver fixes for a piece of equipment that we ship, it is a better use of our time to work at the kernel.org level rather than duplicating effort by working individually with each distributor (or not being able to work with some at all). Providing kernel.org hardware is an easy way for us to give back to the project that has helped save us a lot of effort."

'nuff said.

Here you go:
http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.24.4

- One warning message was fixed (but not a compiler warning if that was what you ment).
- Two problems with new gcc versions were fixed.

But I don't understand what is wrong with fixing small errors or warnings. I have seen old projects that produce so many warning messages that it is impossible to spot the dangerous warnings from there. I actually started fixing warnings from one of these programs and find out fatal errors that could have caused program crash on quite normal error situations. So IMHO fixing warnings is just as important as fixing any other errors.

These theories for why drivers are closed source keep coming up. Dave Airlie's Kitten Killing article which states some (but not all) of your points:

1. The licensed parts may simply have to be rewritten by the community or go unimplemented. It's tricky but not impossible (if Sun can do it with Java...).
2. These folks allegedly employ the smartest people out there. They are probably already capable of reverse engineering binary drivers. If your competition can reverse engineer hardware as complicated as today's graphics card from a driver, well you had better be really concerned...
3. If it were to be released under and open source license then it wouldn't be illegal to redistribute the code. People will already solder cards to get more speed out of their cards so I would think depending on software lockouts would be too risky.
4. Certainly this is becoming more of an issue.
5. If you are making guarantees to someone like military maybe you should make sure that you can really fulfill your obligations?
1 can be worked around and 4 is turning into a growing problem. If you've done 5, well you are always on rocky ground.

Why is "linux" hard to pronounce? If you have problems with that probably it isn't for you. Oh, and btw the Linux pronunciation is documented.

What would you say about the grml project? Or about the overlengthy and oversimplified GNU Is Not Unix Image Manipulation Program Toolkit?

You don't need to test pre-CFS kernels...here you can find a linux vs freebsd benchmark where linux tops freebsd: http://www.kernel.org/pub/linux/kernel/people/npiggin/sysbench/

Looks like it didn't last for long:

http://www.kernel.org/pub/linux/kernel/people/npiggin/sysbench/

http://www.kernel.org/pub/linux/kernel/people/npiggin/sysbench/

This problems were fixed! Take a look here in scalability of the upcoming 2.6.25 and glib 2.7

As I understand it, the issue is not whether ndiswrapper is GPL or not, but whether it can use GPLONLY symbols or not. It is not the same thing. And that is not a Linus decision, it is the decision of the developers that marked their code as GPLONLY to begin with. GPLONLY code is code that is to be used only by modules released under a GPL compatible licenses. GPLONLY requires GPL but it is not implied by GPL, so you may well have GPL modules without GPLONLY requirement. Whether symbols are flagged as GPLONLY is a decision of the developer. Some developers might not have contributed any code at all otherwise. Quite clearly here you have non-GPL code (the proprietary drivers) using GPLONLY code via a passthrough (ndiswrapper). The fact that the passthrough is GPL does not change a thing. You are violating the will of the GPLONLY module developers. Hence the situation has to be addressed one way or the other. Linus simply noted that ndiswrapper has to respect the will of the developers whose code is used, i.e. either they talk to them and get a permission to use their code or they rewrite the GPLONLY code.

http://www.kernel.org/pub/linux/docs/lkml/#s1-19

Userspace programs don't link against the kernel. Additionally, from http://www.kernel.org/pub/linux/kernel/COPYING:

NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the linux kernel) is copyrighted by me and others who actually wrote it.

NDIS wrapper might itself be GPL but a kernel that uses it is not because the kernel is monolithic. Linus is actually giving everyone what they want.

What is this about GPLONLY symbols?.

EXPORT_SYMBOL_GPL was added ... To clarify the ambiguous legal ground on which non-GPL (particularly proprietary) modules lie. [and] ... To allow choice for developers who wish, for their own reasons, to contribute code which cannot be used by proprietary modules. Just as a developer has the right to distribute code under a proprietary licence, so too may a developer distribute code under an anti-proprietary licence (i.e. strict GPL).

Loading a non GPL kernel module makes the whole kernel non GPL and hard to debug because it's a monolithic program. Check out the Linuxant controversy of 2001.

Linus won't keep you from making and loading non free modules but he's not going to be responsible when changes break your module. If others would cooperate, this would not be an issue. The NDIS wrapper people will have to reimplement functions written by GPL strict coders. That kind of sucks for them but they can do it. If Linus were to piss off the GPL strict coders, NDIS wrapper still would not work because those coders would quit contributing. A project as large as the kernel demands give and take. GPLONLY was a nice compromise.

NDIS wrapper has never been a great idea. It puts you at the mercy of Microsoft bugs and malice all for the benefit of a $30 network card. The kind of card that needs NDIS wrapper is usually worst of class and should be shunned. It's brain dead much like a winmodem and the "firmware" game is intentional. The card maker wants to be Windows only so don't buy it. Sooner or later hardware vendors will have to come around.

Look at the second entry from the top in the changelog:

http://kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.25-rc4

The battle is over, the discussion is at end and Linus has already signed off a change to restore Ndiswrapper functionality.

Just in case you are NOT trolling :-) :

Finnish != a slavic language.http://ww w.101languages.net/finnish/

Oh, and Linus Torvalds has Swedish as his first language, like between 5 and 10% of Finns.

http://www.kernel.org/pub/linux/kernel/SillySounds/swedish.au

http://slashdot.org/ This page is not Valid HTML 4.01 Transitional! Result: Failed validation, 7 Errors http://kernel.org/ This page is not Valid HTML 4.01 Transitional! Result: Failed validation, 6 Errors http://wikipedia.org/ This page is not Valid HTML 4.01 Transitional! Result: Failed validation, 15 Errors http://www.fsf.org/ This page is not Valid HTML 4.01 Transitional! Result: Failed validation, 27 Errors Lets not forget, though... http://www.microsoft.com/en/us/default.aspx This page is not Valid HTML 4.01 Transitional! Result: Failed validation, 29 Errors

you can download a disk image, boot from the disk, and start being productive. It's a proven fix that worked for me.

Vista Repair Disk

I used it as soon as I started having problems with Vista on a new work computer and it's been smooth sailing ever since.