How often have you said to yourself "this programming language's if statement is too flexible, I need to make it more rigid, and with a syntax nobody else understands"? If you've ever said that to yourself, then take a look at this Rails plugin. From the brief description of the plugin:

Allows developers to execute or not execute given code block depending on a set of conditions, written in intuitive manner. Especially useful within view templates, where it can eliminate the need for multiple if ... else ... statements.

That screams "overkill" to me, but for the sake of my morbid curiousity (and on the very, very off chance that it's something not entirely ridiculous) I took a look at the detailed documentation. At least there is detailed documentation for this plugin. I didn't get any further than the first example, though. Take a look at this monster:

How often do you find yourself writing something like that in your views:

	  <% if current_user != :false && (current_user.administrator?   current_user == @profile.user) %>
	    <%= button_to('Big Red Button', destroy_everything_path) %>
	  <% else %>
	    <%= button_to('Hands off!!!', access_denied_path) %>
	   <% end %>
	

It works, but, you know, it's not what you would call beautiful, is it? What about something like that:

	  <% access.to_administrator.or_user_of(@profile) do %>
	    <%= button_to('Big Red Button', destroy_everything_path) %>
	  <% end.else do %>
	    <%= button_to('Hands off!!!', access_denied_path) %>
	  <% end %>
	

At least conditions are looking much better, aren't they?

Hopefully, most people out there answered a resounding "no" to that last question. A plugin which causes you to write just as many lines and very nearly as many characters, whilst using a completely different minilanguage to what every Ruby programmer already knows, does not sound "much better" to me. Ruby people tend to love little minilanguages to get things done, but this... I just don't have the words to properly describe it. I'm going to start a list of "poison plugins" -- ones that, if I see any of them in or around the code of a Rails project I'm looking at working on, immediately doubles the hourly rate and the time estimates. Stupidity is toxic, and working with hazardous substances is always more expensive. Other current candidates include the old-world auth generator I gutted while I was at Vquence, and annotate_models -- the former because it's shocking code, and the latter because anyone who uses it has some seriously scary ideas about what constitutes acceptable documentation and development practices.

It’s good to see that a large number of American native languages have their own code in ISO 639-3. I was a little disappointed when I explored ISO 639 for the fist time, most of those languages are grouped by 639-2 by a single code: sai, many of them don’t have any relation with each other. Nasa Yuwe (P ez) and Namdrik (Guambiano), for example, are spoken in the same region of Colombia and they are very different, even don’t have the same origin. If you wanted to develop software for one of them, you had to use a reserved for local use code, but now, that’s no longer needed.

Julien Goodwin asks whether an insecure platform can perform secure computation [1]. My immediate reaction was to recall Charles Babbage’s quote On two occasions I have been asked, ”Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?” […] I am not able rightly to comprehend the kind of confusion of ideas that could provoke such a question [2]. However on careful reading of Julien’s post it seems that he is most interested in the integrity of the computations rather than the secrecy. He suggests the possibility of performing the computation twice and comparing the results. Of course the issue to consider is whether both computations could be subverted. It seems most likely that if you are using someone else’s computation cluster for the calculations then performing the same calculation on two nodes of that cluster will give the same result both times (whether it’s right or wrong). If there was a computation that would get a result that can be verified with little computation then it would be an easy problem to solve. For example if I wanted to brute-force a passphrase for a GPG key then I could try all combinations that were known to be possible, if one was flagged as correct then in a millisecond I could verify it. If none of the possibilities were listed as correct then I could assume that the process was broken in some way. The problem with this is that such a passphrase can have arbitrary length (I know someone who uses more than 50 characters). So if I used a brute-force attack on passwords of up to 9 characters that doesn’t exclude a 10 character password. Probably the best potential use for insecure systems is for analysing large data sets. There have been several projects to harness unused computation resources to perform various large calculations (protein folding and SETI are two examples). Most such projects use closed-source programs because the people who run the contests are afraid of cheats who modify their programs to merely say “no” repeatedly and quickly. Of course this wouldn’t be a problem if they didn’t have a high-score table, and disassembling the program to hack the protocol can’t be that difficult (consider the work invested in reverse engineering protocols such as SMB which are much more complex). It would probably be reasonably to randomly send batches of work to two machines in different regions for such large-scale public computation projects. Finally if you want to perform calculations on secret data on someone else’s hardware then you may have lost before you even start.

• [1] http://laptop006.livejournal.com/39799.html


• [2] http://en.wikipedia.org/wiki/Garbage_In,_Garbage_Out

Share This

The following is a brain dump of some of the things I've been thinking about lately.

One of the biggest changes over the past several years in biology has been the incredible deluge of information. In response to this there's been a rise in bioinformatics to cope with all this. While this has led to some major successes, where it's failed is in its ability to impart a greater understanding of the subject at hand. Biologists still learn primarily from reading papers, the same way we always have. There are massive databases full of wonderful information but most of it is encoded with minimal or no context so you're always forced to go back to the papers to understand what the database is actually telling you. In that sense, these databases are fantastic at indexing information, but very poor at organizing it in such a way as to teach people about the topic at hand. We're still forced to slog through papers for just about everything.

What's striking about this is that the most informative bits in any biological paper I've ever read are encapsulated in the figures. The images themselves, provided you have sufficient background knowledge, show the basic data and give you the most understanding for the smallest investment of time. You can skim an article's abstract, it's figures and figure legends and gain a fair understanding of the topic before deciding whether or not to go further.

Now, there's a contradiction of sorts here. Many of these figures are generated via computers, usually an excel-made graph. The rest are actual photographs of things, such as blots, gels, or stained tissues, eventually inserted and processed via the computer. The contradiction is that the computer is used intensively to organize this data for publication, but we have a hard time extracting the essence of that visualization for indexing in "big picture" sorts of ways. That almost always has to be done by hand (and brain) by the biologist. This, of course, is suboptimal when you have thousands of individual genes.

The fundamental reason for all of this is that biological information depends wholly on context. For example, you can sequence the whole genome, but it's totally unclear what genes will be expressed at any given time unless you have much more information about the cell type, developmental stage, pathologies, and so forth. As far as I can see, all our bioinformatics tools have failed completely at providing any sort of context for their information. A common thing to see is so-called "wiring diagrams" that display molecular interactions. These diagrams are full of nodes and edges and it looks almost impossible to understand such things. While there is a great deal of complexity, contextual information provides us with a framework to understand what's actually working. Looking at these diagrams, there's no sense of this though, it looks instead like complexity overrun.

So that presents us with the challenge for the future. What's required of bioinformatics is to not only index the raw data, but also the context, and then present the data to us in a context-dependent manner. I am convinced that the key to presenting data this way is to come up with novel visualization methods because it's the visualizations in the papers that we use today to get the most out of our time. I believe that this problem is tractable and that there is a solution. More than likely we'll need several solutions, and I look forward to seeing them develop.

We are getting many bugs about wrong DPI configuration and DisplaySize not working. In most of the cases, it is actually caused by a confusion between Monitor sections in xorg.conf and RandR 1.2 outputs. With a default config, RandR 1.2 drivers will basically associate the unique Monitor section with their first output, even if not enabled. Bug #461501 is a good example of this issue. RandR 1.2 drivers (intel, ati, nv for G80, mga in experimental, radeonhd so far) require that you specify which output is attached to which monitor. If you have a Monitor section with identifier "Foo" connected on output "BAR", then you want the following in your Device section:

    Option "Monitor-BAR" "Foo"

Or (easier), just rename identifier "Foo" into "BAR". You need to add such a section for each output that you want to tweak (DisplaySize, ModeLine, PreferredMode). Then your tweaks will be applied to the right monitor/output. See the HowToRandR12 sections III.1 and III.3 for details.

I don't know why some people always shout censorship when it's about what is acceptable behaviour and what not and about what things people want to be assosiated with and with what not. (Must be some relative of Godwin's law (the original, not the "you lost" usenet-variant)).

I personally do not care only little about what happens in irc-channels I'm not in. I don't know what happens in this this special channel starting the discussion, and I don't believe any anedotically examples can make a big difference. (Humans err, sometimes in tone, and even some hundred examples of wrong tone in some backyard alone is nothing I care much about, as long as it is nothing that would be a criminal offense if done in more public places).

What I absolutely dislike is any form of communication forum - especially those that could be associated with me - to be declared as a place where foul behaviour (to which I count sexism) is acceptable and even worse to be accepted as norm. (Why didn't anyone shout "censorship" at the "Love it or get the fuck out of here"? Perhaps there is some correlation between views of the world I don't understand).

By the way, there are places where I feel personally offended as a victim of sexism by a statement like "men are pigs". For example in a discussion about sexism. (I know, I know, it might not be sexism according to some definitions, but I see no reason to not use the word or not dislike it just because the forcing into gender roles is done by members of the same sex as opposed to to members of the opposite sex.)

About a month ago I added symbol version information to the zlib package, allowing dpkg-shlibdeps to calculate more relaxed dependencies for packages using the library. The results have been very satisfying so far - of the 1784 packages depending on zlib1g on amd64:

• 532 depend on zlib1g 1:1.2.3.3.dfsg-1, the version which introduced support for _FILE_OFFSET_BITS=64 and the version which packages that were built before zlib1g had symbol version information will depend on.
• 333 depend on version 1:1.2.1, which predates sarge let alone etch.
• 74 depend on the even earlier version 1:1.1.4-1.
• 843 packages have an unversioned dependency on zlib1g - a quick glance at some of these indicates that (as I would expect) they either don’t actually link against zlib directly or do but don’t use any symbols from it.
• The remaining two packages are the -dev and -dbg packages which have an exact dependency on the library package they were built against.

Of course, zlib is a particularly good use case for this - both API and ABI are extremely stable and most of the changes in interface are in rarely used features - but it’s still good to see it working in practice. I don’t need to worry nearly so much as I would have done previously about keeping other packages out of testing. If you maintain a library written in C I would encourage you to take a look at implementing this, it’s very straightforward. Libraries written in other languages may cause more difficulty. There are some automatically generated symbol files in mole which provide a good starting point (I didn’t use them since upstream already had a more exact list of versions at which symbols were introduced) and support is already present in debhelper. The main things to watch out for when using the mole data are backwards compatible ABI changes which don’t just add new symbols (for example, if new values are accepted by a function) and variations between architectures. Kudos to Rapha l for all the work he’s put into this.

It is not uncommon to run a Linux system with a kernel that was compiled for another distribution. One reason for doing this is the difficulty in compiling and testing a kernel to make sure it will do what you require. It’s not THAT difficult for someone who knows what they are doing, but if someone else has already done the work then it seems like a waste to re-invent the wheel. Sometimes it’s an issue of a driver that one distribution supports but not another, copying the entire kernel package from another distribution may be easier than compiling a new kernel with the extra driver. Sometimes it’s a kernel bug, if distribution A has fixed the bug and distribution B hasn’t, then it’s often easier to install a kernel package from distribution A when running distribution B. Another reason for running different distributions with the same kernel is Xen. If you have a Dom0 which hosts instances for different distributions as DomU’s then running the same kernel on all of them can make it easier to manage. Unfortunately it’s not uncommon for different distributions to have different kernel feature sets. One example I’m currently dealing with is the fact that the Debian/Etch kernel is compiled with CONFIG_AUDITSYSCALL disabled while RHEL and CentOS require it. So if you run a RHEL or CentOS system with a Debian kernel (EG running a Debian Xen server with a RHEL or CentOS DomU) then you see messages such as the following in your logs. crond[7824]: pam_loginuid(crond:session): set_loginuid failed opening loginuid The loginuid feature allows login and equivalent programs (which includes xdm and other graphical login programs, cron and every other program that runs a program on behalf of another user) to set the loginuid. This loginuid will be stored by the kernel, inherited across fork() and exec, and not be changed by running setuid or setgid programs. Therefore if you see some strange entries in your audit log indicating an attempted attack you can determine the original login UID of the person responsible. In terms of security features it’s not a really high priority. But it is really annoying when programs that work on RHEL don’t work properly with a Debian kernel and put many unwanted messages in the log files. For people who have less background knowledge about these things it may be more than annoying, and may even force them to change their deployment plans to make the message go away (not everyone knows which messages can be ignored or where to ask about such things). The fact that Etch has no user-space support for the auditing features in question (auditing system calls or setting the loginuid) was never a good reason for not enabling this feature (IMHO). Using the auditing system calls was simply a matter of copying the auditctl program from a RHEL, Fedora, or CentOS system (for those who didn’t feel inclined to compile the source). The loginuid required changes to PAM to enable it, but is actually a small part of the auditing layer. As a general rule minimising the differences between distribution kernels is going to benefit most people. Some people complain about kernel bloat, but there are worse candidates for that accusation and given that it seems impossible to buy a machine with less than 512M of RAM and a 900MHz CPU (the specs of the ASUS EeePC) adding a few extra kernel features seems unlikely to hurt anyone. It is of course always possible to compile your own kernel for the smallest machines. Finally I am in the process of back-porting SE Linux code and related security features to Etch, and having this already enabled in the kernel would make my work easier. I won’t do a 7 year support cycle for it unless someone pays, but supporting Etch past the release of Lenny with the latest SE Linux features (and the current features working properly) is my aim.

Share This

AJ, if some blogs would support comments, I would leave my opinion there and not add noise to the planet. 1) Censorship does not stop being censorship just because the people doing the censoring don’t have the absolute power to censor the information everywhere and only block the information or opinion from the channels they can control. It can be called otherwise - editorial control, policy of political correctness, libel liability protection policy, Children-Safe Talk Initiative or Women Friendly Environment Collective. But at its heart it is still censorship of all official Debian-related channels of communication as the aim is to remove the objectionable content from all such channels. 2 and 3) Discriminating against jerks is also a discrimination against people or groups. Please do not get all DFSG-bendy on me here. DFSG is about use and distribution license of the software and not about the communication channels used to facilitate this process. I could actually counter you with a quote from the Social Contract that says that we will not hide problems. The discussion as such admits that some people consider sexism to be a problem in Debian (for example). Excluding sexist comments from Debian official channels will not make sexism magically disappear, it will be just hidden, swiped under the rag and said to sit quiet. The only problem is that the community that is tired of such hushing is much larger then anticipated. There are people that think that men and women are different. We checked. I can’t see anything bad in the example quoted on the planet so far. Yes, the depth of the discussion is weak - we can’t be genius all the time, but I really fail to see who is insulted in there. Lesbians? Don’t think so, they are compared to a threesome quite favorably. That is not a technical discussion about interrupt timings, but that’s why it is in offtopic. Doh! Relaxed chit-chat like this is typical in all healthy and tight-knit communities. Is it offensive to women to talk about sex??? Grow up and have a good 3 hour chit-chat with some real women. Women talk about sex even more than men. Especially on-line. Can someone really show what is the “OFFENDING BEHAVIOR” so obscene and dangerous that people want to censor out of Debian and explain what exactly they see as being so horribly bad to Debian that they see total censorship of all Debian communication channels as an acceptable countermeasure?

