One of the most frustrating things about Copyright Expansion is that it s being driven through at international levels, far away from most of the people that it affects. When we try to contact our international representatives, such as national government ministers or officers, or Members of the European Parliament (MEPs), it usually takes me at least two attempts to convince them that I actually understand the issue that I fell they re about to bodge. So, here we go again:-

The European Parliament is being asked to nearly double the term of copyright afforded to sound recordings. Industry lobbyists suggest that extending copyright term will help increase the welfare of performers and session musicians. But the Term Extension Directive, which will be voted on by the Legal Affairs Committee in a few weeks time, will do no such thing.

Follow developments on EDRI s Copyright page and Write to your MEP, like Stuart Langridge did. I ll contact Neil Parish MEP directly and hopefully he ll remember me, so I won t have to do that stop sending me copy-pasta from Malcolm Harbour dance. I ll also see if I can get nice responses out of the other parties this time.

A new release of Backup Manager has been published. This release closes a bunch of bugs reported in Debian and in the official Bugzilla. The release notes are available here. Here is the announcement made on the user mailing list. I ve also uploaded a new Debian package to sid, in order to provide 0.7.8 for the unstable distribution of Debian. Reports are welcome (but bug-related ones are prefered, if possible in the official Bugzilla rather than in the Debian BTS).

Welcome back for the last part of the reviews. You may want to look at the previous parts : part 1 and part 2. Jigdo-ivory, a JavaScript Jigdo client Presentation Debian CDs and DVDs take up a huge mount of space on download servers. Using jigdo to download those images can significantly reduce the amount of bandwidth and space needed on the central servers. Unfortunately, jigdo currently needs special client software to be downloaded/installed first. Adding support directly into a browser-based application could potentially make a very big difference for first-time users here. Jigdo was created in 2001. It allowed to create ISOs from .debs grabbed from regular mirrors. It eliminated the need to duplicate the entire contents of the package repository into ISO files for each release, or even more importantly, for weekly snapshots of testing/unstable/whatever. You may find the complete proposal from the student here. The original idea originated from the Debian-CD people, who wanted to explore ideas about creating a light web client. The project was mentored by Steve McIntyre, who developed a new version of the Jigdo tools, jigit, which is much more efficient. Student Dustin Rayner was a 5th year senior undergraduate student at the Oklahoma Christian University in Oklahoma City, Oklahoma. I studied Computer Engineering for 3 years as a Computer Engineering student before deciding to pursue a Mathematics and Computer Science degree. Result This project was unsuccessful due to numerous issues. First, because of an inadequate technical preparation of the original proposal. The Debian-CD people were too optimistic with the possibilities of Javascript. In the end, the copying and checksumming part of the Jigdo process were implemented but the checksumming (with a Javascript implementation of md5) was so slow that it was unusable (think 50kb/s on a regular laptop at full CPU charge). The student did the right thing to investigate Java and ActiveX but it was too late unfortunately and he ultimately lacked the experience and knowledge in the relevant technologies. If the proposal is tried again, the student would be requested to have much more experience with Java (and possibly ActiveX). Those would be much more efficient for the task, as they are the most used technologies among on-line anti-virus scanners, which have a workload somewhat similar to Jigdo. I could not find further public involvement of Dustin Rayner within Debian. Aptitude-gtk, usability and GTK+ GUI for the Aptitude package manager Presentation A GTK+ GUI for Aptitude that will work alongside improved current ncurses and command-line interfaces. This will offer an alternative to Synaptic with an interface design geared toward usability and advanced functionality. Debian currently supports multiple non-command-line package managers, the most used being Synaptic and Aptitude. Synaptic uses a GTK+ interface but offers no command-line mode. Aptitude offers a command-line mode but no X interface, although it offers a ncurses interface.
Comparing the interfaces of Synaptic and Aptitude reveal many design differences. Although Synaptic may be more accessible to beginners, Aptitude offers many interface behaviors and functions that are useful to the regular to advanced users : fully hyperlinked tabbed navigation between packages and versions of packages, mostly modeless interface, interactive dependency conflict resolver The proposal was introduced by the student in coordination with Daniel Burrows, the mentor and developer of Aptitude. Student Obey Arthur Liu was a 22 year old french student of Computer Science and Applied Mathematics at Grenoble Institute of Technology - ENSIMAG, in France. Did I mention that he s also yours truly ? If you want to know more, you might be interested in my previous post. Result This project was successful. The interface was mostly done and functional by the end of the summer. Daniel merged the code into the main post-lenny branch. Development is still ongoing and packages are released into Experimental. For further information, just read the rest of my blog. I could find some further public involvements of Obey Arthur Liu within Debian. Doh! Lintian for fuller automated setups Presentation lintian, the Debian package checker, at the moment presents possible problems in three categories: errors, warnings and informational messages. This leads to several problems, most importantly that the severity and certainty of a check can t be expressed separately. In the course of this project, the student should design and implement in lintian an improvement of the current situation, for example by using a two-letter code (one for certainty, one for severity). This project would make lintian errors much more fine-grained and help in maintaining pertinent quantitative analysis of package quality. The project was mentored by Marc Brockschmidt. The project proposal was commonly introduced by the Lintian team. Student UPDATED: Jord Polo Bard s has done a lot of work with translation in Catalan, his native tongue. He can usually be found on #debian-catalan. He also maintains a few packages as a DM. Result This project was successful. The classification was entirely done. Jord also helped with the new lintian.debian.org website. The Lintian team was very satisfied with the revamped errors list and new website. They have an immediate impact on packages quality reporting. Jord is still active within Debian, helping package a few games. Debexpo, a generic web-based package repository Presentation mentors.debian.net is currently a very specialized web-based repository that allows everybody to contribute software packages to Debian without the need to be a Debian Developer (or Debian Maintainer). It has successfully helped simplifying the sponsoring process in the last years. However it needs to be refactored and in the process should be turned into a generic piece of software that can be used for other Debian source/binary package repositories, too. Mentors is a very good initiative to recruit new packages maintainers (and needs your help!) and the software underlying it could be reused for many different purposes (think PPA). The project was mentored by Christoph Haas. The project proposal was commonly introduced by the mentors team. Student Jonny Lamb was a Computer Science student in the United Kingdom. He was already quite involved within Debian, maintaining a lot of significant packages. Result This project was successful. The whole proposal was perfectly executed. Jonny now continues to develop debexpo, with the mailing-lists and commit logs showing interesting activity. Of course, help for debexpo is appreciated to get it into full shape. Jonny has since become a Debian Developer (here is his AM report). Congratulations to him. It s nice to end on a nice note isn t it ? Now that we re done with the individual reports, I m going to write down my recommendations report. Hopefully it will help with next year s Summer of Code.

