The Linux community is held hostage by Netscape and their implementation (until Mozilla and OJI frees them) It's not very scientific to have a single datapoint, Netscape's Java implementation, and therefore conclude, Java sucks.
Netscape 4 sucks speedwise, and stability wise. It has resource leaks, segfaults, and its Java VM doesn't even have a JIT. Java on Windows, Solaris, HP-UX, OS/2, and AIX runs very nicely. Only Swing is still a little slow, and even that is wholly dependendant on how you use it. (evidence: jEdit vs JEditorPane)
Try running the applet under IBM JDK1.1.8 appletviewer on Linux, it's about 30-50 times faster than the VM in Netscape and much more resource efficient.
Now try writing a PDP-1 emulator in pure PERL and let's see how fast it runs.
I've been coding Perl since 1991 and Java since 1993, and have mucho experiencing optimizing both Perl and Java code. All the anti-Java bashing that goes on here is pure FUD. You have clueless idiots bashing bytecode interpretation, and then cheerfully boost Perl, Python, PHP, TCL, etc, claiming that parse tree evaluation will be faster than optimized bytecode/JIT, and bashing Java's thread model (when in fact, the fault lies in Linux's poor threading model compared to Solaris, OS/2, BeOS, or NT)
There are plenty of benchmarks out there now showing Java JIT's being within a fact of 50-80% of C on execution speed. Volano Report shows that some VMs/OSes can scale to thousands of simultanaeous threads (4000+). I personally ported a mini-raytracer to Java from C and only lost about 20% execution speed.
No doubt, Java GUI components still need more optimization. But on the other hand, the lack of a Microsoft Office competitor written in Java is not evidence. The desktop app markup is pretty locked up right now, most companies are developing Web/HTML versions of tradition apps like email/address book/form processing/hr/billing/info mgmt/etc, so the fact of the matter is, the number of "desktop apps" being written in C/C++ is also on the way down. (why waste time doing C++ Forms Database, when you can develop much quicker by using HTML and a scripting language?)
Marc Stiegler is asking you to imagine a world of stronger cryptographic mechanisms. Digital certificates, secure communication, secure electronic cash and digital contracts. All things that anyone reading Bruce Schneider would want.
Marc also tries to imagine how lots of mass-produced, small, cheap, computing devices would alter the nature of freedom.
Instead, we get of "answers" that simply ignore the whole spirit of the question, which is imagine a world that has a more secure network infrastructure.
Why even bother with "Ask Slashdot" when the aggregate intelligence level of the readership here has been demonstrated to be slightly above 14 year old teens with a hyperactivity disorder, and a profoundly warped view of their importance in the world?
I would ask Marc Stielger to imagine a world where the Zetetic Institution of David's Sling really exists, and where people are cured of irrationality and knee-jerk opinions.
Sun already licenses SPARC, motherboards, and just about all their other technology. You can go out and buy third party Sun clones right now and they are significantly cheaper. I bought one myself.
Why isn't there more "software" for Solaris (apart from the 15,000 apps already available?) Because Solaris is a server OS, not a consumer OS, that's why.
Whether it is Java, or building "GCC" into the kernel loader so that you can execute a tarball file (and have it compiled on the fly and cached), we need binary independence.
Now, it's temping to say "just compile the source", but if the source is a 20 megabyte monster like Mozilla that takes a loooong time to compile, you have an end-user problem.
The future is going to be awash in processors of all kinds, and we need a way of porting binaries across CPUs. If we don't, we won't have competition in the CPU market anymore, and one architecture will dominate, just like the Windows API dominates.
Also, once you get to IA-64 like devices, code will have to be recompiled for each new generation of IA-64 depending on how many execution units it has. If one generation can do 4-way execution, and the next can do 8-way, a JIT compiler is needed if the code is to be optimal for each CPU.
One approach would be to simply take the middle-layer output of a compiler like GCC, write it out in a byte code format, and then have operating systems backend-compile peephole-optimize this code when loading it.
Whatever mechanism used, JIT compilation (it's not just Java) has several benefits:
1) binary independence, register independence
2) can perform optimizations that even C/C++ can't. C's linker can't inline polymorphic or indirect function calls. A JIT compiler could actually inline calls from a shared library that isn't known until runtime. If this library is OpenGL or GTK, rendering may get a huge improvement.
3) can adjust code and data locality depending on the size/capability of the CPU's cache
4) security. Depending on the mechanism used, can be used to "sandbox" code.
Try not to focus too much on the "interpreted" aspect of bytecode. Instead, just think of bytecode as simply a compressed version of source code. For instance, Java's bytecode format is so verbose, you can pretty much decompile it back to the original source without much loss.
Java is just the first step, but in the future, when the world is filled with ubiquitous CPUs everywhere, we're going to need ways to prove assertions about untrusted code, and we're going to need ways to run it wherever you are, so you aren't tied to any one device.
Last year, I filed my taxes on WebTurboTax. This site is unbelievably great. It is just as detailed as any client-side tax preparation program, only it uses HTML, DynamicHTML, Java, and Acrobat/PDF, and works anywhere on Netscape or IE.
I used Netscape 4 and it took big advantage of layers and JavaScript for its interface.
At the end, all I did was give my CC# and I got a PDF file I could print out and send to the IRS, or, I could just do an electronic filing.
Either way, as a web developer for the last 6 years, I thought it was one of the finest pieces of server-side/client-side integration I have seen.
(Did I mention it gracefully handled Netscape crashing without losing any data, and that it handled all the funky cases of idiot users trying to bookmark, or reload POST CGIs, etc)
For small companies, outsourcing to an ASP rocks. No one in a small startup wants to handle the ugly details of HR, Payroll, accounting, etc.
JPython is written in Java and runs faster in benchmarks than CPython when using the HotSpot JIT. Smalltalk, for a long time, was the king of slowness.
Perhaps you are unaware of the difficultly of efficiently compiling fully dynamic weakly typed languages like Smalltalk, or Perl5?
If Perl5 sees a bunch of expressions, it has no idea until runtime if $x is a string, floating point, reference, or integer variable. The situation is even worse for function calls through a blessed reference where any number of dynamic mechanisms can cause a different subroutine to be dispatched. Perl can't inline like a Java JIT can.
The only way Perl5 could possibly beat a Java JIT is if it had a Smalltalk/Hotspot style JIT compiler that did type-inferencing.
Perl excels at text manipulation and array/hashtable manipulation because those are language primitives which are handled efficiently.
There is no way Perl would beat Java at say, image processing, or ray-tracing. I've been writing Perl for 6 years, and I have written several 30,000+ line apps with it, so I know exactly how it performs.
There is no such thing as one benchmark that decides performance for all languages. Perl will blow away just about even language, even C++ in many cases (inefficient libraries) when it comes to text manipulation, regexp, array slicing, etc. But Perl won't win on any numerically or graphically intense benchmarks.
I use jEdit on JDK1.2.2 and IBM JDK 1.1.8 as my main editor, because it is much easier to extend than Emacs, and less bloated. The speed is very acceptable, some would say speedy.
Just try writing an editor in 100% Perl or Python without using *any* native components except a bitmap to draw into, and let's see how fast it is. (This is essentially what you get with Swing, since all GUI components are written in Java)
Someone already did do it, in fact, several people have.
The Beduin browser (for PersonalJava), and the ICE Browser (icesoft) are both ALOT better than HotJava.
The ICE browser even does CSS2.0, MathML, JavaScript, SMIL, and lots of other things.
Coding makes a huge difference. Remember, Mosaic sucked and was slow, and so was Netscape.
IE4/Mozilla are much better than their former C++ counterparts (IE1-3, Netscape1-4) in their rendering engine speed, and that's precisely because of the algorithms used.
Just look at jEdit (www.gjt.org), an emacs clone written in Java. It's very speedy and usable on my Celeron 300Mhz 128mb system with JDK1.2.2.
(and it probably runs much better under IBM JDK1.1.8)
Look folks, I can believe that the NSA can monitor most of the relevent international EM communications traffic via listening outposts.
I can believe that the NSA monitors international long distance phone traffic. I can even believe that the NSA monitors some internet traffic.
But the claim that they can monitor *everything* is bogus. They can't even monitor all EM frequencies or spread spectrum communications. If they could, they could do what SETI is trying to do in a heart beat. The fact is, the spectrum is too big to monitor in totality for "interesting traffic" It's much easier for them to scan frequencies in use by known equipment being bought by foreign governments.
Secondly: Monitoring *EVERY* phone call? I think not. International traffic, sure. But grepping every voice call made in the world would require such a staggering amount of bandwidth, CPU, and storage, it's a ridiculous assertion.
Even if the Baby Bells agreed to it, the monitoring equipment itself would likely degrade the performance of the carriers.
Every email? We know that's bullshit. The NSA can't monitor intranet-only email (unless they have millions of tempest outposts next to every company and ISP in the world). So they are left with the following choices: partner with AOL/Hotmail/EVERY ISP so they can grep intra-ISP mail or 2:
Somehow monitor IP traffic on everyone's network -- also bogus.
Let's posit that the NSA approached Cisco 10 years ago and had them build a special transmitter in Cisco boxes that forwards all "interesting" traffic to the NSA.
Can you imagine 1) the performance hit on Cisco routers to do this and 2) the bandwidth requirements to trasnmit this data to the NSA for analysis. Also, no geek has ever taken apart a Cisco box and detected this backdoor? No network admin has ever noticed any weird packets on his network going to a strange play? or mysterious delays?
Echelon is a very boring concept I'm afraid. I doubt it lives up to the hype. It's just one big orbital frequency scanner, and some international phone cable monitoring.
To be otherwise, the NSA would have to have its claws into *hundreds* of corporations, and have silenced all the TECHIE GEEKS working at these places who would obviously know about the monitoring. Since I personally know people who work at HUGE ISPs and run their mail/network systems, I know this isn't true.
And the NSA can't just monitor MAE-EAST/WEST, etc, because much traffic is routed through private peer networks now. For instance, Above.Net has 190+ peering arrangements and several private backbones. So now we have the NSA having to splice into and monitor hundreds of private backbone networks.
Echelon would require as fantasic a conspiracy as the UFO morons posit. Occams Razor dictates that the truth is much simpler than that.
Good ole fashion logic dictates the NSA spends more time monitoring the airwaves and international phone, than they do trying to snoop on US internet traffic, given that the vast majority of third world governments are still using primitive radio and telephone equipment.
The conclusion is that JAM Echelon Day was a ridiculous waste of time that probably had some NSA guys laughing on the floor.
And it goes back to why dynamic, typeless, languages are used.
1) Instantaneous Feedback. With Perl, you edit the "document" (script), click reload, and see the effect immediately.
With C/C++, you edit, compile, relink, maybe even "restart the server" and if it crashes, it's debugger time. C/C++ sucks as a language for doing DatabaseText transformations ala Perl, Python, TCL, and 4GLs.
2) A syntax that freely intermixes HTML and script code.
I would argue that a document that is mostly HTML, with some script fragments is far more editable and managable than a C/C++ source file that is mostly "printf" code with HTML interspersed. With some editors, you can even edit the HTML containing Perl/ASP/Cold Fusion/JSP/Python code and see it mostly visually.
3) great for DatabaseText transformations.
Perl blows away C/C++ in processing strings, slicing and dicing arrays, and doing Hashtable tricks. Anything even remotely close in C/C++ requires a third party non-standard library, and a syntax which still isn't as compact.
The vast majority of CGI apps run DB queries and convert the dataset to a text or HTML representation.
With scripting languages, it is much easier to perform the query, and write the template that dumps the output.
CGI apps are *NOT* dominated by CPU performance. The biggest bandwidth is memory and I/O. Except in rare cases, compiling a CGI won't get you as much performance as simply adding more ram, more threading, and more I/O bandwidth.
Why Perl? Should be "Why scripting" Answer? Fast, safe development, economical syntax, easy to debug, can blend with markup languages better.
Cold Fusion is yet another example of something tuned to do one thing (DB->HTML transformation).
The ability to simply "reload" to see you changes, even forced me to recode Java Servlets as JSP pages simply because my development speed was multiplied x 10.
To recap: 1) a development model that allows instanteous feedback (click reload) 2) The ability to deal with documents, and embed code, rather than the other way array. 3) superor handling of datatypes and more compact syntax.
The problem with scripting of course, is that it is brittle from a maintainance point of view. As a project gets larger, there is less code reuse, no way to verify usage of reused code (type checking), and a tendecy for developers to "cut-and-paste" code fragments in a slap-dash attempt to get something to work.
And it goes back to why dynamic, typeless, languages are used.
1) Instantaneous Feedback. With Perl, you edit the "document" (script), click reload, and see the effect immediately.
With C/C++, you edit, compile, relink, maybe even "restart the server" and if it crashes, it's debugger time. C/C++ sucks as a language for doing DatabaseText transformations ala Perl, Python, TCL, and 4GLs.
2) A syntax that freely intermixes HTML and script code.
What's better:
$firstname$lastname
or
out " " "
I would argue that a document that is mostly HTML, with some script fragments is far more editable and managable than a C++ source file that is mostly "printf" code with HTML interspersed.
3) great for DatabaseText transformations.
Perl blows away C/C++ in processing strings, slicing and dicing arrays, and doing Hashtable tricks. Anything even remotely close in C++ requires a third party non-standard library, and a syntax which still isn't as compact.
The vast majority of CGI apps run DB queries and convert the dataset to a text or HTML representation.
With scripting languages, it is much easier to perform the query, and write the template that dumps the output.
CGI apps are *NOT* dominated by CPU performance. The biggest bandwidth is memory and I/O. Except in rare cases, compiling a CGI won't get you as much performance as simply adding more ram, more threading, and more I/O bandwidth.
Why Perl? Should be "Why scripting" Answer? Fast, safe development, economical syntax, easy to debug, can blend with markup languages better.
Cold Fusion is yet another example of something tuned to do one thing (DB->HTML transformation).
The ability to simply "reload" to see you changes, even forced me to recode Java Servlets as JSP pages simply because my development speed was multiplied x 10.
This isn't consumer apps running on a portal, this is a business to business startup, and fulfills a similar function as UUNET, Exodus, or AboveNet.
In the ole days, people got their own T1 lines to their office and hosted their web sites on their own machines, had their own network admins, their own cable/hardware guys, etc.
First step: eliminate the hassle of running a T1 and maintaining your own "high availability" stuff.
Companies: Exodus, AboveNet. Gigabits of bandwidth, earthquake proof, power failure proof, fault tolerant. Pay $1800/mo and stick a few rackmounted machines there, and they do the rest. No brainer for most businesses.
Hosting servers at a professional hosting service is much better than running a T1 from your ISP. The ISP's quality of service simply can't compete.
Next step: services. Example: email. Email is a commodity. Why pay a staff $200k a year plus capital costs to host sendmail, exchange, or lotus notes on your network when you can just "outsource" it to USA.net, Mail.com, CriticalPath, for a small fee and not have to deal with the headache? There is no way your average mail admin will achieve the scalability and level of service that you will get at say, CriticalPath.
Next steps: Why go through the hassle of having to purchase your own copy of Oracle, or an Application server, and pay an Oracle DBA or CIO lots of money to maintain them, their uptime, and the quality of service?
If you have a bright idea for the Next-Big-Thing, and want to start coding immediately next week, and you can't afford to hire lots of people, why not just rent space on someone else's professionally maintained DB/Application Server/Network, etc.
By outsourcing these services, you don't need to waste time, and money, developing your own inhouse installation, and struggling to maintain the QoS that a professionally run organization has. Or for that matter, the fault-tolerance of leasing a DB/Server on an E10000!
Andressen's idea is simply to setup the DB/App server, and simply sell the right to run your servlets, CGIs, applets, etc on their servers.
I can tell you that it's a very valuable proposition to some companies. It's too distracting to have developers wasting time performing maintaince on hardware, software, network, etc.
Now, you can easily hire an inhouse admin to do it, but you still won't have the quality of running on a Sun Enterprise 10000 hosted at Exodus, with 24hr on-call staff, high security, subterranian power generators, etc Also, it takes time to hire someone and have them set it all up. With outsourcing, you make one phone call, write a check, and your developers can start coding the next day.
I think having a single (if forked) open-source implementation is inferior to having multiple implementations of a frozen, agreed upon, standard API.
For instance, I would much rather have multiple HTML browsers rather than a single FooBarML browser, even if it is open-source and "forked"
The whole Linux desktop situation would be better if the GNOME/KDE guys hashed out some standards, agreed to them, and both implemented them. XDnd is one, but almost everything else is divergent.
Protocols are more important than source. Having source to all the implementations is nice too, but if they are divergent in protocol, they add to the cost of software development.
Component based programming and standardized APIs/protocols solves most of the danger of committing to a single vendor.
For instance, for databases, we have SQL/ODBC/JDBC. For distributed programming we have CORBA/EJB. For file formats, we have XML, etc.
I'd much rather target SQL/ODBC than target "MySQL" only, even if there were 50 open-source forked implementations.
Adopt Amiga's message passing and asynchronous I/O archicture for Linux, or some variant. (also similar to NT completion ports)
Amiga's thread-based (Amiga called them processes, but they were really threads) MessagePort based I/O is lightyears easier to program and more scalable than Linux select/poll(), and POSIX AIO sucks, and SIGIO doesn't look much better.
Basically, Amiga OS is deficient in every area (device independent graphics, memory protection, virtual memory, resource tracking, etc) except the one area where a real-time OS kicks ass, which is I/O.
Under AmigaOS, you could send off requests for thousands of different I/O requests and have buffers filled in by device drivers, and then notify the threads that new data is available.
Almost zero-context switch overhead, no "copying" between kernel/user (device drivers would actually DMA data directly into your memory buffer if possible), which would lead to highly scalable servers.
Microsoft didn't implement DOM, they implemented OM. (without the D) At the time IE4/5 came out, DOM wasn't a proposed or draft standard.
Many things changed between DOM working drafts, such as the NodeIterator iterfaces.
if you look at MSXML, it specifically calls it OM for ObjectModel and is different than DOM.
Same thing goes for XML, XSL, etc. Microsoft is good keeping up with drafts, but they are still behind everyone else. The only "near 100%" compliant XSL/XSLT/X-Path processors for instance, are James Clark's.
Nah, I did the same thing in emacs. I just query-replaced Hashtable with Hashmap, Vector with ArrayList, elementAt with get, removeElementAt with remote, addElement with add, and a few other items. The iterators take alittle more work.
If you run a profile, you see that most of the time is spent in following routines:
I replaced StreamTokenizer with BufferedReader and StringTokenizer. I then changed ArrayList into LinkedList. Got about 25% speedup.
Since most of the iteration is linear, and there are frequent removes/adds() from the beginning/end of the List, using the LinkedList is better. During the generate routine, random access is used, but the number of operations is generally smaller, and the size of the list is smaller.
Also, if you subtract the Java VM startup time and just time the code execution (as you would have in a server environment), my execution time is 1.2 seconds on a large dictionary file on a P2-400 Solaris x86 box on JDK1.2. With JavaVM startup overhead, it's 2.7 seconds real.
I bet with further optimizations running on IBM's JDK, you could get within 80% of C.
Can you post the input data too? And the perl version? It's trivial to make modifications to this Java code to speed it up by 5-10 times.
This code doesn't prove anything about Java's execution speed. It just proves that buffered I/O is more efficient than reading a byte at a time.
Any Java programmer who has more than a few months experience will immediately spot the problems.
1) Doesn't use buffered I/O at all. A trivial one line fix adding either BufferedReader or BufferedInputStream would boost speed tremendously.
2) Usage of StreamTokenizer on an interactive stream. A bug in JDK1.0-1.2.1 http://developer.java.sun.com/developer/bugParad e/bugs/4150737.html
3) Usage of synchronized Vector and Hashtable operations instead of ArrayList and HashMap.
4) Usage of StreamTokenizer! Use BufferedReader and indexOf() or StringTokenizer instead.
Like Linux vs NT, let's not post "cooked" or "biased" benchmarks. The only real way to run these sorts of benchmarks is to have a contest between C++, Java, Pyhton, Perl, and C coders, and have the final result judged on speed of execution, speed of development, clairity, and ease of reuse and maintainability.
In terms of academia and research, if you look at the IETF and W3C, almost all "new" protocols start out with Java prototype implementations. This is particularly true of the W3C. Jigsaw, XML, XSL, P3P, SVG,...
If you look at commercial websites, E-Trade and Datek come to mind, you'll see Java on the backend.
My own free pop/webmail/antispam service msgto.com) uses Java for everything, JSP, servlets, SMTP, POP server, etc. It's also faster and more responsive than Hotmail.
Yesterday, two spammers took "revenge" on our site by redirecting spam bounces to my site. In a 10 hour period, about 1 million bounced messages were received and discarded on a lowly dual-processor Solarisx86 box. Even now, we are getting about 10 messages per second but 'top' shows only 10% CPU utilization for the JavaVM and 30M memory used. Java definately scales.
Solarisx86 was used for only two reasons. One, when development was started, JDK1.2 wasn't available on Linux, and our servers use JDK1.2 heavily for its new garbage collection/memory management features and fine grained security.
Second, Solaris can scale to thousands of threads across multiple processors. Only TowerJ on Linux allows massive numbers of threads (by not using kernel threads), and Java's I/O mechanism relies on launching large numbers of threads. But TowerJ is not JDK1.2 compliant: bummer! Otherwise, I would love to have a bunch of rackmounted VA Research boxes.
The only place Java really failed was on the desktop application area. But I'm of the opinion that the general trend is that we are moving away from desktop applications and more towards web-based applications. So in a sense, most new desktop apps will fail, regardless of the programming language they are written in, and especially those that try to compete with areas Microsoft dominates. When was the last "killer-gotta-have-it-client-side app created" I can't think of many besides games, browsers, and other multimedia related utilities.
In the past, if you wanted to manage an address book, or a database, someone would ship you a VB or some other 4GL based app, that displays forms on your desktop and inserts them into the DB. Nowadays, most of these apps can be done on the network. This covers most business uses.
What's left for the desktop apps is multimedia. Music, Games, animation, art.
This Sun/IBM announcement is great news. I only wish that IBM would come out with a JDK1.2 compliant VM, because IBM seems to be alot better at optimizing VMs.
I find this concept stupid. Credit cards are not like bank loans where each transaction has to be approved and you have to state the reason for the loan.
Let me ask you this: Do you want VISA/Credit Bureaus/FINCEN/Big Government to know EXACTLY what you are doing at all times with your money?
Finally, if this women had gotten out of this by using a debit card (on some other stupid technicality) instead of a credit card, would you defend VISA?
Let's face it folks. Credit cards are used primarily online for convenience, because trying to buy something with cash or check sucks.
If online casinos start accepting Digicash, First Virtual, or any other debit scheme, I think you guys would still be defending this women and attacking the casino. The fact that she got off on a technicality is irrelevent. If she had sold her house to get the the $70,000, you'd still be defending her.
If someone wants to spend all their money on drugs, prostitution, or gambling, let them.
I think the application of "local laws" to the internet is just dumb. Whether its gambling laws, obsenity laws, anti-nazism laws, French language police, it's all bunk.
It's amazing that geeks subscribe to the same dumb politics promulgated in the non-net world.
Any small nation that develops ICBM nukes is only going to use it against the US as a bargaining chip.
"see, we now have ICBM nukes. You must admit us into the nuclear club, and you can't just police us like you police other nations."
In other words, they would use it to get the respect that China and Russia have, but that Kosovo, Haiti, Somalia, Sudan, and Indonesia do not. (W can run roughshod all over these countries and there's nothing they can do. We can not do the same to China, Russian provinces, or in the future, Pakistan.)
However, they know that any launch would surely result in their assured destruction (they can't destroy the US), so it's a pure terror weapon.
However, they know they can still gain some negotiating room with the US and other countries as long as they have the threat. The presence of ICBMs in North Korea alone would vastly boost their position in foreign policy at the negotiating table. You can see it today as North Korea uses the threat of missiles or building a weapons reactor to simply get food.
Having a credible missile defense allows the US to say "fuck your ICBMs, you must comply with your agreements, we can shoot down the few paultry ICBMs you have."
Now, whether or not the US can actually do this 100% is irrelevent. As long as the US has the credibility of doing it.
So why not simply announce a new defense system, announce 100% accurate tests, show phony demo tapes, stage phony sales to Israel, Taiwan, Japan, and other allies, and no country could falsify the reality of the situation without actually launching a weapon, which they would never attempt.
The US policy should be "launch a missile, if it gets shot down, you still die."
The only thing that truly matters in this world is perception. As long as Kruchev really believed the US was prepared to go all the way at Cuba, there was a chance for removal. If he felt the US was bluffing, the situation might have been worse.
Some people would like to pay for speed. I'm not saying that Rambus would deliver it, vis-a-vis DDR, or other techniques, but the average end user doesn't buy PentiumIII's or Xeon's either!
You fell for a scam. The DHMO scare is totally phony and masterminded by a Grad student like Sokal's postmodernism hoax to test how gullible the fearmongers are.
Apparently, you can publish a scary treastise on any chemical nowadays and get people to sign up.
John Stossil of ABC 20/20 ran a show on "Fear" a year ago and showed just how strong an effect this was.
He asked the audience "would you allow a new type of power technology into your home? It kills 600 people every year. When something goes wrong, it is explosive. It is silent and mostly undetectable...."
Most people said they would not. Then he revealed that most people already live with this technology, it's called Natural Gas.
The Rand institute applied game theory models for years to the super-power race. The whole reason for nuclear subs is to insure the "tit" ability, that is, retaliatory attack.
Otherwise, first-strike ability could wipe you out before you had a chance to respond.
Great books on the subject are Power's "Prisoner's Dilemma", and the fictional David's Sling.
Slashdot Mirror
The Linux community is held hostage by Netscape and their implementation (until Mozilla and OJI
frees them) It's not very scientific to have a single datapoint, Netscape's Java implementation, and therefore conclude, Java sucks.
Netscape 4 sucks speedwise, and stability wise. It has resource leaks, segfaults, and its Java VM doesn't even have a JIT. Java on Windows, Solaris, HP-UX, OS/2, and AIX runs very nicely. Only Swing is still a little slow, and even that is wholly dependendant on how you use it. (evidence: jEdit vs JEditorPane)
Try running the applet under IBM JDK1.1.8 appletviewer on Linux, it's about 30-50 times faster than the VM in Netscape and much more resource efficient.
Now try writing a PDP-1 emulator in pure PERL and let's see how fast it runs.
I've been coding Perl since 1991 and Java since 1993, and have mucho experiencing optimizing both Perl and Java code. All the anti-Java bashing that goes on here is pure FUD. You have clueless idiots bashing bytecode interpretation, and then cheerfully boost Perl, Python, PHP, TCL, etc,
claiming that parse tree evaluation will be faster than optimized bytecode/JIT, and bashing Java's thread model (when in fact, the fault lies in Linux's poor threading model compared to Solaris, OS/2, BeOS, or NT)
There are plenty of benchmarks out there now showing Java JIT's being within a fact of 50-80% of C on execution speed. Volano Report shows that some VMs/OSes can scale to thousands of simultanaeous threads (4000+). I personally ported a mini-raytracer to Java from C and only lost about 20% execution speed.
No doubt, Java GUI components still need more optimization. But on the other hand, the lack of a Microsoft Office competitor written in Java is not evidence. The desktop app markup is pretty locked up right now, most companies are developing Web/HTML versions of tradition apps like email/address book/form processing/hr/billing/info mgmt/etc, so the fact of the matter is, the number of "desktop apps" being written in C/C++ is also on the way down.
(why waste time doing C++ Forms Database, when you can develop much quicker by using HTML and a scripting language?)
Why wasn't Slashdot written in C++? Hmm..
Marc Stiegler is asking you to imagine a world of stronger cryptographic mechanisms. Digital certificates, secure communication, secure electronic cash and digital contracts. All things that anyone reading Bruce Schneider would want.
Marc also tries to imagine how lots of mass-produced, small, cheap, computing devices would alter the nature of freedom.
Instead, we get of "answers" that simply ignore the whole spirit of the question, which is imagine a world that has a more secure network infrastructure.
Why even bother with "Ask Slashdot" when the aggregate intelligence level of the readership here has been demonstrated to be slightly above 14 year old teens with a hyperactivity disorder, and a profoundly warped view of their importance in the world?
I would ask Marc Stielger to imagine a world where the Zetetic Institution of David's Sling really exists, and where people are cured of irrationality and knee-jerk opinions.
HUH?
Sun already licenses SPARC, motherboards, and just about all their other technology. You can go out and buy third party Sun clones right now and they are significantly cheaper. I bought one myself.
Why isn't there more "software" for Solaris (apart from the 15,000 apps already available?) Because Solaris is a server OS, not a consumer OS, that's why.
Whether it is Java, or building "GCC" into the kernel loader so that you can execute a tarball file (and have it compiled on the fly and cached), we need binary independence.
Now, it's temping to say "just compile the source", but if the source is a 20 megabyte monster like Mozilla that takes a loooong time to compile, you have an end-user problem.
The future is going to be awash in processors of all kinds, and we need a way of porting binaries across CPUs. If we don't, we won't have competition in the CPU market anymore, and one architecture will dominate, just like the Windows API dominates.
Also, once you get to IA-64 like devices, code will have to be recompiled for each new generation of IA-64 depending on how many execution units it has. If one generation can do 4-way execution, and the next can do 8-way, a JIT compiler is needed if the code is to be optimal for each CPU.
One approach would be to simply take the middle-layer output of a compiler like GCC, write it out in a byte code format, and then have operating systems backend-compile peephole-optimize this code when loading it.
Whatever mechanism used, JIT compilation (it's not just Java) has several benefits:
1) binary independence, register independence
2) can perform optimizations that even C/C++ can't. C's linker can't inline polymorphic or indirect function calls. A JIT compiler could actually inline calls from a shared library that isn't known until runtime. If this library is
OpenGL or GTK, rendering may get a huge improvement.
3) can adjust code and data locality depending on the size/capability of the CPU's cache
4) security. Depending on the mechanism used, can be used to "sandbox" code.
Try not to focus too much on the "interpreted" aspect of bytecode. Instead, just think of bytecode as simply a compressed version of source code. For instance, Java's bytecode format is so verbose, you can pretty much decompile it back to the original source without much loss.
Java is just the first step, but in the future, when the world is filled with ubiquitous CPUs everywhere, we're going to need ways to prove assertions about untrusted code, and we're going to need ways to run it wherever you are, so you aren't tied to any one device.
Last year, I filed my taxes on WebTurboTax. This
site is unbelievably great. It is just as detailed
as any client-side tax preparation program, only
it uses HTML, DynamicHTML, Java, and Acrobat/PDF,
and works anywhere on Netscape or IE.
I used Netscape 4 and it took big advantage of layers and JavaScript for its interface.
At the end, all I did was give my CC# and
I got a PDF file I could print out and send to
the IRS, or, I could just do an electronic filing.
Either way, as a web developer for the last 6
years, I thought it was one of the finest pieces of server-side/client-side integration I have seen.
(Did I mention it gracefully handled Netscape crashing without losing any data, and that it handled all the funky cases of idiot users trying to bookmark, or reload POST CGIs, etc)
For small companies, outsourcing to an ASP rocks. No one in a small startup wants to handle the ugly details of HR, Payroll, accounting, etc.
JPython is written in Java and runs faster in benchmarks than CPython when using the HotSpot JIT. Smalltalk, for a long time, was the king
of slowness.
Perhaps you are unaware of the difficultly of efficiently compiling fully dynamic weakly typed languages like Smalltalk, or Perl5?
If Perl5 sees a bunch of expressions, it has no idea until runtime if $x is a string, floating point, reference, or integer variable. The
situation is even worse for function calls
through a blessed reference where any number
of dynamic mechanisms can cause a different
subroutine to be dispatched. Perl can't inline
like a Java JIT can.
The only way Perl5 could possibly beat a Java JIT is if it had a Smalltalk/Hotspot style JIT compiler that did type-inferencing.
Perl excels at text manipulation and array/hashtable manipulation because those are language primitives which are handled efficiently.
There is no way Perl would beat Java at say, image processing, or ray-tracing. I've been writing Perl for 6 years, and I have written several 30,000+ line apps with it, so I know exactly how it performs.
There is no such thing as one benchmark that decides performance for all languages. Perl will blow away just about even language, even C++ in many cases (inefficient libraries) when it comes to text manipulation, regexp, array slicing, etc.
But Perl won't win on any numerically or graphically intense benchmarks.
I use jEdit on JDK1.2.2 and IBM JDK 1.1.8 as my main editor, because it is much easier to extend than Emacs, and less bloated. The speed is very acceptable, some would say speedy.
Just try writing an editor in 100% Perl or Python without using *any* native components except a bitmap to draw into, and let's see how fast it is. (This is essentially what you get with Swing, since all GUI components are written in Java)
What happens if Word Perfect 8 dumps core?
Application stability matters too. There is too
much focus on the "stability of Linux" and not
enough focus on stable GUI applications IMHO.
Someone already did do it, in fact, several
people have.
The Beduin browser (for PersonalJava), and
the ICE Browser (icesoft) are both ALOT better
than HotJava.
The ICE browser even does CSS2.0, MathML,
JavaScript, SMIL, and lots of other things.
Coding makes a huge difference. Remember,
Mosaic sucked and was slow, and so was Netscape.
IE4/Mozilla are much better than their former
C++ counterparts (IE1-3, Netscape1-4) in their
rendering engine speed, and that's precisely
because of the algorithms used.
Just look at jEdit (www.gjt.org), an emacs clone
written in Java. It's very speedy and usable
on my Celeron 300Mhz 128mb system with JDK1.2.2.
(and it probably runs much better under IBM JDK1.1.8)
Look folks, I can believe that the NSA can
monitor most of the relevent international
EM communications traffic via listening
outposts.
I can believe that the NSA monitors international
long distance phone traffic. I can even believe
that the NSA monitors some internet traffic.
But the claim that they can monitor *everything* is bogus. They can't even monitor all EM frequencies or spread spectrum communications. If they could, they could do what SETI is trying to do in a heart beat. The fact is, the spectrum is too big to monitor in totality for "interesting traffic" It's much easier for them to scan frequencies in use by known equipment being bought by foreign governments.
Secondly: Monitoring *EVERY* phone call? I think not. International traffic, sure. But grepping every voice call made in the world would require such a staggering amount of bandwidth, CPU, and storage, it's a ridiculous assertion.
Even if the Baby Bells agreed to it, the monitoring equipment itself would likely degrade the performance of the carriers.
Every email? We know that's bullshit. The NSA can't monitor intranet-only email (unless they have millions of tempest outposts next to every company and ISP in the world). So they are left with the following choices: partner with AOL/Hotmail/EVERY ISP so they can grep intra-ISP mail or 2:
Somehow monitor IP traffic on everyone's network -- also bogus.
Let's posit that the NSA approached Cisco 10 years ago and had them build a special transmitter in Cisco boxes that forwards all "interesting" traffic to the NSA.
Can you imagine 1) the performance hit on Cisco routers to do this and 2) the bandwidth requirements to trasnmit this data to the NSA for analysis. Also, no geek has ever taken apart a Cisco box and detected this backdoor? No network
admin has ever noticed any weird packets on his network going to a strange play? or mysterious delays?
Echelon is a very boring concept I'm afraid. I doubt it lives up to the hype. It's just one big orbital frequency scanner, and some international phone cable monitoring.
To be otherwise, the NSA would have to have its claws into *hundreds* of corporations, and have silenced all the TECHIE GEEKS working at these places who would obviously know about the monitoring. Since I personally know people who work at HUGE ISPs and run their mail/network systems, I know this isn't true.
And the NSA can't just monitor MAE-EAST/WEST, etc, because much traffic is routed through private peer networks now. For instance, Above.Net has 190+ peering arrangements and several private backbones. So now we have the NSA having to splice into and monitor hundreds of private backbone networks.
Echelon would require as fantasic a conspiracy as the UFO morons posit. Occams Razor dictates that the truth is much simpler than that.
Good ole fashion logic dictates the NSA spends more time monitoring the airwaves and international phone, than they do trying to snoop on US internet traffic, given that the vast majority of third world governments are still using primitive radio and telephone equipment.
The conclusion is that JAM Echelon Day was a ridiculous waste of time that probably had some NSA guys laughing on the floor.
And it goes back to why dynamic, typeless, languages are used.
1) Instantaneous Feedback. With Perl, you edit the "document" (script), click reload, and see the effect immediately.
With C/C++, you edit, compile, relink, maybe even "restart the server" and if it crashes, it's debugger time. C/C++ sucks as a language for doing DatabaseText transformations ala Perl, Python, TCL, and 4GLs.
2) A syntax that freely intermixes HTML and script code.
What's better:
<tr><td>$firstname</td><td>$lastname</td></tr>
or
out << "<tr><td>" << firstname << "</td><td>" << lastname << "</td></tr>"
I would argue that a document that is mostly HTML, with some script fragments is far more editable and managable than a C/C++ source file that is mostly "printf" code with HTML interspersed. With some editors, you can even
edit the HTML containing Perl/ASP/Cold Fusion/JSP/Python code and see it mostly visually.
3) great for DatabaseText transformations.
Perl blows away C/C++ in processing strings, slicing and dicing arrays, and doing Hashtable tricks. Anything even remotely close in C/C++ requires a third party non-standard library, and a syntax which still isn't as compact.
The vast majority of CGI apps run DB queries and
convert the dataset to a text or HTML representation.
With scripting languages, it is much easier to perform the query, and write the template that dumps the output.
CGI apps are *NOT* dominated by CPU performance. The biggest bandwidth is memory and I/O. Except in rare cases, compiling a CGI won't get you as much performance as simply adding more ram, more threading, and more I/O bandwidth.
Why Perl? Should be "Why scripting" Answer? Fast, safe development, economical syntax, easy to debug, can blend with markup languages better.
Cold Fusion is yet another example of something tuned to do one thing (DB->HTML transformation).
The ability to simply "reload" to see you changes, even forced me to recode Java Servlets as JSP pages simply because my development speed was multiplied x 10.
To recap: 1) a development model that allows instanteous feedback (click reload)
2) The ability to deal with documents, and embed code, rather than the other way array.
3) superor handling of datatypes and more compact syntax.
The problem with scripting of course, is that it is brittle from a maintainance point of view. As a project gets larger, there is less code reuse, no way to verify usage of reused code (type checking), and a tendecy for developers to "cut-and-paste" code fragments in a slap-dash attempt to get something to work.
And it goes back to why dynamic, typeless, languages are used.
1) Instantaneous Feedback. With Perl, you edit the "document" (script), click reload, and see the effect immediately.
With C/C++, you edit, compile, relink, maybe even "restart the server" and if it crashes, it's debugger time. C/C++ sucks as a language for doing DatabaseText transformations ala Perl, Python, TCL, and 4GLs.
2) A syntax that freely intermixes HTML and script code.
What's better:
$firstname$lastname
or
out " " "
I would argue that a document that is mostly HTML, with some script fragments is far more editable and managable than a C++ source file that is mostly "printf" code with HTML interspersed.
3) great for DatabaseText transformations.
Perl blows away C/C++ in processing strings, slicing and dicing arrays, and doing Hashtable tricks. Anything even remotely close in C++ requires a third party non-standard library, and a syntax which still isn't as compact.
The vast majority of CGI apps run DB queries and
convert the dataset to a text or HTML representation.
With scripting languages, it is much easier to perform the query, and write the template that dumps the output.
CGI apps are *NOT* dominated by CPU performance. The biggest bandwidth is memory and I/O. Except in rare cases, compiling a CGI won't get you as much performance as simply adding more ram, more threading, and more I/O bandwidth.
Why Perl? Should be "Why scripting" Answer? Fast, safe development, economical syntax, easy to debug, can blend with markup languages better.
Cold Fusion is yet another example of something tuned to do one thing (DB->HTML transformation).
The ability to simply "reload" to see you changes, even forced me to recode Java Servlets as JSP pages simply because my development speed was multiplied x 10.
He's talking about Java on the server side, not applets. Applets are only just a small part of what Java can do.
Likewise, Perl can be used for things besides CGI, such as Tk applications, or command line utilities.
This isn't consumer apps running on a portal, this is a business to business startup, and fulfills a similar function as UUNET, Exodus, or AboveNet.
In the ole days, people got their own T1 lines to their office and hosted their web sites on their own machines, had their own network admins, their own cable/hardware guys, etc.
First step: eliminate the hassle of running a T1 and maintaining your own "high availability" stuff.
Companies: Exodus, AboveNet. Gigabits of bandwidth, earthquake proof, power failure proof, fault tolerant. Pay $1800/mo and stick a few rackmounted machines there, and they do the rest.
No brainer for most businesses.
Hosting servers at a professional hosting service is much better than running a T1 from your ISP. The ISP's quality of service simply can't compete.
Next step: services. Example: email. Email is a commodity. Why pay a staff $200k a year plus capital costs to host sendmail, exchange, or lotus notes on your network when you can just "outsource" it to USA.net, Mail.com, CriticalPath, for a small fee and not have to deal with the headache? There is no way your average mail admin will achieve the scalability and level of service that you will get at say, CriticalPath.
Next steps: Why go through the hassle of having to purchase your own copy of Oracle, or an Application server, and pay an Oracle DBA or CIO lots of money to maintain them, their uptime, and the quality of service?
If you have a bright idea for the Next-Big-Thing, and want to start coding immediately next week, and you can't afford to hire lots of people, why not just rent space on someone else's professionally maintained DB/Application Server/Network, etc.
By outsourcing these services, you don't need to waste time, and money, developing your own inhouse installation, and struggling to maintain the QoS that a professionally run organization has. Or for that matter, the fault-tolerance of leasing a DB/Server on an E10000!
Andressen's idea is simply to setup the DB/App server, and simply sell the right to run your servlets, CGIs, applets, etc on their servers.
I can tell you that it's a very valuable proposition to some companies. It's too distracting to have developers wasting time performing maintaince on hardware, software, network, etc.
Now, you can easily hire an inhouse admin to do it, but you still won't have the quality of running on a Sun Enterprise 10000 hosted at Exodus, with 24hr on-call staff, high security, subterranian power generators, etc Also, it takes time to hire someone and have them set it all up. With outsourcing, you make one phone call, write a check, and your developers can start coding the next day.
-Ray
I think having a single (if forked) open-source implementation is inferior to having multiple implementations of a frozen, agreed upon, standard API.
For instance, I would much rather have multiple HTML browsers rather than a single FooBarML browser, even if it is open-source and "forked"
The whole Linux desktop situation would be better if the GNOME/KDE guys hashed out some standards, agreed to them, and both implemented them. XDnd is one, but almost everything else is divergent.
Protocols are more important than source. Having source to all the implementations is nice too, but if they are divergent in protocol, they add to the cost of software development.
Component based programming and standardized APIs/protocols solves most of the danger of committing to a single vendor.
For instance, for databases, we have SQL/ODBC/JDBC. For distributed programming we have CORBA/EJB. For file formats, we have XML, etc.
I'd much rather target SQL/ODBC than target "MySQL" only, even if there were 50 open-source forked implementations.
Adopt Amiga's message passing and asynchronous
I/O archicture for Linux, or some variant.
(also similar to NT completion ports)
Amiga's thread-based (Amiga called them processes,
but they were really threads) MessagePort
based I/O is lightyears easier to program
and more scalable than Linux select/poll(),
and POSIX AIO sucks, and SIGIO doesn't look
much better.
Basically, Amiga OS is deficient in every area (device independent graphics, memory protection, virtual memory, resource tracking, etc) except the one area where a real-time OS kicks ass, which is I/O.
Under AmigaOS, you could send off requests for thousands of different I/O requests and have buffers filled in by device drivers, and then
notify the threads that new data is available.
Almost zero-context switch overhead, no "copying" between kernel/user (device drivers would actually DMA data directly into your memory buffer if possible), which would lead to highly scalable servers.
Microsoft didn't implement DOM, they implemented OM. (without the D) At the time IE4/5 came out, DOM wasn't a proposed or draft standard.
Many things changed between DOM working drafts, such as the NodeIterator iterfaces.
if you look at MSXML, it specifically calls it OM for ObjectModel and is different than DOM.
Same thing goes for XML, XSL, etc. Microsoft is good keeping up with drafts, but they are still behind everyone else. The only "near 100%" compliant XSL/XSLT/X-Path processors for instance, are James Clark's.
Nah, I did the same thing in emacs. I just query-replaced Hashtable with Hashmap, Vector with ArrayList, elementAt with get, removeElementAt with remote, addElement with add, and a few other items. The iterators take alittle more work.
If you run a profile, you see that most of the time is spent in following routines:
add()
Prefix.hashCode()
Prefix() constructor
StreamTokenizer
I replaced StreamTokenizer with BufferedReader
and StringTokenizer. I then changed ArrayList into LinkedList. Got about 25% speedup.
Since most of the iteration is linear, and there are frequent removes/adds() from the beginning/end of the List, using the LinkedList is better. During the generate routine, random access is used, but the number of operations is generally smaller, and the size of the list is smaller.
Also, if you subtract the Java VM startup time and just time the code execution (as you would have in a server environment), my execution time is 1.2 seconds on a large dictionary file on a P2-400 Solaris x86 box on JDK1.2. With JavaVM startup overhead, it's 2.7 seconds real.
I bet with further optimizations running on IBM's JDK, you could get within 80% of C.
Can you post the input data too? And the perl version? It's trivial to make modifications to this Java code to speed it up by 5-10 times.
This code doesn't prove anything about Java's execution speed. It just proves that buffered I/O is more efficient than reading a byte at a time.
Any Java programmer who has more than a few months experience will immediately spot the
problems.
1) Doesn't use buffered I/O at all. A trivial one line fix adding either BufferedReader or BufferedInputStream would boost speed tremendously.
2) Usage of StreamTokenizer on an interactive stream. A bug in JDK1.0-1.2.1
http://developer.java.sun.com/developer/bugPara
3) Usage of synchronized Vector and Hashtable operations instead of ArrayList and HashMap.
4) Usage of StreamTokenizer! Use BufferedReader and indexOf() or StringTokenizer instead.
Like Linux vs NT, let's not post "cooked" or "biased" benchmarks. The only real way to run these sorts of benchmarks is to have a contest between C++, Java, Pyhton, Perl, and C coders, and have the final result judged on speed of execution, speed of development, clairity, and ease of reuse and maintainability.
In terms of academia and research, if you look at the IETF and W3C, almost all "new" protocols start out with Java prototype implementations. This is particularly true of the W3C. Jigsaw, XML, XSL, P3P, SVG,
If you look at commercial websites, E-Trade and Datek come to mind, you'll see Java on the backend.
My own free pop/webmail/antispam service msgto.com) uses Java for everything, JSP, servlets, SMTP, POP server, etc. It's also
faster and more responsive than Hotmail.
Yesterday, two spammers took "revenge" on our site by redirecting spam bounces to my site. In a
10 hour period, about 1 million bounced messages were received and discarded on a lowly dual-processor Solarisx86 box. Even now, we are getting about 10 messages per second but 'top' shows only 10% CPU utilization for the JavaVM and 30M memory used. Java definately scales.
Solarisx86 was used for only two reasons. One, when development was started, JDK1.2 wasn't available on Linux, and our servers use JDK1.2 heavily for its new garbage collection/memory management features and fine grained security.
Second, Solaris can scale to thousands of threads across multiple processors. Only TowerJ on Linux allows massive numbers of threads (by not using kernel threads), and Java's I/O mechanism relies on launching large numbers of threads. But TowerJ is not JDK1.2 compliant: bummer! Otherwise, I would love to have a bunch of rackmounted VA Research boxes.
The only place Java really failed was on the desktop application area. But I'm of the opinion that the general trend is that we are moving away from desktop applications and more towards web-based applications. So in a sense, most new desktop apps will fail, regardless of the programming language they are written in, and especially those that try to compete with areas Microsoft dominates. When was the last "killer-gotta-have-it-client-side app created" I can't think of many besides games, browsers, and other multimedia related utilities.
In the past, if you wanted to manage an address book, or a database, someone would ship you a VB or some other 4GL based app, that displays forms on your desktop and inserts them into the DB. Nowadays, most of these apps can be done on the network. This covers most business uses.
What's left for the desktop apps is multimedia. Music, Games, animation, art.
This Sun/IBM announcement is great news. I only wish that IBM would come out with a JDK1.2 compliant VM, because IBM seems to be alot better at optimizing VMs.
-Ray
I find this concept stupid. Credit cards are not like bank loans where each transaction has to be approved and you have to state the reason for the loan.
Let me ask you this: Do you want VISA/Credit Bureaus/FINCEN/Big Government to know EXACTLY what you are doing at all times with your money?
Finally, if this women had gotten out of this by using a debit card (on some other stupid technicality) instead of a credit card, would you defend VISA?
Let's face it folks. Credit cards are used primarily online for convenience, because trying to buy something with cash or check sucks.
If online casinos start accepting Digicash, First Virtual, or any other debit scheme, I think you guys would still be defending this women and attacking the casino. The fact that she got off on a technicality is irrelevent. If she had sold her house to get the the $70,000, you'd still be defending her.
If someone wants to spend all their money on drugs, prostitution, or gambling, let them.
I think the application of "local laws" to the internet is just dumb. Whether its gambling laws, obsenity laws, anti-nazism laws, French language police, it's all bunk.
It's amazing that geeks subscribe to the same dumb politics promulgated in the non-net world.
Any small nation that develops ICBM nukes is only
going to use it against the US as a bargaining
chip.
"see, we now have ICBM nukes. You must admit
us into the nuclear club, and you can't just
police us like you police other nations."
In other words, they would use it to get the
respect that China and Russia have, but that
Kosovo, Haiti, Somalia, Sudan, and Indonesia
do not. (W can run roughshod all over these
countries and there's nothing they can do.
We can not do the same to China, Russian provinces, or in the future, Pakistan.)
However, they know that any launch would surely
result in their assured destruction (they can't
destroy the US), so it's a pure terror weapon.
However, they know they can still gain some
negotiating room with the US and other countries
as long as they have the threat. The presence
of ICBMs in North Korea alone would vastly boost
their position in foreign policy at the
negotiating table. You can see it today as
North Korea uses the threat of missiles or
building a weapons reactor to simply get
food.
Having a credible missile defense allows the US
to say "fuck your ICBMs, you must comply with
your agreements, we can shoot down the few paultry
ICBMs you have."
Now, whether or not the US can actually do this
100% is irrelevent. As long as the US has the credibility of doing it.
So why not simply announce a new defense system, announce 100% accurate tests, show phony demo tapes, stage phony sales to Israel, Taiwan, Japan, and other allies, and no country could
falsify the reality of the situation without
actually launching a weapon, which they would
never attempt.
The US policy should be "launch a missile, if it gets shot down, you still die."
The only thing that truly matters in this world is perception. As long as Kruchev really believed the US was prepared to go all the way at Cuba, there was a chance for removal. If he felt the US was bluffing, the situation might have been worse.
Which video cards are using RAMBUS? I have
only seen ones on paper that propose to use
it (Glaze3D)
I know of no working PC video cards that use it.
It's hard to even get RDRAM.
Perhaps you confused Rambus with SGRAM, VRAM,
et al?
Some people would like to pay for speed. I'm not
saying that Rambus would deliver it, vis-a-vis
DDR, or other techniques, but the average end
user doesn't buy PentiumIII's or Xeon's either!
You fell for a scam. The DHMO scare is totally
phony and masterminded by a Grad student like
Sokal's postmodernism hoax to test how gullible
the fearmongers are.
Apparently, you can publish a scary treastise
on any chemical nowadays and get people to sign
up.
John Stossil of ABC 20/20 ran a show on "Fear"
a year ago and showed just how strong an
effect this was.
He asked the audience "would you allow a new
type of power technology into your home? It
kills 600 people every year. When something
goes wrong, it is explosive. It is silent
and mostly undetectable...."
Most people said they would not. Then he revealed that most people already live with this technology, it's called Natural Gas.
The Rand institute applied game theory models for years to the super-power race. The whole reason for nuclear subs is to insure the "tit" ability, that is, retaliatory attack.
Otherwise, first-strike ability could wipe you out before you had a chance to respond.
Great books on the subject are Power's "Prisoner's Dilemma", and the fictional David's Sling.