Petter Reinholdtsen

One thing that annoys me with Debian and Linux distributions in general, is that there is a great package management system with the ability to automatically install software packages by downloading them from the distribution mirrors, but no way to get it to automatically install the packages I need to use the hardware I plug into my machine. Even if the package to use it is easily available from the Linux distribution. When I plug in a LEGO Mindstorms NXT, it could suggest to automatically install the python-nxt, nbc and t2n packages I need to talk to it. When I plug in a Yubikey, it could propose the yubikey-personalization package. The information required to do this is available, but no-one have pulled all the pieces together.

Some years ago, I proposed to use the discover subsystem to implement this. The idea is fairly simple:

• Add a desktop entry in /usr/share/autostart/ pointing to a program starting when a user log in.
• Set this program up to listen for kernel events emitted when new hardware is inserted into the computer.
• When new hardware is inserted, look up the hardware ID in a database mapping to packages, and take note of any non-installed packages.
• Show a message to the user proposing to install the discovered package, and make it easy to install it.

I am not sure what the best way to implement this is, but my initial idea was to use dbus events to discover new hardware, the discover database to find packages and PackageKit to install packages.

Yesterday, I found time to try to implement this idea, and the draft package is now checked into the Debian Edu subversion repository. In the process, I updated the discover-data package to map the USB ids of LEGO Mindstorms and Yubikey devices to the relevant packages in Debian, and uploaded a new version 2.2013.01.09 to unstable. I also discovered that the current discover package in Debian no longer discovered any USB devices, because /proc/bus/usb/devices is no longer present. I ported it to use libusb as a fall back option to get it working. The fixed package version 2.1.2-6 is now in experimental (didn't upload it to unstable because of the freeze).

With this prototype in place, I can insert my Yubikey, and get this desktop notification to show up (only once, the first time it is inserted):

For this prototype to be really useful, some way to automatically install the proposed packages by pressing the "Please install program(s)" button should to be implemented.

If this idea seem useful to you, and you want to help make it happen, please help me update the discover-data database with mappings from hardware to Debian packages. Check if 'discover-pkginstall -l' list the package you would like to have installed when a given hardware device is inserted into your computer, and report bugs using reportbug if it isn't. Or, if you know of a better way to provide such mapping, please let me know.

This prototype need more work, and there are several questions that should be considered before it is ready for production use. Is dbus the correct way to detect new hardware? At the moment I look for HAL dbus events on the system bus, because that is the events I could see on my Debian Squeeze KDE desktop. Are there better events to use? How should the user be notified? Is the desktop notification mechanism the best option, or should the background daemon raise a popup instead? How should packages be installed? When should they not be installed?

If you want to help getting such feature implemented in Debian, please send me an email. :)

During Christmas, I have worked a bit on the Debian support for LEGO Mindstorm NXT. My son and I have played a bit with my NXT set, and I discovered I had to build all the tools myself because none were already in Debian Squeeze. If Debian support for LEGO is something you care about, please join me on the IRC channel #debian-lego (server irc.debian.org). There is a lot that could be done to improve the Debian support for LEGO designers. For example both CAD software and Mindstorm compilers are missing. :)

Update 2012-01-03: A project page including links to Lego related packages is now available.

Her er noen lenker til tekster jeg har satt pris på å lese den siste måneden.

• 2012-12-07 Myter og FUD om fri programvare av min venn Christer Gundersen som kommenterer noen av de påstandene som er spredt via Computerworld Norge de siste månedene.
• BankID er et opplegg der utsteder (dvs. banken eller dens leverandør) sitter på alt som trengs for å bruke BankID, men har lovet å ikke bruke den unntatt på oppdrag fra deg. Det er greit nok for banktjenester, der banken allerede har full kontroll over resultatet, men problematisk når det gjelder tilgang til helseopplysninger og avtaleinngåelse med andre enn banken. Jeg håper protestene brer om seg.
  • 2012-12-11 BankID blottlegger helseopplysninger
  • 2012-12-07 - Helseopplysningene ikke sikre med Bank-ID
  • 2012-12-07 Påpeker alvorlige, men kjente utfordringer er den offisielle holdningen til de som lager BankID.
  • 2012-12-08 NTNU Researcher Warns against Security of Bank ID Password
