On the flip side, if the intelligent sensors told the car to start coasting, the gas engine could still be turned off. Combine this with plug-in options on the hybrid for recharging the battery, and you can still see an improvement on the hybrid over the standard combustion engine. If the prediction sensors are anticipating a full stop, you can still get regenerative breaking as well. After all, you're still going to get energy back from slowing down gradually rather than quickly. You might even be able to get more, as you could do more of the deceleration purely through the generation resistance, and less with friction braking.
Where did you get the idea that there was a server involved? If this is anything like the original Grand Challenge, the vehicles won't be allowed to contact any external servers while they're running the course. They'll be given maps of the area with GPS coordinates before they run the course, but while they're running the course they'll have to do everything on their own. No querying some hypothetical traffic server for these autonomous vehicles - they have to be able to run the course based solely on their maps and their observed data (from various sensors).
While the basic concept is sound, practical implementation leads to some basic problems.
First, and the most obvious, is the cost involved. That's a whole lot of infrastructure to set up, and the equipment isn't exactly cheap. Consider that simply replacing the highways signs in any moderate-sized state costs millions of dollars - and that's just for painted sheet metal, and the labor to put them up. Those costs would multiply when you have to have powered radio transmitters on the signs, as well.
Second, it absolutely depends on the autonomous vehicle only driving in places where that infrastructure is already set up, and not anywhere else. That includes making sure that all the vehicles in that place have the radio transmitters set up, as well - can't let someone drive in with a non-transmitting car, or it could screw up everything.
Third, for this challenge in particular, they're talking about wanting this for the vehicles to run supplies into foreign urban theaters - in other words, regions where it is highly unlikely that the infrastructure will be in place. Refer back to the second point.
As a result, oddly enough, it's actually easier to just put the intelligence into the vehicle, instead of trying to wire up the entire world so that the vehicle can drive in it.
I think there might actually be a legal argument for the musicians here. Mainly due to this key quote from the article: "According to the suit, the record company is treating digital downloads like traditional record sales, rather than licensed music, triggering a different royalty deal."
Based on that, it seems like Sony is unilaterally deciding that digital downloads fall under the physical media contract rather than the licensed music contract, despite the fact that neither contract specifies digital downloads. In other words, it actually is _not_ in the contract how this should be handeled. I suspect the musicians' lawyers are going to argue that the licensed music contract should apply instead of the physical media contract, which, based on the fact that there is no physical media, may well have a legal foot to stand on (though what do I know, I'm not a lawyer).
Unless the musicians signed a contract that did specify digital downloads, I can see how they might have a case.
"Games today are waaaaay too easy, which to me is a huge turn off. Fun isn't walking through a game; fun is finally beating the boss that just killed you 18 times."
I submit that you're willing to sit through getting killed 18 times just to kill one boss means you're not a "casual gamer" to begin with. Personally, I sympathize with the original comment. It isn't fun to me to encounter constant frustration. When it takes 18 times to get through the same sequence, I find it frustrating.
The more hardcore gamers demand that level of challenge. That's fine. But it does mean that the games that are made for that level of challenge are going to drive away casual gamers like me, who want to use their games to vent frustration - not cause more of it.
DJing isn't a big industry. For most "professional DJs", the DJ gig is not their primary source of income - the overwhelming majority have day jobs to pay the bills. Someone becomes a DJ because they want to, and they either teach themself, or have another DJ teach them how. There aren't exactly DJ schools out there. So, how are the professional DJs supposed to know about the law in the first place? Who would have told them?
Keep in mind that each vehicle was racing against the clock, not each other, and they had staggered starting times. Also, the judges for the race had the ability to "pause" the vehicles for various reasons, which would not be considered an impact on their travel time (the clock would be stopped for that vehicle while paused). Apparently most vehicles were paused throughout the race.
That said, I was watching the end of the race, and Stanford's "Stanley" passed CMU's "H1ghlander" about 30-40 miles from the end of the race, pulled ahead by several miles, and kept the lead. Stanley was second out of the gate, and the first to cross the finish line. H1ghlander finished several minutes later, with CMU's "Sandstorm" finishing close behind.
In the end, though H1ghlander was the second to cross the finish line, Sandstorm was actually on the course for less time, and thus, took second place. Gray Team took significantly longer than the top 3 to finish, so it was both the fourth to cross the line, and the fourth in standings, while TerraMax didn't technically complete the requirements (it took longer than 10 hours), though it did finish the course.
That sounds more environmental than overhead. I've generally gotten at least half the medium bandwidth in practice, once all overhead, including FTP protocol overhead, is factored in. That is, I'll get 5Mbps from a 11Mbps radio, and around 30+Mbps for a 54Mbps radio. If you are only getting 8Mbps from a 54 Mbps radio, then I suggest you do the following: 1) change to a different radio channel. There is a good chance you are getting a lot of interference in your area from other devices in the 2.4GHz spectrum (assuming you are using 802.11g, and not 802.11a). Don't pick the immediate next channel - channels 1, 6 and 11 are completely orthogonal and do not interfere with each other, but channel 3, for example, can get interference from channels 1-6. 2) Find a position for your Access Point so that you can get a better line-of-sight between your client and the AP's antenna. Also make sure you aren't too far away from the AP - the AP will back off to a lower bandwidth if the signal quality is less, and you may be encountering that if your client is too far from the AP, or there are too many walls or metal objects between your AP and your client. 3) Make sure the antenna on your AP is pointing upwards. The signal actually broadcasts strongest from the standard antennae shipped with APs in a toroidal pattern. The signal above and below the antenna is much weaker than to the sides. 4) Make sure nobody is piggy-backing on your AP and using up your wireless bandwidth without your knowledge. I recommend WPA2 with AES encryption. 802.1x Authentication would be preferred, but tends to not be practical for home use, but PSK should be sufficient for most needs. Granted, this will reduce your bandwidth a bit, as encryption takes processing cycles, but it won't cut you down to 8Mbps!
If none of those help, then you can try getting a better antenna, or possibly switching to another brand's AP - software overhead in processing can make a difference as well, and some vendor's APs are better than others. I'd make a recommendation, but I work in the industry, and am, therefore, quite biased;)
That can be easier said than done, since the "real" throughput greatly depends on the number of clients associated to the same access point, the number of access points on the same channel, the amount of traffic going to each client, etc, etc.
Also, what counts as "real" throughput? Can we count the overhead of an FTP or HTTP transfer, or do we have to discount those overheads as well? (In which case your "100Mbps Ethernet" isn't 100Mbps, either).
You ask that the industry specifies something that can be measured instead of an arbitrary number - they did. The throughput of the medium is actually quantified and measured in a standard way. Attempting to determine just what "real" data throughput is would be arbitrary, and not necessarily something that could actually be measured reliably.
The medium does get 54mbps, in total, raw bits. The problem, however, is that there is protocol overhead and latency to deal with that makes your data throughput something around 12mbps.
You can't just send an Ethernet II or 802.3 frame out onto the air and expect it to get where you want it to go without additional header information. Data collisions also become more interesting when not every node can see every other node's traffic (which is different from wired traffic), which means that there needs to be additional protocol overhead to deal with such occurrences.
802.11n will also have a lower data throughput than the raw medium bandwidth. It will still be significantly faster than 802.11g, though.
Really? Then please, set free all of your userids with associated server names, the passwords to those accounts, your credit card numbers, your ATM PIN, your bank account numbers, and any information needed to access said accounts.
After all, all of that is information, so if it wants to be set free....
Could you please provide a reference for how the names ought to be pronounced? Every single pronunciation guide I could find on-line said, to the last one, that the pronunciation of "Zeus" is [ZOOS]. I've had an interest in Greek Mythology for some time, and I've never come across any other pronunciation. If there actually is a pronunciation that is more correct than that, I am very curious to know what it is.
Why isn't the Judicial Branch doing anything? Well, considering this bill hasn't even been voted on by the full Senate yet, much less been passed by both Senate and House and been signed into Law by the President, the Judicial Branch can't really do much.
That's right, it's only made it out of a committee. It isn't Law yet. And quite likely never will be (or have you not noticed that plenty of Senators from _both_ parties have been questioning the Patriot Act as of late?)
The article in the Register which you link to exhibits some very poor journalism. It asserts that the entire Huffington Post is a hoax - a satire website with fakes impersonating well-known people, entirely on the basis that the author of the Register article can't believe that Hilary Rosen would be, well, hypocritical. Did the author contact Arianna Huffington to confirm that the new blog site was actually a hoax? Did the author contact Hilary Rosen to confirm that she wasn't the actual author of that article? If the answer to either of those questions is "yes", there is no evidence of it in the article.
Meanwhile, other news sites, such as the Washington Post, actually contacted Huffington and several of the named celebrity bloggers, and, guess what? The evidence would seem to indicate that the Huffington Post is no hoax.
Speaking as a software engineer that works on embedded systems, it has nothing to do with being studly as it has to to with wasting my time and effort. There are reasons why operating systems exist. The same reasons that make an operating system a good idea for a PC apply to embedded products. As a result, most embedded products use operating systems. We also don't tend to write our own - why should we reinvent the wheel? So we use already existing and well-developed operating systems, since that saves us a _great deal_ of development time and money (we're talking saving months of development time, and hundreds of thousands of dollars in money, once you add up all the engineers' salaries). So, paying a small royalty seems like a good deal in the end. Of course, these days, most companies are finding they don't need to pay the royalty anymore by going with free embedded operating systems, like eCos, or one of the many variants of Linux for the embedded world that now exist.
Oh, and while I'll agree that the programmers need operating systems, I'd also argue that many applications _need_ operating systems at this point, too. Not all, certainly, but many do.
I would be a bit surprised if they decided to randomly do S-turns at 35 mph on open road during the competition, so I would guess that won't be a problem. As for situations where the course might require them to do an S-turn, I imagine they'll have tweaked the programming to slow down from 35 mph before doing so in the future.
I have to take issue with the ideas expressed that, a) the Team Red robot is not autonomous, and b) there isn't any impressive technology in their robot. First, I'll address a). Autonomous means that it drives itself with no outside control. I'm assuming that you are implying that having detailed maps constitutes outside control. I disagree. When a person drives somewhere they've never been before, they usually use maps themselves. If they've been there and are familiar with the area, they basically already have a mental map that they consult. Pre-mapping the terrain and giving that map to the robot is providing essentially the same kind of information. The robot still must perform extensive obstacle avoidance, and must be able to deal with the rough terrain that it will encounter, which happen to be the harder tasks than simply knowing what the general path to take is beforehand. Addtionally, I might point out that the general aim for the whole challenge is to produce vehicles for the Military - do you really think that the Military would not want to be able to provide detailed maps to any autonomous convoy or fighting vehicle ahead of time? Now to address b). If there wasn't any impressive technology in this robot, the Grand Challenge wouldn't be very much of a challenge, would it? One of the parts I find pretty impressive is the sensor array on that robot, which stabilizes itself, and "looks" the direction of the path the robot wishes to travel, much like a human does when driving. That's actually pretty cool, in my book.
Honestly, all of the teams have pretty impressive technology. I don't think it is really appropriate to insult another team in the competition.
Any WEP capable hardware should be software upgradeable to comply with the TKIP portion of WPA. TKIP uses WEP encryption, but increases the size of the key and the size of the IV. The hardware for the encryption should (given the algorithm for RC4, which is the algorithm used in WEP) be able to handle any length key given to it. Frame generation is done in software in the MAC anyways. Thus, legacy hardware is at least capable of being retrofitted to comply with WPA TKIP (and 802.11i TKIP, which is slightly different) purely through a software upgrade. If one wants to be able to work with the AES-CCMP portion of WPA or 802.11i, then new hardware will be necessary, but the whole point of the TKIP portions of the WPA and 802.11i standards was to allow legacy equipment to become compatible via software upgrades.
Now, why this is still better and why Airsnort won't be quite as effective: Airsnort relied on the fact that everyone was using the same keys; all clients, for both unicast and multicast, used the same set of keys for encryption. That made it easy, using general network traffic trends, to crack the encryption. Another issue was that they used a small initialization vector to try to make it so that the same key wasn't used every time - the IV gets appended to the pre-specified key, and is stored in the frame that is sent over the air. While this extended the key by 24 bits, it became obvious that 24 bits was way too small, and allowed any individual combination of key and iv to be repeated fairly often, which makes it even easier for Airsnort to crach the keys. First, WPA and 802.11i, whether using CCMP or TKIP, do not use the same key for all client encryption. Instead, a transient key is generated per client per session based on a Pairwise Master Key and some exchanged data. Additionally, the size of the key has been increased when using TKIP, and the size of the IV has been dramatically increased (the IV is now 128 bits when performing TKIP). These two measures combined make it much, much more difficult to crack the keys, since each client has a different key per client, and generally speaking, the IV is large enough that any individual key + IV combo is never repeated (before that happens a reauthentication will generally happen, and with reauthentication, a new transient key is generated). Finally, there are also additional countermeasures in the protocol that never existed under WEP, all of which are implementable in software. WPA is not an attempt to force people to go out and buy new hardware - it is the specific realization that people do not want to do so, but new product will not be sold without a better security solution; thus, it was desired to create a protocol that older hardware can be upgraded to while also providing better security. To get the best security requires upgrading (AES does require a hardware change), but getting better security that was available before does not require new hardware at all.
I pointed out MIT Zephyr in a reply to a different post on this subject, so I'll just add to my earlier post by saying that MIT Zephyr was in use all over the world long before July 21, 1998.
The Zephyr system that came out of MIT (IIRC) has allowed people to know that the other person is getting ready to send them a message since long before all these fancy GUI-based IM programs existed. If one's options were setup correctly, one would get a message saying "Ping from " when that person started a message to you. This addresses the language of the patent quoted above, as well as the intent.
DARPA funds a wide range of scientific projects, not all of which are even directly military, much less meant for weapons systems. Many of the kinds of projects they fund are related to data storage, communications, etc, which are useful, in some cases even vital, to the military, but are not weapon-related at all, and definitely help more than just the military. Don't forget, before the internet, there was ARPAnet.
It's funny that you mention User Friendly, Sluggy Freelance and Megatokyo here while asking if on-line comics are economically viable. I don't know about Kevin and Kell, but in the case of the other three you mention, the artists/authors have all quit their day jobs, and live off their webcomics alone now, (Megatokyo is only the most recent of the three to have done so, in fact). On the other hand, I do still grant the point. Those three have among the largest readerships of webcomics, and therefore have a larger base from which to make money off of when selling merchandise, while other webcomics are not so fortunate.
The article left a lot of big-name webcomics, actually. On the other hand, all the webcomics it specifically mentioned offer "exclusive content" if you pay for their "on-line subscriptions." Neither Penny Arcade, nor Megatokyo do this. I'm not sure if the author didn't understand that these sites and ones like them (such as Sluggy Freelance) make money by using their web-presence and fanbase to generate revenue via merchandising, or if he wanted to focus on making money specifically on the comics themselves, and therefore they did not really fall into the same category as the comics he mentioned.
It was an interesting read, but I did note that the author had a number of errors in his article. (Keenspot is not a paper publisher, though he basically said they were, for instance. It just happens that most of the webcomics on Keenspot that do get books published do so through the same publisher: Plan 9 Books).
802.1x has little equipment support?
on
802.11 Security
·
· Score: 3, Informative
Okay, so you won't find 802.1x support in your standard el cheapo LinkSys or NetGear AP. In fact, you won't find 802.1x support in any cheap access point. On the other hand, if one does pay for the higher-end access points, pretty much every major vendor supports 802.1x authentication. It is considered a requirement for an access point to be considered an "enterprise" AP. Furthermore, WECA's requirements for WiFi certification this year are adding "WPA", which is a stripped down version of 802.11i, which happens to depend heavily on 802.1x. Any new products after this requirement is added will have to have 802.1x support in order to be "WiFi Certified." Believe me, the wireless industry is moving heavily towards 802.1x (I've written two different implementations of 802.1x for two different access point products myself), so it should not be so casually dismissed.
For those who scoff at wireless security: sure, it probably won't be as secure as locked away wired networks; but 802.11i does at least make it non-trivial to break the security of wireless networks (pairwise session keys on a per-client basis, larger size keys, larger IV space, message integrity checks, etc).
Slashdot Mirror
On the flip side, if the intelligent sensors told the car to start coasting, the gas engine could still be turned off. Combine this with plug-in options on the hybrid for recharging the battery, and you can still see an improvement on the hybrid over the standard combustion engine. If the prediction sensors are anticipating a full stop, you can still get regenerative breaking as well. After all, you're still going to get energy back from slowing down gradually rather than quickly. You might even be able to get more, as you could do more of the deceleration purely through the generation resistance, and less with friction braking.
Where did you get the idea that there was a server involved? If this is anything like the original Grand Challenge, the vehicles won't be allowed to contact any external servers while they're running the course. They'll be given maps of the area with GPS coordinates before they run the course, but while they're running the course they'll have to do everything on their own. No querying some hypothetical traffic server for these autonomous vehicles - they have to be able to run the course based solely on their maps and their observed data (from various sensors).
While the basic concept is sound, practical implementation leads to some basic problems.
First, and the most obvious, is the cost involved. That's a whole lot of infrastructure to set up, and the equipment isn't exactly cheap. Consider that simply replacing the highways signs in any moderate-sized state costs millions of dollars - and that's just for painted sheet metal, and the labor to put them up. Those costs would multiply when you have to have powered radio transmitters on the signs, as well.
Second, it absolutely depends on the autonomous vehicle only driving in places where that infrastructure is already set up, and not anywhere else. That includes making sure that all the vehicles in that place have the radio transmitters set up, as well - can't let someone drive in with a non-transmitting car, or it could screw up everything.
Third, for this challenge in particular, they're talking about wanting this for the vehicles to run supplies into foreign urban theaters - in other words, regions where it is highly unlikely that the infrastructure will be in place. Refer back to the second point.
As a result, oddly enough, it's actually easier to just put the intelligence into the vehicle, instead of trying to wire up the entire world so that the vehicle can drive in it.
I think there might actually be a legal argument for the musicians here. Mainly due to this key quote from the article:
"According to the suit, the record company is treating digital downloads like traditional record sales, rather than licensed music, triggering a different royalty deal."
Based on that, it seems like Sony is unilaterally deciding that digital downloads fall under the physical media contract rather than the licensed music contract, despite the fact that neither contract specifies digital downloads. In other words, it actually is _not_ in the contract how this should be handeled. I suspect the musicians' lawyers are going to argue that the licensed music contract should apply instead of the physical media contract, which, based on the fact that there is no physical media, may well have a legal foot to stand on (though what do I know, I'm not a lawyer).
Unless the musicians signed a contract that did specify digital downloads, I can see how they might have a case.
One problem is that shielding the instruments from interference might also shield them from receiving the signals they need to in order to be useful.
It's kind of like how we can't shield 802.11g access points from 2.4GHz cordless phone interference.
"Games today are waaaaay too easy, which to me is a huge turn off. Fun isn't walking through a game; fun is finally beating the boss that just killed you 18 times."
I submit that you're willing to sit through getting killed 18 times just to kill one boss means you're not a "casual gamer" to begin with. Personally, I sympathize with the original comment. It isn't fun to me to encounter constant frustration. When it takes 18 times to get through the same sequence, I find it frustrating.
The more hardcore gamers demand that level of challenge. That's fine. But it does mean that the games that are made for that level of challenge are going to drive away casual gamers like me, who want to use their games to vent frustration - not cause more of it.
DJing isn't a big industry. For most "professional DJs", the DJ gig is not their primary source of income - the overwhelming majority have day jobs to pay the bills. Someone becomes a DJ because they want to, and they either teach themself, or have another DJ teach them how. There aren't exactly DJ schools out there. So, how are the professional DJs supposed to know about the law in the first place? Who would have told them?
Keep in mind that each vehicle was racing against the clock, not each other, and they had staggered starting times. Also, the judges for the race had the ability to "pause" the vehicles for various reasons, which would not be considered an impact on their travel time (the clock would be stopped for that vehicle while paused). Apparently most vehicles were paused throughout the race.
That said, I was watching the end of the race, and Stanford's "Stanley" passed CMU's "H1ghlander" about 30-40 miles from the end of the race, pulled ahead by several miles, and kept the lead. Stanley was second out of the gate, and the first to cross the finish line. H1ghlander finished several minutes later, with CMU's "Sandstorm" finishing close behind.
In the end, though H1ghlander was the second to cross the finish line, Sandstorm was actually on the course for less time, and thus, took second place. Gray Team took significantly longer than the top 3 to finish, so it was both the fourth to cross the line, and the fourth in standings, while TerraMax didn't technically complete the requirements (it took longer than 10 hours), though it did finish the course.
That sounds more environmental than overhead. I've generally gotten at least half the medium bandwidth in practice, once all overhead, including FTP protocol overhead, is factored in. That is, I'll get 5Mbps from a 11Mbps radio, and around 30+Mbps for a 54Mbps radio. If you are only getting 8Mbps from a 54 Mbps radio, then I suggest you do the following:
;)
1) change to a different radio channel. There is a good chance you are getting a lot of interference in your area from other devices in the 2.4GHz spectrum (assuming you are using 802.11g, and not 802.11a). Don't pick the immediate next channel - channels 1, 6 and 11 are completely orthogonal and do not interfere with each other, but channel 3, for example, can get interference from channels 1-6.
2) Find a position for your Access Point so that you can get a better line-of-sight between your client and the AP's antenna. Also make sure you aren't too far away from the AP - the AP will back off to a lower bandwidth if the signal quality is less, and you may be encountering that if your client is too far from the AP, or there are too many walls or metal objects between your AP and your client.
3) Make sure the antenna on your AP is pointing upwards. The signal actually broadcasts strongest from the standard antennae shipped with APs in a toroidal pattern. The signal above and below the antenna is much weaker than to the sides.
4) Make sure nobody is piggy-backing on your AP and using up your wireless bandwidth without your knowledge. I recommend WPA2 with AES encryption. 802.1x Authentication would be preferred, but tends to not be practical for home use, but PSK should be sufficient for most needs. Granted, this will reduce your bandwidth a bit, as encryption takes processing cycles, but it won't cut you down to 8Mbps!
If none of those help, then you can try getting a better antenna, or possibly switching to another brand's AP - software overhead in processing can make a difference as well, and some vendor's APs are better than others. I'd make a recommendation, but I work in the industry, and am, therefore, quite biased
That can be easier said than done, since the "real" throughput greatly depends on the number of clients associated to the same access point, the number of access points on the same channel, the amount of traffic going to each client, etc, etc.
Also, what counts as "real" throughput? Can we count the overhead of an FTP or HTTP transfer, or do we have to discount those overheads as well? (In which case your "100Mbps Ethernet" isn't 100Mbps, either).
You ask that the industry specifies something that can be measured instead of an arbitrary number - they did. The throughput of the medium is actually quantified and measured in a standard way. Attempting to determine just what "real" data throughput is would be arbitrary, and not necessarily something that could actually be measured reliably.
The medium does get 54mbps, in total, raw bits. The problem, however, is that there is protocol overhead and latency to deal with that makes your data throughput something around 12mbps.
You can't just send an Ethernet II or 802.3 frame out onto the air and expect it to get where you want it to go without additional header information. Data collisions also become more interesting when not every node can see every other node's traffic (which is different from wired traffic), which means that there needs to be additional protocol overhead to deal with such occurrences.
802.11n will also have a lower data throughput than the raw medium bandwidth. It will still be significantly faster than 802.11g, though.
Really? Then please, set free all of your userids with associated server names, the passwords to those accounts, your credit card numbers, your ATM PIN, your bank account numbers, and any information needed to access said accounts.
After all, all of that is information, so if it wants to be set free....
Could you please provide a reference for how the names ought to be pronounced? Every single pronunciation guide I could find on-line said, to the last one, that the pronunciation of "Zeus" is [ZOOS]. I've had an interest in Greek Mythology for some time, and I've never come across any other pronunciation. If there actually is a pronunciation that is more correct than that, I am very curious to know what it is.
n ary&va=Zeus&x=0&y=0 m l . html
Here are a few references I found when attempting to find a pronunciation guide:
http://www.m-w.com/cgi-bin/dictionary?book=Dictio
http://www.pantheon.org/articles/z/zeus.html
http://www.infoplease.com/ce6/society/A0853377.ht
http://library.thinkquest.org/J002110/zeus.htm
http://www.yourdictionary.com/ahd/z/z0012500.html
http://reference.allrefer.com/encyclopedia/Z/Zeus
http://www.gods-heros-myth.com/godpages/zeus.html
http://www.hyperdic.net/dic/zeus.htm
http://www.uwf.edu/english/lanier/Pronunc.html
Why isn't the Judicial Branch doing anything? Well, considering this bill hasn't even been voted on by the full Senate yet, much less been passed by both Senate and House and been signed into Law by the President, the Judicial Branch can't really do much.
That's right, it's only made it out of a committee. It isn't Law yet. And quite likely never will be (or have you not noticed that plenty of Senators from _both_ parties have been questioning the Patriot Act as of late?)
The article in the Register which you link to exhibits some very poor journalism. It asserts that the entire Huffington Post is a hoax - a satire website with fakes impersonating well-known people, entirely on the basis that the author of the Register article can't believe that Hilary Rosen would be, well, hypocritical. Did the author contact Arianna Huffington to confirm that the new blog site was actually a hoax? Did the author contact Hilary Rosen to confirm that she wasn't the actual author of that article? If the answer to either of those questions is "yes", there is no evidence of it in the article.
Meanwhile, other news sites, such as the Washington Post, actually contacted Huffington and several of the named celebrity bloggers, and, guess what? The evidence would seem to indicate that the Huffington Post is no hoax.
Speaking as a software engineer that works on embedded systems, it has nothing to do with being studly as it has to to with wasting my time and effort. There are reasons why operating systems exist. The same reasons that make an operating system a good idea for a PC apply to embedded products. As a result, most embedded products use operating systems. We also don't tend to write our own - why should we reinvent the wheel? So we use already existing and well-developed operating systems, since that saves us a _great deal_ of development time and money (we're talking saving months of development time, and hundreds of thousands of dollars in money, once you add up all the engineers' salaries). So, paying a small royalty seems like a good deal in the end. Of course, these days, most companies are finding they don't need to pay the royalty anymore by going with free embedded operating systems, like eCos, or one of the many variants of Linux for the embedded world that now exist.
Oh, and while I'll agree that the programmers need operating systems, I'd also argue that many applications _need_ operating systems at this point, too. Not all, certainly, but many do.
I would be a bit surprised if they decided to randomly do S-turns at 35 mph on open road during the competition, so I would guess that won't be a problem. As for situations where the course might require them to do an S-turn, I imagine they'll have tweaked the programming to slow down from 35 mph before doing so in the future.
I have to take issue with the ideas expressed that, a) the Team Red robot is not autonomous, and b) there isn't any impressive technology in their robot.
First, I'll address a). Autonomous means that it drives itself with no outside control. I'm assuming that you are implying that having detailed maps constitutes outside control. I disagree. When a person drives somewhere they've never been before, they usually use maps themselves. If they've been there and are familiar with the area, they basically already have a mental map that they consult. Pre-mapping the terrain and giving that map to the robot is providing essentially the same kind of information. The robot still must perform extensive obstacle avoidance, and must be able to deal with the rough terrain that it will encounter, which happen to be the harder tasks than simply knowing what the general path to take is beforehand. Addtionally, I might point out that the general aim for the whole challenge is to produce vehicles for the Military - do you really think that the Military would not want to be able to provide detailed maps to any autonomous convoy or fighting vehicle ahead of time?
Now to address b). If there wasn't any impressive technology in this robot, the Grand Challenge wouldn't be very much of a challenge, would it? One of the parts I find pretty impressive is the sensor array on that robot, which stabilizes itself, and "looks" the direction of the path the robot wishes to travel, much like a human does when driving. That's actually pretty cool, in my book.
Honestly, all of the teams have pretty impressive technology. I don't think it is really appropriate to insult another team in the competition.
Any WEP capable hardware should be software upgradeable to comply with the TKIP portion of WPA. TKIP uses WEP encryption, but increases the size of the key and the size of the IV. The hardware for the encryption should (given the algorithm for RC4, which is the algorithm used in WEP) be able to handle any length key given to it. Frame generation is done in software in the MAC anyways. Thus, legacy hardware is at least capable of being retrofitted to comply with WPA TKIP (and 802.11i TKIP, which is slightly different) purely through a software upgrade.
If one wants to be able to work with the AES-CCMP portion of WPA or 802.11i, then new hardware will be necessary, but the whole point of the TKIP portions of the WPA and 802.11i standards was to allow legacy equipment to become compatible via software upgrades.
Now, why this is still better and why Airsnort won't be quite as effective:
Airsnort relied on the fact that everyone was using the same keys; all clients, for both unicast and multicast, used the same set of keys for encryption. That made it easy, using general network traffic trends, to crack the encryption. Another issue was that they used a small initialization vector to try to make it so that the same key wasn't used every time - the IV gets appended to the pre-specified key, and is stored in the frame that is sent over the air. While this extended the key by 24 bits, it became obvious that 24 bits was way too small, and allowed any individual combination of key and iv to be repeated fairly often, which makes it even easier for Airsnort to crach the keys.
First, WPA and 802.11i, whether using CCMP or TKIP, do not use the same key for all client encryption. Instead, a transient key is generated per client per session based on a Pairwise Master Key and some exchanged data. Additionally, the size of the key has been increased when using TKIP, and the size of the IV has been dramatically increased (the IV is now 128 bits when performing TKIP). These two measures combined make it much, much more difficult to crack the keys, since each client has a different key per client, and generally speaking, the IV is large enough that any individual key + IV combo is never repeated (before that happens a reauthentication will generally happen, and with reauthentication, a new transient key is generated). Finally, there are also additional countermeasures in the protocol that never existed under WEP, all of which are implementable in software.
WPA is not an attempt to force people to go out and buy new hardware - it is the specific realization that people do not want to do so, but new product will not be sold without a better security solution; thus, it was desired to create a protocol that older hardware can be upgraded to while also providing better security.
To get the best security requires upgrading (AES does require a hardware change), but getting better security that was available before does not require new hardware at all.
I pointed out MIT Zephyr in a reply to a different post on this subject, so I'll just add to my earlier post by saying that MIT Zephyr was in use all over the world long before July 21, 1998.
The Zephyr system that came out of MIT (IIRC) has allowed people to know that the other person is getting ready to send them a message since long before all these fancy GUI-based IM programs existed. If one's options were setup correctly, one would get a message saying "Ping from " when that person started a message to you.
This addresses the language of the patent quoted above, as well as the intent.
DARPA funds a wide range of scientific projects, not all of which are even directly military, much less meant for weapons systems. Many of the kinds of projects they fund are related to data storage, communications, etc, which are useful, in some cases even vital, to the military, but are not weapon-related at all, and definitely help more than just the military.
Don't forget, before the internet, there was ARPAnet.
It's funny that you mention User Friendly, Sluggy Freelance and Megatokyo here while asking if on-line comics are economically viable. I don't know about Kevin and Kell, but in the case of the other three you mention, the artists/authors have all quit their day jobs, and live off their webcomics alone now, (Megatokyo is only the most recent of the three to have done so, in fact).
On the other hand, I do still grant the point. Those three have among the largest readerships of webcomics, and therefore have a larger base from which to make money off of when selling merchandise, while other webcomics are not so fortunate.
The article left a lot of big-name webcomics, actually. On the other hand, all the webcomics it specifically mentioned offer "exclusive content" if you pay for their "on-line subscriptions." Neither Penny Arcade, nor Megatokyo do this. I'm not sure if the author didn't understand that these sites and ones like them (such as Sluggy Freelance) make money by using their web-presence and fanbase to generate revenue via merchandising, or if he wanted to focus on making money specifically on the comics themselves, and therefore they did not really fall into the same
category as the comics he mentioned.
It was an interesting read, but I did note that the author had a number of errors in his article. (Keenspot is not a paper publisher, though he basically said they were, for instance. It just happens that most of the webcomics on Keenspot that do get books published do so through the same publisher: Plan 9 Books).
Okay, so you won't find 802.1x support in your standard el cheapo LinkSys or NetGear AP. In fact, you won't find 802.1x support in any cheap access point. On the other hand, if one does pay for the higher-end access points, pretty much every major vendor supports 802.1x authentication. It is considered a requirement for an access point to be considered an "enterprise" AP. Furthermore, WECA's requirements for WiFi certification this year are adding "WPA", which is a stripped down version of 802.11i, which happens to depend heavily on 802.1x. Any new products after this requirement is added will have to have 802.1x support in order to be "WiFi Certified."
Believe me, the wireless industry is moving heavily towards 802.1x (I've written two different implementations of 802.1x for two different access point products myself), so it should not be so casually dismissed.
For those who scoff at wireless security: sure, it probably won't be as secure as locked away wired networks; but 802.11i does at least make it non-trivial to break the security of wireless networks (pairwise session keys on a per-client basis, larger size keys, larger IV space, message integrity checks, etc).