I just commited export to Texy! into phpMyAdmin SVN. I originally wrote it only as an example for article on Czech phpMyAdmin pages (to be published next Monday), but at the end it turned to be interesting for more people and it ended in SVN, so you can expect it 3.0 release. To see how it actually looks like, you can go to Texy! demo.

As we all know, the Express are a load of xenophobic racist ignorant misleading cocks. Thanks to Iain who pointed me at this glorious post entitled something I won't repeat for fear of offending the children, I discovered what is probably the best example of selective quoting in the Express. They said:

The Government's equality chief Trevor Phillips recently said the fear that migrants are jumping council queues for homes is fuelling tensions.

Well if the government are scared that migrants magically jump up the council house queue, then it must be true. Or is it. The Guardian has the full quote:

Mr Phillips [chairman of the Commission for Equality and Human Rights] said tensions were driven by a widespread perception that newcomers often received unfair advantages. "Specifically, that white families are cheated out of their right to social housing by newly-arrived migrants," he told the [Local Government Association]. "I have never seen any reliable evidence to back up this claim. And there can be no doubt that much of the public feeling is driven by the careless media and racist parties."

If you ever wonder how low the Express and co. will go to get a quote or statistic, this is a good example. In a quote where the essence of the message is that the scum-class tabloids and racist parties are fueling anti-immigration views, they managed to get a quote to support a story against immigration. Well done, Tom Whitehead, you really do deserve a special place in hell. NP: Skreamizm Volume 4, Skream

