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.

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.

Today I read an article that discussed a variety of issues relating to Microsoft Windows today, including the general disappointment surrounding Windows Vista, and the apparent lack of interest in Windows 7, especially in the enterprise. It goes on to suggest that Microsoft themselves are responsible for this, and Apple will gain the most from this situation.

I don't think we're really seeing Microsoft tarnishing the Windows brand. In some sense, it's not even possible for them to do that. Many people, and not just Mac users, have an extremely low opinion of Windows to begin with, along with many of Microsoft's other software products. Although the NT-based systems typically don't suffer as badly from the chronic crashes and security flaws that plagued Windows 95, Windows 98 and Windows ME, users of those earlier versions will forever associate the names "Microsoft" and "Windows" with poor-quality software. Even today, I rarely meet people who outright like Windows. Most of its users just seem to tolerate it.

If anything is causing Windows to become more irrelevant, it's the widespread move towards Web-based applications. This isn't a novel observation, by any means. It has been obvious for some time now that many applications that were formerly desktop apps have been replaced by Web-based alternatives for a large number of people. People using Web-based email services like Microsoft's own Windows Live Hotmail and GMail instead of desktop mail clients is one significant example.

The move towards Web-based applications is a trend that has been common within enterprise software development for years now. More and more companies are replacing what were traditionally desktop applications with Web-based alternatives. Now this often isn't a good idea; there are some applications that are much better left as standalone apps. But in many domains, the software the users are interacting with is solely browser-based, and thus the underlying desktop operating system is essentially irrelevant.

When the user is interacting mainly with a Web browser, it really doesn't matter what operating system is underlying it. Mozilla Firefox and Opera alone are typically good enough for using most Web-based apps. So the need for Microsoft's software is diminished. This is why GNU/Linux has become more appealing for many enterprise users. It's not about GNU/Linux being more capable than Windows, but rather the opposite; it's easier and cheaper to strip GNU/Linux down to provide just the bare essentials for running the browser used to access the Web applications.

Microsoft saw the threat that Web-based apps posed to desktop applications, and put forth their Windows Live and Office Live initiatives. I'm not sure if these have been as successful as Microsoft would have hoped. In my experience, I've seen little to no serious adoption of these technologies in enterprise settings. This is one area where Web-based applications typically aren't as useful or acceptable. Many enterprise users want greater control over their documents, namely where they are stored and who can access them.

I think it's doubtful that Apple will truly make significant inroads into the enterprise. While some such users will likely switch to Apple's hardware and software, and others will no doubt consider it, given the current cost of Apple's offerings I don't see it happening on a wide scale. Much enterprise computing has been driven by large purchases of lower-quality and very low-cost PCs. As mentioned before, with many organizations moving towards Web-based applications, the need for overly powerful PCs is diminished. With low-end PCs still being suitable, many IT managers will need to cut costs by using GNU/Linux instead of Windows, rather than purchasing more expensive hardware/software combinations from Apple.

So we're likely looking at a more diversified computing world, with some users using desktop apps, others mainly using Web-based apps, and many using a mix of both. It's very unlikely that we'll see Apple's products, or any other company's products, achieve the same market share that Windows holds. There's just too much impetus at this time for such significant changes, even if future versions of Windows are as poor as Windows Vista was.

Through my work, I get to visit and work with many different businesses and organizations each year. And like anyone involved in business, meetings happen (far too) frequently, and they often include presentations. Although I don't have to give them very often, I do get to sit through them frequently enough. As laptop computers and projectors have become more prevalent, we've seen slideshows and similar presentations become used more often. While major mistakes can be made easily enough when using whiteboards, handouts and other presentation media, the laptop/projector/PowerPoint combination makes mistakes almost certain for some people.

By "mistakes" I don't mean minor stumbles while speaking, momentarily forgetting what to say, and so forth. I'm talking about incidents that can, within a few seconds, ruin the reputation of the presenter and the party or parties they may represent, or perhaps put an end to a valuable deal that has been in the works for some time. Although somewhat rare, they do happen more frequently than they probably should.

Those who have sat through enough presentations will no doubt have seen scenarios where a rogue popup alert window, often from a networked application like and email client or an instant messenging client, inadvertently displays some unsavory or very personal information. Similarly, some malware may open popups with various advertisements that do no reflect well on the presenter. Another major problem is personal and/or inappropriate photographs accidentally being displayed as thumbnails in the file browser while the presenter is starting to open their presentation. And sometimes laptop users have set a sound file to automatically play when their laptop turns on, but forget to turn down the speaker volume before turning their laptop on before the presentation.

Matt Hulett recently gave some tips to help avoid such mistakes. With respect to his first two tips, one good method of achieving that is, as mentioned by one of the commenters, to have a separate account on the laptop solely for presentations. I know some frequent presenters who take that a step further, and have separate accounts for each presentation, to avoid having the presentation for one group inadvertently displayed to another.

Some of those presenters even have a separate laptop they use just for presentations, and another laptop computer they use for work and personal purposes. I know one fellow in particular who uses a very minimalistic installation of Debian on his laptop. He doesn't even bother with installing a desktop environment, instead just using twm. Essentially, he has stripped his presentation laptop down to the bare minimum needed to make his presentations, and by doing so has eliminated many of the possible causes of major incidents. One thing he even told me is that he uses a shell session running in xterm to navigate his filesystem and start his presentations, to help avoid unintentionally revealing unwanted information to his audience.