• 2012-12-11 Norske elever er dårligst i Europa på algebra
• 2012-12-11 Realfagsdødaren
• 2012-12-21 - Noen må bli skuffet - Politiet i Bergen forteller hvor lavt de prioriterer hverdagskriminalitet.
• 2012-05-03 Kripos-ansatt dømt for snoking for venn - viser hvor svak reaksjonen blir når politiet misbruker innsamlet informasjon. En forvarsel på konsekvensene av nasjonal brev- og besøkskontroll - ofte kalt Datalagringsdirektivet.
• 2012-12-14 Å smøre en forskjell - om ensomhet og jul.
• 2012-12-18 Én krise av gangen, takk!
• 2012-12-17 NAV: Et mangehodet monster
• 2011-01-12 Pasienter uten vern - forteller litt om hvordan Norsk Pasientregister og andre helseregister raderer bort pasienters privatsfære.
• 2012-12-19 Hvorfor er barnefamilier fattige?
• 2012-12-25 Den skjulte minoriteten – konservative kristne i Norge - kronikk av Bjørn Stærk fra aftenposten
• 2009-05-04 Folkebiblioteket 2.0 - Min venn Sturle om opphavsrett og Internett, i debatt med Olav Torvund.

Og et godt nytt år til dere alle!

I was happy to discover a few days ago that the Skolelinux / Debian Edu project also this year received a Christmas present from Another Agency in Trondheim. NOK 1000,- showed up on our donation account December 24th. I want to express our thanks for this very welcome present. As the Debian Edu / Skolelinux project is very short on funding these days, and thus lack the money to do regular developer gatherings, this donation was most welcome. One developer gathering cost around NOK 15 000,-, so we need quite a lot more to keep the development pace we want. Thus, I hope their example this year is followed by many others. :)

The public list of donors can be found on the donation page for the project, which also contain instructions if you want to donate to the project.

Let me start by wishing you all marry Christmas and a happy new year! I hope next year will prove to be a good year.

Bitcoin, the digital decentralised "currency" that allow people to transfer bitcoins between each other with minimal overhead, is a very interesting experiment. And as I wrote a few days ago, the bitcoin situation in Debian is about to improve a bit. The new debian source package (version 0.7.2-2) was uploaded yesterday, and is waiting in the NEW queue for one of the ftpmasters to approve the new bitcoin-qt package name.

And thanks to the great work of Jonas and the rest of the bitcoin team in Debian, you can easily test the package in Debian Squeeze using the following steps to get a set of working packages:

git clone git://git.debian.org/git/collab-maint/bitcoin
cd bitcoin
DEB_MAINTAINER_MODE=1 DEB_BUILD_OPTIONS=noupnp fakeroot debian/rules clean
DEB_BUILD_OPTIONS=noupnp git-buildpackage --git-ignore-new

You might have to install some build dependencies as well. The list of commands should give you two packages, bitcoind and bitcoin-qt, ready for use in a Squeeze environment. Note that the client will download the complete set of bitcoin "blocks", which need around 5.6 GiB of data on my machine at the moment. Make sure your ~/.bitcoin/ directory have lots of spare room if you want to download all the blocks. The client will warn if the disk is getting full, so there is not really a problem if you got too little room, but you will not be able to get all the features out of the client.

As usual, if you use bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

It has been a while since I wrote about bitcoin, the decentralised peer-to-peer based crypto-currency, and the reason is simply that I have been busy elsewhere. But two days ago, I started looking at the state of bitcoin in Debian again to try to recover my old bitcoin wallet. The package is now maintained by a team of people, and the grunt work had already been done by this team. We owe a huge thank you to all these team members. :) But I was sad to discover that the bitcoin client is missing in Wheezy. It is only available in Sid (and an outdated client from backports). The client had several RC bugs registered in BTS blocking it from entering testing. To try to help the team and improve the situation, I spent some time providing patches and triaging the bug reports. I also had a look at the bitcoin package available from Matt Corallo in a PPA for Ubuntu, and moved the useful pieces from that version into the Debian package.

After checking with the main package maintainer Jonas Smedegaard on IRC, I pushed several patches into the collab-maint git repository to improve the package. It now contains fixes for the RC issues (not from me, but fixed by Scott Howard), build rules for a Qt GUI client package, konqueror support for the bitcoin: URI and bash completion setup. As I work on Debian Squeeze, I also created a patch to backport the latest version. Jonas is going to look at it and try to integrate it into the git repository before uploading a new version to unstable.

