John Goerzen recently posted about Git, Mercurial and Bzr that I found interesting, especially since I used to be in the hg camp, but have been gradually using git more and more, even to the point making minor improvements to the git documentation and writing the git mergetool, since being able to automatically fire up a graphical merge tool was one of the features which I missed from hg. So while I haven't yet converted the primary SCM repository for e2fsprogs to use git (yet), I've reached an opposite concolusion from John, and yet, I can't really argue with his observations.

The main reason why I've come out in favor of git is that I see its potential as being greater than hg, and so while it definitely has some ease-of-use and documentation shortcomings, in the long run I think it has "more legs" than hg, and with the release of git 1.5.0, it became clear that the git community was willing to work on these particular shortcomings, which is why I started working on it and making plans to migrate e2fsprogs to use git. The main reasons why I think git is more powerful is that not just that it supports lightweight branches inside a single repository (although I really do like that a lot since it makes it a lot easier to run multiple experiments in parallel and switch back and forth between them), but also because git is much more Unix-like; there are lots of tools that enable scripting for either new git extensions or for ad-hoc shell pipelines that you can't really easily do in hg without breaking into Python.

But git definitely does have shortcomings, and John is on the mark with most of them. Git's documentation is very poor. Part of the problem stems for tutorials that were written to work with older versions of git (don't try using anything older than git 1.5 if you are a git newbie; git 1.4.x is far more user-hostile) or were written for use with systems built on top of git 1.4.x, such as Cogito. (I don't recommend Cogito, since git 1.5 is significantly more usable, and I've always found Cogito to be more confusing that just using stack git.) The tutorials that are distributed with git 1.5 are much better, but they clear do need more work.

It is true that the many of the man pages in git are lacking, and John's criticism of the fact that many man pages do not list all of the options that they take, but rather refer to other man pages is on point and accurate. It has gotten better (take a look at the git-diff man page from the git 1.4.x days, and laugh or cry, depending on your point of view) but there is still much work to be done. In practice, the better way to use the git man pages is to skip past the options section, and take a look at the Examples section. This shows a number of ways that a particular command might be used, just as a Unix master might say, "Grasshoper, see how you can use awk to do all of these amazing things."

I do take issue with John's assertion that git's philosophy has been to make life easy for the central maintainer, and not to pay much attention to the needs of individual contributors. That may have been Linus's development priorities but with Junio having taking over maintenance, there have been a lot of improvements in git 1.5.0 to make life easier for people who are tracking remote repositories and making changes, in particular the git remote command.

The most interesting observation which John made was the non-intuitive semantics of git-format-patches, and I did find it interesting that one commenter posted a solution which made perfect sense given other git commands, and yet didn't work. Obviously the person who posted the comment didn't bother to try it first, probably because in most other places git is actually pretty consistent; but git-format-patch is one of the places where most painfully is not. I view this as a bug that should be fixed, and fortunately I think it can be fixed without breaking the git-format-patches is currently being used. (The problem is that it doesn't use the standard notation so it is more convenient in the common case of how it is normally used, where the end point is not specified and is always the the tip of the current branch. I believe we can avoid the UI surprise by making git-format-patch use the standard revision range parsing if parameter contains the ".." or "..." operators. I'll have to try to prepare a patch which does this and see whether it gets accepted.)

So basically git does have short-comings, yes, but people will come out in different places about which tools is best for them, and that's OK. Actually, I think the ultimate solution for this problem is to build a bidrectoinal hg/git gateway. There are tools that will export from hg to git, and vice versa, and they are actually pretty sophisticated. I don't think it should be that painful to create a tool that does incremental exports in both directions, maintaining state so that the right thing happens when a commit gets made on the git side, and gets exported into hg, or vice versa. Ultimately I think that's the best solution, since that way people can use whatever tool they want, and still contribute and development as first class citizens. This is the main reason why I've held off on converting e2fsprogs to git (although I have made some private test repositories which I'll use to take advantage of git's superior annotation and query/log utilities); I don't want to make a git repository of e2fsprogs public until I'm sure that a bidrectional gateway tool won't require me to make any changes that affect the commit-id's, since that would invalidate any work that people have done that was based on a clone of the coverted git repository.

