I ve been having some cooling problems with my Thinkpad recently. It s an old model T41p which is outside the service period so IBM/Lenovo won t help me (at least not unless I give them more money). If I run it for a few minutes at maximum CPU when the ambient temperature is about 20C then it gets to 90C, apparently 93C is the temperature at which it turns itself off, so obviously I need to do something to keep it cool. On the really hot days of summer my air-conditioners can t keep any part of my house below 30C, so on such days I can t do any compiles on my Thinkpad or watch videos. My Thinkpad seems to idle at a temperature that is about 35C higher than the ambient temperature. At this rate the system could get close to it s maximum temperature on a 45C day by just idling! Not that I plan to have a warm Thinkpad on my lap if I ever happen to be outside on such a hot day. I suspect that a large part of the problem is the dust that has accumulated inside the machine. I asked about this on the LUV mailing list and Andrew Chalmers suggested The Chaos Manor review of taking a Thinkpad T41p apart [1]. The Chaos Manor guy wanted to replace his CPU with a faster one so he had to get access to all the same bits. I followed the instructions until I got to the stage of prying the heatsink off the video chip. I figured that I will never be able to attach it as well as it is currently attached so I will get different cooling problems if I go any further. Taking it apart to that degree was a moderate amount of work, getting the keyboard bezel off was the most difficult part, and taking the palm-rest off required removing bits of plastic that were stuck in place to cover screw holes which will probably fall off in a week or two. Probably everyone who owns a T41p that they regularly use has a similar problem to me as all such machines have been out of support long enough to have accumulated a lot of dust. So I recommend that other T41p owners not disassemble their machine as much as I did, but instead go for my plan B which is to blow compressed air through the CPU cooling system. Doing this merely requires removing the keyboard. One tip that I have heard is that you should hold the fan in place when blowing compressed air as the pressure of the air may spin the fan fast enough to generate enough electricity to damage the motherboard or damage it s bearings. But you might want to wait until I ve got my Thinkpad done before you blow compressed air through yours, it could very well be destroyed. The other option is to try and use software to control the temperature. Patricia Fraser suggested controlling the fan speed [2]. I did some experiments and found that increasing the fan speed dramatically slowed the increase in the temperature. A 10 minute build is almost certain to bring the temperature to dangerous levels in a default configuration, but it seems that if I set the fan to maximum speed before starting the build then I can mitigate this problem. Most programs that I work on will compile in significantly less than 10 minutes. Another possibility that occurred to me is that of limiting the speed of the system. It seems that ACPI has support for reducing the CPU frequency when the temperature rises too much, but Matthew Garrett has pointed out that this effectively increases the amount of energy used (and heat dissipated) for any given quantity of work [3]. So what I want to do is to cause the CPU to idle periodically when it gets too hot. I ve been idly considering writing a program that uses SIGSTOP and SIGCONT to control the operation of programs such as make, or writing a program that creates a new pty (like script) and pauses the output whenever the CPU gets too hot. Of course the easy option would be to figure out how to set the threshold temperature where the CPU speed is limited. Which is made slightly more complicated by my choice of kernel 2.6.30 for Ext4 support. Now the kernel doesn t work with my acpid and I m starting to get forced into an upgrade to Debian/Testing. Does anyone have any ideas?

• [1] http://www.chaosmanorreviews.com/open_archives/sl_20070205.php
• [2] http://www.thinkwiki.org/wiki/How_to_control_fan_speed
• [3] http://mjg59.livejournal.com/88608.html

Our co-op registers domain names for others. Like most registrars, we now cannot register Chinese (.cn) domains. There s a bit of background discussion on WebmasterWorld. While it s always disappointing to offer fewer services, I don t think we ve ever registered a .cn domain and especially not for anyone in China. Most of the .cn domains we see are in spam. If this tighter control makes any dent in the amount of spam and scam sites, that s probably a good thing. I ve not felt any significant reduction in spam since this change, though. I suspect the scammers have just moved to another top-level domain with a long-time idle government, while a few legitimate users of cn domains will also be punished along with the scammers. Will we ever shut out the spammers? Even if we kick them out of all domains, they ll find some way of using IP addresses or something. The price of freedom is eternal vigilance.

Funnily, I just discovered while digging in a user issue of my pet package geneweb, that "start-stop-daemon" has a "--umask" switch, designed exactly for doing what I currently do with a wrapper script in the package..:-) After all, it's only 3.5 years that it's sitting here waiting for me..:-) Looks like I'll have to do an upload for geneweb which I'll do happily as it will drop what I consider a quite bad hack.

"We are currently working on getting the code shipped out, we have your shipping address on file and will ship the code out as soon as it is ready, this will be by the end of this month."

