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.
Cool... (Score:1)
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
Not Even a Contender (Score:1)
Really? (Score:1)
What are you talking about? (Score:1)
This is what I'm talking about. (Score:1)
I guess you're right... (Score:1)
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.
Yep. (Score:1)
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.
Allow me.. (Score:1)
Try this: Linux is worthless
Yes, worthless. Let's say I want to write a document using word97. Word97 does not run on Linux...
When will the PBH's learn... (Score:1)
Please... put the speed in another compiler! (Score:1)
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.
What they should do ... (Score:1)
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
Good first step (Score:1)
Turn on us? (Score:1)
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.
Good first step (Score:1)
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...
Just Which libraries won't be Open? (Score:1)
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)..
*Sigh* - NetBSD Forgotten Again (Score:1)
Please... put the speed in another compiler! (Score:1)
OSS don't mean crud. (Score:1)
Closed-source compilers are WORTHLESS (Score:1)
Maybe they *can't* release source... (Score:1)
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 do not attribute that remark to Compaq (Score:1)
Really Stupid DEC compiler bug (Score:1)
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.
Hmm... (Score:1)
Awesome! (Score:1)
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
Just another Comqrap crack baby (Score:1)
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.
Please do not attribute that remark to Compaq (Score:1)
*Sigh* - NetBSD Forgotten Again (Score:1)
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
DEC compiler - open vs. closed source (Score:1)
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
When will the PBH's learn... (Score:1)
in Bliss...
I don't think that this is particularly useful
artifact as open-source.
- Jim
Just Which libraries won't be Open? (Score:1)
As far as I know, there are no plans to use anything other than the normal Linux header files.
- Jim
When will the PBH's learn... (Score:1)
in Bliss...
I don't think that this is particularly useful
artifact as open-source, given the historical
baggage that this implies.
- Jim
Allow me.. (Score:1)
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
Closed-source compilers are WORTHLESS (Score:1)
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
... And another thing (Score:1)
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
It hasn't been worthless to DEC/Compaq (Score:1)
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
OSS don't mean crud. (Score:1)
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
Closed-source compilers are WORTHLESS (Score:1)
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
*Sigh* - NetBSD Forgotten Again (Score:1)
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
Not Even a Contender (Score:1)
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.
DEC compiler - open vs. closed source (Score:1)
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."
Assumptions, assumptions... (Score:1)
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
Jason
I want one. (Score:1)
/Puppe
Compilers for what? (Score:1)
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.
What is "PHB"? (Score:2)
I see where proprietary would affect you. (Score:2)
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.
This is what I'm talking about. (Score:2)
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.
Proprietary libs and compiler. (Score:2)
As long as the source is free!
Very Fast Linux Boxes for Big Companies. (Score:2)
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
Decisions like this aren't necessarily final... (Score:2)
PHB Decision? (Score:2)
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.
Please... put the speed in another compiler! (Score:2)
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.
What they should do ... (Score:2)
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
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
*Sigh* - NetBSD Forgotten Again (Score:2)
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
Could someone please enlighten me re "phb"? (Score:2)
probably kick myself when I hear
Sorry if this post is "noise".
Never mind, I found out (Score:2)
DEC compiler - open vs. closed source (Score:2)
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."
Compaq Compiler Technology (Score:3)
And what about bugs? (Score:3)
So he's off topic then? (Score:3)
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.
Awesome! (Score:3)
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.
DEC compiler - open vs. closed source (Score:3)
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?
Not Even a Contender (Score:3)
> 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.
egcs? (Score:3)
Jon "Maddog" Hall does not have pointy hair (Score:4)
Bruce
Just Which libraries won't be Open? (Score:4)
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
Just Which libraries won't be Open? (Score:4)
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