It's the same cpu (or at least the same family) used in the new Acer netbooks. I have one of these w/ 4GB ram and a 500GB drive, and it runs Win7 home x64 just fine for your basic putzing around type usage. Loaded up Eclipse to try out some Android development and that may be stretching things a bit, but it's not horrible. The full netbooks are ~350 or so rather than 200, but IMHO it does quite well as a poor-mans-ultrabook.
Figures that this would get coverage, but none of the analysis that shows how full of crap this report is. The US production of *crude oil* is only about 6.2 mmb/day - substantially lower than the ~10mmb/day produced by the Saudis. The IEA has included Natural Gas Liquids (NGL) in their numbers to magically claim the significant increase in US production. Given that the US consumes about 17-18 mmb/day of crude oil, it would take nothing less than a seismic shift in either production or consumption to achieve 'self sufficiency'.
Not to completely downplay the significance - we are indeed awash in far more natural gas products than in the recent past and that shouldn't be missed. However, there is a lot of evidence that the depletion curves of the shale plays are not favorable, so extrapolating what is occurring now out 10-15 years is a fools game.
In other words, this is basically a PR piece designed to assure investors that the oil industry is 'A-OK' - no need to worry and keep pouring the money in. Taking it as actually reflecting anything about reality would be a mistake.
I think we've got a lot of people around here that have never been to the southwest. 10k square miles of available space is most certainly NOT the problem. The truth is that many of the areas that are ideal for solar are very marginal lands due to the scorching heat and lack of water. I'm not entirely up on land prices, but given that I paid $1200/acre for some very nicely treed land in southern CO, I'd guess $400/acre for parched desert isn't a bad place to start. That puts the purchase price at under $4B for the land, or about as much as the US spends on oil in 2 days. (based on 20M bbl/day stat from herehttp://www.eia.doe.gov/neic/quickfacts/quickoil.html)
Transmission of the generated power and political will are the problems, not availability of land.
I'll second the thrust of the parent - I've used Ice, and find it 'easy' (as these things go), reliable, and fast (even the Java version). It takes the simple idea underlying CORBA (ie IDL describing remote interfaces in an implementation-language-neutral fashion), and implements it well with an adequate but minimal-ish amount of supporting services.
Very highly recommended for folks looking for a multi-language distributed object framework.
Interesting - Pyron is obviously going for the 'power plant' market, which IMHO is likely to see a lot of activity in the near future. With rising oil prices, larger scale concentrating solar plants will be competitive in the southwest.
These guys http://www.greenandgoldenergy.com.au/ are doing much the same thing at a domestic scale. Using the same Boeing/Spectrolab panels.
Woodgass/biomass gasification is the first thing I thought of when I read the article, and it might be an ideal source of the necessary CO as there is already the (apparently necessary) low concentration of H2 as well. There are a couple problems with gasification that make it somewhat impractical for large-scale deployments on it's own.
a) gasifiers work best in steady state conditions
b) CO is relatively unstable, and doesn't compress/store well.
With these microbes, you might well get the best of both worlds - a gasification system that is carbon-neutral and can run off say switchgrass grown in otherwise marginal agrigcultural land, plus a flexible fuel in H2 that can be transported, stored etc.
Yeah - all those dvd players pulling 150ma of idle current are the root cause of our energy problems. Way to go after the big issues, Georgie.
$77 mil research budget? Boy, that'll put us out at the forefront of technology in no time. We're spending about 3x that PER DAY in the Iraq debacle. But yeah, it shows George *really* cares about energy efficiency....it's certainly not just a token gesture so they can claim positive energy initiatives. They'd never stoop to that, not the Bush Republicans.
When operating on native integer types, Java does in fact perform comparably to compiled code - as it should, since the JIT compilers should produce very very similar code.
However, Java does have some inherent qualities that cause poor performance in typical real-world apps. -GC is required, and is slower than heap management. -lack of documented/fixed object layout precludes direct memory manipulation of data - mostly a problem in I/O. This makes block-based I/O virtually impossible without serializing. -The 'Design Patterns' that have been adopted as Gospel by most in the Java community (at least the J2EE community) are very inefficient - too many layers, too much indirection, too many object copies etc. - Swing. ugh.
None of these are fatal problems, and I know from experience that it's possible to create very good performing Java apps, but it's not easy. You have to fight the language in some cases, and you can't follow the 'Java Purist' crowd in many cases.
This only works to a point, and the fundamental problem as others have pointed out is that the 'black boxes' are almost never specified to a level of detail adequate to fully describe their behavior. Things like side effects, performance criteria/guarantees, behavior on edge conditions etc are very frequently overlooked. Your statements are idealized versions that might have been taken from some software Methodology book - they completely ignore the real-world problems like bugs, partial/incomplete implementations, outdated specs/documentation and a whole host of others.
This doesn't mean that you always have to be explicitly focused on these issues, but the overall success of the system as a whole can be critically dependent on them. In a perfect world, of course, this wouldn't be an issue. But assuming the viability of black-box treatment in most real-world projects is the source of many problems, and the truth is that a relatively small portion of the population is capable of maintaining a sufficiently broad view of a system to be able to effectively respond..
Man, does this make my blood boil every time I read it. At best, it's outdated, at worst irresponsible. 'Back in the day' when implementations were typically close enough to the hardware that the 'fundamental cost of operations' was relatively well understood, this type of thinking wasn't unreasonable *at the code level*.
However, when selecting base architectures, you have to think about performance *up front*, since you're not going to change the fundamental architecture at the end of the project with a few lines of tweaked code.
Also, now that we have Java and OO and abstraction up the ying-yang, optimizing code is orders of magnitude more difficult in a real world project than it was when a project was a few 10k's of C code. Ever try 'refactoring' a significant API at the end of a project when you're already late?? Doesn't happen, and you ship something that runs like a dog.
Truth is, you have to worry about performance right from the start. Performance and clarity are by no means incompatible when done properly.
Okay, someone help me out here. Exactly what does Borland have that is of any value to MS?? Delphi/Kylix are OK, but compete pretty directly with VB;.Net-ifying them is reasonable enough, but I would imagine Borland would do this anyway. The C++ tools are similar - VC++ isn't going to get any better due to an infusion of borland technology.
Java is an area that Borland is strong (JBuilder and app server, recently purchased OptimizeIt), but obviously MS would probably just shut that side down; conversion to C# wouldn't seem to make much sense, as it would then just be a VS.Net competitor. I suppose they could spin it off, but since the Java branch is maybe the most successful, it again begs the question 'why bother with the purchase in the first place?'
Borland does have a couple other fringe products - DB, SCM etc, but they wouldn't appear to have much compelling value by themselves.
In short, the only concievable reason I can see for MS doing this would be to shut them down and absorb the market share, which is neither particularly cost-effective nor likely to be without PR and other repercussions.
In summary - this one seems like complete vapor to me. It's pure reaction to the IBM-Rational agreement, and the assumption that somehow MS will have to respond in kind.
Clearcase isn't exactly awful, if you consider it's capabilities and potential target market. the problem is that is is resource and personnel intensive to get to work at all let alone well, and it is an absolute bear to get working effectively across even somewhat decoupled sites.
In other words, there are simply not many places outside large, stable (???) in-house corporate development environments where it makes any sense.
In virtually all projects I've been in, CVS is a far far better choice than clearcase
He's not saying that things shouldn't be re-used, just that if there are dependencies, they should be included in the package. I *might* agree, depending on how radical he's being. There are few things more frustrating than seeing a ref to a way-cool package, and then discovering that you need 6 other things to use it, usually including at least 2 unstable/devel versions plus another that is an incompatible upgrade from what you're using now.....
Of course, the degree to which people insist on releasing packages that depend on development/CVS versions of other packages is most of the problem. Somehow, given the 'typical' linux developers, I don't expect that to change any time soon.
I pulled a bunch of CCRMA stuff recently, and it has worked out very well. Most of this is probably due simply to using apt-get, but their package selection is good. I got the patched LL kernel, updated alsa drivers, jack and all associated programs installed with no problems whatsoever.
Highly recommended for RH users, particularly if you only want select packages.
The self-defence argument rings hollow, and even feels like something of a cop-out. Your sister-in-law would simply have placed herself in *more* danger by going for a gun *unless* she was well-trained in it's use, and prepared to use it. Despite the continued protestations of gun advocates, I simply see little to no evidence that this will ever apply to anything but a vanishingly small fraction of the population.
For most able-bodied people (including your sister-in-law facing an unarmed assailant) conventional self-defence, martial arts, or similar training would likely be much more effective, and less risky. Of course, this is hard and takes lots of time, so doesn't appeal to most people - way easier just to go buy a gun.
To be clear, I'm not against gun ownership, but I am against unqualified, unsafe, unaudited ownership. If it's a freedom that is so important and so valuable, then step up to the table with proof that you take it seriously, and are commited to responsible ownership and use.
Sorry, but re-read your own words. Your advocacy of ownership is not based on the *average* citizen, but rather a *trained* *responsible* citizen, and even so, relies on vanishingly small odds.
Sorry, but there are very, very, very few people that I know that I feel could be trusted to rationally respond with a firearm in a situation like you describe. (there are some, but training is present in every case) Much much more likely is: citizen pulls over, stands up and yells 'stop'; gets shot, perpetrator steals gun, putting more uncontrolled firearms on the street.
Furthermore, I do not ever remember hearing a news report of a 'successful citizen firearm defense'. Your story from Phoenix might be one, but it would be the first. This really is the crux of many arguments - that crimes from stolen guns and gun accidents so greatly outnumber these 'self-defence' scenarios that the tradeoff just doesn't make sense - overall, we're currently hurting ourselves by widespread gun ownership, rather than helping.
The simple fact is this (IMHO) guns are simply too dangerous and too risky for the 'average' person to handle responsibility given the current social structure in the US. There is no "magic bullet" (no pun intended) to fixing this. If all owners were well-trained, it would help. If there were fewer illegal guns on the streets, it would help. If guns were tracked better, it would help.
Your post illustrates what tends to stick in my craw about many (not all) gun advocates, though - they rely heavily on the fact that responsible, trained gun ownership is safe, but absolutely positively resist *any* move to formalize or quantify that. I'm baffled by this - some Gumby walking around with a gun when he's more likely to wet himself if confronted than use the gun is nothing more than easy pickings for gun theft, which just perpetuates the argument.
Just because there's no digital out doesn't mean the sound output is 'worse'. Higer grade converters are used to generate the analog output from SACD/DVD-Audio players, and with the possible exception of the bargain-basement players, they outperform even high-end CD based equipment.
Sure, audiophiles like their separate box converters etc, but based on the initial product releases, a good SACD on a good player is already better than high-end CD, in the eyes of audiophiles. The average listener probably doesn't care and wouldn't notice.
BTW - There _is_ digital out available, but it's encrypted. The Pioneer universal player (47-Ai)appears to send the digital stream out a firewire port, and it complies to IEC 1394 protocol standards. The audio payload data is encrypted, though, so you can't directly make use of it.
First, your '48 bit' color is really only 36 (12 bits/pixel), but that's a detail. File size is largely irrelevent - it's only a convenient way of normalizing the pixel count, and assumes a 24 bit image.
The real comparison is effective resolution and noise, and on these counts it should be clear that the new Canon 1Ds is comparable to 35mm in every meaningful way. At 11x17 print sizes, uncropped shots from the 1Ds will equal in sharpness all but the most carefully handled 35mm negs on top quality gear, and in noise there is no comparison at all. Heavy cropping _might_ still be easier on film, but even that doesn't appear to be the case.
Of course, this is still pretty serious $$$$, but even the D60 is very close to 35 in basically every way.
18-24 months? Guess what - that's when digital will start to rival 645, not 35mm. (of course, that'll be in an MF body, and probably cost $10k++)
Wasn't one of the major issues pushed through in a recent telecom bill to remove common carrier status for data networks(don't remember whether it was proposed or passed, though)- the motivation was largely to *allow* the carriers to filter content, setting up the opportunity for direct partnerships with the media firms by preventing access to competing media sites.
It'll be interesting to see whether this backfires on them so quickly.
The best way to print 'cheaply' for a DIY setup is probably an Epson 8xx series (870 if you can find it) with a bulk continuous ink system, such as the one at www.missupply.com (there are others).
It's a non-trivial up-front cost (about $400 total), but your per-print cost will be quite low on a suitable paper. (eg epson heavyweight matte is about $.10/sheet, and will give you four snapshot size prints per sheet. ink cost not counting the up-front cost is about $100 for a couple thousand prints)
Due to the very high cost of manufacturers ink cartridges, I suspect this is the about the only viable home alternative - a service bureau will win out in this case.
What you're looking at is just the theoretical capability of an N bit word to capture a signal. The actual performance of the card will be different when measuring zero-signal noise vs full scale output. ie there is analog noise present in the card that will determine the actual SNR of the card.
100dB is actually not bad, though hardly 'unprecedented'. State-fo-the-art sound cards (LynxTwo) are performing at 110-115 dB levels, which is (IMHO) extremely impressive given the noisy environment in a PC case. Of course at about $1000, I don't think many gamers are going to be lining up for one.......
pretty straightforward - dynamic range = 6*NB.
rationale - each bit is a factor of 2 in voltage, factor of 4 in power. each factor of 2 in power is 3dB. in other words dB=20*log(V) (log base 10).
plug in either 2^16 or 2^24 and this gives the oft-quoted 96 dB for 16 bit ("cd quality") audio, 144dB for 24 bit. (not exact numbers, but close enough)
So, it turns out that your result is actually pretty close, even if your math is wrong. True state-of-the-art converters can get 19-20 bits out of a signal. Check out either the LynxTwo or the new EgoSys 192x for cards that are pushing this. The LynxTwo measures at 115+ dB, or about 19 bits.
I did some work on the 'ego motion' problem in grad school ie determining self-motion solely from an image sequence. Since this effectively the same problem as creating a 3D map from an image sequence, I'd be interested to see what the state of the art has evolved to. Any refs would be appreciated.
Sorry, but I gotta agree with him here for the most part, both in theory and practice.
In theory, the notion of a non-programmer 'who is good at finding bugs' is great, but they rarely exist. For pure end-user apps, they might make up a portion of the QA team, but that's all.
There are two major problems in practice. First is that the type of insight and analytic skills you need to do good QA work are pretty much the same as those needed to be a good designer/developer. You need to understand the 'task' at multiple levels, know how it relates to other aspects of the program, and understand the underlying technology etc. Generally, I can break the code 'finished' by junior programmers almost instantly - why? Because the combination of technical knowledge of how they probably attacked the solution along with domain knowledge of relationships/edge conditions etc is a powerful combination.
Second is that respect for non-programmers by programmers is terrible. How many dev projects have you been involved in where the programmers ignore the stupid/wrong/annoying etc QA guys? Happens all the time. Moreover, when you do get a really good QA guy, what happens? - He gets lured into development because it's 'more important' and/or pays better.
Thus, I really believe that Development and QA are really phases of a project that need the same basic skills, and should be addressed accordingly. In a perfect world where everybody did formal analysis, pre/post condition testing, automated edge condition unit testing etc some of this might change, but that'll never happen in my lifetime.
Slashdot Mirror
It's the same cpu (or at least the same family) used in the new Acer netbooks. I have one of these w/ 4GB ram and a 500GB drive, and it runs Win7 home x64 just fine for your basic putzing around type usage. Loaded up Eclipse to try out some Android development and that may be stretching things a bit, but it's not horrible. The full netbooks are ~350 or so rather than 200, but IMHO it does quite well as a poor-mans-ultrabook.
Figures that this would get coverage, but none of the analysis that shows how full of crap this report is. The US production of *crude oil* is only about 6.2 mmb/day - substantially lower than the ~10mmb/day produced by the Saudis. The IEA has included Natural Gas Liquids (NGL) in their numbers to magically claim the significant increase in US production. Given that the US consumes about 17-18 mmb/day of crude oil, it would take nothing less than a seismic shift in either production or consumption to achieve 'self sufficiency'. Not to completely downplay the significance - we are indeed awash in far more natural gas products than in the recent past and that shouldn't be missed. However, there is a lot of evidence that the depletion curves of the shale plays are not favorable, so extrapolating what is occurring now out 10-15 years is a fools game. In other words, this is basically a PR piece designed to assure investors that the oil industry is 'A-OK' - no need to worry and keep pouring the money in. Taking it as actually reflecting anything about reality would be a mistake.
I think we've got a lot of people around here that have never been to the southwest. 10k square miles of available space is most certainly NOT the problem. The truth is that many of the areas that are ideal for solar are very marginal lands due to the scorching heat and lack of water. I'm not entirely up on land prices, but given that I paid $1200/acre for some very nicely treed land in southern CO, I'd guess $400/acre for parched desert isn't a bad place to start. That puts the purchase price at under $4B for the land, or about as much as the US spends on oil in 2 days. (based on 20M bbl/day stat from herehttp://www.eia.doe.gov/neic/quickfacts/quickoil.html)
Transmission of the generated power and political will are the problems, not availability of land.
I'll second the thrust of the parent - I've used Ice, and find it 'easy' (as these things go), reliable, and fast (even the Java version). It takes the simple idea underlying CORBA (ie IDL describing remote interfaces in an implementation-language-neutral fashion), and implements it well with an adequate but minimal-ish amount of supporting services.
Very highly recommended for folks looking for a multi-language distributed object framework.
Interesting - Pyron is obviously going for the 'power plant' market, which IMHO is likely to see a lot of activity in the near future. With rising oil prices, larger scale concentrating solar plants will be competitive in the southwest. These guys http://www.greenandgoldenergy.com.au/ are doing much the same thing at a domestic scale. Using the same Boeing/Spectrolab panels.
Woodgass/biomass gasification is the first thing I thought of when I read the article, and it might be an ideal source of the necessary CO as there is already the (apparently necessary) low concentration of H2 as well. There are a couple problems with gasification that make it somewhat impractical for large-scale deployments on it's own. a) gasifiers work best in steady state conditions b) CO is relatively unstable, and doesn't compress/store well. With these microbes, you might well get the best of both worlds - a gasification system that is carbon-neutral and can run off say switchgrass grown in otherwise marginal agrigcultural land, plus a flexible fuel in H2 that can be transported, stored etc.
Yeah - all those dvd players pulling 150ma of idle current are the root cause of our energy problems. Way to go after the big issues, Georgie. $77 mil research budget? Boy, that'll put us out at the forefront of technology in no time. We're spending about 3x that PER DAY in the Iraq debacle. But yeah, it shows George *really* cares about energy efficiency....it's certainly not just a token gesture so they can claim positive energy initiatives. They'd never stoop to that, not the Bush Republicans.
When operating on native integer types, Java does in fact perform comparably to compiled code - as it should, since the JIT compilers should produce very very similar code.
However, Java does have some inherent qualities that cause poor performance in typical real-world apps.
-GC is required, and is slower than heap management.
-lack of documented/fixed object layout precludes direct memory manipulation of data - mostly a problem in I/O. This makes block-based I/O virtually impossible without serializing.
-The 'Design Patterns' that have been adopted as Gospel by most in the Java community (at least the J2EE community) are very inefficient - too many layers, too much indirection, too many object copies etc.
- Swing. ugh.
None of these are fatal problems, and I know from experience that it's possible to create very good performing Java apps, but it's not easy. You have to fight the language in some cases, and you can't follow the 'Java Purist' crowd in many cases.
Both drivers and extensive patches to Xine are open source and already available.
This only works to a point, and the fundamental problem as others have pointed out is that the 'black boxes' are almost never specified to a level of detail adequate to fully describe their behavior. Things like side effects, performance criteria/guarantees, behavior on edge conditions etc are very frequently overlooked. Your statements are idealized versions that might have been taken from some software Methodology book - they completely ignore the real-world problems like bugs, partial/incomplete implementations, outdated specs/documentation and a whole host of others.
This doesn't mean that you always have to be explicitly focused on these issues, but the overall success of the system as a whole can be critically dependent on them. In a perfect world, of course, this wouldn't be an issue. But assuming the viability of black-box treatment in most real-world projects is the source of many problems, and the truth is that a relatively small portion of the population is capable of maintaining a sufficiently broad view of a system to be able to effectively respond..
Man, does this make my blood boil every time I read it. At best, it's outdated, at worst irresponsible. 'Back in the day' when implementations were typically close enough to the hardware that the 'fundamental cost of operations' was relatively well understood, this type of thinking wasn't unreasonable *at the code level*.
However, when selecting base architectures, you have to think about performance *up front*, since you're not going to change the fundamental architecture at the end of the project with a few lines of tweaked code.
Also, now that we have Java and OO and abstraction up the ying-yang, optimizing code is orders of magnitude more difficult in a real world project than it was when a project was a few 10k's of C code. Ever try 'refactoring' a significant API at the end of a project when you're already late?? Doesn't happen, and you ship something that runs like a dog.
Truth is, you have to worry about performance right from the start. Performance and clarity are by no means incompatible when done properly.
Java is an area that Borland is strong (JBuilder and app server, recently purchased OptimizeIt), but obviously MS would probably just shut that side down; conversion to C# wouldn't seem to make much sense, as it would then just be a VS.Net competitor. I suppose they could spin it off, but since the Java branch is maybe the most successful, it again begs the question 'why bother with the purchase in the first place?'
Borland does have a couple other fringe products - DB, SCM etc, but they wouldn't appear to have much compelling value by themselves.
In short, the only concievable reason I can see for MS doing this would be to shut them down and absorb the market share, which is neither particularly cost-effective nor likely to be without PR and other repercussions.
In summary - this one seems like complete vapor to me. It's pure reaction to the IBM-Rational agreement, and the assumption that somehow MS will have to respond in kind.
In other words, there are simply not many places outside large, stable (???) in-house corporate development environments where it makes any sense.
In virtually all projects I've been in, CVS is a far far better choice than clearcase
Of course, the degree to which people insist on releasing packages that depend on development/CVS versions of other packages is most of the problem. Somehow, given the 'typical' linux developers, I don't expect that to change any time soon.
I pulled a bunch of CCRMA stuff recently, and it has worked out very well. Most of this is probably due simply to using apt-get, but their package selection is good. I got the patched LL kernel, updated alsa drivers, jack and all associated programs installed with no problems whatsoever. Highly recommended for RH users, particularly if you only want select packages.
For most able-bodied people (including your sister-in-law facing an unarmed assailant) conventional self-defence, martial arts, or similar training would likely be much more effective, and less risky. Of course, this is hard and takes lots of time, so doesn't appeal to most people - way easier just to go buy a gun.
To be clear, I'm not against gun ownership, but I am against unqualified, unsafe, unaudited ownership. If it's a freedom that is so important and so valuable, then step up to the table with proof that you take it seriously, and are commited to responsible ownership and use.
Sorry, but there are very, very, very few people that I know that I feel could be trusted to rationally respond with a firearm in a situation like you describe. (there are some, but training is present in every case) Much much more likely is: citizen pulls over, stands up and yells 'stop'; gets shot, perpetrator steals gun, putting more uncontrolled firearms on the street.
Furthermore, I do not ever remember hearing a news report of a 'successful citizen firearm defense'. Your story from Phoenix might be one, but it would be the first. This really is the crux of many arguments - that crimes from stolen guns and gun accidents so greatly outnumber these 'self-defence' scenarios that the tradeoff just doesn't make sense - overall, we're currently hurting ourselves by widespread gun ownership, rather than helping.
The simple fact is this (IMHO) guns are simply too dangerous and too risky for the 'average' person to handle responsibility given the current social structure in the US. There is no "magic bullet" (no pun intended) to fixing this. If all owners were well-trained, it would help. If there were fewer illegal guns on the streets, it would help. If guns were tracked better, it would help.
Your post illustrates what tends to stick in my craw about many (not all) gun advocates, though - they rely heavily on the fact that responsible, trained gun ownership is safe, but absolutely positively resist *any* move to formalize or quantify that. I'm baffled by this - some Gumby walking around with a gun when he's more likely to wet himself if confronted than use the gun is nothing more than easy pickings for gun theft, which just perpetuates the argument.
BTW - There _is_ digital out available, but it's encrypted. The Pioneer universal player (47-Ai)appears to send the digital stream out a firewire port, and it complies to IEC 1394 protocol standards. The audio payload data is encrypted, though, so you can't directly make use of it.
The real comparison is effective resolution and noise, and on these counts it should be clear that the new Canon 1Ds is comparable to 35mm in every meaningful way. At 11x17 print sizes, uncropped shots from the 1Ds will equal in sharpness all but the most carefully handled 35mm negs on top quality gear, and in noise there is no comparison at all. Heavy cropping _might_ still be easier on film, but even that doesn't appear to be the case.
Of course, this is still pretty serious $$$$, but even the D60 is very close to 35 in basically every way. 18-24 months? Guess what - that's when digital will start to rival 645, not 35mm. (of course, that'll be in an MF body, and probably cost $10k++)
Wasn't one of the major issues pushed through in a recent telecom bill to remove common carrier status for data networks(don't remember whether it was proposed or passed, though)- the motivation was largely to *allow* the carriers to filter content, setting up the opportunity for direct partnerships with the media firms by preventing access to competing media sites. It'll be interesting to see whether this backfires on them so quickly.
The best way to print 'cheaply' for a DIY setup is probably an Epson 8xx series (870 if you can find it) with a bulk continuous ink system, such as the one at www.missupply.com (there are others).
It's a non-trivial up-front cost (about $400 total), but your per-print cost will be quite low on a suitable paper. (eg epson heavyweight matte is about $.10/sheet, and will give you four snapshot size prints per sheet. ink cost not counting the up-front cost is about $100 for a couple thousand prints)
Due to the very high cost of manufacturers ink cartridges, I suspect this is the about the only viable home alternative - a service bureau will win out in this case.
What you're looking at is just the theoretical capability of an N bit word to capture a signal. The actual performance of the card will be different when measuring zero-signal noise vs full scale output. ie there is analog noise present in the card that will determine the actual SNR of the card.
100dB is actually not bad, though hardly 'unprecedented'. State-fo-the-art sound cards (LynxTwo) are performing at 110-115 dB levels, which is (IMHO) extremely impressive given the noisy environment in a PC case. Of course at about $1000, I don't think many gamers are going to be lining up for one.......
pretty straightforward - dynamic range = 6*NB.
rationale - each bit is a factor of 2 in voltage, factor of 4 in power. each factor of 2 in power is 3dB. in other words dB=20*log(V) (log base 10).
plug in either 2^16 or 2^24 and this gives the oft-quoted 96 dB for 16 bit ("cd quality") audio, 144dB for 24 bit. (not exact numbers, but close enough)
So, it turns out that your result is actually pretty close, even if your math is wrong. True state-of-the-art converters can get 19-20 bits out of a signal. Check out either the LynxTwo or the new EgoSys 192x for cards that are pushing this. The LynxTwo measures at 115+ dB, or about 19 bits.
I did some work on the 'ego motion' problem in grad school ie determining self-motion solely from an image sequence. Since this effectively the same problem as creating a 3D map from an image sequence, I'd be interested to see what the state of the art has evolved to. Any refs would be appreciated.
In theory, the notion of a non-programmer 'who is good at finding bugs' is great, but they rarely exist. For pure end-user apps, they might make up a portion of the QA team, but that's all.
There are two major problems in practice. First is that the type of insight and analytic skills you need to do good QA work are pretty much the same as those needed to be a good designer/developer. You need to understand the 'task' at multiple levels, know how it relates to other aspects of the program, and understand the underlying technology etc. Generally, I can break the code 'finished' by junior programmers almost instantly - why? Because the combination of technical knowledge of how they probably attacked the solution along with domain knowledge of relationships/edge conditions etc is a powerful combination.
Second is that respect for non-programmers by programmers is terrible. How many dev projects have you been involved in where the programmers ignore the stupid/wrong/annoying etc QA guys? Happens all the time. Moreover, when you do get a really good QA guy, what happens? - He gets lured into development because it's 'more important' and/or pays better. Thus, I really believe that Development and QA are really phases of a project that need the same basic skills, and should be addressed accordingly. In a perfect world where everybody did formal analysis, pre/post condition testing, automated edge condition unit testing etc some of this might change, but that'll never happen in my lifetime.