Sic Transit Gloria Laptopi
Sic Transit Gloria Laptopi
Posted May 14, 2008 8:43 UTC (Wed) by rvfh (guest, #31018)In reply to: Sic Transit Gloria Laptopi by kripkenstein
Parent article: Sic Transit Gloria Laptopi
Thanks for that, I didn't dare myself but entirely agree with you, and RMS. I can see how difficult it is to leave anything you know for the unknown, and that's made worse by the fact that Linux still can be problematic wrt hardware (whoever is at fault is irrelevant). Anything you've come to be good at is addictive, so let children become good at 'libre' stuff rather than proprietary wherever we have the choice! I thought that was one expected outcome from the XO... which is why putting Windows on it feels so wrong.
Posted May 14, 2008 9:35 UTC (Wed)
by mtall (guest, #52045)
[Link] (6 responses)
Linux still can be problematic wrt hardware (whoever is at fault is
irrelevant).
The fault can't be placed at a set of particular feet, but here are some contributing factors:
One can take the high road and state "we reserve the right to change APIs and ABIs" just so everything in the kernel is technically pure, but at what cost does this come? The cost is not simply the developers' time (maintanance), but also a loss of contribution from 3rd parties. What is a good trade-off between purity and opportunity?
I'm not advocating the use of binary drivers, but at the very least the kernel folks could make it easier for 3rd party companies to write drivers. Contending with a moving target (e.g. APIs) necessitates having an engineer who is constantly up-to-date with what's happening in the linux kernel. Many small to medium size companies simply can't afford that. Even if they release a binary-only driver, there is at least scope for having it open sourced.
Posted May 14, 2008 12:33 UTC (Wed)
by danielhedblom (guest, #47307)
[Link] (2 responses)
Posted May 14, 2008 16:16 UTC (Wed)
by khim (subscriber, #9252)
[Link] (1 responses)
A stable API for drivers would probably encourage more people to
release drivers for Linux. I suppose you've read this, right? Stable API will guarantee worse hardware support over long run. Windows supports less hardware today then linux does - exactly because they choose stable API over source. In the end they got neither stable API (Windows Vista can not use drivers from Windows XP) nor drivers (again: a lot of stuff can only be used with Windows 9X or Windows 2000 or Windows XP). It would probably make the kernel hackers life easier too. Nope. It causes nothing but grief for Windows or Solaris developers. It's much easier to just fix the design then to apply hacks over hacks if the design was done wrong initially - but stable API will preclude first approach. At some point you have to look at constantly evolving code and think about why its never right. Requirements are changing, that's why. 15 years ago hot swap was only dream (and not very realistic at that), today it's reality. Numa was "for someone else". If you can define the task and write stable, finished task - you'll have stable API - because you'll have stable sources. Think TeX. If you are changing requirements you need new API. Other OSes introduce them all the time - they just spent a lot of time writing adaptor layers which are used to imitate old API over new one. They never work perfectly and even if they occasionally do - it's very hard work for little gain: why write all these layers upon layers when you can just fix the root of your problems? If you continually changes things endlessly its not improving anymore but rather just changing for the sake of change itself. If things will ever reach this point you'll have the choice to just use old version of kernel. If old version of kernel does not satisfy you somehow then obviously you DO need these changes and so it's not "change for sake of change"...
Posted May 15, 2008 8:04 UTC (Thu)
by rsidd (subscriber, #2582)
[Link]
If you can define the task and write stable, finished task - you'll have stable API - because you'll have stable sources. Think TeX.
Don't think TeX. It is not "finished" except in the sense that Knuth has declared the program called TeX feature-complete (from his point of view) and is aiming for bug-freeness. It continues to develop under other names -- XeTeX, Omega, etc -- and those are the only ways you can get Unicode support, TrueType/OpenType font support, and many other things that are essential today.
Posted May 14, 2008 21:49 UTC (Wed)
by flewellyn (subscriber, #5047)
[Link] (2 responses)
Posted May 15, 2008 0:32 UTC (Thu)
by mtall (guest, #52045)
[Link] (1 responses)
While it would be nice to have open specs for everything, in reality this isn't so simple. It is an uphill battle to convince company XYZ that open specs are better than trade secrets. Also, a company might be inclined to release drivers with only certain features enabled, for business reasons -- by giving open specs they are in effect giving up control of how their hardware is used (as Creative got upset with recently). Not that I am a fan of this type of "control", but that's real life for you.
This "automagic" process is neither automatic nor magic: there is considerable economic cost involved. There is no tool that automatically converts a set of code to use a new API/ABI. Someone has to do this work manually, and this is not a trivial matter in terms of effort.
Someone still needs to write the driver -- either there's a highly inclined open source developer willing to work for the kick of it, or an open source developer getting paid to do it (e.g. via Red Hat, SuSE, etc), or the company which makes the hardware. I'd say the latter has more vested interest in getting their hardware used as widely as possible.
Posted May 15, 2008 11:30 UTC (Thu)
by man_ls (guest, #15091)
[Link]
IMHO, keeping trade secrets in the driver is not such a good idea; they can be reverse-engineered fairly easily. The most successful hardware devices conform to standards anyway, and those things that give Linux users the most grief (software suspend, power management, BIOS problems, graphic card modes) seem to be those that deviate from their respective standards.
Posted May 14, 2008 11:57 UTC (Wed)
by aleXXX (subscriber, #2742)
[Link]
Sic Transit Gloria Laptopi
Sic Transit Gloria Laptopi
I agree on the ABI/API point. A stable API for drivers would probably encourage more people to
release drivers for Linux. It would probably make the kernel hackers life easier too. At some
point you have to look at constantly evolving code and think about why its never right.
If you continually changes things endlessly its not improving anymore but rather just changing
for the sake of change itself.
It was discussed many times before
It was discussed many times before
Sic Transit Gloria Laptopi
The first point is the major problem. With open specs, problem 2 goes away (no need to
reverse engineer, there's a spec), problem 3 is handled automagically (in-kernel drivers are
updated when interfaces change), and problem 4 is irrelevant (no need to release drivers if
you have open specs).
The first point is the major problem. With open specs, problem 2 goes away
Sic Transit Gloria Laptopi
Open specs
It is an uphill battle to convince company XYZ that open specs are better than trade secrets.
Companies don't have to release their trade secrets at all. Greg KH has started a project just for that task, so that hardware developers don't have to release specs if they don't want to. Sure, competitors will have the source code to the driver, but they have to reverse-engineer that too -- and while it is easier than with binaries, it is not automatic either.
This "automagic" process is neither automatic nor magic: there is considerable economic cost involved.
What flewellyn means is that once a driver is in the kernel, the hardware developer doesn't need to worry about it anymore: the kernel community will update it whenever it is necessary.
Someone still needs to write the driver
Again, the Linux Driver Project is willing to do exactly that. I believe this project is doing a great service to the kernel community, if only to remove a couple of sore points that can be used as excuses by hardware developers.
Sic Transit Gloria Laptopi
> and that's made worse by the fact that Linux still can be problematic
> wrt hardware
Without knowing more details, I'd say for the OLPC this can't be an
actual problem. They are a bit in the same position as Apple here: they
have a fixed set of hardware, so they can concentrate on getting this
combination of hardware working properly.
This is very different from a generic Linux distro which has to support
all combinations of all kinds of hardware properly.
Alex