ARCHAN> How do i make history not stored ? i dont want places > recent doc to store  my recent files

Gnome doesn’t offer an option to turn off the tracking of recently open documents, but you can employ a simple hack to prevent it from happening. Your Places > Recent Documents menu listing pulls data from ~/.recently-used.xbel which stores your recent document’s meta data. It’ll be recreated if you just delete it. Rather, remove it and make a directory with that same name.

rm ~/.recently-used.xbel && mkdir ~/.recently-used.xbel

You can also use this same trick to eliminate your bash history at the command line. Every command you issue at the command line is saved to ~/.bash_history after you close or exit a bash session. Just replace the file with a directory of the same name.

rm ~/.bash_history && mkdir ~/.bash_history

If you ever need or want to use those features again, just remove the directories. The files will be recreated on their own as needed.

rm -r ~/.recently-used.xbel
rm -r ~/.bash_history

Above, I showed how to do it with command lines but you can do the same through a nautilus window (file browser). At your home directory, use CTRL-H to toggle between hiding and showing hidden files (the ones that start with a period) so that you can find the files and delete/create as necessary.

I’ve since eliminated the bottom panel and replaced it with Docky. In the top panel I replaced the Menu Bar applet with the Main Menu applet, removed some icons and added the CPU Frequency Scaling Monitor applet. I then went about setting the top panel to transparent to let the wallpaper behind it bleed through but the Ambiance and Radiance themes weren’t being cooperative. Only the panel would accept transparency but none of the icons. Below is what I ended up with:

That just wasn’t going to work. First thing I did was copy the Ambiance theme to my ~/.themes/ directory. This magically replaces the system’s default global settings for Ambiance with my own and lets me make edits without destroying the originals.

cp -R /usr/share/themes/Ambiance ~/.themes/

I opened Ambiance’s gtkrc file with gedit.

gedit ~/.themes/Ambiance/gtk-2.0/gtkrc

I scrolled down to the panel’s style section and looked for:
bg_pixmap[NORMAL] = "panel_bg.png"

I just commented out that line by placing a # at the beginning of it.
# bg_pixmap[NORMAL] = "panel_bg.png"

After saving the gtkrc file, the change wasn’t immediate. I opened the System > Preferences > Appearance settings, switched the theme to something else and then back to Ambiance. All of the icons and applets lost their backgrounds and the change was complete.

You can do the same with Radiance by copying the original files from
/usr/share/themes/Radiance
and commenting out its bg_pixmap setting.

For me, I like the darker gray windows of Ambiance along with my desktop’s new look.

During the alpha stages of Lucid’s development, a major update to Ubuntu’s theme was introduced which went far and away from the familiar brown. With that, the designers decided to also incorporate a new title bar button layout that flopped the minimize, maximize, and close buttons from the right corner to the left corner. Understandably, chaos ensued as many users offered lots of reasons why this was a horrible design change. But the term “many” should not be confused with “most” as there are plenty more users who aren’t that affected by it, myself included.

There’s been a lot of focus on window design, more so since the introduction of Google’s Chrome web browser, which omits a title bar and a menu bar altogether, yet still maintains the min, max, and close buttons, and functions quite nicely. Ubuntu hasn’t been the only one to rethink the window managers as Microsoft and Apple have done so as well in recent years.

But as much as the debate rolls on, users should not fear it so much. As many things are in the Linux universe, the change need not be a permanent one. If you’re unhappy with it, change it as Gnome provides the means to your end with gconf-editor.

Use ALT-F2 to bring up the Run Application window, enter gconf-editor and click Run. Browse to apps > metacity > general and find the button_layout field.

You can use any combination of six values: : (colon), menu, minimize, maximize, spacer, and close. Button names need to be separated with commas. The colon denotes the separation between the left and right corners. Following are some examples.

The default Lucid layout.
maximize,minimize,close:

The previous layout that we’ve been familiar with looks broken as the minimize button is designed to be sandwiched between the maximize and close buttons.
menu:minimize,maximize,close

Here’s the previous look with Lucid’s button order.
menu:maximize,minimize,close

A spacer can be added. Although it too slightly breaks the design, it may still be helpful to keep the close button separated slightly from the others. The menu button has been removed in the following example.
:maximize,minimize,spacer,close

One alternate layout is to keep the minimize and maximize buttons to the left and pushing the close button to the right.
maximize,minimize:close

With gconf-editor, you can find whatever combination you’re most comfortable with. You can also use the command line tool gconftool-2 to set the value of the layout quickly. To get the pre-Lucid layout:

gconftool-2 --set /apps/metacity/general/button_layout --type=string :minimize,maximize,close

Just because Ubuntu made a small change to the layout doesn’t mean it has to be accepted.

UPDATE: Mark Shuttleworth, Canonical’s founder, takes a brief moment to voice some opinions over the matter.

mountall: error while loading shared libraries: libplybootclient.so.2: cannot open shared object file: No such file or directory.
init: mountall main process (265) terminated with status 127

It’s getting some attention at Ubuntu Forums here and here. There’s also a bug report already filed with a fix on the way.

If you find yourself stuck with a non-bootable Lucid, the posts and bug reports have some ideas. Myself, I used a workaround suggested by Rob2687 and loaded a Karmic LiveCD (LiveUSB key actually), mounted my root partition and added a new symbolic link.

sudo mkdir /mnt/root
sudo mount /dev/sda6 /mnt/root
sudo ln -s /mnt/root/lib/libply-boot-client.so.2.0.0 /mnt/root/lib/libplybootclient.so.2

My Lucid install was able to reboot successfully after this.

UPDATE: Updates have been pushed out to correct this situation with the following versions:
plymouth 0.8.0~-14
mountall 2.8

After some digging, I came across this Launchpad bug explaining the same condition. Lars Bengtsson’s comment explained with a link that there was a change in the gnome-power-manager package back in July that decided to hide the Do nothing option unless it was specified in GConf.

There are two ways to specify Do nothing in GConf. Pick what you’re more comfortable with. The GUI way is to press ALT-F2 and run gconf-editor. Use the tree to navigate to apps > gnome-power-manager > buttons > lid_ac and change it to nothing. The Long description that appears below in the Key Documentation area provides the other possible values.

From a command line, or in a terminal window, use the following command to change the value to nothing:

gconftool-2 --type string --set /apps/gnome-power-manager/buttons/lid_ac "nothing"

You should now see Do nothing as an option from within the Power Management application.

It’s only semi-persistent. Once you change the option to something else, Do nothing is hidden again. You’ll need to repeat the process to add it back. Some comments from the bug entry suggest this may not work for everyone. I suspect there are other issues preventing them from keeping an external monitor active with a laptop’s lid closed which I couldn’t suggest a reason.

I enjoy installing games that are either not in the official Ubuntu repositories or are newer versions than what is available. After downloading and extracting, I move them to /opt and add a launcher to the Applications > Games menu. Some of the games need to be launched from their own directory which makes simply pointing the launcher at the executable impossible.

Instead, I actually set the launcher up to run a shell instance and pass it the required commands in order to run the game. For instance, Nexuiz doesn’t require this workaround as it has that as an option built in to it. I simply set the launcher’s command up as:

/opt/Nexuiz/nexuiz-linux-x86_84-glx -basedir /opt/Nexuiz

However, for games such as Sauerbraten and Warsow, I set the launcher’s command as:

sh -c “cd /opt/sauerbraten/ && ./sauerbraten_unix”

…and…

sh -c “cd /opt/warsow && ./warsow”

Now I can easily get back to my fragging.

My desired layout was to have Vista inhabit a 320GB drive occupying the main bay while Ubuntu would live on its own 320GB drive in the caddy. Dual-booting would be done through the Bios in order to avoid, among other things, having grub issues.

The biggest concern was the encrypted partition that contains separate root and home logical volumes. I wanted to make an exact image copy with dd but retain its encrypted state. However, I was unsure how I could access the data from the image without restoring it. I knew you could mount ISOs through a loop device, but an encrypted image was a lot different. Here’s how I did it.

I booted the machine with an Ubuntu 9.04 LiveCD from an external CD-ROM, opened a terminal window, and gained a root prompt. Doing everything as root is dangerous and contrary to the Ubuntu sudo-only policy, but this went a lot easier without the extra typing. Just don’t say I didn’t warn you.

The first step was to get a list of the partitions. At this point I have both hard drives installed in order to move some shared media files from the Ubuntu drive onto the Vista drive. They are listed as /dev/sda for Vista and /dev/sdb for Ubuntu. Using fdisk to get my list, I have:

root@ubuntu:~# fdisk -l /dev/sdb

Disk /dev/sdb: 320.0 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0×05b304be

Device Boot Start End Blocks Id System
/dev/sdb1 1 12158 97659103+ 83 Linux
/dev/sdb2 12159 38913 214909537+ 5 Extended
/dev/sdb5 * 12159 12188 240943+ 83 Linux
/dev/sdb6 12189 38913 214668531 83 Linux

