The Ubuntu Global Bug Jam is just around the corner, and once again, the kind folks at the Linux Emporium have kindly offered the use of their offices to the Ubuntu UK team. Last time, we focused on bugs, and this time it s only slightly different. Instead of it being a Bug Jam it s just going to be a Jam . There will be people on hand to talk to about Bug Triaging, packaging, translating (and I hope we ll get the whole of Ubuntu translated into English by the end of the Jam), and anything else you can think of. So, if you re interested in helping make Ubuntu a better distro, and live in (or can travel to) the Birmingham Area in the UK, then you re welcome to come along. The Jam is on the 2nd-4th October, and we ll be around on all three days. If you need more info, please feel free to email me on <mez AT ubuntu DOT com>. Last year we had a great time, with refreshments (including beer) provided. Juggling penguins, and one person sleeping underneath the conference room table overnight. Hopefully we ll also have the live Video Streams up and running again for anyone who can t make it (or other Ubuntu Jams) to join in with! You can also find some blog posts about our last bug jam

If you ever wanted to support an open-source project but you are not a programmer, here's one (of many possible) ways to help: The Miro project (Internet TV / Video and Audio Podcast application for Linux, Windows, and Mac OS X) is seeking for pledges/donations that will be used to add subtitles support in Miro. To quote from the announcement:

We re hoping to build real subtitle support into Miro in the next couple months, but we need your help! So we ve started a Kickstarter project to raise $1,000 to develop this feature for Miro on all three platforms: Windows, Mac, and Linux. Can you pledge to help make it happen? One of the great things about the Kickstarter model is that unless we can reach $1,000, your pledge won t be charged.
[...]
(if you live in the United States, donations are tax deductible we are a 501c3 non-profit)

There are 11 days left to make a pledge.

please help out with gdebi - a history of why Short summary: if you are looking for a way to help Debian become a bit more user friendly, please take care of gdebi in Debian. I'm rather upset. So beware, rant ahead. The reason dates back to the beginning of this afternoon, when a friend of mine, GNU/Linux newbie, mailed me asking for help with his brand new (to my astonishment) Debian Lenny installation running the GNOME desktop environment. The request was simple and common to a lot of our users: "how can I see videos on YouTube and use Skype"? Surely, the first (brief) explanation I gave was why those pieces of software are not in Debian, because they are pieces of evil proprietary software. Fair enough, usual song and dance, that gets the message through. But than, given that I personally care about releasing a completely free operating system, but not necessarily in inhibiting the usage of any non-free bits of software, I wanted to actually solve my friend's problem. Regarding flashplugin-nonfree, unfortunately it is not in Lenny. Two solutions to that: either point him to http://www.backports.org and explain how to use them from synaptic (not particularly hard). Or give him a direct download link of the .deb coming from backports.org. It turns out that for Skype there is no such choice. Once there used to be an APT-gettable repository for their debs, but it seems to have vanished (or else I can't find it). Still, there is a page from which you can download Lenny .debs. Given that for Skype the choice is forced, I was tempted to simply reply to him with a couple of link to .debs and solve his problem rather easily. But wait. Once he has the two debs, how can he install them? First attempt: "just click on them in Nautilus" (my hope: "synaptic will do the right thing ). No way, it will fire up file-roller. Second attempt: "install gdebi (using synaptic), right-click on the deb, and choose ;open with gdebi'". Seems to work, but no, you will be hit by bug #493352. (BTW, the reason why you need the right click is bug #421096). What makes me upset is that both bugs were there way before the Lenny release and slipped through our QA knots. Nobody's fault, the maintainer apparently lost interest (or time) package and stopped caring about it. Happens all the time. But damn!, we will lose a user the moment I tell him "you know, you need to open up a root terminal". A few remarks: this rant is not about "we should invite user to use non-free software"; it is not even about "we should be more attractive to newbies"; it is just about the pity of losing users like this, dumbly. Concluding:

1. dear lazyweb, any idea of what can I suggest to my friend to install the debs I'll point him to, without needing the knowledge of a terminal?
2. gdebi in Ubuntu is ahead of lots of version wrt Debian, I'm convinced that it fixes most outstanding issues (given that upstream author is a Canonical employee). If you have some free Debian-time slots (I currently don't) and you care about newbie-accessibility, please consider helping out with gdebi. He needs you.

EOR (end of rant)

drivel is now in a good enough state that I can use it myself - or at least, that's what I'm hoping. It's installed on at least one of my machines and I've already had to fix a glitch or two, so here goes.

Sadly, livejournal users may well be disappointed by 3.0.0 - the XMLRPC for the meta properties of LJ posts is broken and I've so far failed to get a usable response from the lj_dev community. Faced with choosing no LJ support or LJ support without metatags, I'm going with no metatags, at least for now. Hopefully once the code is in use, someone will help find a fix.

