It doesn't take a rocket scientist to build countermeasures. Effective countermeasures can be cheap and use simple technology--much simpler than the technology required to build long-range missiles.
This is something of an understatement. A while back I scanned an article in an IEEE Spectrum on the subject (anyone have a reference?). They cited a study where university graduates (i.e. no special training or experience) were tasked to develop countermeasures. They were given only publically available documentation (i.e. no specs, just textbooks and published papers) and were restricted to off-the-shelf components.
Needless to say the results were a rude awakening for defense officials. The suggested countermeasures could easily overwhelm current (and proposed) ABM systems. The only non-trivial cost to the missile designers would be a slight reduction in payload.
Makes you wonder why they're bothering to throw so much money at this problem when a handful of clever co-op students with a catalog could get probably defeat it.
> If sites had to rely on promoting their IP addresses rather than their domain name...
This isn't the answer. All other reasons aside, it just doesn't scale. Consider what will happen when IPv6/IPng (eventually) arrives.
Sure, I can probably remember 209.207.224.40 long enough to write it down. It even fits on a business card. Once we get 128-bit IP address, we get nastiness like
Is this going to fit on your business card? Hell, will it even fit on a TV screen? It would probably take the length of a standard TV commercial just to write/type it.
DNS clearly isn't the right answer, but we need something to do the job it was originally intended for.
...have you ever noticed how often Microsoft takes a good idea and does the wrong thing with it?
As a multiplatform developer, I understand the value of a useful, portable class library. On the other hand, though, it has also made me appreciate the extra cost that it can add - especially when you're only targeting a single platform.
If I want to write a Windows-only app (say what you will, but that's what most users want) what do I use? I have no interest in writing in (ugh!) C++. AWT is useless. Swing has most of the functionality, but at a terrible performance hit. User-draw widgets are slower, don't always have the expected behavior, and aren't forward compatible. (Luke, use the native widgets Luke.)
If MS had released a library of windows-specific Java libraries (com.ms.whatever) with JNI compliant natives, then Joe-the-Java-developer could write code to fully leverage windows functionality and look-and-feel. Some clever hacker could have even taken a subset of the native methods and written implementations for [insert your favorite GUI toolkit].
Instead, they use the idea to try and crush the competition by corrupting or stealing the language. *SIGH*
There is a parallel tech preview for VA Java for Java2 (windows only). I haven't looked at it, but it's likely what you're looking for -- or will be once it's "real".
In the mean time...you might be able to trim the bloat by deleting/not importing the swing look-and-feel classes you don't care about (i.e. punt everything but "basic"). No idea if this'll actually work, but it should significantly drop the number of classes.
This release was prompted by a large user demand. A similar outcry for VASmalltalk for Linux might have a similar effect. As someone mentioned already, VAJ/Linux implies that some/all of VAST already runs on Linux.
As an added bonus, this might remind IBM that the Smalltalk community hasn't died.
This is something of an understatement. A while back I scanned an article in an IEEE Spectrum on the subject (anyone have a reference?). They cited a study where university graduates (i.e. no special training or experience) were tasked to develop countermeasures. They were given only publically available documentation (i.e. no specs, just textbooks and published papers) and were restricted to off-the-shelf components.
Needless to say the results were a rude awakening for defense officials. The suggested countermeasures could easily overwhelm current (and proposed) ABM systems. The only non-trivial cost to the missile designers would be a slight reduction in payload.
Makes you wonder why they're bothering to throw so much money at this problem when a handful of clever co-op students with a catalog could get probably defeat it.
>It struck me that www.h2g2.com is basically everything.blockstackers.com
Good point. We've already got Everything. All we need now is Life.blockstackers.com
and TheUniverse.blockstackers.com and we'll be set.
>Corel is a small, struggling company...
Clearly the largest software company in Canada isn't big enough for you.
But then again, up north here in Canada companies are, by necessity, pretty small...at least until we perfect the multi-storey igloo.
This isn't the answer. All other reasons aside, it just doesn't scale. Consider what will happen when IPv6/IPng (eventually) arrives.
Sure, I can probably remember 209.207.224.40 long enough to write it down. It even fits on a business card. Once we get 128-bit IP address, we get nastiness like
http://31.41.59.26.53.58.97.93.23.84.62.64.33.83.2 7.95/coolNewProduct.html
Is this going to fit on your business card? Hell, will it even fit on a TV screen? It would probably take the length of a standard TV commercial just to write/type it.
DNS clearly isn't the right answer, but we need something to do the job it was originally intended for.
...have you ever noticed how often Microsoft takes a good idea and does the wrong thing with it?
As a multiplatform developer, I understand the value of a useful, portable class library. On the other hand, though, it has also made me appreciate the extra cost that it can add - especially when you're only targeting a single platform.
If I want to write a Windows-only app (say what you will, but that's what most users want) what do I use? I have no interest in writing in (ugh!) C++. AWT is useless. Swing has most of the functionality, but at a terrible performance hit. User-draw widgets are slower, don't always have the expected behavior, and aren't forward compatible. (Luke, use the native widgets Luke.)
If MS had released a library of windows-specific Java libraries (com.ms.whatever) with JNI compliant natives, then Joe-the-Java-developer could write code to fully leverage windows functionality and look-and-feel. Some clever hacker could have even taken a subset of the native methods and written implementations for [insert your favorite GUI toolkit].
Instead, they use the idea to try and crush the competition by corrupting or stealing the language.
*SIGH*
http://www.software.ibm.co m/ad/r/99enews7/java2-preview/
In the mean time...you might be able to trim the bloat by deleting/not importing the swing look-and-feel classes you don't care about (i.e. punt everything but "basic"). No idea if this'll actually work, but it should significantly drop the number of classes.
Why don't you ask for it?
This release was prompted by a large user demand. A similar outcry for VASmalltalk for Linux might have a similar effect. As someone mentioned already, VAJ/Linux implies that some/all of VAST already runs on Linux.
As an added bonus, this might remind IBM that the Smalltalk community hasn't died.