I have a rough design for how to do the bidirectional gateway, but the issue is finding time to implement it. Anyone with free time looking for a project? If so, contact me. I probably should have written this up as a potential Google Summer of Code project, but it's too late for this year. Oh, well.

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.

Update: Fixed. The workaround described in bug 345700 works perfectly.

Add Option "XaaNoSolidFillRect" to the Screen Section of /etc/X11/xorg.conf, as described in the bug report.

It's hard to identify initially - first thoughts are always to blame Gecko-based browsers but gradually the problem migrates into the nvidia driver.

When editing text in a HTML form entry field, moving the cursor with the cursor keys results in horrid vertical lines: a b c 4 e which disappear when clicking elsewhere in the control but make editing VERY difficult. The vertical lines do not always appear between characters, they often overlay the characters, something I cannot represent here. (The bug report provides a good description.)

It is definitely something to do with Gecko because Gtk does not suffer this problem (which is one reason why I use drivel for blog entries).

Galeon, Iceweasel and epiphany-browser are all affected.

One simple example is the Debian wiki - normal, uncomplicated text inputs, no special Javascript, but moving around the text in a control is almost impossible.

Using realcsh, it's pretty simple to find out cpuid instruction is going to give you.For example, when EAX=0, cpuid returns you some kind of vendor id.On my system, it gave me 68747541 444d4163 69746e65, which obviously is 'AuthenticAMD'.

I'm looking for inspiration - and for someone else with the same problem - to work out how to fix and/or report a long-standing problem with all Gecko-based browsers in Gnome with nvidia.

When editing text in a HTML form entry field, moving the cursor with the cursor keys results in horrid vertical lines: a b c 4 e which disappear when clicking elsewhere in the control but make editing VERY difficult. The vertical lines do not always appear between characters, they often overlay the characters, something I cannot represent here. I'll try a screenshot later.

It is definitely something to do with Gecko because Gtk does not suffer this problem (which is one reason why I use drivel for blog entries).

Galeon, Iceweasel and epiphany-browser are all affected.

One simple example is the Debian wiki - normal, uncomplicated text inputs, no special Javascript, but moving around the text in a control is almost impossible.

I've taken to cutting the text into gedit and pasting it back, which is a nasty hack.

Update: I've had comments since posting that indicate that this is likely to be a bug in the pairing of gecko and the free software nvidia driver which can be 'solved' by using the proprietary driver. I won't be doing that so a little more investigation is in order . . .

I'm looking for inspiration - and for someone else with the same problem - to work out how to fix and/or report a long-standing problem with all Gecko-based browsers in Gnome on amd64. It might not be amd64, it's just that I don't get it on powerpc.

When editing text in a HTML form entry field, moving the cursor with the cursor keys results in horrid vertical lines: a b c 4 e which disappear when clicking elsewhere in the control but make editing VERY difficult. The vertical lines do not always appear between characters, they often overlay the characters, something I cannot represent here. I'll try a screenshot later.

It is definitely something to do with Gecko because Gtk does not suffer this problem (which is one reason why I use drivel for blog entries).

Galeon, Iceweasel and epiphany-browser are all affected.

One simple example is the Debian wiki - normal, uncomplicated text inputs, no special Javascript, but moving around the text in a control is almost impossible.

I've taken to cutting the text into gedit and pasting it back, which is a nasty hack.

Any ideas?

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!

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

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…

Awhile back, one of my favorite bloggers, Philip Dawdy of Furious Seasons, deviated from his usual posts that place a big fat critical magnifying glass under the marketing (and other shady) tactics of Big Pharma and wrote a very thoughtful, (also furious) account of Web 2.0 claiming:

