Applications are still open until March 26th. Note: the following is my personal opinion; I'm not the coordinator of the Debian GSoC project, and others might disagree. Debian has received a couple of applications, but there were rather few among them I found really convincing. :-( What I usually dislike in applications:

• doesn't state an actual project (yes, this happens, we nuke them pretty quickly. "Debian for my life" is not a real project, you know...)
• isn't related to Debian. For example "face recognition PAM module" certainly is an interesting topic, but I don't think Debian is the appropriate organization to mentor this. We aren't an organization of image recognition experts, but our key strength is distribution infrastructure.
• doesn't say much more than the suggested topic already did (note that for such 'popular' topics from the Wiki we usually receive more than one application; so adding some good ideas yourself or at least writing a good plan is key to being accepted!)
• doesn't give the impression of having done some basic background research, such as having searched in the Debian packages repository with "apt-cache search"

So if your application is really Debian-related, invest a few hours in writing the application and your chances are pretty good at being accepted! Of course Debian could be an Umbrella for e.g. another network configuration GUI, a tool to configure traffic shaping etc.; however I don't think that should be our focus. In fact, Google itself could mentor these topics maybe as good as we can. So please don't just submit a proposal to us because you happen to be a Debian user, or submit it to all mentoring organizations. Instead try to find an appropriate mentoring organization. (On a side note, the mentoring organization is supposed to provide you with a mentor which can actually help you on the topic). Debian is a good choice when it comes to integrating software, software management, system administration and such. Thats what we do: collect existing software and try to make it work together as good as possible. And build infrastructure and tools to make this task easier. This of course touches e.g. porting to different architectures and writing new administration frontends, however we try to avoid reinventing the wheel. One of the suggested topics, where I'm really surprised to not having seen a proposal yet is CRMI; which matches what I sometimes call a "per package wiki for metadata". Or a Debtags related project. Or a SELinux project. These are both pretty interesting technologies, which offer substantial benefits when actually used. When properly integrated in the distribution.

Marc, fwiw imo LCD-displays and RAM-memory are much more fun :-) ymmv.

I keep wondering why people keep writing HUB, WEB and SPAM, where the correct technical terms are Hub, Web and Spam. Neither of the three expressions is an acronym. Well, SPAM is, but Spiced Pork and Ham is a Trademark of Hormel Industries, and they ask people not to use their trademark to talk about Unsolicited Commercial/Bulk E-Mail on the Internet. They do, however, allow the expression Spam to be used for UCE/UBE. Any idea why people keep treating Hub and Web as an acronym? It disturbes my reading tremendously.

I've talked a lot lately about different VCSs.

I got some interesting comments in reply to my most recent post. One person took issue with my complaint that nobody really understood how to specify a revision to git format-patch, and proceeded to issue an incorrect suggestion. And a couple of people complained about my comments about bzr, which generally came down to the released version of bzr didn't have anything compelling and also didn't support tags.

So I went into #bzr, asked them what bzr has that git, Mercurial, and darcs don't. And gave bzr the benefit of the doubt that 0.15 will be out soon and will be stable. What I got back were these general items:

1. Renaming of directories (not in hg, git)
2. 2-way sync with Subversion (not in hg, darcs)
3. Checkouts (not in any others by default)
4. No server-side push requirement

Let's look at these in more detail.

1. Renaming of directories

All of them can rename files and (excepting git) completely accurately track back the file's history. But consider this: if person A commits a change to branch A that adds a file, and person B then renames the directory that the file is in on his branch, will a merge cause person A's file to appear in the new directory name? In darcs and bzr, yes. In Mercurial and git, no.

So yes, this is a nice thing. But I have never actually had this situation crop up in practice, and even if it did, could be trivially remedied. I would say that for me, I don't really care.

[Update: Current stable releases of Mercurial can do this too. I'm not quite sure how, but it does work. So git is the only one that can't do that.]

2. 2-way sync with Subversion

This is a really nice feature and is present in both git and bzr. I haven't tested it either place, but if it works as advertised -- and properly supports tracking multiple related svn branches and merges -- would be slick. That was enough to make me consider using git, but in retrospect, I so rarely interact with people using svn that it is not that big a deal to me.

Still, for those that have to work with svn users, this feature in bzr and git could be a big one.

Better yet would be to get all those svn holdouts over to DVCS.

3. Checkouts

A bzr checkout is basically a way to make local commits be pushed to the remote repo immediately, as with svn. This is of no utility to me, though I can see some may have a use for it. But it can be done with hg hooks and probably approximated with scripting in others.

4. No server-side process necessary for pushing repos

