If you read the summary, it does say "client usage", though.

Why? Why would you mind just having the files laying dormant on your file system? As others have pointed out, they're even used by many third-party programs, so at least it's better to let them remain and be used as shared objects.

I mean, there are a million other components of Windows that you may or may not need but that you can't remove either. Just look through the CLSID key in your registry, or check out the many utility programs in your System32 directory.

If you really wanted a system with choice of components, you wouldn't be using Windows to begin with. Why single out IE specifically?

I wouldn't be so sure. When you install the JRE, you get to choose whether it should integrate with MSIE and/or Mozilla browsers. I can't say that I've tried, but I'd guess that if you choose for it not to, then it doesn't install any plugins. If, on the other hand, you choose for it to integrate with the browser (which is, reasonably enough, the default), then it does so.

I really don't see the big deal here. When you install the JRE, you would normally expect it to install a browser plugin, so that applets are displayed, and that's what it does.

Mind you, this differs from Microsoft's plugin, which arrived unannounced through Windows Update.

I agree with the sentiment of your post, but this is not quite correct. Unicode was not invented for Plan 9 (in fact, it seems to have been invented by some Apple guy). Ken Thompson invented UTF-8 for Plan 9 with the purpose of encoding Unicode in an ASCII-compatible manner, and UTF-8 sees only very little usage on Windows, which mostly uses UCS-2 (or is it UTF-16 these days?).

I just thought I'd pick that nit. :)

I don't mean to be trolling, but I don't really think that anyone has a right to be surprised or hardly even angry anymore. Microsoft has been doing things of equal or far greater magnitude of evil for as long as they have existed. If you let an operating system from Microsoft run your computer, then, honestly, I think you just have to reap what you sow.

Why anyone is letting Microsoft run their computers, especially in a business or, even worse, in government, is beyond me. I mean, the people at MSFT clearly do not grasp the concept that people might want to own their own computers. Aside from free software, I can't even think of a single proprietary vendor that has the same track record of evil on their shoulders. Apple may be able to claim to be a competitor, but they don't match up to Microsoft.

I might get modded down for this, but I really don't mean to troll. I don't really think I've said anything but the truth.

Yeah, which is bad indeed. But infinitely better than a web browser.

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.