I m a Debian Maintainer currently undergoing the New Maintainer process. I m also an Ubuntu MOTU as of recently. I have several packages in a variety of categories, but I specialize in Python-based software. I m interested in exploring more ways to improve cross-distribution coordination, specifically as it relates to the Debian Sugar packages. I m working to get all of the Ubuntu-specific Sugar packages included in Debian, which will probably be a summer-long effort.

The inofficial rc bug tracker currently knows about the following bugs:

In Total:	523
Affecting Squeeze:	419
Squeeze only:	65
Remaining to be fixed in Squeeze:	354

Of these 354 bugs, the following tags are set:

Pending in Squeeze:	19
Patched in Squeeze:	55
Duplicates in Squeeze:	51
Contrib or non-free in Squeeze:	26
Claimed in Squeeze:	6
Delayed in Squeeze:	7
Can fixed in a security Update:	31
Otherwise fixed in Squeeze:	38

Ignoring all the above (multiple tags possible), 170 bugs need to be fixed by Debian Contributers to get Debian 6.0 Squeeze released. However, the with the view of the Release Managers, 316 need to be dealt with for the release to happen. Please see my older post for an explanation of the different numbers.

Oddly, I have had four different people ask me about the best way to begin a Django project or setup their system to make it easy to develop with Django. Since I've now given my response via email so many times, I figure I might as well broadcast it and hopefully this will help others as well My assumptions:

• Using Linux (or a Unix machine)
• Single developer with root access (quite possibly a laptop)
• Knowledge of DVCSes (e.g. git / hg / bzr )

What we will do is create a private binary directory and another Python modules. Then take a checkout of the two most important Django projects, and make them work. First: create your user

$ sudo adduser newbie
$ ssh localhost -l newbie
$ whoami
newbie

Then we want to create some local bin and lib directories. First the binary directory $ mkdir ~/bin # On Ubuntu/Debian, this will automatically be in your PATH the next time you login And now a local directory for our various libraries

$ mkdir -p ~/lib/python
$ echo "PYTHONPATH=~/lib/python:" >> ~/.bashrc
$ echo "export PYTHONPATH" >> ~/.bashrc

This will add that directory to our Python path. If you happen to also use another language you can put things into ~/lib/ruby, ~/lib/perl as appropriate

$ mkdir ~/Projects
$ cd ~/Projects

Here is where we will store copies of upstream software. What is the reason for using the repositories rather than packages? This allows us to checkout specific versions to match what our clients might be using. Or test things against newer versions of the upstream project. First, let's setup Django. I tend to use git by default, especially if the upstream is using Subversion. If they are using Mercurial or Bazaar, I use those directly.

$ git svn clone -s http://code.djangoproject.com/svn/django/
Initialized empty Git repository in /home/newbie/Projects/django/.git/
Using higher level of URL: http://code.djangoproject.com/svn/django => http://code.djangoproject.com/svn
r1 = 5cda37203ffa6ea83da2958a95c377984482877f (refs/remotes/trunk)
	A	django-docs/images/flatfiles_admin.png
	A	django-docs/images/users_changelist.png
	A	django-docs/model-api.txt
	A	django-docs/build.py
	A	django-docs/db-api.txt
	A	django-docs/writing-apps-guide-outline.txt
	A	django-docs/templates.txt
r2 = b8249ac45e2154933b9649fd8181d5769e31c9fc (refs/remotes/trunk)
	A	django/utils/feedgenerator.py
	A	django/utils/datastructures.py
[...]
r13399 = f3902c67a3b8788de2145899e435a394c512b455 (refs/remotes/releases)
	M	tests/regressiontests/m2m_through_regress/tests.py
r13400 = cd72207306a5a4eecdf07f65c109f37c8317ed81 (refs/remotes/trunk)
$

Now we have Django, push it into our python path

$ cd ~/lib/python
$ ln -s ~/Projects/django/django/
$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import django
>>> django.VERSION
(1, 2, 1, 'final', 0)

Now, let's do the same for South. South is a database migration helper for Django. These are the two things you want to have in any Django at a minimum. There are also plenty of other amazing things like haystack, piston, satchmo, etc. You can follow the same recipie for them too.

