Why people were enthused about GCC early on in its life | Hacker News Reader

Why people were enthused about GCC early on in its life

utcc.utoronto.ca

187 pointszdw105 comments

There were other reasons too. I worked at a place where we ported our software to 20 different versions of Unix[1]! gcc tended to be a lot less buggy than vendor compilers, and what bugs there were tended to be across all platforms.

gcc's error messages were also a lot better than vendor compilers, as were regular diagnostics. gcc -Wall was a huge boon to improving code quality.

If you were doing C++ for cross platform software, then gcc was the only game in town. The vendor compilers were at different versions of the C++ spec, had different libc++, tended to crash a lot, and had really bad messages. Heck gcc even added a flag to generate warnings based on Scott Meyers' Effective C++ books.

When the vendor compiler started being sold separately, they also included licensing daemons. Every invocation of the compiler would check with the licensing daemon to make sure you didn't go over your license limit. The license daemons also tended to crash or get confused, causing even more grief trying to compile a large code base.

At the end of the day vendor compilers were unreliable, buggy, unpleasant and a pain to work with. gcc was developer friendly and worked well. That got a lot of enthusiasm.

[1] You can get an idea of what development was like back then http://www.rogerbinns.com/visionfs.html

If I may add emphasis... GCC's error messages were a HUGE improvement over existing compilers. Back in 1985, C compilers might tell you what line the error was on, but they also might not. GCC went further, revealing not only the line number but added a carat pointing to the precise term in the source code that was the source of the error. This was a godsend.

In addition GCC's error messages were human readable. Unlike Microsoft, whose compilers and interpreters had long produced only line numbers and error codes, GCC wrote their messages in English, which were sometimes tuned further to fit the syntax.

At the time, all this was a really big advancement over non-IDE compilers (which then died a thousand deaths when the cfront translator and then OOP's general lugubriousness made error messages illegible once again).

Very true! It's easy to forget how bad things were back then ...

Oh, but at least they had a sense of humor:

http://www.ralentz.com/old/mac/humor/mpw-c-errors.html

"I worked at a place where we ported our software to 20 different versions of Unix

If you're feeling odd or out-of-place, I'd like to point out that I had the exact same experience in the mid- to late-'90s.

Gcc also had the major advantage of compiling the same C on all of the machines. Yes, C was standardized and old at that time, but each compiler somehow found room to be slightly different.

Not to mention that the code it generated was pretty competitive in general with AIX's xlc and Sun's SPARC compilers.

P.S. Thanks for the licensing daemon flashbacks, dude. Thanks.

Heh, I remember this too. For a brief time in the late 90s I was responsible for porting NeXT's NetInfo to a bunch of different Unixes. I think, though, we mainly used gcc except on SunOS, because it was free and handled modern C syntax (of course, compiling gcc in the first place without the native compiler involved hunting down a [usually old] binary version). But that's 20 years ago...

Now I feel inadequate. I only had to deal with 8 or 10 versions.

Now I'm feeling inadequate. Growing up in an intel dominated world, you couldn't touch a Sparc or MIPS machine if you were a mere mortal. Everything accessible to me was on windows, and the hard to load versions of *BSD or linux. Nowadays, we're beginning to get access to ARM machines like the Raspberry Pi, or 8 bit things like PICs or Atmels.

Funny thing is, high cost compilers are suddenly becoming free such as Windows with their VS stuff. While gcc has been the gold standard, because it's been free, newer technologies such as LLVM are also beginning to thrive in the free and open source world. Amazing times we live in!

Good news if you're interested in PICs and MIPS --- the PIC32 architecture has a MIPS core! And you can run RetroBSD on it:

https://olimex.wordpress.com/2012/04/04/unix-on-pic32-meet-r...

I work in the FPGA and chip design world and you have described our present day tools to a tee, including the use license daemons that tend to crash and get confused. This thread depresses me, but also gives me a little bit of hope that maybe someday in the future a gcc-like project will free us from our current bonds :-)

There was hope 20 years ago, when NeoCAD wrote an independent partition-place-route tool for Xilinx chips, but then Xilinx bought them [1]. No action since then.

I've thought about this over the last 20 years. In my opinion, designing a free FPGA from scratch and writing the requisite tools would have to be be a serious option for someone considering taking on the task of reverse engineering and tracking the development of existing FPGAs. It probably wouldn't be much more work for a person with the requisite knowledge and the result would be "more free", by not having to follow the silicon manufacturer's elephant.