2/10, must try harder. Even ignoring the fact that it's taking the best part of two months to get from shipping binaries to shipping source, it'll be interesting to see which version of the firmware the source release corresponds to given that the 1.1.0 update included a new kernel.

Speaking of firmware updates - as shipped, the nook was a disaster. The firmware update improved things greatly, but I'm still stuck with cases where books render with the last couple of words in a page left out, and the order of books in the local content library is now based on last modification time rather than, say, author name. The continuing lack of any way to implement catagorisation or provide worthwhile metadata means that it's frustrating having to remember which order the books in a series go in. The fact that there's even a distinction between content you've obtained from B&N and content you've obtained from elsewhere is mindboggling. You need to explicitly switch between the two, which means that collections are broken up if you've had the audacity to buy some books from B&N and some books from elsewhere.

Having now spent a while travelling with the nook, it's clear that it's still not an especially effective example of its type. If my Sony hadn't suffered an unfortunate accident, I'd be using it instead. The nook's hardware is significantly better and as a platform it's got much more potential, but it just doesn't do a terribly good job at its core role - reading books. It'll get better with time, but if you're in the market for something that actually works today then go elsewhere.

There's other little things that are upsetting at a conceptual level. The 1.0.0 firmware will flash unsigned firmware, which is useful[1] but also an obvious wtf. The filesystem is full of scripts that are world writable and executed as root. There's a libGLES, but the coverflow implementation appears to be handled entirely in software. There's a general feeling that the platform's been put together by people who either don't know what they're doing, don't care about doing it properly or were working under sufficient time constraints that getting it right wasn't an option. I'm really not impressed.

[1] Especially given that the 1.1.0 firmware will happily flash the 1.0.0 firmware...

the ultimate text diffing helper I use Git not only for code, but also for text, my most common use case being co-authorship of scientific papers typeset in LaTeX. While reviewing other author changes, the usual line-by-line diff is often annoying since:

1. Paragraph re-formatting gets in the way (hello guys accustomed to compulsory Vim's gq or Emacs' M-q): it does not effect the final rendering, but it still hinders peer-review of changes.
2. Even in the simplest case of a single word change on a single line, it will take some time for your eyes to spot where, along the line, the actual change is.

Stuff like wdiff does help, but I've never looked at how to integrate it with Git, and I still find it a pain in the eyes due to the fancy ASCII arts used to denote additions and deletions (pain that I usually experience when looking at the output of debdiff). There are nice diffing GUIs or editor-integrated solutions out there, but what I've always dreamed of is a plain old cmdline geekism. Enter Git's --color-words, that can be passed to both show and diff commands. My favorite related Git aliases are as follows:

    [alias]
        wdiff = diff --color-words
        wshow = show --color-words

Here is a sample fancy output, yet very intuitive and console-based, of git show --color-words (text in red denotes deletions, text in green additions): Maybe not new to you, but it has been life-changing for me.

While I was under snow last week, the world saw a flurry of Koha company news. We found out that PTFS is to acquire LibLime and ByWater Solutions and BibLibre are partnering for the U.S. With the past ByWater Solutions and PTFS, Inc. partnering, it seems like four of the younger Koha companies (established 2005, 2007, 2008 and PTFS started with Koha in 2008 I think) are now linked together, so it s not entirely surprising that ByWater congratulates PTFS on the purchase of LibLime. What did surprise me is the impressed with PTFS s resources quote from Liblime owner Josh. Some librarians are asking What will the acquistion of Liblime mean to Koha libraries? but I m wondering what does this mean for the Koha project? Well, there s still our co-op (established 2002) and the other older private Koha companies (Calyx, Katipo and so on), as well as the rest of the younger ones, so I think there s still the motivation for a vendor-neutral non-profit group to host the project. Recent history has shown that it s too painful if any one private company hosts it. It ll be interesting to see how the recent private company deals help that work. If all goes well, a bright new day for Koha, as wizzyrea hopes. On another level, I m a bit disappointed that a theoretical Free and Open Source Software player (even if things like LibLime Enterprise Koha had muddied the water) has been sold to a mixed FOSS+proprietary player. I m almost cross with Liblime s owners for selling up, but I don t know if that s fair. Selling up is a fairly common exit move in private companies, so shouldn t I expect it? Do librarians expect it? Is this why some seem reluctant to buy from start-ups which are still independent? As you may know, TTLLP software.coop is in common ownership, so we can t really be bought. This is a self-defence or legacy-guaranteeing mechanism for our cooperative, where our assets are pledged to other common ownership cooperatives if our corporation dies. I think it also has the fringe benefit that we re a fairly safe home for things like trademarks. This unbuyability means that I feel I m watching the sales and cross-linking of our competitors from the sidelines, from a viewpoint more like Koha users than the other vendors, waiting for the dust to settle and the chips to fall where they may. Whatever happens there, software.coop will still be here. Unsurprisingly, there have been a couple of new entrants into Koha support, although the Liblime-controlled Koha project website doesn t show them yet and reportedly its new support company submission form has been broken for weeks, which is irritating. Interesting co-op-y things are happening in the wider library systems world, too, with Karen Coombs going to work for the OCLC library cooperative and Polaris Library Systems workers buying the company although I m not sure yet if they re becoming a worker co-op or merely employee-owned. I suspect many of these announcements are timed for #alamw10 which is a big US library conference. Has anyone seen more co-op or Koha announcements which I haven t spotted in the conference PR flood?

