Slashdot Mirror
Compaq Hints At "Opening" Parts of Tru64
There've been more rumblings from Compaq concerning the potential to "open" parts of the Tru64 source code. Spokesfolks for Compaq talk a bit about Linux, and working with the Community. However, no word about a license, what will be opened, or anything substantial.
Linux runs on architectures other than i386, alphas included. That's the beauty of free software: If a program you want to use doesn't run on your OS or hardware you can port it yourself instead of whining that some corporation won't do it for you.
I'm typing this on a powerpc running the 2.2.15 kernel.
They have ported their C, C++, Fortran compilers; math libraries; debuggers; spike optimizing tool and other stuff too...
Comments also seem to indicate that they'd like to, if they could.
I'd like them to do so, too. Not only do they have good Alpha optimizations, but apperantly a lot of stuff that can be applied to any CPU. That would either make nice additions to gcc, or maybe a completely new compiler (based on DECs code, with enhancements taken from gcc, rather than the reverse).
Now that Intel has bought Kuck & Associates (makers of very fast optimizing compliers for C, C++, and Fortran), it would be great to see them open source at least parts of the technology. The standard library they use is proprietary to another company, though I suppose it could be replaced with libstdc++ (for instance, KAI could spend time completing and optimizing that code instead ot the propritetary ones). The basis behind KCC is a bit more anemable to creating front ends for other languages too, I think.
MS beats BeOS with a much shorter average uptime
134340: I am not a number. I am a free planet!
I've always wondered about the road Compaq was going to take w/r/t Tru64. Earlier, they had announced that the NonStop-series (the old Tandem boxes) were going to use Alphas, and the general assumption was that a modified Tru64 would replace the current custom UNIX on them.
The reasons to continue to support Tru64 on the AlphaServer series is becoming less and less - a vast majority of the neat Tru64 features are (or will be by Q4/2000) available on Linux. Performance is still in Tru64's favor, but that has mostly to do with the optimizing compiler and assembly-tuned system libraries.
In truth, I can easily see Compaq going the route SGI is going: abandon their in-house UNIX brand over a couple of years in favor of Linux, while insuring that there is a Tru64-compatibility layer in Linux.
One thing I'd be interested in seeing is if Compaq would release the Tru64 kernel as OpenSource, and try to build a complimentary kernel system. That is, modify the Tru64 kernel a bit so that it could be a drop-in replacement for the Linux kernel (so RMS could call it a Tru/GNU system! :-). I am aware that this would cause some problems (obviously, no Linux driver would work in a Tru64-based kernel), but I can't see that userland programs would object much at all. Compaq could get all the advantages of having complete Linux-compatible userland programs, and yet, we'd get a kernel that could take advantage of all of Compaq's nice HA and clustering stuff, which are considerably better than Linux (as in MUCH, MUCH better).
Honestly, as a previous poster pointed out, I can't see Compaq opening up their compiler technology right now (it's a major advantage against Intel. Who know what bubbles in the minds of Compaq Management? I certainly don't.
-Erik
There are always four sides to every story: your side, their side, the truth, and what really happened.
Compaq/Digital has long supported Linux development on Alpha platforms. They have provided hardware for development, ported FX!32 to Linux/Alpha to provide Linux/x86 compatablity, as well as helping out out with Digital Unix (now Tru64) -> Linux compatability.
All of this was done well before Linux was on any sort of corporate radar, and is the reason why Alpha is the best and first supported non-intel archetecture, and why Linux has been mostly 64 bit clean a long time.
That is not to say that they might not screw it up, but both Digital and the Alpha division of Compaq have a pretty good history of being suppportive of free software, and they deserve the benefit of the doubt.
Compaq has never released FX!32 for AlphaLinux to date. There is em86 which runs intellinux binaries in full emulation but it's nothing at all like FX!32 and no where near as fast. Q has ported spike to AlphaLinux. Maybe FX!32 is next?
--
www.alphalinux.org
www.alphalinux.org
it's just a matter of linking the foreign binaries against a different libc (or equivilent) that translates syscalls.
Perhaps, but that is not how Alpha/Linux does it. Linux on Alpha implements most of the Tru64 system calls natively. It also can load ECOFF images, permitting it to run Tru64 static binaries with no emulation code.
This system call compatibility was convenient: Linus deliberately made Linux system call compatible with OSF/1 during its early development, as a porting aid before Alpha/Linux was self-hosting.
Note that Tru64 still cannot execute Linux binaries simply because it lacks ELF support.
Wake me when one of these companies that open part of their OS either gets usefull revisions back from the communitie, or their newly open code is usefully used in a project that any users care about.
-- Superlame http://catpro.dragonfire.net/joshua/
Personally, I'm a really big fan of DUX. Mostly because of the amazing compilers and tools that come with it. I would love to see some of this open-sourced. I only hesitate to think that Compaq would release YAOSL (yet another open source license) onto the world.
--------- Beware the dragon, for you are crunchy and good with ketchup.
If Compaq would only make the "Open" in OpenVMS mean GPL, then there could be some more great code to borrow.
I don't think that will ever happen, especially since Compaq licenced whole chunks of OpenVMS to Microsoft, and they won't like the fact that everybody can have a peek at something they paid money for.
AFAIK, OpenVMS isn't written in C, so porting features would not be that easy.
WWTTD?
Actually, I think you'll find that while Tru64 may be years ahead of other Unix systems in clustering/failover technology, OpenVMS is still years ahead of Tru64 in these areas.
While I can't speak authoritatively, I believe that the Tru64 clustering is what OpenVMS had in 1987.
I do believe there is active work to bring the Tru64 clustering capabilities up to more current OpenVMS clustering capabilities, although OpenVMS is not sitting still in these important areas. If you are interested in state-of-the-art clustering, I direct your attention to the The Galaxy Architecture for recent developments in highly flexible clustering. Thi s document is a good overview of the highlights of shared-everything OpenVMS clustering, but it doesn't mention Galaxy.
In fairness to Tru64, it has some features that OpenVMS lacks, like the Logical Storage Manager, that certainly augments a cluster environment.
I also believe that there is a great deal more experience with IP failover and dynamic routing changes in the Tru64 environment vs. the OpenVMS environment. OpenVMS is quickly playing catch up in this area as the TCP/IP code base from Tru64 was recently ported over to OpenVMS and is the new standard there.
Let me anticipate the question about OpenVMS viability. OpenVMS currently represents nearly $4 Billion in yearly revenue for Compaq. This particular $4 Billion is perhaps some of the most profitable product business (as opposed to services), from a margins standpoint that Compaq has. Over 90 percent of the world's CPU chips are controlled by OpenVMS systems. Over 50 percent of the world's cellular phone billing systems run on OpenVMS. OpenVMS is rated #1 in health care. It's heavily used in banking, equity exchange markets and a number of other high availability areas such as lottery systems.
OpenVMS is here to stay. Get used to it.
-Jordan Henderson
hehe i would also like to get an alpha, problem is that x86 computers still have best performance/price ratio.
-- http://electronicintifada.net --
The article mentions that Q will be touting the fact that Tru64 is binary compatible with Linux.
How is this possible? Even if Tru64 uses the ELF format, there is still no way it can be binary compatible with an OS that runs on completely different hardware!
Did he intend to say source compatible, which is not too far fetched, as most Unix systems are source compatible with each other thanks to POSIX?
It's fine to bash MS for their faults, but please don't make up new ones. MS never released their Kerberos source in any form. They never claimed that it was open source in any way whatsoever.
A better comparison would be the Sun Community License.
AAGH! And I'm wearing a ski mask!
It looks like all the former Digital employees are behind this. Compaq doesn't seem to have a fucking clue about linux (try to find linux info for one of their PC's you'd buy at CompUSA), and the information is trickling from the old DEC employees. They have done well so far. That said, I hope Compaq makes the "right" decisions about how to handle this Tru64 thing. Linux could use the introduction of some Tru64 features. Honestly, I see their Tru64 sales declining steadily in the future, and Alpha/Linux installations increasing. It's already possible (has been for years) to run almost any Tru64 binary under Alpha/Linux. Incorporating Tru64 features to Linux and moving their UNIX division over to Linux would be a very strategic move for them.
--Bob
1^2=1; (-1)^2=1; 1^2=(-1)^2; 1=-1; 1=0.
Linux is monolithic. Tru64 uses a microkernel. Compaq used to let you try out their servers (a 30 day shell account) over at testdrive.compaq.com. Not sure if they still do it.
Digital would never have done this on their own, but now they're orphans in Compaq fighting for survival in the big bad consumer co, all the DEC unix boys are getting all open on us.
... some pretty nify machines. Real handy if you need some CPU cycles for free, say for inverting huge matrices (FEM-type stuff).
Remember OpenVMS still lives, barely. Lotsa big bad science people use 'cause its stable - when beamtime costs you millions an hour, you kinda want a stable OS. So (I beleive) being bought by Compaq has brought the Tru64 unix boys out of the closet. They can make suggestions and decisions now, in a way the old DEC culture never allowed them to.
Remember they have those nice testdrive accounts
So, oddly, Campaq buying DEC is turning into a good thing (TM). Eventually Tru64 may merge into the Linux or FreeBSD kernels, the same way IRIX and Solaris are slowly going.
Go Compaq Go!
get a clue
-- http://electronicintifada.net --
Back in the Good Ole Days of VMS, Digital made the source available on Microfiche. It cost something like USD$1000 on top of your right to use license, but at least it was available.
It taught me two important lessons.
First, source code availability is important. I found a number of bugs reading the microfiche, and that helped me find ways around the problems without touching the distributed code.
Second, without a good customer feedback scheme in place, having access to full source code and being able to recompile isn't worth diddly squat. I sent them a number of bug fixes, and not a single one was ever resolved in a distributed update. Thus, the whole "many eyes on the code" argument disappears in a puff of greasy smoke.
As an administrator of umpteen machines with umpteen/3 administrators, I want patches to be rolled back in the project -- whether that project is open source or not. If, for example, Squid doesn't implement a fix I suggest, I'm as bad off as when a commercial vendor doesn't fix a problem. Either way, I'm running with a workaround that may break after installing an upgrade to the code, possibly after I've left the company.
The bottom line is that it's not whether or not something is open source, but how they deal with fixes that counts.
The Squid thing was just an example, btw: my fixes to Squid suck :-)
Bert Driehuis -- All I asked was a friggin' rotatin' chair. Throw me a bone here, people.
Don't forget, everyone, that the Alpha was originally a DEC product. DEC was always populated by engineers of a more "research" bent, i.e. they never really left college - they just moved to DECs lab. From what I've read, DEC was in on the Alpha Linux port from the get-go. Stands to reason that they'd like to "get back in the game", even with the Compaq stuffed shirts running around pushing ProLiants.
BTW, I've used TRU64 on a DS10 - it's something of a RAM pig, but it doesn't stop for much, and it is a nice environment.
"Depression is merely anger without enthusiasm." - Anonymous
I wasn't talking about PC OEMs. I was talking about the lower end workstation OEMs like Compaq, SGI, IBM, and HP that have high end UNIX machines, but had adopted NT for its lower end, especially workstation lines. Moving to Linux for these machines gives these companies much more flexibility and power than if they had used NT. I know that sgi hated using NT for its machines, and I'm sure Compaq, IBM, and HP do as well. Also Linux allows a user to transition to a big-iron UNIX machine much more easily, if they are used to using a UNIX on the lower end machines.
A deep unwavering belief is a sure sign you're missing something...
What would be cool is if Compaq would contribute code to GCC, as for example IBM has done for the Power PC.
Compaq's CCC for Alpha has been specifically tuned for the various Alpha architectures. GCC works pretty well already (I use it all the time and have no complaints), but there are some examples where CCC produces better code. If Compaq would donate their Alpha backend, I'm sure some of those optimizations could be used.
I applaud Compaq for making their compiler and math libraries available for Linux, but it would be even better if we could see the source code.
P.S. No I'm not the same Dr. Tom
From the article:
There are several different types of clustering:
Although it's theoretically possible to build all these aspects into a single operating system, the practical issues of doing so are incredibly complex. While few operating system vendors have attempted to cover all the bases described above, one shining example does stand out in Compaq Tru64 Unix.
End of article snip...
If Compaq would only make the "Open" in OpenVMS mean GPL, then there could be some more great code to borrow.
I have the hobbyist Tru64 running on one of my Multia's, and I'm quite impressed with it. A very smooth install and nice CDE environment. Rock solid system, good response on slow hardware, and a filesystem that doesn't even need fsck after a power dip.
But I seriously doubt that Compaq would open up the most interesting bit: the Alpha optimizing compiler. That would be a great help to the `gcc` folks, but would also help Intel's IA64 (Itanium) compiler more than Compaq would stomache.
So maybe they might open up some parts of the kernel. This isn't trivial either and could definitely help out the Linux kernel developers.
5th ?
could someone post a ars type explanation or link to one on the specific differences between Tru64 and Linux.... Architecture and efficiency wise... thanks.
See, it works like this. Company A, let's call them Compaq reads something about this whole Open Source thing. They see a few things. First, a bunch of people to fix bugs in something they can't be bothered to fix, and they don't lose ownership. They just make up some horribly restrictive license ala Microsoft's Kerberos, and invite people to fix bugs for free, all the while claiming ownership of all things that come from it.
Now, admittedly, I haven't seen the license, but ten to one says this company acts like every faux-open source bandwagoneers that release code simply for marketing and to exploit a group of people who actually like to help each other.
The question is, we like writing free software for each other, because someone will return the favour and often we're scratching our mutual itches. On the other hand, are we helping anyone but the pseudo-oss'ers by fixing their bugs for free, and getting next to nothing out of it?
----------------- "I have a bone to pick, and a few to break." - Refused -------------------
Tru64 is a type of Unix owned by Compaq. If I recall correctly, it was developed by Digital, for the Alpha processor. That's if I recall correctly ... :/
This is yet another move from a major UNIX vendor that shows support of the Open Source movement. (As an aside, I am surprised people think that it shows support for Linux. They make no mention of the type of license that Tru64 will be under, and thus, there will be probably no way for the Linux people to steal parts of Tru64.) Many people could say that it is just Compaq jumping on the OSS bandwagon, but Compaq's other software efforts show that this is not so. They have ported many of their development tools to Linux, and have shown a general support of Linux on the Alpha architecture. Its move to abandon WinNT for Alpha plus its moves to support Linux show a general trend in the PC-class high end workstation market. In general, companies are trying to move away from WinNT on their workstations. SGI is doing this in conjunction with nVidia, and now Compaq is doing this. I believe it is because Linux offers much more freedom to the OEM about how they want their machines configured, and it also bridges the gap between the lower end PC-class workstations and the high end UNIX servers. I can predict that IBM will be making an announcement soon to run some of its workstations on Linux, as it has already done so much to beef up its support. SGI too, is probably not that far away from announcing a Linux based workstation with nVidia Quadro graphics and XFS support to replace the Visual Workstation line.
A deep unwavering belief is a sure sign you're missing something...