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.

Of course I m still waiting for the FrontDesk to check whether I did something wrong, but at first glance, I m quite happy:

Application Manager assigned              Assigned on 2008-12-31
Application Manager recommends to DAM     Approved on 2009-02-01

Evgeni, it s been a pleasure.

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.

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

Content analysis details:   (5.9 points, 3.8 required)                          
                                                                                
 pts rule name              description                                         
---- ---------------------- --------------------------------------------------  
 1.0 NO_REAL_NAME           From: does not include a real name                  
 1.0 HTML_MESSAGE           BODY: HTML included in message                      
 0.0 BAYES_50               BODY: Bayesian spam probability is 40 to 60%        
                            [score: 0.4956]                                     
 1.4 HTML_10_20             BODY: Message is 10% to 20% HTML                    
 1.5 MIME_HTML_ONLY         BODY: Message only has text/html MIME parts         
 1.1 HTML_MIME_NO_HTML_TAG  HTML-only message, but there is no HTML tag         

That's the registration verification email from the National Do Not Call Registry.

Sometimes the pendulum swings a little too far to the east. A young Cypriot strides to the edge of the balcony, and she stares at the horizon. A drowsy calm envelopes her, and her mind, which had just grazed a very important thought, loses itself in the vast void. Up on a hilltop, an even younger boy gazes down at her, contemplating the contrast between her hair and dress, too far to make out anything else. Sometimes the pendulum swings a little too far to the west, and then even Magdalene can't save you.

According to the Service Canada website:

If you are using a Linux operating system (Red Hat Fedora Core 8 or Ubuntu 7.1) with Firefox 2.0.0.6 or higher we recommend using the Sun JVM 1.6.0_03 or higher.

Too cool!

I have been told that not enough information about the Plone user interface sprint at Informaat is getting out. That is not due to a non-disclosure agreement for attendees; all of us have just been too busy working and enjoying ourselves to get to such mundane things as writing reports or blog posts. This sprint is somewhat different than normal sprints: the goal is not to produce as much code as possible, but to lay a foundation for the user interface for future versions of Plone. This requires a lot of thought and prototyping to figure out the right concepts, both in the user interface itself and the backend code on top of which it is built. A lot of this work is done on top of the work done by the little known deco group. There are a few guiding ideas behind the work done at this sprint:

• separate all the knobs and toggles related to content editing and page manipulation out from the normal view.
• there are three different modi of interactiving with a page: view, edit, and construction (modifying layout, managing tiles). These require different types of user interface and should be handled separately.
• make the interface as simple as possible. If possible try to use a progressive complexity approach: keep things as simple as possible, and only expose more advanced options once users are ready to use them.
• always try to use simple semantic markup. There is very rarely a need to add extra elements of pollute the markup with layout or positioning-related information; that should all be done in CSS.

We divided the activities in five areas: content editing, control panels, page assembly, backend and tests. The first day was almost entirely spent on brainstorming, which is very rare for a Plone sprint. This was extremely useful, and provides us with a solid foundation for the rest of the sprint, and ongoing improvement of the Plone user interface.

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

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.

Dhanapalan writes about the small number of voters for Linux Australia elections [1]. I guess that blacklist-voting is partly to blame for my inactivity in this regard. Linux Australia is running pretty well so I don t think there s a great need for me to go out of my way to vote. One thing that could be done given that LCA is an LA event is to give a voting session keynote status at LCA. Have it happen just after a keynote speech and have some prize given away to a random person who attends - the free laptops that were given away one year are not required, a free lunch voucher would be more than enough to increase the attendance. A final factor that needs to be considered is the number of elections that we may vote in. I vote in Australian elections (state and federal), Debian votes (General Resolutions and DPL elections), and sometimes my local LUG. The amount of attention that I can focus on political issues is limited and divided with other elections that are more important.

• [1] http://www.dhanapalan.com/blog/2009/01/27/participation-in-the-nation/

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

I ve been having fun with identi.ca and twitter recently, but some of my contacts, friends, followees, subscriptions (or whatever you want to call them) send many more messages than others. One contact gave a running commentary on his progress up the floors of a building yesterday. Fine, but a bit of a torrent of data. If someone posts and leaves it for a while, it s sometimes an explanation of where they ve gone, so I d like to check people s last tweets. I ve seen some clients do that and it seems there s a method in the API to do it. The API returns XML, so I m using XSL to transform it to xhtml (I ve still not taken the time to learn the XML CSS ways) with the following commands:-

	wget --no-check-certificate -O - https://username:PASSWORD@identi.ca/api/statuses/friends.xml   \
	sed -e '1a\
<?xslt-param name="site" select="identi.ca"?>\
<?xml-stylesheet title="Site Summaries" type="text/xsl" href="twitters.xsl" ?>
' > identica.xml

