$ sudo mkdir /opt/google/chrome/plugins
$ cd /opt/google/chrome/plugins
$ sudo ln -s /usr/lib/adobe-flashplugin/libflashplayer.so libflashplayer.so


Then you have to manually start chrome with this command switch (or edit the menu properties).


$ google-chrome --enable-plugins &


Tada!

This is a q&e summary of my experiences with Ubuntu 9.04 (Jaunty Jackalope) Desktop, and the various performance related issues that have dogged me to this day.  Actually, some of these problems date back to 8.04, and were radically more pronounced on 8.10 which was almost unusable for me. Ubuntu Desktop 8.10 sucked OUT LOUD. At least from a Desktop performance perspective.

Update 2009-12-30: I have belatedly upgraded to 9.10, and my first, early impressions are that it is much improved. Probably due to improvements in the Intel video code.

Update 2010-02-12: Bit the bullet and upgraded to 4G RAM and nVidia graphics. Life is good now. The lesson seems to be that 1G is not enough for full time Ubuntu usage.

Synopsis: Ubuntu Jaunty 9.04 is problematic for various hardware profiles. Intel video chipsets are especially a prickly path to travel. The bar has been raised for system memory as well. 9.04 may run in less than 1G, but the performance will be poor in anything less than 2G. Power users go for 4G. Hey, RAM is cheap these days.

My Hardware

I have two systems to compare, my home desktop and my work desktop. These both run the same version of Ubuntu (and have since 7.04). Both started with 1G RAM. My home system is 3Ghz Celeron with onboard Intel video. My work system is a dual core Intel processor with Nvidia video. Both have Intel motherboards, and are similar in many other respects. My work system was new in Sept 2007, my home system is a little older. Both had also been very similarly configured and tended to run the same mix of apps. I am a command junky, so I tend to do a lot with terminals. Its not unusual for me to have multiple terminal windows opened all the time. And always a few Firefox windows (I work as a web developer).

I have not done any benchmarking or formal comparisons of the two systems. The following is just my attempts at getting a decent level of performance out of both systems.

Both performed admirably up to and including Ubuntu 8.04 with little noticeable difference.

Nose Dive

Upon upgrading my home system to 8.10, performance went into the toilet. Into some real deep doo-doo. My home system was for all intents and purposes unusable, it was so painfully slow. Had this been my first Linux experience, I would have run, not walked, back to whence I came.

Every task was excruciatingly slow — opening windows, changing desktops, scrolling in Firefox. Ouch. Ouch. Ouch. My work system also suffered but not nearly to this degree. Conclusion here: Intel chipset blues (see various online articles related to this).

To ameliorate this, I reconfigured X, changed to a lesser resolution, and switched from Gnome to xfce. All these helped a little. And I started being careful of how many programs I had opened. As a long time Linux user (since 1998), this was the first time, I had to worry about this kind of BS.

As the 9.04 release was just around the corner, I waited for that, and by now finding out that there were acknowledged Intel chipset problems.

Upgrading to 9.04 did help, but still I had a dog system. It was often decent for a few days, then performance went through the floor. Opening any application was painfully slow. Scrolling a simple Firefox page was painfully slow (and top would show the CPU was pegged at 100%). Typing in a Firefox input field was similarly slow. Restarting X every few days, would help, but I HATE doing stupid stuff like that. That’s a Bill Gates legacy issue. Our goal, and repeat after me: never reboot, never take stupid steps to help performance issues.

My work system was noticeably better. But instead of a few days, I’d start feeling the need to restart X maybe once a week or so.

For a goodly time I was convinced of a configuration related issue. Then someone clued me into /proc/meminfo, specifically the Commit* lines:


$ grep Commit /proc/meminfo
CommitLimit: 3512248 kB
Committed_AS: 2100996 kB


The Commited_AS line tells me how much memory my currently running programs have requested. That right now is about 2G. That includes the Window Manager (xfce), several terminal windows, one web browser (chrome) with 5 tabs, several instances of the editor gvim. That’s pretty much it. Not a lot going on really. That’s about where the sweet spot is for me.

The rule of thumb here is you want that Committed_AS to be less than 2 times physical memory. When it goes beyond that, you will get excessive swapping, and eventually things start to crawl. When you hit 3 times physical memory, it starts to feel painful. That’s where I was initially, and have altered my usage habits to try to stay under the 2G threshold.

Here are some previous stats on the same system. Remember 1G physical RAM:


Logged out of X (which restarts the X server), sitting at GDM login:
Committed_AS: 452512 kB

XFCE w/typical app mix including FF, Chrome, multiple Konsole windows and a few vims.
Committed_AS: 1577520 kB


This is where I cut my teeth. The other system, my work system, I was able to upgrade to 4G RAM. It runs like a sports car now No slow downs, no temptation to reboot or restart X.

In the course of all this, I also learned that the Intel video chipsets have developed serious shortcomings as part of an overhaul of the code. So in the long run, this is probably a good thing, but in the short run, there are a number of issues. The one that got me was performance related. I tried various configuration changes to help ease the pain, but nothing has really seemed to help. *sigh*

Conclusions

There are two major issues:

You can’t run Ubuntu 9.04 Desktop comfortably with 1G of RAM. Forget it. Unless you reboot frequently or don’t run things like web browsers. Ubuntu desktop is a hungry beast. Feed it or suffer the consequences. 2G minimum, 4G recommended.

