As I have stated here long ago, I do not really believe in the Debian Project Leader. Yes, it has an importance. Yes, it's not merely a decoration figure. But I do doubt it can really make much of a difference. I don't hold exactly the point of view I held back then, but it's still quite close ;-) Anyway...

[ 1 ] Choice 1: Wouter Verhelst
[ 7 ] Choice 2: Aigars Mahinovs
[ 3 ] Choice 3: Gustavo Franco
[ 2 ] Choice 4: Sam Hocevar
[ 4 ] Choice 5: Steve McIntyre
[ 4 ] Choice 6: Rapha l Hertzog
[ 5 ] Choice 7: Anthony Towns
[ 3 ] Choice 8: Simon Richter
[ 6 ] Choice 9: None Of The Above

As it's not a post I strongly believe in, with that many proposals in play, I cannot say I thoroughly reviewed each of the platforms/rebuttals/debate (I did follow them all, of course). I agree with most of what most of them propose (Sorry, Aigars, but I don't agree with you a bit ;-) ). One thing is, yes, worth noting: During the dunc-tank brouhaha, I spoke very little, but was mostly supportive of AJ's pushing a real new proposal. Why am I ranking lowish AJ, Rapha l and Steve (who were, after all, in there)? Because I did really appreciate AJ having the guts of pushing, of being brave enough to go into uncalm territories trying to change Debian. Is that the change I want? No, I don't really think so, so I'm not voting him (or Steve, as the 2IC, or Rapha l, as one of the board members) very high. And yes, one of the reasons I'm ranking Wouter first is his tendency not to be too passionate in flamefests. And, of course, not having much of a platform - Having an overly ambitious platform which would change the conception of Debian both towards the inside and towards the outside is completely unrealistic. And that's one of Aigars' cardinal sins :)

The version of NIS to be shipped with Debian 4.0 has support for Network Manager in ypbind, the program responsible for ensuring that NIS client systems can access a NIS server. Unfortunately Network Manager is targeted at client systems with dynamically assigned addresses and does not support some common network configurations, particularly static ones. When Network Manager is run on a computer with such a configuration it presents misleading information to NIS, causing NIS to think that it is not connected to a network and fail to connect to a server. In order to avoid these problems the version of NIS in etch disables Network Manager support by default but the configuration file with this change is not updated automatically on upgrade. To disable Network Manager support by hand edit the configuration file /etc/default/nis to add -no-dbus to YPBINDARGS: # Additional options to be given to ypbind when it is started.
YPBINDARGS=-no-dbus
Uninstalling the network-manager package if it is not in use will also resolve the problem. This also applies to the packages currently scheduled for release in the next version of Ubuntu (codenamed Feisty).

The Children’s Online Protection Act, or COPA, requires website operators who provide commercial material that could be “harmful to minors” to verify their users’ age, for example, with a credit card. The statute was immediately challenged as unconstitutional under the First Amendment. A preliminary injunction against enforcement of the law was upheld by the Supreme Court, which remanded the matter for factual development as to whether filters could accomplish the same purpose while interfering less with free speech. (Ironically, the ACLU found itself in the unusual position of arguing for Internet filters in this case.) It was just about one year ago that the Government sought to enforce a subpoena against Google for records of user queries and URLs stored in Google’s database. The court granted the motion with respect to stored URLs but not queries in Gonzales v. Google. It was never quite clear what the Government would really do with the data or why they pushed so hard to get it after receiving what they needed from other search providers. (The U.S. apparently argued Google’s search results would “add luster” to its analysis). In any case, the statute has now finally been held unconstitutional. As Ed Felten insightfully points out, unlike in previous instances where courts have struck down Internet speech regulation, in his opinion, Judge Reed did not provide a roadmap for Congress to try yet again to enact a law that would pass First Amendmend muster. Maybe Congress will leave the issue alone for a while:

