Zram to the Max

While trying to optimize the elementary OS performance, Sergey Davidoff stumbled upon a project called compcache that creates a RAM based block device which acts as a swap disk, but is compressed and stored in memory instead of swap disk (which is slow), allowing very fast I/O and increasing the amount of memory available before the system starts swapping to disk. compcache was later re-written under the name zRam and is now integrated into the Linux kernel.

I decided to give it a try, and the result on my desktop with a quad-core CPU and 2Gb of RAM was fantastic: instead of freezing after running out of RAM, the system worked like nothing happened. I didn't notice any difference at all. It looked just like adding more RAM! Surprisingly, I got almost the same results on a 6-year-old laptop with Pentium M and 1Gb of RAM! So, I've improved the script to automatically adapt to the amount of memory in the system and automatically scale across several CPUs or CPU cores, packaged it in .deb and uploaded to PPA.

- Sergey Davidoff

Sergey also mentions that the only thing that prevents this from being enabled by default in elementary OS Luna for now is the existence of Atom netbooks with fast SSDs for which he doesn't know if this would be useful or not.

This is especially useful for netbooks, old computers (or computers that don't have too much RAM), virtualization or embedded devices but of course, you can use it on any computer.

To install Sergey's script in Ubuntu 11.04 or 11.10, use the following commands:
 sudo add-apt-repository ppa:shnatsel/zram
 sudo apt-get update
 sudo apt-get install zramswap-enabler

THANKS: Webupd8

Fix unity kernel-level issues

To update the Kernel to 2.6.39-0, 0pen the Terminal and add the PPA (Personal Package Archive) by entering the below mentioned commands:

sudo add-apt-repository ppa:kernel-ppa/ppa

sudo apt-get update

After that, check available Kernal by entering the below command. Version 2.6.39.0 kernel should appear in the list.

apt-cache showpkg linux-headers

Then, run this command to update your Kernel.

sudo apt-get install linux-headers-2.6.39-0 linux-headers-2.6.39-0-generic linux-image-2.6.39-0-generic --fix-missing

Restart your system to complete the update. The system might become slow for a while, that’s normal since the Kernel will be updating during this time.

THANKS: wmcloud

Natty Upgrade review

[caption id="attachment_2922" align="alignleft" width="300" caption="Buggy Beta OS"][/caption]

I guess I was lulled into complacency by the regularity and finesse of Ubuntu releases, which since Karmic have been plain sailing for me. This one however takes the cake for the most immediately obstinate type of bugs. Being a major departure from what has gone before, there should have been warning signs. But the only release which springs to mind with so much trouble is Intrepid Ibex. Having enjoyed a good run, since I skipped a release and did a clean install of Karmic, then updated to Lucid and Maverick I was expecting more of the same, a couple of quick fixes after the beta release, but no, we have a minor disaster when it comes to compositing and kernel management, making this in all reality a Beta 2 release.

Take the following:

Natty 11.04 appears to have been released with an unstable Compiz core, the stable version according to the Compiz website is 0.8.6, however Natty has Compiz 0.9.4.0. How long it will take to fix this is entirely up to Compiz, which makes one question the wisdom of relying on Compiz at all. (You can downgrade compiz like this]

Then there is the kernel 2.6.38-8-generic. Which is a little ahead of the kernel.org recommendation which lists 2.6.38-5 as the latest stable kernel, so the entire community is bitching about snarl-ups and slow speeds. Some have solved this problem by rolling back to a previously stable kernel, see here

The price of making Mark Shuttleworth's great big leap forward is we have to break our systems, and then commit to spending hours of bug-fixing, merely so that somebody can show off the result at Google Code. Would it not be better to have introduced a longer testing period than to risk relegating everything until the next LTS to beta?

I can't complain because I've had a pleasant six months with Maverick which after initial problems with Plymouth has been a dream.

So I guess Natty comes with a ton of caveats and warning - this really is a major departure for an Ubuntu release. Install at your peril. Whether having the option of a couple of lenses in Unity is worth the effort, only time can tell. I can see the approaching revolution of activity specific lenses for different community needs, but all of this depends on getting the composting right, and then being faced with the question of why not just install Gnome 3?

Right now, I'm a bit dysfunctional for being forced to use the old Metacity in Ubuntu Classic. The artifacts in the Unity session are too many to make the experience of sitting there anywhere pleasant and I need to get work done. Mad Tux is all I can say. :)

A "200 lines" alternative patch script

I've translated a patch script that automates the hack that is being doing the rounds, it is by superpiwi @ Ubuntulife. Haven't tested it, so be warned. You need root privileges.

Add the following to a new file, name it something like 200patch.sh and chmod +x

#!/bin/bash

YELLOW="33[1;33m"
RED="33[0;31m"
ENDCOLOR="33[0m"



#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
# PATCH
Apply the kernel enhancements (patch 200 lines)
# But in 4 lines of bash

#
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
function PATCH()
{

FILE="$HOME/.bashrc"



echo ""
echo -e $YELLOW"Patching file [${FILE}]..."$ENDCOLOR
echo ""

# Adding strings to .bashrc



# First we look for a string "base" to see whether or not it has already been added
LINES=`cat $FILE | grep "/dev/cgroup/cpu/user" | wc -l`
if [ "$LINES" == "0" ];
then
echo "Adding patch for performance .."
echo "if [ \"\$PS1\" ] ; then" | tee -a $FILE
echo "mkdir -m 0700 /dev/cgroup/cpu/user/\$\$" | tee -a $FILE
echo "echo \$\$ > /dev/cgroup/cpu/user/\$\$/tasks" | tee -a $FILE
echo "fi" | tee -a $FILE
else
echo "it seems that patch has been included in $FILE"
fi



FILE="/etc/rc.local"
echo ""
echo -e $YELLOW"Patching file [${FILE}]..."$ENDCOLOR
echo ""

# Adding strings to... /etc/rc.local

#First we look for a string "base" to see whether or not it has already been added
LINES=`cat $FILE | grep "/dev/cgroup/cpu/release_agent" | wc -l`
if [ "$LINES" == "0" ];
then

echo "Adding patch for performance .."
POSI=`cat $FILE | grep -n "exit 0" | sort -nr | head -n 1 | awk -F: '{print $1}'`
#echo "Is possible [$POSSIBLE]"
echo "making backup $FILE in /etc/rc.local.backup.txt"
cp /etc/rc.local /etc/rc.local.backup.txt
sed "${POSSIBLE}imkdir -p /dev/cgroup/cpu\nmount -t cgroup cgroup /dev/cgroup/cpu -o cpu\nmkdir -m 0777 /dev/cgroup/cpu/user\necho \"/usr/local/sbin/cgroup_clean\" > /dev/cgroup/cpu/release_agent" /etc/rc.local | tee /etc/rc.new.local
mv /etc/rc.new.local /etc/rc.local

#echo "#========== patch improves ============" | tee -a $FILE
#echo "mkdir -p /dev/cgroup/cpu" | tee -a $FILE
#echo "mount -t cgroup cgroup /dev/cgroup/cpu -o cpu" | tee -a $FILE
#echo "mkdir -m 0777 /dev/cgroup/cpu/user" | tee -a $FILE
#echo "echo \"/usr/local/sbin/cgroup_clean\" > /dev/cgroup/cpu/release_agent" | tee -a $FILE
#echo "#====================================" | tee -a $FILE
else
echo "It seems that patch has been included in $FILE"
fi

echo ""
echo -e $YELLOW"Giving execution permissions to [${FILE}]..."$ENDCOLOR
echo ""
sudo chmod +x $FILE

FILE="/usr/local/sbin/cgroup_clean"
echo ""
echo -e $YELLOW"Building FILE [${FILE}]..."$ENDCOLOR
echo ""
if [ -f $FILE ];
then
echo "#!/bin/sh" | tee $FILE
echo "rmdir /dev/cgroup/cpu/$*" | tee -a $FILE

else
echo "File $FILE already exists."
fi;

echo ""
echo -e $YELLOW"Giving execution permissions to... [${FILE}]..."$ENDCOLOR
echo ""
sudo chmod +x $FILE

echo "COMPLETED. Applied patch, reboot and enjoy Linux ..."

}
#-----------------------------------------------------------------------------

# Check that you are user root
if [ $USER != root ]; then
echo -e $RED"Error: you must be root."
echo -e $YELLOW"Finishing..."$ENDCOLOR
exit 0
fi

# Patching the System
PATCH



# end of 200patch.sh

Note: I am not responsible if something breaks on your computer Anyway, it's easy to go "backwards" if you follow the instructions in the original post. However, before running the script I recommend you take a backup of your ". Bashrc" and your "/ etc / rc.local". If it does not give many problems, superpiwi will package. Deb.

UPDATE: Superpiwi reports a new version for the script as follows:

cd
wget http://launchpadlibrarian.net/59511828/cgroup_patch
chmod +x cgroup_patch
sudo ./cgroup_patch

Alternative to the 200 lines kernel hack

You may be aware of the recent debate around a 200 lines kernel hack which makes Linux 10% faster. Andrew from WebUPD8 just posted this alternative. It really does seem to work. I've reposted the relevant part for Ubuntu, but I seriously suggest you take a look at the original posting first.

To use Lennart's solution in Ubuntu (not tested - thanks to Lsh for this), you have to replace "/sys/fs" with "/dev". So you would have to add the following commands in your /etc/rc.local (open it with: sudo gedit /etc/rc.local) file, above the "exit 0" line:

mkdir -p /dev/cgroup/cpu
mount -t cgroup cgroup /dev/cgroup/cpu -o cpu
mkdir -m 0777 /dev/cgroup/cpu/user
echo "1" > /dev/cgroup/cpu/user/notify_on_release
echo "/usr/local/sbin/cgroup_clean" > /dev/cgroup/cpu/release_agent

and make it executable:

sudo chmod +x /etc/rc.local

And then add the following to your ~/.bashrc file (to open it: gedit ~/.bashrc):

if [ "$PS1" ] ; then
mkdir -m 0700 /dev/cgroup/cpu/user/$$
echo $$ > /dev/cgroup/cpu/user/$$/tasks
fi

Run the following command:

sudo gedit /usr/local/sbin/cgroup_clean

And paste this:

#!/bin/sh
rmdir /dev/cgroup/cpu/$1

then save the file and make it executable:

sudo chmod +x /usr/local/sbin/cgroup_clean

And finally, restart the computer.

Update: The above instructions have been updated automatically remove empty cgroups (thank to Ricardo Ferreira - see his comment below).

Update 2: 64bit kernels (Warning: use these at your own risk!!!) for Ubuntu 10.10:

If you want to go even further and install a patched Kernel, you can download a "200 lines" patched Kernel from HERE (thanks to accumulator @ Phoronix forums).

Also, WebUpd8 reader Scott Franke shared a patch he patched with bfs with which he says he gets better performance then with the "200 lines patch". Download from HEREand HERE.

Both of the above 2 Kernels are for 64bit Ubuntu 10.10 only! Use them at your own risk!

Read the discussion @ http://lkml.org/lkml/2010/11/16/392 | via Habrahabr.ru(thanks to Lsh)

Ubuntu kernel 2.6.37-rc1-maverick available

“…an author, with thesaurus in hand, chooses the names of variables carefully…” — Knuth, Literate Programming

If you want to test the latest rc kernel available from the Ubuntu kernel mainline team then hop over to this link, you'll want to download three files, the linux kernel and either the x86 or 64 headers.

Some users report that both 2.6.36 and 2.6.37 (there doesn't seem to be much difference between the two releases) fixes choppy video and lag in Maverick. There is quite a bit of talk about the slowness of the 2.6.35 kernel, so this might be a solution if you experiencing hardware problems.

THANKS: Khattam

NOTE: Ubuntu's default infrastructure for handling kernel OOPSes will not work for these builds as they are external to Ubuntu. To contribute this information to kerneloops.org you will need to make a couple of changes.

First, install the kerneloops-applet package which will handle the prompting and submission on any problem. Then edit /etc/kerneloops.conf and delete the submit-pipe line from the file, so that kerneloops-applet will be used. After a reboot kerneloops-applet will then prompt you if there are any problems and you can choose to submit the information to kerneloops.org.

See here

Install the stable 2.6.34 Lucid kernel

One of the great things about Linux are the new kernels.

Although the stable 2.6.34 is available for Lucid, it is unlikely to make its way into the official repos any time soon.

If you're experiencing issues with your current kernel, or just want a change, then stable 2.6.34 may be for you.

You will need to install 3 packages.

For 32 bit:

http://kernel.ubuntu.com/~kernel-ppa...020634_all.deb

http://kernel.ubuntu.com/~kernel-ppa...20634_i386.deb

http://kernel.ubuntu.com/~kernel-ppa...20634_i386.deb

for 64 bit:

http://kernel.ubuntu.com/~kernel-ppa...020634_all.deb

http://kernel.ubuntu.com/~kernel-ppa...0634_amd64.deb

http://kernel.ubuntu.com/~kernel-ppa...0634_amd64.deb

please install in order listed.

Then run  from a terminal afterwards:

sudo update-grub reboot.

to confirm you are running the new kernel type in a terminal:

uname -a

THANKS: nhasian

Some advice from Sgosnell

Features seldom get dropped from later kernels. It's perfectly safe to install newer kernels, because you can always boot from any kernel still installed. You can install the .34 kernel, and if you have problems just boot from the default kernel. You can easily remove kernels via Synaptic, as long as you aren't booted to the kernel you intend to remove. I would advise installing the .34 kernel and trying it out. I like it a lot. If it doesn't do what you want you can always remove it, and you can also install the .35 kernel over it when it is released. That will just result in the ability to boot to the .35 kernel in addition to the .34 kernel and whatever you already have installed. I tend to remove older kernels after I insure that the newer kernel works ok, just to save space and remove clutter, but I usually keep the default kernel for the OS version I have installed, although I seldom boot to it. It's just a final safety fallback.

NOTE: If downloading and installing precompiled kernels is not your cup of tea, then try KernelCheck, which will install and build the latest kernel for your distribution from source.

ADDENDUM: I noticed the debs above were compiled with an earlier version of GCC than the one which I am running (gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3), which resulted in a kernel check message from the nVIDIA installer. I therefore highly recommend using KernelCheck if you want to maintain concurrency with your compiler. If you run into a kernel panic check this posting of mine.