I used the Info-ZIP version of "zip" (it's the one that comes with Debian).
Zipping two copies of a file produces an archive twice the size as zipping a single copy of that file. This goes for updating as well (adding a renamed copy of a file to an archive that contains only the original will double the size).
I think that ZIP is more like.bz2.tar instead of.tar.bz2. This means that you can extract individual files without decompressing the whole archive. This is probably why Sun went with ZIP for JAR files (because it's convenient to get at some.class files without unzipping the whole thing).
This difference is also probably why.tar.gz and.tar.bz2 are usually smaller than ZIP archives. I don't think ZIP runs different files together so it can't take advantage of longer streams.
It's convenient to have directories separated from files because then you can do directory navigation without the mouse. If there's only one text box, then you often end up overwriting the filename that is given to you by default.
The file selection dialog in Gnome 1.4 sucks because when you create a new directory, it doesn't automatically place the focus on the text box. Also, after you manually click on the text box and type in the name of the new directory, pressing enter wont trigger the "create" action either.
Yes, I'm a Debian/testing user stuck with Gnome 1.4. Well, I have the Gnome 2 libraries and GDM2 (which is slower than the original GDM2 and has the location of the Yes/No buttons reversed) but all my other stuff is Gnome 1.4. That's thanks to Debian's smart "dist-upgrade", which also uninstalled a bunch of other crap without replacing it with equivalent programs. I also don't have an application to configure the theme for GTK2-based apps (anybody know which package to download?).
Totally ridiculous. That's the kind of crap you can expect from a totally clueless reporter. The sentence is ambiguous and in the end, it doesn't really say anything.
For some reason, he felt the need to mention that 10 systems were tested "together" without saying how.
It says that FastTCP can boost the speed past the "capacity" of ordinary broadband links. I don't know how you can get performance that exceeds the capacity (which I take to mean the theoretical limit). On the other hand, it isn't really clear if they even used "ordinary broadband links". For all we know, they could have been testing on a local GigE network (or on localhost!).
If he's trying to say that FastTCP gets 6,000 times the throughput of TCP, then this implies that TCP can be at most using 1/6,001 of the theoretical maximum. I'm guessing that they're advertising some corner case (or the reporter is retarded, which is probably just as likely).
FastTCP just seems like a better predictor of the delay/capacity properties of a connection. The New Scientist article says in one place that they were able to achieve a 4x increase in transmission speed between Geneva and California, which is impressive, but it's probably under strange conditions. The graph in their paper shows that FastTCP utilizes the link about twice as well as regular TCP when you get to 10Gbit links. The "reporter" must have done some serious mangling to get the number 6,000.
The "Smart" prefix is overused to the point of being totally meaningless.
Hmm...it sounds like my clock automatically updates it's display as time passes....I think I'll call SmartClock.
TCP already does a lot of tweaking to get better throughput.
What is your problem with FastTCP? At least "Fast" adds meaning. I guess you could have done worse and suggested "IntelliTCP".
Without the element of choice, entire crops were lost.
Seriously, though...this is what you sound like:
While I don't know what's involved in writing a window manager, I'm going to assume that it isn't difficult to make a WM that anticipates and can handle every possible aspect of customization.
If it were that easy, don't you think somebody would have done so? People try to make things extensible. Sawfish allows you to change a lot of the behavior (run sawfish-ui). I'm sure there are others that allow even higher degrees of customization. What is your beef with those window managers? Do you need to be instructed to use a particular one? I COMMAND YOU TO USE SAWFISH. Happy?
Whoops. In my original post, I linked to a document that described features that were being considered for addition into the language. Don't know what the current official state of C# is.
Actually, my mistake. Technically, C# does have closures. But the lack of Ruby-like syntax makes them seem clunky (though slightly less clunky then Java's anonymous inner classes.
If Java supported closures, the 'foreach' construct wouldn't have to be a special case. I think C# is going to have something that looks a lot like closures but for some reason, they are going to avoid providing general-purpose closure support (it's sad, really).
On the other hand, it looks like the value/class distinction in C# is going to help make its generics more efficient than Java's. It'll be like C++ except with runtime specialization when needed, so the disk image wont be bloated, just the memory image.
Where on the site did it say that a packager requires a sponsor? From the "About" page, it seems like they're warning you that the packages might be poorly-packaged/broken.
Implementing it the way you did is correct, but it needs to acquire the lock on every call. The (ultimately incorrect) version described in the article tries to avoid locking in the common case. As I just learned, there is a subtle problem with that.
I don't understand...are you saying that two threads can be executing code within the synchronized block at the same time? What is an "unsynchronized thread"?
Static typing is such a pervasive part of Java you might as well use something else (like Ruby or Python). What does Java minus static typing have that you can't get from somewhere else?
Any *well* *written* C program will run at least as fast as a java application.
How did you come to that conclusion? The run-time profiling advantage can let the JIT do things like compile code with branch-prediction hints to make it run faster than a statically-run compiler could.
No, it isn't a good idea. That's why they didn't do it. One of the first things they tell you when you do Swing stuff is that all mutations should happen in the event-handling thread.
And it isn't that different from a quad-pentium system, apart from the fact that I suggest reassigning the CPUs according to what the system needs -
So lemme get this straight...you're saying that when you have lots of sound to process, your CPU just sits idle until it has been "assigned" to process sound? I'm pretty sure the gains you will realize by not doing any context switches are insignificant when compared with the losses from having a CPU sit idle.
People don't generally write one-off small apps they intend to run hundreds of times a day in java. That's not what it's designed to do.
You mean like 'ant'? I start to get *really* annoyed after a while using ant. Build applications should still be done in C/C++/something fast (or just use 'make').
And like 'javac'? Yay! Now I get to plug my program again. It tries to make 'javac' a little faster. However, if you read the source, you'll realize that there are lots of problems with doing this in a general way. The problem is that the Java environment isn't designed to handle this.
Some of the problems are:
The static crap in java.lang.System. This is really the biggest problem. I think some hacked up usage of ThreadLocals could get around this but you have to do this for every single function.
System.exit is really a problem. It needs to be replaced with a throwable
And the show-stopper, the one that made me give up on writing a general-purpose framework, is that you can't change working directories. Just to get 'javac' to work as a background process, I had convert all filenames to absolute paths.
The Swing classes assume that only one thread is going to be running through them (haha, sounds like they didn't think synchronization was fast enough). Though I think you can hook into the AWT event loop, I think that some of the classes may have been written with bad assumptions and running multiple threads could cause problems with static, shared code).
I'm waiting for the day when there's a constantly running JVM on your machine and represents one system process.
Yay! Please take a look at my program. It maintains a single JVM in the background and waits for compilation requests. Though this isn't really general purpose, if you run 'javac' a lot, it is pretty helpful. Now you don't have to mangle your Makefile to force it to collect a list of Java files so that it can call 'javac' just once.
Slashdot Mirror
I used the Info-ZIP version of "zip" (it's the one that comes with Debian).
Zipping two copies of a file produces an archive twice the size as zipping a single copy of that file. This goes for updating as well (adding a renamed copy of a file to an archive that contains only the original will double the size).
I don't know if WinZIP does it differently.
I think that ZIP is more like .bz2.tar instead of .tar.bz2. This means that you can extract individual files without decompressing the whole archive. This is probably why Sun went with ZIP for JAR files (because it's convenient to get at some .class files without unzipping the whole thing).
This difference is also probably why .tar.gz and .tar.bz2 are usually smaller than ZIP archives. I don't think ZIP runs different files together so it can't take advantage of longer streams.
It's convenient to have directories separated from files because then you can do directory navigation without the mouse. If there's only one text box, then you often end up overwriting the filename that is given to you by default.
The file selection dialog in Gnome 1.4 sucks because when you create a new directory, it doesn't automatically place the focus on the text box. Also, after you manually click on the text box and type in the name of the new directory, pressing enter wont trigger the "create" action either.
Yes, I'm a Debian/testing user stuck with Gnome 1.4. Well, I have the Gnome 2 libraries and GDM2 (which is slower than the original GDM2 and has the location of the Yes/No buttons reversed) but all my other stuff is Gnome 1.4. That's thanks to Debian's smart "dist-upgrade", which also uninstalled a bunch of other crap without replacing it with equivalent programs. I also don't have an application to configure the theme for GTK2-based apps (anybody know which package to download?).
Totally ridiculous. That's the kind of crap you can expect from a totally clueless reporter. The sentence is ambiguous and in the end, it doesn't really say anything.
For some reason, he felt the need to mention that 10 systems were tested "together" without saying how.
It says that FastTCP can boost the speed past the "capacity" of ordinary broadband links. I don't know how you can get performance that exceeds the capacity (which I take to mean the theoretical limit). On the other hand, it isn't really clear if they even used "ordinary broadband links". For all we know, they could have been testing on a local GigE network (or on localhost!).
If he's trying to say that FastTCP gets 6,000 times the throughput of TCP, then this implies that TCP can be at most using 1/6,001 of the theoretical maximum. I'm guessing that they're advertising some corner case (or the reporter is retarded, which is probably just as likely).
FastTCP just seems like a better predictor of the delay/capacity properties of a connection. The New Scientist article says in one place that they were able to achieve a 4x increase in transmission speed between Geneva and California, which is impressive, but it's probably under strange conditions. The graph in their paper shows that FastTCP utilizes the link about twice as well as regular TCP when you get to 10Gbit links. The "reporter" must have done some serious mangling to get the number 6,000.
The "Smart" prefix is overused to the point of being totally meaningless. Hmm...it sounds like my clock automatically updates it's display as time passes....I think I'll call SmartClock.
TCP already does a lot of tweaking to get better throughput. What is your problem with FastTCP? At least "Fast" adds meaning. I guess you could have done worse and suggested "IntelliTCP".
It's free registration. Just like the NY Times. But yeah, I hate the NY Times links...keep forgetting my login.
Without the element of choice, entire crops were lost.
Seriously, though...this is what you sound like:
If it were that easy, don't you think somebody would have done so? People try to make things extensible. Sawfish allows you to change a lot of the behavior (run sawfish-ui). I'm sure there are others that allow even higher degrees of customization. What is your beef with those window managers? Do you need to be instructed to use a particular one? I COMMAND YOU TO USE SAWFISH. Happy?
Whoops. In my original post, I linked to a document that described features that were being considered for addition into the language. Don't know what the current official state of C# is.
Actually, my mistake. Technically, C# does have closures. But the lack of Ruby-like syntax makes them seem clunky (though slightly less clunky then Java's anonymous inner classes.
If Java supported closures, the 'foreach' construct wouldn't have to be a special case. I think C# is going to have something that looks a lot like closures but for some reason, they are going to avoid providing general-purpose closure support (it's sad, really).
On the other hand, it looks like the value/class distinction in C# is going to help make its generics more efficient than Java's. It'll be like C++ except with runtime specialization when needed, so the disk image wont be bloated, just the memory image.
Does anybody know if the class cast will be ommitted? That would be an efficiency increase.
For those who might propogate the urban legend presented in the parent post, I suggest reading this first.
Where on the site did it say that a packager requires a sponsor? From the "About" page, it seems like they're warning you that the packages might be poorly-packaged/broken.
Implementing it the way you did is correct, but it needs to acquire the lock on every call. The (ultimately incorrect) version described in the article tries to avoid locking in the common case. As I just learned, there is a subtle problem with that.
I'm pretty sure the Sun JVM (and most others) doesn't employ reference counting.
I don't understand...are you saying that two threads can be executing code within the synchronized block at the same time? What is an "unsynchronized thread"?
Static typing is such a pervasive part of Java you might as well use something else (like Ruby or Python). What does Java minus static typing have that you can't get from somewhere else?
Have you ever tried generating the JDK 1.4 API docs with javadoc? It killed my 128MB RAM machine.
How did you come to that conclusion? The run-time profiling advantage can let the JIT do things like compile code with branch-prediction hints to make it run faster than a statically-run compiler could.
No, it isn't a good idea. That's why they didn't do it. One of the first things they tell you when you do Swing stuff is that all mutations should happen in the event-handling thread.
So lemme get this straight...you're saying that when you have lots of sound to process, your CPU just sits idle until it has been "assigned" to process sound? I'm pretty sure the gains you will realize by not doing any context switches are insignificant when compared with the losses from having a CPU sit idle.
I didn't know that "virus" is a subset of "gene".
I'd expect that some may need to strip the JIT compiler out of J2ME installations.
And like 'javac'? Yay! Now I get to plug my program again. It tries to make 'javac' a little faster. However, if you read the source, you'll realize that there are lots of problems with doing this in a general way. The problem is that the Java environment isn't designed to handle this.
Some of the problems are:
Yay! Please take a look at my program. It maintains a single JVM in the background and waits for compilation requests. Though this isn't really general purpose, if you run 'javac' a lot, it is pretty helpful. Now you don't have to mangle your Makefile to force it to collect a list of Java files so that it can call 'javac' just once.