I would very much like bitcoin to succeed, to get rid of the centralized control currently exercised in the monetary system. I find it completely unacceptable that the USA government is collecting transaction data for almost all international money transfers (most are done in USD and transaction logs shipped to the spooks), and that the major credit card companies can block legal money transactions to Wikileaks. But for bitcoin to succeed, more people need to use bitcoins, and more people need to accept bitcoins when they sell products and services. Improving the bitcoin support in Debian is a small step in the right direction, but not enough. Unfortunately the user experience when browsing the web and wanting to pay with bitcoin is still not very good. The bitcoin: URI is a step in the right direction, but need to work in most or every browser in use. Also the bitcoin-qt client is too heavy to fire up to do a quick transaction. I believe there are other clients available, but have not tested them.

My experiment with bitcoins showed that at least some of my readers use bitcoin. I received 20.15 BTC so far on the address I provided in my blog two years ago, as can be seen on the blockexplorer service. Thank you everyone for your donation. The blockexplorer service demonstrates quite well that bitcoin is not quite anonymous and untracked. :) I wonder if the number of users have gone up since then. If you use bitcoin and want to show your support of my activity, please send Bitcoin donations to the same address as last time, 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

Jeg ble overrasket over å se at Piratpartiet i Aftenposten er referert på følgende:

Når det gjelder retten til opphavsrett for kulturproduktene, mener Piratpartiet av levetid + 14 år er tilfredsstillende.

Det betyr en vernetid langt ut over det kommersielle livet til de aller fleste opphavsrettsbeskyttede verker, og er i strid med slik i hvert fall jeg har tolket punkt 5 i kjerneprogrammet til Piratpartiet:

5: Åndsverk og patenter: tilbake til start

forslag:

14 års opphavsrett og ingen programvarepatenter

grunn:

Den første loven om opphavsrett spesifiserte 14 års vernetid. Senere har mediabransjens lobbyister stadig presset loven mot lengre vern, nå er det 70 år etter forfatters død. Dette gjør at mange verk glemmes og går tapt, noe som er skadelig for norsk språk og kultur. Vi til tilbake til start: 14 års vernetid. Patentloven sier klart at dataprogrammer ikke kan patenteres. Likevel klarer patentadvokater å lure gjennom programvarepatenter. Slike patenter gjør dingsene våre dyrere og kan i enkelte tilfelle stoppe dem helt.

Den opprinnelige opphavsretten var på 14 år totalt, ikke 14 år etter opphavspersonens død. Jeg tenkte først dette kanskje var feilsitering fra Aftenposten, men jeg finner samme påstand i en bloggpost fra Geir Aaslid på Piratpartietes offisielle nettsider. Der skriver han følgende:

Hva vi gjør med opphavsretten er mer komplisert fordi den omfavner så mange bransjer, med ulike behov. Enhver reform er en forbedring men det er nærliggende å anta at en opphavsrett på levetid + 14 år er fullt ut tilfredstillende for musikk, film, litteratur og spill.

Det virker dermed på meg som om Piratpartiet allerede har gjort retrett fra sin beundringsverdige holdning om at det holdt med 14 års total vernetid, til sin nye som tar utgangspunkt i levetiden til opphavspersonen. Jeg håper det baserer seg på en misforståelse hos piratlederen som blir korrigert tilbake til 14 års total vernetid før partiet stiller til valg.

Hvis du lurer på hvilke problemer lang vernetid bringer med seg, anbefaler jeg å lese boken Free Culture av Lawrence Lessig. Jeg og en liten gruppe andre er igang med å oversette boken til bokmål og tar gjerne imot hjelp med oversettelse og korrekturlesing.

Oppdatering 2012-12-20: Oppdaget at bloggposten til Geir Aaslid er endret siden i går, og nå inneholder følgende avsnitt i stedet for det jeg siterte over:

Hva vi gjør med opphavsretten er mer komplisert fordi den omfavner så mange bransjer, med ulike behov. Enhver reform er en forbedring men det er nærliggende å anta at en opphavsrett lik levetiden, evt + 14 år er fullt ut tilfredstillende for mange skapere av musikk, film, litteratur og spill. Det er for det meste de store forlagene som er imot enhver reform.

