\r\n

the first line:

\r\n\r\n

"All of Unix is more at risk than Microsoft's Windows in the next few\r\nyears,"

\r\n\r\n

is just plain stupid. Unices play well together, Windows is suddenly odd man\r\nout. Ugly file paths, stupid remote file protocols (smb), monolithic design\r\nhostile to creation of appliance boxes.

\r\n

This is true. However it's undenyable that GNU/Linux has eroded the\r\nproprietary Unix market from the bottom up. This is a typical free\r\nsoftwrare market incursion. First to fall was SCO (now a GNU/Linux\r\ncompany). SGI and DEC cum Compaq cum HP's Tru64 are next on the block.\r\nSGI's already lost much of the high-end graphics rendering market to\r\nGNU/Linux, though it's likely to retain its specialized high-end spook\r\nniche a while longer.

AIX and HP/UX are already slated for replacement (likely with a long\r\nEOL tail), and SGI is actively courting GNU/Linux on Intel and Itanium\r\nsystems. Note that in the IBM and HP of these cases, however, the\r\ncompanies have other business lines, and their RISC / Open Systems lines\r\nfit into a larger strategy, which can be revisited as needed.

Sun is the company that's being hit on a number of fronts. Instance\r\non promoting Solaris is going to be a diminishing niche. To date, Sun's\r\nbeen very reluctant to open to GNU/Linux, or free software. Largely to\r\nits detriment.

I think GNU/Linux will shake up the traditional\r\nmicrocomputer vendors, as part of their value-added has been\r\nsoftware-induced lock-in on their hardware. A GNU/Linux-dominated world\r\nis one in which there will be far greater hardware mobility. OTOH, it\r\nwill also allow shops to mix-and-match hardware to obtain optimum\r\nperformance mixes, while deploying uniform (or non-uniform, if that's\r\ntheir choice) environments across them.

Short term: the stubborn (yes, that's you, Scott) will suffer. Long\r\nterm: Microsoft loses. Big.

\r\n

\r\nSun is the company that's being hit on a number of fronts. Instance on\r\npromoting Solaris is going to be a diminishing niche.\r\n

\r\n\r\n

However, it retains one considerable redoubt, at least in the area of\r\nmassively parallel computing. Linux doesn't scale to large SMP\r\ninstallations, and probably never will, as that is not how it's\r\ndesigned. (Solaris, for its part, is dog-slow in uniprocessor\r\nsituations, on account of how it's tuned.)

\r\n

Though [link|http://slashdot.org/article.pl?sid=03/01/07/179242&mode=thread&tid=139|SGI's\r\ndone some interesting work] (also \r\n[link|http://newsforge.com/newsforge/03/01/07/1712243.shtml|NewsForge])\r\nrecently. 64 processors. GNU/Linux.

My suspicion: GNU/Linux scaling will be accomplished via a split\r\nrole. SMP scalability will remain relatively low-end. SMP is neat\r\nstuff, but there are serious engineering problems encountered in both SW\r\nand HW as node count increases. Clustering SMP boxen in a mixed-mode\r\nwill likely produce the biggest bang for the buck. There are problems\r\nwhich restrict themselves to NUMA solutions, but many can be attacked in\r\naggregate on a clusters or mixed solution.

Too, SMP payoff falls with node count, while complexity increases.\r\n2-CPU systems give you twice the punch of one. Doubling theoretical\r\ncycles requires doubling CPUs, with corresponding costs. Clusters also\r\nhave the same "double the count to double the throughput" issue, but\r\nbeing composed of largely autonomous units, can be stacked lego-block\r\nstyle to a much greater extent.

SMP's appeal is to the technology marketer who sees a high-end\r\nproduct which can be sold at top dollar. The solutions engineer looking\r\nat total systems cost -- hardware, OS, administration, software\r\ndevelopment, and operations -- is likely to find a different contrained\r\noptimization point. I similarly suspect that Java's love of pthreads is\r\nbased on Sun's own success in solving this problem -- it encourages sale\r\nof their HW -- but there are alternate solutions if you take a broader\r\nscope. There will always be a small set of high-end applications which\r\ncall for SMP, but I don't expect the Linux kernel's general reluctance\r\nin this area to be a significant block.