The phpMyAdmin's feature tracker is kind of special thing, which grows all the time. From time to time I try to go through all of them and properly mark those who are fixed meanwhile or do not make sense anymore. Today I started with 277 (49 of them already marked as fixed in upcoming releases). After random accessing the list and about one hour I'm down to 266 (53 out of them fixed in git). Well 15 less is not that much better, but at least I managed to kill some long waiting zombies, which turned out to be bugs instead of feature requests.

Last week we released 1.1.3 of the Entropy Key software. Poor Daniel struggled for days to get this out the door but finally he managed to build all the various debs, rpms and tars for the supported platforms and Rob got it all uploaded and announced.

One of the things that I love about our Local LUG is the people. At our LUG, we have our resident geek artist, Antonio Roberts (aka hellocatfood) who, on the odd occasion, gets harassed into doing a talk for us. His talks are always fairly awesome. His previous talk about FLOSS + Art is the video with the highest views on our video archive, and tomorrow night, Thursday 16th September, at 19:30pm BST, he ll be delivering his next talk about his experience in the FLOSS community as an artist to us. In his own words:-

This talk extends greatly on what was said and goes into issues of copyright and what experiences I ve had as an artist in the open source world

His previous talk was a bit of an eye-opener to me, as a pure geek with barely a trace of artistry in me, and it s always good to see the FLOSS world from the eyes of someone who doesn t exactly fit the stereotype of what you d normally expect to see. The video will be available after the event, at some point, but for those who re interested in gaining an insight into artistry and FLOSS, we ll be broadcasting the talk live over the interwebs. <script type="text/javascript"> var flattr_wp_ver = '0.9.11'; var flattr_uid = '34168'; var flattr_url = 'http://www.sourceguru.net/freedom-creativity/'; var flattr_btn = 'compact'; var flattr_hide = 0; var flattr_lng = 'en_GB'; var flattr_cat = 'text'; var flattr_tle = 'Freedom in Creativity'; var flattr_dsc = 'One of the things that I love about our Local LUG is the people. At our LUG, we have our resident geek artist, Antonio Roberts (aka hellocatfood) who, on the odd occasion, gets harassed into doing a talk for us. His talks are always fairly awesome. His previous talk about FLOSS + Art is the video with the highest views on our video archive, and tomorrow night, Thursday 16th September, at 19:30pm BST, he\'ll be delivering his next talk about his experience in the FLOSS community as an artist to us. In his own words:- This talk extends greatly on what was said and goes into issues of copyright and what experiences I ve had as an artist in the open source world His previous talk was a bit of an eye-opener to me, as a pure geek with barely a trace of artistry in me, and it\'s always good to see the FLOSS world from the eyes of someone who doesn\'t exactly fit the stereotype of what you\'d normally expect to see. The video will be available after the event, at some point, but for those who\'re interest'; var flattr_tag = 'art,artist,floss,lug,presentation,sblug birmingham lug,streaming,talk,video'; </script> <script src="http://api.flattr.com/button/load.js?v=0.2" type="text/javascript"></script>

Last month I gave a presentation on the interaction between Android and kernel upstream at Linuxcon. The video for that is now available here (requires registration). Contrary to stories you may have heard, I do not dropkick anyone through a window.

There's some parallels between the Android/upstream scenario and Canonical's approach to upstream. Mark wrote a lengthy defence of Canonical's focus on components that they feel need development, while not putting development effort into things they feel are good enough already. That's pretty consistent with the discussions I had with him at the Ubuntu development meeting in Oxford over six years ago. Back then the focus was on taking all the excellent software that already existed and concentrating on providing it as a single polished and integrated product. It was successful - what's easy to forget now is that the first release of Ubuntu was massively more usable out of the box than any other Linux distribution available at the time, and it's absolutely undeniable that its release spurred increased efforts on the part of competitors. But I don't think the same focus is being applied any more.

The most obvious (and most controversial) example is the Ayatana project. Ayatana's a pretty explicit statement that Canonical don't view the existing Gnome UI as being suitable for their vision of the Linux desktop. That's absolutely fine. However, unlike many of the papercut projects, Ayatana is a set of complete reimplementations of functionality that behave differently to their upstream equivalents. There's no meaningful sense in which that's not a fork of Gnome. And, let me emphasise, I don't think that's a bad thing.

Let's go back to Android. While we talk about how much we'd have preferred it if Google had interacted with upstream before implementing wakelocks, the realistic outcome is that there's no way that we'd have accepted them even if they'd been posted years before hardware shipped. If there'd been a productive outcome to that aspect of the conversation it would have involved Android having a very different power management policy. Sometimes you're not going to convince people that something is better without implementing it and seeing how well it works. The problem with wakelocks is not that they exist or that Google feels they work better than the alternative, but that they end up integrated into drivers in a way that can cause divergence between mainline and Android.

Ayatana potentially has the same outcome. At some level, well-integrated applications have to be aware of the environment in which they're running. The application indicator patches are an example of that. Carrying conditional code increases maintenance burden, reduces test coverage and is a net loss in the long run. If upstream Gnome never gains support for this functionality, and if Ubuntu continues to depend on it, then Canonical have a delta that they'll have to carry forever. That benefits nobody.

