The comparison probably isn't fair because Pixar and Weta do very different jobs. Weta does visual effects and Pixar does character animation. They are superficially similar in that they often use the same modelling and rendering tools.
VFX houses generally have to produce "elements" to match existing photography (matching camera motion, set lighting and so on). That's actually where most of the trouble happens: getting things to match. So a VFX house's best friend is not necessarily the modeller and renderer, but the compositing system (Cineon, Shake, Avid, After Effects etc).
OTOH, Pixar has to build characters and worlds from scratch, like in traditional 3D animation (e.g. that of Aardman). Every prop and every piece of set decoration needs to be modelled, placed and rendered. Their best friend is the animation system (in Pixar's case, often incorrectly referred to by marketroids as "Marionette", but known to everyone inside the company as "Menv").
Note that this skips over a lot of detail (and I'll no doubt be corrected/chastised for oversimplifying things), so take this with the appropriate sodium chloride.
Linux can render the incredibly lifelike texturing and animation exhibited in "Monsters Inc." [...]
Now of course this is true. Linux can do the job. (Rumour has it that Pixar has found that FreeBSD running with Linux emulation is actually slightly faster at running prman than Linux itself for their kind of scenes, though. It's probably virtual memory performance dominating.) However, until someone comes up with a 14-CPU-per-box Linux machine, Pixar will stick with their Suns.
Though you won't find it in your job ads, having a lot of languages (and a lot of different kinds of languages at that) on your resume is a definite bonus. Especially if there's a variety of languages (procedural, OO, functional, logic etc), it shows that you can easily adapt to a new language should that become an issue.
Kaplan's Understanding GPS: Principles and Applications asserts that GPS transmits Kepler elements whereas GLONASS transmits cartesian coordinates and derivatives. They also keep different time and use a different reference frame. Admittedly the book doesn't go into GLONASS in detail, however, is this information wrong?
I'm curious also about Pseudonym's statement about the geodetic systems, something doesn't seem right about that.
All I meant by that is that if you're using GLONASS, chances are it won't correspond precisely to your map if it was made after 1985 or so. Sure, you can transform between the two systems, but that requires more smarts on the receiver, which eliminates the one potential advantage of GLONASS (having a simple receiver).
If you're just trying to find your way back to where you were, it won't make a difference. If you're trying to locate somewhere accurately on a map, it'll be an unnecessary headache.
GLONASS is a quite different system to GPS, and it's unclear whether or not buying GLONASS would be better than designing your own. The satellites only have a usable life of about 7.5 years for starters, so it would be a short-term measure at best.
GLONASS is designed for smart satellites and relatively dumb receivers, whereas GPS is designed for relatively dumb satellites and smart receivers. For example, the GLONASS satellites are in orbits with an almost zero eccentricity, so receivers don't need to correct for relativistic effects. (The Soviets were always much better than the US at getting things into very precise orbits.) The benefit of GPS here is that you can always upgrade a receiver if you want something even smarter. (The US has always been much better than the USSR at producing sophisticated consumer electronics.)
Also, GLONASS uses an older geodetic system than GPS, which makes it not as useful for advanced surveying applications.
Oh, I dunno. Tom Clancy predicted using a hijacked plane loaded with fuel as a bomb years before it was put into production. That's got to be worth something.
Even better would be if Linux had a translucent file system. Simply mount all the path directories on top of each other and let the OS do the rest.
For the uninitiated, a translucent file system lets you mount one filesystem on top of another filesystem, the idea being that if you tried to open a file the OS would first search the top filesystem, then the bottom one. In conjunction with non-root mounting of filesystems (e.g. in the Hurd) it removes the need for $PATH because you can just mount all the relevant directories on top of each other.
I know Prolog, and I consider myself a fast learner. (Java 1.01 in one day.)
Writing interactive code to determine family relationships in Prolog is easy. Writing a full application which scales is much, much harder. When your medium-sized program fails with no explanation or space leaks for no apparent reason, you really have to know the tricks.
You're right, though. Once you know the paradigm, adapting to anything else in that paradigm is easy. If you know Lisp, Haskell, ML and Erlang will all come easily. If you know Prolog, Mercury and Goedel will come easily. If you know Java, Eiffel and Sather will come easily.
Think about your favourite shrinkwrapped software. Chances are it doesn't only contain one executable.
As an example, my employer makes a product which includes a processor-intensive number crunching program, a compiler, a file format converter and a reporting tool. The number crunching program is in C++ (to keep a cap on performance). The file format converter needs to be in something which can be interfaced with C so it can use some third-party libraries. The compiler, however, has no other requirements and is not time-critical, and so is being rewritten in Haskell for ease of implementation.
The point being that even if it's hard to get two languages to talk to each other, multi-language application suites are more common than you think.
(Although, even Emacs is written mostly in Lisp...)
The Labor party was in favour of the Online Services Act too. Yes, Senator Alston is still a luddite and still in power, but in reality it didn't matter who won as far as this issue is concerned.
The technique doesn't date back to the 1960s. Alvy Ray Smith, who claims the technique's co-invention with Ed Catmull (who were both working at Lucasfilm at the time), says the earliest date on his alpha channel code is January 1978, but the technique was probably actually invented the previous December. (He has good reason for saying this, BTW. Final copy for Ed Catmull's 1978 SIGGRAPH paper was due in January, and the code in question was used to produce some of the figures.)
The definitive reference on the history of alpha is Alvy Ray Smith's technical memo from 1995. It seems pretty clear that he co-invented the technique with Ed Catmull as a solution to a problem that Catmull was having with his sub-pixel hidden surface algorithm.
The earliest dated documentation on his alpha channel code is January 13, 1978, although it was probably written the previous December. See footnote 4, page 6 of the memo for details.
What is interesting to note is that the original design of Windows NT with its servers was abandoned in NT 4.0.
Well, some of the servers are still there, but yes, you're right. NT until version 3.51 used to be an old-style object-oriented microkernel OS not unlike Mach (only better than Mach). Now it's a kind of a bastard child of microkernel and monolithic kernel, retaining some of the benefits and most of the drawbacks thereof.
Fiasco will be fantastic when it's finished, although I think using OSKit is a mistake except in the short term. However, a "real-time kernel" won't help if your drivers and servers aren't also low-latency. Beware of Linux drivers in particular. They almost all assume that interrupts are disabled during execution of the interrupt handler. Excising that will be hard.
Emacs users don't just edit ascii files. They also compile code, read news and get therapy from Eliza.:-)
Linux is a HELL lot more capable as an operating system than Hurd, in stability, efficiency, and capability.
I dunno about "capability". I'll agree with the other two, though. The stability and efficiency are mostly because of its longevity, of course. "Get it working then get it fast."
Slashdot Mirror
That's why sheep don't so much fly as plummet.
The comparison probably isn't fair because Pixar and Weta do very different jobs. Weta does visual effects and Pixar does character animation. They are superficially similar in that they often use the same modelling and rendering tools.
VFX houses generally have to produce "elements" to match existing photography (matching camera motion, set lighting and so on). That's actually where most of the trouble happens: getting things to match. So a VFX house's best friend is not necessarily the modeller and renderer, but the compositing system (Cineon, Shake, Avid, After Effects etc).
OTOH, Pixar has to build characters and worlds from scratch, like in traditional 3D animation (e.g. that of Aardman). Every prop and every piece of set decoration needs to be modelled, placed and rendered. Their best friend is the animation system (in Pixar's case, often incorrectly referred to by marketroids as "Marionette", but known to everyone inside the company as "Menv").
Note that this skips over a lot of detail (and I'll no doubt be corrected/chastised for oversimplifying things), so take this with the appropriate sodium chloride.
Would you be happier with GNU/Linux? *duck*
Er... that's what I said, wasn't it?
What Astral Traveller said was:
Now of course this is true. Linux can do the job. (Rumour has it that Pixar has found that FreeBSD running with Linux emulation is actually slightly faster at running prman than Linux itself for their kind of scenes, though. It's probably virtual memory performance dominating.) However, until someone comes up with a 14-CPU-per-box Linux machine, Pixar will stick with their Suns.
Monsters, Inc was modelled, animated and lit on SGIs and final rendering was done on Suns. No Linux here (yet).
I think you meant Shrek.
Though you won't find it in your job ads, having a lot of languages (and a lot of different kinds of languages at that) on your resume is a definite bonus. Especially if there's a variety of languages (procedural, OO, functional, logic etc), it shows that you can easily adapt to a new language should that become an issue.
The hot tub scene didn't do anything for Insurrection, if that's what you meant.
If you want to avoid surveillance, the optimal strategy is to walk six feet behind someone dressed like Carrot Top.
There's already a library which does some of this, and chances are you already have it installed: libiberty. Perhaps its role could be expanded a bit?
Kaplan's Understanding GPS: Principles and Applications asserts that GPS transmits Kepler elements whereas GLONASS transmits cartesian coordinates and derivatives. They also keep different time and use a different reference frame. Admittedly the book doesn't go into GLONASS in detail, however, is this information wrong?
All I meant by that is that if you're using GLONASS, chances are it won't correspond precisely to your map if it was made after 1985 or so. Sure, you can transform between the two systems, but that requires more smarts on the receiver, which eliminates the one potential advantage of GLONASS (having a simple receiver).
If you're just trying to find your way back to where you were, it won't make a difference. If you're trying to locate somewhere accurately on a map, it'll be an unnecessary headache.
GLONASS is a quite different system to GPS, and it's unclear whether or not buying GLONASS would be better than designing your own. The satellites only have a usable life of about 7.5 years for starters, so it would be a short-term measure at best.
GLONASS is designed for smart satellites and relatively dumb receivers, whereas GPS is designed for relatively dumb satellites and smart receivers. For example, the GLONASS satellites are in orbits with an almost zero eccentricity, so receivers don't need to correct for relativistic effects. (The Soviets were always much better than the US at getting things into very precise orbits.) The benefit of GPS here is that you can always upgrade a receiver if you want something even smarter. (The US has always been much better than the USSR at producing sophisticated consumer electronics.)
Also, GLONASS uses an older geodetic system than GPS, which makes it not as useful for advanced surveying applications.
Oh, I dunno. Tom Clancy predicted using a hijacked plane loaded with fuel as a bomb years before it was put into production. That's got to be worth something.
I've always thought the "cousins" from Farenheit 451 predicted online chat.
Even better would be if Linux had a translucent file system. Simply mount all the path directories on top of each other and let the OS do the rest.
For the uninitiated, a translucent file system lets you mount one filesystem on top of another filesystem, the idea being that if you tried to open a file the OS would first search the top filesystem, then the bottom one. In conjunction with non-root mounting of filesystems (e.g. in the Hurd) it removes the need for $PATH because you can just mount all the relevant directories on top of each other.
I know Prolog, and I consider myself a fast learner. (Java 1.01 in one day.)
Writing interactive code to determine family relationships in Prolog is easy. Writing a full application which scales is much, much harder. When your medium-sized program fails with no explanation or space leaks for no apparent reason, you really have to know the tricks.
You're right, though. Once you know the paradigm, adapting to anything else in that paradigm is easy. If you know Lisp, Haskell, ML and Erlang will all come easily. If you know Prolog, Mercury and Goedel will come easily. If you know Java, Eiffel and Sather will come easily.
Vet is still written in Australia, though it's owned by Computer Associates, so I don't know how tainted that makes them.
Think about your favourite shrinkwrapped software. Chances are it doesn't only contain one executable.
As an example, my employer makes a product which includes a processor-intensive number crunching program, a compiler, a file format converter and a reporting tool. The number crunching program is in C++ (to keep a cap on performance). The file format converter needs to be in something which can be interfaced with C so it can use some third-party libraries. The compiler, however, has no other requirements and is not time-critical, and so is being rewritten in Haskell for ease of implementation.
The point being that even if it's hard to get two languages to talk to each other, multi-language application suites are more common than you think.
(Although, even Emacs is written mostly in Lisp...)
The Labor party was in favour of the Online Services Act too. Yes, Senator Alston is still a luddite and still in power, but in reality it didn't matter who won as far as this issue is concerned.
Danny, what should people outside NSW do? Presumably writing to someone else's local member probably wouldn't make a difference.
Should I see my (Victorian) MP now or wait for legislation to be introduced here?
I guess I could write to the NSW Attorney General and thank them for killing the local internet industry in favour of other states...
The technique doesn't date back to the 1960s. Alvy Ray Smith, who claims the technique's co-invention with Ed Catmull (who were both working at Lucasfilm at the time), says the earliest date on his alpha channel code is January 1978, but the technique was probably actually invented the previous December. (He has good reason for saying this, BTW. Final copy for Ed Catmull's 1978 SIGGRAPH paper was due in January, and the code in question was used to produce some of the figures.)
Still well before 1992, of course.
The definitive reference on the history of alpha is Alvy Ray Smith's technical memo from 1995. It seems pretty clear that he co-invented the technique with Ed Catmull as a solution to a problem that Catmull was having with his sub-pixel hidden surface algorithm.
The earliest dated documentation on his alpha channel code is January 13, 1978, although it was probably written the previous December. See footnote 4, page 6 of the memo for details.
Well, some of the servers are still there, but yes, you're right. NT until version 3.51 used to be an old-style object-oriented microkernel OS not unlike Mach (only better than Mach). Now it's a kind of a bastard child of microkernel and monolithic kernel, retaining some of the benefits and most of the drawbacks thereof.
Fiasco will be fantastic when it's finished, although I think using OSKit is a mistake except in the short term. However, a "real-time kernel" won't help if your drivers and servers aren't also low-latency. Beware of Linux drivers in particular. They almost all assume that interrupts are disabled during execution of the interrupt handler. Excising that will be hard.
Emacs users don't just edit ascii files. They also compile code, read news and get therapy from Eliza. :-)
I dunno about "capability". I'll agree with the other two, though. The stability and efficiency are mostly because of its longevity, of course. "Get it working then get it fast."