Actually, we have several drugs that can attack viruses; Tamiflu, the anti-flu medication, is one current example. We just don't have any that are as broadly effective as antibiotics are against bacteria.
Actually, each version of KDE has been faster than previous versions on the same hardware. I can attest to that, I noticed major speedups when I upgraded from version 2 to version 3.
But the apps compiled for Linux on MacOSX will need X to run; no X, no GUI. That will be a major stumbling block; likely if X is already available then the App vendor can just recompile the app for Mac OSX already.
Well, CPU usage isn't the only metric we've used to measure performance, however our experiment is pretty simple: we have our application deployed on a production web-server, under normal load. We measure CPU usage and keep track of GC logs (this is a JVM feature). Then we switch to Java 1.5 and run the app again. The app is doing the same work but has lower CPU usage. Memory usage is pretty constant for both scenarios; the JVM is configured to GC whenever its various memory zones reach a certain percentage of used memory. We've also experimented with alternate GC algorithms that ship with the JVM. Experience has shown that our site's performance drops when the CPU load on the server reaches a certain level; the new JVM keeps the CPU load down for a larger percentage of the time.
You're right in saying that it's possible our app is waiting for hardware, or something, proportinatly more of the time now that we have Java 1.5, but that's because there's a database involved, it's a separate task to optimize that, and a separate discussion. In truth though, our servers are actually under-utilized now that we are running Java 1.5 because our database is back to being the biggest bottleneck; previously due to poor memory usage, bad GC, and leaks in the application server, the java servers were the bottleneck so we added more of them. Since we've profiled the app, fixed the application server, and switched to Java 1.5, that particular bottleneck is cleared.
I notice a difference in performance because the web site I work for has high volume and we keep track of stuff like CPU usage over time. CPU usage has dropped because garbage collection has significantly improved. The website itself is snappy and responsive but that's because there's lots of hardware behind it; we have multiple servers to provide both speed and redundancy. But we can demonstrate that each server is working more efficiently with Java 5 than it was with Java 1.4.
In C/C++ you can wrap malloc() so that if it fails, you can start dumping cache until it succeeds. The solution is elegant, dare I say beautiful.
In Java this is totally impossible.
In Java there are things called weak references which you can use for this exact purpose. A weak reference is a pointer to a pointer, but the pointed-to object is considered available for garbage collection (as long as it isn't referred to anywhere else). This means you can do this:
Object toBeCached = new Object(); WeakReference wr = new WeakReference(); wr.set(toBeCached); cache.put(cacheKey, wr);
This, obviously, could be handled inside the cache for better encapuslation. But the point is that when garbage-collection runs, the items in the cache are fair game for collection. The obvious problem is that the GC will reap objects in random order, or it may even reap the most-recently-allocated objects first. But if that's a problem for you then you can probably make your cache smarter, such as keeping strong references to newer objects.
In some aspects, yes, it is much faster. For example, I can tell the difference between Java 1.4 and Java 5 (1.5) on the same hardware. My company's website was upgraded to Java 5 and performance increased significantly, mainly due to garbage-collection improvements. So I'd say that the same holds for the older JVMs. However, there may be other things added to the JVMs that make them less suitable for older hardware. I know that class libraries and app frameworks have gotten bigger as time goes on, so that would definately impact things in terms of memory usage.
You're right, Java does have memory leaks, in a sense, but these same problems can arise in any language. You could have a cache implemented in C/C++ that is never properly emptied, so over time it fills up. Or you could have a request log where, due to a bug, requests are not always removed from the log after they are processed. Sure, you might have included code to free the objects in the cache or log when you are done with them, but the programming error is that you forgot to remove the item. This is not a language issue, this is just a programming mistake.
At least in Java you only need to worry about one problem: removing items from caches, logs, queues, etc when you are done with them; in C++ you have to also worry about de-allocating that object, which requires strict planning since the object must not be referred to anywhere else when you de-allocate it. In general you can't prove that the object isn't still referred-to by someone who had it before it was put into the cache/log/whatever; instead you need to establish rules and write documents to make sure everyone knows what the lifecycle of an object should be.
As for your company not having a memory bug logged in 3.7 years, that's great, but without knowing what kind of applications you write, or how they're used, it's hard to say if that's significant. Some programs, like, say, grep, or mv or ls or any one-time-use utilities may be rife with memory leaks, but who cares? When the program terminates the memory is freed, and the user will likely not notice the leak. But even if your apps are long-running network services or whatever, I bet the time spent by developers preventing memory leaks is significant, even if that time is completely spread out throughout the development cycle instead of in large, easy-to-spot chunks running Valgrind or some other profiler.
Having worked at a place that serviced laptops, I can confirm that you can definately buy parts for laptops, and most failures occur while the product is under warranty. Granted, replacing parts in an out-of-warranty laptop can be quite expensive, but no worse than replacing out-of-warranty parts in a desktop from a name-brand-vendor who locks you in to their parts catalogue. But for recent laptops just out of warranty it's usually worth it to replace a busted circuit board or a dead hard disk (actually, a dead hard disk is almost always worth replacing, they are cheap and interchangeable). Even a dead LCD can often be replaced with a new one or one taken from another notebook. Notebooks aren't as modular as desktops, and they usually can only have parts exchanged with notebooks of the same model, but that doesn't stop people from repairing them. And any IT dept that deals with lots of computers usually tries to keep their total number of different models down to ease repairs and inventory tracking, etc.
actually, using the windows boot loader to boot linux is pretty easy as long as you chain it to a linux boot loader. Just install grub/lilo on your linux partition instead of your MBR, use dd to read the first 512 bytes of that partition and store it as a file in your windows root, and add a line in the boot.ini that points to that file. dd is even available for windows, both with and without cygwin, so you don't even need to be in linux to do this.
The problem is that the OS doesn't cache stuff that comes from another computer through a socket, so adding RAM to your DB will make the DB faster, but adding a cache to the DB client will make the DB less busy and the client faster. If it's important, you can use a distributed cache that lets you invalidate the caches on other machines. I don't know anything about memcahced but I imagine it has that feature, otherwise it's just a hashmap.
There was an article in an IEEE magazine about this sort of thing not long ago. Basically a network admin wanted to set up WPA on his network using encryption and certificates etc. But the normal installation mode was too complex for his users, who happened to mainly be PhD research types (i.e. not dumb, but not computer nerds). So they ended up writing a little program that you put on the notebook computer, you bring the notebook into a room, point the IR at the computer in that room, press a button, and the notebook downloads the certificate and installs it and configures it.
How hard would it be to include functionality like that into every WiFi device? Heck, you could do it without a line of sight if the router and client communicate by radio, and require confirmation at both ends that the right computer is talking to the right network. It wouldn't be that hard, really.
Word Perfect 6.0 was clearly around the time of MS dominance... MS Word for Windows was starting to kick Word Perfect 5.1's butt, and WP 5.2 (for windows) was terrible... and Windows/Dos was the default OS for all computers, there was no real alternative. At that time, MS owned the OS market and was on the climb to owning the Word Processor Market. Probably the spreadsheet market at the same time.
I don't have any numbers to prove anything, but I suspect that it's harder to give up older children... also most people who adopt children are prepared for what they are doing, it's not as easy as adopting a pet and the sense of commitment is greater. probably people who adopt are better prepared to be parents than people who give birth.
The point is that you can be against abortion on principle, but allow it in corner cases if necessary. The "Oh no, I made a mistake" scenario is totally different from the "I was raped" scenario.
Yet there's also a waiting list for adopting an infant, in some cases up to 10 years. So perhaps the problem isn't that adoption doesn't work, it's that babies need to be put up for adoption as soon as they're born, rather than later when it turns out the parents couldn't care for it.
Your argument makes sense, but I'm still not convinced that a court would actually find against Disney in this case; a Mickey Mouse movie entering public domain would allow you to make copies of that movie, and it would allow you to make derivative works, but would your derivative works be allowed to contain Mickey as such? Has such a case ever occurred? I'm sure there is old Coke marketing material that has entered public domain, but that doesn't mean you're allowed to use the words Coca-Cola or the image of their logo on your products, does it?
I think Disney could make a successful argument that just because their trademark image is old doesn't mean it's not used in trade... especially Mickey's image, and the image of the other main characters. You have to admit, Mickey and what he looks like are instantly recognizable as Disney property, and if people started using Disney characters in their art, people will think Disney made it, which hurts Disney's brand.
I'm pretty sure the appearance of Mickey is copyrighted. There was an artist who made drawings of disney characters being tied up, chained, beaten, tortured, etc, to make some point about the media's influence. Well, she was sued and had to change her artwork so that the characters were not recognizable as Disney's characters. Which diminishes the art's message, unless you know the story, in which case it proves the point.:)
Anyway, those works were totally new, not based on anything Disney had made, but it was trademark law that stopped her. No copyrights, screenplays, audio clips, etc were used in making that artwork, so even if Steamboat Willie was public domain, you still wouldn't be able to make new movies with Mickey in them. All you'd be allowed to do is make free copies of Steamboat Willie.
The source code for the Java API is available, but not with a Free license. It ships with every JDK. What's not available is the JVM source... at least, also not with a Free license. But I've been programming Java for years and rarely look at the API source, and have never needed the JDK source.
If the task were possible by using logs, would that make it ok? I don't really see the distinction: Using a cookie to track a user for aggregate data is bad, but using logs to track a user for aggregate data is ok?
It's very difficult to own an elephant, in the sense that you own cattle. Cattle are domestic; no one has ever domesticated an elephant. Read Jared Diamond's Guns, Germs and Steel to see the explanation, but it boils down to this: animals need a certain combination of traits to be domesticated for farming, and if they lack one of those traits they are pretty much impossible to domistcate.
Elephants are just not practical: they live too long and take too long to breed. Domesticating them would take several human generations, assuming nothing else went wrong. Just look at the trouble zoos have in breeding elephants.
Slashdot Mirror
Actually, we have several drugs that can attack viruses; Tamiflu, the anti-flu medication, is one current example. We just don't have any that are as broadly effective as antibiotics are against bacteria.
Actually, each version of KDE has been faster than previous versions on the same hardware. I can attest to that, I noticed major speedups when I upgraded from version 2 to version 3.
Uh, Microsoft already did release a 64 bit os, Windows XP Pro for 64-bit cpus (Pentium em-64t and amd 64).
But the apps compiled for Linux on MacOSX will need X to run; no X, no GUI. That will be a major stumbling block; likely if X is already available then the App vendor can just recompile the app for Mac OSX already.
Well, CPU usage isn't the only metric we've used to measure performance, however our experiment is pretty simple: we have our application deployed on a production web-server, under normal load. We measure CPU usage and keep track of GC logs (this is a JVM feature). Then we switch to Java 1.5 and run the app again. The app is doing the same work but has lower CPU usage. Memory usage is pretty constant for both scenarios; the JVM is configured to GC whenever its various memory zones reach a certain percentage of used memory. We've also experimented with alternate GC algorithms that ship with the JVM. Experience has shown that our site's performance drops when the CPU load on the server reaches a certain level; the new JVM keeps the CPU load down for a larger percentage of the time.
You're right in saying that it's possible our app is waiting for hardware, or something, proportinatly more of the time now that we have Java 1.5, but that's because there's a database involved, it's a separate task to optimize that, and a separate discussion. In truth though, our servers are actually under-utilized now that we are running Java 1.5 because our database is back to being the biggest bottleneck; previously due to poor memory usage, bad GC, and leaks in the application server, the java servers were the bottleneck so we added more of them. Since we've profiled the app, fixed the application server, and switched to Java 1.5, that particular bottleneck is cleared.
Exactly, unless you need more complex behaviour.
I notice a difference in performance because the web site I work for has high volume and we keep track of stuff like CPU usage over time. CPU usage has dropped because garbage collection has significantly improved. The website itself is snappy and responsive but that's because there's lots of hardware behind it; we have multiple servers to provide both speed and redundancy. But we can demonstrate that each server is working more efficiently with Java 5 than it was with Java 1.4.
In C/C++ you can wrap malloc() so that if it fails, you can start dumping cache until it succeeds. The solution is elegant, dare I say beautiful.
In Java this is totally impossible.
In Java there are things called weak references which you can use for this exact purpose. A weak reference is a pointer to a pointer, but the pointed-to object is considered available for garbage collection (as long as it isn't referred to anywhere else). This means you can do this:
This, obviously, could be handled inside the cache for better encapuslation. But the point is that when garbage-collection runs, the items in the cache are fair game for collection. The obvious problem is that the GC will reap objects in random order, or it may even reap the most-recently-allocated objects first. But if that's a problem for you then you can probably make your cache smarter, such as keeping strong references to newer objects.
In some aspects, yes, it is much faster. For example, I can tell the difference between Java 1.4 and Java 5 (1.5) on the same hardware. My company's website was upgraded to Java 5 and performance increased significantly, mainly due to garbage-collection improvements. So I'd say that the same holds for the older JVMs. However, there may be other things added to the JVMs that make them less suitable for older hardware. I know that class libraries and app frameworks have gotten bigger as time goes on, so that would definately impact things in terms of memory usage.
You're right, Java does have memory leaks, in a sense, but these same problems can arise in any language. You could have a cache implemented in C/C++ that is never properly emptied, so over time it fills up. Or you could have a request log where, due to a bug, requests are not always removed from the log after they are processed. Sure, you might have included code to free the objects in the cache or log when you are done with them, but the programming error is that you forgot to remove the item. This is not a language issue, this is just a programming mistake.
At least in Java you only need to worry about one problem: removing items from caches, logs, queues, etc when you are done with them; in C++ you have to also worry about de-allocating that object, which requires strict planning since the object must not be referred to anywhere else when you de-allocate it. In general you can't prove that the object isn't still referred-to by someone who had it before it was put into the cache/log/whatever; instead you need to establish rules and write documents to make sure everyone knows what the lifecycle of an object should be.
As for your company not having a memory bug logged in 3.7 years, that's great, but without knowing what kind of applications you write, or how they're used, it's hard to say if that's significant. Some programs, like, say, grep, or mv or ls or any one-time-use utilities may be rife with memory leaks, but who cares? When the program terminates the memory is freed, and the user will likely not notice the leak. But even if your apps are long-running network services or whatever, I bet the time spent by developers preventing memory leaks is significant, even if that time is completely spread out throughout the development cycle instead of in large, easy-to-spot chunks running Valgrind or some other profiler.
Having worked at a place that serviced laptops, I can confirm that you can definately buy parts for laptops, and most failures occur while the product is under warranty. Granted, replacing parts in an out-of-warranty laptop can be quite expensive, but no worse than replacing out-of-warranty parts in a desktop from a name-brand-vendor who locks you in to their parts catalogue. But for recent laptops just out of warranty it's usually worth it to replace a busted circuit board or a dead hard disk (actually, a dead hard disk is almost always worth replacing, they are cheap and interchangeable). Even a dead LCD can often be replaced with a new one or one taken from another notebook. Notebooks aren't as modular as desktops, and they usually can only have parts exchanged with notebooks of the same model, but that doesn't stop people from repairing them. And any IT dept that deals with lots of computers usually tries to keep their total number of different models down to ease repairs and inventory tracking, etc.
actually, using the windows boot loader to boot linux is pretty easy as long as you chain it to a linux boot loader. Just install grub/lilo on your linux partition instead of your MBR, use dd to read the first 512 bytes of that partition and store it as a file in your windows root, and add a line in the boot.ini that points to that file. dd is even available for windows, both with and without cygwin, so you don't even need to be in linux to do this.
The problem is that the OS doesn't cache stuff that comes from another computer through a socket, so adding RAM to your DB will make the DB faster, but adding a cache to the DB client will make the DB less busy and the client faster. If it's important, you can use a distributed cache that lets you invalidate the caches on other machines. I don't know anything about memcahced but I imagine it has that feature, otherwise it's just a hashmap.
There was an article in an IEEE magazine about this sort of thing not long ago. Basically a network admin wanted to set up WPA on his network using encryption and certificates etc. But the normal installation mode was too complex for his users, who happened to mainly be PhD research types (i.e. not dumb, but not computer nerds). So they ended up writing a little program that you put on the notebook computer, you bring the notebook into a room, point the IR at the computer in that room, press a button, and the notebook downloads the certificate and installs it and configures it.
How hard would it be to include functionality like that into every WiFi device? Heck, you could do it without a line of sight if the router and client communicate by radio, and require confirmation at both ends that the right computer is talking to the right network. It wouldn't be that hard, really.
Word Perfect 6.0 was clearly around the time of MS dominance... MS Word for Windows was starting to kick Word Perfect 5.1's butt, and WP 5.2 (for windows) was terrible... and Windows/Dos was the default OS for all computers, there was no real alternative. At that time, MS owned the OS market and was on the climb to owning the Word Processor Market. Probably the spreadsheet market at the same time.
I don't have any numbers to prove anything, but I suspect that it's harder to give up older children... also most people who adopt children are prepared for what they are doing, it's not as easy as adopting a pet and the sense of commitment is greater. probably people who adopt are better prepared to be parents than people who give birth.
The point is that you can be against abortion on principle, but allow it in corner cases if necessary. The "Oh no, I made a mistake" scenario is totally different from the "I was raped" scenario.
Yet there's also a waiting list for adopting an infant, in some cases up to 10 years. So perhaps the problem isn't that adoption doesn't work, it's that babies need to be put up for adoption as soon as they're born, rather than later when it turns out the parents couldn't care for it.
Your argument makes sense, but I'm still not convinced that a court would actually find against Disney in this case; a Mickey Mouse movie entering public domain would allow you to make copies of that movie, and it would allow you to make derivative works, but would your derivative works be allowed to contain Mickey as such? Has such a case ever occurred? I'm sure there is old Coke marketing material that has entered public domain, but that doesn't mean you're allowed to use the words Coca-Cola or the image of their logo on your products, does it?
I think Disney could make a successful argument that just because their trademark image is old doesn't mean it's not used in trade... especially Mickey's image, and the image of the other main characters. You have to admit, Mickey and what he looks like are instantly recognizable as Disney property, and if people started using Disney characters in their art, people will think Disney made it, which hurts Disney's brand.
I'm pretty sure the appearance of Mickey is copyrighted. There was an artist who made drawings of disney characters being tied up, chained, beaten, tortured, etc, to make some point about the media's influence. Well, she was sued and had to change her artwork so that the characters were not recognizable as Disney's characters. Which diminishes the art's message, unless you know the story, in which case it proves the point. :)
Anyway, those works were totally new, not based on anything Disney had made, but it was trademark law that stopped her. No copyrights, screenplays, audio clips, etc were used in making that artwork, so even if Steamboat Willie was public domain, you still wouldn't be able to make new movies with Mickey in them. All you'd be allowed to do is make free copies of Steamboat Willie.
How true... and one day, when Xbox has internet connectivity, you'll be able to download viruses onto that as well
The source code for the Java API is available, but not with a Free license. It ships with every JDK. What's not available is the JVM source... at least, also not with a Free license. But I've been programming Java for years and rarely look at the API source, and have never needed the JDK source.
If the task were possible by using logs, would that make it ok? I don't really see the distinction: Using a cookie to track a user for aggregate data is bad, but using logs to track a user for aggregate data is ok?
It's very difficult to own an elephant, in the sense that you own cattle. Cattle are domestic; no one has ever domesticated an elephant. Read Jared Diamond's Guns, Germs and Steel to see the explanation, but it boils down to this: animals need a certain combination of traits to be domesticated for farming, and if they lack one of those traits they are pretty much impossible to domistcate.
Elephants are just not practical: they live too long and take too long to breed. Domesticating them would take several human generations, assuming nothing else went wrong. Just look at the trouble zoos have in breeding elephants.