Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



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

New Compaq Servers (with Closed Source Libs) 87

pmsyyz sent us a news.com story that talks about the new alpha based Compaq Servers. Lots of interesting tidbits (and hardware specs to drool over) but it reveals that the compiler and libs will not be open source, although they will be cheap. Just read it- its interesting, but frusterating to read about putting Digital's excellence and Compaq's marketing together, and stirring in a PHB decision like a closed source compiler.
This discussion has been archived. No new comments can be posted.

New Compaq Servers (with Closed Source Libs)

Comments Filter:
  • Posted by jpepin:

    I am almost positive it will. The specs seem to indicate nothing unsupported, and they are billing it as Linux Ready. I am very happy that Compaq is perhaps going to get more out the Alpha than DEC was. Although I must say I miss DEC. At least they kept the case designs for the servers and Storage Works systems. There's nothing that looks quite so cool as a stack of those mean blue boxes staring at you. As far as the closed source libs/compiler go, I'll take what I can get. One step at a time is how we've come this far, and it's how we'll get the rest of the way.

    Joe
  • No you won't. And you won't get one, anyway.
    Would you care to explain how one can win a contest by not even showing up? How is nothing twice as fast as GCC? Talk about battling for vapor.
    Grow up.
    It's nice to see you're capable of forming pointed, logical arguments.
    Source is nice. We'd all (well, most of us) prefer it if the source for Digital's cc was made free, but that fact that it isn't is entirely unrelated to the fact that it produces much better code than GNU cc (and variants thereof).
    You are correct in that its proprietary nature is unrelated to its performance. However, I don't see how this gives your argument any credence. I don't want proprietary software; it's a pain in the ass, and there's no way to fix it. Is this where you tell me I don't need source because the compiler is perfect; it has no flaws, no bugs, and not a single error? Microsoft sells that kind of software too.
  • Give them some credit, please. A significant amount of the Alpha development budget went into that compiler, and it certainly whips gcc's ass.
    Really? You sure? Ok, how do I compile it? I'll need a source tarball to start, where do I grab that?
  • This is actually a *good* thing. As long as the source code is free it doesn't really matter
    Huh? How can this be a good thing at all? The source is not free; I can't redistribute it. I can't fix it if I find even the tiniest little annoying bug. I'm still considering buying an Alpha, but it won't be through Compaq, unless I can buy the hardware unattached to this software I'll never use. I won't support a proprietary compiler and set of libraries when I can use fundmentally better ones without isolating myself from the world.
  • And, here is an example of why I think Compaq's proprietary libs and compiler is probably a good idea: When you get an rpm or tgz binary for your system, you will probably get the source code and maybe a binary - right? Then you will compile the source with gcc - right? Or maybe install the binary version.
    Here's a clue for you: I don't do binaries. When I install an operating system, I first compile a fresh compiler for the architecture. I've recently been using EGCS 1.1.2 on the machines I use now; ask anyone with an account on the Intels, Alphas, or SPARCs. I download a source code package for a program I want to use, and I compile it. I install it. I don't do binaries except for the original installations of distributions, and OFTEN I retrieve the source package of a specific utility to bring it around to what I want it to do.
    Now, what is so different about taking the same source code and compiling with a proprietary library and compiler?
    I can't compile the compiler. I don't have immediate access to the latest releases. I can't fix bugs in them. I can't freely redistribute them so that I have a similar build environment on all my machines. I have yet another Makefile battle with cross-architecture development projects and native compiler flags. I get to battle vendor tools, often broken (make, yacc, bin utils, etc.). I waste more time learning another system to do something not as well as the tools I already use, and they actually want to CHARGE me for the experience!
  • Wow, seems like you have a lot to learn about companies who wish to protect their investments in research and development.
    I guess so. Next thing you know, Compaq will endorse some rogue hackers' operating system with some funny name not nearly as marketable as their own ("Tru64 -- We left out the 'e' so you don't have to... we think?"). They might even tell their customers it's alright to use it!

    It's a good thing we'll never see any such mutant operating system become popular, especially in the network, server, technical, and research fields where we work, because we might all get fired if we do something incompetent and don't have anyone else to blame! At least with an industry interested in protecting its valuable "intellectual property investment" above all else (very high indeed above the wishes of its annoying little customers), we're safely tucked away under our own warm fuzzy security blankets, and we'll sleep well knowing we'll never have to worry about the nuisances in life, like personal choice or freewill.

  • Really?
    Yep.
    You sure?
    Yep.
    Ok, how do I compile it?
    You don't need to.
    I'll need a source tarball to start, where do I grab that?
    No you won't. And you won't get one, anyway.

    Grow up.

    Source is nice. We'd all (well, most of us) prefer it if the source for Digital's cc was made free, but that fact that it isn't is entirely unrelated to the fact that it produces much better code than GNU cc (and variants thereof).

    Matthew.

  • The inability to perform one specific and highly unusual task with a piece of software does not make it worthless.

    Try this: Linux is worthless
    Yes, worthless. Let's say I want to write a document using word97. Word97 does not run on Linux...
  • It would be nice to see both the libs and the compiler as Open Source. They can still charge for them (i.e., think free as in freedom). Maybe if Compaq were influenced ever so slightly by a couple of million "restrained" /.'ers. It think that these boxes are a bit beyond my requirements (though I bet these things scream at Quake!).

  • Actually, companies have to learn a lot about "protecting" those investments. All the compiler R&D in the world won't mean diddly squat to Compaq/Digital's bottom line if they can't move boxes. Already, they're going to have to sacrifice the compilers for free, or effectively free. It's not like they're gonna recoup the costs in software - compiler research is a loss leader, which pays for itself by making the boxes faster, which sells more hardware. So are commercial Unix implementations. Why do you think the vendors are all jumping on the Linux bandwagon? To lower the price of entry for their low-end hardware! The reason Unix workstations don't compete with PCs running NT price-wise is because you have to buy $10k worth of operating system and development tools to get full use of your $5k hardware (well, NT ain't really better, but it fools the rubes). Low-end users don't need the high-end features - no sense hot-swapping CPUs in a single-processor box. So give them Linux for free, and sell more hardware. The guys dropping half a million bucks on a server can afford to pay for the extras that come with proprietary Unix.

    Remember also that for serious Open Source users, openness is itself a value. People will use gcc even if it's slower, for trust reasons. And keeping secrets breeds resentment, not to mention serious doubts about the quality of the code. And, as open source becomes more accepted in the business world, this will turn into a suit value as well as a geek value.

    With this in mind, tell me again what it is i have to learn? If it's that the PHBs will live in a portable bombshelter of denial while running their own business into the ground, rather than actually *understanding* the changing needs of their customers, don't worry - i already understand that. And i can also understand not open-sourcing code that has legal restrictions due to contracts with other companies. But if you have a cogent argument that there is bottom-line business value in keeping their compiler research proprietary when it produces no income on its own and galls customers to boot, please make it. Simply telling me i'm ignorant isn't much of an argument.
  • That's anyway good news ....
    Because D/UX has got a price drop and you can now get some good software for almsot has much has the hardware. If they make real money with Alpha servers they should give the oportunity to the dev of linux by :
    1) Helping the compiler guys @ egcs (But I don't mean throwing away the $200 Millions Digital spent in developing it's cc) 2) distribute some binarie version of glibc and other widely used libs compiled with their compiler so that free software would still get some speed boost .....). Selling such lib is not incompatible with GPL , is it ? 3) There should be a price drop for "older" systems like mono 2164 basded systems so many more pple could aford to get one and dev stuff on them or help making 64 bit unclean code clean. Thats all for today ....
  • Although completely open source would obviously be preferable, Compaq probably doesn't want to gut their Digital Un..err Tru64 Unix market. In any case, getting the Digital compiler technology is a big win, because gcc at the moment simply can't come close to competing on Alpha. Previous poster's suggestion about dropping prices on the 21164's would be nice...Alphas have been historically priced just out of range in terms of bang/buck.
  • Do you really think that they're going to turn on us?

    Not a single one of them make any real money off of the OS products on their machines- the money's in the hardware and support services. It's what they provide to make their hardware go- so why not have the user community help with it's growth and development?

    And it's not just the low end in some of the cases of the companies getting on board with us- HP's porting Linux to PA-RISC high-end boxes, and Sun's help with UltraPenguin is allowing Linux to run on Sun's big iron.
  • Alpha 21164 bang/buck has been good for a couple of years, depending on how you use it.. It's just that the benchmark for exceptional power keeps rising with the PII waterline..

    And don't forget mem bandwidth.. 440bx tops out at what, 800MBps? The Alpha LX runs at 1.3GBps.. And the 21264 runs at 5.2GBps.. dr00l...
  • There's gotta be more than that.. IIRC they've already released a no-cost closed drop-in replacement for Linux libm? The compiler's gotta be pretty smart to be a paid extra...

    Still, I don't have a problem with it, as long as there's a free alternative available for those who want it (for price or political reasons)..
  • Wow.. surprising this piece of non-information wasn't moderated out of existance. BSD is far from dead. If it were, why would so many GNU tools as well as the Linux kernel itself contain BSD code? Not just old code, new code as well from both FreeBSD and NetBSD? Wow. Looks like another rabid Linux cheerleader spewing more "Linux only" crap and FUD. I shouldn't be surprised..
  • Wow, seems like you have a lot to learn about companies who wish to protect their investments in research and development.
  • Grow up, Linux poster child. Was this an Apple-bashing thread? Stick to the topic.
  • Wow.. I've never seen so much faulty logic in one place at one time!
  • Perhaps, they are contractually enjoined from
    releasing source by another party. Where, even
    if they wanted to, they couldn't?

    Besides, if *YOU* have the skill and the time and
    the talent and the motivation to work on a *compiler* or a C++ library, apply that energy to
    egcs!!! We already HAVE an opensource project
    that ought to be enough to keep anybody busy.
  • Please check the article again. Mr. Gardner is not a Compaq employee. Most Linux folks at Compaq are very well informed about what has been going on in the Linux community. Why shouldn't they? Many read Slashdot, after all...
  • Open-source compilers are great because even a dummy like me could've fixed this bug in the DEC compiler, if I'd had source.

    With _INTRINSICS defined, the DEC compiler has a special case for sprintf() with only two arguments, and replaces it with a call to memcpy(). This must have seemed like a good idea at the time, but when the second (source) string contains "%%", it is not replaced by a single "%".

    Though I dunno if this is still true.

  • Think maybee a nice, polite (yeah..right) slashdot effect might change their mind? :)
  • The fellow was an engineer in their compiler group. I wouldn't say high up, but it jives with the story I've been getting from the more senior people

    The CPML libraries are nice because they ADD precision compared to gnu libm and they are faster. In fact, our application is bound mostly by simpler operations anyway.

    Glide? I hope to. It's been a matter of time and it hasn't percolated up my stack. With 3Dfx picking up more of the support themselves and the Banshee 2D being open source my workload should get better. I hope!

    - |Daryll

  • Database vendors have warmed to Linux, but the Unix clone simply doesn't have the software support yet from large business software companies such as ERP software vendors, Gardner said.

    What do you call SAP R/3, bonehead? Don't people at Compaq know how to read the friggin' news?

    So let's see... I can get SAP R/3, plus Oracle for the back end. I can get quad processor systems, 1GB+ RAM configurations, terabytes of RAID storage, tape jukeboxes, etc.

    Looks like enterprise computing to me. But then, what do I know, I'm just a paying customer :-P.

  • I stand corrected - perhaps I should learn to read the news before I mouth off :-(.

  • Why, though, in God's name, would I even *want* to run NetBSD on my 8400, which most likely has at least two CPUs? Why would I want to run NetBSD on that system, when DU has a better [etc.]
    Well, given that, why would you want to run Linux on any Alpha, when DU will always have better performance, not to mention far better SMP, journaling filesystems, etc. etc?

    You are right about a lot of the things that are lacking in NetBSD. But it's interesting to see how issues rate differently in technical and `marketing' worlds. SMP is obviously quite important, and a major lack in NetBSD. Even Linux's poor SMP (compared to, say, Solaris) is better than nothing. But the lack of a unified buffer cache is, in the end, not that big a deal technically if you go back and look at the studies and performance measurements done over the years. And while the device-driver framework of NetBSD is incredible (I don't think any OS--including all commercial ones--equals it), that doesn't rate well in terms of marketing, even though it can be quite useful. (Yes, you can even use an Adaptec 1542 in an Alpha if you want, and not through any special machine-dependent hacking on that driver, as with the way Linux does bounce buffers, but because NetBSD has solved that class of problems in a general way.)

    I'm a little more puzzled by the things that I would think would generate `marketing' support. I've been told by any number of people who've used both that the NetBSD install tends to be a lot less painful than the Linux one, and that NetBSD is in general more stable than Linux on the Alpha. (I expect I'm about to get roasted for these statements, and for the most part, roasted by people who don't even run Linux on an Alpha. But what the heck; this is slashdot, after all. :-)) So why haven't these attributes come out?

    cjs

  • As far as your argument about gcc being abandoned goes, I doubt it. I don't think that Cygnus would let itself fall behind.
    Err...in case you hadn't noticed, they already did. Egcs exists for a reason; it wasn't started on a whim.

    Oh, and for those folks who insist that an open source compiler is very important because it lets them fix bugs, I have a buglist as long as my arm for egcs, and I'd love it if you could step up and fix some of these for me. :-)

    cjs

  • If memory serves, the GEM compilers are written
    in Bliss...

    I don't think that this is particularly useful
    artifact as open-source.

    - Jim
  • The Math library (libm)...

    As far as I know, there are no plans to use anything other than the normal Linux header files.
    - Jim
  • If memory serves, the GEM compilers are written
    in Bliss...

    I don't think that this is particularly useful
    artifact as open-source, given the historical
    baggage that this implies.


    - Jim
  • Perhaps I should qualify this, then.

    It is worthless to me, as an OS-geek-researcher-hobbyist-type, to have a compiler whose source cannot be mucked about with in order to make it do things like rearranging the call stack, producing different section names, or producing slightly different symbols in its output.

    Yes, it's a rather specific and highly unusual task, but one worth making possible. Especially if you want to sell hardware. Nothing is gained in this area by making stuff like this proprietary, and in the long run you might be shooting yourself in the foot by making it impossible or difficult for the next Linus Torvalds to tweak things in the way your compiler produces its output to make it meet his needs. Your hardware platform suffers.

    Proprietary compilers are, in the end, a losing proposition for hardware vendors. If Digital are going to make cheap compilers available for Linux/Alpha, then more power to them. If they are going to begin integrating their best hacks into egcs, as someone in a different post said, then they've got my fullest support. Hell, I'll even buy one of the Linux compilers if it would be productive to do so in order to get that stuff into the egcs compiler (where _ALL_ can use it, to the eternal benefit of Digital).

    --Corey
  • It was meant to be a rant, but...

    Please, dissect what I've said and refute my faulty logic point by point. If you cannot, then your claim that my logic is faulty is insubstantial.

    --Corey
  • Oh, also, if the good compiler technology were to become available to the free software community as a whole, OS projects like (Free|Net|Open)BSD would benefit, as well.

    The state of other compiler ports could be advanced, too. I'm sure there are a few optimization tricks in the GEM compilers that could be generally applied. That wouldn't necessarily help out Compaq/Digital, of course, but their "cool factor" would be ratcheted up yet another notch.

    The better everything (yes, _everything_) runs on the Alpha, the more prestige Digital/Compaq gets. Their platform is seen to be faster doing everything (yes, _everything_) if everything is compiled with a good compiler. This _benefits_ DigiCompaqItal (stolen from someone else).

    I'm not an RMS-loving free software nut, but something like a compiler is best if open (at least the parts of it that would make it possible to rearrange the call stack, pass in out-of-band data, emit variously named segments, and so on).

    --Corey
  • No, you're wrong.

    When did I say anything about Linux vis a vis the compiler suite? What I said was, I'd like to be able to modify the code of the compiler to do the things _I'd_ like it to do, by way of some research I'm doing. The result of this would be able to run at optimal speed on an Alpha if Digital's compilers/instruction scheduling/etc. were available in source-form.

    Then I could _do_ the things I want to do, and learn what I want to learn, and have the ability to make something really cool on what is currently the most kick-ass platform out there.

    Now, where is the gross overstatement in that?

    --Corey
  • > fsck off, netbsd luhsur.

    Wow. What an enlightened post. You are obviously vastly more intelligent and superior in every way to this 'netbsd luhsur'.

    Why do you consider *BSD an enemy? If you look at the code (and that's what it's all about, right?), you'll see that *BSD has contributed a lot to Linsux over the years, and will continue to contribute (their nice license makes that possible).

    Why do you bash those with whom you _should_ be cooperating?

    Oh, I forgot. Maybe you're just too 'l33t to have noticed.

    --Corey
  • Yes, worthless.

    Let's say I decide to write the Next Big Thing [tm] in operating systems. This new jewel is the Perfect Operating System [tm], and will solve all problems for all people for all times. Now, suppose I want this wonder of modern technology to be free software. Further, because it is so radically different, binary formats and the like from a completely inferior OS, like Unix or Linux, simply won't fit. How do I get the maximum performance from an Alpha (and since this new operating system is The Bomb [tm], support for it will far outstrip anything else in existence)?

    I want to be able to do research with a good compiler, to write my own binary organization standards, to fiddle with the stack and do neat-o things to tailor the system to my own exacting specifications. I have to, in that case, use the GNU compiler suite. Especially since my new OS project will run on more platforms than Linux and NetBSD combined.

    If I use the GNU compilers, and tailor my code to use features of that compiler suite (and there will have to be compiler-dependent code, that can't be avoided if you want some of the nicest code-generation features), then it becomes very difficult to port all this stuff over to a different compiler for each different platform. I simply won't do it, and performance will suffer on the Alpha.

    Thus, having a compiler that can't be taught new tricks by curious researchers will have sounded the death-knell for the Alpha processor.

    --Corey
  • As far as I can tell, the only reason NetBSD doesn't get more credit for their accomplishments is that, in some areas, they haven't accomplished what they've needed to.

    Case in point: SMP.
    Case in point: Unified Buffer Cache.
    Case in point: Journal File System.

    That NBSD will run on an 8400, and that it is chock-full of RAIDframe goodness, and that it is in many other ways very cool and very well done is a testament to the project. The userland, especially the compiler tool chain, is very nice indeed.

    Why, though, in God's name, would I even *want* to run NetBSD on my 8400, which most likely has at least two CPUs? Why would I want to run NetBSD on that system, when DU has a better buffer cache setup (with AdvFS, that is... AFAIK, the UFS stuff still has a segmented buffer cache, which is silly considering the amount of money Digital must put into development of that Unix)? What on earth would possess me to run NetBSD on my 8400 when I need that system to serve files, and the filesystems have less of a chance of being recovered than a DU system using AdvFS? Oh, and not to mention, does NetBSD have logical volume management?

    I'm not meaning to slam NetBSD here, because most of what I've said above also applies to Linsux, but these are the hurdles that must be lept in order for NetBSD to get its message across.

    --Corey
  • You are apparently unfamiliar with Digital's engineering. If you don't want proprietary software, fine. That wasn't the argument. But if you have an alpha, Digital's CC runs faster and produces significantly faster code. And digital software is among the most bug-free I've ever encountered. No, nobody's perfect, but they're damned close. Open-source compilers are great if one of two conditions are satisfied: 1) you are a compiler engineer with experience on the platform, or 2) there are lots of people like that out there with an interest in the program. For gcc/alpha, the pool is very small. It hasn't been tuned to the same degree that the intel versions have.

    And part of the reason for that is that the compiler exploits characteristics of the processor that Digital (and now Compaq) might legitimately want to keep secret.



  • I'll try to explain more clearly the way I see it - or perhaps, the way I think Compaq is seeing it.

    Compaq is a hardware supplier. This much is true. But to a lot of customers out there, one Alpha system is much the same as another, whatever the badge - therefore hardware suppliers must also offer value-added services.

    Their compiler is one such value-added service. This compiler, because it is a kickass compiler, gives Compaq an advantage over rivals who don't have a kickass compiler for their DEC systems.

    This is not to say you can't install an alternative compiler on a Compaq Alpha (or any other Alpha box for that matter). You just won't have the kickass compiler unless you get the Compaq Alpha.

    So, in short, the sales-speak goes thus: "If you want an Alpha machine where you get the most real work done for your money, get a Compaq Alpha with our snazzy new compiler."

    If _everyone_ had a good optimised compiler, Compaq doesn't have quite as strong a sales pitch.

    Is that any clearer?

    "If it's a bad idea, trash it. If it's a good idea, steal it and release the source code."
  • Someone already mentioned the possibility of there being legal problems with releasing the source of the compiler. Maybe there are other problems as well. Say, the implementation of the compiler is such that it is not amenable to an open source environment. Maybe because of the implementation language, maybe because of the build system, maybe because it's so complicated that only someone who's studied the code for months under the proper tutelage can be trusted to make good changes.

    I'm not saying (yet) that any of these things are true, but without all the facts, it's just speculation why Digital/Compaq made the decision they did. Not that that ever stops taco or other /.ers...

    Jason
  • If anyone out there is feeling generous, give me one of theese monsters :)

    /Puppe
  • While I'm sure your average slashdot reader is only going to compile C or C++ code and run their latest game or webwidget on thier linux boxes, at my place of work, the majority of usefulness for alpha clone machines is running Digital Unix binaries. Specifically binaries which have been compiled on DU boxes using not only the quite good C/C++ compilers, but also the *stunningly* good (in comparison to anything free) FORTRAN 77 and existant (unlike free stuff) FORTRAN 90 compilers.

    Having these very well developed products available on clone machines will make life very very much nicer for these applications.

    In summary. Not all the world's a desktop box compiling GNOME bits. Compaq remember where their income from the Alpha platform boxes actually used to come from.
  • "Pointy Haired Boss" as in Dilbert.
  • You seem to have a valid issue from the development standpoint. You may run into compatablity issues with the binary only compiler. I'd have to say... that would be Compaq's problem unless they choose to provide greater access to their source code.

    For a production system such as a database, inter/intranet, or file and print server, however, the possible loss of development capablities would be more than offset by the long-term efficiency gained using specially tweaked libs and programs compiled using optimizations specifically designed for Alpha.

    If there are major compatability issues between the GNU tools and Compaq's proprietary tools then the real loser will probably be Compaq. Maintaining compatibility is paramount these days; rather, competition on performance and ease-of-use will likely win the day.

    What I'd like to know is... is there a choice to use GNU compilers and glibc rather than the proprietary ones? There is! Use standard Linux.

    Choice is a good thing.
  • Here is a clue for you. Compaq is a company. They are in business to make money. Compaq has also been a contributor and supporter of Linux.

    And, here is an example of why I think Compaq's proprietary libs and compiler is probably a good idea:
    When you get an rpm or tgz binary for your system, you will probably get the source code and maybe a binary - right? Then you will compile the source with gcc - right? Or maybe install the binary version.

    Now, what is so different about taking the same source code and compiling with a proprietary library and compiler? You still get a binary; you still have the source code; you can still contribute to the OpenSource/Free Software cause - what's the difference? I'll tell you. You get a library and compiler especially tweaked and tuned for the Alpha - you get the boost in speed. And, Compaq gets bragging rights. Everybody wins.

    I love GNU tools; I think they're GRRRREAT! But hey, if Compaq can optimise a compiler and libs for Alpha and still maintain source-code compatability with apps designed to be compiled by GNU tools then I say good for them! It's Compaq's way of competing and still contributing.

    ANY UNIX is better as far as I'm concerned.
  • This is actually a *good* thing. As long as the source code is free it doesn't really matter - let them compete on the basis of 'My compiler's better than yours... my processor's better than yours... my bandwidth is better that yours... etc..'.

    As long as the source is free!
  • Posted by jpepin:

    I think this is exactly the kind of thing we need to see. Closed source compiler/libs and all. I feel it is crucial for the success of Linux that corporations see that they can still keep some secrets and make some money while still fostering and supporting the Open Source Movement. I mean look at it like this;

    "Yes, sir, Mr. PHB, this 'Linux Thing' is a little new, but DEC, I mean Compaq has released this new line of servers that are Linux Certified, and they'll warranty it. And they'll ship it with a Proprietary (he'll think you said supported) compiler that will allow us to get the most out of that CPU, which has just dropped signifigantly in price. And oh yeah, an unlimited User Lic Pac is free."

    That will start to have a serious effect at top levels of corporate descion making. That blue DEC case still carries a lot of weight in some places.

    Remember, in large chunks of the IT world Intel==Micro. EOF. A 4x Xeon with redundant everything is still a PC. A DEC Server is a Server.

    Until now an IT Manager who wanted to move a mission critical web application to a Linux server from say a Sun, would have really had an uphill battle. Now the playing field is a little more level.

    That's all.

    Joe
  • I imagine that if Compaq gets enough feedback from the community they may well reconsider their decision about the compiler. But we'll see.
  • Give them some credit, please. A significant amount of the Alpha development budget went into that compiler, and it certainly whips gcc's ass.

    It would be nice if it were free (in either sense), but I don't think it's fair to criticise Digcompaqital for not giving away what many see as their best product.

    On the OS side, it's rather interesting to see the "big Iron" guys lining up behind Linux &emdash; it seems to me that in many ways they're looking to leave the low-end OS market behind (I doubt there's much money to be made there) so they can concentrate on tuning their OS for big machines (E1Ks, &c), and leave Linux for the lower-end hardware.

    This is fine, but I'm a little concerned as what might happen if/when Linux gains more of the enterprise-level features, like partitioning/journalled js/etc.

    I wouldn't like to see them turn on us...

    Matthew.

  • Yeah, the DEC compiler is fast, fast, fast. But from a *configuration* point of view, well... it blows. I do cross-platform integration, and porting code from other unices to DEC took longer than all the other platforms put together. And it wasn't endian issues or any other such technical subtleties, either... it was just various bits of brain damage in the configuration. Non ANSI-compliant headers, for example, or the fact that their linker couldn't resolve symbols that didn't cause problems on any other platform.

    And then there's D/UX itself, which was apparently written by a bunch of bitter, resentful VMS coders seeking vengeance on Unix (I know, most of them wound up at Micros~1, writing NT!). Little things like the man command using a hardcoded path to nroff, which of course wasn't in the installed base (so no unprocessed man pages worked), and other PATH hardcodings. Or the which command under root only looking at the "official" root PATH, not the actual PATH in the shell. Which dovetailed nicely with the fact that sudo screwed up the environment for child processes...

    But i digress. A sensible, user-tested environment like Linux will fix all these gripes. I just wish they would either open up the source to their compiler and libs, or work closely with gcc/egcs to provide their best tricks to the open source compilers. What reasons do they have to do otherwise? I assume they'll be giving the compilers away, or close enough to it, so they won't recoup their cost. The only things that might hold them back are patents (not the case, afaik), or NDAs with other software companies like KAI (who does the C++ front end for some vendor compilers).

    If it's just the usual corporate Catholicism of keeping the Mysteries to themselves, then Compaq has a lot to learn.
  • That's anyway good news ....
    Because D/UX has got a price drop and you can now get some good software for almsot has much has the hardware. If they make real money with Alpha servers they should give the oportunity to the dev of linux by :
    1) Helping the compiler guys @ egcs (But I don't mean throwing away the $200 Millions Digital spent in developing it's cc) 2) distribute some binarie version of glibc and other widely used libs compiled with their compiler so that free software would still get some speed boost .....). Selling such lib is not incompatible with GPL , is it ?
    3) There should be a price drop for "older" systems like mono 2164 basded systems so many more pple could aford to get one and dev stuff on them or help making 64 bit unclean code clean. Thats all for today ....
  • Well, as usual, NetBSD gets left out again, despite the fact that it's the only free OS that runs on high-end AlphaServers, such as the 8400. (Or maybe because of that fact; who knows?)

    I'm entertaining suggestions about what we can do to fix this. What needs to be done to give NetBSD a bigger place in the Alpha community? Or is there a good reason it shouldn't have a bigger place?

    cjs

  • OK, this is really embarassing to ask, and I'll
    probably kick myself when I hear .. but I don't know what "phb" stands for. Could someone be so kind as to fill me in?


    Sorry if this post is "noise".
  • Someone else asked. Sorry for the noise.
  • I started writing this post an hour and a half ago, then was called away to a meeting so if I'm reiterating sentiments that have already been voiced, I apologise.

    As far as Compaq are concerned, it's probably not in their interests to open-source their compiler. It is a value added service, not an essential. If you want an open-source compiler you can always use gcc. If you want their compiler, you'll have to accept it on the terms that it _is_ a value added service (and by all accounts, an absolutely stunning compiler), is closed-source, and is probably going to cost you.

    Sure, it would be _nice_ if it was open-source, but I believe it would be counter-productive.

    Open-sourcing their compiler might effectively _prevent_ the development of existing freeware compilers for Alpha systems, since the compiler and source are already there, who but the most dedicated hacker will bother to develop an alternative? (NIH notwithstanding, I guess.)

    And I believe the reason why development of existing free software continues is because the software was originally _designed_ to be open source - that is, it is generally more legible, modular, well documented and so forth. Software developed by corporates is hardly ever so easy to follow, and most hackers will probably die of boredom before they ever get to understanding the code, let alone modifying it. (Remember Mozilla, anyone?)

    So effectively, neither Compaq nor the open-source/free software community gain any of the benefits of open-sourcing their software, while Compaq's competitors pore over their software, say "ah! so that's how they did it" and write their own versions, because corporates don't need dedication - just a lot of paid programmers.

    This will lose Compaq the main edge it currently has over its rivals in the Alpha supplier market. This does Compaq no good whatsoever - they get no effective return on their investment.

    So, in a way, it could be argued that non-release of the source _benefits_ the open-source community because it actually gives the dedicated compiler hackers something to aim at. For Compaq, by releasing a closed, non-free compiler, is effectively allowing the continuance of unrestricted development of the existing freeware compilers.

    "If it's a bad idea, trash it. If it's a good idea, steal it and release the source code."
  • I was speaking to one of the guys from the Compaq compiler group at Linux World. Compaq realizes that good compilers just make their hardware look better, so they do want to see that happen. The problem is that they can't (for whatever reason) release all the technology open source. They can provide information and some technology to help gcc based compilers get better, but they are afraid that it is a major overhaul and will require a couple years to become functional. The big problem is that the instruction scheduling has to change dramatically particularly for floating point. So, they are taking a two pronged approach. One is to get their compiler out in the short term for a low cost. The second is to add functionality to gcc. Eventually they could get out of selling their compiler. It's a good plan and the right thing happens over time. Alpha's rock running Linux, but our 400 Mhz DEC Unix systems out perfrom 466Mhz Linux systems. I suspect that's mainly because of the compiler and the good math libraries which they have also released for free (proprietary). - |Daryll
  • And what about bugs introduced into my code from bugs in the compiler? At least with Open Source compilers, I can fix that myself, if I need to. And if you don't believe me, you obviously haven't read enough changelogs. I've seen plenty of entries scattered all over the place to the effect of "added a work around for the [compiler] [version] bug on [platform]." What do we do with their closed source compilers? Never have them fixed?
  • And my point was that performance isn't the only important issue. If the only response to him is some idea that having source lurking somewhere on the same hard drive is going to magically make a compiler faster, you've got to be kidding me.

    Respond to this: The compiler can still be closed source and it won't affect the compiler's performance as a paperweight.

    Big deal. Paperweight performance isn't the only issue for compilers. It's legitimate to point that out if I go about saying that it doesn't matter if a program is closed source because paperweight performance isn't affected.
  • by raistlinne ( 13725 ) <{lansdoct} {at} {cs.alfred.edu}> on Tuesday April 06, 1999 @10:47AM (#1947742) Homepage
    Daryll,
    This is awesome news. Is the guy that you heard this from a reliable source? I.e. is he high up enough to be getting this info reliably, like as a first-hand source that doesn't change its mind much?

    On the math lib note, try out libffm. Sometimes it's faster than the compaq portable math libraries, though it depends greatly on the application.

    On a third note, is there any chance that you'll work on glide support for the Alpha?

    Thanks for the info, this makes the future of Linux/Alpha look bright indeed.
  • As far as your argument about gcc being abandoned goes, I doubt it. I don't think that Cygnus would let itself fall behind.

    As far as "This will lose Compaq the main edge it currently has over its rivals in the Alpha supplier market." What are you talking about? Compaq supplies hardware. You're not going to reverse engineer Alphas and come up with Alpha clones from an optimized compiler. Especially not on any timeframe that matters.

    Do you think that Compaq is in the business of selling compilers? They make the compiler to make their hardware faster, and nearly give it away so that they can sell more hardware. Are you going to tell them that 100 different optimized compilers are going to result in compaq selling less hardware?
  • > A source tarball was asked for. A binary is
    > available. If I show up to a race with the parts
    > to a car and a built car, why would you assume
    > the pre-built car was not there?
    There is validity to this argument. But let's say that the atmospheric content has changed from what the pre-built and welded-shut car comes with. The parts can be easily adjusted. The welded-shut car can't. It's close enough to have nothing when you have a car that won't count. (please give the analogy some leniency, I'm not a mechanical engineer to give a really dead-on technically correct example).

    > > You are correct in that its proprietary nature
    > > is unrelated to its performance. However, I
    > > don't see how this gives your argument any
    > > credence.

    > Your first sentence is correct. The second one
    > does not make sense. He was talking about
    > performance which you agreed with in the first
    > sentence.
    No, he wasn't making a performance argument, he was making a closed source/open source argument, and using performance as one justification of that argument. Shaw is attacking the open/closed argument, which is the real argument being made.

    > He stated facts. You can argue the moon is made
    > of green cheese, but it does not change facts.
    No one disagreed with the fact that the digital compiler will probably be faster than current egcs/gcc compilers. Many people, myself included, might take issue with the idea that the digital (compaq) compilers are better. That's what the argument is about.
  • by raistlinne ( 13725 ) <{lansdoct} {at} {cs.alfred.edu}> on Tuesday April 06, 1999 @11:24AM (#1947745) Homepage
    Isn't egcs currently the market leader in ANSI C++ compilers?
  • Let's remember that the pointy-haired boss in this case might be the head of Linux International, who rather than being pointy-haired, bears a strong resemblance to a department-store santa, or Jerry Garcia on a bad day. Or at least he knows the people involved.

    Bruce

  • The Math library (libm)...

    Thanks, Jim, that makes sense. I wish the original message had been clearer. Some people got their dander up because they thought some GPL-ed library would be closed.

    Of course the usual GCC libm would co-reside on the same machine.

    Compiler hackers will take this as a challenge.

    Bruce

  • The libs won't be open-source is a pretty broad statement. Which ones? The C library? Possible, but doubtful, they'd have to use their own, breaking compatibility rather badly. Some run-time library that provides ALPHA low-level facilities for the compiler? Sure.

    So, make EGCS better. We've known for a long time that GCC couldn't stand up to DEC's compiler on the ALPHA.

    Bruce

The answer to the question of Life, the Universe, and Everything is... Four day work week, Two ply toilet paper!

Working...