Will you buy MP3s, unrestricted, for a reasonable price?
Of course, but remember that the definition of "reasonable" is that the price is something both seller and buyer will agree on.
Until the current pricing has proven to actually be reasonable, nobody knows if we're there yet. The "reasonable" price for a song could very well be $0.01 per song, and then the current uncrippling of extremely over-priced songs wouldn't prove anything.
The Bubbling Load Monitor (or "Bubblemon" for short) is a system CPU and memory load monitor. It displays something that looks like a vial containing water. The water level indicates how much memory is in use. The color of the liquid indicates how much swap space is used (watery blue means none and angry red means all). The system CPU load is indicated by bubbles floating up through the liquid; lots of bubbles means high CPU load. If you have unread mail, a message in a bottle falls into the water.
A screenshot doesn't do the applet much justice, since part of its coolness is its physics engine, making the bubbles move and the surface ripple.
It's a GNOME applet, try "apt-get install bubblemon" on your favorite Debian derivative. There are also some forks which also have bubble related names.
A great analogy in my opinion would be if every professional sports team suddenly disbanded. We wouldn't call this "the end of sports!!!!
Considering most people's definition of "sports" is "watching others do stuff on TV", I think that event would actually be considered the end of sports by a large part of the population.
C++ exceptions don't carry a stack trace with them - Java does.
There goes C++ off my list of recommended languages.
[unit tests, verification etc]
That's good practice independently of what language you're coding in. But when things fall apart for the customer (no amount of testing can prevent that), getting a stack trace and a more or less descriptive error message is really nice.
Most C programmers don't bother to check the return of system calls like printf()
Most things shouldn't be written in C.
Don't know if printf() was the best example, but this is really the reason you want a language that throws exceptions when things go wrong. That either forces programmers to write error handling code (if the compiler requires you to catch a certain exception), or gives the runtime a chance to present a stack trace when an exception is thrown.
The new facility in Northlake, Ill. [...] is expected to span 440,000 square feet.
So measuring its size in body parts isn't good enough for you? Anyway, $500M will get them 1.7M Vista licenses to cover all those feet with, might get their sales statistics up a bit.
the stack traces JRockit produces are formatted differently from those of Sun's JVM (which prevents my IDE from turning them into clickable hotlinks that take me to the lines of offending code). FSM knows why they made them different.
Since about two years back our stack traces look identical to SUN's. I'm at home right now and can't give you a specific release for that change. The difference was that old versions of JRockit used to show full method signatures rather than just method names in stack traces. We reverted to doing what SUN's doing because of people having the exact issues you're having. Which JRockit version (do java -version) are you using?
Oh and the line numbers in your stack trace will be wrong unless you turn off optimization - which is the the whole point of using JRockit.
If you have a repro for this, please post it here. Since you're running WLS you probably have a support contract for JRockit, in which case you should open a support case. Unless we know about the problem we cannot fix it:-(.
(It's supposed to be faster than Sun's JVM - I've never seen proof).
As always it's not provable for the general case as it depends on what you're doing. Two references that do have numbers for JRockit being generally faster than SUN's JVM are here and here, but those numbers may or may not be applicable to your app.
Copyright (c) 2006, Clever Age All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
* Neither the name of Clever Age nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Since it prevents people from playing the movies it's obviously a playback protection mechanism. I haven't really seen any proof that this actually stops copying, so why call it "copy protection"?
The article you're linking to refers to using a GC together with C / C++. I'm not advocating running GCs with C / C++ because I don't have any experience with that. For most purposes I don't advocate C / C++ at all because they enable people to over-write memory randomly and get problems that need months of expensive testing to track down:-p.
I'm advocating using languages designed for garbage collection (and that prevents the user from dealing with pointers directly).
As for timing issues, the GC will cause pauses at random times, but so will the OS' process scheduling and interrupt handling. Are you saying that GC incurred timing issues are somehow more problematic than OS incurred timing issues?
In that case I mis-understood your statement. I interpreted what you said to mean that the "resource leaks" you were chasing for months were something that a garbage collector would have taken care of automatically. In which case the garbage collector would have been a drop-in replacement for those months, and most probably a lot cheaper.
Considering how non-deterministic an ordinary system is anyway (due to swapping, system load, different CPUs characteristics etc) I don't really see how having a garbage collector would make thread races any harder to track down than before though. Do you have any actual real-life anecdotes or something to back this up?
managing resources can be hard - one project I worked on had to go through several months of testing to get the resources properly managed, and even then some of the resources were still a little uncontrollable
In some cases using a garbage collecting language can be cheaper than several months of testing.
http://www.opensource.org/docs/definition.html#6 says that an Open Source license cannot discriminate against any "field of endeavor". Running stuff on non-Windows could potentially be seen as a field of endeavor, which would disqualify the "limited" license.
I don't really see how "No transactions or relational integrity checks" could really be useful for any kind of data storage. One bug in your application and your database is hosed.
Under what kind of circumstances would somebody not see this as a problem?
you must be able to accept attachments such as.zip and html mail
From TFA: "the current threat level does not bar the use of attachments"
Now what was the problem again?
Regarding your claim that HTML mail is mandatory, I have a very hard time seeing that anybody would say: "The DoD don't accept HTML e-mail so we don't want them as customers".
even in the best of cases leads to necrosis (cell death) in the hands and feet, along with blindness and kidney failure
No it doesn't. That happens when people don't take enough insulin. Then the sugar level in their blood gets too high. A lot of people with diabetes constantly walk around with about 2-3x as much sugar in their blood stream as what's normal.
Sugar is sticky. So it sticks to the insides of the blood vessels. When a blood vessel is coated with enough sugar on the inside, it won't be able to transport blood any more. The first blood vessels to clog this way is obviously the thinnest ones. Like the ones in the hands, feet, eyes and kidneys (see the connection?).
So all of those issues isn't because people are taking insulin, they are because people are *not* taking their insulin. Under-dosing some other drug won't help either.
For me, apt-get isn't the big thing with Debian, it's the huge selection of packages. Unstable has 20968 packages, Testing 19533, and Stable 17014 (counted from wc -l of the full packages lists at packages.debian.org).
AFAIK no other distro is even close to that, and you're thus forced to install lots of third party stuff.
For me, if I can't apt-get install it, it doesn't exist.
The RIAA think sharing copyrighted music is harmful. Since that's probably what most people use Gnutella clients for, this could just as well be labeled "Patch for not allowing anybody at all to use this software".
Compiler researchers have known for years there is an order of magnitude difference between native and interpreted code across the board.
Considering JRockit compiles all code into machine code before running it, that's a non-argument.
Everybody knows that going by car is faster than walking. That doesn't imply that some car is necessarily faster than some other.
Likewise, everybody knows that native code is faster than interpreted. That doesn't mean that gcc's native code is necessarily faster than JRockit's. Yet, that's the argument you're making above if I understand you correctly.
Of course "movie fans will prefer to pay a reasonable price for a legal downloaded movie rather than risk illegally swapping a computer file that could contain viruses or be a poor quality copy of a film".
But since Warner's opinion about what "reasonable" means may or may not match the market's opinion, the statement is pointless. But correct.
Slashdot Mirror
Of course, but remember that the definition of "reasonable" is that the price is something both seller and buyer will agree on.
Until the current pricing has proven to actually be reasonable, nobody knows if we're there yet. The "reasonable" price for a song could very well be $0.01 per song, and then the current uncrippling of extremely over-priced songs wouldn't prove anything.
This *is* a shameless plug, which is more or less on-topic here. You have been warned :-).
:-) //Johan
http://www.nongnu.org/bubblemon/
The Bubbling Load Monitor (or "Bubblemon" for short) is a system CPU and memory load monitor. It displays something that looks like a vial containing water. The water level indicates how much memory is in use. The color of the liquid indicates how much swap space is used (watery blue means none and angry red means all). The system CPU load is indicated by bubbles floating up through the liquid; lots of bubbles means high CPU load. If you have unread mail, a message in a bottle falls into the water.
A screenshot doesn't do the applet much justice, since part of its coolness is its physics engine, making the bubbles move and the surface ripple.
It's a GNOME applet, try "apt-get install bubblemon" on your favorite Debian derivative. There are also some forks which also have bubble related names.
Have fun
A great analogy in my opinion would be if every professional sports team suddenly disbanded. We wouldn't call this "the end of sports!!!!
Considering most people's definition of "sports" is "watching others do stuff on TV", I think that event would actually be considered the end of sports by a large part of the population.
C++ exceptions don't carry a stack trace with them - Java does.
There goes C++ off my list of recommended languages.
[unit tests, verification etc]
That's good practice independently of what language you're coding in. But when things fall apart for the customer (no amount of testing can prevent that), getting a stack trace and a more or less descriptive error message is really nice.
Most C programmers don't bother to check the return of system calls like printf()
Most things shouldn't be written in C.
Don't know if printf() was the best example, but this is really the reason you want a language that throws exceptions when things go wrong. That either forces programmers to write error handling code (if the compiler requires you to catch a certain exception), or gives the runtime a chance to present a stack trace when an exception is thrown.
Instant maintainability improvement.
So measuring its size in body parts isn't good enough for you? Anyway, $500M will get them 1.7M Vista licenses to cover all those feet with, might get their sales statistics up a bit.
the stack traces JRockit produces are formatted differently from those of Sun's JVM (which prevents my IDE from turning them into clickable hotlinks that take me to the lines of offending code). FSM knows why they made them different.
Since about two years back our stack traces look identical to SUN's. I'm at home right now and can't give you a specific release for that change. The difference was that old versions of JRockit used to show full method signatures rather than just method names in stack traces. We reverted to doing what SUN's doing because of people having the exact issues you're having. Which JRockit version (do java -version) are you using?
Oh and the line numbers in your stack trace will be wrong unless you turn off optimization - which is the the whole point of using JRockit.
If you have a repro for this, please post it here. Since you're running WLS you probably have a support contract for JRockit, in which case you should open a support case. Unless we know about the problem we cannot fix it :-(.
(It's supposed to be faster than Sun's JVM - I've never seen proof).
As always it's not provable for the general case as it depends on what you're doing. Two references that do have numbers for JRockit being generally faster than SUN's JVM are here and here, but those numbers may or may not be applicable to your app.
HTH, have fun :-).
It was this tar file, sorry:
http://ubuntu.org.ua/getdeb/od/odf-converter_1.0.0.orig.tar.gz
License looks good enough to me, from share/doc/packages/odf-converter/LICENSE.TXT in http://ubuntu.org.ua/getdeb/or/oregano_0.69.0.orig.tar.gz:
Copyright (c) 2006, Clever Age
All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
* Neither the name of Clever Age nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Since it prevents people from playing the movies it's obviously a playback protection mechanism. I haven't really seen any proof that this actually stops copying, so why call it "copy protection"?
I'm advocating using languages designed for garbage collection (and that prevents the user from dealing with pointers directly).
As for timing issues, the GC will cause pauses at random times, but so will the OS' process scheduling and interrupt handling. Are you saying that GC incurred timing issues are somehow more problematic than OS incurred timing issues?
Considering how non-deterministic an ordinary system is anyway (due to swapping, system load, different CPUs characteristics etc) I don't really see how having a garbage collector would make thread races any harder to track down than before though. Do you have any actual real-life anecdotes or something to back this up?
In some cases using a garbage collecting language can be cheaper than several months of testing.
http://www.opensource.org/docs/definition.html#6 says that an Open Source license cannot discriminate against any "field of endeavor". Running stuff on non-Windows could potentially be seen as a field of endeavor, which would disqualify the "limited" license.
Under what kind of circumstances would somebody not see this as a problem?
As opposed to ...?
From TFA: "the current threat level does not bar the use of attachments"
Now what was the problem again?
Regarding your claim that HTML mail is mandatory, I have a very hard time seeing that anybody would say: "The DoD don't accept HTML e-mail so we don't want them as customers".
No it doesn't. That happens when people don't take enough insulin. Then the sugar level in their blood gets too high. A lot of people with diabetes constantly walk around with about 2-3x as much sugar in their blood stream as what's normal.
Sugar is sticky. So it sticks to the insides of the blood vessels. When a blood vessel is coated with enough sugar on the inside, it won't be able to transport blood any more. The first blood vessels to clog this way is obviously the thinnest ones. Like the ones in the hands, feet, eyes and kidneys (see the connection?).
So all of those issues isn't because people are taking insulin, they are because people are *not* taking their insulin. Under-dosing some other drug won't help either.
For me, apt-get isn't the big thing with Debian, it's the huge selection of packages. Unstable has 20968 packages, Testing 19533, and Stable 17014 (counted from wc -l of the full packages lists at packages.debian.org).
AFAIK no other distro is even close to that, and you're thus forced to install lots of third party stuff.
For me, if I can't apt-get install it, it doesn't exist.
This clause is all about what you mean by harm.
The RIAA think sharing copyrighted music is harmful. Since that's probably what most people use Gnutella clients for, this could just as well be labeled "Patch for not allowing anybody at all to use this software".
What they are doing now is the exact opposite of that.
Then:
* Let's ship this (gcc-2.96)!
Now:
* Let's not ship this (Xen).
Maybe they have simply become wiser with the years?
Considering JRockit compiles all code into machine code before running it, that's a non-argument.
Everybody knows that going by car is faster than walking. That doesn't imply that some car is necessarily faster than some other.
Likewise, everybody knows that native code is faster than interpreted. That doesn't mean that gcc's native code is necessarily faster than JRockit's. Yet, that's the argument you're making above if I understand you correctly.
But since Warner's opinion about what "reasonable" means may or may not match the market's opinion, the statement is pointless. But correct.
Excellent point. Not.
I noticed that on Coverity's demo page, there's no mention of MySQL. If they *do* scan MySQL for bugs, why not have it on the front page?