Tim Skirvin sent me some enhancements to this script, so I took a moment to write documentation and put it up on my miscellaneous scripts page. This is my version of the integration script between git-buildpackage and pdebuild with cowbuilder. There isn't very much to it, but it does handle automatically adding the etch workaround option where needed and supports selecting the chroot in which to build via an environment variable. As usual for these sorts of little scripts, it hard-codes some of my preferences and will probably require modification to work smoothly in your environment. Unlike the larger packages I maintain, these random scripts are little things I use to speed daily tasks or obscure scripts for specific needs I have. I make them public on the outside chance that they'll solve some problem someone else is having or will serve as a useful example. Further updates generally won't be announced in my blog.

I'm supporting a class of high school students who are new to programming, and will be learning some python. Most of these students are comfortable with computers, but not hacker types, and few if any of them have written code before. I'm looking for an editor or an Integrated Development Environment (IDE) that won't be too scary for them, and will help them get used to the novel idea of writing code without simultaneously having to get used to the novel idea of an unfamiliar user interface. So i can't expect them to pick up my beloved emacs, for example. But on the other end of the spectrum, i'd hate for them to try to write python in an word processor (i've seen people do it!). Here's what i think i'm looking for:

• comfortable graphical interface -- these students have not used the command line before, and while they'll be introduced to the python shell, they should be able to write code and browse for files, etc. in the "normal" (sigh) way. This means, for instance, that tk-based interfaces are less good because they don't integrate with the common GTK-based UI.
• syntax highlighting -- the students will need to figure out what's a variable, what's a function name, what's an operator, what's a reserved word, etc. Visual indications like font-lock-mode from emacs would be really useful.
• whitespace management -- since python has syntactic whitespace, it would be great if there were convenient/intuitive ways for students to adjust the whitespace in their programs. Of course, it's hard to say what's going to be intuitive for other people. I like tab-cycling whitespace myself; are there other approaches i should be proposing?

Do you have suggestions for tools that work well for the above needs? Favorites? Are there features other than the "top three" i listed above that you think i should pay attention to? FWIW, they'll be working in a labful of machines running Ubuntu Hardy for the most part, but i'm willing to port and deploy programs (particularly ones that feel like a perfect fit) if they're not available in hardy.Tags: ide, python, recommendations, student

I've been meaning to try NoMachine NX for a while. Its promise of fast remote X11 sessions sounded exactly like what I wanted to log into my work desktop remotely (I really like having a remote desktop with saved state you can just pick up from when using remote access). That was pretty much all I knew about the software, so I was a completely blank slate. The getting started guide is the perfect example of how not to write a getting started guide. Firstly, Section 1 - "Getting started" - gives me a full history of the product, goes into significant depth about the challenges of forwarding X11 requests, talks about the caching and compression implementation, round-trip latency measurement, the details of two-way proxying system and discusses every other feature of the software. My eyes glazed over after about the first paragraph. That's all great -- I just want to know what to do! At this point, I assume that I'm required to run some sort of daemon at the remote end. I download and install the server package (it is explained that the server package requires the client and agent packages as well, fine). I'm paging down, looking for something to get me started. I'm happy to see Section 7 - "Set up your NX Server environment" (remember, at this point I though I needed some daemon running in the background constantly). It even has some commands commands to type, so I tap away, running nxserver --useradd nxtest --system. My server binary doesn't even seem to recognise these options. I give up, assuming that the server isn't running and nothing will work. The getting started guide has abruptly ended and I have no idea what to do. As it turns out, it's all completely trivial. Here's the missing "getting started guide".

• Download and install the client, agent and server packages on the remote end. You need to have ssh access to this box.
• Install the client on your end.
• Run /usr/NX/bin/nxclient. It will start a wizard where you input the remote host name.
• The client will, under the hood, ssh to the remote end, open the tunnel it needs, start the server and do all the magic required to make things "just work". A remote desktop will appear.
• That's it!

Additional tips:

• It's easy to tunnel this connection (for example, if you have to bounce through a ssh gateway to your internal network). Do something like /usr/NX/bin/nxssh -o 'Compression=no' -L 2022:remote.host:22 -f -N user@sshgateway.company.com and then connect the client to localhost:2022. You don't want to compress this link, as NX is already doing it.
• The only way I can find to make a new session is to start nxclient with the --wizard command.
• Don't click "Disable encryption of all traffic" if you're tunneling. AFAICT this tries to redirect the client to a non-encrypted port, which obviously won't get through.

