I've used Eclipse since it was first opened by IBM.
It was far faster and more responsive than any Swing app then, and it's better now, even given that it's much bigger and more feature rich.
Given 1ghz and 512Mb and you should be in good shape - on Linux.
Upgrade your ram to at least 1Gb if you're on XP.
And, textpad+javac won't let you be nearly as productive. Especially when, under Eclipse, Alt+S, and your java file is incrementally compiled. You don't even need to think about it.
On other thing: Eclipse does more than Java. I use CDT for C & C++. Still has kinks in it, but any developer should be able to be productive with it.
Pay for two cell services (they have to operate simultaneously)
Install and configure IPDrum and Skype
Dial twice on each call
Plus, you get the benefit that there's 3 or 4 extra single points of failure, and you get to use twice the air bandwith when your calling from the same tower as the dedicated cell-phone.
I think the point was that since Java is not open source, you can't get something like SWT into the base tree (without Sun's JCP process) - which would undoubtedly be useful.
SWT is not a modification per se, but it does offer a replacement for AWT or Swing; however, since it does not form part of the JVM and it uses native code, programmers can't rely on it being available, as they can for other APIs.
The native code part is key, because it means you can't ship the SWT library with the app. And you can't assume it's already there.
Acutally you can, but:
You have to ship a version for each supported platform
You can only support platforms to which the library has been ported
If Java were open source, SWT could be incorperated, and become a standard API supported on every platform that Java runs on.
You need to give examples of where the Java API isn't backware compatible.
There are some documented areas, but I haven't run into any instances that weren't documented.
I think Sun has had an exemplary record in backwards compatability, especially when compared to other platform vendors, and when you consider that Java runs on so many OSes.
My biggest gripe about Sun with regard to Java is in the JDBC specification. For example - Can a Connection be used by more than one Thread?
Anwser: It's not detailed in the specification - it's vendor dependant.
This is a bad thing to do in a specification - it means that as a coder you can't rely on one kind of behavior. Or you have to limit to one vendor.
Perhaps you're refering to non Java-platform APIs, like those in the sun. packages?
Hardly matters, since.NET will be part of the Windows OS...
Shame Java can't be preloaded with Linux distro's!
I mean - imagine if there were a 100% platform independent API that you could write against that was avaible on most platforms - already integrated with the environment. And without the minor differences you find in *nixes, resulting in all the config.h and autoconf messes.
And from GP:
Performance wise, Java suffers from large start-up time, since the JVM has to start. It also suffers from a large memory footprint - constraints here cause more GC than would otherwise be the case, resulting in higher latency. This is bad for GUIs, but less important for server contexts.
Other problem areas result from the lack of destructors. Many programming techniques result in objects to be created for very short term use. Plus some objects have outside resources - like GUI widgets or connections. These resources can be held onto until GC - way beyond the time the object would have been freed in, say, C++.
These things can be programmed around (apart from JVM startup time), but it does mean that it is easier to write faster code in some other languages.
SWT exists because AWT and Swing didn't meet the needs of the project. If Sun had been sensible with Swing, it could have produced something responsive and useful like SWT. IF SWT were part of the Java runtime, would you make the same point?
All GUI features have to hook into the OSes graphics library at some point - making them native. Third party native hooks versus built-in hooks - a bit of a fine line there. Especially since SWT runs on most platforms, and platforms that aren't supported could be ported since SWT is OSS.
It'd be nice if you'd acutally give some examples.
Are you refering to language features? Maybe there's some syntax that you're fond of which Java doesn't support?
Since you don't give any details, it's kind of hard to guess.
If it's library features, you'd be hard pushed to find a wider selection of libraries anywhere.
Maybe the C++ STL, but that's rather limited in scope... 99% of apps don't require anything in the STL, even though the STL would probably help 99% of apps.
Perhaps it's the language itself? You want operator overriding? It's desperately important to your project?
Or native compiling? ('course you could try gcj)
Maybe you want different kinds of heaps, or more control over object destruction?
In those cases, you're out of luck, because they are against the basic direction of Java.
Seriously, I'll bet the view from the moon or other Earth orbit, would be spectacular. Imagine: Mercury, Earth, Venus and Saturn together in the sky...
Mercury is actually quite hard to see because it's close to the sun - you can only catch it at certain times of the year and only ever close to dawn and dusk.
Venus is similar - but less so.
Saturn is often in the sky, and is a beautiful sight through a telescope.
I can't wait to see them all so close together - Let's hope for clear skies!
The point you missed is that P2P (amongst other things) can easily saturate your upstream. Once it's saturated, your downstream activities, like browsing, are affected.
Absolutely true about broadband upstream/downstream. Although, many people are using enough upstream these days that saturation is a problem - TCP actually chokes in both directions when either is saturated. This is because every packet is ACKnowledged - and there is a maximum window for sending packets without receiving an ack.
(So P2P users beware - ask your ISP for symmetrical!)
As for the POTS modem, the upstream isn't seperate from the downstream. When modems negotiate, they pick different frequencies - if they didn't the signals would be inseperable.
Complicating this is the 56k modem, which actually uses the fact that the analog signal is digitized prior to funneling down a trunk. Because this happens relatively locally, much of the signal survives the local loop, and the ISP recieves a digital signal, and doesn't need to demodulate in the same way.
Unfortunately, under the law, accessing a computer system without authorization is a very serious crime.
And furthermore, the courts have decided that violating an acceptable use policy amounts to accessing the computer without authorization.
Worse, it is accepted within the courts that an existing "terms of use" or whatever does not have to have been read nor accepted for it to be enforceable.
It is presumed that such a policy exists, and it is the burden of the user to find and read it.
It sucks! I am not a lawyer, this is not legal advice
It's extra overhead, because the messages can't be batched. When a zombie sends messages it opens an SMTP connection to a server, then sends a message to a bunch of recipients.
Ok, so it's not much.
You're kidding, right? Once a machine is rooted, down goes the firewall.
This is true, but only so far as it's a possibility. Plus many of us use a hardware firewall. Rootkits won't beat that.
Plus all the time the zombie's host is offline, the clients aren't getting their messages. And many ISPs have restrictions on their customers running servers - all the incoming connections would be a red flag.
When the zombie host changes IP - oops all those messages vanish.
Plus the zombie has to know the IP address, many hosts are using NAT.
I don't get it. How is that a relief? Who would do that? How is that substantially different from SMTP, where I know the transmitting IP address and can determine if they are a spam sender/relay?
Today, the SMTP client doesn't know the email is spam. The recipient connects to their ISP (for example) and then it's determined that the message is unwanted. The ISP doesn't drop it. In addition, the from address is spoofed. So it's very differnt. - If you spoof the address the recipients don't get their messages!
It would make identifying the senders trivial. Then something can be done.
They can send out LESS traffic (just notifications)...
This is entirely true. But they get more incoming traffic, with extra overhead.
Zombie PC's will still be the preferred senders.
You will still be able to host messages on any machine and send out receipts from other machines.
XP service pack 2 brings a software firewall by default. When incoming connections are prevented, zombies will be unable to host.
And it will be costly to set up a permanent host with enough bandwidth. Sure you can still spam but how much more is it gonna cost when you can't use zombies.
You didn't mention that the zombies could still send messages from the hosts email accounts. This is true, but immediately idenitifies the zombie!
Slashdot Mirror
Programmers have a long history of writing programs with coffee or other caffeinated beverage.
It was far faster and more responsive than any Swing app then, and it's better now, even given that it's much bigger and more feature rich.
Given 1ghz and 512Mb and you should be in good shape - on Linux.
Upgrade your ram to at least 1Gb if you're on XP.
And, textpad+javac won't let you be nearly as productive. Especially when, under Eclipse, Alt+S, and your java file is incrementally compiled. You don't even need to think about it.
On other thing: Eclipse does more than Java. I use CDT for C & C++. Still has kinks in it, but any developer should be able to be productive with it.
It's much better to:
- Buy an extra cell phone
- Hook it to the computer
- Pay for two cell services (they have to operate simultaneously)
- Install and configure IPDrum and Skype
- Dial twice on each call
Plus, you get the benefit that there's 3 or 4 extra single points of failure, and you get to use twice the air bandwith when your calling from the same tower as the dedicated cell-phone.And I'm sure there's no degradation in quality!
That's not much of an argument against open sourcing Java.
Hello, hello, hello, hello, hello, hello, hello, hello, hello, hello, hello, hello...
Geez it sounds crowded - are you at a party?
SWT is not a modification per se, but it does offer a replacement for AWT or Swing; however, since it does not form part of the JVM and it uses native code, programmers can't rely on it being available, as they can for other APIs.
The native code part is key, because it means you can't ship the SWT library with the app. And you can't assume it's already there.
Acutally you can, but:
If Java were open source, SWT could be incorperated, and become a standard API supported on every platform that Java runs on.
...who pictured packs of "dog" bots infiltrating and taking down the spam zombie nets?
Keep paying Microsoft their licensing fee:
Come on! Get with the program. QUIT FUNDING THIS CRAP!
There are some documented areas, but I haven't run into any instances that weren't documented.
I think Sun has had an exemplary record in backwards compatability, especially when compared to other platform vendors, and when you consider that Java runs on so many OSes.
My biggest gripe about Sun with regard to Java is in the JDBC specification.
For example - Can a Connection be used by more than one Thread?
Anwser: It's not detailed in the specification - it's vendor dependant.
This is a bad thing to do in a specification - it means that as a coder you can't rely on one kind of behavior. Or you have to limit to one vendor.
Perhaps you're refering to non Java-platform APIs, like those in the sun. packages?
Shame Java can't be preloaded with Linux distro's!
I mean - imagine if there were a 100% platform independent API that you could write against that was avaible on most platforms - already integrated with the environment.
And without the minor differences you find in *nixes, resulting in all the config.h and autoconf messes.
And from GP:
Performance wise, Java suffers from large start-up time, since the JVM has to start. It also suffers from a large memory footprint - constraints here cause more GC than would otherwise be the case, resulting in higher latency. This is bad for GUIs, but less important for server contexts.
Other problem areas result from the lack of destructors. Many programming techniques result in objects to be created for very short term use. Plus some objects have outside resources - like GUI widgets or connections. These resources can be held onto until GC - way beyond the time the object would have been freed in, say, C++.
These things can be programmed around (apart from JVM startup time), but it does mean that it is easier to write faster code in some other languages.
If Sun had been sensible with Swing, it could have produced something responsive and useful like SWT.
IF SWT were part of the Java runtime, would you make the same point?
All GUI features have to hook into the OSes graphics library at some point - making them native.
Third party native hooks versus built-in hooks - a bit of a fine line there. Especially since SWT runs on most platforms, and platforms that aren't supported could be ported since SWT is OSS.
Are you refering to language features? Maybe there's some syntax that you're fond of which Java doesn't support?
Since you don't give any details, it's kind of hard to guess.
If it's library features, you'd be hard pushed to find a wider selection of libraries anywhere.
Maybe the C++ STL, but that's rather limited in scope... 99% of apps don't require anything in the STL, even though the STL would probably help 99% of apps.
Perhaps it's the language itself? You want operator overriding? It's desperately important to your project?
Or native compiling? ('course you could try gcj)
Maybe you want different kinds of heaps, or more control over object destruction?
In those cases, you're out of luck, because they are against the basic direction of Java.
Nice diatribe, but fairly empty of content.
ok ok stop throwing things!
Seriously, I'll bet the view from the moon or other Earth orbit, would be spectacular.
Imagine: Mercury, Earth, Venus and Saturn together in the sky...
Oh to be an astronaut...
Venus is similar - but less so.
Saturn is often in the sky, and is a beautiful sight through a telescope.
I can't wait to see them all so close together - Let's hope for clear skies!
The point you missed is that P2P (amongst other things) can easily saturate your upstream. Once it's saturated, your downstream activities, like browsing, are affected.
Ok - I didn't fully understand before.
I haven't worked out any details yet, but I'm sure the notification could include the actual FQDN of the server hosting the message.
SMTP uses the MX records, for the recipient; but this would not be necessary for finding the "repository".
So in your example the notification says:
from: julesh@example.com
to: someone@example.co.uk
x-pickup-at: pmtp.example.net
Although, many people are using enough upstream these days that saturation is a problem - TCP actually chokes in both directions when either is saturated.
This is because every packet is ACKnowledged - and there is a maximum window for sending packets without receiving an ack.
(So P2P users beware - ask your ISP for symmetrical!)
As for the POTS modem, the upstream isn't seperate from the downstream. When modems negotiate, they pick different frequencies - if they didn't the signals would be inseperable.
Complicating this is the 56k modem, which actually uses the fact that the analog signal is digitized prior to funneling down a trunk. Because this happens relatively locally, much of the signal survives the local loop, and the ISP recieves a digital signal, and doesn't need to demodulate in the same way.
So, you can never get 56k going modem to modem.
Noye: I thought the upload max was 36kbs?
The only requirement is that the message exists at the pickup address.
There's no need for the "from" email address to map to anything - you still know where it's come from.
Wouldn't you?
That deserves a bonus.
And furthermore, the courts have decided that violating an acceptable use policy amounts to accessing the computer without authorization.
Worse, it is accepted within the courts that an existing "terms of use" or whatever does not have to have been read nor accepted for it to be enforceable.
It is presumed that such a policy exists, and it is the burden of the user to find and read it.
It sucks!
I am not a lawyer, this is not legal advice
Not that I'd recommend it - you'd be better off with a nix variant, but still...
Ok, so it's not much. This is true, but only so far as it's a possibility. Plus many of us use a hardware firewall. Rootkits won't beat that.
Plus all the time the zombie's host is offline, the clients aren't getting their messages. And many ISPs have restrictions on their customers running servers - all the incoming connections would be a red flag.
When the zombie host changes IP - oops all those messages vanish.
Plus the zombie has to know the IP address, many hosts are using NAT.
Today, the SMTP client doesn't know the email is spam. The recipient connects to their ISP (for example) and then it's determined that the message is unwanted. The ISP doesn't drop it. In addition, the from address is spoofed.So it's very differnt. - If you spoof the address the recipients don't get their messages!
It would make identifying the senders trivial. Then something can be done.
And it will be costly to set up a permanent host with enough bandwidth. Sure you can still spam but how much more is it gonna cost when you can't use zombies.
You didn't mention that the zombies could still send messages from the hosts email accounts. This is true, but immediately idenitifies the zombie!