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.
Re:Proprietary drivers (Score:5, Insightful)
People should not accept this or we'll get into another situation like you have with NVidia. Get a brand new box and you can't even do a net install on your Nforce chipset box because you need the nvnet driver which is a proprietary binary-only module and the manufacturer of the motherboard may or may not have included a pre-compiled binary on a floppy for you to use, but it's most likely only for Red Hat 9, etc. Screw all binary drivers, I insist on open source drivers for everything. The only thing I've had to relent on lately is the graphics card since the Nvidia stuff is the only decent graphics card out there but the modules are binary only. Sadly, my Nvidia card is also the most unstable part of my Linux box and it crashes (hard locks up) at least every 2 weeks or so and I have to power cycle the box. Fscking Nforce craptastic Asus A7N8X-Deluxe piece of shit motherboard.
Re:Proprietary drivers (Score:5, Insightful)
Which is what? A ompany providing kick-ass drivers that give superior performance than that same hardware would give in Windows? What do you suggest using as an alternative to NVIDIA? Ati? HAH, good luck trying to get those drivers to work, open-source or not! And if you do get them to work, what kind of performance are you getting from them? And how about their AMD64-support? NVIDIA has AMD64-drivers available right now. Where are Ati's drivers??? Where are open-source AMD64-drivers for Ati?
One word: Forcedeth.
You know, you CAN use the open-source NV-drivers that ship with Xfree. Or you could use the standard VESA-drivers. So it's not like you are forced to use those drivers. I for one haven't had any problems with NV-drivers.
Re:Proprietary drivers (Score:5, Funny)
Superior performance as in shorter time from bootup to lockup?
Re:Proprietary drivers (Score:3, Informative)
He could; if he was talking about video card drivers. He is not, however.
He is talking about the N-force motherboard chipset drivers.
Re: Proprietary drivers (Score:4, Informative)
Well actually he was talking about both -- the references about not being able to do net installs with Nvidia motherboards is because the module for running the ethernet card has to be downloaded from Nvidia's web site and complied for the kernel you are using before you can connect to the net via ethernet -- a situation that is really lame and sucky...
Re: Proprietary drivers (Score:4, Informative)
No-one is being forced to buy NV-hardware. Hell, to be honest, NV is under no obligation to provide Linux-drivers for their hardware AT ALL! Yet they choose to release kick-ass set of drivers, yet people complain.
Would I like it if the drivers were OS? Sure. But I'm not losing any sleep because of it. If you don't like the current situation, feel free to spend your money on hardware that does have OS-drivers available.
Re:Proprietary drivers (Score:3)
I used to do this. I'm a graphics programmer, but I would run the nv driver until I actually needed to test something, then I would restart X with the nvidia driver. Thankfully the stability has of the drivers has improved over the years. But it sure did impact my development cycle when a
Re:Proprietary drivers (Score:3, Informative)
2.6 + latest Nvidia haven't given me a crash yet though with lots of OpenGL going.
The driver is of such quality the remaining bugs would be squashed out in a matter of weeks if they wh
Re:Proprietary drivers (Score:4, Informative)
Restart X? whatever for? I often run two different X sessions on my system, with different configurations. :1
startx --
I've also done it with kdm, in fact when I was playing with the kdm source code I had two different versions of kdm running on my machine at once!
But he does have a point (Score:5, Insightful)
Now my main point is this could lead to some problems for us linux users. Like he pointed out its possible in the future that we'll all be stuck with mobo's that don't work unless we load a dozen proprietary drivers. We did without in the 90's and we can do without now. The nvidia, now the Intel, next the VIA chipsets, its a dangerous trend. You tried to deflate his point at the end by saying just the free nv or vesa etc. What about when that's no longer possible?
The way I see it is this. You should be able to install your OS, have it support your mobo chipset, video card, mouse+keyboard, and ethernet card all with Free software. You should be able to surf the web, get email, use a calendar and contact list, play movies and music, and be able to create Office documents all with Free software. Those are the basics. Anything less is a failure. Right now all of the above is possible. Start throwing in a Nvidia card, a centrino chipset, and the truly Free desktop starts disappearing. Right now its the not the end of the world. But if in the future proprietary binary drivers become the standard a Truly Free Desktop won't exist and there will be no point in using Linux. After all if I need binary drivers for my hardware like in Windows and I continue to use all of my Windows apps via WINE, wtf is the point? Just stick with Windows and the closed source model. Throwing an opensource kernel on top of all that proprietary software is a lost cause.
Re:Proprietary drivers (Score:3, Insightful)
Re:Proprietary drivers (Score:3, Insightful)
Re:Proprietary drivers (Score:3, Informative)
Re:Proprietary drivers (Score:3, Informative)
Re:Proprietary drivers (Score:3, Interesting)
Re:Proprietary drivers (Score:4, Informative)
But yeah, 300 is better, definitely.
Re:Proprietary drivers (Score:5, Informative)
Otherwise, haven't had any problems with my board. I'd hardly call it 'craptastic'. I've gotten much better and more reliable performance out of it than my previous boards, while using Windows or Linux.
Re:Proprietary drivers (Score:5, Informative)
If Intel's choices boil down to "release a binary driver or ignore Linux", which realistically, they do, I'd prefer that they support Linux in any way that they realistically can.
Intel is obligated to its shareholders to protect it's technology. Open source drivers could tip their cards to AMD or some newcomer could gain the upper hand. That is the REALITY of how the hardware business works.
I have had no problem with Nvidia drivers and stability, but I stayed away from the Nforce chipset due to the ongoing support problems it has had.
I too would prefer open source drivers, but I'm not going to threaten to hold my breath until I turn blue just because all they want to give me is binaries.
Re:Proprietary drivers (Score:3, Insightful)
I have an Abit NF7-S with DDR400 RAM, an XP 2500+ CPU and a GeForce FX5900 at 8X AGP. I dual boot Windows XP(games) and gentoo 2.6(everything else).
I have no problems. Anyone who does have problems just isn't doing it right. Absolutely all of my hardware works perfectly in both oses. Yours should too. My SATA even works now because of 2.6. I think I'll up it to 2.6.3 next week
And who cares if drivers are OSS or
Re:Proprietary drivers (Score:3, Insightful)
You now have the choice of ditch X and replace with something else (if it is even available.) Do not upgrade and eventually left in a situation of either ignoring security updates or backporting them yourself. Or write your own driver for X.
I put together a Web server for a charity once out of a bunch of old spare parts. There was a K6-2 CPU and MOBO (witha bad parallel port) ,
Re:Proprietary drivers (Score:5, Insightful)
No. Full stop, no.
On the contrary, all of those examples show how I am more likely to use and buy a product if I know how to use it.
If I could look at a product's manuals, and from that, figure out how to copy the product, then you can be quite certain I knew 99% of what I needed to know to make such a product beforehand.
For example, if I hand you a black box that takes two numbers as input and outputs a third, and you deduce that it's a multiplication box, you knew everything you needed to know to make a multiplication box before I even handed it to you.
On top of this, if you simply copy a competitor, you're a year behind them and dead meat anyway.
Re:Proprietary drivers (Score:4, Insightful)
Algorithms? Techniques? Sheesh. Look at the average C header file or a reference document for some trivial microprocessor some day. It's mostly enumerations of functions and constants, with explanations for each one. That's the level of information we need, and historically, vendors who care about their customers give it to them for the asking.
It's as much "moving this bit over there" as posting this comment to slashdot is "moving this bit over there" - but we wouldn't be having this discussion right now if TCP/IP, HTTP, and HTML were undocumented and released as some binary-only implementation.
Who cares about their optimizations? We're smart, we can figure that out ourselves.
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 reve
e100/e1000 began proprietary (Score:5, Insightful)
So, even if they are originally released as proprietary, who cares, I bet the source will sooner or later be released.
Re:Proprietary drivers (Score:5, Insightful)
Re:Proprietary drivers (Score:4, Insightful)
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:3, Informative)
Initially I had some trouble with my NForce2 board... it was a replacement for an absolutely horrible VIA chipset board that just crapped out. I too impressed with Ali chipsets either, as that's what I had on my other box. AMD chipsets, though stable are a bit behind. I'm glad to say that although some of the features were a bit lagging in support, it is rock solid
Re: Proprietary drivers (Score:3, Informative)
My VIA EPIA system hasn't crashed once, and I just eliminated the last binary-only proprietary driver (the sound driver) now that 2.6 has everything I need working properly in open source form. In fact, VIA made source code and documentation available to developers, and that work is now making its way into the kernel releases.
Re:Proprietary drivers (Score:4, Insightful)
Back in the days of drum memories, computer manufacturers would often offer you software gratis -- in return for which, you were expected to offer them something you had written, so they could pass it around to their other customers. This was a form of policed open source. With no such things as high-level languages, there was no distinction between source and binary; one line of assembly language translated directly to one word of machine code. Experienced programmers could read the ones and zeros as ups and downs on an oscilloscope screen and understand them as an instruction.
Then, somehow, sometime it all got stuffed up, when people began trying to treat ideas as property and earn money by litigation
Re:Proprietary drivers (Score:3, Informative)
Re:Proprietary drivers (Score:5, Insightful)
- fix bugs/do workarounds for the hardware the manufacturer doesn't care about
- tweak the driver to your needs (this is not a joke: I'm glad that the tmscsim-driver for Tekram SCSI cards could be tweaked by me to work seamlessly with my old SCSI scanner!)
- have support for the hardware as long as YOU wish
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
Re:Proprietary drivers (Score:5, Informative)
And I'm not blaming Intel for this one either. Hardware installation under Linux is a nightmare of inconsistency. If the shipped kernel doesn't fully support your hardware, good luck! The typical Windows user is still not ready to compile a kernel.
I sort of like what Nvidia does with it's video cards: The 'compile a small kernel interface on-the-spot' type of script. I'm sorry to hear about the fellow with the Nforce chipset problems, but Nvidia's video card drivers are solid.
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.
Setting an example (Score:5, Interesting)
Re:Setting an example (Score:5, Insightful)
Re:Setting an example (Score:5, Insightful)
Or if you use something other than ix86 platforms. Vendors will probably not make binary drivers for CF-cards on my Yopy.
Although in this Centrino case this might not be a big issue.
Or you want to path your driver. I.e to allow TV-out on your graphics card. Or fix a bug.
Or you use a !Linux OSS OS, like BSD.
Or you use an old or experimental kernel.
Re:Setting an example (Score:5, Insightful)
It's quite a bad thing, irrespective of religion, if the vendors don't release enough documentation of the devices to make open source drivers. We'll end up in a situation where it'll be difficult to install Linux/*BSD on a machine whithout proprietary drivers. As an example, for the NForce chipset I've to buy a NIC due to lack of driver.
As documentation goes, Intel network division is very bad : they release GPL drivers, but no documentation is given (without NDA). That makes it difficult to make good open source drivers. And now the same company wants us to accept more and more hardware components with only a vague promise of drivers, much less documentation?
Re:Setting an example (Score:5, Insightful)
You want to upgrade to new fancy-schmancy kernel 2.7.x and you can't because your CPU-centr-a-yummy needs 2.6.x to install properly. They never keep up or give anything more than half-assed support. I had an nVidia TNT2, and I gave up on nVidia stuff, because I hated being locked in to THEIR schedule... and it crashed a lot, would corrupt the video (you could log in remotely though) and the only thing I could do was reset. I moved on.
Re:Setting an example (Score:5, Insightful)
The people who don't care can do what they like at purchase time and they should have the ability to get their closed source drivers so they can use Linux too. It's all a stepping stone to going completely open source. That's not to say closed source should ship with the kernel, because it shouldn't - that position is reserved for open source only.
Re:Setting an example (Score:5, Insightful)
What Intel is doing is doubly bad:
1) They are releasing a Closed Driver, killing future development, growth and porting of support to future systems.
2) Really only doing this to spite Lin--s. They are doing this to STOP Lin--s' open-source driver development.... probably not because they want to. Why couldnt they have been forthcoming "we are working on a driver. we intend to release it first qtr 2004. we are making it closed." Why keep the FreeSoftware universe in the dark..? Because they want to hold all the marbles, withholding information is dishonesty. Plain and simple. If you want to be 'trusted', keep no secrets.
Re:Setting an example (Score:5, Insightful)
That will take much longer if non-free drivers are available. Intel said somewhere that they won't release the driver as free software because they fear that this would reveal too much information about the hardware itself. So when Intel is out, the driver has to come from a third party. And clearly, the urge to develop a free driver is much lower when there is already a proprietary one available.
Big Hurdle (Score:5, Insightful)
Re:Big Hurdle (Score:3, Insightful)
(That's the main reason why the Linux desktop will take off on the corporate desktop first (if at all). Every good administrator looks for unified hardware in a big company. Checking if Linux is OK is simple. With 100 different computer configurations you will always find combinations that won't work with Linux (but of course work with Windows (at least kind of work
bye egghat.
Lin---s (Score:5, Funny)
Re:Lin---s (Score:3, Funny)
Looks like the censors finally beeped out the profanity.
"Dow" is a profanity?
Nice, but... (Score:5, Interesting)
Reverse engineer the drivers! (Score:5, Interesting)
Re:Reverse engineer the drivers! (Score:5, Interesting)
Re:Reverse engineer the drivers! (Score:5, Informative)
Security through obscurity doesn't work. It's possible to make a safe hardware, so that reverse engineering (as rightfully understood by the EU laws) is applied and legal for compatibility. And even (gasp) open-specced hw.
Even by hardware, I do not mean realy that : software doesn't mean driver OR app OR os, you have firmware too.
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 l
Dumb (Score:5, Insightful)
Yeah. Because obviously no other companies have been able to produce wireless networking products. I can see the point of commercial secrecy when you have some l33t hardware that no-one else can make, but when you just have yet another implementation of something that's already widespread and implemented in lots of different ways it seems dumb to worry too much about protecting it through drivers. If the other companies cared enough about your particular methods they'd just get a team of coders to reverse engineer the closed-source drivers.
Intel gets it IMO (Score:5, Informative)
It would be nice if VTUNE would be brought up to equal footing with VTUNE for Windows, but it's pretty good as is.
Why would 'Proprietary Drivers' be so 'sad'? (Score:5, Insightful)
Intel can do what they want. They are the owners of their hardware designs and the drivers to make that hardware function.
If it's so sad that Intel is going to provide proprietary drivers, do you get sad everytime you get into your automobile? (The computer under your hood mosty likely uses proprietary drivers to interface with the autmobile.)
There is room for both open and closed software in this world. I for one envision a world where the Operating System is wide open with all the tools one needs to make whatever changes they wish to it and to develop whatever they want to on it. If hardware manufacturers want to keep some or all of their drivers 'secret' that's fine, let them. If application developers want to keep their 'Whiz-Bang 2.0' application proprietary, let them.
Believe whatever you want. I have and still use quite a large amount of both proprietary and open source software and in some cases, the open source software is better, in other cases, the proprietary software is better, even for the same task.
What needs to end are silly proprietary APIs put into an OS by particular vendors to allow their other applications to run like the dickens while making competitor's applications less capable.
Re:Why would 'Proprietary Drivers' be so 'sad'? (Score:5, Interesting)
Re:Why would 'Proprietary Drivers' be so 'sad'? (Score:3, Insightful)
What's is interesting in Linux kernel, is that the driver API is always changing ; backward compatibility has little or no importance in the development. Enterprises developing proprietary drivers are not very responsive to these changes. Having GPL'd drivers included in the ker
Re:Why would 'Proprietary Drivers' be so 'sad'? (Score:5, Insightful)
Yes there is. That does not mean that the choice is value neutral, however.
The licensing of the relevant code is a part of the feature set just as much as the checklist items for the hardware is. It is another item that the customer needs to evaluate and contrast with competing offerings.
This is why the anguished cries of some manufacturers against governments requiring open source rings so hollow. Just as a customer can require for instance Word file import capability, or three year installation and upgrade support, they can require open source compatible licensing. It is another feature that may carry more or less importance depending on the customer.
So, if someone says they will not consider hardware without open source drivers, that just means they, for various reasons, value the feature of open source relatively highly, and are ready to pick another supplier to get the feature they want. Note that it really is not just about whether open source or proprietary software is better; the licensing is in itself one (sometimes major) factor in determining the "betterness" of a piece of software.
Re:Why would 'Proprietary Drivers' be so 'sad'? (Score:5, Funny)
Re:Why would 'Proprietary Drivers' be so 'sad'? (Score:3, Insightful)
With Open Source drivers, if the hardware manufacturer stops supporting your hardware/OS & stops shipping drivers it doesn't matter. If the kernel radically changes and incorporates new features which you need, you don't have to wait for the hardware manufacturer to produce updated drivers.
Most of these are things which you don't need to worry about today, when you can just go to the website & download drivers. How about tomorrow?
Give us documentation... instead of closed drivers (Score:5, Insightful)
I doubt that they will open souce their drivers. So the Linux developers will write their own anyway, whenever they can.
And personaly, as a user, I find open source drivers much more convenient.
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...
Re:proprierty drivers (Score:4, Informative)
Re:proprierty drivers (Score:5, Informative)
Re:proprierty drivers (Score:3, Insightful)
In fact they should be more liable for a closed-source version that may, becuase of a bug, violate FCC regulations. Possibly they fear this sort of information being discovered and this is yet another of the real reasons they don't release the drivers.
I just don't get the idea of the Centrino anyway (Score:5, Insightful)
Re:I just don't get the idea of the Centrino anywa (Score:3, Interesting)
Re:I just don't get the idea of the Centrino anywa (Score:5, Informative)
Intel(R) Pentium(R) M processor
Intel(R) 855 Chipset Family
Intel(R) PRO/Wireless Network Connection.
These 3 parts make up the Centrino, it's not just the wireless part.
There is already full support for the processor in the 2.6 kernel
The 855 Chipset is also supported
The PRO/Wireless is what this is all about. Intel has been saying that they will be supporting the wireless for the last year and we have not seen a thing. The best chance we have currently is running a wrapper for the Windows drivers, this is not bad but not good either. If Intel can deliver a driver that gives Linux users FULL functionality with the Wireless, I know I will at least be happy.
proprietary drivers (Score:5, Insightful)
Bullshit. Proprietary drivers are a bad idea for linux. Now I have to say, the licensing issue does matter to me. Even if you don't care, there are plenty of technical reasons to avoid them and pester a company to release the source for their drivers. First of all, the code is usually sub-par. EEs right them, they're smart people, no doubt, but most of them aren't programmers and lot's of bugs and race conditions show up. The OSS community can't help debug them because we don't have the source. Furthermore, on a more personal level, most of the kernel hackers don't give two shits about proprietary drivers, because of that, they generally stay buggy and improperly maintained. Intel is a big enough company that they'll properly produce high-quality drivers; however, it is simply a fact that letting the OSS community have the source would increase their quality, more eyes looking at the code, and they would be the same people that have written the kernel. These debates flair up all the time on LKML. I was too lazy to go look for links to specific discussions, if you're interested in the issue however, they wouldn't be hard to find.
- Ryan, who can't remember his password right now, and so posted AC
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....
Intel Centrino Drivers: A Series of Rumours (Score:5, Interesting)
To everyone saying whats wrong with proprietery. (Score:5, Insightful)
To those who say, but Windows DRivers are closed. They are not to the kernel developers. When installing new drivers you may of had a warning that a driver wasnt signed. A signed driver means one that has had its source code audited by MS for bugs, and is more stable than a unsigned one. Microsoft dosent like closed source (unsigned) drivers, and will warn you if you try to install it.
So if you want a stable Linux, don't load closed source modules into it. Dont take unstabllity for short term hardware support over stabillity in the long term. Encourage companies to open their source, or reverse engineer and stablise their drivers!
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.
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.
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.
Intel once again behind the 8-ball (Score:5, Insightful)
That is so 15-minutes-ago.
802.11g is all-the-rage, there are proprietary (I cannae give ye much more, cap'n) extensions to g which give it even more KickAss throughput and already Intel even are trying to jumpstart "more wireless speed than you would know what to do with" mode AKA UltraWideBand based technologies.
Somebody releasing half-assed (in the sense that we have to rely on them to provide timely updates, because it's not open source) drivers for last-years wireless technology is not in any sense of the phrase "stuff that matters".
On this kind of timescale I expect we're soon going to have our own OpenSource (we worked it out for ourselves, thanks for nothing) drivers.
Intel is a large enough company making enough profit that they could easily afford to provide current-and-up-to-date drivers for their wireless technologies as they release them not whenever they're no longer busy doing "important stuff".
Intel, you're half-assed. Period.
Behind the 8-ball when it comes to 64bit (busily playing catch-up to AMD) and can't be bothered getting out drivers for your technologies.
Here's a clue
Intel, please just plain get up off your fat hairy ass and deliver drivers (we'll live with proprietary if you insist) as soon as the hardware is available on the shelf and provide timely updates for new OS releases (dammit man, it's not like we're releasing a new MAJOR kernel every month) Yours truly The Community (aka Your Customers)
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!
Want your Cake and Want to Eat it Too (Score:4, Insightful)
Intel, NVidia, etc. have spent millions of US$, Euros, etc. developing their hardware and software. They need a competitive edge to their products (real or imagined). If they can protect their interfaces, at least for a short period of time, they can stay ahead of the competititon (or try to).
On the other hand, Open Source including Linux needs the broadest support possible. Restricting the O/S to only closed drivers will scare traditional companies away (and already has in come cases, think Canon printers). It will limit the accessibility to state of the art HW and SW. Much of the performance gains in modern hardware are due to the software drivers (graphics comes to mind). If you give away all your software, you weaken your position in the market and it can affect your bottom line.
The primary objective of a company is to maximize shareholder's wealth. Put these problems in this context.
Linux is the best thing out there. Mozilla and OpenOffice rock. I love open source (free and otherwise) software and support it whenever I can. However there is a market for state of the art hardware (Nvidia) and software (Intel compiler, Oracle database, high-end applications, etc.). We live in a mixed environment.
Do you want to be paid as a programmer? Do you want to have some worth to your products? There is a strong market for commercial, closed software (specialized software, industrial databases, custom solutions, high-end games). Not all can be free and open, nor should it be. It is far harder to make money on just services. Do you want programmer jobs to go to India like the mass of consumer hardware now made in the far east? Are the US and Europe becoming consumers and service organizations with few products of our own?
I can't resist mentioning Microsoft in this context. Much of what they do is now a commodity (operating system: use Linux, word processing/presentation/spreadsheet: use open office, servers: use Linux/BSD with Samba, etc.). They are the competition in the desktop, server, and embedded spaces. They are getting scared (think trapped beast). How can we compete with Microsoft with their nearly 100% (until recently) closed products? By working with vendors that can't or won't open their products. By getting commodity and older product drivers released (for example Canon printers - hint, hint). By working with hardware/software vendors on state of the art drivers but letting them keep their core IP if it helps them with a competitive edge (and gets us drivers).
Cameras (Score:3, Interesting)
Having open-source drivers helps the hardware... (Score:4, Informative)
Therefore, I think the availability of open-source drivers should help the hardware sales quite a bit, in that people like me are willing to accept somewhat worse price-to-performance ratio for a open-source (therefore well-supported) driver. Considering that more and more people are trying to install linux on their desktop, and most distributions are unlikely to include proprietary drivers anytime soon, closed-source drivers will be a significant minus for people planning to install linux on the system.
Don't underestimate the value of having the drivers open-sourced, Intel...
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:I blame Linus Torvalds. (Score:3, Insightful)
Re:I blame Linus Torvalds. (Score:5, Insightful)
He says so repeatedly in his posts, so it's not like it is a secret.
No you are wrong here. As a practical matter binary drivers lead to buggy unstable kernels. The people writing these drivers have no contact with or support from experienced kernel developers due to the closed nature of the process, and code quality suffers. And people posting about binary drivers waste everyone's time, including their own.
Linux has a lot of users outside the "hacker set". Did you miss the part about Linux overtaking MacOS and it's current share of the server market?
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...
Didn't they say this last year? (Score:3, Insightful)
Oh, I also believed them that their crap keeps cool. Even at 600MHz (instead of 1300) and doing nothing this thing gets freaking hot and makes lots of noise.
I am MUCH happier with my Crusoe (Toshiba Libretto) notebook. I guess my next one will be an Efficeon.
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:Legality of these binary drivers? (Score:3, Insightful)
Never heard anything so stupid. You mean all software written for a particular OS is a derivative work of that OS? Nonsense. Even the LGPL states (within the license itself) that it is legally unclear and therefore it explicitly allows it (the whole point of the license). This is like trying to ban reverse engineering. You need to reference header files when you compile to ensure co
Re:Legality of these binary drivers? (Score:3, Informative)
A. You take responsibility for dealing with any bugs or incompatabilities that crop up.
B. You don't expect your driver to actually be INCLUDED in the kernel. You'll have to do it your self or convince the Linux distro vendors to do it for you.
Re:Legality of these binary drivers? (Score:3, Insightful)
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.
One idea (Score:3, Insightful)
One novel approach would be for the company, in this case Intel, to produce a binary driver and place the source code in some form of trust, to be released when they no longer support the driver or the company no longer feels that the source code would provide an advantage to other companies.
FCC regs (Score:4, Insightful)
Software access to the radio control portion of the system would mean users could adjust the frequency and power output of the system -- something which would run them afoul of FCC regulations requiring that equipment of this nature be fixed and not changeable by the end user. And, the FCC would not take kindly to this. Both Intel, and the modifying user, could be liable.
It's already working... (Score:4, Informative)
Since I'm running Debian GNU/Linux [debian.org] stable (yes, that's right, I'm on woody), I had to install a newer version of iwconfig and modify my /etc/network/interfaces file to make it work well:
Of course, since ndiswrapper use the Windows XP drivers file, it does not resolve the problems about proprietary drivers. But at least, I was not stuck to wait (an eternity) for Intel to release their Linux drivers.This space is reserved.
Then what about Linux? (Score:5, Insightful)
Re:**SIGH** (Score:5, Insightful)
It's not about RMS. Open source drivers benefit the development of the kernel, and also the users of the drivers and hardware those drivers support. Remember when the linux kernel was at 2.6, but we had to wait some time before nvidia released 2.6 compatible drivers? If they were GPL, the kernel developers could have incorporated the drivers into the kernel and development would have gone concurrently.
Even now, sticking a closed source driver in there is problematic if there's a kernel panic. How are you going to debug it? What about security? Nobody ourside of nvidia has audited the code. There could be a potential vulnerability that they missed. We negate the benefits of open source if only *part* of our program is open source.
Re:**SIGH** (Score:5, Insightful)
That's quite a flamebait-inducing post you've got there...
What about other operating systems? Do we have to badger Intel to release drivers for BSD, and whatever other operating systems might be released in the future?
What happens if we release a new kernel, or decide to change something that breaks the rigid structure into which this proprietary driver is locked?
Releasing proprietary drivers like this seems to be no more than a "keep them happy" quick-fire solution, as this is by no means a long-term solution. And frankly, ignoring the long-term is a very short-sighted viewpoint indeed.
What's the ideal solution? Write your drivers so that they use a well-documented and open API that can always be well-supported, and make the code as portable as possible. Then what happens when you want to use your hardware with a different operating system? Well, so long as your operating system implements that particular well-documented and open driver API, then you shouldn't have any problem. Recompile, rinse, repeat.
Think ahead. We wouldn't be pushing for open source drivers without reason.
Re:**SIGH** (Score:3, Insightful)
Who the hell cares besides RMS? I love using my machine and it has an nVidia card in it. I don't care that their "driver" is closed source, I can play a lot of heavy duty games with it.
[Raises hand] While I am not dogmatic about it, there are a few serious practical concerns about closed source drivers;
Can't use them out of the box; it's another set of steps.
Re:I don't mind the proprietary*(sp) drivers. (Score:3, Informative)
On the contrary, the opposite is true. Stable and secure hardware drivers are key to a stable and secure system. When I'm running a binary driver, I have no way of knowing what's really going on under the hood. If the driver crashes, so can my whole OS. If a closed source app dies, only that app dies.
Dinivin