No one is forcing anyone to close open relays, and no one is forcing anyone to accept email from everyone.
All those admins who make use of blacklists that contain open relays are breaking the contract of email and trying to use bullying tactics to force others to close their relays. Sure you can choose who to accept mail from, but don't try and justify blacklisting all open relays just because some are used for spam.
My experience has been with WaveStaff. I found them to provide quality people and more importantly --at least IMHO-- expect to work with the person they are placing for the long term. Therefore they only seek out individuals that they can have a long term relationship with.
Seems like your problem is one of architecture and not the underlying platform. You suggest that you would move away from a dynamic site built with J2EE to a generated static site built with PHP. If you really feel having a generated static site is the best way to go then why not leverage your existing Java infrastructure and have it generate a static site instead of server a dynamic one? And if you can levarge your existing code base for that, then writing a new code base could still be done in Java, so I am not sure why you are pointing to Java as the problem.
With all the above being said, I don't know what is wrong with your system, but it isn't that hard to build a dynamic site in Java that meets your scabilitiy needs. All you need is a good caching strategy and you are set. Generally speaking, a good caching strategy coupled with a dynamic site can lead to as good as or better peformance than a static site.
I'm generally a big fan of keeping work in-house because I feel that model creates the best software. This is because the developers have access to the customers and understand the business better than any outside consultant will. Further, they have a vested interested in the software.
With all that being said, offshoring can be good for certain types of projects. Any infrastructure style project where the complexity is high and the specifications known and well documented can benefit from offshoring. For example, imagine if your company had some need for a JVM to be implemented. Building a JVM is a huge project, but the specification known, well documented, and there are plenty of tests available. Such a project would be perfect for outsourcing since the skills required are specialized, but the cost of outsourcing could be emense. This is where offshoring comes in since it provides the same benefits as outsourcing without all costs.
BTW, the reason for this is that Apple got off their but and made sure Java works like a chap on Mac OS X. They implemented the Aqua LAF using their native widgets, so there is no difference between Java and native applications. The same could have been true for Windows, but obviously Microsoft felt different.
Why should an ISP believe SPEWS unless the ISP can generate evidence of their own? Again, the problem here is you want the ISP to police the data they transmit, which has nasty side-effects.
I just don't see how blacklist advocates can see the problem of SPAM as black and white; it is much more complicated than that.
Whether server admins chose to use SPEWS or not is generally a decision they make on their own that affects their entire organization. I have know of at least two server admins who lost their jobs because the company found out later they were losing email because the server's email policy.
Deciding to use a blacklist is a serious commitment for an organization to make that should not be taken lightly. I advise all admins to get approval as far up the chain as they can for their own protection. You haven't seen mad until your CEO learns about customers who can't email them.
Come on! How are you going to enforce the AUP without first finding out if they are violating it? Maybe you expect to provide the ISP with evidence that one of their customers is violating the AUP. How is the ISP supposed to regard your evidence? Unless they can determine on their own what a customer is doing there is no way they can enforce the AUP.
ISPs are in the business of transmitting data. When you start forcing them to inspect the data they transmit you are asking for a whole host of larger problems than SPAM.
SPAM is a tough problem, but that doesn't mean the solution is to blame or attach --which is what you are suggesting-- anyone.
Are you serious? Imagine what would happen if we applied the same logic to other problems facing society. I can see it now, arresting whole neighborhoods because a single criminal was living there.
SPAM is a real problem and it won't be solved by brain-dead solutions.
Since it sounds like the company in question doesn't really know what happened and probably never will, it is much easier to fire you than face future liability if you stay.
When asked about dealings with Linus, SCO indicated that they had only done email exchanges and that Linus had indicated the situation was a contract dispute and he was staying out of it. McBride then went on to say that as of today everything has changed. SCO stated that everyone involved with Linux from the users to the contributors to the distributors are either violation of their Unix copyrights or are contributing to the violation. They also stated that they could sue for copyright violations without showing damages.
Although they didn't specify which files or lines of code are the problem, they were pretty specific that it was NUMA, SMP, and RCU that was introduced by vendors in the 2.4 kernel.
Listening in on the SCO conference call today, they announced that all Linux 2.4 users are in violation of their Unix copyrights. They will now be selling a UnixWare license to Linux users to become compliant.
Slashdot Mirror
Talk about famous last words!
No one is forcing anyone to close open relays, and no one is forcing anyone to accept email from everyone. All those admins who make use of blacklists that contain open relays are breaking the contract of email and trying to use bullying tactics to force others to close their relays. Sure you can choose who to accept mail from, but don't try and justify blacklisting all open relays just because some are used for spam.
My experience has been with WaveStaff. I found them to provide quality people and more importantly --at least IMHO-- expect to work with the person they are placing for the long term. Therefore they only seek out individuals that they can have a long term relationship with.
Seems like your problem is one of architecture and not the underlying platform. You suggest that you would move away from a dynamic site built with J2EE to a generated static site built with PHP. If you really feel having a generated static site is the best way to go then why not leverage your existing Java infrastructure and have it generate a static site instead of server a dynamic one? And if you can levarge your existing code base for that, then writing a new code base could still be done in Java, so I am not sure why you are pointing to Java as the problem.
With all the above being said, I don't know what is wrong with your system, but it isn't that hard to build a dynamic site in Java that meets your scabilitiy needs. All you need is a good caching strategy and you are set. Generally speaking, a good caching strategy coupled with a dynamic site can lead to as good as or better peformance than a static site.
Maybe you didn't read the whole thing. it stated that $15,530,000 was generated in the last two quarters. So that means...
$8,250,000 + $7,280,000 = $15,530,00
I'm generally a big fan of keeping work in-house because I feel that model creates the best software. This is because the developers have access to the customers and understand the business better than any outside consultant will. Further, they have a vested interested in the software.
With all that being said, offshoring can be good for certain types of projects. Any infrastructure style project where the complexity is high and the specifications known and well documented can benefit from offshoring. For example, imagine if your company had some need for a JVM to be implemented. Building a JVM is a huge project, but the specification known, well documented, and there are plenty of tests available. Such a project would be perfect for outsourcing since the skills required are specialized, but the cost of outsourcing could be emense. This is where offshoring comes in since it provides the same benefits as outsourcing without all costs.
In Soviet Russia, satellites drop you!
Find a regex engine for Java? You mean like the one that is included in JDK 1.4?
BTW, the reason for this is that Apple got off their but and made sure Java works like a chap on Mac OS X. They implemented the Aqua LAF using their native widgets, so there is no difference between Java and native applications. The same could have been true for Windows, but obviously Microsoft felt different.
Using Swing and the Aqua LAF sure does look beautiful and it is quite fast on my Mac.
see title
Why should an ISP believe SPEWS unless the ISP can generate evidence of their own? Again, the problem here is you want the ISP to police the data they transmit, which has nasty side-effects.
I just don't see how blacklist advocates can see the problem of SPAM as black and white; it is much more complicated than that.
Whether server admins chose to use SPEWS or not is generally a decision they make on their own that affects their entire organization. I have know of at least two server admins who lost their jobs because the company found out later they were losing email because the server's email policy.
Deciding to use a blacklist is a serious commitment for an organization to make that should not be taken lightly. I advise all admins to get approval as far up the chain as they can for their own protection. You haven't seen mad until your CEO learns about customers who can't email them.
Come on! How are you going to enforce the AUP without first finding out if they are violating it? Maybe you expect to provide the ISP with evidence that one of their customers is violating the AUP. How is the ISP supposed to regard your evidence? Unless they can determine on their own what a customer is doing there is no way they can enforce the AUP.
ISPs are in the business of transmitting data. When you start forcing them to inspect the data they transmit you are asking for a whole host of larger problems than SPAM.
SPAM is a tough problem, but that doesn't mean the solution is to blame or attach --which is what you are suggesting-- anyone.
Are you serious? Imagine what would happen if we applied the same logic to other problems facing society. I can see it now, arresting whole neighborhoods because a single criminal was living there.
SPAM is a real problem and it won't be solved by brain-dead solutions.
I for one welcome our new bourne again overlords.
Since it sounds like the company in question doesn't really know what happened and probably never will, it is much easier to fire you than face future liability if you stay.
It is funny that you associate price with the need to test it considering that the highest priced cars generally aren't test driven.
Two words; labor union!
When asked about dealings with Linus, SCO indicated that they had only done email exchanges and that Linus had indicated the situation was a contract dispute and he was staying out of it. McBride then went on to say that as of today everything has changed. SCO stated that everyone involved with Linux from the users to the contributors to the distributors are either violation of their Unix copyrights or are contributing to the violation. They also stated that they could sue for copyright violations without showing damages.
You are not entirely correct. As have others have shown, they are still distributing a Linux kernel via FTP.
Although they didn't specify which files or lines of code are the problem, they were pretty specific that it was NUMA, SMP, and RCU that was introduced by vendors in the 2.4 kernel.
In addition, they have said that all contributors to the Linux kernel will NOT be protected if they purchase this license to UnixWare.
Listening in on the SCO conference call today, they announced that all Linux 2.4 users are in violation of their Unix copyrights. They will now be selling a UnixWare license to Linux users to become compliant.