Slashdot Mirror

Funny, you've been asked twice now and declined to provide links.

Here's mine:

FreeBSD Driver Initative
Announcement of collaboration between NVIDIA, SGI, and VA Linux
NVIDIA press release
And another release
Tom's Hardware discussion

Oh, and SGI isn't the only proprietary code either. There's also a cross licensing agreement with S3 for the S3TC (S3 Texture Compression) algorithms that NVIDIA doesn't have the right to disclose.

NVIDIA and SGI drop lawsuits

I'm not quite sure, but I think this is one of the things CXFS is trying to do. Now if I could only connect to the SGI site...

Yes. I think it's clear that you can't beat MS at their homecourt.

You need to take the battle somewhere else

While I wish SUN all the best luck in selling these low-cost Linux PCs, I don't have great faith in their ability to succeed in this low-margin market. These companies don't have a true understanding for how little money is involved with selling PC hardware.

I worked for SGI a few years ago (as an intern), just as they were introducing their PC strategy. They were coming out with (relatively) low-cost NT workstations with a proprietary graphics system (kicked ass at the time..), but were immediately stuck in a catch-22. They had high prices because they couldn't sell enough, and couldn't sell enough because of their high prices. SGI also tried selling server-ish PC boxes (with redundant power supplies, and multiple processors and stuff), but that lasted about a year as well, before it went away (at least I can't find it on their web page anymore)

When people buy PC hardware, they expect to pay PC hardware prices. And they want support. And warranties.. There's just no money there...especially not the kind of money these companies are used to seeing.

If they're getting in to this to make money, then they're in trouble. If SUN is getting in to this to fight against MS, then great, but I don't think SUN has enough money to fight MS.

most probably spend some of it to go into space or to the Moon

After the philanthropy had worn down, I myself would tile a wall with these these and hook them to a few of these. And I would go absolutely nuts with other technotoys.

You're basically correct about how SGI did the port... they created an IRIX to Linux VFS mapping layer, as described in the papers on this page: XFS Talks and Papers.

Sure, maybe use it in a Echostar DishPVR 721? :)

This isn't correct... if it were correct, I would not have spent so much time working on a
custom Red Hat installer for XFS. :)

There is some XFS-aware code in the Red Hat Linux installer, but there is no kernel support or userspace tools available, so what you propose simply can't work.

However, SuSE, Mandrake, Gentoo, Slackware, and Debian (to some extent) do have XFS support.

Really, what are you talking about? Have you even been to SGI's XFS site? Stop saying you can't use XFS on 2.4.19, because I'm using it right now.

There's an XFS FAQ and a load more information about it on SGI's site - which points out that several large distributions have had XFS support for a while by default.

Still, it's noteworthy that Linus has finally accepted it into his tree...

Way back in 1998, SGI benchmarked an XFS(IRIX) filesystem at over 7 GB/s.

No, that's not a typo. They also managed over 4GB/s to a single file.

Is that enough for you? :) If not, I'm sure they've improved speeds over the last 5 years...

This link describes some more about the disk benchmark.
http://oss.sgi.com/projects/xfs/papers/xfs_white /x fs_white_paper.html

Based on your resume, you obviously have inside information that I'm not privy to. But I think you're oversimplifying the story a bit.

The Origin 3000 series (SN-1) was designed very nearly from the beginning to accommodate either MIPS CPUs from the R10000 family or IA-64 CPUs. In 1996-1997, when I worked most closely with the SN-MIPS and SN-IA groups, there was doubt about whether the IA-64 processor would be Merced or McKinley, but there was no question about support for one or both of them.

Look inside a C-brick some time. (If you don't have one handy-- heh-- there's an illustration here.) See all that empty space at the front? The original design called for the use of either MIPS PIMMs or IA-64 PIMMs. The IA-64 PIMMs would include all the necessary hardware to make the Intel chips talk to the Bedrock memory controller. The MIPS PIMMs are pretty small, about four inches square or so. But the IA-64 PIMMs were projected to be real monsters with giant heat sinks on them. Thus all that empty space in the C-brick.

