OESF Portables Forum
General Forums => Off Topic forum => Topic started by: Snappy on June 30, 2006, 02:11:31 am
-
http://superdave.blogdns.org/articles/category/linux (http://superdave.blogdns.org/articles/category/linux)
My sentiments concur with his on that *Choice* is a double edged sword that makes linux, but is also what is making linux had to go mainstream.
-
After reading the article, I'd have to say that I'm a little inclined to disagree: it's not as complicated as superdave makes it out to be. Drivers are kernel-level stuff. Once you write one, it should be able to run just fine under both KDE and Gnome and et. al.
Admittedly, you still have a lot of kernels to choose from, but given the modular abilities of Linux, I'm not even sure if that's as much of a problem as superdave makes it out to be. I could be wrong about this, however, since I have no experience writing drivers.
-
After reading the article, I'd have to say that I'm a little inclined to disagree: it's not as complicated as superdave makes it out to be. Drivers are kernel-level stuff. Once you write one, it should be able to run just fine under both KDE and Gnome and et. al.
Admittedly, you still have a lot of kernels to choose from, but given the modular abilities of Linux, I'm not even sure if that's as much of a problem as superdave makes it out to be. I could be wrong about this, however, since I have no experience writing drivers.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=133554\"][{POST_SNAPBACK}][/a][/div]
You are right ... half right anyway ... ... KDE and gnome are the UI shells. Drivers are kernel stuffs, and yes, it should run independent of the GUI shell. But different distros may come with different version of kernel, as a result it may not work correctly for different kernels.
His line of argument is that with each variety of kernel, a company have to make choices on whether he wants to compile the binaries that work for each kernel or release the source, which as he mentioned, may reveal too much about the hardware and cannibalize their own product to asian hardware cloners.
As for UI differences, some drivers come with UI configuration panels which, depending on how its written may be GUI specific or not. Granted, certain GUI code will work across a good variety of distros, but some may break. As he mentioned, its not so much that its impossible, but it just increases the variables (exponentially?) as each layer (from kernel, UI, distro (which is a combination of the former two)) is considered.
Having said all these, I guess it fair to say that even with existing problems, if linux users are 90% of desktop users and Windows is a mere 5%, I think hardware makers will still write for it anyway. But right now, its not. And my feel is that the choice thing itself is becoming a double edge sword for linux. For Windows, its a single company (some may even say, a single person) making the decision to standardize where necessary. To a certain extent, to standardize means to drop choices. So the choice of kernel, GUI, etc can work against linux.
-
Wow, people actually read my blog?!
In response to snowfarthing's comments, the kernel level issues and the desktop environment issues are different but related. You're right that a working kernel module doesn't care about the DE. But a kernel module is often only part of what a device vendor creates. Think about something as simple as the program that installs the kernel module (a link to a source file and instructions to rebuild the kernel isn't going to do much to woo folks away from friendlier systems). Do you write a KDE installer? A Gnome installer? A Qt installer that doesn't need KDE? A GTK+ installer that doesn't need Gnome? All of the above? Why do you even have to write an installer (Windows has a plethora of software installers to choose from)?
That's just one example. How about the fancy wireless card monitor GUIs that come with most Windows wireless card drivers? Or non-generic printer configuration dialogs? Or special video card utilities? One could argue that the standard DEs make that unnecessary, but those things lead to product differentiation. Let's face it, to all but hard core techies and gamers, there's not much difference between a Linksys wireless card and a DLink wireless card other than the wireless monitor and configuration GUIs. In the cutthroat hardware biz, those silly little GUIs help get your brand remembered when Joe Sixpack goes to Best Buy looking for a wireless router.
These problems aren't insurmountable, but by the time a HW vendor is writing drivers, they're already over budget on the hardware R&D and production setup and looking to cut corners everywhere they can. Just the thought of training the support staff to answer Linux questions is enough to make most project managers run screaming from the building
-
Wow, people actually read my blog?!
In response to snowfarthing's comments, the kernel level issues and the desktop environment issues are different but related. You're right that a working kernel module doesn't care about the DE. But a kernel module is often only part of what a device vendor creates. Think about something as simple as the program that installs the kernel module (a link to a source file and instructions to rebuild the kernel isn't going to do much to woo folks away from friendlier systems). Do you write a KDE installer? A Gnome installer? A Qt installer that doesn't need KDE? A GTK+ installer that doesn't need Gnome? All of the above? Why do you even have to write an installer (Windows has a plethora of software installers to choose from)?
None of the above, you just create a package (deb, rpm, tgz) for all common distributions. There usually are GUI apps preconfigured so the user can install the packages w/o using the command line.
The user is running a self-compiled kernel so the precompiled module doesn't work? Well this user should better well know how to compile the module from sources then.
There are no sources? Well that user should have researched the hardware in question before buying.
In an ideal world you would push your driver upstream and have it included into the vanilla kernels.
That's just one example. How about the fancy wireless card monitor GUIs that come with most Windows wireless card drivers?
You don't supply your own but use the the commonly available applets for $GUI.
If $GUI's app doesn't work with $YOUR hardware then the easiest way for any company would be to send a patch for this card upstream. Anything else is unacceptable (think shipping binary-only apps which only run on $SOME_SPECIFIC_SYSTEM).
One of the biggest advantages I personally see over windows is that I do not have to use any of the spyware ridden, bloated and usually buggy crap that comes with the installer CD!
I get to use quality OSS software instead
Or non-generic printer configuration dialogs? Or special video card utilities? One could argue that the standard DEs make that unnecessary, but those things lead to product differentiation.
The company would have to ship source packages for something like this. Anything else is unacceptable since $RANDOM_BINARY_CRAP stops working after the product is EOL'ed and $SOME_API_OR_WHATEVER is changed in Linux. See all loki games that won't run on Debian SID but work fine with Debian Woody (yes, woody).
Oh and the company would now indeed have to write a GUI-Based installer for this kind of thing. One that is compatible to Gnome, KDE, WindowMaker, XFCE and all the WMs / DEs out there. Not going to happen anytime soon, now, is it?
Let's face it, to all but hard core techies and gamers, there's not much difference between a Linksys wireless card and a DLink wireless card other than the wireless monitor and configuration GUIs.
Exactly! That's my point!
Many many devices are just bloody clones of a reference implementation of $SOME_CONTROLLER_VENDOR. I buy my hardware because of the chipset it runs, not which company logo is on the box. If I get to buy a $QUALITY_BRAND device with supported chipset then that's great. If not I'll just buy $RANDOM_TAIWANEESE_CLONE which is going to work just as well (it's the same bloody thing internally after all)
To differentiate your company in the Linux community all you have to do is:
- open the specs of your hardware to developers, NDA is (usually) acceptable
- help said developers to create a quality OSS driver for your hardware
- Ideally do the above before shipping a product to market
- And we all love a picture of Tux next to the Apple and Windows logos on the box
In the cutthroat hardware biz, those silly little GUIs help get your brand remembered when Joe Sixpack goes to Best Buy looking for a wireless router.
Not with Linux, see above. If your company is Linux friendly, word will get around pretty fast. You don't need the useless branded GUI crap in Linux if your community support is very good, trust me.
I know for sure that I only buy hardware that is supported. And when I read lines like "Vendor XY was nice enough to send full specs of their hardware" then I'll go out of my way to support said vendor (because I know the driver will be top-quality, not some reverse-engineered thingy that oopses every 5 minutes. No harm ment to reverse-engineers, I have deep respect before your work, really.)
Not to mention that usually the stuff that ships on the installer CD is
- so buggy it's almost (but not quite) unusable
- intrusive. Why does a bloody PRINTER driver install a god damn taskbar applet (or whatever that's called in windows)
- Why in gods name does a SOUNDCARD driver install 40Mb (!!) worth of "driver" with all kinds of crap like a 2nd taskbar on the top and 3 bazillion "sound fonts"? (whatever *that* is)
I have yet to see a single windows installer disk that just ships the driver and working(!), unintrusive(!) and actually useful(!!!) software.
These problems aren't insurmountable, but by the time a HW vendor is writing drivers, they're already over budget on the hardware R&D and production setup and looking to cut corners everywhere they can.
Sending the spec sheets to OSS developers who are interested isn't going to cost them a dime. And they usually don't even have to spend man-power on a Linux driver as everything is done by the community.
Just the thought of training the support staff to answer Linux questions is enough to make most project managers run screaming from the building
[div align=\"right\"][a href=\"index.php?act=findpost&pid=133565\"][{POST_SNAPBACK}][/a][/div]
Yes, that may be true. A forum for the community would probably suffice. Along with *one* guy that is a Linux expert and knows your hardware in and out.
It is my experience that 80% of all problems are unrelated to any software / driver bugs, but caused by $NOOB_USER who doesn't know how to setup $DEVICE in $DISTRIBUTION if he isn't presented with a metric ton of GUI wizzards to wipe his ass.
Sorry to sound rude but it's driving me crazy at times. One only has to read certain hardware based Linux forums to see that most questions asked could be answered by anybody that knows Linux very well (Blahh blahh, module doesn't auto-load, Yadda Yadda device-files are not created and my favorite: I've "plugged" it in but nothing happens)
Two of the above questions can be answered on the spot with the help of Google or good Linux knowledge, the third is asked by lazy users who can't be bothered to use a bloody search engine.
Small vendors may not have this option tho but it surely can't be a problem for a big corp to pay *one* guy to support an entire operating system.
/end-of-rant
I'm feeling a little bit better now
-
CoreDump, for the most part I completely agree with your take on how things "should" be. Unfortunately, the utopian situation you describe just isn't going to happen.
The problem is that as soon as hardware vendors totally open their specs, it lowers the bar for the cloners to the point where they don't even have to lift their feet to get over it. What's to stop a cloner from building a product that's so compatible that they don't even have to offer their own drivers? They could just point customers to the original vendor's website. Technically they wouldn't be doing anything illegal. If anyone is doing anything wrong at that point it's the end users downloading driver's they're not licensed to use. Will the majority of users care if it saves them $20? Probably not.
Look at the rare cases where a hardware vendor openly supports Linux and ask how do they make it work? Nvidia pulls it off, but they don't actually make the end device. Their products are made exclusively by "cloners" implementing Nvidia's reference designs. Cloners have to buy chips from Nvidia so the drivers essentially come with the chip. But note that Nvidia doesn't open thier chip specs. The driver is a closed binary because if cloners could copy the chip, and use Nvidia drivers without buying Nvidia chips, Nvidia would lose big time. The situation with ATI is similar. They flirted with opening their specs for a while, but that was pretty short lived.
Similarly, you'll find that where network adapters have open specs, it's because the chipset vendor (not the card vendor) has opened them up in hopes of encouraging card vendors (and cloners) to use their chipsets. This works ok in cases where chipsets are complex and hard to duplicate, but with simpler devices like sound cards, webcams, scanners, printers, etc. the core technology is just not that hard to reverse engineer. There is no chipset vendor to source the driver software and as soon as they have to roll their own, vendors will go out of their way to protect that investment.
So, given the real world in which we live, I still contend that unless vendors have a way to create a single closed binary driver that will run on the vast majority of Linux distros, it's just not going to be seen as worth the extra effort.
-
CoreDump, for the most part I completely agree with your take on how things "should" be. Unfortunately, the utopian situation you describe just isn't going to happen.
The problem is that as soon as hardware vendors totally open their specs, it lowers the bar for the cloners to the point where they don't even have to lift their feet to get over it. What's to stop a cloner from building a product that's so compatible that they don't even have to offer their own drivers?
While I'm not in the hardware business, I find it hard to believe that it is easier to reverse-engineer an entire chipset based on driver sources than to build one from scratch.
They could just point customers to the original vendor's website. Technically they wouldn't be doing anything illegal. If anyone is doing anything wrong at that point it's the end users downloading driver's they're not licensed to use. Will the majority of users care if it saves them $20? Probably not.
Err, in the world _I_ live in, 90% of all products on the market are just clones off a reference design made by a controller / chipset manufacturer.
Think of graphics cards, network cards in all shapes, DVB recievers (PCI / USB), WLAN cards and basically anything else.
How many different WLAN cards are out there? Hundreds if not thousands. And how many different chipsets exist? Maybe 20.....
Which hardware vendor can afford to produce his own chipset these days? Almost everyone uses an allready existing one for low-profit hardware.
Look at the rare cases where a hardware vendor openly supports Linux and ask how do they make it work?
All they have to do is to open the specs to their hardware. Usually the chipset manufacturer gives out the specs which then makes a bazillion clones of that chipset work. The manufacturer is indeed interested in making the hardware linux compatible since every sale brings in $$$. And it doesn't cost them a bloody penny to do so. Who would not do that?
Nvidia pulls it off, but they don't actually make the end device. Their products are made exclusively by "cloners" implementing Nvidia's reference designs. Cloners have to buy chips from Nvidia so the drivers essentially come with the chip. But note that Nvidia doesn't open thier chip specs. The driver is a closed binary because if cloners could copy the chip, and use Nvidia drivers without buying Nvidia chips,
Err, lol. I doubt that anyone could come up w/ a "just-as-good" chip only based on the drivers source. A compatible one yes, but not with the same quality that comes w/ many years of experience of creating graphics chipsets.
Nvidia would lose big time. The situation with ATI is similar. They flirted with opening their specs for a while, but that was pretty short lived.
These two keep the sources closed so Joe Sixpack doesn't get to hear about all the "optimizations" they did to cheat in benchmarks.
Similarly, you'll find that where network adapters have open specs, it's because the chipset vendor (not the card vendor) has opened them up in hopes of encouraging card vendors (and cloners) to use their chipsets. This works ok in cases where chipsets are complex and hard to duplicate, but with simpler devices like sound cards, webcams, scanners, printers, etc. the core technology is just not that hard to reverse engineer.
See above. With these simple things it would likely be easier to create a chipset from scratch than reverse engineer it based on a driver.
There is no chipset vendor to source the driver software and as soon as they have to roll their own, vendors will go out of their way to protect that investment.
So, given the real world in which we live, I still contend that unless vendors have a way to create a single closed binary driver that will run on the vast majority of Linux distros, it's just not going to be seen as worth the extra effort.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=133687\"][{POST_SNAPBACK}][/a][/div]
Not going to happen anytime soon.
-
While I'm not in the hardware business, I find it hard to believe that it is easier to reverse-engineer an entire chipset based on driver sources than to build one from scratch.
That's the problem. Your arguments hinge on logic and reason, but the people calling the shots at most hardware companies aren't engineers. The decisions are made by business people who boil everything down to risk vs. reward. It doesn't matter that the odds of Linux support compromising their market position are low, all that matters is that the odds of not supporting Linux compromising their market position are lower.
If your position is "we insist that you change your whole business model to support Linux" guess what's going to happen? That Open Source sense of righteous indignation, that "our way" is the only way, just isn't a position you can take when you're this small a minority regardless of how right you actually are.
The Linux community isn't in a position to dictate supplier behavior. We either make it easy for hardware vendors to support us (radical business model changes are not easy no matter how much development effort they may save or how good they may be in the long run) or vendors will simply ignore us as they've typically done in the past. That was the fundamental premise for my blog post, and it's based on first hand experience in the hardware development business.
Novell (SUSE) sort of "gets it" and has created their Partner Linux Driver Process (http://developer.novell.com/wiki/index.php/Category:Partner_Linux_Driver_Process) to address the problem. It doesn't go nearly far enough, but at least they're trying. I was quite surprised by the amount of vocal resistance from the Open Source community when this was announced (much of which was from folks who couldn't even be bothered to actually read what Novell has proposed).
Yes, the reluctance of hardware vendors to embrace our way of thinking frustrates me. But the unwillingness of the Open Source community to make any concessions that could get us better hardware support frustrates me just as much.