bzr has built-in support to push to a server that has sftp only, and doesn't require a copy of itself on the server. While I believe that none of the other three have that, it is possible to rsync (and probably ftp) darcs and Mercurial repos to a server in a safe fashion by moving repo files in a defined order. Probably also possible with git. All four can pull repos using nothing but regular HTTP.

What bzr still doesn't have

Integrated patch emailing. The big thing is that it has no built-in emailing of patches support. darcs is extremely strong in this area, followed by hg, and git is probably third. "darcs send" is all it takes to have darcs look at the remote repo, figure out what you have that they don't, and e-mail a bundle of changesets to them. I posted an extension and later a patchset that does all this for Mercurial except for automatically figuring out what default email address to do (that'll come in a few days, I think). One feature Mercurial has had for awhile that Darcs hasn't is sending multiple textual diffs as a thread, with one message per changeset. bzr doesn't have any support for emailing patches yet, which is disappointing. Because of the strong support for this in darcs and Mercurial, people running those systems feel less of a need to publish their repos.

[Update: There is a plugin for bzr that seems to address some of this. I haven't tested it, and it's not in bzr core (so doesn't quite meet my very friendly for a newbie requirement), but this does exist, though apparently not as advanced as Mercurial]

Performance. Supposedly 0.15 is supposed to be better on this, but even if bzr achieves the claimed doubling of performance, most benchmarks I have seen would rate it as still being significantly behind git and Mercurial, though it may overtake darcs in some tests.

Extensive documentation. I would say that bzr's docs are better in some ways than git's (its tutorials especially), but lack depth. If you want to know some detail about how the repository works on-disk, it's not really documented. Darcs still has David's excellent manual, and Mercurial has the hg book which is still great as well.

Merging not as advanced. darcs is pretty obviously way on top here, but of the others, Mercurial does a pretty good job with its automatic handling of renames and automatic resolving of different branches that commit the same change (even if that same change is a rename, or an add of the same content). bzr can't resolve as much automatically.

Summary

Well, I'll say that bzr still doesn't look compelling enough for my use cases to use, and the lack of an easy-for-a-newbie-to-use automated email submission feature is a pretty big disappointment. Though I did appreciate the time those on #bzr spent with me, and if I needed to sync with svn users frequently, I'd probably choose bzr over git.

For now, I'm happy with sticking with darcs for my code and hg for my Debian work.

But all four communities are aggressively working on their weaknesses, and this landscape may look very different in a year.

Adrian von Bidder made an interesting post in response to my post about Spanish wind power. He correctly points out that power sources that have seasonal variations and which may vary during the course of a day can not be used as the sole power source.

The ideal design would be to have wind power stations that are designed to have a peak power that is greater than the expected use for the country. Then when wind power is slightly below peak the entire use for the country could still be satisfied.

There are a number of power sources that can quickly ramp up, this includes hydro-electric and gas-fired power stations. Such forms of power generation could be used as backup for when wind and solar power are limited. Incidentally one thing to note about Solar power is that it is most effective during the day in summer - which is when there is the highest demand for electricity to run cooling systems. There is also an option for having the sun heat up rocks which can be used for generating electricity at night or at periods of peak demand. So eventually we could have all our energy needs supplied by solar and wind power.

If wind power was designed to exceed the demand at windy times there are a number of ways that it could be used. The first thing to do is to implement billing systems that vary the cost according to the supply. This information could be provided to customers via X10 (or a similar technology). Home appliances could take note of this information and perform power-hungry operations when it's cheap. Your freezer could cool itself to -30C when electricity is cheap and allow the temperature to rise to -5C when it's expensive. You could program your washing machine to start when electricity becomes cheap - usually a few hours delay before starting the washing is no inconvenience.

Ideally home power generation from solar and wind sources would be used. There is significant loss in the power lines that lead from power plants to the consumer, so there are efficiency benefits in generating power locally. A wind turbine for a home will give highly variable amounts of power, and the electricity use of a home also varies a lot. So batteries to store the power are required. When you have local battery storage you could use your batteries to power your home when electricity is expensive and use mains power when it's cheap. Also if it was possible to feed power back to the main grid then home battery systems could be used to help power the main grid at expensive times (if the electricity company reimburses you for putting power back in the grid then you want such reimbursement to be done at the highest rate).

Adrian also mentioned turning devices off when leaving home. It is common practice in hotels that when entering your room you will insert your key in a holder by the door which acts as a master switch for all lights and some other electrical devices (such as the TV).

This same idea could be adopted for home use, not based on key storage (although this would be an option) but instead on a switch near the front door. Push a button and all lights turn off as do human-focussed appliances such as the TV and DVD player turn off (not the VCR), etc. There could also be a night option which would turn off the TV, DVD player, and most lights. Obviously at night you want bedroom and bathroom lights to still work but many things can be turned off.

This is all possible with today's technology, small changes to usage patterns, and spending a little more money on technology. Currently you can get a basic solar power system for your house for about $10,000. That isn't much when you spend $300,000 or more buying the house!

please stop writing mails asking me whether I’d like to mentor your yet-another-reportbug-alternative project. It’s not that I’m opposed to the idea of rewriting reportbug(-ng) for gtk or as a webapp — really. I just don’t see why your project needs to be part of SoC. I know working for/with google is kinda sexy nowadays and as a student you can even get some money — but be honest: what was Debian’s benefit of last year’s SoC projects? My question which of last year’s projects failed and which succeeded is still unanswered. So no, I’m not yet jumping on this bandwagon everybody seems to be so exited about. Don’t get me wrong: I don’t hate google or the SoC, I’m just not convinced of the success of our last year’s projects, plus I don’t think we need such an event to write useful tools for Debian. NP: The Beatles — Happiness Is a Warm Gun

OK, Having agreed that Openid is a good idea to solve the multiple-login-issue, i've been looking at enabling it on the python-based projects I work with. Harder than it looks, for no apparent reason. Firstly, I've succeeded in enabling an Openid Server in my Pyblosxom blog. Just google to pyblosxom+openid+server and install. It works. Now I can log into openid sites with my blog address http://blog.scealnetworks.com. Alternatively, I can openid-enable the comments login on the blog by installing the openid comments plugin. Unfortunately this seems to conflict with the server above, and both seem to conflict with Debians python-openid. All three seem to have a common original codebase that has diverged, but I haven't had time to do any software genealogy and figure out which codebase is out of date. Any ideas anybody ? (other than emailing everyone involved). Secondly, I'd like to share the logins with my MoinMoin wiki. Again, a patch has been written for this, but to share the logins between pyblosxom and MoinMoin will need co-ordination. My current plan is to try and get all related openid sites to share /srv/www/openid-store on the server to share identities. This'll need patches, and probably justify making Debian packages out of the plugins. Finally, I'm working on a Plone website for IFAS, for observation tracking and co-ordination (see aop.irishastronomy.org and aop-test.irishastronomy.org if you're interested). Here, all the users already have logins on a related system in PHPBB on a different host. It would be nice to integrate them : query the SQL database on the PHPBB site? give them openid identities from the PHPBB machine?

Today's featured spam is from Digital Parts, Rowan House, Bricklehampton Lane, Pershore, Worcestershire, WR10 3JT sent via ukcompanydeals.com and reroute-all.com. They get a special mention for including the fully buzzword-compliant footer

"Marketing communications are delivered in accordance with EU Directive on Privacy and Electronic Communications. [...] All communications are targeted to business users only."

and then sending their weasel words to one of my personal org.uk addresses, clearly marked as "UK non-trading individual" at Nominet. No real contact details included, so if you get the same spam, please link this to help them find themselves on search engines.

There are times when you want to track the bleeding edge of a particular project, and having a new laptop is often one of those moments... I've recently bought an HP Compaq nx6320 and while most of it is working, one of the reasons I got it was because of Keith Packard's work on the RandR extensions for X. Well, I was definitely seeing this bug but with a small patch I can get the latest (experimental) packages for xserver-xorg-video-intel to work, and now with a few magic tweaks to my xorg.conf I can make my desktop expand to another monitor when I unsuspend at work, and contract back to just the laptop screen when I resume somewhere else. The Magic Expanding X Config First of all, when I got the driver to actually work, xrandr explained to me that my maximum resolution was 1400x1400:

Screen 0: minimum 320 x 200, current 1400 x 1050, maximum 1400 x 1400
VGA disconnected (normal left inverted right)
LVDS connected 1400x1050+0+0 (normal left inverted right) 305mm x 228mm
   1400x1050      60.0*+
   1280x800       60.0  
   1280x768       60.0  
   1024x768       60.0  
   800x600        60.3  
   640x480        59.9  
TV disconnected (normal left inverted right)

Using a few clues from Ross Burton I managed to get that "maximum 1400x1400" to increase. The trick is to add a "Virtual" setting for screen size into your "Screen" Section, like so:

Section "Screen"
        Identifier      "Default Screen"
        Device          "Intel 945GM/GMS/940GML"
        Monitor         "Laptop Panel"
        DefaultDepth    24
        SubSection "Display"
                Depth           24
                Virtual         2680 1050
        EndSubSection
EndSection

The downside of this is that if you set the width greater than 2048 (as I have here) then DRI won't work, so you won't get 3d stuff. I guess I can manage without ice-cream, just so long as I get my cake! Once I have the "Virtual" setting, when I resume at the office I can:

xrandr --output VGA --mode 1280x1024 --pos 1400x0

And then when I resume somewhere without the external monitor, I can:

xrandr --output VGA --off

Quibbles All of these features are kind of under development, but Xorg 7.3 will support this stuff, and then Gnome and suchlike will have to start thinking about how to deal with it. The dynamic screen changing is not something these environments are completely ready for. One example is that while I know that monitor is always on the RHS of my docking station, X wants it to be the primary monitor and Gnome moves both panels onto that screen. Perhaps that's not a choice that can be made automatically. Someone who had an external keyboard plugged into their docking station might want the opposite behaviour, and there is certainly no way the environment can magically know whether that monitor is left or right of my laptop screen. Eventually I expect that Gnome will recognise this monitor, and will make the panels and location automatically set the RandR environment to match the way I set it last time. It is also somewhat annoying that I have to actually choose the virtual size. No doubt this configuration will disappear in due course and it is not really surprising to see it for something which is admittedly quite bleeding edge! I noticed at LCA that Keith had his own screen set for a Virtual size of 2048x2048, and now I know why: that's the maximum size that is supported for DRI, so if I expand my desktop onto a 1280x1024 screen I'm going to have some overlap. In fact I could almost configure my external monitor to be above my normal screen and use it that way, but it would feel pretty weird I think. In the meantime I've gone back to "blank screen" for my screen saver which admittedly is currently the only application for 3d acceleration on my desktop. Remaining Problems with this Laptop The only outstanding issues for me with this laptop are:

• Suspend/Resume to RAM does not work (I use suspend to disk)
• Fingerprint Sensor does not work (AuthenTec say Linux support will be available later this year)

That's about the best Linux compatibility I have had for any of my last five laptops within a month of buying it. Most of them have had much more significant stuff less supported even after three years of use!

I know I'm pretty quiet since several weeks. I had to give up my work on several front, including Debian, my stupid idea to do some things for the DPL election and my world domination project.
I'm currently on holiday all the week, and I am taking a break from computer activities, in favour of real life ones. I know that I won't have more time in the next weeks, but I expect to be back online one day. ;-)

For those who care about kids... I recently blogged about TMBG s marketing genius in releasing kids albums that adults who grew up to TMBG will love and buy. Another good example of kids music that you, too, can enjoy is Ralph s World. It's not quite as ironic or odd as TMBG, but still a good listen. Check out, for example, the RealAudio clips for Clean-Up (much better than the Barney version!), Baa-Baa Black Sheep, and The Coffee Song. Speaking of Barney, apparently his music has been used to torture Iraqi detainees. Technorati Tags: Children's Music, Music

The latest news is that Spain has wind power as it's main source of electricity. The second largest source is nuclear and the third is coal. This is due to some particularly windy weather recently, but Spain is also a world leader in both manufacture and installation of wind power systems.

Other countries should follow their lead. Wind power is very cheap once it's installed, there are minimal ongoing costs and when things go wrong the scope of the problem is very small (unlike nuclear power plants which have the potential to contaminate large areas).

Sorry no link, this news is too new to be indexed by google.

Recently I bought a HP DL385 Opteron server at auction. It has an Opteron 265 1.8GHz dual-core CPU and is designed for SFF (Small Form Factor) SAS disks.

A friend told me that S-ATA disks would work in it and so would a faster Opteron CPU. I bought 3 S-ATA disks which work fine in a RAID-5 array. Unfortunately when I tried booting with the second CPU installed the BIOS said that it detected a CPU speed mismatch and would halt.

If anyone knows of a way of swapping Opteron 265 CPUs so that I can get a pair at the same speed then please let me know. I'd prefer to swap the 1.8GHz one for a 2.2 GHz one if possible, but the other way is also an option.

Hobix There were some issues concerning Hobix and the new Ruby (1.8.6) that entered Sid recently. I’ve solved the problem, as you can see, and uploaded a Subversion snapshot package to experimental. Update: It seems that hobix 0.5~svn20070319-1 accidently was uploaded without share data. This was spotted and fixed by Arnaud, thanks! A new version (0.5~svn20070319-2) is on its way to experimental! Ruby D-Bus A few weeks ago I wrote to Arnaud Cornet about the fact that it is quite amazing that there is no up-to-date implementation of D-Bus for Ruby at all after such a long time. This resulted a few days ago in our Ruby D-Bus project. Some stuff is working already, quite low-level still, but really nice. I’m looking forward to designing the high-level API. I found out that other people had the same thoughts as us and also started to work on an implementations on their own without telling anyone. So, it seems there are three implementions now (as far as I know) that all have specific features working. I hope we can merge everything into one project. We’ll see what happens… OpenID I have taken some interest into OpenID, having to register some accounts on arbitrary forums. I ran into the fact that Rails recently got OpenID support and that support for phpBB is coming up, which is nice. Finally it could be over with all the logins and all the password. At the moment I haven’t found a statisfactory identity provider yet, so I started working on my own service. Ruby OpenID has an example server implementation which I am working on to become FLOIDS: the Free Luon OpenID Service. Koditoj Recently, I inventoried all the programs I authored or co-authored in the past 8 years. There is some stuff in there that maybe deserves a second life or at least some description. So, in a series of posts that I’ll call ‘Koditoj’ (free translatable from Esperanto to ‘things that have been coded’) I want to go over all these programs and libraries and give them some attention. More to come soon…

2007-03-21: (the "so use a news search service that works instead of Google, then" update): Spain's wind energy reaches new high

CompWizrd commented:

"You can also get water faucets that are limited in the maximum temperature they'll put out.. it mixes in cold water as needed to keep the temperature down Far as I remember, they're required nowadays anyways.. Or maybe it was the pressure regulated ones.. those keep the temperature at a set level. Even if someone flushes the toilet, it will reduce the hot water coming in, to keep the temperature regulated."

I read somewhere that there's a maximum of 49C for new fittings in the USA, but I'm not sure there's a limit here in England yet.

Working on cluster testing is not easy and debugging can be extremely more complicated that you can think of given the distributed nature of the software you are running. So RedHat Cluster guys (Patrick and Lon) and I have been sitting together on IRC for the past couple of days trying to figure out what the hell was wrong with this bug that did block services from being switched from one node on the cluster to the other that is sort of vital functionality for a cluster itself. Everything turned up to be a kernel race condition in the DLM (Distributed Lock Manager) that we were able to workaround in userland by changing the way the resource manager tells the kernel (via libdlm2) to de-allocate the lock_space with a one liner. So what's the point? Simple.. these guys could have just turned me down and send me away since we were testing on Ubuntu, but they didn't. They have been of great help (nevermind that you can really have a good time working with them) and extremely responsive. They really rock hard. Clearly.. get to know your upstream! it's vital for your activity as Ubuntu Developer. Get to know what you are working on! Packaging is not just a matter of creating a debian/ dir in your source to build the code and ship a .deb. You have to know what's in that code and how things work. Upstream can always help you, but you need to be helpful to upstream too and let them understand that you are not just another packager for yet another distribution.

Now that live-helper¹ has superceded live-package I have a config for the junior livecd work-in-progress in the debian-live repository:

sudo apt-get install live-helper
svn co svn://svn.debian.org/debian-live/configs/junior
sudo make-live --root junior &>make-live.log

This will build a usb image for the gnome-junior package list. If you want a regular iso image or want to try the kde-junior or xfce-junior lists, just make the appropriate changes in config. I have tested the usb image on a 1G usb key. At this point I’m not layering on customizations, but am focusing on basic usability issues: X autoconfiguration, sound, menus, etc. Once I’m happy with these I’ll move on to the kinds of customizations we’d like to make for children.

¹ live-helper is still in NEW at the moment. I’ve been checking it out from svn and building the package myself, though you can also get Daniel’s packages from his site. My config should work with a2-1 or later.

update For the time being it is best to stick with live-helper from svn, as my configs are being developed to work with trunk, which is still in flux (e.g. config variables are renamed without notice, etc.)

svn co svn://svn.debian.org/debian-live/dists/trunk/live-helper
cd live-helper ; debuild -us -uc

A Business Week Article points out that Ethanol fuels in the US face opposition because of rising corn prices. Since 25% of the US' corn supply winds up going to Ethanol, that apparently leaves less for livestock.

Last year at Opus, someone had brought along signs that said "Support Your Soybean Farmers", followed by a URL http://thankachicken.com/. While it was funny, it was an interesting reminder that vegans really *aren't* the target of North American soybean producers.

According to a the Wikipedia article on Environment Vegetarianism, "the inefficiencies of meat, milk and egg production range from a 4:1 energy input to protein output ratio up to 54:1". Perhaps the solution to driving our cars as much as we want on clean fuel is to go vegan? What do you suppose would give first, our car addiction, or our meat addiction?