Forking because you believe that your approach is better is a completely valid development model, but in the long run can cause problems if you don't have a long-term strategy for how to resolve that fork. For all we criticise Google's ability to get Android code into the mainline kernel, they've put orders of magnitude more effort into doing so than Canonical have in terms of getting Ayatana's code into mainline Gnome. This isn't a function of Google's relative size - the Android kernel team is on the order of 10 people. It's not enough of a difference to explain the disparity.

Canonical would be perceived as much better team players if there was an indication of their long-term plan in terms of Unity and the Ayatana projects and getting that code into mainline Gnome and integrating with the Gnome shell. It's completely unsurprising that they're viewed with distrust until that happens.

I finally made some progress on Czech translation of phpMyAdmin and it has again reached 100%. It was first time since merging GSoC projects, which introduced quite a lot of new strings. Not that they would be hard to translate, but it was rather hard to find time for that. However there are still lot of translations which are quite behind and would need some love. So if you can translate, you're welcome to join our translators and translate! PS: If you're looking for more work, we're also translating documentation :-).

I was asked to write about what I do at Canonical and what I do in the Free Software community at large. There is obviously a great deal of overlap, but I ll start with the things I m involved with when I m wearing my Ubuntu hat. My primary job at Canonical is keeping Ubuntu secure. This means that I, along with the rest of the Ubuntu Security Team, coordinate with other Free Software distributions and upstream projects to publish fixes together so that everyone in the community has the smallest possible window of vulnerability, no matter if they re running Ubuntu, Debian, RedHat/Fedora, SUSE/openSUSE, Gentoo, etc. Between vendor-sec, oss-security, and the steady stream of new CVEs, there is plenty going on. In addition to updates, the Security Team works on pro-active security protections. I work on userspace security hardening via patches to gcc and the kernel, and via build-wrapper script packages. Much of this work has been related trying to coordinate these changes with Debian, and to clean up unfinished pieces that were left unsolved by RedHat, who had originally developed many of the hardening features. Things like proper /proc/$pid/maps permissions, real AT_RANDOM implementation, upstreaming executable stack fixing patches, upstreaming kernel NX-emu, etc. Most of the kernel work I ve done has gotten upstream, but lately some of the more aggressive protections have been hitting frustrating upstream roadblocks. Besides the hardening work, I also improve and support the AppArmor Mandatory Access Control system, as well as write and improve confinement profiles for processes on Ubuntu. This work ends up improving everyone s experience with AppArmor, especially now that it has gotten accepted upstream in the Linux kernel. I audit code from time to time, both on the clock with Canonical and in my free time. I m no Tavis Ormandy, but I try. ;) I ve found various security issues in Xorg, Koffice, smb4k, libgd2, Inkscape, curl+GnuTLS, hplip, wpa_supplicant, Flickr Drupal module, poppler/xpdf, LimeSurvey, tunapie, and the Linux kernel. With my Canonical hat off, I do all kinds of random things around the Free Software ecosystem. I m a sysadmin for kernel.org. In Debian, I maintain a few packages, continue to try to push for security hardening, and contribute to the CVE triage efforts of the Debian Security Team. I ve written or maintain several weird projects, including MythTVFS for browsing MythTV recordings, GOPchop for doing non-encoding editing of MPEG2-PS streams, Perl s Device::SerialPort module, and the TAP paging server Sendpage. For a selection of things I ve contributed to other project, I ve implemented TPM RNG access in rng-tools, made contributions to Inkscape s build and print systems, implemented CryptProtect for Wine, wrote a PayPal IPN agent in PHP that actually checks SSL certificates unlike every other implementation I could find, added additional protocol-specific STARTTLS negotiations to OpenSSL, implemented the initial DVD navigation support in MPlayer, updated serial port logic in Scantool for communicating with vehicle CAN interfaces, tried to add support for new types of timeouts in Snort and Ettercap, fixed bugs in mutt, and added HPUX audio support to the Apple ][ emulator XGS. As you can see, I like making weird/ancient protocols, unfriendly file formats, and security features more accessible to people using Free Software. I ve done this through patches, convincing people to take those patches, auditing code, testing fixes and features, and doing packaging work. When I go to conferences, I attend UDS, DefCon, OSCon, and LinuxCon. I ve presented in the past at OSCon on various topics including security, testing, and video formats, and presented at the Linux Security Summit (miniconf before LinuxCon this year) on the need to upstream various out-of-tree security features available to the Linux kernel. I love our ecosystem, and I love being part of it. :)

Hello Following a discussion on #debian-perl IRC channel, I ve proposed to provide a script to parse DEP-5 files. The goal is to be able to parse *and* validate DEP-5 files. DEP-5 is a
proposal to make debian/copyright machine-interpretable. This proposal is driven by Lars Wirzenius. With Config::Model, any evolution of DEP-5 specification will
be easy to include in the DEP-5 model read by Config::Model. What DEP-5 model ? To keep a long story short, let s say that DEP-5 model is a description of DEP-5 syntax and semantic that can be used by Config::Model to perform validation. For more detail on how to create a model, please read this doc. In other word, DEP-5 model is DEP-5 document translated into a special format. First step was to directly edit the doc and munge it into a YAML document describing the structure of DEP-5. Here s a small extract of this YAML file (slightly edited to remove most long descriptions) :

 
---
class:
  Debian::Dep5:
    class_description: >
       Machine-readable debian/copyright
    accept:
      name_match: X-.*
      type: leaf
      value_type: string
    element:
      Format-Specification:
        mandatory: 1
        type: leaf
        value_type: uniline
        description: >-
          URI of the format specification, such as ...
      Name:
        type: leaf
        value_type: uniline
      Files:
        type: hash
        index_type: string
        ordered: 1
        cargo:
          type: node
          config_class_name: Debian::Dep5::Content