Two things make the judge s ruling relatively roadmap-free. First, it is based heavily on factual findings that Congress cannot change things like the relative effectiveness of filtering and the amount of HTM material that originates overseas beyond the effective reach of U.S. law. (Filtering operates on all material, while COPA s requirements could have been ignored by many overseas sites.) Second, the alternative it offers requires only voluntary private action, not legislation. Congress has already passed laws requiring schools and libraries to use content filters, as a condition of getting Federal funding and with certain safeguards that are supposed to protect adult access. The courts have upheld such laws. It s not clear what more Congress can do. Judge Reed s filtering alternative is less restrictive because it is voluntary, so that computers that aren t used by kids, or on which parents have other ways of protecting kids against HTM material, can get unfiltered access. An adult who wants to get HTM material will be able to get it. Doubtless Congress will make noise about this issue in the upcoming election year. Protecting kids from the nasty Internet is too attractive politically to pass up. Expect hearings to be held and bills to be introduced; but the odds that we ll get a new law that makes much difference seem pretty low.

Tomorrow at 9 in the morning some officers from the Valencian regional Government will drive up to the mountains of the Bartolo, Serra Perentxissa, Montd ver and Carrasqueta to power off the set of antennas which have broadcasted the signal of TV3, the Catalan public television, during the last 20 years for the entire Valencian territory. These news have been responded with protests from most of the Valencian cultural collectives. You can sign a petition, or send an e-mail, which will be swiftly ignored by the people in charge. Behind the official reasoning for this attack to our freedom of choice -the broadcast is illegal- there is a set of good reasons for the usual suspects, the Valencian Partido Popular to do this. The biggest one is that two months before the local and regional elections, the right-wing are doing their math and it may not be working out too well for them. They need to scrape as many votes as they can, and an easy granary is attracting the extreme right-wing, which is a bit active but fragmented in the region, and mostly in the city of Val ncia. This social group is greatly virulent against anything which sounds like Catalan , especially the people known as blaveros , who claim our culture and language has no common root and has nothing to do with the culture and language from the North. Fortunately, the ISO 639 standard and the entire scientific community agree that they are nuts. But back to my rant. So, how can the PP try to get a handful of votes from the right-wing? Easy, start an anti-TV3 show on the media and start scalating it until the final act -tomorrow-, where milions of citizens are deprived of one of the best channels available in our TV sets. This will surely be sold as a major victory against the Catalan invasion or as the end of an "alegal situation", although there are like 30 other channels in the same situation in the city of Val ncia, and the PP-controlled Canal 9 channel is broadcasted in the Balear Islands (also controled by PP) in the same legal situation. In a time when watching Middle-East or American channels is trivial using a satellite set, some people think the best thing they can do is to end a service paid and provided for free by Acci Cultural del Pa s Valenci , an important cultural entity, during the last 20 years, ending the right to choose one of the only channels with all the programs in our language for milions of Valencians. Their right to do it is also challenged in court, but there is no doubt that tomorrow they'll go ahead and shut it off. We could have a reasonable government who would maybe want to accept the Catalan TV and radio channels in our territory, if the Catalan government would also accept our (crappy) channels in theirs, but they refuse this as well, because they now feel insulted . All in all, I had enough of PP long ago, and am hoping I am not the only one. In less than a month, Valencians will celebrate the 300^th anniversary of the Batalla d'Almansa on the 25th of April of 1707, although we seem to be fighting a new battle now in 2007. The Batalla d'Almansa meant the end of the War of the Spanish Succession in Spain, but also the start of tough times for our culture, language, and people, when Felipe V abolished the Valencian furs. But this story can make a blog post of its own next month. Quan el mal ve d'Almansa, a tots alcan a...

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.

