For what it's worth, the 404 error page being served on http://www.google.com/chrome is not their standard one - their standard one is to search for the whole url from the looks of things?
I guess it probably takes quite a bit of time to push out a config change to all of the servers that respond to www.google.com. So they've probably told them all to start proxying the content from a main server [cluster] somewhere so they can update it quickly when they've got the release together.
I'll say one thing from Microsoft - when you could use MS Java it never (not once in the several years we supported it) broke apps and patches were actually PATCHES and not whole new broken versions.
That's because they never bothered adding new features to it. When they withdrew it in -- what, 2003? -- it was functionally equivalent to Sun's v1.2, which was released in 1998. It's easy to ensure patches don't break stuff when you're implementing a 5 year old standard.
Good summary. Not much I'd suggest doing differently, except that I'd recommend getting familiar with JUnit a little earlier than you suggest, and learning test-driven development whether or not you intend on doing XP -- of all the new ideas XP contains, TDD seems to be the most useful.
Not entirely sure I agree there. Spring's an IoC framework with a lot of bells & whistles. Some of its other features (e.g. automatic wrapping of objects with transaction controllers) are as generally useful as the IoC stuff.
But, yes, agree with the rest of your point: you'll get more from it if you understand why you want IoC in the first place. I prefer the more "modern" name, dependency injection, as it makes the purpose somewhat clearer.
Which means: first step, if it's not a skill you already have, is learning test automation. Test automation is the key reason you want dependency injection. So, in order:
* core Java stuff * learn a little about J2EE * pick up JUnit and learn to write good tests with it * learn Spring
If you use automated payment, if the system fucks up, you'll personally spend hours upon hours on the telephone with said company trying to get the insanity dealt with. "No, no that's not what our system says here sir, the amount we deducted from your account is US$45.97" "But you deducted US$495.70!" "No sir that is not what our system says". It will take days, if not weeks, to get things straightened out.
That's the problem with your system, right there. Here's how it works in the UK:
(Call utility company) "You charged me £495.70" "No, we charged you £45.97" "Refund me £495.70 now, or I'll get my bank to take it back from you.
(In the unlikely event that they refuse, call bank) "I've been overcharged on a direct debit. Can you refund it for me?" "Certainly. What's your account number?"
My favorite part, if you've RTFA to the very end[...]
I wish I could. But NYT seems to have deleted my account with them (the username and password from my autologin aren't working any more) and when I try to register again I get a page that says "Please check the highlighted areas below" and then shows a form field that is correctly filled in.:(
Stories of epic fails with DDs are legion - an extra zero on the bill makes the person go overdrawn, they get a bad credit record, they lose their house, they kill all their family and so on. I exaggerate. Slightly.
You do know that if an incorrect direct debit makes you go overdrawn, all you have to do is tell your bank and they will refund it to you, along with any charges/interest that occurred because of it, and correct any incorrect information that has been placed on your credit record, don't you? All it takes to fix a direct debit error is one phone call...
I guess that I can't think of a problem where Perl would be the best solution anymore.
Any task that involves iterating over a bunch of lines, applying pattern matching to them. Perl is well optimized for this, and handles it substantially better than python. Although it's worth considering whether either sed or awk might be better -- they often are.
WTF does a CIO have to worry about languages for? That's the development manager's problem. The CIO's problem is the management of the organization and the technology big picture. How said technology is implemented isn't his problem: that's just minor details. I guess a micro manger would be concerned about a scripting language. If that's the case, he needs to quit and get a tech management job.
You seem to have a large-company oriented image of the world. Let me broaden your horizons a little: approximately 99% of the businesses in the developed world have fewer than 500 employees. OK, so a lot of these won't have CIOs (or people with equivalent titles, like mine: IT Director). But many do. Enough that probably 80-90% of CIOs in the world are working in these companies.
These CIOs don't have development managers to assist them with these details. They have to interact directly with developers themselves, or, in some cases, have to _be_ developers themselves. So, yes, a large majority of CIOs do, in fact, have to concern themselves with the specifics of implementation in this fashion. For them, being a CIO _is_ a tech management job.
For example, if you have a "return" statement in a block that's passed into a function, and the called function yields to the block, Ruby returns from the calling function, rather than "returning" from the block (yield'ing nil), and not returning from the called function either. However, if the called function wraps its block in a lambda before calling it (if, say it wants to pass it to another function like in your example), the same return statement in the block has a completely different effect, depending on how the block is used. I see why it was done, but don't think the overall design is right, especially if blocks are special like that but you can't pass multiple blocks into a function.
Coming from a smalltalk background, that'll be _exactly_ what's bothering the original poster. Smalltalk statement blocks use the former pattern rather than the latter, with the result that the design is _extremely_ neat. It lets you produce new flow control primitives, for example:
randomlyExecuteEither: block_a or: block_b
| randomlySelectedBlock |
"code to randomly assign either block_a or block_b to randomlySelectedBlock goes here"
randomlySelectedBlock value.
When executed, the two statement blocks, "[ ^ 1 ]" (return 1) and "[ ^ 2 ]" (return 2) are passed to the randomlyExecuteEither:or: method, which picks one and executes it. This causes myTestMethod to return, not the closure, and not randomlyExecute.... The coding style it enables is clear, readable and very useful. You can do it in smalltalk or lisp, but not (it would appear) ruby. This is definitely to ruby's disadvantage.
Many of the language features that Ruby proponents bring up are often found in some way or another in Python, Lisp, or Perl.
Hmm... I think that of those, only LISP supports statement blocks passed as parameters to a function, which is, you know, the key language feature of Ruby.
The only _other_ language I know that supports that is smalltalk.
I'd be happy to learn about other languages with the feature.
Unless a language is self hosting, i.e. written in itself, I wouldn't call it a 'full' language.
Disagree. It must be _possible_ to produce a self-hosted implementation of the language, but it isn't necessary for anyone to actually do so, I.M.O.
Why? First, the language that the implementation you are using has little actual effect on the usefulness of the language you are using (unless that language is sub-optimally efficient, in which case it may diminish that usefulness).
Also, we're moving into an era now where single components (class libraries, virtual machines, parsers, optimizers, machine-specific object code generators) are more and more commonly shared between multiple language front-ends. It would be silly to classify a language as "not full" just because its implementers decided not to reinvent the wheel and reused somebody else's work to simplify their own job.
Example: the leading Ada95 compiler is GNAT. GNAT is an Ada front end that uses the back end optimization and platform-dependent output sections from GCC, which are obviously written in C. Is Ada therefore not a "full" language? The notion is absurd: by any reasonable definition of "full", Ada95 should probably be one of the leading examples.
Javascript doesn't have an interactive prompt (that I know of),
Netscape used to have one, but it seems to have been removed from modern Mozilla projects. You can run javascript interactively by typing 'javascript:[statement]' into your URL bar, though.
This led to a californian state senator to call for a ban on the use of all perfluorocarbons (the group of chemicals that contains both PFOA and PF5080) in the food industry. The call has not lead to any action.
OK, that last sentence might be misleading. There is a bill in-progress in the californian senate (SB-1313), which will ban "perfluorinated compounds" from use in food packaging. It looks likely that it will pass.
(b) "Perfluorinated compounds" means perfluorooctanoic acid (PFOA) or perfluorooctane sulfonate (PFOS), or PFOA- and PFOS-homologues that differ only in the length of the fluorinated carbons and contain more than six fluorinated carbon atoms, or chemicals that are reasonably suspected to degrade in the environment to PFOA or PFOS, or PFOA- and PFOS-homologues containing more than six fluorinated carbon atoms. "Perfluorinated compound" includes all acids, salts, or ionic forms of the perfluorinated compounds.
This does not include any form of fluorinert, unless "degrad[ing] in the environment" is considered to include being exposed to sulphuric acid.
Also, IIRC, California recently added Flourinert to it's list of potentially cancer causing chemicals, which IMHO makes it less than ideal for a warm LED lit water fall in your living room or office...
Fluorinert is not one chemical, but a family of them marketed under the same name. This machine uses PF5080, which is also known as perfluorooctane.
The case you have likely heard about relates to perfluorooctanoic acid (PFOA), a related but distinct chemical that is used as an industrial cleaning agent, and also in the process of applying teflon coatings. There are concerns that it could accumulate in the food supply, and that it would be carcinogenic in this case. This led to a californian state senator to call for a ban on the use of all perfluorocarbons (the group of chemicals that contains both PFOA and PF5080) in the food industry. The call has not lead to any action.
FWIW, perfluorocarbons, including some variants of fluorinert, have actually been suggested as anti-cancer drugs, and PF5080 is being considered for use as human medication (as a vector for delivery of anaesthetics). Rats have routinely survived being immersed in oxygenated PF5080 for prolonged periods with no ill effects. If you've seen the film The Abyss, you've seen a rat breathing PF5080.
They got their flourinert from an old supercomputer, and that's not a viable supply for fullscale production.
There are suppliers that will provide generic perfluorooctane (the same stuff, just not manufactured by 3M) for a figure that means this machine wouldn't have to be priced at _too_ extreme a figure. At least compared to the top end config recommended by the hardware site/. linked to yesterday...
Once again, an article that sparks my interest, then someone comes along and destroys it with reality...
You can do the same thing with mineral oil. Unfortunately, the higher viscosity will make it harder to pump the fluid around effectively (you _can_ do it with an ordinary fan, but they won't last for very long) while the lower heat capacity will mean you need to pump more of it around more quickly.
it says right in the abstract that they are using 70kg of the stuff. Prices online seem the range from about 500-1000 USD per gallon, usually in 3 gallon minimum quantities.
OK... must have missed that.:) Note that a gallon of the stuff weighs significantly more than equivalent water. 70kg is approximately 9gal.
Looking at the prices I see, I could acquire 70kg of the stuff for $2,500 US. There are good deals to have if you look around for them! For a showpiece item like this, I don't think $2,500 on cooling fluid is too much. OK, I wouldn't spend it. But then I'm sitting here typing this on an old Celeron D. I'm not the kind of person who this is targetted to.
I'm merely suggesting that wasting ~10k USD on coolant and then building a giant gaudy waterfall enclosure isn't exactly how I'd go about doing a project like this.
I'm struggling to get a good grasp on the scale of that thing to estimate how much flourinert would be required, but I don't think it's as expensive as you think it is. 5kg of the stuff can be had for significantly under $1000 US, and I doubt they're using 50kg of the stuff in there.
You've probably seen small order prices (250ml or thereabouts) and have extrapolated. That's a bad extrapolation: large orders don't cost more than a small percentage extra.
turning the area near the CPU into a mini deep fryer - definitely not cool!
Hmm. Vegetable oil's a dielectric, you know.
I'm thinking of an 8-core 5Ghz quad-crossfire 5-litre fryer. Should do the job. You'd just need to make sure you had a way to throttle back your overclocking before you reached the flashpoint.
It seems like somebody's already on the right track...
Fixed resolution 8bit/channel RGB data will degrade gracefully with random bit errors (to an extent), unlike compressed formats like JPG and PNG which will just die completely.
Actually, there are several known algorithms that allow recovery of complete information from JPEG files with small numbers of random bit errors in them. E.g. this one. JPEG2000 is considered much more resiliant, also; it is, in fact, optimised for transmission over unreliable media (e.g. one-way satellite links).
You'd be much better off using ECCs (e.g. reed-solomon, or even, in the extreme, storing 3 copies of the file so you can process them bit-by-bit and pick the most common value at each point) to find and correct bit errors than using uncompressed images and letting them degrade arbitrarily.
Note that most media you're likely to use is probably using error correction anyway, so single bit errors are unlikely: they would be found and fixed by the media itself. Probably the smallest error you'll see is an unreadable block of a few hundred bits. So the block cipher is unlikely to be much of an issue, as the media you're likely to be recording on has exactly the same issue: errors wipe out blocks, not individual bits.
Ummm... I'm sure that most of us who are 25 years old or older have pictures of themselves that are stored in bad conditions and still look decent.
Yes, but the pictures I printed on my HP Deskjet 640C only 10 years ago are already looking significantly faded.
Digital photo printing and colour photography are not the same process, and have different expected lifetimes. Some of it is down to the paper, and some is down to the inks. I don't know how those pictures would look if I'd used glossy, acid-free paper -- I suspect they'd be significantly better. I don't know how much better the prints from my current printer (an Epson R285) will fare. Printing for archival isn't as simple as it sounds.
The common suggestion is to make sure you use a pigment-based ink and high quality acid-free paper. Stuff printed like that should (apparently) last 100 years before it fades noticeably. Obviously that's based on "accelerated aging" results, so may or may not be truly accurate, but it's probably a ballpark figure.
This might be an attractive alternative, but the profit margin (for an essentially illegal operation) would need to be decidedly low to attract people from any other jobs even in the poorest areas.
Why would you say the operation is illegal? What (Russian/Chinese) laws are being broken?
English pointy clicky tools like this certainly do exist and certainly pre-date any Russian or Chinese tools; when was SATAN first developed?
Except, well, no.
The two aren't really comparable. SATAN is a tool designed to fulfil a perfectly legitimate purpose, which happens to also be able to do some things that aren't exactly legal.
These tools are (mostly, at least) things that have no legitimate purpose. What's the legitimate purpose behind a service to provide forged ID? A marketplace for stolen credit card data? Running authorization requests to find the likely amount of cash you can get away with taking from one of those cards via hijacked merchant accounts? Producing custom botnets on-demand using pre-compromised end-user PCs?
The point is that in Russia and some other Eastern European countries (many of which have populations that speak Russian due to Soviet occupation), and probably also China, you can get away with providing this kind of service, because the local police in these countries don't generally cooperate with international investigations, so as long as the people being ripped off are in another country, they won't bother you.
In most English-speaking countries, you can't get away with doing this kind of thing because the local police will proactively investigate this kind of activity regardless of who the victim is likely to be, and will definitely cooperate with international requests for assistance with this kind of criminal activity.
Which is why these tools are predominantly Russian-language. I'm not so sure about Chinese, but I'd certainly not be surprised to find Chinese tools in this field significantly outnumbering native-English ones (i.e., not counting those that are produced in English to attract an international market but are clearly run from countries such as those I mention above).
Slashdot Mirror
For what it's worth, the 404 error page being served on http://www.google.com/chrome is not their standard one - their standard one is to search for the whole url from the looks of things?
I guess it probably takes quite a bit of time to push out a config change to all of the servers that respond to www.google.com. So they've probably told them all to start proxying the content from a main server [cluster] somewhere so they can update it quickly when they've got the release together.
would be an *online browser*. Like Google docs.
Oh, that. Already been done.
I'll say one thing from Microsoft - when you could use MS Java it never (not once in the several years we supported it) broke apps and patches were actually PATCHES and not whole new broken versions.
That's because they never bothered adding new features to it. When they withdrew it in -- what, 2003? -- it was functionally equivalent to Sun's v1.2, which was released in 1998. It's easy to ensure patches don't break stuff when you're implementing a 5 year old standard.
Good summary. Not much I'd suggest doing differently, except that I'd recommend getting familiar with JUnit a little earlier than you suggest, and learning test-driven development whether or not you intend on doing XP -- of all the new ideas XP contains, TDD seems to be the most useful.
Spring's just an IoC framework
Not entirely sure I agree there. Spring's an IoC framework with a lot of bells & whistles. Some of its other features (e.g. automatic wrapping of objects with transaction controllers) are as generally useful as the IoC stuff.
But, yes, agree with the rest of your point: you'll get more from it if you understand why you want IoC in the first place. I prefer the more "modern" name, dependency injection, as it makes the purpose somewhat clearer.
Which means: first step, if it's not a skill you already have, is learning test automation. Test automation is the key reason you want dependency injection. So, in order:
* core Java stuff
* learn a little about J2EE
* pick up JUnit and learn to write good tests with it
* learn Spring
Seems reasonable to me.
If you use automated payment, if the system fucks up, you'll personally spend hours upon hours on the telephone with said company trying to get the insanity dealt with. "No, no that's not what our system says here sir, the amount we deducted from your account is US$45.97" "But you deducted US$495.70!" "No sir that is not what our system says". It will take days, if not weeks, to get things straightened out.
That's the problem with your system, right there. Here's how it works in the UK:
(Call utility company)
"You charged me £495.70"
"No, we charged you £45.97"
"Refund me £495.70 now, or I'll get my bank to take it back from you.
(In the unlikely event that they refuse, call bank)
"I've been overcharged on a direct debit. Can you refund it for me?"
"Certainly. What's your account number?"
It'll take ten minutes to deal with, maximum.
Yes, this has happened to me.
My favorite part, if you've RTFA to the very end[...]
I wish I could. But NYT seems to have deleted my account with them (the username and password from my autologin aren't working any more) and when I try to register again I get a page that says "Please check the highlighted areas below" and then shows a form field that is correctly filled in. :(
Stories of epic fails with DDs are legion - an extra zero on the bill makes the person go overdrawn, they get a bad credit record, they lose their house, they kill all their family and so on. I exaggerate. Slightly.
You do know that if an incorrect direct debit makes you go overdrawn, all you have to do is tell your bank and they will refund it to you, along with any charges/interest that occurred because of it, and correct any incorrect information that has been placed on your credit record, don't you? All it takes to fix a direct debit error is one phone call...
I guess that I can't think of a problem where Perl would be the best solution anymore.
Any task that involves iterating over a bunch of lines, applying pattern matching to them. Perl is well optimized for this, and handles it substantially better than python. Although it's worth considering whether either sed or awk might be better -- they often are.
WTF does a CIO have to worry about languages for? That's the development manager's problem. The CIO's problem is the management of the organization and the technology big picture. How said technology is implemented isn't his problem: that's just minor details. I guess a micro manger would be concerned about a scripting language. If that's the case, he needs to quit and get a tech management job.
You seem to have a large-company oriented image of the world. Let me broaden your horizons a little: approximately 99% of the businesses in the developed world have fewer than 500 employees. OK, so a lot of these won't have CIOs (or people with equivalent titles, like mine: IT Director). But many do. Enough that probably 80-90% of CIOs in the world are working in these companies.
These CIOs don't have development managers to assist them with these details. They have to interact directly with developers themselves, or, in some cases, have to _be_ developers themselves. So, yes, a large majority of CIOs do, in fact, have to concern themselves with the specifics of implementation in this fashion. For them, being a CIO _is_ a tech management job.
For example, if you have a "return" statement in a block that's passed into a function, and the called function yields to the block, Ruby returns from the calling function, rather than "returning" from the block (yield'ing nil), and not returning from the called function either. However, if the called function wraps its block in a lambda before calling it (if, say it wants to pass it to another function like in your example), the same return statement in the block has a completely different effect, depending on how the block is used. I see why it was done, but don't think the overall design is right, especially if blocks are special like that but you can't pass multiple blocks into a function.
Coming from a smalltalk background, that'll be _exactly_ what's bothering the original poster. Smalltalk statement blocks use the former pattern rather than the latter, with the result that the design is _extremely_ neat. It lets you produce new flow control primitives, for example:
myTestMethod
randomlyExecuteEither: [ ^ 1 ] or: [ ^ 2 ].
randomlyExecuteEither: block_a or: block_b
| randomlySelectedBlock |
"code to randomly assign either block_a or block_b to randomlySelectedBlock goes here"
randomlySelectedBlock value.
When executed, the two statement blocks, "[ ^ 1 ]" (return 1) and "[ ^ 2 ]" (return 2) are passed to the randomlyExecuteEither:or: method, which picks one and executes it. This causes myTestMethod to return, not the closure, and not randomlyExecute.... The coding style it enables is clear, readable and very useful. You can do it in smalltalk or lisp, but not (it would appear) ruby. This is definitely to ruby's disadvantage.
Many of the language features that Ruby proponents bring up are often found in some way or another in Python, Lisp, or Perl.
Hmm... I think that of those, only LISP supports statement blocks passed as parameters to a function, which is, you know, the key language feature of Ruby.
The only _other_ language I know that supports that is smalltalk.
I'd be happy to learn about other languages with the feature.
Unless a language is self hosting, i.e. written in itself, I wouldn't call it a 'full' language.
Disagree. It must be _possible_ to produce a self-hosted implementation of the language, but it isn't necessary for anyone to actually do so, I.M.O.
Why? First, the language that the implementation you are using has little actual effect on the usefulness of the language you are using (unless that language is sub-optimally efficient, in which case it may diminish that usefulness).
Also, we're moving into an era now where single components (class libraries, virtual machines, parsers, optimizers, machine-specific object code generators) are more and more commonly shared between multiple language front-ends. It would be silly to classify a language as "not full" just because its implementers decided not to reinvent the wheel and reused somebody else's work to simplify their own job.
Example: the leading Ada95 compiler is GNAT. GNAT is an Ada front end that uses the back end optimization and platform-dependent output sections from GCC, which are obviously written in C. Is Ada therefore not a "full" language? The notion is absurd: by any reasonable definition of "full", Ada95 should probably be one of the leading examples.
Javascript doesn't have an interactive prompt (that I know of),
Netscape used to have one, but it seems to have been removed from modern Mozilla projects. You can run javascript interactively by typing 'javascript:[statement]' into your URL bar, though.
This led to a californian state senator to call for a ban on the use of all perfluorocarbons (the group of chemicals that contains both PFOA and PF5080) in the food industry. The call has not lead to any action.
OK, that last sentence might be misleading. There is a bill in-progress in the californian senate (SB-1313), which will ban "perfluorinated compounds" from use in food packaging. It looks likely that it will pass.
This does not include any form of fluorinert, unless "degrad[ing] in the environment" is considered to include being exposed to sulphuric acid.
Also, IIRC, California recently added Flourinert to it's list of potentially cancer causing chemicals, which IMHO makes it less than ideal for a warm LED lit water fall in your living room or office...
Fluorinert is not one chemical, but a family of them marketed under the same name. This machine uses PF5080, which is also known as perfluorooctane.
The case you have likely heard about relates to perfluorooctanoic acid (PFOA), a related but distinct chemical that is used as an industrial cleaning agent, and also in the process of applying teflon coatings. There are concerns that it could accumulate in the food supply, and that it would be carcinogenic in this case. This led to a californian state senator to call for a ban on the use of all perfluorocarbons (the group of chemicals that contains both PFOA and PF5080) in the food industry. The call has not lead to any action.
FWIW, perfluorocarbons, including some variants of fluorinert, have actually been suggested as anti-cancer drugs, and PF5080 is being considered for use as human medication (as a vector for delivery of anaesthetics). Rats have routinely survived being immersed in oxygenated PF5080 for prolonged periods with no ill effects. If you've seen the film The Abyss, you've seen a rat breathing PF5080.
PF5080 is safe. I'm pretty damned sure of that.
They got their flourinert from an old supercomputer, and that's not a viable supply for fullscale production.
There are suppliers that will provide generic perfluorooctane (the same stuff, just not manufactured by 3M) for a figure that means this machine wouldn't have to be priced at _too_ extreme a figure. At least compared to the top end config recommended by the hardware site /. linked to yesterday...
Once again, an article that sparks my interest, then someone comes along and destroys it with reality...
You can do the same thing with mineral oil. Unfortunately, the higher viscosity will make it harder to pump the fluid around effectively (you _can_ do it with an ordinary fan, but they won't last for very long) while the lower heat capacity will mean you need to pump more of it around more quickly.
it says right in the abstract that they are using 70kg of the stuff. Prices online seem the range from about 500-1000 USD per gallon, usually in 3 gallon minimum quantities.
OK... must have missed that. :) Note that a gallon of the stuff weighs significantly more than equivalent water. 70kg is approximately 9gal.
Looking at the prices I see, I could acquire 70kg of the stuff for $2,500 US. There are good deals to have if you look around for them! For a showpiece item like this, I don't think $2,500 on cooling fluid is too much. OK, I wouldn't spend it. But then I'm sitting here typing this on an old Celeron D. I'm not the kind of person who this is targetted to.
I'm merely suggesting that wasting ~10k USD on coolant and then building a giant gaudy waterfall enclosure isn't exactly how I'd go about doing a project like this.
I'm struggling to get a good grasp on the scale of that thing to estimate how much flourinert would be required, but I don't think it's as expensive as you think it is. 5kg of the stuff can be had for significantly under $1000 US, and I doubt they're using 50kg of the stuff in there.
You've probably seen small order prices (250ml or thereabouts) and have extrapolated. That's a bad extrapolation: large orders don't cost more than a small percentage extra.
turning the area near the CPU into a mini deep fryer - definitely not cool!
Hmm. Vegetable oil's a dielectric, you know.
I'm thinking of an 8-core 5Ghz quad-crossfire 5-litre fryer. Should do the job. You'd just need to make sure you had a way to throttle back your overclocking before you reached the flashpoint.
It seems like somebody's already on the right track...
Fixed resolution 8bit/channel RGB data will degrade gracefully with random bit errors (to an extent), unlike compressed formats like JPG and PNG which will just die completely.
Actually, there are several known algorithms that allow recovery of complete information from JPEG files with small numbers of random bit errors in them. E.g. this one. JPEG2000 is considered much more resiliant, also; it is, in fact, optimised for transmission over unreliable media (e.g. one-way satellite links).
You'd be much better off using ECCs (e.g. reed-solomon, or even, in the extreme, storing 3 copies of the file so you can process them bit-by-bit and pick the most common value at each point) to find and correct bit errors than using uncompressed images and letting them degrade arbitrarily.
Note that most media you're likely to use is probably using error correction anyway, so single bit errors are unlikely: they would be found and fixed by the media itself. Probably the smallest error you'll see is an unreadable block of a few hundred bits. So the block cipher is unlikely to be much of an issue, as the media you're likely to be recording on has exactly the same issue: errors wipe out blocks, not individual bits.
Ummm... I'm sure that most of us who are 25 years old or older have pictures of themselves that are stored in bad conditions and still look decent.
Yes, but the pictures I printed on my HP Deskjet 640C only 10 years ago are already looking significantly faded.
Digital photo printing and colour photography are not the same process, and have different expected lifetimes. Some of it is down to the paper, and some is down to the inks. I don't know how those pictures would look if I'd used glossy, acid-free paper -- I suspect they'd be significantly better. I don't know how much better the prints from my current printer (an Epson R285) will fare. Printing for archival isn't as simple as it sounds.
The common suggestion is to make sure you use a pigment-based ink and high quality acid-free paper. Stuff printed like that should (apparently) last 100 years before it fades noticeably. Obviously that's based on "accelerated aging" results, so may or may not be truly accurate, but it's probably a ballpark figure.
This might be an attractive alternative, but the profit margin (for an essentially illegal operation) would need to be decidedly low to attract people from any other jobs even in the poorest areas.
Why would you say the operation is illegal? What (Russian/Chinese) laws are being broken?
English pointy clicky tools like this certainly do exist and certainly pre-date any Russian or Chinese tools; when was SATAN first developed?
Except, well, no.
The two aren't really comparable. SATAN is a tool designed to fulfil a perfectly legitimate purpose, which happens to also be able to do some things that aren't exactly legal.
These tools are (mostly, at least) things that have no legitimate purpose. What's the legitimate purpose behind a service to provide forged ID? A marketplace for stolen credit card data? Running authorization requests to find the likely amount of cash you can get away with taking from one of those cards via hijacked merchant accounts? Producing custom botnets on-demand using pre-compromised end-user PCs?
The point is that in Russia and some other Eastern European countries (many of which have populations that speak Russian due to Soviet occupation), and probably also China, you can get away with providing this kind of service, because the local police in these countries don't generally cooperate with international investigations, so as long as the people being ripped off are in another country, they won't bother you.
In most English-speaking countries, you can't get away with doing this kind of thing because the local police will proactively investigate this kind of activity regardless of who the victim is likely to be, and will definitely cooperate with international requests for assistance with this kind of criminal activity.
Which is why these tools are predominantly Russian-language. I'm not so sure about Chinese, but I'd certainly not be surprised to find Chinese tools in this field significantly outnumbering native-English ones (i.e., not counting those that are produced in English to attract an international market but are clearly run from countries such as those I mention above).