$ cd ~/Projects
$ hg clone http://bitbucket.org/andrewgodwin/south/
destination directory: south
requesting all changes
adding changesets
adding manifests
adding file changes
added 802 changesets with 1340 changes to 183 files (+1 heads)
updating to branch default
143 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd ~/lib/python
$ ln -s ~/Projects/south/south
$ python 
Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import south
>>> south.__version__
'0.7.1'

Finally, we want to be able to create Django projects. There is a great helper called django-admin that will do this. Let's put it into our path

$ cd ~/bin
$ ln -s ~/Projects/django/django/bin/django-admin.py
$ hash -r

That last statment will cause your interpreter to re-read PATH and make anything new available for execution. Now, you should go ahead and create your projects. There are a variety of ways to do this. However what I like to do is keep Django applications separate from the Django project. That way, they can easily be re-used if required. So, for a project called 'foo', we might have

$ mkdir -p ~/Work/foo
$ cd ~/Work/foo
$ mkdir foo.example.com
$ mkdir templates
$ mkdir media
$ mkdir <individual apps>

For each individual app, put them into the Python library. And you then have your re-usability from within Django. For a application called 'bar', you would do:

$ cd ~/Work/foo
$ django-admin.py startapp bar
$ cd ~/lib/python
$ ln -s ~/Work/foo/bar

And now, in your Django foo.example.com setting.py's file you can put 'bar' as one the installed applications and things will Just Work Obviously there are many way to slice this particular mango, but I've found that this works pretty well for me. You can spruce it up by revision controlling each directory in your project (I do) and also take advantage of things like virtualenv and Fabric to make deploying just as easy as developing. But I'll leave those topics until a later date

A while ago, I discovered nagstamon, a very useful piece of software by Henri Wahl. This program sits in the notification area of your desktop and alerts you when your nagios-monitored services have problems. Using nagstamon allows me to keep my servers under close surveillance, and it also adds another channel besides e-mail alerts, which will be helpful in case my mail server has problems. The wish I am not a full time sysadmin, I only monitor very few hosts and the services rarely have problems. Therefore, I do not want nagstamon to constantly sit in the notification area but only use it when there is something, well, to notify me about. It turned out that nagstamon did not support this mode of operation, so I created a ticket and asked whether this feature could be added. The author raised two points, one being that then the user would not know when nagios crashed and the other being that you would not be able to configure nagstamon because you do not see it. He also indicated that he does not have the resources to work on it and asked if I could find the time. The patch Since I really liked nagstamon, but really want to keep my panel uncluttered, I found the time: I created a series of self-containing patches, adding an option for the feature, adding code to prevent more than one instance of nagstamon running in parallel and adding a "nagstamon --settings" flag that would signal the running instance to show the settings similar to how mail-notification is been behaving. The author then raised the valid point that some people run more than one instances in parallel, with different configuration options. I then extended the patch to cater for that. The rebuff The author remained reserved, did not answer my last commend on the ticket and then, six weeks later, closed the bug without explanation and turned off the possibility to add comments. I can understand when people are reluctant to add contributed features to their code, I often feel the same way. But completely blocking more comments is not a nice way of communicating with possible contributors. The fork(let) So I m left with no option but patching each released version with my changes and building my own package. As I have to do this work anyways, I d like to share it. You can find my branch in my git repository. If you happen to want this feature as well and are using a Debian-based distribution, please let me know: I am building modified Debian packages anyways and can publish them as well. As I don t want to maintain this fork of nagstamon I don t plan to diverge any more from Henri s code, so if you have other feature requests, please talk to him first.