I've just rolled up release 0.1.0 of r (pronounced littler). A few changes made it into this release:

• A new option -l (with long form --packages) to load packages into the R session. This is useful when you have data-processing one-liners as it does away with the explicit library(foo) inside your actual R expression. For added bonus, library() is wrapped in a suppressMessage() call.
• The --no-restore option is now passed to the embedded R session.
• Argument handling was improved / corrected for a corner case.
• Output shown by --help was improved.
• The manual page and README were updated accordingly.
• The datasets package will now be autoloaded.
• Two minor fixes went into bootstrap, the wrapper around autotools and friends.
• The cache-clearing part of the R package updater example update.r was improved.
• We added some comparisons to Rscript in the timing tests.

As usual, our code in our svn archive, on my r page, and in the local directory here. A fresh package is in Debian's incoming queue, and Jeff's littler page at Vanderbilt should reflect the new release soon too.

Sometimes I don’t particulary want to follow a bug intimately and just want to be notified of the interesting changes; when it’s closed, when someone attaches a fix, etc. Take, for example, #454935. I didn’t subscribe to the bug at the time I noticed it, as it would have taken a couple of minutes to email 454935-subscribe (and send the confirmation back, wait on the fscking greylisting, delete the ACKs, etc.) and I could have always been overrun with annoying “severity wars”, merges with various duplicates, etc. In the event, this didn’t happen, but the perceived cost of subscribing to the bug was much greater than the benefit. Anyway, as I’m fairly certain I’m not alone in encountering bugs like this, my solution was to put together a GNOME panel applet for monitoring specific Debian bugs. It’s pretty fully-featured already:

