| |||||||||||||
|
| |||||||||||||
A Sun engineer on LinuxA Sun engineer on LinuxPosted Sep 23, 2004 15:36 UTC (Thu) by einstein (subscriber, #2052)Parent article: A Sun engineer on Linux
Very interesting... Sun takes a wad of cash from microsoft, and lo and behold, they turn up the volume on their anti-linux FUD. They are sounding more and more like sco.
(Log in to post comments)
A Sun engineer on Linux Posted Sep 23, 2004 15:42 UTC (Thu) by alonso (subscriber, #2828) [Link] The evil has tree letter.... I think will be better if we'll spell I.B.M. :)
A Sun engineer on Linux Posted Sep 23, 2004 16:29 UTC (Thu) by rcbixler (guest, #11917) [Link] Speaking of SCO, it ought to be interesting to see if they balk at Sun'smove to open source Solaris. After all, according to SCO's theories, Sun is a System V licencee, Solaris is a derivative work of System V and therefore they are obligated under their licence to keep the Solaris source code confidential.
SCO on open-sourcing Solaris Posted Sep 24, 2004 15:32 UTC (Fri) by Duncan (guest, #6647) [Link] > [I]t ought to be interesting to see if [SCO]> balk at Sun's move to open source Solaris. They already have. The official word is that while Sun bought more rights to the code than anyone else has, even that has limits, and open sourcing the code goes beyond those limits. (That's what Chris Sontag stated in a recent interview. Unfortunately I don't recall where the article was that I was reading, likely ZDNet or CNet, maybe linked from a Groklaw article thread, as I spent a couple hours on those three sites yesterday.) Duncan
A Sun engineer on Linux Posted Sep 23, 2004 16:45 UTC (Thu) by Duncan (guest, #6647) [Link] OK, I'm certainly not particularly a Sun lover myself (and believe Java isslowly becoming irrelevant, particularly on open source, because they refuse to truly libre-ware it), but here, you are certainly sinking into anti-Sun FUD yourself. LWN didn't do a very good job of excerpting a good summary of the article, and it's obvious you didn't RTFA yourself either, because the context there is entirely different. The context of the article is a Sun kernel engineer commenting about their plan to "open source" Solaris. Now, while we don't yet know /how/ "open source" this "open source" will be, and while that raises significant questions only to be answered with time, Sun /has/ stated that they /will/ ensure it is an OSI approved license. Granted, that still leaves an awful lot of wiggle room, and this step may or may not be of serious significance to the Linux portion of the open source community in particular depending on just what the license terms are, but in /any/ case, Sun has obviously come a /long/ way already, and just the fact that they've pledged to do it and pledged to make it OSI approved, will (when it actually happens) put them miles ahead of MS's so-called "shared source initiative", which amounts to "if you have the money or the bureaucratic clout, you can look, but only we get to touch." Within that context -- within the context of a corporation the size of Sun doing the soul-searching and largely internal debate necessary for such a step, occurs the quote LWN excerpted. Taken within context, then, it's simply a statement of the position they take in regard to the question of why not just dump Solaris and jump onto Linux? Within that context, that's a legitimate question to be asked, and this blog entry is a decent attempt at an answer -- from the viewpoint of the poster, who admits he could very well be eating his words if Sun /does/ go with a GPL compatible (therefore proprietary-banning, other than their own, of course, much like a number of companies already do, MySQL and Trolltech with QT, among them, GPL licensed for free source use, but pay them if you want to take it proprietary -- a valid model the GPL approves of) license. RTFA (Read the "friendly" article), it's worth it! I don't agree with everything he says, but a lot of it is certainly valid from their perspective. Taking the simplest example, direct from the LWN quote, the kernel hackers have a deliberate and stated policy of *NO* ongoing binary compatibility, for at least two reasons. One, being tied to binary compatibility can seriously hinder further development and they don't want to tie themselves down due to having to maintain compatibility with some previous mistake. Two, within kernel binary compatibility context, the only folks that need to worry about it are out-of-kernel module developers, in particular, those (such as NVidia) developing closed source proprietary modules, refusing to open up their own code. Rightly or wrongly, the kernel developers have taken the position that encouraging proprietary modules isn't something they want to do, and therefore, they feel under no obligation to bend over backward to maintain binary compatibility as a help to proprietaryware, particularly when doing so would at times be at the expense of flexibility in further kernel development. That's a great position for the kernel hackers to take, and one I definitely agree with. However, it /will/ make things difficult for the likes of Sun, who are in the business of supporting customers that just want their hardware to work, and would consider having to procure new proprietaryware drivers for it every time they upgrade a kernel a big hassle. Therefore, while I agree with the Linux kernel hackers' position on the matter, that of Sun, wanting their own kernel to support binary compatibility, is a legitimate and reasonable position as well. Far from FUD, it's a legitimate concern. Anyway, like I said, RTFA. Reading some of the articles linked from it also proved informative. It's really quite fascinating (and educational) watching Sun come to terms with this code open sourcing attempt, both internally and in its external relationships. I'm glad LWN linked the article and drew my attention to it, tho certainly a couple sentences of context within which to place the chosen excerpt, would have been better. Duncan
A Sun engineer on Linux Posted Sep 23, 2004 17:57 UTC (Thu) by mmarq (guest, #2332) [Link] " Taken within context, then, it'ssimply a statement of the position they take in regard to the question of why not just dump Solaris and jump onto Linux? "
Simple, they are affraid to lose the market differentiation that they are about to lose anyway with Solaris... so Solaris must desperately compete with Linux...
IMO they should dump completly their Sparc operations, and trying to join hands ( that is not much of their culture ) to create a truly Open Source Hardware Platform with Open/Linux BIOS and defined design for Chipset supporting the different processor architectures.
This turmoil not only resembles SCO,... it resembles a battle for scraps, where the only one laughing is Microsoft.
A Sun engineer on Linux Posted Sep 23, 2004 19:16 UTC (Thu) by marduk (subscriber, #3831) [Link] But IBM is all but ditching AIX for Linux. Why not the same? I know that IBM has decided not to compete with Linux but rather to support it via 2rd parties. But is the OS, or control thereof, really that important for Sun?
Oh wait, these are the same people that have Java locked up.
A Sun engineer on Linux Posted Sep 23, 2004 21:41 UTC (Thu) by mmarq (guest, #2332) [Link] Perhaps because the main business at I.B.M. are already Global Services,..., in SUN it still is Server Iron...Anyway i dont belive they will dump AIX interely.
A Sun engineer on Linux Posted Sep 23, 2004 23:42 UTC (Thu) by cajal (guest, #4167) [Link] IBM is not "all but ditching AIX for Linux." They still sell quite a lot pSeries machines to run AIX.They have said that in the big picture (i.e. 10 years) they will try to migrate users to Linux, but IBM has been known to change their position in the past. And, frankly, given IBM's history, they'll sell the customer whatever he wants, so their commitment to Linux could change.
Sun has made the decision that they want control over their primary OS. Frankly, I think that's a
Frankly, it sickens me to see so much Sun-bashing on this site - it almost reads like Slashdot.
A Sun engineer on Linux Posted Sep 24, 2004 1:25 UTC (Fri) by hppnq (subscriber, #14462) [Link] Frankly, it sickens me to see so much Sun-bashing on this site - it almost reads like Slashdot. You one of the regulars over there? You've got to be kidding, by far most of the comments I read here are well informed and quite reasonable. Either you don't really know what you're talking about (I'm sorry I have to say it seems so from the rest of your post), or you are deliberately ranting. In both cases, yes, you would fit in better on other sites.
A Sun engineer on Linux Posted Sep 24, 2004 1:48 UTC (Fri) by cajal (guest, #4167) [Link] Actually, I'm not a regular on Slashdot. I agree that most of the comments on LWN are pretty good; except when the topic of Sun and/or Solaris comes up. Then the rapid Sun bashers come out. And what exactly was so unreasonable about the rest of my post?
A Sun engineer on Linux Posted Sep 24, 2004 2:28 UTC (Fri) by hppnq (subscriber, #14462) [Link] Still, I have to strongly disagree with your take on Sun bashing at lwn.net. Perhaps you have noticed that Sun has been campaigning quite actively lately? That might account for the increased attention over here. Disagreement with points of view does not add up to bashing. Read the comments again.I think you don't know what you are talking about, when you say -- for instance -- that IBM sells pSeries to run AIX. IBM needs an OS to sell their expensive hardware, it's not the other way around. Even worse is your statement that it would not be very wise for Sun to ditch Solaris and start patching the Linux kernel continuously. (What do you think they are doing right now? Yes, they are frantically patching Solaris, continuously.) That statement shows that you have not completely grasped the way Open Source software development works. I agree with you on the importance of this weblog entry: in itself, it is very insignificant indeed. For the very poor reasoning alone, it does not deserve the attention it gets here. (Another thing: don't get me wrong, I've got nothing against you -- I haven't even got much against Solaris, except that I personally do not like it -- and you of course have every right to criticize whatever you like, but let's keep it fair. ;-)
A Sun engineer on Linux Posted Sep 24, 2004 4:07 UTC (Fri) by cajal (guest, #4167) [Link] I'm not saying that disagreement constitunes bashing. But I think the "oh look, they got moneyfrom Microsoft, now they're evil" and the "SPARC sucks, Sun is dying" type comments do constitute bashing, and I'm seeing more of them on LWN over time.
I disagree with just about everything else you said. The majority of IBM's pSeries machines run
Re: Sun, I stand by my statement. Sun has decades of experience with Solaris. Why should they
As for not grasping the way open source development works, I'm afraid you're mistaken. In fact,
A Sun engineer on Linux Posted Sep 24, 2004 4:50 UTC (Fri) by einstein (subscriber, #2052) [Link] The guys said:But I think the "oh look, they got money from Microsoft, now they're evil" and the "SPARC sucks, Sun is dying" type comments do constitute bashing, Are you being deliberately obtuse? you severely distorted what was said, and one can only wonder what your motivation is. Contrast your rant to the actual comment, a simple observation: Sun takes a wad of cash from microsoft, and lo and behold, they turn up the volume on their anti-linux FUD. I'm no stranger to sun, my first real unix experience was on sunos back in the early 90s, and I have been a sun advocate on the job for years. But that doesn't give them a pass for all the ridiculous anti-linux FUD they are throwing around now. I was just talking to a sun engineer the other day about linux and solaris in the data center, and he started right in with the party line, laying it on thick about how linux is cheap and ok for the low end, but crashes all the time unlike the rock solid solaris (har har). The fact is, we run linux and solaris boxes, and both OSes normally have uptimes in the hundreds of days - I see absolutely no difference. The trash talk sounds like they are reading from a script. blech, I won't waste any more time or energy defending sun, whatever happens, happens.
A Sun engineer on Linux Posted Sep 24, 2004 5:06 UTC (Fri) by cajal (guest, #4167) [Link] *Sigh*First, my comment wasn't a rant. But I guess that distinction is lost here. Secondly, what does this have to do with "anti-Linux FUD" from Sun? This article is about someone's personal opinion, not an official statement from Sun. It was in some guy's blog. Seriously. No, I was not trying to be obtuse. I was paraphrasing. Comments like the two you quoted, as well as: Just a window into the unbelievable arrogance of Sun (or at least some at Sun). If they don't wise up soon, they will be gone. and Oh I see now how Sun is going to trash Linux. are pretty much just mindless Sun-bashing, most likely by people who didn't bother reading the blog entry. neoprene's comment is also an example of this, although slightly less so -- it reeks with open-source, Linux arrogance, insuinating that Solaris' codebase is of no use. I'm just tired of the GPL elitism on what is supposed to be a technical news site.
A Sun engineer on Linux Posted Sep 24, 2004 5:48 UTC (Fri) by hppnq (subscriber, #14462) [Link] Okay, I'm not really sensitive to trolling, and I hate to depict people as trolls, but this leaves me no other conclusion: you are a troll.Pity.
A Sun engineer on Linux Posted Sep 24, 2004 12:46 UTC (Fri) by cajal (guest, #4167) [Link] Thanks for proving my point - that on LWN (just like on Slashdot or OSNews) anyone who doesn'tbuy the party line that "Linux rules and Solaris sucks" is branded as a troll.
A Sun engineer on Linux Posted Sep 24, 2004 21:47 UTC (Fri) by mdekkers (guest, #85) [Link] dude, Sun got money from Microsoft, now they're evil! Oh, and SPARC sucks, Sun is dying.... Just so you know....
;-)
A Sun engineer on Linux Posted Sep 25, 2004 16:14 UTC (Sat) by Tao (guest, #24985) [Link] Cajal,
You should be proud of being called a troll by the real troll (the worse kind) :)
Tao
A Sun engineer on Linux Posted Sep 24, 2004 5:40 UTC (Fri) by hppnq (subscriber, #14462) [Link] Okay, please show me the comments then, if you insist. The only "SPARC sucks" type of comment I have seen so far here seemed to defend Eric's stance rather clumsily.You cannot seriously mean what you say about IBM's deployment of AIX. IBM ships high-end pSeries with AIX because Linux isn't ready for it yet?! That's a nice one, hadn't heard that before! (Since that is the only reason you mention, please don't catch me on that one, I know a few more reasons why IBM would want their own OS for their hardware.) Here is the current recommended patch set for Solaris 8. Note the revisions. That's what I call frantic. If you want to talk features with me, not bugfixes, please take a good hard look at the features that Solaris 10 offers, they're hilarious. Also, note the remarkable similarity to Eric's piece. And, of course, the punchline: Linux binaries run natively on Solaris 10. Claiming that Linux has a binary compatibility problem itself is sheer stupidity. If you want to call that bashing, please, go ahead, but pick another platform. I applaud your apparent commitment to Open Source, but I still think you do not fully get it.
A Sun engineer on Linux Posted Sep 24, 2004 13:09 UTC (Fri) by cajal (guest, #4167) [Link] Ok, one last time, because I just don't care enough to continue this thread anymore....Yes, AIX has features and hardware support for pSeries hardware that Linux lacks. Yes, this is one reason why IBM still ships AIX. There's also the issue of application support. And some environments have been running AIX for years and don't want to retrain their staff on Linux. I'm not saying that no one is migrating from AIX to Linux, just that I don't see it happening en masse. In the long run, I do think IBM's hardware strategy is interesting -- in a few years' time it should be possible to run AIX, Linux, i5/OS and z/OS on the same machine in different LPARs. It's also interesting that you don't bother listing what any of these "few other reasons" are, but I'll leave that alone for now. All your link to the Solaris 8 patchcluster proves is that Solaris, like Linux, AIX, Windows and everything else, requires patches. Solaris 8 is four years old, after all. As for Solaris 10, I'm very much impressed. Have you read the DTrace Guide? Predictive Self- healing also looks to be quite useful; I'm looking forward to testing it out on my test machine. I'm not crazy about Sun's use of so much XML for it, but I can live. As for the rest, I don't see how they're "hilarious" -- a faster TCP stack, a new filesystem, improved process rights management, etc. They all look useful. Maybe if you looked into them further, rather than just linking to a marketing page by Sun you'd realize that. Frankly, I'm still waiting for Linux to be able to properly handle large pages. (yes, ok, that last line was a troll, I was in a jovial mood). Now, as concerns your allegations of trolling, I have to say it sounds to me like you're being the troll. This is the second time you've told me that I "just don't get it" when it comes to open source development, and now you claim that I only have "apparent" commitment to open source, but you haven't offered any reasons at all for that statement. Sounds like more baseless namecalling to me.
A Sun engineer on Linux Posted Sep 24, 2004 2:37 UTC (Fri) by marduk (subscriber, #3831) [Link] Dude, relax...
I was merely asking a question, mainly that why does Sun consider Solaris so significant from a business POV whereas many other Unix companies seem to be jumping on the Linux bandwagon.
You did provide some insight into my query, though not entirely to my satisfaction.
Basically I was not "bashing" Sun. I agree that LWN may have overreacted to the blog posting, but I feel like you're overreacting a bit yourself. Relax.
A Sun engineer on Linux Posted Sep 23, 2004 18:45 UTC (Thu) by mmarq (guest, #2332) [Link] " Rightly or wrongly, the kerneldevelopers have taken the position that encouraging proprietary modules isn't something they want to do, and therefore, they feel under no obligation to bend over backward to maintain binary compatibility as a help to proprietaryware. "
Agree as a principle that is coherent.
"That's a great position for the kernel hackers to take, and one I
That i dont agree with the spirit of the sentence. The problem *is not* or *should not* be the likes of SUN, but thousands and thounsands of advanced users and IT professionals that are the 'strongest' Linux adopters (not the six pack commom joe users and not the somehow *affraid* big entreprises and goverment institutions),... and that 'strongest' Linux adopters have the power to completely change the IT landscape... if only given the chance...
IMO what Open Source needs in that department, is again standards, not Linux standards but a Open Source Driver Model from OpenDarwin to BSDs to Linux and possibily OpenSolaris,... let the *better* kernel win !...
In my low technical ability of this matters, i belive, that that could be achieved with a message passing communication layer, forming a ´split´ Driver Model, similar in spirit to I2O, and not requiring no one to bend over to any ABI compatibility...
Better for what i can understand of D-BUS: http://www-106.ibm.com/developerworks/linux/library/l-dbu...
...well just a good idea anyway... at least an idea, IMO, that has the power to percipitate the entire Hardware Industry to jump head first into the Open Source bandwagon.
A Sun engineer on Linux Posted Sep 23, 2004 21:30 UTC (Thu) by khim (subscriber, #9252) [Link] In my low technical ability of this matters, i belive, that that could be achieved with a message passing communication layer, forming a ´split´ Driver Model, similar in spirit to I2O, and not requiring no one to bend over to any ABI compatibility... Hmm... Possible ? Yes. Feasible ? Hardly. For example if you are using right kind of hardware then data can be transferred from disc (via DMA) straight to network card buffer - without processor help and in some cases even without main RAM involved. It's quite easy to do with linux kernel (if hardware is capable): drivers know enough about kernel internals to easily shuffle data around in such a way. It's very hard to develop something like this with "split drivers". Proprietary drivers have nasty tendency to become broken and obsolete long before hardware becomes unusable. Windows suffers from this horrible. "Oh, your three year old winprinter have drivers for Windows98 but not for WindowsXP? Sorry - we can not do anything with it. You USB gadget works fine with Windows2000 but will crash WindowsXP? Try to ask manufacturer and pray...". And this is Windows! With mighty Microsoft behind it! You can be very sure binary drivers for "split driver model" will have a lot of kludges, will break constantly (it's one thing to write specifications for "correct split drivrs" and it's quite another thing to make vendors do drivers really compatible with abstract specifications and not with real Linux 2.6.8.1 or FreeBSD 5.2) and so on. Just like most binary-only Linux drivers today. No, it does not worth it. Too many problems, too little gain. Solaris x86 does support far less hardware then Linux after all.
Why a split model makes sense Posted Sep 23, 2004 22:58 UTC (Thu) by mmarq (guest, #2332) [Link] " be transferred from disc (via DMA) straight to network card buffer - without processor help and in some cases even without main RAM involved...... drivers know enough about kernel internals to easily shuffle data around in such a way. It's very hard to develop something like this with "split drivers". "
Processores, memory and disk always had plenty of good support in many Open Source kernels, *you simple dont have to put everything under a 'split model'*.
By the way, it is very hard to me to discuss deep technical details of kernels, but never the less i suspect that with my example about D-BUS extension it wouldn't be that hard,...
" Proprietary drivers have nasty tendency to become broken and obsolete long before hardware becomes unusable... "
That is the main reason because a split model, not ABI compliant, makes all the sense... nasty or not the software can be mended, but the hardware can only be changed, even inside a family... as simple as that.
"You can be very sure binary drivers for "split driver model" will have a lot of kludges,... "
True. But worst than kludges is no support at all... and you can always harden the kernel, like in patches that circulated before 2.6.0, i belive, and that were supposed to kick out from running any kernel module that breaks... and join to that the possibility of load the tiny 'split' extension portion, in RING 0 or RING 1 of the processor, far way from userland where Windows drivers get massacreded by all sort of "your computer is mine" software and other malware.
And if a 'split model', light on overhead, and with little "intrusivity" because it dosent need an ABI compliance, is negociated trough out the all Open Source landscape, i belive, the hardware industry will jump right on because the "same" driver will be possible to run from OpenDarwin(Apple Iron) to the BSDs to Linux and OpenSolaris... then we get to know which kernel is the best, and not having people talk the talk in blogs, and them having excuses for not being able to walk the walk.
Why a split model makes sense Posted Sep 24, 2004 22:23 UTC (Fri) by khim (subscriber, #9252) [Link] True. But worst than kludges is no support at all... Not true. It's much better to know that this or that piece of hardware is "no-go" then to buy RAID-controller with Penguin on sticker and only crappy driver for Linux 2.4.10 or somwathing. and you can always harden the kernel, like in patches that circulated before 2.6.0, i belive, and that were supposed to kick out from running any kernel module that breaks... And if module does not work and is kicked from kernel this helps me exactly how ? I still can not use the thing. If you can use driver for USB-IrDA dongle and it works just fine till you'll try to use it to connect to some device via IrDA (real-life example from W2K=>WXP transition) - how it's usefull for you ? and join to that the possibility of load the tiny 'split' extension portion, in RING 0 or RING 1 of the processor, far way from userland where Windows drivers get massacreded by all sort of "your computer is mine" software and other malware. Windows drivers were in userspace long-long ago. With NT they always were protected from userspace. It does not help with subtle API changes at all. I see how "good" it works for Windows and Solaris. Not very good at all: drivers from third-party providers are often break after major upgrade despite "commitment to binary compatibility". Sometimes installation of some Service Pack is enough.
Why a split model makes sense Posted Sep 25, 2004 11:07 UTC (Sat) by nix (subscriber, #2304) [Link] You think that's bad? Within the last year, I've bought NICs with a penguin on the sticker... and a driver for Linux 2.0.28!
(Naturally, 2.4.x supported it natively. 2.2 didn't, so what they thought they were playing at with a driver that antique I don't know; it clearly wasn't support for pre-native-support kernels that they were thinking of.)
A Sun engineer on Linux Posted Sep 23, 2004 22:19 UTC (Thu) by Duncan (guest, #6647) [Link] > IMO what Open Source needs [is standards,> not just Linux,] but a Open Source Driver > Model from OpenDarwin to BSDs to Linux > and possibily OpenSolaris,... Neat idea. To bad it can't work, for both technical and political reasons. Technical, because Linux tends toward a monolithic kernel model where even if there are modules, once they are loaded into the kernel, they become /part/ of the kernel (thus one of the objections to proprietaryware modules and why the kernel hackers insist that the kernel is tainted when a closed source module is loaded, that could do virtually /anything/), while the BSDs AFAIK tend toward a far more "microkernel" design where the drivers are /not/ part of the "microkernel" but operate at a lower privilage level either as "userland" code or just above it, but below the level of the "microkernel" code. (Vastly simplifying reality, a very general statement of the relative benefits of each model would be that microkernels are less complex and easier to stabilize, since the amount of code operating with maximum privs is relatively small, while monolithic kernels tend to be higher performing, and are either less stable or take far more effort to make stable. In reality, however, neither model tends to be used in pure form in modern operating systems, thus my use of the qualifier "tend toward" in the above description.) Political, for the same reason Linux and the GPL haven't merged with the BSDs already, at the macro/legal level, and there are multiple distributions and multiple BSD variants at the micro/interpersonal level. At the macro level, there's a split between the philosophies of those that believe code isn't truly free unless it is free to be used even in proprietaryware, and those who simply aren't even interested in contributing if others can take the contributed code and close it up, without returning improvements to the community from which the code originated, while at the same time publicly distributing the binaries (as Apple has done with the many proprietary improvements it made to the BSD base it used for OSX). Keep in mind that many developers are contributing in their free time, while others work for companies and can contribute code /only/ under the condition that it can't be made proprietary and potentially used by a company competitor. For the former, it may simply not be worth the bother if others can take the code without paying /something/ for it (in either cash for use or code improvements in return), while for the latter, they wouldn't even have the /choice/ of contributing if it could be made proprietary. This contrasts, as I said, with those who wish that their code be as widely used as possible, even becoming a standard, even where that means use in proprietaryware (as MS used BSD code to implement its original TCP/IP stack, as well as the previous Apple/OSX example). These camps will never be fully reconciled, but fortunately, that's fine, because there's room for both in open source. Likewise, at the micro level, interpersonal politics is part of the reason we have four BSD variants (Open, Net, Free, Dragonfly) and all the Linux distributions. Were there not serious personal disagreements, quite apart from philosophical ones, we'd have fewer splits there, as well. However, again, open source has proven that it's a "big tent", big enough to let folks that can't get along with each other work in different portions of the community, while remaining /in/ the community. Duncan
A Sun engineer on Linux Posted Sep 24, 2004 1:10 UTC (Fri) by mmarq (guest, #2332) [Link] " Neat idea. To bad it can't work, for both technical and politicalreasons. "
No??... but it has already worked when a young computer engineer decided to make something cool over the net with 'friends'...
Who would had thought, in the middle 90's, that the Linux kernel ends up in the position that it is now ?... the key to the impossible seems to be persistence and looking out from the side way problems... if they had worried about political, social, and many of the technical hurdles from the very begining we wouldn't be discussing this now.
There aren't any political problems really, only those of more egoistic views against less egoistic or altruistic views...
Again, if blessed by the simplicity of an unworied begining, if the many 'anonymous' friends over the Net dindn't work out their differencys, we wouldn't have Linux.
Linux dont have to merge to the point of losing personality to achieve consensus, neither does the BSDs or OpenDarwin or OpenSolaris. Consensus is exactly the contrary of self destruction or of letting others destroy you. And consensus is the bases of powerfull standards. Microsoft only is what it is today because, an almost family company, had the vision to profit from the Unix wars, and impose a standard, that no *SINGLE* one was able to defeat, and so impose a dominium to the much larger confliting Unix parties.
The technical hurdles derive directly from above. There isn't the problem of different approaches with the processor ring privileges... that is a false question because almost exactly the same code can be made to work in kernelmode (ring 0), or ring 1 or in userland (ring 3). There was a web server inside Linux kernel once... Different approaches always existed and always will exist, the contrary seems what Microsoft is trying to marketing brainwash people with. Technical frontiers can be layed out in consensus, and defended by all in consensus, and that include a Driver Model that everybody in Open Source, including Microsoft if they will to Open more, can profit from... that is not to much far fetched... it only fail for sure if the Open Source community dosent try... and after all the main propose of a kernel is to make all the hardware to function !!
A Sun engineer on Linux Posted Sep 24, 2004 8:22 UTC (Fri) by khim (subscriber, #9252) [Link] As I've said already technical problems do exist but is solveable. Political problem is other story: when Linus first hacked kernel he did it to make "GNU on PC" possible. Here and now it was the only thing he cared about. Everything else come afterwards. What exactly will split driver model bring to the table ? Here and now, not in some distant future ? A lot of headache for kernel maintainers and ability to do... what exactly ? When you are trying to solve technical problem you need technical solution. When you are trying to solve political problem you can not use technical solution. And since "split driver model" is big PITA for kernel developers without any immediate benefits it becomes mostly political problem: if you'll convince someone to do so you'll do it for political merits, not for technical ones. And it's very hard sell in free software world... If you'll recal there is driver for all disk drivers: it's called BIOS. It's exactly "split model" you proposed. Yet there are no contemporary OSes based on BIOS acess to disks. Why is it ? Think before answer.
A Sun engineer on Linux Posted Sep 24, 2004 21:55 UTC (Fri) by mmarq (guest, #2332) [Link] " As I've said already technical problems do exist but is solveable "
Then the rest of your argumentation is almost all political in nature. Sure there isn't an easy and perfect solution that does not give a lot of work and trouble... but that was always the tryumph of Open Source... it didn't made stops because of the hurdles that scared so much 'close' developed projects.
" If you'll recal there is driver for all disk drivers: it's called BIOS. It's exactly "split model" you proposed. Yet there are no contemporary OSes based on BIOS acess to disks. Why is it ? Think before answer. "
Geez... sorry about my mistake!... but are disk drives that important ?... IMO they are quite irrelevant, as irrelevant are other subsystems that have plenty of good enough support... the problem are subsystems that dont have good support and as i said before * you simple dont have do change everything to make it 'split' complaint* ... IMO is a SMALL PITA, that dont invalitate the pressure for the hardware industry to open more in the technical documentation department, which inspite of how much we'd love(including me) that could be much better, it simply dont depend on the community, and solely depend on the *proprietary* powers that some part of this community seems to fight so furiously... it is simple an arround never ending race!!... and that is what is undoubtly a *ENOURMOUS PITA*.
A Sun engineer on Linux Posted Sep 24, 2004 22:35 UTC (Fri) by khim (subscriber, #9252) [Link] Geez... sorry about my mistake!... but are disk drives that important ?... IMO they are quite irrelevant, as irrelevant are other subsystems that have plenty of good enough support... Since a lot of high-end controllers DO NOT have good support they are relevant. the problem are subsystems that dont have good support and as i said before * you simple dont have do change everything to make it 'split' complaint* ... That's exactly problem with "split drivers": you must literally redesign everything to make idea feasible. Otherwise you'll have the same problem as BIOS have with hard discs: yes, it works, but it's so slow it's totally unusable. If some piece of hardware is so slow that speed is not an issue you can just move everything to userspace and avoid drivers in kernel altogethers. Printer support is implemented this way and it works great.
A Sun engineer on Linux Posted Sep 25, 2004 1:04 UTC (Sat) by mmarq (guest, #2332) [Link] " That's exactly problem with "split drivers": you must literally redesign everything to make idea feasible...... If some piece of hardware is so slow that speed is not an issue you can just move everything to userspace and avoid drivers in kernel altogethers "
Sound a little contraditory... you would need some interface to the kernel anyway, and userland to kernel is somehow 'split' anyway... pardon my hardness of speech... and some ignorance in the details that i might show...
But the big question is *Everything ?*... well is just a big ??... what particular *existing* implementation or patch are we discussing about ???...
I2O ?,... from what i read and understood it seems really a dramatic change to go beyond what is already in kernel: (links in URL)
But is that all there is ?
An idea was laying arround from reading:
The problem solved by the systemwide or communication-with-the-OS case is explained well by the following text from the Linux Hotplug project:
A gap in current Linux support is that policies with any sort of dynamic "interact with user" component aren't currently supported. For example, that's often needed the first time a network adapter or printer is connected, and to determine appropriate places to mount disk drives. It would seem that such actions could be supported for any case where a responsible human can be identified: single user workstations, or any system which is remotely administered.
This is a classic "remote sysadmin" problem, where in this case hotplugging needs to deliver an event from one security domain (operating system kernel, in this case) to another (desktop for logged-in user, or remote sysadmin). Any effective response must go the other way: the remote domain taking some action that lets the kernel expose the desired device capabilities. (The action can often be taken asynchronously, for example letting new hardware be idle until a meeting finishes.) At this writing, Linux doesn't have widely adopted solutions to such problems. However, the new D-Bus work may begin to solve that problem.
And:
* Binary protocol designed to be used asynchronously (similar in spirit to the X Window System protocol).
* Stateful, reliable connections held open over time.
* The message bus is a daemon, not a "swarm" or distributed architecture.
* Semantics are similar to the existing DCOP system, allowing KDE to adopt it more easily.
Better, even if i degress above, never the less it seems the answer to the prayers of technical problems( not political) raised here:
And since it is a messaging system that dosent have to bend any ABI complaiance, then it dosent have to be in conflit with what is said here:
And since it is *so* low footprint, to the point of herding somewhere of putting 'libdbus' in kernel space anyway, how much more intrusive it could be from an average structural change in kernel anyway ??, if that "small" structural change has the propose of only load *tiny* module extension to the Linux drivers already present in kernel, in a similar way to the *single* NVIDEA driver that loads *tiny extensions* relative to the particular Graphic Board present.
Ok, OK,... it means to change all the actual hardware device drivers that this thing touch... but according to a real expert;... here again :
Well why not keep that way where the support is good, and change to new structures where the support is bad ?... the loss and the work of that change dosent seem much.
Rest my case.
A Sun engineer on Linux Posted Sep 26, 2004 9:13 UTC (Sun) by khim (subscriber, #9252) [Link] ound a little contraditory... you would need some interface to the kernel anyway, and userland to kernel is somehow 'split' anyway... pardon my hardness of speech... and some ignorance in the details that i might show... Huh. It's simple: in cases where you can safely make split-driver (i.e. where driver can be pushed far away from kernel to form a stable API) you can almost as easily pull it in userspace completely and avoid all this talks. When driver can not be easily pulled in userspace you more often then not can not create "split drivers with stable API" as well. Where's contradiction ? And since it is *so* low footprint, to the point of herding somewhere of putting 'libdbus' in kernel space anyway, how much more intrusive it could be from an average structural change in kernel anyway ?? DBUS only proposes to add stable interface to userspace for some non-time-critical operations. It does not change anything about kernel iteraction with already loaded drivers. if that "small" structural change has the propose of only load *tiny* module extension to the Linux drivers already present in kernel, in a similar way to the *single* NVIDEA driver that loads *tiny extensions* relative to the particular Graphic Board present. Have you looked at NVIDIA driver ? This is good example why your proposal does not work without huge changes in kernel internals. It's huge beast and it does not play well across quite wast number of kernel changes - you need to wait for nvidia to fix binary part of driver. The only reason why it's usable at all is nvidia's constant efforts to make it compatible with new kernels. You can not expect this from average manufacturer. Plus I've never seen new nvidia subriver for new piece of hardware compatible with old piece of main driver - so I can not see what are you talking about. Well why not keep that way where the support is good, and change to new structures where the support is bad ?... ...and have bad support for these type of hardware forever ? Thnx, but no thnx. the loss and the work of that change dosent seem much... The work is enormous: you'll be forced then to keep this frozen subsystem in working state - just like you keep kernel interface to userland frozen, akin to what nvidia does for "glue level" of nvidia driver. It's huge PITA to keep userland interface frozen (it's frequent topic of debate on lkml "how can we change this or that and still keep userspace from noticing anything?") - and you want new one, equal in difficulty just for few crappy drivers ? Thnx, but no thnx.
A Sun engineer on Linux Posted Sep 26, 2004 18:03 UTC (Sun) by mmarq (guest, #2332) [Link] " Huh. It's simple: in cases where you can safely make split-driver (i.e. where driver can be pushed far away from kernel to form a stable API) you can almost as easily pull it in userspace completely and avoid all this talks "
You are reminding me that the Linux USB infrastructure is already completly 'split' in nature, as is 1394, as is ALSA... 'splitness' is not a marketing buzzword and dont seem something that the Linux kernel and other kernels are complete strangers to... the simple idea of modularity implyes a certain kind of splitness anyway.
So 'APIs belonging to a new 'split' framework can evolve as the rest of any other API, as long it keeps speaking the protocol... like in Ethernet, where we have so many different implementations, and in a state of flux like in Linux, with different API particularitys, but that dosent stop a Linux box to talk to a Windows box or to a BSD box... and in that sense you can have all those 'split' *extension modules* in userspace instead of kernelspace as you suggest, and still make them talk through the same IPC protocol anyway. The economy that i'm suggesting with a new, "advanced split framework", is that the Linux kernel could have changed as it did, as well as the APIs of that 'split' infrastructure inside of it, but that "tiny" *module extension* could have remained the same(in cases where the NIC is the same)... if that *module extension* were good enough and stable... or could have changed also if it were not... it will not be dead ends, because they are talking through an IPC based protocol that is not ABI complaint, being those *module extensions* in kernel or userland... and all this makes perfect sense to me, and to the majority of people, i belive, because the Linux Ethernet implementation have changed along this few years, with inumerous, non functional or non debugging changes to the driver i use, but i'm still using the same NIC.(when, "IF" you'll approach the million drivers inside, with the ever increasing in complexity nature of hardware, linux then would be unmaintainable:-Thnx, but no thnx.)
And since D-BUS is stated to be *very low* in overhead, it seems a good candidate. And since that 'split framework' subsystem is independent of any other subsystem, you would only have to make changes, for the 'new split framework' model, to those subsystems that youd like, arbitrarily... it dosent have to be the network subsystem. I belive this is perfectly doable and sensible.
"DBUS only proposes to add stable interface to userspace for some non-time-critical operations. It does not change anything about kernel iteraction with already loaded drivers."
That is why i talked about an extension(vaporware yet!?)... and an extension with the purpose of only thouch subsystems, in a first fase perhaps, where the support is bad, or where the subsystems have already a clear splitness, what makes them perfect candidates, like the mentined USB,1394,ALSA... and that is achievable because that *D-BUS extended framework* infrastructure is independent of any other subsystems that you might put into the kernel, and is a stateful and asynchronous protocol. It could be laying there in kernel doing nothing, just for the fun, if you wich. We already have there a moribund I2O subsystem that nobody or very very few people seem to use, anyway.
"Have you looked at NVIDIA driver ? "
Unfortunatly the nvidea driver i use, is a user space module, that is loaded by a new NVIDEA interface added to the kernel, different from the interface already there and different from any other interfaces from other Graphics Boards suppliers, namely ATI, which in his turn is also different from the interface already in kernel...!!?
"...and have bad support for these type of hardware forever ?"
??!!... should i comment political, or what...??... the 'advanced split framework' can suit 'Open' perhaps better than 'Proprietary', because it could make it much more easy to compile from source, without modversions and without some makefile magics sometimes needed, when only 1 module is needed to be changed.
"you'll be forced then to keep this frozen subsystem in working state - just like you keep kernel interface to userland frozen, akin to what nvidia does for "glue level" of nvidia driver"
Well what i suggested is a IPC based protocol, i almost 100% certain that it dosent imply, not even near, that kind of frozeness that you mention.
A Sun engineer on Linux Posted Sep 26, 2004 19:55 UTC (Sun) by mmarq (guest, #2332) [Link] On better look...
" Plus I've never seen new nvidia subriver for new piece of hardware compatible with old piece of main driver - so I can not see what are you talking about. "
Geez!... that wouldn't be asking for too much ??... but the answer might be yes anyway, if that new piece is from a family already present, and dosent need diferrent support of what is already present in the main driver... or...
... does that mean you know better... because you had the chance to look at the code of their unified driver!??... or what??(nvidea buddys ?)...
... but better than Linux kernel is exactly that they *appear* to be able to had support for a new chipset family, only with "some" changes to the main driver, and whitout having to change even a single line of code to the *majority* of the drivers modules(if we can call them that) *already present*.
A Sun engineer on Linux Posted Sep 25, 2004 18:39 UTC (Sat) by vonbrand (subscriber, #4458) [Link] IMO what Open Source needs in that department, is again standards, not Linux standards but a Open Source Driver Model from OpenDarwin to BSDs to Linux and possibily OpenSolaris,... let the *better* kernel win !... Nice sentiment, but that won't fly. Just look at the massive changes in the driver model in Linux from 2.0, 2.2, 2.4, to 2.6. They weren't gratuitous, there are sound reasons behind the changes. And surely while there is a healthy dose of "Oops, screwed that one up; let's try and make it right this time around" (BTW, the people designing this changing interface did look at the "unchanging interfaces" used elsewhere), at least some of it has been predicated by external changes (hotplugging all over the place just wasn't even a pipe dream when Solaris started some 10 years back, much faster CPUs, hyperthreading, large memories, NUMA, you name it, have changed the demands on the driver model dramatically). In the end, it is the driver model that makes up a large part of the OS. By mandating an unchanging driver interface, Sun is painting themselves into a corner, IMHO. Sure, they can continue dressing up their particular corner with their own high-end iron, but even with very large margins there the PC price/performance will eat them alive over short or long. It killed off DEC and a lot of other midi-frame vendors, and even mainframe vendors like IBM are looking elsewhere.
A Sun engineer on Linux Posted Sep 26, 2004 0:57 UTC (Sun) by mmarq (guest, #2332) [Link] Yes, you might be right in the sense that the horizont of that sentiment may lay far away in a distance galaxy...
Perhaps a better aproach, could be, i belive:- Gentleman, if your BSDs, OpenDarwin, OpenSolaris(??) want to profit from the far superior hardware support that Linux has(A FEW YEARS FROM NOW), you could work to help OSDL to create separated trees of your kernels that implement for your kernels the technical superior features relative to device driver support( open to discussion), and that way create an Open Source Device Driver Model, that all kernel and Unix flavours could profit in the sense that a "low level" kernel module could be used *UNCHANGED* across kernels.
That is, all kernels "will" implement a form of :
The latency of such a 'Declaration' could be enourmous, yes,... worst it could inflate the personality not of some kernels, but of some kernel developers beyond the explosion point,... but persistence would win,... there were already mingling code between Linux and BSDs far before,.. better 'they' are using ALSA(FreBSD i belive), as well as KDE and GNOME.
All of a sudden, we are actualy talking of code and documented mechanisms that exist already in large proportion...
The pipe dream then dosent seem of a far galaxy anymore...
A Sun engineer on Linux Posted Sep 26, 2004 1:33 UTC (Sun) by mmarq (guest, #2332) [Link] hmmm... may be i'm wrong,... but an IPC mechanism for drivers (D-BUS based or some other form talked above) could be the help to implement proper HOT-Pluggin across the board,... as well as suspend to disk,... as well as proper power saving modes to all categorys of hardware that compose a computer...
Although i not the right person to discuss such details, and i'm not trying to sell nothing to nobody.
By the way,... IMO was closed platforms not exactly hardware/software, but *MOSTLY HARWARE* for in house comsuption only, that not only killed DELL, but almost killed Apple, until they changed to PCI and ATA/SATA, and also kicked the well of P4 sells when Intel insisted on RAMBUS,... and is definitely pushing SUN into the edge... So having *no form at all what so ever or not* of a standard for hardware device drivers had nothing to do with those mysfortunes... Just look at Microsoft with their WinHEC specifications,... hein!??
A Sun engineer on Linux Posted Sep 24, 2004 8:48 UTC (Fri) by arasila (guest, #20891) [Link]
Since the fiaSCO incident I haven't much liked Sun; but anyway I don't see any "FUD" in this article. It's very much true that certain design choises of Linus are annoying big hardware vendors. And that you can't link non-GPL code to Linux kernel -- that's very bad for the companies developing hardware drivers with lots of licensed IP, patented technology, etc. I'm not saying that Sun's approach is right or even a good one -- just that the technical points made in the article make sense and are logically sound. In particular, from a cynical point of view, it makes sense for Sun to adopt a GPL-incomptatible license to prevent the "edge" of Sun's technology from slipping into Linux. A completely different issue is, will the strategy succeed. Linux has many years lead as an Open Source project -- building a community is slow. Also, Sun has much talent in annoying people and creating distrust -- as demonstrated by the reaction to this article. But Helix/RealPlayer project was also trashed by LWN readers and it has yet been somewhat successful.
|
|
||||||||||||