Slashdot Mirror

Yes, Java didn't surpass, but was competitive with C++ many years ago - at least as far as CPU goes. In fact, if you use gcj, you'll find that Java performance is *very* similar to C++ :-). For the IBM JVM, the turning point was JDK 1.1.6. I think having each thread allocate blocks of memory to dish out without lock contention was a big part of it. One interesting benchmark was this.

Now, before you C/C++ or Java fanboys get too excited, the absolute hands down fastest language on most of the benchmarks was LISP (I think it was Common LISP). I don't use LISP because I hate the syntax (and LISP fanboys regard it as a requirement of club membership that you like it). But the performance is quite impressive (with GC too), and that's what I would look into if I needed top performance from a high level language. Eat your heart out C++.

I use Java quite a bit, and the biggest drawback performance wise is the amount of memory chewed up by the GC schemes and JIT. It is otherwise quite fast. I often turn off JIT to save memory (at the expense of CPU), and I would like to see options to use a GC algorithm that minimizes memory consumption (at the expense of CPU).

mix that with the fact that java doesn't run well for most things that people try and use it for..

Most people seem to be doing server side development with it. Works fine. :-)

i am sorry but without inter proccess comunication it is usless to me.

You mean like TCP/IP, CORBA, RMI, SOAP, XML-RPC, etc.? You need to be more specific if you're going to complain. BTW, there are libraries for SMB Remote IPC and POSIX IPC, but using either of them won't result in very portable code under ANY language.

Which raises the question, what exactly are you doing that you need native IPC?

Your definition is a good one. But it still doesn't make this product the first - or revolutionary. Sendmail created the 'milter' interface many years ago precisely to make this kind of rejection of unwanted mail possible. There are many sendmail milters written in many languages. The most popular being C, Perl, Python in that order. I run a Python milter which removes Windows executables (except DOC and XLS), checks SPF, and checks content with DSPAM wrapped for Python. Of the 40000 spams a day we get, nearly all are rejected before SMTP DATA. Those flunking content check are rejected before the connection closes - except when addressed to a 'screener', in which case it goes to a spam mailbox. Screeners have the task of providing feedback to the Bayesian filter - relieving others in the company of the burden.

Your definition is a good one. But it still doesn't make this product the first - or revolutionary. Sendmail created the 'milter' interface many years ago precisely to make this kind of rejection of unwanted mail possible. There are many sendmail milters written in many languages. The most popular being C, Perl, Python in that order. I run a Python milter which removes Windows executables (except DOC and XLS), checks SPF, and checks content with DSPAM wrapped for Python. Of the 40000 spams a day we get, nearly all are rejected before SMTP DATA. Those flunking content check are rejected before the connection closes - except when addressed to a 'screener', in which case it goes to a spam mailbox. Screeners have the task of providing feedback to the Bayesian filter - relieving others in the company of the burden.

Have you tested that syntax with the current Mail::SRS module? Unless I'm seriously mistaken, passing the email into a program in .forward passes the entire email.

The current "srs" executable that comes with that module only translates an address, and that address has to be on the command line. The most efficient way to handle SRS rewriting is in the MTA, and there are already patches for a few of them. There's Python SRS, that can be plugged into Exim and sendmail, and there's a similar implementation in Perl that it links to. There is also an implementation for qmail. I haven't seen one yet for Postfix, but I can't see it being that difficult to implement.

In any case, the only sites that really need to implement it are those that do any forwarding or sending of email as if it's coming from a domain other than their own. In the meantime, there's a trusted forwarder list to ease the transition where it's needed.

There is no startup cost because the milter process is persistent. Each connection is handled by its own thread. If your objection to Perl has to do with syntax, then I am with you. Otherwise, Perl has similar issues.

However, since AOL is designed for people that are general incompetent when it comes to computers, (because they have other interests), then AOL might wisely choose not to reject any mail based solely on SPF.

While foo.edu didn't do anything wrong, they also could make life easier for the student by implementing SRS for mail that they forward. I install my pysrs package for sendmail. Enabling SRS is a single line in sendmail.mc.

Using the milter interface, messages can be rejected anytime. While rejecting extremely spammy mail is worthwhile, it is important to allow mail for which there is some doubt through in case of false positives. I suppose the milter could fully receive the mail before rejecting it, and *still* deliver it to the user for feedback.

Using the milter interface, messages can be rejected anytime. While rejecting extremely spammy mail is worthwhile, it is important to allow mail for which there is some doubt through in case of false positives. I suppose the milter could fully receive the mail before rejecting it, and *still* deliver it to the user for feedback.

These are problems they would not wish on their fiercest competitors, so there is no desire to keep it proprietary. In general, when a company's primary business is not computers, the computer is just a tool. And they are willing to contribute to projects to improve the tool for everyone.

These investments are always going to be small and short term. However, sometimes you can go around to many businesses in a trade, and convince them to pool contributions for a project that benefits them all. They are competitors, so there is suspicion to overcome, but if you are a neutral third party (e.g. you are a computer consultant) it can be done.

These are problems they would not wish on their fiercest competitors, so there is no desire to keep it proprietary. In general, when a company's primary business is not computers, the computer is just a tool. And they are willing to contribute to projects to improve the tool for everyone.

These investments are always going to be small and short term. However, sometimes you can go around to many businesses in a trade, and convince them to pool contributions for a project that benefits them all. They are competitors, so there is suspicion to overcome, but if you are a neutral third party (e.g. you are a computer consultant) it can be done.

What *has* helped is installing a sendmail milter to remove executable Windoze attachments.

TUIPeer is a text-mode look-and-feel for the Java AWT. Would it be possible to do the same thing for Mozilla? If that happened then Mozilla and all apps based on its widget set would be runnable over telnet or in an xterm. It might give the Lynx users something to worry about :-)