Current nitrogen content in the Martian atmosphere is 2.7%
That's news to me! Last I heard, the concern was that there was practically no nitrates on Mars. Your information completes the picture. We have pretty much all the necessary base elements necessary to survive on Mars. With the right engineering to solve the industrial issue, we are getting close to knowing everything we need to know to colonize!:-)
But what is written to the mag-stripe on the card is NOT the PIN, but rather an RSA-signed hash of the PIN. The ATM verifies the signed hash against the PIN you input on the console.
There are two problems there. First is that the security leak was supposedly at a third party level. i.e. The ATMs could have been compromised, the servers the ATMs talk to could have been compromised, etc., etc. etc. Anyway you cut it, the hash would have been just as compromised.
Secondly, the ATM cannot verify the data by itself. That isn't its job. If it was, I could put a forged card in the machine that checks out and get money from the machine. Instead, ATMs talk to secure banking servers that verify the information and process the transaction. The ATM is merely a front-end to that transaction and provides the money on behalf of the bank. (Whichever bank that might be.)
In result, ATMs line up with the authentication required by a VPN fairly well. The information going over the wire could be compromised. So how do we prevent compromises? An RSA token is a good solution. Both your bank and your card share a secret. (i.e. A seed for a psuedo-random number generator.) By communicating non-reversible information that is hashed against a changing value (in this case: time), security is greatly increased. Thus I definitely think that smartcards are a good solution.
The only part that sucks is that it would take a while to get the current magstrip infrastructure converted over to a smartcard infrastructure.
"It's typical of the soil here on Earth minus the organics," Kounaves said during a teleconference from Tucson, Ariz....
i.e. We're still missing the magic ingredient: Nitrogen. Getting a sufficient quantity of nitrates to Mars might end up being the biggest problem with colonization efforts in the future. We obviously have water. CO2 can be reprocessed into O2.
The soil is not toxic. Now all we need is Nitrogen and a good method of bootstraping industrial production on Mars. (Shipping heavier technology would be impractical.)
No, no you don't. Not if you build it into the ATM card. Smartcards exist for that very reason.
I'd rather keep it on my keys for that reason, *plus* your rsa key is seperate from the card. so you have to have two things and your pin to access the account.
Putting aside for a moment that such a tactic would be inconvenient and would lead to a large number of fobs on your keychain, it wouldn't add any real-world security to the process. Instead of one physical item, you'd need two physical items. Most people would find some clever way of keeping the two items together, thus defeating your attempt at increased security.
Putting the RSA auth into the card gives you secure two-factor authentication: Account #+RSA+PIN. The account number is analogous to a username in this case. The RSA token (something you have) thus works in concert with a standard PIN (something you know) thus providing strong security.
The problem in the article was that the cards were easy to defeat because the PIN and card number can easily be captured and reproduced. Thus just account and PIN (i.e. user/pass) are insufficient. The RSA token secures that further by demonstrating a shared secret without divulging the secret to any party who was not already aware of it.
This problem is already solved. It's called an RSA dongle. "Oh, but it's a pain!" So is having your checking account cleared out.
No need for a dongle. Just build it into the ATM card. That way the machine could authorize no more than one transaction every minute. (One transaction per token generated.) If bad guys got hold of your account number, they'd still need to physical card to crack the PIN. It might be slightly annoying that multiple transactions at an ATM would take a little longer, but the vast majority of people would never notice.
That being said, if it WAS Citibank's servers that were compromised, these guys would have been able to heist the shared secret as well. Then they'd be able to reproduce the RSA token in your card. According to Citibank, however, their servers were not compromised. They claim that a third party clearing service was responsible for the leak. (Who knows?)
No, sorry. That doesn't fly. I don't care if you read the books or not*. If you know random trivia like that offhand, you're a LoTR geek. I'm not saying that's a bad thing, but most of us read Tolkien's books only as an enjoyable diversion.
Speaking of which, it would have been nice if Tolkien had come up with more unique names for his characters. It gets really confusing after a while, especially when the names are spoken aloud.
In any case, I still maintain that The Hobbit was better. It was a whimsical adventure that was a joy to read. LoTR was a story of ever-dwindling hope and despair, drawn out into three books. Tolkien may claim that WWII was not the subject of his books, but the stress of the war definitely came through in his writing.
* I have read LoTR but I couldn't answer that. Nor do I really care that much.
you do realize that people still go down into coal mines to work? Now? in the US?
I hope that you also realize that modern coal mining has nothing to do with the hard, labor intensive work of yore. Coal mining these days is mostly about proper operation of machinery to slice off sheets of rock, process them, and then transport them to the surface for shipping. Companies wouldn't hire kids for the job even if they could. Kids would be far too likely to make a major mistake and put the company's investment at risk. (Not to mention lives. Contrary to popular belief, not ALL mines were run by greedy, heartless murderers.)
If you are ever in the Chicago area, I highly recommend visiting the Museum of Science and Industry. They have an old coal mine there that they give tours of. They show both antique and modern methods of mining for coal, including the problems that regularly occurred before the advent of modern methods. You can even see the areas that had previously been dug out by both methods.
Today the US has one of the more powerful armies and a lot of police available so the need for a citizen to have a gun and being part of a militia is no longer there.
That's assuming that the purpose of the right to bear arms was intended to support a militia. That seems rather silly as a militia would be granted special privileges while serving in the militia. Much in the same way a soldier in the modern army can carry a fully automatic assault rifle, or a rocket launcher, or operate a tank firing DU rounds. You and I really can't do any of those things, despite our right to carry arms.
The forefathers made it clear in their writings that the people must police their own country and start a revolution if the power of government became oppressive. It was their hope that such constant threat would keep the government in line and abiding by its own rules. Some argue that with the modern military under the control of the President, it wouldn't be much of a fight to crush a rebellion. In my opinion, that actually calls for a relaxation of current gun control provisions. Realistically, though, there are enough military weapons and personnel loyal stationed in each state to where a revolution would be able to seize enough equipment to put up a serious fight.
We actually saw this in the civil war. The south was able to seize quite a bit of equipment and manpower to give the north a run for its money. (Need I remind everyone how the battle of the Merrimac and Monitor went after the capture of Norfolk?) What defeated the south was that their cause was not going to gain much sympathy from the rest of the nation. Thus the north was willing to fight a horrible battle of brother against brother to ensure the unity of state. Let's hope that any future revolutions would happen for the purpose of saving human rights rather than oppressing them.
The first thing I thought of wasn't music, though that's a very good point. I was thinking "in-car speakerphone" and "Skype". But maybe I'm just weird that way.
(And apparently quite goofy, considering I barely talk on my cell phone. Especially when in the car.):-P
I disagree. One of the key reasons why I like reading eBooks is that I DON'T have to flip pages. I can use a scroll wheel or a button to flip, instead. I've found that it's many times more comfortable than holding a paperback in the center, then having to move my thumb and other arm to manage a page flip.
The reason why paper has defeated eBooks to date is because you don't have to invest in a $$$ reader ahead of time and the paper is of a much higher resolution than an eBook reader. (1200dpi prints put eBook readers to shame.) Not in a million years would I have thought that the lack of "page flipping" was a significant barrier to eBook adoption. In fact, adding page flipping would probably become an ADDITIONAL barrier to eBooks as users would be unfamiliar with how to operate the electronic device.
Steven Musolino of Brookhaven National Laboratory, who worked on the dirty bomb experiments with Harper, summed it up this way: "Pretty much everything bad happens within 500 meters, and to a large extent [the bad effects] don't happen." That conclusion jibes with the Nuclear Regulatory Commission's fact sheet on dirty bombs, which says the long-term health risk of limited exposure to radioactive particles is probably "extremely small." The commission categorizes the dirty bomb not as a weapon of mass destruction, but as a weapon of mass disruption.
Even if terrorists got access to radioactive isotopes and wrapped them around a conventional explosive device - an unlikely scenario, according to Palmore - the real danger would come from the explosion, not the spread of radioactive material. "If you're thinking in terms of pellets of radioactive material that might be spread through an explosion," he said, the danger is minimal because "it doesn't disperse in the air; you would just go through the area with a Geiger counter and clean it up."
To many experts, the dirty bomb is the most over-rated weapon in the terrorist arsenal. That's because the actual loss of life and property from such an attack probably would be relatively limited.
Long story short: Dirty bombs don't work. It's not nearly as easy to distribute radioactive materials as the media would have you believe.
Dirty bombs are scare tactics. They don't actually work.
And a small bomb hidden on the reactor could bring so much Allahu Ackbar to our ports it's not funny anymore.
A "small bomb" on the reactor would have a "small effect". Nuclear reactors are not bombs. They will not blow up like nukes when damaged. The most likely result of a "small bomb" would be a lot of damage to the ship, but very little to the reactor's containment vessel. (Easily 90% or more of a reactor's weight is heavy shielding.) The absolute worst case scenario is that the reactor goes prompt critical, and the nuclear materials sink to the bottom of the harbor. (Where they will actually be fairly well shielded against by the water.) Perhaps you might even have a boiler explosion to go with the situation.
Any way you cut it, a reactor is not a weapon. The materials inside the reactor can be used to devise a weapon with some reprocessing, which is why they must be protected. But the ships themselves would pose no danger. So please tone down the FUD machine.
Their big mistake has been ignoring commodity hardware
Not really sure what you mean here. I was rather surprised when I decided to do some Solaris development that the primary focus has moved from Solaris/SPARC to Solaris/x86. Half the cool stuff in OpenSolaris is designed around the x86 platform.
Similarly, the primary focus of the Java codebase is the x86 platform first, remaining platforms later.
Sun is also a massive seller of AMD64 and Intel Xeon based servers and workstations. Amazingly, Sun's prices have even come out of the stratosphere and are extremely competitive with other manufacturers like Dell.
Sun is even working to virtualize these "commodity platforms" with their surprisingly good OpenxVM project. I actually passed on a free copy of Parallels because Sun's VirtualBox was working so well for me.
I know Sun has the stigma of selling only overpriced iron, but the truth is that they're fairly well in tune with their customers and are working hard to provide them with the products and services they need. Along the way, the Open Source community is benefiting greatly.
It should be bringing nuclear wessels. With the cost of oil to fire a ship being what it is, the Savannah would have been competitive back in the 70's. The only problem to solve is that high seas piracy still exists and the US government doesn't want the nebulous "bad guys" to steal a nuclear wessel and reuse its atomic fuel for something nasty.
There was a video game called Rocket Ranger back in the 80's that used this device called a "Secret Decoder Wheel" to compute the fuel necessary to go from destination to destination. In fact, you had no way of punching in where you wanted to go. You only entered the fuel amounts.
Of course, the "Secret Decoder Wheel" was really a fancy lookup table, so it's wasn't too difficult for determined pirates to defeat this protection. But it was something in the vein you're thinking of.
Generated Javascript from the GWT compiler is on average much faster than hand written JavaScript. Unless you want to make your JavaScript source unmaintainable, compiled code is always faster.
This is incorrect for the same reason that GWT code is larger than its pure Javascript brethren. For every cycle you save in GWT's compiler, you spend two more on being constrained by Java's class model. Javascript is a LISP-style language. Heavily dependent on concepts like loose object definitions and lambda code. (These's features are one of the reasons why LISP is easily one of the fastest languages in existence.) Jumping through the Java hoops only ensures that you will have more code than necessary, have to perform more operations than necessary, and will generally waste a lot of cycles that could have been eliminated in pure Javascript.
Meaning, if you use one layout GWT ensures it looks the same in every browser.
If only that were true. Try loading GWT in Opera sometime and see how well it works. What's that? You wanted to target devices like smartphones and game consoles? So sorry. No can do.
Hash file names are brilliant. If you understand how HTTP caching works you'll realize this is an automatic versioning system.
I understand quite a bit about HTTP caching. And having to include the com.whatever.MyClass.nocache.js ensures that older versions of IE will always need their cache cleared before the new component will be available. So you'll forgive me if I'm not impressed.
GWT does not compile in it's libraries each time. In fact, the compiler does excellent dead code elimination with incredible detail. It only includes the code you use.
That's nice. You still have the most of the widget library, JSON library, networking library, and a few other libraries in nearly every component. They're recompiled into your code every time, ad nauseum. This creates an incredible amount of bloat that would be avoided in pure Javascript by separating libraries out into their own, reusable files. Even Google knows this.
On top of all this when the browser downloads the app it only downloads code for that browser (no IE specific code if you're using FF), which further reduces size.
IE-specific code should always be kept to a minimum. In my projects, that comes down to conditionally including runtime patches to IE's object model. So I guess you could say that I'm one step ahead of GWT.;-)
Try doing this with other bloated javascript libraries (which the frameworks themselves are substantially larger than a GWT app).
You're assuming that most of these libraries are good examples. As it so happens, most common Javascript libs are universally bad. I generally try to avoid them like the plague as they are bad enough to make GWT look like an amazing solution.
GWT is not an amazing solution. It's a decent solution that does a fairly good job for those unfamiliar with Javascript technology. But if you actually know Javascript well, you WILL be regularly frustrated by it.
For the record, I need to stop replying to anonymous cowards. They never know what they're talking about.:-/
Combine that with setting the compiler to output full names, rather than compressed ones helps.
That would help immensely. I have not found such an option, though. (And we've been looking for it!) How do you enable full symbols?
Styling of widgets appropriately comes with practice. You learn where you need to call.setStyleName/.addStyleName pretty quickly, and using things like firebug to experiment with CSS options makes it no more difficult than anything else.
My point was not that it can't be done, only that it is clunky. Invariably I have to rework my use of the widgets several times before I find a layout that I can style appropriately. This is less of an issue when you're building a desktop-replacement app, but it can be a bit figidty when you're trying to integrate GWT into an existing webpage layout. What's really interesting in my case is that our art department gives us mockup HTML so that we know the layout is feasible. Unfortunately, GWT has its own ideas about how components should be laid out, thus creating the wrestling match.
Hashed filenames are used to prevent browser caching issues.
Except they don't work. It is not feasible in many cases to configure the server not to cache the *.nocache.js. If it was a dynamic file it would be easier, but it's not. So the first step in testing a new compile in IE is... clear your cache.:-/
You don't need an ANT plugin.
Your solution is workable, but easy to break. Path issues cause enough headaches to where it has yet to be economical to switch over to GWT compiles for builds. Of course, our current situation is slightly complicated by a predecessor who configured quite a few projects without ANT. This does make converting more difficult than starting from scratch.:-)
If, instead, you mean that it doesn't load on demand, or separate them into files, or whatever...you (as a browser user) don't want that, it'll increase load time by causing more HTTP requests.
Not really. If you're using modular Javascript, it will be cached once and then reused after that. If I have 3 GWT components on my site, the AJAX, JSON, and GUI libraries are getting loaded three times over. If I have 3 Javascript-based components, the AJAX, JSON, and GUI libraries are loaded once, then reused by each component.
Speaking of JSON, I distinctly dislike the way it's handled in GWT. One of the reasons why JSON is so great is that I have a simple Javascript Object once the JSON is parsed. In GWT I have to jump through an incredible number of hoops to retrieve the simplest value. e.g.:
parsed.get("myvalue").isString().stringValue();
Ouch.
I just wrote the application to be flexible on its own. Load a different application model to have it do different things within one runtime. But, that is the way most regular java apps work anyway, until you get in to dependency injection and similar techniques.
That's not really true. The MVC model of Swing is highly customizable, and SPIs make Java APIs extremely pluggable. Even if it was true that Java code is not highly pluggable, pluggability would still be the Javascript way. It's incredibly frustrating that I have to make a super-project that contains all possible variations of the component, plus code to configure all those possible variations. I'd much rather be able to take well-testing components, generically slap them together, and have a working component emerge.
For example, let's say I've got a feature-rich component that displays records returned from the server. I originally write it to handle JSON data. Now let's say my company has a legacy XML stream they want to use the component with. I need to add XML as a feature to the component rather than writing a new data model that you would include
Pros: GWT is very cool in that you can quickly write Java-based interfaces that run in the web browser as Javascript. Because GWT includes a wide variety of components, interfaces are super-simple to create. You can even make your own widgets and reuse them as libraries to make even more complex widgets.
Cons: (Better grab a seat.) It's nearly impossible to debug code outside of the GWT test shell. Which really sucks if your code relies on a web application in some way, but you can't decipher "Error in line 127: b is null". Which brings me to the next major problem. GWT does not integrate with Javascript very well. You can use a JNI-style interface to run bits of Javascript code in a Java method, but for the most part the worlds stay far apart. Which means that you can't easily use GWT objects or Javascript objects interchangeably to solve problems. More often than not, a Javascript object would be faster than the Java code you're writing. But since you can't intertwine them...
Which brings me to the next con. Because the layout is determined by the construction of the built-in widgets, it's often difficult to achieve a layout that meets the specs. Doing simple things like removing spaces from tables, or applying pre-existing styles invariably end up more difficult to do than they should be. And even when you can apply a style, it applies the style to an element which is inside a container element (or vice-versa), thus preventing you from styling the layout of the specific element you're trying to target.
Another frustrating aspect is that GWT dumps out hashed file names. Different hashes for every compile, too. Which wreaks all kinds of havoc with source control systems. Ideally you'll want to generate the Javascript code at compile-time because of this mis-feature. Unfortunately, GWT does not ship with an ANT plugin. You can find a few that people have made, but I haven't yet found one that's of particularly high quality.
Generated GWT code is obviously quite large. Whatever you save with GWT's obfuscator is more than made up for by the fact that GWT compiles in its libraries every time.
Last but not least (and quite possibly the most frustratingly), you can only plug the components together at compile time. Mixing and matching renderers, data models, and I/O backends at runtime is pretty much a no-no. You get it right when you compile it. Period. Which really reduces the flexibility of the technology. Instead of being able to combine plugins at runtime, you have to create a new project for every variation of the component. Alternatively, you can write your code to have a half-billion runtime settings.
--
If you want my advice, learn Javascript. GWT may provide you with a good stop-gap solution, but the trade-offs can be incredibly painful at times. And since Javascript is obviously not going anywhere, you know you'll get a good return on investing in the education. If you need a good place to start, Douglas Crockford has an excellent introduction to the language here. Also, trying READING the Javascript Client Guide. It really does explain the language well, including some of its incredibly advanced features. (That 95% of so-called JS coders have no idea exist.):-)
Most people see a funny video of a cat flushing a toilet. I see an action that suggests higher than average intelligence. Did anyone instruct the cat to flush the toilet? Probably not. In fact, its actions suggested curiosity. Which suggests that it learned the task by watching its owners use the device.
This is a form of emergent behavior that is not present in computer programs. Even the best AI has difficulty emerging new abilities and demonstrating independent thinking. Sure, I can stick a genetic algorithm or a Bayesian filter on a problem, but it will never demonstrate behaviors above and beyond the problem space it's given. These sorts of algorithms may be a key piece of artificial intelligence, but we're still missing the secret ingredient that gives animals their own identity and ability to adapt and learn.
Turing gave us the litmus test decades ago. While the full Turing Test may be far beyond us right now, it at least teaches us the types of behaviors we're looking for when attempting to create an intelligent machine. When even the creators of the machine are surprised by certain behaviors, THEN we will be getting close.:-)
The link in the article appears to be protected against offsite linking. If you want to view its contents, make sure you open it in a new window. If the site detects Slashdot, you will be redirected to the sitemap.
That being said, I'm not sure if it's worth bothering. The photo is a sneaky shot of a component of the airframe. Specifically the nose-cone and forward portion of the craft. It's gray in color. Really, if you've seen an airplane before, you'll be just about as impressed.
So unless you're a competitor looking to derive secrets about SpaceShipTwo's construction, just move along. There's nothing to see here.
The graphics rendering pipeline was based on licensed code from Kodak. The sound support was based on a licensed copy of Dolby Headspace. Headspace is actually far more capable than the Java API exposes. There was a bit of a push to expose that functionality, but Sun didn't want to go that direction for fear of compromising the possibility of independent Java implementations. Seems that was a wise decision.;-)
Slashdot Mirror
That's news to me! Last I heard, the concern was that there was practically no nitrates on Mars. Your information completes the picture. We have pretty much all the necessary base elements necessary to survive on Mars. With the right engineering to solve the industrial issue, we are getting close to knowing everything we need to know to colonize!
Secondly, the ATM cannot verify the data by itself. That isn't its job. If it was, I could put a forged card in the machine that checks out and get money from the machine. Instead, ATMs talk to secure banking servers that verify the information and process the transaction. The ATM is merely a front-end to that transaction and provides the money on behalf of the bank. (Whichever bank that might be.)
In result, ATMs line up with the authentication required by a VPN fairly well. The information going over the wire could be compromised. So how do we prevent compromises? An RSA token is a good solution. Both your bank and your card share a secret. (i.e. A seed for a psuedo-random number generator.) By communicating non-reversible information that is hashed against a changing value (in this case: time), security is greatly increased. Thus I definitely think that smartcards are a good solution.
The only part that sucks is that it would take a while to get the current magstrip infrastructure converted over to a smartcard infrastructure.
i.e. We're still missing the magic ingredient: Nitrogen. Getting a sufficient quantity of nitrates to Mars might end up being the biggest problem with colonization efforts in the future. We obviously have water. CO2 can be reprocessed into O2.
The soil is not toxic. Now all we need is Nitrogen and a good method of bootstraping industrial production on Mars. (Shipping heavier technology would be impractical.)
No, no you don't. Not if you build it into the ATM card. Smartcards exist for that very reason.
Putting aside for a moment that such a tactic would be inconvenient and would lead to a large number of fobs on your keychain, it wouldn't add any real-world security to the process. Instead of one physical item, you'd need two physical items. Most people would find some clever way of keeping the two items together, thus defeating your attempt at increased security.
Putting the RSA auth into the card gives you secure two-factor authentication: Account #+RSA+PIN. The account number is analogous to a username in this case. The RSA token (something you have) thus works in concert with a standard PIN (something you know) thus providing strong security.
The problem in the article was that the cards were easy to defeat because the PIN and card number can easily be captured and reproduced. Thus just account and PIN (i.e. user/pass) are insufficient. The RSA token secures that further by demonstrating a shared secret without divulging the secret to any party who was not already aware of it.
Now that you mention it, that's not a bad idea...
No need for a dongle. Just build it into the ATM card. That way the machine could authorize no more than one transaction every minute. (One transaction per token generated.) If bad guys got hold of your account number, they'd still need to physical card to crack the PIN. It might be slightly annoying that multiple transactions at an ATM would take a little longer, but the vast majority of people would never notice.
That being said, if it WAS Citibank's servers that were compromised, these guys would have been able to heist the shared secret as well. Then they'd be able to reproduce the RSA token in your card. According to Citibank, however, their servers were not compromised. They claim that a third party clearing service was responsible for the leak. (Who knows?)
Speaking of which, it would have been nice if Tolkien had come up with more unique names for his characters. It gets really confusing after a while, especially when the names are spoken aloud.
In any case, I still maintain that The Hobbit was better. It was a whimsical adventure that was a joy to read. LoTR was a story of ever-dwindling hope and despair, drawn out into three books. Tolkien may claim that WWII was not the subject of his books, but the stress of the war definitely came through in his writing.
* I have read LoTR but I couldn't answer that. Nor do I really care that much.
P.S. They're GOBLINS, not Orcs.
I hope that you also realize that modern coal mining has nothing to do with the hard, labor intensive work of yore. Coal mining these days is mostly about proper operation of machinery to slice off sheets of rock, process them, and then transport them to the surface for shipping. Companies wouldn't hire kids for the job even if they could. Kids would be far too likely to make a major mistake and put the company's investment at risk. (Not to mention lives. Contrary to popular belief, not ALL mines were run by greedy, heartless murderers.)
If you are ever in the Chicago area, I highly recommend visiting the Museum of Science and Industry. They have an old coal mine there that they give tours of. They show both antique and modern methods of mining for coal, including the problems that regularly occurred before the advent of modern methods. You can even see the areas that had previously been dug out by both methods.
A ring that makes me invisible when I wear it. Obviously.
(We need fewer people reading Lord of the Rings, and more people reading The Hobbit. The latter is WAAAAY better.)
Fish. Now my turn:
What's in my pocket? :-P
That's assuming that the purpose of the right to bear arms was intended to support a militia. That seems rather silly as a militia would be granted special privileges while serving in the militia. Much in the same way a soldier in the modern army can carry a fully automatic assault rifle, or a rocket launcher, or operate a tank firing DU rounds. You and I really can't do any of those things, despite our right to carry arms.
The forefathers made it clear in their writings that the people must police their own country and start a revolution if the power of government became oppressive. It was their hope that such constant threat would keep the government in line and abiding by its own rules. Some argue that with the modern military under the control of the President, it wouldn't be much of a fight to crush a rebellion. In my opinion, that actually calls for a relaxation of current gun control provisions. Realistically, though, there are enough military weapons and personnel loyal stationed in each state to where a revolution would be able to seize enough equipment to put up a serious fight.
We actually saw this in the civil war. The south was able to seize quite a bit of equipment and manpower to give the north a run for its money. (Need I remind everyone how the battle of the Merrimac and Monitor went after the capture of Norfolk?) What defeated the south was that their cause was not going to gain much sympathy from the rest of the nation. Thus the north was willing to fight a horrible battle of brother against brother to ensure the unity of state. Let's hope that any future revolutions would happen for the purpose of saving human rights rather than oppressing them.
The first thing I thought of wasn't music, though that's a very good point. I was thinking "in-car speakerphone" and "Skype". But maybe I'm just weird that way.
(And apparently quite goofy, considering I barely talk on my cell phone. Especially when in the car.) :-P
I disagree. One of the key reasons why I like reading eBooks is that I DON'T have to flip pages. I can use a scroll wheel or a button to flip, instead. I've found that it's many times more comfortable than holding a paperback in the center, then having to move my thumb and other arm to manage a page flip.
The reason why paper has defeated eBooks to date is because you don't have to invest in a $$$ reader ahead of time and the paper is of a much higher resolution than an eBook reader. (1200dpi prints put eBook readers to shame.) Not in a million years would I have thought that the lack of "page flipping" was a significant barrier to eBook adoption. In fact, adding page flipping would probably become an ADDITIONAL barrier to eBooks as users would be unfamiliar with how to operate the electronic device.
I don't have the energy to go through this all over again, so I'll punt to the experts:
http://goliath.ecnext.com/coms2/gi_0199-6700447/Scrubbing-dirty-bombs-explosive-hype.html
http://www.news.uiuc.edu/gentips/02/07dirtybomb.html
http://www.notposta.com/?p=19
http://www.onthemedia.org/yore/transcripts/transcripts_072503_fear.html
Long story short: Dirty bombs don't work. It's not nearly as easy to distribute radioactive materials as the media would have you believe.
Explains a lot, doesn't it?
Dirty bombs are scare tactics. They don't actually work.
A "small bomb" on the reactor would have a "small effect". Nuclear reactors are not bombs. They will not blow up like nukes when damaged. The most likely result of a "small bomb" would be a lot of damage to the ship, but very little to the reactor's containment vessel. (Easily 90% or more of a reactor's weight is heavy shielding.) The absolute worst case scenario is that the reactor goes prompt critical, and the nuclear materials sink to the bottom of the harbor. (Where they will actually be fairly well shielded against by the water.) Perhaps you might even have a boiler explosion to go with the situation.
Any way you cut it, a reactor is not a weapon. The materials inside the reactor can be used to devise a weapon with some reprocessing, which is why they must be protected. But the ships themselves would pose no danger. So please tone down the FUD machine.
Not really sure what you mean here. I was rather surprised when I decided to do some Solaris development that the primary focus has moved from Solaris/SPARC to Solaris/x86. Half the cool stuff in OpenSolaris is designed around the x86 platform.
Similarly, the primary focus of the Java codebase is the x86 platform first, remaining platforms later.
Sun is also a massive seller of AMD64 and Intel Xeon based servers and workstations. Amazingly, Sun's prices have even come out of the stratosphere and are extremely competitive with other manufacturers like Dell.
Sun is even working to virtualize these "commodity platforms" with their surprisingly good OpenxVM project. I actually passed on a free copy of Parallels because Sun's VirtualBox was working so well for me.
I know Sun has the stigma of selling only overpriced iron, but the truth is that they're fairly well in tune with their customers and are working hard to provide them with the products and services they need. Along the way, the Open Source community is benefiting greatly.
It should be bringing nuclear wessels. With the cost of oil to fire a ship being what it is, the Savannah would have been competitive back in the 70's. The only problem to solve is that high seas piracy still exists and the US government doesn't want the nebulous "bad guys" to steal a nuclear wessel and reuse its atomic fuel for something nasty.
There was a video game called Rocket Ranger back in the 80's that used this device called a "Secret Decoder Wheel" to compute the fuel necessary to go from destination to destination. In fact, you had no way of punching in where you wanted to go. You only entered the fuel amounts.
Of course, the "Secret Decoder Wheel" was really a fancy lookup table, so it's wasn't too difficult for determined pirates to defeat this protection. But it was something in the vein you're thinking of.
The game can now be (legally!) downloaded for free at Cinemaware's website: http://www.cinemaware.com/clsgame_rr.asp
They even throw in a virtual decoder wheel. :-)
This is incorrect for the same reason that GWT code is larger than its pure Javascript brethren. For every cycle you save in GWT's compiler, you spend two more on being constrained by Java's class model. Javascript is a LISP-style language. Heavily dependent on concepts like loose object definitions and lambda code. (These's features are one of the reasons why LISP is easily one of the fastest languages in existence.) Jumping through the Java hoops only ensures that you will have more code than necessary, have to perform more operations than necessary, and will generally waste a lot of cycles that could have been eliminated in pure Javascript.
If only that were true. Try loading GWT in Opera sometime and see how well it works. What's that? You wanted to target devices like smartphones and game consoles? So sorry. No can do.
I understand quite a bit about HTTP caching. And having to include the com.whatever.MyClass.nocache.js ensures that older versions of IE will always need their cache cleared before the new component will be available. So you'll forgive me if I'm not impressed.
That's nice. You still have the most of the widget library, JSON library, networking library, and a few other libraries in nearly every component. They're recompiled into your code every time, ad nauseum. This creates an incredible amount of bloat that would be avoided in pure Javascript by separating libraries out into their own, reusable files. Even Google knows this.
IE-specific code should always be kept to a minimum. In my projects, that comes down to conditionally including runtime patches to IE's object model. So I guess you could say that I'm one step ahead of GWT.
You're assuming that most of these libraries are good examples. As it so happens, most common Javascript libs are universally bad. I generally try to avoid them like the plague as they are bad enough to make GWT look like an amazing solution.
GWT is not an amazing solution. It's a decent solution that does a fairly good job for those unfamiliar with Javascript technology. But if you actually know Javascript well, you WILL be regularly frustrated by it.
For the record, I need to stop replying to anonymous cowards. They never know what they're talking about. :-/
That would help immensely. I have not found such an option, though. (And we've been looking for it!) How do you enable full symbols?
My point was not that it can't be done, only that it is clunky. Invariably I have to rework my use of the widgets several times before I find a layout that I can style appropriately. This is less of an issue when you're building a desktop-replacement app, but it can be a bit figidty when you're trying to integrate GWT into an existing webpage layout. What's really interesting in my case is that our art department gives us mockup HTML so that we know the layout is feasible. Unfortunately, GWT has its own ideas about how components should be laid out, thus creating the wrestling match.
Except they don't work. It is not feasible in many cases to configure the server not to cache the *.nocache.js. If it was a dynamic file it would be easier, but it's not. So the first step in testing a new compile in IE is... clear your cache. :-/
Your solution is workable, but easy to break. Path issues cause enough headaches to where it has yet to be economical to switch over to GWT compiles for builds. Of course, our current situation is slightly complicated by a predecessor who configured quite a few projects without ANT. This does make converting more difficult than starting from scratch. :-)
Not really. If you're using modular Javascript, it will be cached once and then reused after that. If I have 3 GWT components on my site, the AJAX, JSON, and GUI libraries are getting loaded three times over. If I have 3 Javascript-based components, the AJAX, JSON, and GUI libraries are loaded once, then reused by each component.
Speaking of JSON, I distinctly dislike the way it's handled in GWT. One of the reasons why JSON is so great is that I have a simple Javascript Object once the JSON is parsed. In GWT I have to jump through an incredible number of hoops to retrieve the simplest value. e.g.:
Ouch.
That's not really true. The MVC model of Swing is highly customizable, and SPIs make Java APIs extremely pluggable. Even if it was true that Java code is not highly pluggable, pluggability would still be the Javascript way. It's incredibly frustrating that I have to make a super-project that contains all possible variations of the component, plus code to configure all those possible variations. I'd much rather be able to take well-testing components, generically slap them together, and have a working component emerge.
For example, let's say I've got a feature-rich component that displays records returned from the server. I originally write it to handle JSON data. Now let's say my company has a legacy XML stream they want to use the component with. I need to add XML as a feature to the component rather than writing a new data model that you would include
I've used GWT. Here's the long and short of it...
Pros: GWT is very cool in that you can quickly write Java-based interfaces that run in the web browser as Javascript. Because GWT includes a wide variety of components, interfaces are super-simple to create. You can even make your own widgets and reuse them as libraries to make even more complex widgets.
Cons: (Better grab a seat.) It's nearly impossible to debug code outside of the GWT test shell. Which really sucks if your code relies on a web application in some way, but you can't decipher "Error in line 127: b is null". Which brings me to the next major problem. GWT does not integrate with Javascript very well. You can use a JNI-style interface to run bits of Javascript code in a Java method, but for the most part the worlds stay far apart. Which means that you can't easily use GWT objects or Javascript objects interchangeably to solve problems. More often than not, a Javascript object would be faster than the Java code you're writing. But since you can't intertwine them...
Which brings me to the next con. Because the layout is determined by the construction of the built-in widgets, it's often difficult to achieve a layout that meets the specs. Doing simple things like removing spaces from tables, or applying pre-existing styles invariably end up more difficult to do than they should be. And even when you can apply a style, it applies the style to an element which is inside a container element (or vice-versa), thus preventing you from styling the layout of the specific element you're trying to target.
Another frustrating aspect is that GWT dumps out hashed file names. Different hashes for every compile, too. Which wreaks all kinds of havoc with source control systems. Ideally you'll want to generate the Javascript code at compile-time because of this mis-feature. Unfortunately, GWT does not ship with an ANT plugin. You can find a few that people have made, but I haven't yet found one that's of particularly high quality.
Generated GWT code is obviously quite large. Whatever you save with GWT's obfuscator is more than made up for by the fact that GWT compiles in its libraries every time.
Last but not least (and quite possibly the most frustratingly), you can only plug the components together at compile time. Mixing and matching renderers, data models, and I/O backends at runtime is pretty much a no-no. You get it right when you compile it. Period. Which really reduces the flexibility of the technology. Instead of being able to combine plugins at runtime, you have to create a new project for every variation of the component. Alternatively, you can write your code to have a half-billion runtime settings.
--
If you want my advice, learn Javascript. GWT may provide you with a good stop-gap solution, but the trade-offs can be incredibly painful at times. And since Javascript is obviously not going anywhere, you know you'll get a good return on investing in the education. If you need a good place to start, Douglas Crockford has an excellent introduction to the language here. Also, trying READING the Javascript Client Guide. It really does explain the language well, including some of its incredibly advanced features. (That 95% of so-called JS coders have no idea exist.) :-)
I don't think you quite follow how this works. Go watch this video:
http://www.youtube.com/watch?v=D9D_HN9gXVI
What do you see?
Most people see a funny video of a cat flushing a toilet. I see an action that suggests higher than average intelligence. Did anyone instruct the cat to flush the toilet? Probably not. In fact, its actions suggested curiosity. Which suggests that it learned the task by watching its owners use the device.
This is a form of emergent behavior that is not present in computer programs. Even the best AI has difficulty emerging new abilities and demonstrating independent thinking. Sure, I can stick a genetic algorithm or a Bayesian filter on a problem, but it will never demonstrate behaviors above and beyond the problem space it's given. These sorts of algorithms may be a key piece of artificial intelligence, but we're still missing the secret ingredient that gives animals their own identity and ability to adapt and learn.
Turing gave us the litmus test decades ago. While the full Turing Test may be far beyond us right now, it at least teaches us the types of behaviors we're looking for when attempting to create an intelligent machine. When even the creators of the machine are surprised by certain behaviors, THEN we will be getting close. :-)
The link in the article appears to be protected against offsite linking. If you want to view its contents, make sure you open it in a new window. If the site detects Slashdot, you will be redirected to the sitemap.
That being said, I'm not sure if it's worth bothering. The photo is a sneaky shot of a component of the airframe. Specifically the nose-cone and forward portion of the craft. It's gray in color. Really, if you've seen an airplane before, you'll be just about as impressed.
So unless you're a competitor looking to derive secrets about SpaceShipTwo's construction, just move along. There's nothing to see here.
The graphics rendering pipeline was based on licensed code from Kodak. The sound support was based on a licensed copy of Dolby Headspace. Headspace is actually far more capable than the Java API exposes. There was a bit of a push to expose that functionality, but Sun didn't want to go that direction for fear of compromising the possibility of independent Java implementations. Seems that was a wise decision.