Slashdot Mirror
Novell Delivers Device Driver Breakthrough
An anonymous reader writes "Novell today announced a new Linux device driver process to make it easier for third party device driver writers to integrate their drivers with SUSE Linux." From the article: "The new driver process allows customers to obtain drivers independently of Novell® kernel updates and supplies a straightforward approach third parties can use when developing device drivers for Novell's SUSE® Linux Enterprise products. The new Linux driver process developed by Novell allows hardware and software vendors to provide Linux drivers and driver updates for their products to customers directly and transparently, in a way that is completely integrated with SUSE Linux Enterprise delivery and support."
I hope it's not a case of a tree falling in the forest, and nobody to hear it...
FP?
WARNING: Smartphones have side effects--most of them undocumented.
The Article is a merketing blurb, anybody knows how it's actualy implemented?
Plan 9 offers everything you would expect from a modern desktop OS. So there is no need for Suse Linux.
Does this mean that I might be able to get wireless working without ndiswrapper in the near future?
... it is generally the result of a badly written 3rd party device driver, and the inability of the OS to protect itself from that driver. Have Novell delivered a major breakthrough here (as the article suggests) or the beginnings of a major headache?
I know there will be replies about how the architechure of Linux protects us from some of the risk, but in reality 3rd parties will circumvent any device driver model in an effort to make their device perform optmally, even at the expense of the wider platform.
http://developer.novell.com/wiki/index.php/FAQ_for _the_Partner_Linux_Driver_Process
Geez, is /. so short of news that it accepts corporate press releases? "Driver breakthrough" - you can load a third party driver from a floppy. Well knock me down.
This "breakthrough" requires device vendors to recompile (and possibly port) their driver for every distro, every time that distro updates their kernel ABI. The only thing that has really changed seems to be that Novell will keep track of when the kernel ABI changes and notify driver developers.
Not that I could tell from that fluff piece, but it's obviously some sort of kerneldriver interface layer or wrapper of some kind.
The question is, how much overhead does the abstraction add?
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
This doesn't have anything to do with that recent NV/ATI GPL violation story, does it?
(after reading Novell's intro page and the FAQ) It's not a shim driver: "A driver is linked to a specific kernel version via Kernel Application Binary Interface (kABI) metadata. ... In the event of kernel updates Novell will notify partners about possible changes to the kABI". This is just a new process by which established device manufacturers can work with Novell, not a shim driver to create a stable kernel ABI.
I am a longtime SuSE Linux Professional user, and I always wondered why they change the externally-visible kernel version number for each security update.
This makes binary and externally compiled drivers (including nvidia and vmware drivers that I use) break on every kernel update, and probably unnecessarily, The chances that anything changes to the driver interface because of a security patch are probably very slim, and they could always change the version in case a major change is made.
But now, it is just an annoyance. I need to install their patch, reboot into textmode, re-make the vmware and nvidia drivers, and again reboot to go back to fully functional operation. And I know how to do this. A beginning user is happy to finally have such an install/compile procedure behind him, and not at all happy to see the whole thing break after YOU installed a kernel patch.
(not to mention the fact that it can take him quite some time to find out that the kernel patch is the reason, and how to fix it)
This is only going to work if you're using SuSE. And if you don't compile your own kernel. It only gives vendors an excuse to call their shitty binary-only drivers "Linux support". I'd call this thing a Linux driver setback.
To be fair, also OS device drivers are designed to hide bugs in the hardware/firmware!
ahahaha fat linux fag.
No, they certainly work around such bugs when they know of them, but there is no hiding going on. You find comments in the source documenting this bugs, frequently in not-so-friendly terms.
they are designed to hide bugs in the hardware/firmware,
I was always under the impression that the specs were closed to ward off copycatting from competitors.
Where does the school board find them and why do they keep sending them to ME?
It is a breakthrough, because having a shitty, flaky, unfixable and unsupportable binary-only driver is better than having no driver at all. Don't use it if you don't like it. As someone who writes closed source device drivers, I sincerely welcome this. Now, if someone just convinced Linus to add this (or similar functionality) to the "vanilla" kernel...
Get over yourselfs Plan 9 and BSD trolls - I'm seeing more of you fall out of the wood work in /. comments and it is getting annoying...Guess what; I have games (HL2, UT2k4, Q4, EVE, etc) and XGL (transset over xcompmgr) with fully compatible nvidia binary drivers and every bit of hardware on my computer supported, nearly, all under gpl compared to your what? Firefox suport? To put it simply there is need for Plan 9 and smaller BSDs to exist and that is so they spur Linux to continue to better itself and they provide good server OSes.
So bugger off and let people use their favourite OS in peace or don't bitch when the next major Plan 9 feature is reported and every one else just sighs and says 'use linux'.
I ate your fish.
i hope you burn in hell for writing closed source drivers.
"It is a breakthrough, because having a shitty, flaky, unfixable and unsupportable binary-only driver is better than having no driver at all."
No, its not. See how when you want to use an ethernet adapter, you just put it in the machine and it works? See how when you want to use a wireless adapter, its a huge hassle, barely works, and will likely cause you machine to randomly hang?
If people keep accepting binary only shit like this, then the situation will just keep getting worse. Soon, you won't be able to buy any hardware that works, you will only be able to buy hardware + crappy driver for some OS you may or may not use. Demand documentation so the people writing the kernel can write the drivers, and everything will work smoothly and without any hassles, in any OS.
From what I can see (too much marketing crap), it looks like they have an option in YaST to add an ISV's repository.
So, the ISV builds a package for their module and sets the dependencies and YaST allows you to update the module/kernel without breaking the dependencies.
Not much of an accomplishment at all (if that is all there is to it). Which would explain why they resorted to so much marketing crap in their announcement.
Copycatting what? What memory address to write what bytes to? What is copying that going to accomplish? All it would do is let your competitors write drivers for your hardware, it wouldn't help them copy your hardware in any way.
This argument is repeated time and again here on Slashdot and the fact is it is rediculous. Want to know why? Because Novell's customers want it. In fact, they want Suse Linux to run on whatever white-box thrown-together-component list they decide, and having vendors supply drivers to reach that goal makes Novell a more attractive company.
Novell isn't /. - this is the real world. Compatability = greater acceptance = better marketing position & happier customers = more sales. Period.
Excuse my speling.
Making The Bar Project
Sounds more like a new marketing process.
"I now inform you that you are too far from reality."
> they are designed to hide bugs in the hardware/firmware,
:)
>> I was always under the impression that the specs were closed to ward off copycatting from competitors.
I thought they were to make sure noone knew they were stealing other people's/companies' intellectual property they didn't want to license.
It's probably a combination of all three, though.
...model of consistent binaries is vastly superior. Quick and ragged works for a flying lap, but slow and steady wins the race.
So, YaST now has the ability to include ISV repositories ... and Novell will tell people who sign up with them when the interface changes?
Sorry, but I'm not seeing the "breakthrough" here.
If device drivers are third-party plugable without a recompile, I wonder if this is going to open the same sort of security hole that windows and it's device driver overwrting causes.
Some drink at the fountain of knowledge. Others just gargle.
Is not as hard as some make out. It's worth spending a few hours learning how to build your own kernel, it will reward you.
... Standards and Practices !
Then we would not have put up with pitiful crap like this quite so often.
PenGun
Do What Now ???
I guess we know who writes the true Servers OS, and who writes the true Desktop OS.
Nice try at a troll though :)
"I can't give you a brain, so I'll give you a diploma" - The Great Oz (blatently stolen sig)
While you're at it, you could reverse-engineer & document the damn thing, too.
kids these days...
While you're at it with the ® symbol, shouldn't it really read Novell's SUSE® Linux(tm) Enterprise products. As far as I know Linus Torvalds owns the Linux(tm) trademark. In case someone complains, I was going to use the & trade; entity but slashcode filters it out for some reason.
Buy hardware that is supported. Yes it's a pain to do the research, but it's worth it. I have a Shuttle XPC and wanted to install their wireless add-on that doesn't require a PCI slot. I worried about drivers until I found that it uses the ZD1211 chip for which ZyDas provides an open source Linux driver. Then I learned that there is a sourceforge project to rewrite the driver so it's suitable for integration into the mainline kernels - 64bit included. They plan to get into 2.6.17 or 18 kernels, so wireless may well work out of the box when I upgrade to Fedora 6 in the fall. For now it's possible to make it work the hard way (download/compile) without ndiswrapper.
There are other cards with this chip and there are other chips with native Linux drivers in various states. The future looks good.
i hope you burn in hell for writing closed source drivers.
... this isn't 1998 anymore, I understand the need for open source drivers so you can troubleshoot issues with both them and the kernel but, come on now, grow up - either figure out a way to make it so binary only drivers aren't a problem with stability, make a certification process, or forever be stuck with having 1/3rd the devices supported, 1/3rd supported poorly, and 1/3rd oblivious to your existence.
Sad thing is, this probably isn't a troll. You sound like most of the kernel developers who refuse to make a stable API or ABI.
You wonder why Linux has such shitty support? Your attitude and the attitude of the devs
Let's see something truly revolutionary from Novell besides them purchasing a Linux operating system and making little tiny improvements. Let's see them get together some kind of open hardware compendium where every company submits details of their hardware to kernel hackers. While it's unreasonable to expect every obscure piece of hardware you pull off a shelf to work in a given OS, the more the merrier.
So enabling YasT to handle kernel modules... is now a breakthrough.
I mean, all this appears to be is distribution of precompiled kernel modules being handled by the package manager. This is not a good thing, let alone a huge advance.
How about a package manager that downloads the code, lets you inspect, customize, or debug it, then compiles it and adds it to your modules list once you approve it?
"It is a breakthrough, because..."
It is NOT a breakthrough because ALL package dependency managers IN THE WORLD do exactly what Novell is announcing.
This is nothing but a marketroid bluff.
So "XASER3 Co" wants to upgrade in place to current Debian, Red Hat, SuSE, Ubuntu, Mandriva... you name it? They just need to publish a repository for that distribution and add it to the repository manager of choice (yum, apt, up2date... you name it). From that moment onwards, package A will only update if all their dependencies are met.
That, and nothing else, is what Novell is announcing as "breakthrough news". That if you deploy a Yast2-compatible repository and add it to the managed sources of the installation you can make a package (it really doesn't make difference if you distribute it under an open or a closed source) that depends exactly on kernel-image-2.4.37-1.0.3, so once installed, next security update from Novell, say kernel-image-2.4.37-1.1.0 won't install till you publish you new revision against it.
On Debian, to name one, exactly what Novell is announcing has been possible (and done by the people who knows his trade) for at least half a decade, probably more.
You wonder why Linux has such shitty support?
In my experience, it doesn't. All not-shitty server-class hardware is supported just fine and typically by open-source drivers (only notable exception being nvidia graphics cards, which have HIGH quality but unfortunately closed-source drivers). It's only the crappy desktop-class hardware support that sometimes lags, controllers that noone who knows anything would consider using, el-cheapo motherboard-integrated crap. Basically, if you buy cheap hardware, you might have trouble, but my workstation works fine with linux, because I am careful to buy decent hardware.
Is this circumventing the GPL? Doesn't this hinder the ideal of getting the drivers out in the open where the community can support them? Or is this just a way to legitimise binary only drivers? Who will do the security review for these drivers? Seems like a Bad Idea to me.
It means more sales in the short-term, but it also means sales lost in the long-term due to customer dissatisfaction. Closed drivers do suck, and they hamper the idea of open-source software. Open code means that bugs can, and will, get fixed quicker. Often (with good leadership), it also means that bugs get good quality fixes, instead of market-driven hacks. Vendors have very little to lose by open-sourcing their drivers. The source already exists. They might as well open up the source and let people with better motivation than "just paying the bills" get into it and fix it. It amazes me how short-sighted hardware manufacturers are when they choose to keep their drivers closed-source. Why pay software developers to develop closed-source solutions when the OSS community would, often, gladly accept the responsibility, and even provide you a better-quality driver for a fraction of the money that you'd spend developing the closed-source equivalent?
/. ID card on your way out for failing to support OSS when appropriate ;)
Now, hand in your
I pity the foo that isn't metasyntactic
Let's get philosophical. Why does this problem exist? Has it ever occured to any of you that device drivers are themselves a complete throwback and an obomination in the 21st Century? We take them for granted, but there is no good reason whatsoever for a computer peripheral to use "device drivers". None.
If you can't design a piece of hardware that works through an existing standardised interface you're no kind of engineer at all. And take your pick.. firewire, USB, RS232, SCSI...
Do you suppose every video display, digital camera, audio converter and so on is somehow uniquely special, that it is so ground breaking in its design that it needs custom crafted code just to make it work?
We are so entrenched in our legacy thinking that nobody, not even smart developers ever ask themselves the obvious paradigm breaking question, why the hell should you need a device driver? The reason is no more than a gross failure of modern computing, a failure of standardisation, a failure of coordination and regulation. It is a failure of ourselves as users and customers to demand a higher standard of compatibility. It is a failure of us as developers and coders to solve a simple problem once and move on.
Before you answer with some circular reasoning that merely begs the question take five and think it through. I speak as a software and hardware engineer who has designed and built entire computer systems and written an operating system.
They took a problem, wrapped a marketing program around it, and now it's an enterprise feature!
Whenever I hear the word 'Innovation', I reach for my pistol.
Linux got to where is is precisely because of the kernel devs not producing a stable API. Think about it, what would the kernel be if it was stripped of all the drivers? Not much use at all.
Now that Linux has a large userbase, you're arguing that is ok to relax that since some user wants binary drivers that just work. However, when you go that route, it's hard to go back because everybody *expects* the ABI to remain stable. Instead of improving the kernel, the devs will waste time sorting out ABI issues; not the best use of time.
:. Ultimate Control Dedicated/VM Servers
I was just looking for a way to run HL2 on SuSE10. How doyoudo it on Linux?
This is one of the things that stops me from getting rid of Win boot on my PC. (and poor support for ATI TV card, and wireless).... groan...
It just pisses me off how Novell might be very successful in this, and if they are, it has no benefit for Linux (as in, you know, the free/open source side), and quite possibly a negative effect. All this does is benefit Novell, and once companies write up their drivers, where are the rest of us that use real Linux left? In the dust, and possibly moreso, because now the companies can say with a smile on their faces that they support Linux, and may not ever bother to turn back and support the rest of us. Thanks Novell, for giving the world a stabler Windows.
Yes, right, closed source, proprietary like Windows, or Netware.
But, wait, they allready have Netware, why did't that go well ?
Remindes me painfully of this: http://www.ussg.iu.edu/hypermail/linux/kernel/0512 .0/0972.html
The only breakthrough here is for hardware companies who don't want to publish specs for their hardware. Whoever at Novell designed this driver deal doesn't truly understand what Free Software is all about (or Open Source for that matter) and why it's important to have documented hardware.
This is incorrect. High-end enterprise-type storage stuff and the like tends to come only as binary drivers.
To move this to the software realm, where I suspect people here are more comfortable, this is like saying that 'if we release the headers for our library, then it is easy for people to duplicate the library.' Tell this to the WINE guys, who have had the headers (and documentation) for the Win32 API for over a decade. Effectively they are saying that the interface is a significant portion of the design. Personally, I would hope that the implementation would be an order of magnitude more complicated than the interface...
I am TheRaven on Soylent News
You know, the argument about closed-source drivers and "the idea of open source" is getting old. If I'd want a religiously open system, I'd be running debian. Oh well, I couldn't play the games I paid for, but I'd be running a 100% GPL'ed box, so I should be happy with it, right? Since those games are closed source as well, that would be fine, ok, right? What I want is a system that does what I want, the way I want it to (which in my case happens to mean linux, YMMV), and which lets me do the things I want to do (which in my case means installing the closed-source nvidia drivers).
Sure. Then explain why there are so many OSS projects where you can find bugs in the respective bugtrackers that haven't even been acknowledged after several years, and three-figure number of comments from people who stumbled over the same thing? Hunt the mozilla and kde bugtrackers for any number of examples.
To sum it up, I'm happy with linux as it is, and I'm perfectly fine with the one or other closed-source thing on my box, be it a driver, or any commercial app like moneyplex or the dozen or so games where I've happily bought the linux version.
oh, and a word to the plan9 advocates... I can't see any reason to install that. any at all. Sounds like BeOS to me... good idea, dies (or shrinks to insificance) due to lack of apps and users. Happened to OS/2 as well, which was a shame.
Look, corporate users aren't going to go compile their own kernel, compile their own drivers or download and install binary drivers with a shell script. It's completely absurd to expect them to do that.
What Novell is doing is making it possible for vendors to update drivers without waiting on Novell to distribute them. To date, if you want a driver more recent than what ships with a stable distribution you are generally out of luck. Distributions just can't spend the time and resources it takes to keep changing the kernel in a stable system. It's impractical and counter-productive.
Can vendors ship crap drivers? Yes.
Does this plan from Novell somehow give vendors more magical mojo to destroy your system? No.
Novell is doing a good thing here, quit bitching.
Now that Linux has a large userbase, you're arguing that is ok to relax that since some user wants binary drivers that just work. However, when you go that route, it's hard to go back because everybody *expects* the ABI to remain stable. Instead of improving the kernel, the devs will waste time sorting out ABI issues; not the best use of time.
:)
That was one of my arguments yes. My other was that if they are going to insist on open source drivers you can make a certification process for companies who wish to keep their drivers closed source, or find a way (I hate to even bring up the one way I know of...) of preventing drivers from bringing down to the entire system, or at least a way to mitigate it.
I'm just saying, there *has* to be a compromise. NVIDIA walks a very fine line, and they get harrassed by people for not being completely open. I dunno, it's just frustrating to see the same people on one hand scream for drivers for linux and on the other demand they be open source as well. While, in a perfect world, this would be true.. it's not a perfect world. Compromise. Somehow
The only breakthrough here is for hardware companies who don't want to publish specs for their hardware.
Which 3D video card vendor does publish a reasonably complete spec for the devices that it sells?
Wasn't it Novell that developed Xgl?
This is only a new process for Novell to deal with vendors to make kernel upgrades more seamless to customers. I don't think this is going to cause all the vendors to release binary only drivers, but for the ones who do, SUSE will now work better with kernel updates. Personally, every system I use has an nvidia card in it and a marvell sata controller which only has a binary driver, about 75 systems btw... So, what kernel am I running? Oh, the stock one that came with red hat el 4, have there been security updates? YES, have I updated NO! because that is 75 systems I have to boot into text mode, rebuild the Nvidia drivers, rebuild the sata drivers, and reboot back to X windows... and that's if everything just works... I've had it not work before. Then of course you have to wait at least 2-3 weeks after red hat releases a new kernel before nvidia publishes the new version of the driver, and all in all its just a huge headache.
Binary only drivers are here to stay folks, we aren't going to abolish them, and as long as Linus is in charge of the kernel we aren't going to get a stable ABI, so, kernel update means recompile all your drivers... Any way to ease this burden is a GOOD THING because it encourages people to update their kernels. upgrading a kernel right now on any somewhat complex system, or anything that might not be 100% supported (IE wifi, some network cards, some storage devices and video cards) means a huge headache every single time a new kernel is released (by the major vendors at least 6 times a year). I estimate that if I were to keep my system updated it would take an additional 6-700 man hours per year, that is 30,000-35,000 dollars at $50/hour (which is low), you have to figure 1+ hour per system 75 systems, 6 times a year...
Cedega - http://www.transgaming.com/
Slashdot is proof that Sturgeon's Law applies to mankind.
Whaaaaaa.... What happen to free nux software? :)
Yeah, the customers want a lower quality system that gives kernel developers headaches. Well, stuff that. Thank gosh this isn't a "product". The GPL and structure of community projects like the kernel keeps everyone honest.
You wonder why Linux has such shitty support? Your attitude and the attitude of the devs ... this isn't 1998 anymore, I understand the need for open source drivers so you can troubleshoot issues with both them and the kernel but, come on now, grow up - either figure out a way to make it so binary only drivers aren't a problem with stability, make a certification process, or forever be stuck with having 1/3rd the devices supported, 1/3rd supported poorly, and 1/3rd oblivious to your existence.
Why don't you go write your own ABI? All it needs is a method for setting up MMIO and a secure interface to hardware ports and DMA, and then you can run your little binary blobs in userspace where they belong. Can't design your hardware to use MMIO and have sane DMA requirements? Too bad.
Of course this benefits Novell. They have a business to run. But just because you're upset another distro might not benefit from this, it's rather unfair to say that SUSE isn't "real" Linux, isn't it? Aside from proprietary drivers (and there aren't many - I'm not using any in my case), all source is included in the distribution.
http://outcampaign.org/
Hmmm, look, Mr. Gates,
A user expects his system to be configurable by nice, friendly, intuitive and easy-to-use GUI apps that come with a nice in-built help section.
Yes, Mr. Gates, we know that. But Linux has this "control center" GUI thingie that does anything a user needs to control. It's only those weirdos who have been smoking too much of that stuff that got you nailed in New Mexico (you sure look funny in that mugshot, boss!) who use vi or emacs, anyhow.
However, we all know that sometimes we have problems that only the weirdos can solve, then they use vi to edit some stuff the same way our technical guys edit The Holy Registry. The difference is that the Linux weirdos have something they call
there are quite a lot of reasons why so many programmers DEMAND the latest and greatest release of Visual Studio.
Ooohhh, THANK YOU, Mr. Gates! So you do realize how hard we in the Marketing & FUD department have been working? Does this mean we will be paid overtime?
Idiot. The fact that we demand Open and Free drivers is one of the things that gives us an advantage over closed systems. Everything that goes into the kernel can be read, and checked and improved.
This isn't Windows, and users aren't prepared to put up with drivers that are shitty, and that break when we make changes.
Drivers are one the the biggest sources of crashes, and if we allowed every shitty hardware company to throw binary blobs over the wall, in less than a year we'd have a kernel just like NT.
It's not a question of "refusing." The issue is that they know they're not done yet.
The kernel API is a moving target because the technology -- and knowledge behind it -- is growing and evolving. One of the more perfect examples of this evolution is Linux power management. The first released API consisted essentially of suspend() and resume(). Even back in the days of APM, this may have seemed adequate, but it really wasn't. This inadequacy was driven home when ACPI happened (ugh!), and the shortcomings of suspend() and resume() became obvious. So the kernel API was changed to try and encompass it.
Whoops! It turns out that, aside from being incomprehensibly baroque, ACPI is absolutely useless when trying to address power management issues on, say, embedded systems where power and clock throttling controls are far richer and more complex. So the API is being spun again, and this time they're trying to get something more future-proof.
Besides, your complaint is specious to begin with. Microsoft has changed its device driver API at least three times in the Windows era (and probably far more in the DOS era). This didn't stop HW manufacturers from supporting it. What it did stop was old peripherals moving forward on to shiny new HW platforms. That old joystick you loved from the company that died just before Windows 98 came out? Too bad, you have to throw it away now; there's no WDM driver for it, and there certainly won't be a Vista driver for it. Oh, hmm. Looks like someone made the necessary changes to the Linux driver source so that it'll compile under 2.6.16.
It sounds like what you're really saying is that Linux is too small a market to bother with, rather than there being any intrinsic issue with publishing driver source. If the market shares of Windows and Linux were swapped, the source code issue wouldn't be; it would just be treated as part of the landscape.
Schwab
Editor, A1-AAA AmeriCaptions
This is a bit offtopic but when is Linux going to go mainstream for general users. I've been running win2k now for 6 years and can't imagine that software companies will still be making win2k compatible stuff 5 years from now so an upgrade will be in order preferably to linux.
Any chance we'll see laptops being sold with cards based on these chips already installed any time soon? Didn't think so. So we either have to rip out the card and spend an extra $50 on a different one (do they still have those idiotic BIOS whitelists?) or live with ndiswrapper and only 70% of the card's functionality.
Everyone is born right-handed; only the greatest overcome it
You all bitch about not having open source drivers, but how many of you look at the source and trace down bugs?
The source is great for driver and kernel developers, but the average application developer could care less about this stuff when all they want is a working OS and drivers that support their hardware.
Stop tugging your little wieners about this open source driver issue. You would understand this if you had a real paying job that involve interfacing with a system that only provided a published interface and no source code.
Ok, I like Linux. In fact, I'd love to write software for it since, as a developer who leverages open source libraries, I feel like Microsoft has told me I'm no longer welcome.
... what there is is not abstract enough to be graced with that name. Module maybe fits. C'mon you geeks, seriously, what's the holdup here? What is the big problem with having a driver binary that just works across all minor revisions of a major version of a Linux kernel? That would be a HUGE plus for me.
So when I saw CentOS, I figured it was time to make the switch. It offered everything I needed. I went to fry's and bought the hardware for my new app server which included a cheapy HighPoint 1640 RAID card so I could setup a RAID 1 system. It said it supported Linux, so I figured I was good.
Well I wasn't good. There was source code for an open source driver from HighPoint. But trying to figure out how to package and build the thing was amazingly arcane and retarded! I HAD to install a floppy disk for godssakes. The experience of trying to bootstrap and get the damned open source drivers built for the thing was a long trip through the fiery pits. Equally evil was trying to figure out how to patch a new kernel with recompiled drivers whenever yum got me a new one. What a pain!
I'm a developer not a sysadmin. The fact that I figured out how to make my RAID card work with Linux was not a satisfying experience to me, it was frustrating and it was a waste of tens of hours over many months. You geeks who like to build kernels and fiddle with make files have at it. It's just not my thing.
In fact, I think there is no such thing as Linux device drivers
Whatever the case, the other poster who said it's not 1992 anymore had it right - we need some more slickness around drivers if we are going to win. And since I'm planning on not upgrading to the next version of windows, I would prefer we start winning on the desktop real quick.
Dave
"Novell isn't /. - this is the real world."
But this is slashdot. To claim this is a breakthrough on slashdot is moronic. Because its not a breakthrough, its setting us back further.
"This argument is repeated time and again here on Slashdot and the fact is it is rediculous. Want to know why? Because Novell's customers want it."
No, its not "rediculous", its perfectly accurate and valid. Because Novell's customers don't matter to linux developers. We want a free operating system we can support and debug. Novell's customers can blow a goat.
so binary only drivers aren't a problem with stability
The only way to get stability is to fix them, and the easier way to do that is opensource them. Even if you have a 100% pure microkernel, a bad disk driver won't allow you to run your programs, a bad graphics driver won't allow you to use graphics. Stability is not just about hanging, and there's not magic that you can apply to make drivers not suck.
Posts like yours always amaze me. You take a contradictory tone, then go on to explain why the parent was right, and even go so far as to give examples of how it can be done, and devices that have already done it.
I'm just saying, there *has* to be a compromise.
Either closed source drivers are required for proper use of hardware, or they're not. What possible compromise could there be?
(If people demand open-source firmware too, a compromise would be to close the firmware, and open the drivers, but I don't know if there actually is such a demand.)
Equivalent translations for appropriate points in history include:
Oh well, I couldn't play the games I paid for, but I'd be running a 100% GPL'ed box, so I should be happy with it, right? Since those games are closed source as well, that would be fine, ok, right?
I'm not a software communist; I don't support "all software should be free". It seems that the grandparent's argument is limited to the closed-ness of so many hardware manufacturers' drivers. This shouldn't be so -- they're shooting themselves in the foot.
What I want is a system that does what I want, the way I want it to (which in my case happens to mean linux, YMMV), and which lets me do the things I want to do (which in my case means installing the closed-source nvidia drivers).
Great, have fun with that. Just remember how much effort went into this operating system that does what you want, the way you want, and how much money it cost you. Remember those developers that had to reverse engineer hardware just to get working drivers, and think about the big fat insult you're giving to them each time you load a free operating system like Linux and then choose to buy a piece of hardware from a manufacturer who, in their own short-sightedness and greed, has chosen to continue making life difficult for people working on device drivers in Linux. You're willing to pay the hardware manufacturers for their crappy drivers, but using a free operating system? You seem to preach how Linux is so great, but apparently you're not putting your money where your mouth is.
Then explain why there are so many OSS projects where you can find bugs in the respective bugtrackers that haven't even been acknowledged after several years, and three-figure number of comments from people who stumbled over the same thing? Hunt the mozilla and kde bugtrackers for any number of examples.
If you don't believe that OSS has created a better operating system than closed-source, why the hell are you running Linux? First, you preach about how cool Linux is, and then you bash on other OSS projects. Linux is not an anomaly in the open-source world. Open-Source Software development works better than closed-source.
Back to the issue at hand, I agree with the GP -- hardware manufacturers don't have anything to lose by open-sourcing drivers, or even (*gasp*) releasing hardware specs. It's trading long-term profits from customer loyalty for short-term profits based on better time-to-market. It's short-sightedness, and it's hurting everyone, not just the OSS community. The latest-and-greatest hardware, driven by closed drivers, usually crashes hard on Windoze, too.
http://www.microsoft.com/windows/directx/default.m spx
That happened... No one likes rewriting from other people's interfaces...
This argument is repeated time and again here on Slashdot and the fact is it is rediculous. Want to know why? Because Novell's customers want it. In fact, they want Suse Linux to run on whatever white-box thrown-together-component list they decide, and having vendors supply drivers to reach that goal makes Novell a more attractive company.
The argument isn't against vendors supplying drivers, it's against binary-only drivers. To be honest, I don't like compiling drivers every time I upgrade my kernel, but at least I have the option with a source driver. With binary drivers, I have to wait for the vendor to supply an update. If the hardware is old, that might never happen.
I've never understood why ALL drivers aren't distributed as source. Hardware vendors don't make a dime off of driver updates, so why should they care if the driver code is open source?
That's 100% correct. Users aren't prepared to put up with drivers that are shitty and break when we make changes! You tell them how it is Cal.
They are however prepared to live with "having 1/3rd the devices supported, 1/3rd supported poorly, and 1/3rd oblivious to your existence." I saw in another post on this thread where someone mentioned that "this isn't 1998 anymore" and that's kind of interesting because in those 7-8 years we've seen Linux having "dick" in the way of drivers to now having that "1/3rd" or so supported. There's some lightning-fast progress my friend. If we can putz around like this for another 20-25 years we'll be looking at complete "2006" driver support.
Maybe.
The relative handful of Linux users today seem content with it so I don't know why Novell wants to change things. I bet they just want to increase their user numbers. Idiots.
Appended to the end of comments you post. 120 chars.
Imagine my surprise when I wasn't modded into a flaming ball of poo... ;)
Excuse my speling.
Making The Bar Project
IIRC there was no driver API to speak of in the DOS era. Since every application had full unrestricted access to the hardware with no need to bother the OS, your average driver was in no way special.
Simple: when your parents/friend/gf asks you about "that Linux thingy" that you use on your desktop, you can burn a SuSE DVD for them and know that their hardware will work with minimal effort on their part. Myself, I'll keep my Debian where I can tweak things to my heart's content. Everyone wins.
Well, as I see it Novell will work with hw companies that want to put Linux Drivers for their product, but the cool thing about this is that once working they could ship a wifi card or a printer with a CD that says "Novell SUSE Linux Support", you can open yast, add an "Add-On Product" and be done with it, what can be easier to install "supported" drivers?, not even windows is this easy (not always).
Yes, at the begining I'm sure we'll lots of binary only drivers, but I'm sure that with time some will open, I don't think that they'll want to keep up with the kABI updates for long, altough Novell will mantain their shiped kernel ABI for longer time.
I think this can be a good movement for Novell, to increse their acceptation as an OS provider and Linux in general, this may give them a better position to talk with hardware manufacturers to open up their drivers, I think Novell can take a polite aproach and be better heard after working with them in this way.
This can have positive effects too!
C-x C-c
We have compromised. Those who want to use propritary drivers and not suffer instability, don't use Linux. Compromise complete.
Linux, at least as envinished by Linus, is not some corporate drone designed to attract users. It is designed to be open. To be a learning tool. Something fun to work on. Just because some corporate interests want to make a profit off of it doesn't mean it needs to cave to them. If they can figure out how to deliver binary drivers that work, so be it. Better for them. We aren't going to go out of the way to help. Neither help nor hinder.
I am not trolling. I am one of the many, many PC users that are not code monkeys. I use Windows because (for me) it 'works'. By 'works' I mean that my PC does what I want it to do 99.99% of the time. I have however an older laptop (It's a Haus laptop: Pentium 2, 1.4Ghz, 256MB RAM, 20GB Hard disk - Haus were an own-brand badging for the former jungle.com now owned by Argos) on to which I have installed Mandriva. The experience has been interesting. I can do all sorts of OSS stuff like play OSS games and type up OSS documents and so on. The fun stops, however, when I want to anything that an ordinary PC user might want to do. I cannot surf the web because there are no Linux drivers for my Netgear or Belkin wireless cards. I cannot send or receive email because of the same reason. I cannot download new software because of the same reason. I cannot print anything because I do not have a linux driver for my printer (Lexmark X1170 - if you know of one let me know).All this means is that my Linux laptop is a mere curiosity and not a powerhouse driven by cutting edge OSS technology
Could the people who know all about APIs, ABIs and Microkernels and so on PLEASE stop bickering and just write some drivers.
Open Source of course.
Travelling forward in time at a rate of 1 second per second.
If at first you don't succeed, skydiving is not for you
If at first you don't succeed, skydiving is not for you
It's on the home desktop where binary drivers matter. There will always be new bits of hardware coming out that work a little bit better with the vendor drivers, or are too niche for anyone to write decent OSS drivers. Multi-channel sound cards for the home studio market come to mind - they come to market with a fanfare, are very useful to those who need them, but become obsolete quickly when replaced by the next incompatible product. Giving the hardware vendors a reasonable mechanism to port their Windows/Mac drivers to Linux that is consistent across distros would be a great service to home Linux users without damaging the general stability of the OS.
Same thing could have been said when Redhat introduced the RPM format. "It only works if you use RedHat and if you don't compile your own packages!" I think RPM is pretty usefull.
And again, this is for the Enterprise server. Administrators that use enterprise editions are generally into compiling their own kernels, that would defeat the purpose of an enterprise edition. They're into getting a rock solid vendor guaranteed OS that doesn't break with each security update. That doesn't combine well with compiling your own kernel.
---
"The chances of a demonic possession spreading are remote -- relax."
There is already a process for integrating device drivers into Linux. It's called "releasing your drivers under the GPL". Then they can be incorporated into the main kernel source tree for the benefit of every Linux user, not just users of a particular distribution. It is not rocket science.
SUSE already use a kernel that is patched to christ, so there's not much chance of anything compiled against a SUSE kernel working with a normal kernel from kernel.org such as Debian / Gentoo / Slackware / Ubuntu users will be using. And binary drivers are a massive step backward.
I'm not at all sure this is a good thing. It don't see how it can be anything but divisive. If SUSE users end up becoming dependent upon SUSE for access to proprietary, binary-only drivers, then that absolutely violates the spirit of Free Software.
Je fume. Tu fumes. Nous fûmes!
By reading Novell's press release and corresponding FAQ I got a feeling that this new driver support scheme is limited to Novell Enterprise line of products. OpenSUSE has not been mentioned once. If I got it right, the Linux communitity will not see any benefits of these "Enterprise Only" binary driver "solution" from Novell.
You are totally wrong, my friend. Stable Linux driver API is not necessary just for closed source binary-only drivers. It is also required for OPEN SOURCE 3rd party drivers that are not included in the kernel.
Take for example, TrueCrypt. They delive state-of-the-art cross-platform (Windows/Linux) on-the-fly disk encryption like nobody else does. The problem they (and their users) have is that they have to recompile the driver EACH FUCKING time a single bit in the kernel is changed. If every user of Linux was a developer able to compile drivers, everything would be ok. But it isn't.
Oh, yes, I forgot to add that this problem does not exist on Windows XP/2000/2003/Vista as these OS's have a stable driver API. Only Linux is major PITA for such projects.
"Buy hardware that is supported."
My hardware is supported, just not by any Linux distribution.
By the way, that reply is idiotic and snotty, and exactly defines why people despise Linux zealots.
Thanks for being an asshole and doing your part to hold Linux back.
I'm saying there's no possible compromise, you say you compromised. How? What are you not doing now that you would've liked to do?
"Just vote with your wallet."
I did. I bought an OS that works with my hardware and told Linux to suck my balls.
indeed, i bought a laptop which came with another card which i never could get to work. i ordered an intel mini pc (2915?? i think) and it worked out of the box with SUSE 10.1 (rc123 - haven't tried the release yet). This is with an amd 64 bit laptop with which i could get nothing else to work. the time i've spent screwing around with other wireless hardware makes the $30 (including shipping) a bargain
The driver and the adapter are really the same thing in a lot of cases. Things that can be done in software with no added expense would logically be put in software in many cases, instead of hardware.
If I told you the format in which an nVidia card accepts lists of vertices, and the address to which they should be written, would this help you design a better card?
It would show any optimization methods they use to transfer verticies from the application to the driver.
But even if you do your research, finding a wireless device with good Linux drivers is a crapshoot.
Manufacturers like to change the chipset without changing the product number or revision number.
When I was shopping for a pci wireless card I read reviews and checked the lists and decided to buy a card with the prism54 drivers (which are the most supported). I decided on a Hawking HWP54G which supposedly uses the prism54 chip, although there were reports newer ones used the broadcom chip (which is probably the second most supported).
When it arrived I plugged it in and found to my delight it had a crappy Texas Instruments ACX 111.
Fortunately some kind soul had hacked out a partially working driver, so it is moderately functional -- I eventually got it to pass traffic after hacking my init scripts, but dhcp always times out, it dumps tons of error messages in the kernel log, the driver seems to randomly stop functioning sometimes and I have to unload and reload the driver for it to start working again, additionally my system is noticeably less stable (but that appears to be improving with the latest release).
Of course this is more or less true with every piece of hardware, since hardware vendors like to switch suppliers to reduce costs and abstract the difference in software. It is more of a problem for wireless where Linux drivers are more sparse...
Sounds like dkms from Dell:
when you see the word 'Linux', drink!
I can't tell you exact details, as it would probably get me in trouble. I *can* say that I do linux kernel development at a fairly large telecom equipment vendor and by far the most problems we've had with any drivers were the two closed-source ones.
Eventually for one of them we signed NDAs and our developers fixed the bugs for the vendor. On the other one I kept sending back bug reports and eventually they sorted out most of the issues, although it still disables interrupts for 250ms when you load the module.
In the case of drivers for which we did have the code, there was a general trend that the vendor-supplied drivers tended to be more bloated and poorly-written than the ones which were part of the vanilla kernel.
After reviewing the comments on this item, it appears that there are still a lot of questions about Novell's intent and how the program will work. So, I called up Kurt Garloff and Susanne Oberhouser from the SUSE offices and asked them several questions about the program. The interview will appear later today on Novell Open Audio.
Out of academic curiosity, can I ask why do you write closed source drivers?
Is it a policy that was imposed by upper level management or do you have your own reasons for doing so? Or is it just the way it's always been done by your establishment and no alternative has been considered?
Is there something in your driver that discloses something about the hardware you don't want your competitors knowing about?
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
2) It was the first post. How can it possibly be "redundant"?
Ridiculous. I wish I had a mod point right now.
-Mike
I'm sorry; I don't know what I was thinking!
The relative handful of Linux users today seem content with it so I don't know why Novell wants to change things. I bet they just want to increase their user numbers. Idiots.
Oh, so it's ok because they just want to make a quick buck, and fuck us all over? They are idiots. It would be better to take the time and persuade every hardware company to release Free drivers or write every driver ourselves than take a short cut to achieving popularity by incorporating every piece of crap someone wants to write, without having the sourcecode to improve it.
These drivers may work now, but they won't work in future. Look at Vista; one architecture change, and they've had to build the driver base from scratch because they didn't have the source code. Debian has 11 different architechures; chances are a binary driver will exist only for one (or rarely, two). NetBSD has 17 different architectures; with 50 different platforms. Are vendors going to release 11 different binary drivers? No, of course not; they just want to make a quick buck.
The Linux kernel supports the majority of common hardware in some fashion. There are exceptions with some things, but pretty much, excluding Wireless Networking, we can support everything on the average desktop. It is extremely rare that you have a distro like Ubuntu or MEPIS or something that can't get working (sans wireless) on the average computer. Even with wireless, I think he have a couple of popular pieces of hardware working (I specifically remember a Belkin model). If it's not supported, someone is working on it, and we will probably one day have it. In almost every case, these drivers are written from reverse engineered specs. Maybe, if you want good driver support, you might consider going to some hardware companies and asking for documentation.
The only reason we have good drivers today is because we took the high road before. We wanted free ones, and this has meant that the quality of drivers in the Linux kernel is good. If we had taken binary ones, you wouldn't have the stable, audittable, editable, free kernel you have today.
But of course, if someone wants to make a quick buck, it's perfectly understandable if they decide to fuck us all over.