From time to time I see people arguing that the wide deployment of IPv6 will force DNSBLs to significantly change their operations and semantics. Usually they have little or no actual experience with IPv6 and the main argument used to justify this view appears to be more or less "OMG so many bits!1!!!".
I have no reason to believe that this will really happen. People are already sending mail over IPv6 and I expect that the same reputation mechanisms used for IPv4 will be deployed as soon as they will be needed, with small policy changes to cope with the fact that end users typically get a whole network instead of a single IP address.
So I expect that DNSBLs will continue to operate as usual like they currently do for IPv4 addresses, optionally by promoting "single IP" listings to "whole /64" listings when appropriate.
Debian Packages
Every now and again I look over server logs and see people downloading random .deb packages from my mirrors, or from my servers, via wget or Firefox (rather than with apt-get/aptitude). Personally I don't often download random binaries even from people I believe I can trust. Instead I'll download source and rebuild. But it bugs me that somebody might download a work-in-progress, decide it isn't complete or otherwise good enough, and miss out on an update of awesome-sauce a day or two later. I suspect there is no real solution to this "problem", and that including /etc/apt/sources.list.d/ entries inside a binary package to "force" an upgrade behind the scenes is a little too evil to tolerate. And yet .. something something dark-side .. something something seductive something?Blog Update
This is my last film-subject entry. In the future I will have more accurate subjects, albeit more dull ones. I still amuse myself with quotations, and before that the song lyrics, but I guess that now is a good time to call it a day with that.ObFilm: Cruel Intentions
Thanks to the versatility of the Linux kernel, Debian has always been known for supporting a large number of architectures. It has also often been criticized for that as it is said to slow down the development of Debian.
Among these architectures, the ARM one was considered dead a few years ago, and some people wanted to get rid of it. Today all major distributions now have an ARM port, one of those distributions being even based on Debian. It seems Debian was right.
Now that Android has been ported to MIPS, we may see more and more MIPS based devices. Will the same scenario happen again?
Folks at last year's Wikimania may remember the presentation I gave
there. It was essentially a literature review of Wikipedia and
Wikimedia scholarship from the previous year. The idea was to give a
bird's-eye-view as well a series of highlights -- all aimed at
Wikimedians.
Apparently somebody found it useful because I've been asked to do it
again! I'm going to be paired up in a longer session with Felipe
Ortega -- whose excellent dissertation I summarized as part of my
talk last year -- and Mayo Fuster Morell has also agreed to help
out. Felipe is program chair for WikiSym this year and will be
focusing on providing folks with a summary of the papers published at
that conference. It will be held immediately before Wikimania in Gdansk.
For my part, I'm going to be focusing more broadly and talking about
papers published, well, anywhere else.
And this is where you come in!
With search engines and all, I've got a pretty good idea of breadth of
the work that's out there. I also "just know" stuff from my own areas of
interest and study. That said, I don't have as strong of an idea of
what's good and what's relevant beyond what I can grok from citation
counts. And after one year (or less!), that's clearly not very much
information.
As a result, I'm looking for suggestions or recommendations from anybody
on interesting, useful, important, or otherwise noteworthy scholarly
papers on or about Wikipedia or other Wikimedia projects published in
the last year. Feel free to leave a comment, email mako@atdot.cc, or
edit this page.
Since I have started to use Org-mode, I though it was missing something to
have appointment locations on a map. Of course, it's easy to get a LOCATION
property from an entry, and then browse-url on Google Maps.
But it is too easy for me, so once again I said: challenge accepted! I will
bring Google Maps into Emacs!
After several hours of work, the google-maps-el project shows a map!
It fully implements the Google Static Maps API and the
Google Maps Geocoding API.
You can type M-x google-maps and type some place to see it marked on map. Of
course you can do much more, as seen in the screen shot above.
I've also completed all of this with a small org-location-google-maps which
simply show a Google Maps' map for the location of an event in Org mode by
pressing C-c M-l in an Org buffer or in the Org agenda.
From time to time I find myself using
git-svn with
projects using subversion, this is all nice and fine but it takes quite some
time to do the ''initial import'' if you are doing it over a remote transport
such as ssh+svn.
One trick to speed things up is to use rsync to copy
the svn repo locally and then ''git-svn'' it from your harddisk. The idea is
originally documented at the allegro
wiki
For example a typical sourceforge project will be done like
this:
DESTDIR=/your/dest PROJECTNAME=vde PROJECTURL=https://$PROJECTNAME.svn.sourceforge.net/svnroot/$PROJECTNAME SVN_COPY=$(mktemp -d) rsync -c -av $PROJECTNAME.svn.sourceforge.net::svn/$PROJECTNAME/'*' $SVN_COPY mkdir -p $DESTDIR cd $DESTDIR git svn init file://$SVN_COPY --rewrite-root=$PROJECTURL --stdlayout git svn fetch # ... git svn imports the repo ... sed -i 's@url =.*@url = $PROJECTURL' .git/config rm -rf $SVN_COPYThe important bit is to remember to update the
url key after
updating otherwise subsequent commits will go to your rsync-ed repo and not the
original one!
I ve written a simple application which will automatically extract media from CDs and DVDs when they are inserted into the drive attached to my server. This makes it easy for me to compile all of my media in one place and access it anytime I like. The application uses the modern udisks API, formerly known as DeviceKit-disks, and I wrote it in part to learn get some experience working with udisks (which, it turns out, is rather nice indeed).
Naturally, I wanted to grant this application the privileges necessary to mount, unmount and eject removable media. The server is headless, and the application runs as a daemon, so this would require explicit configuration. udisks uses PolicyKit for authorization, so I expected this to be very simple to do. In fact, it is very simple, but finding out exactly how to do it wasn t quite so easy.
The Internet is full of web pages which recommend editing /etc/PolicyKit/PolicyKit.conf. As far as I can tell, nothing pays attention to this file anymore, and all of these instructions have been rendered meaningless. My system was also full of tools like polkit-auth, from the apparently-obsolete policykit package, which kept their configuration in some other ignored place, i.e. /var/lib/PolicyKit. It seems the configuration system has been through a revolution or two recently.
In Ubuntu 10.04, the right place to configure these things seems to be /var/lib/polkit-1/localauthority, and this is documented in pklocalauthority(8). Authorization can be tested using pkcheck(1), and the default policy can be examined using pkaction(1).
I solved my problem by creating a file in /var/lib/polkit-1/localauthority/50-local.d with a .pkla extension with the following contents:
[Access to removable media for the media group]
Identity=unix-group:media
Action=org.freedesktop.udisks.drive-eject;org.freedesktop.udisks.filesystem-mount
ResultAny=yes
This took effect immediately and did exactly what I needed. I lost quite some time trying to figure out why the other methods weren t working, so perhaps this post will save the next person a bit of time. It may also inspire some gratitude for the infrastructure which makes all of this work automatically for more typical usage scenarios, so that most people don t need to worry about any of this.
Along the way, I whipped up a patch to add a --eject option to the handy udisks(1) tool, which made it easier for me to test along the way.
I've grown tired of the firefox/iceweasel memory hog for a couple of reasons:
Neil Williams recently commented on the lack of smart-bookmarks in Firefox/Iceweasel/Chromium and since the post doesn t accept comments, counter-post FTW.
So previously I introduced the idea of my image-tagging system. There seemed to be at least a little interest. So here's a brief introduction and real update.
There is a command line tool, itag, which will index the UserComment field from a hierarchy of JPG files. (This field is compatible with digikam, by happy accident).
Additionally there are a pair of GUI tools, both very nasty in terms of code quality and extensibility:
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.
$ sudo adduser newbie $ ssh localhost -l newbie $ whoami newbieThen 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" >> ~/.bashrcThis 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 ~/ProjectsHere 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 -rThat 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/barAnd 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
Up to now I had a single blog hosted on ouaza.com, I used to blog in French and in English on many topics, even though free software and Debian was the main topic. Sometimes I avoided blogging on something because it would not really match the expectations of my readers (and of the various planets syndicating my blog). And I have always been annoyed by the fact that English readers were second-class on my blog because everything was configured in French.
So I decided to fix this once for all, I have created two new blogs in addition to ouaza.com. The latter is now my private blog (in French) with everything that is not free software related. And free software will be the topic of my 2 new blogs :
The GNOME Foundation released their conference speaker guidelines today. This is an important step not just in helping speakers know what's acceptable, but also in helping audience members understand in advance what the community is likely to find objectionable and ensure that they can feel comfortable in raising concerns.Next.