Quodlibet is a GTK+ audio library manager / player. In Debian, it makes up four binary packages: quodlibet, quodlibet-ext, exfalso, and quodlibet-plugins. It's big/popular enough to get a few bugs filed against it and for people to yell when things break, but not so big as to be overwhelming. Since the previous comaintainer has been inactive for some time, I've been thinking that it might be nice to have a comaintainer again. During my academic term at MIT or if I'm on vacation, I don't get to things as quickly as I should. The package has also gone through a period of inactive Debian maintainers and a period of inactive upstream maintainers, so it's accumulated a fair number of ignored bugs in the BTS. And in general, having others to fall back on is a good thing, as long as it doesn't lead to no one taking responsibility. So, here's a deal: I want a comaintainer. There's a catch, though: this person doesn't need to be already involved in Debian. In fact, I'd prefer it if she weren't. If you have a good grasp on the English language, enthusiasm for Debian, and a willingness to learn some technical skills, contact me, preferably via email, and let me know who you are. Quodlibet is written in python, but I'm explicitly not saying that you need to know python in order to help out. You'll gain the benefit of having someone willing to answer your questions and direct your efforts and an automatic sponsor for uploads you prepare. I can't say I have a ton of time to put into mentoring someone, but I'm willing to put in some, so hopefully such an arrangement will turn out well for all parties involved: you, me, upstream, and Debian.

In a comment on my post about (relatively) Cheap Net Access in Australia [1] sin from Romania said Somebody needs to whack the aussie ISP in the head with a cluebat. The prices that you pay are insane . In Eastern Europe you have optic fibers from Germany and other western European countries that carry vast amounts of data. As the demand for capacity increases it s not THAT difficult to lay more fibers. You also have competition between different companies that lay fiber. To get data to Australia you must lay cables under the sea, this is expensive and can t be done quickly. Therefore all international data transfers are expensive to cover the expense of laying the cables. I don t think that we have any real competition in the market for International connectivity from Australia either. Now the links between Europe and the US aren t cheap either, but I believe that there are economies of scale (as well as shorter distances) that make them significantly cheaper than the links to Australia. Also a good portion of the traffic that you generate as a customer of a European ISP will stay within Europe as there are heaps of good sites in Europe. The number of people living in Europe who speak English as their first language is more than twice that of Australia. The number of Europeans who communicate in English almost as fluently as the native speakers (such as about half the population of the Netherlands) is also quite significant. I expect that the amount of English-language material on the net that is published from the EU is more than three times greater than the quantity published from Australia. People who speak languages that have a more limited geographic spread (IE anything other than English, Spanish, French, and Portuguese) will have a higher portion of local traffic which is therefore cheaper for their ISP. So based on the relative population sizes we should expect to have Australians making a higher portion of their Internet bandwidth be expensive international data transfers than that of Europeans. Then of course there is the issue of server costs. Running servers in Australia is horribly expensive, while user access to the net is merely annoyingly expensive, the costs of hosting servers are significant and usually the offers have slower hardware and slower transfers (particularly to the important US and EU markets). My blog is hosted in Germany because the company that was offering me free hosting in Australia encouraged me to host it elsewhere due to the price. Also hosting in Germany gives me slightly lower ping times to the US and significantly lower ping times to Europe. As about half the readers of my blog are based in the US, a significant quantity of the readers are based in the EU, and Australia only contains a small portion of the readers the overall experience for readers of my blog is improved by having it hosted outside Australia. It would be better to have it hosted in the US (where most of my readers are located) but I was offered free hosting in the EU. It would be nice if there was a cheap and easy way of getting a mirror of my blog running in Australia with Geo-DNS so that people using Australian IP addresses would get a local server. Putting the static images on an Australian server would be trivial, setting up Geo-DNs would be painful and probably increase reliability issues later on but isn t insurmountable (I have root on both DNS servers). The Debian blog gives some basic information on how to setup GeoDNS [2]. Then I would need to set up a MySQL slave for Wordpress data and modify Wordpress to send it s writes to the master server which is probably impossible for me unless someone else has already written a Wordpress plugin for this, I m really not good at PHP programming. Another possibility would be one of the Wordpress cache plugins that maintain static files to avoid needless database lookups. Until/unless I do such things, every Australian reader of my web site (and those of my friends who do similar things to me regarding hosting) will slightly tilt the balance of Internet transfers in favor of expensive data from foreign servers instead of cheap content from local servers. Sometimes it just sucks to live on an island.