Blogger has gained Subject support, MT has tags, WP and Serendipity are OK (albeit with some issues) and advogato is working too.

The string freeze ends at the end of this month (10 days) so there's time for a few more fixes but current SVN is likely to be what gets released as 3.0.0.

The main changes are behind the scenes - dropping old libraries like gtksourceview1.0 and libglade, moving from libsoup2.2 to libsoup2.4, dropping libgnome and libgnomeui, using GtkBuilder and dropping curl (not needed with libsoup2.4). There is little new functionality, 3.0.0 is primarily focused on keeping drivel working through the upcoming GTK transitions so that there's time to deal with other issues. Still been a huge amount of work though - one very good reason for NOT adding new functionality if it brings in a new library dependency. There is still code to be removed from 3.0.0 and I'm intent on ensuring that new functionality comes from using the existing libraries in better ways.

.... and then it crashed after posting . . .

this weekend while giving a bit of TLC to the php packages, i thought i'd finally get around to tackling #490023 and similar bugs, which meant learning about how to use the triggers feature provided by dpkg. unfortunately documentation for this feature was in fairly short supply, and after extensive searching (and by extensive searching i mean typing "dpkg triggers howto" into a google search) i had a couple short manpages (dpkg-trigger(1) and deb-triggers(5)) and an overly verbose and possibly out of date /usr/share/doc/dpkg/triggers.txt.gz. none of these documents really gave a clear "big-picture" for how to get going either. so, as is often the case, i got distracted from my intended task and ended up on a little side-project putting together a nice howto/tutorial for how to integrate dpkg triggers into a package. note that there may be misunderstandings or inaccuracies in the document, as it's based on an afternoon's worth of hacking and q&a directed at #debian-dpkg (thanks to Guillem and Rapha l for fielding those questions). so if i'm off on anything, please feel free to let me know! to get started:

git clone http://git.debian.org/git/users/seanius/dpkg-triggers-example.git

and for those who are too lazy even for that, the README follows: The debian package triggertest This package is a dead-simple "triggers in a nutshell". It shows a few different ways that triggers can be used in practice, to hopefully cover most of the general use cases for triggers. The purpose of triggers Triggers are used to ensure that during the standard package-management process certain operations always run, but not more than necessary. For example:

• during an upgrade many packages might provide updated texinfo(5) documentation, and triggers are used to ensure that update-info-dir(8) is run without having to be run several unnecessary times from the maintainer scripts of package in question.
• if a system has both apache2 and PHP's apache2 engine installed, apache2 will need to be restarted whenever new php extensions are installed or removed. Without triggers it would be very disruptive (and inefficient) to explicitly stop and start apache by each PHP extension.
• update-initramfs(8) should be run once and only once after kernels are updated or certain other packages are installed/upgraded that would want to have a new initramfs generated.
• other expensive operations that are desirable to be aggregated and consolidated during installs/upgrades, such as update-texmf(8) or scrollkeeper-update.

How triggers work in a nutshell Trigger-using packages can be classified in two behavioral categories:

• Consumers: packages which declare triggers and thus can be "triggered"
• Producers: packages which activate triggers (explicitly or implicitly)

When a consumer is triggered, its postinst script is run with the arguments:

postinst triggered "<trigger1> ... <triggerN>"

i.e. $2 contains an iterable list of activated triggers. Note that if a consumer is going to be normally configured (i.e. it is also being updated), then no triggering may occur and thus the standard control flow of the maintainer scripts should still take care to handle this. A "trigger" is declared for the consumer by shipping a file in DEBIAN/triggers (in the case of debhelper based packages, ./debian/consumer-package.triggers will JDTRT). Useful RTFM: deb-triggers(5). Example:

interest /path/to/a/directory
interest my-second-trigger

This declares that the package in question is interested in two triggers. The first trigger has a leading path separator in its name, which instructs dpkg that any filesystem modifications underneath this directory by other packages should cause the respective consumer(s) to be triggered. The second name is completely arbitrary (and also global, so you should probably pick something reasonably specific and identifiable), and will only cause a trigger to be activated when a producer

1. ships its own triggers file with a corresponding "activate my-second-trigger", or
2. invokes the trigger explicitly in a maintainer script by calling "dpkg-trigger my-second-trigger".

Another perhaps useful RTFM: dpkg-trigger(1). Examples contained in this source package This source package produces a single "consumer" package and a number of different "producer" packages. The consumer is triggered in various ways, such as:

• Filesystem updates to a given directory from any other package
• "activate foo" from a producer's triggers file
• Activation from a producer's explicit call to dpkg-triggers

