Slashdot Mirror

..at least you didn't purchase an sgi prism which probably cost us $15k+, has dual ati firegl's, uses the same shitty fglrx drivers, with all the same shitty problems found on ati's unofficial bugzilla.

Intel architecture can't provide more than 16 cores

Sure its a provocative statement, and mod me down if you are whiny enough to do it, but Apple has proprietary unix-like software, running on proprietary hardware. The operating system (OSX-Darwin) sure as hell isn't even close to being in the same league as eg: Solaris or Linux (both of which beat the pants off OSX in real terms that real computer scientists can measure). Then there is the closed-software mentality. Sure you can get the whole iLife package. What the hell is the accountant supposed to do with that? What about massive data needs? Does the whole 'Apple experience' run on hardware like this? No? Please note too, the operating system these 512 processor, 128TB of globally shared memory machines run on! Does Apple sell that kind of hardware? No? What about for databases and enterprise CRM? What about stripping functionality to the needs of the business? Does the warehouse really need a built-in webcam? Is it all about 'one size fits all'? In truth, Apple is trying to be a late-model proprietary unix vendor (only it isn't calling itself that). Only it doesn't have the performance of proprietary unix, doesn't scale like unix (or Linux), isn't customizable like traditional hardware/software offerings, and is more expensive than traditional PCs (even more so than microsoft). As for Linux, remember, this is an enterprise environment. Do you look after your computer at work? I wish the writers of articles like these would actually think a bit (at least for 5 minutes per day).

http://www.sgi.com/tech/stl/basic_string.html

Oh, I'm sorry you completely brainless boob, but several points: Linux runs on supercomputers... MOST OF THEM, including all of the top ten for the past several years. SUPERCOMPUTERS EAT MAINFRAMES FOR BREAKFAST LUNCH AND DINNER! The throughput of a measly little mainframe IS PITHY COMPARED TO A SUPERCOMPUTER! Secondly, there is NOTHING wrong with the uptime of Linux. Years, decades, no problem. As for 'typical linux box' do you mean this: http://www.sgi.com/products/servers/altix/4000/ ?
You make it sound like something from microsoft, and are WAY OUT TO LUNCH! As for COBOL, it does nothing that ANY OTHER MODERN LANGUAGE CAN ALSO DO! Read carefully about what "TURING COMPLETE" means before spouting off again. You may have never heard of it before, but your level of education may be your limiting factor. Oh ,and BTW, Linux runs very well on IBM mainframes too (when Linux was ported to the mainframe, sales of mainframes went up for the first time in years). Be careful about biting the hand that feeds you! Upmty indeed, what a clod!

so it's not like we're going to see an Indiana Jones trying to come to terms with teh Intarwebs.

In fact, 12-year olds do know UNIX (I did), and even better, what I knew back then still applies nearly perfectly to today's UNIX systems, decades later. In fact, it even applies to Macintosh, while little of the original Macintosh survives. And the UNIX command line is highly consistent. UNIX is probably the single best choice the script writers could have made for the movie plot, since, although it may seem a little confusing to the likes of Nielsen and home users, among existing, widely-used operating systems, it has the longest-lived and most consistent design and conventions.

The UNIX command line was really the first user-friendly user interface actually put into large scale use, at least it's the first one I know of designed for users who had to run multiple programs to do their work, rather than being designed around efficiently running standalone applications over and over again.

Now, 36 years later, the consistency at the command line level is still there, even on Mac OS X.

As for "this is a UNIX system"... that 3d user interface was SGI's 3d navigator. It's completely reasonable for a kid who'd been exposed to SGI's version of UNIX would find it familiar.

you could link to the real thing

it exists

That program does exist. It is called "3D File System Navigator for IRIX 4.0.1+"
More information on this page

Similar systemes do exist like the linux clone called fsv

The C++ revision committee is dominated by people who want to do l33t things with templates, things nobody will ever do in production code but, they think, are really cool. There's a whole "generic programming" cult of abusing the template mechanism to do computation at compile time.

I saw the method used in the SGI OpenGL sample implementation. It was quite a while ago.

http://oss.sgi.com/projects/ogl-sample/

Anyone have access to the version control for this at SGI?

Between 1998 and now, SGI has had to rent space out to Google to stay afloat, has been delisted, gone through at least three separate downsizings (including several executive changes), and has filed for bankruptcy. The point is, SGI has tried the "sue to keep afloat" pattern before, and it didn't work then. I doubt very much it'll work now. SGI produces fast Linux boxes, for sure, but it competes in a very hard market.

