Nonsense, the graphite in a PBMR will never melt. Some say, a leak could allow air into the reactor vessel and the graphite would burn, but even that is contested. Silicon-coated graphite definitely wouldn't.
The only thing that happened at Hamm-Uetrop was that some pebbles broke. Fuel and fission waste were still contained within the fuel particles, some clumsy handling then lead to the release of some coolant gas. I've never seen an estimate on how much activity was released with it (the helium itself is not radioactive). Nobody got hurt, but green wackos took the opportunity to kill a promising technology.
Hanford by the way isn't about nuclear power. They never produced a single kilowatt-hour, so that's a red herring anyway.
half of them probably not connected to any switch at a given time. Why do you need to complicate matters by "managing" ALL ports of ALL sites at once? What's there to manage anyway, you don't even have physical access to most of them!
Go back to basics, think about one subnet at a time. If you can't trust that no rogue machine will be connected to that net, don't run insecure protocols over it.
Bah, it's just the usual slashdot misinterpretation. Priviledge escalation was used to break in, so the cracker had local access before. The admins looked for weak passwords that could have been guessed and locked those users out. They can get back in if they use sensible passwords.
You cannot expect many tens of MiB/s when reading files, the sustained transfer rate is never reached in practice. Writing is slower, still. You're getting 5 MiB/s for essentially random reads and writes, and that's about all you can expect. Yes, that means hard disks are actually slow. They basically haven't gotten any faster over the last couple of years, only bigger.
Can it be sped up? No. dd or dump could read faster, but the former would shred the target filesystem and the latter couldn't speed up the writing. So let it copy overnight and be done with it.
Actually multithreading isn't such a bad idea. You will often have different threads of control, mostly independent of each other, and you want to keep them together, not rip them apart into request/response pairs that are queued somewhere. Doing the latter is about as maintainable as GOTO programs. The problems with multithreading start when threads interact in unpredictable ways, and that's what they do in C (and C dialects like C++, C#, Java, Pascal,...). That's also the principal cause of all then synchronity: you have to make sure that all side effects complete before a procedure returns. If a procedure could complete in the background while you don't yet access its result, you'd get rid of most latency. But things don't work this way in C.
The way out is to get rid of (most) global state. Without global state, thread cannot interact at all, with little global state, their interaction is manageable. That's what Erlang does (and to some extent, most functional languages). In fact, in Erlang virtually everything is done with threads (called processes), and it works beautifully. Of course, if you try hard enough you can still write a programm that is bogged down by network latency. No technology can protect against stupidity.
it only appears so. The GIOP protocol itself is completely asynchronous, invocations can be arbitrarily interleaved, results don't even need to be reported in the same order the requests came in. What is synchronous, however, are the language bindings. Then again, how else would you embed remote invocations into C and similar languages? Without first class functions is is simply too cumbersome to compose a program out of parallel invocations and continuations. The only way out are threads, and multithreading should properly be written multithreating.
But consider a functional language. It would be ridiculously easy to define a language mapping where you could explicitly set off parallel invocations, or you could call each invocation with a continuation that tells it what to do when it eventually returns. Nobody did this, and the only explanation is that the guys at OMD did not know Standard ML. That explains some other major blunders, like missing recursive structures, but I digress...
So we get another one. Everybody who has the slightest problem with CORBA goes off and builds the successor. How many more square wheels without spokes do we need? KDE started with CORBA, then invented DCOP. OpenOffice disliked CORBA, then created UNO. This Henning fellow grew tired of CORBA and made Ice, and what drove the D-BUS guys to add another one is simply beyond me. And most often the only visible "progress" is the replacement of IDL and IIOP by some XML hackery. Well no, I don't fscking care that an XML parser is "the only dependency I need". I don't want the bloated monster (it's just a lexer posing as a poor man's parser anyway), and I want it even less if I still have to do the hard work in my head!
What's wrong with the GNOME approach? They simply fixed the crappy CORBA implementation. It works.
I spent almost 3 years working on an abstraction layer over CORBA
All right, I'll bite. What's there possibly to abstract?!
CORBA gives you network transparent objects. They look like objects in your host language. Nothing to learn here. You only need to orb_init and resolve_initial_references and go on acting as if everything happened on your machine. (But you shouldn't, naive network transparency will bite you.) What could possibly abstract more from the network than that without taking away all the power?
Well, some language bindings, notably C++, could benefit from an abstraction layer. Actually, they'd benefit more from being replaced. I hope you wasted your time "only" writing a wrapper layer for some specific interfaces. That's legitimate, though it is also an indication that these interfaces were crap.
No, I won't. To be honest, I have a bit of a problem with Mr. Henning. I'm pretty sure he misunderstood some parts of CORBA back in the day when he co-authored "Advanced CORBA Programming in C++", and his misconceptions only got worse in time (the tantrum he threw about the allegedly useless "oneway" directive particularly stuck). The he started working on Ice and since that day constantly derailed CORBA as bloated and fundamentally flawed. But it isn't. It is fixable, and it is an open standard, while Ice isn't. And I don't trust the guy not to make more fundamental mistakes; second-system-effect and all that.
BTW, what bugs me about CORBA, is that the most interesting part are poorly documented: the Interface Repository and the wire protocol. Were they easier to grok, you could pull information about an interface from the IR (no need for an IDL compiler) and generate a very simple stub from scratch. Voila! A custom made stellite ORB, almost trivial to write in any programming language, and no heavyweight like that MICO abomination, either. Heck, this way both IDL and the ugly C++ mapping could long be a thing of the past, someone would already support something-sharp, and I would have written my 100% pure Haskell ORB. But no, that would destroy the market for commercial ORBs.
Boy, I'm starting to positively hate this whole industry.
Encryption: IIOP over SSL works. Many ORBs support it directly, and then there's always stunnel. Authentication: gimme a break! HTTP/Basic is a goddamn cleartext password! You can transmit that in the message context, if you want. (Possibly the only application for that context nonsense, but it's there anyway.)
Java RMI can always be faster
Haha, you're so full of it. RMI is exactly the same as CORBA, the original protocol is a bit different, but RMI can also speak IIOP. No, CORBA doesn't transmit "description of the objects". Nonsense, all it gives is the class name, for the benefit of dynamic clients.
Re:What a ridiculous trend... CORBA to WebServices
on
The Rise and Fall of Corba
·
· Score: 3, Interesting
Butbutbut... CORBA is simple! WTF are you doing?
More specifically, CORBA does what needs to be done. You want location transparency, so you need a wire protocol and object references that include endpoint adresses. You want language neutrality, so you need the IDL. These parts are necessary and not overly complicated. A Naming Service is probably a good idea, and it is still simple.
What are you doing that's complicated? Trading Service or stuff layered even on that? Useless junk. Programming in C++? Okay, that mapping is crap. But why? People are constantly grappling with stuff they neither want nor need. Just don't use it, and optionally fix the faults in the things that are needed. (My wishlist: gimme a better C++ mapping that knows about STL, gimme me an ORB for Haskell, allow parametric polymorphism.)
Well, you can. It's actually dead simple: CORBA is RPC, just that you don't address some particular service, you invoke a method on an object reference, which contains the servers address. Add in an interoperable binary protocol, a standard language to define interfaces and some standard mappings to common programming languages, that's all there is to it. Services are completely optional, the ORB, commonly depicted as an all encompassing cloud with mystic abilities, is just a support library to decode object references and speak the wire protocol. For the long version, here's CORBA in 5 Minutes.
Now why the confusing websites? Well, what would you do as a vendor? Tell your clients (managers!) that you're selling them an RPC library? No way! It has to be Object Oriented Middleware, it must be Enterprise, and everything ties into the mystic ORB. You absolutely need an ORB! Well, you didn't in the 80's, but this is the 21st century and there you need an ORB! Oh, and what a remarkable conincidence... we are just selling ORBs!
Anyway, have a look at ORBit. CORBA can actually be simple. It's commercial software that cannot.
Doh, my math skills seem to be a bit rusty, and nobody notices. I also remembered the numbers incorrectly. Bruce Schneier says, Twofish costs 17.8 cycles per byte, so a 1.7GHz cpu could encrypt 100MB/s. The bus is still hard pressed to shovel that much data back and forth and it is still a lot more than a hard disk can deliver, especially if it is read and written at the same time.
I'm also assuming he's doing nothing else with the disk. Also, what's not to understand about "order of magnitude"?! Dude, it's I/O bound, no matter what else he's doing. And frankly, I cannot imagine why anyone would read/decrypt/write a chunk of 30GB at a time. Completely useless, doing it in the background while using the data (must be pr0n flicks anyway) would make much more sense.
The performance hit is not always negligible (there's a reason why numerical work is still coded in Fortran), and I'd like to see the "intepreted language" that has shorter development time and is more powerful than OCaml. And what's more widely available than C? Probably only BASIC.
Besides, being compiled/interpreted/something-in-between is NOT a property of a language but of a language's implementation. Use Haskell and you can choose between all three. There are more things than C- and Perl-lookalikes.
Assume a sustained transfer rate of 30MB/s, which is quite good for a single hard disk. You won't get that much when transferring lots of small files. Reading 30GB takes 1000s or about 18 minutes, writing it back another 18 minutes, doing both takes longer, because interleaving both processes will lower the transfer rate. If you're shredding the old data, you can add in another 20 minutes per pass. So encrypting 30GB takes 60 minutes, probably a lot more, and there's nothing you could do about it in software.
Encryption itself... I seem to remember that TwoFish needs 26 clocks to encrypt 8 bytes on a Pentium. So your 2.6GHz CPU can encrypt 8GB/s (but the bus cannot deliver that much, I suspect). Add in some fudge factors for OS overhead and other tasks, and you're still two orders of magnitude below the IO time.
You seem to live in a pretty small world, where there's no Lisp, Modula, O'Caml, Smalltalk, Haskell, Eiffel, Scheme,...
Crappy programmers stuck with BASIC/PHP/Perl will be crappy programmers forever. Crappy programmers using Lisp might achieve enlightenment one day. Don't forget, every good programmer started out as a crappy neophyte.
UCS is an independent nonprofit alliance of more than 100,000 concerned citizens and scientists. We augment rigorous scientific analysis with innovative thinking and committed citizen advocacy to build a cleaner, healthier environment and a safer world.
So most of them are not actually scientists and how "augmenting scientific analysis" and "scientific integrity" can be compatible is anybodies guess. They also have ulterior motives that will inevitably colour their "science", and they are even admitting it, showing their ignorance. Sorry, but they are a bunch of crackpots.
If you try and fail, you're certainly no worse off than if you just sit around on your ass wishing the problem would disappear!!
Well, this is wrong. If you try, you lose whatever effort you expend trying. If you fail, that's wasted. Therefore you shouldn't try unless you are reasonably sure the expedted outcome is better than the expended effort. If you're not sure, you should gather more information. Don't forget that any poorly understood "solution" might actually make the problem worse. There comes a point where gathering more information is likely to be more expensive than just trying what is best according to current knowledge, and that's when you actually try something. Until then, the best advice is
When my mother learned touch typing on a mechanical(!) typewriter, they had cardboard covers to block the view to the keys. Some students peeked under the covers, some didn't. Those who didn't generally learned touch typing faster. And I mean faster: 300 characters per minute is damn fast, even more so on that mechanical monstrosity.
That was somewhere in the 1960's. Mechanical typewriters went the way of the dodo, "typist" is no longer a profession, but not seeing your keycaps still helps the muscle memory remembering them.
of convincing your boss. If he's already decided that VB is the right tool for everything (apparently he has), nothing will convince him otherwise.
On a more general note, every programming language is suitable for everything, modulo availability of specific libraries. There are languages that are simply superiour, and they are always the better choice, with the possible exception of small throw-away programs and speed sensitive inner loops. VB is not one of them, but you won't convince your boss.
Therefore, write the sodden thing in VB or get a better job. Your boss is an idiot for not letting you use the best tool for the job, but he doesn't know and he doesn't want to be educated about that.
Damn well he is. Any boss, who tells his engineers what tool to use, is stupid. It doesn't matter if the prescribed tool is crap (VB), inferior (C#) or good (Lisp), he should simply trust his engineers to know best.
Interesting, I didn't know of this particular implementation. Slyck's explanation only covers simple parity, which is only capable of recovering a single missing block. An explanation of more sophisticated codes can be found on http://www.eccpage.com/. SmartPAR is probably using a Reed-Solomon-Code.
In principle, there's no need for temporary storage for the whole batch of data. Storage for all parity files would suffice and still allow single pass coding. Even better, given online storage for the redundant images would allow to incrementally add another image to the store and update the parity files. A system with such capabilities would be quite handy for large archives, and SmartPAR falls a bit short, as you noticed. Come to think of it, implementing something like that could actually be a fun project.
BTW, back in the days when floppy discs were state of the art, it annoyed me no end that every single floppy that spent some months on the shelf would certainly be missing one track when reading it. 79 tracks would be okay, and one broken, usually making the whole archive on it useless. A simple RS code would have helped. Alas, I didn't know about them back then. Neither did anybody else, it seems...
use DVD-RAMs. They are much better engineered, without needless backwards compatibility and designed for long term storage. They're also a bit more expensive. If it's important enough, always have at least two copies of your data. (I guess, some king of ECC over many DVDs would be possible, but I doubt that anyone has ever implemented something like that.)
Other than that, as others have already pointed out, you can always buy harddiscs. It's not what they're designed for, but still the easiest solution.
Slashdot Mirror
Nonsense, the graphite in a PBMR will never melt. Some say, a leak could allow air into the reactor vessel and the graphite would burn, but even that is contested. Silicon-coated graphite definitely wouldn't.
The only thing that happened at Hamm-Uetrop was that some pebbles broke. Fuel and fission waste were still contained within the fuel particles, some clumsy handling then lead to the release of some coolant gas. I've never seen an estimate on how much activity was released with it (the helium itself is not radioactive). Nobody got hurt, but green wackos took the opportunity to kill a promising technology.
Hanford by the way isn't about nuclear power. They never produced a single kilowatt-hour, so that's a red herring anyway.
half of them probably not connected to any switch at a given time. Why do you need to complicate matters by "managing" ALL ports of ALL sites at once? What's there to manage anyway, you don't even have physical access to most of them!
Go back to basics, think about one subnet at a time. If you can't trust that no rogue machine will be connected to that net, don't run insecure protocols over it.
Bah, it's just the usual slashdot misinterpretation. Priviledge escalation was used to break in, so the cracker had local access before. The admins looked for weak passwords that could have been guessed and locked those users out. They can get back in if they use sensible passwords.
Nothing to see here, please move on.
You cannot expect many tens of MiB/s when reading files, the sustained transfer rate is never reached in practice. Writing is slower, still. You're getting 5 MiB/s for essentially random reads and writes, and that's about all you can expect. Yes, that means hard disks are actually slow. They basically haven't gotten any faster over the last couple of years, only bigger.
Can it be sped up? No. dd or dump could read faster, but the former would shred the target filesystem and the latter couldn't speed up the writing. So let it copy overnight and be done with it.
Actually multithreading isn't such a bad idea. You will often have different threads of control, mostly independent of each other, and you want to keep them together, not rip them apart into request/response pairs that are queued somewhere. Doing the latter is about as maintainable as GOTO programs. The problems with multithreading start when threads interact in unpredictable ways, and that's what they do in C (and C dialects like C++, C#, Java, Pascal, ...). That's also the principal cause of all then synchronity: you have to make sure that all side effects complete before a procedure returns. If a procedure could complete in the background while you don't yet access its result, you'd get rid of most latency. But things don't work this way in C.
The way out is to get rid of (most) global state. Without global state, thread cannot interact at all, with little global state, their interaction is manageable. That's what Erlang does (and to some extent, most functional languages). In fact, in Erlang virtually everything is done with threads (called processes), and it works beautifully. Of course, if you try hard enough you can still write a programm that is bogged down by network latency. No technology can protect against stupidity.
it only appears so. The GIOP protocol itself is completely asynchronous, invocations can be arbitrarily interleaved, results don't even need to be reported in the same order the requests came in. What is synchronous, however, are the language bindings. Then again, how else would you embed remote invocations into C and similar languages? Without first class functions is is simply too cumbersome to compose a program out of parallel invocations and continuations. The only way out are threads, and multithreading should properly be written multithreating.
But consider a functional language. It would be ridiculously easy to define a language mapping where you could explicitly set off parallel invocations, or you could call each invocation with a continuation that tells it what to do when it eventually returns. Nobody did this, and the only explanation is that the guys at OMD did not know Standard ML. That explains some other major blunders, like missing recursive structures, but I digress...
So we get another one. Everybody who has the slightest problem with CORBA goes off and builds the successor. How many more square wheels without spokes do we need? KDE started with CORBA, then invented DCOP. OpenOffice disliked CORBA, then created UNO. This Henning fellow grew tired of CORBA and made Ice, and what drove the D-BUS guys to add another one is simply beyond me. And most often the only visible "progress" is the replacement of IDL and IIOP by some XML hackery. Well no, I don't fscking care that an XML parser is "the only dependency I need". I don't want the bloated monster (it's just a lexer posing as a poor man's parser anyway), and I want it even less if I still have to do the hard work in my head!
What's wrong with the GNOME approach? They simply fixed the crappy CORBA implementation. It works.
I spent almost 3 years working on an abstraction layer over CORBA
All right, I'll bite. What's there possibly to abstract?!
CORBA gives you network transparent objects. They look like objects in your host language. Nothing to learn here. You only need to orb_init and resolve_initial_references and go on acting as if everything happened on your machine. (But you shouldn't, naive network transparency will bite you.) What could possibly abstract more from the network than that without taking away all the power?
Well, some language bindings, notably C++, could benefit from an abstraction layer. Actually, they'd benefit more from being replaced. I hope you wasted your time "only" writing a wrapper layer for some specific interfaces. That's legitimate, though it is also an indication that these interfaces were crap.
No, I won't. To be honest, I have a bit of a problem with Mr. Henning. I'm pretty sure he misunderstood some parts of CORBA back in the day when he co-authored "Advanced CORBA Programming in C++", and his misconceptions only got worse in time (the tantrum he threw about the allegedly useless "oneway" directive particularly stuck). The he started working on Ice and since that day constantly derailed CORBA as bloated and fundamentally flawed. But it isn't. It is fixable, and it is an open standard, while Ice isn't. And I don't trust the guy not to make more fundamental mistakes; second-system-effect and all that.
BTW, what bugs me about CORBA, is that the most interesting part are poorly documented: the Interface Repository and the wire protocol. Were they easier to grok, you could pull information about an interface from the IR (no need for an IDL compiler) and generate a very simple stub from scratch. Voila! A custom made stellite ORB, almost trivial to write in any programming language, and no heavyweight like that MICO abomination, either. Heck, this way both IDL and the ugly C++ mapping could long be a thing of the past, someone would already support something-sharp, and I would have written my 100% pure Haskell ORB. But no, that would destroy the market for commercial ORBs.
Boy, I'm starting to positively hate this whole industry.
Encryption: IIOP over SSL works. Many ORBs support it directly, and then there's always stunnel.
Authentication: gimme a break! HTTP/Basic is a goddamn cleartext password! You can transmit that in the message context, if you want. (Possibly the only application for that context nonsense, but it's there anyway.)
Java RMI can always be faster
Haha, you're so full of it. RMI is exactly the same as CORBA, the original protocol is a bit different, but RMI can also speak IIOP. No, CORBA doesn't transmit "description of the objects". Nonsense, all it gives is the class name, for the benefit of dynamic clients.
Butbutbut... CORBA is simple! WTF are you doing?
More specifically, CORBA does what needs to be done. You want location transparency, so you need a wire protocol and object references that include endpoint adresses. You want language neutrality, so you need the IDL. These parts are necessary and not overly complicated. A Naming Service is probably a good idea, and it is still simple.
What are you doing that's complicated? Trading Service or stuff layered even on that? Useless junk. Programming in C++? Okay, that mapping is crap. But why? People are constantly grappling with stuff they neither want nor need. Just don't use it, and optionally fix the faults in the things that are needed. (My wishlist: gimme a better C++ mapping that knows about STL, gimme me an ORB for Haskell, allow parametric polymorphism.)
Well, you can. It's actually dead simple: CORBA is RPC, just that you don't address some particular service, you invoke a method on an object reference, which contains the servers address. Add in an interoperable binary protocol, a standard language to define interfaces and some standard mappings to common programming languages, that's all there is to it. Services are completely optional, the ORB, commonly depicted as an all encompassing cloud with mystic abilities, is just a support library to decode object references and speak the wire protocol. For the long version, here's CORBA in 5 Minutes.
Now why the confusing websites? Well, what would you do as a vendor? Tell your clients (managers!) that you're selling them an RPC library? No way! It has to be Object Oriented Middleware, it must be Enterprise, and everything ties into the mystic ORB. You absolutely need an ORB! Well, you didn't in the 80's, but this is the 21st century and there you need an ORB! Oh, and what a remarkable conincidence... we are just selling ORBs!
Anyway, have a look at ORBit. CORBA can actually be simple. It's commercial software that cannot.
So the difference is that Debian is nicely modular while Vista is impenetrable spaghetti code.
Figured as much.
Doh, my math skills seem to be a bit rusty, and nobody notices. I also remembered the numbers incorrectly. Bruce Schneier says, Twofish costs 17.8 cycles per byte, so a 1.7GHz cpu could encrypt 100MB/s. The bus is still hard pressed to shovel that much data back and forth and it is still a lot more than a hard disk can deliver, especially if it is read and written at the same time.
I'm also assuming he's doing nothing else with the disk. Also, what's not to understand about "order of magnitude"?! Dude, it's I/O bound, no matter what else he's doing. And frankly, I cannot imagine why anyone would read/decrypt/write a chunk of 30GB at a time. Completely useless, doing it in the background while using the data (must be pr0n flicks anyway) would make much more sense.
The performance hit is not always negligible (there's a reason why numerical work is still coded in Fortran), and I'd like to see the "intepreted language" that has shorter development time and is more powerful than OCaml. And what's more widely available than C? Probably only BASIC.
Besides, being compiled/interpreted/something-in-between is NOT a property of a language but of a language's implementation. Use Haskell and you can choose between all three. There are more things than C- and Perl-lookalikes.
Assume a sustained transfer rate of 30MB/s, which is quite good for a single hard disk. You won't get that much when transferring lots of small files. Reading 30GB takes 1000s or about 18 minutes, writing it back another 18 minutes, doing both takes longer, because interleaving both processes will lower the transfer rate. If you're shredding the old data, you can add in another 20 minutes per pass. So encrypting 30GB takes 60 minutes, probably a lot more, and there's nothing you could do about it in software.
Encryption itself... I seem to remember that TwoFish needs 26 clocks to encrypt 8 bytes on a Pentium. So your 2.6GHz CPU can encrypt 8GB/s (but the bus cannot deliver that much, I suspect). Add in some fudge factors for OS overhead and other tasks, and you're still two orders of magnitude below the IO time.
You need faster disks.
You seem to live in a pretty small world, where there's no Lisp, Modula, O'Caml, Smalltalk, Haskell, Eiffel, Scheme, ...
Crappy programmers stuck with BASIC/PHP/Perl will be crappy programmers forever. Crappy programmers using Lisp might achieve enlightenment one day. Don't forget, every good programmer started out as a crappy neophyte.
So most of them are not actually scientists and how "augmenting scientific analysis" and "scientific integrity" can be compatible is anybodies guess. They also have ulterior motives that will inevitably colour their "science", and they are even admitting it, showing their ignorance. Sorry, but they are a bunch of crackpots.
If you try and fail, you're certainly no worse off than if you just sit around on your ass wishing the problem would disappear!!
Well, this is wrong. If you try, you lose whatever effort you expend trying. If you fail, that's wasted. Therefore you shouldn't try unless you are reasonably sure the expedted outcome is better than the expended effort. If you're not sure, you should gather more information. Don't forget that any poorly understood "solution" might actually make the problem worse. There comes a point where gathering more information is likely to be more expensive than just trying what is best according to current knowledge, and that's when you actually try something. Until then, the best advice is
Don't just do something, stand there!
When my mother learned touch typing on a mechanical(!) typewriter, they had cardboard covers to block the view to the keys. Some students peeked under the covers, some didn't. Those who didn't generally learned touch typing faster. And I mean faster: 300 characters per minute is damn fast, even more so on that mechanical monstrosity.
That was somewhere in the 1960's. Mechanical typewriters went the way of the dodo, "typist" is no longer a profession, but not seeing your keycaps still helps the muscle memory remembering them.
of convincing your boss. If he's already decided that VB is the right tool for everything (apparently he has), nothing will convince him otherwise.
On a more general note, every programming language is suitable for everything, modulo availability of specific libraries. There are languages that are simply superiour, and they are always the better choice, with the possible exception of small throw-away programs and speed sensitive inner loops. VB is not one of them, but you won't convince your boss.
Therefore, write the sodden thing in VB or get a better job. Your boss is an idiot for not letting you use the best tool for the job, but he doesn't know and he doesn't want to be educated about that.
But that doesn't mean the boss is being stupid.
Damn well he is. Any boss, who tells his engineers what tool to use, is stupid. It doesn't matter if the prescribed tool is crap (VB), inferior (C#) or good (Lisp), he should simply trust his engineers to know best.
Interesting, I didn't know of this particular implementation. Slyck's explanation only covers simple parity, which is only capable of recovering a single missing block. An explanation of more sophisticated codes can be found on http://www.eccpage.com/. SmartPAR is probably using a Reed-Solomon-Code.
In principle, there's no need for temporary storage for the whole batch of data. Storage for all parity files would suffice and still allow single pass coding. Even better, given online storage for the redundant images would allow to incrementally add another image to the store and update the parity files. A system with such capabilities would be quite handy for large archives, and SmartPAR falls a bit short, as you noticed. Come to think of it, implementing something like that could actually be a fun project.
BTW, back in the days when floppy discs were state of the art, it annoyed me no end that every single floppy that spent some months on the shelf would certainly be missing one track when reading it. 79 tracks would be okay, and one broken, usually making the whole archive on it useless. A simple RS code would have helped. Alas, I didn't know about them back then. Neither did anybody else, it seems...
use DVD-RAMs. They are much better engineered, without needless backwards compatibility and designed for long term storage. They're also a bit more expensive. If it's important enough, always have at least two copies of your data. (I guess, some king of ECC over many DVDs would be possible, but I doubt that anyone has ever implemented something like that.)
Other than that, as others have already pointed out, you can always buy harddiscs. It's not what they're designed for, but still the easiest solution.