Asimov already explored this. I wish I could recall the title. U.S. Robots hired a maverick who realized that the key to alleviating public fears of robots was not to make them more complex and human-like, but to make them *less* complex and more specialized. He designed robo-worms and suchlike.
One of the later "Foundation" books has nonhumanoid robots, too, and there is a brief discussion of what it is that makes a machine a robot.
Hmmm, probably the only facet of robots-in-society not explored by Asimov is the possibility that people never would really come to fear them. The two attitudes I've seen toward robots are basically (a) "so what?" and (b) "cool!"
The "theory" section seems to treat feature extraction as something new. Am I missing something, or doesn't this go back at least as far as Minsky & Papert's work on perceptrons?
I was just re-reading Hofstadter's _Gödel, Escher, Bach: an Eternal Golden Braid_ last week and there was a nice compact description of the problem and the theory about how human brains solve it, which sounds quite similar. This book is now older than some of the people working in the field of image recognition.
(Rats, now I've gotta figure out where I put my copy of _Perceptrons_.)
Re:How does it work when it's freezing?
on
Self-Heating Can
·
· Score: 2, Interesting
Works great, I presume. Telegraph linemen used to thaw frozen ground by upending a keg of quicklime over the spot where they needed to dig a post-hole.
Older than that. Asimov used it in several stories, including one of the Powell & Donovan robot stories (the one in which The Brain solved the hyperwarp dilemma and shanghaied P&D to test it).
Self-heating cans also appear in _Foundation and Empire_, when Lathan Devers explains its operation to Ducem Barr as they're running from Riose's task force. That would make it 50-60 years old.
Our servers are named after Indy 500 drivers. (We started out using only firsts, to wit HARROUN and GUTHRIE, but ran out of firsts pretty fast.) The Indianapolis Motor Speedway site has a complete list of drivers, and I imagine that other tracks would too.
We're stuck with shortie names too, alas. I can't use HURTUBISE since we gave up Netware.
(For internal stuff I have lately been using names drawn from Norse mythology. Microsoft-based boxes get the bad-guy names.:-)
Yeah, it's terrible, stores could track your shopping habits, and then they'd...know your shopping habits. What exactly have I lost?
Oh, and the government could use a machine to see who is coming or going in a certain place, unlike today when they could just have someone stand there and look at people as they go by, or post a nearly invisible camera. Wow, that's so much worse.
Indeed, _1984_ is another case where the idea is to obliterate personal identity. The Party doesn't *care* who you are, so long as you're willing to do good work in exchange for bad gin.
REVELATION 13:16-18 is almost, but not quite, precisely unlike ID cards. Useful ID cards all have *different* numbers. Perhaps you've noticed?
The mark of the Beast serves to *destroy* personal identity, not to assure it. It's got nothing to do with knowing who you are; it's about saying that your identity is irrelevant, that you're property.
The Social Security card is a piece of paper which asserts a binding between a name and a number. It's not a reasonable form of identification at all, and that's why it says "not for identification" right on the card.
These Hong Kong cards assert a binding between the name, the number, the appearance of someone's face, and the configuration of his thumbprints. Assuming the authenticity of the card can be verified, this is a MUCH stronger condition and makes it reasonable to trust that the person presenting the card is the person to whom the card was issued. These cards might actually be useful.
The main problem is that idiots who think the SS card means something that it does not, will be even more certain that the smart ID means something that it doesn't. The cure for that is to move the idiots into jobs where they have no opportunity to make that sort of mistake.
As long as it's still compilable, there's no reason that someone couldn't build tools to unobfuscate it (with a bit of human guidance). Since it's GPLed, there's no reason he couldn't publish the result. So really all this cleverness is just a waste of time.
I've done similar things starting with *object modules*, resulting in commented source and a user's manual using nothing but a decent disassembler and my wits. It's more tedious than it is difficult. Having the source, in whatever form, would be a lot easier.
What this actually means is that you can't go to the store and get off-the-shelf parts to read it. Someone invented the LaserDisc the first time, so someone can reinvent it if there is need. It's even easier the second time, because you know it's been done and have some idea as to how.
I dunno about the legal ramifications, but RCA or Pioneer or whoever owns the design would look really stupid bringing suit to stop the reverse-engineering of a product from which they have no intention of ever again making money.
If the computer's the problem, reconstructing the software on some other platform from whatever is left of the design documents should be even easier, as no mechanical engineering or fabrication skills are required.
(Sorry, but I've been bugged by this lazy thinking ever since someone on NPR's "Lost & Found Sound" suggested that wire recordings were on the verge of being lost forever just because nobody sells wire decks anymore.)
However, IPv6 support beyond routing is a huge undertaking. Every single network aware program in existance will have to be rewritten to deal with addresses much larger than they currently are.
Huh? man gethostbyname. Look at the struct hostent. See the h_addrtype and h_length fields. Understand how *some* code will have no problems.
Code which depends on htonl() and friends will indeed be in trouble.
What was that story? It was set during an interstellar cold war of some sort, and described the impact of a new game that had begun popping up all over the Earth. It turns out that They have crafted a game which is teaching Our children to lose. Hmmm....
Indeed, subscription is the way that software development used to be funded. "Long before you, before the mammoth and the mastodon as well, in the time of the dinosaurs", we bought three things: a license, a copy of the currently shipping distribution, and "software maintenance". The maintenance contract caused the vendor to supply you with updates as they were released (shipped to your door, no downloading from a sluggish server!) and a support contact in the vendor's company. You could call for support AND DEMAND RESULTS, because you paid for them and could wave the invoice in the support techs' faces if they balked. ("I'm sorry but I can't accept that. Please connect me to the Manager On Duty.")
Nowadays it's all bundled together and we get fobbed off with lousy answers because nobody can show which part of the $69.95 you paid was for support.
The thing that's different this time around is, again, bundling. In the old scheme, you had the license in perpetuity and could simply stop paying for maintenance so long as you stopped expecting upgrades or support. You didn't have to buy maintenance at all, although it was usually a good thing to do.
Re:Used up in the cost to get the electricity, tho
on
Magnetic Space Launches
·
· Score: 2, Interesting
Indeed, since O2 + 2H2 -> 2H2O an oxy-hydrogen motor doesn't look like harming the environment at all, unless it's the size of Madagascar. The winnage is in leaving the motor and its fuel supply Earthbound.
OTOH since launches don't happen continuously 24x7 the launcher could use solar/wind/tidal input and store it in superconducting accumulators for the next launch. These variable inputs are much more practical for powering rare events than for things like home heating or lighting. Win again.
...is the recyclability of the reaction products. The remanufacture of the fuel could be coupled to solar, wind, or nuclear generation at the source, meaning that all of that industrial plant could be put wherever it is best sited, whether distributed or centralized.
(This reminds me of the "nuplexes" that James Hogan wrote of, which not only produce steel from ore but send cogenerated electricity *out* insted of taking vast amounts of it in.)
I can't wait to see the "patent-pending circuitry" which sounds to me like just a rectifier. (Not even a proper full-wave network, either, if they flash at 60Hz rather than 120Hz.)-:
Oh, well, having just hand-tested 300 bulbs in those crummy series-wired strings to find the duds, I want some Forever Lights anyway.
Also, the founder of Unimation has said that he was inspired by Asimov's depiction of robots as realistic engineering products (as opposed to unpredictable, soulless monsters as in _Frankenstein_).
When I start a project, I create a directory for it to live in. Project directories live in the directory I created to contain all of my project directories. Email is in another set of directories, but if a mailgram is related to something specific (like a project) then it gets filed with related mailgrams in a suitably named folder.
So when I want something that's part of the Foo project, I know it's in Projects/Foo. If I don't remember that it's part of the Foo project, I think for a moment about what makes it distinctive and then ask the machine to find files that look like that. After all, that's why we *have* machines.
I think the real problem is the vast number of people who do work first and save organizing it for later. To overcome that mechanically requires not only a machine that understands the stuff we do with it, but understands it in the way that we do. And if you really know how we understand anything, there are a lot of cognitive scientists who would like to talk to you.
I'm afraid there is a whole lotta science to be done before we'll have a really useful interface revolution.
See Emitter-Coupled Logic. ECL operates in the linear region. That's why it needs huge power supplies and throws lots of heat. So, there are potential problems, but there is also more experience than you may have thought.
Sorry, but if MSN page authors aren't smart enough to read standards documents, then too bad for them. I'm still waiting to see anything worth reading on MSN anyway.
Replacing IBM drives with Maxtors may not make a difference. Dunno about the particular Maxtor model in question, but not so long ago I bought a Maxtor and when I read the label pasted on the HDA it seemed to say that it was actually built by IBM.
Now I wonder what part of the product Maxtor made. The carton, I guess.
At some point, the cost of fiddling with something exceeds the benefit of further fiddling. The whole point of most projects is to reach a state in which no further change is very desirable, so that the product becomes usable without daily re-learning.
Maybe window managers have just gone as far as they can go until someone comes up with a really new idea (that is actually useful).
Slashdot Mirror
Asimov already explored this. I wish I could recall the title. U.S. Robots hired a maverick who realized that the key to alleviating public fears of robots was not to make them more complex and human-like, but to make them *less* complex and more specialized. He designed robo-worms and suchlike.
One of the later "Foundation" books has nonhumanoid robots, too, and there is a brief discussion of what it is that makes a machine a robot.
Hmmm, probably the only facet of robots-in-society not explored by Asimov is the possibility that people never would really come to fear them. The two attitudes I've seen toward robots are basically (a) "so what?" and (b) "cool!"
The "theory" section seems to treat feature extraction as something new. Am I missing something, or doesn't this go back at least as far as Minsky & Papert's work on perceptrons?
I was just re-reading Hofstadter's _Gödel, Escher, Bach: an Eternal Golden Braid_ last week and there was a nice compact description of the problem and the theory about how human brains solve it, which sounds quite similar. This book is now older than some of the people working in the field of image recognition.
(Rats, now I've gotta figure out where I put my copy of _Perceptrons_.)
Works great, I presume. Telegraph linemen used to thaw frozen ground by upending a keg of quicklime over the spot where they needed to dig a post-hole.
"releasing tons of heat...and water". And salt. You *do* know what you get when you combine acid and base, besides furious boiling?
Self-heating water would be good, though -- then I can avoid nasty coffee and brew up a nice cup of tea.
You mean, calcium hydroxide? You could clean stopped drains with that. I'm surprised it's allowed near food.
Older than that. Asimov used it in several stories, including one of the Powell & Donovan robot stories (the one in which The Brain solved the hyperwarp dilemma and shanghaied P&D to test it).
Self-heating cans also appear in _Foundation and Empire_, when Lathan Devers explains its operation to Ducem Barr as they're running from Riose's task force. That would make it 50-60 years old.
Our servers are named after Indy 500 drivers. (We started out using only firsts, to wit HARROUN and GUTHRIE, but ran out of firsts pretty fast.) The Indianapolis Motor Speedway site has a complete list of drivers, and I imagine that other tracks would too.
:-)
We're stuck with shortie names too, alas. I can't use HURTUBISE since we gave up Netware.
(For internal stuff I have lately been using names drawn from Norse mythology. Microsoft-based boxes get the bad-guy names.
Yeah, it's terrible, stores could track your shopping habits, and then they'd...know your shopping habits. What exactly have I lost?
Oh, and the government could use a machine to see who is coming or going in a certain place, unlike today when they could just have someone stand there and look at people as they go by, or post a nearly invisible camera. Wow, that's so much worse.
Indeed, _1984_ is another case where the idea is to obliterate personal identity. The Party doesn't *care* who you are, so long as you're willing to do good work in exchange for bad gin.
REVELATION 13:16-18 is almost, but not quite, precisely unlike ID cards. Useful ID cards all have *different* numbers. Perhaps you've noticed?
The mark of the Beast serves to *destroy* personal identity, not to assure it. It's got nothing to do with knowing who you are; it's about saying that your identity is irrelevant, that you're property.
At least get the right Apocalypse, will ya?
The Social Security card is a piece of paper which asserts a binding between a name and a number. It's not a reasonable form of identification at all, and that's why it says "not for identification" right on the card.
These Hong Kong cards assert a binding between the name, the number, the appearance of someone's face, and the configuration of his thumbprints. Assuming the authenticity of the card can be verified, this is a MUCH stronger condition and makes it reasonable to trust that the person presenting the card is the person to whom the card was issued. These cards might actually be useful.
The main problem is that idiots who think the SS card means something that it does not, will be even more certain that the smart ID means something that it doesn't. The cure for that is to move the idiots into jobs where they have no opportunity to make that sort of mistake.
As long as it's still compilable, there's no reason that someone couldn't build tools to unobfuscate it (with a bit of human guidance). Since it's GPLed, there's no reason he couldn't publish the result. So really all this cleverness is just a waste of time.
I've done similar things starting with *object modules*, resulting in commented source and a user's manual using nothing but a decent disassembler and my wits. It's more tedious than it is difficult. Having the source, in whatever form, would be a lot easier.
What this actually means is that you can't go to the store and get off-the-shelf parts to read it. Someone invented the LaserDisc the first time, so someone can reinvent it if there is need. It's even easier the second time, because you know it's been done and have some idea as to how.
I dunno about the legal ramifications, but RCA or Pioneer or whoever owns the design would look really stupid bringing suit to stop the reverse-engineering of a product from which they have no intention of ever again making money.
If the computer's the problem, reconstructing the software on some other platform from whatever is left of the design documents should be even easier, as no mechanical engineering or fabrication skills are required.
(Sorry, but I've been bugged by this lazy thinking ever since someone on NPR's "Lost & Found Sound" suggested that wire recordings were on the verge of being lost forever just because nobody sells wire decks anymore.)
Huh? man gethostbyname. Look at the struct hostent. See the h_addrtype and h_length fields. Understand how *some* code will have no problems.
Code which depends on htonl() and friends will indeed be in trouble.
What was that story? It was set during an interstellar cold war of some sort, and described the impact of a new game that had begun popping up all over the Earth. It turns out that They have crafted a game which is teaching Our children to lose. Hmmm....
Indeed, subscription is the way that software development used to be funded. "Long before you, before the mammoth and the mastodon as well, in the time of the dinosaurs", we bought three things: a license, a copy of the currently shipping distribution, and "software maintenance". The maintenance contract caused the vendor to supply you with updates as they were released (shipped to your door, no downloading from a sluggish server!) and a support contact in the vendor's company. You could call for support AND DEMAND RESULTS, because you paid for them and could wave the invoice in the support techs' faces if they balked. ("I'm sorry but I can't accept that. Please connect me to the Manager On Duty.")
Nowadays it's all bundled together and we get fobbed off with lousy answers because nobody can show which part of the $69.95 you paid was for support.
The thing that's different this time around is, again, bundling. In the old scheme, you had the license in perpetuity and could simply stop paying for maintenance so long as you stopped expecting upgrades or support. You didn't have to buy maintenance at all, although it was usually a good thing to do.
Indeed, since O2 + 2H2 -> 2H2O an oxy-hydrogen motor doesn't look like harming the environment at all, unless it's the size of Madagascar. The winnage is in leaving the motor and its fuel supply Earthbound.
OTOH since launches don't happen continuously 24x7 the launcher could use solar/wind/tidal input and store it in superconducting accumulators for the next launch. These variable inputs are much more practical for powering rare events than for things like home heating or lighting. Win again.
...is the recyclability of the reaction products. The remanufacture of the fuel could be coupled to solar, wind, or nuclear generation at the source, meaning that all of that industrial plant could be put wherever it is best sited, whether distributed or centralized.
(This reminds me of the "nuplexes" that James Hogan wrote of, which not only produce steel from ore but send cogenerated electricity *out* insted of taking vast amounts of it in.)
I can't wait to see the "patent-pending circuitry" which sounds to me like just a rectifier. (Not even a proper full-wave network, either, if they flash at 60Hz rather than 120Hz.)-:
Oh, well, having just hand-tested 300 bulbs in those crummy series-wired strings to find the duds, I want some Forever Lights anyway.
Also, the founder of Unimation has said that he was inspired by Asimov's depiction of robots as realistic engineering products (as opposed to unpredictable, soulless monsters as in _Frankenstein_).
When I start a project, I create a directory for it to live in. Project directories live in the directory I created to contain all of my project directories. Email is in another set of directories, but if a mailgram is related to something specific (like a project) then it gets filed with related mailgrams in a suitably named folder.
So when I want something that's part of the Foo project, I know it's in Projects/Foo. If I don't remember that it's part of the Foo project, I think for a moment about what makes it distinctive and then ask the machine to find files that look like that. After all, that's why we *have* machines.
I think the real problem is the vast number of people who do work first and save organizing it for later. To overcome that mechanically requires not only a machine that understands the stuff we do with it, but understands it in the way that we do. And if you really know how we understand anything, there are a lot of cognitive scientists who would like to talk to you.
I'm afraid there is a whole lotta science to be done before we'll have a really useful interface revolution.
See Emitter-Coupled Logic. ECL operates in the linear region. That's why it needs huge power supplies and throws lots of heat. So, there are potential problems, but there is also more experience than you may have thought.
Sorry, but if MSN page authors aren't smart enough to read standards documents, then too bad for them. I'm still waiting to see anything worth reading on MSN anyway.
Replacing IBM drives with Maxtors may not make a difference. Dunno about the particular Maxtor model in question, but not so long ago I bought a Maxtor and when I read the label pasted on the HDA it seemed to say that it was actually built by IBM.
Now I wonder what part of the product Maxtor made. The carton, I guess.
At some point, the cost of fiddling with something exceeds the benefit of further fiddling. The whole point of most projects is to reach a state in which no further change is very desirable, so that the product becomes usable without daily re-learning.
Maybe window managers have just gone as far as they can go until someone comes up with a really new idea (that is actually useful).
But I'm still using fvwm2, so what do I know?