Slashdot Mirror

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.

jim frost
jimf@frostbytes.com
jim frost

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).

jim frost
jimf@frostbytes.com

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...

jim frost
jimf@frostbytes.com

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.

jim frost
jimf@frostbytes.com

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.

jim frost
jimf@frostbytes.com

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.

jim frost
jimf@frostbytes.com

I've used both utilities extensively.

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

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.

jim frost
jimf@frostbytes.com

Overall I thought the article was well-done. In the PC desktop space it's certainly true that Linux will not displace Windows anytime soon, and IMO it never will due to the entrenced market.

But Microsoft is wrong that Linux has not affected sales of NT. A lot of historical UNIX workstation users such as myself switched to NT in order to take advantage of the cheap PC hardware and easy software availability. I jumped onto NT almost immediately because it was good enough and a lot cheaper than your typical RISC workstation. It took a lot of effort to make a usable development environment, but you could do well enough.

Over the last few months, however, Linux has started to make significant inroads into our engineering department. Today roughly a quarter of all engineers run Linux rather than NT -- up from just two in the spring (that's about 700% growth). Microsoft can't see that in their sales yet because IT is still buying NT licenses whether or not we use them, but the transition is happening remarkably fast -- far faster than the RISC->PC movement that brought in NT. It will not be long before new NT purchases are curtailed to some degree.

There have certainly been some NT sales lost to Linux, however. I recently purchased a new laptop and I chose to go with Linux rather than NT despite running NT exclusively for the last four years. That's a sale NT would have gotten only a few months ago.

Generally speaking Gartner is correct that the people jumping onto Linux are traditional UNIX users. That means that on the desktop Microsoft is pretty safe -- there never were that many UNIX users.

But on the server, well, that's another thing entirely. Microsoft is not particularly well-entrenched; they're competing well against the commercial UNIXen at the low-end but that's largely because the hardware is cheaper. Linux uses the same hardware, costs less, and doesn't have client license issues. That 3.5% market that is dismissed in the article was statistically insignificant only a year ago!

Gartner is right that the traditional UNIX vendors are in the most trouble, but they were already in trouble. Their problem isn't and never was Microsoft, it was the PC. Linux gives those UNIX people a lower-cost solution without giving up UNIX. For small servers it's a very interesting solution to an IT department that is UNIX-savvy.

Microsoft makes great noise about how Linux isn't hurting them in that market, but the truth of the matter is that it's taking sales away from traditional UNIX vendors that Microsoft would otherwise have gotten. It has noticably slowed the impact of NT, and that definitely has their attention. Why else are they running benchmarks all over the place? They have to prove that NT is worth spending the money.

A lot of Linux people believe that Linux will beat NT by outperforming it. That might be true in a couple of years, but it's not true now except on the lowest-end hardware. Linux will beat NT in two respects:

1. Everything you need to run practically any kind of server is already in the box. That dramatically reduces the up-front cost of the server.

2. Linux is dramatically more reliable. You set it up and you forget about it. I contrast this with NT, which needs a regular reboot to keep performance up or whenever you install or upgrade an application.

Microsoft is worried about the server market and they should be. Linux is cheap and reliable and if there's any two things that IT departments like in a server those are the things.

jim frost
jimf@frostbytes.com

Ignoring for a minute that Solaris is already free for a lot of people, it still wouldn't make it.

Why not? It's not a matter of software at all. It's a matter of hardware.

First, my basic assumption: People don't really care which computer system they run so long as it gets the job done. If it works well enough they will decide by price. Sun beat Apollo and DEC not by having better software (even today's Solaris is a pale shadow of Domain in all sorts of ways) but by selling fast machines cheap. SunOS was bare-bones to say the least. But Sun sold their Sun3 boxes at prices the other guys couldn't match, and then they slam-dunked them with the SPARCstation, providing three times the performance at the same price.

The "fast machines cheap" theme runs decades long in the computer world. Remember: DEC beat IBM not by having better stuff but by selling it for less.

We're seeing it happen again. The Intel and the PC manufacturers are building boxes using mainstream hardware that are the equal of some pretty expensive hardware just a couple of years back. Sure, Sun's stuff got faster too but that's not the point: the point is that people who couldn't have dealt with a PC before can now use them to get their job done. So why pay more?

PCs are cheap and up to all but the toughest tasks -- and they're getting faster and more reliable and even cheaper all the time. Lots of people, like myself, who were exclusive SPARC users for years now use PCs because they provide much better bang for the buck. So long as the PC is fast enough to get the job done it doesn't much matter that the SPARC has the performance edge.