Other than the documentation, it really works as promised, making remote X11 usable. One really nice feature is that it is smart about the resolution of the remote desktop, filling up your local screen. Add to that you don't need anything setup but your normal ssh connection, and it's a great remote desktop solution.

Have you seen the New American Passport? If you have, you know it is kinda creepy. First, the abundance of patriotic pictures (eagles, presidents, flags, you get the picture) is in fact so patriotic, it might burn a hole in your hand if you hold onto it for too long. Aside from the visual creepiness, well, it is also RFID enabled and depending on your take, this is creepy (or not). But whatever your view, here is a great example of how easy it is to crack, . RFID is, as Chris Paget puts it succinctly available to be queried by a suitable reader.

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.

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.

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

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!

In my living room, there's a TV, with a computer connected to it. In that computer, there's a DVD-ROM player, a hard disk, and a card with a TV output. On that hard disk, there's Debian with xine to view DVDs When I originally put it there, I would pick up the keyboard to do some user input. This works, but a keyboard is klunky. So, instead, I've been working on jsxine, a little application that does not much more than open a window, and tell xine to play a DVD there, but use the joystick for UI[1]. My 'joystick' is a Logitech Wingman Gamepad Extreme, which has a cable long enough for me to be able to use it comfortably from the couch, so I can use it as a sort of remote control. The current version has quite some things hardcoded: button 0 is 'select', button 5 is 'eject', button 6 'previous chapter', button 7 'next chapter', and button 8 is 'start or stop playing'. The primary two axes move around in the DVD menu; and other stuff is not yet implemented. This layout, of course, makes a lot of sense on this particular gamepad, but I doubt it does on other joystick devices. And since I want this to eventually be useful for other people, too, I recognized that I would need some way to configure things. My initial stab at configuration would create a hash table of available actions, read out a configuration file, and then find the appropriate function pointer in the hash table. While this works, it has one rather important downside: adding a configurable action would requrie another item in the hash table; this would eventually make the hash table horribly long. So I thought, why not use the configuration value to ask the dynamic linker to get me a function pointer? With a little help from my friends, that's exactly what I did. Proof-of-concept code:

#include <dlfcn.h>
#include <stdio.h>
int function()  
	printf("In function!\n");
 
int main(int argc, char**argv)  
	int (*funcptr)(void);
	void* handle;
	printf("foo\n");
	handle = dlopen(NULL, RTLD_NOW);
	funcptr = dlsym(handle, "function");
	funcptr();
	return 0;
 

Compile with cc -ldl -rdynamic. Et voila, that gets you an application which can do a lookup of function names at run time. Long live C. Of course, there's a bit of a danger in the above example. A user could just write a config file that has things like 'open' and/or 'write' as arguments, or the like. One should make sure that it can be obvious from the function name that it does indeed define an action; for example, by giving them a common prefix, and prepending that prefix to the function name before handing the name off to dlsym(). But other than that, this seems to work. It apparently also is documented in the FreeBSD documentation on dlopen(), so maybe it's not as much a hack as I thought... Oh well. Note that on GNU systems, you can also put a #define _GNU_SOURCE before the #include <dlfcn.h>, you can drop the dlopen() call and go straight to dlsym(), with RTLD_DEFAULT as the handle. [1] Yes, I could have done a Xine plugin. I didn't want to. This is as much a project to produce something useful as it is a project to hack and have fun.

I'm using Drupal from several sites as a CMS/CMF, e.g. Buildd.Net and SysAdmin-Jobs.de. Drupal upgrades its database with a dedicated script, which usually works well. But I experienced some problems with taxonomy terms and nodes after upgrade finished. For example all forum articles are "lost". They are still there but have lost information to which taxonomy term they belong. And because Drupal uses taxonomy terms for its forum tree, no forum article is displayed any longer.
Same problem is with Blog articles that are tagged with taxonomy terms: the node is still there, but the taxonomy information is lost.

Looking at the databases table term_node for Drupal5 and Drupal6 makes the difference visible:





So, obviously the update script of Drupal misses to store the additional table row vid somehow. At least all the difference in the table schema causes the loss of taxonomy terms of those nodes.

So, I wrote a little script called bin/drupal6_fix_taxonomy.sh to fix that problem for my PostgreSQL databases:



It works for me![TM]
Use it at your own risk!

The changes to whitehouse.gov are being used as an example of ephemeral digital content.

At the exact moment Barack Obama was inaugurated, all traces of President Bush vanished from the White House website, replaced by images of and speeches by his successor. Attached to the website had been a booklet entitled 100 Things Americans May Not Know About the Bush Administration - they may never know them now. When the website changed, the link was broken and the booklet became unavailable.

