The Haskell Hackathon in Freiburg is nearly over now. For me, it turned out to be a xmonad hackathon, as of a few days ago, xmonad is able to handle dock applications such as the gnome-panel properly (that has prevented me from looking at xmonad before).Now that the panel worked, I also wanted it s window list and workspace switcher to at least show me the state of my workspaces. This resulted in the EwmhDesktops extension. I also noted that the dock handling provided in the default Config.hs was not sufficient, as it would even treat dialogs from gnome-panel as a dock. This is fixed with the extension ManageDocks, which later got additional support to increase xmonad s border gap if an window (such as gnome-panel) has the STRUT attribute set. To closer match my old metacity keys I added support to CycleWS for going to the next/previous workspace and for moving the current window there.I had some ideas how to make the hook interface for xmonad nice, and now started to work on debian packges for xmonad: You can get and test prelimary ones.

A party calling themselves Oslo Byaksjon this year entered the elections, with the tagline “P parti med byen” (roughly, “On the city’s side”, or “With the city”). Their platform wasn’t horrible, and I briefly entertained the notion of voting for them. In the end I didn’t, for some important reasons; but that’s not very relevant. A Norwegian tradition is for the political parties to set up stands leading up to the election, along Karl Johans Gate (Main street, the street between the Royal Palace and the Storting (the parliament building), and this year was no exception. However, almost a month after the September 10th city elections, Oslo Byaksjon still haven’t removed the fiber boards after taking the thing apart. They’re now an orange eyesore in the middle of Oslo’s main street. Ironic! (More pictures here) Update: ZOMG, I am on Planet Debian. Hello, friends

After 6 weeks of teaching and over 2 months in my new apartment, I am making a short escape from NYC to visit my mom and sister in PR. In my Impacts of Technology class, we just finished a week on large-scale and complex technological systems, with a focus on industrial farming. We read a few sections of Micahel Pollan’s fanstastic book, The Ominvore’s Dilemma, which combines the odd qualities of being seductively alluring (thanks to his exquisite writing) and repulsive (thanks to the content, well at least the part on factory animal “farming”). I can’t recommend it enough and look forward to reading the rest, when I find the (magical) time to do so. Now that I am at the airport, I am struck at how little I know about this place, which is also a large and complex technological system and I bet revealing its technological and cultural innards would provide as fascinating (although not quite as gross) of a story as that of factory animal farming. There are many questions I would love answered: How exactly is coordination secured and what are the toughest elements to airport coordination? Where are the lines of cooperation and those of competition between airlines? What factors and values go into the design of the airport? (I know that for one thing, in American airports, there rarely seems to be enough electrical jacks; I am now sitting under the telephones, the only place with jacks in terminal 8 at JFK, and the funny thing is that there are a row of 7 unused phones and only one jack and I am sure it would be more useful to have 1 pay phone and a row of 7 jacks, instead). What sorts of airport technologies have put people out of jobs? What technologies have created new job opportunities? What sorts of social hierarchies are there in airports? Like who runs the big show? Is it a CEO? Or is something more like a university provost? What is standardized by the FAA, and what elements are more flexible, and thus different airport to airport? Is there a sense of camaraderie among airport employees, or are loyalties built primarily among employees of one airline or among the classes of workers? Given that unions are quite strong among airport employees and from the top (pilots) down (food workers), what is the political culture of airports/employees like? (I remember once overhearing a group of machinist and ground crew talking about the ugly face of globalization and NAFTA over coffee and I was dumbfounded and pretty psyched too). Are airports one of the few last remaining places in th US that provides for decent job security? Why do so many of the ground crew have such athletic, bulging calves? Is it a result of the physical demands of the job? Or is it that the type of job ( outdoors with lots of heavy lifting), attract the athletic types? Do they have to pass certain physical standards as to pilots? Was there always first class seats? Or did that come about when flying became cheaper? Are employees trained to deal with irate passengers? In what ways do pilots bitch about the long waits/delays they also have to endure? What can they do when they are waiting, as we did for an hour last night, during the massive traffic jams that are especially noxious in NYC-area airports? Do pilots have any say in the way airports are run? Why do they consistently provide less chairs than are needed in lounges, even in new terminals, as the one I was in tonight? Do air traffic controllers ever meet face-to-face with pilots or do they largely have a virtual relationship? Are programmers who patch, improve, and build traffic control systems housed in the airports, or elsewhere? Airports are not only fascinating for technological and sociological reasons but I reckon there is a lot of interesting psychological work that must happen in airports. I imagine that during those long, endless waits in the lounge, on the security lines, on the tarmac, people must often take the time to reflect, on where am I going, where am I coming from, and not in the literal sense but the metaphorical one. I know that I have spent many hours in airports letting my mind wander to places and thoughts in ways that don’t happen as easily or often elsewhere. And in many instances, I don’t think that this propensity to indulge in some reflective thinking, is a matter of time, that is waiting. For me at least, it is the fact that many times when I fly, I am moving between worlds. While I have flown hundreds of times, I never have been shed of the sense of awe I feel about planes and their ability to shrink space and time so quickly. For me, it is less the act of flying itself (that feels boring, tiring, annoying, mostly because of the insane waits and delays and I never seem to get the right amount of sleep the night before) but the visceral contrast it brings. In the morning my life is of a particular tone and rhythm, currently situated in NYC and by evening, I am back at home in PR, surrounded by thick humidity and the loud sound of coquis. Once there, my as currently configured in NYC, has little direct bearing to those around me. Planes don’t just transport, they shift and convert your inner and outer world… So, if anyone (who got this far) knows of a good social history of the airport, do tell. I would love to read it.

There is ongoing debate about the issue of security cameras, how many should there be, where should they be located, and who should be able to access the data. I spent about a year living in London which probably has more security cameras and a greater ratio of cameras to people than any other city. I was never bothered by this. I believe that if implemented correctly security cameras increase public safety and will not have any serious problems. A while ago I witnessed a violent assault (which could potentially have ended up as a manslaughter case - it was merely luck that ~200 people got off a train at the right time to scare the attackers off). AFAIK I was the only person who identified themself to the police and was prepared to stand as a witness, without security camera footage the case would not have gone anywhere (I only saw the attackers from behind as they ran off). Security camera footage allowed the police to identify the attackers, my testimony was not required and I was never informed as to how the case proceeded - but I know for a fact that the police investigation depended on security camera footage and that they did make progress in the case based on such footage. There are current plans to increase the scope of security cameras in many cities under the guise of the “war on terror”. The problem is that once a terrorist is involved in an attack it’s too late for security cameras. Security cameras are really only good for catching criminals after an attack, in most cases they will be entirely ineffective against suicide bombers as the issue of catching them is moot. There have been cases where security cameras have enabled the authorities to identify people with terrorist ideas who were investigating military bases (but I wouldn’t call such lamers “terrorists” as all the available evidence suggests that they would be incapable of succeeding in an attack). However no-one is disputing the fact that military installations need to have good security. Given that security cameras do provide significant benefits to public safety I don’t think it’s reasonable to oppose them as long as they are implemented in a sensible and responsible manner. Most of the current plans to install security cameras don’t seem to be sensible and have few controls on who can access the data. This makes them good targets for oppressive government actions, organised crime, and even terrorists. The countries that have serious terrorist problems always have problems of terrorists infiltrating government departments and bribing government officials. A centralised system that allows the police to watch anyone at any time would probably do more good for al Quaeda and the Mafia than it would for regular police action. For the fastest possible response a security camera system needs to have humans able to monitor it’s output in real-time. Having a control-room where police officers can randomly switch between public cameras to see if a crime appears to be in progress is a good thing (and works well in the UK). Of course the actions of such police need to be monitored to make sure that they are actually doing their job (not checking out hotties on the camera - an ongoing problem with security cameras). Finally there’s the issue of what level of surveillance can be expected in a public place. I think that most people agree that when you enter a government building it’s reasonable to expect that you will be on camera, and many private buildings have security cameras with a condition of entry being that you permit yourself to be watched and no-one seems to be boycotting shopping centres because of this. Significant public spaces such as main roads and public transport also seem like reasonable locations for security cameras. One location that is widely disputed is that of streets in residential areas. Most people who are happy to be photographed when entering and leaving public buildings such as train stations and shopping centres are not happy to be photographed when entering and leaving their own home. I think that a reasonable solution to these problems requires the following:

1. Restrictions on the duration and scope of surveillance in residential areas (EG require police to get court orders for such surveillance that must be periodically renewed).


2. Restricting the duration for which records may be kept by the police. Keeping any records for longer than the period in question (which would be a few weeks at most) would require a court order.


3. Prohibiting private organisations from handling surveillance data from government property (including public roads, train stations, etc). There are problems with having a private company aggregate surveillance data from multiple private properties but I don’t think we can address this at the moment.

Share This

Thanks to Faidon Liambotis, pristine-tar has been extended to support recreating pristine gz files, as well as tar files. It's been tested against the entire corpus of .tar.gz files in the debian archive, and succeeds on 98.7% of them. We're using the whole archive as a test suite for pristine-tar, which is such a nice change -- excellent test coverange, and no need to write tests. :-) I've put up all the deltas it generated during its most recent run at http://hydra.kitenet.net/~joey/tmp/tar/. The deltas for all the tarballs in the archive use only 175 mb of space. The next step, once it gets out of incoming will be for tools that inject sources into revision control to get support for generating pristine-tar deltas and checking the deltas in too. And for tools that build packages from revision control to get support for using the deltas to reproduce the original tarball. If you maintain such a tool, I'm happy to help you do that. how pristine-gz works Recreating gz files is tricky, since you generally can't binary diff them as pristine-tar does with tar files. Instead, gzip has to be fed exactly the same conditions that applied when the original gz file was created. This includes time stamps, filenames, file content, and compression level. These are figured out by looking at the header of the gz file. But that's only the easy part, because there's a lot of variation in gz creation programs. The debian archive contains gz files produced on BSD systems by a libz based compressor, other built on MS-DOS, Windows NT, and many other strange and often buggy things. All of these differences result in different gz files. To deal with this, pristine-gz uses a gz creator that can reproduce any of the known variants on demand, and just tries different varients until it finds a match. There are still 132 files that it fails to reproduce, so if this sounds interesting to you, you can try to figure out how they were created and add support for them. It would be possible to make pristine-gz succeed even for gz files it can't reproduce. It could just generate xdeltas to the files it tries, and store the smallest one. I am undecided if that would be a good idea, since the delta wouldn't be very small.