During this YAML file creation step, the problem raised by the License keyword became obvious because of License properties:

• Limited number of valid License (no problem, let s use an enum)
• License names are not case sensitive (optimism goes somewhat down)
• License names have version number and an optional + suffix (ok, let s use a regular expression with Config::Model s brand new match specification)
• License can be combined with and or or . (uh oh, the match regexp will not be enough. A grammar would be better.)
• License can specify an abbreviation or the full text of the license.

Long story short, I had to add to Config::Model the possibility to specify a Parse::RecDescent grammar to validate a value. More on this later. Of course, the first draft of a model in YAML was far from being perfect. So the second step was to load it with config-edit-model. I had to fix a number of YAML errors and then some errors in the model description. Then, I had to write a parser to load the DEP-5 data into Config::Model tree. I first used Rapha l Hertzog s Dpkg::Control::Hash module. But this one is not able to cope with repeated fields without clobbering them. So I had to provide my own parser. The parser is divided in 2 parts:
- the parse function to load DEP-5 data in a simple data structure
- the read function to load the simple data structure into Config::Model s configuration tree You can view the code on Config::Model repository. Then the model is divided in 3 configuration classes:

• Debian::Dep5: the root class
• Debian::Dep5::Content: To represent Files specification
• Debian::Dep5::License

And the full model of Dep-5 can be also read on Config::Model repository:

• Dep5.pl.
• Dep5::Content
• Dep5::License

(The models are biggish because they include help text taken from DEP-5 documentation) Now some explanation is required on how is performed the License validation. The trick is that each License used must be listed in Dep5 s license parameter which is specified this way (in YAML syntax):

 
License:
  type: hash
  index_type: string
  allow_keys_matching: '^(?i:Apache Artistic BSD etc... other)[\d\.\-]*\+?$'
  cargo:
     type: leaf
     value_type: string

So this License element contains the list of licenses with their full text and only Licenses whose name matches the regular expression are accepted. Now, let s explain how the files are tied to the declaredlicenses. The Debian::Dep5::Content class had a License element that represent the relation between the files and the License(s). This bond is represented by Debian::Dep5::License configuration class. The abbrev and full_license elements are fairly obvious. The abbrev element is another matter. Here s its declaration (minus the description and help):

 abbrev:
 type: leaf
 value_type: uniline
 default: other

So far, so good. Now the meaty part: the validation requirement based on Parse::RecDescent

grammar: "license (oper license)(s?)
          oper: 'and'   'or'
          license: /[\\w\\-\\.\\+]+/i\n
               # PRD action to check if the license text is provided
               $return = $arg[0]->grab('! License')->defined($item[0]);
               "

This grammar specifies:

• The syntax of the License line itself (hence something like Perl or GPL )
• An action performed when the grammar is matched. Using Config::Model API, this Perl snippet checks that the License abbreviation has a corresponding License declared in Debian::Dep5 License hash

This way, an abbreviation cannot be used without a proper License statement. This code is the first stab. Some more work is to be done soon:

• Implement exception parsing
• Provided DEP-5 writer
• Provide config-edit-dep5 cli

Anyway, I ll soon release Config::Model with this first version of DEP-5 parser. As always feedback are more than welcome. All the best update: added missing Parse::RecDescent link

