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.

3 of 40 comments (clear)

  1. Thoughts on Compaq and Tru64 vs Linux... by trims · · Score: 3

    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.
  2. Re:Binary compatability? by codealot · · Score: 3

    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.

  3. Not if it would help Itanium by redelm · · Score: 3

    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.