I got a call from one of the researchers from ABC news this evening. Apparently they are planning on doing a segment on Hans Reiser on their 20/20 show, and the researcher knew enough that there were some serious technical inaccuracies with the script (at the level of “so when Hans was creating reiser4, was that software; was he writing a program?” and “does the program run on the hard drive?”), and so they were looking for help on some technical issues on a background basis. She didn’t take any quotes from me; what she needed was help understanding the technical issues around filesystems and Linux. I tried to help explain what a filesystem was that would make sense to a lay person in 15 seconds; I have no idea whether the researcher got it, and whether she’ll be able to make changes in the script that will be vaguely coherent. We’ll see. I spent a lot of time working with Joshua Davis, providing background material for his Wired article, and he still got a bunch of the technical details wrong. The 20/20 researcher did ask me some silly questions such as “whether we were surprised when murder charges were filed against Hans?” Well, yes. What did she expect me to say? “Oh, yes, were always worried someone would get hurt…” Not! Sigh…. I might not agree with Hans’s filesystem design principles or his tactics in trying to get reiser4 accepted, but I always respected him as a fellow open source programmer. The researcher mentioned to me that Hans had done a talk at Google that was available at the Google Video site. Out of curiosity, I took a look at it. It was interesting; the last time I had seen Hans was in 1999, at the Linux Storage Management Workshop in Darmstadt, Germany that was organized by Matthew O’Keefe at Sistina Software. Compared to how he looked back then, and the picture of him in the Wired article, taken a 10-12 months after his talk at Google in February, 2006, I was struck by how much heavier (and older at least compared to my memory of him, which was much closer to this picture from his resume) in the Google Video. I also remember him as being a much more dynamic and energetic speaker, and I was struck by how slowly he spoke, with lots of long pauses and “umms” and “ahhs”. He seemed to be a much better public speaker in Darmstadt, but in the Google talk he seemed very tired as he gave the talk. One of the questions that the researcher asked me was whether I thought he was a genius or not. I told her that I thought he was quite bright in terms of raw intelligence, but that his Social IQ wasn’t as high as you might want for someone to be successful in gathering volunteers to work on an Open Source project, and in working with others in an Open Source development community. Looking at the video, I think that is very much true. He was a terrible public speaker, but some of the points he made about optimizing B-tree algorithms made sense. I might disagree with his philosophy over filesystem design and benchmarking, and I might not be terribly impressed by his social skills, but in terms of being a talented computer scientist, he was and is that. Is he guilty of the crime that he has been accused of? I have no idea. But from looking at his talk and knowing what I know of him, I have the sense of a greek tragedy. He’s been working on some of his ideas since his undergraduate days in UC Berkely in the early eighties — which he entered after finishing his 8th grade. And as research ideas, I think he might have gotten some very interesting results out of trying some of the things that he wants to do around operating system namespaces. (I think they are doomed in a production system descended from Unix, since application programmers are unlikely to rewrite their programs to take advantage of reiserfs’s performance characteristics — which would mean instead of using a Unix-like configuration file, treating a directory hierarchy containing the configuration information like a Windows registry. Still, as an academic, Plan 9-like system, I could have seen it has being a potentially very interesting Systems Research effort.) Unfortunately, his skills at public speaking and his ability to work with other people have handicapped him, and I know that has frustrated him deeply. So I have a lot of sympathy for him, and I hope that he is innocent, and will be found innocent. But only time will tell…. Anyway, according to the researcher, they are currently scheduling their segment about Hans on 20/20 on October 19th. I’m sure that schedule is subject to change, but it’ll be interesting to see how they treat Hans in their coverage. Hopefully it will be fair, and not overly sensationalistic, but unfortunately my faith in today’s TV edutainment-focused news program isn’t terribly high. My impression was that the research wanted to do a good job, but she was burdened by a very tight deadline, and in the end, the decision of what goes on the air and what doesn’t won’t be up to her. So we’ll see.