[Nothing related to Debian here, move on if you don't care about my recurring obsession with the end of the world, Cassandra pains, or Big Phat Living Room Revolution yearnings].

Although I am still looking for a community of anarcho-primitivists that want to accept me joining their frugal living, and simply slip off the social construct, the system, the fucking face of earth, call it what you will, I could find some comfort in my favourite feminist blogger's take on the subject of my midlife crisis regarding ecology, capitalism, patriarchy, child bearing, overpopulation, meat consumption and all the rumination of consuming thoughts that (still) make my life miserable and have kept me running away from human contact for a year.

[Emphasis mine]

At what point does human culture depart from the Natural? With the invention of computers? TV? Cars? The cotton gin? Electricity? Taco stands? Gunpowder? The printing press? Written language? Shoes? Crop cultivation? Yurts? The wheel? Did humans become unnatural when the good old days of picturesque, endless agrarian toil, feudal oppression, unchecked disease, ignorance, and death from dysentery at 35 turned into the bad new days of urban post-industrial capitalism where a pound of fair-trade organic coffee costs $12.99 and your email inbox is full of spam?

ah. Everything humans do, or have ever done, is natural. We can t do anything else. The idea that modern culture is un-natural is nostalgic and inaccurate. Living off the grid in a yurt is good in some absolute sense, whereas driving an SUV from a suburban bungalow to the stripmall is bad ? Come on. This a romantic, but misguided view. The cosmic reaction to a 20 Ford Expedition is the same as to a sanctimonious Prius: bupkis. The universe doesn t give a fuck about you or your lifestyle choices. It doesn t give a fuck about the economy, oil spills, or civil unrest in Blargistan. It doesn t give a fuck about katydids. Eventually our whole planet will be erased from space, and the galaxy won t bat an eye. The inevitable extinction of our species (imminent, according to research here at Spinster Laboratories) via the exhaustion of available resources is as natural as a fresh-picked peach. As Andre 3000 and other dude philosophers have observed, nothing is forever.

Yes, yes, when people use the word natural what they really mean is free of chemical additives and maybe some of the assorted hippie concepts that go with that narrative. Barter economies, home furnishings made from bamboo, vegan cookbooks, living in the country. While I would argue that it is just as natural for people to put chemical additives in things as it is to not put chemical additives in things, I admit that it is appealing to fantasize that the source of human misery is an unnatural isolation from Nature, and that doing yoga on an organic rubber mat and drinking organic spinach smoothies will put me back in sync with the cosmos.

But alas, I m already in sync with the cosmos, and so are you. In other words, this is it. This is what we ve become, and this is what we get. Which is not to say that a person can t fantasize about a verdant paradise full of songbirds and polar bears and Bengal tigers, untouched by human influence. Only, that world isn t a world we could actually live in. The minute you add contented children, lazy from a carefree day at the swimming hole, eating ripe plums on the porch at sunset to that scenario, natural history changes, and it s right back to our scorched-earth dystopia. Our giant brains use up resources, it s as simple as that.

As long as we re still here, though, we might as well try to make the best of it.

http://blog.iblamethepatriarchy.com/2010/06/19/heads-up-art-week-starts-on-monday/

Though the comfort is somewhat ephemeral, because deep inside, I know she's wrong, I know another way is feasible, but I have given up already, I have very well come to terms with extiction, I get an enormous pleasure from the thought of the very well deserved human mass suicide-by-cop^Wnature, and in fact, I trust and hope it will save me personally from facing the hard times ahead, as I am a damn coward, paralized by fear, hopeless about the flock ever getting it (is it so hard, really?), while doing as much as I can but completely overwhelmed by the need of changing a world everyone seems to like just as it is. I can certainly empathize with much more disturbed ways of airing similar anguish, among many other examples, such as The Unabomber, or The Weather Underground. I don't even want to go there as I know violence all too well and it is not fun to be on the receiving end. But I see the screaming desperation behind the motives of acts I am not at the liberty to discuss here. I wonder if consumption of resources in the form of books will numb the disorder or make it worse and what sort of medical arrangement the stablishment has for it. As you click away the previous links will mean nothing to you because a)it is Wikipedia after all, and b)you probably don't even understand what the problem of eating animal corpses is, humans are omnivores after all, and what is all this nonsense about dropping language altogether.

WTF, there was no comfort after all, and I am still a nutjob.