I have /dev/sdb1 as the encrypted partition and /dev/sdb5 as the /boot partition, which I also want to back up. Of course, this listing doesn’t explicitly describe what each partition is. I know what they are from the installation process when I set them up. After plugging in my external drive, Ubuntu happily mounted it at /media/disk. The first step was to create the backup images.

root@ubuntu:~# dd if=/dev/sdb5 of=/media/disk/sdb5_boot.img
481887+0 records in
481887+0 records out
246726144 bytes (247 MB) copied, 11.3419 s, 21.8 MB/s

root@ubuntu:~# dd if=/dev/sdb1 of=/media/disk/sdb1_root_home.img
195318207+0 records in
195318207+0 records out
100002921984 bytes (100 GB) copied, 6447.54 s, 15.5 MB/s

It took a while to back up the /dev/sdb1 partition giving me plenty of time to catch up on my emails and rss feeds. The next step was to make sure I could still access the data contained within the backups. For the boot partition, this was as easy as mounting it to a temporary location and listing the directory.

root@ubuntu:~# mkdir /mnt/ob_boot

root@ubuntu:~# mount /media/disk/sdb5_boot.img /mnt/ob_root -o loop

root@ubuntu:~# ls /mnt/ob_root/
abi-2.6.28-11-generic memtest86+.bin
abi-2.6.28-13-generic System.map-2.6.28-11-generic
abi-2.6.28-14-generic System.map-2.6.28-13-generic
abi-2.6.28-15-generic System.map-2.6.28-14-generic
config-2.6.28-11-generic System.map-2.6.28-15-generic
config-2.6.28-13-generic vmcoreinfo-2.6.28-11-generic
config-2.6.28-14-generic vmcoreinfo-2.6.28-13-generic
config-2.6.28-15-generic vmcoreinfo-2.6.28-14-generic
grub vmcoreinfo-2.6.28-15-generic
initrd.img-2.6.28-11-generic vmlinuz-2.6.28-11-generic
initrd.img-2.6.28-13-generic vmlinuz-2.6.28-13-generic
initrd.img-2.6.28-14-generic vmlinuz-2.6.28-14-generic
initrd.img-2.6.28-15-generic vmlinuz-2.6.28-15-generic
lost+found

That was simple enough, but this is where it gets complicated. I needed to install cryptsetup and lvm2, and then load the dm-crypt kernel module.

root@ubuntu:~# apt-get install cryptsetup lvm2
[..snip..]
root@ubuntu:~# modprobe dm-crypt

I thought you could mount the encrypted backup through a loop in the same way I just did the boot backup, but mount complains about the filesystem type.

root@ubuntu:~# mkdir /mnt/ob_root_home

root@ubuntu:~# mount /media/disk/sdb1_root_home.img /mnt/ob_root_home -o loop
mount: unknown filesystem type ‘crypto_LUKS’

After a quick googling, I landed at an Ubuntu Forums post concerning something a little different but contained the steps I needed. They included the use of /dev/loop0 which I couldn’t use in the LiveCD environment as the LiveCD was currently using it, so I needed to adapt.

Mount the encrypted backup on a loop device.

root@ubuntu:~# losetup /dev/loop1 /media/disk/sdb1_root_home.img

Decrypt the new loop device. At this point it helps to remember the passphrase. I tried and failed three times before I smacked my forehead with the heavy hand of common sense.

root@ubuntu:~# cryptsetup luksOpen /dev/loop1 ob_enc
Enter LUKS passphrase:
key slot 0 unlocked.
Command successful.

Now to activate the volume groups, which is done rather automagically, with vgchange.

root@ubuntu:~# vgchange -ay
2 logical volume(s) in volume group “obsidian” now active

Now my /dev/mapper directory had entries for the decrypted device, ob_enc, and the two logical volumes, obsidian-home and obsidian-root.

root@ubuntu:~# ls /dev/mapper/
control ob_enc obsidian-home obsidian-root

At this point, I could mount the logical volumes anywhere I needed to access the files contained in each and do with them what I pleased.

root@ubuntu:~# mkdir /mnt/ob_home/

root@ubuntu:~# mount /dev/mapper/obsidian-home /mnt/ob_home/

root@ubuntu:~# ls /mnt/ob_home/
adam adam_original stovicek

From here on out, I re-partitioned the drive for better layout, re-installed the core Ubuntu system, mounted the backups as outlined above, and restored /home and any other necessary files to their new partitions.