For quite a while, of course, SGI has been working on SN-2, or whatever they're calling the successor to SN-MIPS these days. I'm not associated with that group any more, so I'm not in the loop on the new design. I've heard rumors on the order of 128 MIPS processors in a rack, quadrupling the processor density of the 3000 series systems, but I don't have any real information there. It's certainly possible that SGI is preparing to roll out their IA-64 systems in the spring in the new architecture, but that would surprise me. Of course, like I said before, you seem to know more than I do on this one.

What about SGIs new high-speed storage server things that were announced a couple months ago. Looks like they are trying hard to get the full package of HPC again.

What is most impressive about this to me is that they did it using Linux over IRIX. Why? Because this has provent to be Linux's weakest point: scalability.

This new system is news, but it's hardly groundbreaking news. Back in '99, SGI spun off MIPS and announced they would do commodity systems -- including supercomputers with commodity processors. At that they had a choice: port IRIX to the Itanium, or teach Linux to scale so they could use it on their supercomputers. It's been no secret that they chose the latter. Or why: it was less expensive, and catered to an established user community.

Note that Itanium/Linux systems are not meant to replace MIPS/Irix systems. Unless they've changed their strategy since I worked there, SGI plans to keep developing Irix systems for another 10 years, at least. Of course, that depends on maintaining loyalty to Irix solutions, and the buzz is that they're having trouble with that.

That said, it's an impressive result. And it's done in an unusual way. SGI has a 1.6GB/s channel running through routers connecting the processors and memory. A computer is made up of multiple rackmount "bricks" connected by cables and routers. The "router" is a 2U rackmount device.

Processors and memory reside in rackmount boxes with 4 CPUs and 8 GB (max) of local memory. These boxes interconnect through a single 1.6GB/s link per box, which, in a big system, goes through several layers of routers. So a memory access to another box is routed through what is essentially a fast LAN. All this is cached, of course.

It's not clear to what extent application programs have to be aware of this. Clearly, if you lay things out in memory badly, with lots of CPUs reading and writing the same memory from all over the memory net, the system will bottleneck. (Everybody reading the same stuff is OK; it's cached. But writes have to propagate back to the home location of the data.)

Since the whole monster crashes all at once, you don't want to build your web server farm this way. It's for applications that really need all that crunch power in one machine.

These results are quite old. The SGI MIPS based machines seem to be much faster.
512 processor Origin 3000 quoated as 716 GB/sec.
I have no idea why they are using Itanics for this but its not because they are better processors.

I meant to say that the 3 walls were not at 180 degrees from each other but at 90 degrees. There exist project systems where walls are not set up like this (see SGI reality centers for instance). Now I bet you feel less smart ;-)

Well, it wasn't strictly a Unix system - it was an IRIX system.

http://www.sgi.com/workstations/fuel/

Nothing Apple has compares to that.

Apple doesn't even have 64-bit processors yet, so lets not jump the gun and assume they're going to overtake SGI and Sun in the scientific market.

Granted, for the type of computer Apple offers (32-bit), they're great. But, as I said before, why use the bloated OSX which'll hog alot of your RAM and CPU time, when you can install Debian, which won't?

IIRC for raw disks it was far easier to implement asynchronous I/O which is a significant performance boost over synchronous I/O. With filesystems you had to rely on the OS which may not have it or implement it differently, and it tends to blow away the disk cache anyway.

p.s. isn't dsync a slightly better method to use than fsync if you're using pre-defined/sized filesystem devices?

there's got to be another goal that will step up after quake (whatever number) looks as good as a live action movie. i think it will probably be a new interface. possibly vr type things.

i see pixar's point that by the time pc graphics catch up to now, cinematic cg will be further down the road. but the gap is getting smaller. i would be really impressed if a desktop could make use of something like MASSIVE in real time during a game. good looks will look better when there is more intelligent behaviour of bots in games. someday it will be possible, but by that time movies will be even prettier.