I abandoned paper calendars in 1997. For a few years I used various Palm devices, then Evolution. For the most part, this has worked fine. One of the drawbacks is that I have not had any info in my calendar about official holidays in Finland. That would be useful so that I would know when other people are going to be responding to e-mail slowly, and get annoyed if I call them on business. Evolution can deal with several calendars at the same time, and can import calendar files in various formats. A couple of years ago I found an iCal file with Finnish holidays, and imported that to Evolution, but it's out of date by now. This week I decided to look for a new one, but before I did, Droidy, the fastest interface to search engines, found one for me. Unfortunately, it was severly lacking, and did not even include Midsummer Eve, the biggest summer festivity in Finland. I then decided to make my own. I skimmed the web pages of The Almanac Office at University of Helsinki. They used to have the monopoly on making calendars in Finland (and what a silly anachronism that was), and they still have the copyright on name days, but that stuff doesn't interest me. The list of holidays is uncopyrightable, and that's the info I extracted from their pages. I also looked at the list of times when food stores are allowed to be open. That's actually more important to me than holidays. I ended up making two .ics files: aukiolot2007.ics for opening hours, and suomi2007.ics for the holidays. They're probably riddled with errors: if you find any, e-mail me and I'll fix and update. I hope they're of some use for someone. (I realize that someone is going to tell me about a complete and officially supported .ics file with all the above data as a response to this log entry. Good.)

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?

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.

Using Sun Java 1.5.0_11:

final SimpleDateFormat almostXsDateTime=new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss.SSSZ");
System.out.println("One: "+almostXsDateTime.format(c));
c.set(GregorianCalendar.HOUR_OF_DAY, copy.get(GregorianCalendar.HOUR_OF_DAY));
System.out.println("Two: "+almostXsDateTime.format(c));

IMHO, the get/set combo shouldn't be changing the date... but:

One: 2007-05-17T00:00:00.000+0200
Two: 2007-05-17T02:00:00.000+0200

(I'm not yet sure under which exact cirumstances this happens; it doesn't happen always...) P.S. the format is called "almost XSDateTime", because it's just almost XML Schemas DateTime format. Unfortunately, the Java date parsing and writing classes can't handle XML Schema DateTime (or ISO 8601) because of a tiny little detail: they use a colon in their timezone offset. How annoying is that, that java can just almost handle this ISO date format? P.P.S. so apparently Java is adding the ZONE_OFFSET to the date in this situation; it likely is related to locales and timezones.

This article got me thinking about some new ways we could dramatically improve Debian. We had a lot of success in the past because good packaging helps people get over the fearful hump of installing and setting up new software in order to learn it. We're great at that, and the battle is pretty much over there.

Afterwards though, I don't think we're so good at helping our users through the scary parts. We include a lot of documentation, but that's not really cutting it any more. I set out to work on X because the scariest thing for a lot of users is getting X up and running, and I wanted to help them (and myself!) do it. We still don't have that nailed, but it's in the pipeline, so I think the next stage will be to help people do cool things with X that they wouldn't have done before. In the past, this would have involved doing things like setting xrdb settings, but these days such things aren't really useful. I'm going to continue brainstorming this, but to this end I've started a page on the wiki that's expressly for helping users get over some of the more difficult and interesting things that people might want to do with, or to, X.

Currently the only tip is on building packages using upstream's git HEAD and our own packaging, but I'm looking to put more stuff up in the nearish future. While we haven't been maintaining it so well, the XSF FAQ has a lot of these sorts of tips too.

I think we can push harder and be more clever about giving our users and ourselves cool things to do with Debian beyond packaging. The XSF move to git opened up the opportunity to easily track the X.org HEAD with the Debian packaging, and I think that sort of thing is indicative that we can be clever about enabling people at all stages of the development process, not just through the packaging itself. If you guys have any ideas for more X tips you'd like to see documented, please edit that wiki page or at least drop me or debian-x a mail so we can write it up for you. I want to see how far we can push this.

Anyone wants to join in the Luke Kenneth Casson Leighton fanclub? And these unfortunately aren’t candidates for DeFuBu

As I recently bought a NSLU2 ("slug") for 24/7 server usage and random ARM-based development (more on that later), I'm looking for a suitable storage device to use as the root filesystem for a complete Debian system. The requirements are:

• Large enough (>= 1 GB).
• Silent. Hard disks are not an option (no IDE, no SATA, no USB, neither 2.5" nor 3.5")
• As fast as possible.
• USB-attached (the slug only has 2 USB connectors).
• Should live as long as possible.

The last item is the most important. The obvious choice is a USB memory stick, but unfortunately those are flash-based and only survive a certain number of write cycles. Thus I'm looking for something which at least survives enough write cycles to make it usable for a few years... I do know several ways to reduce the number of writes via software, that's not what I'm currently interested in. I'd like to know which storage types will survive the longest amount of time (because of their hardware properties). Some options:

• USB memory stick, obviously. Usually quite slow, but there are quite fast ones (read 33 MB/s, write 22 MB/s), too. Some seem to survive 100.000 or even 1.000.000 write cycles, but that may not be enough. Are there any sticks with more possible write cycles?
• Any other USB-attached (via external USB card-reader if necessary) silent storage type: SD, MMC, Transflash, Memory Stick, Compact Flash, whatever. Does any of those survive more write cycles?
• Any other viable option?

Has somebody else done something like this before and can share some experiences as to which storage type is best suited for such a scenario? I suspect my slug will be mostly idle, but there might also be phases where it runs on 100% CPU and heavy disk I/O for multiple days in a row...

In response to my last post about using laptops for presentations it has been suggested to me that using white (or a very bright color) as the background color can help some displays synchronise with the signal. I haven't had an opportunity to test this but it seems likely that as most computers are configured with a white background nowadays the display hardware is optimised for this case.

Another benefit of a light background is that it provides more ambient lighting to the room where the presentation is held. If all the lights are turned off (sometimes there is no dimmer switch) then the radiant light from the screen is the only form of illumination for the room.

Finally with the way the current generation of beamers work there is less heat trapped in the beamer if there is mostly white on the screen. This will hopefully decrease the incidence of hardware failures during lectures (which unfortunately are not uncommon in my observation).

Update:

Based on a comment on this blog entry I did a quick survey of the color scemes, black on white, yellow on blue, and white on green. Black on white got the most votes with some people saying that yellow on blue was most aesthetic while black on white was easiest to read ("clear and boring" was one comment).

One person pointed out that the light diverges slightly so black on white makes the letters look smaller while white on black makes them look bigger. My response to this is to use a slightly larger font.

The design is now agreed with the weavers, but unfortunately I misunderstood the price-list, so the prices I've been quoting for hand-sewn 8-yard kilts, and machined lady's 4-yard kilt-skirts were too low -- the correct prices for those and a couple of other things being:

Hand-sewn, 8 yard kilt:	£420.00
Machined, 4-yard, skirt-kilt (lady's):	£237.50
Machined, 6-yard kilt:	£270.00
Waistcoat:	£113.00

I'm sorry about quoting prices without making absolutely sure they were correct, the reason was that I was quoting the prices for standard weaves from stock, and it turns out that the custom weaves are more expensive. That said, note that the machined kilts are £80.00 cheaper than the previously quoted price (for hand-sewn), and that these are perhaps more appropriate to the use to which many of us will be putting the kilts anyway (hand-sewn are really an evening dress item, after all) Even so, I'll probably still fork out for the full 8-yards, on the basis that my dinner jacket is falling to bits after 20 years wear, so I need something new anyway. In case you're wondering what on earth I'm talking about, this has been discussed elsewhere. Just to make sure there are no other nasty surprises, if you are of a more rotund nature, you may find that it will take some extra material to encompass your circumference -- as an example, a 7 yard machined gents kilt will cost an extra fiver to stitch, and an extra £25.00 for the yard of cloth, so will come in at £300.00 rather than the usual £270.00 Confused? Well, so was I --- The designer's sending me a fuller price list, which I will ensure than anyone on the list of currently interested people is fully conversant with before we put the order in, so don't panic that I'll spend your money without giving you a final chance to come to your senses ;-) I hope that doesn't result in everyone changing their minds, but I'll understand completely if it does. Alternatively, you could decide that this is an opportunity to save yourself £80.00 by opting for a machined kilt (which AIUI are still made to measure, but just have proportionately less work and material in them) Anyway I'll post any further developments here so as not to continue spamming the lists. So, if you're interested in getting hold of any of the above despite the new prices, and have not yet told me you need to mail me now! -- the order will probably go in at the end of the week.

... this is the problem

I just casually saw Norbert post about the ion3 querelle. This a very unfortunate example of collapsing interactions among upstreams and maintainers. My general advice (but for suggesting to use wmii or dwm instead of ion3 :-)) is avoiding packaging of development branches, but this is a decision which sometimes is difficult to take: some programs seems in development for years and stable releases could result largerly unusable or limited. Surely our - and generally speaking any distribution - release cycle and maintainance are not adequate for many on-the-edge software out there.

