Slashdot Mirror
LoTR , Linux, and Database Management
minus23 writes: "Very interesting article over at Digitalanimators.com, talking about some of the challenges faced by the crew working on the second installment in the Lord of the Rings Trilogy. Interesting bits include managing an off-site database of 45TBs, Linux workstations from IBM, 1400 processors, and the animation methods to be used on Gollum. It's a good thing. :)"
It's just for the kids these days. Can't push those few brain cells of theirs that are supposed to bring books to life, so they harness a few rooms of whirring computers to do it for them.
Now if we just used those things to do molecular interaction models for AIDS vaccines, maybe Tolkien wouldn't be spinning in his grave right now.
On a consumer level I would agree with you; I doubt Dell/HPaq/IBM etc would bother with your average home user on stability issues. On the other hand, this is a very high profile client. It wouldn't suprise me if they had dedicated staff available to help with any issues, stability or otherwise, that came up.
Overall, the article was a good read. But, I must point to the following observation..
..."
"... The problem with Linux is that it's an open source system, so if you are having issues or difficulties with its stability, it's like pushing on a rope; there's no single vendor to deal with.
The very next paragraph...
"Weta had just taken delivery of 25 Linux workstations from IBM and Labrie reported that IBM and Hewlett Packard were the frontrunners for additional Linux workstation upgrades."
Alright, so... what am I missing here? You've got IBM behind your efforts. Whats the problem?
Perhaps the comment was referring to specific pieces of software, although my experience has been that dealing with a group of open developers is far more useful than dealing with a single inept vendor. When the vendor is full of crap, where else can you turn?
The first paragraph I mentioned continues...
"You have to be self-deterministic in terms of how things work. You have to make your own choices and do your own tests on motherboards, graphics cards, applications, operating system releases, all those kinds of things."
Again, I'm not buying this comment either... afterall, you have IBM behind you! Don't they test the motherboards, graphics cards, operating system releases, and all those kind of things?
Obviously Linux has been a good solution for them because they're using it. They're having success with it, and its saving them loads of $$ versus using an alternative proprietary system.
Can't wait to see this installment of LOTR!
Skiers and Riders -- http://www.snowjournal.com
forma3
Back in your day they had smelly old puppets made from sheep bladders and ping-pong balls with dots. Real fucking smart.
But yeah - 'computers do all the work' is the fable. Computers only do work to render between key frames, or to replicate something you've already done. Sorta like turning a puppet head and having the interia spin it.
Or perhaps you mean 'book vs tv: the ancient debate'. There's always that baseless idea that your imagination is moved more in a book (I was one of those dorks thinking about Fight Club for months after the fact). Fact is that books aren't as accessible to people as a movie is. I sat for three hours and got more information than I would for 3 hours with the book. Now they had to remove detail from the book to make it pallatable to the masses, but there's no particular reason why the movie medium is bad. That's an attack on commercial movies - not movies themselves.
A picture says a thousand words.
I have not found this to be the case with enterprise vendors and customers who pay for real support. When you have access to the vendor's engineers (not just the front-line tech support drones), you can get answers to problems that would completely stump an outsider.
If you ring up Sun with a Platinum support call for an E15K, I can pretty much guarantee that they won't start by telling you to "restore the system".
The main advantage to having a single point of contact for this sort of support is that you have a better shot at accessing the expertise (though usually indirectly) of the primary maintainers of a given piece of code. IBM is probably well equipped to deal with a wide range of Linux problems, but there will definitely be times when the best resource is someone at SGI, HP or some random university. This advantage is largely mitigated by the widespread availability of sourcecode, but it could still be significant when you need answers right now.
This type of processing is the reason people used to pay a hefty premium for systems from folk like DEC who had lots of experience filling a room with machines and getting them to work reliably.
...then you have some incredibly unstable software. This isn't a "designed for fault-tolerance", it's not even normal - it's less stable than your average Windows-based desktop system. It's fallacious to use this example to attempt to support your arguments.
Perhaps you should tell that to Google, who seem to have realised you can make Linux work stably enough to run a cluster of 10,000 machines. I'm not saying there's no place in the world for commercial Unix, but the single vendor argument was always weak and remains so. If I pay Red Hat (for example) the same amount of money I pay DEC (Compaq/HP, whatever), there's no reason to expect I won't get the same level of support.
Separately, there's the consideration of whether I'm better off paying DEC/Sun/X this enormous chunk of change for their premium "we don't randomly close your tickets" support level vs. just supporting my large cluster in-house. Clusters are, oddly enough, the place where this comparison leans closest toward the in-house argument - hundreds/thousands of sets of identical hardware means you only have to solve the hardware/software compatibility issues once, only have to keep one type of replacement hardware around, etc.
If you have a system that is using multiple processors in a single computational task you have to have both software that is designed for fault tolerance and a very high level of basic reliability.
Actually, part of the point of clustering is that you don't need enormous levels of fault tolerance. You only need the systems to be as fault-tolerant as the rate at which you can replace them (though, sure, it's nice to have them quite a lot more fault-tolerant than that).
If you have a render wall of 256 processors and each one in standalone mode runs for a week without a crash
PenguiNet: the (shareware) Windows SSH client