| |||||||||||||
GNU + Linux = broken development modelGNU + Linux = broken development modelPosted Jul 30, 2009 19:41 UTC (Thu) by mikov (subscriber, #33179)In reply to: GNU + Linux = broken development model by Tomislav Parent article: A tempest in a tty pot
It seems to me that he's not missing it by much. Although I would prefer a stable API it looks like this is a matter of priorities. If you prefer stability and longevity, you choose RHEL or Debian and stick with their kernels. RHEL 4 supported 2.6.9 for 4 years. As I pointed out, that doesn't work. First, what are you supposed to do with this stable kernel if you want to use newer hardware? Secondly, every vendor and distribution has a different "stable" kernel, which in turn is different from the vanilla kernel with the same version. So, what do you do if you a hardware vendor? Even if you have included your driver in the mainline in 2.6.30, who does it help your customers some of who are using 2.6.18, some 2.6.9, some 2.6.26, etc? Is anybody surprised that hardware vendors are not keen on supporting Linux? Lastly, even if there was only one stable distribution in the world, 4 years is a far cry from 15. :shrugs: You pointed out (several times) that you are speaking from the developers standpoint. But here you base your argument on a claim that _businesses_ and _users_ want a stable API. It's the ABI they (well, me at least) care about. Clearly I mean businesses who develop and support software and their customers who are affected by it because their reliability goes down and their costs go up. What I am going for here is that an enthusiastic hacker who is happy to recompile his own kernel daily (like most of us) can't always see the big picture. Another thing here that sticks in my eye, and I see that I'm not the only one, is the allusion that Microsoft offers support for it's kernel for 15 years. IMO nobody there has touched the NT4 kernel for quite a while and would be greatly surprised if the NT5 family had any recent updates. They are only stable by virtue of being old. Huh? Who is talking about support? The point of a stable API is precisely that - to continue using the same source with the newer OS-es which are currently supported.
(Log in to post comments)
Then there are no point and case is closed, right? Posted Aug 5, 2009 19:40 UTC (Wed) by khim (subscriber, #9252) [Link] 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!
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.
|
|||||||||||||