When upstreams releases [a]periodical milestones, those could be packaged, but upstream will not support them: we have already our problems in supporting regular releases for security independently by upstream for mainstream programs, without adding pieces of casual crap around.

Packaging a casual snapshots is out of question IMHO, but for using it in sid/experimental, so I can understand the upstream opinion, because many users report problem to upstream instead of maintainers. I see definitively no silver bullet anyway, but for maintainers' capability of understanding what should be packaged or not and opening an unbreakable communication channel with upstreams to be up-to-date in respect with upstream roadmap.

The GNU Compiler Collection (GCC) is a compiler suite which supports a number of programming languages, such as C and C++. It is a very important development tool and is the standard compiler among free software projects. GCC was quite stagnant in the middle of the 1990s until the EGCS project formed. EGCS took over development of the official GCC in October 1998 and instituted rigorous processes, such as high levels of peer review, and created a steering committee which has the power to appoint maintainers and make important decisions. In theory, the project follows a time based release with an interval of six months. In practice, the project has released only one new version every year in recent times.

Version	Date	Months
3.0	2001-06-18
3.1	2002-05-15	11
3.2	2002-08-14	3
3.3	2003-05-13	9
3.4.0	2004-04-18	11
4.0.0	2005-04-20	12
4.1.0	2006-02-28	10

Past problems

• The GCC project suffered from a closed development style in the past: few people could make code changes and the mailing list was by invitation only.
• There was a long time between releases and development snapshots, which contained bug fixes and features, were not available to the public.
• When development opened and picked up, significant code changes were often made which required a long stabilization phase.

Solutions

• The project moved to a more open development style and established a steering committee which has the power to appoint new maintainers and make important decisions.
• The development process was divided into three stages in order to coordinate code submissions and keep the development tree reasonable stable. Major changes that developers wish to make during stage 1 and stage 2 have to be proposed on the project's wiki. Proposals are reviewed by the release manager who also assign a sequence to proposed projects which says when they can be applied to the development tree.
• All patches are peer reviewed on the development mailing list and need approval before they can be applied. The steering committee appoints maintainers who can approve patches that touch particular areas. There are maintainers for the C front-end, various port maintainers, and maintainers for other areas.
• Each development stage lasts two months, theoretically yielding a release every six months. A regular release cycle ensures that it is not the end of the world if a feature does not make it into the following release.

Outstanding problems

• The release manager is busy and has not pushed the release forwards as much as would be possible.
• The branch criteria may need revision to make it easier to create a branch which leads to the next stable version. At the moment, the branch criteria is to have 100 or less regressions on the development tree. However, this number may include regressions that are also present in previous releases, which makes it fairly hard to reach this criteria.

... or why PHP sucks so much?