Keeping track with packaging software which is under heavy development can be time-consuming. I noticed this while packaging Conkeror, because there was quite a demand for up-to-date packages, especially from upstream themself. So recently on the IRC channel #conkeror the idea of automatically built Debian packages came up. After a few hours of experimenting and a few days of steadily optimizing, I can proudly present daily built snapshot packages of Conkeror for currently Lenny and Sid, ready to be included in your sources.list:

deb     http://noone.org/conkeror-nightly-debs lenny main
deb-src http://noone.org/conkeror-nightly-debs lenny main
deb     http://noone.org/conkeror-nightly-debs sid main
deb-src http://noone.org/conkeror-nightly-debs sid main

The binary package conkeror-spawn-process-helper is currently only built for the i386 architecture, but other architectures may follow. The packages probably work also on any other Debian based distribution (e.g. Ubuntu) which includes XULRunner version 1.9. Surely they are not of the usual Debian quality, but they should do it for staying up-to-date with the Conkeror development just by using your favourite APT frontend. The script which generates those packages is also available in the Conkeror git repository at repo.or.cz. The APTable archive is generated with reprepro. Packages and the repository are signed with the passphrase-less GnuPG key 373B76B4 which is used only for the Conkeror nightly builds. (If anyone knows a better solution for automatic builds than a passphrase-less key, please tell me. :-) P.S.: I really like the new keybindings << , >> and G . :-)

After everybody though that Midnight Commander is dead and the next release of it will be released together with hurd, it is very cool to announce that a new team of developers are active again. We've taken over officially the development in December and now, after two months of work a new version of mc is available: 4.6.2. This is mostly a bugfix release addressing several very nasty bugs which are also present in the debian package. Here the notes what has changed in this release:

• MC Core
  • Changed HQ url to point to new website www.midnight-commander.org (Closes: #137, #138)
  • Added a micro helper library in order to go slowly avay from glib (Closes: #157)
  • Use static strings as section entries in ~/.mc/history WARNING!: This will break old files (Closes: #50)
  • Fixed a repaint issue when clicking on the "View" Button instead of using F3 (Closes: #35)
  • Removed obsolete autoconf macros (Closes: #133)
  • Fix escaping for command line completion (Closes: #147)
  • prevent mc from segfaulting when getting invalid timestamps on files (Closes: #96)
  • Fixed a keybord issue when running mc via a putty console (Closes: #203)
  • setted pty fd to closeonexec (on subshell) (Closes: #174)
  • Fixed file renames, when copying/moving is performed into deleted directories. (Closes: #181)
  • Add an option to show executables first in the panels (Closes: #173)
  • Fixed concatdirand_file if there is a parameter = NULL (Closes: #180)
  • Allow out-of-tree builds (Closes: #224, #208)
• Editor
  • Syntax highlighting for:
    • debian files (debian/changelog, debian/control, debian/copyright, ..) (Closes: #142)
    • updated sh syntax highlighting (Closes: #143)
    • updated pascal syntax highlighting (Closes: #65)
    • differentiate between c and cpp files for highlighting (Closes: #16)
    • updated python highlighting to support python 2.6 (Closes: #216)
  • Removed some unneeded variables (Closes: #168, #151)
  • Do use a ro test if a file exists (Closes: #206)
  • Fixes some missbehaviour in regex matching (Closes: #207, #211 )
    • start at front of line and not on cursor position
    • . shouldn't match a newline
• VFS
  • Fix some bashisms in some extfs scripts (Closes: #146)
  • Fixed various problems with symlinks and files with chars which needs escaping over fish (Closes: #10, #87, #149, #53)
  • Added 7zip extfs descriptor (Closes: #92)
  • Switched from o3totxt to odf2txt as o3totxt is outdated (Closes: #218)
• Locale
  • Updated german translation (Closes: #167)
  • New Belarussian translation (Closes: #170)
  • Updated russian translation (Closes: #159)

As you see.. quite a long list of fixes Have fun and check the new release out right here!

I ve so far been going through the list of projects that were done last year (part 1, part 2) in a somewhat dry fashion so I m going to make a little pause here and tell where I m going from with these posts. As I went through the 2008 Summer of Code at Debian, I moved from being a nearly total outsider student to something more of a developer. I ve been contributing to Aptitude since the end of the Summer of Code (well, trying to find time to contribute more, as with many people..) and will be going to FOSDEM. I can t say I m an insider yet: I haven t met a lot of people, most people have no idea who I am, I ve been active here for, like 9 months and I m not even in new-maintainer yet (though I plan to apply when I feel I ll have contributed significantly to Debian). The Student point of view See, I m a student in Computer Science. I use free software, I d like to participate but it s intimidating and you never know where to start. You know the drill. Then comes the Google Summer of Code. Let s review its stated goals, as per its FAQ:

Google Summer of Code has several goals:

• Get more open source code created and released for the benefit of all;
• Inspire young developers to begin participating in open source development;
• Help open source projects identify and bring in new developers and committers;
• Provide students in Computer Science and related fields the opportunity to do work related to their academic pursuits (think flip bits, not burgers );
• Give students more exposure to real-world software development scenarios (e.g., distributed development, software licensing questions, mailing-list etiquette).

I m going to start with these goals and provide some of my opinions in something of a candid way. Inspire young developers to begin participating in open source development I have been playing with the idea of making a GUI for Aptitude ever since I dropped Synaptic, about 2 months into its use. It felt like when I bought a high-school required Texas Instruments TI-83+, that I dropped for a TI-89 within a month. Since back in 2005, every time I would see someone using Synaptic, I would pitch Aptitude as a better tool. The main reason for not doing so was that Aptitude was scary-looking. See, it s a lot of blocky text and wacky colors. With life and cool stuff like CPGE, I never had time to really code so I left it at that. In 2008, for the first time I was free the whole summer and so, I tried to get into the Summer of Code program and into Debian. Actually, it wasn t the first try. One popular way to get acquainted with Debian is to go to wnpp, adopt a package (new or orphaned) and find a mentor to upload it. In January 2008, I did try to package a set of geocaching tools I used at that time. But I didn t find a mentor to upload it. I didn t try very hard though and the package had some minor issues anyway. I reckon that Debian-mentor is a good idea to bring in new Debian Maintainers but the whole process is still quite technical. It is true that the minimal technical level for good packaging is not trivial in itself and the process should filter out unserious people, but the technicality curve could be adjusted to be more welcoming. I think the Debian website could be improved in this area (ok, it s a quite long-standing bug). Holger Levsen mentioned the way Fedora and Sugar presented avenues of collaboration to prospective developers. The crux here is that it should feel much easier to identify areas to get involved into and who to contact if needed. Help open source projects identify and bring in new developers and committers Actually, it would rather be the other way around: help students identify and integrate into open source projects. For the Summer of Code, I only postulated at two organizations, Debian and Freenet (the ones working on an anonymous darknet, remember ?). I got accepted at both and ultimately chose Debian (was my first choice from the beginning). The Debian developers community is quite unique in the way it is very decentralized, independent and fluid. There are teams in some areas (Kernel, KDE, Translation, Edu, Publicity, whatever) but much of what makes up Debian is done by individual developers working on their own. The downside of this is that for a newcomer, it s a little off-putting. Organized teams are not the way all things are done within Debian so there are often no smaller circle of people one gets to know. Going to Debian meetings and not knowing most of the people is a little intimidating. Keeping up with all the faces is a little hard too :). Many other organizations participated into the Summer of Code and many would feel arguably different. Many may be more corporate-like, more hierarchical, more centralized. I preferred Debian because it was less formal in its structure. I felt that I didn t want to get into something that looked too much like work with supervisors and the like. It is indeed how it felt, there were no one up there to decide what we had to do. We were quite independent. I can say that the Summer of Code is quite a good way to get a feeling of how a particular organization works in the inside. Give students more exposure to real-world software development scenarios As said earlier, many parts of Debian are independent, which is a result of the work separation through packages. In my work on Aptitude, it is a pity that I didn t have to interact a lot with other members of the Debian community. Aptitude talks with the rest of the Debian packaging ecosystem through mature library interfaces so there s not much need to ask questions beyond them, and even more so because my Daniel Burrows, my mentor and developer of Aptitude participated in their development. Also, I was working on bringing a graphical interface to it, so I didn t have to modify a lot of core code that interacted with the outside world. Despite this, I still met a few people interested with future developments in the area of package managers. One example is Enrico Zini who pushed his work with Xapian APT Index. Over the summer, my mentor integrated packages search through Xapian which was interesting with the expanded possibilities of a graphical interface such as search as you type, drop down suggestions and so on. Because of the short duration of the Summer of Code, most projects can t complete a full development cycle. The proposed work in my proposal was quite imposing. In the end, I managed to produce an (probably not even) alpha quality version of a graphical interface. My branch (if I remember correctly) was merged into the main trunk at the end of the summer and a version landed in Experimental at the end of the year. One aspect that I missed was beta-testing feedback. During summer, only a handful people popped up on the mailing-list giving feedback on the GUI I was writing, although I knew through stats on my mercurial repository that dozens of people cloned it and followed it. Debian has no testing team , or any kind of semi-organized group of people who try stuff, which would be very useful to have an idea of how well I was doing. So, did the Summer of Code at Debian give me real-world software development scenarios ? Not really in my case but by staying longer into Debian, I think caught up a little with that. Here is some advice for the future Summer of Code student at Debian:

• the work of a Linux distribution might look a little nebulous and mysterious but the reality is that Debian does a very large range of development work: web development (debexpo), user application development (aptitude-gtk), hardware interaction (Debian NAS), developer infrastructure (lintian) or even quite theoretical stuff (debgraph) there is really a lot to choose from.
• Debian is not a nanny-project: you will not be managed, you re free, but you re on your own, be prepared
• don t hesitate to contact anybody working in areas you re interested in: look for packages maintainers, search mailing lists and wiki, look for debconf/fosdem/wherever talks by Debian developers. Developers will be happy to redirect you to the right people.
• choose something that can be reasonably finished by summer s end. Also take into account release freezes.
• be sure to contact anyone involved into the area you re working on: they will try to make it easier to merge your work in
• be sure to contact anyone involved into the area you re working on: it s ok to ask for help
• publicize your work: the Debian Project News will be happy to take your press releases , write a blog and get included on the planet, go on #debian-devel and #debian-soc, go to conferences and meetings
• you re not alone, interact with the other Summer of Code students, try out their code, give them feedback
• Communicate, nobody will kill you if you say something stupid
• Communicate, don t be afraid if you run into problems
• Communicate, clear enough ?

To conclude, despite all the difficulties, I would say that the Summer of Code at Debian was awesome. Although Debian is quite different from many other organizations, it was a very fruitful experience. And that s why I m still here. Coming next is the rest of the projects reviews and a more concise and substantive list of recommendations for the handling of the next Summer of Code at Debian. And of course, see you at FOSDEM.

This is a great little video/animation Steamboat Mickey, which references one or more events from each year, starting in 1928 and ends in 2008. The music, which accompanies the animation, is fantastic and is by Owen Chapman, an assistant professor of communication at Concordia and a great DJ/sound artist.

Stewart has made some predictions for the future of computing [1]. He predicts that within 2 years the majority of consumer machines will be laptops and have SSD (not rotational media). I predict that by the end of next year more than half of all new consumer machines that are being sold will be laptops (defined as being portable machines with the display and keyboard forming part of a single unit), and that more than half of such machines will have SSD as the primary storage (IE used for booting and for most common file access). I predict that by the end of 2010 the majority of all computers shipped (in all form factors including games consoles and servers) will have SSD as their primary storage. I predict that in late 2010 rotational media will start to go away for most tasks, but for at least the next year the model will be SSD for small/light/fast operations and rotational media for large capacity. I m not disagreeing with Stewart, just being more precise. Also while Val made some good points about the reliability of SSD [2] I don t think that this will be an obstacle in the low-end of the market. There is no little evidence of computers failing in the consumer market due to being unreliable - it seems that Microsoft has conditioned people to expect unreliability. I predict that Sun will not release ZFS under the GPL in time for anyone to care. The release of OpenSolaris was way behind schedule and I don t expect anything different this time around. Stewart predicts that in five years Linux will have significantly more desktop market share than Apple. I agree and also predict that Apple will convert to the Linux kernel. I predict that Apple will become the first Linux distributor to make any significant hardware sales for the mainstream computer market (Linux bundled with hardware has already done well for mobile phones, routers, Tivo, and similar devices where the user doesn t know what OS is running). I predict the death of Windows mobile. I predict that in five years the mobile phone/PDA market will be dominated by Android with a variety of other Linux based phones. I predict that some time after five years the iPhone will go away. Chris Samuel has made some predictions too [3]. He predicts that within two years The distinction between laptops, netbooks and mobile phones will get even more blurred with consumers demanding mobiles with more power and lighter and lighter laptops/netbooks . I believe that the difference between laptops, netbooks, and mobile phones is primarily one of IO (size of keyboard, sockets for peripherals, and size of screen). For desktop use the only application I use which requires more RAM or CPU power than my EeePC 701 can provide is Firefox. A combination of more efficient javascript interpretation and better coding practices by web designers would solve that problem. A significant portion of the mass of a laptop is dedicated to suppporting IO ports and maintaining the structural integrity of the device. A common feature in science fiction is lapotops that can be rolled up, stretched to size, etc (the Thinkpad Butterfly keyboard was an attempt at a first step towards this which failed due to issues of mechanical strength). As some Netbook class systems already have 3G networking built in it seems a logical extension to have telephony functions built in to a laptop. I predict that laptops with full telephony support will go on sale in 2010. One promising feature in regard to laptop IO is the new Display Port [4] video port. It will only be an incremental improvement to the space taken for IO capacity, but I am not expecting anything revolutionary in the near future. I predict that HDMI will be a failure in the market and DVI will never gain critical market share, it will be VGA and Display Port on most systems by 2012. Predicting that technological developments won t happen is always risky, but I predict that the mechanical issues which separate the heavier laptops and desktop-replacements from netbooks (in terms of making a large display and keyboard that won t break frequently) won t be solved within five years. In the same note, I don t expect anyone to try building a mobile phone which can have a full-size screen and keyboard connected to it (although it would be possible to do so). So I expect that the phone/PDA, Netbook, and laptop distinction will remain for at least the next 5 years. One thing that would make sense is to have a small device (PDA or mobile phone) store data that is security relevant and connect it to full-size machines for serious work. So for example you could use a desktop machine for Internet banking (maybe in an Internet cafe) and have your mobile phone ask you to confirm the transaction and then authenticate you to the bank server. I predict a larger role for PDAs and mobile phones as computers as soon as people start to take security seriously. I won t try and guess when that might be, but I predict that it won t be for at least five years. I predict that increasing oil prices will significantly make a significant impact on the price of computers before the end of 2010. Not that I expect the prices to suddenly jump upwards, it s more likely that prices will steadily increase while at the same time new technology to reduce production expenses in other areas is introduced. I also predict that increasing oil prices will increase the desire to maintain systems for longer periods of time without maintenance. For example my Thinkpad T41p has had a few significant part replacements (a couple of motherboards, half the case, and a few keyboard replacements). This is OK while plastic costs almost nothing and the manufacturing expenses are also very low. But in future I expect that people will want laptops that can run for years without needing part replacments and which have a service life of 10 years or more. This requirement for strength will counteract the demand for laptops that are as light as netbooks.

• [1] http://www.flamingspork.com/blog/2008/11/09/technology-predictions/


• [2] http://valhenson.livejournal.com/25228.html


• [3] http://www.csamuel.org/2008/11/09/technology-predictions


• [4] http://en.wikipedia.org/wiki/Displayport

Recently there has been increasing attention paid to thermal issues. The power used by computers not only impacts the electricity bill (and battery life for a portable device) but is a cooling problem. The waste heat from desktop systems and servers costs energy (and therefore money) to remove by the air-conditioning system and the heat produced by small devices can impact where they may be used. It seems that a temperature of 40C can cause burns if applied to the human body for any period of time. As it doesn t immediately hurt this can happen without people noticing. A friend recently reported getting a large blister on his arm after drinking a moderate amount of alcohol and falling asleep next to his EeePC. I have noticed that my EeePC 701 has an unpleasant pattern of heat dissipation. It appears to use only one small vent in the side to vent most of the heat (with some vents in the base for air intake) and the base is all plastic. Apparently such a machine draws 14W from the wall when in active use compared to my measurements of 20W for a Thinkpad T41p. The Thinkpad however has a significantly greater size, this means bigger vents (and therefore lower temperatures of the vented air). Also the fan inside the Thinkpad makes much less noise so I guess it s larger. If I am working in the loungue and leave my Thinkpad on the couch it doesn t seem to have any thermal issues. But if I leave my EeePC sitting in a normal manner the vents on the base are partially blocked and it becomes unpleasantly hot. If I leave my EeePC upside-down with the lid closed so that the vents in the base are exposed to the air) then the screen gets very hot, I am not sure whether this is heat from the CPU going through the keyboard to the screen and then being prevented from going further by the insulating cushion or whether heat is generated in the screen (although it is supposed to be powered down when the lid is closed). One suggestion I have received is to place a laptop on a metal baking tray. The flat tray preserves the airflow underneath it and the metal conducts heat reasonably well. Baking trays seem to be made of aluminium or thin steel, they don t conduct heat well - but a lot better than a cushion. It seems to me that one factor which will limit the development of NetBook class machines is the ratio of heat dissipation to either area or volume (I m not sure which is more important). For use similar to mine providing the same compute power as an EeePC 701 with less heat dissipation would be ideal - and technically shouold not be difficult to achieve. Unfortunately I think that people will want to run Windows on NetBook class machines so we will see the development of machines with faster CPUs and GPUs which have worse ratios of heat to heat dissipation potential which will lead to more heat induced shutdowns and low temperature burns. It s a pity that no-one makes a netbook with the CPU power of an iPaQ. A 400MHz ARM CPU is all I need for my portable computing and my iPaQs don t have cooling vents.

One of the points I made in my presentation at LCA this year was that for power management to be effective, it needs to be something that works without anyone having to think about it. One aspect of that is ensuring that it doesn't get in the way of the user, since otherwise the user will eventually get irritated and turn it off. Part of my work at Red Hat is coming up with ways to not only offer power management functionality, but to make it sufficiently useful and inobtrusive that manual configuration is almost never required.

Screensavers are an interesting case. We have a good idea of whether most hardware is "doing something" or not, based on whether it's generating traffic or an application has it open. This is less true of screens - the resource making use of the display is the user, and it's entirely possible for the user to be reading or watching something[1] onscreen without us getting any feedback from them. It's common to see people noticing that their screensaver is activating and hitting the mouse or keyboard to stop it. What's the correct solution?

One solution is to have the user increase the screensaver timeout. This is a poor solution - it's one of those "Think about what you're going to be doing with the computer before starting to do it" ideas that I dislike a lot. Computers are there to serve the user, not the other way around. The other downside to this is that the timeout will be left at a large number and monitors will be turned on for significantly longer than necessary.

Another is to pay attention to what the user's doing. If they keep hitting the keyboard just as the screensaver's activating, it's because they want a larger timeout. It's not difficult to give them that. I spent a while today playing with various complex implementations, but I finally came down to a simple one:

• If the user generates activity while the screen is blanking or immediately afterwards, bump the timeout by 10 minutes. Perform a further increase each time they do this.
• If the screen is successfully blanked and the user doesn't immediately unblank it, reset the timeout to the original value

Another option would be to double the timeout each time the user unblanks the screen, and that may be what I end up going with. A more complex solution might be to keep track of the user behaviour and tie it to time of day (if the system goes idle at 3:30, you might as well blank straight away - they've gone to grab a coffee or something), but I'm leaning towards thinking that that's overkill.

To test this out, I've actually gone to the extent of setting my default screensaver timeout to a minute. We'll see whether it gets irritating. I suspect that there's some more fine tuning to do, and I may want some kind of decay function rather than immediately pushing the timeout back to the original value.

Next job is to think about whether there's any reason to not just enter DPMS straight away if the user's selected a blank screen...

[1] I'm thinking along the lines of IRC conversations or logfiles rather than films - media players should be talking to the screensaver already

Sarah was discharged today. I decided to scrap trying to go to work, as I'd just have to leave at some point to pick her up. The hospital had to ensure that the nurse from Critical Care Systems was able to come to our home before they could discharge her, so that the IV antibiotics could be continued. We left the hospital at about 11:30am, and he got to our place just after 1pm. He whizzed through the whole process, as she was due for more antibiotics at midday and he wanted to get the IV started. She's on a four hourly course. Fortunately, that doesn't mean we have to change the IV every four hours. The way it works is the bag has enough antibiotics in a (presumably saline) solution to last six infusions on a four hourly frequency, and it's hooked up to a pump (that'll cost us $5000 if we don't give it back at the end), which takes care of everything. So once a day at around noon, Sarah has to disconnect the old bag, flush the line with saline, do something with some Heparin to prevent clots in the line, and hook up a new bag. The bag and the pump fit into a carry bag that can be worn like a bum bag or slung from her shoulder and looped through a belt. It'll be her permanent companion for the next (hopefully only) two weeks. The PICC has two ports (and I don't think that's the correct term) on it, and the IV is only hooked up to one, so the other one should be flushed and "Heparinised" regularly as well. The nurse comes back in a week with more supplies and to do some maintenance on site where the PICC line enters her arm. Critical Care Systems seems pretty impressive. They provide all the gear, fill the prescription, and bring it all out to you (by a nurse). They provide a 24 hour hotline to call if there's any problems, questions or concerns, and can dispatch somebody to us if necessary. We've got syringes preloaded with saline and Heparinised saline, more alcohol swabs than you can poke a stick at, and the fridge is full of IV bags. It's awesome that medical technology has progressed to this point, where Sarah can go about her business almost as normal, instead of being stuck in a hospital for another two weeks just because she has to have a tube in her arm. To prove this, the little trooper was back at her CNA course this evening, and starts clinical training tomorrow night.

That is, my laptop. Since at night I keep it in the same room where I sleep, I figured that I could as well use it as an highly customizable alarm clock. My alarm script uses rtcwake(8) from util-linux-ng to set the RTC alarm clock, suspends the computer and then plays some music at a set volume when it wakes up (if it never wakes up, check your BIOS settings). Since it uses the date(2) command it can parse the alarm time in many formats.

#!/bin/sh -e
# for a random tune, list multiple space-separated files
MUSIC='/home/mp3/The_Velvet_Underground/The_Velvet_Underground_&_Nico/07_Heroin.mp3'
# some days I like different music
DOW="$(date +%u)"
if [ $DOW -eq 6 -o $DOW -eq 7 ]; then
  MUSIC='/home/mp3/The_Velvet_Underground/The_Velvet_Underground_&_Nico/01_Sunday_Morning.mp3'
fi
# choose your favourite music player
player()   mpg123 --random --quiet --control --title "$@"   true;  
#player()   mplayer -loop 0 "$*";  
# play the music at this volume
VOLUME='50%'
# ALSA mixer control used to set and restore the master volume
VOLUMECTL='iface=MIXER,name="Master Playback Volume"'
##############################################################################
# this is more elegant, but it needs rtcwake from util-linux-ng >= 2.14.2
rtcwake_set_alarm()  
  local when="$1"
  local rtc="$2"
  if [ "$rtc" ]; then rtc="--device $rtc"; fi
  local epochtime=$(date --date "$when" +%s)
  [ "$epochtime" ]   return 1
  sudo rtcwake $rtc --mode no --time $epochtime
 
# you can use this function instead if your system lacks a working rtcwake
set_alarm()  
  local when="$1"
  local rtc="$2"
  [ "$rtc" ]   rtc='rtc0'
  local epochtime=$(date --date "$when" +%s)
  [ "$epochtime" ]   return 1
  local alarmfile="/sys/class/rtc/$rtc/wakealarm"
  sudo sh -c "echo 0 > $alarmfile && echo $epochtime > $alarmfile"
 
##############################################################################
if [ "$1" ]; then
  WHEN="$1"
else
  echo "Usage: $0 WHEN"
  exit 1
fi
set_alarm "$WHEN"
# save the volume
oldvolume="$(amixer cget "$VOLUMECTL"   sed -nre '/ : /s/.*=//p')"
amixer -q cset "$VOLUMECTL" $VOLUME
# actually here I run a script which also deals with network interfaces,
# IM and IRC clients and so on
sudo pm-suspend
player $MUSIC
# restore the volume
amixer -q cset "$VOLUMECTL" "$oldvolume"
exit 0

It took more than a week this time, because I was ill, but new testing Gammu version is here. This time there are finally no really major changes, only fixes of regressions (PostgreSQL SMSD brokeness) and bugs found by testing and reported by users. Full list of changes:

• Fixed getting of network name from saved message.
• Fixed encoding of text to some encodings in AT engine.
• Detect more Siemens CME error codes.
• Windows binary is again with MySQL support.
• Initial native support for Motorola phonebook (bug #748).
• Use getpass if available for PIN code prompt.
• Fixed parsing of phone number from incoming calls.
• Added ID for Nokia 1112.
• Dropped obsolete packaging/debian and point users to proper packages.
• Fix crash when operator logo is empty.
• Fix memory leak in SMS backup.
• Fixed processing of SMSD outbox with PostgreSQL (bug #803).
• Automatic detection of lib64 directory for installation.
• Allow separate installation of some components on Windows.

You can download sources and Windows binaries (now for first time you can select which parts you want to install) from usual place: http://cihar.com/gammu/, Debian users will find packages in experimental soon and RPM users can use my repository at OpenSUSE Build Service. PS: I'd like to thank to "j t" who kindly donated me Nokia 6822 for testing.

Seriously, every time Sarah has surgery, it all goes pear shaped. The bottom (last time it was towards the top) of Sarah's incision from her recent wire removal surgery was looking a bit red, swollen and hard on Friday, so she went in to the clinic at got them to take a look at it. They decided that a knot in the sutures was trying to work its way out, and causing inflammation or something, so just like last time, they decided to reopen the incision a bit. They did that, and cut the knot out, and rather than packing with gauze, they just taped the small opening closed with some steristrips and covered it with gauze and sent her on her way. Somewhat fortunately (for me) Sarah went into the clinic during the day while I was at work, so I missed participating in the fun and games. They didn't use any local anaesthetic, but Sarah said it didn't hurt too much. That night, though, she was in a reasonable amount of pain, again, similar to last time, except it was a band across her upper abdomen, below her breasts, instead of chest pain. Mindful of the staph infection disaster from last time, we trotted off to the ER on Saturday afternoon, hoping to nip this in the bud. They did some blood work, which came back clear, and gave her some IV pain medication, which didn't seem to do much, and were generally scratching their heads as to the cause of the pain. Fortunately, one of the surgeons involved with Sarah's wire removal from 2.5 weeks previously happened to be on call, so he got called in. He had a bit of a poke around the opening with a long cotton bud, and declared that it was possibly infected, because there was a bit of cloudy fluid discharged when he poked it in. Oh, and the cotton bud disappeared a good centimetre or more under the skin further up the incision, which indicated an abscess was forming. So, for the second time, I got to watch my wife being cut open with a scalpel. I think the local anaesthetic injections were the most painful part for her. He opened the incision up a bit further, and packed it with some Betadine-soaked gauze, and we got sent home with the same instructions as last time this happened: I had to repack the wound with saline-soaked gauze two to three times a day and let it heal from the bottom up. She was also prescribed some antibiotics. She's got about a 2cm incision just below her breasts. It looks a lot deeper than the hole from last year's incision. So we got home about 6pm last night, and went to bed around 11pm. Sarah lasted a couple of hours before she woke up in even more pain than before. She called up the hospital and had the same surgeon paged, and he advised her to come in to the ER again. So at I think about 2am, we headed back. They took some more blood, did a CT scan, which came back clear, and decided to admit her. They're giving her IV antibiotics and pain medication. Initially she didn't want to have any more IV pain medication because it didn't seem to be working, and it tends to make her nauseous. She wasn't keen on dealing with throwing up with the amount of pain she was having. It hurt to move as it was. With a mixture of IV anti-nausea drugs and the IV pain medication, the pain has finally come under control though. She did have one bought of vomiting this evening, which didn't seem to cause her too much discomfort, and she's getting in and out of bed more comfortably. They're going to keep her in overnight. She has a post-operative followup tomorrow in the clinic, so I expect they'll keep her in the hospital until at least then, depending on how things go. Her cardiologist, intimately familiar with last year's debacle, dropped in this afternoon. He's wondering, given how this has happened twice now, if Sarah has some sort of allergy to the type of absorbable suture they've used. Apparently there are different types of sutures, so if she ever has any other surgery, we'll have to get them to try a different type It'll be interesting to see how she goes tonight, as the pain seems to get worse overnight. She hasn't had any IV pain medication since about 1pm, and she wanted to see how she goes without it, because if she gets discharged tomorrow, she'll have to rely on oral stuff anyway. I think it definitely gets harder for her to manage her pain when the pain is causing her to lose sleep. She can only deal with having a couple of night's worth of bad sleep before it all gets too much. So I'm really hoping she gets a good night's sleep tonight. Not that hospitals are renowned for that...

Executive summary To avoid confusion with the proprietary versions of GForge (known as GForge Advanced Server, GForge Express Edition and GForge Community Edition), the free/libre/opensource codebase will from now on be separately maintained under the name FusionForge by the main developers of the free GForge 4.x codebase. Since this is mostly a renaming, the migration path for existing users will be smooth. Longer version, with details After the initial forking from the Sourceforge codebase, the development of GForge has long been hosted, and many enhancements directly developed, by the GForge Group (GForge, LLC), with regular contributions from outsiders. The results of these evolutions were public and free, subject to the GNU GPL. In parallel, the GForge Group wrote a proprietary re-implementation of GForge, which it sold under the name "GForge Advanced Server", or "GForge AS" for short. This re-implementation added some features for "the enterprise", but was not contributed wholesale to the GForge codebase under a free license. Although some of the features were contributed to the public, the GForge Group concentrated its efforts on its (proprietary software) business model, with more versions appearing, such as "GForge Express Edition" and more recently "GForge Community Edition". As a result, it became increasingly harder for the public to know which version was which without doing extensive research (indeed, some users mistakenly installed one version instead of the other). A consequence was that the free software codebase suffered from a loss in visibility, which lowered its momentum to the point that there haven't been any moderately important releases since the (currently stable) 4.5.x series was announced in late 2005. So, in order to clarify things, avoid further confusion, and regain some of the lost momentum, it was decided by a group of leading contributors that the free software version of the GForge codebase would from now on be developed under the FusionForge name, and its development would be hosted on FusionForge.org. So is this a fork? Well, we don't know yet. It could arguably be called one, since we're taking the code and running away with it under a new name. However, we believe it's not a fork unless both roads continue their own way (more of a oddly-shaped bend). What happens to the GForge codebase developed by the GForge Group at gforge.org remains to be seen, although for the sake of our users we will backport security fixes to the gforge.org Subversion repository (at least for the 4.5.x series and the unreleased 4.6 and 4.7 pre-series) for some time. The bulk of the development will move on to FusionForge and the repositories at FusionForge.org, though, and users are encouraged to migrate at their own pace. Since we're basically continuing the evolution rather than starting from scratch, the migration path should be rather smooth. So why the FusionForge name? Because there were actually lots of locally-patched versions of GForge (and Sourceforge), and we felt it was a waste of resources that should be fixed. It seems many people and organisations took these codebases at some point in time and evolved them for their own needs. Sadly, many of the changes were not contributed back or even published, so lots of efforts were duplicated. Fortunately, many of the people managing these locally-patched forges are now realising that "out-of-tree" patches and features require quite some manpower to maintain. Some formal inter-project discussion is already taking place, and we hope to achieve actual merging of most of the interesting features that have been developed here and there into a common base that can be reused locally with minimal changes. We'd like to "un-fork" as much as possible. We also expect that, by using standard components and tools, we'll facilitate the work of potential contributors, thereby reducing the risk of a new era of fragmentation. And who are we anyway? We're Christian Bayle, Roland Mas and Alain Peyrat, long-time contributors to GForge and responsible for over 95% of the commits over the past two years, as well as a few relative newcomers. Christian and Roland have been maintaining the Debian packaging since the "Debian-SF" era, and Alain has been focusing on code quality. The three of us have, for various reasons, a vested interest in maintaining a lively codebase in a healthy ecosystem. What are our plans? Our short-term goals, as currently planned, include:

• pushing a stable FusionForge release out of the door;
• cleaning up and auditing the database schema to ensure consistency and increased performance;
• merging in new plugins, in particular for new version control systems;
• continuing streamlining the installation process to make it more portable across distributions.

Longer term goals are less well defined, but we're thinking about the following:

• increasing code quality by the use of modern automated tools;
• encouraging a lively stream of external contributions, to reduce the gap between the official version and the locally-patched ones;
• defining an explicit governance model and release process for the FusionForge project;
• as a consequence, a more frequent and predictable release schedule;
• increasing data portability and interoperability with other forges, to reduce lock-in for users and projects.

Some of these items should be facilitated by our switch to a distributed version control system and a new coordinated workflow. Also, the Debian i18n team has been kind enough to offer to host our translation effort on their Pootle server, which means translators will have a much easier time doing their job. We hope to hear from users and contributors alike in the near future. For more information, we can be reached via our fusionforge-general mailing-list (see our lists), which is also suitable for general discussions. We can also be found on IRC (#fusionforge on the Freenode network).

Giving up on a position within a free software project when you know you re no longer managing to do an effective job is a wonderfully liberating experience. Now that I have started to talk with Miriam Ruiz about handing over the Debian Jr. project, I can stop worrying about the leadership task and just have fun with it. I can always count on Miriam for recommendations for games in Debian my kids may enjoy, as she has a passion for finding good games to package for Debian, and in particular, games for children. Over the past few weeks we ve had some fun with her picks. At the same time, I always have Debian Jr. in mind. How can we ensure kids can have the most fun with this? How do we equip their guides to help them? What we ve done with each new piece of software is to find a quiet time when one or more of the children can start playing with it on their own while we watch, offering such guidance as they need, but for the most part just letting them loose with it. Each wrinkle of the brow, each impetuous thump of the mouse, every illuminated grin and exclamation of delight is noted. We try to see what frustrates or pleases our kids and discuss it both with them and the Debian maintainers and upstream developers. This is an excercise we ve managed to pull off without being overly intrusive and the results have been well worth the effort. Using a few of Miriam s picks we tried this week, we were able to draw their play into the free software development process. Here s a brief summary of those sessions: Platinum Arts Sandbox puts into children s hands the ability to role play in a 3D world and edit that world using simplified controls. The expressions on the faces of our kids as they played were priceless: both the ups and the downs. I wanted to capture this on video and share it. After having established a rapport with upstream, we took a 20 minute clip of one of our play sessions and gave a copy to them to use to help further their work. Here is the edited result. They were very pleased to have that kind of feedback and found the video valuable for determining where the software still needed improvement and to notice which aspects particularly pleased the children. I happen to know that Hex-a-hop is one of Miriam s personal favourites. We have a household full of puzzle-lovers so this puzzle game was an instant hit. While on irc on #debian-jr with Miriam we relayed in real-time some of the reactions as they played this and a handful of her other picks. This gave her some confirmation of areas she knew needed work as well as inspiration for upcoming releases of these packages. During this play session, which also included StegaVorto, kartofel, Anagramarama, Funny Boat and Vodovod, my youngest girl, age 7, plunked down on the couch next to me as her 10-year-old sister played. Then she started to notice I was typing what people in the livingroom were saying and doing on irc. She took a mild affront to me copying her own words and actions, so I decided it would be better to let her participate so she would feel included. At this point, I started playing secretary for her, typing what she dictated to me while she read the responses from the display. Later, I just handed her the keyboard so she could type and read the responses on her own. She was still at it long past bedtime and it was with some reluctance that she finally gave up the keyboard. We all had a lot of fun and look forward to doing this again. We are particularly careful with privacy, taking care to share pictures, videos, and other personal details only so far as we believe it does not put our children at risk. Also, we need to ensure we observe in a way that is welcome and doesn t interfere with their enjoyment. But with a little bit of prudence and a practiced eye and ear for what increases or diminishes enjoyment of the software, we can involve our children directly in the free software development process. I commend to anyone who has the privilege to share free software with children to use this method to communicate with maintainers and developers, increasing your own enjoyment of the software in the process and that of children and their guides everywhere.

This week's emacs-snapshot release (20090118-1) reached a new milestone with more than 700 downloads in just under a week. I guess this is quite an achievement considering that not everyone wants to download 25MB of Emacs packages on a weekly basis, so thanks to all my users for their continued trust and support!

Here's a quick update on the status of the Emacs 23 release: the last remaining feature on the roadmap was finally completed this week with the merge of the rmail-mbox (pmail) branch into rmail. The pretest (GNU lingo for beta ) phase could start as early as next week, which is not to say that the release itself is right around the corner since a few major tasks need to be finished first, like updating the manuals. The release could also be delayed by the proposed (and long overdue) switch from CVS to Bazaar, pushed by newly-minted Launchpad evangelist Karl Fogel.

That being said, aiming for a release in 2009 isn't entirely unrealistic, and I really can't wait to see Emacs 23 reach a wider audience. It is the culmination of many years of work in lots of areas (Unicode support, font backend, multi-tty, Cocoa, ...) and is by far the best Emacs version to date!

It has been a while since my last post here. Not because nothing happened, but mostly because I did not have time to do much for X. Fortunately, Julien is taking good care of X in Debian so we are still close to latest upstream bits. Obviously, due to Lenny's freeze, everything is happening in experimental these days. Xserver 1.6 The release Xserver 1.6 is expected in the near future. 1.6-rc1 (1.5.99.901) entered experimental recently. Both video and input driver ABIs changed and very few drivers have been rebuilt so far. So if you're not running Intel or Radeon, you might not be able to upgrade yet. Please be patient :) You might have heard that many things are happening in X.org these days: DRI2, kernel-modesetting (KMS), RandR 1.3, ... Everything is not ready yet, but it's getting close for real. Radeon 6.10.0 and Intel 2.6.1 Radeon driver 6.10.0 was released in early 2009. As usual, it brings many fixes, and improvements for modern boards (see Alex Deucher's blog for details). However, Radeon is not ready for above DRI2 and KMS yet. Most of the development for these new features is first done in the Intel driver, which got recently bumped to 2.6.1 as well. DRI2 DRI2 is the new Direct Rendering Infrastructure. The most noticeable change from the user point of view is support for Redirect Direct Rendering, which basically means that your 3D application can be wobbly/transparent in Compiz. See Kristian H gsberg's blog for details. If you want to try DRI2 on Intel, you have to enable UXA as the acceleration architecture in xorg.conf (Option "AccelMethod" "UXA" in the Device section). DRI2 will then be enabled automatically. Then, it may or may not work, depending for instance on the hardware. I get a black screen at startup on i865 while i945 works fine until I start Compiz (the server suddenly exits for some reason then). Note that you probably want to upgrade your Mesa packages to experimental as well here (7.3 has been released recently). Of course, running git snapshot of various components (Mesa, libdrm, kernel drm, Intel driver, ...) may help since the released versions seem to not be entirely ready yet. But, things should may be ready to use for everybody in the near future. Kernel Modesetting The other nice feature that makes a lot of noise in X.org these days is Kernel modesetting (KMS). It moves the management of mode (aka resolution+rate) into the kernel. It helps support for switching between different users' sessions, enables reporting of kernel messages (oops, panics, ...) while X is running, and reduces the need to blank the screen during boot (since the kernel can setup the display early and X doesn't have to change it later independently). KMS testing requires a bleeding-edge kernel (2.6.29). Using a git snapshot of the drm stack is probably a good idea as well since I couldn't get KMS to work on 2.6.29-rc2 here. Again only Intel will support KMS soon, but other drivers will follow. Panning is back (aka RandR 1.3) Xserver 1.6 brings support for the 1.3 version of the RandR X extension. Among other improvements, it reintroduces one feature that many users miss since it was removed back in Xserver 1.3 or so. "Panning" (often referred to as "Virtual Desktop") gives the ability to move the display within a larger screen when the mouse approaches from the border. Instead of being configured with the Virtual option in xorg.conf (this option means something else nowadays), it may now be enabled/tuned with xrandr --panning. You'll need the latest libxrandr2 and xrandr utilities to do so (the latter is not uploaded yet).

... and I completely missed it. I've been ranting on and off about the Linux desktop world needing a shakeup, about non-techies shaking their head and not understanding why a Linux Desktop needs further clarification so that anybody knows what it means. Seems I'm absolutely not the only one: KDE's aKademy conference and GNOME's GUADEC are to be held side by side as the Gran Canaria Desktop Summit 2009 in early July this year. I finally saw this in connection with LWN's coverage (subscriber only at this time, sorry) of the recent Qt relicensing by Nokia. The true Year of the Linux Desktop finally? I doubt it, seeing that many people with little computer skills are still completely unaware of what's happening. And currently, I share the pessimism about OpenOffice.org's future as shown in Michael Meeks' interpretation of the commit stats. A real killer in the collaboration platform space is still missing, as well: there are numerous commercial players, quite a few commercial pseudo-opensource packages, tons of real opensource frameworks, but none that can be recommended, in my opinion, without its share of doubts, either about the features, the licensing, or the future. Still, it's been the year of the Linux desktop for me since about 1997 (and that means Debian since not long after that), and I do see the situation improving year for year, so here's a big thank you to all working on it.