I'd like to join those who also feel the happiness of knowing that a new Debian release is getting closer It has been a long wait, but the result will be a good one.

I am anxious to see the official announce and to have a bunch of new versions of packages in unstable, so that my system will be more funny than it is

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.

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!

Here I ll try to present you some tips on how one could easily make a playground become a paid fun. And no, I won t be teaching you how to become rich, although I would like if you would teach me how that could be accomplished as I m trying to come up with a way to do just that for a couple of years now and failed miserably. Recently, I ve been setting up KVM virtual machines in order to do a lot of testing for a project I m involved with. Letting boring details aside, one could say that a very long, boring and error prone setup was finished after a lot of work and it worked like a charm in the end, as a KVM machine. As always, laziness is a given and when you are into it you empower yourself to come up with some nice hacks and goes that extra mile to find out how one could not to have to do boring and repetitive things again and again, in the best spirit of let s have some work now and save me ten times more work later . As I m becoming more and more into that spirit of laziness, there I went looking for a way which would let me transform my beloved and nice working KVM machine into a fully featured real physical server. After some tips from microblogosphere friends (thanks fike), I had some ideas on how that could be accomplished. Turned out my ideas weren t really all that right so there I went again looking for a way to do what I wanted. After some research I found out that the KVM guys already gave some thought about it and even had a ready solution to my problem : it s called qemu-nbd. Yes, by now everyone should know that KVM builds on top of the excelent (just not so snappy) QEMU. However, as I m a Debian user, here I should say that in Debian, most notably Debian sid/unstable, the qemu-nbd binary was renamed to kvm-nbd, just as the KVM binary is called only kvm and not qemu-system-x86_64 or whatever else is called these days upstream. NBD (short for Network Block Device) is a nice thing. I hadn t tried it before (I certainly used and am still using in some projects of mine the not-upstreamed-yet-but-so-nice-that-I-couldnt-resist DRBD, which seems to share some ideas which NBD). In short (read NBD link for more info on that), NBD allows the Linux kernel to use a remote server as a block device. Also, its upstream is a fellow Debian developer (hello Wouter). How nice s it ? As NBD is an upstreamed kernel feature, you don t need to go to the external-module-route-hell. You only need the userland tools, which are nicely packaged and integrated into Debian as well. They re only one aptitude away, so you could use this command to bring it to your KVM host :

aptitude install nbd-client

After that, you will want to export your image file (the file which represents the disk of you virtual machine) as a NBD block device, so you will be able to mount it under your KVM host and do whatever you want to do with it. Here s how one would do it :

kmv-nbd conect=/dev/nbd0 myimagefile.img

I tested it using both qcow2 and raw disk images and both worked like a charm so I don t think you will have any problems here. Next, you need to create a directory structure under your KVM host which temporarily will be used to mount the partitions inside the virtual block device of your KVM machine. You could do this like this :

mkdir /newserver mkdir /newserver/usr mkdir /newserver/var mkdir /newserver/home

In the example above, I ve created these directories because I want my new server to have separated root, /usr, /var and /home partitions and mount points. Feel free to adapt to any kind of partitioning layout you please. Next, you will mount yout virtual machine filesystem under a temporary location, so you will be able to copy all of its content later to your final desired destination, i.e. the real partitions inside the real disk you are going to use in your future real server (not a virtual machine anymore). I did it using :

mkdir -p /mnt/temp mount /dev/nbd0p1 /mnt/temp

Notice that the /dev/nb0p1 above is my root partition inside my KVM machine, only that it s represented now in my KVM host in NBD s device node notation here. I ve only one partition inside this particular virtual machine (aside from the swap partition). Next, you want to mount the partitions on the real disk you want to be used in your new real server under the directories created earlier so you will be able to chroot to then later and do any tweaks you may want to, like fixing /etc/fstab, /boot/grub/device.map, /boot/grub/menu.lst and all these places we know makes references to block devices which may differ from the situation you had in your virtual machine running under the KVM. Here s what I used :

mount /dev/sdb1 /newserver mount /dev/sdb3 /newserver/usr mount /dev/sdb5 /newserver/var mount /dev/sdb6 /newserver/home