It is quite common (at least for me) finding abused web applications on shared hosts around. The most typical case is finding some kind of IRC bot running as www-data and a few unauthorized files around used for phishing, cross-site scripting or what else. That motivated me to try playing with mod_chroot in order to minimize the possibility of webapps abuse from our friendly kiddies^Wcrackers. Mod_chroot is a nice tiny Apache module whose purpose is the confinment of webapps within a limited tree, where nothing but a few files and dirs are available to try exploits and abuse badly written code.

Unfortunately, I found that mod_chroot poses one major problem (among others, see its CAVEATS doc): the sucking mail() function is not working out of the box, because PHP folks - God knows why - decided to implement that stuff by calling a local /usr/sbin/sendmail program within a shell call. The most sane option is simply ignoring the issue and living happy with a disabled local mail() function. A nice solution in that case is using a PEAR Mail module, which is able to send mails via SMTP in much more elegant way. Unfortunately, there are quite a good number of morons out there, and that could be not a viable option if you are the system administrator of a bounce of shared hosts which are exposed to those morons, who absolutely need a working mail() function.

After a few googling around, I did find that many people had the same problem, but none found (or explained) a working and neat solution for a working mail() implementation, so I'm writing some notes about that. My implementation is based on a nice tiny program (mini_sendmail) which has the great advantage of not requiring a configuration file or a spool directory to work. It also works without suid bit on, which is a good thing as well. It is statically compiled by default, so it simplifies things a lot. In order to have mail() working you need also to install a (statically compiled) shell, e.g. bash-static as sh under the /bin directory of your chroot tree (a more tiny shell would be appropriate). I commented out the silly username autodetection code in the mini_sendmail.c source, because it creates some problem within an empty chroot tree (it failed with a "can't determine username" message with or without the /etc/passwd file available).

Now, the next step is using an entry like

sendmail_path = /usr/sbin/sendmail -t -fwww-data@your.domain -s127.0.0.1

in your php.ini file. You can also use another IP address if your SMTP server is not your localhost or you used some more exotic routing setup. Having a suitable /etc/hosts is also useful. A final trick is adding a var/lib/php4 or what ever directory is required to store PHP session files. No other files should be required in order to have all working. Of course, you have also to use inet sockets for any required connection (e.g. mysql) but this is typically the default in etch. I would also suggest to add only ad hoc statically-compiled binaries within the chroot tree when required, else you will need to store all required shared libs: in that case you will need to find binaries requirement by using ldd and chroot to find loading/running errors by means of an usual trial-and-error cycle.

[ Warning: Long post follows ]
Just today, I read that H01ger is happy he can wear just a T-shirt somewhere in Northern Germany. Well, from my point of view, much the opposite has happened. And I'm not just happy - I'm fucking proud!
About four years ago, Nadezhda went almost every weekend to hike to the mountains with the Grupo de los Cien people. I'll sidetrack a bit to speak about them: Grupo de los Cien is a group of mountain lovers (no relation with the enviromentalist group which later took the same name) that, since the 1950s, have built and maintained the high mountain shelters in Central Mexico. It is a group, by the way, with which Nadezhda fell completely in love - and now it's up to me to find out why ;-) But lets go back to the main topic.
Almost every week, she came back delighted and loaded of energy from a mountain hike. Almost every week, I told her I wished to go with her, of course, if they went to a simpler route. Of course, lugging around over 130Kg of humanity is no easy deal. And, after over a year and because of many problems that came together at once, she stopped going to the mountain as well. She always kept an eye on their friends, but so far had not been able to return to the mountain.

Ok, so last week she heard the group was organizing volunteers to go fix the Ayoloco 2 shelter. She signed up, and invited me. I was afraid, but accepted the challenge - Of course, full of fear.
Being this a historical event (at least in my life), I cannot but offer you some of the photos I took. And, yes, I've just started playing with Flickr. Lets see if it works for me ;-)
Saturday, 5 AM, we woke up. 5:50AM, we met part of the group near Daniel's house, in Condesa. 7 AM, we were having a nice breakfast (tamales and coffee, yum!) in Amecameca, still 28km from La Joya. From Amecameca, we went to Paso de Cort s, where we met the rest of the group, and from there we went by a little, bumpy and unpaved road until La Joya. Somewhat around 20 people started the hike at around 9 AM.