And here s twitters.xsl which converts the downloaded xml to xhtml:-

<?xml version='1.0' ?>
<xsl:stylesheet version="1.0"
 xmlns="http://www.w3.org/1999/xhtml"
 xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:param name="site">twitter.com</xsl:param>
<xsl:template match="/" xml:space="preserve">
<html xmlns="http://www.w3.org/1999/xhtml"><head>
<title><xsl:value-of select="$site" /> Friends</title>
<link rel="stylesheet" type="text/css" href="mirrors.css" />
</head><body>
<dl class="statuses">
<xsl:apply-templates />
</dl>
</body></html>
</xsl:template>
<xsl:template match="/users/user" xml:space="preserve"><dt><a href="http:// $site / screen_name "><img src=" profile_image_url " /><xsl:value-of select="name" /> (<xsl:value-of select="screen_name" />)</a> - <a class="time" href="http:// $site / screen_name /statuses/ status/id "><xsl:value-of select="status/created_at" /></a></dt><dd><xsl:value-of select="status/text" /></dd>
</xsl:template>
</xsl:stylesheet>

Have fun! (And what have I done wrong?)

Here s for the second installment of my review of this past year s Summer of Code at Debian. See the previous part here: Debian Summer of Code 08 : Where are they now (part 1/3). I apologize for being so late at getting this second part out but I have been very busy. Still, I ll get the last part out before FOSDEM. Those of you who ever had to write a Java compiler (ok, Java subset, but the OOP part was here ) in brainfucking Ada will understand what I went through working on two of my most loathed languages. Debian NAS, improve support of Debian on NAS devices Presentation There is a large range of inexpensive Network storage devices available on the market. For some of them, such as Linksys NSLU-2 and Thecus N2100, we have added support, but there is many many more devices we could support. For this summer we look forward at supporting multiple Marvell Orion based devices (as outlined in Martin Michlmayr s talk Running Debian on Inexpensive Network Storage Devices), such as Revogear Kuro Box Pro, Buffalo Linkstation, QNAP TS-109+, If you don t have old computers lying around to turn into NAS servers, you need to sleep at night without the soothing sound of computer fans or if you actually pay your own electricity bill, you might want to have a look at standalone NAS devices. They re cheap and can be made vastly more capable by slapping a Debian on it. If you ever heard of DD-WRT, you know the spirit. The project was mentored by Riku Voipio, with help from Martin Michlmayr. The project proposal (sorry, Google cache) was introduced by Martin, who did a presentation about it the previous year at FOSDEM. Student Per Andersson was a 24 year old student working towards a MSc in computer science at Chalmers University of Technology in Sweden. He had been looking for ways to join Debian but with school still being priority one, he didn t find time to dive in. Result This project was successful. The Kurobox Pro is now supported and several useful tools were packaged to make life easier with these NAS devices. Martin Michlmayer is still working on Debian NAS related stuff. Per was happy to be invited to the Emdebian work session in Extremadura and has been active within debian, maintaining the packages he created during the Summer of Code. Cran2deb, generate Debian packages from R packages Presentation GNU R has become the preeminent platform for computing with data . The CRAN archives contain over 1300 source packages of very high-quality, and BioConductor has again almost as many focuses on bioinformatics. We want more of these in Debian, and going beyond the 50+ packages we currently have suggests more scripting and automation. R is a pretty big among statisticians and all of them they wasted no time writing their own package to work on particular research subject. It s a lot like Perl with CPAN or LaTeX with CTAN. It s always a pain to discovery that a particular R package is not wihtin Debian and having to resort to unmanaged installation of said packages. The project was mentored by Dirk Eddelbuetel. The project proposal (which is nowhere to be found but seemed to be good) was introduced by Dirk, along with another proposal he did for R. Student Charles Blundell is a research student at.. hum.. didn t do my homework about that. Anyway, you can find him around R related projects. Result This project was successful. Cran2deb is happilly turning more than 1400 of the ~1500 CRAN R packages, all with correct dependencies. The work has since been moved to R-Forge. It s working, we re almost there. We just need it to be polished and we ll get a whole bunch of new packages into Debian. Charles pinged me about the status of Cran2Deb after the previous post. He admits that he hasn t done much about cran2deb recently because of his new position as a research student but hopes to commit again to it soon. I do encourage him to get these R packages into Debian. I had to manually install some packages myself when I had to use R for school because they weren t into Debian and it s not pretty. Mergemaster, interactively merge changes in configuration files Presentation FreeBSD has a shellscript called mergemaster which is used to interactively merge changes in configuration files, based on 3-way diffs. Debian s approach to configuration file differences is much more primitive: either keep the original file, or blow it away (including all local changes) and use the Debian-provided file. It would be nice to get a system such as mergemaster into Debian. Important is to remember that Debian contains two often-used configuration file management systems: ucf, and conffiles; porting mergemaster in such a way that it will be used in both cases would be great. The handling of configuration files during upgrades has always been a little.. brutal, with the user being asked at gunpoint to make a good decision, lest the upgrade won t continue or configuration files get borked (ever tried automerging nagios configuration files?). Having a less stressful upgrade experience is a good thing since the point of Debian is to make package management a stressless thing. The project was mentored by, hum, Manoj Srivastava. I have no idea who came up at first with the proposal. UPDATE: Wouter Verhelst mailed to say that he made the original proposal. Student Max Wiehle was a physics student at the University of Heidelberg. He did a Summer of Code stint (Archive.org copy..) as a student for Beagle Project in 2006 which, I suppose, was successful. He s been active in the past with Gnome and desktop related projects. Result This project was somewhat successful. He posted an update one month into the program with repositories with code to test. Last commit to the mergecf branch of project was September 19th but it was never merged in. According to Steve McIntyre, it s dead, Jim. I couldn t find any further public involvement of Max within Debian. PAS NSS Debian Installer, improve support of PAM and NSS at install-time Presentation It would be very important for the Debian allowing the user to configure additional PAM and NSS modules (eg. LDAP, NIS) during the installation process inside the Debian Installer. To do this, we have to provide tools and helpers to modify /etc/nsswitch.conf and /etc/pam.d/common-*, as well as changing the maintainer scripts for the packages libpam-* and libnss-* to apply the required changes at install time using debconf and these helpers. To be honest, I will probably never use this. I don t do that many coordinated installs in the same place to warrant doing funny authentication with PAM and NSS, and if I did, I would probably use a more elaborate tool to personalize the install, like FAI. On the other hand, I can see the appeal of being done with authentication mechanisms before the first boot. The project was mentored by Fabio Tranchitella. The proposal came from the student. Student Juan Luis Belmonte was a computer science student. He worked in a couple of companies in the area of Sarragossa. He is now founding debug_mode=ON. Result This was quite a disappointement after seemingly good work. Although Juan was satisfied with the project, the PAM package maintainer (Steve Vorlon Langasek) was not. He was never asked about this project (but didn t intervene timely either when the accepted projects were announced though). In his words, it was the wrong solution to the problem . You can find his lenghty rationale on the wontfix bug report that resulted from the project. It really was a problem of communication with the Debian developpers since Juan could certainly have done the right work if pointed to it. Juan didn t ask thoroughly for existing work and Steve didn t publicize his (enough). That s all for now. The information is quite fragmented I admit. Most of it was pulled from Google, mailing lists, commit logs, blogs, whatever. If some projects are lacking in information here, it s because I couldn t find it readily (which is an issue in itself!). In my next post, I ll try to give a student point of view of the Summer of Code in general, and more specifically, at Debian. It will be post 2.5/3 since it s getting a little longer than I planned. Release early, release often, as the say.
If you re a student or a mentor mentioned above, feel free to fill any of the blanks in my report. It s much appreciated. You re not a student or mentor mentioned above and have an opinion on how to improve the next Debian Summer of Code ? Feel free to comment.

