And that is why the block checksum is a function not only of the contents of the block but of its address on disk. If the disk picks up the wrong block, the address you input into the checksum won't match and the verify will fail.
On the transport layer? That doesn't make any sense. The endpoint implementations insert into language-standard growable arrays (PHP native indexed arrays, C++ std::vector, et al), as they should.
hashes
Easily represented as maps.
sets
They have those. Templated type 'set' in the Thrift interface file (just like std::set).
arbitrary nested structures
And those. map<string, map<string, set<string> > > is a perfectly valid construct in the Thrift file, and will emit (as you might expect) the same thing using STL data structures in the C++ endpoint, or nested assocative arrays in the PHP endpoint. The same thing applies to non-templated structure nesting as well, and to templating around user defined structures.
canonicalized timestamps
There's no good reason to make a separate timestamp class; an int64 is plenty big enough to hold microseconds (or nanoseconds, even) since the epoch.
If the display goes out, just boot it in Firewire target mode (power on and hold T) and plug it into another computer to pull off all of your precious, precious animal porn.
No, not laptop batteries; CMOS batteries. Standard CR2032 button cells. We had a batch of machines (SX270), a few of which shipped with CMOS batteries going bad, so we RMA'd for 5 new CMOS batteries. (as was policy at the time -- might as well get all of our warranty support that we can, and such.)
We received a box about 12 x 12 x 8 inches. This box contained 5 inner boxes, each about the size of a standard retail software box. Inside each box, the top and bottom were covered in eggcarton foam. In the center of each box was a single CMOS battery.
1080p is lower resolution than many computer monitors (UXGA, 1600x1200) and about the same as most (SXGA, 1280x1024)
1080p = 1920x1080 progressive scan (not interlaced). Usually @ 24 fps (also 1080p24).
Since when have 1600x1200 or 1280x1024 been considered higher resolution than 1920x1080? (Hint: 1,920,000 or 1,310,720 pixels, respectively, vs 2,073,600)
Disclaimer: I don't know much about the software layout of a Tivo.
Since it's based on Linux, you can grab a copy of IBM's iSCSI target reference implementation from the web, and point it at the drive. Access the iSCSI target 'ro' on any other suitable machine.
Or you could use NBD, but that might require a kernel module. The iSCSI target runs entirely in userland.
Both of these, though, involve installing more software on the Tivo. Without some really weird hardware sitting between the drive and the Tivo's motherboard, that's the best you're going to get.
Low demand equals high cost when the company manufacturing the product is trying to recoup its initial outlay for that product. More products moved means that the R&D and production runup costs (and other one-time expenses) can be amortized across more units, therefore (in theory) bringing the individual unit cost down.
If I make a single motherboard, it'll have a higher per-unit cost than some company that is spreading the pre-production costs across 100,000 units.
I've built a few robot platforms around the 68hc11 brain, and that chip is the easiest one to get started with:
8 bucks each, from any number of suppliers
Single-chip solution - the only external components are an 8 MHz crystal and 2x 22pf capacitors
DIP package - fits into Radio Shack solderless breadboards nicely
It's fast - a whopping 2 MHz
256 bytes of RAM, and a 2K EEPROM for program storage
16 lines of digital I/O, 8 ADCs, input compare and output compare timer lines, 2 serial ports, and a few other nicities
You can download code to it over the serial port (and write it into the EEPROM), with the addition of 1 more chip - a MAX232 serial level converter. Tools for its instruction set (compilers, assemblers, etc) are very easy to find, as are schematics for a basic setup for the chip and for the serial converter. A google search should reveal a BASIC and a FORTH compiler for it, among various other (free) tools.
The guys at the Seattle Robotics Society do a lot with this architecture, and they have plenty of articles and links pertaining to it.
On the performance differences side, I had the same experience. The machine was an AMD K6/2 400 with a 3dfx Voodoo3 2000 16MB AGP - Windows 2000 and (Redhat) Linux dual boot.
Under Windows - Quake3 was fine in 1024x768, slow to the point of unplayability at 1280x1024.
Under Linux - After finally getting hardware 3d acceleration working (wow, I never want to hear the words "Glide OpenGL Wrapper" ever again...) - completely playable in 1600x1200, highest detail settings, at 50 FPS (bottoming out at 30FPS with too many rockets onscreen). On a Voodoo 3. I was absolutely amazed.
I doubt the differences will be THAT pronounced (I blame it on 3dfx's Windows drivers being horrible), but it certainly would be nice to have the Linux port of Doom3 running faster than on Windows.
Last I checked, Tyan's 4way Opteron boards start at $1500 and change. And then you have to get the 8xx series processors. Not exactly cheap - $1250 for the Opteron 848, $855 for the 846 (or if you really have cash to blow, $1549 for the 850). And then you need some good registered ECC DDR400 RAM - $120 per 512 meg stick of Kingston, and I'd want to put several gigs in a machine like that... Plus incidentals like a huge case, really big fans and an even bigger power supply, and you're getting into some serious cash outlay - $8000+ for a 4x 848 with 4 GB of RAM.
Re:A (small) case in point for open-source tools
on
SIGGraph and Open Source
·
· Score: 4, Insightful
Thanks, I think you just finished the point I was trying to make. I guess I should've said shared-source, but I was drawing a blank for the right terminology there.
What I was trying to imply is that if companies can make the code available to their customers, it becomes much easier to integrate their products into the existing software environment. For something simple like a word processor, this wouldn't make much sense; it already stands alone. But for such a complex environment like a computer graphics production pipeline, with software from different manufacturers and (sometimes) running on different platforms all needing to work seamlessly together, eventually you're going to run into an integration problem. And in all likelyhood, the company producing the software package in question hasn't had the time nor the resources to test your exact configuration.
So in this scenario, if you don't have the source, you're left at the whim of the manufacturer to fix the problems. Maybe they will, maybe they won't. But if your software license (that you bought and paid for, just like any other software - I'm not advocating giving this stuff away for free) includes the ability to easily get the source and make your own modifications to it, then you both win. The company gets their money and you can fit it into your pipeline. If the source license also includes proceedures and methods to submit said changes back either to the company for a potential merge into the main source tree (if it doesn't break something else), or to a user community group where other (licensed!) users can view code patches and apply them to their own (legally licensed!) copy of the code, then EVERYONE wins. Including the company that is now selling more licenses of the software because it is gaining new features and having integration issues fixed up.
But just open-sourcing the code will probably put companies out of business ("why pay when you can just grab the code yourself?"), and we don't need that.
A (small) case in point for open-source tools
on
SIGGraph and Open Source
·
· Score: 5, Interesting
As a student, I use Pixar's tools - Renderman Artist Tools 6.0 and Renderman Pro Server 11.5.3, plugged into Maya 5.0.1.
Why did I start using these tools? Maya's Fur renderer was (and still is) a complete piece of shit. No offense to anyone who's actually gotten it to work well, but... damn. If you've ever used it, you'll know what I'm talking about, specifically in regards to the lighting, and trying to match it to the rest of your scene. And yes, I've tried Maya 6 rendering out Fur in Mental Ray - something about trying to allocate several gigs of RAM just for the Fur, where PRMan would use 800 MB for the whole scene, turned me off from that. And RAT includes a plugin to build Fur out of RiCurves primitives. Perfect match, right? Of course.
Well, it was lacking a couple of features. Specifically, Attractor Influence Start and Influence End (specifying how far along the length of each hair dynamic attractors would affect the curve direction). Thankfully, Pixar decided to throw in the code for the mtorFurProcedural DSO with the toolkit. So I added the 6 (or so) lines of code needed to implement those features, recompiled, and it now works perfectly, exactly the way I'd expect it to.
And then the shading model being used wasn't giving me the results I needed. I took a look at a paper (from a previous SIGGRAPH) on the fur shading used in Stuart Little, specifically in regards to mixing the underlying surface's normal with the hair normal. Sounds like a good idea, think I'll try that. Oops, the plugin doesn't pass that information to the shader. 10 lines of code later - a new shader variable, surface_normal, has been added. And after modifying a shader to take advantage of that (loosely based on the example code in the paper), the shading looks infinitely better than anything I EVER got out of Maya. Score another point for having the source.
Unfortunately, there was also another bug, this time in the mtor_maya5 plugin (which, being the bulk of the product, is NOT open source). I had to reimplement the command that the mtorUltraFur RIBGen plugin was using to dump the surface information (for each uv coord: x, y, z, normal vector, u vector, v vector), because its handling of trimmed NURBS surfaces was broken. That was irritating, but made possible because I had the source to the plugin and was able to change the command that it was calling (to my own plugin's name). (Though it would've been easier if I had the source to the mtor_maya5 plugin as well...)
So, because I got the source with the tools, I was able to very quickly fix the problems that showed up, and tune them to do exactly what I needed them to do.
The hardware repair percentage for servers is probably higher because the people who are in charge of maintaining the servers generally should be proficient enough not to have to call tech support for software issues. My friend's place of employment runs several Sun machines (a pair of Sun Fire 240s, a couple of Blade 1000s, and a few other machines), with a Sun service contract covering everything, and he's only had to call them on a non-hardware issue once (some obscure configuration thing, I don't remember what it was).
I know that for Sun machines, you can find pretty much all of the software support you need (and a lot of the hardware support, save replacing parts) through SunSolve, BigAdmin, and simply googling it.
If you need 3d characters or assets (including texture/bump maps and such), I can do just about any modelling/rigging/animation in any format that Maya can export (or for which specs can be provided, so I can write a translator). And seeing as how I'm a student currently on summer break, I have plenty of spare time and don't expect to be paid much, if anything.
Interested? Shoot me an email: sabretooth@gmail.com
Re:Dangers of using ATA or SATA for Raid
on
SATA vs ATA?
·
· Score: 3, Informative
SCSI drives tend to have the same size (or larger) caches as [S]ATA drives. You can disable the write-behind caching on any drive fairly easily using hdparm. ( hdparm -W 0/dev/... to disable, -W 1 to enable).
Of course, if you are using a hardware RAID controller, you'll have to figure out how to tell it to disable the write-behind cache on the drives under its control. Perhaps it will be smart enough to figure it out if you use the hdparm command on the logical device it presents to the operating system, but I'd certainly want to read the manual and find out.
I know from experience that Windows 2000 automatically disables write-behind caching on drives in software RAID arrays (and dumps some Informational messages in the system log to let you know what's going on).
The latest version of Visual Studio that I have is 6.0, but I still think you're right. MS puts a lot of thought and work into their dev tools, and it really shows; it is unfortunate that they can't get that same level of quality across all of their software!
On a side note, have you checked out XCode on a recent Mac? I've used that, too, and it is a very nice environment to work in.
XServe RAID is fibre channel, which is basically SCSI spoken over a serial link (well, switch IDs for WWNs, add fabric support, stuff like that, but still SCSI). Try to convince him based on that. Tell him it's like the difference between using 10base2 and 10baseT - same protocol you've grown accustomed to, different physical medium.
Or hide his body under the false floor after taking over his job. Whichever works.
Ahh crap, maybe I shouldn't have offered that. 6 emails already... I'm going to put a web page up detailing how I did it. I won't be posting the link here because my cable modem will probably catch fire.
I don't know what the setup for After Effects and such looks like, but I managed to build a pretty good Sun Grid Engine system for distributing Maya batch renders. SGE is free, works on Linux or Solaris, x86 or SPARC (I obviously used the x86 linux binaries), and seems to be very well designed. I set up a pretty solid system for netbooting the clients, running them diskless (or with local swap drives), adding new clients on the fly (all scripted), and it all worked flawlessly. You could submit a batch job and it would distribute it per-frame as an array job to all the different nodes. Or you could just run SETI on all of them...
It's since been taken down in favor of running Alfred (because I no longer use Maya's builtin renderer, we've moved on to MTOR and PRMan), but I still have all of the files and scripts for it. If anyone's interested, I'd be happy to share: sabretooth@gmail.com
"He has a fast computer with maya and photoshop, and everything else worthwhile installed. but he has shitty ram that core dumps quite often causing the computer to reboot, and he never takes the time to make a backup!"
Been there, done that (on Linux, so Maya stays, but s/photoshop/FilmGIMP/). Except instead of shitty RAM (but I've had plenty of that too), it was a shitty power supply that could barely support dual Athlons at idle. Kick off a batch render that runs for more than 30 minutes or so, and the comp would reboot. Until one hot day, when it went into coma mode and the PS fried itself. That was quite entertaining.
Oh, now look what I've done. What was the topic again?
I know a few "smart" people who have zero motivation. They could do just about anything with a computer that they wanted (with very few exceptions), but all of them sit on their collective asses and chat on IRC all day. Sound familiar to anyone? Well, if it does, try to do something about it. Try to get them interested in something.
Me? I ran for years protecting the assumption that everyone is as smart as I, but that little holdout has been long since chipped away. I have found myself with the ability to pick up and learn new things, computer-related or not. Everything is a challenge and, as I find myself saying quite often (to justify my position to other, usually): "How hard could it possibly be?" This is the kind of mindset that gets such interesting results as everyone else wheeling up wooden catapults for a project in Physics, and me unloading a 200-pound solid steel Ballista. Taught myself to weld, mainly because I wanted to try it (and not because I was not skilled enough in the art of wood working to build it from wood instead).
Just trying new things has gone a long way towards my figuring out what I want to do with my life (seeing as how I'm only 17 at this point). Take any opportunity you possibly can to try and learn to do something you've never done before, no matter what you think the outcome may be. If all else fails, you'll have another skillset to stuff on the mental dusty shelf in the corner, but you may just find something you like to do.
Well, prior art aside, what I meant is that they won't get their patents because SGI has most likely already patented the technologies behind it. Of course, if they tack "on the internet" to the end, they could probably get all of their applications immediately granted...
This kind of system has been around for quite some time, both the software and hardware to do it. SGI's Onyx4 uses their OpenGL Multipipe software kit (which works on unmodified OpenGL apps), a bunch of ATI FireGL cards, and some digital video compositing hardware to do both loadbalancing for complex data sets (what Alienware is doing) and realtime rendering at resolutions much higher than any one card could support (tiling).
The thing that's new about this implementation is that you won't have to run out and drop $40,000 on the base Onyx4 if you have an application that needs this (to some extent - SGI's solution will go to 16 cards, with the bandwidth to drive them all, while Alienware's is currently limited to 2). Only $4000 for the Alienware box.
Somehow I doubt that Alienware will get the patents that are 'pending' - I'd imagine that SGI probably already has a whole portfolio covering this area, since this kind of thing is their bread and butter. It's nice, though, to see a consumer-affordable implementation of this technology coming to market.
Well, Ghost is a bit more advanced than DD. It copies the filesystem structures and the files exactly (as far as [the NTFS/FAT32 equivalent of] inode numbers and such), but it doesn't bother copying the unallocated space, and it compresses the image on the fly.
which will zero all of the free space in the partition, then pipe the actual dd of the partition through bzip2 or gzip.
Then you have all of the Ghost enterprise features like being able to multicast a Ghost image, netboot to autoghost, push images (remotely trigger a reboot and image download), deploy individual applications (like Windows installer automated deployments, except that it works), etc... which I'm sure you can do with free software anyway, but it's nice to have the convenient package.
Slashdot Mirror
And that is why the block checksum is a function not only of the contents of the block but of its address on disk. If the disk picks up the wrong block, the address you input into the checksum won't match and the verify will fail.
There's no good reason to make a separate timestamp class; an int64 is plenty big enough to hold microseconds (or nanoseconds, even) since the epoch.
If the display goes out, just boot it in Firewire target mode (power on and hold T) and plug it into another computer to pull off all of your precious, precious animal porn.
No, not laptop batteries; CMOS batteries. Standard CR2032 button cells. We had a batch of machines (SX270), a few of which shipped with CMOS batteries going bad, so we RMA'd for 5 new CMOS batteries. (as was policy at the time -- might as well get all of our warranty support that we can, and such.)
We received a box about 12 x 12 x 8 inches. This box contained 5 inner boxes, each about the size of a standard retail software box. Inside each box, the top and bottom were covered in eggcarton foam. In the center of each box was a single CMOS battery.
1080p is lower resolution than many computer monitors (UXGA, 1600x1200) and about the same as most (SXGA, 1280x1024) 1080p = 1920x1080 progressive scan (not interlaced). Usually @ 24 fps (also 1080p24). Since when have 1600x1200 or 1280x1024 been considered higher resolution than 1920x1080? (Hint: 1,920,000 or 1,310,720 pixels, respectively, vs 2,073,600)
Disclaimer: I don't know much about the software layout of a Tivo.
Since it's based on Linux, you can grab a copy of IBM's iSCSI target reference implementation from the web, and point it at the drive. Access the iSCSI target 'ro' on any other suitable machine.
Or you could use NBD, but that might require a kernel module. The iSCSI target runs entirely in userland.
Both of these, though, involve installing more software on the Tivo. Without some really weird hardware sitting between the drive and the Tivo's motherboard, that's the best you're going to get.
Low demand equals high cost when the company manufacturing the product is trying to recoup its initial outlay for that product. More products moved means that the R&D and production runup costs (and other one-time expenses) can be amortized across more units, therefore (in theory) bringing the individual unit cost down.
If I make a single motherboard, it'll have a higher per-unit cost than some company that is spreading the pre-production costs across 100,000 units.
I've built a few robot platforms around the 68hc11 brain, and that chip is the easiest one to get started with:
- 8 bucks each, from any number of suppliers
- Single-chip solution - the only external components are an 8 MHz crystal and 2x 22pf capacitors
- DIP package - fits into Radio Shack solderless breadboards nicely
- It's fast - a whopping 2 MHz
- 256 bytes of RAM, and a 2K EEPROM for program storage
- 16 lines of digital I/O, 8 ADCs, input compare and output compare timer lines, 2 serial ports, and a few other nicities
You can download code to it over the serial port (and write it into the EEPROM), with the addition of 1 more chip - a MAX232 serial level converter. Tools for its instruction set (compilers, assemblers, etc) are very easy to find, as are schematics for a basic setup for the chip and for the serial converter. A google search should reveal a BASIC and a FORTH compiler for it, among various other (free) tools.The guys at the Seattle Robotics Society do a lot with this architecture, and they have plenty of articles and links pertaining to it.
On the performance differences side, I had the same experience. The machine was an AMD K6/2 400 with a 3dfx Voodoo3 2000 16MB AGP - Windows 2000 and (Redhat) Linux dual boot.
Under Windows - Quake3 was fine in 1024x768, slow to the point of unplayability at 1280x1024.
Under Linux - After finally getting hardware 3d acceleration working (wow, I never want to hear the words "Glide OpenGL Wrapper" ever again...) - completely playable in 1600x1200, highest detail settings, at 50 FPS (bottoming out at 30FPS with too many rockets onscreen). On a Voodoo 3. I was absolutely amazed.
I doubt the differences will be THAT pronounced (I blame it on 3dfx's Windows drivers being horrible), but it certainly would be nice to have the Linux port of Doom3 running faster than on Windows.
Last I checked, Tyan's 4way Opteron boards start at $1500 and change. And then you have to get the 8xx series processors. Not exactly cheap - $1250 for the Opteron 848, $855 for the 846 (or if you really have cash to blow, $1549 for the 850). And then you need some good registered ECC DDR400 RAM - $120 per 512 meg stick of Kingston, and I'd want to put several gigs in a machine like that... Plus incidentals like a huge case, really big fans and an even bigger power supply, and you're getting into some serious cash outlay - $8000+ for a 4x 848 with 4 GB of RAM.
Thanks, I think you just finished the point I was trying to make. I guess I should've said shared-source, but I was drawing a blank for the right terminology there.
What I was trying to imply is that if companies can make the code available to their customers, it becomes much easier to integrate their products into the existing software environment. For something simple like a word processor, this wouldn't make much sense; it already stands alone. But for such a complex environment like a computer graphics production pipeline, with software from different manufacturers and (sometimes) running on different platforms all needing to work seamlessly together, eventually you're going to run into an integration problem. And in all likelyhood, the company producing the software package in question hasn't had the time nor the resources to test your exact configuration.
So in this scenario, if you don't have the source, you're left at the whim of the manufacturer to fix the problems. Maybe they will, maybe they won't. But if your software license (that you bought and paid for, just like any other software - I'm not advocating giving this stuff away for free) includes the ability to easily get the source and make your own modifications to it, then you both win. The company gets their money and you can fit it into your pipeline. If the source license also includes proceedures and methods to submit said changes back either to the company for a potential merge into the main source tree (if it doesn't break something else), or to a user community group where other (licensed!) users can view code patches and apply them to their own (legally licensed!) copy of the code, then EVERYONE wins. Including the company that is now selling more licenses of the software because it is gaining new features and having integration issues fixed up.
But just open-sourcing the code will probably put companies out of business ("why pay when you can just grab the code yourself?"), and we don't need that.
As a student, I use Pixar's tools - Renderman Artist Tools 6.0 and Renderman Pro Server 11.5.3, plugged into Maya 5.0.1.
Why did I start using these tools? Maya's Fur renderer was (and still is) a complete piece of shit. No offense to anyone who's actually gotten it to work well, but... damn. If you've ever used it, you'll know what I'm talking about, specifically in regards to the lighting, and trying to match it to the rest of your scene. And yes, I've tried Maya 6 rendering out Fur in Mental Ray - something about trying to allocate several gigs of RAM just for the Fur, where PRMan would use 800 MB for the whole scene, turned me off from that. And RAT includes a plugin to build Fur out of RiCurves primitives. Perfect match, right? Of course.
Well, it was lacking a couple of features. Specifically, Attractor Influence Start and Influence End (specifying how far along the length of each hair dynamic attractors would affect the curve direction). Thankfully, Pixar decided to throw in the code for the mtorFurProcedural DSO with the toolkit. So I added the 6 (or so) lines of code needed to implement those features, recompiled, and it now works perfectly, exactly the way I'd expect it to.
And then the shading model being used wasn't giving me the results I needed. I took a look at a paper (from a previous SIGGRAPH) on the fur shading used in Stuart Little, specifically in regards to mixing the underlying surface's normal with the hair normal. Sounds like a good idea, think I'll try that. Oops, the plugin doesn't pass that information to the shader. 10 lines of code later - a new shader variable, surface_normal, has been added. And after modifying a shader to take advantage of that (loosely based on the example code in the paper), the shading looks infinitely better than anything I EVER got out of Maya. Score another point for having the source.
Unfortunately, there was also another bug, this time in the mtor_maya5 plugin (which, being the bulk of the product, is NOT open source). I had to reimplement the command that the mtorUltraFur RIBGen plugin was using to dump the surface information (for each uv coord: x, y, z, normal vector, u vector, v vector), because its handling of trimmed NURBS surfaces was broken. That was irritating, but made possible because I had the source to the plugin and was able to change the command that it was calling (to my own plugin's name). (Though it would've been easier if I had the source to the mtor_maya5 plugin as well...)
So, because I got the source with the tools, I was able to very quickly fix the problems that showed up, and tune them to do exactly what I needed them to do.
The hardware repair percentage for servers is probably higher because the people who are in charge of maintaining the servers generally should be proficient enough not to have to call tech support for software issues. My friend's place of employment runs several Sun machines (a pair of Sun Fire 240s, a couple of Blade 1000s, and a few other machines), with a Sun service contract covering everything, and he's only had to call them on a non-hardware issue once (some obscure configuration thing, I don't remember what it was).
I know that for Sun machines, you can find pretty much all of the software support you need (and a lot of the hardware support, save replacing parts) through SunSolve, BigAdmin, and simply googling it.
At this time, I think it'd be best to point out that most positive numbers are greater than zero...
If you need 3d characters or assets (including texture/bump maps and such), I can do just about any modelling/rigging/animation in any format that Maya can export (or for which specs can be provided, so I can write a translator). And seeing as how I'm a student currently on summer break, I have plenty of spare time and don't expect to be paid much, if anything.
Interested? Shoot me an email: sabretooth@gmail.com
SCSI drives tend to have the same size (or larger) caches as [S]ATA drives. You can disable the write-behind caching on any drive fairly easily using hdparm. ( hdparm -W 0 /dev/... to disable, -W 1 to enable).
Of course, if you are using a hardware RAID controller, you'll have to figure out how to tell it to disable the write-behind cache on the drives under its control. Perhaps it will be smart enough to figure it out if you use the hdparm command on the logical device it presents to the operating system, but I'd certainly want to read the manual and find out.
I know from experience that Windows 2000 automatically disables write-behind caching on drives in software RAID arrays (and dumps some Informational messages in the system log to let you know what's going on).
The latest version of Visual Studio that I have is 6.0, but I still think you're right. MS puts a lot of thought and work into their dev tools, and it really shows; it is unfortunate that they can't get that same level of quality across all of their software!
On a side note, have you checked out XCode on a recent Mac? I've used that, too, and it is a very nice environment to work in.
XServe RAID is fibre channel, which is basically SCSI spoken over a serial link (well, switch IDs for WWNs, add fabric support, stuff like that, but still SCSI). Try to convince him based on that. Tell him it's like the difference between using 10base2 and 10baseT - same protocol you've grown accustomed to, different physical medium.
Or hide his body under the false floor after taking over his job. Whichever works.
Ahh crap, maybe I shouldn't have offered that. 6 emails already... I'm going to put a web page up detailing how I did it. I won't be posting the link here because my cable modem will probably catch fire.
I don't know what the setup for After Effects and such looks like, but I managed to build a pretty good Sun Grid Engine system for distributing Maya batch renders. SGE is free, works on Linux or Solaris, x86 or SPARC (I obviously used the x86 linux binaries), and seems to be very well designed. I set up a pretty solid system for netbooting the clients, running them diskless (or with local swap drives), adding new clients on the fly (all scripted), and it all worked flawlessly. You could submit a batch job and it would distribute it per-frame as an array job to all the different nodes. Or you could just run SETI on all of them...
It's since been taken down in favor of running Alfred (because I no longer use Maya's builtin renderer, we've moved on to MTOR and PRMan), but I still have all of the files and scripts for it. If anyone's interested, I'd be happy to share: sabretooth@gmail.com
Been there, done that (on Linux, so Maya stays, but s/photoshop/FilmGIMP/). Except instead of shitty RAM (but I've had plenty of that too), it was a shitty power supply that could barely support dual Athlons at idle. Kick off a batch render that runs for more than 30 minutes or so, and the comp would reboot. Until one hot day, when it went into coma mode and the PS fried itself. That was quite entertaining.
Oh, now look what I've done. What was the topic again?
I know a few "smart" people who have zero motivation. They could do just about anything with a computer that they wanted (with very few exceptions), but all of them sit on their collective asses and chat on IRC all day. Sound familiar to anyone? Well, if it does, try to do something about it. Try to get them interested in something.
Me? I ran for years protecting the assumption that everyone is as smart as I, but that little holdout has been long since chipped away. I have found myself with the ability to pick up and learn new things, computer-related or not. Everything is a challenge and, as I find myself saying quite often (to justify my position to other, usually): "How hard could it possibly be?" This is the kind of mindset that gets such interesting results as everyone else wheeling up wooden catapults for a project in Physics, and me unloading a 200-pound solid steel Ballista. Taught myself to weld, mainly because I wanted to try it (and not because I was not skilled enough in the art of wood working to build it from wood instead).
Just trying new things has gone a long way towards my figuring out what I want to do with my life (seeing as how I'm only 17 at this point). Take any opportunity you possibly can to try and learn to do something you've never done before, no matter what you think the outcome may be. If all else fails, you'll have another skillset to stuff on the mental dusty shelf in the corner, but you may just find something you like to do.
Well, prior art aside, what I meant is that they won't get their patents because SGI has most likely already patented the technologies behind it. Of course, if they tack "on the internet" to the end, they could probably get all of their applications immediately granted...
This kind of system has been around for quite some time, both the software and hardware to do it. SGI's Onyx4 uses their OpenGL Multipipe software kit (which works on unmodified OpenGL apps), a bunch of ATI FireGL cards, and some digital video compositing hardware to do both loadbalancing for complex data sets (what Alienware is doing) and realtime rendering at resolutions much higher than any one card could support (tiling).
The thing that's new about this implementation is that you won't have to run out and drop $40,000 on the base Onyx4 if you have an application that needs this (to some extent - SGI's solution will go to 16 cards, with the bandwidth to drive them all, while Alienware's is currently limited to 2). Only $4000 for the Alienware box.
Somehow I doubt that Alienware will get the patents that are 'pending' - I'd imagine that SGI probably already has a whole portfolio covering this area, since this kind of thing is their bread and butter. It's nice, though, to see a consumer-affordable implementation of this technology coming to market.
Well, Ghost is a bit more advanced than DD. It copies the filesystem structures and the files exactly (as far as [the NTFS/FAT32 equivalent of] inode numbers and such), but it doesn't bother copying the unallocated space, and it compresses the image on the fly.
/path/to/partition/zero.dat
Though if you want to do that with dd, you could:
dd if=/dev/zero of=/path/to/partition/zero.dat bs=1048576 count=freespace-in-MB
rm
which will zero all of the free space in the partition, then pipe the actual dd of the partition through bzip2 or gzip.
Then you have all of the Ghost enterprise features like being able to multicast a Ghost image, netboot to autoghost, push images (remotely trigger a reboot and image download), deploy individual applications (like Windows installer automated deployments, except that it works), etc... which I'm sure you can do with free software anyway, but it's nice to have the convenient package.