Second Sunday in September -- time for the annual Chicago Half Marathon now in its fourteenth edition (and I have been running it in 2003, 2004, 2005, 2006, 2007, 2008 and 2009 making this and the JPM Chase Corporate Challenge the races I've run most often). And the course was altered this year, alongside with an earlier start as the Bears have their season home opener today. So we started north towards 57th, then running down to 67th, turning east towards the lake at around three miles --- and having the remaining ten miles along the lakefront running up to 31st (the usual turn) and back down to 63rd. I like this course better; let's hope it sticks. Race conditions were fantastic. We had a rainy and gray day yesterday but today is pure bliss. Temperatures around 60 degrees at the 7:00am start, no wind, sunshine and not a cloud in the sky. The race itself went well. I had a pretty brutal running year suffering most of the time from some archilles tendon inflammation. It has gotten better in the last few weeks possibly thanks to some heel cups I now put in the shoes. But I had exactly one run longer than ten miles since the Boston Marathon. So I lost a lot of speed, as well as endurance and was a little nervous as to how I'd do. And considering all this, it went pretty well. I fininished in 1;41:50 or a 7:47 pace. While is easily the slowest half in a number of years, at least I got to run it evenly, pain free and with a negative split (== faster second half) and some gas left for a fast last half mile or so. So maybe I don't have to retire from running just yet. We'll see if I get some speed back in 2011.

A lot is being said on how Ruby is packaged in Debian and Ubuntu. In this post, I m trying to go through the most common myths and give my position as a Debian Ruby maintainer. Note that those are my views, not necessarily those of the other Debian Ruby maintainers. Myth: Ruby is completely outdated in Debian and Ubuntu There s a culture in the Ruby community of always using the latest bleeding-edge version. There s also a culture (though this one has recessed a bit, I think) that it s perfectly fine to change APIs in incompatible ways if it makes the software slightly better. In Debian (and Ubuntu) stable releases, we try to provide a rock-solid version of Ruby that won t be allowed to change API during the support lifetime of a release. Bugfixes for important bugs can be applied, but that s basically all. So it s not surprising that Ruby in released versions of Debian and Ubuntu is behind the latest upstream version. In development branches, we are following the latest upstream versions quite closely. Debian 6.0 squeeze , to be released by the end of the year, includes Ruby 1.8.7-p302, and will include 1.9.2-p0 (the currently of Ruby 1.9.2 in squeeze is currenty a SVN snapshot from beginning of august). There are people interested in installing a packaged Ruby that just works, and other people interested in installing their own version of Ruby (through RVM and such). People in the Ruby community tend to forget about the first category, and consider that, because they install Ruby from source or with RVM, that should be the solution for everybody. We need the Ruby community to respect that different people have different ways of using Ruby, and to stop recommending that everyone using Debian and Ubuntu should install Ruby from source. We also need to leverage the backports services for both Debian and Ubuntu to provide a way to install the latest upstream version on stable releases. The only reason why we are not doing it yet is lack of time. Myth: Ruby is split into a myriad of packages in Debian In the past (pre-2005), a decision was made to split some libraries from the standard library into separate packages. This was motivated by:

• the size of some libraries, like REXML
• the fact that some libraries, like OpenSSL, readline, gdbm and tk require other library packages to be installed
• licensing concerns about shipping some code (a .so) linked with OpenSSL, and some other code (another .so) linked with readline, in the same package.

Most of the split was undone a very long time ago, and the readline and openssl splits were undone this year. The current package in Debian squeeze has:

• ruby1.8: binaries (ruby itself, irb, rdoc)
• libruby1.8: the standard library, except ruby-tk
• libtcltk-ruby1.8: ruby-tk (merging it with libruby1.8 would add several megabytes)
• ri1.8: contains both the ri binary and documentation
• ruby1.8-dev: development headers (to build applications or gems linked against the Ruby C API), and statically built version of the library
• ruby1.8-elisp: Ruby emacs mode
• ruby1.8-examples: Examples
• libruby1.8-dbg: debug symbols

It is always possible to merge more packages, but merging any of the other packages would significantly increase the size of what you get by default, and might discourage people to use it in some contexts (disk space is not always cheap. Think embedded systems and smartphones). Myth: Rubygems is crippled in Debian There are two differences in the rubygems Debian packages. First, gems are installed in /var/lib/gems, not /usr/local/lib/gems. That is because rubygems are seen as state for the Rubygems package, not independant software installed separately. A change for this is currently being discussed, and should be done after the squeeze release. (I don t think that it s reasonable to push that change now). A consequence of installing to /var/lib/gems is that gems binary are outside of $PATH. After the change, gems binary would also be installed in /usr/local/bin. Second, gem update --sytem is disabled in the Debian package, because that would replace code from the Rubygems Debian package with code downloaded from the Internet, and can break your system in subtle ways. We have changed this (in SVN, not in any package in the archive yet) to allow gem update --system if a specific environment variable is set, which gives us the opportunity to display a warning message. Myth: Ruby is slow on Debian Ruby is built with the pthread threading code, because not using it breaks many native Ruby libraries (Ruby-gnome2, for example). And other Linux distributions are doing the same. There are some very old benchmark results floating around in some blogs that show that the pthread code has a performance impact of about 20%. There are been patches for that for a long time (applied in Ruby Enterprise Edition), but they were never properly sent back. Actually, all the discussions about this issue were rumors and blog posts, and there wasn t even a bug report about it! After the bug was reported properly, it was fixed in a timely manner. The fix is not yet included in the Ruby 1.8.7, but is being applied as a patch to the Debian package since 1.8.7.299-2. (So the Debian package is actually newer and faster than upstream Ruby in that regard). What makes Ruby so difficult to maintain in Debian? The main problems we have with Ruby are portability issues. The only officially supported platform for Ruby is IA32 (i386 in Debian), and everything else is best effort. It means that it is not even supported officially on x86_64/amd64! Debian supports a dozen of architectures, and the Ruby package has to work on each of them. Ruby 1.8 is mostly OK nowadays thanks to the help of Debian porters, but we still have serious problems with 1.9.2, since the test suite fails on sparc, hppa, ia64 and Debian GNU/kFreeBSD. Why doesn t Ruby use the alternatives system on Debian? The alternatives system provides a way to switch between different software providing the same functionality. Currently, if you want to use Ruby 1.9.2, you need to use the ruby1.9.1 executable (1.9.1 = ruby compatibility version here). The alternatives system would allow to switch ruby to ruby1.9.1 on a system-wide basis. However, the situation of applications and libraries working only with Ruby 1.8 should be clarified: those should use /usr/bin/ruby1.8 instead of /usr/bin/ruby. Another problem is that the way to specify packages dependencies still need to be determined. There s nothing impossible to do about that, it just needs someone to do the work. Where do we go from here? The Ruby developers (or expert users) community is generally very hostile towards Debian. Many harsh words and insults are used in discussions mentioning Debian in the ruby-core@ mailing list, and there are frequent recommendations to avoid the Debian packages and install from sources, which is quite demotivating (Actually, what prompted that blog post is someone calling Debian-specific changes unforgivable). This atmosphere makes it hard to recruit people, and the Debian Ruby teams are completely understaffed, which is clearly the major blocker to improving the situation further. We are 3 co-maintainers for the interpreter packages, and I m the only Debian Developer that is really active on a regular basis in the pkg-ruby-extras team (that does libraries and applications packaging). We desperately need help, but at the same time I have no time to improve our documentation and make it easier to join the team. While I haven t reached a final decision yet, I am also likely to stop doing Ruby work in Debian after squeeze is released, as I am getting increasingly tired and demotivated.

While SSDs are all the rage nowadays (and for good reason), I don't trust them yet for my important storage, as I'm not familiar with their failure behaviour. So when one of my hard-drives recently started misbehaving, I bought the new WD Raptor model. Since some people might be interested in how it performs in some synthetic tests under Linux, here are some fio results. Now, I admit that 10K RPM for desktop is a want versus need discussion, but nevertheless, these hard-drives are (for their capacity) quite affordable, compared to SSDs, and faster than a regular 7200 RPM drive. So:

# smartctl -i /dev/ 
 
Device Model:     WDC WD6000HLHX-01JJPV0
Serial Number:    WD-WXA1C20U0627
Firmware Version: 04.05G04
User Capacity:    600,127,266,816 bytes

The older hard-drive I'm comparing to is also a WD Raptor, the WD3000GLFS model (yes, I'm a sucker for shiny hardware). A few of the SMART capabilities seems to have changed (e.g. a new Phy Event Counter has been added, CRC errors within host-to-device FIS, and the SCT Status Version is now 3 instead of 2, the Temperature History Size is now 478 instead of 128), but nothing significantly different that I can see. First, the IOPS test: nothing changed here. To be honest, even the WD3000 model had pretty good performance. The fio job definition is:

[global]
filename=$ DRIVE 
iodepth=$ IODEPTH 
bs=$ BS 
ramp_time=10
runtime=120
[rate-iops]
rw=randread
ioscheduler=noop
ioengine=libaio
direct=1

I did tests for block sizes of 512 and 4096 bytes (but the results were so close that I only used the 512 bytes ones), and at queue depths of 1, 2, 4, 8, 16 and 24 (not 32 as AFAIK the SATA protocol only allows a max queue depth of 31, and I wanted to test only the drive's queue). So: As I said, nothing really changed, but starting at 130 IOPS and reaching more than 200 IOPS at queue depth 8 (which again, is not so much used at home) is nice. Next, the bandwidth tests. This uses the standard disk-zone-profile job shipped with fio:

[global]
bs=64k
direct=1
rw=read
ioengine=libaio
iodepth=2
zonesize=256m
zoneskip=2g
write_bw_log
[disk_zoning]
filename=$ DRIVE 

Here the changes are significant. Whereas the previous generation topped at around 110MB/s, the new model tops at over 140MB/s: I'm not sure what makes the old model vary so much at the start of the test (I repeated the measurement twice, and it looks the same), but in any case, there a few conclusions to be drawn:

• the new model is fast; the logs tell me that in the first 30 entries (zones), there are 10 entries with speeds of over 150000 KB/s (147MB/s)
• even though the capacity has been doubled, the time to read the entire drive (in zones) has only increased by ~62%, which is good
• I'll need more than Gigabit Ethernet to be able saturate just one of these drives in my storage box; even at the slowest, the drive is over 90MB/s

So, I can say I'm pretty happy. The 300GB model was a tiny bit too small for me, but the new size is great, and it seems the sequential read/write speed is also good. Let's see how long they will last though, HDD failures are (unwanted) friends of mine

It has been a pretty exhausting time since my last blog post in my area of Debian land . If you followed the news you should have seen some of it. Last weekend there was the point release. For those I have the (good?) position to sit in the middle of the working queue, where the hardest part (sorting out which stuff to include, getting it all build, etc) is already done. Still, due to the amount of steps neccessary to take its usually a multi-hour thing. This one release was even slower, as we had to wait for hours until the package lists had all been built - unfortunately the thing writing that keeps berkeley db files of data around as cache - and uses the FULL path to the files as key. How stupidly annoying when the path changes during a server move. Ohwell. The other big part that got a tiny bit of press coverage was the move from www.backports.org over to backports.debian.org. This was actually waiting for me for a good longish while already (err, well, since well before DC9 this was decided to happen) but now I finally got myself moved. This turned out to be much more work than I ever feared (which is part of the reason why it took so long), but some numbers:

• At the start the code changes between the revision running on oldbpo compared to HEAD: 303 files changed, 21227 insertions(+), 468357 deletions(-) (There had been 1723 commits in the master branch since the last time bpo got it, thats about a quarter of all we have in master!)
• Database schema version oldbpo: 5, HEAD: 35
• sub-sub-sub-optimal damn old shell scripts for the cronjobs.

The db update alone took me a week to figure out which steps to do in which order. Good to have an automated system, if you the manage to have the updates run specific to the main archive. Ups. When I was done with the database (during which I managed to just erase all work done by formorer and rhonda on the webpage, ups^2) I had some code and config cleanups to do, and especially manage to get it all running with a new path layout. Much less complicated, but enough work to do, before I finally was far enough to get it all move so far that formorer could start testing it and we could turn off the old system. At this time I had to fix up our shell scripts for our cron jobs, but that (with one exception) was a nearly straight forward easy task. And on Wednesday I managed another goal - backports is fully running the master branch of dak, the exact same code as on ftp-master. The cronjobs are slightly different, as well as the config (of course, duh), but otherwise its the same. My current goal and the last things left on this move todo is to change the cronjobs so that debian as well as backports do run the SAME scripts, but their configs list which tools should be run when. Considering that my dinstall cron already contains something pretty much a state machine I think I m insane enough to get this in shell, but when I told that to Mark (you know, the second ftpmaster :) ), I heard something very much like vomiting (you know, 700km between us, this might mean something) and then the plea to use a real language for the task. Oh my. I like my shell. :)