Although I predicted that I'd be a busy boy with my bushfire brigade on Tuesday, I wasn't expecting to get our first "Bush Alight" fire call so quickly. But, yesterday (Wednesday), a few minutes after 1800, off goes the pager, and off I go to the station. Thankfully the high winds that had been a major feature of the day had settled down quite a bit, so it was relatively easy to control and stamp out (we were back at the station by around 2015) I still found it a little overwhelming -- "I'm supposed to help Stop This Fire". At a couple of hectares in size, it wasn't too massive, and it wasn't visually "spectacular" (like the fires you always see on the news) but still... given that my only experience of fire in the past has been small campfires and the occasional bonfire, having an area the size of a football field in front of you glowing with embers and flaring with small clusters of flames, it was certainly a very different experience. The heat, the smoke, the noise (those truck pumps are loud), and the adrenalin, it's a hell of a mix. Being that I'm the newest and least experienced crew there, I got given the unglamourous but important job of controlling traffic, as we had one lane of the one-each-way 100km/h road closed to give our crews more working space around the trucks. Let me just say that I now have an infinitely greater respect for road repair crews, and I think that every person should do an evening of traffic control with a group of their mates on the road behind them, so that they know what it feels like outside their car. Car drivers do the darnedest things. So, I've popped my bushfire-fighting cherry now, and I'd be more than happy if there's nothing more impressive than that awaiting me for the rest of the season.