Sigh. I'm not part of the FOSDEM organisation team, and this is by choice. I know that I wouldn't find the time to help organize a conference of the scale of FOSDEM, since I'm rather liable to forget to do important things at times. Having said that, I happen to run a company together with Philip Paeps, who is now one of the main FOSDEM organizers; apart from that, I've also managed the Debian presence there for the past few years (lost count how many exactly), and arranged the key signing party for a few years with Joost Van Baal taking over for me starting this year. As such, I'd like to believe that although I'm not exactly in to all their secrets, I do have a front-row seat when it comes to how things are going there. FOSDEM is the "Free and Open Source Developers' European Meeting". It has been that since 2001, and will always remain so. Yes, originally it was called "OSDEM", because frankly, the organisation of the original OSDEM was done by a group of people who like Open Source, without necessarily subscribing to the Free Software ideals. The core group of the organisation is a rather diverse group; for instance, Philip has been known to be rather... negative... about Ubuntu, while Mark (one of the press contacts) has done some activism and translation work for Ubuntu. The change of name from OSDEM to FOSDEM was done not because the organisation's ideas about software were changed overnight by a mail from Richard Stallman or anyone else from the FSF; but rather, because they were open-minded enough to understand that having a name which only says 'Open Source' would be excluding a considerable part of the community that encompasses both Free and Open Source people. This is why the name wasn't changed in FSDEM; it is FOSDEM. I'm quite sure that the fact that FOSDEM is so open-minded about many of the controversial issues that have separated our community over the years not just Open Source vs Free Software, but so many other things as well is one of the main reasons why FOSDEM is so popular today: because everyone, and I truly mean everyone, will find something that he or she likes. That is why I'm so saddened that some people seem to find it necessary to not only whine, but also boycott a conference, because they believe that FOSDEM should not take money from a big Free Software/Open Source contributor, just because they also happen to be a company, and as such make business deals with Microsoft. Note that I'm not either defending or condemning Novell's attitude here; but it is a fact that not everyone in the larger Free and Open Source community feels the same way about the whole Novell/Microsoft deal (else there wouldn't be an openSUSE anymore), and as such they still deserve a place on FOSDEM. Over the history of the organisation of FOSDEM, it's always been a place where everyone could get their opinion out; whether it be the opinion that "Free Software Must Rule The World", or that "It's All About The Way You Do Things"; as long as your opinion is shared by a large enough number of people in the larger FLOSS community, it is welcome. I feel that blocking one organization from sponsoring the event, just because they have made some deals which a significant group of people, one which nevertheless does not encompass the whole of the FLOSS community, disapprove of, would set a dangerous precendent that might jeopardize the very core of what makes FOSDEM so great: its impartiality. Thank god that didn't happen.

It's been a somewhat long day... I got up at 6:30am for a 7am ankle physical therapy session. I went to the hospital after that. When I got there, a sonographer was doing the echocardiogram on her heart to check the valves. I missed the doctors. Sarah didn't feel any more knowledgeable about her condition even though they'd been through. The patient Sarah was sharing with had a bad night, caused her to have a bad night's sleep also, and she always deals with all of this crap much worse when she's got a sleep debt. Dinner stayed down, but breakfast did not. The sonographer seemed fairly confident about her heart condition. Usually they don't make any comments on what they're seeing and leave that to the doctors, so we took some comfort from that. I managed to corner the physician's assistant who had been following Sarah in her office, and quizzed her on what was going on. It turns out a PICC line had been ordered, and they get installed by specalised PICC nurses and that's all they do all day. The PA implied that it might not happen until tomorrow. The gall stones were definitely unrelated, and something to follow up with her primary care physician. Incidentally, Wikipedia has some wicked pictures of gall stones. Talk about freaky. I think I hung around until 10am, and then headed into the office to try and get some work done, with the intent to come back after work. Not long after, Sarah called me up all beside herself about the PICC line (she doesn't deal well with the idea of getting jabbed at the best of times, and being tired put her over the edge), so I scrapped work, and went back to the hospital for the remainder of the day. I decided to hunt down her cardiologist to see if the PICC line was absolutely necessary, and I managed to get the exact low down on her condition.