With some care, preparation and forethought, it's often relatively easy to make a presentation go well. But it's also quite easy to be in a rush and forget something minor, such as closing down a running email client. Soon enough this can balloon out into an angry audience, and possibly even the end of valuable business relationships. A secondary, minimalistic, presentation-only laptop with separate user accounts for each presentation will go a long way towards preventing some of the most common incidents. Adequate preparation usually takes care of the rest. And if all goes well, the presentation will be a success.

Google's relatively new Web browser, Chrome, has generated a lot of interest since its initial release in September of 2008. It has managed to generate this even without native Linux and Mac OS X, although such ports are now in development.

Unfortunately, if this article from OSNews is correct, it appears that the developers at Google have opted to use GTK+ for the UI. The OSNews article does a good job of asking the obvious question: why not just use Qt for the Windows, Linux and Mac OS X versions of Chrome? The article suggests that Google opted not to use Qt, as they want to use native toolkits only, to allow for better integration with the host platform, and to avoid the warts that tend to accompany cross-platform applications.

I think that's a sensible policy. Mac OS X applications do differ in many ways from Windows desktop applications, both of which differ in many ways from X11 desktop applications. While cross-platform applications can be written that run on all three environments, they usually do feel somewhat out of place, and awkward to work with at times. However, it's too bad that Google has opted to consider GTK+ as the "native" toolkit for their Linux port, instead of using Qt, even if they opted to use the native UI functionality of Windows and Mac OS X for those versions.

It's difficult to give quantitative measures when comparing UI toolkits. So we'll need to rely on more qualitative analysis. Thankfully, GTK+ and Qt have both been used as the basis for a large number of popular open source applications that we can analyze.

One such way to qualitatively compare toolkits is in terms of responsiveness. And this is one area where Qt is often much better than GTK+. Qt-based applications often feel noticeably more responsive than similar GTK+-based applications. We can see this when using Kate and gedit. Kate is a text editor for KDE, while gedit is currently the official text editor of GNOME. Both are similar in terms of features and functionality, but I have always found Kate far more enjoyable to use that gedit. Gedit has a laggy feel to it, when opening menus, working with various dialogs, pasting in significant amount of text, scrolling through large files, and so forth. Kate, on the other hand, has always felt very fast; there is typically no noticeable delay between invoking a particular action, and the results of that action being available.

In relation to Chrome, a more apt comparison would be between existing browsers that use GTK+, and browsers that use Qt. Thankfully, we have several examples we can use. Epiphany is a Gecko-based browser coming from the GNOME project, and uses GTK+ for its UI. Many builds of Mozilla Firefox for Linux also use GTK+ as the underlying toolkit. On the other hand, we have Konqueror from the KDE project, and Opera, both of which use Qt.

An employment opportunity over the past six months has resulted in me making extensive use of all four of those browsers, on a variety of different PCs running various Linux distributions. After all of this use, I have to say that I've found Opera and Konqueror to offer the most pleasant Web browsing experience. While Epiphany and Firefox aren't bad browsers, they've always felt bloated. This isn't the feeling that one gets with Opera, for instance. And while we can't attribute their responsiveness solely to the underlying UI toolkit, it does help that Konqueror and Opera are both built on a solid Qt foundation. Pages appear to render faster in both, scrolling is much smoother, the browser menus and dialogs open without delay and can be manipulated without flicker, and both Konqueror and Qt feel like more polished, professional software products than Firefox and Epiphany do.

So based on my experience using other Web browsers that make use of GTK+ for the UI, I have not been very impressed. Qt-based browsers like Konqueror and Opera offer a much more enjoyable experience. Given Chrome's emphasis on providing a speedy and stable browser, Qt seems like the natural choice. The developers of Qt have put a lot of effort into making their toolkit one of the fastest out there, and this is reflected by the responsiveness of the applications that make use of Qt.

Qt also seems like a better fit for Chrome. Much of the source code for Chromium is implemented in C++. Likewise, Qt is also written in C++. But GTK+, on the other hand, is written in C, using pseudo-OO techniques. Integrating the Qt object model with that of Chromium may not be straightforward, but it likely would be cleaner than trying to integrate GTK+'s object model.

In terms of licensing, the recent announcement from Nokia that Qt 4.5, expected for March, would be available under the terms of the LGPL should make it much more appealing. Chromium already makes use of LGPL'ed software, including the essential WebKit. So while the licensing of Qt may have been a valid concern in the past, this no longer seems to be the issue it might have been.

One benefit that Opera has offered for some time now are Linux binaries that are statically linked against Qt 3. Although this can bring in the various problems associated with static linking, it does greatly reduce dependency-related problems. The user doesn't have to install Qt 3 themselves, whether from source or via the package manager of their distribution of choice. Assuming the licensing could be worked out, it would be helpful if static binaries of Chrome for Linux were available, to make installation more straightforward.

So while GTK+ will no doubt suffice as a toolkit in this case, it is too bad that Google opted not to use Qt. In many ways, Qt appears to be a better choice, and would help allow Chrome become a responsive, stable, high-quality browser for Linux. Like the OSNews article points out, a Qt-based implementation of Chrome may need to be written by the community, rather than by Google. I hope it doesn't come down to that, but it seems that Google has made up their mind and will use GTK+ for the time being. So those of us who prefer a Qt-based browser may need to just stick with Opera and Konqueror for now.