Slashdot Mirror
Compaq May Nix Tru64 for Merced
Pivo writes "Sure I'd rather use Linux, and sure, "Tru64" is a cheezy name for a Unix variant, but for some reason I'm not happy to hear that Compaq may not release Tru64 for Merced after all. Nothing has been confirmed by Compaq however." But, according to the article, Compaq will keep supporting Unix on Alphas.
I love this guy. He must work for Microsoft. Since when was having "too many" choices a problem? We have linux, freebsd, openbsd, netbsd, solaris, tru64, sunOS, AIX, HP-UX, etc. All of them have niche markets. For example, netbsd is an excellent platform to build a firewall or intranet server on (good security), whereas linux makes an excellent server for a small-office setting (linux/samba - can't be beat). This analyst definately needs to get out more... he probably thinks NT and MSOffice are the only two products on the planet...
--
Or chip development.
Compaq has taken the OS provided them by Micro$oft and the CPU by Intel and made products.
From the DEC/Digital side, their Unix was not well accepted. The OEM mags were quoting that for every 10 users leaving VMS, only 2 stayed with Digital. (No one identified if it was DEC or its Unix as to why 80% left)
And, for Intel there are MANY Unixes, and a few non-Unix OSes. (PICK, THEOS, and some stuff from a company in Redmond) The Alpha choices are much less.
So, it does not suprise me to here that they are just going to keep working on what has already been developed...the Alpha product.
Because without a market for the Alpha processor, Compaq has alot of IP they can't get a return on.
If it was said on slashdot, it MUST be true!
Let's see:
Irix will not run on Intel
Tru64 will not run on Intel
Win2000 will only run on Intel
So which OS will be able to run on more than one platform: Linux!
I have nothing against the other Unixes, even less against ths BSDs, but I think that after decades of fragmentation, the Unix world is coming together at last, in the form of Linux.
Why compete with themselves? According to the article, they already are planning to sell Monterey on their IA-64 systems. They probably figure that selling both TRU64 and Monterey for IA-64 would be redundant and a big waste of their money.
I think I see what they're trying to do:
Alpha-based systems: Digital branding (running OpenVMS or Tru64)
All others: Compaq branding (running Monterey or W2K)
although that might be a little too obvious to be correct.
Glückwünsche, haben Sie Slashdot ermordet, indem Sie zum korporativen Druck beugten und Subskriptionen einlei
Actually everyday its becoming more & more obvious that Merced is really the Mckinley Beta. Even Intel has admitted there will be no performance gain with Merced & IA64 will only get into high gear when Mckinley comes out. Afterall, Merced partner HP even admitted it, saying that it's better to wait till Mckinley. Quite a few of the other vendors have also said they wont be ramping up their IA64 products till Mckinley hits the shelves.
All we have here is a couple of analyists saying they believe Compaq is likely to cut development of Digital UNIX[1] on IA-64. Nothing official. Nothing from Compaq.
Now, granted, "Shannon Knows DEC" often gave us great insights into DEC. However, Mr. Shannon also blew it many a time. He's in the business of making predictions, and like weather predictions, they aren't always right. It is also worth pointing out that while Shannon knew DEC, he prolly doesn't know Compaq all that well.
In short: This is much ado about nothing.
I'm not saying it can't happen, just that this bit of information is mere speculation from the outside, and should be taken with a large amount of salt.
[1] I refuse to use the name "Tru64". That is the stupidest name for an OS I have ever heard.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
OK, for years we've been hearing about this wonderful IA64 architecture, and that it's going to be the be-all and end-all of CPUs. Naturally, you hear a lot about Microsoft promising 64-bit support, "shipping on the same day as Merced", and how Merced is a critical product for them to scale NT up and invade the datacenter. Of course, this is to be expected, because Microsoft and it's customers are pretty much stuck Intel platforms, so this would be a natural move (especially with the IA32 compatibility built into merced).
But at the same time, you have the big UNIX vendors (Sun, HP, IBM, DEC/Compaq) announcing that they too are also going to support Merced. Which is odd because these vendors make their own hardware and CPUs. I have to admit that I'm confused at the strategy, which on it's face seems to bolster WinTel.
Are the UNIX companies using IA64 to slowly get out of the CPU business? or the hardware business in general? That would be an odd strategy because right now they're making most of their money off hardware, and that's where the main differentiation is right now.
What happens when ZDNet benchmarks all of the commercial Unixes on some Dell PowerEdge? Does Vendor X really want their customers to see that they are 7% slower than Vendor Y on the same hardware? Or are they going to lock it down so that Vendor X Unix only runs on Vendor X Merced hardware. If so, what's the point?
Maybe Compaq/DEC is the first company that figured out that Unix-on-Merced is a loser strategy, and there's more money to be made with their own CPUs and hardware. (You have to figure Compaq would know - they are certainly going to be the premire IA64 hardware vendor for the Windows folks.)
Business. Numbers. Money. People. Computer World.
So why bother porting for Merced when Linux is the biggest selling 64 bit OS already?
And Compaq firmly supports Linux. If you don't believe me go and download the Compaq/Digital Fortran and C compilers for Linux.
Known as the best optimized that you can get, they now are fully supported on Linux Alpha.
Oh, almost forgot: They are FREE!
Enjoy.
Maurice W. Hilarius Voice: (778) 347-9907
In what way do you consider Solaris 7/SunOS 5.7, AIX 4.3, whatever the first 64-bit IRIX was, and HP-UX 11.0 not "fully functional commercial 64 bit operating systems"? (Throw in Red Hat, SuSE, etc. if you consider them "commercial".)
(I shall assume that "UNIX-compatible" was implicit; if that assumption is incorrect, throw OS/400 and OpenVMS in while you're at it.)
They probably got in the habit from System/360, following it up with S/370 and, after not bumping the number in the '80's, S/390, as well as System/3, S/32, S/34, S/36, S/38, and so on.
...and Solaris (unless Sun does something like making the IA-64 version not 64-bit), and, presumably, Monterey (the AIX bits of which, at least, could be 64-bit).
Linux is one hell of a lot more than just POSIX-compliant; it implements tons of stuff that isn't in POSIX but that's in other UNIX-compatible systems.
Given the extent to which systems "derived from UNIX", in the sense that, at one point, the code in those systems started out with code from AT&T, have diverged from that code base, I'm not sure I consider being "derived from UNIX" to be all that interesting.
I consider the "feel" of the OS, even if none of the code ever looked like AT&T code, more important, and, given that Linux's native API looks as much like that of other "UNIX-flavored" OSes as the API of any of those other systems looks like that of its compatriots, and that its command-line interface looks as much like that of other "UNIX-flavored" OSes as the command-line interface of any of those other systems looks like that of its compatriots (no noise about color ls, please, Interactive Systems had a UNIX-flavored system whose ls had a significantly different set of flag options than others - adding color to ls is a relatively minor tweak), I consider it to be a member of the same family as those OSes that, at one point in their history, had AT&T code in them - and more of a member of that family than OSes that offer UNIX compatibility in addition to a native API (you administer a Linux system in ways that look pretty much like the ways you administer other UNIX-flavored OSes; you don't administer an OS/390 system, or an NT system with Interix, or an OpenVMS system).