As a provider, you are probably not in a position to do this. Not using SPEWS, or using it just to tag mail or subject it to more scrutiny, may be more appropriate for you. Using SPEWS to block mail means taking the position that you hate even having spam attempts banging on the port 25 door, and want the ISPs that harbor spammers to stop or be driven out of business... even if that means upsetting some of the customers of that ISP long enough to make them move (or at least to threaten to move). If you run your own network, you can get away with that, depending on what your business does. An ISP would have a lot harder time doing it across the board, though if you can selectively enable or disable it on a per-customer basis and let them choose for themselves, then you might have something going there.
In the referenced page, it says to ask SPEWS to punch a hole in the listing. SPEWS generally does not do that, based on my observations, and the observations of others as reported. It may be the case that SPEWS will do so on a very short term basis if a customer reports they have contacted someone high up in the ISP to hopefully get the problem dealt with. It also may be that SPEWS will short term list a customer who provides some substantial evidence that they are moving away from that ISP, and that the move (as is usual in the industry) takes a little time to get the new circuits in, and such. If the customer shows the new IPs the new ISP has assigned to them already, it might even be believable.
I'm sure the professional spammers would love to do that. It may even be possible they are responsible for that happening to DSL Reports that very way. But that effort could have also been thwarted by the ISP (NAC.net according to the article, which I have not had time to verify) properly enforcing their AUP/TOS. The problem is, the ISP didn't do The Right Thing [TM], so they ended up in SPEWS, dragging DSL Reports in along with them. Maybe the spammers knew that the ISP would fail and decided to proceed. But regardless, the ISP has culpability here.
it is about trying to get high-level service providers to violate their contracts.
ISPs that have contracts like that to provide services to spammers, or lower level ISPs that provider services to spammers, should be forced to violate them. They are supporting the violation of other people's networks, mail servers, and mailboxes. SPEWS in fact has been successful at turning several ISPs around, by making them painfully aware of the consequences of harboring spammers. I only wish more ISPs would quit providing services to spammers once this is made known to them.
They publish lists which are in turn downloaded by automated scripts and are applied to e-mail servers as filters. They are aware of this.
While SPEWS probably is aware that many networks use their published data to utterly refuse mail, they are also aware that many networks use their published data to subject mail from those addresses to more extensive testing, or to separate that mail into separate folders, or merely to tag it as possible spam. SPEWS surely is aware of this since it is so obvious. Are you aware of this?
As a customer of a listed ISP, don't bother. SPEWS will not deal with you. They will only deal with the ISP. If you want to post to say some information about the case, don't say you are a customer, and don't say you are wanting your little piece of the ISP's space excluded; it won't happen that way. Just spell out what steps have been taken to terminate all services to a spammer, with the proper SPEWS record reference.
Be sure that all services are terminated, not just email access. If the ISP or any customer of the ISP hosts even web pages, DNS, or anything else for the spammer, the listing will stay in place as long as that spammer spams from anywhere in the world (or even pays a spammer to spam for them to advertise their products). It is not necessary for the actual spam to ever have come from an ISP's network for that network to be listed; it's about services to a spammer. Be certain that all services are cut off before posting, or you'll lose credibility if you say something that isn't true. And the people who run SPEWS will never, ever, contact you... at least not in the name of SPEWS.
There is no collective involved when an ISP is listed in SPEWS. It is the ISP that is responsible for the problem being so widespread and persistent in their network, and it is the ISP that is being punished. Their customers are along for the ride because of the ISP. If an exception were made to permit the good customers to get through, then it would negate all the effort to get the ISP to change their ways. One aspect of what this is about is to put that ISP's financial revenue at risk. How do you do that? You scare the customers away. As ugly as it might seem, it actually has turned around many ISPs, so it does work. Unfortunately, it has not worked on all ISPs, but those where it has failed have pretty much become total spammer havens or were really operated as a front by spammers.
A trespasser may, or may not, use my phone line and prevent me from sending or receiving faxes. A trespasser may, or may not, be using my paper and printer toner. But a junk faxer is most certainly taking these things for their own intentions, and depriving me of the use I had intended for my property. That is most definitely theft.
The phone line time, and printer toner, is my property that they are taking from me. That is theft. Want a different term? OK, cyburglary. There. happy? I still prefer theft.
I'm less likely to classify trading of copyrighted MP3s as theft when it is a case of someone who never would have bought that music by paying for it in the first place. No money is lost because that person would not have been a customer, anyway. No resources are lost because the bandwidth was not taken from the owners of the copyright. Of course, where someone trades to get something for free when they would have, or could have, paid for it, that does deprive the copyright owner of legitimate revenues.
If the junk faxer calls when the phone would not be used, such as maybe at night, it could be argued the phone time is not lost. But they cannot be sure that such a phone number is not used for things like lots of batch reports coming in from field offices overnight. In any case, the loss of toner for the print is real. It is theft without a doubt.
People should just stop suing junk faxers and start putting them in jail. Advertising should pay for the media it comes in through, not steal from it. Junk faxing, and spam, is theft, which is a crime, and should be dealt with as a criminal case (which in many jurisdictions can be brought to court even by average citizens).
Nice. You have a lot more than I do. I added yours to mine. BTW, mine are in the form of entries in/etc/named.conf pointing to a zone file that wildcards an A record pointing to a special web server that always gives a 1x1 pixel transparent GIF regardless of the requested URI. It looks cleaner that way.
SCO claims that their contract with IBM gives SCO all rights to any improvements to these Unix licensed products. In a way, that's kind of like GPL, except for corporate greed, although it seems that it did not provide for any means for SCO to actually get that source code they claim to own. SCO believes that IBM did develop improvements for AIX and/or Dynix/ptx (I presume the original Sequent license for Dynix had a similar provision), and that IBM also contributed those improvements to Linux. SCO thus believes that code they own is in Linux, but cannot positively identify it because they don't have the AIX and Dynix/ptx code to cross check with. Apparently SCO would assert that any code found in AIX or Dynix/ptx is either code originally licensed, or code that was added later by IBM and still covered under the license agreement.
The clause that gives SCO ownership of improvements to AIX and Dynix/ptx is itself suspect. If there is no provision for transferring that code to SCO, then how is such a clause to have any meaning. And how can it be determined if any improvements were developed by IBM or simply acquired by IBM under other licensing (including GPL) and integrated? If I had sold a piece of code to IBM that would improve AIX and/or Dynix/ptx, a contract between SCO and IBM cannot take ownership of the rights to that code away from me (and I have no contract with SCO). It would not be any different if IBM did this with GPL code. Nor would it make any difference if IBM did this with BSD code. And it wouldn't even make any difference with public domain code (since the public by definition has all rights to use it, so any ownership is moot in that case).
Suppose there is some common code in both Linux and AIX. SCO might well assert ownership of that code. But what if the code was originally in Linux and subsequently put in AIX (if it is GPL that might be a problem, but suppose it is a public domain, or BSD licensed piece of code). What if the code was in another free licensed OS like FreeBSD, and subsequently put in both Linux and AIX (in either order of time). Or it could be public domain code. SCO won't have any ownership rights to that code (although they could likely have usage right like anyone else).
SCO will have to do more than merely show that some code is in both Linux and AIX. They will have to prove that IBM developed the code and put it in AIX first, before putting it in Linux. If IBM put the code in Linux first, even under a GPL license, as original owner they also have the right to put it in another system under another license... and more importantly, cannot subsequently withdraw the rights already granted under the first contribution. So if they put code in Linux under GPL, then put it in AIX under SCO's assertion of ownership rights through the Unix license (which is in dispute), IBM would not be obligated to make AIX open under GPL (since it is not putting it as GPL'd code in AIX). And since the rights under GPL are already released, even if SCO prevails to own the code because IBM developed it, it has no means to withdraw the rights already released under GPL. What SCO would have to prove is that the development was done at IBM, under IBM ownership, for AIX and/or Dynix/ptx, now subject to the disputed license, then donated to Linux under GPL. Just looking at the AIX and Dynix/ptx code isn't going to show that.
Suppose the worst happens and SCO prevails and the courts believe that certain (at that point identified in court) pieces of code are owned by SCO and their unlicensed distribution and use infringes on SCO's intellectual property. Linux can deal with this very effectively by simply releasing a new version (wanna place bets on how quickly that will happen) without any of that code from IBM. SCO's current case is against IBM, not against Linux. So even if SCO were to prevail, their recovery under that case is only against IBM. There will be two areas of infringement in Linux to consider: the past and the future.
Good corporate citizen? That doesn't mean much coming from a company that ships jobs away from its home country. I think they mean "Good citizen among a nation of greedy corporations".
SCO believes that their license with IBM entitles SCO to ownership of all code IBM develops and puts in products licensed to IBM by SCO. SCO believes some of that code IBM has put in AIX and/or Dynix/ptx was also put in Linux. So SCO's claim is "We don't know what code is ours, but we know IBM put it in Linux". Of course that can't account for any code IBM took from BSD and put in AIX and/or Dynix/ptx (which is in compliance with the BSD license), which SCO cannot possibly own, and which could also be in Linux, and might no longer even be in BSD. It also cannot account for any code IBM acquired from any other parties who may have approved putting it in AIX, Dynix/pts, or Linux.
In this particular case, I do need to have my files visible as whole files. That was the big reason I didn't go with CVS. For what I needed to have it do, it wasn't that big a deal to implement it. I have done other projects by using some package to do it, and it usually ends up being more work than if I had just done it myself. The setup I have right now took about 1 hour to implement and has been virtually zero maintenance (5 minutes to add IPv6, another 5 minutes to add SPF).
I considered CVS, but in the end I wanted to have a whole archive with a sliding window expiration. CVS could have done that but the setup was more complex than I have now. For a much larger setup, maybe CVS would be better, but I'd probably end up doing it in MySQL instead (for more flexibility in managing the data). As for troubleshooting, I generally don't encounter that as a problem.
The DNS protocol uses 32 bits for serial number. So what you should be saying is that we should be upgrading the DNS protocol before 2038, with enough lead time so all the network operators will have time to make the switch. That means we need to expand the DNS protocol to more than 32 bits (40 bits should actually be enough) by around 2008.
That could be done. But rather than have to process it like that and either store or parse the serial value to be updated, the way I do it to take the master file (not a normal zone format) I use to generate each zone, get its last modification date from the filesystem, and produce the serial number from that. This way, I can still derive the date and time, to a 4 second resolution, from the serial number, and back track it to the archived master files if there are any issues to figure out. It's basically simpler with more benefits.
3. Your caching nameservers just flushed cache or restarted, and thus they have no idea where any of the top level domains are, and have to ask the root servers (provided in the hints file) where they are. Also, this will happen again in 2 days when those NS records, and their corresponding A records, expire from the cache.
My serial number format lasts longer than Verisign's, and I still get more than 100 updates a day out of it. In fact it will last until 07:06:36 Tuesday 2 October 2096 while staying in just 9 digits (which it has been since 15:06:40 Saturday 4 September 1982). After that it goes to 10 digits, but still remains a positive signed 32 bit integer until 12:56:28 Wednesday 16 March 2242, and if unsigned 32 bit integer works everywhere else, it will go all the way to 01:53:00 Wednesday 30 May 2514.
Instead of being the count of number of seconds, as Verisign plans to use, mine is 1/4 of that value. Basically, I take the system time() value and divide by 4. By treating that value as an unsigned quantity, I won't have the Y2038 bug, either. That logic will work until 06:28:15 Sunday 7 February 2106 (past the 9 digit limit). And I can do 21600 updates a day (one every 4 seconds).
Java just-in-time compilation will fail to perform well in certain cases. In fact, even if it were to completely compile itself into native code right from the outside, it will still fail to perform well in these certain cases.
The cases I speak of are when multiple processes are using the same executable code, which for Java will be the class file, and for compiled C source will be an ELF executable image. When Linux and other Unix systems run these programs, the original executable image is memory mapped by the kernel or the run time loader. At this point the pages are all shared between multiple processes. The run time loader will link in necessary libraries, which will modify a few pages and result in them not being shared due to copy on write. But these are generally the jump tables and few other things that happen to be in the same page area. Most of the executable machine code is not modified.
When a Java class file is loaded, the executable as far as the system sees it to be is the Java run time engine itself. When it compiles the Java byte code at run time, it can produce good performing code, but it can't cause that code to be shared in memory with other processes that were running the same Java class file.
OTOH, Java applications tend to be run as threads, not multiple processes. As long as the compiling of the code is done so that there are no thread collisions in that (you'd know pretty quickly if there were), then you have one copy of the code shared between all threads.
The use of threads and Java is a tradeoff. You get the better program protection of Java (and not programming with pointers, which the average programmer is not capable of dealing with very well), but you also get the risk of threads (it's still possible to program badly for threads even in Java, and get data crossover where it should not be).
But when you see benchmarks that say one is better than the other, you better have a close look and see exactly what kind of thing is being tested, including whether multiple instances in processes, vs. multiple instances in threads, is being done. In some cases (like when it has to be processes, not threads) you might want to consider using a Java to native machine code compiler, or if you can handle it, program in C or C++.
Investors are no fools. The good ones will make money on this. Since the price will go up because there are in fact many fools in the market, the savvy investor will take the ride up to the top to pick the fruit. They will be the ones to sell out first. The best of the best will see the right signals and sell at the highest point, leaving the fool investors who bought it at various prices across the whole range dealing with trying to recover a meager few cents per share once the whole thing crashes.
Many investors are anticipating a buyout, perhaps by IBM itself.
But this could be a while. The wheels of justice grind slowly (and sometimes run in reverse for a while). Just look at all the time it has taken to even get to arguing about discovery, and counter arguing about who's not cooperating in discovery. The crash might not happen for another year or two or maybe even longer.
If you didn't get in on SCO when it started up, then what you might want to look into doing is shorting the stock just before you think it will crash. Shorting the stock can be a lot riskier, so you better be a good investor if you want to do this. If you don't know what it means, don't even think of trying it.
Slashdot Mirror
... as soon as I pass the Microsoft Certified Medical Physician test.
As a provider, you are probably not in a position to do this. Not using SPEWS, or using it just to tag mail or subject it to more scrutiny, may be more appropriate for you. Using SPEWS to block mail means taking the position that you hate even having spam attempts banging on the port 25 door, and want the ISPs that harbor spammers to stop or be driven out of business ... even if that means upsetting some of the customers of that ISP long enough to make them move (or at least to threaten to move). If you run your own network, you can get away with that, depending on what your business does. An ISP would have a lot harder time doing it across the board, though if you can selectively enable or disable it on a per-customer basis and let them choose for themselves, then you might have something going there.
In the referenced page, it says to ask SPEWS to punch a hole in the listing. SPEWS generally does not do that, based on my observations, and the observations of others as reported. It may be the case that SPEWS will do so on a very short term basis if a customer reports they have contacted someone high up in the ISP to hopefully get the problem dealt with. It also may be that SPEWS will short term list a customer who provides some substantial evidence that they are moving away from that ISP, and that the move (as is usual in the industry) takes a little time to get the new circuits in, and such. If the customer shows the new IPs the new ISP has assigned to them already, it might even be believable.
I'm sure the professional spammers would love to do that. It may even be possible they are responsible for that happening to DSL Reports that very way. But that effort could have also been thwarted by the ISP (NAC.net according to the article, which I have not had time to verify) properly enforcing their AUP/TOS. The problem is, the ISP didn't do The Right Thing [TM], so they ended up in SPEWS, dragging DSL Reports in along with them. Maybe the spammers knew that the ISP would fail and decided to proceed. But regardless, the ISP has culpability here.
ISPs that have contracts like that to provide services to spammers, or lower level ISPs that provider services to spammers, should be forced to violate them. They are supporting the violation of other people's networks, mail servers, and mailboxes. SPEWS in fact has been successful at turning several ISPs around, by making them painfully aware of the consequences of harboring spammers. I only wish more ISPs would quit providing services to spammers once this is made known to them.
While SPEWS probably is aware that many networks use their published data to utterly refuse mail, they are also aware that many networks use their published data to subject mail from those addresses to more extensive testing, or to separate that mail into separate folders, or merely to tag it as possible spam. SPEWS surely is aware of this since it is so obvious. Are you aware of this?
As a customer of a listed ISP, don't bother. SPEWS will not deal with you. They will only deal with the ISP. If you want to post to say some information about the case, don't say you are a customer, and don't say you are wanting your little piece of the ISP's space excluded; it won't happen that way. Just spell out what steps have been taken to terminate all services to a spammer, with the proper SPEWS record reference.
Be sure that all services are terminated, not just email access. If the ISP or any customer of the ISP hosts even web pages, DNS, or anything else for the spammer, the listing will stay in place as long as that spammer spams from anywhere in the world (or even pays a spammer to spam for them to advertise their products). It is not necessary for the actual spam to ever have come from an ISP's network for that network to be listed; it's about services to a spammer. Be certain that all services are cut off before posting, or you'll lose credibility if you say something that isn't true. And the people who run SPEWS will never, ever, contact you ... at least not in the name of SPEWS.
There is no collective involved when an ISP is listed in SPEWS. It is the ISP that is responsible for the problem being so widespread and persistent in their network, and it is the ISP that is being punished. Their customers are along for the ride because of the ISP. If an exception were made to permit the good customers to get through, then it would negate all the effort to get the ISP to change their ways. One aspect of what this is about is to put that ISP's financial revenue at risk. How do you do that? You scare the customers away. As ugly as it might seem, it actually has turned around many ISPs, so it does work. Unfortunately, it has not worked on all ISPs, but those where it has failed have pretty much become total spammer havens or were really operated as a front by spammers.
A trespasser may, or may not, use my phone line and prevent me from sending or receiving faxes. A trespasser may, or may not, be using my paper and printer toner. But a junk faxer is most certainly taking these things for their own intentions, and depriving me of the use I had intended for my property. That is most definitely theft.
The phone line time, and printer toner, is my property that they are taking from me. That is theft. Want a different term? OK, cyburglary. There. happy? I still prefer theft.
I'm less likely to classify trading of copyrighted MP3s as theft when it is a case of someone who never would have bought that music by paying for it in the first place. No money is lost because that person would not have been a customer, anyway. No resources are lost because the bandwidth was not taken from the owners of the copyright. Of course, where someone trades to get something for free when they would have, or could have, paid for it, that does deprive the copyright owner of legitimate revenues.
If the junk faxer calls when the phone would not be used, such as maybe at night, it could be argued the phone time is not lost. But they cannot be sure that such a phone number is not used for things like lots of batch reports coming in from field offices overnight. In any case, the loss of toner for the print is real. It is theft without a doubt.
People should just stop suing junk faxers and start putting them in jail. Advertising should pay for the media it comes in through, not steal from it. Junk faxing, and spam, is theft, which is a crime, and should be dealt with as a criminal case (which in many jurisdictions can be brought to court even by average citizens).
Nice. You have a lot more than I do. I added yours to mine. BTW, mine are in the form of entries in /etc/named.conf pointing to a zone file that wildcards an A record pointing to a special web server that always gives a 1x1 pixel transparent GIF regardless of the requested URI. It looks cleaner that way.
SCO claims that their contract with IBM gives SCO all rights to any improvements to these Unix licensed products. In a way, that's kind of like GPL, except for corporate greed, although it seems that it did not provide for any means for SCO to actually get that source code they claim to own. SCO believes that IBM did develop improvements for AIX and/or Dynix/ptx (I presume the original Sequent license for Dynix had a similar provision), and that IBM also contributed those improvements to Linux. SCO thus believes that code they own is in Linux, but cannot positively identify it because they don't have the AIX and Dynix/ptx code to cross check with. Apparently SCO would assert that any code found in AIX or Dynix/ptx is either code originally licensed, or code that was added later by IBM and still covered under the license agreement.
The clause that gives SCO ownership of improvements to AIX and Dynix/ptx is itself suspect. If there is no provision for transferring that code to SCO, then how is such a clause to have any meaning. And how can it be determined if any improvements were developed by IBM or simply acquired by IBM under other licensing (including GPL) and integrated? If I had sold a piece of code to IBM that would improve AIX and/or Dynix/ptx, a contract between SCO and IBM cannot take ownership of the rights to that code away from me (and I have no contract with SCO). It would not be any different if IBM did this with GPL code. Nor would it make any difference if IBM did this with BSD code. And it wouldn't even make any difference with public domain code (since the public by definition has all rights to use it, so any ownership is moot in that case).
Suppose there is some common code in both Linux and AIX. SCO might well assert ownership of that code. But what if the code was originally in Linux and subsequently put in AIX (if it is GPL that might be a problem, but suppose it is a public domain, or BSD licensed piece of code). What if the code was in another free licensed OS like FreeBSD, and subsequently put in both Linux and AIX (in either order of time). Or it could be public domain code. SCO won't have any ownership rights to that code (although they could likely have usage right like anyone else).
SCO will have to do more than merely show that some code is in both Linux and AIX. They will have to prove that IBM developed the code and put it in AIX first, before putting it in Linux. If IBM put the code in Linux first, even under a GPL license, as original owner they also have the right to put it in another system under another license ... and more importantly, cannot subsequently withdraw the rights already granted under the first contribution. So if they put code in Linux under GPL, then put it in AIX under SCO's assertion of ownership rights through the Unix license (which is in dispute), IBM would not be obligated to make AIX open under GPL (since it is not putting it as GPL'd code in AIX). And since the rights under GPL are already released, even if SCO prevails to own the code because IBM developed it, it has no means to withdraw the rights already released under GPL. What SCO would have to prove is that the development was done at IBM, under IBM ownership, for AIX and/or Dynix/ptx, now subject to the disputed license, then donated to Linux under GPL. Just looking at the AIX and Dynix/ptx code isn't going to show that.
Suppose the worst happens and SCO prevails and the courts believe that certain (at that point identified in court) pieces of code are owned by SCO and their unlicensed distribution and use infringes on SCO's intellectual property. Linux can deal with this very effectively by simply releasing a new version (wanna place bets on how quickly that will happen) without any of that code from IBM. SCO's current case is against IBM, not against Linux. So even if SCO were to prevail, their recovery under that case is only against IBM. There will be two areas of infringement in Linux to consider: the past and the future.
I bet the spammers will like that feature.
Good corporate citizen? That doesn't mean much coming from a company that ships jobs away from its home country. I think they mean "Good citizen among a nation of greedy corporations".
SCO believes that their license with IBM entitles SCO to ownership of all code IBM develops and puts in products licensed to IBM by SCO. SCO believes some of that code IBM has put in AIX and/or Dynix/ptx was also put in Linux. So SCO's claim is "We don't know what code is ours, but we know IBM put it in Linux". Of course that can't account for any code IBM took from BSD and put in AIX and/or Dynix/ptx (which is in compliance with the BSD license), which SCO cannot possibly own, and which could also be in Linux, and might no longer even be in BSD. It also cannot account for any code IBM acquired from any other parties who may have approved putting it in AIX, Dynix/pts, or Linux.
In this particular case, I do need to have my files visible as whole files. That was the big reason I didn't go with CVS. For what I needed to have it do, it wasn't that big a deal to implement it. I have done other projects by using some package to do it, and it usually ends up being more work than if I had just done it myself. The setup I have right now took about 1 hour to implement and has been virtually zero maintenance (5 minutes to add IPv6, another 5 minutes to add SPF).
I considered CVS, but in the end I wanted to have a whole archive with a sliding window expiration. CVS could have done that but the setup was more complex than I have now. For a much larger setup, maybe CVS would be better, but I'd probably end up doing it in MySQL instead (for more flexibility in managing the data). As for troubleshooting, I generally don't encounter that as a problem.
Let me do it. I'm not making any profit. I can run the root servers on my little Linux box. I'll just leave the phone dialed up all day long.
The DNS protocol uses 32 bits for serial number. So what you should be saying is that we should be upgrading the DNS protocol before 2038, with enough lead time so all the network operators will have time to make the switch. That means we need to expand the DNS protocol to more than 32 bits (40 bits should actually be enough) by around 2008.
That could be done. But rather than have to process it like that and either store or parse the serial value to be updated, the way I do it to take the master file (not a normal zone format) I use to generate each zone, get its last modification date from the filesystem, and produce the serial number from that. This way, I can still derive the date and time, to a 4 second resolution, from the serial number, and back track it to the archived master files if there are any issues to figure out. It's basically simpler with more benefits.
Third reason:
My serial number format lasts longer than Verisign's, and I still get more than 100 updates a day out of it. In fact it will last until 07:06:36 Tuesday 2 October 2096 while staying in just 9 digits (which it has been since 15:06:40 Saturday 4 September 1982). After that it goes to 10 digits, but still remains a positive signed 32 bit integer until 12:56:28 Wednesday 16 March 2242, and if unsigned 32 bit integer works everywhere else, it will go all the way to 01:53:00 Wednesday 30 May 2514.
Instead of being the count of number of seconds, as Verisign plans to use, mine is 1/4 of that value. Basically, I take the system time() value and divide by 4. By treating that value as an unsigned quantity, I won't have the Y2038 bug, either. That logic will work until 06:28:15 Sunday 7 February 2106 (past the 9 digit limit). And I can do 21600 updates a day (one every 4 seconds).
dig linuxhomepage.com. soa
Java just-in-time compilation will fail to perform well in certain cases. In fact, even if it were to completely compile itself into native code right from the outside, it will still fail to perform well in these certain cases.
The cases I speak of are when multiple processes are using the same executable code, which for Java will be the class file, and for compiled C source will be an ELF executable image. When Linux and other Unix systems run these programs, the original executable image is memory mapped by the kernel or the run time loader. At this point the pages are all shared between multiple processes. The run time loader will link in necessary libraries, which will modify a few pages and result in them not being shared due to copy on write. But these are generally the jump tables and few other things that happen to be in the same page area. Most of the executable machine code is not modified.
When a Java class file is loaded, the executable as far as the system sees it to be is the Java run time engine itself. When it compiles the Java byte code at run time, it can produce good performing code, but it can't cause that code to be shared in memory with other processes that were running the same Java class file.
OTOH, Java applications tend to be run as threads, not multiple processes. As long as the compiling of the code is done so that there are no thread collisions in that (you'd know pretty quickly if there were), then you have one copy of the code shared between all threads.
The use of threads and Java is a tradeoff. You get the better program protection of Java (and not programming with pointers, which the average programmer is not capable of dealing with very well), but you also get the risk of threads (it's still possible to program badly for threads even in Java, and get data crossover where it should not be).
But when you see benchmarks that say one is better than the other, you better have a close look and see exactly what kind of thing is being tested, including whether multiple instances in processes, vs. multiple instances in threads, is being done. In some cases (like when it has to be processes, not threads) you might want to consider using a Java to native machine code compiler, or if you can handle it, program in C or C++.
Oh great! Now I won't be able to track down what open relay was used to send me spam.
Investors are no fools. The good ones will make money on this. Since the price will go up because there are in fact many fools in the market, the savvy investor will take the ride up to the top to pick the fruit. They will be the ones to sell out first. The best of the best will see the right signals and sell at the highest point, leaving the fool investors who bought it at various prices across the whole range dealing with trying to recover a meager few cents per share once the whole thing crashes.
Many investors are anticipating a buyout, perhaps by IBM itself.
But this could be a while. The wheels of justice grind slowly (and sometimes run in reverse for a while). Just look at all the time it has taken to even get to arguing about discovery, and counter arguing about who's not cooperating in discovery. The crash might not happen for another year or two or maybe even longer.
If you didn't get in on SCO when it started up, then what you might want to look into doing is shorting the stock just before you think it will crash. Shorting the stock can be a lot riskier, so you better be a good investor if you want to do this. If you don't know what it means, don't even think of trying it.