• the infection is staphylococcus aureus, not one of the other staph strains that I can't remember, which are considered less serious. The one Sarah has/had is the "bad enough" one, a.k.a. "golden staph". Fortunately it's sensitive to antibiotics, unlike MRSA, which is the really bad news one to have. So my heart skipped a beat when he said it was aureus, but I recovered when he said it was sensitive. I could have sworn the staph infection she had last year wasn't aureus, but he seemed to think that it was.
• when she presented at the ER on I guess Sunday morning, this staph was found in the blood sample they took. What is unclear is whether this is because of contamination from the skin when they took the sample (staph is present on the skin, it's only a problem when it gets internal), or it was indeed in her blood, whereas with the infection she had last year, it was never present in her blood.
• because of her aortic root replacement/graft and the risk of endocarditis destroying her heart valves, they didn't want to take any chances. Hence the PICC line and the two weeks of intravenous antibiotics. Two weeks is really a compromise. He said if they'd wanted to get all paranoid on her, it'd be a six week course, and they'd have done a transesophageal echocardiogram to boot.

So armed with the facts, I headed back to tell Sarah the news that she really should have the PICC line installed, and that she was getting off fairly lightly, relatively speaking. The PICC nurse had a cancellation, so she was able to do the installation today. It was totally less traumatic than I think either of us were expecting. It took about 45 minutes to install, and it was done at her bedside. Sarah was very brave and I don't think it really hurt her all that much. I watched the whole thing, and it was very interesting. It was particularly interesting because there was another nurse observing, so the PICC nurse was explaining everything as she went. She was also really nice and good at what she did (she'd been doing it for 14 years) so I think all of that helped. So Sarah's now got two IV ports strapped to the inside of her upper left arm (attached to the PICC line), and no other IV lines in. She should get discharged tomorrow after they sort out whether she's going to receive IV antibiotics on a 4 or 8 hourly schedule at home, and exactly how all of that's going to work. I think they send someone out to our place to give us some training, and someone comes out once a week to do a bit of maintenance on the PICC line itself. I presume I'll be her personal nurse again. All it involves is a bit of plumbing. Her cardiologist seems to think she should be able to still do her CNA clinical training with the PICC line in. She may just have some problems with lifting duties. I guess we'll just see how all of that pans out. So that was the excitement for today. Sarah had her appetite back at dinner time, and was generally in much better spirits when I left her this evening than she was this morning. I could go into much more detail about the ins and outs of the PICC line installation, but I don't really have the energy.