This Monday, state secretary Bijlevelt of interior affairs finally decided that any current type of voting computer is not safe enough for elections. This decision is not a surprise for anyone who's followed along with the wedonttrustvotingcomputers.nl action group, but it's the first time the government has acknowledged the full problem. This means that on the next "election" at October 10th here in Utrecht, already the red pencils will be recovered from their long time storage. Most interesting about this whole discussion is the question I only see asked sparingly:

What problem are voting computers trying to solve?

As a data point: on the last general elections, the Amsterdam district finished their counts of pen-and-paper voting before midnight on election day.

The webkit rendering plugin for liferea is now available in unstable. It has missing features and crashes not-so-rarely. But it renders properly (and I rather like how it loks, actually) everything I’ve tested with it so far. Please help us get it into a releasable shape by testing and reporting bugs, but do be kind to us and try to see if the bugs are in liferea or in webkit itself, by using /usr/lib/WebKit/GdkLauncher on the relevant URL. Many thanks are due to Lars, our very excelent upstream.

For the last month, I’ve been running a non-profit Xen server for a few friends. It’s been working really well but I’ve got three two one no slot left. I think it’s quite good value: £7.88 per month (£17.73 setup) gives you:

• 440Mb RAM
• 15Gb SATA RAID-1 disk space
• Very-low contention Athlon64 X2 4400 CPU
• Fast, London-based bandwidth (provided by Bytemark)
• IPv4 IP address (IPv6 also available)
• Custom reverse DNS
• Backup mail relay
• Choice of distros, Xen-shell remote admin, etc.