Between 1998 and now, SGI has had to rent space out to Google to stay afloat, has been delisted, gone through at least three separate downsizings (including several executive changes), and has filed for bankruptcy. The point is, SGI has tried the "sue to keep afloat" pattern before, and it didn't work then. I doubt very much it'll work now. SGI produces fast Linux boxes, for sure, but it competes in a very hard market.

No, sorry, lots of raytracers did not use floating point framebuffers. Much of the pipeline might have been in floating point, but when it came to store the data, they did so in fixed point (0-255) RGB (it's also questionable as to whether a targa file is a framebuffer). The patent's actually reasonably specific - down to pixel formats. Admittedly, it does claim as broadly as possible, but that is pretty standard.

If ATI is infringing on some of the later claims, eg., they're using a pixel format of s10e5, then there's a problem. I think that might be why they're only suing now. If you bother to look, you'll notice that ATI started off using s16e7 floating point in their graphics cores. nVidia started with support for s10e5 and s23e8 (both explicitly in the claims), so we might assume that nVidia licensed from SGI at this point (In fact: http://www.sgi.com/company_info/newsroom/press_rel eases/2006/october/ati.html 'SGI has licensed this technology to ATI's major competitors...' basically says that nVidia have). ATI have now added support for pixel formats which infringe on SGI's patent, which is clearly documented in the ARB note. SGI don't (the Prism is now legacy) sell any products with ATI hardware in. SGI sue.

If this is true then:

1) It explains why nVidia aren't getting sued.
2) It explainy why ATI weren't being sued, but now they are.
3) The infringement claimed is about a specific implementation rather than the general concept.

Oh, and yes, they're still shipping new products - there being an announcement for some the day after they announced suing ATI.

SGI owns US Patent #6,650,327, issued November 18, 2003. SGI
        believes this patent contains necessary IP for graphics systems
        implementing floating point (FP) rasterization and FP framebuffer
        capabilities.

SGI owns US Patent #6,650,327, issued November 18, 2003. SGI
        believes this patent contains necessary IP for graphics systems
        implementing floating point (FP) rasterization and FP framebuffer
        capabilities.

From the looks of things the business model has been shifted out of the graphics market and into the server market. Probably explains why there is no silicon graphics in SGI anymore... From there site:
"Expanding Focus: Enterprise Data Management
As it redoubles its focus on solving problems for customers in its core technical markets, the new SGI business model - and its expanded potential within new and existing customer organizations - is built in part around solutions that help enterprises address the data explosion underway within companies worldwide."

Go and have a look here if you haven't already. There's some great stuff.

XFS is an awesome filesystem, and has been ranked the overall best in at least two fs benchmarks:- here, and here. Given what I've read here, I'm possibly considering making it my own default fs...at least for some things.

There's also some OpenGL related projects, as well as some kernel work. What this could also mean for them is that even if they do have to sell SUSE clusters, they can still have some individuality in the offering. Sure, anyone can burn xfsprogs to a CD...but SGI can still market themselves as the people who invented the fs, and thus the people who are most intimate with the code, and thus who can possibly most quickly/easily extend it, or fix it if something breaks.

Considering that SGI has already announced the end of IRIX production:

http://www.sgi.com/support/mips_irix.html

I doubt you'll see many new OS features, if they update at all it will most likely be security updates.

Will this reorganization put them back as a player in the graphics game?

That's the cost of claiming conformance to the OpenGL standard--I'm not sure how legal that is--or using OpenGL trademarks; or for closed-source implementations by hardware developers, or for implementations by hardware developers for closed-source platforms.

Check the SGI OpenGL FAQ for more information. It's ambiguous as to whether an open source driver project would require the fee; however, since the fees are associated closely with closed-source development, I'm guessing that there would be no additional charge.

Just like in Jurassic Park you didn't see a migration back to Unix because the park ran it, or a huge migration away because the park failed because of it.

I dunno... SGI is not doing so hot right now.

"No I'm not kidding, give me one example of a Linux or Windows running on a 16 way SMP box."

I don't need to. An example was already posted by another before you even posted this question. http://www.sgi.com/products/servers/altix/4000/

Why did you ignore this example?

Here's the Windows 2003 spec. Up to 64-way: http://www.microsoft.com/windowsserver2003/evaluat ion/sysreqs/default.mspx

Windows NT was SMP from the very beginning.

"It's been talked about how do we identify cpus. You would go with the external interface."

Of course I would. So would any other sane person. The instruction set defines what the processor does.

"If an external instruction set is deconstructed to lower level op codes is the cpu still an x86."

