Another thing I really like is that the plot development isn't predictable, nasty things happen and the characters have to live with the consequences.
Yeah, that's my favorite thing about this series. You never can be quite sure who is a friend and who is an enemy. A long-time enemy, like Scorpious (or however you spell his name) may turn out to be the good-guy in the next episode (how many times did the Scorpy-in-Chriton's-head save them all?).
The article mentioned exploring other planets or searching earthquake zones. Such environments often require something that can adapt quickly to changing circumstances.
The rules for BattleBots specificly mention "polybots" (aka a modular robot). However, I can only remember seeing one robot a few seasons ago that used such a design, and it didn't do too well.
The rules for polybots go like this:
You have to show the ability to put the robot back together (without getting in there and doing it with your hands)
The robot is KOed when 50% or more of the peices are incapacitated.
If you have different configurations, your robot must meet the weight requirement in all its possible configurations
I believe there is also a rule that only two people on your team are allowed to be by the arena for driving, which will limit the number of peices that can be manualy controled. (I'm not sure about that rule, though).
There are also practical considerations to when taking the third rule into account. Imagine bringing in your highly-modular robot and telling the judges that your bot has a total of 2^32 possible configurations, and it must be weighed in all of them. The best thing to do in this circumstance is to call up the judges before the tourny and ask them if the bot can just be weighed in the configuration you're about to send into the arena. Bots are reweighed before each fight anyways, so this shouldn't be a problem.
In a lot of situations, an old PC with a bunch of ethernet cards, GNU/Linux, and Zebra would be perfectly fine for a router. Memory is cheeper, and it's probably faster (though a Cisco 2500 is still plenty powerful enough for the task). A PC also is quite a bit more flexible. Further, in the case of Zebra, the syntax used is very similar to Cisco's IOS, so there is a smaller learning curve for those who are used to IOS already.
However, one drawback is security. On a Cisco router, you only have to worry about someone breaking the IOS system; with Zebra, you have to worry about someone breaking the underlieing OS AND Zebra itself. Breaking either gives you access to the router itself. Further, IOS has been around for years and has been throughly debugged. Zebra is not quite in a 1.0 release. Plus there are features; Zebra won't have support for multicast routing protocols until 2.0.
You basically have to decide if the extra expense of a Cisco router is worth whatever reduction in secuiry and stability. And you can't go the Zebra if you need multicast (like for streaming videos, game servers, whatever).
Am I alone in thinking Wrox generaly sucks? Their Beginning Java 2 book was used in my Java course last year. The book is OK if you're just learning Java, but is almost useless as a referance (possibly because they want you to buy the referance as a seperate book). Don't get me started on that Ivor Horton guy (aka, "Evil Horn").
But then cheaters could just change a few variable names and get away with it. You really need a human to review the programs flaged as cheaters, someone who knows that 20 identical 'Hello, World!' programs is to be expected.
My high school CS teacher once found a few identical programs. He printed out the source code to some transparancies, then lined them up, one on top of the other, on the overhead projector. The only blurred spot was the comment with the students' names.
Just because it's "printing" doesn't mean that there aren't large tooling costs, and I suspect (but can't verify) that there might be.
I've been wondering about tooling costs, too. Every article I read says " . . . printed with technology similar to inkjet printers." That "similar" word makes me worry. Apparently one group at MIT did use an actual inkjet, though. You'd still need special ink and paper, which could get pricy. Also, the kinds of size of the paths would be dependent on how good your printer is; an old printer that tends to smear even standard images and text just won't cut it.
I think there will always be a demand for all that little stuff like LEDs or discrete transistors or whatever. Even on a modern motherboard, that has a few bazilion really tiny transistors may occasionaly have a single transistor sitting off somewhere. Even big, mass-produced places will have a need to put just a few LEDs at a few specific spots (indicator lights) just like they do today. These things are not going to go away, and they will probably be massed produced for the forseeable future, no matter what new plastic-computers come along.
This actually isn't going to be any use for processors, and it won't necessarily work for small runs either. But it is a very cool technology for different reasons, and the article does explain this.
For big, cycle-sucking applications, maybe. However, I could see this being quite useful as a means for hobbists to create their own PDAs or other microcontroler devices (it could be a boon for robot fighting, being able to pre-program certain moves, etc.)
OK, so there are already things like the BASIC Stamp to do this, and while I can't imagine plastic microcontrolers being cheeper (overall) than a BASIC Stamp, it would still be fun to play with the circutry on your own.
"Those nanobots I printed and released into the fish tank to monitor polution yesterday have eaten my goldfish. Could you come up with some new nanobots to eat the bad nanobots?"
Thanks, that was great. Do you mind if I put that in my e-mail.sig file?
I realized about three seconds after I hit "submit" that it's not just the OS that would need to be portable; you also need to port all those Windows applications. So I guess if CLR caught on, Microsoft really *could* move away from being Intel-only.
. . . then they are quite capable of doing it all on their own. NT, so I am told, should be no harder to port than Linux. It is just a matter of doing to work to make the port happen. They don't need CLR or.NET to make it happen. In fact, it makes it worse because you have to port the kernel, the old Windows libs (for backwards compatibility), AND the new.NET libs.
Physical access almost always means total access. I don't know of any OS that can get around that problem (although encrypted filesystems help to a degree). It's just something you have to live with.
Umm, I've never seen a computer that was missing a CD drive, yet had a USB controller (except maybe embedded systems). I'd be cool with using CD-R/W, except they're better for doing one big save all at once instead of lots of little saves ("Oops, I made a typo. Guess I have to sit here waiting 10 minutes for the new copy to burn.") These things are really for replacing floppy disks.
Also, for putting distros on these things, do you know of a BIOS that lets you boot off a USB storage device? I suppose you could use a regular floppy as a boot disk then load the filesystems off the storage device. You would either need a boot manager that can understand the USB mass storage device standard (good luck), or can boot a kernel off the floppy (wait about three minutes for this), then load up the filesystems from your keychain:)
Because people still use Win98. Find me someone who still uses a 1.x kernel for any real work (i.e., it's not just a system that was set on a shelf somewhere and forgotten, or some kernel hacker looking at ancient code.
The problem with CD-R/W is that it is rather klumsy for saving stuff. CD-R/W is not an effective replacement for a good (bad) ol' floppy disk. Zip disks are a rather expensive, propreity disk type, so they're no good. I would be very happy to see these USB devices allow me to throw away my floppies.
Could this at last be the end of crappy, unreliable floppy drives that haven't grown since the days of the 40 MB hard drive? Oh please, oh please, oh please . . .
RC4 is a propreity algorithm, IIRC, and was kept under lock-and-key by RSADSA Inc. I know that one of the RC? algos was leaked onto USENET. OTOH, it was made by Rivest, who is "not your typical snake-oil peddler" (in the words of Bruce Schiner).
DES is also very annoying in software because of that first-round that adds no extra security (it just makes it nice for hardware implementations). Software DES could ignore that first round completely, though you couldn't really call that "DES". If you must use DES, DO NOT use your standard 56-bit DES. Use 3DES.
The only thing DES still has going for it is that you've got 20 or so years of cryptanylisis behind it and brute force is still the most efficent way of breaking it. Even so, you absolutly SHOULD NOT use plain DES. Use 3DES instead. AES has about 4 years of cryptanylisis on it (IIRC), but it is also much faster than DES (and it doesn't have that annoying first round that adds nothing to security and makes it really annoying to implement in software). So your choices of modern block algorithms are either 3DES or AES.
56 bits is not secure enough for jack squat besides leading you into a false sense of security (there is a rule in crypto that says that low secuirity is actually worse than no secuirity). In 1993, it was estimated that it was possible to build a specialized DES-cracking computer for about $1 million (US), well within the reach of a large corperation or government-funded orginazation, which would take about three hours to go through the keys. Today, you could probably get some freinds and hook up a distributed.net/Seti@home-style network (cracking encryption by brute force is CPU dependent, not bandwidth or latency dependent, so you can do it over a dial-up connection) and crack the keys used in about the same time.
Slashdot Mirror
Another thing I really like is that the plot development isn't predictable, nasty things happen and the characters have to live with the consequences.
Yeah, that's my favorite thing about this series. You never can be quite sure who is a friend and who is an enemy. A long-time enemy, like Scorpious (or however you spell his name) may turn out to be the good-guy in the next episode (how many times did the Scorpy-in-Chriton's-head save them all?).
The article mentioned exploring other planets or searching earthquake zones. Such environments often require something that can adapt quickly to changing circumstances.
The rules for BattleBots specificly mention "polybots" (aka a modular robot). However, I can only remember seeing one robot a few seasons ago that used such a design, and it didn't do too well.
The rules for polybots go like this:
I believe there is also a rule that only two people on your team are allowed to be by the arena for driving, which will limit the number of peices that can be manualy controled. (I'm not sure about that rule, though).
There are also practical considerations to when taking the third rule into account. Imagine bringing in your highly-modular robot and telling the judges that your bot has a total of 2^32 possible configurations, and it must be weighed in all of them. The best thing to do in this circumstance is to call up the judges before the tourny and ask them if the bot can just be weighed in the configuration you're about to send into the arena. Bots are reweighed before each fight anyways, so this shouldn't be a problem.
Anybody have ideas for a good polybot?
See also: The Slashdot Brigade.
(Yeah, OK, so it was proposed a year ago. We just really need people to get the job done.)
In a lot of situations, an old PC with a bunch of ethernet cards, GNU/Linux, and Zebra would be perfectly fine for a router. Memory is cheeper, and it's probably faster (though a Cisco 2500 is still plenty powerful enough for the task). A PC also is quite a bit more flexible. Further, in the case of Zebra, the syntax used is very similar to Cisco's IOS, so there is a smaller learning curve for those who are used to IOS already.
However, one drawback is security. On a Cisco router, you only have to worry about someone breaking the IOS system; with Zebra, you have to worry about someone breaking the underlieing OS AND Zebra itself. Breaking either gives you access to the router itself. Further, IOS has been around for years and has been throughly debugged. Zebra is not quite in a 1.0 release. Plus there are features; Zebra won't have support for multicast routing protocols until 2.0.
You basically have to decide if the extra expense of a Cisco router is worth whatever reduction in secuiry and stability. And you can't go the Zebra if you need multicast (like for streaming videos, game servers, whatever).
Am I alone in thinking Wrox generaly sucks? Their Beginning Java 2 book was used in my Java course last year. The book is OK if you're just learning Java, but is almost useless as a referance (possibly because they want you to buy the referance as a seperate book). Don't get me started on that Ivor Horton guy (aka, "Evil Horn").
But then cheaters could just change a few variable names and get away with it. You really need a human to review the programs flaged as cheaters, someone who knows that 20 identical 'Hello, World!' programs is to be expected.
My high school CS teacher once found a few identical programs. He printed out the source code to some transparancies, then lined them up, one on top of the other, on the overhead projector. The only blurred spot was the comment with the students' names.
Just because it's "printing" doesn't mean that there aren't large tooling costs, and I suspect (but can't verify) that there might be.
I've been wondering about tooling costs, too. Every article I read says " . . . printed with technology similar to inkjet printers." That "similar" word makes me worry. Apparently one group at MIT did use an actual inkjet, though. You'd still need special ink and paper, which could get pricy. Also, the kinds of size of the paths would be dependent on how good your printer is; an old printer that tends to smear even standard images and text just won't cut it.
I think there will always be a demand for all that little stuff like LEDs or discrete transistors or whatever. Even on a modern motherboard, that has a few bazilion really tiny transistors may occasionaly have a single transistor sitting off somewhere. Even big, mass-produced places will have a need to put just a few LEDs at a few specific spots (indicator lights) just like they do today. These things are not going to go away, and they will probably be massed produced for the forseeable future, no matter what new plastic-computers come along.
This actually isn't going to be any use for processors, and it won't necessarily work for small runs either. But it is a very cool technology for different reasons, and the article does explain this.
For big, cycle-sucking applications, maybe. However, I could see this being quite useful as a means for hobbists to create their own PDAs or other microcontroler devices (it could be a boon for robot fighting, being able to pre-program certain moves, etc.)
OK, so there are already things like the BASIC Stamp to do this, and while I can't imagine plastic microcontrolers being cheeper (overall) than a BASIC Stamp, it would still be fun to play with the circutry on your own.
"Those nanobots I printed and released into the fish tank to monitor polution yesterday have eaten my goldfish. Could you come up with some new nanobots to eat the bad nanobots?"
Thanks, that was great. Do you mind if I put that in my e-mail .sig file?
I realized about three seconds after I hit "submit" that it's not just the OS that would need to be portable; you also need to port all those Windows applications. So I guess if CLR caught on, Microsoft really *could* move away from being Intel-only.
. . . then they are quite capable of doing it all on their own. NT, so I am told, should be no harder to port than Linux. It is just a matter of doing to work to make the port happen. They don't need CLR or .NET to make it happen. In fact, it makes it worse because you have to port the kernel, the old Windows libs (for backwards compatibility), AND the new .NET libs.
Jesus Christ. I just wasted 30 minutes of my life reading through that whole mess. I want those 30 minutes back!
Welcome to Slashdot!
Physical access almost always means total access. I don't know of any OS that can get around that problem (although encrypted filesystems help to a degree). It's just something you have to live with.
Loopback encrypted filesystems
Umm, I've never seen a computer that was missing a CD drive, yet had a USB controller (except maybe embedded systems). I'd be cool with using CD-R/W, except they're better for doing one big save all at once instead of lots of little saves ("Oops, I made a typo. Guess I have to sit here waiting 10 minutes for the new copy to burn.") These things are really for replacing floppy disks.
Also, for putting distros on these things, do you know of a BIOS that lets you boot off a USB storage device? I suppose you could use a regular floppy as a boot disk then load the filesystems off the storage device. You would either need a boot manager that can understand the USB mass storage device standard (good luck), or can boot a kernel off the floppy (wait about three minutes for this), then load up the filesystems from your keychain :)
Because people still use Win98. Find me someone who still uses a 1.x kernel for any real work (i.e., it's not just a system that was set on a shelf somewhere and forgotten, or some kernel hacker looking at ancient code.
The problem with CD-R/W is that it is rather klumsy for saving stuff. CD-R/W is not an effective replacement for a good (bad) ol' floppy disk. Zip disks are a rather expensive, propreity disk type, so they're no good. I would be very happy to see these USB devices allow me to throw away my floppies.
Could this at last be the end of crappy, unreliable floppy drives that haven't grown since the days of the 40 MB hard drive? Oh please, oh please, oh please . . .
RC4 is a propreity algorithm, IIRC, and was kept under lock-and-key by RSADSA Inc. I know that one of the RC? algos was leaked onto USENET. OTOH, it was made by Rivest, who is "not your typical snake-oil peddler" (in the words of Bruce Schiner).
DES is also very annoying in software because of that first-round that adds no extra security (it just makes it nice for hardware implementations). Software DES could ignore that first round completely, though you couldn't really call that "DES". If you must use DES, DO NOT use your standard 56-bit DES. Use 3DES.
We should all know about the wonderful editorial integrity of the Washington Post.
The only thing DES still has going for it is that you've got 20 or so years of cryptanylisis behind it and brute force is still the most efficent way of breaking it. Even so, you absolutly SHOULD NOT use plain DES. Use 3DES instead. AES has about 4 years of cryptanylisis on it (IIRC), but it is also much faster than DES (and it doesn't have that annoying first round that adds nothing to security and makes it really annoying to implement in software). So your choices of modern block algorithms are either 3DES or AES.
56 bits is not secure enough for jack squat besides leading you into a false sense of security (there is a rule in crypto that says that low secuirity is actually worse than no secuirity). In 1993, it was estimated that it was possible to build a specialized DES-cracking computer for about $1 million (US), well within the reach of a large corperation or government-funded orginazation, which would take about three hours to go through the keys. Today, you could probably get some freinds and hook up a distributed.net/Seti@home-style network (cracking encryption by brute force is CPU dependent, not bandwidth or latency dependent, so you can do it over a dial-up connection) and crack the keys used in about the same time.