this whole Web 2.0, social networking, virtual community business is essentially a pornography of the self a projected, fictionalized self that is then worshipped by the slightly less-perfect self.

It is a little off the top at times but makes some really good points that I agree with (and generated a really interesting discussion). It merits reading alongside Danah Boyd’s recent rumination on the very same topic, fame, narcissism and MySpace, where she seeks to address narcissism but she deflects blame the suite of technologies and places it instead on the broader set of cultural practices that sustain this accentuated inward focus:

My view is that we have trained our children to be narcissistic and that this is having all sorts of terrifying repercussions; to deal with this, we’re blaming the manifestations instead of addressing the root causes and the mythmaking that we do to maintain social hierarchies. Let’s unpack that for a moment.

These two read nicely with an older piece in Harpers Attack of the superzeroes: why Washington, Einstein, and Madonna can t compete with you . The author, Thomas de Zengotita claims “Being famous isn’t what it used to be” because new technologies of mediation and reflexivity (and by new, he means a lot more than web 2.0, it includes reality shows, focus groups, karaoke, the hyper-representation of the real stars, alongside the usual suspects) and concludes that we life as if we were always on stage, concluding somewhat disparagingly “We are all method actors now.” Of course, this is an important part of the story but not the whole story. There are times, for example, these social technologies help to patch up what is arguably as common in North America as is this narcissistic self, which is the fragmented self, that comes into being, for example because many of us, migrate here and the, for example, for work. So a social networking site like Facebook, provides somewhat of a stable point of reference, where there are individuals collected, in the same place, even though the people are no longer really in the same place. It is at least a recognition of certain relationships whose “local” face has now passed but instead of completely completely fading into the realm of memory, the past lives on, albeit in transformed ways, within a virtual space. This facet of social networking is not particularly narcissistic, but is building new technologies of memory that I think works somewhat against the conditions that fragment the self. And while the patching up of the person may make an individual “whole” and “individuated” it seems it is a form that is much more mundane than the “pornography” or “narcissism,” explored above, though of course, they do abound–but karaoke, that is always pornography of the self. But… porn can be fun.

Icedove, Iceape, Evolution, Sylpheed, Sylpheed-Claws and Mutt. Is your favorite mail client missing? Does your mail client accept URLs in mailto-format? If yes, please drop me a note containing the name of your mail client, if it needs a terminal (like mutt) and an example call which starts the client with address, subject an body already filled in. Examples:

• Icedove (needs no terminal)
  icedove "mailto:mail@example.com?subject=foosubject&body=foobody"
• Sylpheed (needs no terminal)
  sylpheed --compose "mailto:mail@example.com?subject=foosubject&body=foobody"

I’ll use this data to include more clients in Reportbug-NG. Please double-check if your mail client really supports mailto-URLs with subject and body. KMail for instance accepts such a parameter but silently drops subject and body.

About two weeks ago, I wrote about my thoughts on Mercurial and how I was switching to it from Darcs.

At the time, I had skipped Git because of its lack of Windows support. I have some contributors to pieces of Free Software that I write that use Windows, and that seemed a pretty big flaw.

But I recently discovered git-svn and git-svnimport, both of which look like great tools for working with our friends using svn that haven't yet gotten ahold of the DVCS light. Then I noticed that Git has a CVS server emulation tool, which means that Windows users can use TortoiseCVS to interact with it. Nice.

I spent some time today learning Git. This was a lot easier having already learned Mercurial. Git and Mercurial have very similar philosophies to a number of things, but the Mercurial documentation explains all this far better than the Git documentation does.

I'm going to have to try both of them out more and see what I think. But git-svn (which is bi-directional) certainly looks like a very nice thing.

Neither of them have something as nice as darcs send, though.

