The local CompUSA here has several modern Macs running Mac OS X. I pulled up the console (terminal.app) and poked around a bit. It's very much like the NeXT unix machines I've used in the past. Even pico was installed by default, heh.
However...
CompUSA didn't have the developer tools (gcc, gdb, libs, the awesome GUI debugger and IDE, etc) installed. Have the manager fetch the CD or bring in your own:
Mac OS X is just as unix-ish as the NeXT OSes it's based on -- NEXTSTEP/OPENSTEP. True, in many ways it doesn't look like a traditional unix, especially regarding filesystem layout and the use of NetInfo. Like NEXTSTEP and OPENSTEP, it has its quarks, but for the most part, things work. It's Unix, but it's a funky Unix. And if you don't want to pay for it, you can run the bare guts, the opensource non-GUI version, Darwin. (even on x86)
NeXT machines came in two formfactors: cube and slab. The cube was 12 inches on each side. The slab was a pizzabox 14" deep, 14" wide, and 2.5" tall. Where I come from, that'd be a pretty tiny fridge. I used a Turbo Color NeXTstation for three years, almost zero footprint as it sat under my 17" monitor. Classy as all heck.
This is not a computer for geeks. It's certainly not the computer for schools. And I can't imagine most households wanting something like this when room is plentiful and 18" LCDs (or 21" CRTs) are cheaper than ever. Even die-hard Mac fans are unimpressed.
So, who is Apple targeting? I feel this may set them back *much* further than the Cube.
Current OSs can transfer large amounts of data, it's the broadband connections that are lagging behind... My P-90
can easily handle the 128Kb/s uplink my DSL provides... And the number of people paying for Broadband is not
increasing at the rate everyone expected... The research needs to be how to get faster broadband at a cheaper price.
The spread is even more than that. In 1994 we had two T1s to the internet via uunet. One was dedicated to our webserver... a P60 running Windows NT3.5 and Netscape Enterprise Webserver. About 75% of our content was static, but there was a good amount of CGIs and background tasks (email, dns, and ftp daemons). And yet, our P60 worked like a charm. Sure, we should have used Linux or maybe even Solaris on a SPARC, something a bit more suited to the task... but it worked, even when the T1 was fully saturated.
... but this sounds like more of a PR op than anything else. Since when has a game console shuffled more data than a workstation or even a desktop computer? And since when has a TV (even an HDTV) been higher resolution than a 21" monitor?
It's PR BS, but hopefully the OS will have some merit. Choice is good.
Once we get the 64-bit hardware, we still have the MMOS (minor matter of software) to worry about.
Cases in point:
Silicon Graphics machines with MIPS R4400 (and up) CPUs were 64-bit, but the additional address and pointer space wern't utilized until IRIX 6.0 in 1994 -- over 18 months later. (And, of course, certain SGIs still run in 32-bit mode due to RAM concerns -- 64-bit requires more RAM -- all Indys, all Indigos, all O2s, and R4400 Indigo2s).
Sun machines with UltraSPARC CPUs were 64-bit, but again, the additional address and pointer space had to wait for software support. (Multi-stage transition to 64-bit, starting with Solaris 2.5 and finally complete with Solaris 7 in 1998).
Then there's application optimization. Many apps can get slight speedups by processing data in larger (say, 38-bit or even 64-bit chunks). Sometimes the difference is huge, many times it's small. But, lots of little speedups can add up across an entire system. Still, someone has to make these changes to apps and compilers. It takes time, testing, and adoption. In better times, SGI did several such overhauls... they got some insane speed out of Netscape Enterprise and Netscape FastTrack web servers during the Everest project. One of their engineers also did some cool (but nonstandard) hacks to Apache, including the very first pure, clean 64-bit port/mod.
Newer, faster, wider, more-torque hardware is always great. But don't forget the software.
Been in 64-bit heaven since IRIX 6.0 in 1994. PowerIndigo2 (R8000) on the desktop, Challenge XL's in the server room (R4400 and R10000). And, today, Octane on the desktop and Origin 300 + Origin 3000 in the server room. A few UltraSPARC Suns, too, but Solaris took its sweet time making the move to 64 bit (Sun started the migration with Solaris 2.5 and finished with Solaris 7).
Re:Large biotech firms
on
Monsanto and PCBs
·
· Score: 5, Informative
Living near the Candian boarder I've been reading about this in our local newspapers. Seems a canadian farmer obtained some freshly harvested canola seed which he planted the very next year. Well, this wasn't the cheap stuff, it was Monsanto RoundUp-Ready canola (GM to resist RoundUp... spray field with RoundUp, kill everything but the canola... better yields, only downside is possible glyphophosphate poisoning). But, the license for Monsanto RR canola specifically states that it cannot be harvested for use as seed (that is, you have to keep buying your seed from Monsanto each year). Somone reported the farmer and Monstanto investiaged and sued. Farmer made some pretty weak excuses, but at least did grab some media attention.
What he did was illegal, but I don't blame him. Farming is hard business these days, especially when only certain crops get subsidies and the seed and fertiziler companies are out to suck the farmer's wallet dry.
Monsanto is the Microsoft of the ag world. They are constantly buying up smaller seed and chemical corporations and/or their patents. They have no regard for safety, only their bottom line financial figures. Some of their more scary research and development involves genetically engineered plants (and seed) that reacts to only certain (Monsanto-brand) chemicals and fertilizers.
This is certainly a company to be watching. At least Microsoft only fiddles around with computers and home entertainment gizmos. Monsanto plays god with our food supply at all levels. It's scary and it gets more scary each year.
I was under the impression that M$ UTV supported HDTV via DirecTVPlus/HD. But then, I could be wrong. I was also one of the many under the impression that the M$ XBox w/ HD breakout box would give me something better than plain 480i. Even 480p would be nice. *sigh*
Not totally useless, but not all that useful either.
80+ GB drives are quickly becoming the norm, and the typical "power user" has several. Still, a 40 GB drive could be useful in a low-use machine, such as a DNS server or a PC built from scraps for a newbie.
Might need to low-level format the drive after yanking it from the recorder, but that's easy with any decent disk utility software. Do a google search, this is nothing new.
This is an awesome hack! The high prices and small capacity of the M$ UTV bundled drives is what has kept me from buying just yet. I want at least 100 GB for plenty of standard TV shows as well as for high quality audio and/or HDTV for my movies and such. This is what I have been waiting for!
Exactly why you need a machine with gobs of bandwidth and the ability to sift through terabytes of textures as fast as your pentium can sift thru megabytes of text.
Given the history of Bali and Odyssey, it's hard to feel good about the future of SGI gfx pipes. IR4 won't be much of an upgrade and still isn't due for awhile. Nothing about Tyhpon impresses me. *Sigh*. All that I/O and 6-year-old gfx subsystems running on it. And shoot, even on a brand-new O3K, the IR3 pipe are interfaced thru O2K-era Xtown rather than O3K-era Xtown2. *sigh*
Oracle on IRIX is dead. Sybase is a totally different story. Sybase is excited about IRIX once again and they've been doing some impressive optimizations. I personally like Sybase better anyway, but it doesn't have the "impress the clients" ring that Oracle does. It's up to the PHB to decide what our next DB machine will be.
I have a friend who had an idea that could have saved them. When he was at SGI, he pointed out that machines
that were optimized for graphics had to have great I/O performance, which would also make them great
performers in another I/O intensive task: running RDMS engines like Oracle and Sybase. SGI management
wasn't interested.
Indeed true and indeed sad. Management ignored databases, stating that their focus was on the "technical and creative professional". Seems they ignored the fact that said pros need to store their data somewhere. Q: Where does PIXAR or ILM store its vast amounts of models, textures, and scenes? (Hint: it's not in a bunch of basic directories on a generic filesystem).
SGI failed to realize that databases are *big*, *everywhere*. Oracle on SGI IRIX is dead, but that's almost ok... Oracle 8 was nothing more than a quick port with zero optimization (other than some basic compiler flags -- hardly "optimized"). Sybase is a different story. Its IRIX version has risen from the ashes and is quite zippy. Current version makes good use of O200/O2K/O300/O3K architecture and future version will be even better.
In all honesty, I have never had a problem with IRIX stability. I have only experienced two kernel panics: one was related to failing hardware, the other to a brand-new graphics subsystem that had a major known bug (and subsequently fixed in the next quarterly OS release... there may already even been a patch for it at the time).
Thinking back on IRIX history, only a few issues come to mind... ballooning RAM usage starting with IRIX 5.X (gee, IRIX swaps to disk on machines with less than 32 MB of RAM) and patch dependancy hell starting with IRIX 4.X but fixed in 1998 with the IRIX 6.5.X quarterly release stream. There have been a few minor regressions over the years and some software issues with brand-new hardware, but almost all have been fixed within a month or two. Anyone deploying mission-critical hardware will fully test their setup before deployment and work closely with the vendor. Heck, I would trust IRIX just as much as any other UNIX flavor... maybe even moreso. As with any other OS, stability issues should be worked out with the vendor, not ignored.
SGI has always had a hard time trying to market itself. They've typically made endless incorrect assumptions and end up preaching to the choir. And yet, the wow factor that made the company and it's little cube logo a legend in the late 1980s is still there, abeit in a slightly different manner.
True, not everyone needs 512 or 1024 CPUs running on a single system under a single kernel. Or 16 graphics pipelines. But there are those that do. Which is why, shortly after the introduction of the Origin 3000 two years ago, an entire convoy of the machines were sent to Fort Meade.
It's almost as though SGI has gotten used to the high end, as though their technology (HW, SW, APIs, SDKs) no longer impress themsleves. Nowhere else, not even E&S, can a person find a platform that can drive up to 128 display channels (16 pipes x 8 channels per pipe) with perfect sync, or even at all. O2K and O3K (and more recently, O300 and Octane2) can drive multiple displays from one or more graphics pipelines. Raw, per-CPU performance isn't anything to write home about, but the thruput and latencies are perfect for generating insane 3D and mixing it with streams of HDTV... or anything. Think of a way-cool use of video and 3D. Now increase the complexity and choose, oh, 4 camera viewpoints. Maybe an additional display for stats and another for an "operators station". Easy with O2K/O3K (aka "Onyx" when gfx are invloved). It can be done and it's proven. They've been doing this sort of thing since you and I were using our "cutting edge" unaccelerated 2D graphics cards running at an "insane" 1024x768.
A pair of old demos SGI likes to show off are sometimes called "from space to your face", in which over 500 GB of sat photo textures are shuffled thru one or more InfiniteReality graphics pipes to provide a realtime "bungie jump" from the moon to earth and back. INSANE. 60fps/60hz locked. 4 huge disk RAIDs composed of dozens of drives grinding away like mad to keep the textures coming. WILD STUFF. All in a day's work.
SGI isn't about buzzwords or about wizbang marketing. It's about providing modular solutions to some of the most challenging problems. They've been there to provide HW and SW to those wishing to work on the cutting edge. In 1988 they were selling 3D workstations. In 1991 folks were doing crazy 3D and video mixing. Today their hardware can be used to drive gobs of displays and to shuffle huge amounts of data. Sure, the desktop PC in 2007 will be able to do the same thing. By then, PCs will be able to drive gobs of high end gfx subsystems, and even a cheap graphics card won't sneeze at several GB of textures loading and unloading every second... but until then, for those that need this TODAY, there's SiliconGraphics.
Let's hope SGI is here tomorrow to show us even more cool things.
It's UNIX. Sure, it's a *flavor* of UNIX, but its genetic makeup is 99% indentical to every other flavor out there. Golly, even the "SGI GUI" is just a modified version of Motif plus HTML and vector icon libraries, all of which are well documented. Over the past 10 years I've ported code (graphical, non-graphical, and device drivers) to and from IRIX with very few problems. And heck, most of the problems had to deal with REACT, SGI's real-time kernel extensions... something that nobody else in the UNIX arena had at the time (they're just now catching up).
SGI hardware isn't cheap, but it's worth every penny to those that need it. The same goes for the support contracts (which are cheap if you consider the short response times and 24/7 electronic monitoring). And for the high-dollar customers, SGI Custom Engineering is actually a bargain if you compare their services to that of other companies. For almost any user, the SGI developer program (www.sgi.com) offers A LOT for the price (nothing, it's free)... compilers, 40% - 70% hardware discounts, support & training discounts, and gobs of co-marketing opportunities. Plus they listen. Aside from two less-than-satasfactory incidents, my group has had no trouble talking to real SGI engineers when their help was needed. SGI management and executives have also always been willing to lend an ear. Of course... listening and *doing* are two totally different things, but I think the company is finally pulling its head out of its rear.
Slashdot Mirror
The local CompUSA here has several modern Macs running Mac OS X. I pulled up the console (terminal.app) and poked around a bit. It's very much like the NeXT unix machines I've used in the past. Even pico was installed by default, heh.
However...
CompUSA didn't have the developer tools (gcc, gdb, libs, the awesome GUI debugger and IDE, etc) installed. Have the manager fetch the CD or bring in your own:
http://developer.apple.com/tools/macosxtools.html
Mac OS X is just as unix-ish as the NeXT OSes it's based on -- NEXTSTEP/OPENSTEP. True, in many ways it doesn't look like a traditional unix, especially regarding filesystem layout and the use of NetInfo. Like NEXTSTEP and OPENSTEP, it has its quarks, but for the most part, things work. It's Unix, but it's a funky Unix. And if you don't want to pay for it, you can run the bare guts, the opensource non-GUI version, Darwin. (even on x86)
Here are three better URLs:
http://developer.apple.com/unix/index.html
http://developer.apple.com/darwin/
http://www.opensource.apple.com/projects/darwin/
... so Silicon Graphics can go back to the "cube" logo!
http://www.bluesnews.com/archives/carmack122396.ht ml
Now, I know D3D has undergone many changes since then, but without a 100% about-face, I doubt they could fix the major coding issues.
NeXT machines came in two formfactors: cube and slab. The cube was 12 inches on each side. The slab was a pizzabox 14" deep, 14" wide, and 2.5" tall. Where I come from, that'd be a pretty tiny fridge. I used a Turbo Color NeXTstation for three years, almost zero footprint as it sat under my 17" monitor. Classy as all heck.
The iMac only Jobs could love.
Seriously.
This is not a computer for geeks. It's certainly not the computer for schools. And I can't imagine most households wanting something like this when room is plentiful and 18" LCDs (or 21" CRTs) are cheaper than ever. Even die-hard Mac fans are unimpressed.
So, who is Apple targeting? I feel this may set them back *much* further than the Cube.
I wish Apple good luck, they need it.
Am I the only one that wishes Apple would dump Ive's "style" in favor of the classy NeXT machines?
Current OSs can transfer large amounts of data, it's the broadband connections that are lagging behind... My P-90 can easily handle the 128Kb/s uplink my DSL provides... And the number of people paying for Broadband is not increasing at the rate everyone expected... The research needs to be how to get faster broadband at a cheaper price.
The spread is even more than that. In 1994 we had two T1s to the internet via uunet. One was dedicated to our webserver... a P60 running Windows NT3.5 and Netscape Enterprise Webserver. About 75% of our content was static, but there was a good amount of CGIs and background tasks (email, dns, and ftp daemons). And yet, our P60 worked like a charm. Sure, we should have used Linux or maybe even Solaris on a SPARC, something a bit more suited to the task... but it worked, even when the T1 was fully saturated.
... but this sounds like more of a PR op than anything else. Since when has a game console shuffled more data than a workstation or even a desktop computer? And since when has a TV (even an HDTV) been higher resolution than a 21" monitor?
It's PR BS, but hopefully the OS will have some merit. Choice is good.
Once we get the 64-bit hardware, we still have the MMOS (minor matter of software) to worry about.
Cases in point:
Silicon Graphics machines with MIPS R4400 (and up) CPUs were 64-bit, but the additional address and pointer space wern't utilized until IRIX 6.0 in 1994 -- over 18 months later. (And, of course, certain SGIs still run in 32-bit mode due to RAM concerns -- 64-bit requires more RAM -- all Indys, all Indigos, all O2s, and R4400 Indigo2s).
Sun machines with UltraSPARC CPUs were 64-bit, but again, the additional address and pointer space had to wait for software support. (Multi-stage transition to 64-bit, starting with Solaris 2.5 and finally complete with Solaris 7 in 1998).
Then there's application optimization. Many apps can get slight speedups by processing data in larger (say, 38-bit or even 64-bit chunks). Sometimes the difference is huge, many times it's small. But, lots of little speedups can add up across an entire system. Still, someone has to make these changes to apps and compilers. It takes time, testing, and adoption. In better times, SGI did several such overhauls... they got some insane speed out of Netscape Enterprise and Netscape FastTrack web servers during the Everest project. One of their engineers also did some cool (but nonstandard) hacks to Apache, including the very first pure, clean 64-bit port/mod.
Newer, faster, wider, more-torque hardware is always great. But don't forget the software.
Been in 64-bit heaven since IRIX 6.0 in 1994. PowerIndigo2 (R8000) on the desktop, Challenge XL's in the server room (R4400 and R10000). And, today, Octane on the desktop and Origin 300 + Origin 3000 in the server room. A few UltraSPARC Suns, too, but Solaris took its sweet time making the move to 64 bit (Sun started the migration with Solaris 2.5 and finished with Solaris 7).
Living near the Candian boarder I've been reading about this in our local newspapers. Seems a canadian farmer obtained some freshly harvested canola seed which he planted the very next year. Well, this wasn't the cheap stuff, it was Monsanto RoundUp-Ready canola (GM to resist RoundUp... spray field with RoundUp, kill everything but the canola... better yields, only downside is possible glyphophosphate poisoning). But, the license for Monsanto RR canola specifically states that it cannot be harvested for use as seed (that is, you have to keep buying your seed from Monsanto each year). Somone reported the farmer and Monstanto investiaged and sued. Farmer made some pretty weak excuses, but at least did grab some media attention.
What he did was illegal, but I don't blame him. Farming is hard business these days, especially when only certain crops get subsidies and the seed and fertiziler companies are out to suck the farmer's wallet dry.
Monsanto is the Microsoft of the ag world. They are constantly buying up smaller seed and chemical corporations and/or their patents. They have no regard for safety, only their bottom line financial figures. Some of their more scary research and development involves genetically engineered plants (and seed) that reacts to only certain (Monsanto-brand) chemicals and fertilizers.
This is certainly a company to be watching. At least Microsoft only fiddles around with computers and home entertainment gizmos. Monsanto plays god with our food supply at all levels. It's scary and it gets more scary each year.
As of yet, UTV doesn't do HDTV
I was under the impression that M$ UTV supported HDTV via DirecTVPlus/HD. But then, I could be wrong. I was also one of the many under the impression that the M$ XBox w/ HD breakout box would give me something better than plain 480i. Even 480p would be nice. *sigh*
Not totally useless, but not all that useful either.
80+ GB drives are quickly becoming the norm, and the typical "power user" has several. Still, a 40 GB drive could be useful in a low-use machine, such as a DNS server or a PC built from scraps for a newbie.
Might need to low-level format the drive after yanking it from the recorder, but that's easy with any decent disk utility software. Do a google search, this is nothing new.
This is an awesome hack! The high prices and small capacity of the M$ UTV bundled drives is what has kept me from buying just yet. I want at least 100 GB for plenty of standard TV shows as well as for high quality audio and/or HDTV for my movies and such. This is what I have been waiting for!
The name of the game is "Where's Waldo"
Exactly why you need a machine with gobs of bandwidth and the ability to sift through terabytes of textures as fast as your pentium can sift thru megabytes of text.
Given the history of Bali and Odyssey, it's hard to feel good about the future of SGI gfx pipes. IR4 won't be much of an upgrade and still isn't due for awhile. Nothing about Tyhpon impresses me. *Sigh*. All that I/O and 6-year-old gfx subsystems running on it. And shoot, even on a brand-new O3K, the IR3 pipe are interfaced thru O2K-era Xtown rather than O3K-era Xtown2. *sigh*
Oracle on IRIX is dead. Sybase is a totally different story. Sybase is excited about IRIX once again and they've been doing some impressive optimizations. I personally like Sybase better anyway, but it doesn't have the "impress the clients" ring that Oracle does. It's up to the PHB to decide what our next DB machine will be.
I have a friend who had an idea that could have saved them. When he was at SGI, he pointed out that machines that were optimized for graphics had to have great I/O performance, which would also make them great performers in another I/O intensive task: running RDMS engines like Oracle and Sybase. SGI management wasn't interested.
Indeed true and indeed sad. Management ignored databases, stating that their focus was on the "technical and creative professional". Seems they ignored the fact that said pros need to store their data somewhere. Q: Where does PIXAR or ILM store its vast amounts of models, textures, and scenes? (Hint: it's not in a bunch of basic directories on a generic filesystem).
SGI failed to realize that databases are *big*, *everywhere*. Oracle on SGI IRIX is dead, but that's almost ok... Oracle 8 was nothing more than a quick port with zero optimization (other than some basic compiler flags -- hardly "optimized"). Sybase is a different story. Its IRIX version has risen from the ashes and is quite zippy. Current version makes good use of O200/O2K/O300/O3K architecture and future version will be even better.
It's looking up, but ever so slowly.
Reminds me of the "Indizone" 3D games contests SGI had years ago (from 1993 to 1995, I belive... in conjunction with Indy and Indigo2 marketing).
Cool that they're actually recognizing hobbyists and the fun that once accompanied SGI and its products.
Maybe there's still a chance the fun can return...
In all honesty, I have never had a problem with IRIX stability. I have only experienced two kernel panics: one was related to failing hardware, the other to a brand-new graphics subsystem that had a major known bug (and subsequently fixed in the next quarterly OS release... there may already even been a patch for it at the time).
Thinking back on IRIX history, only a few issues come to mind... ballooning RAM usage starting with IRIX 5.X (gee, IRIX swaps to disk on machines with less than 32 MB of RAM) and patch dependancy hell starting with IRIX 4.X but fixed in 1998 with the IRIX 6.5.X quarterly release stream. There have been a few minor regressions over the years and some software issues with brand-new hardware, but almost all have been fixed within a month or two. Anyone deploying mission-critical hardware will fully test their setup before deployment and work closely with the vendor. Heck, I would trust IRIX just as much as any other UNIX flavor... maybe even moreso. As with any other OS, stability issues should be worked out with the vendor, not ignored.
SGI has always had a hard time trying to market itself. They've typically made endless incorrect assumptions and end up preaching to the choir. And yet, the wow factor that made the company and it's little cube logo a legend in the late 1980s is still there, abeit in a slightly different manner.
True, not everyone needs 512 or 1024 CPUs running on a single system under a single kernel. Or 16 graphics pipelines. But there are those that do. Which is why, shortly after the introduction of the Origin 3000 two years ago, an entire convoy of the machines were sent to Fort Meade.
It's almost as though SGI has gotten used to the high end, as though their technology (HW, SW, APIs, SDKs) no longer impress themsleves. Nowhere else, not even E&S, can a person find a platform that can drive up to 128 display channels (16 pipes x 8 channels per pipe) with perfect sync, or even at all. O2K and O3K (and more recently, O300 and Octane2) can drive multiple displays from one or more graphics pipelines. Raw, per-CPU performance isn't anything to write home about, but the thruput and latencies are perfect for generating insane 3D and mixing it with streams of HDTV... or anything. Think of a way-cool use of video and 3D. Now increase the complexity and choose, oh, 4 camera viewpoints. Maybe an additional display for stats and another for an "operators station". Easy with O2K/O3K (aka "Onyx" when gfx are invloved). It can be done and it's proven. They've been doing this sort of thing since you and I were using our "cutting edge" unaccelerated 2D graphics cards running at an "insane" 1024x768.
A pair of old demos SGI likes to show off are sometimes called "from space to your face", in which over 500 GB of sat photo textures are shuffled thru one or more InfiniteReality graphics pipes to provide a realtime "bungie jump" from the moon to earth and back. INSANE. 60fps/60hz locked. 4 huge disk RAIDs composed of dozens of drives grinding away like mad to keep the textures coming. WILD STUFF. All in a day's work.
SGI isn't about buzzwords or about wizbang marketing. It's about providing modular solutions to some of the most challenging problems. They've been there to provide HW and SW to those wishing to work on the cutting edge. In 1988 they were selling 3D workstations. In 1991 folks were doing crazy 3D and video mixing. Today their hardware can be used to drive gobs of displays and to shuffle huge amounts of data. Sure, the desktop PC in 2007 will be able to do the same thing. By then, PCs will be able to drive gobs of high end gfx subsystems, and even a cheap graphics card won't sneeze at several GB of textures loading and unloading every second... but until then, for those that need this TODAY, there's SiliconGraphics.
Let's hope SGI is here tomorrow to show us even more cool things.
Proprietary OS and software.
It's UNIX. Sure, it's a *flavor* of UNIX, but its genetic makeup is 99% indentical to every other flavor out there. Golly, even the "SGI GUI" is just a modified version of Motif plus HTML and vector icon libraries, all of which are well documented. Over the past 10 years I've ported code (graphical, non-graphical, and device drivers) to and from IRIX with very few problems. And heck, most of the problems had to deal with REACT, SGI's real-time kernel extensions... something that nobody else in the UNIX arena had at the time (they're just now catching up).
SGI hardware isn't cheap, but it's worth every penny to those that need it. The same goes for the support contracts (which are cheap if you consider the short response times and 24/7 electronic monitoring). And for the high-dollar customers, SGI Custom Engineering is actually a bargain if you compare their services to that of other companies. For almost any user, the SGI developer program (www.sgi.com) offers A LOT for the price (nothing, it's free)... compilers, 40% - 70% hardware discounts, support & training discounts, and gobs of co-marketing opportunities. Plus they listen. Aside from two less-than-satasfactory incidents, my group has had no trouble talking to real SGI engineers when their help was needed. SGI management and executives have also always been willing to lend an ear. Of course... listening and *doing* are two totally different things, but I think the company is finally pulling its head out of its rear.
reality is up for approx. 10 billion years now and AFAIK it's still running
Yeah, but most of us are out of touch with it...