In this case the triggers correspond to an "update-foo" and "update-bar" command, which do nothing other than echo to the console that they are being run. In practice they'd correspond to updating some kind of database or restarting a daemon. More information For more information about triggers, see /usr/share/doc/dpkg/triggers.txt.gz, which will make a lot more sense having a working example like this package as reference. Especially useful is "Transition hints for existing packages", which can be used if you need to gracefully handle migrating in support for triggers across other packages not directly under your control. Corrections, suggestions, etc Are appreciated and should be sent to the author, below. -- Sean Finney seanius@debian.org Sat, 19 Sep 2009 15:57:48 +0200

i've been maintaining v86d for a year, and is has to stop now.
no, not because its bad to maintain it, it's just I've sold the last piece of hardware (my Thinkpad Z61m) it was useful on.
my X300 has an Intel card and KMS, my iBook does not know what 86 is ;)

Currently, the package has two bugs:
#505977 segfault
never could reproduce this one, reporter has nvidia gpu...
#525415 CFLAGS setting includes random kernel headers
this is easy to fix and I will do so in my orhpan upload (or provide a patch)

So if someone has the hardware and need of v86d, please tell me and take over the package.

PS: Christoph, do it NOW! :)

One of my professional duties in my past ten years was monitoring systems. Even my diploma thesis was dedicated to distributed monitoring (altough my professor sucked badly). Apart from a few custom-programmed scripts to analyze special situations (e.g. proxy clusters) I used tools that fellow administrators will find familiar: Nagios and Cacti. And another less famous text-configuration-based monitoring tool called Cricket. That worked well somehow but Cricket was hard to learn for my coworkers and Cacti seems unreliable and fundamentally broken in terms of SNMP checking. Besides why do I have to set up availability checking in Nagios and set up checking of the same parameters in another software to draw graphs? Just recently I came across an open-source software I hadn t heard of before: Zabbix. And although it has a few rough edges it seems way more professional than other common tools (the commercial tools I saw are even worse than the open-source variants). I tried it and after a lot of reading and trying it looks like it has a good potential to replace Nagios and Cacti. So I thought I d sum up my personal experiences with all of these tools. Nagios. Their makers claim that it s the industry-standard in IT infrastructure monitoring . Honestly it s a great tool but considering how many years it has been existing it barely evolved. During my diploma thesis I wrote an alternative software that I called MrNetwork that dealt with flaws that Nagios hasn t even fixed today. Still Nagios is a tool I have used for many years and it is very reliable. Advantages:

• open source
• large community
• many powerful plugins (and own plugins are easy to create: just write a program that prints a one-line string and set a certain return code)
• easy-to-use web frontend
• debugging plugins is moderately simple.
  
• many thought-out features like host groups or notification options that make your life easier
  
• dependencies (so that you don t get 100 alerts if a router between the Nagios server and other servers went down)
  
• nagvis plugin with a great interactive editor that draws nice management-suitable graphs (although I found the ndo2db interface hard to set up at first and a little flaky)
  

Annoyances:

• The focus is on availability checking you don t get fancy graphs on the values that are monitored (e.g how the CPU load was over time). So you ll need a second tool and set up the same checks there just to get graphs. But availability percentages are computed automatically.
• Textual configuration that has so many different settings that you need to look up the parameters often. A web-based configuration would probably be better (and is available as an add-on but I haven t tested it).
• Third-party plugins are often very badly programmed and barely documented that it appeared easier to reinvent the wheel. ( Look, ma, I can has plugins. )
• Some views on the web interface are not very obvious (e.g. clicking on the title of a host group gives a nice view of all hosts with all services).
• Many plugins don t have corresponding configuration entries so you have to find out how they work and write configuration entries yourself (and those which are preconfigured take some archeology to find out which parameters they expect). This is a huge time-waster for beginners. And in your services configuration you have to verify your checks configuration to understand the meaning of each parameter. Or do you remember what check_http 80!john!doe!10!30!body is supposed to check?
• Every set of parameters of a certain plugin requires a distinct configuration entry. The plugins have dozens of configuration switches that you may need one day. Want to set a timeout on HTTP checks? Write another check configuration. Want to check for a certain string in the HTTP response? Write another check configuration. And so on.
• Most checks are run from the Nagios server itself (the NRPE plugin to do the checks on the respective remote systems somehow refused to work properly here) which is suboptimal and puts a lot of load on the server.
• By default every alert triggers a notification. So if you can t define proper dependencies (e.g. if you want to check your web server in all 30 supported languages and there is some logical error) then you will get spammed with alerts.