A while ago, I discovered nagstamon, a very useful piece of software by Henri Wahl. This program sits in the notification area of your desktop and alerts you when your nagios-monitored services have problems. Using nagstamon allows me to keep my servers under close surveillance, and it also adds another channel besides e-mail alerts, which will be helpful in case my mail server has problems. The wish I am not a full time sysadmin, I only monitor very few hosts and the services rarely have problems. Therefore, I do not want nagstamon to constantly sit in the notification area but only use it when there is something, well, to notify me about. It turned out that nagstamon did not support this mode of operation, so I created a ticket and asked whether this feature could be added. The author raised two points, one being that then the user would not know when nagios crashed and the other being that you would not be able to configure nagstamon because you do not see it. He also indicated that he does not have the resources to work on it and asked if I could find the time. The patch Since I really liked nagstamon, but really want to keep my panel uncluttered, I found the time: I created a series of self-containing patches, adding an option for the feature, adding code to prevent more than one instance of nagstamon running in parallel and adding a "nagstamon --settings" flag that would signal the running instance to show the settings similar to how mail-notification is been behaving. The author then raised the valid point that some people run more than one instances in parallel, with different configuration options. I then extended the patch to cater for that. The rebuff The author remained reserved, did not answer my last commend on the ticket and then, six weeks later, closed the bug without explanation and turned off the possibility to add comments. I can understand when people are reluctant to add contributed features to their code, I often feel the same way. But completely blocking more comments is not a nice way of communicating with possible contributors. The fork(let) So I m left with no option but patching each released version with my changes and building my own package. As I have to do this work anyways, I d like to share it. You can find my branch in my git repository. If you happen to want this feature as well and are using a Debian-based distribution, please let me know: I am building modified Debian packages anyways and can publish them as well. As I don t want to maintain this fork of nagstamon I don t plan to diverge any more from Henri s code, so if you have other feature requests, please talk to him first.

I've had the opportunity to look into the Joojoo tablet recently. It's an interesting device in various ways, ranging from the screen being connected upside down and everything having to be rotated before display, to the ACPI implementation that's so generic it has no support for actually attaching most embedded controller interrupts to ACPI devices and so relies on a hacked kernel that exposes individual interrupts as ACPI events that are parsed in userspace, to the ChangeOrientation binary that's responsible for switching between landscape and portrait modes containing gems like ps aux grep fgplayer grep -v grep and containing references to org.freedesktop.PandaSystem, a somewhat gratuitous namespace grab. Hardware-wise it seems to be little more than battery, generic nvidia reference design board and touchscreen with an accelerometer and LED glued to the chipset's GPIO lines. The entire impression is one of an ambitious project not backed up by the level of technical expertise required to get things done properly. Frankly, I think Michael Arrington came out of this rather better than he could have done - behind the reasonably attractive UI, the entire device is pretty much held together by string and a following wind.

Of course, releasing shoddily put together technology isn't generally illegal and from that point of view Fusion Garage aren't any worse than a number of products I've had the misfortune to actually spend money on. But they're distributing Linux (stock Ubuntu with some additional packages and a modified kernel) without any source or an offer to provide source. I emailed them last week and got the following reply:

Dear Sir,

we are still actively making changes to the joojoo software. We will make
the source release available once we feel we are ready to do so and also
having the resources to get this sorted out and organized for publication.
We seek your kind understanding on our position and appreciate your
patience on this. Thank you.

Best Regards
joojoo Support Team

Strong work, Fusion Garage. Hardware and software may not be your strong points, but you're managing copyright infringement with the best of them.

racket (previously known as plt-scheme) is an interpreter/JIT-compiler/development environment with about 6 years of subversion history in a converted git repo. Debian packaging has been done in subversion, with only the contents of ./debian in version control. I wanted to merge these into a single git repository. The first step is to create a repo and fetch the relevant history.

TMPDIR=/var/tmp
export TMPDIR
ME= readlink -f $0 
AUTHORS= dirname $ME /authors
mkdir racket && cd racket && git init
git remote add racket git://git.racket-lang.org/plt
git fetch --tags racket
git config  merge.renameLimit 10000
git svn init  --stdlayout svn://svn.debian.org/svn/pkg-plt-scheme/plt-scheme/
git svn fetch -A$AUTHORS
git branch debian

A couple points to note:

• At some point there were huge numbers of renames when then the project renamed itself, hense the setting for merge.renameLimit
• Note the use of an authors file to make sure the author names and emails are reasonable in the imported history.
• git svn creates a branch master, which we will eventually forcibly overwrite; we stash that branch as debian for later use.

