It'll be interesting to see how he gets around the most critical issue in one time pads. Never re-use them. There are several interesting stories about one time pads finally being re-used and years old messages being decrypted along with the new stuff.
No one's yet commented on some of the issues that have gotta be there, which are cool I think. What if you lose one? Big robots might be easy to spot yeah, but what about smaller ones. Having that much space give you the opportunity to test some cool stuff like actual navigation and location problems in real scale.
Talk about potenitally noisy neighbors though... "Sorry our 500kg robot tore down your fence and let the animals out. It was only our of sight for a few minutes."
I bet they'll still check for abandoned mine shafts and wells just as carefully as anyone else.
You might get the impression this is about NASCAR size cars... still interesting when you realize that 9fps is coming from a single NiCad in Tyco size vehicles.
Just to clarify for those who made the same initial assumption I did.
If I remember right, the alternating 3 leg movement is the best case for a 6 leg walker. There were some interesting experiments done with simple walking robots, disabling legs and such and watching how it parallelled insects with a damaged leg.
I'd bet it depends on if there is an imbalance in weight distribution and one side can't pick up 2 legs at the same time, which would probably force it into one at a time movement. Just a guess though. Theres lots of research done on simple walking robots done with really minimal fedback control circuits. They do teh same stuff. Of course the extra degrees of freedom in the joints makes things a little harder.
Something the article does not state... A system like this can make a major difference in the power cost. Big commercial consumers pay based on their *peak* power draw (at least in CA). If you can reduce the peak draw, you change your costs for your entire usage. Cost/megawatt is significantly higer on a 600Amp peak circuit than it is on a 300Amp peak draw circuit. Major major difference, especially when multiplying that across the entire system.
Not all of it. One of the braking systems on electric vehicles is to alter the phase on the motors, making them generators, and run the current through resistors on the tops of the cars. Railroad engines do this, for example, and many streetcars do.
Several posts refer to the flywheel as being on the train. I don't think it explicitly says in the article, but I think it's clear that they are talking about stationary equipment in the stations, not flywheels on the trains. Lots of advantages to this.
The modifications to the trains are actually significant to support this, but it's about how the braking systems work and how the motor controllers work on the trains. There are a class of motor controllers that are not really compatible with regenerative braking, and they are fairly commonly used since they are cheaper than the others. The conversion to regenerative braking may involve replacing a fair bit of gear on the rolling stock. They were considering this kind of thing in San Diego, which is where I picked up lots of this trivia.
Many rail systems and streetcar systems have regenerative braking, but frequently they don't store the energy. What they do is have one unit braking while another is accellerating, so the excess power is in effect transferred via the wire to the other vehicle. Think of cable car systems where the guy at the top of the hill counterbalances the one at the bottom. This is hard to make work though, the timing issues being what they are.
That is what this *should* be about. Doesn't look like they are thinking about fundamentally changing the system though. It'd be interesting to see if any of the bidders are.
What SHOULD happen is that all the current owners of a.org should vote on what organization they want to run the.ORG domains. This way, we have a better chance that whatever organization that controls it will serve the interests of the public, not some corporations interests.
If the Internet ran on the whim of the masses, we'd reallyt be in the soup.
That being said I don't knwo whether ICANN is the best decision maker or not.
There is more info on the product page at Freecharge. But I think it would be cool if there were a little more information. The "45 seconds of winding" for what sounds like full charge seems pretty cool. This would be excellent for camping trips and such.
The nerd in me wants to know if you are winding a sping or direct charging....
Why is it that people assume that everything BEEP must be XML, it's not true. Channel 0 (the control channel) is XML, this has NOTHING to do with what an application profile's data looks like.
Profile data can be binary (and is by default) or specified by a MIME header in the frame. Other than that, it's handed off to the profile to handle, BEEP does not look inside the encapsulated data other than to pass it to the profile handler.
XML is used in the control channel, that is the limit of BEEP's imposition of XML on the world.
I know for a fact that the server is not very brawny. Here's a note from beepcore.org.
WE'VE BEEN SLASHDOTTED... sorry! Because the beepcore.org server is built using apache/tomcat, but runs on a small server, it can't handle the load of the slashdot hordes. So, you're getting this statically-generated page instead.
If you really want to get to the dynamic site, click on the logo above.
Yes, BEEP handles the case you talk about, but only if you have opened multiple channels within the connection. Each channel is processed synchronously, there is no guarante of synchronous or ordered processing between channels. This is not to say that the channel handlers can not impose this within the application, but the protocol itself does not.
There are a couple of (significant) differences between BXXP and BEEP, but no fundamental changes. And the name change came about as a result of commentary from folks at the IETF session on the topic. It appears they were tired of the eXcessive use of the letter X, that and BEEP is easier to say.
The BEEP activity I noticed most recently was on a proposal for syslog-reliable, and I believe there are some intrusion detection things using it in the academic space.
There is also an excellent white paper (on beepcore.org I think) on the transport of SOAP using BEEP rather than HTTP, and it really is a pretty sweet fit, though early on they were in competition for mindshare at the IETF and neither wanted to be absorbed conceptually into the other.
O'Reilly has published a book on BEEP by Dr. Marshall Rose, the principal BEEP designer. It's good.
There are various cool things going on in this space.
One of the big issues in this case is perhaps that every transformation you do on the type of energy has an efficiency cost. So, from the mechanical energy you generate with a combustion engine, you pass it through an electrical generation step, perhaps storage in the battery, and then back to mechanical.
On the plus side, my understanding about vehicles being built by a company in San Diego (busses and trash trucks I think), is that they reduced the diesel emmisions by 95%, since diesels are dirtiest when idling. I am not sure about the savings on cleaner burning fuels such as CNG. These vehicles were using a combustion generator of about 35% of the horsepower of the standard engine in the smae vehicle.
SOAP (as first presented) is RPC structured in XML and transported over HTTP. This is as I understand it in a nutshell. There is more, but that's the basics
The question is, "Do you need RPC?". A big question. RPC is something that has been done badly many times, and solves a limited class of problems. If you do then structuring the protocol constructs in XML seems a fine way to go. If you really need to do CGI-POST type transactions then HTTP is a good choice, but that's a big IF. There are lots of people trying to more with CGI/POST than is was meant for, and that's part of what is being addressed with SOAP. HTTP is well known, and people inderstand it, so it is very attractive. It's about as ubiquitous as it gets on the net. Ask a business type what DNS is and you'll likely get a blank look, ask them what HTTP is and they'll (theink they) have a much better clue.
The major questions are "do you need RPC?" and "do you want to do things like HTTP does them?" in my opinion. Fortunatley HTTP is an easy component of the puzzle to replace with something that has a longer session duration that one connection or peer-to-peer characteristics if you need them.
There are many reasons they do this I am sure, including custom hardware etc.
and the only way youcan guarantee that kind of reliability is to code it yourself
Huge statement, also fluff. Assumes you are smarter and more careful than the rest of the world.
In the end they do need extreme reliability, and one of the ways they deal with this systems that vote among themselves. They don't trust a single machine to be 100% reliable. No personal knowlege here, but I surmise NASA has a testing regime/QA process that is almsot unparallelled. Run an opensource project structure in the way Linux is through that same process and you would see remarkable reliability.
------------------------
I was working at a bank at the time and some folks there took a *careful* look at the fixes. Since DES/3DES was a well accepted encryption standard in wide use at the time (and still is...) it's
pretty important to them. Also important to the FDIC for similar reasons, and I'd be willing to bet that's a big reason for their release of that fix. ------------------------
For those that have not visited the link in the article it is well worth the read. Pretty good discussion of the topics involved and a decent high-level discussion of the kernel architecture involved.
Interesting also the comments by the NSA guy interviewed about what this is and what it is not. They are pretty carefully staying out of CroptoFS and such and not commenting about the crypto available.
In the end there could be a lot of good done by this, in terms of making a large piece of the net harder to trash by idiots and kiddies. Also could make the linux mail/web/server platform orders of magnitude more interesting to corporate/business if easily accessible security is (more?) orders of magnitude better than NT/2000 tech.
We have watched SOAP reasonably closely for a variety of reasons where I work, and there are a couple of things that others here have touched on which I also wanted to comment on.
HTTP -- one of the other folks higher up noted that SOAP uses HTTP for transport, but is not tightly linked. I was not aware of this, but that was one of my primary concerns, trying to overload this functionality on a prototcol which was designed for other things.
One of the things cited initially as a benefit of SOAP was that it does use HTTP and therefore can easily pass firewalls without lots of extra configuration and support worries. On the one hand this is good for ease of support, on the other hand, it gives somewhat less control on the Firewall as noted by another post. In the end one could write validation routines for SOAP via HTTP as easily as one could for standard HTTP. It's the same problem one has detecting netcat connections masqerading as HTTP.... not a lot of good solutions out there in use yet.
RPC -- is what it is. There has been a fair bit of discussion as regards SOAP and some of it's percieved competitors. In the end a big piece of SOAP is the RPC stuff transported in an XML framework. If you need to do RPC that is cool, but RPC is not panacea. When you need it you need it. When you don't, it's likely to cause you more heartache than joy. As I understand it, it is difficult to do right, though I have never been involved in an implementation myself.
Slashdot Mirror
Too late. As I understand it, they are in fact windows boxes.
It'll be interesting to see how he gets around the most critical issue in one time pads. Never re-use them. There are several interesting stories about one time pads finally being re-used and years old messages being decrypted along with the new stuff.
Talk about potenitally noisy neighbors though... "Sorry our 500kg robot tore down your fence and let the animals out. It was only our of sight for a few minutes."
I bet they'll still check for abandoned mine shafts and wells just as carefully as anyone else.
Just to clarify for those who made the same initial assumption I did.
I'd bet it depends on if there is an imbalance in weight distribution and one side can't pick up 2 legs at the same time, which would probably force it into one at a time movement. Just a guess though. Theres lots of research done on simple walking robots done with really minimal fedback control circuits. They do teh same stuff. Of course the extra degrees of freedom in the joints makes things a little harder.
Something the article does not state... A system like this can make a major difference in the power cost. Big commercial consumers pay based on their *peak* power draw (at least in CA). If you can reduce the peak draw, you change your costs for your entire usage. Cost/megawatt is significantly higer on a 600Amp peak circuit than it is on a 300Amp peak draw circuit. Major major difference, especially when multiplying that across the entire system.
Per my other post, the youo don't stick the flywheels on the trains... they go in the stations.
Not all of it. One of the braking systems on electric vehicles is to alter the phase on the motors, making them generators, and run the current through resistors on the tops of the cars. Railroad engines do this, for example, and many streetcars do.
The modifications to the trains are actually significant to support this, but it's about how the braking systems work and how the motor controllers work on the trains. There are a class of motor controllers that are not really compatible with regenerative braking, and they are fairly commonly used since they are cheaper than the others. The conversion to regenerative braking may involve replacing a fair bit of gear on the rolling stock. They were considering this kind of thing in San Diego, which is where I picked up lots of this trivia.
Many rail systems and streetcar systems have regenerative braking, but frequently they don't store the energy. What they do is have one unit braking while another is accellerating, so the excess power is in effect transferred via the wire to the other vehicle. Think of cable car systems where the guy at the top of the hill counterbalances the one at the bottom. This is hard to make work though, the timing issues being what they are.
My $.02
That is what this *should* be about. Doesn't look like they are thinking about fundamentally changing the system though. It'd be interesting to see if any of the bidders are.
That being said I don't knwo whether ICANN is the best decision maker or not.
The nerd in me wants to know if you are winding a sping or direct charging....
Why is it that people assume that everything BEEP must be XML, it's not true. Channel 0 (the control channel) is XML, this has NOTHING to do with what an application profile's data looks like.
Profile data can be binary (and is by default) or specified by a MIME header in the frame. Other than that, it's handed off to the profile to handle, BEEP does not look inside the encapsulated data other than to pass it to the profile handler.
XML is used in the control channel, that is the limit of BEEP's imposition of XML on the world.
Sweetums
Sorry, might as well post the link ... http://www.beepcore.org
Hmm. It sure used to.
Yes, BEEP handles the case you talk about, but only if you have opened multiple channels within the connection. Each channel is processed synchronously, there is no guarante of synchronous or ordered processing between channels. This is not to say that the channel handlers can not impose this within the application, but the protocol itself does not.
Sweetums
BEEP isn't RPC, though it can be used as a transport layer for an RPC profile (e.g. the rpc aspects of SOAP).
Pretty much nope....
Sweetums
There are a couple of (significant) differences between BXXP and BEEP, but no fundamental changes. And the name change came about as a result of commentary from folks at the IETF session on the topic. It appears they were tired of the eXcessive use of the letter X, that and BEEP is easier to say.
The BEEP activity I noticed most recently was on a proposal for syslog-reliable, and I believe there are some intrusion detection things using it in the academic space.
There is also an excellent white paper (on beepcore.org I think) on the transport of SOAP using BEEP rather than HTTP, and it really is a pretty sweet fit, though early on they were in competition for mindshare at the IETF and neither wanted to be absorbed conceptually into the other.
O'Reilly has published a book on BEEP by Dr. Marshall Rose, the principal BEEP designer. It's good.
Sweetums
There are various cool things going on in this space.
One of the big issues in this case is perhaps that every transformation you do on the type of energy has an efficiency cost. So, from the mechanical energy you generate with a combustion engine, you pass it through an electrical generation step, perhaps storage in the battery, and then back to mechanical.
On the plus side, my understanding about vehicles being built by a company in San Diego (busses and trash trucks I think), is that they reduced the diesel emmisions by 95%, since diesels are dirtiest when idling. I am not sure about the savings on cleaner burning fuels such as CNG. These vehicles were using a combustion generator of about 35% of the horsepower of the standard engine in the smae vehicle.
The question is, "Do you need RPC?". A big question. RPC is something that has been done badly many times, and solves a limited class of problems. If you do then structuring the protocol constructs in XML seems a fine way to go. If you really need to do CGI-POST type transactions then HTTP is a good choice, but that's a big IF. There are lots of people trying to more with CGI/POST than is was meant for, and that's part of what is being addressed with SOAP. HTTP is well known, and people inderstand it, so it is very attractive. It's about as ubiquitous as it gets on the net. Ask a business type what DNS is and you'll likely get a blank look, ask them what HTTP is and they'll (theink they) have a much better clue.
The major questions are "do you need RPC?" and "do you want to do things like HTTP does them?" in my opinion. Fortunatley HTTP is an easy component of the puzzle to replace with something that has a longer session duration that one connection or peer-to-peer characteristics if you need them.
my 2 cents.
------------------------
In the end they do need extreme reliability, and one of the ways they deal with this systems that vote among themselves. They don't trust a single machine to be 100% reliable. No personal knowlege here, but I surmise NASA has a testing regime/QA process that is almsot unparallelled. Run an opensource project structure in the way Linux is through that same process and you would see remarkable reliability.
------------------------
I was working at a bank at the time and some folks there took a *careful* look at the fixes. Since DES/3DES was a well accepted encryption standard in wide use at the time (and still is...) it's pretty important to them. Also important to the FDIC for similar reasons, and I'd be willing to bet that's a big reason for their release of that fix.
------------------------
Interesting also the comments by the NSA guy interviewed about what this is and what it is not. They are pretty carefully staying out of CroptoFS and such and not commenting about the crypto available.
In the end there could be a lot of good done by this, in terms of making a large piece of the net harder to trash by idiots and kiddies. Also could make the linux mail/web/server platform orders of magnitude more interesting to corporate/business if easily accessible security is (more?) orders of magnitude better than NT/2000 tech.
------------------------
HTTP -- one of the other folks higher up noted that SOAP uses HTTP for transport, but is not tightly linked. I was not aware of this, but that was one of my primary concerns, trying to overload this functionality on a prototcol which was designed for other things.
One of the things cited initially as a benefit of SOAP was that it does use HTTP and therefore can easily pass firewalls without lots of extra configuration and support worries. On the one hand this is good for ease of support, on the other hand, it gives somewhat less control on the Firewall as noted by another post. In the end one could write validation routines for SOAP via HTTP as easily as one could for standard HTTP. It's the same problem one has detecting netcat connections masqerading as HTTP.... not a lot of good solutions out there in use yet.
RPC -- is what it is. There has been a fair bit of discussion as regards SOAP and some of it's percieved competitors. In the end a big piece of SOAP is the RPC stuff transported in an XML framework. If you need to do RPC that is cool, but RPC is not panacea. When you need it you need it. When you don't, it's likely to cause you more heartache than joy. As I understand it, it is difficult to do right, though I have never been involved in an implementation myself.
------------------------