If Sun's market share is being gradually eaten from the lower end up, how do you explain their rapid growth in both earnings and stock price over the last few years ?
Much more of their income is coming from high-margin servers rather than volume workstations. That makes them a lot more profitable even as their unit sales decrease.
That's great business, but it's exactly the same kind of business that IBM was in before DEC showed up, and DEC was in before Sun showed up. Over time the cheaper machines got good enough to do the job and all at once there was a market discontinuity and the incumbant saw income collapse.
In response to your claim that powerful PCs will overtake Sun's hardware -- well many UNIX servers are less powerful than today's top of the line x86 hardware. But they still sell.
There is a resistance to movement because it's expensive to jump hardware platforms, particularly between operating systems. There has been a whole lot of resistance towards jumping on PCs because the dominant OS has been NT for the last few years. NT hasn't been particularly mature and the jump is especially costly because there is little in common between the two systems.
This is one area where Linux stands to make a really big impact. Lots of Sun customers who wouldn't use NT would use Linux. But really this will only accelerate the migration, it would happen anyway.
Also, you have to factor in the relative lifetimes of machines. It's only been in the last couple of years that PC platforms have started to get competitive with some of Sun's server-class systems, but the lifetime of a system is three to five years. That means that a lot of those systems will start being retired in the next two to three years and you should start to see a lot of defections.
Given the growth of NT Server this may already have happened; it's hard to tell because the server market has simply exploded due to demand for web servers. That's hiding a whole lot of Sun's problems.
I don't think that the PC will ever push Sun out of the server market.
There are a whole lot of ex-DEC employees who thought the same way. Never say never; the ongoing progress of technology (and especially the pace of Moore's Law) continually destabilizes the market.
Ther are few that can touch Sun when it comes to the *real high end enterprise* market. Linux and NT (despite what the marketing drones from MS say) are not in direct competition with Sun.
What you say is true; today Sun has some really significant market advantages. But those advantages are not permanent; anyone with a little time and the appropriate talent can reproduce them.
Ok, nowadays you can buy your Starfire server with a gazillion processors and no NT or Linux box can touch it. Well, six years ago Sun couldn't do it either. They got better, and I think it's a foregone conclusion that PC platforms and OSs are going to get better too.
Now, some people believe that Sun can continue to push this envelope. The fact of the matter is that they can't. They already have the OS operating at super high levels of concurrency, they're not going to be able to get that much more improvement out of it. But that's not even the thing that will hurt them the most.
As PCs get better they will eat at more and more of the low-end Sun customers. Sun will not be able to grow the high end fast enough to sustain their income because there just aren't that many customers who need it, and as the customer base shrinks their R&D costs will be skyrocketing because incremental improvements get more and more expensive with each generation.
This has been happening for years. I don't know about you, but half of my career was spent on Sun workstations -- and as a result I have a soft spot in my heart for Sun. But that soft spot wasn't enough to get me to spend ten grand on a Sun workstation in 1995 when I could get a PC that was almost as fast (and had more memory and faster graphics) for three thousand.
Not surprisingly I went with the PC, and by 1997 lots of traditional Sun customers were doing the same. That was the first year that Sun's workstation sales growth underperformed the overall market growth. Today nobody even talks about Sun as a workstation vendor. They're a server vendor. They had to move upstream because they weren't making any money downstream.
This process will continue, with commodity hardware taking more and more sales from the bottom-end of Sun's product line. As it does so Sun's R&D will be amortized over fewer and fewer systems even as the R&D costs skyrocket for each incremental improvement. It will not take long before they run out of money for new R&D and shortly thereafter they'll run out of customers.
This story should sound familiar; it's what happened to the supercomputer companies and mainframe companies and minicomputer companies. And it's going to happen to Sun. Mark my words: they're in their glory days now. All of the weaker competitors have already died.
I dunno about that -- Look at where Sun and Linux were two years ago, and compare that with where they are today. Linux has exploded, creating more mindshare for Unix -- if anything, that has *helped* Sun -- Sun's earnings and stock price both have mushroomed dramatically over the past 2 years...
Linux has helped Sun by causing the Unix market to grow far faster than many so-called experts predicted it would.
No. The buying public doesn't really care what operating system they're running. They care that it's cheap. Open Systems didn't sell UNIX in the 80s, it was the fact that you could buy a Sun for half the cost of a VAX and it ran several times as fast. And Open Source isn't selling Linux, it's that it runs really well on cheap hardware and it costs a lot less than anything else.
NT has been growing like mad, but it wasn't because it was a better product than UNIX or Novell or whatever. The fact of the matter is that the PC platform has gotten so good that you can do a lot of stuff on it now, and for most of the last five years the most cost-effective OS on the PC was NT by quite a margin.
Seen this way, it is no wonder that Linux is exploding. It's using commodity hardware and has an incremental cost of zero (while NT's incremental cost has skyrocketed of late). Linux is going to hurt NT really, really bad on the server.
I've long said that Sun's problem isn't Microsoft: it's Intel (and nowadays AMD too). As commodity hardware gets better and better it pulls in more and more customers that used to have to buy bigger stuff (e.g. Suns).
Ok, I hear you thinking: If this is true, why is Sun doing so well? Two reasons. First, the web has caused an explosion of demand for servers. If you're not growing you must really suck. That growth will level out in the next couple of years as we reach the market saturation point. But just as importantly most of the web software out there today scales better by running it on bigger hardware than by replicating hardware. People who were serving a few hundred thousand hits two years ago on a midrange Sun are serving millions today, and it was way easier to buy a bigger Sun than to rewrite their software to work in a distributed manner.
There is, however, a limit to how far you can go with the One Big Box approach. (Just ask eBay.) When you hit that limit and are forced to distribute you then have the choice of going with lots of commodity boxes or a few big boxes. Well, lots of commodity boxes is cheaper and far more fault-tolerant (they may fail more often, but the percentage loss is smaller). An awful lot of companies are going to go with that approach, and the ones who don't are still going to shift to less expensive boxes (with much lower profit margins) because they can.
So what Sun's seeing today is a bubble caused by a combination of overall market explosion and legacy software. That bubble will break. The only question is when.
That's what DEC thought before Sun and that's what IBM thought before DEC.
There's this funny thing called Moore's Law that basically means that stuff that takes really expensive hardware today will be possible on machines that cost half as much 18 months from now. Run through that iteration a few times and you're looking at doing most everything on commodity hardware. We're way, way into that cycle now.
I'm quite familiar with Sun's offerings and I agree that today they have a really nice market. But the number of people who need to spend that kind of money to get the job done shrinks (as a percentage of population) every year simply because the cheap machines get good enough to do the job.
Why the heck do you think NT Server sold so many copies? It's not because it was better than a low-end Solaris box, it was because it was cheaper and did the job well enough. (And that's why Linux is a big problem for Microsoft: it does the job more than well enough and it's free.)
Now, with the web blowing big server demand through the roof Sun is going to do well for awhile... but it can't last forever. I'd be surprised if they pulled five more years out of it. And when they crash it's gonna make DEC's wild ride look like a mere fender-bender.
we also need to keep in mind that Linus himself said that Linux was not suited well for the high-end server market, since it still does not scale well.
This is true, but then again neither does NT, and Linux' is improving visibly in this area with every passing day.
But this is not particularly important. The bread-and-butter of NT is not big servers, it's all those little ones. If we can win the hearts and minds of small server buyers then we will beat Microsoft.
I feel kinda bad for Sun, though. They're screwed no matter which way this goes.
Linux increased in distribution at the expense of Netware and the Commercial Unixes
I can say quite definitively that Linux increased to some degree at the expense of NT as well. I've replaced a number of NT boxes in both server and workstation roles with Linux.
Now, maybe that trend doesn't hold with the industry at large, but a whole lot of the development organization I work with is running Linux today -- and almost all of them were on NT just six months ago.
I really never thought I'd see this much support for Linux.
It strikes me that most of the problem with DeCSS, aside from the possible trade-secret issues which I think are going to be effectively impossible to prosecute, result from it being effectively a copy-and-strip-protection program.
Now, from an engineer's point of view this is the first step toward creating a viewing program, but from the POV of the MPA it's a copy program. It's hard for a lot of people to see it any other way, since that's exactly what it's doing.
While I cannot agree with the judge that this makes copying DVDs inexpensive (it costs a lot more for storage for the copy than it does to buy an original), all of the other points seem pretty well founded in fact and/or in law. DeCSS looks to be precisely the kind of thing that CDMA is designed to prevent.
This does not, however, mean that it's necessarily illegal to produce a DVD viewer for Linux without the permission of the MPA et al. Rather, it means that you need to produce software that does not have an data output function and can therefore not be seen to have any intent to circumvent copy protection (i.e. it cannot copy the work).
Splicing the decryption code of DeCSS into an MPEG viewer, and providing no option to emit decrypted data, would effectively circumvent the argument that it has any intent to defeat copyright protection. Furthermore, the application should clearly fall under fair use doctrine.
All told, the plaintiffs have a really strong case that DeCSS violates CDMA. I'd be astounded if they lost, although it will be something of a hollow victory since the program is already widely disseminated and they cannot control dissemination worldwide.
But this is neither here nor there, because DeCSS doesn't really give me the ability to watch DVDs under Linux. It's just the first baby step. So why don't we focus our energies on producing a real viewer rather than disseminating DeCSS? jim frost
Not really. if there was a market for non-shite films/tv etc then there`d be some examples of it. I dont see any.
The fact of the matter is that without the distribution power of the major studios it's really hard for your average consumer to find such content.
You said it yourself: you don't see any. But it exists, produced by a bunch of independents. Sometimes they win awards for their work, and still consumers can't get it.
Piracy is going to be the downfall of the internet.
That's total baloney. They said that about photocopiers and audiotape and videotape and of course piracy was supposed to cripple the software industry.
It hasn't worked out that way for any industry yet. Rather, the easier it was to make copies the more money the content producers made because their production costs just kept dropping even though their prices remained relatively constant.
I mean, software is easy as hell to copy and yet look at how many software guys are billionaires (to say nothing of the unwashed hordes of us who are mere millionaires).
There's no reason whatsoever to believe that things will be any different this time.
To understand why this is the case you have to understand that the driving factor in media penetration is not how easy it is to duplicate but how easy it is to get in the first place.
The first rule in mass-market money making is the guy with the best distribution channels wins. In the past this meant that if you could get your stuff in the most newspapers or stores you sold more of it than anyone else. The Internet is just another distribution channel. It's cheaper and more accessible than most but the same rules still apply.
Microsoft proved without a doubt that traditional distribution channels beat Internet distribution channels in the long term. It was easier to get your browser software preloaded than to download it. So Netscape, the first business to really leverage the Internet as a distribution channel, lost. They would have won if they had locked up the vendor distribution channel before Microsoft got their act together.
So long as the media companies have the power to make content more accessible than anyone else they will win. The Internet doesn't change that; they'll still have the money for faster connections and better advertising.
As for copy control, we have been developing a legal framework for that for centuries and it works long-term. If the other guy is stealing your stuff you sue them.
Let them implement their protection schemes. Nobody's forcing anyone to use any particular scheme, right? I mean, theoretically a movie producer could release an unencrypted DVD, if they felt so inclined.
This brings up the question of whether or not a DVD player would actually play unencrypted content. I thought not. Does anyone know for sure?
It makes a huge difference. If they can, then there is really no reason whatsoever for CSS (since verbatim copies work without decryption). If they cannot, then CSS automatically limits who can produce content.
They'll come up with ways of copying the stuff, and the companies will use their collective efforts to keep it to a minimum, but really we're not dealing with any new ground here.
About the only thing DeCSS gives to the pirates is the ability to change the distribution format, in particular it's easy to retarget it to VCD. But that's a way worse copy than you got with even third or fourth generation videotape copies and it's not playable by that wide an audience anyway so clearly they can't be worried about that. The only way to match the quality is by stamping more DVDs, and that's possible without decryption.
Clearly there is some other reason they're worried about this.
What CSS is about is content provider control. Ever-dropping costs of delivery technologies is making it easier and easier for new players to get into the media game, and more competition is bad for the established media companies.
Now, with CSS, you have to be a member of The Club to get the keys you need to produce playable content. That dramatically reduces the number of potential competitors because they have to pony up the cash (at a minimum) -- assuming there aren't other membership restrictions.
The real threat with DeCSS is that it's the first step towards breaking the limitations on content production. I mean, what kind of disaster would it be if anyone with talent and a moderate production budget could produce content and sell it mass-market? You have to shudder at the thought.
I bought a pair of Inspiron 7500s back in late September. It took a little while to get the process going because of poor availability of the 15" displays, but they called me and told me about it and even beat their (revised) estimated ship date by two weeks.
I have no complaints about them and the machine works so well that I recommend it. I had to cobble together some drivers and figure out the display settings myself but this was expected.
Now we have Dell officially supporting Linux (even if only RH Linux) on the things. That's another step in the right direction if you ask me.
My only complaint with them in the ordering process was that they refused to sell me a DVD driver for the machine I bought with NT. NT doesn't have DVD drivers, which I knew, but even though I told them I didn't care (because I intended to dual-boot the thing) they wouldn't sell me the drive anyway. The service representative said their order entry system wouldn't allow him to do it.
What does this prove? Absolute nothing. However, it does raise some questions about how it's idiotic to just do everything with C/C++ because it's traditionally "the right thing to do". By using "traditional" programming languages, you will often be forced to spend so much time thinking about language issues, memory allocation & leaks, complex threading issues etc. that the application logic will suffer and become a secondary priority.
I've worked extensively in C, C++, and Java. Given my choice I will take Java virtually every time.
The reason why comes down to pure productivity. On average (we're talking about over the course of years) I'm 300% more productive in Java than C++. In some cases (particularly networking code) that number is more like 1500%.
Just think of what things you can do if you can write your application three or more times as fast as the other guy. You have time to write it, rewrite it, and optimize it before he's even done the first time.
And that, my friends, translates into huge market advantage.
Now, lots of people say that the reason Java is more productive is because you don't spend your time tracking down memory issues. That's not the case for me, at least not in large part; it's really not that hard to write a clean program in C++, and memory leak issues still exist in Java (which sells a lot of Optimize-It licenses, lemme tell you). Rather, Java is a lot more stringent in enforcing interfaces than is C++, to say nothing of C.
Consider, for instance, that Java enforces handling or passing of exceptions. In C++ you can silently ignore them, usually resulting in bugs or reliability problems that don't show up until late in the development cycle (or, worse, in the field). In Java you have to explicitly deal with exceptions; you are forced to make a conscious decision as to what to do every time you use an interface that throws an exception. What that means In The Real World is much more robust code on the first effort -- if it fails, it usually fails gracefully.
There are actually some problems related to this. In beta test programs, for instance, it is a lot harder to get people to report problems because they usually manifest themselves as a feature that doesn't always seem to work rather than a complete application crash. On the other hand the application can notice the problem and report it nicely rather than just disappearing or dumping core. These kinds of problems I can live with.
There are other development advantages. Java is dynamically linked at runtime. This makes it slower to start up than a C or C++ application but it means that there is no link phase to deal with at each compile/edit/debug cycle. On a large C++ project I used to wait as much as fifteen minutes per link; with Java that time is always zero. That translates into many more cycles in the same timeframe, and that translates into product going out the door faster. (I must note that I used to work on a C/C++ debugger with an incremental linker and it had many of these same advantages. It was, however, rather expensive.)
So: we have a case here were random heap crashes can't happen, where interface enforcement is stringent enough that you get more reliable stuff together on the first try, and where you can run through a compile/edit/debug cycle a lot faster. There is a hell of a lot to like there.
There are some downsides though.
The compilers still suck -- at least all of the common ones. Oh, projects like Jikes are yielding compilers that build code fast, but none of them build good code. They don't even do simple peephole optimizations, to say nothing of what you get in your typical C++ compiler. It's like going back and looking at code produced by 70s C compilers. Apparently the idea is that the JIT system takes care of that -- but JIT systems are severely limited in how much time they can spend compiling the code, plus they don't have anywhere near as much semantic information. The end result is worse code. This was true of C++ for quite some time too, of course, and is expected to get better, but for the moment you get to optimize a lot of things by hand.
JVM stability has been something of an issue. Big programs that push the environment hard (like, say, a web application that's handling tens of millions of hits per day, which is what I do with Java) tend to find the dirty corners that don't show up in your typical "hello world" applet. Things like limitations on the number of classes and methods you can have in your application (low tens of thousands prior to JDK 1.2), heap lock contention overhead as the thread count scales beyond a hundred or so, and other things have pushed us towards designs that are less convenient to build (although arguably much more scalable and fault tolerant).
Some people speak of JDBC being really nice. It's a good idea, but practically speaking very few of the JDBC drivers are particularly reliable, cross-compatibility leaves a lot to be desired, and performance is often not so hot. You have to spend more time on optimization. Luckily you have more time to spend on optimization.
So Java has its problems, but in my experience everything has its problems. Java's problems can be worked around with architecture and optimization and productivity improvements are so good that you have the time to do it. The end result is often a better product out the door faster.
Now, for all you guys who say that Java just isn't fast enough, several of the largest sites on the web run Java-based applications (you almost certainly have used some of them without even knowing it). And they do it on a lot less hardware, and less expensive hardware, than any of the competition manages with C/C++. This is in direct contract to the popular opinion that Java is slow.
There's nothing stopping someone from writing the same kind of thing in C/C++ other than time. We've had the time to write, optimize, rewrite, and optimize again several times over in the time span it has taken most of the competition to just make their product stable. Unsurprisingly this results in a faster and more stable product even when we've had to work around problems that the other guy wouldn't have had to deal with.
Java isn't for everything. You'd be insane to write drivers or operating systems in it, and runtime environments are really way too big for most embedded applications today. But when it works it's great, and it is working on a whole lot of servers out there on the 'net. You don't hear about them because nobody talks about the stuff that works, only the stuff that doesn't (like, say, eBay).
It's easy to copy down to a format that fits on a single CD; I saw a copy of The Matrix that had been copied this way (though I'm not sure the original source was DVD, it had been made prior to the release of the DVD).
The thing is, the quality really sucked in that format. It just wasn't an acceptable substitute.
And that's the thing that really irritates me about this. The storage necessary to produce a decent copy of a DVD currently costs more -- a lot more -- than the original DVD. CD formats are the only current storage medium that is even remotely cost effective, but you need about ten CDs to hold a single movie at the original resolution. Hard disk storage costs about five times as much as a legal copy (this week, anyway).
At the moment it's cheaper to buy the DVDs than steal them. That will probably change in about three or four years (the 4.xGB writable DVDs available next year won't quite do it, we need at least the next generation) but until then it's just not cost effective.
Personally I couldn't care less about the ability to copy DVDs. I'm happy paying for them, but I want to play them under Linux. If what it takes to get a player is subverting their asinine copy protection scheme, well, there is an easy way they could have dealt with that.
We noticed the tremendous similarity to the Blackdown work right away, too, and were a little surprised that no mention was made of them in the press release, but that's marketing for you.
It's wrong to say that they just repackaged the Blackdown work, however. Certainly the bulk of the package is Blackdown, but it appears that the Inprise part of this work is a new JIT system -- one that actually works. The JIT included with the Blackdown port is hopelessly broken. This has historically led to Linux JVMs having pretty much the poorest performance of any available JVM since you had to run it in interpreted mode.
This is not the only change we noticed. We had all kinds of problems using the Blackdown code with native threads -- serious performance degredation and unreliability. Not so with the Sun/Inprise version.
In our testing all run modes worked -- green, native, interpreted, and JIT. (Though there are some debugging messages that prove that this stuff is still not production quality.) This is a welcome change. Our testing shows a 60% performance improvement using native threads and JIT over the best we could get out of Blackdown RC2. That, my friends, is terrific news.
I still want to look at the IBM JDK 1.2 when it finally comes out, but for the moment we have something that's good enough to perhaps be used in a production environment. Now if I only had a debugger that worked...
Now I've had time to think about it, I don't think it goes far enough. Microsoft is not a progressive company. Sure they like to bundle stuff and give things away until they have a market stranglehold, but technically, they are not innovative or progressive.
I can agree that they haven't been progressive or innovative, but do we have to eliminate the possibility that they might become so?
The next few years are going to be terrifically hard on Microsoft; PCs are going to become seriously deemphasized in favor of portable internet access devices. They're going to have to think of ways to deal with that or they're going to become yet another dinosaur.
Hey, I hate 'em as much as anyone. Maybe more -- I've been dealing with them a lot longer than most of you guys. But past performance is not necessarily an indicator of future performance!
Stacker was the market. There was nothing until Stacker! If there is any company which has a grievance against MS, it's Stacker. We'll never know what other innovations they might have come up with.
Yes, Stacker was the market, but what they did was clearly something that was advantageous as an OS feature. Where Microsoft went wrong was stealing the implementation rather than building it themselves -- and they were justly punished.
Can you honestly say that adding that capability to the operating system as a no-extra-cost item was bad for the consumer? I can't; too many people I know used it.
Clearly it was bad for Stac, and I agree that Stac was innovative and I would have rather seen them stick around. Then again the same was true of FTP Software; do we lament having TCP/IP in the OS?
You say it was to the benefit of the consumer, but poor quality software and the unjudicious use of disk compression could cause devastation.
Certainly, but it meant that people who couldn't afford a new disk drive (remember when disk drives were expensive?) could continue to use their systems. That was a big benefit.
The power that Microsoft has been abusing with their monopoly position is the network effect that their application bundling and integration provides. If they continue to be allowed to bundle applications together (And I include the individual MS Office applications here), the network effect will persist and so will their market abuse.
Certainly. Their ability to bundle products that aren't competing well with monopoly products is an important issue that needs to be resolved, and Jackson certainly didn't go far enough in addressing the situation with Office. On the other hand there's nothing stopping someone from making a wordprocessor that is really compatible with Office's file formats and underselling them -- except that right now Microsoft sells most copies along with new PCs, leveraging their OS monopoly. That must stop or the other guys don't have a chance.
The only way to prevent this effect is to break this hard relationship between the applications. Excel is sold by one complany, Word by another, Outlook by another, Windows by another.
I don't have anything in particular against this approach other than the more companies you break them up into the harder it will be to get agreement and to administer. The simplest solution that can be effective is what we should be looking for.
Star Office isn't bundled with Red Hat.
You are mistaken. It comes with every copy of RH6.1. Buy one and see.
The SQL databases bundled with the various Linux distributions are not in competition with SQL server.
Aren't they? Don't people build websites and applications with postgres and MySql as the back-ends? Wouldn't MSQL be an option if these others weren't already there? And, as Linux proves itself in real-world deployments, don't you think it will become more and more of a competitor?
I do. I think the next two years are going to see all kinds of Linux-based competition to MSQL.
I don't actually see them unbundling anything... Ever... Even after they've destroyed the market.
They bundled and then unbundled Office -- not as an end-user bundle, but to OEMs. That's why it took off in the first place. Who's to say they wouldn't do it again if given the chance, particularly if we make it hard for them to leverage their monopoly in other ways?
I think this is too restrictive, as it requires that Microsoft be reactive rather than allowing them to be progressive.
Consider, for instance, disk file compression. No other OS that I'm aware of bundles that capability, but clearly it is a benefit to consumers that Microsoft did it.
Granted, it sucked to be Stacker when they started bundling it -- but it was good for the market.
What's important is that Microsoft make the decision to include a new capability on the grounds of a competitive OS feature, not as a means of wiping out an application competitor.
I think simply restricting their ability to unbundle does the trick; they can't decide to gouge the consumer for the feature when the other guy is gone.
Furthermore your approach would be virtually meaningless nowadays. Could Microsoft bundle Office? I dare say they could -- StarOffice is bundled with Red Hat. Could they bundle SQL server? Certainly, there are several databases bundled with various Linux distributions. Could they bundle development environments? Again, yes.
When it comes right down to it one or another OS bundles pretty much any kind of application or service you care to pick.
You're buying into the idea that multiple competing flavours of the operating system is bad. This 'fracturing' of the Unix market has lead to an extremely competitive and fast moving market.
No, it didn't. UNIX has progressed very little between the late 1980s and today with the exception of better supporting ever larger (and more proprietary) systems. Looking at the software you get with commercial UNIXen today is like looking into a time machine for me: almost nothing has changed. It took open source to stir up real progression.
Why? Because there was little incentive to improve things beyond supporting faster/bigger hardware, and none of the vendors had enough market share to attract very many ISVs.
In contrast a highly regular Windows led to an explosion in hardware and software. In just the last few years we've seen PC video and audio equipment progress from the stone age into some really marvelous stuff -- and do so at unbelievably low prices. Meanwhile the application pool has simply exploded, both in breadth and depth.
Windows, being a single implementation, had true standardization. UNIX, being a set of more-or-less similar implementations, had myriads of incompatibilities that made it hard to support all of the different vendors.
Sure the vendors innovate to try to get the edge on the competition, but they can't stray too far from 'standard' Unix. Features that really take off are eventually adopted by all players and become part of the 'standard'.
I have to disagree. It takes years before you can get new features into a group standard, meanwhile you can see a whole lot of API forking. But mostly we saw little to no API enhancements at all with UNIX.
A lot has been said about possible remedies. Most of it would not be practical or would not actually address the problem.
Let me make a couple of comments and suggestions regarding addressing the problem rather than focusing on penalties (which, most likely, will amount to Microsoft paying a stiff fine).
As the experts say the odds of opening up the source are essentially nonexistant. That does amount to the taking of Microsoft's intellectual property and even if it didn't it wouldn't be a good solution for the consumer except where code may improve by peer review. Most likely the result would be a great many code forks and that would be bad for everyone involved.
The idea of breaking Microsoft up into a number of Baby Bills, each with the same rights and equal resources, would be even worse. You would immediately see code forks and in the end you'd probably have one company win and the others fail -- accomplishing nothing but a lot of confusion in the interim.
As I see it there are two things we need to do in order to protect the consumer from monopolistic practices while simultaneously protecting Microsoft's right to do business.
First, we must separate the OS monopoly from the applications division. A lot of people suggest that this would help eliminate private use of APIs but, speaking as a professional developer with a long history of working with Microsoft code, I don't see that Microsoft has gained any make-or-brake capability through the use of private APIs -- at least not since way back in the MS-DOS days. If anything their dependency on such techniques has opened them up to ridicule and limited their implementation approaches. No Microsoft product has won in the market as a result of utilizing private APIs; rather, they won through the use of bundling agreements.
The rationale for breaking them up is to provide a disincentive to product packaging (bundling) as a way of putting competitors out of business.
The problem we have now is that Microsoft's OS and applications divisions operate out of the same revenue pool. This allows Microsoft to sacrifice applications revenue in the short term in order to gain long-term applications market share. They can afford to do this because their monopoly product provides a huge, uninterruptable cash flow. They have wielded this power repeatedly to build market share for new products, including but not limited to Windows itself, Office, and IIS. (Notice that I'm not including Internet Explorer. More on that in a minute.)
Separating the two in this way makes any deal to package software with the OS a licensing decision that will affect the bottom line of both companies right from the start. This is how it is for everyone else already.
The second thing we have to do is eliminate the ability for Microsoft to use pricing and/or availability of the monopoly product as a bargaining lever. This means establishing some sort of price control. I don't believe we should go so far as to totally regulate pricing; Microsoft is correct in that they will have competition in the future (particularly since PCs will shortly have to compete with simpler and cheaper devices) and they need to be able to respond to that. But they don't need the ability to be able to charge Gateway one price and Dell another simply because one company kowtows to the company's plans and the other doesn't. Allow Microsoft to set the price of the OS product but enforce equivalency amongst all buyers and do not allow Microsoft to deny the sale of the product to anyone. This would make it very difficult for Microsoft to use monopoly power as a bargaining device.
Microsoft is also correct in saying that they cannot give up their right to add features to their product. This does in effect put the government in the operating systems design position and I think it's safe to say that that won't do anyone any good.
The typical argument that I see against allowing them to add features is that they use that as a way to destroy competition (particularly Netscape). Well, there's some truth to that, but there's also a lot of truth to the proposition that adding Internet Explorer to the basic Windows package was very good for consumers and very good for the market as a whole (sorry Netscape). In fact, by the time they added IE virtually all of their competition had already been shipping a web browser. It's hard to see why they shouldn't have been allowed to do the same thing.
To put it another way: How many of us lament the death of the TCP/IP add-on companies that resulted from bundling TCP/IP with Windows? I sure don't -- that made the rocket-like growth of the Internet possible.
There do need to be some limits, however.
First and foremost anything they bundle with the OS cannot be separated out again and sold as a separate product. This makes it impossible for Microsoft to use short-term bundling as a way of putting a competitor out of business but allows them the ability to add stuff for competitive reasons.
Secondly products bundled with the monopoly product cannot interact in a proprietary way with outside applications. This makes it impossible for them to build features into IE that will help sell IIS or MSN, for instance.
Lastly, the monopoly product company must be prevented from entering into exclusive distribution agreements of any kind.
A remedy along these lines accomplishes the goal of introducing a number of checks on the ability for Microsoft to leverage their monopoly as a club and it does so without eliminating their right to extend their OS product. It ought to be palatable to both sides and, to cut to the chase, do what needs to be done.
The advent of the BSD line of Unixen, providing the possibility of Open Source OS'.
You're giving more credit here than is really due. If I were going to give a "father of the open source OS" to something it would be the original Bell Labs UNIXen. They basically gave it away for a song for years, and BSD wouldn't have ever happened if that weren't the case.
But BSD was seminal in that it provided fertile soil for the development of a whole lot of software that was distributed in source form, often at little or no cost. And perhaps the most important of that software was the TCP/IP implementation -- it formed the foundation on which today's Internet is built.
I'd give credit to the Bell Labs folk in one other area too. The OS they built was simple enough to be cloned, and that led to a wealth of reimplementations including Xinu, MINIX, and of course Linux. And those formed the foundations of today's open source movement.
The advent of MACH, allowing people to see how different OS philosophies work.
Mach wasn't really that interesting. Its core ideas had been well hashed out some fifteen years earlier. If anything I might consider Mach something of a failure; it was, after all, the basis of NeXT and OSF -- both huge failures.
The advent of K&R C, which made programming much easier, whilst retaining a lot of power.
C was following in the footsteps of PL/I. What made C particularly interesting was not its power but its simplicity; it was easy to learn and easy to implement and cheap to license. All of these things kickstarted its spread.
Lest we give C too much credit let us not forget that C also overloaded the concept of reference, pointer, and array as well as providing very little in the way of inter-function consistency checking. These things led to a whole host of bugs that continue to plague us (although at least ANSI gave us function parameter checking).
The advent of X10, providing a networkable GUI to the real-world workstation.
While the general idea is good, neither X10 nor X11 are particularly good designs. Sun's NeWS (yet another Gosling brainchild) was vastly superior in design. Too bad the implementation was so bad (something you could say about a lot of Gosling stuff, actually).
Where X failed was in its association with DEC. DEC wanted a really limited functionality desktop (they sold servers don't you know) and that resulted in serious overuse of network bandwidth and a whole host of warts in the protocol. The one thing that could really have improved X was display lists (rendering macros, if you will), which would have reduced network overhead by at least an order of magnitude for typical applications.
But good ideas just won't stay down. Sun failed with NeWS but we got the functionality a few years later anyway -- only now we call it a web browser.
An interesting sidebar to all of this is that DEC's idea of a graphics terminal failed miserably in the face of ever faster and less expensive desktop equipment. And yet we have companies like Sun and Oracle trying to foist the same old stuff on us a decade later.
The creation of Perl, which revolutionised the concept of scripts.
Well, you got me confused with this one. Perl is certainly popular but to say it revolutionized scripting -- well, that's pushing things a bit. Technologically there was nothing new there. What made it particularly interesting was Wall's trademark portability and source distribution.
And that leads us naturally to:
The development of Sun's RPC system, making the development of distributed software practical.
Sun's RPC wasn't revolutionary by any stretch of the imagination; this stuff had been done long before. What was revolutionary was what Sun did with it -- they gave it away, along with NFS. In short order any machine you had could be an NFS server and Sun sold the only fully integrated clients. Now that was smart! It gave them a serious leg-up on the fully proprietary Domain.
We see the pattern of "cheap source availability wins" repeated again and again throughout the history of computing. UNIX was hugely successful because source code was cheap. (In fact, the darkest days of UNIX can be traced directly to AT&T's change in the pricing model.) TCP/IP exploded because its source code was cheap. RPC/NFS was successful because source code was cheap. The FSF tools have propagated widely because source code was cheap. Linux is exploding because source code is cheap. BSD has made a comeback since its source code got cheap again.
Sun's idea that they could make money while effectively giving the source away was revolutionary. Too bad they went the proprietary route after beating Apollo into submission.
The development of Gopher and WAIS, introducing distributed information services, distributed hypertext, and distributed multimedia. The WWW built on these concepts, but did not create them.
Hypertext finds its source in Xanadu, which predates the rest of these considerably. Xanadu was quite revolutionary concept and it spawned a wealth of projects to build distributed document systems.
But while Xanadu gave us the concepts it was the Mosaic team that made it not only practical but attractive. And that turned the world on its head.
The writing of TWM - a window manager SO horrible as to actually encourage people to go out and write something better.
Heh, clearly you don't remember uwm. Twm was a vast improvement.
Anyway, while I don't agree with most of your opinions, you certainly did hit on several important themes.
Autodetection has certainly improved things on those cards where it works, but it fails on a lot of hardware (eg the ever-popular ATI hardware). But things have at least gotten to the point where you can more or less pick your video card off of a list and have it work.
Unfortunately that's only the first part of configuration. The next part is the monitor, and here there are lots of problems. The monitor lists have huge holes and even monitors on the lists can be overdriven by the server. For instance: just try running a Sony Multiscan 20sfII at 1024x768 sometime. The monitor is on the list and the list specs are the same as the published specs -- but it still doesn't work. Have a laptop display? Good luck: not only aren't there any on the lists, the manufacturers don't give specs. It's take-a-guess-and-hope-I-don't-fry-the-display.
I've literally spent more time fiddling with monitor configurations than all other Linux installation tasks combined, and that includes stuff like debugging the driver for my new wireless network card. Your basic user just gets scared when confronted with the questions asked by the Custom Monitor configuration. (Hell, I get scared. You can blow a monitor if you guess wrong!)
I realize that the XFree86 folk are stuck between a rock and a hard place here. This stuff is really complicated and they're getting little or no help from the vendors. But it's still a problem and we do ourselves no favor by pretending that it's not.
Software and hardware sales are interrelated, no question, but it is false to say that the software drives the hardware sales. That's true only in a stable, mature market.
The problem is that the onslaught of ever faster, ever cheaper hardware lends automatic instability to the market. New hardware platforms show up that can do the same job for a lot less money -- and when that happens people first start building homegrown systems on it, then as system sales jump the software vendors get into it, then the network effect takes hold as the market matures.
This isn't theory, we've seen it again and again. Why did people jump off of IBM 360 hardware in favor of the PDP and VAX hardware? Why did people jump off the VAX in favor of SPARC? Why are people using Intel hardware now when they used to use SPARC?
Using history as a guide I'd estimate that software drives hardware until you hit a price/performance differential factor of about three. Then you see a platform jump.
Sun is a buisness, Linux is not. Linux was meant to be free and Solaris is a licensed copyrighted product and is Suns flagship software. Asking Sun to give up control is a funny.
The one serious problem with this statement is that Sun does not now nor has it ever made money from its software. Any doubt about that was quelled with the Solar System fiasco. At best Solaris helps sell Sun hardware; they sell more hardware (a lot more) by offering Solaris than not.
Now, lots of lipwork has gone into the battle between Sun and Microsoft. But here's the thing: Sun's enemy isn't Microsoft. If anything Sun could to pretty well cooperating with Microsoft, leveraging their software expertise against Sun's hardware expertise. That they have not done so to date has been to their advantage in that they provide little encouragement to their customers to stop using Sun hardware. But for how much longer?
Sun's problem isn't Microsoft and it never was. Sun's problem is Intel. Sun makes their money from hardware. They always have. They sold stuff that could do things almost nobody else could do at a terrific price point. The fact that it ran UNIX instead of Domain or VMS wasn't material to customers -- it was fast and cheap.
The problem they have is that commodity hardware (Intel hardware) has improved to the point that there's not much you can do on Sun systems that you can't do on Intel systems -- but at a lower cost. Barring some reason not to do so people will tend to buy the cheaper stuff.
One big reason Sun customers haven't jumped onto Intel stuff wholesale is that it was not all that easy to get UNIX software to run under Windows. But now there's this Linux thing: it's not hard at all to move Solaris-based software to Linux, and Linux provides many of the same benefits you'd get running Solaris. All that's missing is the really big hardware and Moore's law and the quest for more money is driving the Intel vendors that way at breakneck pace.
We've seen this before. It's exactly how Digital took the market from IBM with its minis and how Sun took the market from Digital with its workstations. The question is not which one is better, it's which one is cheaper and still gets the job done.
In the past few years a lot of prior Sun customers like myself started using NT. We did so not because we thought NT was better but because it was good enough and a lot cheaper. Now here's this Linux thing; we can have everything we always liked Sun for, but at a price even better than that of NT. I don't know about the rest of you, but that's pretty damn appealing to me. It may be why a quarter of engineers at my company run Linux today, a transition that happened in just the last couple of months.
And that's Sun's problem in a nutshell. Intel-based systems are going to eat them alive, and Linux availability is going to make that happen far faster than it would if they were competing against vendors running only NT.
Sun's "community source license" is a PR stunt, taking advantage of the momentum of open source in public perception. The licenses are a sham; you're welcome to help them but you can't make money off of it. That is not a sustainable position; one incentive for Open Source is that there is always the possibility that you can take what you did and make some money off of it. As we've seen there are certainly people making money off of Linux!
Sun's lawsuit against Microsoft for dirtying Java is also a PR stunt. Have you actually used Microsoft's JVM? It's pretty good. If I were interested in suing people for dirtying the language I'd be suing Netscape in a flash because their JVM is a piece of crap. (Actually that should be plural. There are dozens of incompatible -- both with the Java standard and amongst themselves -- Netscape JVMs, and none of them are stable enough to use for real work.) That Sun went after the big boy Microsoft rather than the real core of the problem is rather illuminating in terms of their underlying motivation.
I've been a Sun proponent for years, ever since my first exposure to the Sun2. But I can see the handwriting on the wall: Sun's position is untenable. Their life has been extended a few years by the explosion in large system demand caused by the Internet, but it is not sustainable. All this PR around their community license and whatnot is great in the short term but completely beside the point.
Slashdot Mirror
Much more of their income is coming from high-margin servers rather than volume workstations. That makes them a lot more profitable even as their unit sales decrease.
That's great business, but it's exactly the same kind of business that IBM was in before DEC showed up, and DEC was in before Sun showed up. Over time the cheaper machines got good enough to do the job and all at once there was a market discontinuity and the incumbant saw income collapse.
In response to your claim that powerful PCs will overtake Sun's hardware -- well many UNIX servers are less powerful than today's top of the line x86 hardware. But they still sell.
There is a resistance to movement because it's expensive to jump hardware platforms, particularly between operating systems. There has been a whole lot of resistance towards jumping on PCs because the dominant OS has been NT for the last few years. NT hasn't been particularly mature and the jump is especially costly because there is little in common between the two systems.
This is one area where Linux stands to make a really big impact. Lots of Sun customers who wouldn't use NT would use Linux. But really this will only accelerate the migration, it would happen anyway.
Also, you have to factor in the relative lifetimes of machines. It's only been in the last couple of years that PC platforms have started to get competitive with some of Sun's server-class systems, but the lifetime of a system is three to five years. That means that a lot of those systems will start being retired in the next two to three years and you should start to see a lot of defections.
Given the growth of NT Server this may already have happened; it's hard to tell because the server market has simply exploded due to demand for web servers. That's hiding a whole lot of Sun's problems.
I don't think that the PC will ever push Sun out of the server market.
There are a whole lot of ex-DEC employees who thought the same way. Never say never; the ongoing progress of technology (and especially the pace of Moore's Law) continually destabilizes the market.
jim frost
What you say is true; today Sun has some really significant market advantages. But those advantages are not permanent; anyone with a little time and the appropriate talent can reproduce them.
Ok, nowadays you can buy your Starfire server with a gazillion processors and no NT or Linux box can touch it. Well, six years ago Sun couldn't do it either. They got better, and I think it's a foregone conclusion that PC platforms and OSs are going to get better too.
Now, some people believe that Sun can continue to push this envelope. The fact of the matter is that they can't. They already have the OS operating at super high levels of concurrency, they're not going to be able to get that much more improvement out of it. But that's not even the thing that will hurt them the most.
As PCs get better they will eat at more and more of the low-end Sun customers. Sun will not be able to grow the high end fast enough to sustain their income because there just aren't that many customers who need it, and as the customer base shrinks their R&D costs will be skyrocketing because incremental improvements get more and more expensive with each generation.
This has been happening for years. I don't know about you, but half of my career was spent on Sun workstations -- and as a result I have a soft spot in my heart for Sun. But that soft spot wasn't enough to get me to spend ten grand on a Sun workstation in 1995 when I could get a PC that was almost as fast (and had more memory and faster graphics) for three thousand.
Not surprisingly I went with the PC, and by 1997 lots of traditional Sun customers were doing the same. That was the first year that Sun's workstation sales growth underperformed the overall market growth. Today nobody even talks about Sun as a workstation vendor. They're a server vendor. They had to move upstream because they weren't making any money downstream.
This process will continue, with commodity hardware taking more and more sales from the bottom-end of Sun's product line. As it does so Sun's R&D will be amortized over fewer and fewer systems even as the R&D costs skyrocket for each incremental improvement. It will not take long before they run out of money for new R&D and shortly thereafter they'll run out of customers.
This story should sound familiar; it's what happened to the supercomputer companies and mainframe companies and minicomputer companies. And it's going to happen to Sun. Mark my words: they're in their glory days now. All of the weaker competitors have already died.
jim frost
Linux has helped Sun by causing the Unix market to grow far faster than many so-called experts predicted it would.
No. The buying public doesn't really care what operating system they're running. They care that it's cheap. Open Systems didn't sell UNIX in the 80s, it was the fact that you could buy a Sun for half the cost of a VAX and it ran several times as fast. And Open Source isn't selling Linux, it's that it runs really well on cheap hardware and it costs a lot less than anything else.
NT has been growing like mad, but it wasn't because it was a better product than UNIX or Novell or whatever. The fact of the matter is that the PC platform has gotten so good that you can do a lot of stuff on it now, and for most of the last five years the most cost-effective OS on the PC was NT by quite a margin.
Seen this way, it is no wonder that Linux is exploding. It's using commodity hardware and has an incremental cost of zero (while NT's incremental cost has skyrocketed of late). Linux is going to hurt NT really, really bad on the server.
I've long said that Sun's problem isn't Microsoft: it's Intel (and nowadays AMD too). As commodity hardware gets better and better it pulls in more and more customers that used to have to buy bigger stuff (e.g. Suns).
Ok, I hear you thinking: If this is true, why is Sun doing so well? Two reasons. First, the web has caused an explosion of demand for servers. If you're not growing you must really suck. That growth will level out in the next couple of years as we reach the market saturation point. But just as importantly most of the web software out there today scales better by running it on bigger hardware than by replicating hardware. People who were serving a few hundred thousand hits two years ago on a midrange Sun are serving millions today, and it was way easier to buy a bigger Sun than to rewrite their software to work in a distributed manner.
There is, however, a limit to how far you can go with the One Big Box approach. (Just ask eBay.) When you hit that limit and are forced to distribute you then have the choice of going with lots of commodity boxes or a few big boxes. Well, lots of commodity boxes is cheaper and far more fault-tolerant (they may fail more often, but the percentage loss is smaller). An awful lot of companies are going to go with that approach, and the ones who don't are still going to shift to less expensive boxes (with much lower profit margins) because they can.
So what Sun's seeing today is a bubble caused by a combination of overall market explosion and legacy software. That bubble will break. The only question is when.
jim frost
There's this funny thing called Moore's Law that basically means that stuff that takes really expensive hardware today will be possible on machines that cost half as much 18 months from now. Run through that iteration a few times and you're looking at doing most everything on commodity hardware. We're way, way into that cycle now.
I'm quite familiar with Sun's offerings and I agree that today they have a really nice market. But the number of people who need to spend that kind of money to get the job done shrinks (as a percentage of population) every year simply because the cheap machines get good enough to do the job.
Why the heck do you think NT Server sold so many copies? It's not because it was better than a low-end Solaris box, it was because it was cheaper and did the job well enough. (And that's why Linux is a big problem for Microsoft: it does the job more than well enough and it's free.)
Now, with the web blowing big server demand through the roof Sun is going to do well for awhile ... but it can't last forever. I'd be surprised if they pulled five more years out of it. And when they crash it's gonna make DEC's wild ride look like a mere fender-bender.
jim frost
This is true, but then again neither does NT, and Linux' is improving visibly in this area with every passing day.
But this is not particularly important. The bread-and-butter of NT is not big servers, it's all those little ones. If we can win the hearts and minds of small server buyers then we will beat Microsoft.
I feel kinda bad for Sun, though. They're screwed no matter which way this goes.
jim frost
I can say quite definitively that Linux increased to some degree at the expense of NT as well. I've replaced a number of NT boxes in both server and workstation roles with Linux.
Now, maybe that trend doesn't hold with the industry at large, but a whole lot of the development organization I work with is running Linux today -- and almost all of them were on NT just six months ago.
I really never thought I'd see this much support for Linux.
jim frost
Now, from an engineer's point of view this is the first step toward creating a viewing program, but from the POV of the MPA it's a copy program. It's hard for a lot of people to see it any other way, since that's exactly what it's doing.
While I cannot agree with the judge that this makes copying DVDs inexpensive (it costs a lot more for storage for the copy than it does to buy an original), all of the other points seem pretty well founded in fact and/or in law. DeCSS looks to be precisely the kind of thing that CDMA is designed to prevent.
This does not, however, mean that it's necessarily illegal to produce a DVD viewer for Linux without the permission of the MPA et al. Rather, it means that you need to produce software that does not have an data output function and can therefore not be seen to have any intent to circumvent copy protection (i.e. it cannot copy the work).
Splicing the decryption code of DeCSS into an MPEG viewer, and providing no option to emit decrypted data, would effectively circumvent the argument that it has any intent to defeat copyright protection. Furthermore, the application should clearly fall under fair use doctrine.
All told, the plaintiffs have a really strong case that DeCSS violates CDMA. I'd be astounded if they lost, although it will be something of a hollow victory since the program is already widely disseminated and they cannot control dissemination worldwide.
But this is neither here nor there, because DeCSS doesn't really give me the ability to watch DVDs under Linux. It's just the first baby step. So why don't we focus our energies on producing a real viewer rather than disseminating DeCSS?
jim frost
The fact of the matter is that without the distribution power of the major studios it's really hard for your average consumer to find such content.
You said it yourself: you don't see any. But it exists, produced by a bunch of independents. Sometimes they win awards for their work, and still consumers can't get it.
jim
jim frost
That's total baloney. They said that about photocopiers and audiotape and videotape and of course piracy was supposed to cripple the software industry.
It hasn't worked out that way for any industry yet. Rather, the easier it was to make copies the more money the content producers made because their production costs just kept dropping even though their prices remained relatively constant.
I mean, software is easy as hell to copy and yet look at how many software guys are billionaires (to say nothing of the unwashed hordes of us who are mere millionaires).
There's no reason whatsoever to believe that things will be any different this time.
To understand why this is the case you have to understand that the driving factor in media penetration is not how easy it is to duplicate but how easy it is to get in the first place.
The first rule in mass-market money making is the guy with the best distribution channels wins. In the past this meant that if you could get your stuff in the most newspapers or stores you sold more of it than anyone else. The Internet is just another distribution channel. It's cheaper and more accessible than most but the same rules still apply.
Microsoft proved without a doubt that traditional distribution channels beat Internet distribution channels in the long term. It was easier to get your browser software preloaded than to download it. So Netscape, the first business to really leverage the Internet as a distribution channel, lost. They would have won if they had locked up the vendor distribution channel before Microsoft got their act together.
So long as the media companies have the power to make content more accessible than anyone else they will win. The Internet doesn't change that; they'll still have the money for faster connections and better advertising.
As for copy control, we have been developing a legal framework for that for centuries and it works long-term. If the other guy is stealing your stuff you sue them.
jim frost
This brings up the question of whether or not a DVD player would actually play unencrypted content. I thought not. Does anyone know for sure?
It makes a huge difference. If they can, then there is really no reason whatsoever for CSS (since verbatim copies work without decryption). If they cannot, then CSS automatically limits who can produce content.
jim frost
About the only thing DeCSS gives to the pirates is the ability to change the distribution format, in particular it's easy to retarget it to VCD. But that's a way worse copy than you got with even third or fourth generation videotape copies and it's not playable by that wide an audience anyway so clearly they can't be worried about that. The only way to match the quality is by stamping more DVDs, and that's possible without decryption.
Clearly there is some other reason they're worried about this.
What CSS is about is content provider control. Ever-dropping costs of delivery technologies is making it easier and easier for new players to get into the media game, and more competition is bad for the established media companies.
Now, with CSS, you have to be a member of The Club to get the keys you need to produce playable content. That dramatically reduces the number of potential competitors because they have to pony up the cash (at a minimum) -- assuming there aren't other membership restrictions.
The real threat with DeCSS is that it's the first step towards breaking the limitations on content production. I mean, what kind of disaster would it be if anyone with talent and a moderate production budget could produce content and sell it mass-market? You have to shudder at the thought.
jim frost
jimf@frostbytes.com
jim frost
I bought a pair of Inspiron 7500s back in late September. It took a little while to get the process going because of poor availability of the 15" displays, but they called me and told me about it and even beat their (revised) estimated ship date by two weeks.
I have no complaints about them and the machine works so well that I recommend it. I had to cobble together some drivers and figure out the display settings myself but this was expected.
Now we have Dell officially supporting Linux (even if only RH Linux) on the things. That's another step in the right direction if you ask me.
My only complaint with them in the ordering process was that they refused to sell me a DVD driver for the machine I bought with NT. NT doesn't have DVD drivers, which I knew, but even though I told them I didn't care (because I intended to dual-boot the thing) they wouldn't sell me the drive anyway. The service representative said their order entry system wouldn't allow him to do it.
jim
jim frost
I don't know what your problem might have been, but I've been running RH6.0 and 6.1 on my Inspiron 7500 since October and power off works fine.
Suspend works too, although it loses the keyboard repeat settings and one of my PCMCIA cards doesn't reset properly.
jim
jim frost
I've worked extensively in C, C++, and Java. Given my choice I will take Java virtually every time.
The reason why comes down to pure productivity. On average (we're talking about over the course of years) I'm 300% more productive in Java than C++. In some cases (particularly networking code) that number is more like 1500%.
Just think of what things you can do if you can write your application three or more times as fast as the other guy. You have time to write it, rewrite it, and optimize it before he's even done the first time.
And that, my friends, translates into huge market advantage.
Now, lots of people say that the reason Java is more productive is because you don't spend your time tracking down memory issues. That's not the case for me, at least not in large part; it's really not that hard to write a clean program in C++, and memory leak issues still exist in Java (which sells a lot of Optimize-It licenses, lemme tell you). Rather, Java is a lot more stringent in enforcing interfaces than is C++, to say nothing of C.
Consider, for instance, that Java enforces handling or passing of exceptions. In C++ you can silently ignore them, usually resulting in bugs or reliability problems that don't show up until late in the development cycle (or, worse, in the field). In Java you have to explicitly deal with exceptions; you are forced to make a conscious decision as to what to do every time you use an interface that throws an exception. What that means In The Real World is much more robust code on the first effort -- if it fails, it usually fails gracefully.
There are actually some problems related to this. In beta test programs, for instance, it is a lot harder to get people to report problems because they usually manifest themselves as a feature that doesn't always seem to work rather than a complete application crash. On the other hand the application can notice the problem and report it nicely rather than just disappearing or dumping core. These kinds of problems I can live with.
There are other development advantages. Java is dynamically linked at runtime. This makes it slower to start up than a C or C++ application but it means that there is no link phase to deal with at each compile/edit/debug cycle. On a large C++ project I used to wait as much as fifteen minutes per link; with Java that time is always zero. That translates into many more cycles in the same timeframe, and that translates into product going out the door faster. (I must note that I used to work on a C/C++ debugger with an incremental linker and it had many of these same advantages. It was, however, rather expensive.)
So: we have a case here were random heap crashes can't happen, where interface enforcement is stringent enough that you get more reliable stuff together on the first try, and where you can run through a compile/edit/debug cycle a lot faster. There is a hell of a lot to like there.
There are some downsides though.
The compilers still suck -- at least all of the common ones. Oh, projects like Jikes are yielding compilers that build code fast, but none of them build good code. They don't even do simple peephole optimizations, to say nothing of what you get in your typical C++ compiler. It's like going back and looking at code produced by 70s C compilers. Apparently the idea is that the JIT system takes care of that -- but JIT systems are severely limited in how much time they can spend compiling the code, plus they don't have anywhere near as much semantic information. The end result is worse code. This was true of C++ for quite some time too, of course, and is expected to get better, but for the moment you get to optimize a lot of things by hand.
JVM stability has been something of an issue. Big programs that push the environment hard (like, say, a web application that's handling tens of millions of hits per day, which is what I do with Java) tend to find the dirty corners that don't show up in your typical "hello world" applet. Things like limitations on the number of classes and methods you can have in your application (low tens of thousands prior to JDK 1.2), heap lock contention overhead as the thread count scales beyond a hundred or so, and other things have pushed us towards designs that are less convenient to build (although arguably much more scalable and fault tolerant).
Some people speak of JDBC being really nice. It's a good idea, but practically speaking very few of the JDBC drivers are particularly reliable, cross-compatibility leaves a lot to be desired, and performance is often not so hot. You have to spend more time on optimization. Luckily you have more time to spend on optimization.
So Java has its problems, but in my experience everything has its problems. Java's problems can be worked around with architecture and optimization and productivity improvements are so good that you have the time to do it. The end result is often a better product out the door faster.
Now, for all you guys who say that Java just isn't fast enough, several of the largest sites on the web run Java-based applications (you almost certainly have used some of them without even knowing it). And they do it on a lot less hardware, and less expensive hardware, than any of the competition manages with C/C++. This is in direct contract to the popular opinion that Java is slow.
There's nothing stopping someone from writing the same kind of thing in C/C++ other than time. We've had the time to write, optimize, rewrite, and optimize again several times over in the time span it has taken most of the competition to just make their product stable. Unsurprisingly this results in a faster and more stable product even when we've had to work around problems that the other guy wouldn't have had to deal with.
Java isn't for everything. You'd be insane to write drivers or operating systems in it, and runtime environments are really way too big for most embedded applications today. But when it works it's great, and it is working on a whole lot of servers out there on the 'net. You don't hear about them because nobody talks about the stuff that works, only the stuff that doesn't (like, say, eBay).
jim frost
jimf@frostbytes.com
It's easy to copy down to a format that fits on a single CD; I saw a copy of The Matrix that had been copied this way (though I'm not sure the original source was DVD, it had been made prior to the release of the DVD).
The thing is, the quality really sucked in that format. It just wasn't an acceptable substitute.
And that's the thing that really irritates me about this. The storage necessary to produce a decent copy of a DVD currently costs more -- a lot more -- than the original DVD. CD formats are the only current storage medium that is even remotely cost effective, but you need about ten CDs to hold a single movie at the original resolution. Hard disk storage costs about five times as much as a legal copy (this week, anyway).
At the moment it's cheaper to buy the DVDs than steal them. That will probably change in about three or four years (the 4.xGB writable DVDs available next year won't quite do it, we need at least the next generation) but until then it's just not cost effective.
Personally I couldn't care less about the ability to copy DVDs. I'm happy paying for them, but I want to play them under Linux. If what it takes to get a player is subverting their asinine copy protection scheme, well, there is an easy way they could have dealt with that.
jim
It's wrong to say that they just repackaged the Blackdown work, however. Certainly the bulk of the package is Blackdown, but it appears that the Inprise part of this work is a new JIT system -- one that actually works. The JIT included with the Blackdown port is hopelessly broken. This has historically led to Linux JVMs having pretty much the poorest performance of any available JVM since you had to run it in interpreted mode.
This is not the only change we noticed. We had all kinds of problems using the Blackdown code with native threads -- serious performance degredation and unreliability. Not so with the Sun/Inprise version.
In our testing all run modes worked -- green, native, interpreted, and JIT. (Though there are some debugging messages that prove that this stuff is still not production quality.) This is a welcome change. Our testing shows a 60% performance improvement using native threads and JIT over the best we could get out of Blackdown RC2. That, my friends, is terrific news.
I still want to look at the IBM JDK 1.2 when it finally comes out, but for the moment we have something that's good enough to perhaps be used in a production environment. Now if I only had a debugger that worked...
jim frost
jimf@frostbytes.com
I can agree that they haven't been progressive or innovative, but do we have to eliminate the possibility that they might become so?
The next few years are going to be terrifically hard on Microsoft; PCs are going to become seriously deemphasized in favor of portable internet access devices. They're going to have to think of ways to deal with that or they're going to become yet another dinosaur.
Hey, I hate 'em as much as anyone. Maybe more -- I've been dealing with them a lot longer than most of you guys. But past performance is not necessarily an indicator of future performance!
Stacker was the market. There was nothing until Stacker! If there is any company which has a grievance against MS, it's Stacker. We'll never know what other innovations they might have come up with.
Yes, Stacker was the market, but what they did was clearly something that was advantageous as an OS feature. Where Microsoft went wrong was stealing the implementation rather than building it themselves -- and they were justly punished.
Can you honestly say that adding that capability to the operating system as a no-extra-cost item was bad for the consumer? I can't; too many people I know used it.
Clearly it was bad for Stac, and I agree that Stac was innovative and I would have rather seen them stick around. Then again the same was true of FTP Software; do we lament having TCP/IP in the OS?
You say it was to the benefit of the consumer, but poor quality software and the unjudicious use of disk compression could cause devastation.
Certainly, but it meant that people who couldn't afford a new disk drive (remember when disk drives were expensive?) could continue to use their systems. That was a big benefit.
The power that Microsoft has been abusing with their monopoly position is the network effect that their application bundling and integration provides. If they continue to be allowed to bundle applications together (And I include the individual MS Office applications here), the network effect will persist and so will their market abuse.
Certainly. Their ability to bundle products that aren't competing well with monopoly products is an important issue that needs to be resolved, and Jackson certainly didn't go far enough in addressing the situation with Office. On the other hand there's nothing stopping someone from making a wordprocessor that is really compatible with Office's file formats and underselling them -- except that right now Microsoft sells most copies along with new PCs, leveraging their OS monopoly. That must stop or the other guys don't have a chance.
The only way to prevent this effect is to break this hard relationship between the applications. Excel is sold by one complany, Word by another, Outlook by another, Windows by another.
I don't have anything in particular against this approach other than the more companies you break them up into the harder it will be to get agreement and to administer. The simplest solution that can be effective is what we should be looking for.
Star Office isn't bundled with Red Hat.
You are mistaken. It comes with every copy of RH6.1. Buy one and see.
The SQL databases bundled with the various Linux distributions are not in competition with SQL server.
Aren't they? Don't people build websites and applications with postgres and MySql as the back-ends? Wouldn't MSQL be an option if these others weren't already there? And, as Linux proves itself in real-world deployments, don't you think it will become more and more of a competitor?
I do. I think the next two years are going to see all kinds of Linux-based competition to MSQL.
I don't actually see them unbundling anything... Ever... Even after they've destroyed the market.
They bundled and then unbundled Office -- not as an end-user bundle, but to OEMs. That's why it took off in the first place. Who's to say they wouldn't do it again if given the chance, particularly if we make it hard for them to leverage their monopoly in other ways?
jim
Consider, for instance, disk file compression. No other OS that I'm aware of bundles that capability, but clearly it is a benefit to consumers that Microsoft did it.
Granted, it sucked to be Stacker when they started bundling it -- but it was good for the market.
What's important is that Microsoft make the decision to include a new capability on the grounds of a competitive OS feature, not as a means of wiping out an application competitor.
I think simply restricting their ability to unbundle does the trick; they can't decide to gouge the consumer for the feature when the other guy is gone.
Furthermore your approach would be virtually meaningless nowadays. Could Microsoft bundle Office? I dare say they could -- StarOffice is bundled with Red Hat. Could they bundle SQL server? Certainly, there are several databases bundled with various Linux distributions. Could they bundle development environments? Again, yes.
When it comes right down to it one or another OS bundles pretty much any kind of application or service you care to pick.
jim
No, it didn't. UNIX has progressed very little between the late 1980s and today with the exception of better supporting ever larger (and more proprietary) systems. Looking at the software you get with commercial UNIXen today is like looking into a time machine for me: almost nothing has changed. It took open source to stir up real progression.
Why? Because there was little incentive to improve things beyond supporting faster/bigger hardware, and none of the vendors had enough market share to attract very many ISVs.
In contrast a highly regular Windows led to an explosion in hardware and software. In just the last few years we've seen PC video and audio equipment progress from the stone age into some really marvelous stuff -- and do so at unbelievably low prices. Meanwhile the application pool has simply exploded, both in breadth and depth.
Windows, being a single implementation, had true standardization. UNIX, being a set of more-or-less similar implementations, had myriads of incompatibilities that made it hard to support all of the different vendors.
Sure the vendors innovate to try to get the edge on the competition, but they can't stray too far from 'standard' Unix. Features that really take off are eventually adopted by all players and become part of the 'standard'.
I have to disagree. It takes years before you can get new features into a group standard, meanwhile you can see a whole lot of API forking. But mostly we saw little to no API enhancements at all with UNIX.
jim frost
jimf@frostbytes.com
Let me make a couple of comments and suggestions regarding addressing the problem rather than focusing on penalties (which, most likely, will amount to Microsoft paying a stiff fine).
As the experts say the odds of opening up the source are essentially nonexistant. That does amount to the taking of Microsoft's intellectual property and even if it didn't it wouldn't be a good solution for the consumer except where code may improve by peer review. Most likely the result would be a great many code forks and that would be bad for everyone involved.
The idea of breaking Microsoft up into a number of Baby Bills, each with the same rights and equal resources, would be even worse. You would immediately see code forks and in the end you'd probably have one company win and the others fail -- accomplishing nothing but a lot of confusion in the interim.
As I see it there are two things we need to do in order to protect the consumer from monopolistic practices while simultaneously protecting Microsoft's right to do business.
First, we must separate the OS monopoly from the applications division. A lot of people suggest that this would help eliminate private use of APIs but, speaking as a professional developer with a long history of working with Microsoft code, I don't see that Microsoft has gained any make-or-brake capability through the use of private APIs -- at least not since way back in the MS-DOS days. If anything their dependency on such techniques has opened them up to ridicule and limited their implementation approaches. No Microsoft product has won in the market as a result of utilizing private APIs; rather, they won through the use of bundling agreements.
The rationale for breaking them up is to provide a disincentive to product packaging (bundling) as a way of putting competitors out of business.
The problem we have now is that Microsoft's OS and applications divisions operate out of the same revenue pool. This allows Microsoft to sacrifice applications revenue in the short term in order to gain long-term applications market share. They can afford to do this because their monopoly product provides a huge, uninterruptable cash flow. They have wielded this power repeatedly to build market share for new products, including but not limited to Windows itself, Office, and IIS. (Notice that I'm not including Internet Explorer. More on that in a minute.)
Separating the two in this way makes any deal to package software with the OS a licensing decision that will affect the bottom line of both companies right from the start. This is how it is for everyone else already.
The second thing we have to do is eliminate the ability for Microsoft to use pricing and/or availability of the monopoly product as a bargaining lever. This means establishing some sort of price control. I don't believe we should go so far as to totally regulate pricing; Microsoft is correct in that they will have competition in the future (particularly since PCs will shortly have to compete with simpler and cheaper devices) and they need to be able to respond to that. But they don't need the ability to be able to charge Gateway one price and Dell another simply because one company kowtows to the company's plans and the other doesn't. Allow Microsoft to set the price of the OS product but enforce equivalency amongst all buyers and do not allow Microsoft to deny the sale of the product to anyone. This would make it very difficult for Microsoft to use monopoly power as a bargaining device.
Microsoft is also correct in saying that they cannot give up their right to add features to their product. This does in effect put the government in the operating systems design position and I think it's safe to say that that won't do anyone any good.
The typical argument that I see against allowing them to add features is that they use that as a way to destroy competition (particularly Netscape). Well, there's some truth to that, but there's also a lot of truth to the proposition that adding Internet Explorer to the basic Windows package was very good for consumers and very good for the market as a whole (sorry Netscape). In fact, by the time they added IE virtually all of their competition had already been shipping a web browser. It's hard to see why they shouldn't have been allowed to do the same thing.
To put it another way: How many of us lament the death of the TCP/IP add-on companies that resulted from bundling TCP/IP with Windows? I sure don't -- that made the rocket-like growth of the Internet possible.
There do need to be some limits, however.
First and foremost anything they bundle with the OS cannot be separated out again and sold as a separate product. This makes it impossible for Microsoft to use short-term bundling as a way of putting a competitor out of business but allows them the ability to add stuff for competitive reasons.
Secondly products bundled with the monopoly product cannot interact in a proprietary way with outside applications. This makes it impossible for them to build features into IE that will help sell IIS or MSN, for instance.
Lastly, the monopoly product company must be prevented from entering into exclusive distribution agreements of any kind.
A remedy along these lines accomplishes the goal of introducing a number of checks on the ability for Microsoft to leverage their monopoly as a club and it does so without eliminating their right to extend their OS product. It ought to be palatable to both sides and, to cut to the chase, do what needs to be done.
jim frost
jimf@frostbytes.com
You're giving more credit here than is really due. If I were going to give a "father of the open source OS" to something it would be the original Bell Labs UNIXen. They basically gave it away for a song for years, and BSD wouldn't have ever happened if that weren't the case.
But BSD was seminal in that it provided fertile soil for the development of a whole lot of software that was distributed in source form, often at little or no cost. And perhaps the most important of that software was the TCP/IP implementation -- it formed the foundation on which today's Internet is built.
I'd give credit to the Bell Labs folk in one other area too. The OS they built was simple enough to be cloned, and that led to a wealth of reimplementations including Xinu, MINIX, and of course Linux. And those formed the foundations of today's open source movement.
The advent of MACH, allowing people to see how different OS philosophies work.
Mach wasn't really that interesting. Its core ideas had been well hashed out some fifteen years earlier. If anything I might consider Mach something of a failure; it was, after all, the basis of NeXT and OSF -- both huge failures.
The advent of K&R C, which made programming much easier, whilst retaining a lot of power.
C was following in the footsteps of PL/I. What made C particularly interesting was not its power but its simplicity; it was easy to learn and easy to implement and cheap to license. All of these things kickstarted its spread.
Lest we give C too much credit let us not forget that C also overloaded the concept of reference, pointer, and array as well as providing very little in the way of inter-function consistency checking. These things led to a whole host of bugs that continue to plague us (although at least ANSI gave us function parameter checking).
The advent of X10, providing a networkable GUI to the real-world workstation.
While the general idea is good, neither X10 nor X11 are particularly good designs. Sun's NeWS (yet another Gosling brainchild) was vastly superior in design. Too bad the implementation was so bad (something you could say about a lot of Gosling stuff, actually).
Where X failed was in its association with DEC. DEC wanted a really limited functionality desktop (they sold servers don't you know) and that resulted in serious overuse of network bandwidth and a whole host of warts in the protocol. The one thing that could really have improved X was display lists (rendering macros, if you will), which would have reduced network overhead by at least an order of magnitude for typical applications.
But good ideas just won't stay down. Sun failed with NeWS but we got the functionality a few years later anyway -- only now we call it a web browser.
An interesting sidebar to all of this is that DEC's idea of a graphics terminal failed miserably in the face of ever faster and less expensive desktop equipment. And yet we have companies like Sun and Oracle trying to foist the same old stuff on us a decade later.
The creation of Perl, which revolutionised the concept of scripts.
Well, you got me confused with this one. Perl is certainly popular but to say it revolutionized scripting -- well, that's pushing things a bit. Technologically there was nothing new there. What made it particularly interesting was Wall's trademark portability and source distribution.
And that leads us naturally to:
The development of Sun's RPC system, making the development of distributed software practical.
Sun's RPC wasn't revolutionary by any stretch of the imagination; this stuff had been done long before. What was revolutionary was what Sun did with it -- they gave it away, along with NFS. In short order any machine you had could be an NFS server and Sun sold the only fully integrated clients. Now that was smart! It gave them a serious leg-up on the fully proprietary Domain.
We see the pattern of "cheap source availability wins" repeated again and again throughout the history of computing. UNIX was hugely successful because source code was cheap. (In fact, the darkest days of UNIX can be traced directly to AT&T's change in the pricing model.) TCP/IP exploded because its source code was cheap. RPC/NFS was successful because source code was cheap. The FSF tools have propagated widely because source code was cheap. Linux is exploding because source code is cheap. BSD has made a comeback since its source code got cheap again.
Sun's idea that they could make money while effectively giving the source away was revolutionary. Too bad they went the proprietary route after beating Apollo into submission.
The development of Gopher and WAIS, introducing distributed information services, distributed hypertext, and distributed multimedia. The WWW built on these concepts, but did not create them.
Hypertext finds its source in Xanadu, which predates the rest of these considerably. Xanadu was quite revolutionary concept and it spawned a wealth of projects to build distributed document systems.
But while Xanadu gave us the concepts it was the Mosaic team that made it not only practical but attractive. And that turned the world on its head.
The writing of TWM - a window manager SO horrible as to actually encourage people to go out and write something better.
Heh, clearly you don't remember uwm. Twm was a vast improvement.
Anyway, while I don't agree with most of your opinions, you certainly did hit on several important themes.
jim frost
jimf@frostbytes.com
Autodetection has certainly improved things on those cards where it works, but it fails on a lot of hardware (eg the ever-popular ATI hardware). But things have at least gotten to the point where you can more or less pick your video card off of a list and have it work.
Unfortunately that's only the first part of configuration. The next part is the monitor, and here there are lots of problems. The monitor lists have huge holes and even monitors on the lists can be overdriven by the server. For instance: just try running a Sony Multiscan 20sfII at 1024x768 sometime. The monitor is on the list and the list specs are the same as the published specs -- but it still doesn't work. Have a laptop display? Good luck: not only aren't there any on the lists, the manufacturers don't give specs. It's take-a-guess-and-hope-I-don't-fry-the-display.
I've literally spent more time fiddling with monitor configurations than all other Linux installation tasks combined, and that includes stuff like debugging the driver for my new wireless network card. Your basic user just gets scared when confronted with the questions asked by the Custom Monitor configuration. (Hell, I get scared. You can blow a monitor if you guess wrong!)
I realize that the XFree86 folk are stuck between a rock and a hard place here. This stuff is really complicated and they're getting little or no help from the vendors. But it's still a problem and we do ourselves no favor by pretending that it's not.
jim frost
jimf@frostbytes.com
The problem is that the onslaught of ever faster, ever cheaper hardware lends automatic instability to the market. New hardware platforms show up that can do the same job for a lot less money -- and when that happens people first start building homegrown systems on it, then as system sales jump the software vendors get into it, then the network effect takes hold as the market matures.
This isn't theory, we've seen it again and again. Why did people jump off of IBM 360 hardware in favor of the PDP and VAX hardware? Why did people jump off the VAX in favor of SPARC? Why are people using Intel hardware now when they used to use SPARC?
Using history as a guide I'd estimate that software drives hardware until you hit a price/performance differential factor of about three. Then you see a platform jump.
jim frost
jimf@frostbytes.com
The one serious problem with this statement is that Sun does not now nor has it ever made money from its software. Any doubt about that was quelled with the Solar System fiasco. At best Solaris helps sell Sun hardware; they sell more hardware (a lot more) by offering Solaris than not.
Now, lots of lipwork has gone into the battle between Sun and Microsoft. But here's the thing: Sun's enemy isn't Microsoft. If anything Sun could to pretty well cooperating with Microsoft, leveraging their software expertise against Sun's hardware expertise. That they have not done so to date has been to their advantage in that they provide little encouragement to their customers to stop using Sun hardware. But for how much longer?
Sun's problem isn't Microsoft and it never was. Sun's problem is Intel . Sun makes their money from hardware. They always have. They sold stuff that could do things almost nobody else could do at a terrific price point. The fact that it ran UNIX instead of Domain or VMS wasn't material to customers -- it was fast and cheap.
The problem they have is that commodity hardware (Intel hardware) has improved to the point that there's not much you can do on Sun systems that you can't do on Intel systems -- but at a lower cost. Barring some reason not to do so people will tend to buy the cheaper stuff.
One big reason Sun customers haven't jumped onto Intel stuff wholesale is that it was not all that easy to get UNIX software to run under Windows. But now there's this Linux thing: it's not hard at all to move Solaris-based software to Linux, and Linux provides many of the same benefits you'd get running Solaris. All that's missing is the really big hardware and Moore's law and the quest for more money is driving the Intel vendors that way at breakneck pace.
We've seen this before. It's exactly how Digital took the market from IBM with its minis and how Sun took the market from Digital with its workstations. The question is not which one is better, it's which one is cheaper and still gets the job done.
In the past few years a lot of prior Sun customers like myself started using NT. We did so not because we thought NT was better but because it was good enough and a lot cheaper. Now here's this Linux thing; we can have everything we always liked Sun for, but at a price even better than that of NT. I don't know about the rest of you, but that's pretty damn appealing to me. It may be why a quarter of engineers at my company run Linux today, a transition that happened in just the last couple of months.
And that's Sun's problem in a nutshell. Intel-based systems are going to eat them alive, and Linux availability is going to make that happen far faster than it would if they were competing against vendors running only NT.
Sun's "community source license" is a PR stunt, taking advantage of the momentum of open source in public perception. The licenses are a sham; you're welcome to help them but you can't make money off of it. That is not a sustainable position; one incentive for Open Source is that there is always the possibility that you can take what you did and make some money off of it. As we've seen there are certainly people making money off of Linux!
Sun's lawsuit against Microsoft for dirtying Java is also a PR stunt. Have you actually used Microsoft's JVM? It's pretty good. If I were interested in suing people for dirtying the language I'd be suing Netscape in a flash because their JVM is a piece of crap. (Actually that should be plural. There are dozens of incompatible -- both with the Java standard and amongst themselves -- Netscape JVMs, and none of them are stable enough to use for real work.) That Sun went after the big boy Microsoft rather than the real core of the problem is rather illuminating in terms of their underlying motivation.
I've been a Sun proponent for years, ever since my first exposure to the Sun2. But I can see the handwriting on the wall: Sun's position is untenable. Their life has been extended a few years by the explosion in large system demand caused by the Internet, but it is not sustainable. All this PR around their community license and whatnot is great in the short term but completely beside the point.
jim frost
jimf@frostbytes.com
I don't know about the rest of you but XFree86 really hasn't been unreliable for me. In fact, it's never even crashed.
It's a total bitch to configure, but aside from that....