According to Google Earth, La Joya (just South of the Iztacc huatl - white woman or sleeping woman in N huatl) is at 3995m - And, of course, to start at that altitude is not easy. The air is very thin, and walking a little bit too fast quickly makes you feel the blood pumping, trying to get some more oxygen. I often remembered how my Bolivian friends behave in Potos , walking slowly even when in a hurry :)

We first went down a little valley, then up. The first portion of the hike was on soft, wet sand, with some grass (what we call zacate - Strong, hard grass, not what you commonly see in a garden). I soon learnt that was a blessing, as it was by far the easiest part. Then we went up a steep and quite rocky area - It started getting tricky for somebody not used to trusting his own feet. And it was steep, yes. This was the first time (of many, of course) I started thinking whether I should head back.

We reached what I foolishly thought was the summit, only to find a steeper, longer way to go. It started getting common to find little deposits of snow/ice (I don't know the exact term in English - it's called aguanieve in Spanish, literally snow-water. [[Update]: Thanks to the now-DD H01ger, I now know that aguanieve in English is called sleet]. I understand it's a bit harder than snow, but still much lighter than hail). We crossed a completely rocky section - No sand to hold the rocks to their place. That meant being extra careful (and thus, extra slow).

But just afterwards, in case it was not enough, Mother Nature answered my pleads for some sand - we crossed a section made exclusively of loose sand. And, please, if you have ever walked upwards on sand, imagine doing so at over 4000 meters. I was taking so much care of how and where I stepped that I strayed not more than 5 meters down of the path the group was following - Being able to climb back to the right path was really not easy. This was the point that not only I was thinking about heading back, but I'm sure Nadezhda thought I would abort the mission. She cheered me up, took some pictures of me as soon as I got out of the sand trap, and we were able to move on.

After the sand, some more rocks, and we started feeling the chilly wind. We entered a cloudy region - Humidity does get the coldness into your bones! We could not really see where was the rest of the group, so we proceeded the best way we could. Fortunately for Nadezhda and me, just behind us came the very experienced Mario Corsalini and led us. And, yes, we finally saw the Ayoloco 2 shelter.

I was by then exhausted, after some four hours of ascent. I ate one of my apples - The sweetest apple I have tasted so far. After resting a bit, and realizing I was almost frozen (we were at 2 Celsius under, with constant chilly, humid wind)... Then I started working with the guys, reinforcing the shelter, while Nadezhda and some other people painted the inside with. People started eating - of course, I joined them. And, after some time up there, we started going back down. Miguel ngel, a volunteer in the Izta-Popo park, walked a good portion of the descent with me, giving me tons of help and tips. Thank you, thank you, really. The descent is, of course, much easier - We were chatting most of the time, and we made only around two hours back. The weather was quite nice on us - We had some aguanieve falling every now and then (yes! Yes! many of you guys have heard/read me bitch on how I had never seen snow falling before - Ok, this is not exactly snow, but I think it qualifies as my first experience ;-) ), but aguanieve does not make you wet, as it bounces off the clothes. When we approached La Joya we started having some light rain. We hopped in the cars, and then the rain really began.
But even if this was not enough: Grupo de los Cien was celebrating the 83th birthday of one of its senior members, Poncho Rico. No, being 83 years old is not an excuse for skipping this memorable hike.

We went to Anatolio's house, very close to Amecameca, and had a delicious dinner, cake and drinks.
Nadezhda: Thank you. So, so, so very much. Thank you for being so patient with me, for dragging me up the Sleeping Woman. Thank you for getting me into this so very important and beautiful experience. I hope this will be the first of many. There is still a very long way for me to go before I'm really up to the challenge, but believe me: This will not be my last time on the mighty mountains.