If you’re interested, please drop in on #lamby-xen on OFTC. UPDATE: All gone. Thanks for the huge interest.

Man never realizes how much customised distribution he has until he has to reinstall it. Last week hard disk in my notebook died, so I had to reinstall system and reconfigure everything. I fortunately have backups of almost everything (at least I didn't notice that anything would be missing), but I anyway spend two evenings in installing, configuring and restoring from backups and I'm still not done with it, but the system is at least usable for normal work. However there are also some positive things on this: I get more space and faster disk. I finally set up encrypted file system on my notebook. I dropped several old crap that lived (or better was buried) somewhere in my system and which I already forgot why it was there. And I also got rid of very bad partitioning scheme, which was there from times I used together Debian and Windows and wanted to have another partition to test SUSE installation while I worked there. Now there is only Debian to rule them all ;-).

Today I received the replacement hard drives for the two that failed the other week. Despite me not ticking the box (or paying the $10 for the upgrade), they gave me 500Gb drives to replace the 400Gb drives that I'd shipped them. I was a little dismayed to find that they were labelled as refurbished drives though. Oh well. I plugged the first drive in, and it started exhibiting the same behaviour as the one that had failed, and I immediately thought "oh, they've shipped me a dud refurbished drive". So I tried the other one. It also did the same thing. I started to smell a rat. I have a slightly convoluted power setup for these four disks. They're all connected to minotaur via IDE-USB adapters, and they have external DC power supplies. They're just sitting on top of minotaur, which is a Pentium III 1-RU server, in the bottom of my linen cupboard. In order to reduce the number of plugs involved, I have an IEC Y-cable, which goes to two of these DC power supplies (which take an IEC cable in one end and has a Molex connector on the other end), and the Molex cable from the DC power supply has a Molex splitter cable on it. So I'm powering two drives from each DC power supply, and each DC power supply is connected to an IEC Y-cable. There's no redundancy whatsoever, and I'm not that concerned. I don't have a UPS anyway, and the whole thing has worked fine for months, and it reduces the rats nest of cables a little bit, which is good. I already have way too many things plugged into my linen cupboard. Anyway, so after both new drives appeared to be faulty, I discovered that both drives that had failed within a day of each other were connected to the same DC power supply. The plot thickened. So I dug out a standalone IDE-USB hard drive enclosure (with a separate power supply) and tried that. Everything worked. I tried it with just the enclosure's power supply and either of the IDE-USB adapters I'd been using previously. Everything worked. So I'd managed to narrow it down to the power supply. Most unusual. So fortunately I have four of these DC power supplies, as they came with the IDE-USB adapters, and I freed up two of them when I went for the aforementioned crazy power splitting setup, so I dug out one of the two spares, and tried that, and everything worked. So I've no idea why the power supply decided to go dicky after months of working. I've yet to introduce my multimeter to it to try and work out what's going on. I'm a bit embarrassed that I didn't do more homework before I declared the drives to be faulty. To be honest, they were clicking and generally looking "failed", and I've had a lot going on lately, so I just jumped to the conclusion. Oh well, at least I still haven't lost any data. Too bad I have 200 Gb that is going to go to waste.

It's bad enough that we have anti-social fuckwits spamming the world. It's made even worse by morons using broken-by-design challenge-response software like Active Spam Killer to push back-scatter on to the rest of us. I'm depressed that people can be so ignorant, but not exactly surprised. I just got another challenge in my inbox today. *sigh*

Looking at the web stats, I noticed, that quite a lot of people find something relevant to "environmental" on my pages. As I was not aware of anything related here, I tried that in Google. To my surprise all results are in demo for Ukolovnik. Well I do not want to add any anti spam technique to this simple tool as it will be usually password protected. And this is exactly what I did with demo for now. So if you want to use it, you need to login with user demo and password demo. I hope this will prevent spammers from using this demo, otherwise I would probably have to close it.

