Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Compaq's Tru64 may include KDE, GNOME, RPM 126

davie writes " Jon Hall, leader of Compaq's Unix Group, said Compaq is porting its compiler suite from Tru64 to Linux, and will ship extended maths libraries under the open source General Public License. But Compaq is also considering adopting the software installation software Red Hat Package Manager, and the Gnome and KDE desktop environments in Tru64 Unix. The story is worth reading. "
This discussion has been archived. No new comments can be posted.

Compaq's Tru64 may include KDE, GNOME, RPM

Comments Filter:
  • by Anonymous Coward
    After that NT-is-much-better-than-Linux FUD on M$' site, this is refreshing.
  • by Anonymous Coward
    Aren't these the DEC Digital UNIX compilers? Porting them to Linux/Alpha isn't a large problem, as the assembly output is the same in general. Taking those compilers to Intel would get them nothing as they'd have to rewrite them from scratch.

  • by Anonymous Coward
    But deb is better, and some of us care more about technical merit than politics.
  • by Anonymous Coward
    FX!32 was the end of Native application developement for AlphaNT. I've lost count of how many vendors I've tried to get to port their software over to the platform and then they give me "You can run it under FX can't you?". It was the worst thing that could have ever happened to the platform. It's a different arch and should be treated as such much like the powerpc/mac's. Do you see them whining about intel compatibility?
  • by Anonymous Coward
    FreeBSD CAN NOT run Linux software on the Alpha. I asked Jordan Hubbard about this at Linux World Expo and he said no. He went on to say that he hoped compatibility with Digital Unix would come first. It looks like FreeBSD is locked out for the present.
  • by Anonymous Coward
    Could you please tell us why deb is supposedly better?

    I've seen the claims again and again, but no solid arguments.

    For instance, have deb proven to be more portable? Mor stable? Easier to use? Why?

    As for RPM, in this case RPM has proven to be very portable: it runs on a heap of different platforms under Linux, but it also runs on Solaris (and works well), HP-UX, SCO OpenServer, SunOS 4, AIX, NCR v2, and, and here you might have the reason for Compaqs choise: It already runs under Digital Unix/Tru64 3.2/4.x.

    It's been ported, and it has been tested on the platform already.

    Just face it, if deb is in some way superior, at this point it would be better to explain why to the people doing RPM development, and try to get them to add those improvements to RPM. It is far more widespread, being used by lots of distributions, is portable, and is the defacto standard for almost anyone but the Debian and Slackware crowd.

  • According to this Deja News article em86 is no longer supported. This seems a pity.

    Was it ever? I thought it was unsupported from the outset, like most of Alpha/Linux. It still works, albeit with some hacking, on RH6/Alpha.

  • Cool, then you'll have made BSD/Linux, and proved the point.
  • I think they meant "free software General Public License." Somebody needs to do some research before writing articles.
  • No.

    X is a windowing system. It is not part of the OS. A Linux box can run perfectly fine without X. It cannot run perfectly fine without libc.

    The Mozilla and KDE comment was even more ignorant, as those are obviously just applications.
  • Maybe you should too. The full name of the GPL is the GNU General Public License. No "open source" or "free software" anywhere. So in other words: They likely meant "open source" as a qualifier to explain that the GPL is an open source licens (which is true).

    I am well aware of the fact that "open source" was used as a qualifier. However, the proper term to use as a qualifier is "free software," as the GNU GPL is a Free Software license. It is not related to the Open Source Initiative, and the Free Software Foundation has never even sought OSI certification of the GNU GPL as an Open Source(tm) license.
  • You're missing the point. Tru64 will still be Tru64, a complete OS on its own. GNOME and KDE will merely be window managers (not part of the OS), and RPM isn't even a FSF project.

    Linux, on the other hand, is not a complete OS on its own. You can boot Tru64 by itself. You cannot boot a kernel by itself.

    The GNU OS will be an OS by itself as well. For the moment, it's missing a kernel, so you can use the Linux kernel as a replacement, making a GNU/Linux hybrid OS, or "GNU OS with the Linux kernel."
  • Amen...

    I've got Gnome and E running on RH6.0 and it is pretty and functional (and mostly stable). The
    design of Gnome seems to follow the unix `tool' model and GTK looks a lot better to program than

    I sat, I stared, I popped a bottle of wine and drank to the well deserved death of CDE/Motif,
    though few will mourn their passing. The sooner the unholy pair are purged from the earth by a
    superior and free alternative the better. These tools have held the unix desktop back more than
    any other single influence.
  • They do produce a very good Fortan compiler for Intel, though (Compaq Visual Fortran), but that only runs under Windows...
    According to Steve Lionel (DEC^H^H^HCPQ Fortran guru) in a posting on comp.lang.fortran at about the time DEC introduced their product for Windows, they keep a common code base which conditionally compiles for VMS, OSF (now Tru64), and Windows (both x86 and Alpha). In fact (later Lionel post), that's why the version 5 of DVF did it own transcendental functions instead of using the built in x87 hardware intrinsics. (IIRC, DVF6 now _does_ use x87 intrinsics).


  • There is a blow by blow at [].

    The user advantages of .deb include:

    • suggested and recommended packages--- these are great when you don't know much about what you are installing
    • easy of upgrade--- the system can automatically compare itself to the ftp archive(s) and update any out of date software.
  • Right now wine only works on x86. The Wine concept CAN theoretically run on Alphas for Alpha NT binaries, but that could be a lot of work patching stuff over. I don't know if anyone's going to do that until Wine stabilizes.

    I have more interesting fish to fry.

    I suppose someone could improve Bochs' performance. That might be a better option for non-x86 (except possibly Alphas, but see above).
  • The version of FX!32 they did for Linux (em86) doesn't include the dynamic recompilation technology, it just has the x86 interpreter. That's why it's so slow.

    According to this Deja News article [] em86 is no longer supported. This seems a pity.

    Of course a version that worked with Wine to run x86/NT programs would be cool, but I rather doubt Compaq would want to release their FX!32 technology. They have worked on it for years, and it looks like they are better at it than anyone else. Intel needs something like this for McKinley (according to rumour it has no hardware support for x86 code), and perhaps even for Merced if the rumours of poor x86 performance are true.

    I guess they could just rely on a combination of NIH [] and the GPL to stop Intel using it.

  • vim is the most non-standardscompliant piece of crap i've ever seen.

    What is it about editors that gets everyone so emotional that they forget how to use the shift key?

    Personally, I don't care so much about standards in an interactive app like an editor. It feels like vi, only much better, to an old vi fox like myself.

  • I was talking more about the code, not really about the name. I was using 'Linux' to mean the stuff you usually get in a Linux distro. I have some sympathy for the GNU/Linux stuff, I'm just too lazy to use the phrase myself.

    Not wanting to ruin RMS's decade, or anything

  • the math libraries will be open but the compiler will be a linux only binary.

    Should be possible to get it to work on the BSDs, then. They seem to have Intel executable support, so unless the compiler license specifically forbids it (why should it?) there should be no insurmountable problems.

  • And you can easily add a non-GNU shell, and voila, you have a running Linux based OS without GNU tools.

    Sure you could easily add a non-GNU shell. what compiler would you compile it with? Which C library would you compile it with (hint, all versions of libc for Linux are based on GNU libc). Which termcap would you link to?

    You seem to think that Linus wrote the kernel, and then there just happened to be available all the free tools necesary to make a free OS. The reason why all the bits were just there as if by magic was that the GNU project [] had been adding them, filling in the gaps in the available free software until all there was missing (or rather late) was the kernel [].

    Do you think the GNU people wrote a C library because it was the most exciting free software project they could think of? I'm sure they would have had more fun writing the LISP-based windowing system they originally planned [], but if they had done that we would have had two windowing systems (with X) and no C library. Ie we would not have had Linux distributions.

    I can quite understand RMS's frustration that everyone thinks the entirety of the Linux system appeared out of nowhere as soon as Linus wrote the kernel. Probably changing the name isn't the way to raise awareness (gets too many people's backs up, and noone can be bothered with as clumsy a name as GNU/Linux) but I don't know what is.

    For those old enough to remember the Yggdrasil distribution (my first) it was labelled Linux/GNU/X. Can't quite remember the order, though I still have the CD somewhere.

    And of course what all the above means is that noone would want to call the combination of Tru64 and a lot of free stuff GNU/anything. To suggest otherwise (even as a joke) is to misunderstand totally the motivation behind the GNU/Linux name.

  • AFAIK, Intel binary support is available only in the *Intel* ports of *BSD.

    Could be, I am not familiar enough with the BSDs

    There is *no* way to run Linux/Intel binaries under *BSD/Alpha

    Sorry, I messed up. I wrote that the BSDs have Intel binary support. What I meant was that they have Linux support. Clearly the GEM compilers are Linux/Alpha applications, so, what is needed here is a way to run Linux/Alpha (not Linux/x86) binaries under BSD/Alpha.

  • by Erik Corry ( 2020 ) on Friday May 14, 1999 @06:53PM (#1891305)
    I've been wondering for a while why the big Unix companies don't do something like this. Ship most of a Linux distribution, but with their own compilers and kernel (and whatever else they feel they are good at). It lets them ship a nicer set of tools and GUI than they do at the moment and at the same time they can concentrate on their strengths.

    It would save a lot of trouble for people who get new Unix boxes and have to spend a lot of time upgrading the tools to the stuff Linux has as standard. When you are used to Linux, 1000 little things about the big Unixes will irritate you. Like the useless versions of vi that everyone else ships, the bizzare packaging systems (none of them as good as rpm or dpkg) and the fact that that the up key just produces a set of escape codes on the screen in their shells. If it's so difficult to get right, why don't they just ship vim, rpm and bash?

    Here at my University they already use rpm for all the commercial Unixes, and it seems to work fine.

  • What's the "open source General Public License?" A separate license, or corporate speak for "free software?"
  • I think this is a MAJOR win for Linux and will benefit all (maybe except M$). The neat part is that like SGI they will "Give back" source code adding to the snowball.
  • by Glith ( 7368 ) on Friday May 14, 1999 @07:14PM (#1891309)
    I can see it now:

    HOUSTON, TX -- Compaq officials rescended their idea of shipping with GNOME and RPM after receiving a threatening letter from the FSF which insisted that they rename their product to GNU/Tru64 to "give credit to the FSF project". Officials were unavailable for comment.

    Hmm... maybe not :)
  • AFAIK, Intel binary support is available only in the *Intel* ports of *BSD. There is *no* way to run Linux/Intel binaries under *BSD/Alpha, and even if there was one (like an em86 port to *BSD), it would be slower than native binaries.
  • I would compile the non-GNU shell with lcc and use the newlib C library (which is BSD-licensed). Termcap is even easier (from BSD).

    Don't be so ignorant - the GNU tools were handy, but not necessary, as NetBSD/FreeBSD proved (except gcc for the kernel, but if it hadn't been available, something else would have been used).

    Just because Linux was GPL-friendly from the beginning, it doesn't mean that it wouldn't exist without GPL'ed software.

  • Oops. I meant, "I NOT trying to bait anyone..."


    -Paul Iadonisi
  • Um, not start a YAFW, but could someone please tell me WHY dpkg is supposedly better than rpm. I've been doing quite a bit with rpm lately and find it quite incredible. I have not, however, had any experience with dpkg and would like to see a point-by-point comparison. I'm trying to bait anyone, or anything, I seriously want to know.

    On the topic at hand, I think this is awesome! I was just saying this morning (but only joking) that CDE is dead now that GNOME and KDE are here. Now, if the other *nix vendors would just follow suite, we'd all have a FREE desktop.

    -Paul Iadonisi / Consultant
    Collective Technologies
    Team Yankee, Local Linux Lobbyist
    Ever see a penguin fly? -- Try Linux.
    GPL all the way: Sell services, don't lease secrets

    YAFW=Yet Another Flame War
  • You can boot a kernel, you just couldn't do anything with it (or build it for that matter).
  • hmm? what standards worth being complied with does vim fail to follow? if you don't have a .vimrc it sets a lot of options to their vi-like settings. if you're missing something specific, I suggest you mail it to the vim developpers.
  • nah, it's not linux 2.3.1 that will seal bsd's grave.. the BSD people are competent enough to pick up the enhancements too. I can see maybe one of the BSDs going away from lack of interest in a few years, because having 3 of htem is a bit too much for the number of people interested.. but otherwise my guess is that BSD development will continue indefinitely, just like that of Linux.
  • "What the hell" I said (yeah I really talk like that!)
    tsk, tsk.... you shouldn't talk like that! say "what the fuck" all you want, but not "what the hell"!

  • I don't know why they *wouldn't* port FX!32 to Linux. After all, a Linux/Alpha user is one more Alpha box sold.
  • vim is the most non-standardscompliant piece of crap i've ever seen. Use nvi.
  • by Graymalkin ( 13732 ) on Friday May 14, 1999 @07:10PM (#1891321)

    I think it's great that Compaq and SGI are starting to play nice with linux, it gives the rest of us a nice boost in support. But it shouldn't be world domination, just give everyone (not just geeks) a M$ alternative. OpenBSD, NetBSD, FreeBSD, Solaris, IRIX and half a dozen others can all do things linux cant, or do some things better. OpenBSD has über-security, NetBSD is rather portable and so forth. Linux can also do things better then all of them or some things they cant (like work the first time I install it unlike FreeBSd which didn't like my computer for whatever reason). What I hope happens is the companies that support linux add some of their features to linux, stuff they are good at. A journaling file system, better SMP support, ect.. I think that would lead to linux becoming a better all around OS, while still allowing for plenty of other operating systems. Heck, even MacOS and Windohs have their good sides. MacOS is obscenely easy for new users ad makes everything fluffy and cute while Windows drives more people to use unix.

  • I can't help but feel that Compaq is making a big mistake by adopting RPM for Tru64... of course, the irony here (unlike the VHS/Beta thing) is that both alternatives are equally cheap to license, so choosing the technically superior solution should be a no-brainer.
  • Well, 'setld' might not be what users expect today but remember that it stems from Ultrix-Days where others still were using tar/cpio to install SW. Not to talk about deinstalling / upgrading the once installed SW.

    Maybe DEQ forgot to adapt it to todays standards though. And after all: why not gather around a reasonable packaging standard like RPM for all those UNIX-like environments? Arguments like ".deb is so much better than .rpm" are rather a waste of time: if Linux helps to unify UNIX then this is a good thing. If it comes for free, the better!

    My 5 cts.

  • Didn't the Gartner Group "thin server" study compare FreeBSD with Linux 2.0? Unfortunately, the Gartner Group study is no longer online (according to I would bet Linux 2.2 would be (almost?) as fast as current FreeBSD.

    FreeBSD may be faster now, but Linux is getting better faster. With millions more people using Linux, it has reached a critical mass FreeBSD never will. How long until Linux surpasses FreeBSD's networking performance?

  • Referring to Ghandi's saying, adopted by Linux fans -- "First they ignore you, then they mock you, then they fight you... then you win" -- Hall said, "Everybody except Microsoft has got past the fighting stage."

    Well, almost everybody but Microsoft, but it's still a nice quote.

    And it only took about a year from the time Linux first came onto the Big Boys' radar screens.

  • I know that Compaq are porting their f90 and c++ compilers to Linux/Alpha, but are they planning to do the same for Linux/Intel?
  • Ah yes, I didn't really think about the fact the story only mentioned porting their unix compilers. They do produce a very good Fortan compiler for Intel, though (Compaq Visual Fortran), but that only runs under Windows...
  • Great but I hope they mean to make the libraries LGPL'd, otherwise you can't compile other than GPL with them or are they used for something completely different ?
  • As far as I know, they don't make any compilers for an x86, so there is nothing to port. If they try to port their alpha compiler to x86, it would be a waste cuz their compiler is designed specifically for the alpha.
  • I hope they port to the *BSD alphas as well.
    I'd hate to see this under BSD linux emulation.
  • First SGI then Compaq, this is a real stream of good news. Linux is now heading quickly to world domination. Now if Compaq and SGI could subsidize a project like Wine by devoting some developers to this project, that would be really great, and in less than one year, bye bye M$
  • It's great that Compaq has realised that Motif/CDE is a dead technology. Hopefully this will result in greater acceptance of either KDE or GNOME as the standard GUI for commercial Unices as well as Linux. It would be teriffic if big-name commercial *nix applications used Qt or GTK and offered KDE/GNOME integration, instead of the bloated, statically-linked Motif apps we generally have to put up with now. Hopefully other vendors will follow suit.
  • see Wine/About []
    "Wine freely redistributable. (The licensing terms are similar to BSD.)"

    >...Wine to run x86/NT programs would be cool, >but I rather doubt Compaq would want to release >their FX!32 technology.

    If the licencse is BSD-like they should not have to release it. :)
  • I don't know, and please stop filling up Slashdot with this mindless drivel.
  • Well, there was the FX!32 package from DEC that let NT/Alphas run NT/i386 binaries by doing a binary conversion ahead when you first ran the program and then storing the translated program for later use. This was maybe 1-2 years ago that i heard about it. They boasted performace of better than PII 266 on their 500MHz 21164 machines.
    They later moved the tech to Linux/Alpha to let people run Linux/i386 binaries. I remeber running netscape for linux/i386 on my old Alpha station, but it was REALLY slow.

Somebody's terminal is dropping bits. I found a pile of them over in the corner.