Pinderkent

James Hamilton recently wrote about the use of low-cost and low-power servers, with a focus on ARM-based systems running Linux. He points out that the linux-arm.org site itself is running on such a setup. Looking at the specs of their systems reminds me of the servers we used in the mid-to-late 1990s, and even into the 2000s. Having been involved with software development for many years now, with much of my work revolving around networked business applications and server applications, I find this to be an interesting topic.

Clearly, a huge part of the problem today is the software we'd be running on such hardware. With the rise of Java, and especially frameworks like Ruby on Rails, far less of our hardware resources are used for actually performing the work of our software applications, and instead go towards powering the numerous frameworks, virtual machines, and platforms typically underlying our applications. Indeed, it has gotten so bad that some people are surprised when their Ruby on Rails-based Web application can handle "multiple requests per second", on modern hardware, without exhibiting performance problems.

Most recently, I wrote about Stack Overflow's outrageous hardware usage. Give the generally simplistic nature of that site, and the huge amount of processing power offered by today's low-end hardware, it's almost absurd to see how much they're apparently using.

When discussing lightweight servers, we shouldn't forget to consider the use of NetBSD instead of Linux. Aside from it already offering several ports to various ARM-based platforms, NetBSD is among the highest-quality open source software out there. I know of one person who used NetBSD on old PCs to serve images. I've also advocated it as an alternative to lightweight Ubuntu Linux distributions, as well as for use on low-power systems like Intel's classmate PC.

People today seem to forget just how powerful a typical server is today. Even the ARM-based servers that James mentions, or those powering the linux-arm.org Website, sound much more powerful than what we used a decade ago. That's not unexpected, of course. The cost of hardware rapidly drops, while its capabilities rapidly increase. Unfortunately, our software systems seem to eat up those gains rather quickly.

The main barrier to the widespread use of low-power and low-cost servers will likely be our existing software, frameworks, and platforms that use hardware resources very inefficiently. Instead of trying to salvage those, many of which are already a lost cause, perhaps we should be more willing to start from scratch, strip out all of the unnecessary layers of software that have accumulated, and make better use of functional programming languages like Erlang and Haskell. So not only would we get the benefits of using more efficient hardware, but we'd also get a much simpler and efficient software platform upon which to build our applications.

I recently saw an article about the accepted Project Coin changes that are planned to be included in JDK 7. This is some good news for the Java community. After a relatively long period of stagnation concerning the evolution of the Java language, and some fierce competition from C#, these are the sort of practical changes we need to see.

Most of these proposed changes aren't exactly revolutionary. Several of them have already been implemented for some time in C# and other .NET-based languages. They've proven to be effective there, and will hopefully bring the same benefits to Java.

The Automatic Resource Management proposal is a good example of a feature that is badly needed in Java. The using statement of C#, and the Using statement of VB.NET, have proven this concept. They make it safe and easy to ensure that certain non-memory resources are disposed of appropriately. This is exactly the sort of practical language-level change that Java needs.

The Strings in Switch proposal is another one that suggests a very useful change. Not being able to use a switch statement to select a case based on a string value has always been an annoyance to me.

The Improved Type Inference for Generic Instance Creation proposal may help making coding quicker, although I'm not convinced it's as beneficial as it sounds. Although it reduces what some may consider to be redundancy in code, most decent Java IDEs offer auto-completion support that helps prevent a programmer from actually typing out the parameterized types. And we do lose some detail within the object instantiation code, which otherwise is self-documenting in some sense. I think the benefits of this change will require some experimentation once an implementation is available.

Some of the other proposed changes, such as the addition of language support for JSR 292 and the collection-related changes don't seem as sensible to me. In the case of adding more support to the JVM and the Java language for supporting dynamically typed languages, I think this is a bad idea. The JVM itself is better suited to statically typed languages, and trying to hack on support for dynamically typed languages may just result in further bloat.

In the case of the collection-related changes, we are getting to the point where a major reworking of the collection classes is in order. We already have older classes like java.util.Hashtable and java.util.Vector, as well as the Java Collections Framework, and then all the changes that were made to both groups during the introduction of generics with Java 5. Trying to further build on the existing mess may just make the situation worse. But a clean up would be massive, and would have many repercussions on existing software. So there may be no easy answer here.

The acceptance of these proposals is a very good sign. They show the sort of activity and change needed to keep the Java programming language and platform relevant in the face of numerous other competing programming languages and platforms. I do hope that we get to see these implemented in JDK 7, as some of them do sound to be practical and badly needed by Java developers.

For several years now, those of us involved even in the slightest degree with Web development will no doubt have run into the numerous problems associated with supporting Internet Explorer 6. Although it has survived longer than much other software, and even today still has a significant number of users, many Web developers are finding that it's just not worth supporting IE6.

So while many Web developers and sites are beginning to phase out support for IE6, apparently even including heavyweights like YouTube, others aren't ready to do so yet. Toby Joe Boudreaux, for instance, suggests that we shouldn't stop supporting IE6.