The device nodes above are from your real disk s partitions, not from any virtualized device block access method like NBD. Also, take care not to mount your primary disk s partitions (the ones you are using under in your KVM host) as you could destroy them easily. As you can see above, I m using /dev/sdbX as /dev/sda is my primary disk, the one under which my KVM host is running. Again, adapt to your scenario. Next, you just copy everything from your virtual machine filesystem (which is now accessible from within your NBD block device) to your real disk. I did it using :

cp -a /mnt/temp/* /newserver/

After that, you can disconnect your KVM virtual machine image file from the exported NDB device block using :

kvm-nbd -d /dev/ndb0

And then chroot to your real disk layout yout just copied to /newserver in order to fix anything which would make reference to block devices while running as a virtual machine under KVM but which now will be a completely different thing as a real server, like your /etc/fstab, /boot/grub/device.map, /boot/grub/menu.lst and so on. In order to chroot to your new soon-to-be-real filesystem you could use :

chroot /newserver

Then go nuts and start fixing everything you may think needs to be fixed so this filesystem could be used in a real server to boot it up. Im my case, I needed to fix /etc/fstab in order to mount my additional partitions (as under KVM I was using only a root and a swap partition and now, under the real server, I ll be using separated root, swap, /usr, /var and /home). Before I went changing more things, I fixed my /boot/grub/device.map and my /boot/grub/menu.lst files to point to /dev/sdb and /dev/sdb[1], respectively, so I could run grub-install from inside the chroot in order to install GRUB into the real new disk s MBR (master boot record), using :

grub-install /dev/sdb

Then, finally, I fixed /boot/grub/device.map and /boot/grub/menu.lst again so they would point to /dev/sda and /dev/sda[1], as /dev/sda will be the device node for this new disk when it wil be running under the new real server and not as a disk inside the KVM host machine. Next, I exited the chroot using :

exit

And umounted the new real disk s partitions, using (now already out of the chroot) :

umount /newserver/home umount /newserver/var umount /newserver/usr umount /newserver

Now you can take this new disk out of your KVM host machine, put it inside your new real server, physically install it there, turn on your new real server and everything installed while the filesystem in it was being used under the KVM virtual machine will be there, running nicely. And you re done. That s it. Also, it s important to point out that it s much easier being done than being said (or written, in this case) so, if it looks scary because of the size of this post, don t let it disincourage you as this whole thing is a pretty straightforward procedure, much easier than it seems. And as I know that I will receive lost of complaints from people which will tell me how inefficient this whole thing is and how I could have accomplished the exact same thing in a much easier and faster way (perhaps even with a already existing tool which would automate almost entirely the whole proccess), I would say to these people to please exercise their right to share ideas using the comments. Just be nice on me, please. After all, it was fun and I learned new things while doing it all, as well as I tried to share what I learned from this experience with my peers. That s what matters. Peace, love and geekness to all of you

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.

Another Saturday, another Lintian release. As has frequently been the case lately, much of the work was done by Raphael Geissert, who provided several more patch sets fixing new problems and old ones. I also finally got a chance to dig into the code that generates the long tag descriptions and ended up rewriting it entirely, which will remove some minor annoyances in the setup of Lintian on lintian.debian.org. I was expecting to have a chance to write a pile of pedantic checks, since several of the old bug reports are easy checks to write and were just waiting for the new tag status. I ended up working on other things and merging patches instead, though. Maybe the next release. One amusing note: the compressed Lintian changelog is 112KB (365KB uncompressed). The tar.gz file for the entire Lintian release is 589KB. So the changelog for Lintian is nearly 20% of the entire distribution. Admittedly, we have a fairly verbose changelog style, but most Lintian work involves large numbers of small tweaks and small patches. I think most of the changelog size is unavoidable. I don't think this is a problem Lintian is not the sort of thing that one runs in an embedded environment and within reason it doesn't matter how large the installed size is but it is rather funny. I stopped the last archive-wide run because gluck was being rebooted with a new kernel that didn't cause Perl to close huge numbers of file descriptors on popen, and then due to other things going on my life, didn't get a chance to restart the archive run until yesterday. It's on binary packages starting with "p" now, so hopefully sometime tomorrow there will be fresh Lintian results with 2.2.0 and I can post a bits from the Lintian maintainers message.

Paul Wayper has said that he only wants to work for companies that will send him too LCA [1]. While that criteria is quite reasonable it seems overly specific. Among other things the varying location of LCA will result in the expense for the employer varying slightly year by year - which employers generally don t like. I believe that a better option is to have an employment package that specifies a certain amount of money (related to the gross income of the employee) should be set aside for training, hardware, or other expenses that help the employee (or their colleagues) do their job. Such an option would probably only be available to senior employees who are most able to determine the most effective way of spending the money. For example an employee who earns $100,000 per annum might be permitted to assign 10% of their income ($10,000) to training or hardware that assists their job. Modern PCs are so cheap that any reasonable hardware requirements could fit within that budget with ease. There are several benefits to such a scheme. On many occasions I have had colleagues who had inadequate hardware to do their work, slow PCs with small screens really impacted their productivity, in such situations buying a $400 PC and a $400 monitor for each person in the team could make a significant direct improvement to productivity before the impact on moralle kicked in! Some years ago Lenovo ran some adverts for Thinkpads which said demand one at the interview . That made sense when a Thinkpad was an expensive piece of hardware. While there are still some expensive Thinkpads, there is a good range of cheap models, two which cost less than $1200AU and another eight which cost between $1200 and $1800. Now it makes more sense to allow each employee to choose their own hardware (both desktop and portable) and not even bother about issues such as whether the IT department blesses them. As Tom Limoncelli suggested in his LCA keynote, users are going to take more control over their environment whether the IT department like it or not, so it s best to work with them rather than fighting them. For training a common problem is that management can t correctly determine which conferences are worthy of the expense of sending their technical staff. Then when a conference is selected they send everyone. It seems to me that when there are a number of conferences in a region (EG AUUG, LCA, OSDC, and SAGE-AU in Australia) there is a benefit in having someone from your team attend each one. Planning at the start of the year which conferences will be attended by each team member is something that appears to be beyond the ability of most managers as it requires knowing the technical interests and skill areas of most staff. If each employee was granted one week of paid time per year to attend conferences and they could determine their own budget allocation then they would be able to work it out themselves in a more effective manner.

• [1] http://www.mabula.net/tbfw/blosxom.cgi/2009/01/23

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

Okay, I'm again not ready for release on Friday, so I will probably switch to Monday releases ;-). But I think it's good to announce some news which you can expect in next Gammu version. Besides usual bunch of bug fixes (many of them were revealed by testing with Valgrind) the new testing version will have few interesting features. For Nokia users on Linux is great news, that Gammu can now use directly FBUS USB interface (through libusb-1.0. This is especially good news for DKU-2 cable owners, as before they did not have possibility to use Gammu without compiling separate (and broken) module. This connection type is called fbususb and is heavily inspired by implementation in Gnokii, but uses newer libusb API and behaves more nicely when CDC ACM driver has already hooked some interfaces. I would specially like to thank to Peter Stuge for testing this feature (I'm still without a Nokia cable). The second big news is monitoring of SMSD state. SMSD now exports shared memory segment, where some information about it's runtime can be found. Little program called gammu-smsd-monitor can display you these information. The third update is for python-gammu users, which now gain ability to interact with SMSD through new gammu.SMSD object. For now it can inject SMSD messages and get SMSD status (see previous paragraph), but more features can come in future. I want to use this for creating some GUI for SMSD, which will allow to send messages and monitor it's state. But this is still future and if you want to write something like this, you're welcome!

... is almost as bad as ever before.On my Core 1 Duo system (32 bit), official Adobe Flash crashes my browser when I close a tab which had a Flash plugin running. Going to a blank page then closing the tab usually helps, but it seems that sometimes Flash continues to run in the background (sound doesn't stop either) and then will still crash.On my AMD64 system, the official Adobe plugin crashes my browser. There are reports at Adobe that link it to Gmail. So here, the Adobe flash is unusable. The 32 bit version via nspluginwrapper did not have sound for me, probably some issue with Pulseaudio.So I'm now trying out Gnash. First thing I noticed: it has FlashBlock built in, all those stupid Flash things won't auto-run but I'll always have the nice play button to enable them when I want them to run. And while Gnash is working pretty well on most sites, every now and then something just does not work. Like some YouTube movies not playing (usually very short ones - maybe it will only start playing a video when the buffer was completely filled, and a video which is smaller than the buffer will thus not play?) etc.Some wishlist items:

• Add a 'auto run whitelist' to Gnash, when I go to YouTube I usually want to actually run the video.
• Provide some 'fall through' option, so if the Flash doesn't work right in Gnash I can pass it on to the Adobe plugin if I really need to.

I know that the latter won't be easy, but isn't nspluginwrapper doing something like that?

Next week will be quiet busy. I will travel a lot. Of course, I am talking about OCaml Meeting and FOSDEM. The OCaml Meeting subscription is over and we reach a quiet good number of attendees: 45. This is the approximate number of people who come last year. There is now some details to finish (dinner for the previous day, schedule for talks...) but enough time left. The only thing I hope for the meeting is that it generates the same effect as last year: another impulse in the OCaml community. Many people are working continuously on OCaml but last year event has generated a lot of post-event discussion and many people started different project. Some of these projects are still alive, some are not as vivid as they deserve. I enjoy being at FOSDEM last year, but I only stay 1 day and it was not enough. I will be able to stay during the 2 days and attend more Debian conference than last year. I will visit Brussels and Ghent just after. Belgium is a really nice country and it has been a long time I haven't take a break.

There is currently a lot of discussion about how to protect marriage , such discussion is based on the issue of whether Gay Marriage should be prohibited to protect Straight Marriage. Some straight people believe that their own marriage would be better if homosexuals were allowed to get married, some have even declared that they won t get married until discrimination in this regard is ended. I don t believe that whether some other people get married will make any difference to my marriage. I believe that any two consenting adults who are not closely related should be allowed to get married, but I am not going to write about that today. What I will address is some positive steps that can be taken by a government to protect Straight Marriage without regard to Gay Marriage. By the most objective criteria, death is the greatest obstacle to marriage. To protect someone s marriage you should first protect them from becoming a widow or widower for as long as possible. Also protecting the lives of children (both biological and adopted) is important for protecting marriage. Here are some of the many ways of preventing needless death:

1. Don t start wars except in the most extreme situations. Wars inevitably involve the death of soldiers (some of whom are married) and any war that is anything other than the smallest border incident will involve the death of civilians (married people and children).


2. Protect the food supply and the environment. When toxic chemicals, heavy metals, or radioactive material are released in the environment it results in a statistical increase in the death rate from cancer.


3. Increase the funding for medical research. Today there are many medical situations which can be routinely and safely resolved which would have been likely to be fatal 10 or 20 years ago. More medical research will lead to more diseases being cured.


4. Spread positive technology around the world. Protecting marriage should have a larger scope than your local region, therefore life-saving medicine needs to be affordable in all countries. Patents that prevent this need to be voided in the poorer regions of the world.


5. Increase the research on car safety. Car crashes are one of the largest causes of death and significant injury in the first world which can be easily reduced. Unfortunately there has been little research on making cars safe for women and children (crash-test dummies for woman and children are to a large extent scaled-down models based on research on men due to the lack of female and child cadavers for research [1]). Also I believe that the majority of car safety research in regard to crash test dummies was done in the US and therefore is biased towards caucasians and afro-americans - I believe that research on other races is needed to give equal protection to all races (caucasian and afro-american races are in a minority in the world).

This is by no means a comprehensive list, but it does cover some issues that are current and well known. Now the next objective way to analyse this issue is to look at statistics related to divorce. It seems that money is an issue related to divorce and therefore protecting the finances of married people is a way of protecting marriage. The first thing that can be done is to give people more continuity of employment. Being in a situation where you could lose your job at short notice is stressful and has to have a negative impact on a married couple. Recently the supposedly conservative Liberal government in Australia was trying to ban Gay Marriage while also introducing legislation to make it easier to lay off employees who have done nothing wrong (based on business issues). Among other things the Work Choices legislation made it more difficult for such employees to take out bank loans (which means that they often pay higher interest rates). A final issue that causes stress for married couples is the school system (which is broken in many ways). I m not going to try and cover this in detail here, but I will note that installing flag-poles (as the Liberal government wanted to do) is not the solution to problems with the education system. Addressing these real issues will take some government funding, but it s not a lot and a much greater amount of money could be saved by ending the war on drugs . If the people who claim to be protecting straight marriage can address these other more serious problems that threaten straight marriages then I still won t agree with calls to ban gay marriage. But it would make then seem less hypocritical.

• [1] http://en.wikipedia.org/wiki/Crash_test_dummy

I received quite some feedback on my dlhack() post. Most of it negative. For clarity: no, I do not consider such practices to be the best of ideas. I called it a 'hack' for a reason I fully expect this mechanism to be replaced by the time I eventually release the code. It was just fun to do it this way, that's all. Having said that, There's one comment from a xine developer that deserves a followup:

I'm sure I have seen a few different software that can simulate keypresses from the keyboard through the user event interface of the kernel with a joystick, and thus you should just need to wire it down with the original xine-ui. Or use gxine and the gxine_client program to control it.

While this will work, there are several problems with this approach:

• The kernel can't know which application currently has the focus. With this approach, you may be sending joystick-generated keypress events to your IM client because it popped up while you were watching a DVD, and you hit the table (causing the joystick to move) while trying to click it away.
• A keyboard and a joystick are fundamentally different devices. While a keyboard can only tell the difference between 'the button is depressed' or 'the button is not depressed', a joystick has a much wider range; the Linux API will give you a signed 16-bit integer for the position of the stick. This can be useful to skip forward or backward in a much more detailed manner than the traditional 'chapter, 5 seconds, 30 seconds' approach; or one could use it to set the volume to a particular level (activate 'set volume', push the stick somewhere between fully-forward and the idle position for a volume level over 50%, or somewhere between fully-backward and idle for a volume level under 50%, then push a button to confirm). This kind of UI comes naturally with joysticks, but is impossible to implement through a keyboard-emulated UI.
• Some of the functionality I have in mind will require some visual feedback (e.g., the volume setter described above). I could do a separate window, of course, but that has its own set of problems; e.g., you need to ensure that it is on top of the video window; it will also be opaque, which is not as nice as transparent overlays on the xine window itself.

While all of the above is not a problem if I write a xine plugin, and indeed I might eventually convert the code to a one, the problem with that is that I don't know the xine plugin API yet; and writing a standalone application makes for easier prototyping. For the time being, at least. Oh, and in case you wonder why I don't just buy a LIRC-capable device and use a regular remote control: I have my gamepad. I do not have such a LIRC-capable device. My budget is not unlimited. 'Nuf said.

On the risk of repeating myself... While I do understand aseigo's dismay at the recent Linus-goes-to-GNOME-land media hype, caught by LWN amongst others is anyone taking bets if and when Linus will return to KDE? and I share LWN's (Jake Edge's) view that Red Hat/Fedora (I have no idea how far the latter really is a community project nowadays) has a long history of questionable release decisions regarding its inclusion of newer than bleeding edge software in releases, ultimately it's still KDE's fault for releasing KDE 4.0 with that ominous 4.0 version number in a move to get as many testers as possible for this public beta program (at least users didn't have to pay lots of money for this KDE Vista.) Why not just call it 3.9, if a beta label should be avoided? It would have been a release and avoided the bad press of staying in eternal beta, but the dot nine version would have made clear that it's not finished. Leaving the ranting aside, I congratulate the KDE crew for getting 4.2 out of the door, and the Debian KDE team for their decision to stay with KDE 3 in Lenny and providing KDE 4 via backports. I'm very happy with KDE 3 on my office workhorse, and have KDE 4 on the home machine and am quite impressed, but with reservations since I see parts of it crashing far too often for my taste (in the latest version I have installed, kmail rarely survives longer than 10min.)

Last Friday, I wrote I m not going to FOSDEM again because there are better value-for-money events around now right near the start of an article on here. But on Wednesday, I was surprised to learn from another website that I find it necessary to not only whine, but also boycott a conference, because [I] believe that FOSDEM should not take money from [Novell], just because they also happen to be a company, and as such make business deals with Microsoft. That s just plain false. I also found a link from the Boycott Novell website holding it up as an example of the boycott working - huh? Firstly, my wording wasn t perfect (by not going to FOSDEM again , I meant I didn t go last year either, not that I ll never go), but I feel it was pretty clear that I m not boycotting FOSDEM due to Novell. Both schestowitz (on the boycottnovell site) and Wouter Verhelst (quoted above from his personal website) were naughty to suggest otherwise! Secondly, Novell didn t do a deal with Microsoft just because they happen to be a company . Lots of companies haven t done deals with Microsoft. Novell did it to make a net profit from the deal and so I have some admiration for campaigners who aim to make the deal a huge liability for Novell. That s just influencing corporations as they were designed to work, so don t blame the campaigners for trying. So, I feel that both No-Novell-ers and company-blinders should try to find some compromise instead of flaming each other from twenty paces. It looks to me like the No-Novell-er s request (roughly: tell us how much to donate to get rid of them) was a reasonable suggestion. If the organisers are so open-minded, why not make a counter-offer instead of simple they still deserve a place defence? To close, I repeat: if you re going to FOSDEM, I hope you have a safe journey and a fun time and why not tell them what you think of the Novell-MS deal. If you re helping run FOSDEM, thank you!

I'm happy enough with the langupdate tool now that I've made the upload to Debian experimental. langupdate is an apt frontend to Emdebian TDebs to support Emdebian Grip and Emdebian Crush but also to support mixed installations of Debian and Emdebian.

Any Debian package is ignored because those packages already contain all the translation files.

Emdebian packages do not include /usr/share/locale, so langupdate identifies these packages from the dpkg status files, identifies the available Emdebian TDebs for the corresponding source package via libapt-pkg and a temporary apt-cache in /var/lib/langupdate and identifies which locales are supported on the current machine from the environment and from /etc/locale.gen. The Emdebian TDeb packages that match these criteria are then automatically installed.

If only Debian packages exist, langupdate reports "Nothing to do."

The end result, for Emdebian users, is that a typical 450Mb /usr/share/locale on Debian is stripped down to 9Mb (or less) per configured language.

The advantages over localepurge are:

1. The Emdebian packages are smaller because the translations have already been removed at the repository, so no wasted bandwidth or wasted CPU workload removing files that have just been installed.


2. If a language is added or de-configured, all the corresponding translation files are added or removed respectively.

langupdate can use any suitable repository - the default is the Emdebian TDeb repository.

Note that, unlike in Debian, Emdebian TDebs are architecture-dependent and are split into individual packages for each language and source package and architecture. Yes, it is a lot of packages and a lot of work for the machine hosting the server but better that than trying to do the work on the Emdebian device.

Currently, Emdebian Grip still has a very limited package set so the list of packages that have Emdebian TDebs is still small. Depending on how long it takes to release Lenny, more packages will get added to Grip but the "full Grip experience" will, for most people, involve upgrading from Emdebian Grip 1.0 (based on Debian 5.0 "lenny") to Emdebian Grip testing - what will become 2.0, based on Squeeze.

langupdate itself is translated into 7 languages (cs, de, eu, fr, it, ru and sv) thank you to those who prepared those translations before the deadline ended tonight and uses a langupdate-locale package as a precursor to the eventual Debian TDeb.

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.

first large-scale CC licensing of scientific papers University of California and Springer have signed an agreement to publish as Open Access (Creative Commons by-nc). This is huge news, I personally wonder how UC managed to achieve that. But nevertheless this is undeniably a precedent, which other research institution should use to reach similar agreements. The currently publishing situation for scientific papers is on the average terrible, with (at least in Italy) research institutions being strangled by the yearly subscriptions fees to digital libraries. The subscriptions are so bad that the year you stop paying them you loose access entirely, basically admitting that you have wasted all the past year payments. At least CC by-nc will create material that in the future can be collected independently and made available by each institution.

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

The Bureau of Meteorology has forecast temperatures of 43, 43, and 35 for today and the next two days. Those temperatures are in celcius. Yesterday was also above 40C so my entire house is hot. As my airconditioner is not overly large (a smaller unit is more efficient) the back part of my house will get really hot even without extra computers so I m turning off my SE Linux Play Machine. Also a couple of years ago a SE Linux Play Machine died during summer in a similar situation, and I prefer not to lose hardware. It will be on again in a few days.