Madduck wondered why a package using revision control needed pristine tarballs at all. Firstly, the example he gave of tagging an upstream release and creating a tarball of it to build the package against is exactly what pristine-tar does. Except it preserves permissions and timestamps and other tar cruft. Sometimes timestamp or permissions issues do cause issues with package builds, so being able to build against the original files from the pristine tarball is potentially useful to catch and fix such problems. As to other uses of pristine tarballs... It's hard to list the advantages to using pristine tarballs, since Debian (rpm too) has had them forever, and lots of people may depend on them in ways that we don't anticipate. For example, I've seen FreeBSD point at ftp.debian.org to get tarballs for their packages, since they don't archive tarballs on their own, and sometimes the tarball isn't available upstream (or ftp,debian.org is the upstream). That's a wacky example, but I've seen it more often than I've seen pristine tarballs used for the often-cited md5sum comparison case. Rather than try to enumerate all the possible reasons for pristine tarballs, and then try to whittle the list down to reasons that actually make sense, and cost-benefit analise those, it seemed better to just try to write a solution to the problem. (Or at least, to most of it -- a hopefully small subset of the set of reasons for pristine tarballs are not satisfied by pristine-tar.) I've also been theoretically interested in this problem of generating pristine tarballs from version controlled source ever since Scott Remnant mentioned at a meeting (140 mb video of meeting here) that he had a tool to do it -- and AFAIK never shared the tool! So the challange factor was another reason to write it. However, pristine-tar has already saved me hundreds of megabytes of disk space, sped up my release process (avoiding bug #225483) and simplified the way I work, so it's already a net win for me, even if it turns out we don't need pristine tarballs for anything at all!

Joey writes about the difficulty of dealing with the need of pristine tarballs and version control systems. He concludes that it's best to save the tarballs in the repository and has written a tool to store binary differences to save space to achieve his goal. This being another piece of software by Joey, it's probably worth checking out. But I wonder why we actually bother about pristine tarballs. Sure, our Debian archive scripts require a tarball, but why does that have to be the pristine upstream tarball? As Debian maintainer, I use git to keep track of the software that I package, and if possible, I track the upstream repository directly (Git makes it very easy to track repositories of the other, popular version control systems). When I decide to upload a new upstream version to the Debian archive, I tag the upstream tree, sign the tag, and generate a tarball from it:

git tag -s -m'preparing release of upstream 1.2.3' upstream/1.2.3
git archive --prefix=foo-1.2.3/ upstream/1.2.3   gzip -9 \
  > ../foo_1.2.3.orig.tar.gz