All in all, this is a situation that those of us who have been in the industry for years have faced time and time again. There ends up being a platform of some sort that was heavily used at some point, but has clearly become obsolete. And there's always some resistance towards moving away from it, or no longer supporting it. Yet we typically find that once we've moved on to newer versions or newer platforms, we're much better off that we were in the past.

A good example of this is the JS2E 1.3 and J2SE 1.4 releases of the Java platform. A huge number of businesses standardized on it a few years back. Large systems were build upon it, and it became quite entrenched. Eventually, we had Java 5 available to us, and then Java 6. Yet there was a huge amount of resistance within these enterprise operations when it came to moving forward from 1.3 or 1.4.

I work with a number of different clients who have each standardized on different versions of Java. If there's one trend that is quite clear, it's that those who have transitioned to newer versions of the Java platform are much better off. For instance, one of those clients uses Java 1.3, even today. While it is generally suitable for their needs, they've been finding it more and more difficult to find good Java developers willing to work on such an old version of the platform. They also find it difficult to make use of the numerous class libraries and frameworks that don't support Java 1.3.

On the other hand, some of those clients are on Java 6. One of them is even actively developing some upcoming projects targeting Java 7. And what we see with them is a development team that is on the cutting edge, eager to use the new language features and third-party code or frameworks to develop more effective software in a more efficient manner. Whatever effort is spent on transitioning to newer versions of the Java platform ends up being dwarfed by the benefits the newer versions have brought to the developers, and then the users of the software systems themselves.

So one main lesson we can take away from this is that we shouldn't be afraid to discard old software, especially when we know there is much better out there, even if it means ruffling the feathers of some entrenched users. This is exactly where we are with IE6 today. Firefox, Safari, Opera and Chrome are clearly superior browsers, in just about every way. There are significant benefits, for both developers and users, to moving away from IE6. It's just one of those things that we should do, and the sooner the better. We shouldn't be afraid.

Thanks to a submission at Slashdot, I became aware of some recent efforts to prototype a new UI for the OpenOffice.org suite. Since OpenOffice.org isn't exactly known for having the nicest UI around, I thought we might see some significant improvements.

Unfortunately, that does not seem to be the case. I think this proposed UI is quite a step backwards, and not just because of its similarities to the "Fluent user interface" of Microsoft Office 2007.

My main complaint is that it's quite wasteful of space. It looks like about a quarter of the window space is consumed by the new toolbar or ribbon. This is partially due to the use of larger buttons. Functionality as simple as copying and pasting ends up using significant screen real estate.

So while we have larger monitors these days, we don't actually make better use of the greater screen area that they offer. Instead, it is wasted on unnecessarily large buttons and ribbons. And with smaller-screened netbook computers rapidly gaining popularity, even the slightest bit of wasted screen space becomes a hindrance.

For power users, a design of that sort is typically a step backwards when it comes to increasing their productivity. As some CAD software packages have shown, it often makes sense to get rid of mouse-based interaction. Some go so far as to offer a command prompt built into the bottom of the window, to allow for an experienced user to very rapidly interact with the software, and minimize the role of toolbars. Maybe this is an approach that OpenOffice.org should investigate.

Even for average or casual users, that sort of a design often proves to be confusing. Even now, a few years after Office 2007 has become widely used, there are many people I work with who just don't like it. While similar functionality is grouped, such a grouping may not be natural for all users. Such users have to repeatedly search through tab after tab, looking for how to perform the action they wish to perform. Their productivity ends up dropping significantly, as what should be simple tasks end up taking 10 seconds or more to perform.

I hope that the OpenOffice.org developers don't go ahead and adopt a design like the one that has been proposed. I'd rather see the UI left as it is for the time being, with more emphasis put towards improving the performance of OpenOffice.org, as well as reducing its often-significant memory footprint. Changes like those will, I think, help users out more than such a radical UI change, especially one that itself doesn't really bring any improvement.

Very recently, Google announced their upcoming Google Chrome OS product. One sentence in particular from the announcement caught my eye, that stating, "The software architecture is simple - Google Chrome running within a new windowing system on top of a Linux kernel." While much of the current discussion regarding this announcement focuses on the Web-related aspects of Google Chrome OS, I think this new "windowing system" for Linux is interesting in itself.

The X Window System is no doubt a very useful and effective windowing system in many ways, especially when making use of its network-oriented functionality. But as with everything, there are many things about it that could be better. Some of the main complaints revolve around its performance, resource usage, and complexity.

Although there are currently very few details about the "windowing system" for Linux that we're supposed to be getting with Google Chrome OS, I do hope we eventually see a system that is completely new. This presents us an opportunity to get rid of a lot of the cruft that has accumulated within the X-based stack, in order to produce a lean, efficient, and effective windowing environment. The initial targeting of netbooks, as mentioned in the announcement, will surely help with this.

Other efforts to provide an alternative to X, such as Fresco and the Y Window System, have unfortunately stagnated. But this windowing system would have the support of a major backer, and it sounds like it may achieve a significant market share within a short period of time.

I'm eagerly awaiting more details regarding this windowing system. It may very well have the potential to provide a more enjoyable Linux-based desktop experience, even for those of us who aren't overly interested in the Web-related aspects of it.