• [1] http://etbe.coker.com.au/2010/01/15/cheap-net-access-australia/
• [2] http://dsa.debian.org/dsablog/2009/06/Setting_up_GeoDNS_for_security.debian.org/

Two days ago, I posted about looking for a new netbook or notebook, and asked for people s advice. Since then, I ve done some investigation based on these suggestions. Rejected Candidates First, I ve outright rejected several options. The Thinkpad X100e was out, mainly because it doesn t compare favorably to the Acer 1810TZ. The X100e s battery life is worse than the 1810TZ, it is heaver, and has a single-core CPU. Secondly, the EeePC 1201N was ruled out. Again, its battery life was quite a bit worse than the 1801TZ, and also worse than my existing Eee 901. Finally, the EeePC was out because of its extremely slow performance. Remaining Candidates I took information from notebookcheck for models I was interested in, and those suggested in the comments at the earlier post. After reviewing them, I made a comparison chart showing issues that matter most to me. Candidates: Battery Life Let s start with battery life. The X200s presents an interesting picture here. In the 9-cell battery, we can expect over 15 hours of life in idle mode, and 7 hours when surfing the Internet over wifi. This was best in class performance for the idle and surf tests, but when under load it drops to one of the worst ad only 2.57 hours. This could correlate with what Lars Wirzenius commented, saying the X200s battery life is poor: obviously it is doing a lot of power management in software to achieve its runtimes, and if a default Linux installation isn t doing that power management, battery life could be poor. The other standard in terms of battery life was the Acer 1810TZ, with 12 hours runtime in idle usage and almost 6 when surfing the net with wifi: that s an hour longer than my Eee 901. It was also the best performer under full load of anything on my chart. Disappointing results were turned in by the HP 2530p. Even with a 9-cell battery, it couldn t match the 1810TZ s battery life. The Dell E4200, with its 6-cell battery, fared even worse though I should note notebookcheck hasn t tested the E4200, so those figures come from elsewhere. Candidates: Size and Weight Looking at weight, the X200s and E6200 turn in amazing weights at under 3 pounds for a 12 notebook. HP s 2530p is the heaviest in the group at 3.84 pounds with the 6-cell battery (the 9-cell will be heavier but I couldn t find specs on it). The 1810TZ checks in at 3.1 pounds, a bit more than half a pound heavier than my Eee 901. Considering size, the E4200 is the thinnest in the group at just 0.79 inches thick. The 2530p is also thin, but is one of the deepest. The Eee 901 is smallest in terms of length and depth, but it is the thickest of all. Candidates: Performance Here you can really see why I complain about the Eee 901 being slow. On the PCMark 05 test, it had a third of the performance of the 1810TZ. The best performer was the X200s, followed by HP s 2530p. In terms of hard disk speed, the E4200 was fastest due to its SSD (though I suspect these tests are not fully evaluating write performance). The SSD on the EeePC 901 didn t help it; it finished with less than half the speed of the E4200. Conclusions From this chart, it looks like there are only three really interesting models: the X200s with its top-of-the-line performance and display, the HP 2530p, and the 1810TZ with its stellar battery life. The disappointing battery life on the E4200 rules it out for me. The battery life on the HP 2530p is modiocre, but it has a touchpad. For the 1810TZ, my main concerns are size of screen and the fact that the screen is glossy. I am not at all a fan of glossy screens. For the HP 2530p, we ve had an HP 2510p in at work. Its size is virtually identical to the 2530p, and felt a bit bigger than I d like. It was also lighter than the 2530p, but still a bit heaver that I d like to see. But the 12 screen might be worth it. The X200s lacks a touchpad, which is a major annoyance in my book. I have reports of 7-hour battery life on it with the L9400 CPU under Ubuntu. Another person has reported 12 hours on Arch Linux using a power saving guide (which looks helpful in general as well). Considering size and weight, the X200s is lighter than the 1810TZ, though only by a little if using the 9-cell battery. It s very slightly bigger in every dimension than the 1810TZ, but perhaps not enough to influence the decision. What are your thoughts?