Intel video sucks the big one on 8.10 and 9.04. This is possibly short term pain for long term gain, but in the meantime, avoid Intel onboard video. Its painful.

Other tweaks discovered and worth noting:

xfce is significantly lighter weight than gnome. Recommended for anyone with performance related issues.

Google chrome browser performs significantly better for me than Firefox. It opens faster, it loads pages faster, and it actually scrolls without taking all CPU.

The Abode flash plugin (sadly) solves some problems with sound that can come out the open source plugins.

And lastly, close those unused programs. They eat memory. This was never an issue with me on older Linuxes, but definitely is a factor with limited memory resources with newer Ubuntu desktops.

So where am I now? Still an Ubuntu guy. Hoping the future gets a little brighter. Or the ol’ pocketbook can afford a new/improved system.

“Open Source” is one of those buzzwords that probably doesn’t matter much to most people. But its our bread and butter. We use Open Source products to run our servers. We use it to build and manage websites. We use it for hosting, marketing campaigns, and internal business applications. And its not just us. Much of the Internet is built with Open Source products. Google for instance, is built on Linux, an “Open Source” operating system. Its worked out OK for those guys. And Apache, an Open Source web server, has been the #1 web server on the planet since 1996 (based on Netcraft web surveys), despite Microsoft really working to flex its muscles in the server realm. Apache has succeeded because the Apache Foundation produces a first rate product, that is fast, featureful and robust. Firefox, the web browser, is something that possibly resonates with more people. Its Open Source too.

OK, Open Source matters to us, but why should it matter to our clients? Well
because there are number of benefits to Open Source development, that trickle
down and benefit our clients, and ultimately, our client’s users.
Using Open Source tools will allow us to produce quality products:

• At Less Cost
• Faster
• Using the newest web-based technologies
• With better support for web standards

Now let’s look at why this matters a little more closely:

• Less costly. While many Open Source products are “free” (meaning
  without monetary cost — “free beer” vs “free speech”), they are not all
  “free”. But certainly we can bring a server on line with minimal software
  expenditure. We can then build the finished products that will be the
  websites on that server using tools that often cost relatively little.
  These savings get passed directly to the client. Money matters.
  
• Faster development cycles. Most of the core software we use for server
  deployment and website building can be downloaded and installed in a
  matter of minutes. Of course, we are providing a number of value added
  improvements to this code, so that the finished products are just what our
  clients want. The fact they we can readily access code that has some of
  the functionality that our client wants, makes it easier for us to look at
  that “open source” code, modify it, add to it, and improve it as we see
  fit, and then launch it. Anyone that has done Open Source development will
  tell you this is a huge time saver in many instances. Time matters.
• Fast adoption of new web-based technologies. Things happen faster in the Open Source world. The development cycles are much faster than in the closed source world. Anyone can start a project any time they want and explore or adopt new ideas and features at the drop of hat. When new ideas come along, and if they hit a nerve on the web, they spread like wildfire. Open Source by its nature responds quickly. Closed, proprietary systems have to wait for the next software production cycle. And if they misjudge the merits of a new concept, maybe two release cycles. (How many years did it take Microsoft to acknowlege and adopt RSS? Three? Four? Five?). Technology matters.
• Better support for web standards. The Internet is built on “standards”.
  Standards provide a common language so that one system here can talk
  reliably to another, very different system over there. There has to be a
  high level of commonality in protocol implementation for this to work
  the way we’d like. One way this can fall apart, is proprietary closed source
  providers that have a dominant market position, can play fast and loose
  with the standards. Their non-compliant products always can be made to
  work with their own products, but working with somebody else’s product
  that is standards compliant, gets to be hit or miss. So
  the little guys on the standards compliancy side have to adjust what they
  do so that it works correctly with both the standard compliant vendors,
  and the big boys with non-standards compliant products. Anyone who has
  worked with web development will tell you that Microsoft’s Internet
  Explorer browser is a nightmare to code for, just for these reasons. It
  has had a history of poor standards compliancy (this is changing for the
  better now). When we are talking a potential audience of millions and you have a few percent that you miss because of compliancy issues, its going to add up pretty quickly. Standards do matter.

These are meat and potatoe reasons our customers receive tangible
benefits from our participation in the Open Source software community. They
are more likely to get a quality product, faster, and cheaper than if the same
project were built soley with proprietary, closed source products.

But there is one last reason that Open Source matters. And this is a
philosophical point: because its open, and its “free” ^[1]. We, in the United
States, live in a free and open society. At least, we aspire to those lofty
ideals. We preach them and foster their acceptance around the globe. I’m
hardpressed to think of a way to use those two words in a sentence, and come
up with anything that has a negative connotation. We have free speech, freedom
of the press, freedom to worship as we please (or not), freedom of choice, of
assembly, and so on down the line. Freedom is just “good”, no?

Yes, free access to the code we use to build servers, sites, applications and
share information with is a good thing. It allows us to share and improve a
global codebase that is open to all of us, not just the few. It is not held
in proprietary hands and licensed to us temporarily as the masters of that
codebase see fit. It belongs to us, we, the people. Yes, freedom matters too.

Open Source matters.