• At-a-glance view of subscribed bugs, showing relevant information concisely
• “Fuzzy” bug number entry box - parses bug URLs, emails addresses and subject lines, etc.
• libnotify messages when bug changes state
• Quick access to reportbug or reportbug-ng via right-click on applet icon
• Polls BTS with exponential back-off to avoid BTS denial-of-service
• Quick access to the BTS page via right-click on bug entry
• Graceful offline mode - downloaded data is still available without network

Perhaps something like this can lure some Debian users into following development a little closer and put them on the path to becoming a regular contributor, who knows.. Source (GPLv3) is available in Git:

% git-clone git://git.chris-lamb.co.uk/debian-bts-applet  # or
% git-clone http://git.chris-lamb.co.uk/repo/debian-bts-applet.git

It comes with a debian/ directory, which is highly recommended over configuring Bonobo manually. What would be really useful right now is testing. If you want to contribute, please run your eyes over the TODO and HACKING files as well as the (OMGWTFBBQ) unit tests. If no major issues are found in the next few days, I’ll file an ITP and make a call for translations.

Finally I uploaded the new ghostscript package. Now CJK languages are fully supported, so if you install the needed CJK TrueType font packages(suggested by gs-cjk-resource) along with it, you should be able to see the following examples properly:

• Chinese (Traditional) sample PS
• Chinese (Simplified) sample PS
• Japanese sample PS
• Korean sample PS