Moving on from the horrible tax situation, I m struggling to get three pieces of hardware working. I m terrible with hardware. Can anyone help me get these working better, please?

1. I ve been lent an Asus M5200N after I busted my shoulder with a 7kg laptop at #davebcs. I ve managed to enable processor scaling as ondemand, but like the page says, the fan is noisy. Other sites report that the Centrino s thermal limit is 100C, so is it OK to set the fan not to kick in until 78C on the sensor? The default is 40C which means it s permanently on - the coolest the fan makes it is about 74C.
2. The Asus has Ubuntu on it (intrepid I think). Is there an easier way to get my three GPRS connection working than copying the config files from the old laptop and using the terminal? Network Manager doesn t seem to work and I can t see what it s trying to do or why it s failing (where s its debug log?). Alternatively, is there a distribution better suited to occasional laptop use than Ubuntu?
3. I ve been lent an iPod Touch. However, when plugging it into the USB on the Asus, the screen says simply iTunes and the quick start guide says to connect it to iTunes. Can gtkpod do this, is there another way to start it up from Ubuntu, Debian or GoboLinux, or shall I beg access to a computer running iTunes?

Thanks for any answers. I may send out small gifts in return because questions 2 and 3 seem very awkward to me.

Intel have a magic communciation channel between the system firmware and the graphics hardware. It's based on a region of shared memory and judicious use of interrupts, and it's documented here.

Nvidia have a magic communication channel between the system firmware and the graphcis hardware. It's based on WMI and bonghits, and it's not documented.

Why, yes, I have spent half the day trying to work out how the NVIF method works.

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...

About a week ago I updated the KDE 4.1 backports for Lenny with the fourth and last revision of KDE 4.1.
As previously announced, this will be the last update available at http://kde4.debian.net What is next? The repository will continue there, so Lenny users can choose between KDE 3.5.9+ and KDE 4.1.4. But since 4.1.4 packages are not official, they do not have support: no bugs in the BTS or security updates.
If you are using Debian Lenny for stability and security purposes, you should use KDE 3.5. Testing users (future squeeze, current Lenny) can continue using them until KDE 4.2 reaches testing. Again, remember, no bugs in the BTS or security updates, but they will get a clean upgrade to KDE 4.2 in the near future. Unstable users. I have found that there are people using unstable with the backports, when they should be using experimental KDE 4.1. If this is your case, you can stick with 4.1.4 until KDE 4.2 reaches unstable or switch to experimental in a few days and get KDE 4.2 (no yet! it needs to be released first :) ). Last, but not less important, thanks to all the people helping with the backports: MoDaX for helping as backup and the rest of the Qt/KDE team who worked in the experimental packages. HE, zobel and aba for his sysadmin tasks. apol for allowing me torture his PowerPC machine. All those who translated the instructions into their languages and
helped to others users in mailing lists and forums. A quick note about KDE 3.5 to be released in Lenny As most of you have realized, the packages of KDE 3.5 in Lenny and unstable are a mixture of KDE 3.5.9 and 3.5.10. Given that KDE 3.5.10 was released after Lenny was frozen, we could not push this new version into Lenny, however the KDE 3.5 packages were patched about June last year with the latest changes in KDE 3.5 from the KDE subversion. This means some of the modules with the version 3.5.9 are exactly the same that is shipped as 3.5.10.
The only big stuff missing are the kicker improvements shipped in kdebase and some bug fixes in kdepim. But in global, it is closer to KDE 3.5.10 that to KDE 3.5.9. If you want to see what changes are you missing, check the KDE 3.5.10 changelog.