Yes it is, provided it's the CPU doing the deconstruction. Instruction decode is the first step of execution in any processor. Doing so doesn't somehow make the processor "not x86".

"Take a look at the P4 design docs, they talk about micro op codes as do most cpus that try to maintain backward compatability for their instruction set."

Yeah, so? Are you arguing that NetBurst is really a different processor masquerading as x86? It isn't. It was specifically designed to run x86 and nothing else.

Let's look at this another way. If a processor runs x86 code without emulation then it's x86. There are two processors that don't directly run x86 that are worth considering. Transmeta is the first (and they made more than one). Transmeta had emulation software that was loaded to run x86 and could theoretically run other instruction sets or even it's own internal one. Thing is that never happened. The other is Itanium. Itanium ran x86 only partially in hardware and required software emulation assistance. All other x86 processors execute x86 code natively starting with the first instruction coming out of reset. If that isn't x86 then I can't imagine what would satisfy you.

"...you might stop being so rude when you have a perceived cloak of anonimity to protect you."

I have no more a cloak than you do. I'm not posting as an AC and I'm not the only one hurling insults. Let's just say "I've now got my fingers crossed your not some big name CompuSci guy :-)" Smiley indeed.

Linux SMP is being added as needed

Actually, the file viewer used in Jurassic Park was fsn from Silicon Graphics.

Incidentally, SGI provided the hardware for the Jurassic Park control room, not to mention it was also the hardware platform for the rendering farm. So it's not entirely too far-fetched to presume that the SGI techs assigned to the JP project might have shown someone the "really cool" file manager.

Except that software did exist... SGI made it for JP admittedly, but shortly afterwards released the binary for IRIX. So, it was a "Real UNIX" even if the 3D browser was pointless to use when you could open up a shell and type the path in a matter of seconds...

You can still get the app from here: http://www.sgi.com/fun/freeware/3d_navigator.html, but you need IRIX 5.3 or below.

Or, if you have an IRIX machine you can download the real thing from:
http://www.sgi.com/fun/freeware/3d_navigator.html

Clearly written by a boy who wasn't tall enough to reach the ticket counter when Jurassic Park was in theaters, to say nothing of Wargames.