Of course, you can use ps2pdf etc. too. Also, I prepared the current SVN snapshot package w/ CJK support. Try it if you wish. The apt-line is as follows:

deb http://people.debian.org/~mhatta/debian/ghostscript/ ./
deb-src http://people.debian.org/~mhatta/debian/ghostscript/ ./

I still need the inputs from Chinese or Korean users. Please tell me if you experience any problem, or your idea for improvement.

Tag this post with del.icio.us!

Finally I uploaded the new ghostscript package. If you install needed CJK TrueType font packages(suggested by gs-cjk-resource) along with it, you should be able to see the following examples properly:

• Chinese (Traditional) sample PS
• Chinese (Simplified) sample PS
• Japanese sample PS
• Korean sample PS

Of course, you can use ps2pdf etc. too.

Tag this post with del.icio.us!

If you follow online discussions of programming languages, you'll occasionally see articles about language X "dying". It is, however, a bad metaphor, because the "life cycle" of a programming language is different from single biological units, of which you can definitely say at some point "He's not pining ... this is an ex-parrot!". Once a programming language is widely deployed, it simply won't up and disappear from one day to the next. Too many people and companies depend on it, and replacing it is difficult enough, that the "switching costs" will keep it in place for many years. The obvious example is Cobol. This effect works in favor of languages that are not "the new thing", and means they will probably not truly cease to be used for many, many years. On the other hand, it's also pretty easy to tell which way the wind is blowing and get an idea of what's hot and what's not. Java got hyped a lot in the past, now it's Ruby. Scala is beginning to get hyped some, so is Erlang. Careful observers can spot the rise of languages as they hit the early stages of the technology adoption lifecycle. By paying attention to what's going on in the wider world, it's also possible to see when languages are used less and less for new projects, and solely kept on for the legacy systems. I think this is what most people mean by "dying", but of course it creates confusion, because it's clear that the language is still utilized. In some cases, I think it may be possible that a language continues to be more widely adopted, yet still seems to lag behind, simply because other languages are being adopted at a significantly higher rate. So what it's really about is two factors: how widely deployed is the language in any given moment, and, perhaps more importantly, the rate of adoption - is it accelerating or slowing down? Are more people jumping on the bandwagon, or is the language being used less by innovators, early adopters, and new projects? You need both those coordinates to understand where a language is at - it may be huge but declining, small but on its way up, or a niche language that never achieved widespread usage that isn't catching on any more. The last one is the one you'd probably want to be wary of. The first two will probably be ok as long as you understand what you're getting, and the type of user or organization you are matches where the language is at in its lifecycle. I think that perhaps those interested in discussing these things seriously ought to find some good terms to use. "Forth's rate of adoption is declining" doesn't sound as exciting as "Java is dying!" though. "Fortran's diffusion is decelerating" doesn't have much of a ring to it. Any other ideas?