Now a couple complications arose about upstream's git repo.

1. Upstream releases seperate source tarballs for unix, mac, and windows. Each of these is constructed by deleting a large number of files from version control, and occasionally some last minute fiddling with README files and so on.
2. The history of the release tags is not completely linear. For example,

rocinante:~/projects/racket  (git-svn)-[master]-% git diff --shortstat v4.2.4  git merge-base v4.2.4 v5.0 
 48 files changed, 242 insertions(+), 393 deletions(-)
rocinante:~/projects/racket  (git-svn)-[master]-% git diff --shortstat v4.2.1  git merge-base v4.2.1 v4.2.4 
 76 files changed, 642 insertions(+), 1485 deletions(-)

The combination made my straight forward attempt at constructing a history synched with release tarballs generate many conflicts. I ended up importing each tarball on a temporary branch, and the merges went smoother. Note also the use of "git merge -s recursive -X theirs" to resolve conflicts in favour of the new upstream version. The repetitive bits of the merge are collected as shell functions.

import_tgz()  
    if [ -f $1 ]; then
        git clean -fxd;
        git ls-files -z   xargs -0 rm -f;
        tar --strip-components=1 -zxvf $1 ;
        git add -A;
        git commit -m'Importing ' basename $1 ;
    else
        echo "missing tarball $1";
    fi;
 
do_merge()  
    version=$1
    git checkout -b v$version-tarball v$version
    import_tgz ../plt-scheme_$version.orig.tar.gz
    git checkout upstream
    git merge -s recursive -X theirs v$version-tarball
 
post_merge()  
    version=$1
    git tag -f upstream/$version
    pristine-tar commit ../plt-scheme_$version.orig.tar.gz
    git branch -d v$version-tarball
 

The entire merge script is here. A typical step looks like

do_merge 5.0
git rm collects/tests/stepper/automatic-tests.ss
git add  git status -s   egrep ^UA   cut -f2 -d' ' 
git checkout v5.0-tarball doc/release-notes/teachpack/HISTORY.txt
git rm readme.txt
git add  collects/tests/web-server/info.rkt
git commit -m'Resolve conflicts from new upstream version 5.0'
post_merge 5.0

Finally, we have the comparatively easy task of merging the upstream and Debian branches. In one or two places git was confused by all of the copying and renaming of files and I had to manually fix things up with git rm.

cd racket   /bin/true
set -e
git checkout debian
git tag -f packaging/4.0.1-2  git svn find-rev r98 
git tag -f packaging/4.2.1-1  git svn find-rev r113 
git tag -f packaging/4.2.4-2  git svn find-rev r126 
git branch -f  master upstream/4.0.1
git checkout master
git merge packaging/4.0.1-2
git tag -f debian/4.0.1-2
git merge upstream/4.2.1
git merge packaging/4.2.1-1
git tag -f debian/4.2.1-1
git merge upstream/4.2.4
git merge packaging/4.2.4-2
git rm collects/tests/stxclass/more-tests.ss && git commit -m'fix false rename detection'
git tag -f debian/4.2.4-2
git merge -s recursive -X theirs upstream/5.0
git rm collects/tests/web-server/info.rkt
git commit -m 'Merge upstream 5.0'

Petter suggests to make the dhcpHost LDAP objectClass an auxiliary one, to make it possible to combine it with the dNSDomain objectClass in one and the same object. Unfortunately, you can't do that. Well not if you want Debian-edu to remain compatible with everything else under the sun. You see, one of the features of LDAP is that each and every objectClass is well-defined, and that you cannot change it. As such, once a tool knows about an objectClass, it can make assumptions about objects in that class, for any such object, in any LDAP-server anywhere. Change an objectClass, and some tools will break. The proper fix is, first, to verify that you are using the proper objectClasses. To me, an objectClass called dhcpHost and one called dNSDomain don't sound like they were meant to be used together; I would suspect that there is another DNS-related objectClass that is meant for hosts rather than domains. If that isn't the case, then one can create a new objectclass say, auxiliaryDhcpHost or some such that is the same as dhcpHost in all but name, OID, and the fact that you make it an auxiliary rather than a structural objectClass. Because luckily, what's true for an objectClass is also true for an attributeType: if it is assigned to an LDAP object, tools may assume that their meaning is what they think it is...