In the not-so-distant future the SPARC will become untenable for Sun; the R&D costs will continue to climb while the number of chips they can amortize the cost over will drop due to increasing penetration by Intel-based systems. Sun will get pushed ever upward towards the tip of the pyramid of users, those few who buy the fastest machines, and will have to charge more and more for those machines just to break even.

This theme is familiar too: Sun did it to the supercomputer companies. Thinking Machines? Cray? Gone. All of the specialized supercomputer companies are gone, their markets dwindled to the point where the business was untenable.

I think we can take as a given that whatever wins in the workstation/server space will win on Intel-based hardware. It has such a huge user base that they have the most R&D resources and can spread it amongst the most user. Now the question is: is Solaris good enough on Intel hardware to beat Linux or other contenders?

Today that answer is emphatically "no". Solaris scales better and performs pretty well but it just doesn't support that much hardware. Linux runs on everything while Solaris is, well, picky. You really want top-grade stuff to run Solaris. Linux runs on that piece of junk clone 486 box with the weird CD-ROM. Or any clone box you happen to find in the pages of Computer Shopper.

What that means is that the market for Linux is way, way larger than that for Solaris. Sun could fix that, but it'll take years and cost a fortune. Linux is getting that support for free. And even if Sun makes the investment they can't beat Linux on price.

I've long wondered why Sun keeps bashing on Microsoft. It must just be for the PR. You see, Microsoft is not Sun's problem. Intel is Sun's problem. Linux just makes that problem worse.

So: All else being equal, Linux would probably win because it's faster on common hardware and supports more (read: cheaper) hardware and Sun can't really afford to make Solaris competitive.

But all else is not equal. You see, Sun doesn't make their money on software. Never did; if you needed any proof of that the Solar System fiasco really removed all doubt. Sun makes their money on hardware and they're in trouble because PC hardware is decimating their sales at the low-end and rapidly encroaching on midrange. Over the next few years Intel-based hardware will scale well up into Sun's performance spectrum and will do it at a price Sun cannot afford to match.

Sun can't afford to give away a version of Solaris that might accelerate that. Hell, they can't even afford to SELL a version of Solaris that might accelerate that. Solaris/x86 was supposed to be a hole card if they had to jump off of SPARC. But Linux blindsided them. Now all their competitors have a high-quality UNIX too, and they don't even have to pay anyone else for the right to sell it.

So: Sun can't win this. They can't compete in the PC space against companies that are accustomed to razor-thin margins. They can't give away any kind of seriously supported Solaris on the PC because it'll just chop up their market even faster. And the PC is encroaching, fast. At some point they simply won't be able to afford to do Solaris development anymore, free or otherwise.

Lots of people are claiming that open source will rule the world because it's open. No, that's not it at all. Open source will rule because it's CHEAP. As it turns out "open" and "cheap" are interrelated in this case, but the important point is that the hardware companies don't have to pay a software tax.

For all practical purposes Microsoft is successful because they allow vendors to outsource the OS development, spreading R&D costs out over many vendors. That was true of UNIX, too, once upon a time. Well, Linux is the mother of all outsourcing operations and that will make it a smash hit. It is not only low-cost, it's zero-cost.

Linux gives the PC manufacturers -- particularly Compaq and Dell -- the possibility of competing head-to-head with Sun on functionality but without any of the software R&D costs that Sun has to bear with Solaris. With super-low software costs and the ability to undercut Sun seriously on hardware these PC vendors are going to beat Sun silly.

Some may argue that scalability problems will keep Linux out of the game indefinitely. I don't think so; it'll slow it down in the near term, but not much. Linux' scalability is improving at an unbelievable pace. It did in the last two years what it took Sun five to do with Solaris, and that was without significant vendor support. Linux will likely scale as well as Solaris inside of two years.

And that's why Solaris can't possibly beat Linux. Not now, anyway, and it probably never could have.

But all of this is just a specific case of a more important point that you should keep in mind whenever you're thinking of Linux-versus-whatever. Linux has effectively devalued server OS software to the point where it's not worth spending a lot of money on anymore. That is great for the consumer but it's bad for proprietary server OS vendors. It's certainly going to dent Microsoft's plans, but it's really going to hurt Novell. And you'd have to be blind to miss the fact that it's going to devalue it elsewhere too; the desktop PC is probably immune, but only because it's so late in its life and there's a lot of momentum.

Food for thought.

jim frost
jimf@frostbytes.com