After four or so months, it's time for another Hecl "checkpoint". Those who are seriously interested really ought to be getting Hecl from subversion, however, it's a good idea to tie up the loose ends every now and then, and put something that's easy to fetch for the casual user. https://sourceforge.net/project/showfiles.php?group_id=122383 This release contains a number of interesting things:

• Alpha support for Java integration. For example:

  java java.lang.System sys
  set ms [sys currentTimeMillis]
  

• Alpha support for Google Android. This utilizes the Java integration system above heavily. What sets it apart from just writing code in Java is that on top of the building blocks, I've started to write little bits of Hecl code to make common things very straightforward, layering on top of the Java API.
• Numerous fixes in the code, documentation, and build system.

Originally I planned to post this with the title "Last night I slept with 300 people" but this night happened two weeks ago... It was the night before the fourth and last day of the 24C3 were I slept in the gym :-) Actually I also planned to blog on the third day but then this day turned out to be really busy... and then I arrived home on new years eve and suddenly it was a week later and now it's the 10th of January. Time flies when you're having fun. And as you might have noticed it's not even the 10th anymore...

Timewarp back to the chaos communication congress! I think it's safe to say that the Debian booth at the 24C3 was a success. It was a nice meeting (and storage) point for Debian people, we collected quite some donations for t-shirts and stuff (the exact amount needs to be examined still) and we were able to help various users and contributors answering Debian specific questions of both kinds: how to install/configure/fix foo and packaging and other development questions from a number of people.. And we had a babelbox setup which was much better understood and perceived, once I added a sign explaining it :-)

Thanks a lot to the 24C3 organizers and the angels (thats how the congress volunteers are called) for making such a smooth and interesting conference as well as giving such a great space to the Debian booth! And equally thanks a lot to all the people operating our booth! For those who are interested to attend next year: roughly 64 talks were held in english, and 26 in german. I saw about five events live...



The sign hung for about an hour unmodified...

On the third day of the congress we had an OLPC.de meeting, which was quite productive and resulted in us founding OLPC Germany this monday. In the aftermath of this meeting I came up with the idea of having an OLPC Europe event at FOSDEM in Brussels in February, which by now has been accepted and scheduled by the FOSDEM organizers. Yay! So if you are in Europe and involved or interested in the OLPC, please mark the 23rd of February 15-17 localtime in your calendar :-) The idea of these projects is probably best summarized with "think global, act local and global", for more detail please read our vision. (And keep in mind this is in its very early stages.) OLPC Europe should also become an interface for all those european OLPC efforts which have been popping up recently and which all take up ressources in Cambridge, the OLPC "mothership", taking ressources away from the children of the world.

Then on the last day of the 24C3 congress I also gave the DebConf7 "thank you, Sponsor"-package to those four people from the freifunk community, who helped us out with accesspoints for Edinburgh. Much to my surprise and joy, they were really happy about it! Funnily two of those four are also among the three OpenWRT developers who ported OpenWRT to the OLPC laptop, which I borrowed to them somewhat in return :-) And now we work together in OLPC.de and .eu. Networking is sometimes really really fun.

