Ubuntu Desktop

Some tips on Ubuntu Desktop configuration are found below. Take it for what it is: bits and pieces. The goal is not to provide coherent information, but rather to propose solutions to specific problems. Therefore said coherency, if present anywhere on this page, is entirely incidental. :-) For more complete information on any of these matters, please refer to documentation elsewhere.

Note that some steps here are not, or are only partially, specific to Ubuntu, or to Ubuntu 10.04. I'm sure there are also a number of things I haven't really mentioned here that are an important part of my configuration. I hope to get around to the rest once I figure out what those things might be.

Consider disabling PulseAudio

Note that this may cause problems as some packages in Ubuntu are tied to PulseAudio by default. This is probably not a useful thing to do unless you have specific needs. See below for details.

Chances are you have PulseAudio on your system, which like ALSA allows for multiple programs to use an audio device simultaneously, but also allows for individual volume control (and perhaps some other feature(s) I'm unaware of). However, if you have any games or programs using the legacy sound system OSS, you may have to 1) kill pulseaudio or 2) use padsp or similar, often leading to unwanted "scratches", audio delays, audio gaps, or worse. In my case I might as well disable it completely since, as of Lucid Lynx (10.04), I still have issues with PulseAudio and OSS. Here's how:

  • Edit /etc/pulse/client.conf and make sure you have
autospawn = no
  • Possibly also use rcconf or similar to remove any references to /etc/init.d/pulseaudio

If you want to get PulseAudio-tied programs to work with ALSA / OSS / … you may need to do some reconfiguring. In the case of SDL applications such as dosbox, we can solve this by installing the appropriate package:

sudo apt-get install libsdl1.2debian-alsa

Note that this seems to remove the libsdl1.2debian-pulseaudio and the ubuntu-desktop packages as a result. Make sure this does what you want. In the latter case, you may need to think twice; from the package description: "This package depends on all of the packages in the Ubuntu desktop system. It is also used to help ensure proper upgrades, so it is recommended that it not be removed."

In case of ambiguity, an appropriate environment can be used, e.g.:

export SDL_AUDIODRIVER=alsa

but this shouldn't be necessary in most cases.

If dosbox does not find PulseAudio running when it's configured to use it, it might say:

MIXER:Can't open audio: No available audio device , running in nosound mode.

If you're worried that you've messed things up in ~/.dosbox/dosbox-0.73.conf , or whichever the default configuration file for dosbox happens to be, try making a backup of it and then delete the configuration file. A new one with default settings should be created automatically when you start dosbox the next time. As of 0.73 there have apparently been slight syntax changes (e.g. to MIDI settings) compared to prior versions, so if things have stopped working you should consider starting from a "clean" config again.

In case of MIDI trouble, you might get something like:

ALSA:Can't subscribe to MIDI port (65:0) nor (17:0)
MIDI:Opened device:oss

Try adjusting the midiconfig variable under the [midi] section if you need to adjust MIDI port. E.g.:

mididevice=default
midiconfig=128:0

which corresponds to Timidity in this case (wherever that might be useful):

$ pmidi -l
 Port     Client name                       Port name
 14:0     Midi Through                      Midi Through Port-0
128:0     TiMidity                          TiMidity port 0
128:1     TiMidity                          TiMidity port 1
128:2     TiMidity                          TiMidity port 2
128:3     TiMidity                          TiMidity port 3

On that note, in the interest of thoroughness, Timidity settings can be specified in /etc/default/timidity . I have e.g.:

TIM_ALSASEQPARAMS="-Os"

for ALSA output.

The init script is /etc/init.d/timidity and should give you /usr/bin/timidity -Os -iAD in your process list, running as the timidity user.

See the timidity page for some suggestions about soundbanks.

Configuration for USB headsets

I haven't experimented much with this as I usually only use the USB headset. In theory it should be possible to switch between sound cards / devices, but in practice some programs (especially ones using a legacy sound system) will have problems with this by sending output to the wrong device or whatnot. So, make sure the USB headset has highest priority if you intend to use it solely or most of the time:

Edit /etc/modprobe.d/alsa-base.conf and make sure that

options snd-usb-audio index=-2

is commented out (has a leading #). Upon restarting your computer, the USB headset should now have priority. (I hope, you may actually have to force the other device to a lower priority. In my case commenting this out is enough though.)

If you don't want to restart your computer to get there, you'll probably have to unload all the sound modules manually after stopping any programs from using them.

Disable tooltips (Compiz)

See the tooltip page.

Set up some custom shortcuts

In Compiz, use ccsm —> General —> Commands (10.04) and the Commands and Keybindings tabs there to set up custom shortcuts, or use gconf-editor to fiddle with /apps/metacity/keybinding_commands and /apps/metacity/global_keybindings .

Use a decent terminal

I'm a konsolaholic.

<praise>
Konsole is one of my favourite parts of KDE. I don't really like Gnome (usability disagreements mainly, some on a more technical level), and I don't really like KDE (mainly the aesthetics, but also some other GUI aspects). I pretty much dislike the file dialogs in both GTK and QT, bad for me… Maybe I should try to fix it. :-) In the case of QT, my major complaint about the dialog seems to be solvable. For now, though, I log in with Gnome and from there I try to use the best of each world.

Konsole provides pretty much everything I want (some of which others terminals have, some of which they don't):

  • searchable buffer
  • monitoring (silence / activity)
  • configurability (including getting a clutter-free interface)
  • stable scrollback (what you're looking at remains in place as long as it's in the buffer)
  • tabs (a must)
  • output can be saved to plain text or HTML (good to preserve foreground and background colors)

In addition, I suspect some stuff may come in quite handy at some point or other:

  • full screen mode
  • split views
  • bookmarks
  • simultaneous input to multiple shells

etc.

It also gets out of the way by allowing pretty much any shortcut to be used: Alt-* (no interference with menu bar), Ctrl-*, F* (no interference with help or so), etc. Note that there may be some exceptions by default (though even then they may be handled smartly enough, e.g. the F3 shortcut is disabled when not in search mode) - see the configuration for details. There may also be a need to setup a dedicated shortcut for hiding / displaying the menu bar in case the program in question interacts with mouse input by means of curses or so.

It also handles Ctrl-S nicely (clear indication that a tab's output is currently suspended).
</praise>

Well, enough of the advertising. YMMV.

I only have a few complaints, like about some minor bugs (e.g. when trying to show the menu again it may show in the context menu that it is already being displayed), and the rendering is slower than it should be (e.g. mplayer console output for some reason takes noticeable CPU power, something caused by a combination of factors involving X, QT and whatnot as far as I can tell - haven't a found a solution that works for me yet), but as long as I don't do heavy stuff in the terminals I should be OK. I could also see some minor improvements being made to the interface.

Bash

See the bash page.

Zsh

See the zsh page.

Temperature / fan / voltage / … monitoring

In my case it seems that the module it87 needs to be loaded manually to make sure gkrellm works (this is with a IT8718F chip on a Gigabyte EP35-DS3P), so I've added a line in rc.local :

modprobe it87

Linux RAID

See the Linux RAID page.

Graphics drivers

If you're an NVIDIA user, you will want Ubuntu to handle the graphics drivers for you. Just saying. Some versions prior to 10.04 it seemed best to install each new driver version manually. Letting Ubuntu handle it will however mean automatic updates with new kernels and so on and so on, plus the Ubuntu developers do some testing. I haven't had to worry about these things for some time. See e.g. System —> Administration —> Hardware Drivers for details. There may also be the option to use Nouveau to avoid the drawbacks of proprietary drivers (security risks, stability, etc.), though at this point it lacks many features including 3D-related functionality.

Security

See the security page.

Activity monitoring

Good packages to install: iotop, jnettop (run jnettop as root or it will exit without displaying the error for long)

The htop package may be a fancy replacement / complement for top (scrollable process list by means of ncurses, for instance).

Package management

Usually I just use apt-get, but depending on the situation, aptitude or Ubuntu Software Centre may be more appropriate. As of 10.04, the latter lists all packages available. If I'm not mistaken, one advantage with the Centre over aptitude is that it allows you to browse the package list while installing things, while aptitude blocks you from accessing anything during installation. Granted, if you know beforehand what to install, great. If not, wait, possibly for a few minutes or more if it's a large package. That's too long. ;-) Package management is convenient to be sure, but it could be even more so in some cases.

I haven't had much reason so far to look around a lot, but this Linux.com article might shed some more light on this issue.

As for dpkg -l, if your terminal is not wide enough, try setting the COLUMNS variable thus:

COLUMNS=150 dpkg -l "foobar"

might be enough.

Screenshots

I find gnome-screenshot to be not that useful. For me it's usually slow and clunky (meaning, for one, it seems that it won't actually take a screenshot until the dialog comes up, which may be several seconds after you see something). Possibly ksnapshot or kgrab are better in this respect. All of these programs seem to require clicking away a GUI dialog though.

Anyway, when looking into this I found a mention of scrot, a CLI-based screenshot application. Together with a shell script I wrote:

#!/bin/bash

cd ~/Screenshots

i=0
FILE="$i.bmp"
  # make sure to use a unique filename. calling "scrot" without arguments will generate a filename dynamically, but may overwrite old files, e.g. taking shots in a quick succession
  #   (if you want to get really picky there's still a chance for a race condition here, I haven't bothered though)
  # other filetypes may be more appropriate for your needs. also check the manpage for more details

while [ -e "$FILE" ]
do
  i=$[$i+1]
  FILE="$i.bmp"
done

scrot "$FILE" # (If you want to capture a window, I suggest using scrot -u instead. Note however that this will not include the title bar. It would seem that the application would need to use SDL as well in order to handle that.)

I'd now like to rebind the PrintScreen button (and similarly for Alt-PrintScreen) to use this script. I have seen some suggestions of moving the actual gnome-screenshot binary and replacing it with a symlink. I would not recommend that if you want to avoid unnecessary problems with upgrades and so on. Note however that the solution I propose is going to be a user-level change, rather than a system-wide one. So:

  1. Disable the existing bindings.
  2. Enter new bindings. See the Set up some custom shortcuts section above for details.

Oh, and don't forget to create the directory that the above script expects in place. :-)

Suspend in console

To reproduce what Gnome does when it suspends, implement the following:

alias susp='gnome-screensaver-command -l ; sudo /root/scripts-for-sudo/suspend.sh'

and that (and with an appropriate sudoers) is simply:

#!/bin/bash

pm-suspend

For some reason my networking cuts out if I go to sleep, and there is no "quirk" for it in pm-suspend . So I wrote a workaround as /etc/pm/sleep.d/05_networking-fix :

#!/bin/bash

function reset_net
{
  ### Workaround for wakeup

  # Restore things

  NETM=r8169

  rmmod $NETM
  modprobe $NETM
}

ARG=$1

case "$ARG" in
  suspend)
    # Dummy
    ;;
  resume)
    reset_net
    ;;
  *)
    exit 1
    ;;
esac

I also have some scripts in /etc/network/if-{down,up}.d/ that handle interface-level setups as appropriate.

Not that it might matter that much, because with an appropriate keyboard I can just hit one button and it sleeps, but it could be useful as a backup or whatnot, plus I couldn't resist digging a little bit. The second half (files in /etc/pm/sleep.d/ and /etc/network/if-{down,up}.d/) are necessary anyway to get things to work properly for me.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License