Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Compaq

Compaq Hints At "Opening" Parts of Tru64 40

Posted by Hemos from the could-be-maybe dept.
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.
This discussion has been archived. No new comments can be posted.

Compaq Hints at "Opening" Parts of Tru64 More

Compaq Hints at "Opening" Parts of Tru64

Comments Filter:
  • 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 [kai.com] (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

  • Thoughts on Compaq and Tru64 vs Linux... (Score:3)

    by trims ( 10010 ) on Sunday May 28, 2000 @02:38PM (#1041757) Homepage

    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

  • 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

  • Re:Binary compatability? (Score:3)

    by codealot ( 140672 ) on Sunday May 28, 2000 @12:51PM (#1041760)

    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.

  • I don't think thats ever going to happen and I'll give you one good reason. Tru64 has the BEST clustering/failover technology ever developed and it's been around the longest in that area as well. It inherited these capibilites from you guessed it , OpenVMS. Also Linux compatibilty could be achieved by porting glibc to Tru64. Then AlphaLinux binaries would be able to run on Tru64 with 0 modifications.
    --
    www.alphalinux.org
  • 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.
  • 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.

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

    • Tru64 has the BEST clustering/failover technology ever developed ...

    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 [digital.com] for recent developments in highly flexible clustering. Thi s document [digital.com] 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.
  • Yah, VMS isn't in C, I think it might be in Bliss in fact.
    But VMS is a wonderful example of a better mousetrap that priced itself out of the market. If DEC had made VMS, the layered utilities, and TCP/IP for VMS all free with the purchase of Alpha hardware when the Alpha was first introduced, Microsoft would be a bit player and Linux would probably still be a hobbyist toy.
    The VMS system I genned in 1990 is still running today with no crashes since that time. One SCSI disk (it's a 3100e box) burnt out, and the system had to be taken down for replacement - other than that it's been continuously up for 10 years.
    And even though VMS's file protection & ACL mechanisms aren't quite as clean as Novell's, their privilege and memory protection system is better (and we won't even get into the absurdly primitive rwx protection and all-or-nothing suid privilege mechanisms of Unix-derived systems). VMS could've ruled the world, but the same DEC management drones that tossed Ken Olsen out on his ear flushed the corporation down the toilet with their small-minded policies and failure to protect and market key hardware technologies.
    --Charlie
  • 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?
  • They just make up some horribly restrictive license ala Microsoft's Kerberos

    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.

    /peter

  • Re:you've been caught! (Score:1)

    by Anonymous Coward
    AAGH! And I'm wearing a ski mask!
  • I diagree strongly. Thus far, Compaq/DEC has been very forthcoming with porting their software to linux. They have ported their C, C++, Fortran compilers; math libraries; debuggers; spike optimizing tool [compaq.com] and other stuff too. Comments in these things seem to indicate that they're under license agreement for pieces of the code from other companies, and cannot easily open soure their whole compiler, for instance. Comments also seem to indicate that they'd like to, if they could.

    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

  • Not only as mentioned 5 or 6 times does Linux run on Alpha, but at one point Digital released a port of the FX!32 emulator for Linux, allowing Linux/Alhpa to run Linux/intel binaries. I don't know how good it is, or how well supported, though.
  • 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 [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.

    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 ... some pretty nify machines. Real handy if you need some CPU cycles for free, say for inverting huge matrices (FEM-type stuff).

    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
  • About your sig. BeOS boots up in 12 seconds, so sucks to MS.
  • 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?

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

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

  • 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.
  • The reasons are less and less to use Tru64 Unix over Linux? Do you have a clue? Tru64 Unix beats Linux hands down in performance, scability, security, and clustering. There isn't much Non-Stop with Linux.

  • CCC (Score:1)

    by Dr. Tom ( 23206 )
    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

  • Actually, this is a reply to the two previous responses...

    Yes, I am fully aware of the great clustering & HA setup for Tru64 - I've worked with it extensively. The clustering tools require the Tru64 kernel, which is why I suggested that they might explore using the Tru64 kernel as a drop-in replacement for the Linux kernel. You'd be able to use the clustering software already written for Tru64, and get the neat features it provides.

    Also, porting glibc to Tru64 doesn't give you Linux compatibility. It's already ported to Tru64. Compatibility has alot more to do with things other than the C library.

    The problem for Compaq is that maintaining the Tru64 system as a whole is alot of work. And I mean ALOT of work. If they could concentrate on their kernel and the few places they make really excellent add-ons (the HA stuff being the primary), they could save alot of $$. Pawn off all the non-interesting userland tools to the OpenSoftware folks.

    Also, Tru64 doesn't make alot of sense on the Alpha workstations - a small improvement in Linux gives you the performance of Tru64, and you're not going to be using all the neat features of Tru64 on an AlphaStation anyway.

    Like I said, but perhaps not clear enough, Tru64 make alot of sense on the NonStop stuff right now. It also make sense on the high-end AlphaServers. It makes no sense on the AlphaStations, and I think Compaq could save themselves alot of cash, and make alot more by concentrating on making a hybrid Linux/Tru64 system for everything but the NonStop stuff.

    Look at what SGI is doing - Compaq could learn from them.

    -Erik

  • In this article, When will comprehensive clustering for Linux arrive? [linuxworld.com] Rahn Shaw of LinuxWorld discusses various aspects of clustering.

    From the article:

    There are several different types of clustering:

    • Parallel computing: Beowulf is one example of the parallel-computing cluster, executing parallel applications written for libraries like the Message Passing Interface (MPI). Used mostly in scientific computing.
    • High availability: Dedicated to maintaining a high level of overall system availability, these clusters replace failing nodes with backup nodes as quickly as possible, so that in the worst case a node failure only creates a few seconds of downtime.
    • Load balancing: To improve overall system performance, the load-balancing cluster shares the application workload of all system users across the nodes of the cluster.
    • Resource sharing: This kind of cluster combines system resources into a central system or service so they can be accessed by all nodes of the cluster or by other computers.
    • Single system image: Here, the operating systems of several nodes are combined in a single system, so that it appears that all the users are running on a single large machine. This can ease system management and make it simpler to run applications for load balancing.

    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.

  • Not if it would help Itanium (Score:3)

    by redelm ( 54142 ) on Sunday May 28, 2000 @10:46AM (#1041784) Homepage
    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.

  • I think they mean True64 is binary compatible with Linux Alpha not Linux i386

  • Re:Binary compatability? (Score:1)

    by Anonymous Coward
    Um, perhaps you've been asleep in a hole for the past several years (or perhaps you're a troll that eluded the moderators), but Linux runs on Alpha hardware. (Compaq will even sell you alphas with RedHat preinstalled.) Presumably, Tru64 will run RedHat/Alpha binaries.
  • 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?
  • 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 ... :/
  • linux x86 != linux

    linux is available for at least 9 platforms (ppc, x86, alpha, sparc, s390, m68k....)

    linux alpha is second most used port of linux, right behind x86. i believe that alpha was first non x86 platform that linux was ported to.
  • linux has been running on alpha for YEARS (and ppc, sparc, etc). binary compatibility is not difficult on the same cpu. it's just a matter of linking the foreign binaries against a different libc (or equivilent) that translates syscalls. you really must live in a cave if you think linux only runs on x86 (god what a horrible arch).
  • 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.

Slashdot Top Deals

Happiness is twin floppies.

Close