At the same time, the Obama administration is chafing under rules that don't allow them to use Facebook, gmail, Blackberries, and Twitter. Because of this pesky Presidential Records Act.

Suddenly, they have to relearn how to communicate, because the law has not caught up with the way people live. They are being forced to return to older technologies (or they will once those technologies start working properly), and abandon or become more guarded in their use of newer technologies.

Anyone else find the dissonance am(az us)ing? Seems that anyone who really wants a copy of that missing booklet will be able to access it via FOIA in a few years (unless it got wiped with all of Cheney's files). Meanwhile, if the new guys find a way to stop being hobbled by the law, their digital content will likely be truely ephemeral, since they have become addicted to "newer technologies" that eliminate all expectations about data's preservation and privacy. I think this is one case of the law not keeping up with technology that I can support. It might be more fair to describe it though, as technology not keeping up with the law.

Was attempting to merge a branch in one of my projects and upon committing the merge, I kept getting this error:

mojo-jojo david% svn commit -m "merge in the maven branch"
Sending        trunk
Sending        trunk/.classpath
Sending        trunk/.project
Adding         trunk/.settings
svn: Commit failed (details follow):
svn: Server sent unexpected return value (502 Bad Gateway) in response
to COPY request for '/svn/eddie/!svn/bc/314/branches/maven/.settings'

A quick search found several other people having the same problem. Seems it only happens for https repositories using mod_dav_svn. The solution is to make sure that your virtual host in apache has explicit SSL config options, even if you are using an SSL config from a default virtual host. For example, I added the following to my subversion vhost, which was just copied from my default vhost:

SSLEngine on
SSLCertificateFile /etc/apache2/ssl/catnip.org.uk.crt
SSLCertificateKeyFile /etc/apache2/ssl/catnip.org.uk.key

If you are in the NY-area and would like to help out with the project described below, they are looking for volunteers. Help FLOSSIFY the enormously popular book Digital Foundations. The event is being hosted Feb 6-8 at the lovely Eyebeam with some Free as in Beer and Grub provided! ******************************************************* FLOSSIFY 1 : Digital Foundations
For a long time educational courses have been cheap marketing
for proprietary software companies. Can a student really afford all
those expensive softwares required by the courses? No. Ever hear of a
software company kicking up a fuss because students are using
unofficial versions? Well, it does happen but not often. And why not?
Because proprietary software companies know, as the universities know,
that once the students leave their training they will be indoctrinated
with those tools and simply slipstream into being paid up proprietary
software citizens. Simply put, unlicensed software used in education is
tolerated because it is cheap marketing. This is how tools become industry standards . FLOSS Manuals is fighting this flow by converting textbooks that
use proprietary software to using free software in their examples. We call this process FLOSSify . We convert the book from
closed software to Free Libre Open Source Software (FLOSS) hence we
FLOSSify the book. Our first text book is the wonderful Digital Foundations book produced
by Michael Mandiberg and Xtine Burrough
(http://digital-foundations.net/). Its a text book designed to teach
software by teaching design. The current toolset it uses is the Adobe
Creative Suite and we will convert these examples entirely to using free
software. FLOSSIFY 1 : Digital Foundations will focus on a fun 3 day event at
Eyebeam, NYC. Anyone is welcome to attend and some food and beer will be
provided. Come and meet some of your old geek friends, make some new,
and help make a step towards unshackling education from proprietary
software. FLOSSIFY 1 : Digital Foundations
Eyebeam, New York City
Feb 6-8
starts 10ish
finishes when we are done
fast connection, a table, some chairs, and beer and food provided
contact adam@flossmanuals.net for more info venue:
http://eyebeam.org/
540 W. 21st Street, (between 10th and 11th Avenues)
New York, NY 10011
Tel. 212.937.6580 Fax: 212.937.6582

Since I keep ending up in situations where I need to clean up postfix queue from mails sent by a single host and always forget the command, I'm posting it here. Maybe someone else will find it useful as well. To begin with, you need to determine the IP address of the culprit you want to eliminate. How you do this, is up to you. Grepping logs or examining the files in the queue both work. But for some reason there doesn't appear to be a good tool to get statistics on the sending IP addresses, only the origin and destination domains. Once you have determined the IP address which you want to purge, you can use the following spell. You might have to repeat the same line for active and incoming queues as well, but usually deferred is the queue I have the most mails. grep -lrE '[^0-9]10.20.30.4[^0-9]' /var/spool/postfix/deferred xargs -r -n1 basename postsuper -d - It's important that the IP address has escaped dots, because dots can account for any character. In the worst case it will end up matching a lot of wrong IP addresses. Another important bits are the '[^0-9]' groups in both ends of the pattern. Those make the IP address only match that particular IP address. Without that extra limitation 1.1.1.1 would match anything that has 1 as the last number in the first octet and 1 as the first number of the last octet. For example: 211.1.1.154 would be a valid match. The other important bit, yet oddly unknown, is the postsuper command. Postsuper modifies the queue and -d flag makes it delete files in the queue by QueueID. For some reason I keep on seeing all sorts of find -exec rm spells all over, which isn't really that nice for the daemon itself. So here it is, one more tidbit I've been meaning to write up for quite some time now. Enjoy!

A few months ago, I asked for suggestions for magazines to subscribe to. I got a lot of helpful suggestions, and subscribed to three: The New Yorker, The Atlantic, and The Economist. Today, I m reviewing the only one of the three that I m disappointed in, and it s The Economist. This comes as something of a surprise, because so many people (with the exception of Bryan O Sullivan) recommended it. Let s start with a quote from the issue that found its way to my mailbox this week:

A crowd of 2m or more is making its way to Washington, DC, to witness the inauguration of Mr Obama. Billions more will watch it on television. [link]

Every issue, I see this sort of thing all over. An estimate, or an opinion, presented as unquestioned fact, sometimes pretty clearly wrong or misleading. For weeks before Jan. 20, and even the day before, the widely-reported word from officials was that they had no idea what to expect, but if they had to guess, they d say that attendance would be between 1-2 million. In the end, the best estimates have placed attendance at 1.8 million. Would it have killed them to state that most estimates were more conservative, and to cite the source of their particular estimate? That s all I want, really, when they do things like this. I knew going into it that the magazine (to American eyes) essentially editorializes throughout, and I don t have a problem with that. But it engages in over-generalization far too often and that s just when I catch it. This was just a quick example from the first article I read in this issue; it s more blatant other places, but quite honestly I m too lazy to go look some more examples up at this hour. I do remember, though, them referring to members of Obama s cabinet as if they were certain to be, back before Obama had even announced their pick, let alone their confirmation hearings happening. One of my first issues of The Economist had a lengthy section on the global automobile market. I learned a lot about how western companies broke into markets in Asia and South America. Or at least I think I did. I don t know enough about that subject to catch them if they are over-generalizing again. The end result is that I read each issue with a mix of fascination and distrust; the topics are interesting, but I can never really tell if I m being given an accurate story. It often feels like the inside scoop, but then when I have some bit of knowledge of what the scoop is, it s often a much murkier shade of gray than The Economist s ever-confident prose lets on. Don t get me wrong; there are things about the Economist I like. But not as much as with the New Yorker or the Atlantic, so I ll let my subscription lapse after 6 months but keep reading it until then.

We're still managing to keep to the weekly release cycle and put substantial changes into each version. This makes me happy. I'm hoping that we'll be able to keep slowly working the bug count down. This release merges quite a bit of work done by Raphael Geissert, most notably the addition of pedantic tags. Lintian has quite a few open bugs for checks that are useful in only some contexts or that check coding style issues that not everyone agrees with or wants to be bothered with, and we've been holding off on implementing those since I'd like to encourage everyone to enable info-level tags and I didn't want to just put them all in there. Now we have a new level, --pedantic, which includes all the picky stuff and the stuff that may be completely wrong. It's up to each maintainer whether to use --pedantic at all. The tags won't be in the default lintian.debian.org view (right now, they're not there at all). If you do use --pedantic, please don't worry too much about making your package pedantic-clean unless the tags really seem like a good idea. Also, as noted in the man page, adding overrides for pedantic tags is probably not worth the effort. You should look over the report and apply human judgement. I expect this mode to be useful for sponsors, who want to be alerted to possible issues but can decide for themselves which ones to mention. This release will also add a new page on lintian.debian.org that shows tags sorted by severity and certainty. Not only will this be useful for people looking for problems in the archive, it will also help the Lintian maintainers with updating severities and certainties. (For example, looking at the test page, I think a lot of the important tags should probably be serious instead.) I'm currently doing a full archive run from scratch with the new version to make sure that I plugged the memory leak problems that Lintian had before and to finish fixing #507849. Once that run finishes, I'll send a "bits from the Lintian maintainers" post to debian-devel-announce with information about the pedantic mode and the new tag page.

I have been wondering for a while how to get X.org "input-hotplug" to work, but I never actually tried before today. It is actually fairly easy, once you know what to do. Requirements First, make sure you have the evdev X driver installed (xserver-xorg-input-evdev). You might want to use X packages from experimental since things are much more recent than in Lenny or Sid these days, and upstream improved input management in the meantime. Then, if you are not running a pre-packaged kernel, check the the evdev driver is enabled and loaded in your kernel (CONFIG_INPUT_EVDEV). Telling hal what to do with input devices Now, you need to tell hal how to configure your input devices. Actually, you do not have much to do since latest xserver-xorg-input-evdev packages bring what you need. hal reads all fdi files under /usr/share/hal/fdi/policy to find out how devices should be configured. If you run lshal and look for input, you should see that the evdev is planned to drive your input devices. However, if you look at keyboard devices in lshal (look for input.keys), you will see that the US layout is used. To switch to another layout, you can add some overriding rules as a new *.fdi file in /etc/hal/fdi/policy/. For instance, to get French layout:

<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.keys">
      <-- Enforce XkbLayout=fr and XkbVariant empty -->
      <merge key="input.xkb.layout" type="string">fr</merge>
      <merge key="input.xkb.variant" type="string" />
    </match>
  </device>
</deviceinfo>

Thanks to this, you can enforce XkbLayout, XkbVariant and friends as usual in /etc/X11/xorg.conf. Don't forget to restart hal after modifying some fdi files. Then run lshal, and look for Xkb, you should find your setup there. Note that you can add some matching rules to configure some devices with different setups if needed. Just need to read the output of lshal and find something like a hardware identifier to match on. You can find some documentation about these rules by looking at the existing fdi files in /usr/share/hal/fdi/policy/20thirdparty/, and in the upstream x11-input.fdi (note that input.xkb.foo is the actual recommended syntax instead of input.x11_options.XkbFoo). Touchpads If you have a touchpad and want to use the synaptics driver, installing the xserver-xorg-input-synaptics will bring another fdi file. /usr/share/hal/fdi/policy/20thirdparty/11-x11-synaptics.fdi matches input.touchpad in the device capabilities in hal. Now the synaptics driver will be automagically loaded for your touchpad (instead of evdev for regular mice). Again, you can override this rule in /etc/hal/fdi/policy/ and you can add many configuration options for synaptics as well. See /usr/share/hal/fdi/policy/20thirdparty/11-x11-synaptics.fdi to get an example. Fortunately, you will not have to manually take care of the above /etc/hal/fdi/policy/ file for ever. The plan is to have hal look at the Debian console configuration and get at least the keyboard layout from there automatically. Telling the Xserver to talk to hal Now, you need to tell the Xserver to use what hal wants. Basically, you want to remove everything about keyboard, mouse and other input devices from your xorg.conf. Just drop all InputDevice sections and all references to them within other sections. With recent Xserver versions, options AllowEmptyInput and AutoAddDevices are enabled by default (otherwise, you might have to add them in the ServerFlags section). For more documentation, you want to read Peter Hutterer's blog, especially this post and this one. By the way, if you don't want this input-hotplug thing and you want to run a recent Xserver anyway, you should set AllowEmptyInput and AutoAddDevices to off in the ServerFlags section. Update: Fixed the way to manage fdi files, fixed the syntax of input.xkb.foo rules, added a paragraph about synaptics, and organized things in sections. Thanks to everybody's comment.

One very convenient feature of Apple's hardware is the ability for their workstations to enter target disk mode. This effectively transforms the machine into a glorified ieee1394 (firewire) block device, which can then be manipulated from outside the machine using the standard SBP-2 protocol. Is there a way to provide this same functionality from a running GNU/Linux machine? For example, i have a GNU/Linux system with a block device attached to it. I would prefer if the block device was available to a neighboring machine, but (for whatever reason) i'm unable to physically move it. However, i'm able to link the two machines via a simple ieee1394 connection. A "virtual target disk mode" server (or would it be better to say "an SBP-2 mass storage target service over an ieee1394 link"?) would be really useful. One thing that occurs to me is that i could do some sort of networking abstraction over the link (using eth1394?), and then use something like vblade (an ATA-over-Ethernet target service) to provide a virtual block device to the remote host. However, this requires the remote host to run an operating system capable of dealing with these (more obscure) protocols, and i'd like this to work for any remote machine that knows how to deal with generic SBP-2 ieee1394 mass storage. I know that in general GNU/Linux is at least as powerful and capable as the firmware that Apple ships ;) But it's possible that our community just hasn't gotten around to implementing something like this. Is this the case? My attempts to search for it haven't turned up anything, but it's entirely possible that i'm reading the wrong docs (or reading the docs wrong). Any pointers?Tags: firewire, ieee1394, sbp2, vblade