An estimated 80% of the cc transactions originating in this country are with stolen cc numbers. So, if you have
online cc processing on your site, MAKE SURE you block any requests originating with 202.*
Hey! All the IP addresses where I work start with 202, and I'm fairly sure that New Zealand isn't the country in Southeast Asia you're referring to. I don't think that IP address is a very good way of determining geographical location, and I don't think geographical location is a good way of determining guilt.
er..... no, it's not. many reckon it should be, and some of the thicker webmasters even claim it is, legal. but
there's no two ways about it, downloading abandonware is illegal, as it putting it up on a site.
This is seriously understating the myriad problems with many of those JVM ports.
Ah, you caught me. This is very true. I just thought it was worth mentioning.
I'm not a compiler/language design expert, so I can't really comment on how good/bad.NET/JVM are for multiple languages. What I do know is that some of the different languages available for the JVM are very useful. I'm thinking particularly of JPython and SILK.
So,.NET has features good for language independence. This is cool. Java has a large, generally useful, cross-platform API. This is also cool.
It compiles (on the fly) to a form of bytecode. I think that it's possible to distribute only the bytecode. Still, it's not hard to decompile the bytecode. If you're worried about people "stealing" your ideas, perhaps an ASP ("application service provider", not "active server pages") approach would be more "secure".
Gah! Let's not fight inaccuracies with inaccuracies. That way madness lies.
The.NET platform is an improvement for Visual C++ and Visual Basic programmers, but it is yet another proprietary Microsoft platform which will tie the developer to Windows, albeit possibly a.NET-ized notion of Windows.
I love Java, but this is simply bullshit. The main purpose of.NET is the exact opposite. It's purpose is to allow developers to actually use COM and the Windows API without being shackled to VB and Visual C++.
You haven't contradicted the quoted statement. In fact, it seems that you agree with it. If using COM and the Windows API isn't being tied to Windows, I don't know what is.
Currently there are plans for.NET to support the following languages APL, CAML, Cobol, Haskell, Mercury, ML, Oberon, Oz, Pascal, Perl, Python, Scheme, and Smalltalk.
This is cool. Many of these languages can be targetted to the JVM (see Languages for the Java VM), which is also cool. Language diversity is cool.
Obviously this scares Sun and that's why they are publishing this propaganda because it begins to show the truth that Java shackles developers by forcing them to use the Java[tm] platform for all development in all three tiers of a client-server application if they plan to use the Java[tm] language for any aspect development (yes, I know about JNI, but it is currently subpar).
I'm not sure where you get this idea. Certainly, if you want to use the full-on J2EE platform then you need to use Java, just like you need to use.NET if you want to use.NET. But nobody said that you need to program to J2EE to write a client-server application. You can use CORBA in Java. You can use SOAP if you really want to.
Want Java applets that talk to CORBA services written in Haskell that talk to an RDBMS? You can have that. Want Perl CGI scripts that use SOAP to talk to a JAVA middle tier application? You can have that, too.
It looks like.NET is promising this as well, which is all well and groovy, but just because Sun published someone's opinion that you don't agree with is no reason to try to spread misinformation.
I agree, BTW, that the article is heavily slanted in favour of Java, but what did you expect?
I think this post is a troll, but I'm intrigued by this:
> there's a point (the "absolute processing
> point") where the speed of a program is
> dependent solely on the algorithm used, and not
> on how fast the microprocessor is chugging along
Huh? Can somebody shed some light on this "absolute processing point?" Sure, most tasks are going to be constrained by other resources, such as disk or memory bandwidth, once you pump the CPU speed up enough, but "dependent solely on the algorithm?"
> Java itself is not the problem. This summer I
> have been doing a lot of Java development on
> Linux, and not once has Java crashed on me
> unless I wrote some bad code.
What kind of "bad code"? If you mean Java code, then Java itself (well, the JVM you're using) *is* the problem. If you mean native code, then sure, it's your fault.
The state of JVMs on anything other than Solaris and Windows is pretty shocking in my experience, which is, admittedly, limited to Linux and IRIX. I hear the HP/UX JVM is pretty good.
Slashdot Mirror
Mserv has worked for me in the past. It has telnet and web interfaces and the latest CVS version supports Ogg as well as MP3.
What does forward and back have to do with handedness?
Are we talking about the forward and back buttons in a browser? I thought they were to do with the way writing goes from left to right.
Hey! All the IP addresses where I work start with 202, and I'm fairly sure that New Zealand isn't the country in Southeast Asia you're referring to. I don't think that IP address is a very good way of determining geographical location, and I don't think geographical location is a good way of determining guilt.
Read the FAQ! It says:
Ah, you caught me. This is very true. I just thought it was worth mentioning.
I'm not a compiler/language design expert, so I can't really comment on how good/bad .NET/JVM are for multiple languages. What I do know is that some of the different languages available for the JVM are very useful. I'm thinking particularly of JPython and SILK.
So, .NET has features good for language independence. This is cool. Java has a large, generally useful, cross-platform API. This is also cool.
Everything's cool.
It compiles (on the fly) to a form of bytecode. I think that it's possible to distribute only the bytecode. Still, it's not hard to decompile the bytecode. If you're worried about people "stealing" your ideas, perhaps an ASP ("application service provider", not "active server pages") approach would be more "secure".
"Regards,"
Toby.
P.S. sorry for the overuse of "s
Gah! Let's not fight inaccuracies with inaccuracies. That way madness lies.
You haven't contradicted the quoted statement. In fact, it seems that you agree with it. If using COM and the Windows API isn't being tied to Windows, I don't know what is.
This is cool. Many of these languages can be targetted to the JVM (see Languages for the Java VM), which is also cool. Language diversity is cool.I'm not sure where you get this idea. Certainly, if you want to use the full-on J2EE platform then you need to use Java, just like you need to use .NET if you want to use .NET. But nobody said that you need to program to J2EE to write a client-server application. You can use CORBA in Java. You can use SOAP if you really want to.
Want Java applets that talk to CORBA services written in Haskell that talk to an RDBMS? You can have that. Want Perl CGI scripts that use SOAP to talk to a JAVA middle tier application? You can have that, too.
It looks like .NET is promising this as well, which is all well and groovy, but just because Sun published someone's opinion that you don't agree with is no reason to try to spread misinformation.
I agree, BTW, that the article is heavily slanted in favour of Java, but what did you expect?
Regards,
Toby Allsopp.
The preprocessor cares not for these "reserved words" of which you speak.
Try this:
#define while exit
int main() { while(1); }
I think he meant This_story_has_been_bouncing_around_for_a_while.h, which contains the prototype for the this_is_old_news() function.
I think this post is a troll, but I'm intrigued by this:
> there's a point (the "absolute processing
> point") where the speed of a program is
> dependent solely on the algorithm used, and not
> on how fast the microprocessor is chugging along
Huh? Can somebody shed some light on this "absolute processing point?" Sure, most tasks are going to be constrained by other resources, such as disk or memory bandwidth, once you pump the CPU speed up enough, but "dependent solely on the algorithm?"
This just makes no sense to me.
GrEp wrote:
> Java itself is not the problem. This summer I
> have been doing a lot of Java development on
> Linux, and not once has Java crashed on me
> unless I wrote some bad code.
What kind of "bad code"? If you mean Java code, then Java itself (well, the JVM you're using) *is* the problem. If you mean native code, then sure, it's your fault.
The state of JVMs on anything other than Solaris and Windows is pretty shocking in my experience, which is, admittedly, limited to Linux and IRIX. I hear the HP/UX JVM is pretty good.