However, the biggest problem with robotic ethics is that it all presupposes that we can create a machine that actually demonstrates non-deterministic intelligence in the first place.
And, if and when we do, it also presupposes that we have the option of controlling what ethics are programmed in to it.
I'm a belever in the Accident AI theory of artificial intelligence that says that if we do create a useful non-deterministic intelligence, it will be by accident and will make everybody who tries to make it happen again look really stupid.
Well, given that this dude's patent is about as insightful as all of the vacuum energy, prepetual motion, and other cranks that people have slipped under the nose of the patent office, I don't think the field of ethical robotics has a problem...;)
Ahh, but you aren't aware of the rest of the story.
Said creator of BMRT (Blue Moon Rendering Toolkit) then left Pixar, commercialized BMRT, was sued into oblivion by Pixar, and the tatterd remnants of BMRT were then picked up by nVidia.
BMRT is now off the market. Which is too bad, because it was entirely NOT like the traditional renderman rendering engines. It used ray tracing with caustics instead of REYES.
The problem is, there's certain things that Pixar owns patents for and has been getting progressively more predatory about. So there's a limit to how successful Pixar will let the other renderman engines get.
Even though, of course, they don't make much money off of it.
Ahh, but you can do BGAs in a $15 used toaster oven.
The problem, of course, is that you pretty much are going to have to get your board professionally fabricated because I can't see that being too happy of a situation without mini vias.
I just used a laptop. A cheap one, either used or closeout. I got one partway through high school, which then lasted until my senior year of college. Walmart is selling new generic ones for a few hundered now.
The trick is to set up style sheets and macros and such for Word to allow you to get all of the symbols and stuff.
Of course, typing may not help too much if you have hand problems.
Most unversities, when faced with a student who has a medically documented problem taking notes the normal way, will generally provide you with "accomidations". All you need is a doctor to vouch for you. Accomodiations will generally be some sort of notetaking service, at least.
Different schools do it differently. Some schools can move heaven and earth for you if you have a documented dissability.
Yeah. Same with the Pentium II. Then they moved the cache onto the processor and everything else got much much bigger.;)
Re:If you don't use rosin...
on
Solder in Space
·
· Score: 2, Interesting
I thought that maintaining heat would be a problem, too.
Then it was pointed out by another slashdotter that vacuum is an insulator. As demonstrated by the Thermos container.
Soldering *might* be useful outside of one's spacecraft eventually. I'm mostly thinking of plumbing solder for running piping, however. But I imagine that doing relatively precise soldering while wearing spacesuit gloves wouldn't be the world's easiest task. But yeah, they'll probably be more interested in space welding than anything else.
Re:If you don't use rosin...
on
Solder in Space
·
· Score: 2, Informative
See, that was my thought too.
I don't think that doing it in a vacuum is the world's greatest idea. Space suit gloves do a number on your manual dexterity.
Given that you are probably going to have to collect the fumes anyway, it's probably not the world's worst idea to solder in a nitrogen filled bag, which fixes that problem.
The problem, I think, is that not only are you cleaning off any of the newly created oxidation from the soldering iron, you are also cleaning off any of the existing oxidation. And, furthermore, you are also changing the surface tension to better allow the solder to flow. So you probably still need the flux.
I'm just amazed that it took folks this long to start thinking about these sorts of things and actually working on them.
I tend to view it as the window of optimal instruction set usage closed. In that, right now, *any* reasonable instruction set, and quite a few non-reasonable ones, are "good enough" that it mostly is a matter of the performance of everything else. Because, compared to everything else, the hardware translation that is on both the AMDs and Intels (you know, the part that takes an ugly CISC instruction set and turns it into something that the RISC core can deal with) is a pretty small "bag on the side" compared to all of the other stuff on the chip.
And, really, the only thing holding back the x86 architecture otherwise is the lack of registers, which has been fixed in the AMD 64 bit extensions.
You also forgot about the ARM architecture, which shows up in a *lot* of personal computing devices -- pretty much all of the PDAs and cellphones have an ARM in them now.
It's much faster to just send out to a plasuable set of addresses than to actually try to check for them actually being "good". So they generally don't wory about that sort of thing.
They, of course, still claim that their lists are good addresses who have "opted in" to their list. But that's just salesmanship.
The only reason why IBM is not going after folks for GPL infringement of Linux code, and in many other ways being a buddy to the Linxu world, is because it benefits them. IBM has a huge patent inventory and could make SCO look like a bunch of catholic schoolboys if they *wanted* to.
In the end, the only people that the open source community have to count on is themselves. Remember, openly published examples of code with verifiable history going back in time are sufficent for prior art.
Re:New standard still necessary
on
RGB to become RGBCMY
·
· Score: 4, Interesting
It's probably simpler than you think.
CMY are really "combinations" of R G and B.
So, what's happening is that they are tossing in "intermediate" colors in roughly the same way as a 6 or 7 color printer. The exact equations are probably proprietary, but the process is pretty standard.
This comes in to play at two places. First, HDTV has a pretty ambitious color gamut, so videos designed around the HDTV gamut will look better, assuming of course that the source footage is equally high quality.
Second, there are colors that your eye can perceive that are not representable by the RGB system.
Overall, the research is already done. There's actually quite a few different ways to represent this data. PhotoCDs already use it. You want to use L*a*b or XYZ or one of the other CIE color systems.
I think it's interesting, but when I read the headline, my first thought was "Gee. What took them so long?"
See, the PostgreSQL authentication (i.e. what your clients use to connect to the database) can use all kinds of different methods, including challenge/response.
What I'm talking about is when you are making some sort of web application where you want to allow users to specify passwords, but you want those passwords to be reasonably secure themselves and stored in a database table.
So the way the contrib module for PostgreSQL works is that they are stored encrypted. However, if you try to compare them against the plaintext password, it will encrypt the supplied plaintext and compare it against the encrypted form in exactly the same way that the unix password system works.
Having said that, it's entirely possible (just nobody's done it yet) to have a similar "shared secret" that allows for the challenge/response authentication systems and, at the same time, implement it as a type such that all of the logic behind it is nicely modularized.
So you cause you string to take up more space, then count on the compression being good enough to undo that, sucking up CPU all of the time, because you don't *like* the format that the standard text format of the binary is. You do know that most of the APIs provide functions to translate these sorts of things for you already.
Doesn't make sense to me.
Do you *know* what compression format it uses for text and the paramaters thereof? Just because it says that it uses compression doesn't mean that it will do a good job of compressing base64. Have you run tests to see if you are, in fact, correct about this?
However, I'm more speaking towards ~1983 when they were making the 68k mac, not in the 90s. So, if they had made a 68k reference platform back then, it might have worked.
The problem is that Apple differentiated themselves by the MacOS and clean hardware design, Atari differentiated themselves by cheap and fast hardware design, and Amiga differentiated themselves by really incredibly cool graphics chipsets, and both Atari and Amiga were color in ways that the Mac took a while to be.
And, the problem is that compatability issues was what the mac was trying to avoid having. The paramaters of more machines with different hardware and such wouldn't help that.
The problem is that Apple relies upon both hardware *and* software revenue to survive, so PREP and CHRP made about as much sense as any other licensing effort at that point.
user defined types, including the ability to create customized indicies for them. So there's a type specifically to handle encrypted authentication passwords, for example, so you don't need to mess with crypt() all of the time.
Inheritance for tables, so you can agregate different types of data without needing to explicitly set all kinds of primary keys.
One way, of course, is to use a binary type, which can be tricky, depending on your client API. It mostly sucks if you are using an actual text-based insert query and response, whereas most of the time, there's *also* a way to use a more binary-oriented interface -- using the binary COPY interface and the relevant C API.
The problem was that the IIgs had a 65816 processor, not a 68000. So it's not quite an "underclocked Amiga". Now, the 65816 is pretty impressive given the context, but even then, it really didn't have much future to it compared to the 68k series.
And, if you look at the competition, everybody else on the 6502 (NES, Commodore, Atari, Acorn, etc) reached for the 68k, except for Acorn who made the ARM instead. And the big people working on the 6502 line was Commodore (who owned MOS) and Western Design Center (who were and still are a small company). Whereas the 68k line was backed by Motorola, who has a lot of resources to throw at it.
And the IIgs, while well designed, was pretty far out of headroom for growth, without some major changes.
So really, even though the IIgs was a great computer, Apple really shouldn't have released it because all it did was prolong the inevitable end of the Apple II line without actually "parlay"ing it into the future.
Really, they "should" have killed off the Mac and do what Acorn did -- release a new computer based on a newer processor that was able to emulate the Apple II. The problem is that, while the ARM was fast enough to emulate a BBC Micro, the 68k probably wasn't, so they wouldn't have been able to just make the Mac do it.
I think the problem is that Apple was assuming that the things that *had* ruled the market before 1984 would *continue* to rule the market.
Until the PC came along, microcomputers did not have really compatable upgrades. Sure, CP/M stuck around for a while, but after they ran out of steam in the 8080/Z-80 systems, everybody migrated elsewhere.
Same thing happened with mainframes. There was all kinds of crazy incompatable mainframes, and *then* IBM made the System 360 series and suddenly stability hit.
This is why Apple made the Apple///, the Lisa, and eventually the Mac. Because conventional wisdom said that the Apple II line would be gone anyway and that people wouldn't value long-term compatability.
I think the big thing not addressed in the linked article was the possibility of creating an "open" hardware standard, like the PC. Given that Atari and Amiga both followed with their own 68k systems, and Sun and others were making workstations out of them for quite some time, it's not entirely impossible that they could have produced a compatability standard.
Not like it would have worked, mind you. It's important to remember that, were IBM to have only been in the PC business, they would have been slaughtered by how the PC became an open standard. And it also could have happened that Microsoft, Amiga, Atari, or others would release a competing operating system and deprive Apple of the OS revenues.
I think the big thing is that Apple's decision made complete sense given the situation at the time. The big players would often try to sue or otherwise prevent their plug-compatable competition from stealing their business.
And there weren't Commodore or Atari clones, either, mind you.
In a certain sense, we only think that Apple made the wrong move because of the partially-accidental semi-open PC platform. Hindsight is 20/20, as they say. It is now possible to trust somebody other than IBM/Apple/Amiga/Atari/etc. for hardware, but it wasn't back then. I mean, when my parents purchased stuff for their Apple II, there was one Genuine Apple disk drive and one off-brand clone. But you had to have the Genuine Real Thing, Just In Case.
Ahh, yes, I was thinking of a different kind of pen.
Since I don't actually spend much time using a pen or pencil outside of artistic applications, I fear I'll one day forget how to operate traditional writing implements.;)
'cept they didn't open it until later, so it was found dumped in a construction site instead. And he *did* have his PalmPilot in it, so that was, naturally, not found with the bag.
Slashdot Mirror
Indeed.
However, the biggest problem with robotic ethics is that it all presupposes that we can create a machine that actually demonstrates non-deterministic intelligence in the first place.
And, if and when we do, it also presupposes that we have the option of controlling what ethics are programmed in to it.
I'm a belever in the Accident AI theory of artificial intelligence that says that if we do create a useful non-deterministic intelligence, it will be by accident and will make everybody who tries to make it happen again look really stupid.
Well, given that this dude's patent is about as insightful as all of the vacuum energy, prepetual motion, and other cranks that people have slipped under the nose of the patent office, I don't think the field of ethical robotics has a problem... ;)
Ahh, but you aren't aware of the rest of the story.
Said creator of BMRT (Blue Moon Rendering Toolkit) then left Pixar, commercialized BMRT, was sued into oblivion by Pixar, and the tatterd remnants of BMRT were then picked up by nVidia.
BMRT is now off the market. Which is too bad, because it was entirely NOT like the traditional renderman rendering engines. It used ray tracing with caustics instead of REYES.
The problem is, there's certain things that Pixar owns patents for and has been getting progressively more predatory about. So there's a limit to how successful Pixar will let the other renderman engines get.
Even though, of course, they don't make much money off of it.
Ahh, but you can do BGAs in a $15 used toaster oven.
The problem, of course, is that you pretty much are going to have to get your board professionally fabricated because I can't see that being too happy of a situation without mini vias.
I just used a laptop. A cheap one, either used or closeout. I got one partway through high school, which then lasted until my senior year of college. Walmart is selling new generic ones for a few hundered now.
The trick is to set up style sheets and macros and such for Word to allow you to get all of the symbols and stuff.
Of course, typing may not help too much if you have hand problems.
Most unversities, when faced with a student who has a medically documented problem taking notes the normal way, will generally provide you with "accomidations". All you need is a doctor to vouch for you. Accomodiations will generally be some sort of notetaking service, at least.
Different schools do it differently. Some schools can move heaven and earth for you if you have a documented dissability.
Yeah. Same with the Pentium II. Then they moved the cache onto the processor and everything else got much much bigger. ;)
I thought that maintaining heat would be a problem, too.
Then it was pointed out by another slashdotter that vacuum is an insulator. As demonstrated by the Thermos container.
Soldering *might* be useful outside of one's spacecraft eventually. I'm mostly thinking of plumbing solder for running piping, however. But I imagine that doing relatively precise soldering while wearing spacesuit gloves wouldn't be the world's easiest task. But yeah, they'll probably be more interested in space welding than anything else.
See, that was my thought too.
I don't think that doing it in a vacuum is the world's greatest idea. Space suit gloves do a number on your manual dexterity.
Given that you are probably going to have to collect the fumes anyway, it's probably not the world's worst idea to solder in a nitrogen filled bag, which fixes that problem.
The problem, I think, is that not only are you cleaning off any of the newly created oxidation from the soldering iron, you are also cleaning off any of the existing oxidation. And, furthermore, you are also changing the surface tension to better allow the solder to flow. So you probably still need the flux.
I'm just amazed that it took folks this long to start thinking about these sorts of things and actually working on them.
Hrmm...
I tend to view it as the window of optimal instruction set usage closed. In that, right now, *any* reasonable instruction set, and quite a few non-reasonable ones, are "good enough" that it mostly is a matter of the performance of everything else. Because, compared to everything else, the hardware translation that is on both the AMDs and Intels (you know, the part that takes an ugly CISC instruction set and turns it into something that the RISC core can deal with) is a pretty small "bag on the side" compared to all of the other stuff on the chip.
And, really, the only thing holding back the x86 architecture otherwise is the lack of registers, which has been fixed in the AMD 64 bit extensions.
You also forgot about the ARM architecture, which shows up in a *lot* of personal computing devices -- pretty much all of the PDAs and cellphones have an ARM in them now.
True, but does this actually *help* them?
It's much faster to just send out to a plasuable set of addresses than to actually try to check for them actually being "good". So they generally don't wory about that sort of thing.
They, of course, still claim that their lists are good addresses who have "opted in" to their list. But that's just salesmanship.
Indeed.
The only reason why IBM is not going after folks for GPL infringement of Linux code, and in many other ways being a buddy to the Linxu world, is because it benefits them. IBM has a huge patent inventory and could make SCO look like a bunch of catholic schoolboys if they *wanted* to.
In the end, the only people that the open source community have to count on is themselves. Remember, openly published examples of code with verifiable history going back in time are sufficent for prior art.
It's probably simpler than you think.
CMY are really "combinations" of R G and B.
So, what's happening is that they are tossing in "intermediate" colors in roughly the same way as a 6 or 7 color printer. The exact equations are probably proprietary, but the process is pretty standard.
This comes in to play at two places. First, HDTV has a pretty ambitious color gamut, so videos designed around the HDTV gamut will look better, assuming of course that the source footage is equally high quality.
Second, there are colors that your eye can perceive that are not representable by the RGB system.
Overall, the research is already done. There's actually quite a few different ways to represent this data. PhotoCDs already use it. You want to use L*a*b or XYZ or one of the other CIE color systems.
I think it's interesting, but when I read the headline, my first thought was "Gee. What took them so long?"
Ahh, but there is one real piece of evidence.
Always curly-bracketing your if statements will result in fewer bugs, statistically.
Why? Take this piece of code:
if (cond)
doThis()
now what's your first urge when you want to add something?
if (cond)
doThis()
doThat()
Works in Python and Ruby fine, but not in C. Hence always do things of the form
if (cond) {
doThis()
}
Ahh..
;)
But then you should try Ruby, which is even more awesome than Python in many respects.
Indeed.
See, the PostgreSQL authentication (i.e. what your clients use to connect to the database) can use all kinds of different methods, including challenge/response.
What I'm talking about is when you are making some sort of web application where you want to allow users to specify passwords, but you want those passwords to be reasonably secure themselves and stored in a database table.
So the way the contrib module for PostgreSQL works is that they are stored encrypted. However, if you try to compare them against the plaintext password, it will encrypt the supplied plaintext and compare it against the encrypted form in exactly the same way that the unix password system works.
Having said that, it's entirely possible (just nobody's done it yet) to have a similar "shared secret" that allows for the challenge/response authentication systems and, at the same time, implement it as a type such that all of the logic behind it is nicely modularized.
Ummm....
So you cause you string to take up more space, then count on the compression being good enough to undo that, sucking up CPU all of the time, because you don't *like* the format that the standard text format of the binary is. You do know that most of the APIs provide functions to translate these sorts of things for you already.
Doesn't make sense to me.
Do you *know* what compression format it uses for text and the paramaters thereof? Just because it says that it uses compression doesn't mean that it will do a good job of compressing base64. Have you run tests to see if you are, in fact, correct about this?
Indeed.
However, I'm more speaking towards ~1983 when they were making the 68k mac, not in the 90s. So, if they had made a 68k reference platform back then, it might have worked.
The problem is that Apple differentiated themselves by the MacOS and clean hardware design, Atari differentiated themselves by cheap and fast hardware design, and Amiga differentiated themselves by really incredibly cool graphics chipsets, and both Atari and Amiga were color in ways that the Mac took a while to be.
And, the problem is that compatability issues was what the mac was trying to avoid having. The paramaters of more machines with different hardware and such wouldn't help that.
The problem is that Apple relies upon both hardware *and* software revenue to survive, so PREP and CHRP made about as much sense as any other licensing effort at that point.
Except that if you code it in base64, you'll blow up the size of the binary data, whereas if you'd use BYTEA or large-object support, you won't.
There's two ways to do binary types.
One way, of course, is to use a binary type, which can be tricky, depending on your client API. It mostly sucks if you are using an actual text-based insert query and response, whereas most of the time, there's *also* a way to use a more binary-oriented interface -- using the binary COPY interface and the relevant C API.
The other way is to use the large object support.
Well, not necessarily.
The problem was that the IIgs had a 65816 processor, not a 68000. So it's not quite an "underclocked Amiga". Now, the 65816 is pretty impressive given the context, but even then, it really didn't have much future to it compared to the 68k series.
And, if you look at the competition, everybody else on the 6502 (NES, Commodore, Atari, Acorn, etc) reached for the 68k, except for Acorn who made the ARM instead. And the big people working on the 6502 line was Commodore (who owned MOS) and Western Design Center (who were and still are a small company). Whereas the 68k line was backed by Motorola, who has a lot of resources to throw at it.
And the IIgs, while well designed, was pretty far out of headroom for growth, without some major changes.
So really, even though the IIgs was a great computer, Apple really shouldn't have released it because all it did was prolong the inevitable end of the Apple II line without actually "parlay"ing it into the future.
Really, they "should" have killed off the Mac and do what Acorn did -- release a new computer based on a newer processor that was able to emulate the Apple II. The problem is that, while the ARM was fast enough to emulate a BBC Micro, the 68k probably wasn't, so they wouldn't have been able to just make the Mac do it.
I think the problem is that Apple was assuming that the things that *had* ruled the market before 1984 would *continue* to rule the market.
///, the Lisa, and eventually the Mac. Because conventional wisdom said that the Apple II line would be gone anyway and that people wouldn't value long-term compatability.
Until the PC came along, microcomputers did not have really compatable upgrades. Sure, CP/M stuck around for a while, but after they ran out of steam in the 8080/Z-80 systems, everybody migrated elsewhere.
Same thing happened with mainframes. There was all kinds of crazy incompatable mainframes, and *then* IBM made the System 360 series and suddenly stability hit.
This is why Apple made the Apple
I think the big thing not addressed in the linked article was the possibility of creating an "open" hardware standard, like the PC. Given that Atari and Amiga both followed with their own 68k systems, and Sun and others were making workstations out of them for quite some time, it's not entirely impossible that they could have produced a compatability standard.
Not like it would have worked, mind you. It's important to remember that, were IBM to have only been in the PC business, they would have been slaughtered by how the PC became an open standard. And it also could have happened that Microsoft, Amiga, Atari, or others would release a competing operating system and deprive Apple of the OS revenues.
I think the big thing is that Apple's decision made complete sense given the situation at the time. The big players would often try to sue or otherwise prevent their plug-compatable competition from stealing their business.
And there weren't Commodore or Atari clones, either, mind you.
In a certain sense, we only think that Apple made the wrong move because of the partially-accidental semi-open PC platform. Hindsight is 20/20, as they say. It is now possible to trust somebody other than IBM/Apple/Amiga/Atari/etc. for hardware, but it wasn't back then. I mean, when my parents purchased stuff for their Apple II, there was one Genuine Apple disk drive and one off-brand clone. But you had to have the Genuine Real Thing, Just In Case.
True, but you may need cable clippers to really cut through the cable easily, which tend to be pretty big, in order to get enough leverage.
;)
Hmmm... Makes me want to see if I can pick up one cheap just to screw with it.
Ahh, yes, I was thinking of a different kind of pen.
;)
Since I don't actually spend much time using a pen or pencil outside of artistic applications, I fear I'll one day forget how to operate traditional writing implements.
Same thing happened to a cow-orker of mine.
'cept they didn't open it until later, so it was found dumped in a construction site instead. And he *did* have his PalmPilot in it, so that was, naturally, not found with the bag.