Yeah, most of those movies are truly terrible (and how did they miss "The Net"?), but the 10-year-old girl in Jurassic Park (who's been of legal drinking age for almost 3 years!) was shown using a real app called FSN that was indeed contemporary with the SGI gear of 1993 - a far cry from the Macromedia Director abominations of Mission: Impossible, for sure.

And listing WarGames - blasphemy! OK, it's ridiculous that Matthew Broderick would leave the speech synthesizer on (unless he was blind), but we (er, some people) really did use wardialers back then (well, just called them dialers before WarGames...), and man that IMSAI rig was sweet, if a little dated by 1983. Considering that typewriters still vastly outnumbered PC's at the time, the Internet had just switched over to TCP/IP, and the notion of booking an airline reservation with a home computer (fraudulently or not) was gee-whiz stuff, I'm willing to cut this movie much slack.

-Isaac

last release 6.5.30 was on august 16, 2006. See improvements and new features here

How could you possibly know that? Do Sun have anything in the same league as an Altix?

And look how much good Altix's have done SGI.

http://www.sgi.com/company_info/newsroom/press_rel eases/2006/may/sgi_reorg.html

SGI doesn't have any valuable rights in OpenGL. The specification is a public document. The reference implementation is open source. You can't copyright an API (SCO and Microsoft have both tried and failed). There's a charge to use the OpenGL trademark in a closed-source implementation, and that's it.

SGI's higher level APIs, like Inventor and Performer, have little if any resale value.

They've been using 'Silicon Graphics' for several years now. They use 'Silicon Graphics' for their graphics offerings, and 'SGI' for their non-graphics stuff.

http://www.sgi.com/products/visualization/

Gee, I had my Slashdot article on the SGI bankruptcy rejected back on May 8th when it actually happened. Two months later, the bankruptcy gets a mention on Slashdot.

SGI's main remaining business is real estate. They own many buildings in Mountain View, most of which they lease to Google. Due to some bad decisions (like signing up for a 55-year land lease in 1995) SGI loses money on that deal. Then they tried a sale/leaseback deal with Goldman Sachs and dug themselves a bigger hole by locking in their rent at the top of the dot-com boom. A friend at Google says that SGI is a "great landlord", though.

SGI doesn't really have much left in the way of manufacturing facilities. The only thing left is Chippewa Falls, the old Cray facility. They had 1,858 employees left at the start of the bankruptcy. SGI had way too much legacy administrative overhead. They had 18 different corporate entities, from Cray to MIPS to Parallel to Alias/Wavefront, and 43 more marketing subsidiaries in various countries. Most of those organizations will disappear in the bankruptcy.

From the filing: In the last several years, SGI has faced a number of challenges, which, taken together, have had a negative impact on SGI's overall financial performance. In the late 1990's, SGI made a series of investments in strategies and technologies that yielded less than the expected results.

Er, right.

Realistically, what happened is that SGI was totally unable to cope with their high-margin business becoming a low-margin business. Few companies succeed at that transition, IBM being a notable exception. And even IBM finally bailed out of PCs.

SGI already did this with their (a PDF, it's all that's left apparently) CADduo offering.

The original press release from SGI is here: http://www.sgi.com/company_info/newsroom/press_rel eases/2006/may/speedo.html

Why does Roland Piquepaille always point to a copy of these pressreleases surrounded by a lot of ads.

It would take 5 seconds to find the original info.

Please mod up so this gets some visibility, and hopefully better submissions.

For a better understanding of what you are referring to as XFS zeroing:
http://oss.sgi.com/projects/xfs/faq.html#nulls

To see how XFS can now be configured to reduce corruption due to power failure, see:
http://oss.sgi.com/projects/xfs/faq.html#wcache

For a better understanding of what you are referring to as XFS zeroing:
http://oss.sgi.com/projects/xfs/faq.html#nulls

To see how XFS can now be configured to reduce corruption due to power failure, see:
http://oss.sgi.com/projects/xfs/faq.html#wcache

SGI do a Linux solution i think. Let me check... Yeah - http://www.sgi.com/products/storage/tech/dmf.html It's pretty cool tech. Runs totally transparent.

Give me a moment, and I'm sure I'll think of one.

Here is an interesting article I saw in Doom3World.org: http://www.doom3world.org/phpbb2/viewtopic.php?t=1 0673 Check the fourth post. Here are some interesting links about ClipMapping/ClipTexture: http://www.cs.virginia.edu/~gfx/Courses/2002/BigDa ta/papers/Texturing/Clipmap.pdf http://www.sgi.com/products/software/performer/pre sentations/clipmap_intro.pdf http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc .cgi?coll=0650&db=bks&srch=&fname=/SGI_Developer/P erf_PG/sgi_html/ch15.html

Here is an interesting article I saw in Doom3World.org: http://www.doom3world.org/phpbb2/viewtopic.php?t=1 0673 Check the fourth post. Here are some interesting links about ClipMapping/ClipTexture: http://www.cs.virginia.edu/~gfx/Courses/2002/BigDa ta/papers/Texturing/Clipmap.pdf http://www.sgi.com/products/software/performer/pre sentations/clipmap_intro.pdf http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc .cgi?coll=0650&db=bks&srch=&fname=/SGI_Developer/P erf_PG/sgi_html/ch15.html

From the article at sgi.com http://www.sgi.com/company_info/newsroom/press_rel eases/2006/may/sgi_reorg.html/

All of SGI's existing common stock and the unsecured subordinated debentures will be cancelled upon confirmation of the plan by the court and receive no recovery. Accordingly, the Company believes that SGI's currently outstanding common stock and unsecured subordinated debentures have no value.

"I always wanted an SGI workstation though."
Hey, nows your chance, dig in. I got a couple in the basement. Perhaps I'll get be able to get one of these cheap http://www.sgi.com/products/workstations/tezro/
Tezro purdy enough for the living room.

The main download page is here:

Download the STL
http://www.sgi.com/tech/stl/download.html

STL v3.3 Source Code, as a tar file
http://www.sgi.com/tech/stl/stl.tar
STL v3.3 Source Code, as a zip file
http://www.sgi.com/tech/stl/stl.zip
STL v3.3 Source Code, as a tar file compressed with gzip
http://www.sgi.com/tech/stl/stl.tar.gz

STL v3.3 Documentation, as a tar file
http://www.sgi.com/tech/stl/STL_doc.tar
STL v3.3 Documentation, as a zip file
http://www.sgi.com/tech/stl/STL_doc.zip
STL v3.3 Documentation, as a tar file compressed with gzip
http://www.sgi.com/tech/stl/STL_doc.tar.gz

C++ I-O library (experimental)
http://www.sgi.com/tech/stl/standard_library.html
C++ I-O library (experimental), as a tar file compressed with gz
http://www.sgi.com/tech/stl/stdlib_20000608.tar.gz
C++ I-O library (experimental), as a zip file
http://www.sgi.com/tech/stl/stdlib_20000608.zip

The main download page is here:

Download the STL
http://www.sgi.com/tech/stl/download.html

STL v3.3 Source Code, as a tar file
http://www.sgi.com/tech/stl/stl.tar
STL v3.3 Source Code, as a zip file
http://www.sgi.com/tech/stl/stl.zip
STL v3.3 Source Code, as a tar file compressed with gzip
http://www.sgi.com/tech/stl/stl.tar.gz

STL v3.3 Documentation, as a tar file
http://www.sgi.com/tech/stl/STL_doc.tar
STL v3.3 Documentation, as a zip file
http://www.sgi.com/tech/stl/STL_doc.zip
STL v3.3 Documentation, as a tar file compressed with gzip
http://www.sgi.com/tech/stl/STL_doc.tar.gz

C++ I-O library (experimental)
http://www.sgi.com/tech/stl/standard_library.html
C++ I-O library (experimental), as a tar file compressed with gz
http://www.sgi.com/tech/stl/stdlib_20000608.tar.gz
C++ I-O library (experimental), as a zip file
http://www.sgi.com/tech/stl/stdlib_20000608.zip

The main download page is here:

Download the STL
http://www.sgi.com/tech/stl/download.html

STL v3.3 Source Code, as a tar file
http://www.sgi.com/tech/stl/stl.tar
STL v3.3 Source Code, as a zip file
http://www.sgi.com/tech/stl/stl.zip
STL v3.3 Source Code, as a tar file compressed with gzip
http://www.sgi.com/tech/stl/stl.tar.gz

STL v3.3 Documentation, as a tar file
http://www.sgi.com/tech/stl/STL_doc.tar
STL v3.3 Documentation, as a zip file
http://www.sgi.com/tech/stl/STL_doc.zip
STL v3.3 Documentation, as a tar file compressed with gzip
http://www.sgi.com/tech/stl/STL_doc.tar.gz

C++ I-O library (experimental)
http://www.sgi.com/tech/stl/standard_library.html
C++ I-O library (experimental), as a tar file compressed with gz
http://www.sgi.com/tech/stl/stdlib_20000608.tar.gz
C++ I-O library (experimental), as a zip file
http://www.sgi.com/tech/stl/stdlib_20000608.zip

The main download page is here:

Download the STL
http://www.sgi.com/tech/stl/download.html

STL v3.3 Source Code, as a tar file
http://www.sgi.com/tech/stl/stl.tar
STL v3.3 Source Code, as a zip file
http://www.sgi.com/tech/stl/stl.zip
STL v3.3 Source Code, as a tar file compressed with gzip
http://www.sgi.com/tech/stl/stl.tar.gz

STL v3.3 Documentation, as a tar file
http://www.sgi.com/tech/stl/STL_doc.tar
STL v3.3 Documentation, as a zip file
http://www.sgi.com/tech/stl/STL_doc.zip
STL v3.3 Documentation, as a tar file compressed with gzip
http://www.sgi.com/tech/stl/STL_doc.tar.gz

C++ I-O library (experimental)
http://www.sgi.com/tech/stl/standard_library.html
C++ I-O library (experimental), as a tar file compressed with gz
http://www.sgi.com/tech/stl/stdlib_20000608.tar.gz
C++ I-O library (experimental), as a zip file
http://www.sgi.com/tech/stl/stdlib_20000608.zip

The main download page is here:

Download the STL
http://www.sgi.com/tech/stl/download.html

STL v3.3 Source Code, as a tar file
http://www.sgi.com/tech/stl/stl.tar
STL v3.3 Source Code, as a zip file
http://www.sgi.com/tech/stl/stl.zip
STL v3.3 Source Code, as a tar file compressed with gzip
http://www.sgi.com/tech/stl/stl.tar.gz

STL v3.3 Documentation, as a tar file
http://www.sgi.com/tech/stl/STL_doc.tar
STL v3.3 Documentation, as a zip file
http://www.sgi.com/tech/stl/STL_doc.zip
STL v3.3 Documentation, as a tar file compressed with gzip
http://www.sgi.com/tech/stl/STL_doc.tar.gz

C++ I-O library (experimental)
http://www.sgi.com/tech/stl/standard_library.html
C++ I-O library (experimental), as a tar file compressed with gz
http://www.sgi.com/tech/stl/stdlib_20000608.tar.gz
C++ I-O library (experimental), as a zip file
http://www.sgi.com/tech/stl/stdlib_20000608.zip