Debian is participating in the Google Summer of Code again. Russell Coker offers to mentor SELinux projects, and so do I. I'm available for mentoring SELinux and Debtags related projects in particular. This years idea pool in the Debian Wiki. Make sure to also check last years idea pool (some of which will no longer be open, though). And of course your idea doesn't need to be on these pages already; we're of course interested in anything that goes beyond that. One thing with SELinux I'm particularly interested in is install scripts. That is quite some work to do, and you might want to automate it somewhat. Debian install scripts can be quite complex. Some things are obvious such as restarting services on upgrade. But some scripts do much more. SELinux uses a deny by default approach (which is the only sane security approach, btw.); in particular this means that many Debian install scripts will be failing. Right now, package postinst scripts are being run with the full permissions of the apt-get domain. It would be good to reduce that to a "postinst" domain. It would be a possible GSoC project to analyze which permissions package postinst scripts need, and if we can e.g. add a "postinst extended" domain for just a few postinst scripts that really need extended permissions. An example for extended postinst tasks in Debian (I don't think Redhat, Fedora or Gentoo does that yet): precompiling all python modules for all installed python versions (and to avoid having programs try to precompile them on demand, which will result in audit errors and such). I wrote a module for that called python-support. It adds a restricted domain which can exactly do this task of precompiling Python. But there is other such stuff, such as updating the menus, managing alternatives etc. But feel free to suggest your own ideas.

A common criticism of fluorescent lights is the inability to use dimmers, as mentioned in Julien Goodwin's blog.

However with some thought at the time the lights are installed this problem can be solved. The first thing to keep in mind is that an infinite number of levels of illumination (analogue scale) is not really required. In most cases two or three levels should do.

If you have two compact fluorescent lights that use 5W and 10W then you have the options of 5W, 10W, and 15W. If you have a large room to light (such as a lounge room) which needs 30W of fluorescent lighting for full illumination then you could have six 5W globes dispersed and have anything from one to six of them turned on to give different levels of illumination.

Of course if you don't plan electrical work then it's easiest to just use incandescent lights in those areas. As long as the areas that use the most light for the longest time have fluorescent lighting it shouldn't make too much difference.

In response to a post on Planete Beranger, saving energy DOES matter. Sure you saving a few KWh isn't going to make much difference on it's own, but when a million other people do the same it all adds up.

The lack of public transport in the US causes more problems for the country than just environmental damage. It hurts the economy by making it more difficult for people to get to work. It will hurt the defence forces in the (unlikely) event of an invasion (trains are the best way of moving large numbers of troops, heavy weapons, and military supplies. It also hurts the national interest in decreasing the ability to react to civil emergencies. For example the entire population of New Orleans could have been evacuated in time using a single platform of a European station. If every city had multiple stations that had a reasonable number of platforms and multiple redundant train lines then evacuating civilians and bringing in emergency equipment and workers would be very easy. In the Netherlands train lines often run on top of dikes, this means that the dikes are very strong (if they can sustain the weight of a freight train then they aren't going to be washed away by a wave) and that trains can still operate while flood waters are rising. If New Orleans is to be rebuilt to it's former glory then the Americans should consider a similar design.

Large cars are a temporary issue. As fuel prices rise people will choose smaller cars. Also hopefully people will start to realise that 4WD and SUV vehicles are actually less safe than cars and stop buying them for perceived safety.

The Chinese government doesn't worry about the same environmental issues, however they have more agressive targets for renewable energy use than most countries. It's not a matter of being nice (they aren't), but of looking out for their own self interest. It's a pity that the governments of the US, Australia, and EU countries have not yet done the same - but it will happen eventually.

As for supermarkets using open fridges, if the vent the heat outside the building then it will be just part of the building air-conditioning system. Every adult dissipates about 100W of heat when at rest, when shopping it would be more than 100W. Get 100 people in a supermarket (not the peak business time) and 10KW would have to be removed by the A/C system without counting heat from lights (fluorescent lights dissipate about half their energy as heat, they are much more efficient than incandescent lights but much less than LEDs),
and heat from other machinery.

Finally, if you want to see changes in government policy then join your local Green party!

Brain Handles did a test to see if Google indexes Javascript-generated content (for simple scripts). It doesn't. So if you are doing a heavily Ajax-based web page, you are (still) risking to prevent Google from indexing your contents. (Note that for two prime Ajax examples this doesn't matter: GMail and Google Maps. One doesn't have any public content anyway, the other no text.) Please use Ajax only sparingly. It's a dirty workaround for shortcomings in interaction capabilities of HTML and web browsers, not the ultimate solution to all our web problems. Two consequences:

1. For now you can hide content from being indexed by Google by putting it into Javascript code. Note that it will be missing for non-Javascript-enabled browsers then, too.
2. There might be a business opportunity in running Javascript in a Crawler to obtain additional text to index. This is best when integrated with the Javascript interpreter, to e.g. index text changes as they are generated. And this could also be used to detect e.g. sites with annoying commercials (popups), fraud sites or sites which try to run browser exploits or that try to cheat on search engines by e.g. doing a Javascript redirection.

I've started using Yahoo Pipes today, and it's pretty cool. I wouldn't go so far as to call it a "milestone in the history of the Internet", but there are a few interesting use cases. Say for example if you're an avid reader of Planet Debian and you don't like the French Revolutionary Calendar, then you can use Pipes to filter out entries whose title matches a French Revolutionary month and enjoy a 100% revolution-free Planet. Or you could split matching entries into a separate feed, or just use regexp replacement to translate them into something else, etc. The possibilities are endless.

There's also a handy Babelfish module, so you can create a pipe that takes Planet Debian, translates it to French, then back to English. Hours of fun!

Plone is a content management system that is built on the powerful Zope application server. The project experienced many delays with its 2.1 release. This made it difficult for Plone consultants to choose whether to use the old release or wait for the new one, and users faced many upgrade issues when 2.1 was finally released and had many changes. Partly to address these problems and partly in order to sync their releases with Zope, they decided in 2005 to move to a six month time based release cycle.

Version	Date	Months
1.0	2003-02-06
2.0	2004-03-23	13
2.1	2005-09-06	17
2.5	2006-06-16	9

Past problems

• Releases, in particular version 2.1, took a long time to get out.
• Releases had many changes and caused some migration problems.
• Many Plone developers work as consultants building web sites. Because of the unpredictability of Plone, it was difficult for them to decide which version to use for future projects.

Solutions

• Plone moved to a time based release, partly because the Zope framework on which it builds has done so. This allows them to make use of new Zope features in their software.
• Time based releases allowed the project to implement more structure. For example, new features have to be proposed as a Plone Improvement Proposals (PLIP) which the framework team reviews.
• Deadlines have motivated developers to get their features done within a certain time frame.
• Plone consultants can decide in advance which version of Plone to use for future commercial projects.

Outstanding problems

• As the project has moved to time based releases only recently, they still need to show whether they can consistently release on time.

I've been playing around some with the Google Maps API, via ym4r. I discovered, however, that its geocoding API doesn't do anything with the "accuracy" information that Google gives you, which tells you if the address you fed it actually means much. The XML looks something like this:

<Placemark>
  <address>Italy</address>
  <AddressDetails Accuracy="1" xmlns="urn:oasis:names:tc:ciq:xsdschema:xAL:2.0">

I opened up geocoding.rb, and had a look, figuring it had to be pretty simple, and indeed, with REXml's XPath stuff, you can easily grab the elements you want. For example:

data_country = data['//CountryNameCode']

So... data['//AddressDetails'].attributes['Accuracy'] ought to give me what I want, right? Nope. The namespace in the sub element confuses everything. After some googling, I finally found the recipe:

data_accuracy = data['//*[local-name()="AddressDetails"]'].attributes['Accuracy']

Kind of a mess, but it works, I have my accuracy attribute, and I submitted a patch to the ym4r guy.

I just read an interesting blog post from December 2005 about the environmental impact of bio-fuels. It makes some really good points that should be studied by everyone who is interested in protecting the environment.

However this doesn't mean that bio-fuels are inherently bad, just that some methods of production are bad.

The blog claims that reusing oil that had been used for frying would cover 1/380 of the fuel used for road transport in the UK. There are some technologies that have been recently invented to process farm and industrial waste into oil, some of which are already in production in the US. The volume of farm waste (and equivalent waste from restaurants) would significantly exceed the frying oil from restaurants and converting waste plastic into fuel would add even more. I'm sure that these sources of fuel from waste would add up to at least 1% of the current transport fuel use.

A better train system has the potential to halve the use of fuel for transport (or better), when living in Europe I never considered owning a car, the trains were so good and the car parking was so bad that it wasn't worth doing. A combination of less cars and the cars being driven less would significantly reduce fuel use.

Hybrid vehicles and vehicles with smaller and more efficient engines could halve the use of fuel again (or better). Diesel hybrid cars that are currently being tested use as little as 1/4 the fuel of current petrol cars. Add further technological improvements such as the six-stroke engine and we could be looking at something better than four times the current fuel economy of cars.

I don't think it's unreasonable to assume that a combination of a good public transport infrastructure, fuel efficient vehicles, and government incentives for using both could reduce the transport use of fuel by a factor of 8. This would mean that fuel produced from restaurant, farm, and plastic waste (which I conservatively estimate at four times the volume of used frying oil) could account for more than 8% of the fuel supplies. The EU wants to have 5.75% of fuel oil to come from renewable sources, it seems to me that this is possible without importing any bio-Diesel from developing countries!

Electric cars could of course significantly decrease the use of fuel oil too. A Prius+ (Prius modified to take mains power) would be an ideal vehicle for me. I rarely make long journeys and rarely make multiple journeys in one day so I could use mains power most of the time. I estimate that with a Prius+ I would use no more than two tanks of petrol a year.

Then of course there's the issue of market protection. It seems that every first-world country has a farming lobby that convinces the government to pay them to produce more crops than they can sell at market rate. Instead of subsidising food that is sold to other countries such government money could go towards subsidising development of bio-fuels. The US subsidy of corn production is a classic example of this, corn syrup can be easily fermented and distilled to make fuel - much better than eating the nasty stuff!

The book SE Linux by Example has been reviewed on Slashdot.

The issue of Perl scripts was raised for discussion. It is of course true that a domain which is permitted to run the Perl interpreter can perform arbitrary system calls - it can therefore do anything that SE Linux permits that domain to do. This is in fact a demonstration of how SE Linux does the right thing! If you want to restrict what can be done when executing the Perl interpreter then you can have a domain_auto_trans() rule to have Perl run in a different domain.
Restricting Perl (as used by one particular program) is actually easier than restricting a complex application run by users such as Firefox. Users want to use Firefox for web browsing, local HTML file browsing, saving files that are downloaded from the web, running plugins, and more. Granting Firefox access to perform all those tasks means that it is not restricted from doing anything that the user can do.

A claim was made that a novice users would not understand how to use SE Linux. The fact is that they don't need to. I know many novice computer users who are running SE Linux systems, it just works! It's more advanced users that have to learn about SE Linux because they configure their machines more heavily.

The essential difference between path-based access control and Inode based access control is that the standard Unix commands to control file access (chmod, chown, and chgrp) all operate on Inodes. If a file has 1000 hard links then I can restrict access to all of them via a single chmod or chcon (the SE Linux command that is comparable to chmod) command. AppArmor does things differently and implements an access control model that is vastly different to the Unix traditions. SE Linux extends the Unix traditions with Mandatory Access Control.

Granting different levels of access to a file based on the name of the link which is used is a horror not a feature.


I wrote this as a blog entry rather than a /. comment because my lack of Karma means that less people will read my /. comments than my blog.