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
Seriously, Linus doesn't like propretary drivers and will happily make source code compatible but binary incompatible changes. Linus does not want to have to deal with proprietary binary compatibility crap for drivers. It just clogs up the kernel with a lot of dead wood and dead weight. For open source, Linus can integrated the code and ensure that any changes will be automatically propagated to these drivers. With proprietary drivers, his hands are tied.
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.
Totally agree here. Now if only we could have accelerated ati 9600 and broadcomm drivers, we would have clear sailing with emachines's AMD64 laptop.
To-do List: Receive telemarketing call during a tornado warning. Check.
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 ---
If it's so sad that Intel is going to provide proprietary drivers, do you get sad everytime you get into your automobile?
;^)
No, I get sad every time I take it in for service and have to pay $400 for a new computer control module to fix a problem that a new $75 generic open source controller could fix
try { do() || do_not(); } catch (JediException err) { yoda(err); }
If they want to make it easiest then they should submit code to the Linux kernel. That way the next version of almost every Linux would support that hardware straight away automatically.
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!
Great. So where are the frickin' drivers for all the Intel USB cameras?
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
You've obviously never had the luxury of using a Centrino laptop. A 1.6 ghz laptop that performs like a 2.4 with a 7 hour battery life. Hmm quite outdated I'd say.
802.11G isn't even supported by Cisco yet so it is far from being a standard.
I did some reading on the linux kernel mailing list and the general concensus between the developers seems to be that binary-only drivers as modules for the linux kernel are not legal.
The only case they sited as a legal binary only module so far was the nvidia video card driver because the driver was not written for linux, it was written for windows and merely repackaged into linux.
The concensus seemed to be that a driver written specifically *for* linux is a derrivative work and therefore must be GPL'd.
Liberty.
This will be a binary only release, pretty much hands down, pretty much precluding the more esoteric and non US centric distros getting a driverset. Still the big deal for me isn't distro, OS lockin because of drivers is no news to me.
I sit here typing this on my Presario X1000 which would not agree to function with the DriverLoader hack. The only way I'll be able to get reliable support for mini-PCI wifi will be to replace the intel card with something like this.
Hell I'm not even worried about the wifi drivers until I can actually get decent battery life. Maybe if the speedstepping was 100% complete and verfied by an intel OSS coder then I'd take this to heart. Until then, this is just more of the same empty promises Linux drivers are "under development" and have been for nearly a year for the wifi, from intel's page anyways.
Until after i actually see the crap they promise. I'll stick with AMD and superior add-on/pcmcia cards that have native linux support.
Intel is pschizo. They "support" linux, they don't support linux. They say one thing, do another. They are, in a sense, merely Bill Gates' and M$'s Poodle.
Boycott Intel until they pull their multiple personality head out of their anal sphincter and actually go OS neutral the way a CPU maker SHOULD be.
In Bushworld, they struggle to keep church and state separate in Iraq as they increasingly merge the two in America.
The grandparent was not talking about 3D or Xvideo or DRI. Those do fine.
The problem is that there is no information released about how to program the display resolution directly. So XFree86 has no way to do so, not because of some limitation of its capabilities but because of lack of information. What XFree86 has to do now is to rely on routines in the BIOS to set the video mode. The amazingly stupid thing is that laptops are shipped with 1400x1050 resolution but BIOS support to set the native resolution. So XFree86 cannot do it. Windows and XiG do it because they have specs needed for the server to program the resolution directly. XiG might be a viable, for-pay option if it didn't crash all the time. As it is, XiG is not usable unless you can lend them your laptop for a month for debugging.
I agree with a lot of what you said, but...
I think what's being lumped into the word "driver" here is bogus. To me, a driver is the bare minimum code needed to flip the right bits in the right registers to make a piece of hardware do something. That's all. When you deal with a video card, or a network card, all you want from the driver is the ability to say "blit this over to there" and be done with it. I don't expect anybody to give away their carefully developed software if they don't want to. But that shouldn't prevent anyone else from banging bits on the hardware and exploring/developing on their own.
If there are proprietary algorithms in Nvidia's "driver" that do special graphics manipulations, I really don't want to see them. That, to me, belongs in the application space and has no business being in the driver in the first place. All we need, as *kernel* driver developers, is a documented register map.
When people allow themselves to talk about "drivers" in fuzzy terms, blurring the boundaries between real hardware-level issues and application-level issues, it only confuses things.
-- *My* journal is more interesting than *yours*...
Let's see if Intel really supports Linux:
When situations like this change, then Intel can boast about Linux support. Until then, its hot air.
And until then, I'll continue buying AMD, the best bang for my buck, and the new performance leader on 64 bit, which I can use on Linux NOW.