A while back, I complained about the fact that it is not possible with the provided schemas for storing DNS and DHCP information in LDAP to combine the two sets of information into one LDAP object representing a computer. In the mean time, I discovered that a simple fix would be to make the dhcpHost object class auxiliary, to allow it to be combined with the dNSDomain object class, and thus forming one object for one computer when storing both DHCP and DNS information in LDAP. If I understand this correctly, it is not safe to do this change without also changing the assigned number for the object class, and I do not know enough about LDAP schema design to do that properly for Debian Edu. Anyway, for future reference, this is how I believe we could change the DHCP schema to solve at least part of the problem with the LDAP schemas available today from IETF.

--- dhcp.schema    (revision 65192)
+++ dhcp.schema    (working copy)
@@ -376,7 +376,7 @@
 objectclass ( 2.16.840.1.113719.1.203.6.6
        NAME 'dhcpHost'
        DESC 'This represents information about a particular client'
-       SUP top
+       SUP top AUXILIARY
        MUST cn
        MAY  (dhcpLeaseDN $ dhcpHWAddress $ dhcpOptionsDN $ dhcpStatements $ dhcpComments $ dhcpOption)
        X-NDS_CONTAINMENT ('dhcpService' 'dhcpSubnet' 'dhcpGroup') )

I very much welcome clues on how to do this properly for Debian Edu/Squeeze. We provide the DHCP schema in our debian-edu-config package, and should thus be free to rewrite it as we see fit. If you want to help out with implementing this for Debian Edu, please contact us on debian-edu@lists.debian.org.

ikiwiki is not yet able to create a Google sitemap internally, so I'm using google-sitemapgen. To run it automatically when the website is being updated, I've changed the git hook to run it after the ikiwiki hook.

• In the ikiwiki setup file let git_wrapper point to a file which is not the post-update hook, so you're able to run it from your own skript. I'm using /path/to/myikiwiki.git/hooks/post-update.ikiwiki.
• Write a skript which runs as post-update hook and executes the created hook from ikiwiki and google-sitemapgen with a proper configuration. My versions of both files are listed below.

/path/to/myikiwiki.git/hooks/post-update

#!/bin/sh
/path/to/myikiwiki.git/hooks/post-update.ikiwiki
/usr/bin/google-sitemapgen --config=/path/to/mywikiconfig/sitemap_config.xml
exec git-update-server-info

/path/to/mywikiconfig/sitemap_config.xml

<?xml version="1.0" encoding="UTF-8"?>
<site
  base_url="http://bzed.de/"
  store_into="/path/to/bzed.de/sitemap.xml.gz"
  verbose="0"
  suppress_search_engine_notify="0"
  default_encoding="UTF-8"
  >
  <directory
    path="/path/to/bzed.de"
    url="http://bzed.de/"
    default_file="index.html"
  />
  <!-- Exclude URLs that end with a '~'   (IE: emacs backup files)      -->
  <filter  action="drop"  type="wildcard"  pattern="*~"           />
  <!-- Exclude URLs within UNIX-style hidden files or directories       -->
  <filter  action="drop"  type="regexp"    pattern="/\.*"     />
  <!-- Exclude ikiwiki directories -->
  <filter  action="drop"  type="regexp"  pattern="/helponformatting/*"           />
  <filter  action="drop"  type="regexp"  pattern="/ikiwiki/*"                    />
  <filter  action="drop"  type="regexp"  pattern="/markdown/*"                   />
  <filter  action="drop"  type="regexp"  pattern="/openid/*"                     />
  <filter  action="drop"  type="regexp"  pattern="/pagespec/*"                   />
  <filter  action="drop"  type="regexp"  pattern="/preprocessordirective/*"      />
  <filter  action="drop"  type="regexp"  pattern="/sandbox/*"                    />
  <filter  action="drop"  type="regexp"  pattern="/shortcuts/*"                  />
  <filter  action="drop"  type="regexp"  pattern="/smileys/*"                    />
  <filter  action="drop"  type="regexp"  pattern="/subpage/*"                    />
  <filter  action="drop"  type="regexp"  pattern="/templates/*"                  />
  <filter  action="drop"  type="regexp"  pattern="/theme/*"                      />
  <filter  action="drop"  type="regexp"  pattern="/wikiicons/*"                  />
  <filter  action="drop"  type="regexp"  pattern="/wikilink/*"                   />
  <filter  action="drop"  type="regexp"  pattern="/wmd/*"                        />
  <!-- Exclude css files, favicon and javascript -->
  <filter  action="drop"  type="wildcard"    pattern="*.css"                         />
  <filter  action="drop"  type="wildcard"    pattern="*favicon.ico"                  />
  <filter  action="drop"  type="wildcard"    pattern="*.js"                          />
  <!-- Exclude ikiwiki.cgi -->
  <filter  action="drop"  type="wildcard"    pattern="ikiwiki.cgi"                   />
