Category Archives: Gnome

Mac OS X killed the Linux desktop? I must have missed the memo (and so did Google)…

Bizarre little opinion piece by Miguel de Icaza proclaiming the death of the Linux desktop. A little excerpt:

True story.

The hard disk that hosted my /home directory on my Linux machine failed so I had to replace it with a new one. Since this machine lives under my desk, I had to unplug all the cables, get it out, swap the hard drives and plug everything back again.

Pretty standard stuff. Plug AC, plug keyboard, plug mouse but when I got to the speakers cable, I just skipped it.

Why bother setting up the audio?

It will likely break again and will force me to go on a hunting expedition to find out more than I ever wanted to know about the new audio system and the driver technology we are using….”

Here’s my true story. I have a number of Ubuntu Linux desktops, and all are a joy to use. Ubuntu Linux has been fast and stable. The Unity interface is quite lovely (after some initial reservations). Software package installation is incredibly slick (and has been for years), and I couldn’t be happier with the quality of desktop applications. And I’ve never had a problem with audio support either for that matter. I switched from Mac OS late in 2007, partly because the money I was paying for the privilege wasn’t delivering in the areas where Ubuntu excels – and its ties to proprietary hardware (or beyond proprietary as Scott McNealy would say) generally make it a proposition for the well moneyed.

I’ve maintained hundreds and hundreds of desktop Windows and Mac OS computers in my time, so I’ve got a fairly good handle on the pros and cons of each, especially with regard to stability and ease of use. Is Ubuntu a superior desktop OS to Windows? No question. Even if Microsoft were to drop the price of Windows to zero (as if) it would still be an average product. Is Ubuntu comparable to Mac OS X, for common productivity and entertainment activities? Absolutely, especially in its current LTS incarnation.

So: I’m not sure where I’m going wrong, but Ubuntu has been nothing short of a fantastic desktop OS for me. The irony is that I don’t use it on the server, preferring Illumos/OpenIndiana due to a number of compelling advantages from its OpenSolaris roots. Why does the author feel the need to make negative comparisons to Mac OS? Why even bring up the old bugbear of Linux on the desktop at all?

I think I hear an axe being ground.

Incidentally, Google apparently didn’t get the author’s memo either…

http://www.zdnet.com/the-truth-about-goobuntu-googles-in-house-desktop-ubuntu-linux-7000003462/

About these ads

Modifying the message date and time format in Thunderbird

Quick post – date and time format of messages displayed in Thunderbird can be controlled in two simple ways. This is useful if you’ve noticed Thunderbird using the bizarre US format (e.g. MM/DD/YYYY). This is on OpenIndiana, but is just as applicable for any Gnome 2-based environment.

First, the “LC_TIME” variable can be set in a user’s profile file (e.g. ~/.profile if using bash or ksh). Let’s specify New Zealand English:

export LC_TIME="en_NZ.UTF-8"

Log out and log back in, fire up Thunderbird and messages should now be using the DD/MM/YYYY format.

 

The second method is much simpler. Thunderbird actually uses the system language settings for message date and time display formatting. So, if you’ve never noticed that little language setting before on the Gnome login screen, now would be the time to change it to the language of your choice:

OpenIndiana Gnome login screen

Thunderbird will then use a sane format.

Adding a custom theme to GIMP

GIMP running on .nix distributions that support the Gnome desktop environment can be used with custom themes. Following is a brief how-to which covers doing this on OpenIndiana oi_151a x86, with GIMP 2.6. The method should be very similar or identical for Linux distributions (e.g. Ubuntu).

 

First, let’s locate a sample GTK theme. I am using a rather nice theme called “Darkilouche” found here:

http://art.gnome.org/themes/gtk2/1285

Simply download the compressed file in the above link, and extract the contents to disk.

 

Next, we need to locate the gtkrc file in the uncompressed theme folder. The sample theme we are using contains the following files and directories once uncompressed:

$ ls -al
total 7
drwxr-xr-x 4 dave staff   5 2012-03-07 22:47 .
drwxr-xr-x 3 dave staff   3 2012-03-07 22:47 ..
drwxr-xr-x 6 dave staff   9 2007-02-28 00:22 .svn
drwxr-xr-x 3 dave staff   4 2007-02-28 00:22 gtk-2.0
-rw-r--r-- 1 dave staff 240 2007-02-28 00:23 index.theme

The gtkrc file sits within the gtk-2.0 directory, and appears to be the only critical file that is needed.

 

