| |||||||||||||
Then there are no point and case is closed, right?Then there are no point and case is closed, right?Posted Aug 5, 2009 19:40 UTC (Wed) by khim (subscriber, #9252)In reply to: GNU + Linux = broken development model by mikov Parent article: A tempest in a tty pot
The point of a stable API is precisely that - to continue using the same source with the newer OS-es which are currently supported. Sure. And we have many OSes which promised and failed to deliver that: Windows, Solaris, etc. It just does not work. Drivers from NT don't work in Windows 2000, drivers from Windows 2000 crash the Windows XP, drivers from Solaris 8 are unusabel in Solaris 10, etc. Right now Linux supports more hardware then Windows - sure, the "latest and greatest" gadgets are supported by "latest and greatest" release of Windows only, but sheer number is on Linux side. Stable OS (not stable API, but stable OS - I certainly remember cases where switch from NT4SP5 to NT4SP6 was impossible because drivers had no suppoort for this version) makes support for some hardware easier and for some hardware harder (recall NT4 and USB, for example, then do the same with Pixel Shaders 4), so I see no huge advantages either way. What I do see is the wish to reduce number of problems for manufacturers by increasing number of problem for users and developers - and I can not agree that it's good idea. If you want to make life easier then implement stable API where it naturally exist anyway: on the border between your hardware and my hardware!
(Log in to post comments)
Then there are no point and case is closed, right? Posted Aug 5, 2009 22:17 UTC (Wed) by mikov (subscriber, #33179) [Link] Sure. And we have many OSes which promised and failed to deliver that: Windows, Solaris, etc. It just does not work. Drivers from NT don't work in Windows 2000, drivers from Windows 2000 crash the Windows XP, drivers from Solaris 8 are unusabel in Solaris 10, etc. Well, I am talking about a source level API, so I don't see your point really. Plus, I disagree with your example. The vast majority of drivers did work between Windows versions. Speaking both as a user and as an ex-Windows kernel developer. What I do see is the wish to reduce number of problems for manufacturers by increasing number of problem for users and developers - and I can not agree that it's good idea. I am sorry but you are dead wrong. Very ironically just today (about hald an hour ago) I encountered exactly the problem I am describing. I was asked to troubleshoot a Debian Lenny image on a new batch of POS machines. Well, guess what, Lenny's kernel 2.6.26 does not support the network adapter (Intel 82567LM-3). So, WTF am I supposed to do? All the "wisdom" against out-of-tree drivers and stable API expressed in the numerous responses does not help me a bit! Should I perhaps install a newer kernel version? Huh? What about security updates? Backport a driver from 2.6.28? I don't have time to do that, and I am not a network driver expert. Fortunately for me, Intel maintains an out-of-tree driver at http://e1000.sf.net/ . An out of tree driver saved the day! As usual and as expected. Unless somebody can offer me a better solution than this out-of-tree driver, I don't see how the arguments carry any weight.
Then there are no point and case is closed, right? Posted Aug 7, 2009 14:34 UTC (Fri) by deleteme (guest, #49633) [Link]
But the e1000 driver is in the tree as well, right? Which has been stated before in this thread, it's nice to have the source directly from the vendor as well.
Then there are no point and case is closed, right? Posted Aug 9, 2009 11:46 UTC (Sun) by khim (subscriber, #9252) [Link] Well, I am talking about a source level API, so I don't see your point really. What makes API so much different from ABI? In my experience breakage occurs not at format ABI/API level, but at level of semantic: old driver presume that something is done in some specific way and it does not work in exactly this way after small fix in kernel (I've personally seed cases where driver stopped working with NP4SP5=>NT4SP6 and XPSP1=>XPSP2 upgrades) - at that point the only solution is some person who can maintain driver... and if you have such person why do you need stable ABI or API? Plus, I disagree with your example. How can you disagree with truth? The vast majority of drivers did work between Windows versions. The wast majority of drivers work with Linux out-of-the-box. Speaking as a Linux user. I was asked to troubleshoot a Debian Lenny image on a new batch of POS machines. Well, guess what, Lenny's kernel 2.6.26 does not support the network adapter (Intel 82567LM-3). How is it different from my example above - where Windows XP SP2 broke drivers for Pinnacle DV500? So, WTF am I supposed to do? You know the answer - you just refuse to resign yourself to it. Should I perhaps install a newer kernel version? Yes. Either that or ask your vendor for older motherboard. What about security updates? What about them? Latest version of kernel always have the latest version of security updates applied - it's up to your distribution to package them. Remember that bug in driver can make your system volnerable (case to the point - and
conveniently it's about e1000 as well) so there are only two ways to
live: Both approaches don't need any stable API or ABI... P.S. Infromation from Windows campus agrees with me: substantial percentage of problems with the (in)famous Windows (un)stability are caused by drivers.
Then there are no point and case is closed, right? Posted Aug 12, 2009 4:12 UTC (Wed) by obi (guest, #5784) [Link]
My first reaction would have been to install Debian's 2.6.30 kernel backport - that way I get all the bugfixes and security updates too.
|
|||||||||||||