Then again, buying an FPGA and spending a heap of time reverse engineering it is more accessible to the average hacker than designing and building an FPGA chip.

[1] http://www.xilinx.com/publications/archives/xcell/Xcell17.pd...

---

Edit: Delete unused reference

At this point I'd be happy with just a Free multi-language simulator, let alone synthesis tools. There are a couple Free verilog-only or vhdl-only ones, but any modern project, for better or worse, has a combination of verilog, SystemVerilog, vhdl, and probably some verification-language testbench stuff (specman/vera).

Also, the current free simulators don't have the advantages that gcc had over commercial compilers mentioned. They are slower, have worse error messages (hard to believe that's possible but it really is), and worse language support. So sad.

Writing GPL'd synthesis stuff is the #1 item on my "things to do when independently wealthy" list. Personally I'd start with reverse engineering Lattice's FPGAs. They have the most documentation and the simplest chips. Plus as the third horse in the FPGA business they might be the most amiable about the advantages being more open provide.

The state of EDA tools really does remind me of the bad old days of proprietary vendor compilers a few decades ago. It's so incredibly frustrating.

speaking as someone who was there: (https://groups.google.com/forum/#!msg/gnu.gcc/nMF9tvS8E-w/Op...)

it's not that gcc was less buggy. There were bugs in the gcc ports, too.

In my particular case (Convex), gcc would generate faster scalar code than the for-pay 'vectorizing' compiler would. This was very popular with the technical marketing folks (who would attempt to 'win' benchmarks in order to sell computers.) I pointed this out to the compiler group, and suggested that perhaps some emphasis on scalar code generation would be a good thing. (Amdahl's law, anyone?) I was ignored. At one point I threatened to put a trivial instruction scheduler in gcc, as gcc in those days didn't have any instruction scheduling, the Haifa scheduler didn't come about until the late 90s. Doing so would have probably beat the convex compiler at all but embarrassingly-vectorizable codes (and those were normally written in Fortran anyway.)

gcc still doesn't have a proper control flow graph, which is essential for interlock scheduling.

After I left (for Sun) it became cause for termination to use gcc in a customer-facing benchmark at Convex. As it turns out, the manager of the compiler group took offense. I was only trying to help.

Michael Tiemman made an ovation about a job at Sun (working on gcc) based on that work. Yes, Sun was supporting the gcc work even as the compiler group was "unbundling" the for-pay compiler.

gcc was basically an example of filling a need. There was a good-enough compiler available that could be ported to new architectures.

These days we have llvm/clang, which is architecturally cleaner, and which I expect to eventually eclipse gcc.

Michael Tiemann has a friend who has to have the worst job in the world:

http://www.art.net/~hopkins/Don/unix-haters/slowlaris/worst-...

Great summary of just how bad that era was. I only saw the tail end of it but I worked at a place which had (IIRC) something like 600 different platform + version combinations to test – most Unix variants, DOS, Windows, OS/2, VMS, OS/400, etc. combined the fact that OS upgrades were far less frequent than we now assume and many shops preferred specific patches rather than wholesale upgrades.

In addition to the compiler itself, we had tended to favor the opensource libraries after having found various hard problems with the vendor versions or lack of support in general.

Amusingly, most of the vendors doing this sold the “Open Systems” Unix platforms which had successfully attracted customers away from the even more expensive mainframe / minicomputer market before themselves losing customers to PCs running BSD and Linux by making the cost/support ratio less favorable.

I enjoyed the real meaning of writting portable C and C++ code across DG/UX, Aix, Solaris, Linux and HP-UX using the vendor provided compilers.

Young generations that think UNIX == GNU/Linux, *BSD, Mac OS X, might not imagine the "wonderful" portability across UNIX systems in the golden age of UNIX wars.

Then again, we seem to be getting into distribution wars nowadays.

At least the C and C++ compilers are the same.

The worst codebase I had to support in that period was a serial communications library which cross-compiled for a bunch of Unix flavors and 16/32-bit DOS/Windows/OS/2. If memory serves roughly half of that code was preprocessor directives.

Don't see too many folks this days with stick time on DG/UX. My neckbeard and I tip our beer to you.

That Dr. Dobbs article you link is indeed wonderful - and very relevant today. I made a separate hn-submission -- maybe we can get some interesting software design advice/discussion going?:

https://news.ycombinator.com/item?id=8988358

As for VisionFS - how sad to see yet another project locked up at Oracle. On that note: there's still no decent support for DavFS in/for (free for) windows (8+10)?

Maybe I'm weird, but I'm still enthused about GCC.

I mean come on, it's a free high-quality C compiler for almost any platform you can dig up! That's just awesome! C hasn't died or gone away since the 1980s, and being able to compile C for such a wide range of processors and platforms is great, in my opinion.

LLVM seems to be where the interesting action is these days, I think mostly because it's adopted a superior modular design. GCC's technical design was compromised by RMS' desire to keep it tightly coupled for licensing reasons, and in the past few years the pain of that has really started to be fault. Which is somewhat ironic considering how the free software movement started.

Both LLVM and gcc suffer from the problem that they're vast underdocumented code bases with Internal Platform Syndrome and mostly-but-not-quite-finished internal tools which generate undebuggable code. The actual working set of knowledge which you need to do serious work on the compiler, such as porting it to a new backend, mostly exists as tribal knowledge only, and the only way to find this out is to either investigate the source yourself or to try and ask for help on the mailing lists. LLVM's is significantly more helpful than gcc's, because LLVM has more people participating and more momentum behind it, but you're still not guaranteed to get an answer. Actually producing a working backend is an enormous investment of time and effort.

By way of example: I'm interested in the Broadcom Videocore IV processor, also known as the main processor on the Raspberry Pi. I bounced off both gcc and LLVM, and for much the same reason --- after getting the port about 75% complete I ran into blocking issues that I couldn't fix on my own and couldn't get enough assistance on the mailing lists to fix. Which is a shame. (I should point out that prior to that I did do a VC4 backend for the ACK compiler. It generates terrible, terrible but working code.)

I have run into commercial compilers which were easy to port, and generated good code, to boot. Volker Barthelman's vbcc even has a VC4 backend, which produces amazing code, and his compiler is a tiny fraction of the size of either gcc or LLVM! But it's not open source. Maybe one day we'll get a similarly good open source small compiler...

Offtopic: what's a good way to learn about the Videocore processor? I now own a B+ and a Pi 2 so it might be worth my while.

I have absolutely no idea about the processor in the Pi 2, but I got all the specs for the Pi 1 from here:

https://github.com/hermanhermitage/videocoreiv

(It's a beautiful processor. 32 registers, built in DSP, built in vector processing, some really elegant instruction design, dual core, and enough weirdness that writing good code is satisfying without being frustrating. No double precision float, alas, although it's got single precision, and for some bizarre reason there's no adc or sbc instruction which makes 64 bit arithmetic annoying.)

If you're interested in playing with it, you might also like a look at my half-finished pure-VC4-code boot loader here:

https://cowlark.com/piface

Stick it on an SD card, hook up a serial terminal, and it'll boot directly on the VC4 without even starting up the ARM.

Whoa, does that mean there's a chance of replacing the proprietary bootloader on the Pi? It's the most common complaint I see here.

You can replace the proprietary bootloader on the SD card. You can't replace the one in the ROM. And while running executables is easy --- just drop a VC4 binary called bootcode.bin onto the root directory of the card and the ROM loader will load and run it --- there's a lot of hardware setup which still needs to be figured out; such as initialising the SDRAM.

I originally wanted to get Prex (a Minix-like microkernel OS with a Unix interface which doesn't need an MMU) running on the VC4, but I need an actual working compiler for that.

May I ask you: why programming VC4 (apart from taking over the control of the rest of Raspberry Pi?) It's only 250 MHz? And if you want the new control of the Raspberry Pi, why, as it's so proprietary?

Clock speed is only a very small part of the performance of a chip when comparing across completely different architectures (like VC4 vs. ARM).

Because the VC4 is really cool, basically.

Pi 2 apparently has the exact same GPU/VPU as the Pi 1.

The only thing they changed was the arm cores and the memory subsystem.

Gcc code is arcane: it relies heavily on macros to define some kind of DSL for the compiler backends (check out the .def files), but if you want to contribute seriously you need to learn that DSL and how it works behind the scene somewhat, whereas llvm is C++. That being said, it's an interesting experience to dive into that code.

I give you: https://github.com/llvm-mirror/llvm/blob/master/lib/Target/X...

I agree with you that gcc is much less pleasant than LLVM+Clang, but to say that LLVM is better becauses it uses C++ everywhere is simply incorrect. In fact, using this kind of DSL for backend definitions is good design.

The LLVM DSL engine is really annoying to use, mainly because the pattern matching engine is pretty simple, and it's possible to express patterns in the DSL language which the pattern matching engine is unable to actually match. Until you know where the limits are it's really frustrating; you write a pattern which should work and the compiler blows stack or produces an impenetrable internal error because the pattern matcher has given up or gone into a working loop.

A large part of any LLVM backend is actually custom C++ code for matching and expanding patterns which the pattern matcher either can't or is unwilling to do (e.g. custom backend-specific DAG nodes). I direct you at this file:

https://github.com/llvm-mirror/llvm/blob/master/lib/Target/X...

github will give you a warning before loading it because that single C++ source file is over a megabyte...

I must admit that my knowledge of llvm is very limited. I did make the (perhaps wrong) assumption that it would be easier to understand on that basis alone (well, and the fact that the people writing it know how to code C++ properly, I guess for major projects like Gcc and llvm you may expect well engineered code). I felt that the whole macro business isn't as solid nowadays as what templates could allow in terms of type checking (and perhaps some macros involved for syntactic sugar alone; caveat with the cryptic error messages for errors in templates), hence my previously stated opinion.

Note that I am not complaining about the DSL, just how things are quite difficult to figure out (and untyped macros, as stated above).

That looks very readable. Maybe the gripe was that GCC isn't readable? I don't know, I haven't looked at GCC code.

LLVM's target backends are also written in a custom DSL (tblgen). Is that not a good thing?

As opposed to LLVM's tblgen?

GCC developers say that things are better now. I really don't know; I haven't checked.

But the simple fact remains that they did intentionally create hard to maintain code and spent several years rejecting patches that would clean up the monstrosity as a defense against people using GCC code in nonfree programs.

It's hard to trust their judgment now.

Things are better, yes, but there's still a long way to go. This LWN article covers one developer's ongoing frustration: https://lwn.net/Articles/629259/

Yes, the efforts to make it hard for nonfree programs to use parts of GCC also make it hard for free programs to use parts of GCC.

> compromised by RMS' desire to keep it tightly coupled for licensing reasons

It's certainly better to have an intermediate language and a modular design to compile to it and from it, but I thought this was introduced by LLVM and not gcc because (1.) compiler performance mattered more at the time, so it was better to couple everything to save some performance with dirty tricks, and (2.) people just hadn't realized that this was the right design. (The same way that it took time for the relational database abstraction to come around and replace the tendency for each program to use its custom internal database.)

Is there any specific reason to believe that gcc's design was influenced by licensing reasons?

See https://lwn.net/Articles/629259/

OK, I was wrong. Thanks for pointing this out. This is very interesting (and, in my opinion, quite depressing).

> Maybe I'm weird, but I'm still enthused about GCC.

I'm just as weird as you.

I am hoping to be able to devote some time this year to cross-pollinate with David Malcolm's work to get libgccjit working on GNU Octave:

https://savannah.gnu.org/patch/index.php?8395

I'm weird too, and I'd add that I think Autoconf is also awesome.

I think the idea of autoconf is great (test for features, not for versions). The implementation in m4 is sadness.

It's possible to do autoconf-style checks in other build systems, but not as easily. I don't know why most build systems seem to ignore the wisdom of autoconf.

m4 is actually pretty awesome when fulfilling its original purpose of adding macros to programming languages. Certainly it's not hygienic and is a pain to debug but it can work wonders to bypass language limitations especially when dealing with assembly code.

It's not that you are weird you just haven't looked too closely at clang :-)

On a more serious note, the whole "I feel <x> about GCC" has a certain challenge about it as GCC isn't a compiler so much as it is a very long story. I think I have pretty much had every emotion you can have with respect to GCC, whether it was admiration for supporting an obscure platform, hatred for a gratuitous interdependency on a library, or respect for a particularly clean compilation. But over its life it has gone in many directions and gone through many theories of how a compiler should be written, and some of those chapters are very dark indeed.

I was also amused that there is a link chain to the 'kissed a girl' email that Bryan Cantrill (CTO of Joyent) wrote back in 1996. Proof that the Internet really really doesn't like sarcasm.

Another reason to be enthusiastic about GCC is support for OpenMP.

There's another big reason to still be 'enthused' by GCC: without GCC we wouldn't have Linux. Or Mozilla/Firefox. Or virtually all of the shareware / freeware we largely take for granted, that frees users and developers alike from the domination of control-freak juggernauts like Apple and Microsoft and Oracle.

Every day I'm enthused by GCC and the freedoms it spawned.

That is a great point. ... and without Firefox, how painful would it have been to wrest control of the internet away from IE6? Would Apple have even had a chance, or would they be stuck with IE5.5 for Mac? What would they base Safari on, if there wasn't KHTML for KDE (which might not exist without gcc)? What if Apple couldn't make an independent phone / tablet with browser, would we all still be stuck with flash?

No way to really know what would have happened, but it's a bit scary.

(EDIT: I'm not a fan of Apple stuff due to their walled gardens, but I do recognize their role, along with Firefox, in saving us from an IE/flash internet and thus from a crazier Windows monoculture.)

I'm still enthused about GCC!!! :)

When I started using it, The alternatives were expensive. Even the educational version of Borland our university used was expensive (The mediocre book it came with was ~$300!!!)

It isn't as performant or as well tested as professional compilers (that cost tens of thousands or more!) You wouldn't expect it to be, would you?

> t isn't as performant or as well tested as professional compilers

I don't know how true this statement is. ICC has been found to be very lacking compared to both gcc and clang -- and I'd wager in-house testing doesn't compare to massive world-wide deployment of gcc and clang as far as rooting out tough bugs that crop up in weird circumstances.

> ICC has been found to be very lacking compared to both gcc and clang

Who found that? For processing intensive tasks, I routinely get a 30% reduction in run time using ICC - mainly owing to ICC's aggressive vectorization.

Rarely, I'll have to do some shenanigans to force it to work correctly. Very rarely.

I use clang when developing because the error messages are miles ahead of anybody else, then produce a 'stable' GCC version and an ICC version. If the ICC version produces the same results as the GCC version for the test suite, I exclusively use the ICC version.

In my experience, `icc/pc` and `ifort` give a significant speed boost for numerical code (on Intel hardware at least), but for more general purpose code it's not really very impressive.

However, the related products like `ipp` and `mkl` are where Intel has a real advantage. My experience has been that `mkl` in particular is dramatically faster than vanilla LAPACK and friends and still quite a bit faster than more optimized variants like ATLAS. But, you don't need to use the Intel compilers to use those libraries, you can use them with gcc as well.

"processing intensive tasks" may not be the one to expose all the corner cases of C and C++?

My professor in college made the statement and his class said "oh yeah right GCC is everywhere".

He spent the break writing tests for GCC and found errors in it's parse tree. He submitted bugs and patches cause good guy coder.

I think gcc is in some ways more tested than professional compilers given the huge range of code thrown at it. It can fall down in performance on workloads that things like ICC are tuned for, but performance is nearly always structural rather than micro-optimisable.

To be fair, the micro-optimizations are nice, and being able to just throw a switch and turn them on is nice. Of course you're right that a compiler is "never" (boy, prove me wrong, then shut up and take my money!) going to convert Array-of-Structs to Struct-of-Arrays code, for example.

FYI, LLVM was a byproduct of Chris Lattner's PhD thesis titled "Macroscopic Data Structure Analysis and Optimization", which aimed to do exactly that. It is still a great paper. Alas, it was found that doing the basics well is much harder and larger task than doing the proof of concept of very clever optimizations.

Jonathan Blow is doing some very exciting stuff in this area with his new language. Check out his latest talk on YouTube about data-oriented programming.

I was fortunate to be well supplied by government science departments with workstations of many flavours (DEC Ultrix, IBM AIX, SGI Irix, Sun 'Suntools', VMS). Due to these machines being setup the same way by some nice kind civil servants somewhere in England there was always a compiler on there with a few bookshelves of printed manual not far away.

I grew up with that expectation.

Imagine my shock when I properly made it into the real world and realised that all of these machines were useless without their government-special software suites. This I did not entirely mind at the time as this kept the barriers to entry up meaning that my skills and experience were of value, purely because they were gleaned from the privilege of having access to software and hardware beyond the affordable.

Nowadays I only use free open source software and this is how I like it. The idea of having to go through the hassle of licensing software and typing codes carefully into a screen does not do it for me. I am glad I don't have 2-3 hardware dongles on the printer port(!) of my Chromebook. Instead I have Ubuntu. Needless to say I don't compile often, if at all, however, to not have that feature would be a problem for me.

> You wouldn't expect it to be, would you?

Yes I would, especially since it's often made by the same people (Intel, IBM, Google)...

No reason to not keep improving gcc!

There is no reason to expect a product with $100M spent in testing by some of the highest paid mathematics and software engineers in the world to keep up with free software?

I say that is wrong. We should expect it to be better, and it is. The intel compiler is faster than GCC on Intel hardware and it always will be. Why? Because GCC can't keep up with the new hardware that comes out. Proprietary compilers have always had the upper hand because incredibly complicated optimizations are incredibly hard to reverse engineer.

> There is no reason to expect a product with $100M spent in testing by some of the highest paid mathematics and software engineers in the world to keep up with free software?

Are you aware that gcc has probably just as much if not more money poured into it? It's not a product of a bunch of hobbyists. Most of the gcc code is done by contributors who are paid to work on gcc. A lot of it is done precisely by companies who are interested in gcc generating the right code for niche hardware.

Sun removing the C compiler from Solaris pretty much made it obligatory for my whole university department to install GCC in the early 90s.

And if you're using a cross-platform compiler, you've no longer got any need for a particular OS to run your software on. And now there are thousands of university students and professors relying on gcc, and therefore willing to devote time and effort to improve it. And oh look - this Finnish kid has just released an open source Unix clone than runs gcc compiled software just fine, and it's free too!

I can't really say that this decission killed sun. I don't knoe how much revenue they got from selling cc, and they were probably toast anyway in the long run. Their main selling point was that they were the same as all the other versions of Unix.

It's the hardware costs that killed the unix vendors relative to commodity beige boxes, not the software Linux (and to some degree the BSD's) just gave a smoother path.

I recall seeing side by side memory quotes from Intel (i.e. an "expensive" vendor in the space, when they were shipping servers) and SGI for the same amount of memory on smallish servers - from memory the SGI was about $18k vs $500 for the intel. Staring at that difference it becomes pretty hard to justify, even if the memory bus was much better. I could buy a couple of new servers for the cost of that memory upgrade.

I suspect Sun's pulling the free c compiler was just one of many "cost cutting" (which end up being revenue cutting) decisions made by a company that saw the writing on the wall but couldn't see how to avoid it.

The sun C compiler was pulled in an era where the Unix workstations were (1) very clearly superior to PCs and (2) available with steep .edu discounts.

By 2000, the Unix workstation were not much faster outside of 3D hardware and floating points and the discounted price was well above the "equivalent" PC costs.

By 2005, the PCs had exceeded Unix workstations in every way.

The line is kinda blurry in my head but basically a 2004 vintage AMD CPU could do in software (using MesaGL) roughly the same OpenGL performance as a '98 vintage O2 could do with a decent frame buffer. Once the nVidia drivers became ubiquitous, that PC ran circle around all of our SGIs except for the Octane2s (at a 10:1 price differential.)

By 2006, we were down to a single Octane2 with a busted frame buffer being kept to avoid relicensing a numerical package for $$$$.

I want to say my quote comparison came from '96, but I could be off a bit. At any rate, the unix vendors still all had pretty significant hardware advantages over even the beefiest PC ... but the bang/buck was already pretty painful.

We had systems developed on Sun, but we couldn't afford to deploy them on Sun hardware. After briefly flirting with the idea that SunOS x86 would be a viable path, we gave up and moved to linux on commodity hardware. It was a new enough thing to do (in the market we were in) that we got a few raised eyebrows, but it turned out to be the right decision.

Yep, without .edu discount, by the time the P-Pro (mid/late 90s) came out the value proposition was really bad.

For integer performance RISC had no benefits left by 1996-1997. 300Mhz P2 (in a Compaq workstation) was at parity with a 250Mhz R10k (SGI O2). The P2 as a fully assembled system was priced less than the R10k CPU alone.

Only the huge amount of cash available to dot-coms propped up Sun then. With all the "you need sun servers for dot-coms" beliefs.

My current employer made the same call (Linux on commodity PC) around the same time for the same reasons. It took ~8-10 years for competitors to stop using the fact it was Linux based for FUD. Now the only issue we get is Windows-only shop (very common in our industry) complaining that we're the only non-Windows system they use.

Only the huge amount of cash available to dot-coms propped up Sun then. With all the "you need sun servers for dot-coms" beliefs.

I wonder if Sun would have been better off if this didn't happen.

Almost certainly. Sun kit was very reliable (there's more to building a server than putting a PC in a rackmount case) and for 5 or 10 years after the dotcom bust, they were competing with their own second-hand kit at fire sale prices, which was still perfectly good for the job it was sold for.

I remember, in 2003, going to a tech demo being put by SGI at our university. It was obvious that they'd been running this same demo for years, in part because some of their showcase graphics would have looked dated on my friend's Xbox. I knew from classmates that they're hardware was capable of more than was being shown, but I also got the feeling that they'd stopped pushing the envelope.

The other thing to remember is that SGI had gone through their disastrous pivot to a custom (i.e. unsupportable) version of Windows and switching to Intel's then-architecture of the future (Itanium), which was a huge write-off even for Intel[1].

That soaked up a huge amount of resources just to catch up to their existing products and, worse, was a message to their existing customers that the old SGI hardware was a dead-end and the new stuff was unproven, which lead most of them to migrate to standard PCs to avoid being locked into the fate of a single vendor.

It's possible that things could have been very different with better senior managers who could limited the number of simultaneous risky transitions or recognized that semiconductor economics would quickly give high-volume “toy” 3D accelerators a huge advantage over niche workstation hardware.

1. Seriously, check out the sales graphs – this is staggering flop given how much hype the entire industry got about Itanium and VLIW being the way, truth and light going forward: http://en.wikipedia.org/wiki/Itanium#mediaviewer/File:Itaniu...

The other thread mentions that they provided the first unbundled C compiler back in 1989, closer to the standardization of ANSI C, which is probably no coincidence as many compilers had to be revised to support it and another reason why GCC became popular. It was not until they moved to SVR4 with Solaris that they removed the bundled one however, after gcc 2.0 was released I think.

If BSD and Linux hadn't happened, Windows NT line would have taken all workstations market.

Perhaps. Having been there at the time, OS/2 was killed by linux. So... you're not going to run this new windows95 thing, eh? Then why bother running OS/2 when there's linux?

OS/2 was killed by IBM's near complete disinterest in promoting or supporting it.

1. They barely advertised it.

2. They did not buy good shelf placement in stores. The result was OS/2 was on the bottom shelf in the darkest row in the back of the store, where it would only be found by people who specifically came seeking t.

3. The developer support was terrible. Nothing sums it up better than a report from COMDEX from, if I recall correctly, Jerry Pournelle. He went to the Microsoft booth, where they were promoting the upcoming Windows 95. He asked them what it would take to get started developing for Windows 95. They handed him the SDK right there, no questions asked.

Then he went to the IBM booth, where they actually had an OS/2 display. He asked them what it would take to get started developing for OS/2. They handed him the paperwork to apply for the developer program. He started to fill it out, but it required him to explain his business plan for OS/2 software, and justify why he should be allowed to develop for their platform. He did not complete the form.

4. If you did persevere and become an OS/2 developer and release an application, IBM didn't care. Apple and Microsoft would provide money to promote major applications for their platforms, or applications that highlighted the advantages of their platforms. IBM did very little of this.

[1] Major retail software store back in the days before everything was distributed online, since online back then typically meant dial-up modem.

>1. They barely advertised it.

...does anyone remember the IBM OS/2 Fiesta Bowl?

http://en.wikipedia.org/wiki/1992_Fiesta_Bowl

Back then I remeber reading articles all the time about UNIX vs Windows NT.

OS/2 wasn't really a thing, at least not in Portugal. PC able to run it confortably cost at least 500€ more than the ones that would fly with Windows 3.1.

Sure it wasn't the same thing, but for the majority of the folks it was good enough for what they wanted a computer for.

Actually I would say when Linux came to be a thing, OS/2 was already gone.

I only saw OS/2 once live back in 1994 in the anual computer expo in Lisbon.

GNU/Linux in 1995 still wasn't for the faint of heart. My Slackware 2.0 took quite some effort to install.

OS/2 was not killed by linux. They barely co-existed.

OS/2 was killed when Microsoft, who schooled IBM and the rest of the world on execution, released Windows. Then MS and IBM "divorced".

Also having been there, my admittedly fading memory remembers OS/2 as doomed before Linux was really an function parity option. And OS/2 wasn't really put up as a alternative to Unix (certainly IBM didn't want to cannibalize AIX); rather it was the server OS and upgrade to Windows that Microsoft customers were screaming for. Microsoft effectively killed off OS/2 the day they said "forget about OS/2...what you really wan't is this nifty thing we've got cooking called NT", no matter the effort IBM continued to pour into it.

Yea, but that is only part of the story. This fiasco ended up being so bad it used to be one of my favorite topics. "Microsoft Munchkins" and DR-DOS are two of the reasons why.

That's why both Sun and SGI made last-ditch efforts to run on Intel hardware towards the end of their server/workstation production.

But that made it worse, they were selling x86 hardware for much higher prices than HP or Dell, without much advantage.

We should be. It's amazing that it's available free (x2). I remember when my choice of programming language was determined by which compiler I could get hold of. So I ended up using Turbo Pascal. The local library had some C books but I couldn't find a compiler. (TP had an amazing IDE though for its time...)

Honestly, GCC was a pretty good optimizing compiler even on RISC architectures. The one exception was on SPARC, because the optimizer didn't take advantage of the "register windows" feature, which arguably is the most un-RISCy aspect of the SPARC architecture.

RISC vendors often shipped carefully optimized floating point libraries, which would result in floating-point optimized code from their compilers outperforming gcc, but for fixed point performance GCC was often competitive and even superlative to the offerings from RISC vendors. If you look through the history of SPEC benchmarks, you'll see that for SPECint, GCC was as much the compiler of choice for RISC vendors as it was for CISC vendors.

In 1990-1991, in my first job, I insisted on using gcc on SunOS primarily because I wanted to use ANSI C89 features (primarily function prototypes). These were already available on the other two platforms we were targeting (the Microsoft C compiler, and Apple Macintosh Programmers Workbench), and the standard SunOS PCC-based compiler didn't support any of the new Standard C features.

Honest question about grammar (not a native speaker): is enthused correct here? Other than the fact that enthuse is a verb that was made up from enthusiasm, shouldn't this be "Why people were enthusiastic about…", "Why people enthused about…" or "Why people were enthused by…"?

It's correct. As an intransitive verb, the subject is the person feeling enthusiasm. "I'm enthused to be going to Disneyland!"

As a transitive verb, the subject is the thing causing enthusiasm. "Disneyland enthuses me!" (This formation does tend to be less common.)

Don't all verbs use have as the auxiliary in the present perfect tense? As such I am enthused would not be an intransitive verb, but either a nominal predicate or a passive verbal predicate. A correct intransitive form would be "I've enthused about going to Disneyland".

In the first case enthused should be replaced by enthusiastic, which is the correct adjective, in the second case you would use by rather than about as a preposition for the agent. Correct?

You'll just never find anyone using this verb in spoken English...

Yes, it's correct, at least my dictionary says so.

Where does the author establish that people are not enthused about gcc anymore? Or does he not even imply that?

No, he's providing an alternative reason for gcc's popularity in response to Rob Landley's email[1] that asserts that it was due to developers determined "to avoid paying Ed Zander extra for Sun's Solaris compiler."

[1] http://article.gmane.org/gmane.linux.toybox/1890

I do remember something about SGI making you pay extra for the C compiler for IRIX. Perhaps they only made it free for universities.

Yup, they used MIPSpro compiler but it cost extra. And my recollection was that gcc wasn't fully functional without MIPSpro installed.

You didn't get the system include files without having the compiler so, yes, gcc wasn't a full solution. Also missing without paying extra was troff so I had to use groff just to be able to format man pages (they mostly came preformatted).

It wasn't free for universities, but in the first half of the 90s, SGI offered so-called "Varsity" contracts, which was basically a campus license for OS updates and unbundled products like compilers, NFS/YP and the "Documenter's Workbench" (a fancy name for troff/nroff).

That was not the case when I used Irix (commercially), or later when I worked at SGI. Perhaps you mean "Son of SGI", the company that once was Rackable Systems?

Sun did the same thing on Solaris (charging extra for the compiler).

In college, I was excited about GCC because it was free as in beer, worked well, and the other compilers we could use were hundreds or thousands of dollars.

tldr: gcc was a good compiler compared with the existing alternatives, so people used it. It also was free.

Reply on news.ycombinator.com