Next, we copy the gtkrc file into the GIMP themes directory. In this example, I am using the global GIMP themes directory at /usr/share/gimp/2.0/themes. We simply create a directory named after the theme we are installing (in this case “Darkilouche”), and copy the gtkrc file into it.

 

Finally, we launch or restart GIMP and test that the theme is accessible at Edit -> Preferences -> Theme. The following screengrab illustrates that GIMP has found the theme, and, it is also the active theme:

Darkilouch GTK theme installed in GIMP

OpenShot video editor for Linux – watch out iMovie…

I’ve recently begun to use OpenShot on Ubuntu Linux to edit a series of short screencasts with, and holy smoke what a pleasant surprise. Stable, easy to use (including a polished and smoothly responsive UI), a nice selection of effects and transitions, and pretty darn stable to boot:

OpenShot running on Ubuntu 11.10 x86

It’s pretty much based on the iMovie paradigm, before Apple screwed too badly with it. Lots of advanced goodies which the competition doesn’t have, like fancy 3D animated and SVG titles via integration with Blender and Inkscape. Built-in support for insta-upload to YouTube. Even the documentation is great. Between Ubuntu, ffmpeg, and OpenShot (oh, and Audacity for the audio), it’s entirely possible to put together high-quality screencasts for zero software cost.

OpenShot is totally worthy of a donation, which I have happily made.

recordMyDesktop, Ogg video files, and OpenShot – part 2

A quick follow up to my post here. As it turns out, VLC refuses to play back any Ogg file generated by recordMyDesktop at normal speed: playback jumps all over the shop, with the net effect of it appearing to run much faster than the speed it was actually originally captured. So, we are shit out of luck with using it to transcode recordMyDesktop files for editing in OpenShot.

You can read what the VLC core developers thought of this issue in posts 8 and 9 here:

http://forum.videolan.org/viewtopic.php?f=2&t=94169

Frustrating that recordMyDesktop is so close to being perfect for my needs, but as it’s a defunct project I am forced to look elsewhere. Turns out that the ffmpeg command line utility can be used to capture a live desktop (loads of guides on the web on this topic), so in a follow up post I will outline my efforts to use this instead.

Interview with Damien Sandras, creator of Ekiga

As posted on the Ekiga users mailing list, this is an interesting interview conducted recently with Damien Sandras. Lots of good stuff here, from his views on the future of the project to how it compares with the default VoIP apps in Ubuntu.

http://www.josetteorama.com/interview/ekiga-open-source-softphone-video-conferencing-and-instant-messenger/

OpenIndiana 151a is out – and powered by Illumos

In case you haven’t already heard, OpenIndiana development release 151a is out. The critical change in this release is that it’s now based on the Illumos kernel, developed by star ex-Sun Microsystems talent in the wake of Oracle’s compeltely styleless killing off of OpenSolaris. Substantial new features which you won’t be seeing in Solaris 11 anytime soon such as KVM support are built-in and tightly integrated. And yes, KVM support for AMD CPUs is on the way – hopefully in time for the 8-core AMD Bulldozer architecture desktop CPUs…

There are also a nice set of desktop software additions, some of which OpenIndiana and OpenSolaris before it has been needing for ages, for example a capable suite of multimedia playback applications. OpenIndiana now has dedicated SFE repositories from which VLC and Mplayer can be installed, as well as bonus goodies such as Scribus and more.

OpenIndiana download links, release notes, and SFE repository details:

http://openindiana.org/
http://wiki.openindiana.org/oi/oi_151a+Release+Notes
http://wiki.openindiana.org/oi/Spec+Files+Extra+Repository

After running 151a for a few days (the upgrade from release 148 was completely seamless by the way), I was presented with something I hadn’t seen for a long time, not since OpenSolaris development was closed off a couple years back…

OpenIndiana update manager

Sipdroid interoperability with Ekiga 3.2.7

I’ve recently been playing around with various mobile SIP clients, testing how well they work making calls to Ekiga 3.2.7 clients running on the desktop. Following are some notes I’ve collected using Sipdroid 2.0.1 Beta, running on a Motorola Milestone with Android 2.1.

In all tests, I am using the Milestone on the Vodafone New Zealand 3G network, while my desktop clients are all connected to either corporate LANs with public IP addresses, or running NATed on home networks.

Generally, for voice calls, Sipdroid plays quite well with Ekiga using this network arrangement, but there are some niggles regarding the various audio codecs either SIP application supports. A summary of this follows.

 

Speex

First, it appears that the speex (11kbit) codec in Sipdroid’s implementation is just plain incompatible with either the Speex 8khz or Speex 16khz codecs featured in Ekiga.

