Eh? $99 gets you full root access on a dedicated server...you can upgrade what you like when you like. I don't see the problem.
You said it yourself: you CAN upgrade what you like and when you like... which is "nothing" and "never" for most people who don't want to spend the time and effort required to react quickly to vulnerabilities as they are discovered.
That's the point - they usually don't bother. There are some few cases where companies that have a LOT of such projects are beginning to see potential gains by developing reusable components or an entire framework together with partners, and I know of at least one case where they're actually planning to creat a real open source project.
You seem to have no idea whatsoever what custom software is and how it is made.
These aren't some small changes to standard software that give a "small edge". These are HUGE, mission-critical systems hand-tailored to fit the company's business processes. They may incorporate some standard software such as app servers, but that's really the smallest part; what's important is the stuff that runs ON the app server.
And giving away this code, via GPL or otherwise, would be no loss to the company or gain to its competitors whatsoever, since the whole point is that the systems are customized to fit that particular company's needs, and would be pretty useless to any other company without modifications so big that you might as well start from scratch.
Big consulting companies like Accenture (what used to be Anderson Consulting) may be able to profit from this by developing internal frameworks and reusable components, but that's a whole lot different than "duping" the clients, especially since this "R&D" accumulates over time and is unlikely to form aubstantially in one particular project.
Earlier clients may pay more this way, but they still have the benefit of having their systems up and running earlier as well.
And indeed the far more likely, common, and still quite valuable (to the developers) case is the users giving feedback in the form of bug reports. A programmer working on a commercial project is not likely to want to get familiar enough with huge chunks of other people's code to make extensive fixes. Instead making a detailed bug report with everything that's needed to reproduce the bug is going to get the bug fixed relatively quickly with less work for him, and also get it fixed for everyone else.
ESR is the mustache guy, I think. Unfortunately your criteria aren't all that helpful either, since there is more than one very bearded poster child of the open source movement.
I doubt they're telling anyone, since it would be easier for the fraudsters to circumvent the checks if they knew the exact method.
The obvious measure would be statistical analysis to see whether some IP addresses are generating an excessive amount of clicks, especially on the same ads.
Correction: Java has not exploitable buffer overflows, because arrays have a fixed size and any array access is checked against that size, so attempts to write beyond the end of the array result in an ArrayIndexOutOfBoundException rather than smashing the stack. Most other common (in C) forms of exploits don't exist because there is no pointer arithmetic.
Nope, it's you who's confused. Java has made use of JIT compilers since at least version 1.2. The platform independent bytecode (Java.class files) is compiled to platform-dependant machine code while it runs. At first this was done to all the code, which increased startup delays a lot, nowadays only the frequently-executed code (on a per-method basis) is JIT-compiled, the rest is indeed interpreted, which gets you the best of both worlds.
If "mu" could talk, it would deny such allegations. In fact, it's not a word at all, but a prefix with negating properties. For example, it can be prefixed to turn the word "imi" (meaning) into "muimi" (meaningless). I'm pretty sure it's never used on its own in normal Japanese usage.
Those benchmarks seem like crap to me - the first four are supposed to be more or less equal for C and a Java JIT compiler, since from what I can see, they're just coding C in java (ie, no objects, just loops with variables of primitive types, etc).
So what you're saying is that you want to benchmark not languages but programming paradigms? Or just rig the benchmark so that it might support your false original claim?
If you are talking about pure speed, java is certainly not even 75% as fast as C
Yes, it most certainly is. However, it does tend to be a bit of a memory hog, which slows down larger apps. Then again, big fat C++ apps like OpenOffice aren't exactly blinding fast either.
Bullshit. We can see the source just, fine. All of it. The API library source comes with every JDK, and you can get the JVM source as well.
However, the license does not allow you to change that source and distribute the changed version. That's what Open Source purists are criticizing, no the lack of the actual source code.
The "freenet client" you see in the task list is almost certainly nothing but a startup script, with the JVM task being the actual client. And I agree that it's quite definitely the fault of the freenet client code, not the JVM.
Well, my experiences have been quite the opposite. Between two big commercial Java apps I've worked on, I've personally seen a whopping TWO JRE-version related problems. In one instance someone was using some weird beta JRE that was missing a mandatory encoding. In the other, the app was operating the the legal gray zones of focus management and working on the old JRE more or less by accident.
Seems to me that if your app had that many problems between different JREs then you were doing something wrong.
Partial credit. You seem to forget (rather willingly) that you are allowed to create one backup for music, movies etcetera that you already OWN. If you borrow a CD from your friend, make a copy of that one and return it, you are breaking the law.
Wrong. It's perfectly legal according to, for exaple, Articel 53 of German copyright law, which makes an explicit exception for non-commercial copying for private use.
Now wait. Once you've considered a permutation, you can forget it. You don't need more than O(n) memory.
Depends on the algorithm. My algorithm required keeping all permutations for 1..n-1 around in order to compute those for 1..n. It was faster than all other solutions (including that of the professor).
Many would like to sell 'spare parts' but the cost of a 'no sale' is a real turn off. Selling a 'new mobile phone' vs selling 'recon engine head' means hard to get spares are no longer listed - ebay has drove useful obscure spare parts merchants off ebay and onto online forums.
I remember the time when ebay charged nothing for listing items. That was back when it wasn't the dominant online auction house. People would put in stuff with unrealistic minimum bids, and when nobody was willing to pay that much, they'd just put it in again, hoping for a sucker. Any search would turn up at least 75% such overpriced items. Then ebay installed the listing charge. There was a terrible outcry and people were urging a boycott of ebay. But the reasult was that ebay became a lot more attractive to the BUYERS, because they didn't have to wade through pages upon pages of overpriced stuff. In the end, it was not ebay but its competition that died out.
Reminds me of that little program I had to write for a class whose job it was to print all the permutations of the numbers from 1 to n (n being a parameter). Happy that I'd found a very efficient solution I tested it with n=3, n=4, and all was fine. Then, for kicks, I started it with n=20. I knew that it would take a while, so I did a back-of-an-envelope calculation of how much RAM it might need to assemble the result... and came up with something like 20GB. Which was more than all the HDs of the 50 computers in the pool together had at that time. Oops.
I think you're overstating the case. According to the jargon file, vaporware is mere " Products announced far in advance of any release (which may or may not actually take place)", i.e. malicious intent, or even lack of intent to release, is not necessarily implied. Wikipedia elaborates that apart from the cases you describe, it can also be a "test ballon", with the project getting cancelled when there is not enough positive response, or simply the result of too much optimism.
"Avalanche," as a name for a product or project, would be just about the worst possible choice. As a P2P tool that would imply bandwidth problems and the potential for a single point of failure.
Um... Would it? Why? I don't see these implications at all. Quite the opposite, really. An avalance is (in popular imagination, anyway) started by a small cause and quickly develops into an unstoppable mass of snow. Just like a single limited-bandwidth uploader of a popular file to a P2P network can result in many Terabytes of data being moved.
Slashdot Mirror
More likely than the large copyright-holding companies themselves doing it, and right now those are the only ones operating such systems.
Eh? $99 gets you full root access on a dedicated server...you can upgrade what you like when you like. I don't see the problem.
You said it yourself: you CAN upgrade what you like and when you like... which is "nothing" and "never" for most people who don't want to spend the time and effort required to react quickly to vulnerabilities as they are discovered.
That's the point - they usually don't bother. There are some few cases where companies that have a LOT of such projects are beginning to see potential gains by developing reusable components or an entire framework together with partners, and I know of at least one case where they're actually planning to creat a real open source project.
You seem to have no idea whatsoever what custom software is and how it is made.
These aren't some small changes to standard software that give a "small edge". These are HUGE, mission-critical systems hand-tailored to fit the company's business processes. They may incorporate some standard software such as app servers, but that's really the smallest part; what's important is the stuff that runs ON the app server.
And giving away this code, via GPL or otherwise, would be no loss to the company or gain to its competitors whatsoever, since the whole point is that the systems are customized to fit that particular company's needs, and would be pretty useless to any other company without modifications so big that you might as well start from scratch.
Big consulting companies like Accenture (what used to be Anderson Consulting) may be able to profit from this by developing internal frameworks and reusable components, but that's a whole lot different than "duping" the clients, especially since this "R&D" accumulates over time and is unlikely to form aubstantially in one particular project.
Earlier clients may pay more this way, but they still have the benefit of having their systems up and running earlier as well.
And indeed the far more likely, common, and still quite valuable (to the developers) case is the users giving feedback in the form of bug reports. A programmer working on a commercial project is not likely to want to get familiar enough with huge chunks of other people's code to make extensive fixes. Instead making a detailed bug report with everything that's needed to reproduce the bug is going to get the bug fixed relatively quickly with less work for him, and also get it fixed for everyone else.
What, however, if ALL locks came with such disclaimers?
ESR is the mustache guy, I think. Unfortunately your criteria aren't all that helpful either, since there is more than one very bearded poster child of the open source movement.
It has only just released support for the latest Java version, 6 months behind NetBeans.
I was using JDK 1.5-compatible Milestone builds of eclipse 3.1 as much as 8 months ago.
Admittedly, the 1.5 compatiblity wasn't complete at that time, but otherwise there were no problems one might expect with a beta release.
I doubt they're telling anyone, since it would be easier for the fraudsters to circumvent the checks if they knew the exact method.
The obvious measure would be statistical analysis to see whether some IP addresses are generating an excessive amount of clicks, especially on the same ads.
sigh
Correction: Java has not exploitable buffer overflows, because arrays have a fixed size and any array access is checked against that size, so attempts to write beyond the end of the array result in an ArrayIndexOutOfBoundException rather than smashing the stack. Most other common (in C) forms of exploits don't exist because there is no pointer arithmetic.
Nope, it's you who's confused. Java has made use of JIT compilers since at least version 1.2. The platform independent bytecode (Java .class files) is compiled to platform-dependant machine code while it runs. At first this was done to all the code, which increased startup delays a lot, nowadays only the frequently-executed code (on a per-method basis) is JIT-compiled, the rest is indeed interpreted, which gets you the best of both worlds.
Same way you crack any other sufficiently-complex appliance... find a buffer overflow
Except you don't have buffer overflows in Java.
If "mu" could talk, it would deny such allegations. In fact, it's not a word at all, but a prefix with negating properties. For example, it can be prefixed to turn the word "imi" (meaning) into "muimi" (meaningless). I'm pretty sure it's never used on its own in normal Japanese usage.
Those benchmarks seem like crap to me - the first four are supposed to be more or less equal for C and a Java JIT compiler, since from what I can see, they're just coding C in java (ie, no objects, just loops with variables of primitive types, etc).
So what you're saying is that you want to benchmark not languages but programming paradigms?
Or just rig the benchmark so that it might support your false original claim?
If you are talking about pure speed, java is certainly not even 75% as fast as C
Yes, it most certainly is. However, it does tend to be a bit of a memory hog, which slows down larger apps. Then again, big fat C++ apps like OpenOffice aren't exactly blinding fast either.
Bullshit. We can see the source just, fine. All of it. The API library source comes with every JDK, and you can get the JVM source as well.
However, the license does not allow you to change that source and distribute the changed version. That's what Open Source purists are criticizing, no the lack of the actual source code.
The "freenet client" you see in the task list is almost certainly nothing but a startup script, with the JVM task being the actual client. And I agree that it's quite definitely the fault of the freenet client code, not the JVM.
Well, my experiences have been quite the opposite. Between two big commercial Java apps I've worked on, I've personally seen a whopping TWO JRE-version related problems. In one instance someone was using some weird beta JRE that was missing a mandatory encoding. In the other, the app was operating the the legal gray zones of focus management and working on the old JRE more or less by accident.
Seems to me that if your app had that many problems between different JREs then you were doing something wrong.
Partial credit. You seem to forget (rather willingly) that you are allowed to create one backup for music, movies etcetera that you already OWN. If you borrow a CD from your friend, make a copy of that one and return it, you are breaking the law.
Wrong. It's perfectly legal according to, for exaple, Articel 53 of German copyright law, which makes an explicit exception
for non-commercial copying for private use.
Now wait. Once you've considered a permutation, you can forget it. You don't need more than O(n) memory.
Depends on the algorithm. My algorithm required keeping all permutations for 1..n-1 around in order to compute those for 1..n. It was faster than all other solutions (including that of the professor).
Many would like to sell 'spare parts' but the cost of a 'no sale' is a real turn off. Selling a 'new mobile phone' vs selling 'recon engine head' means hard to get spares are no longer listed - ebay has drove useful obscure spare parts merchants off ebay and onto online forums.
I remember the time when ebay charged nothing for listing items. That was back when it wasn't the dominant online auction house. People would put in stuff with unrealistic minimum bids, and when nobody was willing to pay that much, they'd just put it in again, hoping for a sucker. Any search would turn up at least 75% such overpriced items. Then ebay installed the listing charge. There was a terrible outcry and people were urging a boycott of ebay. But the reasult was that ebay became a lot more attractive to the BUYERS, because they didn't have to wade through pages upon pages of overpriced stuff. In the end, it was not ebay but its competition that died out.
Reminds me of that little program I had to write for a class whose job it was to print all the permutations of the numbers from 1 to n (n being a parameter). Happy that I'd found a very efficient solution I tested it with n=3, n=4, and all was fine. Then, for kicks, I started it with n=20. I knew that it would take a while, so I did a back-of-an-envelope calculation of how much RAM it might need to assemble the result... and came up with something like 20GB. Which was more than all the HDs of the 50 computers in the pool together had at that time. Oops.
I very much doubt that a significant percentage of /. readers is affected, directly or indirectly, by PMS...
I think you're overstating the case. According to the jargon file, vaporware is mere " Products announced far in advance of any release (which may or may not actually take place)", i.e. malicious intent, or even lack of intent to release, is not necessarily implied. Wikipedia elaborates that apart from the cases you describe, it can also be a "test ballon", with the project getting cancelled when there is not enough positive response, or simply the result of too much optimism.
"Avalanche," as a name for a product or project, would be just about the worst possible choice. As a P2P tool that would imply bandwidth problems and the potential for a single point of failure.
Um... Would it? Why? I don't see these implications at all. Quite the opposite, really. An avalance is (in popular imagination, anyway) started by a small cause and quickly develops into an unstoppable mass of snow. Just like a single limited-bandwidth uploader of a popular file to a P2P network can result in many Terabytes of data being moved.
Quite similar to the "Torrent" part of BT.