| |||||||||||||
A Sun engineer on Linux
Sun engineer Eric Schrock has put up a weblog
entry which gives a view into how Sun sees the Linux development
process. "The main reason we can't just jump into Linux is because
Linux doesn't align with our engineering principles, and no amount of
patches will ever change that. In the Solaris kernel group, we have strong
beliefs in reliability, observability, serviceability, resource management,
and binary compatibility. Linus has shown time and time again that these
just aren't part of his core principles, and in the end he is in sole
control of Linux's future."
(Log in to post comments)
A Sun engineer on Linux Posted Sep 23, 2004 15:36 UTC (Thu) by einstein (subscriber, #2052) [Link] 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.
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 (subscriber, #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 (guest, #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 (subscriber, #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 (guest, #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 (subscriber, #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 (subscriber, #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 (guest, #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 (subscriber, #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 (guest, #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 (subscriber, #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.
A Sun engineer on Linux Posted Sep 23, 2004 15:44 UTC (Thu) by clugstj (subscriber, #4020) [Link] 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.
A Sun engineer on Linux Posted Sep 23, 2004 15:52 UTC (Thu) by gowen (guest, #23914) [Link] In the Solaris kernel group, we have strong beliefs in reliability, observability, serviceability, resource management, and binary compatibility.... There is a very small bit of Solaris that is platform specific, and is scattered throughout the codebase such that it would be impossible to separate.Does that not seem somewhat inconsistent? If your core beliefs include "reliability" and "serviceability", wouldn't it make sense to ensure sure the platform specific code was already and essentially separated from the rest, as opposed to being "scattered throughout the codebase [and] impossible to separate"?
Platforms integration Posted Sep 23, 2004 15:57 UTC (Thu) by southey (subscriber, #9466) [Link] Of course "Linux doesn't align with our engineering principles" when hesays things like: "Both x86 and SPARC are built from the same source! There is a very small bit of Solaris that is platform specific, and is scattered throughout the codebase such that it would be impossible to separate." It is clear that Sun must put considerable more effort in maintaining the two Solaris sub-codebases than Linux requires.
A Sun engineer on Linux Posted Sep 23, 2004 15:58 UTC (Thu) by ami.ganguli (guest, #9613) [Link] I'm actually curious about what they come up with and I wish them luck. I see no reason to believe that OpenSolaris will flop, but I doubt it will be as popular as Linux.
For whatever reason, Linux has emerged as the dominent Unix-like OS, despite perfectly good competitors in the form of the BSDs. The BSDs meet all of the requirements that Sun has: they allow proprietary extensions, they follow a more controlled engineering process. Despite this, Linux has captured the mainstream imagination.
The question that Sun needs to answer is: do the advantages of sticking with (what is becoming) a niche OS outweigh the costs. It costs them in R&D budget, it costs them in hardware support, it costs them in application support.
If Sun looks at the figures and concludes that, yes, they should stick with Solaris, then good for them. Any developers they fund to work on Open Source will, in the end, help the community.
A Sun engineer on Linux Posted Sep 23, 2004 16:50 UTC (Thu) by philips (guest, #937) [Link] Main advantage of Linux is its price.
Ask anyone in business what keeps Sun floating around that long?
Well, it is used mostly on crappy Sun's hardware. Will see how good Sun will manage to make x86
With Sun/Solaris combination - you are assured that hardware will work ok with that OS. (Just
On flip, side - Solaris might be as crappy as Linux can be sometimes - we just cannot run it on
P.S. Hm... Probably it is not Sun's hardware which is crappy - but Solaris which makes it crappy.
P.P.S. Including into equation support by hardware vendors of Linux, Linux just shines, compared
A Sun engineer on Linux Posted Sep 23, 2004 17:10 UTC (Thu) by bronson (subscriber, #4806) [Link] I don't understand your post... "Everybody loves it [Solaris]." vs. "Solaris makes [good hardware] crappy."
It's true that hardware selection takes more effort when buying a Linux box than a Sun box, especially for server grade hardware. So, buy your box from a reputable Linux vendor and get a service contract. Don't just throw Linux onto random hardware you have lying around and then expect it to be a well-tested, 100% reliable solution. (I'm not saying you did this -- I don't know -- but a lot of people do).
I last worked on Solaris in 2000. I remember banging my head into a bunch of SysV vs. BSDisms, and that the desktop environments (either OL or CDE) were truly poor. There also wasn't much of a support community for small problems.
So, though it got the job done, I sure didn't love Solaris.
A Sun engineer on Linux Posted Sep 23, 2004 23:49 UTC (Thu) by cajal (subscriber, #4167) [Link] Well, a lot has changed on Solaris since 2000.
Most of the shell utilities now accept the "-h" argument. There's Blastwave for automated
I tried Solaris (briefly) back in the 2.7 and 2.8 days, and then went with Linux. But I'm seriously
A Sun engineer on Linux Posted Sep 23, 2004 17:30 UTC (Thu) by jeskritt (guest, #4092) [Link] I'm currently a Solaris admin. Personally I prefer linux to Solaris. Not that Solaris is bad, but their command line tools don't have all the same features as linux (e.g. -h for human readable file sizes was only added in Solaris 9), though they are slowly adding functionality to them. The main complaints I have about Solarisis that I don't really like their packaging system and I really hate their patch system. It is horrible.
A Sun engineer on Linux Posted Sep 23, 2004 23:31 UTC (Thu) by hppnq (guest, #14462) [Link] Heh, I just spent 6 hours installing patches (not counting downloading the +100MB) in order to install an LDAP client -- on a fairly well maintained Solaris system.There is no way to script this, and I have 800 (eight hundred) systems to go.
A Sun engineer on Linux Posted Sep 23, 2004 21:12 UTC (Thu) by simlo (subscriber, #10866) [Link] I have tried to install a plain postscript network printer on Solaris. Scream! I gave up. On Linux: I started the printtool, give the IP number and it printed right away.Yes, this is the argument Windows users use against Linux, but you would expect these kind of things to work better in a expensive, commercial product than in something you just download for free, right?
A Sun engineer on Linux Posted Sep 24, 2004 0:10 UTC (Fri) by xtifr (subscriber, #143) [Link] I've been in the business for over two decades, and I strongly disagree. I agree that it's not the hardware, but it's not Solaris either. The thing that has kept Sun "floating around" for so long is the same thing that keeps MS where they are: the apps. And when you're discussing server apps, there's one that stands out like a 600 pound gorilla in a room full of tree shrews: ORACLE!
When Solaris was Oracle's primary recommended platform, Sun was flying high. They could literally do no wrong. Then, a few years ago, Oracle announces that now Linux is their primary recommended platform. And suddenly Sun is floundering, lost and aimless, and desperate to find a way back into the limelight. Anyone who thinks this is a coincidence is invited to invest in some interesting real estate deals I have going down Florida way.
The idea that it's all about the OS is something that only a geek could possibly believe. Nobody in the real world gives two hoots about the OS. Of course, the Sun fanatics want to believe that it's about the OS, because they don't want to admit that Sun was NEVER in control of their own destiny, and the Free/OSS geeks go along because they want to believe that it *should* be about the OS (they want to promote Linux or BSD on their own merits), and because they (at least some misguided subset of them) want to believe that nobody should care about Oracle, since you can just use MySQL for all your database needs (yeah, right).
A Sun engineer on Linux Posted Sep 24, 2004 1:17 UTC (Fri) by hppnq (guest, #14462) [Link] I agree with a big part of what you say. I do think, however, that Linux enthusiasts have one big, shining reason to be very vocal about the merits of Linux, other than the technical ones. It is the GPL. Companies, governments and universities all over the world are switching to Linux because of the freedom it provides, that leads not only to an excellent operating system, but also to a system that gives the user every possibility to make it even better.
A Sun engineer on Linux Posted Sep 24, 2004 3:30 UTC (Fri) by hppnq (guest, #14462) [Link] s/possibility/opportunity/ ;-)
A Sun engineer on Linux Posted Sep 23, 2004 17:21 UTC (Thu) by rcbixler (guest, #11917) [Link] > The question that Sun needs to answer is: do the advantages of sticking> with (what is becoming) a niche OS outweigh the costs. It costs them in > R&D budget, it costs them in hardware support, it costs them in > application support. I would be quite surprised if the figures really did add up, especially since Sun's real bread-and-butter is their hardware. It strikes me that Sun simply suffers from "Not Invented Here" syndrome.
A Sun engineer on Linux Posted Sep 23, 2004 18:56 UTC (Thu) by pflugstad (subscriber, #224) [Link] For whatever reason, Linux has emerged as the dominent Unix-like OS, despite perfectly good competitors in the form of the BSDs. The BSDs meet all of the requirements that Sun has: they allow proprietary extensions, they follow a more controlled engineering process. The problem with the BSDs is precisely that: they allow proprietary extensions. If a company contributes something to one of the BSDs a competitor could grab it and instantly be on a level playing field with the original developer. And then they can make changes and not be required to feed them back to the BSD base. That can't happen with Linux. GPL requries the changes get fed back. So companies such as IBM feel safe investing in GPL'd stuff because it can't be easily used by their competitors to get a leg up.
A Sun engineer on Linux Posted Sep 23, 2004 16:34 UTC (Thu) by huffd (guest, #10382) [Link] Won't this just become one more conflict that Sun needs to deal with? They've stated they will be buying a distro. What kind of a game are they playing, nobody dilutes their product line like this?
Let's take these one by one Posted Sep 23, 2004 16:43 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]
Let's take these one by one Posted Sep 23, 2004 22:32 UTC (Thu) by dmarti (subscriber, #11625) [Link] Ain't binary-only drivers just swell?
Rebuttal by a Linux kernel developer Posted Sep 23, 2004 17:03 UTC (Thu) by gregkh (subscriber, #8) [Link] I wrote a rebuttal of his points about the Linux kernel here.
Question (re: a.out compatibility) Posted Sep 23, 2004 18:33 UTC (Thu) by allesfresser (subscriber, #216) [Link] Thanks Greg! Great summary. But one little question (not a disagreement necessarily): is the old a.out (pre-ELF) code going away? I seem to recall someone saying that it would be removed in 2.6 sometime... this would break compatibility with stuff before the ELF switchover. (I know there are very few instances of these being necessary at this point, of course, and I run my kernels with the a.out code disabled, but just checking...)
Question (re: a.out compatibility) Posted Sep 23, 2004 19:24 UTC (Thu) by gregkh (subscriber, #8) [Link] Nope, CONFIG_BINFMT_AOUT is still there, and I haven't heard any rumorsof it being deleted anytime in the future.
But I don't really pay attention to that part of the kernel :)
Rebuttal by a Linux kernel developer Posted Sep 23, 2004 22:10 UTC (Thu) by khim (subscriber, #9252) [Link] Applications written for Linux 1.0 work just fine on the 2.6 kernel. Now, this is just plain wrong. Any applications ? No chance in hell: there were quite a few changes in userspace visible API (even if you'll forget about things like procfs and devfs). Take a look on linux/arch/i386/kernel/entry.S : Some applications? You do not need any serious compatibility for this: empty shell script works for all known UNIX-like systems - you can even rename it to .bat and run unmodified under Windows ! Yet I do not see this like such a big problem: there are no such a thing as 100% compatibility! And most obsoleted syscalls are really... obsoleted and not used by contemporary programs. And yes, usually old interface is kept around for a long-long time. Yet... just this week all sysadmins got the warning to prepare to throw away perfectly good userspace applications. Why ? Support for that code is too hard, it's obsoleted for a few years, so it's time to stop bothering. You just can not keep old interfaces forever. It's way better to have no support for "old USB drivers" model (like Linux does) then buggy support for "old USB drivers" (like Windows does) and I'm pretty sure Sun engeeners spend a lot of time trying to support old binary interfaces - work with no real benefits in open-source world, where driver can always be adopted to new API.
Rebuttal by a Linux kernel developer Posted Sep 24, 2004 23:05 UTC (Fri) by hch (guest, #5625) [Link] check your copy of the linux 1.0 sources, and you'll see they weren't implemented there either ;-)
Rebuttal by a Linux kernel developer Posted Sep 25, 2004 11:10 UTC (Sat) by nix (subscriber, #2304) [Link] i.e., it's an `old placeholder' for something that's not planned to be implemented anymore, not a placeholder for an old syscall that is no longer implemented.
Gotta love English; ambiguities *everywhere*.
Rebuttal by a Linux kernel developer Posted Sep 26, 2004 13:39 UTC (Sun) by mbp (subscriber, #2737) [Link] ipchains and ipfwadm are not "userspace applications". They are interfaces for configuring the kernel; as the kernel changes so do the interfaces for configuring it.
An application is something like vi or netscape or (heh) WordPerfect, run by users rather than administrators. As you say, there are some kernel interfaces which change, but in general they are not the application interfaces.
Rebuttal by a Linux kernel developer Posted Sep 25, 2004 14:20 UTC (Sat) by hppnq (guest, #14462) [Link] Here is Mr Schrock's answer to your rebuttal, just for completeness' sake. It is not really worth reading, just a lot of misinterpretation. He also describes his view on the GPL, on the same page. It shows that he doesn't understand the first thing about the GPL and the Open Source community.
Round 2 by a Linux kernel developer Posted Sep 26, 2004 16:50 UTC (Sun) by gregkh (subscriber, #8) [Link] Thanks for letting me know. And here is my response.
Round 2 by a Linux kernel developer Posted Sep 26, 2004 21:47 UTC (Sun) by hppnq (guest, #14462) [Link] Thanks Greg, for a very polite and to the point response -- I thought Eric's piece was, again, deliberately inflammatory, even though he did have a couple of valid points.I'm looking forward to your article on binary compatibility. ;-)
Round 2 by a Linux kernel developer Posted Sep 27, 2004 1:38 UTC (Mon) by Tao (guest, #24985) [Link] hppnq,
Do you understand the words "deliberately inflammatory" and "troll"?
Tao
Round 2 by a Linux kernel developer Posted Sep 27, 2004 6:57 UTC (Mon) by hppnq (guest, #14462) [Link] Get off my back.
A Sun engineer on Linux Posted Sep 23, 2004 17:42 UTC (Thu) by mmarq (guest, #2332) [Link] Here must be the reason!(one at least) of so much contempt:
http://news.zdnet.com/2100-9584_22-5371721.html
Linux is not the reason for SUN trouble, it is the IT satatus quo, and the state of the art...
SUN just couldn't go on quitly selling ultra lucrative Sparc paralell machines with Solaris on, when the much much cheaper 'WINTEL' model is approaching the performance levels of 4 to 16 way Sparc with 2 to 4 way AMD or INTEL...
The problem, IMO is not much of Linux or BSD,..., but perhaps in the larger responsability of Microsoft, that has steadly along the time puched SUN, IBM, HP to the 'High End' performance computer Market, knowing that certainly with time, that 'high end' market will get smaller and smaller and smaller - "Moore's law".
People are not replacing older SUN equipment with Linux or Windows on Intel... they are replacing older SUN equipment with more performant ones that happen to have less processores footprint, and that happen to cost a lot less...
The only chance for the cornered SUN now, and soon IBM and HP(time will tell), is not to sell to the 'real' enemy as SUN did with OpenOffice, but to invade the dominiums of Microsoft, namely Desktop, with the so many superior projects that abound in the Open Source community...
The torrent of patches is only a side effect,... what the Open Source needs are strong and effective standards that could stick, and not be easy prey of commercial pushes be it of SUN, IBM, HP, RED HAT or whoever, that are always trying to change standards to there sides to gain market differentiation and possible edge... that way Microsoft has already won.
And you know what ? ,..., IMO Microsoft is so close to the edge for loosing... but if the battles among Open Source providers is to get tougher, they may yet escape... wonder if that was not laying behind the deals they made with SCO and now SUN StarOffice.
A Sun engineer on Linux Posted Sep 23, 2004 19:49 UTC (Thu) by stumbles (guest, #8796) [Link] Oh I see now how Sun is going to trash Linux.
A Sun engineer on Linux Posted Sep 23, 2004 19:50 UTC (Thu) by stumbles (guest, #8796) [Link] <I>Linux doesn't align with our engineering principles, </I>Hey, Microsoft can use the same excuse.
A Sun engineer on Linux Posted Sep 23, 2004 20:34 UTC (Thu) by copsewood (subscriber, #199) [Link] I'm glad that there are likely to be many Unix and Unix-like systems around for many years to come. Not only does this provide healthy competition, it also prevents a monoculture likely to be vulnerable to a clever network worm which exploits a previously unknown and unpatched vulnerability. We now hardly question the similar benefits that maintaining biodiversity has natural ecosystems.
I have some fondness for Solaris, having learned much of what I know about Unix on this some years ago. Without this knowledge I would not have been able to change most of my working and useful systems to Linux so easily.
To be truly human, one must respect the right of other apes to continue to enjoy a niche where they can exist, preferably outside of a zoo.
A Sun engineer on Linux Posted Sep 23, 2004 21:14 UTC (Thu) by cdmiller (subscriber, #2813) [Link] Sounds to me like the actual principle that does not match up is that of selling software licenses. SUN still does not see that this is a failing business model.
I have an uncle high up in SUN management. In about 2000 I tried to convince him that the future was in Linux. My thoughts then were if SUN would start contributing and even sponsor the Linux SPARC port a killer product would emerge for SUN to sell more SPARC hardware. Oh well. At least they have the SUN Java desktop and Open Office / Star Office going on.
- cameron
A Sun engineer on Linux Posted Sep 24, 2004 18:26 UTC (Fri) by cpeterso (guest, #305) [Link]
but if Sun dumped Solaris for Linux on SPARC, they might shoot themselves in the foot. Almost every feature or performance boost they add to Linux on SPARC would help Linux on commodity x86 hardware!
Fork Posted Sep 23, 2004 22:05 UTC (Thu) by larryr (guest, #4030) [Link] I agree with the author to the extent that I think the Solaris kernel developers should put effort into providing the changes the customers want, and should not be beholden to Linus to have their changes accepted into the Linus kernel. What I would like to see happen is IBM, Sun, and other vendors, maybe RedHat, Canonical, Novell, create a fork which has enough momentum to displace the Linus kernel as the one most often used, even by those who typically build from source. I would have much more confidence in that consortium to provide more of what I as a customer want. I do not think a Sun-only fork would be widely used, so if that is their only choice besides continuing with Solaris, I think they should continue with Solaris. Larry
Fork Posted Sep 24, 2004 0:54 UTC (Fri) by hppnq (guest, #14462) [Link] I would have much more confidence in that consortium to provide more of what I as a customer want. So what is it that you want? Don't tell me it's the lock-in. ;-)
Fork Posted Sep 24, 2004 1:15 UTC (Fri) by man_ls (subscriber, #15091) [Link] Oh great, design by committee. Now that would be sound engineering?
Fork Posted Sep 24, 2004 16:07 UTC (Fri) by larryr (guest, #4030) [Link] Oh great, design by committee. Now that would be sound engineering? To the extent the Java Community Process is design by committee, I think it can be. Larry
Bad example Posted Sep 24, 2004 19:21 UTC (Fri) by man_ls (subscriber, #15091) [Link] If you think the JCP produces good engineering, then we have hardly a common ground to start discussing (I don't). Anyway, let's look at it from another point of view: if you trust vendors (better than developers) to produce your version of Linux, then go directly to them and use some vendor-maintained kernel like RedHat's or SUSE's, which are heavily customized. Nobody forces you to use kernels from Linus. Or, why not, shell out some $$$ and use Solaris x86.
Fork Posted Sep 25, 2004 18:12 UTC (Sat) by trshash84 (guest, #20778) [Link] Um, what exactly is wrong with the kernel to the extent that you want tofork it?
A Sun engineer on Linux Posted Sep 23, 2004 23:11 UTC (Thu) by iabervon (subscriber, #722) [Link] There are really two engineering philosophies. One is that you make something you believe to be correct, and then debug it until it works; the other is that you make something that works, and then hack at it until it's correct. Linux has the second philosophy (with the addition of gatekeepers who keep things out until they're right). Sun seems to have the first philosophy. This leads to a feeling of superiority, although not necessarily better design.
Linux is not developed with strong beliefs in reliability, observability, serviceability, and resource management. It has acquired these properties as the need for them has been demonstrated. It has also avoided picking up a lot of buzzwords and ideas which were not actually needed, even though people claimed at various times that they were important. It hasn't come by its reliability out of a commitment to it, but rather by identifying classes of bugs, finding the extant examples, fixing them, and making sure they will be caught in the future.
A Sun engineer on Linux Posted Sep 24, 2004 18:01 UTC (Fri) by AJWM (guest, #15888) [Link] It hasn't come by its reliability out of a commitment to it, but rather by identifying classes of bugs, finding the extant examples, fixing them, and making sure they will be caught in the future. [Emphasis added]Or perhaps in other words, the Linux development method is just as much about fixing the process as fixing the bugs, which is the right way to ensure that quality of the product continually improves.
A Sun engineer on Linux Posted Sep 24, 2004 0:10 UTC (Fri) by pspinler (subscriber, #2922) [Link] Whatever else he may say, I feel a signifcant part of Sun's problem, perhaps the majority, is espoused by this simple quote from his article:The real problem ... is simply that the GPL doesn't align with our corporate principles.Well, it's their own grave. Too bad, though. Sun does produce a reasonably good OS. It's a pity to not apply that hard won expertese. -- Pat
A Sun engineer on Linux Posted Sep 24, 2004 0:33 UTC (Fri) by hppnq (guest, #14462) [Link] I think it's more likely for this piece to end up on a shrink's coffeetable than it becoming the landmark article of Sun's involvement in Open Source.Apart from that, it displays an uncommon lack of understanding sound engineering principles. That is, if you believe that improvement of your codebase does not involve clutching around your horrible past mistakes. Even from a commercial point of view Eric does not get it. Oracle is not interested in backward compatibility of its products, it will happily recompile its software and make customers upgrade. (Where he gets the idea that Linus does not care about binary compatibility, I don't know, by the way. Also, the fact that there are other operating systems that offer binary compatibility with Linux should say something.) Eric seems to have an obsession for integrating Solaris features into Linux. In fact, he reasons that a fork of the Linux kernel would probably not work, partly because integrating things like DTrace would be problematic. This train of thought is derailing all over the place. It is a bit worrying that a Solaris kernel engineer seems disappointed at not being able to incorporate Dtrace in the Linux kernel. First, because it implies that he thought it would be relatively easy; second, because their competitor IBM does seem to be able to contribute big chunks of kernel code to Linux easily. So, Eric, what is more problematic: the capabilities of Sun's kernel engineers, or the quality of the code? (Apart from that, it would be really nice if we could actually do something with the results of your superior kernel debugger, instead of just banging our heads against the wall 'cause we can't touch your proprietary kernel, nor do anything to the system that the next patch might find disruptive, bringing the system to a screeching halt.) But of course it is the complete and utter misunderstanding of a project fork and its intimate relation to the GPL that is even more alarming. No, Eric, a fork does not mean: I take your software and incorporate my brilliant features in it. Back to Open Source 101 for you. Really, the disdain -- even if not intended, the product of a troubled mind (fearing for your job, maybe?) -- is inappropriate. Come back when your thoughts on the subject have matured.
A Sun engineer on Linux Posted Sep 24, 2004 12:19 UTC (Fri) by dan_b (subscriber, #22105) [Link] Where he gets the idea that Linus does not care about binary compatibility, I don't knowCome now. It's really quite obvious that he's talking about the kernel there, not userspace, and we all know that binary compatibility for third-party kernel modules is a non-goal for Linux.
A Sun engineer on Linux Posted Sep 25, 2004 6:59 UTC (Sat) by hppnq (guest, #14462) [Link] Read it again, carefully. From the article:
In the Solaris kernel group, we have strong beliefs in reliability, observability, serviceability, resource management, and binary compatibility. Linus has shown time and time again that these just aren't part of his core principles, and in the end he is in sole control of Linux's future. And then he goes on describing how non-free drivers (outside of the tree) have such a hard time. The first "binary compatibility" reference is clearly userspace though. You might call this FUD. ;-)
A Sun engineer on Linux Posted Sep 25, 2004 21:57 UTC (Sat) by hppnq (guest, #14462) [Link] Mmhh, I missed this, even better:
Not to mention the complete lack of commitment to binary compatibility (outside of the system call interface). Kernel developers make it nearly impossible to maintain a driver outside the Linux source tree (nVidia being the rare exception), whereas the same apps (and drivers) that you wrote for Solaris 2.5.1 will continue to run on Solaris 10. (Sorry for replying to myself. Enough said. ;-)
A Sun engineer on Linux, trying to keep his job Posted Sep 24, 2004 1:46 UTC (Fri) by neoprene (guest, #8520) [Link] "In the end, dumping Solaris into Linux makes no sense, either technically or philosophically."
...and not at least, why would Linux need it? It would be up to Linus et al, and not SUN to decide. SUN pays money to SCO and adding SUN "IP" into Linux is just not Linux. Maybe thats how Sun gets code into their product but that's not how Linux/GPL works. As I see it Sun can take their code and cram it.
Sun sits on an ice-flake in a warm ocean, and their feet are getting wet.
Yes, there will be sunnies around a long time keeping legacy software running on ole boxes.
A Sun engineer on Linux Posted Sep 24, 2004 14:16 UTC (Fri) by petegn (guest, #847) [Link] at the end of the day what does it matter .
Just keep an eye on Suns prices they will suffer for even thinking of trying to do an M$ Corp on Linux they will be the next to join SCO in the can the trash can ..
Now thereare probably a few Sun people reading this we boo hoo start looking for another job is about the best advice you can take right now He He He He ! ..
Boom Boom Boom another one bites the dust Boom Boom Boom another one bites the dust Boom Boom Boom another one bites the dust
Pete.
A Sun engineer on Linux Posted Sep 24, 2004 15:13 UTC (Fri) by sdalley (subscriber, #18550) [Link] From the posting advice:> Please try to be polite, respectful, and informative ...
This is, after all, lwn, not slashdot.
Is the battle already won? Posted Sep 24, 2004 17:46 UTC (Fri) by Nelson (subscriber, #21712) [Link] He sites the rejection of several debugging tools by Linus, but Linus always does it with reason. He's not outright against any of that stuff, he expects it to work on all the platforms that are mainlined in to Linux. He expects it to be generic. His dedication to support outweighs the dedication to debugging tools.
We've seen this discussion numerous times, Hans Reiser seems to always bump into it, features aren't the most important thing, not in Linus' mind. If you observe it from 30,000 feet then it looks a lot like Linus is flatly rejecting patches for some unknown reason and thusly rejecting a new feature but it's almost never that way. Implement your feature in the current architecture or own the architecture and design a better one and get it past Alan Cox, Ingo Molnar, Al Viro, Linus and company. Don't just hack stuff in and expect it to get in there.
If the Sun guys really believe that Linus doesn't hold on to those engineering principals then I think it's just a formality of beating them because they clearly do not understand their competition. Give it time, there won't be anything Solaris can do that Linux can't and probably do better.
Is the battle already won? Posted Sep 24, 2004 18:41 UTC (Fri) by piman (subscriber, #8957) [Link] Actually, in the past, Linus has spoken outright against the very idea of a kernel debugger. So, he's correct in that respect. (There is one, but it's not distributed with the kernel. And if you actually read that guy's blog, he goes through and explains various issues with it and compares it to Solaris's kernel debugger.)
Not technical, just marketing Posted Sep 26, 2004 23:20 UTC (Sun) by bojan (subscriber, #14302) [Link] Although this weblog entry is technical, its aim is completely that of marketing. We must not forget that. Sun is threatened by Linux because people no longer have to buy a Sun box (or any other proprietary RISC box for that matter) to run good quality Unix-like OS. And that hurts Sun's bottom line. Therefore, they have to make it looks as if:
1. Solaris is just as open as Linux.
At least two respectable companies (IBM and SGI) have so far realised that by sharing development (through Linux) they can save money. Sun still believes that it is better if they have their own differentiation factor (Solaris) when it comes to selling boxes (they make no money on Solaris anyway). Time will tell if all this effort was warranted, of course.
Technical merits of this weblog entry aside (and they really aren't very important - we knew before it that development methodologies and goals of Sun and Linux community are different), this is just another attempt to revive sales of Sun machines. We have to remember that majority of people in charge of making purchasing decisions view purchasing of IT equipment the same way they view any other purchase. It is a product to be had, from a respectable vendor, with established, stock-standard support contracts available straight off the price list. Linux has gotten there with Red Hat. Sun naturally don't like that, because that means that there is no "Sun is the ultimate Unix shop advantage". Any hardware will do and support contracts are just as good (in terms of ease of getting them). And there is IBM standing behind the whole thing, thus giving the whole deal even more credibility. So, Sun is putting all their efforts into making sure this doesn't work any more. And by emphasising their newly found friendship with MS, they are positioning themselves as some kind of unique Unix company with access to Windows technologies and, of course, the leaders in Java.
On and (un)related note... Although I do not normally subscribe to conspiracy theories, it is an interesting coincidence that both Sun and Microsoft are using the same tactics to discredit Linux. And that is by attacking Red Hat. That's really funny, because I would think that Novell is plenty capable of making Linux a supported product, even if Red Hat went bust tomorrow. Not to mention anyone else that cares to take on it. Strangly shortsighted strategy by both MS and Sun... But maybe that's just because nothing else worked so far.
|
|||||||||||||