Proving the Obviously Untrue - Free Software

Gnome 3, or Gnome Shell issues

nospam@example.com (Colin Turner) — Sun, 30 Oct 2011 19:35:36 +0000

I use the Debian operating system on several computers. My "main" computer (Imladris) runs Debian unstable (Sid) while the others mostly run on testing. I've been anticipating the Gnome 3 upgrade for some time, mainly because of the switch to Gnome Shell which is a completely new way of using the desktop. I had played with Gnome Shell a while ago, and was kind of impressed and worried by it in equal measure, I decided it wasn't ready for prime time so stopped using it. Naturally I assumed it would be much more impressive upon release; especially since Debian is not (by far) the first GNU/Linux distribution to include Shell.

A while ago a big upgrade came through on imladris, and it was clear it was the Gnome 3 upgrade. I share this computer with three other users, two of which are children for whom I have implemented password less login (locally only). I can only say I think Gnome have significantly mishandled the upgrade. Here are some reasons why.

Login is seriously slow

The display manager can take up to a whole minute to display the list of users (and often doesn't display the icons). There are some bug reports about a possible race condition that causes this, but seriously on a reasonable spec computer this is unacceptably slow. The same problems occurs when switching user.

I couldn't login

My, admittedly old user account simply wouldn't launch a working desktop. I had to (at a command prompt) delete configuration directories to get my account working again.

Absolutely zero support for the user in transition

So the average user does the upgrade and suddenly their entire desktop has changed. But when they first login there will be some guidance about where everything is gone... right? No. Having already used Shell, I knew, but I had to try and show everyone else how to use the machine again. It's not that spectacularly intuitive.

Actually, a lot of functions have just gone

There's a huge removal of existing functionality. All your carefully tweaked panels: gone. All your applets: gone. And bizarrely often with no working alternative.

Not friendly for children

It was possible to set up a Gnome 2 account to make it easy for kids. Low res graphics, and big panels with big select icons. The new paradigm completely ignores all that in favour of a sleek minimalist environment which is probably not that easy for young children to understand.

Dictatorial design choices

It's been decided that we don't need minimise buttons or maximise buttons. It's been decided not to honour old desktop backgrounds. It's been decided not to honour existing resolution settings. It's been decided not to show anything on the Desktop (much to the confusion of many users). It's been decided we can't right click on the desktop.

Some of this kind of nonsense is exactly why I don't like some other operating systems who believe they know what's best for you with Messianic Zeal (I'm looking at you Apple).

All in all I find this transition very disappointing. There are lots of basic things no-one seems to have thought of, and years of desktop customisation have been swept away with an extraordinary arrogance. Don't get me wrong, I support the idea of trying a new Desktop paradigm: but, for instance, if people used to have applets on their desktop for the weather, or for system monitoring, it's because they needed it. Rolling out a new desktop that simply ignores these things in favour of how some people thing everyone should use their desktop is exasperating.

I'm seriously hoping that Gnome Shell improves significantly and fast. I won't hold my breath.

Multi User Sound in GNU/Linux

nospam@example.com (Colin Turner) — Thu, 04 Aug 2011 08:42:28 +0000

For some years now, basically since Aimee became old enough to use a computer, I have had a need for decent multi-user sound. Specifically I would often have intricate work open in multiple work spaces on my desktop, and Aimee would want to do some artwork.

I guess Aimee was about two when she started using my computer a fair bit, and I immediately had a separate account for her with lower resolution graphics, easier menus, simple shortcuts and the like. I also had a graphics tablet for her, which she mastered very quickly. Another important reason to have a separate account was that if stuff got really badly messed up I could just nuke the account and start again, and she couldn't really hurt my configuration.

As you would imagine, lots of the excellent free software for children, like GCompris, and Tuxpaint is very rich in its sound effects, and sometimes the sound is not just desirable, but essential for the activities. So a very annoying persistent problem has been that, once in a while, something in the sound stack in my login would stop Aimee's sound from working.

Now I share my main PC with two other people, Tamsin and Aimee, and soon Matilda too, so this recurrent problem is more of an issue, it's also very hard to nail down. Despite protests to the contrary the default ALSA setup still has this problem; ConsoleKit on its own doesn't seem to get it quite right. I tried PulseAudio for a while, and generally it was an improvement, but the problem did still occur sometimes. I even made sure all the users were members of the right groups including pulse-rt.

Then I found this entry in the PulseAudio FAQ.

Sound doesn't work when switching users

PulseAudio works with a single user, but when an additional user logs in (fast user switching), sound/audio does not work for the additional user.

Check that no users are part of the "audio" group.

In simple setups (e.g. singe user, without PulseAudio), users must be a member of the "audio" group to access the sound devices (/dev/snd/* (which have group "audio" write permissions)). Switching users will not automatically stop programs using those sound devices though, so those sound devices will not be accessible to a new (faster user switched) user's programs.

By removing all users from the "audio" group (the PulseAudio server still runs in the "audio" group), PulseAudio is able manage access to sound devices (/dev/snd/*) amongst multiple users with the help of ConsoleKit.

It would never have occurred to me to remove the users from the audio group, but doing so seems to have solved the problem. I almost don't want to say that, because every "solution" up to now has been partial, but so far no problems, so maybe this will be the fix.

Boot time sound problems with QuickCam Pro 9000 webcam

nospam@example.com (Colin Turner) — Sun, 17 Jan 2010 22:21:30 +0000

I've had a Logitech QuickCam Pro 9000 for some time now, and it works well, but I did have one bizarre problem with it when I used it with my main desktop machine (running Debian (Sid)). Namely, that if I had the camera plugged in (usb) at boot time the sound on the computer did not work, if you plugged it in after boot, everything was fine.

This was pretty irritating because if I forgot I would often have dozens of windows open and ready for work before I realised.

Normally this happens because the cards are loaded in the wrong sequence by udev. But, if you listed the sound cards with

cat /proc/asound/cards

the main card wasn't just in the wrong order, it simply wasn't there. I tried comparing modules loaded with and without the camera (at boot) and manually loading the differences, but this did not help. I tried forcing the index to be zero on the correct card, but this also did not help.

In the end, I made the following edit to /etc/modprobe.d/alsa-base.conf

# Keep USB (webcam from being loaded as first card)
options snd_usb_audio index=-2

and this did the trick. So if like me you were searching for the answer to this, I hope it helps.

Virtual folders with Dovecot and Debian

nospam@example.com (Colin Turner) — Thu, 31 Dec 2009 15:06:09 +0000

I use client side virtual folders a bit for my mail. Specifically, I tag messages with IMAP flags like todo and important, and then in Icedove / Thunderbird, I set up a special folder as a saved search which shows message that are either unseen, or marked todo in my inbox. It works rather well, and I use the same set-up on my laptop, and work and home desktop machines.

But it's not very useful on my phone, which doesn't allow such sophisticated client side behaviour. My phone mail applications shows the most recent 25 messages in a folder, but there are times when it would be really useful to look up messages that are labeled as important but rather old. It would be time consuming to look through the older messages, and difficult to find the one I want anyway.

As a result, I've been looking at the possibility of using virtual server side folders using dovecot on my Debian mail server. I was put off by the documentation which left a lot of questions unanswered.

Here's how I did it on Debian. First of all edit the config file /etc/dovecot/dovecot.conf, back up this file first, so you can restore working behaviour if something goes wrong.

#
# You have to add the default namespace
# which is normally NOT added explicitly before
#
namespace private {
prefix =
separator = /
# the next line is very specific to where you keep your mail
location = mbox:~/Mail/:INBOX=/var/mail/%u
list = yes
inbox = yes
subscriptions = yes
hidden = no
}

#
# Then add the virtual namespace
#
namespace private {
prefix = virtual/
separator = /
# pick where the virtual folders will be
location = virtual:~/Mail/virtual
list = yes
inbox = no
subscriptions = yes
hidden = no
}

You must also add the virtual folder plugin.

##
## IMAP specific settings
##

protocol imap {

# ... you need to enable the plugin
mail_plugins = virtual

Now restart dovecot and check your normal folders are working.

/etc/init.d/dovecot restart

Note that I found dovecot will generally not serve physical folders correctly if the virtual mail folder (even if empty) does not exist. I consider this a bug, but one that needs to be worked around, at least for me.

If that's all done and working you can begin to create virtual folders. I created two directories within my ~/Mail/virtual folders; which were inbox-todo and inbox-important respectively. Inside each I put the following files.

# ~/Mail/virtual/inbox-todo/dovecot-virtual
INBOX
OR (OR (OR KEYWORD $TODO KEYWORD todo) KEYWORD $label4) unseen

which shows all unseen and mail labelled todo in my inbox and

# ~/Mail/virtual/inbox-important/dovecot-virtual
INBOX
OR (OR KEYWORD $IMPORTANT KEYWORD important) KEYWORD $label1

which shows only important mail in my inbox.

It seems to be working, my normal folders appear to be working perfectly correctly (but I'll know better in a couple more hours/days); my phone has successfully subscribed to the two virtual folders, though the folder list shows a number of files which I'm certain it should not, again, this looks like a dovecot bug to be honest.

Cyanogen Android ROM on the g1

nospam@example.com (Colin Turner) — Tue, 15 Dec 2009 21:37:25 +0000

I've had my Google development phone, the g1, for some time now. I haven't had the luxury of time to write anything for it, but I mainly wanted it to try out Android anyway. I've reviewed the phone before, and again after some canonical firmware upgrades.

I use the truly excellent K9 application for mail, it has good support for self signed certificates, now has IMAP push support and is generally excellent. However, it stores all the mail on the shockingly limited internal memory on the device. That, and upgrades to things like Google Maps, adding truly excellent new functionality, left me constantly looking for applications to remove.

This is why in the end I decided to try Cyanogen's ROMs. Since I have a development phone, I didn't need to root it, and just followed the relevant instructions (in truth, I couldn't be bothered to downgrade the OS to root it first).

Here are some observations about the new ROM:

Apps2sd is amazing.
I have the whole pleasure of trying different apps all over again, without sweating about every byte. I don't have to worry about how much data is in my contacts (whether I assign them icons), my emails, and so on. I have plenty of room. I was delighted to be able to install DocumentsToGo. Which makes the phone much more useful for work emails. Loads of great apps I had to remove have been reinstated, and I can play with others, like the awesome Google Googles.
Extra workspaces
There are five workspaces, making for more widget playroom. I now have a calendar app taking up a whole workspace with the events to come. Excellent.
It fixes several problems I had with MMS functionality.
- It fakes a variety of user agents, meaning that a test video message I sent myself on o2 finally worked, for the first time ever.
- The stock ROM allows you to prevent data access when roaming, which is good. But it also doesn't fetch MMS when roaming, which is (for me) a nuisance, and these are usually on a different tariff system. So when you receive an MMS on roaming, you end up enabling all data access to quickly receive the MMS, and then turn it off again. The Cyanogen ROM has an option to retrieve MMS on roaming.
UI feels snappier
USB tethering
can be enabled, which JustWorks (TM) with Debian. Excellent.

On the downside, I have had some reset problems, but admittedly I have sometimes been pushing the phone very hard indeed to test it. And the battery life on the g1 is still awful. I know Noodles has solved the problem by not actually using his phone :-), but I want to use mine.

Another minor problem I encountered some weeks ago was the accelerometer suddenly starting serious misreporting on one axis. This problem seems to be becoming less severe, but even reinstalling the stock and then cyanogen ROM did not fix it. However, note I did not wipe the user data.

Cyanogen has made my phone fun to have again. And I will still replace it when a new Android handset comes out that I really like, but a lot of the urgency has gone. I'll certainly buy him a beer for Christmas.

Choosing a development hosting solution

nospam@example.com (Colin Turner) — Mon, 10 Aug 2009 16:02:00 +0000

I'm considering changing the development environment we use to host our projects in work and I'm not alone. The reason why will become more clear further down. To be honest this article is partly to help me work out what my priorities for this are, and to appeal to the lazy web for any other suggestions.

So first of all, here are the things I'm looking for in this project.

These are essential:

must be free software;
must have flexible issue tracking with user defined fields;
must be able to handle multiple projects;
must be extremely transparent to non developer users;
must support svn and git and graphical front ends to them;
must support some kind of announcement system.

These are desireable:

should integrate in some way to mailing lists;
should support ad hoc tar bar downloads from scm;
should be easy to search issues;
should graphically depict progress on releases;
should have documentation (wiki like) integration;
should handles news and download areas;
should be able to exchange data (like issues) on projects;
should actively maintained;
should automate most sysadmin activity, account creation etc.;
should be packaged for Debian ideally.

The contenders thus far are:

Savane, which we are currently using;
Fusion Forge;
Redmine;
Trac.

Let's take these one at a time.

Savane

Savane currently supports all the essential features, with the exception of git support. Being a fork from the original SourceForge software it works in a similar way. A web front end (in PHP), with back end functionality (in Perl) that creates shell users and groups, interfaces with mailman and so on.

But there are some problems. First of all the official project seems to have ground to a complete halt. Fixes that were submitted by users are not applied, there seems to be no forward momentum whatsoever. This is a problem, the offical version needs patched (modestly) to run on PHP 5, and the code base is a mess, with a few pages still requiring register_globals to be on. Bad.

However, another fork was taken some time ago which addresses all these problems including git support, well actually, the code base is still probably in need or work, but most apps of a certain age have this problem. What I'd like to see in Savane is better graphical tools to monitor project progress, better documentation features and incidentally better Debian packaging, but I've signed up to the fork to work on the latter on the first instance (this looks like it will be quite a bit of work, it's non Debian policy compliant in many ways right now). The new fork is going to be forked again by the way, into a Python version. Could be interesting.

Fusion Forge

Previously known, or descended from GForge, Fusion Forge is another fork of the original SourceForge source code. It is well packaged for Debian (naturally, it runs Debian's own code hosting environment, Alioth) and well maintained. It has many of the features of Savane, which probably makes it puzzling why I didn't choose it in the first place. Well, there's one reason why, in my opinion the front pages of FusionForge are rather un-user friendly, I mean what the heck is "Code Snippets" doing there? They feel very aimed at developers, which is great... but I need a nice straightforward interface for less savvy users. Looking today, the navigation still feels it's just too developer centric, but as these sites double as developer sites and user sites (to acquire the software, report bugs and so on), that's not great. I really don't know yet whether Fusion Forge has better graphical tools than Savane.

In a conversation about this last week, Noodles suggested I should look at the ease with which the interface could be changed. A sensible suggestion I shall follow up.

Redmine

Written in Ruby on Rails and advocated by my work colleage Paul Vitty, Redmine is clean and elegant looking. It shows all the signs of benefiting from being a later generation project and has a plugin architecture that seems excellent too. It has easy clean wiki integration, graphical road maps and Gannt charts; and these things make a difference. I don't think it's as remotely scalable as the design of the first two systems, which isn't a huge problem for me, but I mention it in passing.

On the other hand, it seems to have little or no automated integration into the backend, user and group creation, mailing lists and so on. on the other hand it has a very rich set of plug ins, so it may already have such support or it may be possible to implement it.

Trac

Written in Python, Trac feels like Redmine lite, and that's in the wrong direction for me. It explicitly does not have multiple project support and that's a deal breaker for me.

I haven't come to a strong conclusion about this so far. I note John (whom I linked above) notes that Redmine is difficult to install and upgrade because of Ruby, this is a hassle I just don't need, but he also thinks it may be the best of the field. For me, it is probably more trouble free to migrate to the fork of Savane or to FusionForge. More thought needed, and your thoughts are most welcome!

Richard Feynman Lectures

nospam@example.com (Colin Turner) — Sat, 25 Jul 2009 00:03:10 +0000

I hold Richard Feynman in huge regard. He was a fascinating human being, a Nobel laureate physicist, his research in physics was second to none. But he was also a legendary lecturer, in both the fields of physics, and perhaps surprisingly computer science. And even more, he was an exceptionally well rounded person, a gifted artist, an amateur safe cracker and more besides. I own a copy of his lectures on Physics, bought for me by my Mum who felt (probably correctly) that no-one else would buy an item that sounded so boring, though it was on my Amazon wish list. (Incidentally, I think some pages touch on issues like the paradox I presented on crashing cars, I haven't had the leisure to study this more closely).

Recently it was announced (and one of my students kindly wrote to tell me) that Bill Gates had bought up the rights to his lecturers and was making them available. I do praise Bill Gates for his philanthropy, and would have praised him for this, but regrettably, the lectures are only available with Silverlight, and so it's another of a long line of Trojan horses to ensure we buy into a new proprietary standard from Microsoft. A huge shame.

In my last, marathon article, I talked a little about models of reality. A point I didn't make is that we have trouble accepting that; no matter how much we dislike aspects of reality, they remain the same despite that. Feynman encapsulated this beautifully in this YouTube snippet of his QED lectures (which I had showed to my final year students). I have attempted a limited transcript below, but you should hear it in Feynman's excellent good humoured Brooklyn accent for full effect.

And then there's the ... kind of thing which you don't understand. Meaning "I don't believe it, it's crazy, it's the kind of thing I won't accept."

Eh. The other part well... this kind, I hope you'll come along with me and you'll have to accept it because it's the way nature works. If you want to know the way nature works, we looked at it, carefully, [...unsure of this bit...] that's the way it works.

You don't like it..., go somewhere else!

To another universe! Where the rules are simpler, philosophically more pleasing, more psychologically easy. I can't help it! OK! If I'm going to tell you honestly what the world looks like to the... human beings who have struggled as hard as they can to understand it, I can only tell you what it looks like.

And I cannot make it any simpler, I'm not going to do this, I'm not going to simplify it, and I'm not going to fake it. I'm not going to tell you it's something like a ball bearing inside a spring, it isn't.

So I'm going to tell you what it really is like, and if you don't like it, that's too bad.

If you'd like to hear more from this fascinating man, can I suggest more YouTube videos showing an old BBC interview with him:

Mono in Debian

nospam@example.com (Colin Turner) — Mon, 29 Jun 2009 12:20:32 +0000

I note that the controversy of Mono in Debian which reached fever pitch with the inclusion of Tomboy as part of the default Gnome applications rages on, and now RMS has entered the fray.

I respect Stallman a lot. I'm a fellow of FSFE. His positions are usually well thought and argued, though I can't say I agree with him on all of them, and I don't agree with this one.

On the issue of the plain usefulness of Mono apps; well some of them are just excellent. I use f-spot for managing my photo collection and have to say no other application I've used comes close. Tomboy is itself a considerable improvement on the almost useless sticky notes applet that's been in Gnome for some time; though I've yet to work out what minimum I need for ssh synchronization (to be fair, I've hardly tried).

And I should declare an interest. I thought Gnome-Do was absolutely excellent when I stumbled upon it, and I helped in a modest way to initially package it for Debian (specifically I updated the Ubuntu stuff for the plugins package and prepared that for its initial import to the archive), albeit I haven't worked on it since. It's fairly clear to me that implementing this in, for example, C++ looks like it could be a lot more work. I can't say I've studied it in total depth, but that was my feeling when working with the code.

Anyway, never mind all the issues of sheer practicality; Jo Shields of the Debian Mono team, wrote an excellent rebuttal to some of the nonsense that was posted about Mono. It makes excellent reading. It is calmly delivered (with an undertone of quite justified and controlled anger), carefully argued and a cautionary tale about some of the nonsense we in the Free Software community can get wrapped up in, it's value extends well beyond the current debacle.