One thing everyone forgot to talk about the WebKitGTK+ hackfest was that master Dan Winship added basic Content-Encoding support to libsoup, and patched WebKitGTK+ to use it. If you are using a recent enough version of those you will finally be able to visit web sites that send gzipped content despite the browser saying it could not handle it, like the Internet Archive. This was one of those cases in which the web shows all of its potential to behave weirdly. The HTTP/1.1 RFC says that if an Accept-Encoding header is not present, the server MAY assume the client accepts any encoding, so we were having many sites send us gzip content even though we did not support it. We then started sending a header saying we support identity, and nothing else! . It turns out the web sucks, so many servers were not happy with a full header, and started giving us angry looks (slashdot, for instance, would not render correctly because it started sending encoded CSS files!). We then simplified the header we were sending, which made those servers happy again. Some sites, though, completely ignored our saying we didn t support anything except identity, and sent us gzipped content anyway. Most of these were misbehaving caches (this was the case for Wikipedia), so would work after you asked for a forced reload, which would ignore the cache, but some servers, such as the Internet Archive s didn t really want to talk about encodings - they only wanted to send gzip-encoded content. So, in the end, our only way out was implementing the damn encoding support, which finally happened during the hackfest. Take that, web!

OSLC-CM V1 is a proposed standard for REST APIs of bugtrackers, and in our seek for more interoperability in the bugtracker space, we ve been very interested in it. OSLC-CM is quite young and only so far implemented in proprietary tools (although elaborated in an open way) on the server side, and as we believe in FLOSS, we ve started trying to implement basics of server side plugins for a few bugtrackers.
In addition to a demo server that s simulating the behaviour of a bugtracker, we have started implementing a Mantis plugin and FusionForge and Codendi trackers add-ons (all PHP and based on Zend framework, see this project on picoforge). All are very basic, but we hope they will be the basis for future OSLC-CM compatible servers in these tools. At the same time we ve been experimenting with the code already published in Mylyn to support OSLC-CM on the client side. Not everything is public yet in Mylyn, as the elements that have been developped for some connectors of Tasktop to the proprietary tools are being ported to the open source code of Mylyn.
We have thus been able to use the Junit tests classes of Mylyn and tweak them in a way to connect to an instance of the demo server for Mantis (including handling some Basic auth), and be able to retrieve the first bugs descriptions Now that this works, we ll try and add some Java code (maybe reusing Mylyn client libs) to doc4 (being developped as part of Helios) in order to start linking doc4 and Mantis so that this can be used in the Helios platform. This may involve mixing code of XWiki and Mylyn hmmm well, we ll see. Next steps may be also to try and implement a connector in Python that might be used in tools like bts-link. Then whichever Python or Java client libraries we have, will allow us to use them inside FetchBugs4.me to connect and harvest bugs of OSLC-CM compliant bugtrackers eventually. Lots of interesting developments ahead. Stay tuned.

I've been using an iphone since late 2007 as my primary phone and so I've gotten quite a few contacts and SMS conversations stored on it. Now that Collabora has given me a nice and shiny N900, I wanted to move my contacts and conversations over, but this proved to be a bit more work than expected. Please note that the following procedure worked for me, I have tried to take reasonable steps to prevent anything breaking, but if something breaks, you get to keep both pieces. I am not responsible and this comes with absolutely no warranty. Take backups. What you need

• the addressbook and SMS SQLite databases. On my phone, they live in /var/mobile/Library/AddressBook and /var/mobile/Library/SMS.
• A copy of my iphone-contacts-convert script. It's written in Perl and should be reasonably easy to understand. Put it in the same directory as AddressBook.sqlitedb.
• A copy of my iphone-export-sms script. It's also written in Perl and should also be reasonably easy to understand. Put it in the same directory as sms.db.
• The smstools program you can get from this thread on talk.maemo.org.

