Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Compaq Readies Solaris-Linux Migration tools 39

Posted by Hemos from the beginning-of-the-porting dept.
stereoroid writes "LinuxGram is reporting that Compaq has nearly completed the Solaris Threading Library (STL), a set of tools that help Solaris developers port their applications to Linux (White Paper here). I suppose that when it's ready, it'll appear on opensource.compaq.com alongside the Linux PPTP drivers and the "Single System Image" Linux Clustering system they've been working on.
This discussion has been archived. No new comments can be posted.

Compaq Readies Solaris-Linux Migration tools More

Compaq Readies Solaris-Linux Migration tools

Comments Filter:

  • Re:Anyone want to migrate to Tru64? (Score:5)

    by Anonymous Coward on Wednesday June 20, 2001 @03:23AM (#138660)
    It's a shame, as Digital UNIX (True64, whatever marketing calls it) is the best UNIX I've used for production systems. DEC was doing real clustering and journaling filesystems long before any other UNIX I used (SunOS, Solaris, HPUX, AIX, IRIX, BSD, Linux). I used to run (not by myself, of course) the Ziff Davis shareware FTP side, which was a very high volume site that was unbelievably stable on a Digital UNIX cluster with a StorageWorks RAID rack. My personal theory is that they applied the robust VAX/VMS engineering to UNIX. VMS, while it's own little proprietary world was a nice place to live. Digital UNIX brought that product quality mentality to an open (as in UNIX) system.

    The possible upside would be if Compaq decided to contribute that crunchy goodness to Linux the result would be wonderful. Linux is a great platform, but it's not as mature and robust as the high-end UNIX platforms, and Compaq could go a long way to addressing that. It's pretty deep work, though, that might require fighting some serious kernel battles in order to properly support clustering at the thread level. It's amazing to hot-plug a new machine into a cluster and see load migrate transparently onto the new box.
  • ...and may take a long time to complete: according to their paper here [compaq.com], the port to Linux is not finished since "Problems with thread suspend and continue have been encountered, and are as yet unresolved".
    It is no easy task, because the handling of SIGSTOP and SIGCONT under Linux does not follow POSIX. Hope they'll succeed anyway.
  • I guess you'll have to be a little quicker
    next time, Sparky.

    -Kevin
  • DEC TRU 64 is leaps and bounds ahead, err was I suppose as development seems to have nearly halted, of any unix I've ever used. The alpha hardware ROCKS. DEC marketing is the WORST in the world. They got bought for a nickel by Compaq and screwed horribly. A friend is a CE for DEC (COMPAQ) and is being pushed to drop TRU64 and VMS and get M$ training, as if the world needed another MC$E....
  • so I guess I'll shut up until I learn some more. I was judging it by the amount of commercial software available, and my buddies' experiences within Compaq. Hopefully I will learn differently
    in the near future.

  • Re:STL? (Score:1)

    by PD ( 9577 )
    If your STL is from SGI, or based on one from SGI, then you are OK. The GCC STL is OK too. Only worry if you have the HP STL. That's a problem. Of course, MS uses the HP STL. WTF?
  • The other thing is that this could greatly benefit Java performance on Linux, since the current threading model is something of a handicap. I checked out Allen Holub's "Taming Java Threads" session at JavaOne, and it was quite an eye-opener. Basically, you're always using threads in Java, whether you notice or not, so being able to use Sun's threading model on Linux Java would be sweeeeet.
  • Why is it that a site with "linux" in the name has the annoying problem where their quotes display as question marks? Have they even viewed their own site on an open-source platform? I'm disgusted.

    --
  • Who cares what time it was submitted? The
    category is "redundant", not "copied from another post"

    In other words, redundant should be applied if the information content of a comment is a subset of another comment.

    Now, if you had mentioned the fact that the above comment actually is NOT redundant by this definition (since it includes a link to the SGI STL library), then you would have been making a valid argument.
  • I was agreeing with your conclusion.

    Not the reasoning you used to reach it.

    A key difference.

    (I can't believe I'm replying to an A.C. That's really sad. I mean, who are "you" anyway...)

  • It's not like there is much difference between Solaris code and generic UNIX code for the majority of applications. Since Solaris has POSIX Threads libraries too, wouldn't be a good idea just to recode your application to use pthreads (and thus allow it to run on AIX, *BSD, ...) rather than extend the life of an old API?

    The wite paper hints at differences between the APIs that may make porting complicated, but in 98% of cases i'm sure the hastle is minimal.

  • Tru64 "development nearly halted????" What kind of crack are you smoking? Tru64 is in extremely active development and if you have ever been to a DECUS show you would know that. Tru64 has the best clustering of any Unix. That is vitally important to both availability and performance.
  • Sorry about the crack crack. Tru64 and Alpha development certainly was slowed a little by the uncertainty caused by the Compaq takeover. And you are right that there are fewer packages available for Tru64 than HP/UX or Solaris. But Tru64 is finally getting noticed in the industry as still being worthwhile (Celera uses Tru64 on Alpha for their Human Genome project). I believe your buddy's experience too, but its probably from a couple of years ago, when faith that Compaq would keep doing its own Unix was low. Back then the management only understood PCs.
  • Why in the world would they call it STL?

    Maybe people will get confused and think about some other popular library [sgi.com]?

  • Re:Anyone want to migrate to Tru64? (Score:5)

    by bgarcia ( 33222 ) on Wednesday June 20, 2001 @03:16AM (#138674) Homepage Journal
    And if you would have read the linked-to white paper [compaq.com] instead of just spouting your ignorant reply, you would have read:
    STL was originally developed as part of the Solaris Compatibility Libraries (SCL) [5] for the Compaq Tru64 UNIX operating system. SCL was developed to ease the porting of Solaris applications to Tru64 UNIX.

  • Actually they have a full binary translater & emulator that will run your SunOS apps on Tru64.
    It's called Freeport express. I don't think it's been updated in a while though. They probably do have solaris migration kits you just have to look.

    Peter
    --
    www.alphalinux.org

  • Yes, Compaq is indeed following IBM's [ibm.com] lead.

    IBM has already developed porting libraries to allow Linux software to be recompiled on AIX. Looks like we're at the beginning of a trend by the major UNIX players to offer "easy migration paths" to their commercial products.

    I have to admit, this is not the method of the IT industry's acceptance of Linux I had in mind.
    --
    Steve Jackson

  • STL is old news, we do it every day.

    I'm still waiting for FTL travel.
    ---
    Interested in the Colorado Lottery?
  • Ack. Sun threads are very different from posix threads. The expected behavior is fundementally different. I'm sure any port would toss dozens of bugs.
  • You are right that my rationale was misguided. However, QA's testing matrix just doubled with the addition of linux as a platform. And there really is no such thing as linux (i.e. RedHat 6.2, 7.0, 7.1, Debian, etc). So sympathies should still be extended to QA, just not for the reasons it stated.
  • I have to admit, this is not the method of the IT industry's acceptance of Linux I had in mind.

    We OS/2 users welcome you to the club!
    --
    Lord Nimon

  • Locus Computing (which doesn't exist anymore.) had a technology called Locus TNC. When I was still at Intel doing supercomputers, we used this in the Paragon MPP system to do full SSI. (We did it across hundreds of nodes.) If you notice on the Compaq SSI web page, one of the principles is Bruce Walker who was one of the architects at Locus when I was involved with them. (I never dealt with him personally.) There is a fairly old book describing Locus TNC which was published through MIT Press called The LOCUS Distributed System Architecture by Popek and Walker. It worked fairly well but we never implemented any of the availability or reliability ideas that were kicked around.
  • I was on the team that developed Freeport Express. That was a few years ago, when Sun was making the transition from SunOS to Solaris. Currently Freeport Express only works on SunOS executables, and there are currently no plans to re-target it for Solaris. In other words, it is of limited utility today.
  • Slightly offtopic, but....

    DEC had journaling in Ultrix? I don't know, because I never adminned any Ultrix boxes, but AIX has had journaling since at least 1991-92, possibly earlier.

    I've adminned boxes from every major player and I'd still take AIX over any of them. $0.02.

    sedawkgrep
  • DEC isn't a company, it's a virus that nearly killed Compaq when it infected itself. I've always gotten the impression that DEC managed to succeed (I use the term loosely) solely on its product merits; its management has always come off as being somewhat clueless and idiotic. (I live in the Boston area, so reports of Digital layoffs have always been commonplace events to me.)

    I've never thought especially highly of DEC; I sort of always put them in the same broad category as Apple for a company that made excellent products but can't quite be trusted. The main difference: with Apple it's always been virulent egotism (especially under Steve -- being a Mac fan at the dawn of the 21st is a rollercoaster), but with Digital it was always abject and inexcusable cluelessness (viz. Ken Olson's comments about Unix vs. VMS and DEC's failed first entries into the PC market).

    I actually have somewhat more respect for Compaq now that they've started to get some of the DEC toxins out of the system while still maintaining DEC's R&D rep. But I still wouldn't buy one of their systems new -- their home systems are ugly, their business systems are just sort of cheezy-looking (except for those workstation cases -- silver and black with Jenna Jameson-level sex appeal) -- even worse than IBM's VogonBoxen. (I do have an old Compaq Prolinea, a system so dumbed down that I've had a love-hate relationship since the day I bought it for $90 heavily used, but it's been retired.)

    I do think they could do a little better in the TLA department, but it's nice to see something like this. It's the kind of thing open source should be -- at least if there's bloat it's cool bloat.

    /Brian
  • Solaris is an enterprise-level system. Linux started on the desktop and hasn't grown to that level yet. I'm not saying it won't, but it's not there yet.

    But there is a logic to this -- essentially Compaq, being somewhat back of the pack, is hedging their bets on the possibility that Linux will attain enterprise respectability. At the same time they know it won't be much of a profit center for them, so they're open sourcing it.

    /Brian
  • Does Compaq produce a similar migration kit for moving from Solaris to Tru64? They really don't seem to give a crap about Tru64...hardly any mentions of it in the media or around the Compaq site.
  • Speaking of ambiguity of acronyms, did anyone catch this one? SSI = "Single System Image" != "Server-Side Includes"
  • Compaq is believed to be worried that IBM will come to own the Linux market and that it'll be nosed out so it's planning on raising its Linux profile.

    After my visit to Linux World in New York, I was a little afraid of IBM's sudden interest in Linux and the amount of money they were about to invest into Linux solutions. But hey: if this means Compaq is going to raise their Linux profile, that's fine with me.

    It will also participate in Oracle's Linux Lab to optimize kernel development and performance.

    Ok, now given that a Solaris Threading Library probably wasn't on many Linux user's wish list, Compaq's plan to help in optimizing the Linux Kernel for SMP systems sounds like christmas to me.

  • STL? (Score:4)

    by KevinMS ( 209602 ) on Wednesday June 20, 2001 @03:05AM (#138689)

    They couldnt have chosen a more confusing acronym. The question on my mind is: is the STL compatable with the STL considering that most implementations of the STL are not thread-safe???
  • and the "Single System Image" Linux Clustering system they've been working on.
    Yahooo!!!!

    Caldera must be sick about this!

    Well, they've just made sure that my next system is Linux. Sorry FreeBSD, vinum was nearly enough, but NSC is the hard stuff!

  • Maybe Sun will start posting how to port your AIX app to GNULinux, and IBM will post a 'Guide to Migrating your Tru64 app to GNULinux', etc.


    It's easy to write songs, you just sit down and write them?
  • I too attended that session, it rocked!
  • POSIX threads are *slower* and the API is a bit more kludgy, so if high performance and a slightly faster development cycle is more of an issue than portability then you code for Solaris threads.
  • Interesting. The company I work for is going the other direction in porting. Our server product started on Windows, was ported to Linux, and I'm now finishing a port to Solaris Intel and Sparc.

    This seems a more natural progression to me. Most Linux implementations are Intel-based, so it was a clearer path to step to Linux first (porting to POSIX APIs), the Solaris Intel (relatively few changes for SunOS), then to Solaris Sparc (little-endian/big-endian changes, word boundaries).

    We also seem to have more demand for the Solaris port because Linux users prefer GPL/free software.

    But the article did say it was targeted for existing Solaris apps, so obviously I'm looking at it from a different angle.

  • Except there is more to a threads library than
    renaming its functions!

    Solaris has a posix wrapper anyway and already
    had a tool to help move from Solaris thread
    naming to posix thread naming. ie users could
    have moved to other posix threads libraries years
    ago.

    The real issue is that Linux threads become
    highly unpredictable above even 50% of the
    old maximum of 1024

    Everyone knows that. My prediction? We will see
    a media attack by SGI/Intel/IBM on Linus to
    accept their new threads library before the
    year is out.
  • What do you mean they aren't thread safe. THe only problem I've had is with string on SMP intel based machines.
  • When reading this, I all of the sudden got this visual of evil nasty beasts from Hell jumping on this cute 'lil deer's neck and ripping it to pieces. I must be hallucinating.
    • Imagination is more important than knowledge.
  • Bingo! Compaq's SSI technology dates back to a project at UCLA in the early 80s where Bruce Walker was working on his doctoral dissertation. Around '83, he started Locus Computing with Dr. Popek and others. Locus developed TNC, among various other projects.

    I think it was during the 90s that Locus was bought by Platinum. A few years later, Computer Associates bought Platinum, but the SSI technology was sold to Tandem. It was around this time that the port began to UnixWare 2.1.

    After Compaq bought Tandem, the SSI code was brought up to UnixWare 7.1 and released as NonStop Clusters for Unixware 7.1.0 [compaq.com] in late '99. SCO sold it under their name [sco.com] and Compaq hoped to make money from increased sales of servers. Compaq retained ownership of the NSC code, of course.

    It was around this time that I joined the development team. We went through a few more iterations on UnixWare, merging with the UW 7.1.1 code base, adding support for TCP/IP interconnects as an alternative to ServerNet, and fixing bugs.

    Early in the year 2000, Bruce (my boss) decided that we should port NSC to Linux. Later that year, he and some other managers decided that we should also open-source the technology.

    Now here we are halfway through 2001. We've cleaned up alot of the code (more important for open-source than proprietary), adapted much of it to the implementation of Linux, and just released a major piece (Cluster Infrastructure [compaq.com]). Hopefully, an initial release of the full SSI code [compaq.com] will be ready soon.

    BTW, the article says that we're releasing the SSI code under Yet Another Open-Source Licence. There was some miscommunication here. We're releasing it under the plain vanilla GPL version 2 [gnu.org].


    Brian Watson
    Linux Kernel Developer
    SSI Clustering Laboratory
    Compaq Computer

Slashdot Top Deals

Whoever dies with the most toys wins.

Close