Enabling only the speex (11kbit) codec in Sipdroid, and Speex 8Khz in Ekiga, I could make calls to Ekiga from the Milestone fine, but calling from Ekiga to the Milestone results in an incompatible codec error at the phone end, and the call then immediately terminates.

Enabling only speex (11kbit) in Sipdroid, and Speex 16Khz in Ekiga, calls cannot be made in either direction. Calling from the Milestone to the PC, Ekiga gets an incoming call notification but on accepting the call, the connection is lost at the PC end, with a notification that the call was missed. On the Milestone, it simply continuously reads “Dialling”. Connecting to the Milestone from the PC, one gets the same codec error as above before the call terminates.

 

PCMA

Calls made from the Milestone to Ekiga worked great, and vice versa.

 

PCMU

Calls made from the Milestone to Ekiga using PCMU also worked great, and vice versa.

 

An interesting observation at this point is that if the PCMA, PCMU and Speex codecs are all enabled in both Ekiga and Sipdroid, and in Ekiga Speex is sorted in the audio codecs window to be at the top, then calls made from Ekiga to the Milestone will fail with the codec incompatibility error. Calls made from the Milestone to Ekiga however are fine, but will fall back to a PCMU/PCMA codec.

 

G722

Calls made from the Milestone to Ekiga using the G722 audio codec also worked great, and vice versa.

 

GSM

Calls made from the Milestone to Ekiga using the GSM audio codec also worked great, and vice versa.

Ubuntu 10.10 x86 and older nVidia graphics cards

A couple months back, I upgraded a friend’s computer via software update to Ubuntu 10.10. She had been happily running Ubuntu 10.04 on an old Pentium 4 box, with an equally vintage nVidia Quadro4 380 XGL installed in it. Accelerated 2D and 3D was no problem courtesy of nVidia’s legacy drivers.

Well, all that changed after the update, and post-update-reboot we had no window manager. It took close to an hour of fiddling around before I eventually read the small type in the release notes and realised that the nVidia legacy drivers for the Quadro4 380 were not compatible with the updated Xorg server in the Ubuntu 10.10 release.

You can read the whole saga here, but in short, the good news was we were saved at the time by two things; nVidia’s completely awesome effort in the updating of the driver for a vintage graphics card to work with the new Xorg, and the generosity of a community developer who packaged it into a PPA. It’s just a shame that Canonical didn’t place far more emphasis on warning users with older hardware that an OS update might make their system unusable!

Since then, the nVidia driver update has made it into the Ubuntu maverick-proposed repository, as I found out recently when installing Ubuntu 10.10 on another machine of similar vintage (this time with an nVidia Quadro4 550 XGL installed in it). So, only a simple tick-box needs to be checked for the driver to be downloaded and installed automatically:

Ubuntu 10.10 - enable the proposed repository

After doing this, run a software update, and install both the “nvidia-96″ legacy driver, plus a couple of additional updates, such that it is handled by the GNOME hardware driver installation utility:

Ubuntu 10.10 software update - install nVidia drivers and utilities

Ubuntu 10.10 software update - install nVidia drivers and utilities

After updating, run the GNOME “Hardware Drivers” utility (“System -> Administration -> Hardware Drivers”), and install the driver visible there:

Ubuntu 10.10 Hardware Drivers utility

After a restart, accelerated graphics are back in Ubuntu 10.10. A note of thanks to nVidia – it’s stuff like this that makes me want to buy your products! :)

Outgoing SIP call problem in Ekiga 3.2.7 on OpenIndiana

Quick problem with a quick resolution: on my desktop OpenIndiana oi_147 machine, I found I was unable to make SIP voice calls to any of my contacts, nor even a test call to the the test service at sip:500@ekiga.net.

After a quick posting to the Ekiga mailing list with an accompanying debug file, I received a helpful response from another user (Eugen Dedu), who pointed out that packet sizes were too big as a result of too many audio codecs being selected in the application preferences.

After enabling a basic set of audio codecs in Ekiga, I could then place calls fine:

Ekiga audio codecs

Ekiga test call working

Ekiga could do with some fine tuning vis a vis somewhat more helpful error reporting, but all the same I am glad to have this working. For VoIP calls at least there is an impressive amount of interoperabilty on offer here amongst Windows, Linux, and OpenIndiana platforms. With a bit more testing and documentation (eventually branching out to H323, video, and interoperability with commercial hardware-based SIP/H323 solutions) I’m looking forward to recommending Ekiga as a one-stop solution for cross-platform open source desktop A/V conferencing.