I'm sorry, but I must conclude that you are either trolling, or that that specific application is really poorly written. I'll admit that I'm no great fan of Java really, but for quite different reasons. I've written quite a few Java programs in recent years, and performance has been the least of the problems. I have never experienced the click or processing lags of which you speak, and the startup lag is far less than a second, so it is certainly competitive with other GUI programs in that regard (I wouldn't use it to write command-line programs though, of course).

Most recently, I've been writing a MMORPG (as a hobby), where the client is written in Java precisely because that means I can use Java Web Start for dead easy "installations" on users' machines. You just click on a link and it runs. While there are a few (minor) performance problems, I have profiled the program and narrowed it down to certain algorithms, which I know how I could improve if the need would truly arise.

If you doubt me, you can try it (though you'd need to register, but it's an easy registration process). You would get to experience the goodness of Java Web Start, and you'd also see that there are no click or processing lags apart, of course, from those inherent to the Internet latency which is part of running an online game.

Be very wary of making that statement if you are not very sure that you know what you're saying. It is certainly true that the process monitor on both Unix and Windows will display Java processes as consuming hundreds of MBs of RAM, but that is because the JRE preallocates virtual memory for its heap. Virtual memory, mind you -- not physical memory. The OS (or at least Windows and Linux) will allocate physical pages to the process on demand, and the PermGen and OldGen heap spaces are compacted by the GC and therefore readily available for swapping out. The JRE interacts quite well with the VM for at least the most common systems.

You are correct, and that is definitely a problem. However, the problem is certainly not limited to Java, and bad programmers are abundant for any programming system you could envisage. I do not think that it is fair to blame that problem on Java.

I'd really like to go on a long tirade against "web applications", but I'm not feeling pumped up enough right now. I'll be content with insisting that such applications are violating -- nay, raping! -- the model of the WWW (being hypertext) and making it close to impossible to write a new web browser, the latter of which is a great problem, seeing how all current web browsers suck.

Actually, that is not quite true. Every time the user runs the JWS program locally, the JNLP client connects to the server to see if there's a upgrade available. It's even so good that it simply does the check per JAR file, so the program is upgraded very quickly, as only the files that have actually changed are re-downloaded.

In that case, I would recommend that you look to Java Web Start instead. It's as easy to deploy as an applet, but the user gets a real, stand-alone application instead.

That's why you have Java Web Start. It's as easy to deploy as a web application (it is just a couple of files on a web server), and you get the full goodness of a locally running application. And, since it's Java, it doesn't even take much effort to make sure it even runs on other clients than Windows desktops.

Damn you! You just made me waste hours on that site. Why didn't you warn me?!

Oh...

FYI, Coreboot doesn't do that, but many of the payloads that you put with it in ROM do. For example, I use Coreboot with FILO on my server. FILO is a port of GRUB that uses no legacy BIOS code (but rather accesses disk hardware directly). It is quite nice indeed to have a good bootloader in ROM.

Indeed, what you said about building better compilers certainly does apply, but it is well known to be a very hard problem to solve.

For example, one kind of code which would benefit greatly from SSE (or some other vector engine) is a simple matrix addition, for which the manually written C code might look like this:

/* Slashdot's stupid ecode tag removes my indentation :-P */
void add(int *m1, int *m2, int len)
{
int i;

for(i = 0; i < len; i++)
m1[i] += m2[i];
}

In assembler, you could easily write this code with SSE, packing four ints into an SSE register, adding them all with one instruction, and storing them back, making the code potentially four times faster (assuming all the data to be in cache, of course). However, how would you propose that a compiler be able to see this fact? It would have to do some kind of global analysis on the loop itself and figure out the aggregate effects of the operations happening inside.

Not that it's impossible, of course, and as I recall it, one of the largest changes in GCC 4 was that it switched to a new form of internal data flow representation, SSA, which was supposed to make it easier for the GCC devs to add certain kinds of auto-vectorization techniques later on. I seem to recall that it was supposed to be added in GCC 4.1, but I never kept track of it. Does anyone, by any chance, know if it was implemented?

Either way, the point I wanted to make is that some things are very hard to optimize. Even if it can be done, it may take quite some time between the point where a CPU vendor adds a new feature and the point where people figure out how to use it automatically in a compiler. (MMX, AltiVec and other vector engines have been around since -- I don't know? The 80s? -- and only recently have compilers been emerging to take advantage of them automatically (excluding such specialty languages as C*). For this reason, writing assembly language to optimize certain, specific code paths is still relevant. For the most part, however, it is very much correct that a good compiler with knowledge of a CPU's execution units, branch prediction techniques, register renaming schemes and whatever other have you, will outperform human-written assembler in most cases.

That just seems so very far fetched, though, mixing number systems in one post without any hint. Isn't it more likely, in that case, that we should interpret "11" as "11 Hz"? I wish the OP could give his opinion on this matter, because I really don't get it either.

I don't quite see the point of that, in all honesty. What, exactly, are the "conveniences" that you speak of? Automounting of hotpluggable media? As if "pmount sdb1" were any harder? Being allowed to use to mouse instead of the keyboard to browse files? Having a program menu, clicking interactively through 3 levels of menus instead of simply typing the name of the program you want to run? I don't know; I just get annoyed by these "desktop environments" and all the hoops they make you jump through.

I might (if I'm in a good mood) see some kind of point for the kind of people who are scared by seeing a monitor full of text, but between reasonable people? I do not see that the "desktop environments" actually have any practical advantages.

For the record, I'm using StumpWM. Oh, and get off my lawn! :)

Well, if you consider one-two seconds for opening a compacted Slashdot comment on a machine with a 2 GHz superscalar CPU and 2 GB of RAM "not that slow", I guess it "isn't that slow". As for me, I can see that there might just be some layers of cruft in there.

You might want to look at Debian. It has been running on ARM for quite a while.

Actually, it's because that's how it is. The "galaxy rotation problem" is the partially unresolved question of whether stars actually travel at the same linear velocity regardlessly of their distance from the galactic center. See Wikipedia.

Also, regardlessly of the galaxy rotation problem, I don't think you'd expect a galaxy to rotate like a solid disk, now would you? :-) (In case of doubt, think of the linear and angular velocities of our own solar system)

There is the problem, however, that in a VM, you need to be running Windows. There are those of us who don't particularly want to go buy a version of Windows just to run some Windows game/application. I applaud the Wine guys' efforts instead. They are doing an immensely impressive work.

To be honest, that in itself is probably worthy of notice. It is not a self-evident truth that all the laws of physics work exactly the same throughout the entire universe. There have, for example, been quite a few theories that have postulated that some of the fundamental constants may vary over space and/or time.

Therefore, just the confirmation that chemistry actually does seem work the same 11 billion years ago on the other side of the known universe is certainly not worthless knowledge. It may also have provided some knowledge about how long it takes for oxygen to accumulate in the evolution of a galaxy (though that may well have been known previously).

Furthermore, of course, it is a great verification of our observational capacity. Though the existence of water may not have been unexpected, our ability to observe it is quite something to marvel at, if I may say so.

Not that you don't have a point at all, but your argument is quite akin to saying that all games are equivalent -- "If you think The Sims is overpriced, just buy Unreal Tournament instead". Which is, needless to say, also quite ludicrous.

And you needed this article to tell you that something was wrong? ;)