Cricket. As Nagios does not support plotting graphs of the monitored values I was in need of another piece of software. Basically Cricket is a frontend to RRD (which stores data in a rotating/round-robin file that keeps data of the last X minutes/hours/days). It has a textual configuration that takes a lot of getting used to. It s main principle is inheritance of settings they call it configuration tree . Which means you have a master DEFAULTS file that contains general settings like how to query SNMP. In a subdirectory you define a certain class of devices that you want to monitor e.g. routers (the DEFAULTS are inherited to this level). Within the routers directory you can just define a list of routers you want to monitor. All settings are inherited from above (parent directories). It s more a geek tool for shell lovers. Advantages:

• very quick to monitor a large set of similar devices once the general device class is defined
• simple web interface
• very reliable
• can monitor SNMP values (it does this very well) or execute external scripts thus can be easily extended
• flexible graphing you can sum up values of two graphs into a new graph (aka mtargets multiple targets)
• different check frequencies can be configured for different subtrees through cron (by default values are collected every 5 minutes this can be set as low as one minute if needed)

Annoyances:

• the textual configuration is error-prone (leading to funny Perl errors that can be hard to debug)
• users may expect to see all parameters of a certain device instead of all devices having a certain parameters ( Give me the statistics of router42 instead of Let s see the temperature of all routers we have. )
• customizing the graphs (drawn by RRD tool) isn t trivial
• Frequency of checks is by default 5 minutes. Before RRD can draw the first value of a graph it needs three values. So you ll be waiting 15 minutes before you see any results.
• RRD rounds data by default. So the yearly graph doesn t show the peaks that the daily graphs do. (This can be fixed by not graphing the average values but the maximum values.) Long-time archiving of graphed data is not possible without throwing away the RRD files and manually customizing them. Changing the monitoring frequency (aka heartbeat ) is not possible either without throwing away the data and starting from scratch either.
• No proper built-in alerting in case certain thresholds are exceeded.

Cacti. Another frontend to RRD and a pretty sophisticated one. Nearly everything is configured through its web interface. And the result is beautiful. It s not entirely reliable though and SNMP support (at least in version 0.8.7b) is a big fail. I like Cacti for its user interface is much better than Cactis but it s less reliable and flexible. Advantages:

• Beautiful and (for most features) simple web interface. Nice features like graphs that can be zoomed using Javascript.
• Fine-grained permissions system. So a certain user may get read-only access to a certain subtree.
• The tree where graphs are placed can be configured freely so you get exactly the view you want.

Disadvantages:

• Doesn t hide the RRD magic very well. The user is easily confused by templates, data sources and the like.
• Graphing sometimes just stops working for no reason or values are missing although the server isn t overloaded and other software doesn t show such outages. According to a quick search on the lazyweb I m not the only one with such effects.
• Setting up many systems means a lot of clicking in the web interface. Setting up new kinds of checks (aka templates ) means even more clicking and is very error-prone.
• The quality of some third-party templates I tested was pretty bad. Creating new templates is tedious, error-prone, frustrating and close to black magic. Nothing for the casual user at least.
• Doesn t handle SNMP correctly (this is the biggest fail in my opinion and makes it unusable here). Although it knows how to query indexes (e.g. ifDescr to get the names of your network interfaces) it just seems to stored fixed OIDs. So once the SNMP tables change the order or number of items (which isn t unusual) then suddenly other parameters get graphed.
• Frequency of checks is by default 5 minutes. Increasing the frequency leads to missing data and wrong results.
• As it uses RRD and needs 3 valid values you won t see that your monitoring fails until you wait 3 5=15 minutes. Not suitable for impatient non-smokers like me.
• Debugging failed checks is close to impossible. If a check fails then I find myself clicking around randomly trying to find typos because the alternative is digging around in database entries.
• The web interface is sometimes confusing. A refresh of SNMP tables is done by clicking a unmeaning green circle icon. Adding new items to a list is done by clicking an inconspicious Add link that doesn t even look like a link.
• Another UI confusion: graphs are created from the devices view. But they are deleted from the graph management view.
• No alerting in case certain thresholds are exceeded. Another tool like Nagios would still be needed to notify you.
• Can t sum up multiple targets so monitoring failover clusters doesn t work well.
• RRD averages data when putting daily values into weekly values, weekly into monthly and monthly into yearly. So the yearly graph doesn t show the peaks that the daily graphs do. (This can be fixed by not graphing the average values but the maximum values.) Long-time archiving of detailed graphed data is not possible (RRD). Changing the monitoring frequency (aka heartbeat ) is not possible either without throwing away the data and startin from scratch.

Zenoss. People pointed me to Zenoss which is supposed to offer the same functionality as other monitoring systems but is much more integrated. So this short list is more a quick one-day-experimental expression than a thorough analysis. But in the end much of the fuss is just marketing. Advantages:

• Beautiful web interface
• Nice gimmicks like google maps integration to show you where your servers are down worldwide. Only makes sense when monitoring networks with several/many remote locations.
• Can partly discover parameters of systems automatically. That works for static routes (although I wonder why the heck I want to monitor static routes), file systems and network interfaces. On the other hand processes can t be discovered automatically and have to be set up manually.
• Does not come with a specific agent but plays rather well with plain old SNMP.
• Can monitor Windows through native WMI.
• Large fanbase.

Annoyances:

• Web interface feels slow (Zope is bloated)
• Opaque operation. It does not tell what s actually going on. You can add monitoring and check back later if anything worked they way you want.
• Questionable reliability. In a test here I was monitoring a running process. The process was said to be down and suddenly went to up after a while although nothing had changed on the system.
• Just one dashboard. Several dashboards similar to Zabbix screens would be nice.
• Configuration and data is spread across MySQL, the internal Zope database storage and RRD files on disk.
• The dependency graph is a nice Flash-based applet displaying how the systems are connected. But it does not show any details about the systems aside from whether they are up or down. And clicking on a host does not take you anywhere but center on the system. Beautiful but it could do so much more than just look beautiful.
• I dislike the way that things are configured. The context menu with the down arrow needs to be used. I d prefer simple add or delete actions instead of navigating the menu all the time. Looks like Javascript is used wrongly here.
• Limited open-source version. Full version needs to be paid for.

Zabbix. This is the tool I have been evaluating for the past two weeks and currently I m moving all checks away from Nagios and Cacti and put it into Zabbix. So the following list is more a first impression instead of a year-long experience. (I m using Zabbix 1.6.5 here. Debian Lenny s 1.4 version lacked some interesting features like proper SNMP handling so I backported the newer version to Lenny.) Zabbix seems very close to the perfect monitoring system I had always dreamt of. I would have designed it differently in some aspects though. Advantages:

• Availability Monitoring (like Nagios) and graphing (like Cacti) is combined into one tool.
• Highly configurable. User John may just get an SMS for problems of high severity during the weekend and on weekdays get a Jabber message. Even automatic actions like restarting services can be set up.
• The notifications actually help the person who gets the message. Low disk space on /var on web5 with an additional comment is pretty helpful even when sent via SMS.
• Very performant. The remote agent gathers the information on each system.
• Fast web interface.
• Sophisticated monitoring of web sites. Zabbix can follow a path of simulated mouse clicks on a web site and check for functionality and response time.
• Real-time graphs. Values are by default collected every 30 seconds. You quickly see where you are going.
• Permissions system. Certain users can be limited to certain views.
• Gathered data is stored in a database (MySQL, PostgreSQL, SQLite) instead of an RRD file. Storage periods (aka history ) can be configured freely. Backup up the database is all there is to be done.
• Agent for remote checks simply works (and is available on Debian Lenny) and can even call scripts or shell one-liners to gather information. The agent can gather a lot of information locally and send it to the Zabbix master server. Works on several operating systems and even on Windows (just set up monitoring of Windows services and processes successfully).
• Templates (that can even link to further templates) save time in setting up many checks.
• Graphs (plots of values over time) can be customized like which items are plotted and in what way. Even pie charts are possible.
• Even the parameters that don t get an explicit graph can be graphed at any time. E.g. the agent has tracked the CPU load on a system that you never cared about then you can graph that with one mouse-click.
• Screens and slide shows can be used for high-level views (aka dashboards ) or to be displayed on a big geeky display. They can combine textual display of the status as well as clocks, ad-hoc graphs or predefined graphs.
• Very flexible trigger expressions. For example you can tell a trigger to fire if the average system load over the last 15 minutes is above a certain value. As all measured parameters are stored in a backend database you can use all kinds of mathemical expressions. Like firing a trigger if the average number of running processes during the last half hour is above 50. All other software I tested just has access to the last value gathered.
• Customized alerting is simple through shell-based alert scripts.
• Remote monitoring made easy by using a Zabbix proxy.
• Paid support and paid custom programming available. But the software is completely open-sourced.
• 320 page PDF manual with screenshots and nice references. (Although I d personally prefer an online help. Currently the ? link within the web interface just points to the PDF that you can download.)

Annoyances:

• A lot of mouse moving and clicking is required to set up things. For example setting up an alert if the free space on a disk on a certain server is getting too low then you need to set up hosts, items, triggers and actions. Some of the clicking seems redundant. E.g. I didn t find a way to create triggers automtically for a set of checks. If I monitor how full the /home partition is then I d like to set a threshold in the same configuration step.
• Takes a little patience understanding the concepts although they make sense after half a day.
• The web interface is crammed full of features. For casual users it s confusing to navigate.
• The map editor is close to unusable. You can put icons and connections into the graph but have to define the X and Y coordinated manually. This feature is nice but desperately needs a good interactive map editor like nagvis uses.
• Does not detect the available assets in a monitored server automatically. Imagine that you want to monitor the space on all disk partitions on a system. You will have to copy over or create the check items manually or define all possible checks in a template and disable those you don t need. Cacti handles that better by offering you a list of partitions to monitor. Zenoss can do that partly. The zabbix agent should be able to handle such a service discover automatically. (The built-in Discovery feature rather seems to detect new servers in a given network range automatically. But that s something different.)