or maybe i'll finally be able to game at full speed without worrying about ruining the cds i'm burning.

I had a similar problem when I originally got my SGI 1600sw flat panel LCD a few years back. It ran at 1600x1024 native, and to accomodate this unstandard (at the time) resolution, you were forced into using one of their "pre-approved" graphics cards. At the time they were fairly decent, but eventually they got old, without being able to upgrade, since the default connection was OpenLDI digital (not DVI), you had to buy an adapter (Usually out of stock and $600 retail) or get a new monitor.

If there are enough monitors made at 16:9 instead of 16:10 in time 16:9 resolutions will be standardized. So if you plan to use this monitor for a few years, I think eventually you wont have any graphics cards problems. But until then, I would say the GeForce cards are very accomodating to non standard resolutions. I cant say much for 16:9 but I know that all VisionTek GeFroce2+ cards and certainly 4+ cards support 16:10 resolutions. GeForce2 was one of the few vendors that also supported 16:10 when there were only a handful of monitors running at that resolution.

If you cant find anything that runs 16:9 and that monitor can rescale to 16:10 then I think a decent Geforce4 wont be much of a compromise. Plus, you should be able to hook up your DVD directly to it and still have it hooked up to your PC so you can still watch your movies at 16:9.

My next monitor is the SGI F220 which im ordering next week, and lucky me I can get a GeForce4 to render, now I just have to find out if its compatible with non-SGI systems. ^_^

I had a similar problem when I originally got my SGI 1600sw flat panel LCD a few years back. It ran at 1600x1024 native, and to accomodate this unstandard (at the time) resolution, you were forced into using one of their "pre-approved" graphics cards. At the time they were fairly decent, but eventually they got old, without being able to upgrade, since the default connection was OpenLDI digital (not DVI), you had to buy an adapter (Usually out of stock and $600 retail) or get a new monitor.

If there are enough monitors made at 16:9 instead of 16:10 in time 16:9 resolutions will be standardized. So if you plan to use this monitor for a few years, I think eventually you wont have any graphics cards problems. But until then, I would say the GeForce cards are very accomodating to non standard resolutions. I cant say much for 16:9 but I know that all VisionTek GeFroce2+ cards and certainly 4+ cards support 16:10 resolutions. GeForce2 was one of the few vendors that also supported 16:10 when there were only a handful of monitors running at that resolution.

If you cant find anything that runs 16:9 and that monitor can rescale to 16:10 then I think a decent Geforce4 wont be much of a compromise. Plus, you should be able to hook up your DVD directly to it and still have it hooked up to your PC so you can still watch your movies at 16:9.

My next monitor is the SGI F220 which im ordering next week, and lucky me I can get a GeForce4 to render, now I just have to find out if its compatible with non-SGI systems. ^_^

