Dell Promises Pre-Installed Linux (PC World)
Dell Promises Pre-Installed Linux (PC World)
Posted Mar 30, 2007 13:33 UTC (Fri) by nim-nim (subscriber, #34454)In reply to: Dell Promises Pre-Installed Linux (PC World) by drag
Parent article: Dell Promises Pre-Installed Linux (PC World)
> So in reality Free software support in distribution releases comming even
> from rapid distributions like Fedora or Ubuntu perpetually falls behind Free
> software driver _development_ in X.org and the Kernel.
Fedora Core 5 & 6 are at 2.6.20.x level
Fedora Devel is at 2.6.21-rcx level
Find another distro "falling behind" than Fedora. They ship the drivers released upstream when they are released upstream, any lag between hardware release and driver propagation is 100% on the manufacturer side.
Posted Mar 30, 2007 16:24 UTC (Fri)
by AJWM (guest, #15888)
[Link] (5 responses)
But, a PC manufacturer like Dell is unlikely to want to load a bleeding-edge distro on their systems. Hardware model lines don't change that fast, and for support reasons you want reasonably stable and well-tested software. More to the point, though, drivers and subsystem development is often ahead of being merged into mainline.
Some years back I was somewhat involved in the 1394 (Firewire) development -- the company I was working for was developing a system (hardware and software) using DV and 1394, and I was developing using bleeding edge drivers from the 1394 subsystem development team, not yet merged upstream. Fortunately Mandrake came out with a release that they'd merged that code into -- almost a year ahead of SuSE or Redhat -- so that we could tell the customer to use that rather than providing the drivers separately.
> They ship the drivers released upstream when they are released upstream, any lag between hardware release and driver propagation is 100% on the manufacturer side.
No, it takes time for new driver code (ie code for a new device) to be merged upstream (unless it is similar enough to an existing driver that it can be merged with a small patch). Granted, with the current kernel development model it's a bit faster than in the old days, but there's still working driver code out there that for whatever reason isn't yet in the mainline kernel, hence not released upstream, and thus won't be in the likes of Fedora.
Posted Mar 30, 2007 16:48 UTC (Fri)
by nim-nim (subscriber, #34454)
[Link] (4 responses)
Read the messages users posted on the Dell site. They do *not* want Dell to do the support of the software. They *do* want Dell to take care of the drivers.
> More to the point, though, drivers and subsystem development is often
So what? You have the same problem on other OSes (Windows early USB support comes to mind). The OP singles out Linux distros for being responsible for slow driver availability, when distros "falling back" is a handy excuse to obscure the fact hardware vendors are not doing their work for Linux (both in code quality and in code availability). And justify half-backed out-of tree drivers (open or closed).
Posted Mar 30, 2007 17:57 UTC (Fri)
by madscientist (subscriber, #16861)
[Link] (1 responses)
No, you don't. The difference is that with other OSs, the kernel ABI is static or at least stable for a number of years at a time. Linux has no stable ABI, which means it's very difficult to distribute binary drivers that work for any length of time, across any wide cross-section of distributions.
That's all fine: I'm fully in agreement with Linus about ABI stasis in the kernel, and I want source code for my drivers as much as anyone. But let's not kid ourselves that this doesn't cause problems for even the most friendly hardware vendors, who are working to get their drivers into the kernel proper, as Greg K-H etc. recommend. Even with the advanced pace of kernel development there can still be a lag of a number of months before a driver for new hardware is accepted into the kernel.
And that doesn't do anything to help people who are using distros with older kernels: distros come out even less frequently than kernels, and by the time your distro releases (even if, like Ubuntu, it releases every 6 months) it's likely the kernel in that distro is 9 months or more old.
And of course, even the API in the kernel changes so drivers that you write for the newer kernel may well not work properly with older ones (and, to a lesser extent, vice versa), and that's not to mention that most distros are not configured by default to be able to build out-of-tree kernels: they don't install all the kernel headers or even, sometimes, a compiler. Yes, this is easy to remedy by the user but it adds a good bit of complexity to the entire operation.
Contrast this with Windows, where a hardware vendor can give a driver to Microsoft to be shipped with Windows, then put a disk or CD in their package with 2 or 3 versions of a driver, and cover all Windows systems shipped in the last 10 years at least, with virtually no support costs.
I'm not saying Windows has it right or that Linux should follow that model (I loathe Windows). I'm just saying we're not doing anyone, including ourselves, any favors by not admitting the truth: Linux is a more challenging environment for hardware vendors to support than Windows, EVEN IF they are completely committed to FLOSS principles (which is rare). That's a real problem and we need a real solution. I think DKMS, or something like it, is a good attempt to address this problem in a pragmatic fashion.
Posted Mar 31, 2007 11:27 UTC (Sat)
by nim-nim (subscriber, #34454)
[Link]
Yes you have and it's proved every time a new major hardware family (usb, sata, x86_64...) is introduced. Once the base support is in the kernel all is fine but till it is hardware manufacturers have to wait.
It's a complex ecosystem, it's not a manufacturer-to-user one to one (it's not under windows either but that's less clear-cut). It works perfectly for server-class hardware because everyone involved knows its responsibilities (and you have cutting-edge hardware there too) but it seems desktop-class manufacturers still have their homework to do.
1. Manufacturers for a device class are collectively responsible to get the core infrastructure needed by their device class written (either inhouse, paid-for externalisation, documentation to interested developers, etc) and submitted to the core FLOSS project managing this kind of hardware (kernel, xorg, cups, sane...). This is where most of the time is spent and you don't see it overmuch under windows because it's usually done well in advance. You'll note even though Nvidia has a closed driver its people work with xorg to get the required infrastructure done (as do Intel)
2. Then when they're ready to ship one particular device the actual device driver writting and submission can be quick and compatible with time-to-market requirements.
3. Core hardware projects (kernel, xorg, cups, sane...) have to audit and integrate these submissions in a common source release.
4. System builders like Dell have to select hardware that went through 1. 2. and 3. to provide an incentive to their suppliers, and systems to their users distributions can support.
5. Distributions have to package the source releases and make them available to users, and do community or paid-for support.
Any delay before 3. is hardware manufacturer problem (and the system builder problem is he does not push its suppliers in the right direction). Delays at 3. are hardware manufacturer problem if the submitted code is not clean enough for quick integration, and community/distro problem if there's not enough people to audit it in time. Delays at 5. (what hardware people like to complain at) are distro-side, however major distros like Fedora have already make clear they'll pick up source release quick (not like in the bad old days). If the driver pump is correctly initiated at 1. and 2. every other distro will have to follow suit. They only get by with lagging because hardware manufacturers do not provide any incentive by failing to push drivers at 1. and 2.
Getting satisfied with a foolish distro shipping half-baked code only means others won't ship it any time soon because there's nothing working to ship (the mandrake firewire example is a good one it made everyone lose months/years, if we get proper support someday that's because Red Hat is restarting at 1. now and rewriting the base class support)
Posted Mar 31, 2007 4:31 UTC (Sat)
by drag (guest, #31333)
[Link] (1 responses)
The kernel developement model nowadays, as I understand it, is:
1. Kernel developers have -mm branch for 'everything included' that they hack on. End users aren't suppose to use this.
2. Kernel developers have their vanilla kernel releases and have 'stable' support about 2 releases in the past.
End users aren't realy suppose to use this either.
3. Distributiosn take a kernel and then _those_ kernels are the ones that the end users do.
This is good because you have at least 3 levels of quality control. Hacker branches, Vanilla kernel branch, distro branch. Hopefully most bugs get found and fixed in those three things.
And it's not just the kernel. You have X. Don't forget that X has it's own drivers that are seperate from the kernel. So that is another layer of complexity.
Ok, so Fedora has 2.6.20.
At a minimum Dell is going to have to pick a professionally supported distribution. Either Redhat or Suse, or both. Then it's going to probably pick a 'free' one, like Ubuntu or (less likely in my opinion) Fedora.
So what I am talking about is a real issue. It's not a insurmountable issue, but it is a issue non-the-less.
The issue is that Dell is going to have to figure out a way to work with the kernle developers and the distribution developers to be able to provide source code-level drivers that will probably just work on relatively modern kernels irregardless of what paticular kernel version is being used.
This is a new problem for them.
The reason you don't deal with this with other operating systems is...
OS X -- Dell doesn't sell OS X, they aren't allowed to. As far as Apple goes they just are very carefull to select very specific hardware configurations.
Windows -- Dell has a sort of similar problem for Windows if they support 64bit. But otherwise...
The last desktop-oriented Windows release is 5 years old now. Vista is new and is causing all sorts of headaches for Dell.
But the headaches are just because it's new. It won't be at least 3 years for another Windows release. Probably 5 years.
That is Windows mythical 'ABI' stability comes from. They have _one_ OS at a time, and most of the time it's a old OS.
With Linux it's always new.
This is a problem for Dell, but if somebody figures out a good solution for everybody involved then we all will benifit from it and probably Dell, distros, and the kernel developers will all be better off.
I don't think that ABI stability realy matters a whole lot, it's a non-starter as far as a solution goes. At least for Linux.
Posted Apr 1, 2007 21:17 UTC (Sun)
by dlang (guest, #313)
[Link]
while there are gotcha's with some hardware that requre work-arounds in the driver, they are a lot less common that you would think.
the end result is that a well built new card will frequently just plugin and work in an older kernel, no change needed.
not all the time, but if compatability with older kernels is an issue for you, and you are selecting the hardware, you can work with your suppliers to pick hardware where this is the case.
David Lang
> Find another distro "falling behind" than Fedora. Dell Promises Pre-Installed Linux (PC World)
>> Find another distro "falling behind" than Fedora.Dell Promises Pre-Installed Linux (PC World)
> But, a PC manufacturer like Dell is unlikely to want to load a
> bleeding-edge distro on their systems. Hardware model lines don't change
> that fast, and for support reasons you want reasonably stable and
> well-tested software.
> ahead of being merged into mainline.
> So what? You have the same problem on other OSesDell Promises Pre-Installed Linux (PC World)
>> So what? You have the same problem on other OSesDell Promises Pre-Installed Linux (PC World)
> No, you don't.
I am not saying that it's impossible, just that it's a difficult.Dell Promises Pre-Installed Linux (PC World)
But Ubuntu has 2.6.18
Debian Etch is 2.6.18
Redhat has their own version, so does Suse.
one thing you are missing is that device support in linux isn't one driver per model/manufacturer of device like it is in windows, it tends to be one driver for all devices that use the same chip.Dell Promises Pre-Installed Linux (PC World)