Slashdot Mirror
Intel to Increase Linux Support, Release Centrino Drivers
jonman_d writes "ZDNet UK is reporting that Intel has promised to increase Linux support by releasing Linux drivers at the same time it releases Windows drivers for its hardware. According to the general manager of Intel's Software and Solutions Group, Intel wants Linux users to be able to use their hardware as easily, or easier, than any other hardware on the planet." Pingla writes in with more good news: "Intel promises to release Linux drivers for its Centrino chipset at the same time it releases drivers for Windows. An article featuring Lindows (aka Lin---s) on CNet has more." Sadly, the Centrino support will most likely be a proprietary driver, but it's better than nothing.
Sadly, the Centrino support will most likely be a proprietary driver, but it's better than nothing.
I'll take proprietary drivers if it means I can use the hardware I like with the OS I love to get work done.
I don't think it matters if this is a proprietary driver, just yet. With big people like Intel and IBM showing an interest in Linux, its bound to encourage others to do the same. Then with time, open source drivers might just happen?
It's nice that one of the giants to adopt this position, but I wonder about the form of these drivers. Maybe it's me, but I find more convenient to have drivers that can be compiled as kernel modules, and diffently from, for example Nvidia drivers, that they're not closed source, and license-compatible with the Linux kernel, so people can contribute in order to improve them, and maybe who knows if they can be integrated in the Linux kernel tree. Maybe i'm being too idealist.
If you really care about freedom, then help reverse engineer the drivers. Several drivers have already been reverse engineered (such as nvnet for example), whats so hard about a simple wireless network adapter!
what is so secret about them, really?
To use them for your own hardware, don't you have to create the exact same hardware? So no use there, since you have your own hardware...
To use the hardware independet part of the code? Well.. that ought to be a lot of code.
To use their algorithms? Well, there are a lot of code already they can have a look at (without telling they looked at it, if they are evil)..
And if they are to stupid to come up with an algorithm of their own, how expencive would it be to hire someone to do it?
I don't get it...
Evolution of Language Through The Ages: 6000 BC : ungh, grrf, booga 2000 AD : grep, awk, sed
Intel is announcing plans to release Linux drivers for the WLAN part of their centrino technology from the time beginning. Though there are no facts yet, no release date, no statement whether the drivers will be binary only or Open Source, no information which chipset generations will be supported eventually and so on. See details of the story and How to Get Linux Running on Centrino Laptops at TuxMobil. So don't miss to sign the Linux Support On Centrino Petition! More at the link above.
With that said, this is a step in the right direction and I hope other hardware manufactures do what Intel has pledged to do. Closed source, proprietary drivers are better than no drivers at all.
Actually I do get sad when I get in my car with a proprietary computer under the hood. I enjoy "tinkering" and doing minor maintenance to my car, but something as simple as an oxygen sensor now requires a $50 trip to the dealer to tell me this is the reason why my check engine light is on.
It might be a small marked, centrino together with linux, but they are pissing off a lot of people unnecessary. Many of these people have influence in companies buying computer hardware, not only laptops but servers and workstations. Good way to make the bias towards AMD stronger.
My job gave me a dell laptop where I am not using the wireless at the moment (I don't dual boot). I am reminded everyday why the next server will be opteron since I am in charge of buying the new one.
--- guns don't kill people, people with guns kill people ---
Though it's not an open-and-shut simple approach, one can imagine a closed hardware management layer, driven by an open, developer-manageable O.S. software management interface layer. This doesn't solve the instruction-set incompatibility problem, but it is possible to let open maintainers handle the work they are (very) good at: Accommodating changing kernel interfaces, races, etc.
Linus is on record stating that as uncomfortable as it is, proprietary binary-only software can be linked into the kernel as long as it is not a derived work, meaning not depending on any interface provided by the kernel.
So Intel can preserve their private, secret register settings, providing a controlled abstraction of the hardware, and still tolerate, to some extent, varying kernel interface requirements.
The situation is pretty infuriating with the video drivers for laptops with integrated graphics on 855GM chipset. Many of these come with a 1400x1050 SXGA+ lcd display but a bios that does not know how to switch to this mode. (No kidding, it can do 1024x768, 1280x1024, etc, but NOT the native lcd resolution...) Intel has not released specs to let the XF86 developers program the video modes from the driver, so X Windows is entirely dependent on the BIOS.
Result is your spiffy new SXGA+ laptop with Intel integrated graphics can only do a fuzzy interpolation at lower effective resolution. Needless to say, the Windows driver authors had all the info they needed to program the driver.
And you guess what trouble you will have getting the laptop to display on an attached external monitor....
Intel needs to provide specs to the XF86 developers, so that they can provide good drivers for Linux!
Seriously. This is not a troll, so hear me out here. I love Linux and I won't use anything else, including on my desktop.
The real problem here is Linus's stubborn refusal to freeze the driver API's. At the very least, the driver API's should be frozen during each major release cycle; i.e. a driver which loads on 2.6.0 should continue to work properly on 2.6.999. If there are big new exciting things that force an API change, it should wait until 2.8.0.
I say that this is Linus's fault because it's well-documented that the moving-target API's are his clear decision. And it's a bad decision. If he wants large-scale adoption of Linux at the end-user level, he's going to have to realize that most end-users aren't smart enough to do their own driver integration -- but they might be able to download a driver off the 'net or from a CD, and see "Gruntle FOOset driver for Linux 2.6" and expect that it'll work on any Linux distribution that includes a 2.6 kernel.
Until the driver API is stabilized, Linux is going to have a hard time finding users outside the hacker set.
Tired of FB/Google censorship? Visit UNCENSORED!
Does this mean that we're more likely to get Palladium aka Trusted Computing to work with Linux? If Intel is interested in making sure that their boards work with Linux, this seems like a good start to keep Microsoft from tying up the hardware...
--
$tar -xvf