SGI did the graphics cluster thing over two years ago and even released it as a product. Very, very similar to the IBM. They even ported several of their programming APIs and SDKs from InfiniteReality to the Linux Graphics Cluster. Not many were sold, however. Heck, Slashdot didn't even cover it. It was still pretty neat to see multiple spanned monitors and even composited high res projectors driven by a half rack of Linux PCs. Many of the demos were actually ported from SGI's big iron Onyx machines and worked just as well on the cluster. The basic setup was a stack of rackmount Linux boxes using nVidia AGP cards and custom PCI cards daisy chained together to provide sync for glSwapBuffers among other things. Also availble were gigE and Myrinet for networking the machines with something better than 100BT. A compositor (similar to what's used in InfinitePerformance) was also available.

More information (white paper and data sheet) can be found on SGI's legacy systems page:
http://www.sgi.com/products/legacy/vis_systems.htm l

I belive a few .edu and .org have also rolled their own graphic clusters... though I don't know who supplied the compositors.

Why, do you have performance benchmarks comparing the experimental, non production DeepView with the commercially available InfinitePerformance visualization system?

This is exactly right. Changing the underlying data representation is the first step to enabling truly new GUIs. As Gelernter says, it simply doesn't make sense to use a 1960's era data model (the hierarchical file system) on 2002 hardware.

Also, while radical approaches like 3DUIs don't make a lot of sense on top of the traditional file/folder storage model, they become much more compelling when the file system becomes a relational database.

And you are absolutely correct that Microsoft is pursuing this opportunity with a vengeance. By battling for the "Windows desktop", most Linux UI developers are fighting yesterday's battle. Instead, they should be looking forward and trying to beat Microsoft to a truly next-generation environment.

I think what Richards is overlooking in his commentary is that Cg is not *supposed* to be a general-purpose graphics programming language. Its design goal was precisely what he said later in the article -- to expose the capabilities of current (and presumably future) NVIDIA hardware without requiring programmers to write assembly code. Likewise, conditionals like if, case, and switch aren't in there right now because the profiles the compiler is aimed at -- DirectX and OpenGL extensions -- don't yet support them. I expect this to change.

Also, Cg programs run at the level of vertices and pixels. This is the wrong place to be thinking about a scene graph: that happens at a much higher level of abstraction. Dealing with scene graphs in a fragment shader is a little bit like making L1 cache aware of the memory-management policy of whatever OS happens to be running.

After reading the article a few times, I think it's meant more as a "here's why our product is better than theirs" release than an honest criticism of the design of Cg. If he was interested in the latter, there are a few obvious issues. I won't go into them all, but here are two I ran into last week at a Cg workshop:

• Cg limits shaders to single-pass rendering. This is a design limitation: there are lots of interesting multipass effects, and it's not all that difficult to get the compiler to virtualize the shader to do multipass on its own. The Stanford Real-Time Shading Project people wrote a compiler that does precisely that: it uses Cg as an intermediate language. The advantage of that design decision is that you-the-programmer have fuller control over what's happening on the hardware, which is the entire point of the exercise.
• Cg requires that you write separate vertex and fragment shaders. You can't do things like texture lookups inside a vertex shader; you can't change the position of your vertices inside a fragment shader. Again, this gives you control over the details of the pipeline at the cost of some added complexity. This can be changed by changing the semantics of the language.

One final note: Cg is not the be-all and end-all of real-time shading languages. Nor is DirectX 8.1, 9, or whatever. Nor is the SGI shading language. Real-time shading on commodity hardware is still a new enough field that the languages and the hardware are evolving. DirectX 9 and OpenGL 2.0 both incorporate shading languages that will by nature be less tightly coupled to one vendor's hardware. Watch those over the next year or so.

You got most of your info about IR4 right, but I just wanted to clarify some things in greater detail. IR is confusing at first, and very different from the typical single-board graphics systems that most people are familiar with. All the details can be found here, but here's an executive summary.

InfiniteReality (be it the original IR on Onyx, or IR2, IR2E, IR3, or now IR4) is comprised of a set of boards. In order to function, the set has to include one geometry engine (or GE), one raster manager (or RM), and one display generator (or DG). The GE board is where the graphics coprocessors live, and it's responsible for most of the 3D math. The DG converts the frame buffer into an analog RGB signal, or a CCIR-601 SD video signal, or, recently, a digital signal.

The RMs are the interesting part. The RM board holds both the frame buffer (80 MB on IR3, 2.5 GB on IR4) and the texture RAM (256 MB on IR3, 1 GB on IR4). A graphics pipe can include one, two, or four raster managers. When you add RMs, you increase frame buffer size (or the size of the raster you can render), but texture cache.

So a four RM graphics pipe will have 10 GB of frame buffer and 1 GB of texture cache, but that 1 GB of texture will be on each of the four RMs. So each texture you download will be stored, in parallel, on each of the four RMs. This keeps texture operations nice and peppy even when you're rendering into a 3840 x 2160 buffer. (That's four times more resolution than HDTV, if you're interested.)

Note, also, that these memories aren't combined. The TRAM and the frame buffer RAM are isolated in hardware. You can't store textures in the frame buffer, and you can't render in texture RAM. So saying that IR4 has a combined 11 GB of graphics RAM is not quite true, and slightly misleading. But only slightly. ;-)

The whole thing adds up to an incredibly flexible system. You can configure the graphics pipe as a relatively small raster of 2,048-bit-deep pixels, or an 8-million-pixel raster of 256-bit-deep pixels, or almost anything in between. You can render a truly giant image-- about 3K by 2K pixels, progressive scan, or even more than that if you're willing to live with interlacing-- with full antialiasing, multi-buffered. It's pretty.

(If all you want is pure geometry performance, for viewing giant CAD models and stuff in real time in a VR environment, SGI also has their InfinitePerformance line of graphics hardware for Onyx. But that's another topic.)

Okay, that's enough "Rah-rah, IR" for one night, with just one more little piece of trivia. InfiniteReality graphics has remained fundamentally unchanged since 1996 or so. The only exception is the change from an Everest bus host to an XIO host system. Every few years, SGI has increased the speed of the GEs, or the texture capacity on the RMs, or the performance of the DACs in the DG, but the system itself hasn't really changed at all in six or seven years. That's pretty amazing.

Why isn't the equipment wireless, using bluetooth or something similar for everything to communicate. Its not going to feel very realistic to me if I have a strand of wires attached to me.

SGI was showing off some examples of what you are describing. Basicly, the big iron (clusters, or large machines such as Onyxes) sit in the machine room, while the users have wireless webpads and such elsewhere. It's the only way we can currently tap the power of thousands of processors and dozens of 3D accelerators in a handheld using current technology.

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

SIGGRAPH exhibits closed on Thursday evening, but here are some of the biggest highlights:

SGI annouced their Infinite Reality 4 option for the Onyx series... comes standard with 1gbyte of texture ram and 2.5gbyte of buffer, expandable to 10gbyte of buffer for a total of 11gbyte of onboard gfx ram. Up to 16 IR4 subsystems can be installed in a single machine. Each subsystem can drive up to 8 monitors... or all subsystems can run in parallel for greater performance. The Virtual LA Urban Simulation project demoed part of their 3D LA using IR4 and the older IR3. They currently have over 1TB of texture and geometry data from Los Angeles, mostly in downtown areas... though they have 20,000 square miles mapped out, 4,000 of which are quite detailed.

Sun was showing off their XVR-4000 gfx option, a cardset that uses the IPA slot found in most Ultra-series machines. It has about 8x the geometry performance of IR3 and about 50% of the fill performance of IR4... for a fraction of the cost. 1gbyte of texture and 144mbyte of buffer. Different market targets, but interesting none the less.

SIGGRAPH exhibits closed on Thursday evening, but here are some of the biggest highlights:

SGI annouced their Infinite Reality 4 option for the Onyx series... comes standard with 1gbyte of texture ram and 2.5gbyte of buffer, expandable to 10gbyte of buffer for a total of 11gbyte of onboard gfx ram. Up to 16 IR4 subsystems can be installed in a single machine. Each subsystem can drive up to 8 monitors... or all subsystems can run in parallel for greater performance. The Virtual LA Urban Simulation project demoed part of their 3D LA using IR4 and the older IR3. They currently have over 1TB of texture and geometry data from Los Angeles, mostly in downtown areas... though they have 20,000 square miles mapped out, 4,000 of which are quite detailed.

Sun was showing off their XVR-4000 gfx option, a cardset that uses the IPA slot found in most Ultra-series machines. It has about 8x the geometry performance of IR3 and about 50% of the fill performance of IR4... for a fraction of the cost. 1gbyte of texture and 144mbyte of buffer. Different market targets, but interesting none the less.

The problem with on-line C++ is that many people who claim to write about it don't know their subject, and consequently write superficially correct code that actually sucks. I'm sorry to name names, but the much-recommended-here CPlusPlus.com is one such site; their "Hello, world!" program at the start of their isn't even correct. I'd give sites like that a miss if you're seriously interested in learning C++.

One good source of information about C++ (and many other programming-related subjects) on-line is the related Usenet newsgroups, particularly the group specifically for learners if you're just starting out, or the moderated C++ group for more advanced subjects.

Many of these groups also have helpful FAQs, available (as usual) via the Internet FAQ Consortium. Again, for those just starting out, I'd particularly recommend the alt.comp.lang.learn.c-c++ FAQ, which has links to helpful on-line resources, free compilers, etc.

There are a few web sites of which anyone in the C++ field should be aware.

• You can get generally pretty sound book reviews for thousands of books on these and related subjects at the Association of C and C++ Users web site.
• Herb Sutter's web site has lots of informative and thought-provoking C++ articles by one of the guys who's advanced C++ programming technique a lot in recent years.
• Similarly, Scott Meyers' publications page has many worth-reading articles on C++.
• It would be remiss not to mention Boost, a collection of very good general-purpose C++ libraries. If you can't see how to do something with the standard stuff, the answer -- or a useful idea to find it -- may well be here.

There are a few decent on-line references to the standard library:

• Dinkumware make a standard library implementation, which is shipped with Visual C++ amongst other things, and provide some helpful documentation on-line. (NB: The version that shipped with VC++ 6 was flawed in many horrible ways, but that wasn't really Dinkumware's fault given the compiler limitations at the time when they wrote that library; please don't judge them by that alone.)
• SGI's implementation of the "STL" parts of the C++ standard library is excellent, and well-documented on-line.

About the only decent on-line C++ tutorial I know of the electronic version of Bruce Eckel's "Thinking in C++" books. You can find a complete copy of these, and several of his other books, at his books web site. (He also has books on Java, C#, Python amongst other things, and all of his work I've read has been reasonably good.)

Since one of the major things in C++ is it's libraries, I find the two best references for that are:
1. SGI's STL Reference
2. Reference for iostreams and standard C library

And don't forget man pages in unices and msdn in windows.

Two sites I refer to frequently for C++:

SGI's reference to the STL.

cpluslus.com, most notably the "standard libraries" reference link on the left there (for looking up bits and pieces of the iostreams library).

-Rob

I've been using XFS for all my systems since the beggining of this year and I've personally had zero problems with XFS. I have heard some complaints from other people but when I asked them what they didn't like the complaint was that there were null bytes in files after a crash. Unfortunatly for them this is the intended behavior by XFS in some situations.

I think the most common kernel with XFS is 2.4.18 which is known to have some swapping problems.

So as long as the RedHat 7.3 kernel doesn't have that swapping problem I'd say go for it. Be sure to install the xfsdump package if it isn't already and run the xfs_fsr command weekly from a cron job to keep performance high.

I've been using XFS for all my systems since the beggining of this year and I've personally had zero problems with XFS. I have heard some complaints from other people but when I asked them what they didn't like the complaint was that there were null bytes in files after a crash. Unfortunatly for them this is the intended behavior by XFS in some situations.

I think the most common kernel with XFS is 2.4.18 which is known to have some swapping problems.

So as long as the RedHat 7.3 kernel doesn't have that swapping problem I'd say go for it. Be sure to install the xfsdump package if it isn't already and run the xfs_fsr command weekly from a cron job to keep performance high.

An SGI o2 Clone. Now that I'd like to see...

Take a look at XFS.

what about kwave? I'm not too familiar with what cooledit is like these days but kwave has most of the features I used to use in cooledit 95.

here's what they say...

• KDE2/3 conform GUI
• 24 Bit Support
• Undo/Redo
• Simple Drag & Drop
• Support for multi-track files
• Complete zoom and scroll-capability
• Playback via KDE's aRts or OSS (deprecated)
• Load and edit-capability for large files (can use virtual memory)
• Reading and auto-repair of damaged wav-files
• Supports multiple windows
• Import of all file types supported by libaudiofile
• Extendable Plugin interface

they should buy me an Octane2.

If not, then they should stop complaining...

Personally, I'm using:
Red Hat Linux 7.1 with XFS support and Ximian GNOME

My only problem was downloading drivers for my NIC card, and I will admit, that was a b*tch. However, the card was new, and it's supported in newer versions.

You're having sound problems, hmm? I remember the first time I installed 6.2, I had to run sndconfig manually to get my sound card initialized. Maybe try this?

Also, IRC, mailing lists, forums, etc., are *very* helpful. I can't stress this enough! Find a related IRC chat or forum or such and ask for help. This applies to anything Linux. Often when asking for help about a certain program or project, you'll wind up talking to one of the developers in person. People do OSS (Open Source Software) because they love to do it, and it really does show.

Please feel free to email me with more information, I'd be happy to help. =)

Links you might be interested in:
linuxnewbie.com
linuxdoc.org
rpmfind.net

Try google for something similar to "Windows to Red Hat Linux transition guide." I'm sure there is a good one out there.

Some people would disagree.

There is considerably more to the computing world than PCs. High-end 3D graphics don't get done on PCs, just the low-end stuff that makes it into games. Even here there's no monopoly - Sony has its take on gaming, as does Nintendo.

If you're suggesting that Microsoft offers the dominant 3D API for Microsoft platforms, well then yes - it does. But then where's the surprise in that? Sony offer the dominant API for Sony platforms, and Nintendo offer the dominant API for Nintendo platforms.

Don't be too quick to cry 'monopoly'. It devalues the term, and makes it lose impact for when it's really needed.

Cheers,
Ian

Didn't MS buy OpenGL patents from SGI recently?

Hard to tell... (more stuff found here). The opengl.org Licensing page links back to oss.sgi.com...

It's not easy to tell who currently owns the rights to OpenGL.. er, the OpenGL API. *gak*

-fester

Didn't MS buy OpenGL patents from SGI recently?

Hard to tell... (more stuff found here). The opengl.org Licensing page links back to oss.sgi.com...

It's not easy to tell who currently owns the rights to OpenGL.. er, the OpenGL API. *gak*

-fester

it would seem relatively trivial to port XFS to the OS.
There's a icensing issue Here. SGI'sxfs is GPLed, apple does not endorse GPL or LPGLed software. They removed wget because it was gpled, gnutar has also been removed. Apple want to use BSD like licence exclusively, so one day if they want to they can make a closed source OS again .....
If you'de want xfs on OS X it should come from The GNU-Darwin project or from Fink. Both project are leading software port (one bringing support for AMD powered ia32 machines).

• opengl shader.
• a great paper on the hardware shading problem, and a very generic approach.
• stanford's rtsl.
• the proposed opengl2 also has a hardware shading abstraction language.

hopefully, opengl2's shading will become standard, and mitigate the cross-platform differences. it's seemingly a much better option than this new thing by nvidia, but we'll have to wait and see what does well in the marketplace, and with developers.

• opengl shader.
• a great paper on the hardware shading problem, and a very generic approach.
• stanford's rtsl.
• the proposed opengl2 also has a hardware shading abstraction language.

hopefully, opengl2's shading will become standard, and mitigate the cross-platform differences. it's seemingly a much better option than this new thing by nvidia, but we'll have to wait and see what does well in the marketplace, and with developers.

See, this is why I'm keeping with ext2. ;)

Uhh, no. The original poster meant X Font Server, not XFS (the journalled filesystem from SGI).

TDM TLA's! (Too Damned Many Three-Letter Acronyms) ;-)

FWIW, On the Ep I DVD Making of Documentary, OS 9 was visible durinag a photoshopping session, Windows (or a GUI clone) for Motion capture and unix (presumably IRIX) for the rest.

It is also worth noting that Microsoft have had Windows 2000 going through a C2 evaluation for over 18 months with a proper hardware configuration unlike the previous NT 4.0 evaluation.