The address book conversion script takes the SQLite database structure and converts that into a VCF file. It should be completely safe to run multiple times (it only does SELECT from the different tables in the contacts database, and you have made backups, haven't you?). If it dies with an "Unknown property", "Unknown label" or other error, you can poke it and see if you can work out what's wrong or drop me an email and I'll see if I can help you. Assuming it doesn't fall over, it will spit out a series of VCards, which you should store in a file, which you then to the N900 and open in the address book. Assuming you have less than 1000 contacts, they should now all be in your address book. If you have more, you need to split the file. A couple of known limitations:

• It doesn't handle some of the attributes, like job title, notes, department, display names, prefix and suffix. None of my contacts used those, so I just didn't care. Patches to change this accepted. Also, it doesn't handle custom attributes and birthdays. I intended to handle birthdays, but forgot and I have few enough contacts with birthdays that I just did it by hand.
• When it hits something it doesn't know how to handle, it stops and you need to add the relevant handle to the code. I think it is mostly clear, how to, but again, feel free to contact me with any problems.
• Only tested on firmware version 2.2. Yes, ancient, but it's what my iphone is running.
• If you have contacts that are organisations, they will come up with a blank full name. Just edit them on the N900 (pressing edit and then save immediately works fine) and they'll be automatically fixed.
• No picture support. This looked a bit involved, so I didn't do this bit. Should be possible with a bit of effort.

The procedure for exporting and importing SMS-es is a bit more involved. First, export the sms-es by running the perl script. It spits out a tab-separated file which you should copy to the N900 along with the smsimporter program from the smstools thread. Run ./smsimporter foo.csv and you should get all your SMS-es put into the conversation app. I ended up compiling my own smsimporter based on the 0.2.1 from the thread with the UUID patch too. Read the whole thread and it should be fairly clear.

So I previously mentioned I'd knocked up a simple automation tool, for deploying policies (read "scripts") from a central location to a number of distinct machines. There seemed to be a small amount of interest, so I've written it all up:

• slaughter - Perl System Administration & Automation tool

Why slaughter? I have no idea. Yesterday evening it made sense, somehow, on the basis it rhymed with auto - (auto as in automation). This morning it made less sense. But meh. This list of primitives has grown a little and the brief examples probably provide a little bit of flavour. In short you:

• Install the package upon a client you wish to manage.
• When "slaughter" is invoked it will fetch http://example.com/slaughter/default.policy
  • This file may include other policy files via "IncludePolicy" statements.
• Once all the named policies have been downloaded/expanded they'll be written to a local file.
• The local file will have Perl-fu wrapped around it such that the Slaughter::linux module is available
  • This is where the definitions for "FetchFile", "Mounts", etc are located.
• The local file will be executed then removed.

All in all its probably more complex than it needs to be, but I've managed to get interesting things primarily with these new built-in primitives and none of it is massively Debian, or even Linux, specific. ObSubject: Jaws

Merry Christmas! Happy New Year! Yeah, it's that time of year again, I am writing a blog post . As some of you have probably already noticed I managed to get Smuxi 0.7 released a few days ago. Almost all of my Xmas vacation I was hacking on Smuxi. This is the best Smuxi release ever (guaranteed!). The most notable features I implemented in the 0.7 release are: Twitter support, handling for high latency networks (UTMS, WLAN, busy DSL) and an improved IRC experience through tweaks such as splitting oversized messages and new context menus. This release also contains very nice contributions from David Paleino [2] and Cl ment Bourgeois. Both joined the hackfest during my Xmas vacation and made the hacking sessions on Smuxi even more fun. Thanks for that guys! Here you can find a full list of changes. As everbody likes screenshots and as screenshots say a thousand words, here they are: Quick Connect
Twitter
User Menu
Which direction will Smuxi head in after the 0.7 release? For the 0.8 release, I plan to focus on making the IRC support feature complete. That means we will get DCC, SSL, IPv6 and logging support. Nothing of that sounds very special but I am already investigating how Smuxi can be integrated with the promising new Zeitgeist project. I interviewed one of the developers for potential communication between Smuxi and Zeitgeist. Last but not least, I want to announce that I will be attending FOSDEM 2010 in Brussels. I also will give a talk about Smuxi there, scheduled on 2010-02-07 at 16:30. If you want to have a chat, a beer, do some GPG keysigning, or ask me any questions, I am available PS: If you want more updates than once per year, just follow me on Twitter

My mutt said this last night:

 894   + Jan 15 Archive Adminis (0,4K) ipcfg_0.1_amd64.changes ACCEPTED

This obviously means that if you wish to use it, you no longer need to go through git; you can just add experimental to sources.list and run 'apt-get install ipcfg'. A few notes, though:

• I missed a few build-dependencies, so it's only available on amd64 for now. Yes, I should use pbuilder more (I did for the 0.3 upload, which went in today).
• The documentation is somewhat lacking. I just found out that the documentation isn't actually installed in the binary package, so you have to download the source package (or check out the git repository). This will be fixed for the next release. The documentation also currently consists of a few .txt files rather than (a) proper man page(s). This will likely take some more time.
• ipcfg Conflicts:, Replaces: and Provides: ifupdown. This is because there is no proper virtual package name for it to conflict/replace/provide. I have filed a bug, #554194, against debian policy, to request it be made, but so far this is not yet finished (and indeed was somewhat dead during the period that I had no time to work on ipcfg). This may confuse some packages that really do depend on ifupdown.
• ifdown works, but not reliably so. This will be my next main point of focus.
• If you use the insserv automatic ordering system for initscripts, then you must either purge ifupdown or remove its initscript before installing ipcfg; otherwise, the availability of two initscripts that provide network configuration will confuse the hell out of insserv.

And in case you wonder why the hell I went from 0.1 to 0.3:

ipcfg (0.2) experimental; urgency=low
  * Rebuild without .git directory. D'oh.
 -- Wouter Verhelst <wouter>  Tue, 12 Jan 2010 17:43:09 +0100

srsly

As Dries Buytaert, the creator and head of development of Drupal, announced on Twitter, the new major (pre-)version of Drupal, namely Drupal 7 alpha 1 has been released! This was on the 9th birthday of Drupal.

This is great news and the release notes are mentioning some aspects why this is so:

Revamped User Interface
An incredible amount of work has gone into improving the user experience and administration interface. The new administration theme "Seven", the overlay module, the dashboard and the configurable shortcut bar, all lead to a much more user-friendly interface. In-place editing is enabled for blocks and nodes by default, so modifying the content of a site becomes much simpler.

Custom Fields
Drupal 7 bundles in the ability to add custom fields, similar in functionality to the Content Construction Kit (CCK) module. However, fields are no longer limited only to content types; they can be added to users, taxonomy terms, and other entities. Fields also have support for translations.

Image Handling
Drupal 7 brings native image handling to core. Image fields may be added to content, and have image styles applied to them, such as scaling, cropping, and other effects.
Update Manager
Building on Drupal 6's Update module, which keeps site administrators informed when new module and theme releases are available, the new Update Manger module can also install and upgrade modules and themes.

Front-end "under-the-hood" improvements
A new render API allows for highly granular theming, core template files have been revamped to provide more semantic markup, Drupal 7 now has built-in RDFa support, includes jQuery UI and a new AJAX framework, and a new core theme "Stark" which exposes Drupal's markup directly for those who want to dive in and start theming.

In addition, Drupal 7 has several major accessibility enhancements, making it the most accessible release of Drupal to date!

Back-end "under-the-hood" improvements
A revamped database layer resolving nearly all limitations in the Drupal 6 database layer, automated testing framework, new PHP stream-based file API that supports private and public files simultaneously, revamped node access system, new hooks for more flexible system interaction, an Entity API, a job queue API, and many, many, many more improvements.

Drupal 7 is also the most scalable release to date, with features such as built-in proxy server support, advanced caching techniques, and Content Delivery Network support for static files.

Alone the inclusion of CCK and Views are great news, whereas all PostgreSQL users will benefit from the new database layer under the hood. I've tested a pre-alpha development version some weeks ago and that Drupal 7 experience was already great. So, it would be nice to see Drupal 7 in Debian soon as well, but I guess a alpha 1 version might be too early to be packaged.

I've talked before about the minimal way in which I've been using a lot of the available automation tools. I tend to use them to carry out only a few operations:

• Fetch a file from a remote source.
  • If this has changed run some action.
• Ensure a package is installed.
  • If this is carried out run some action.
• Run a command on some simple criterion.
  • E.g. Every day at 11pm run a mirror.

In the pub I've had more than a few chats about how to parse a mini-language and carry these operations out, and what facilities other people use. It'd be almost trivial to come up with a mini-language, but the conclusion has always been that such mini-languages aren't expressive enough to give you the arbitrary flexibility some people would desire. (Nested conditionals and the ability to do things on a per-host, per-day, per-arch basis for example.) It struck me last night that you could instead cheat. Why not run scripting langues directly on your client nodes? Assume you could write your automation in Ruby or Perl and all you need to do is define a few additional primitives. For example:

#
#  /policies/default.policy - the file that all clients nodes poll.
#
#
#  Fetch the per-node policy if it exists.
#
FetchPolicy $hostname.policy ;
#
#  Ensure SSH is OK
#
FetchPolicy ssh-server.policy ;
#
#  Or explicitly specify the URL:
#
# FetchPolicy http://example.com/policies/ssh-server.policy ;
#
#  Finally a quick fetch of a remote file.
#
if ( FetchFile(
                Source => "/etc/motd",
                Dest => "/etc/motd",
                Owner => "root",
                Group => "root",
                Mode => "0644" ) )
 
    RunCommand( "id" );
 

This default policy attempts to include some other policies which are essentially perl files which have some additional "admin-esque" primitives. Such as "InstallPackage", "PurgePackage", and "FetchFile". FetchFile is the only one I've fully implemented, but given a server it will fetch http://server/prefix/files/$FILENAME - into a local file, and will setup the owner/gid/mode. If the fetch succeeded and contents differ from the current contents of the named file (or the current file doesn't exist) it will be moved into place and the function will return true. On the server side I just have a layout that makes sense:

.
 -- files
     -- etc
         -- motd
         -- motd.silver.my.flat
         -- motd.gold
 -- policies
     -- default.policy
     -- ssh-server.policy
     -- steve.policy

Here FetchFile has been implemented to first request /files/etc/motd.gold.my.flat, then /files/etc/motd.gold, and finally the global file /files/etc/motd. In short you don't want to be forced to write perl which would run things like this:

# install ssh
if ( -e "/etc/apt/sources.list" )
 
  # we're probably debian
  system( "apt-get update" );
  system( "apt-get install openssh-server" );
 

You just want to be able to say "Install Package foo", and rely upon the helper library / primitives being implemented correctly enough to be able to have that work. I'll probably stop there, but it has given me a fair amount to think about. Not least of which : What are the minimum required primitives to usefully automate client nodes? ObFilm: Moulin Rouge!

I am a big fan of thin and light notebooks. I ve been using the 9 EeePC 901 for awhile now, almost since it first came out. I initially loved it. The keyboard, while an obstacle, wasn t as much as I feared. The thing got insanely long battery life (5-6 hours or more typical), and was so small that my laptop bag is a DVD player bag . Now for the downsides. I am getting into a time where I m spending more time on the laptop, and I m starting to be far more acutely aware of them. #1 is performance. Let s face it: the 901 is just a slow machine all-around. The video performance isn t great, and I can watch the Thunderbird interface being drawn as it loads. But the real killer is the SSD storage. It is exceptionally slow, and gets in the way of multitasking in a serious way. (Syncing mail? Kiss performance in Firefox goodbye.) Problem #2 is the 1024 600 screen. This is becoming a serious inconvenience, as when you combine the need to do a lot of scrolling with slow scrolling performance, the result is unpleasant. Coding is pretty difficult at that size. #3 is the keyboard size. It is OK for light-duty work, but it is getting in the way for more serious work. So I m looking for a replacement. I m thinking something in the 10 to 12 range, thin and light, would be ideal. My main criteria are size, weight, performance, and compatibility with Debian. Durability is an added plus as it will be riding in my bicycle bag on a regular basis. This puts me in something of a grey area: there are netbooks in that range, and then there are machines like the Macbook Air (which may actually be a bit bigger than I d like). I have recently been hearing good things about the EeePC 1005PE (Atom N450) and the 1201N (N270 with Nvidia Ion). The 1201N seems to beat the 1005PE in terms of performance (especially video-related), but with far less battery life. I think I could live with the slower CPU, but the 1005PE still has only 1024 600 resolution, which would be a big problem for me. Lenovo has an IdeaPad U150 with an 11.6 1366 768 screen, and in the 12 size, they ve got various options, both Atom and Core 2 Duo. The X200 and X200s look interesting, but lack a touchpad. (The X200s appears to be their long-lasting-battery version.) The HP EliteBook 2530p also looks interesting; it has a touchpad, but is heavier and appears to have inferior battery life to the X200s. What ideas do people have?

