Rethinking the Linux Distribution (O'ReillyNet)

[Posted May 14, 2007 by ris]

This O'ReillyNet tries to think outside the box when it comes to Linux distributions. "As I hope to demonstrate in this article, FOSS tools are the right technology to define the post-PC software era, and not merely as a backend platform for someone else's proprietary SaaS (Software as a Service) suite. Today's typical Linux distribution, however, follows a design that resembles a legacy Unix system with a Windows-style front end bolted on. This is a competitor to products such as Vista, which may actually be the last of its kind, even for Microsoft. It would be unfortunate indeed to suddenly find ourselves stuck with yesterday's business model."

to post comments

Green Computing

Posted May 17, 2007 18:30 UTC (Thu) by filker0 (guest, #31278) [Link] (2 responses)

I kind of hate to say this as it will upset some people out there who I respect greatly, but some of the model that is suggested in the article for the Web OS goes against the greener (less resource hogging) goal. Well written Java apps, no matter what the proponents say, use more resources than equally well written C++ or C apps because the runtime environment in the two latter is passive, and in the former is active. Compiled Java (to native code) is somewhat better, but keeping the Java semantics intact still requires an active runtime.

Background resource garbage collection is just fine in some situations, and for applets running within a larger context, I have no trouble with it. For a large application (word processing, database, spreadsheet, manufacturing control, enterprise accounting, transaction processing, etc.), the overhead imposed by the constructing, destructing, and reaping of transient objects, the copying of data when converting from communications character sets to internal character sets and back, and a number of other things that large Java applications do a lot of, keep the runtime environment (JVM) quite busy, thus not providing as much idle time and using more resources on the CPU / VM that might be used by other processes/VMs. Explicit destruction and freeing of dynamic memory resources is more efficient, but requires more dicipline on the part of the programmer to avoid memory leaks.

A greener interpreted language, or a new generation of Java and JVM (not byte-code compatible, some altered semantics) to allow architecture independent binary apps might be able to solve this, but the current Java does not fit the goals of greener computing.

Green Computing

Posted May 18, 2007 0:42 UTC (Fri) by Per_Bothner (subscriber, #7375) [Link] (1 responses)

keeping the Java semantics intact still requires an active runtime

I'm tempted to say "nonsense" but will only point out there is a lot of hand-waving without proof.

For a large application ... the overhead imposed by the constructing, destructing, and reaping of transient objects

It's not that much with modern garbage collectors. And of course the overhead of malloc is quite substantial too.

thus not providing as much idle time and using more resources on the CPU / VM that might be used by other processes/VMs.

For something like a word processor, there will be no input events most of the time. Which means if the application is well-writtem (no silly spinning animations or pinging a server) there is no reason the VM can't be idle.

Explicit destruction and freeing of dynamic memory resources is more efficient

Lots of experts disagree.

Nonsense.

Green Computing

Posted May 18, 2007 15:35 UTC (Fri) by filker0 (guest, #31278) [Link]

I base my comments on some work that I did 3 years ago using an instrumented JVM, and stand by my comments.

malloc()/free() do have significant runtime costs, but well written applications don't used them nearly as frequently as Java creates and discards objects. In C, it's always explicit, so the programmer has to know about it. In C++, it can be hidden, and many C++ programmers don't pay much attention, but analysis of the code can locate where objects are being created and destroyed, and the impact minimized. In Java, unless you are extremely careful and use byte arrays rather than strings, you're likely to be creating and destroying objects quite frequently without knowing it. It is in the parsing of strings (including XML) that this is most noticable.

I'm afraid my proof is not my property, nor am I at liberty to talk about the specific project for contractual reasons, but this was work that I did for a large corporation that is very pro-Java, both on the client and server side. My focus was on the server side, in fact. I was hired specifically to find the ineffincencies and come up with design changes in the code to eliminate them still using pure Java. It lead to a lot of unobvious code, but a speed-up of about 8x over the straight-forward code. Use of the un-documented unsafe class, or JNI, was not an option (though we would have had more options.)

In the case of Java applications on the client side, GC and the Java event model sometimes conspire to cause applications to become momentarily unresponsive. I've seen this lead to mistakes and frustration by users who hit a key sequence multiple times before anything happens, only to have all of the events happen all at once. There's not always a useful "undo".

So I stand by my belief that Java, as applications are being written in it now, is not a Green technology. It can be made more green by changes in the JVM, and perhaps has since I did my research. Perhaps I'm an old codger, but I'm also an efficiency weenie with a background in embedded and real-time programming. Java is fine for the small applet, but I'm not happy with it for large applications -- it's just not light weight enough for my tastes.