My Ubuntu 10.04 strategy

on my Pioneer Dreambook and it's running really well, no slowdowns lots of applications loaded (all in 1 Gig of RAM)

However. running Ubuntu 10.04 on a VirtualBox VM, after about 2 or 3 hours the VM slows to a crawl, just about hangs the host (64 Bit quad core 8 Gig of RAM with 1 Gig assigned to the VM), and finally kills the VM.

Quoting:on my Pioneer Dreambook and it's running really well, no slowdowns lots of applications loaded (all in 1 Gig of RAM)

Does it have Intel graphics, or Nvidia? Intel especially has trouble with this Xorg bug, which is somehow related to dri2.

It's funny - support for Intel video just gets worse and worse. I've never run a Ubuntu distro before release date, and I can't believe that 3 days from the release date there's a problem this huge.

If ever there was a reason to hold the release, this would seem to be one of those reasons.

And Lucid seems to be breaking quite a bit of new ground as far as features and design go. That doesn't seem very much in keeping with a release designed to be an LTS out of the box. Maybe when it hits .1, but not before then.

Intel Graphics

> If ever there was a reason to hold the release, this would seem to be one of those reasons.

I guess we'll find out if Ubuntu is ready for primetime. Even if there is a fix available, now is too late to allow for a Thursday release, on an LTS release nonetheless. If they want to be taken seriously for real applications they should wait at least a week. It needs more testing.

I wonder what kind of half-a**ed development process they've got that would allow a bug like this to enter in a release candidate. My guess is that this wouldn't happen to Red Hat.

Fix released:

[url=https://bugs.edge.launchpad.net/ubuntu/ source/xorg-server/ bug/565981]https://bugs.edge.launchpad.net/ubuntu/ source/xorg-server/ ...[/url]

Run

glxinfo | grep "GLX version"

If you are at version 1.2 rather than 1.4 then you are unaffected.

@bigg ... if a release candidate which is not a stable or final release, does not qualify looking for bugs to squash, what is it? Its a testing release ... if your not running a final your bug hunting, dont like it, dont run it.

@azerthoth

It's not a question of finding bugs in the RC, if you reread my post, you'll notice that I'm referring to bugs entering in the RC. If you read through some of the links it appears to have been due to a recent update of certain packages. They should not be updating packages so late in the release cycle that it is an issue in the RC.

rc = testing = still open to do whatever you want.

Quoting:glxinfo | grep "GLX version"

Before this will work, you need to install mesa-utils.

I just did this, and my output is:

GLX version: 1.2

Which means I'm "unaffected."

So what exactly is grabbing all that swap now that the xorg bug supposedly isn't affecting me?

I've been running Fvwm, Fvwm Crystal and Fluxbox in Ubuntu 10.04 - one of the performance-enhancing effects of not using GNOME is that much of that Lucid-y stuff, including gwibber-service and desktopcouch, isn't running, so the load on the system is greatly reduced.

I can certainly see myself adding Wicd so I can at least get my wifi under control without needing GNOME.

> rc = testing = still open to do whatever you want.

They're free to release with lots of bugs too, but that doesn't mean it's an intelligent thing to do. If you're adding the latest and greatest in a RC the release is more appropriately titled a development snapshot.

There is a message out there somewhere that this is not a Ubuntu Lucid bug, but an Xorg bug...

Someone indicated that you can reduce the swap grabbing by editing the /etc/sysctl.conf to either edit it to read or include the following line; vm.swappiness=10

(Those who don't know how to edit a system file may want to launch a a term console, and type: sudo gedit /etc/sysctl.conf and then do their edits from there.)

Ubuntu's default swappiness is 60, which is more of a setting that is ideal for servers than desktops...

Try it,... It's a nice tweak regardless.

Quoting:Someone indicated that you can reduce the swap grabbing by editing the /etc/sysctl.conf to either edit it to read or include the following line; vm.swappiness=10

A commenter wrote this on my original entry. I did change the swappiness temporarily to 10, and that did stop the overzealous swapping. I will make the change permanent and see how that affects performance over the course of a day.

I wonder what the default swappiness is in other distributions.

My funtoo install is defaulting to 60

Quoting: cat /proc/sys/vm/swappiness 60

So far swappiness at 10 seems to be working great. I'm leaving the machine running overnight. I'll see what it looks like tomorrow.

Quoting:I'm leaving the machine running overnight. I'll see what it looks like tomorrow.

At a guess... tired because it's been up all night and slightly feverish... I mean warm. :)

I'm not jumping into a pre-release version of Leaping Lemmings, thankyouverymuch.

Normally I wouldn't have run the beta, but after blowing out Debian Lenny with a failed dist-upgrade to Squeeze, then blowing out FreeBSD with a failed package/port upgrade, I couldn't do worse with a Ubuntu LTS in beta. It's like bears with honey, that Ubuntu.

Quoting: So far swappiness at 10 seems to be working great. I'm leaving the machine running overnight. I'll see what it looks like tomorrow.

Unless there is real evidence to the contrary, I do not believe that reducing swappiness from 60 to 10 will improve overall desktop performance even though many faqs etc. claim so (my own experience also corroborates this). If anything there may be certain usage patterns where it might help but not on an average.

The reason being that linux kernel will normally swap out only least used pages so as to make more memory available to programs. This means that new programs (or new plugins in existing programs like flash, or new tabs in firefox) will start and run faster due to more system RAM being available. Swapping out unused pages makes good sense in most desktop usages also because of programs like Xorg, firefox that may have allocated memory chunks that are no longer in active use (or are just constant "leaks" that will never be used) will be removed from RAM. Sure if one goes to some firefox tab after a long time then there may be more delay to bring it from swap, but I think such usage pattern is likely to be less frequent than opening new tabs, for example. Of course, all this will only be noticeable when RAM is near full.