Intel to Increase Linux Support, Release Centrino Drivers 381
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.
Proprietary drivers (Score:5, Interesting)
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.
Setting an example (Score:5, Interesting)
Nice, but... (Score:5, Interesting)
Reverse engineer the drivers! (Score:5, Interesting)
proprierty drivers (Score:5, Interesting)
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...
How about Linus? (Score:1, Interesting)
Intel Centrino Drivers: A Series of Rumours (Score:5, Interesting)
Re:I just don't get the idea of the Centrino anywa (Score:3, Interesting)
Will other organizations follow suit? (Score:5, Interesting)
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.
Re:Why would 'Proprietary Drivers' be so 'sad'? (Score:5, Interesting)
what's wrong with Intel? (Score:4, Interesting)
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.
Re:Why would 'Proprietary Drivers' be so 'sad'? (Score:2, Interesting)
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
Re:Proprietary drivers (Score:2, Interesting)
Don't bitch. Even if it is like nVidia, at least you CAN get a driver. (or at least you will, soon)
Easiest (Score:2, Interesting)
HAL: Proprietary, SML: Open (Score:4, Interesting)
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.
Graphics specs too please! Not just wireless (Score:4, Interesting)
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!
Re:Proprietary drivers (Score:2, Interesting)
It seems they might as well release Linux drivers, a representative from Microsoft recently told me most driver authors figure out how to do things in Linux and then port the drivers to Windows because it's easier that way.
Re:Reverse engineer the drivers! (Score:5, Interesting)
Re: Proprietary drivers (Score:5, Interesting)
I totally agree.
I built a shuttle box for my little sister a while ago not realising that the Nvidia motherboard's built in ethernet card will only run with a module from Nvidia, it took a while to work this out after installing Linux on it the first time...
Then 6 months later I have a chance to upgrade Red Hat 9 to Fedora on the box and after the upgrade I discover that the network doesn't work... and at this point I remember what I had to do 6 months before... Aarh!
So I have to go through the whole process again, find another computer that is connected to the net, download the Nvidia drivers, burn a CD... I thought I'd try the SRPM to make upgrades easier, well these don't build as a normal user so I gave up on them, so I then need to download the tgz version, burn another CD....
This results in a situation where the kernel can't be upgraded without manually rebuilding the Nvidia modules and this isn't something that I would want to suggest to my sister (she never uses a CLI)... So the local root exploits that all but the latest Fedora kernal have don't get patched... (not a big issue since it's behind a NATed connection and there are only a couple of user accounts, but still it's not ideal...)
The result of this is that I'll never recommend that anyone gets a Nvidia motherboard and I'll never buy one, it's far too much hassle.
Sadly I'm stuck with Nvidia video cards in order to play games such as Quake 3 in linux... I wish this wasn't the case...
What would be ideal would be if the manufactures either release enough info so that GPL drivers can be produced or if they release GPL drivers themselves so they can be included in the kernel.
Last year I wanted a IDE RAID card and after much googling I discovered that the 3ware ones have drivers in the kernel and no others do, so I brought one even though it cost me more money it has saved me loads of time because I haven't had to mess with installing modules from a hardware company every time I upgrade the kernel... I have no regrets about this bit of hardware... unlike the Nvidia motherboard...
Re:Proprietary drivers (Score:2, Interesting)
the nVidia drivers (the UDA at least) have source code available, in case there is no precompiled module for your kernel.
there is an interesting clause in the LICENSE file:-
No Reverse Engineering. Customer may not reverse engineer,
decompile, or disassemble the SOFTWARE, nor attempt in any other
manner to obtain the source code.
but these files are in the package:-
nv.c
nv.h
nv-linux.h
os-agp.c
os-r
os-interface.c
os-interface.h
rmretva
os-registry.c
nv-misc.h
gcc-version-check.c
if the source is already there you don't have to reverse engineer,
decompile, or disassemble the SOFTWARE.
although attempting in any other
manner to obtain the source code could include just extracting the archive.
Cameras (Score:3, Interesting)
Re:proprietary drivers (Score:5, Interesting)
Would Intel do this? maybe, maybe-not. But no one expected it from Borland's interbase [com.com]
is this paranoid? maybe, maybe-not....
I blame Linus Torvalds. (Score:5, Interesting)
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.
Re:Proprietary drivers (Score:4, Interesting)
I worked on a C++ project for some future DVD+RW devices, and we wrote windows only last year, even though I did all my dev in VmWare under linux -I can tell if the technology takes off there will be complaints that we didnt bring out a linux driver.
But even a pure Win32 driver (a) reused lots of existing windows code (some with Win16/win32 #ifdefs to show its age), and (b) took a lot of engineering effort. I dont realistically think the company will rush to duplicate that effort for Linux, unless it is tangibly lost sales. Even then, it will take ages. The new code we wrote will be ok -its all std:: C++ stuff, but the public API (COM) and legacy stuff is a historic mess.
I hope the company does the right thing and just documents the new SCSI commands and let other people write the Linux stack on demand. No maintenance costs, no development costs, the first implementation starts of OSS and stays that way.
Palladium (Score:4, Interesting)
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...
Re:I just don't get the idea of the Centrino anywa (Score:1, Interesting)
802.11G isn't even supported by Cisco yet so it is far from being a standard.
Legality of these binary drivers? (Score:3, Interesting)
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.
Re:Proprietary drivers (Score:3, Interesting)
Fedora Core 1, Suse 9.0 etc etc (Score:3, Interesting)
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. [agere.com]
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 [intel.com] Linux drivers are "under development" and have been for nearly a year for the wifi, from intel's page anyways.
I will hold fast to my no-intel policy... (Score:3, Interesting)
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.
Re:Reverse engineer the drivers! (Score:3, Interesting)
The reason they don't release drivers is that they are unsure of the legal nature of some of the code. All they have to do is release the source code for their Windows one. It would take ZERO effort. But their legal department realizes that closed source has the advantage that any legality mistakes they made are hidden.
Re:Proprietary drivers (Score:3, Interesting)
The manufacturers don't normally charge for the drivers anyway so I don't really think that's a problem. In many cases just releasing the specs for the hardware would be enough and they wouldn't even need to develop the driver themselves. Another alternative would be to do what many OSS developers do and add support for their hardware to an existing driver.
If you just stick to GPL'd drivers, you can only get drivers for a small amount of hardware. Sad, but true.
Most people only HAVE a small amount of hardware so it's OK.
Grandparent is right (Score:1, Interesting)
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.
Re:Proprietary drivers (Score:3, Interesting)
BZzz.. wrong. You clearly have no understanding of how the hardware business works. #1.) It is common practice, when actually necessary, to reverse engineer a competitor's product to see how it works. Lack of source code for their drivers is not a hindrance. Hobbyists have in the past reverse engineered complex hardware in their basements in order to write open source drivers. Multi-million dollar engineering labs are more than capable. #2.) It takes too long to copy off somebody else's design. If you do, you'll be too late to market. #3.) Intel is obligated to its shareholders to make money, not "protect its technology." Sure, there are cases and ways in which it sometimes can/should, but this is not an example of one of them.
Re:Want your Cake and Want to Eat it Too (Score:2, Interesting)
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.
Will Intel really support Linux? Or just Centrino? (Score:1, Interesting)
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.