Then I merge the tag into my Debian branch and prepare a Debian release, which I also tag (debian/1.2.3-1) just before uploading the package to our archive. This is very flexible and allows me to release packages based on software snapshots, as I just did with mdadm. Now, a filename of mdadm_2.6.3+200709292116+4450e59.orig.tar.gz pretty clearly states that this is not mdadm-2.6.3.tar.gz, so people would be aware that this tarball is not "upstream-official". But what about official releases, like mdadm-2.6.3.tar.gz? When preparing the Debian package, it's only slightly more effort for me to download the official tarball and store it as ../mdadm_2.6.3.orig.tar.gz, but why do I need to keep it around after I uploaded Debian package 2.6.3-1? I know I need the orig tarball to prepare the diff.gz for 2.6.3-2, but for that purpose, I can really just git-archive the appropriate tag. The result won't produce the same hash (because the tar format stores timestamps and is thus not really appropriate for the cause), but it provides the same contents. In fact, what I (or someone else) should finally implement is a tool to create the diff.gz directly from the version control data or even better, we should finally get rid of source packages as I've previously suggested, long before Ubuntu came around to propose and blueprint the concept. I am aware of some people's preference to be able to "independently verify Debian's orig tarball using e.g. a detached GPG signature provided by upstream," but I dare to question the point of this verification. Those who care enough to verify that the Debian-provided orig tarball is pristine are hopefully building their own binary packages instead of trusting mine (another beef I've raised in the past), and then they might just as well download the source directly from upstream. I'd say most people (rightfully) don't do this and just use the Debian-provided content, which can be assumed to be pristine if you trust me and Debian: my GPG signature authenticates uploads to the Debian servers, and APT provides authenticity checks downstream up until the installation on an end-user system. and if you trust the version control system, and this actually raises an interesting point for me: how feasible would a man-in-the-middle attack between Neil's (the mdadm upstream) repository and mine be, given that I use the plain-text git transport protocol to fetch new commits. If you have any comments on that, please let me know. I'll leave this issue for another discussion or post. NP: The Beatles: Abbey Road Update: Matej Cepl pointed me to this thread on the fedora-devel mailing list, where they discuss switching from CVS to Git and talk a lot about their needs and how the end result is much the same as what I am proposing. Thanks!

I had one of these devices collecting dust in my basement. I finally got around to reverse engineering a userspace driver for it, which was much easier than I expected. It just shows up as a usb->serial device, and it was mostly a matter of of watching the serial line while hitting buttons. I have started to figure out some of what I need to know to communicate with it in the other direction in order to do stuff like turn on the lights and manipulate the lcd displays. That stuff is not yet, however, functional, but in the spirit of "release early, release often", I've uploaded a 0.0.1 release to the project page on sourceforge. Also included is a python extension which allows you to register callbacks for the various controls on the device. After I get the leds and lcds working, I think the next step will be to write a program to generate synthetic MIDI events when the device is manipulated so I can hook the thing up to something like mixxx. Hopefully someone else has one of these kicking around and might also find this work useful!

I had one of these devices collecting dust in my basement. I finally got around to reverse engineering a userspace driver for it, which was much easier than I expected. It just shows up as a usb->serial device, and it was mostly a matter of of watching the serial line while hitting buttons. I have started to figure out some of what I need to know to communicate with it in the other direction in order to do stuff like turn on the lights and manipulate the lcd displays. That stuff is not yet, however, functional, but in the spirit of "release early, release often", I've uploaded a 0.0.1 release to the project page on sourceforge. Also included is a python extension which allows you to register callbacks for the various controls on the device. After I get the leds and lcds working, I think the next step will be to write a program to generate synthetic MIDI events when the device is manipulated so I can hook the thing up to something like mixxx. Hopefully someone else has one of these kicking around and might also find this work useful!

In the last few days we (as in DebConf admins Steve Gran, Mark Hymers and myself) have been doing some DebConf maintenance work. Some time ago one of DebConf’s permanent sponsors, ByteMark sponsored a new machine, krabappel, which we use as a replacement for the older machine we have from them, cmburns. It was neccessary, as good old cmburns had a lot of stuff running and so was always pretty loaded. Imagine it running most of our websites, main mail and dns server and then also having 4 vserver instances on it. Those vserver itself where also running things that do use some resources, like our wiki and the main DebConf7 site, the PentaBarf test-host and our LedgerSMB instance. While it was long decided to move stuff our - we just had to find time to do it. This weekend seems to be it, everything is migrated except cmburns itself, as that needs a fix in the reverse dns entries for the new /28 we got. We are using xen-tools to make installation of new images easy. For that I wrote a script that is used as a role script, automating all that various setup tasks that one can automate easily. Which means that it takes about 5 minutes to get a complete new XEN domain up and running. (Add some minutes to add it to nagios2, munin, our mail setup and to sync the userdatabase.) Mark and Steve also did another migration: gallery.debconf.org is now using gallery2. Still needs a nice layout designed looking similar to our normal DebConf website, but that shouldn’t be too hard to get. While they have been on it they also integrated gallery.debian.net, so that it is back up again. Feel free to use both of them! gallery.debconf.org offers space for all DebConf related pictures, be it the main yearly DebConf (and related) or regional DebConfs, like the one planned for Panama soon. gallery.debian.net is a place where pictures from all Debian related events/parties/whatever can be put. Basically - whenever people working on Debian meet (like a BSP, a work meeting, etc) - feel free to put pictures up there. Just put them into a folder matching the year it happened in… Basic goal is to get a huge set of pictures from people involved in Debian.

Nicolas Fran ois just announced that we (shadow package maintenance team in Debian) are taking over the maintenance of shadow upstream. Shadow is the source package that builds the passwd and login packages. login provides.....login, while passwd of provides 'passwd' but also several low-level user/group maintenance utilities (useradd, userdel, etc.....not to be confused with higher level utilities we have in Debian such as adduser). Since March 2007, Tomasz Klockzek (insert some specific Polish letter here and there), the former upstream author, nearly vanished, probably too busy with his RL and professionnal activities. Shadow is in a pretty good state, thanks to Tomasz great work and the great collaboration we had last years with him. So, it sounded quite logical topropose taking the maintenance over. Therefore, we proposed this to maintainers from Gentoo and RedHat. While none of them really want to maintain the software, they're OK to collaborate if we're taking the "lead". The shadow "team" in Debian is currently made of Nicolas, Christine Spang and me. We might need more help, particularly from people involved in PAM-related stuff and skilled in C programming and security. As of now, I don't expect us to do more than trying to merge in patches used in Debian/Gentoo/RedHat and maintain the code without adding features. The main contact point for shadow maintenance is the pkg-shadow-devel mailing list on Alioth.