Perfect example of why printed receipts are needed.
Here we have an election where the results were obviously wrong, yet no recount is possible.
The fact that the fraud is not alleged and that election was not close enough for the error to matter is irrelevant. What happens when the election is close?
Digital's OS-8 software for the PDP-8 was sold by... if I recall correctly the term was "software maintenance contract." For something like $500/year you got "every" release, which had always been annual... until the year when there was no release. There were some fairly harsh questions at DECUS that year.
Of course, it wasn't as bad as the Y1978 bug. OS-8 stored the date in a single 12-bit word, with three bits for the year... epoch 1970. By 1975 or 1976 people were starting to get a little nervous. The PDP-11 was hot by then and the DEC line was that nobody would be using OS-8 by the time the date field ran out. In fact, the product manager said to a roomful of DECUS attendees that he would "personally" fix the date if OS-8 was still in use in 1978. Of course... it was. And, of course... the manager had moved on to other things at Digital and wasn't around to be held accountable. The date field actually did run out. Digital fixed it by shoehorning in a two-bit extension. But the fix was late, sometime after mid-1979 if I recall recorrectly.
The saddest part of the story to me was the Multidata spokesperson, Conley, saying that the FDA's finding "is wrong." "Given [the input] that was given," he says, "our system calculated the correct amount, the correct dose. It was an unexpected result."
In other words: "functions as designed."
In a strictly technical sense, Multidata might be right. Operators were actually trying to increase safety by adding an additional shielding block. In so doing, they encountered a problem in the software design and created a workaround--a creative way of entering the data--which seemed valid, and which the software did not flag as an error. To me, it is not at all clear from the story whether the other way of entering the data was properly within the scope of the software's spec or not.
But I really wish Multidata had chosen to acknowledge some responsibility for the outcome.
Forgive me, but that's what I hate about tradeshows. Why would I want to see a close-up magician at a computer trade show?
Yes, I like magic--we've just gotten tickets to Le Grand David and are looking forward to it. But if it turns out that Le Grand David's show includes a tutorial on software development I will be as appalled as I am by magicians at a tradeshow.
The pity is that GUI usability peaked sometime in the late eighties and has declined since then, as the rise of "computer literacy" has created an expectation that users will master complex UI's, and the rise in computing power has removed any barriers to marketing-driven featuritis.
The most telling point was the discussion of "discoverability." "Discoverable: The interface must, from first switch on, provide a clear direction for a new user to go. At each stage it should encourage experimentation while providing adequate notice of important or key features."
In the 1980s, GUIs were intentionally designed to facilitate discoverability were far more "discoverable" than CLIs of the day. They were also intended to be forgiving. The user was supposed to feel empowered to try things, confident that there was always an "undo" to bring them back. On the Mac in the 1980s, "Undo" was far more prevalent and worked far more consistently than in today's software, in which many operations commit you to something whose effects you may not understand.
As for "dialog," UI designers understood that well. Why do you suppose that what are now called "screens" were once called "dialog boxes?"
What the article is really saying is not that CLIs are better than GUIs, but that a) modern UIs are not catering to the needs of the average user, and that b) modern UIs have gotten so badly designed, cluttered, and complex that they have become less usable to beginners than CLIsbecause GUIs have deteriorated, while CLIs have benefitted from benign neglect.
It's a reference to a famous and very funny song/monologue/thingy in the musical "The Music Man," in which a con artist drums up support for his scam by raising the spectre of the terrible problems that a pool hall will bring to River City (Mason City, Iowa, circa 1910). "And the next thing ya know ya got TROUBLE my friends, right here in River City" is something of a byword. The point being that there is always a popular, vaguely disreputable youth pastime being regarded with concern, and that there are always those eager to exploit that concern.
...I remember when I could actually learn things at trade shows. I could belly up to a booth and play with some software hands-on and learn its capabilities. The people in the booth actually knew the product. In some cases they were developers.
The turning point came circa 1987 or 1988 and I remember the instant it occurred. I was evaluating a word processor, and the person in the booth didn't know whether it could import files from some other word processor. I said, "Well, let's try," and pulled out a diskette containing some files. And she said, "I'm sorry, we've been instructed not to let anyone insert diskettes in the demo machine."
I used to walk up to booths that were demonstrating OCR equipment, which, of course, always worked perfectly on the particular sheets they were scanning for the test. I would ask a couple of questions about its ability to scan a wide range of material, to which the answer was always "yes." I would then pick up some of the booth literature describing the product and ask them to try scanning it. If they said, "Oh, that's glossy," I would look around for anything in my bag or lying around that was, say, an ordinary typed (remember this the eighties) document on bond paper, until I found something that the booth representative agreed was a fair "real-world" test. They'd put it in the stack and scan it. The results were very revealing.
Starting in the early nineties, I started to encounter booth people that would no depart from their memorized scripts, had know knowledge apart from their memorized scripts, and would not allow any hands-on interaction or requests to explore features more deeply ("OK... so could you show us what happens if you...").
At MacWorld, I'd always head for the booths that were farther from the entrance where you'd sometimes find little companies that were interested in showing you their wares, not giving you the hard-sell. And I used to love the funky little BCS "Mac Megameeting," a low-key trade-show-like event.
My friends, either you are closing your eyes To a situation you do not wish to acknowledge, or you are not aware of the calibre of disaster indicated by the presence of an arcade parlor in your community.
Now I play PC games myself, mighty proud to say it; I consider the hours I spent with Zork are golden-- Helps ya cultivate logic, and horse sense, and a keen mind. But just as I say it takes judgement, brains, and Maturity to solve a puzzle, I say that any boob can punch a button on an arcade console And I call that sloth The first big step on the road to dee-gradation.
And all night long your River City youth'll be fritterin' away their hard-earned quarters Stick the coin in the slot, don't worry about taking out the garbage--
And, my friends, ya got TROUBLE! Yeah, ya got TROUBLE! With a capital T and that rhymes with V and that stands for GAMES...
Imagine how terrible it would be if the processor were hermetically sealed in plastic or something. You couldn't go in and put a probe on anything to scope the signals. You'd have to throw away the whole processor if a single transistor in it went bad, instead of just changing the transistor. There would be no way to tinker with it--if you had an idea for an improvement in the instruction set, you couldn't just put a few more flip-chips in the bay and wire-wrap them in.
In a landmark case, the Supreme Court ruled that copyright "rewards originality, not effort." That's the principal that needs to be applied. A publisher may spend a lot of time, effort and money promoting (say) a reprint of a book originally published in 1900, but even if the book practically owes its current existence to their hard work, it is still in the public domain.
eVoting on machines that do not produce auditable paper trails are disasters waiting to happen. As in many other intrinsically dangerous situations, years may, and probably will go by with no apparent problems.
Our lives are full of protections that are seemingly "no needed." How often does an elevator cable actually break, for example? Does that mean we don't need overspeed brakes on elevators? Or inspectors to see whether the brakes are there and working?
One little-noted contribution by Edward Teller was his almost single-handed insistence that civilian nuclear power plants be enclosed in containment buildings. This is particularly interesting because he was, of course, a strong advocate of nuclear power. And, of course, nuclear reactors are supposed to be safe in the first place, so why go to the huge expense of a containment building that isn't supposed to be needed? Then a Three Mile Island comes along, and we find out why.
Black-box voting is a disaster waiting to happen. The disaster probably won't happen tomorrow, or this year. And when it does happen, it probably won't happen in a district with plenty of careful, well-trained, honest conscientious poll workers.
That sounds to me like high praise, and that's the fair dinkum.
It's nice to know that the GPL Linux programmers are reading the C++ Programmers' Journal, programming on purpose, and following the elements of programming style.
I have to admit to being puzzled as to why people spend so much time and energy trying to determine the relative merits of lossy formats.
I find the music I've downloaded from iTMS perfectly acceptable; ditto the music I hear on my car's factory-equipment FM receiver. That doesn't mean I can't tell the difference between them and better sound.
Actually, I've been transferring my LP's to CD... and recently I've been converting the CD's to.mp3 format with iTunes. The first recording I compressed, using some middle-of-the-road "high-quality" setting, happened to be a recording I liked because of the warmth of the violins. Remember, this is an old LP... digitized on a $250 consumer-grade CD recorder. To my utter astonishment, I could instantly tell the difference. After some experimentation, I upped everything to the max, encoded at 256k bits/second... and could still tell the difference.
On the other hand, with popular music (e.g. the Beatles) and some classical recordings, I couldn't.
The point is, if I can hear the difference between a CD and an.mp3 at 256k bits per second, that tells me that the difference in quality is NOT in some rarefied, golden-ears, territory. It's like the difference between a CD and FM radio.
So, why even bother to agonize over minute differences in an imperfect format when a) upping the bit rate does far more to improve quality than fussing over which format is best; b) the mileage varies so much depending on program material; c) they're obviously inferior to CD sound to begin with?
Isn't it a little like arguing over which electrically-recorded 1950s 78's sound better... RCA or Columbia?
I can't see them either, and I'm enormously grateful to eddie-can-read for posting links to better pictures (below), and to the representative of the Cassini Imaging Team for confirming that it's not a good picture.
As a very, very amateur backyard astronomer, I find that one of the most difficult problems I have in showing non-astronomical friends anything in my telescope, is that very few people will tell you what they are seeing or will say "I can't see it." My telescope is a Cassegrainian, meaning out-of-focus images look like doughnuts. When I show someone Saturn, the conversation invariably goes like this:
"You should see a very small object that looks like the pictures of Saturn in comic books, but much smaller. Do you see it?"
"Yes, I see it."
"Are you sure?"
"Yes, I can see the rings."
"Does it look the way I described it? Very small and the rings tilted at an angle?"
"Yes."
"Please turn this focus knob a little. Did the rings change size?"
"Yes."
"OK, you're not really seeing Saturn yet, please turn the knob back and forth until you get it just as small as you possibly can."
"Ok... um, wrong way... ok, I--OMIGOD! THERE IT IS! It's that little shimmery thing that looks like it has a halo, right?"
They can say "I see it," "I see it," but until I get the reaction of surprise I know they haven't seen it.
The problem with all of this stuff is that I have no way to check any of it for myself. How do I know that the "blocker bag" they gave me works? How do I know that someone won't start a business of supplying cheap substitutes, for businesses that want to pacify their customers, that look like real blocker bags but don't do anything? What do I look for? The genuine RSA seal? What if the pharmacist hands me a bag that has some other company's seal on it? Do I trust it?
Will there be a TRUSTe seal on the bag to tell me that I can trust the company that made the bag... just like the TRUSTe seal that certified that eToys would never sell their customer list?
Suppose I have a genuine RSA-branded blocker bags with an authentic non-counterfeitable TRUSTe hologram on it. How do I know it's working properly? Will the pharmacy supply a "blocker bag scanner," like the price-checking guns in Walmart, that let me verify that the blocker bag is actually working? Will the blocker bag scanner have a Commonwealth of Massachusetts weights-and-measures sticker on it to assure me that it's working properly?
If the answer is that I should just trust the pharmacist to be telling the truth when he says it's a blocker bag... well, why shouldn't I just trust the pharmacy not to do anything bad with the data they are capturing from all the RFID tags I'm wearing?
Just because CVS/Pharmacy gave a marketing firm a list of diabetic customers to sell to companies marketing products for diabetics doesn't mean they'd ever do such a thing again. Heck, that was way way back in dark ages... 1998.
These companies are all like Lucy holding the football for Charlie Brown. Trust us, trust us, trust us... even though we've betrayed your trust over and over again in the past, we'll never do it again.
One more oldie-but-goodie from Smithsonian... this one from the Folkways catalog rather than the Cook catalog... is "The Science of Sound," Folkways 06007. Their online catalog is confusing... the original 1958 recording was a two-LP set and Smithsonian's Folkways 06007 appears to be the full recording; there is also another entry under the same title that seems to be only a portion of it.
Anyway.
This was a tutorial produced by Bell Labs which has dozens of sonic examples of the effects of filtering out high and low frequencies, overtones, "subjective tones," and so forth and so on. All accompanied by fifties-style authority-figure Edward-R-Murrow type narration...
Yes! Yes! And I thought I was the only person who had ever heard that record.
The title was actually "Speed the Parting Guest" and yes, indeed, the Smithsonian has it, too. Cook catalog number 01041. It is paired with an even weirder recording called "The Hot-Tempered Clavichord," of a jazz pianist playing a clavichord.
My copy of the Smithsonian had the tracks mis-numbered in the printed insert, and it appeared as if some of the tracks from "Speed the Parting Guest" were missing, but in fact they are all there.
I rather liked that recording then, and I rather like it now. I can't say the same for "The Hot-Tempered Clavichord."
When I first got my digital camera (2 megapixels) I experimented with this sort of thing and gave up. The camera resolution was more than sufficient to capture an entire book page well enough OCR it... IF I put the page under glass to flatten it and lit it very carefully, with two lights at 45 degrees each as with a copy stand.
If I just handheld the camera over the page and pushed the button, the page curl prevented the page from being evenly in focus. The lighting was so uneven--even on pages that looked flat and readable to the naked eye--that the images were very unpleasant to read and completely impossible to OCR. If you set the threshold properly for the center of the page, the area within a couple of inches of the gutter went completely black. Using available light and using the camera's built-in flash produced very different, but equally unusable results.
The ability to wave a phone over a reference book in a library and capture a page would be genuinely useful, but I am rather skeptical that the software is really clever enough to synthesize a flat, evenly lit, in-focus image from the resulting set of images.
Yes, I've considered bringing a sheet of Plexiglass, a table-top tripod, and a couple of battery-powered fluorescent lamps into the library with me. And thought better of it.
This only confirms what many of us have long suspected. Companies promise tech support but, these days, simply don't deliver.
Any idea what to DO about it?
How do I "vote with my dollars" when everyone is doing the same thing?
The worst part is, I'm convinced that computer hardware and software has become less usable, and that this is part of the reason. In the old days, the need to deliver tech support provided some market discipline. If the stuff didn't work, support costs went up. But now, companies are essentially not paying for the real cost of proper tech support... and have lost the disincentive that used to inhibit the release of badly-designed products.
...that obfuscator had better be completely bug-free.
Just suppose that every once in a while the obfuscated version of the code just isn't exactly 100% functionally equivalent to all the others.
How are you ever going to debug that?
It's far worse than a bug in a compiler optimizer.
Worse yet, this could even be used to attack competitors. Let's say the obfuscator has the ability to distinguish code from different vendors in some way... (well, for example, let's supposed the code is signed). It could subtly sabotage the products of certain vendors so that they seemed to be buggy or unreliable... and the victim would never know what had happened or have any way of knowing what had happened (assuming the victim could not reverse the obfuscation).
The reason why you'd want an x86 is to leverage all the existing code which runs on it--practically none of which is relevant to embedded devices.
It's not as if you were going to program your embedded application in Visual Basic, or as Lotus 1-2-3 macros, or something.
Designing a consumer appliance with an x86 processor in it makes about as much sense as designing a rocket ship that runs off 97-octane gasoline, just because gasoline is more familiar, more available, safer, and more competitive in pricing than nitric acid and hydrazine. All true, but that doesn't make gasoline an appropriate rocket fuel.
In the eighties, games were the existence proof that computer programs could be accessible, quickly learned, and usable without reading a manual. What a pity that they, too, have succumbed to bloat, complexity, and featuritis.
And I bet he was secretly thinking "And if the truth be told, someday people will recognize me as being just like Einstein, Gandhi, Martin Luther King, Amelia Earhart, Isadora Duncan, Salvador Dali, Jim Henson, and Charles and Ray Eames--all rolled into one."
(Personally, I think he's no more than another Edwin Land...and that's pretty darn good).
Don't-don't-don't-don't-look at what's in front of you. (Boots-boots-boots-boots-movin' up an' down again); Men-men-men-men-men go mad with watchin' 'em, An' there's no discharge in the war !
'Tain`t-so-bad-by-day because o' company, But night-brings-long-strings-o' forty thousand million Boots-boots-boots-boots-movin' up an' down again There's no discharge in the war !
--Rudyard Kipling, "Boots"
Now if those boots had had little blinking lights in them...
...was, if I recall correctly, the headline on a story that appeared in Whole Earth Review in the 1980s. The article concerned Scitex's image-processing workstations, and their use to move pyramids on the cover of Time Magazine in order to achieve a more pleasing composition, to add or remove people from a picture, and so forth and so on. The cover, as I recall, showed a UFO landing on the street where Whole Earth's offices were located.
Now we can do it with Photoshop Elements on a home computer.
Yes, juries ''should'' be cautious in their approach toward photographic evidence. It was never true that "the camera doesn't lie," but the ease and inexpensiveness with which digital images can be altered certainly ought to alter the jury's Bayesian estimates of the likelihood that tampering could have occurred.
Slashdot Mirror
Perfect example of why printed receipts are needed.
Here we have an election where the results were obviously wrong, yet no recount is possible.
The fact that the fraud is not alleged and that election was not close enough for the error to matter is irrelevant. What happens when the election is close?
There has to be a way to check the results.
Digital's OS-8 software for the PDP-8 was sold by... if I recall correctly the term was "software maintenance contract." For something like $500/year you got "every" release, which had always been annual... until the year when there was no release. There were some fairly harsh questions at DECUS that year.
Of course, it wasn't as bad as the Y1978 bug. OS-8 stored the date in a single 12-bit word, with three bits for the year... epoch 1970. By 1975 or 1976 people were starting to get a little nervous. The PDP-11 was hot by then and the DEC line was that nobody would be using OS-8 by the time the date field ran out. In fact, the product manager said to a roomful of DECUS attendees that he would "personally" fix the date if OS-8 was still in use in 1978. Of course... it was. And, of course... the manager had moved on to other things at Digital and wasn't around to be held accountable. The date field actually did run out. Digital fixed it by shoehorning in a two-bit extension. But the fix was late, sometime after mid-1979 if I recall recorrectly.
The saddest part of the story to me was the Multidata spokesperson, Conley, saying that the FDA's finding "is wrong." "Given [the input] that was given," he says, "our system calculated the correct amount, the correct dose. It was an unexpected result."
In other words: "functions as designed."
In a strictly technical sense, Multidata might be right. Operators were actually trying to increase safety by adding an additional shielding block. In so doing, they encountered a problem in the software design and created a workaround--a creative way of entering the data--which seemed valid, and which the software did not flag as an error. To me, it is not at all clear from the story whether the other way of entering the data was properly within the scope of the software's spec or not.
But I really wish Multidata had chosen to acknowledge some responsibility for the outcome.
Forgive me, but that's what I hate about tradeshows. Why would I want to see a close-up magician at a computer trade show?
Yes, I like magic--we've just gotten tickets to Le Grand David and are looking forward to it. But if it turns out that Le Grand David's show includes a tutorial on software development I will be as appalled as I am by magicians at a tradeshow.
The pity is that GUI usability peaked sometime in the late eighties and has declined since then, as the rise of "computer literacy" has created an expectation that users will master complex UI's, and the rise in computing power has removed any barriers to marketing-driven featuritis.
The most telling point was the discussion of "discoverability." "Discoverable: The interface must, from first switch on, provide a clear direction for a new user to go. At each stage it should encourage experimentation while providing adequate notice of important or key features."
In the 1980s, GUIs were intentionally designed to facilitate discoverability were far more "discoverable" than CLIs of the day. They were also intended to be forgiving. The user was supposed to feel empowered to try things, confident that there was always an "undo" to bring them back. On the Mac in the 1980s, "Undo" was far more prevalent and worked far more consistently than in today's software, in which many operations commit you to something whose effects you may not understand.
As for "dialog," UI designers understood that well. Why do you suppose that what are now called "screens" were once called "dialog boxes?"
What the article is really saying is not that CLIs are better than GUIs, but that a) modern UIs are not catering to the needs of the average user, and that b) modern UIs have gotten so badly designed, cluttered, and complex that they have become less usable to beginners than CLIsbecause GUIs have deteriorated, while CLIs have benefitted from benign neglect.
It's a reference to a famous and very funny song/monologue/thingy in the musical "The Music Man," in which a con artist drums up support for his scam by raising the spectre of the terrible problems that a pool hall will bring to River City (Mason City, Iowa, circa 1910). "And the next thing ya know ya got TROUBLE my friends, right here in River City" is something of a byword. The point being that there is always a popular, vaguely disreputable youth pastime being regarded with concern, and that there are always those eager to exploit that concern.
...I remember when I could actually learn things at trade shows. I could belly up to a booth and play with some software hands-on and learn its capabilities. The people in the booth actually knew the product. In some cases they were developers.
The turning point came circa 1987 or 1988 and I remember the instant it occurred. I was evaluating a word processor, and the person in the booth didn't know whether it could import files from some other word processor. I said, "Well, let's try," and pulled out a diskette containing some files. And she said, "I'm sorry, we've been instructed not to let anyone insert diskettes in the demo machine."
I used to walk up to booths that were demonstrating OCR equipment, which, of course, always worked perfectly on the particular sheets they were scanning for the test. I would ask a couple of questions about its ability to scan a wide range of material, to which the answer was always "yes." I would then pick up some of the booth literature describing the product and ask them to try scanning it. If they said, "Oh, that's glossy," I would look around for anything in my bag or lying around that was, say, an ordinary typed (remember this the eighties) document on bond paper, until I found something that the booth representative agreed was a fair "real-world" test. They'd put it in the stack and scan it. The results were very revealing.
Starting in the early nineties, I started to encounter booth people that would no depart from their memorized scripts, had know knowledge apart from their memorized scripts, and would not allow any hands-on interaction or requests to explore features more deeply ("OK... so could you show us what happens if you...").
At MacWorld, I'd always head for the booths that were farther from the entrance where you'd sometimes find little companies that were interested in showing you their wares, not giving you the hard-sell. And I used to love the funky little BCS "Mac Megameeting," a low-key trade-show-like event.
A VIDEO GAME ARCADE?
My friends, either you are closing your eyes
To a situation you do not wish to acknowledge, or you are not aware of the calibre of disaster indicated by the presence of an arcade parlor in your community.
Now I play PC games myself, mighty proud to say it;
I consider the hours I spent with Zork are golden--
Helps ya cultivate logic, and horse sense, and a keen mind.
But just as I say it takes judgement, brains, and
Maturity to solve a puzzle,
I say that any boob can punch a button on an arcade console
And I call that sloth
The first big step on the road to dee-gradation.
And all night long your River City youth'll be fritterin' away their hard-earned quarters
Stick the coin in the slot, don't worry about taking out the garbage--
And, my friends, ya got TROUBLE!
Yeah, ya got TROUBLE!
With a capital T and that rhymes with V and that stands for GAMES...
Imagine how terrible it would be if the processor were hermetically sealed in plastic or something. You couldn't go in and put a probe on anything to scope the signals. You'd have to throw away the whole processor if a single transistor in it went bad, instead of just changing the transistor. There would be no way to tinker with it--if you had an idea for an improvement in the instruction set, you couldn't just put a few more flip-chips in the bay and wire-wrap them in.
In a landmark case, the Supreme Court ruled that copyright "rewards originality, not effort." That's the principal that needs to be applied. A publisher may spend a lot of time, effort and money promoting (say) a reprint of a book originally published in 1900, but even if the book practically owes its current existence to their hard work, it is still in the public domain.
eVoting on machines that do not produce auditable paper trails are disasters waiting to happen. As in many other intrinsically dangerous situations, years may, and probably will go by with no apparent problems.
Our lives are full of protections that are seemingly "no needed." How often does an elevator cable actually break, for example? Does that mean we don't need overspeed brakes on elevators?
Or inspectors to see whether the brakes are there and working?
One little-noted contribution by Edward Teller was his almost single-handed insistence that civilian nuclear power plants be enclosed in containment buildings. This is particularly interesting because he was, of course, a strong advocate of nuclear power. And, of course, nuclear reactors are supposed to be safe in the first place, so why go to the huge expense of a containment building that isn't supposed to be needed? Then a Three Mile Island comes along, and we find out why.
Black-box voting is a disaster waiting to happen. The disaster probably won't happen tomorrow, or this year. And when it does happen, it probably won't happen in a district with plenty of careful, well-trained, honest conscientious poll workers.
That sounds to me like high praise, and that's the fair dinkum.
It's nice to know that the GPL Linux programmers are reading the C++ Programmers' Journal, programming on purpose, and following the elements of programming style.
I hope they'll all keep Plauging away at it.
I have to admit to being puzzled as to why people spend so much time and energy trying to determine the relative merits of lossy formats.
.mp3 format with iTunes. The first recording I compressed, using some middle-of-the-road "high-quality" setting, happened to be a recording I liked because of the warmth of the violins. Remember, this is an old LP... digitized on a $250 consumer-grade CD recorder. To my utter astonishment, I could instantly tell the difference. After some experimentation, I upped everything to the max, encoded at 256k bits/second... and could still tell the difference.
.mp3 at 256k bits per second, that tells me that the difference in quality is NOT in some rarefied, golden-ears, territory. It's like the difference between a CD and FM radio.
I find the music I've downloaded from iTMS perfectly acceptable; ditto the music I hear on my car's factory-equipment FM receiver. That doesn't mean I can't tell the difference between them and better sound.
Actually, I've been transferring my LP's to CD... and recently I've been converting the CD's to
On the other hand, with popular music (e.g. the Beatles) and some classical recordings, I couldn't.
The point is, if I can hear the difference between a CD and an
So, why even bother to agonize over minute differences in an imperfect format when a) upping the bit rate does far more to improve quality than fussing over which format is best; b) the mileage varies so much depending on program material; c) they're obviously inferior to CD sound to begin with?
Isn't it a little like arguing over which electrically-recorded 1950s 78's sound better... RCA or Columbia?
I can't see them either, and I'm enormously grateful to eddie-can-read for posting links to better pictures (below), and to the representative of the Cassini Imaging Team for confirming that it's not a good picture.
As a very, very amateur backyard astronomer, I find that one of the most difficult problems I have in showing non-astronomical friends anything in my telescope, is that very few people will tell you what they are seeing or will say "I can't see it." My telescope is a Cassegrainian, meaning out-of-focus images look like doughnuts. When I show someone Saturn, the conversation invariably goes like this:
"You should see a very small object that looks like the pictures of Saturn in comic books, but much smaller. Do you see it?"
"Yes, I see it."
"Are you sure?"
"Yes, I can see the rings."
"Does it look the way I described it? Very small and the rings tilted at an angle?"
"Yes."
"Please turn this focus knob a little. Did the rings change size?"
"Yes."
"OK, you're not really seeing Saturn yet, please turn the knob back and forth until you get it just as small as you possibly can."
"Ok... um, wrong way... ok, I--OMIGOD! THERE IT IS! It's that little shimmery thing that looks like it has a halo, right?"
They can say "I see it," "I see it," but until I get the reaction of surprise I know they haven't seen it.
The problem with all of this stuff is that I have no way to check any of it for myself. How do I know that the "blocker bag" they gave me works? How do I know that someone won't start a business of supplying cheap substitutes, for businesses that want to pacify their customers, that look like real blocker bags but don't do anything? What do I look for? The genuine RSA seal? What if the pharmacist hands me a bag that has some other company's seal on it? Do I trust it?
Will there be a TRUSTe seal on the bag to tell me that I can trust the company that made the bag... just like the TRUSTe seal that certified that eToys would never sell their customer list?
Suppose I have a genuine RSA-branded blocker bags with an authentic non-counterfeitable TRUSTe hologram on it. How do I know it's working properly? Will the pharmacy supply a "blocker bag scanner," like the price-checking guns in Walmart, that let me verify that the blocker bag is actually working? Will the blocker bag scanner have a Commonwealth of Massachusetts weights-and-measures sticker on it to assure me that it's working properly?
If the answer is that I should just trust the pharmacist to be telling the truth when he says it's a blocker bag... well, why shouldn't I just trust the pharmacy not to do anything bad with the data they are capturing from all the RFID tags I'm wearing?
Just because CVS/Pharmacy gave a marketing firm a list of diabetic customers to sell to companies marketing products for diabetics doesn't mean they'd ever do such a thing again. Heck, that was way way back in dark ages... 1998.
These companies are all like Lucy holding the football for Charlie Brown. Trust us, trust us, trust us... even though we've betrayed your trust over and over again in the past, we'll never do it again.
One more oldie-but-goodie from Smithsonian... this one from the Folkways catalog rather than the Cook catalog... is "The Science of Sound," Folkways 06007. Their online catalog is confusing... the original 1958 recording was a two-LP set and Smithsonian's Folkways 06007 appears to be the full recording; there is also another entry under the same title that seems to be only a portion of it.
Anyway.
This was a tutorial produced by Bell Labs which has dozens of sonic examples of the effects of filtering out high and low frequencies, overtones, "subjective tones," and so forth and so on. All accompanied by fifties-style authority-figure Edward-R-Murrow type narration...
Yes! Yes! And I thought I was the only person who had ever heard that record.
The title was actually "Speed the Parting Guest" and yes, indeed, the Smithsonian has it, too. Cook catalog number 01041. It is paired with an even weirder recording called "The Hot-Tempered Clavichord," of a jazz pianist playing a clavichord.
My copy of the Smithsonian had the tracks mis-numbered in the printed insert, and it appeared as if some of the tracks from "Speed the Parting Guest" were missing, but in fact they are all there.
I rather liked that recording then, and I rather like it now. I can't say the same for "The Hot-Tempered Clavichord."
When I first got my digital camera (2 megapixels) I experimented with this sort of thing and gave up. The camera resolution was more than sufficient to capture an entire book page well enough OCR it... IF I put the page under glass to flatten it and lit it very carefully, with two lights at 45 degrees each as with a copy stand.
If I just handheld the camera over the page and pushed the button, the page curl prevented the page from being evenly in focus. The lighting was so uneven--even on pages that looked flat and readable to the naked eye--that the images were very unpleasant to read and completely impossible to OCR. If you set the threshold properly for the center of the page, the area within a couple of inches of the gutter went completely black. Using available light and using the camera's built-in flash produced very different, but equally unusable results.
The ability to wave a phone over a reference book in a library and capture a page would be genuinely useful, but I am rather skeptical that the software is really clever enough to synthesize a flat, evenly lit, in-focus image from the resulting set of images.
Yes, I've considered bringing a sheet of Plexiglass, a table-top tripod, and a couple of battery-powered fluorescent lamps into the library with me. And thought better of it.
This only confirms what many of us have long suspected. Companies promise tech support but, these days, simply don't deliver.
Any idea what to DO about it?
How do I "vote with my dollars" when everyone is doing the same thing?
The worst part is, I'm convinced that computer hardware and software has become less usable, and that this is part of the reason. In the old days, the need to deliver tech support provided some market discipline. If the stuff didn't work, support costs went up. But now, companies are essentially not paying for the real cost of proper tech support... and have lost the disincentive that used to inhibit the release of badly-designed products.
...that obfuscator had better be completely bug-free.
Just suppose that every once in a while the obfuscated version of the code just isn't exactly 100% functionally equivalent to all the others.
How are you ever going to debug that?
It's far worse than a bug in a compiler optimizer.
Worse yet, this could even be used to attack competitors. Let's say the obfuscator has the ability to distinguish code from different vendors in some way... (well, for example, let's supposed the code is signed). It could subtly sabotage the products of certain vendors so that they seemed to be buggy or unreliable... and the victim would never know what had happened or have any way of knowing what had happened (assuming the victim could not reverse the obfuscation).
The reason why you'd want an x86 is to leverage all the existing code which runs on it--practically none of which is relevant to embedded devices.
It's not as if you were going to program your embedded application in Visual Basic, or as Lotus 1-2-3 macros, or something.
Designing a consumer appliance with an x86 processor in it makes about as much sense as designing a rocket ship that runs off 97-octane gasoline, just because gasoline is more familiar, more available, safer, and more competitive in pricing than nitric acid and hydrazine. All true, but that doesn't make gasoline an appropriate rocket fuel.
In the eighties, games were the existence proof that computer programs could be accessible, quickly learned, and usable without reading a manual. What a pity that they, too, have succumbed to bloat, complexity, and featuritis.
I bet he did wrote it himself.
And I bet he was secretly thinking "And if the truth be told, someday people will recognize me as being just like Einstein, Gandhi, Martin Luther King, Amelia Earhart, Isadora Duncan, Salvador Dali, Jim Henson, and Charles and Ray Eames--all rolled into one."
(Personally, I think he's no more than another Edwin Land...and that's pretty darn good).
Don't-don't-don't-don't-look at what's in front of you.
(Boots-boots-boots-boots-movin' up an' down again);
Men-men-men-men-men go mad with watchin' 'em,
An' there's no discharge in the war !
'Tain`t-so-bad-by-day because o' company,
But night-brings-long-strings-o' forty thousand million
Boots-boots-boots-boots-movin' up an' down again
There's no discharge in the war !
--Rudyard Kipling, "Boots"
Now if those boots had had little blinking lights in them...
...was, if I recall correctly, the headline on a story that appeared in Whole Earth Review in the 1980s. The article concerned Scitex's image-processing workstations, and their use to move pyramids on the cover of Time Magazine in order to achieve a more pleasing composition, to add or remove people from a picture, and so forth and so on. The cover, as I recall, showed a UFO landing on the street where Whole Earth's offices were located.
Now we can do it with Photoshop Elements on a home computer.
Yes, juries ''should'' be cautious in their approach toward photographic evidence. It was never true that "the camera doesn't lie," but the ease and inexpensiveness with which digital images can be altered certainly ought to alter the jury's Bayesian estimates of the likelihood that tampering could have occurred.