See also: Ben Rockwood s blog Further similar software I didn test thoroughly: Hyperic and Opsview (I ll surely update this blog post while I learn more about Zabbix.) All of the above tools are great. I m not meaning to say that Zenoss is total crap for example. The differences are subtle. And whether a piece of software suits your needs really depends on your expectations. I love that all this software is available as open-source. And a totally unscientific but fun analysis of the community is counting the number of active people in the respective channels on the Freenode IRC network:

• #nagios: 133 users
• #cacti: 58 users
• #cricket: 2 users
• #zenoss: 54 users
• #zabbix: 61 users

Either Nagios has the largest fanbase or perhaps that means that the majority of people needs help with it.

Over on Planet Ubuntu there is a VRMS meme winding down. Usually I tend to think web log aggregator memes are an abomination, however, this one is a little more interesting, especially if Debian folk pick it up. It seems like many Planet Ubuntu posters require some non-free stuff, examples include; graphics and other drivers/firmware, Flash (Gnash/Swfdec aren't there yet), Sun Java (despite OpenJDK), RAR 3.0 archives, LHZ archives (despite jlha), Microsoft fonts (despite ttf-liberation), icon themes, ICC profiles, mind mapping, support for codec DLLs from Windows, VirtualBox drivers for Windows, the Opera web browser, games and other things. For Debian users, the popcon information pretty much confirms the above issues. Some other stuff Debian users use that isn't in Debian include; patented codecs, skype, acroread, the non-free version of VirtualBox and more. Next, lets get in on the getting your meme on part. On my Dell Inspiron 6400 laptop I have following Debian non-free/contrib stuff installed; firmware-iwlwifi, gcc-doc, gcc-doc-base, gcc-4.3-doc, autoconf-doc, gdb-doc, make-doc. On my OpenMoko FreeRunner phone I have nothing installed from Debian non-free/contrib. My wireless router and ADSL modem don't run Debian. The wireless router is a MIPS-based Netgear WGR614L (that is marketed as supporting DD-WRT, OpenWRT and Tomato) so I could conceivably install OpenWRT etc or Debian on it, but I haven't gotten around to that yet. The ADSL modem is a MIPS-based Siemens SpeedStream 4200, but it looks like that would require a significant amount of effort to get running FLOSS. Lets ponder my laptop freeness a bit more. The docs are all FSF-free, but not DFSG-free. It appears they are not DFSG-free because the FSF will not allow 28 words of FSF/GNU advertising to be removed (I'm not sure if Debian or the FSF is more pedantic). I'm not aware of any DFSG-free alternatives to them and I don't particularly care about the restrictions. My wireless card is an Intel 3945ABG mini PCI card that requires the kernel to upload the iwlwifi firmware before it works. Intel refuse to release firmware source code under a free license, citing FCC requirements. I'm not aware of any free firmware (or firmware reverse engineering efforts) for this device so the only alternative is to use wired Ethernet or buy another wireless card. Ethernet wires everywhere would be very inconvenient, so I've been thinking about trying to replace the card or laptop as soon as I am able. Since Atheros has released GPLv2 firmware for its AR9170 802.11n USB chipset I'll probably get something released by Atheros. I wonder why the FCC didn't prevent Atheros from releasing modifiable firmware, perhaps Intel will change their position too. So, what other software is on my laptop apart from Debian? Lets see, nothing on the HD apart from GRUB 2, /boot containing a Linux image/initrd from Debian and the LUKS partition containing swap and the Debian ext3 rootfs. Coreboot laptop support seems to be in the very early stages so I have no alternative to the supplied Dell BIOS at the moment. There is also the CPU microcode and other firmware installed in the various devices on the system, at least the HD, Ethernet, Bluetooth, GPU, DVD drive etc. have some kind of firmware in them. Some of this firmware is updatable using software from the Dell Linux repositories. Lets ponder my phone freeness a bit more. On it I have two copies of the u-boot bootloader (one in the protected NOR flash), u-boot is free. The NAND flash has an old Qt Extended Improved (QTEI) install that I need to copy stuff off and wipe. I also have a 4GB microSD card containing QTEI, Debian, FDOM and SHR. Now that QtMoko has brought QTEI to Debian packages I can probably ditch the QTEI install. I read that OM2009 is being merged into SHR so I can get rid of FDOM. That leaves SHR and Debian/QtMoko (nothing non-free). IIRC SHR does contain some firmware for devices that the OpenMoko FreeRunner doesn't contain, but that will get removed as Linux upstream moves more and more of that into linux-firmware.git. Nothing more on the main flash or microSD storage, so what else? The OpenMoko contains lots of hardware, but the main problematic devices here are the AR6000 Wi-Fi chip and the TI Calypso GSM device. The AR6000 is an issue because the firmware embedded in the chip is non-free and FullMAC so it is hard to add new features like AP mode or improve the connection quality/etc. In addition the firmware currently on the device is a development version of a 2.0 version (1.x was apparently broken) and further development does not seem to be happening yet. Since Atheros GPLed the AR9170 firmware I idly wonder if they could be convinced to release the source and GPL the AR6000 firmware. Perhaps a life-size gold statue of RMS would help there. The GSM device is problematic because of various bugs in the firmware. It apparently is an ARM chip with Nucleos, so perhaps uCLinux or something could be ported to it or written for it. There has been at least one discussion about hacking the GSM firmware (thar be dragons). Searching for some keywords extracted from the end of the first mail in that thread lead to some interesting results indeed. Lets ponder my network freeness a bit more. I should allocate some time to investigate putting Debian on my wireless router and ADSL modem. These generally just work except the ADSL modem reboots itself a lot during the summer. The just-works status of these devices means that messing with them is problematic in case I brick them (luckily I have a spare for the ADSL modem though). I presume OpenWRT and similar have replacements for all the software on my wireless router, drivers may be an issue though. I use gmail for reading email lists, mainly because of intertia, cheapness and because the interface has no GUI FLOSS peers yet (sup-mail exists for console use). TangoGPS, OpenStreetMap and other tools are slowly replacing my use of Google Maps, although I imagine routing will remain an issue for many years yet. One of the tech groups I'm involved in uses Plesk as a hosting control panel, mainly out of intertia, I'm not familiar with any FLOSS replacement though. Some of the upstream FLOSS projects I'm involved with use sourceforge as a hosting platform. There is a certain level of lock-in with SF.net, most of the data is easily exportable though. Lets ponder my software freeness in comparison to Planet Ubuntu posters. I have no freeness issues with drivers at the moment, however firmware seems likely to have freeness issues for a long time to come. I've avoided the need for the Adobe Flash Player by using swfdec and clive for downloading videos for some sites. swfdec works OK for some sites, some that I care about where it doesn't work and clive cannot download video include Vimeo, abc.net.au and sbs.com.au. For Vimeo you can download raw video if you have a login, but I do not, bugmenot is unreliable and Vimeo doesn't seem to be accepting new registrations. SBS I watch on television and ABC I get no reception so I just don't watch it. Java isn't an issue now that OpenJDK exists. I sometimes need to extract RAR 3.0 archives, which I do by copying the files to a friend's Windows machine or using a RAR extractor website. There is no free implementation of a RAR 3.0 extractor yet. I seem to remember that there is source code for a non-free extractor so presumably a clean-room documentation and reimplementation effort could fix this. I don't encounter LHZ files, but jlha-utils is available for if I do. I feel no need to install Microsoft fonts since the Liberation fonts and DejaVu meet my general font needs and Debian contains fonts covering all the scripts of Unicode (except for about half the huge amount of Han characters). In my music collection, only the Voxware audio codec and DigiTrakker MDL files are not supported by Rhythmbox, but I don't really miss those few tracks. I rarely have audio/video codec issues with video from the Internet. I don't have a use for Opera. Thanks in part to the efforts of the Debian games team, games from Debian main (such as warzone2100) satisfy my gaming needs. I just don't use Skype. Overall, I'm generally happy with my level of software freedom. My main strategy for preventing regressions in my software freedom is to just avoid doing things that require non-free software. The most problematic FLOSS issues for me are Flash support (adoption of the HTML5 video tag will resolve this for me), RAR 3.0 support and firmware. Please feel free to contact me with any comments or questions. Happy Software Freedom Day everyone!

I was really happy a few years back, when Martin announced he'd start working on netconf. Not just because I agreed with his assessment that ifupdown needed replacement; also because I had been thinking about a good way to implement such a thing, and had been planning to start writing 'soon'. With Martin's announcement, I made a few suggestions to give him some input, and then put my plans away I had more important things to take care of, anyway. Unfortunately, netconf did not manage to reach the ambitious goals that Martin set out, mainly due to lack of contributors. I wanted to help out; I really did. But Martin's choice of python to implement a 'prototype' which then had to be reimplemented in C or C++ didn't get me very thrilled. Not just because I have a severe dislike of python; also because implementing something twice is, in my humble opinion, not quite the best way to do something like this. But hey, who am I, if I don't put my code out there. Never the less, I tried helping. I really did. During debconf8 at Mar del Plata, I approached Martin with the suggestion that I start reimplementing those bits that were unlikely to change anymore in C, as a first step toward something that could be in the base system. Unfortunately, that didn't happen. After trying for about two weeks, I just gave up. I thought I could read python code and reimplement that so that it would work the same way, but I couldn't. I thought I could implement python modules in C without knowing python, but as it turns out that's a laughable idea. For several months then, I didn't think about it anymore. In March of this year, however, I got a little bored. And what does one do when they get bored? Right, you find something to do. I my case, that was 'figure out how bison works'. I'd of course known about parser generators for quite a while, but just never had the time to dive in deep and figure out how they work. When I needed to do a config file for nbd, I instead hand-wrote my parser and used a lexer from libglib. But I wanted to learn how to do things properly, so I sat down. Long story short, when I had to choose something somewhat more complex to implement, I thought 'how about a hypothetical config file for a network configuration utility', and I started implementing that. It turned out to be fun, so I didn't stop after I knew enough about bison. And just last week, for the first time I successfully used it to bring up my wired interface using DHCP -- and bring it down again. It can also already manage static interfaces through netlink, though it isn't quite able to the equivalent of 'ip addr flush' yet. Fun. The system is quite flexible. It has a plugin interface (which needed some refinement that I did using some help on IRC just today), which should allow developers to implement extra functionality by just dropping a shared object in the right directory. In fact, I'm working on the wireless support (hence my blog post of last week) as a plugin. Obviously the code isn't remotely ready yet. The wireless code has a long way to go. The firewall module needs to be started. It will probably crash and burn if put to the test. But even so, it already has one feature that ifupdown, in its 10 years of existence, never acquired: it will not try to DHCP off an interface if it finds out that there is no cable connected to it unless you wrote a configuration that asks you to do so. I wanted things to be as simple as possible, and therefore the minimal valid configuration file that will do something useful is the following:

That's right, it's empty. This will cause the system to bring up the 'lo' interface at bootup, and do nothing else. If you say 'ifup eth0', where eth0 is a valid and existing interface, it will first check whether there is a link, and if so, DHCP off of it. There's much to do still, but I have now reached a point where I feel the system is ready to meet all challenges it should be able to meet (or so I hope), and where it might be nice if interested people check it out. The code is in a git repository that's mirrored on git.debian.org, github.com, and my own git.grep.be. The latter is my --mirror repository, but is not available for cloning to anyone else. If you're interested in checking it out, you may want to start with doc/tech.txt, and/or examples/ipcfg.cfg. I updated the former just yesterday, so it's quite up-to-date. On the other hand, while the latter shows the direction I would like the system to take, the code is a far cry from implementing everything shown there, and it has been a while since I last checked that file out, so the comments in there are, in some cases, somewhat outdated. But that's good, because I want to keep the file as a reference of the goals that I originally had, before I'd written this whole corpus of code, so that I can go back at some undefined point in the future and fix things. Comments are (more than) welcome.

During one of my project I need to interact with Java cryptographic extension. Some data has been encrypted using PBEWithMD5AndDES. I need to access it from OCaml. I take a look at available cryptographic extension in the Debian project for OCaml: cryptgps and cryptokit. I choose cryptokit, because its author is well known: Xavier Leroy. This article was my starting point. Of course, I keep in mind that the reference is there and that there is a good article covering it. Here is the result in OCaml:

 let decrypt passphrase salt ?(iterationCount=41) str =
   let key, iv =
     let rec hash_aux iter str =
       if iter > 0 then
         (* Rehash string *)
         hash_aux
           (iter - 1)
           (hash_string
              (Hash.md5 ())
              str)
       else
         (* Key = first 8 bytes of the MD5 hash *)
         String.sub str 0 8,
         (* IV = last 8 bytes of the MD5 hash *)
         String.sub str 8 8
     in
       (* Hash n times combination of passphrase and salt,
           return key and iv 
         *)
       hash_aux
         iterationCount
         (passphrase ^ salt)
   in
     transform_string
        (Cipher.des
           ~pad:Padding.length
           ~iv:iv
           key
           Cipher.Decrypt)
       str

The only missing information was the pad algorithm to use (Padding.length). For this piece of information, I need to browse the RSA documentation and test a little bit. Rewriting PBEWithMD5andDES is quite straightforward with cryptokit and OCaml. It takes 25 lines with C# and OCaml (only counting LoC, no comment, no empty constructor or declaration in C#). I was thinking that this task will require 2 or 3 days, but it has been done in 4 hours... Many thanks to cryptokit ;-)