---

There is one big black cloud on the horizon to see. I have to do something similar for security. They are at a dak (and database) version pretty similar to what bpo had. They do need to support this obnoxious spare new format too before they can support security for squeeze, so there is no way I can ignore that archive for much longer. I already asked DSA for a vm in which I can play (not good to interrupt security archive for long), but probably wont start on this before the upcoming FTPMaster meeting. Pretty busy otherwise. Wellwell, I hope it will be less painful, as I now know the steps already. :)

I am a Debian developer again, and here's what I plan to do at first:

• continue driving DEP5 to conclusion
• help develop piuparts
• participate in Freedom Box development
• write some other tools to aid Debian development, perhaps one to help maintainer scripts create/remove system accounts more easily

I don't expect to do a lot of packaging work. I'll package, or help package, stuff that I develop, but I'll not be specifically be looking for stuff to package.

GSoC 2010 is over for some time and I should write some summary how students projects ended up. The very short summary is that all five students were successful and their work got merged. Follows description of the project in no particular order. Thanks to Martynas Mickevicius you can now get charts out of various parts of phpMyAdmin. They are used on server status pages or you can get query results in form of several charts. It seems to work pretty well at least what I've tried so far. Ankit Gupta was working on Visual Query Builder for phpMyAdmin. Unfortunately this is only project which is not yet merged to master branch, mostly because some UI things were not yet finished. But hopefully it will be merged soon. Adnan Mughal was converting our schema export feature from PDF to support multiple formats. You can now get the schema as SVG, DIA or even Visio formats, some of them will require a little bit of tuning still, because the scaling is not perfect. Ninad Pundalik did a lot of work on AJAXifying phpMyAdmin. His changes touched quite a lot of places and there are still some rough edges (as you can see in our bug tracker), but this is definitely welcome improvement and I hope it will get stable soon. Piotr Przybylski basically continued in his effort two years ago when he had reimplemented setup script and now he had focused on user configuration. It can be stored in session, browser local storage (HTML 5 feature) or in separate table in phpMyAdmin configuration storage (that's new name for pmadb). This is something what people were requesting for very long time and I'm happy we can finally bring this feature. And last but not least is Lorikeet Lee, who spend lot of time on tuning user interface of phpMyAdmin. The most visible changes are on export and import pages, which now should be less scaring for new users, but there are other changes in lot of other places, for example the main page. Generally it was a great summer and I hope we will be so successful also next year. PS: You can try all these features on http://demo.phpmyadmin.net/.

GSoC 2010 is over for some time and I should write some summary how students projects ended up. The very short summary is that all five students were successful and their work got merged. Follows description of the project in no particular order. Thanks to Martynas Mickevicius you can now get charts out of various parts of phpMyAdmin. They are used on server status pages or you can get query results in form of several charts. It seems to work pretty well at least what I've tried so far. Ankit Gupta was working on Visual Query Builder for phpMyAdmin. Unfortunately this is only project which is not yet merged to master branch, mostly because some UI things were not yet finished. But hopefully it will be merged soon. Adnan Mughal was converting our schema export feature from PDF to support multiple formats. You can now get the schema as SVG, DIA or even Visio formats, some of them will require a little bit of tuning still, because the scaling is not perfect. Ninad Pundalik did a lot of work on AJAXifying phpMyAdmin. His changes touched quite a lot of places and there are still some rough edges (as you can see in our bug tracker), but this is definitely welcome improvement and I hope it will get stable soon. Piotr Przybylski basically continued in his effort two years ago when he had reimplemented setup script and now he had focused on user configuration. It can be stored in session, browser local storage (HTML 5 feature) or in separate table in phpMyAdmin configuration storage (that's new name for pmadb). This is something what people were requesting for very long time and I'm happy we can finally bring this feature. And last but not least is Lorikeet Lee, who spend lot of time on tuning user interface of phpMyAdmin. The most visible changes are on export and import pages, which now should be less scaring for new users, but there are other changes in lot of other places, for example the main page. Generally it was a great summer and I hope we will be so successful also next year. PS: You can try all these features on http://demo.phpmyadmin.net/.

A few days ago I talked about how noisy my new Dell Studio 15 was but I can now report back with the beginnings of a solution to that problem, and it doesn't appear to be ACPI related. The first clue I needed was that if I switch to the proprietary fglrx drivers for the Radeon the fan quite quickly drops off to a much more reasonable level. It seems the fglrx drivers have issues, however, in particular I get big black patches on my screen. This video corruption happens especially in Firefox, but sometimes in other applications as well. They also appear to screw up my suspend/resume, which is probably even more annoying to me. The second clue that I needed was that Radeon power management support has only just made it into recent kernels. Thanks to Michael Kirkland for providing me with both of those clues :-) Looking under /sys/class/drm/ I find a whole bunch of stuff, but in particular there are /sys/class/drm/card0/device/power_method and /sys/class/drm/card0/device/power_profile. Looking through the kernel source code I can see that power_profile can be set to low, mid, high, auto and default, while power_method can be set to either dynpm or profile. Trying out all of these values, it seems I get the quietest result with the profile method and either the low or mid profile. The dynpm method is nearly as good, and I would think it should really be the default for a 'Mobility' chipset. From the detailed benchmarking that Phoronix did I wonder if it shouldn't be the default for everyone. For myself, I see some small 'tearing' artifacts occasionally when running with the low profile. These disappear when I run with the mid profile, and since that seems to have pretty much the same temperature (and noise) results I'll go with that one. Though the laptop often does still make more noise than I would prefer it to, it is no longer annoying everyone in the room. Not unexpectedly this seems to have a huge impact on power use, too. It appears that the laptop should now give me around 4.5 hours when I do everything I can think of to lower the power use, whereas before it was more like 2.5 hours. Now I guess I can get back to hacking on DAViCal...