While I was apparently on Google’s homepage, the address bar was still under the impression that I was at the Google Reader page. It was also not immediately displaying my home page when Firefox 3.5 launched. It turns out that ubufox, the Ubuntu Firefox Modifications plugin, isn’t quite compatible. Only after disabling it did Firefox 3.5 return to operating normally. All of my other plugins seem to function as expected.

Some other interesting tidbits from the screenshot:

• I am not the author of the ubufox plugin. I was still trying to figure out how Firefox handled plugins and used my troubleshooting skills by changing its name in order to show if I had made any progress.
• There is no version 2.02.00 of the Fast Video Download. I changed the version number for the very same reason I added my name to the ubufox plugin.

Things I learned in the process:

• Firefox keeps a record of the plugins in an extensions.rdf file located in the profile directory. Even after making changes to the necessary plugin files for both ubufox and Fast Video Download, Firefox 3.5 still wouldn’t allow me to enable them. It wasn’t until I removed the extensions.rdf file, which was later auto-generated by Firefox 3.5, that Firefox 3.5 finally recognized the version changes.
• The ubufox plugin is a global plugin and isn’t kept in your local profile directory. It’s install.rdf file is located at /usr/share/ubufox/install.rdf and is owned by root. The idea is still the same by locating the maxVersion and changing it to 3.5.* but using sudo instead. Unfortunately, it still prevents Firefox 3.5 from functioning normally.

Until a suitable replacement is made of the ubufox plugin, I recommend against changing its install.rdf file’s maxVersion entry. Since it’s a global plugin, any new user that is added to your computer will get a broken Firefox 3.5 setup.

Looking in the ~/.mozilla/firefox-3.5/(profile).default/extensions directory, replacing (profile).default with your own, you should see a directory for each of your extensions.

Using my own example, at ~/.mozilla/firefox-3.5/(profile).default/extensions/moonlight@novell.com I have Novell Moonlight installed. Within is a file called install.rdf which I needed to edit.

First I made a copy of it in case I broke it after editing it.

cp install.rdf install.rdf-original

Next, the permissions needed to be fixed in order to save any changes I make to the file.

chmod 0600 install.rdf

Now to edit it. I chose nano but any text editor will do.

nano install.rdf

Paging down to the bottom, I find the following section:

<Description>
  <em:id>{ec8030f7-c20a-464f-9b0e-13a3a9e97384}</em:id>
  <em:minVersion>1.5</em:minVersion>
  <em:maxVersion>3.1.*</em:maxVersion>
</Description>

I changed the maxVersion to 3.5.* and saved it.

<em:maxVersion>3.5.*</em:maxVersion>

Last thing to do was change the file permission back to a strict read-only.

chmod 0400 install.rdf

After giving Firefox 3.5 a restart, it was now possible to enable Novell Moonlight in lieu of a future update.

Keep in mind that this may or may not work with all Firefox plugins with some possibly causing havoc with Firefox itself. If that’s the case, you’ll need to reverse the changes you made and wait for an official update from the plugin’s programmers.

sudo apt-get install firefox-3.5

You can also install by way of Synaptic by searching for the firefox-3.5 package name.

That’s assuming one has the universe repository enabled. This will install FF 3.5 as Shiretoko, it’s developmental codename. It was decided to retain the Shiretoko name to differentiate it from FF 3.0 which is the default browser for Jaunty. It is planned that FF 3.5 will be the default for Karmic.

When FF 3.5 (Shiretoko) is first run, it will make a copy of your current ~/.mozilla/firefox directory to ~/.mozilla/firefox-3.5 so that all of your settings, preferences, add-ons, etc. from FF 3.0 will be the same in FF 3.5. Although, as in the past, new versions of Firefox may prevent some previous extensions from being seen as compatible. There is a workaround for this which I’ll cover briefly in my next post.

You’ll see it listed in the Internet menu as Shiretoko Web Broswer with a Firefox-less globe icon. Once installed, both versions will coexist happily on your computer. The only thing to remember is that any changes you make to one will not be mirrored by the other since they won’t share the same settings directory.

For the more advanced users who are brave enough, one can move the new directory to a new name and create a symbolic link to the original so that settings are shared between the two.

mv ~/.mozilla/firefox-3.5 ~/.mozilla/firefox-3.5-original
ln -s firefox firefox-3.5

Whenever Shiretoko looks to ~/.mozilla/firefox-3.5 it will actually find the ~/.mozilla/firefox directory. The only drawback to this is FF 3.0 and FF 3.5 constantly checking plugins when switching from one to the other.