The article implies that earlier generations of MIT students included lots of electronics hobbyists, whereas today that portion has been replaced with programmers and sysadmins. It makes sense for universities to arrange the curriculum to work with these backgrounds and try to fill in the gaps, without re-treading subjects most freshmen already know. Whereas before it made most sense to offer extensive programming courses (the electronics knowledge being assumed), now MIT makes the smart move of concentrating on hands-on electronics (programming knowledge being assumed). I bet this will result in more well-rounded graduates!
I remember a speech by Alan Cox some years ago where he noted this trend - computer science schools had better get ready, he said, to adapt to incoming freshmen classes where most students already have extensive user-level, if not kernel-level, programming experience.
compress is explicitly classed "non-free" in Debian. I don't know how Redhat includes it; maybe they just haven't gotten a nasty letter yet.
The LZW patent expires next month though, so there isn't much point. (thank goodness, I am so sick and tired of graphics software that refuses to read or write LZW-compessed TIFFs...)
The default IPV6 address of an ethernet interface incorporates its MAC address. So every NIC in the world automatically has its own IPV6 address. There isn't much point in dictating an allocation; you get an address each time you buy a NIC.
There isn't really much difference bewteen a "cheat" and a true optimization. As long as the "cheated" driver produces acceptable results, and produces them faster, I don't see what the problem is.
Some of the cheats potentially reduce image quality, but we are talking about OpenGL and DirectX here - nobody really aims for 100% visual quality, and indeed there is no target to shoot for since neither standard specifies "correct" rendering down to the pixel level.
You might complain that 3DMark is being treated specially, that other software wouldn't receive the same speedups. That is true. But application-specific optimization has a long history. Just look at Windows - the more recent versions detect and flag certain programs that are known to break or run slowly due to compatibility issues. Nobody says Windows is "cheating" because it refuses to install a driver that its internal knowledge base knows will trash your system. In the CAD world, video card makers almost always tweak drivers to support specific CAD and 3D applications. (3DLabs' control panel used to have a box where you could select "optimize for AutoCAD/3D Studio/Maya/etc...")
ATI should be happy that NVIDIA engineers are wasting time fixing specific benchmarks when they could instead be improving performance in general. But I wouldn't read much more than that into this.
Making your buying decision based on a synthetic benchmark, rather than in-context with your intended application, is always going to distort the picture. (Looking at SPEC benchmarks, Itanium blows the competition away - just tell that to the millions of people who are *not* buying IA64 chips!)
If you, the OpenGL developer, end up writing the next wildly-successful game, I'm sure NVIDIA will be happy to tweak their drivers for it.
AFAIK the Xbox graphics chip is equivalent to something like GeForce 3 or GeForce 4, neither of which will be capable of running Doom III with all the features on. The Xbox version will certainly be running with a lot of the fancier rendering features disabled.
That's sort of where D-VHS is now. (a niche high-end format for HDTV playback and recording). The only serious technical problem with it is the magnetic tape, which prevents random access and DVD-style special features. The marketing problem is that very few movies are going to be released on D-VHS. (and those that are released will be "second-tier" movies, not the videophile classics like Star Wars, T2, etc).
LaserDisc was different in that there were a lot of high-quality releases. (my box set of the original Star Wars trilogy on CAV disks is, to my knowledge, the very best format you can get the original movies on). But I think a lot of non-geeks had trouble with the concept of movies that came on 2 or 3 hubcap-size optical disks. (just like today's non-geek prefers anything optical over tape, and LCDs over CRTs, etc...)
No format that I am aware of uses linear 8-bit color components. 8 bits doesn't give you enough steps in brightness at the low end of the scale. If you look at an image in 8-bit linear, you'd see horrible banding in dark areas. You need at least 12 or 16 bits for a linear format.
Most video codecs, even those primarily intended for viewing on a computer screen, use the Y'CbCr color space, which is the standard for digitized NTSC and PAL video. The Y' component is non-linear and has a defined gamma encoding.
MPEG is a very rich spec and leaves a LOT of room for encoders to find different and better algorithms. In fact you can almost think of an MPEG decoder as a virtual machine that executes a program to reconstruct the video. The encoder has a lot of freedom in choosing where to put I frames and how to find the motion vectors. (as opposed to say GZIP or JPEG, where there is pretty much only one way to encode things).
One issue that sometimes bites people is converting between RGB-style and YUV-style color spaces. A round-trip from 8-bit R'G'B' to 8-bit Y'CbCr is always lossy, although not terribly so. The killer is when different codecs disagree on how to map the R'G'B' values to Y'CbCr values. MPEG-2 is nominally Y'CbCr with Y' in the range 16-235. Some encoder expect R'G'B' values in the range 16-235 and others expect 0-255. If there is a mis-match, shadows and highlights will get clipped and the translation will be much lossier.
IMHO the non-video parts of MPEG, like "face compression," are just wishful thinking. Most optional parts of the spec are only going to be implemented by one or two vendors.
Theoretically you could have 32-bit code calling 64-bit libraries, as long as the libraries never return pointers to allocated memory above the 4GB line. But I doubt that's provided for in the ABI. My guess is that app/library combinations must be 64-bit-only or 32-bit-only in order to work.
And yes, amen to the whole C++ ABI thing. My only complaints are that the final solution involves yet another required library, libgcc_s.so, and AFAIK the libstdc++ API is never going to stabilize:(
Absolute performance might be important if you use software that charges exorbitant per-CPU licensing fees. I know several packages that cost $5k-$15k per CPU - in that case, the cost of the CPU itself is negligible, so you might as well go for the highest absolute performance.
Large datacenters also probably need to worry about performance/power consumed, and performance/heat output.
I think what Macs do is more like a version of the open() syscall that takes an inode number rather than a filename. Applications remember the inode of a file they want, so they can open it even if the user has re-named or moved it. (on the other hand, this can make life very difficult if you really *do* want to replace a given file - e.g. the "blessed" System folder in OS9)
The cd thing bothers me too. For me the problem is that NFS doesn't let you export across mount points - if it did, I wouldn't have to do nearly as much symlinking. In fact, I'd love for NFS to have a feature like "server-side symlinks," so the client would just see the destination of the link instead of a symlink. Samba has both these abilities (since it runs in user-space), and for once it makes life easier on Windows than on Linux! (every time I add a new hard disk I have to modify/etc/fstab on *every* Linux box, but I can get it to show up in Windows with a mere symlink...)
One way to solve the "where am I?" problem is to hard-code a specific absolute path, and then force users to install (or symlink) the software there. e.g. "you MUST install this software in/mycompany/myapp". Sure it's ugly, but it works. I haven't seen any commercial packages do this. An open-source example is the djbdns suite of network tools.
(you might say that many Windows programs follow this convention, perhaps accidentally, by hard-coding stuff like C:\ paths)
On the other hand, commercial Linux software vendors seem to have settled on forcing an environment variable (MY_APP_DIR=/usr/local/myapp) and then setting LD_LIBRARY_PATH in a wrapper shell script.
(btw if you are releasing commercial software for Linux, *please* provide a plain.tar.gz install in addition to.rpm - not everybody uses Redhat:)
Many games & movies do get it wrong. But ask anyone who's ever been in the military, or who owns an AR or AK - you will never hear them say "clip", ever.
I would not be too hopeful about a software emulator. This sounds a lot like FX!32, the software binary translater that let you run x86 Windows programs on the DEC Alpha. While FX!32 was impressive for its time, and certainly a workable product, for most of its life it was not nearly performance-competitive with real x86 hardware. And the Alpha in its heyday was a MUCH faster chip than the Pentium. It's not clear to me that the Itanium CPU is inherently superior to x86 or x86-64 (if you optimize code specifically for it, sure, but that's a time-consuming, expensive proposition). IMHO Intel at this point is just trying to re-clothe the emperor before it's too late. Given their huge R&D investments it could certainly pay off, but I wouldn't put too much stock in that possibility.
Just to pick nits - it is improper to refer to the ammunition feeding device of an AK as a "clip." It has a spring inside of it, therefore it is properly called a "magazine."
MPEG is really intended as a final-output format, not an acquisition format. (for the same reasons that JPEG is a good final-output format for images, but a poor input format)
The issue with editing MPEG-2 is that it uses inter-frame compression. In MPEG-2, frames are grouped into "GOPs" - batches of inter-dependent frames, typically 15 to 30 frames long. If you want to cut to another shot from the middle of a GOP, you have to break apart all of the frames surrounding the cut and re-encode them into seamless GOPs. This adds another layer of lossy compression. (just like in JPEG, once you disturb a single pixel of a DCT block you have to re-encode the entire block)
Intra-frame formats like DV and I-frame-only MPEG are easier to work with, since you can freely mix and match frames. You only have to re-compress if you alter the contents of a frame (e.g. to superimpose a title or do a dissolve).
Probably because the first thing a consumer is going to do is try to load Windows on it, and AMD64 Windows won't be available for a couple months yet... I bet AMD just doesn't want to see waves of clueless people returning Opterons because it "doesn't run Windows"...:)
Last time I saw specs on this camera (the site is slashdotted now), I noticed that it records MPEG-2 at over 20Mbit/sec. This is going to look quite good, since broadcast 1080i HDTV streams are limited to ~18Mbit/sec - and the camera is 720p so there are fewer pixels to compress. On the other hand, if they use full MPEG-2 it will make editing very difficult (and lossy) since the software will have to break apart and re-encode the frames around each edit.
They might be using I-frame only MPEG, which is basically the same as JPEG for each frame, or DV. In this case the 20Mbits/sec won't look nearly as good, but editing will be much easier (and lossless).
A good application for this camera might be low-budget filmmaking, where the final output format is NTSC but you want a better image than DV can deliver with its horribly lossy compression... I don't really see the point of working at 720p since the vast majority of HDTV systems are designed around 1080i. Well, perhaps this is just a stepping stone to a 1080i camera...
(and just to pick a nit - there is no such thing as a 30 frame-per-second video format. Ever since the advent of color, NTSC video has been 30000/1001 frames per second, or 60000/1001 fields per second)
Re:The GPL is a GOOD idea for commercial software
on
Free as in Marketable?
·
· Score: 2, Interesting
The only problem with this, which may or may not be serious, is the possibility of competitors stealing code from your GPL project.
Of course outright copying would be illegal, but how are you going to prove it? Are you going to have to constantly throw money at lawyers to get subpoenas to look at your (closed-source) competitors' code? Will the legal system even allow you to do that?
Plus a competitor could "contaminate" their code with yours without really taking it line-by-line; a patent may be helpful against this but you can't stop it completely.
Whether or not these threats are significant depends on what kind of software you are writing. It think there is a case for making "ancillary" code (GUI/command-line interfaces, cross-platform libraries, etc) GPL, while keeping "core algorithms" secret.
(most of the bugs and flaws I find in commercial software are in the "ancillary" stuff like I/O code anyway; I'd love to have access to the source for those things, even if I didn't have access to the "core")
Mod parent up please. No currently-available DVD burners can burn 8.5GB double-layer video DVDs. They are limited to single-layer 4.7GB DVDs. You have to go through the whole mastering process to make a double-layer DVD.
No, performance in general would go *down* if you simply re-compiled existing code from 32 to 64 bits. (this is because pointers would double in size, and executables would grow slightly, increasing the cache footprint).
The only ways to gain performance moving to 64 bits are:
1) re-write software that needs a >4GB working set (e.g. databases) to use 64-bit pointers rather than paged or segmented 32-bit addressing
2) re-write high-performance integer code to process values in wider chunks (although you can do this on today's hardware with MMX and SSE)
The great part about AMD's new chips is that you will be able to run a hybrid 32/64-bit system. 64 bits for the few programs that actually benefit from it, and 32 bits for everything else. Running an entire system at 64 bits, although cleaner, is a loss for most mundane programs (cat, grep, bash, etc).
The interesting twist here is that someone is still gunning for SGI's graphics workstation market - Apple!
Consider their recent software-industry purchases, and their endless boasting about Maya and Shake and video editing. OS X's BSD layer is a trump card since all the high-end 3D studios are UNIX strongholds. Also I just started playing with OSX's OpenGL profiler, which fills a vital need for real-time 3D and has no equivalent on any other platform.
Right now Linux is gaining lots of ground, but most studios see its primary virtue as being a cheaper, faster UNIX (they don't really care about the open-source or "tweakability" aspects). Even ILM just uses off-the-shelf Redhat distros, with no custom work. If Apple can offer a more pleasing out-of-the-box configuration (and I think they can), the studios might just jump all over OSX.
That is definitely true now, but remember that the rate of advancement for PC bus technology is much faster than SGI can improve its desktop workstation buses (not counting the big SGI servers here, since they are really in another league). A few years ago you couldn't even send a single SD video stream across a typical PC's bus; nowadays uncompressed HD is definitely within reach. SGIs have been doing both for a while, but the gap has narrowed considerably. I expect you'll see PCs with faster buses than Octanes and Onyxs within a year or two, just like the $200 NVIDIA/ATI graphics cards that surpassed SGI Reality Engines some years ago:).
Slashdot Mirror
The article implies that earlier generations of MIT students included lots of electronics hobbyists, whereas today that portion has been replaced with programmers and sysadmins. It makes sense for universities to arrange the curriculum to work with these backgrounds and try to fill in the gaps, without re-treading subjects most freshmen already know. Whereas before it made most sense to offer extensive programming courses (the electronics knowledge being assumed), now MIT makes the smart move of concentrating on hands-on electronics (programming knowledge being assumed). I bet this will result in more well-rounded graduates!
I remember a speech by Alan Cox some years ago where he noted this trend - computer science schools had better get ready, he said, to adapt to incoming freshmen classes where most students already have extensive user-level, if not kernel-level, programming experience.
compress is explicitly classed "non-free" in Debian. I don't know how Redhat includes it; maybe they just haven't gotten a nasty letter yet.
The LZW patent expires next month though, so there isn't much point. (thank goodness, I am so sick and tired of graphics software that refuses to read or write LZW-compessed TIFFs...)
The default IPV6 address of an ethernet interface incorporates its MAC address. So every NIC in the world automatically has its own IPV6 address. There isn't much point in dictating an allocation; you get an address each time you buy a NIC.
There isn't really much difference bewteen a "cheat" and a true optimization. As long as the "cheated" driver produces acceptable results, and produces them faster, I don't see what the problem is.
Some of the cheats potentially reduce image quality, but we are talking about OpenGL and DirectX here - nobody really aims for 100% visual quality, and indeed there is no target to shoot for since neither standard specifies "correct" rendering down to the pixel level.
You might complain that 3DMark is being treated specially, that other software wouldn't receive the same speedups. That is true. But application-specific optimization has a long history. Just look at Windows - the more recent versions detect and flag certain programs that are known to break or run slowly due to compatibility issues. Nobody says Windows is "cheating" because it refuses to install a driver that its internal knowledge base knows will trash your system. In the CAD world, video card makers almost always tweak drivers to support specific CAD and 3D applications. (3DLabs' control panel used to have a box where you could select "optimize for AutoCAD/3D Studio/Maya/etc...")
ATI should be happy that NVIDIA engineers are wasting time fixing specific benchmarks when they could instead be improving performance in general. But I wouldn't read much more than that into this.
Making your buying decision based on a synthetic benchmark, rather than in-context with your intended application, is always going to distort the picture. (Looking at SPEC benchmarks, Itanium blows the competition away - just tell that to the millions of people who are *not* buying IA64 chips!)
If you, the OpenGL developer, end up writing the next wildly-successful game, I'm sure NVIDIA will be happy to tweak their drivers for it.
AFAIK the Xbox graphics chip is equivalent to something like GeForce 3 or GeForce 4, neither of which will be capable of running Doom III with all the features on. The Xbox version will certainly be running with a lot of the fancier rendering features disabled.
That's sort of where D-VHS is now. (a niche high-end format for HDTV playback and recording). The only serious technical problem with it is the magnetic tape, which prevents random access and DVD-style special features. The marketing problem is that very few movies are going to be released on D-VHS. (and those that are released will be "second-tier" movies, not the videophile classics like Star Wars, T2, etc).
LaserDisc was different in that there were a lot of high-quality releases. (my box set of the original Star Wars trilogy on CAV disks is, to my knowledge, the very best format you can get the original movies on). But I think a lot of non-geeks had trouble with the concept of movies that came on 2 or 3 hubcap-size optical disks. (just like today's non-geek prefers anything optical over tape, and LCDs over CRTs, etc...)
No format that I am aware of uses linear 8-bit color components. 8 bits doesn't give you enough steps in brightness at the low end of the scale. If you look at an image in 8-bit linear, you'd see horrible banding in dark areas. You need at least 12 or 16 bits for a linear format.
Most video codecs, even those primarily intended for viewing on a computer screen, use the Y'CbCr color space, which is the standard for digitized NTSC and PAL video. The Y' component is non-linear and has a defined gamma encoding.
MPEG is a very rich spec and leaves a LOT of room for encoders to find different and better algorithms. In fact you can almost think of an MPEG decoder as a virtual machine that executes a program to reconstruct the video. The encoder has a lot of freedom in choosing where to put I frames and how to find the motion vectors. (as opposed to say GZIP or JPEG, where there is pretty much only one way to encode things).
One issue that sometimes bites people is converting between RGB-style and YUV-style color spaces. A round-trip from 8-bit R'G'B' to 8-bit Y'CbCr is always lossy, although not terribly so. The killer is when different codecs disagree on how to map the R'G'B' values to Y'CbCr values. MPEG-2 is nominally Y'CbCr with Y' in the range 16-235. Some encoder expect R'G'B' values in the range 16-235 and others expect 0-255. If there is a mis-match, shadows and highlights will get clipped and the translation will be much lossier.
IMHO the non-video parts of MPEG, like "face compression," are just wishful thinking. Most optional parts of the spec are only going to be implemented by one or two vendors.
Theoretically you could have 32-bit code calling 64-bit libraries, as long as the libraries never return pointers to allocated memory above the 4GB line. But I doubt that's provided for in the ABI. My guess is that app/library combinations must be 64-bit-only or 32-bit-only in order to work.
:(
And yes, amen to the whole C++ ABI thing. My only complaints are that the final solution involves yet another required library, libgcc_s.so, and AFAIK the libstdc++ API is never going to stabilize
Absolute performance might be important if you use software that charges exorbitant per-CPU licensing fees. I know several packages that cost $5k-$15k per CPU - in that case, the cost of the CPU itself is negligible, so you might as well go for the highest absolute performance.
Large datacenters also probably need to worry about performance/power consumed, and performance/heat output.
I think what Macs do is more like a version of the open() syscall that takes an inode number rather than a filename. Applications remember the inode of a file they want, so they can open it even if the user has re-named or moved it. (on the other hand, this can make life very difficult if you really *do* want to replace a given file - e.g. the "blessed" System folder in OS9)
/etc/fstab on *every* Linux box, but I can get it to show up in Windows with a mere symlink...)
The cd thing bothers me too. For me the problem is that NFS doesn't let you export across mount points - if it did, I wouldn't have to do nearly as much symlinking. In fact, I'd love for NFS to have a feature like "server-side symlinks," so the client would just see the destination of the link instead of a symlink. Samba has both these abilities (since it runs in user-space), and for once it makes life easier on Windows than on Linux! (every time I add a new hard disk I have to modify
One way to solve the "where am I?" problem is to hard-code a specific absolute path, and then force users to install (or symlink) the software there. e.g. "you MUST install this software in /mycompany/myapp". Sure it's ugly, but it works. I haven't seen any commercial packages do this. An open-source example is the djbdns suite of network tools.
.tar.gz install in addition to .rpm - not everybody uses Redhat :)
(you might say that many Windows programs follow this convention, perhaps accidentally, by hard-coding stuff like C:\ paths)
On the other hand, commercial Linux software vendors seem to have settled on forcing an environment variable (MY_APP_DIR=/usr/local/myapp) and then setting LD_LIBRARY_PATH in a wrapper shell script.
(btw if you are releasing commercial software for Linux, *please* provide a plain
Many games & movies do get it wrong. But ask anyone who's ever been in the military, or who owns an AR or AK - you will never hear them say "clip", ever.
Even some Slashdot readers own an AK and AR-15 :)
I would not be too hopeful about a software emulator. This sounds a lot like FX!32, the software binary translater that let you run x86 Windows programs on the DEC Alpha. While FX!32 was impressive for its time, and certainly a workable product, for most of its life it was not nearly performance-competitive with real x86 hardware. And the Alpha in its heyday was a MUCH faster chip than the Pentium. It's not clear to me that the Itanium CPU is inherently superior to x86 or x86-64 (if you optimize code specifically for it, sure, but that's a time-consuming, expensive proposition). IMHO Intel at this point is just trying to re-clothe the emperor before it's too late. Given their huge R&D investments it could certainly pay off, but I wouldn't put too much stock in that possibility.
Just to pick nits - it is improper to refer to the ammunition feeding device of an AK as a "clip." It has a spring inside of it, therefore it is properly called a "magazine."
MPEG is really intended as a final-output format, not an acquisition format. (for the same reasons that JPEG is a good final-output format for images, but a poor input format)
The issue with editing MPEG-2 is that it uses inter-frame compression. In MPEG-2, frames are grouped into "GOPs" - batches of inter-dependent frames, typically 15 to 30 frames long. If you want to cut to another shot from the middle of a GOP, you have to break apart all of the frames surrounding the cut and re-encode them into seamless GOPs. This adds another layer of lossy compression. (just like in JPEG, once you disturb a single pixel of a DCT block you have to re-encode the entire block)
Intra-frame formats like DV and I-frame-only MPEG are easier to work with, since you can freely mix and match frames. You only have to re-compress if you alter the contents of a frame (e.g. to superimpose a title or do a dissolve).
If they use full MPEG-2 with P- and B- frames, then yes, at 20Mbits it should look better than DV (because of interframe compression).
But if they use I-frame-only MPEG (which is essentially the same compression technique as DV), then it should look worse.
Probably because the first thing a consumer is going to do is try to load Windows on it, and AMD64 Windows won't be available for a couple months yet... I bet AMD just doesn't want to see waves of clueless people returning Opterons because it "doesn't run Windows"... :)
Last time I saw specs on this camera (the site is slashdotted now), I noticed that it records MPEG-2 at over 20Mbit/sec. This is going to look quite good, since broadcast 1080i HDTV streams are limited to ~18Mbit/sec - and the camera is 720p so there are fewer pixels to compress. On the other hand, if they use full MPEG-2 it will make editing very difficult (and lossy) since the software will have to break apart and re-encode the frames around each edit.
They might be using I-frame only MPEG, which is basically the same as JPEG for each frame, or DV. In this case the 20Mbits/sec won't look nearly as good, but editing will be much easier (and lossless).
A good application for this camera might be low-budget filmmaking, where the final output format is NTSC but you want a better image than DV can deliver with its horribly lossy compression... I don't really see the point of working at 720p since the vast majority of HDTV systems are designed around 1080i. Well, perhaps this is just a stepping stone to a 1080i camera...
(and just to pick a nit - there is no such thing as a 30 frame-per-second video format. Ever since the advent of color, NTSC video has been 30000/1001 frames per second, or 60000/1001 fields per second)
The only problem with this, which may or may not be serious, is the possibility of competitors stealing code from your GPL project.
Of course outright copying would be illegal, but how are you going to prove it? Are you going to have to constantly throw money at lawyers to get subpoenas to look at your (closed-source) competitors' code? Will the legal system even allow you to do that?
Plus a competitor could "contaminate" their code with yours without really taking it line-by-line; a patent may be helpful against this but you can't stop it completely.
Whether or not these threats are significant depends on what kind of software you are writing. It think there is a case for making "ancillary" code (GUI/command-line interfaces, cross-platform libraries, etc) GPL, while keeping "core algorithms" secret.
(most of the bugs and flaws I find in commercial software are in the "ancillary" stuff like I/O code anyway; I'd love to have access to the source for those things, even if I didn't have access to the "core")
Mod parent up please. No currently-available DVD burners can burn 8.5GB double-layer video DVDs. They are limited to single-layer 4.7GB DVDs. You have to go through the whole mastering process to make a double-layer DVD.
No, performance in general would go *down* if you simply re-compiled existing code from 32 to 64 bits. (this is because pointers would double in size, and executables would grow slightly, increasing the cache footprint).
The only ways to gain performance moving to 64 bits are:
1) re-write software that needs a >4GB working set (e.g. databases) to use 64-bit pointers rather than paged or segmented 32-bit addressing
2) re-write high-performance integer code to process values in wider chunks (although you can do this on today's hardware with MMX and SSE)
The great part about AMD's new chips is that you will be able to run a hybrid 32/64-bit system. 64 bits for the few programs that actually benefit from it, and 32 bits for everything else. Running an entire system at 64 bits, although cleaner, is a loss for most mundane programs (cat, grep, bash, etc).
The interesting twist here is that someone is still gunning for SGI's graphics workstation market - Apple!
Consider their recent software-industry purchases, and their endless boasting about Maya and Shake and video editing. OS X's BSD layer is a trump card since all the high-end 3D studios are UNIX strongholds. Also I just started playing with OSX's OpenGL profiler, which fills a vital need for real-time 3D and has no equivalent on any other platform.
Right now Linux is gaining lots of ground, but most studios see its primary virtue as being a cheaper, faster UNIX (they don't really care about the open-source or "tweakability" aspects). Even ILM just uses off-the-shelf Redhat distros, with no custom work. If Apple can offer a more pleasing out-of-the-box configuration (and I think they can), the studios might just jump all over OSX.
That is definitely true now, but remember that the rate of advancement for PC bus technology is much faster than SGI can improve its desktop workstation buses (not counting the big SGI servers here, since they are really in another league). A few years ago you couldn't even send a single SD video stream across a typical PC's bus; nowadays uncompressed HD is definitely within reach. SGIs have been doing both for a while, but the gap has narrowed considerably. I expect you'll see PCs with faster buses than Octanes and Onyxs within a year or two, just like the $200 NVIDIA/ATI graphics cards that surpassed SGI Reality Engines some years ago :).