Fast forward to 2008. Two days ago I finanlly had the time to to run etch, lenny and sid on the OLPC laptop (with wireless (including WPA), xorg and sound working and dualbooting with the original fedora install) and then yesterday I've created a usbstick which successfully booted a "d-i prototype". Yay! And best of all (for me), most of the actual work was done by other people, I just had to collect the pieces. My next steps will be documenting what I did and prepare a d-i image which actually works. I don't have pics yet (it's Debian running on a laptop, I guess you can imagine this), so for now I will just post another picture I received some three months ago and which made me incredibly happy at that time:



When I have a working d-i running on it, I'll post more pics.

Bits from the Debian i18n meeting (Extremadura 2007)

From December 12th to December 15th, Junta de Extremadura hosted another one of the Debian Meetings; five i18n guys shared ideas, food, buses and fun with the Debian KDE maintainers. We would like to thank Extremadura for hosting us during the Hispalinux Meeting 2007, the event was held at Universad de Derecho (Law University) in Caceres, Spain.

These are the minutes, results and notes from our work, it is a brief description but hopefully complete of what we have done and what is still missing/pending.

Thanks to Cesar (cek) we had the chance to work on churro (i18n.debian.net) locally; the server is still running a 2.4 kernel because of some "tick" problems with 2.6 series, the last one tried was 2.6.21 and we should try newer ones, in order to support upgrades and not get stuck with 2.4, we hope Cesar will find time to test new Debian kernels.

First, let me introduce everybody to the services, robots and resources being hosted by i18n.d.n:

• MoinMoin wiki for local and simple reference documentation, it contains all the links to the below resources. (http://i18n.debian.net/wiki/)
• Pootle experimental server
• dl10n scripts, aka dl10n robots (codename Lion), these scripts are responsible for the status of pseudo URLs used by some translation teams, by the Project Smith and by the NMU Priority List for i18n NMU Campaign
• Synchronization of the i18n material used by the Debian website to generate translation statistics about PO and PO-debconf
• Generation of Compendium PO files per-language
• Different types of statistics
• Other non user-visible services like a full source mirror for stable, testing, unstable and experimental, used by the scripts and robots.
• DDTP, Debian Descriptions Translation Project
• DDTSS, The Debian Distributed Translation Server Satellite, a web front-end for DDTP, now integrated to DDTP to use the Database back-end instead of the e-mail interface.

And, at some point, we found important to state clear the acronyms and names used in related DDTP projects/tools:

• DDTS, Debian Description Translation Server, this is the main "back-end" used in DDTP, it tends to be the interface between translator tools (present and future ones) and the database;
• ddt.cgi is a CGI interface that is able to provide info for specific packages or translations, including diffs, related packages and active/inactive descriptions.
• DDTC which is the old (and still functional) command line client for DDTP.

We took the chance to organize a few things on churro, old accounts were cleaned out and removed, we moved from /org to /srv and got more GBs of space to the "playground". Old files were also removed and some are schedule to deletion on early 2008. With the reallocation of /org we also find some more space to /home and /var, we reorganize some of the links on the web space (specially to remove services from people's accounts), and we changed the mirror script to also synchronize the Packages and Contents files.

Grisu and Martijn worked mainly on DDTP and DDTSS integration. DDTSS now provides statistics for stable, testing and unstable, we are also working with Debian Med to provide support and infrastructure to a specific audience, like packages related to Medicine. The conversion to talk directly with DDTP/DDTS database also provided:

• Fetching new translations is almost instantaneous and marks translation as requested (avoiding duplicated works via the e-mail interface).
• After sufficient reviews occurred, the upload is instant
• Committed DDTS / DDTSS / DDTP website generation into SVN
  • Added READMEs for the above directories

DDTSS now announces the user using authentication because of its integration with the Database backend used by DDTP. Quick trivia: DDTP is now a compound of 25 languages occupying 18 GBytes.

A few days before the meeting we had the offer to use "AUTOBYHAND" to upload a package with the Translation-* files. The package is now called 'ddtp-translations' and we worked during the meeting to create scripts to build the package and to test it on the archive side. This approach allow Debian i18n Team to upload new translations and remove old ones (or inactive ones) without bother FTP Master Team. Special thanks to Anthony Town, he has been working with us to prove tips, fixes and info on how to produce the package and the scripts. The code is available in the debian-l10n SVN under pkg-ddtp-translations:
http://svn.debian.org/viewsvn/debian-l10n/pkg-ddtp-translations

In our case, "BYHAND" processing consists of a simple tarball of the main,contrib,non-free /i18n/Translation-*, we decide to work on a set of scripts to make it easier to create new packages (ddtp-translations) in a consistent way and keeping debian/changelog up-to-date. We also made some suggestions to the script what will run on the archive side to check the tarball structure, base on the examples of debian-maintainers and debtags (tags-override).

One of our initial targets for the meeting with regards to Pootle and Debian was to try big PO files per language, fortunately, Nicolas and Friedel were able to increase Pootle performance enough to get a few languages from DDTP loaded in Pootle. Using the upstream Pootle-diet branch, which uses a database back-end for the generation of statistics, the time to browse the DDTP POs of a language (~20.000 files) went down to a dozen of seconds.

Speaking about Pootle, Friedel gave us a good picture of what is coming next in terms of Pootle's development. There are improvements planned in the areas of permissions and rights delegation, as well as file management (for projects and templates). Improved management of terminology projects is also planned.

Improvements in the QA capabilities of the translate toolkit and Pootle are planned to help with the "false positives" of the pofilter checks. Better reuse of existing translations will become possible by using better translation memory techniques. There is also work planned on formats and converters involving, for example, XLIFF, TMX, TRADOS and WordFast.

Another pending task for quite a while was the CVS migration to SVN, it is now done, with a new layout. Commits to the CVS were disabled and every single script or resource depending on CVS should be changed to use SVN. For now, we are publishing (via HTTP) the status files generated by the pseudo-urls robots until we can fix the scripts to re-enable the commit of the files. You can find them here: http://i18n.debian.net/debian-l10n/status/

We are pretty happy with the changes and results of the work during those days, but we still have some items pending on our TODO list:

• More advertisement and usage information about PO Compendiums
  There are two use cases are identified:
  
  • Filling new PO files.
  • QA work to find inconsistent translations.
  Maybe Eddy would love to do that? :-)
• Extend the duration of the statistics history. (Nekral)
• Debian packages of the services running on churro
  • DDTP (Grisu)
  • DDTSS (Martijn)
  • dl10n (Nekral)
• DDTP: add some scripts to handle packages with version in the description (e.g. kernel and kernel modules) (Martijn)
• DDTP: Standard generation of the translation tarballs (faw)
• DDTP: document the bracketed stats on the main page (faw)
• DDTC: should be updated to match the current features. Documentation to ease integration with procmail. (Nekral - low priority)
• Implement mail service for translation teams with their own robots (e.g. Dutch) (faw)
• Collect data from http://www.debian.org/devel/website/stats/ (Nekral)
• http://www.debian.org/intl/l10n/po/,
  http://www.debian.org/intl/l10n/po-debconf/
  are built based on the churro material. It would make more sense to build these statistics on churro (Nekral)
  • We could "fork" the page and add some fancy new features on these pages (Nekral)
  • Add information from the coordination page to indicate that a translation is ongoing. (Nekral)
• Pootle: missing review indication. Hard with PO back-end. (Friedel)

There are a couple more reports to be sent but they are more focused on i18n specific questions, tools and plans for 2008. So, probably those will be sent only to debian-i18n mail list. If you are interested, please, stay tuned. :-)

Posted on d-d-a: http://lists.debian.org/debian-devel-announce/2008/01/msg00002.html
And a big thanks to Nicolas François (aka nekral), he helped me a lot making notes, preparing the text and reviewing it; and was patient enough to wait for the report while I was solving some personal problems.

The other day, I had an interesting problem, regarding Apache, the LocationMatch directive and regular expressions. I'll put it here, so I'll be able to find it again... Actually it was a quite simple problem: A simple web page, where all web pages are protected with a password. No big Problem: Use a <location /> and AuthType basic, problem solved.... or isn't it? Some documents might be needed to be available without the authentication... for example robots.txt... or the funky custom error document, which explains how to get the authentication data, in case the authentication fails. Looking at the documentation, found a solution: LocationMatch exists, where you specify a regular expression, which must match, for the following configuration to apply. What isn't mentioned in the documentation, that the obvious solution... something like <LocationMatch !"^/(robots.txt my401handler.html"> doesn't work. See apache bug 10932. Needed quite some time, to find this out... Luckily Meike found the bug report above, which has a workaround for that problem: Use <LocationMatch "^/(?!robots.txt my401handler.html)"> Oh... and if your customized error handler references some pictures or style sheets, don't forget to add them to the regular expression above, too.