WICD 1.7.0-1 just landed in Unstable! This is supposed to be the last 1.* release -- upstream will actively work on 2.0, and fix bugs on 1.7 only if they're serious enough. I will obviously support 1.7 until 2.0 comes out Enjoy!

News is slow this month on the FusionForge development front. We're all busy gathering all the things that we want to go into the next release, but there's no big news from the code. However, there is something of interest. You may have heard about the Coclico project, which is an initiative aiming at collaboration and convergence between several forge engines, most notably FusionForge, Codendi and Novaforge. That project was started last October, and it holds regular meetings with its members. The next meeting is scheduled for the 2nd of February in Paris, and we thought we could host an open meeting on the 3rd for non-Coclico members, a bit like the forge meeting we had last year (which is when FusionForge was officially born), but with an emphasis on what Coclico did so far. Since most of the FusionForge hackers are in Western Europe, and several are in Paris (especially if we add those who go to Paris for the Coclico meeting), we thought it would also be a good opportunity to gather for a technical and social meeting. It seems the Coclico open session didn't generate much interest this time (at least, it hasn't so far), so I proposed to hijack the room for this FusionForge meeting, and I didn't hear any objections. I have several themes I'd like to discuss with people, and possibly start implementing during that day:

• database maintenance and schema: unification of the upgrade scripts (including for plugins), cleanup of obsolete stuff, addition of missing constraints, and so on;
• configuration system: my initial prototype didn't raise many objections (at least in its scope), now what to do with the next steps?
• packaging and installation system: what needs to be done to keep the three ways of installation (manual, *.deb, *.rpm) in sync with as little work as possible?
• permissions system: clarification of what happens currently, ideas for evolution;
• plugins and interaction with external software: do we lack stuff that would make this easier?
• roadmap, long-term plans, this sort of things;
• other things that users may want to discuss with hackers?
• possibly drink a beer or two;

and so on. These are in no way specific to FusionForge, and in fact I think it would be great if hackers/users of other forges were present, because we could benefit a great deal from their experience and plans. But if we find ourselves amongst FF people only, I think these would be good to discuss, possibly write some code for, and go home with a clearer picture of where our efforts should focus in the near future. I'd therefore like to invite interested people to mark the 3rd of February on their agendas. The meeting will take place in Issy-les-Moulineaux (near Paris, within reach of the tube). If you're interested, please get in touch with us (#FusionForge on the FreeNode IRC network, or the fusionforge-general mailing-list), so we can have a rough estimate of how many people to expect. The meeting room is provided by France T l com, and they're probably going to need numbers if not names. Further details will be announced when known.