After a semi-recent thread on debian-devel, I poked around and realized that I'd never actually gotten around to formally announcing the release of source code for Selectricity, a piece of web-based election software designed to allow for preferential decision-making and to provide "election machinery for the masses." Selectricity is useful for a range of decisions but it targets all those quick little decisions that we might want to decide preferentially but where running a vote would be overkill. Things were delayed through a drawn out set of negotiations with the MIT Technology Licensing Office over how to release the code under a free software license of my choosing. I was swamped when things finally came through. Over time, I managed to forget that I never did a formal announcement, never setup a mailing list, and never did all those things that I have tried to teach other people in the Free Software Project Management HOWTO. Code just sort of appeared on my website under the GNU Affero General Public License. It was until the debian-devel thread that I remembered I'd never made a formal announcement. Sorry about that! The git repository has been online and accessible through searches for more than a year now. Most folks who wanted the code seem to have been able to find it there. Indeed, a number of people have set up their own instances and a few have submitted patches to the code! But more visibility for the source means more empowered users, more visibility for free software, and more developers. So I've shipped all the code into a project in Gitorious (its like GitHub, except free), announced things on the Selectricity Blog, changed the Selectricity footer of to include a prominent link to the source. I've also created a mailing list. The Gitorious project page includes a wiki. I also want to mention this all here because the attention of the current development team seems mostly to have moved on to other projects. The current team seems able to keep the hosted version up and running, and even gets around to little improvements now and then, but there's definitely room for new life and new leadership. There are some nearly-complete and "complete minus further testing" features in the development tree that might provide low hanging fruit for folks interested in elections and decision-making who might want to get involved in Selectricity development. If you're interested and know (or want to learn) Rails, feel free to check out the code, introduce yourself on the list or contact team@selectricity.org to coordinate.

I'm swinging on the front porch shade, with happy wifi bars lit up on my laptop. A good network makes for a happy home, isn't that how the saying goes? (Maybe not yet.) Typically that's easy to achieve -- here it wasn't. The house is solar powered, the only connection to the outside is a phone line. So I needed a computer that would work in that environment, using minimal (12 volt) power, and getting the most out of the limited bandwidth while providing those happy wifi bars. At DebConf we learned that the name for these little home servers we have been building for years is "FreeDomBox". All right then, here's my latest FreedomBox build.

A typical inexplicable tangle of computer bits.

• Computer: NSLU2. There are faster choices than the "Slug", but on dialup, speed doesn't much matter, and there are not many lower-powered choices. And with the NSLU2, I can take advantage of years of development and experience, that has resulted in great support for running eg, Debian on it, and deep available knowledge of hardware hacks. It's proven, cheap, highly reliable hardware, and I had it lying around.
• Power: The NSLU2 is a 5 volt computer. There are some highly (90%) efficient 12 volt to 5 volt converters, which I covet. But the cheap and easy option is a automotive USB power adapter. So power is coming in to the NSLU2 on a USB cable. It's possible to just plug that into its usb port and it will run. But that wastes a port. Instead, I made the other end of the usb cable have a NSLU2 power socket on it. So, no wasted ports. The system has available as many amps as the voltage converter supplies. Not many. Booting it with too many usb gadgets attached could be an issue. (If I need to run an external usb hard drive, it had better have its own power supply.)
• Wireless: ZyDAS 2501 USB dongle. Not my first choice, just one I had lying around. This device cannot run in AP mode. It is, by the way, possible to use some USB dongles in AP mode with a modified hostapd, but the few I know that work are out of stock. No problem; this house won't have many visitors, and I can tell them the details for connecting using Ad-Hoc wireless mode.
• Storage: 64 gb thumb drive I had lying around. Hmm, last time I touched a NSLU2, I had only 1 gb drives lying around. Progress.
• Modem: My NSLU2 is modified to have an external serial port, so I can use an external modem if desired. But I suspect a USB modem will use slightly less power, even though this third USB device means I need a USB hub too. I was doubtful about finding a USB modem dongle that works with Linux, but it was actually no problem, the USR5637 Just Works.
• Software: Debian Linux of course. For the first time I'm using the polipo web proxy cache, and it works marvelously on dialup and on this low-spec system. Combined with dnsmasq, this makes web browsing over dialup actually not painful.

Since the solar house is in the sticks, the result is a server I call "stick".

I finally finished an article I've had in one form or another for years about on the use of proprietary tools in the creation of free software. From BitKeeper to SourceForge to Google Code to GitHub, non-free tools and services have played an important role in free software development over the past decade and, I argue, continue to create a number of important, if sometimes subtle, problems for our community. The article was published in the Spring 2010 FSF Bulletin which was mailed to all FSF associate members. I've also posted the article on my website and in PDF form as well.