$ 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.

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.

I hired Bradley Mills of “Mills Remodeling” to replace a roof that had suffered storm damage. The roof had not leaked or had previous problems.

Bradley seems like a nice enough, hard working young guy. He is from Bardstown, KY though does most of his work in Louisville, KY. He completed the work for me on time, and was paid the agreed to amount. The house itself is rental property. Several months later, the tenants called me with the news  that the ceiling in the living room at collapsed. Sure enough, it had. A roof leak had brought it crumbling down in a big pile on top of their furniture. There was also damage in 2 other rooms.

I contacted Bradley Mills (its more of a one man show than a real business). He was courteous and said he would look into it. Having not heard anything in a week or so, I called him back. He agreed to meet me there. He looked at the roof and the damage inside and agreed that the damage was due to leaks. He said he would care take of them and the resulting damage. That is the last I heard from him. Bottom line, the roof was poorly done, and defective and Bradley Mills refuses to this day to do anything about it. In fact, he refused to accept any phone calls from me at all. Attempts to contact him through other means, were unanswered as well. He had disappeared totally. A black hole of a business operation!

After filing a complaint with the Better Busines Bureau (see here
), Bradley called to inform me that he did the roof as “a favor” to me ($5,000 payment for the “favor” not withstanding), and that he offered no warranty of any kind, written or otherwise, therefore was not obligated to fix anything.

So this is Bradley Mills: hand open, ready to take a paycheck, but refuses to stand behind his work. Obviously the man does not know enough about roofing to be on one. And his “customer service” leaves something to be desired, to put it mildly. So buy beware!

Warning: Do not let this man on your roof! Make sure you get a guarantee IN WRITING. Or you may well be screwed.

“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.

• How granddad invented Tabasco Sauce
• I own a piece of the Titanic
• Hitler’s Doorknob
• Famous Kentuckians no one has ever heard of
• That’s what happens when earth fucks with space
• Sued by a moron
• The Gospel according to St Jimi

The True History of Tabasco Sauce.¹

This is really one of those rags-to-riches, American success stories. To get to the beginning of the story, let’s start at the end, and then march backwards. First, some family history …

My mother is Laura Bullitt Burgiss,
whose father was Hugh Kennedy Bullitt,
whose mother was Heloise Kennedy Bullitt ²,
whose mother was Anne White Kennedy,
whose father was Maunsel White,

and the guy that invented Tabasco Sauce.

I guess that makes him not granddad, but great-great-great-grandad.

Maunsel was born in Tipperary, Ireland in 1784. Orphaned at the age of 13, he emigrated to the “colonies” in the late 1700’s, settling first in Louisville, Ky. where he worked as a clerk in the shipping industry. Commerce was primarily river based goods at that time, and eventually he relocated down-river to New Orleans. He quickly did quite well for himself in various business ventures, becoming wealthy, eventually owning several plantations, including the “Deer Range” plantation (near New Orleans), where he hosted such notables as Andrew Jackson, and Lady Wilde (Oscar’s mom). By the time of the War of 1812 he was well established, captained and financed the “Lousiana Blues” regiment.

The principal crop of his plantations was sugar cane, but Maunsel dabbled in various other horticultural interests, including a failed attempt at marketing a fermented beverage made from oranges. He also had a taste for peppers.

A sea-captain friend, who traveled the Caribbean, returned one day with a handful of pepper seeds from the “Tobasco” region of Mexico, which were unknown in Louisiana at that time. Maunsel began cultivating these peppers. As was the custom of the day, these were called “Tabasco” peppers (variously spelled “Tobasco”) for their native region.

The traditional method of preserving peppers was to dry them. Tabasco peppers are unusually oily, and Maunsel found they did not dry well in the heat and humidity of south Louisiana. Not to give in easily, he experimented with sauces made from the peppers which he bottled, and was known to give freely as gifts to friends and neighbors. He eventually settled on a vinegar based sauce. “Maunsel White’s Tabasco Sauce”, as it was known in its day, was well known in the area prior to 1850, and the successful marketing of THE TABASCO® Sauce in the late 1860’s by the McIlhenny family of nearby Avery Island, Louisiana.

The McIlhenny family (founders of THE Tabasco Sauce) were neighbors and acquaintances of Maunsel White, and undoubtedly knew of his sauce, which pre-dated their own concoction (despite their apparent denials). Though well known locally, Maunsel never marketed his own Tabasco sauce. Family members did market several sauces bearing his name after his death. He died well before the commercialization of the product that he inspired.

Hal Burgiss