I tillegg har det dukket opp en setning nederst "Dette dokumentet er et utkast til svar på et angrep på Piratpartiet fra Gramo. Det endrer seg derfor over tid og den endelige versjonen er det som blir publisert på Hardware.no", som tyder på at originalformuleringen ikke var veloverveid og sitatet i Aftenposten kanskje var basert på en misforståelse.

A few days ago I came across a blog post from Joey Hess describing ledger and hledger, a text based system for double-entry accounting. I found it interesting, as I am involved with several organizations where accounting is an issue, and I have not really become too friendly with the different web based systems we use. I find it hard to find what I look for in the menus and even harder try to get sensible data out of the systems. Ledger seem different. The accounting data is kept in text files that can be stored in a version control system, and there are at least five different implementations able to read the format. An example entry look like this, and is simple enough that it will be trivial to generate entries based on CVS files fetched from the bank:

2004-05-27 Book Store
      Expenses:Books                 $20.00
      Liabilities:Visa

The concept seemed interesting enough for me to check it out and look for others using it. I found blog posts from Christine Spang, Pete Keen, Andrew Cantino and Ronald Ip describing how they use it, as well as a post from Bradley M. Kuhn at the Software Freedom Conservancy. All seemed like good recommendations fitting my need.

The ledger package is available in Debian Squeeze, while the hledger package only is available in Debian Sid. As I use Squeeze, ledger seemed the best choice to get started.

To get some real data to test on, I wrote a web scraper for LODO, the accounting system used by the NUUG association, and started to play with the data set. I'm not really deeply into accounting, but I am able to get a simple balance and accounting status for example using the "ledger balance" command. But I will have to gather more experience before I know if the ledger way is a good fit for the organisations I am involved in.

For noen dager siden omfavnet nok en kommune NUUGs FiksGataMi. Med 61 kommuner som lenker til FiksGataMi fra sine hjemmesider er «markedsandelen» 14% (av 429 kommuner). Siden siste oppdatering i november har kommunene Re og Vågsøy kommet til og slår følge med kommunene Askim, Askøy, Audnedal, Aure, Balestrand, Bærum, Eide, Farsund, Flekkefjord, Folldal, Gran, Grue, Hadsel, Halden, Halsa, Hamar, Hobøl, Holtålen, Hægebostad, Høyanger, Kongsberg, Kristiansund, Kvinesdal, Kviteseid, Levanger, Lindesnes, Luster, Lyngdal, Løten, Mandal, Marnardal, Moss, Namsos, Nissedal, Nordreisa, Randaberg, Rindal, Sel, Sirdal, Skiptvet, Sortland, Spydeberg, Stange, Stjørdal, Stord, Søgne, Sør-Odal, Tolga, Trysil, Tynset, Tysvær, Ullensvang Herad, Utsira, Vennesla, Verdal, Vågan, Vågå, Våler og Åseral. Oppdatert liste er tilgjengelig fra NUUGs wiki. Kartet er dog ikke oppdatert med de siste kommunene.

Kanskje du bør høre med din kommune om de vil bli mer aktive brukere av FiksGataMi? Se en tidligere bloggpost med tips om hvordan det kan gjøres.

I snitt rapporteres det nå via FiksGataMi ca. 60 meldinger fra innbyggerne i uka om feil på offentlig infrastruktur.

Where I work at the University of Oslo, we use the Cerebrum user administration system to maintain users, groups, DNS, DHCP, etc. I've known since the system was written that the server is providing an XML-RPC API, but I have never spent time to try to figure out how to use it, as we always use the bofh command line client at work. Until today. I want to script the updating of DNS and DHCP to make it easier to set up virtual machines. Here are a few notes on how to use it with Python.

I started by looking at the source of the Java bofh client, to figure out how it connected to the API server. I also googled for python examples on how to use XML-RPC, and found a simple example in the XML-RPC howto.

This simple example code show how to connect, get the list of commands (as a JSON dump), and how to get the information about the user currently logged in:

#!/usr/bin/env python
import getpass
import xmlrpclib
server_url = 'https://cerebrum-uio.uio.no:8000';
username = getpass.getuser()
password = getpass.getpass()
server = xmlrpclib.Server(server_url);
#print server.get_commands(sessionid)
sessionid = server.login(username, password)
print server.run_command(sessionid, "user_info", username)
result = server.logout(sessionid)
print result

Armed with this knowledge I can now move forward and script the DNS and DHCP updates I wanted to do.