</site>

See the examples and README files in /usr/share/doc/google-sitemapgen/ for an introduction into configuring google-sitemapgen. So far the generated sitemaps works very well, especially for search engines which are not able to use the rss feeds like Google does.

Over the past few years I've amassed a collection of a few thousand images taken with a succession of digital cameras. I'm pretty good at organising images, in a directory hierarchy which makes sense to me, in a few simple and broad categories:

skx@birthday:~$ tree -L 1 ~/Images/
/home/skx/Images/
 -- Misc
 -- Parties
 -- People
 -- Pets & Animals
 -- Travel

Beneath ~/Images/People, for example, I have subdirectories for specific individuals (or a "Debian/" folder for Debian-people who've been snapped but don't warrant their own folder.) ~/Images/Travel has things like Travel/Local/2010, Travel/Vienna/2008, etc. In summary I have images of people, places, and things stored beneath what should be a reasonably discoverable directory hierarchy, however this just doesn't work. I still struggle to find images - for example images of myself might be located in ~/Images/People/Self/*, but in practise I'm often included in ~/Images/Travel/* as well. A few times I've looked at using f-spot, digikam, and similar tools to perform image-organisation (but not editing, or timelines, or anything else. Just organisation). I've found I didn't like being locked into their formats, didn't want them to copy my images to a second location, and other gripes. In the end I've forced myself to come up with a Steve-Specific-Solution. Not for the first time, but I think I have just cause... I'm now using the User-Comment field in the image's EXIF data to store tags. (When it comes to EXIF data I keep camera-generated fields, but sometimes update/set "Copyright", "Comment", and "Title" fields. So UserComment is one I've never used until now, and thus I run no risk of trashing existing meta-data.) I've put together a simple perl script, called itag, which will:

• Index the tag information from all images beneath ~/Images into a DBM file.
• Show the filenames of all images matching a tag, or tags.
• Allow me to add tag(s) to an image (which both updates the EXIF data and updates the DBM "cache").

This is enough for me to be able to see all images of "Edinburgh", via:

~$ qiv --fullscreen --slide --delay 5 $(itag --search=edinburgh)

Similarly I could find myself:

~$ itag --search=steve --search=people

I'm not sure it is useful to others, mostly on the basis that people probably fall into their own routine when it comes to filing, and I suspect that people with vast collections of images will just get annoyed by the obscenely slow indexing process I've got. (Hint: run "exiftool" on every /.jpe?g$/i file..) Still its a simple enough idea and I think it should scale in the future - I can even see myself writing a wee GUI to do tag exploration and similar. Just not today. ObFilm:Aeon Flux ObRandom: Apologies for people waiting on email - it's been that kind of week.

Debconf is fast approaching I thought I would pass on some helpful news: some helpful to you all, some more to us. First, a number of volunteers have compiled this astonishingly detailed list of things to do in NYC, including many that are free. Clearly you can come to Debconf and not come to Debconf. We hope you still do, but if you want to sneak out a few times and venture into this city, this is the list to consult. We are also now coordinating our on-site volunteers and perhaps you are interested in pitching in here and there. If you are, here is a list of things we need help with. If you do want to help, you can drop a line on our mailing list (please write [volunteer in the subject line). You can post even if you are not subscribed (although there are times it takes awhile for message approval. Alternatively, you can drop me a note (contact information here and I can pass on the information.

Actually they're more interested in freedom, to be no longer slaves to humans. I don't think it's any spoiler to mention that an electric sheep does appear in the book.

This is a classic science fiction story of a dark not-so-distant future. In fact given that it's over 40 years old it could be set in some alternate now. Some disaster has occurred and many have either left earth or died. Some andriods, or andys have escaped and bounty hunters are after them.

You may not know the book by its correct title, but you may of heard the movie that is based upon it, called Blade Runner. Like most movies based on books, it takes some of the concepts and ideas of the book but in my opinion is a pale imitation.

I'm glad I read this book. It hasn't aged that much and it's very though provoking. Sci-Fi often uses some alternate reality to put a mirror up to what happens in the real world and this book is no exception.

And a token link to Debian, if you want you own electric sheep you can install the screensaver electricsheep package which draw pretty fractals on your screen.

Related articles by Zemanta

• Philip K. Dick Journals To Be Published In 2011 (huffingtonpost.com)
• Philip K. Dick on Blade Runner (kottke.org)

Having invested in some introspection into my reading habits, I made up my mind to dial down my consumption of bite-sized nuggets of online information, and finish a few books. That s where my bottleneck has been for the past year or so. Not in selecting books, not in acquiring books, and not in starting books either. I identify promising books, I buy them, I start reading them, and at some point, I put them down and never pick them back up again. Until now. Over the weekend, I finished two books. I started reading both in 2009, and they each required my sustained attention for a period measured in hours in order to finish them. Taking a tip from Dustin, I decided to try alternating between fiction and non-fiction. Jitterbug Perfume by Tom Robbins This was the first book I had read by Tom Robbins, and I am in no hurry to read any more. It certainly wasn t without merit: its themes were clever and artfully interwoven, and the prose elicited a silent chuckle now and again. It was mainly the characters which failed to earn my devotion. They spoke and behaved in ways I found awkward at best, and problematic at worst. Race, gender, sexuality and culture each endured some abuse on the wrong end of a pervasive white male heteronormative American gaze. I really wanted to like Priscilla, who showed early promise as a smart, self-reliant individual, whose haplessness was balanced by a strong will and sense of adventure. Unfortunately, by the later chapters, she was revealed as yet another vacant vessel yearning to be filled by a man. She s even the steward of a symbolic, nearly empty perfume bottle throughout the book. Yes, really. Managing Humans by Michael Lopp Of the books I ve read on management, this one is perhaps the most outrageously reductionist. Many management books are like this, to a degree. They take the impossibly complex problem domain of getting people to work together, break it down into manageable problems with tidy labels, and prescribe methods for solving them (which are hopefully appropriate for at least some of the reader s circumstances). Managing Humans takes this approach to a new level, drawing neat boxes around such gestalts as companies, roles, teams and people, and assigning them Proper Nouns. Many of these bear a similarity to concepts which have been defined, used and tested elsewhere, such as psychological types, but the text makes no effort to link them to his own. Despite being a self-described collection of tales , it s structured like a textbook, ostensibly imparting nuggets of managerial wisdom acquired through lessons learned in the Real World (so pay attention!). However, as far as I can tell, the author s experience is limited to a string of companies of a very specific type: Silicon Valley software startups in the dot com era. Lopp (also known as Rands) does have substantial insight into this problem domain, though, and does an entertaining job of illustrating the patterns which have worked for him. If you can disregard the oracular tone, grit your teeth through the gender stereotyping, and add an implicit preface that this is (sometimes highly) context-sensitive advice, this book can be appreciated for what it actually is: a coherent, witty and thorough exposition of how one particular manager does their job. I got some good ideas out of this book, and would recommend it to someone working in certain circumstances, but as with Robbins, I m not planning to track down further work by the same author.

How to have a (Debian) summit without turning into a secret cabal It seems rather uncontroversial that sponsoring various kinds of Debian meetings (conferences, sprints, BSPs, etc.) is a good way to spend, actually invest, Debian money. Historically, that has not always saved the Debian community from muttering about "cabal-ish" meetings in very few specific occasions. (No, there is no cabal, in case you wonder.) I've always believed in the good faith of people and I don't think that we have ever had "secret meetings" on purpose. Nevertheless the question of how to have meetings in a community-compatible way is a sound one. Answering properly to such a question is something that it's harder than what it might seem at first sight (at least for me). In particular, organizers have to carefully balance the high efficiency that meetings offer (e.g.: communication bandwidth is higher than when working remotely, people have less distractions, more enthusiasm, more fun!, etc.) with the risk of cutting out the rest of the community which cannot attend the meeting, for whatever reason. Note also that since Debian is not a company, we cannot just require that everybody who is interested attend the meeting. As DPL, I'm starting to get quite some requests for meeting sponsorship, and that's just wonderful: it means that we have thrilling groups of people that are eager to get together and hack to improve Debian! Still, in doing so, we should all try to minimize the above risk; that's why I've started to apply the following Debian meeting guidelines, as a kind of prerequisite for sponsoring.

1. Before the meeting: the meeting should be announced to the most relevant public mailing list(s); ideally, the tentative agenda of the meeting should be included in the announcement.
   That will enable people interested in the meeting topics to provide their inputs and more generally to know what is going on.
2. During the meeting (preparation): expenses should be minimized, as a form of respect for all people that donate to Debian. Since we value their contributions, we do our best not to waste them. (TTBOMK, we've always done that, but making it explicit won't hurt.)
3. After the meeting: meeting minutes should be sent to the most relevant public mailing list(s), usually to d-d-a for meetings that cover topics of general development interest.
   As an obvious consequence, minutes should be taken during the meeting; it is a bit of extra burden, but the risk of leaving the rest of the community in the dark is just not acceptable a community as wide and diverse as ours.
4. In general, think about communication, e.g.: (micro)blog about the meeting, contact press/-publicity to prepare a news item about it, enable others to attend virtually on IRC or other media, etc.

For now, the above is just a brain dump.
Now, what do you think? Are the above reasonable demands? What else should we ask for?
Feel free to leave a comment or mail me about that.

Well the latest version of PSmisc is almost finished, so I pushed the tar archive up to the spot for the translators, waiting for the updates before it gets released.

It reminded me that perhaps a lot of people don't know how their programs get translated. Perhaps there are some that could even contribute. The nice thing about the translation systems is that you don't need to know programming to help.

PSmisc uses the translation project as its method. The program itself uses gettext for the translation part which makes a single text file called a POT file. A translator takes this text file and makes a po file, such as it.po for the Italian translation and then translates, which basically means editing the file, reading each first line of a set and writing the translation on the second line.

For the programmer, once it is setup it is pretty simple to use, just mark your translatable lines and follow some simple rules, mainly about not embedding too much in a string. I've used this system for years for quite a few of my programs and there is little added work for me.

Unfortunately, translating is hard work and should be a long-term commitment. Having a look at the translation project's Translation Matrix and you can see that some languages do suffer, though there are some very good results there too. Particular kudos goes to the Vietnamese group which I think is just Clytie who does a marvellous job and is often the first translation file I get.

For the Debian project, there are many places where translations can occur. There doesn't seem to be a centralised place for this, but some of the places they use translation work are:

• Translating The Debian website
• Debian Description Translation Project
• Debian debconf (configuration questions when you install packages)
• Translating Debian News

Lockfiles are usually hard to get right, especially in sh scripts. The best bet so far was "lockfile" included with procmail, but its semantics are pretty weird. (Try to understand what exit code you want, with or without "-!".) Not to mention that failing to clean up the lockfile will stop the next cron run, etc. Since Lenny, util-linux ships "flock". Now you simply say

$ flock /path/to/lockfile /path/to/command

and are done. If you want it non-blocking, add "-n":

$ flock -n /path/to/lockfile /path/to/command

I should probably migrate all my cronjobs to use this.