It seems that most mailing lists occasionally have meta-discussions about what is on-topic, the few that don t are the ones that have very strong moderation authoritarian moderators who jump on the first infraction and clearly specify the rules. I don t recall the list of acceptable topics for any mailing list including also discussions about what is on-topic . As this is the Internet I m sure that someone will immediately point out an example of such a list, but apart from the counter-example that someone will provide it seems obvious that for the majority of mailing lists a meta-discussion is not strictly on topic. Regardless of a meta-discussion not being on-topic I don t think there s anything wrong with such a discussion on occasion. But if a meta-discussion is to be based on the volume of off-topic messages it would be nice if the people who advocate such a position could try and encourage the discussion in a way that reduced the number of messages. Replying to lots of messages is not a good strategy if your position is that there are too many messages. If a meta-discussion is going to be about moving off-topic discussions to other forums that are more appropriate then it would be nice to have the meta-discussion move to another forum if possible. My previous post which advocates creating a separate mailing list for chatty messages was an attempt to move a discussion to a different forum [1]. Anyone who believes that such discussions don t belong on a list such as debian-private is free to commit their thoughts to some place that they consider more appropriate and provide the URL to any interested parties. I think that it s worth noting that the only comment on my previous post is one that describes how to filter mail to split the traffic from the debian-private list into different mailboxes. I had hoped that other people would write blog posts advocating their positions which would allow us to consider the merits of various ideas without the he-said-she-said element of mailing list discussions. Most mailing lists have a policy against profanity and some go further and ban personal abuse. Therefore it seems hypocritical to advocate a strict interpretation of the rules in regard to what is on-topic while also breaking the rules regarding profanity or personal abuse. I don t think it s asking a lot to suggest that the small minority of messages that someone writes on the topic of a list meta-discussion should obey the set of rules that they advocate I m not suggesting that someone should obey all the rules all the time, just when they are trying to enforce them. Also you can argue that a list policy against profanity doesn t preclude sending profane messages off-list, but if the off-list messages are for the purpose of promoting the list rules it still seems hypocritical to use profanity. It is a fair point that off-topic discussions and jokes can distract people from important issues and derail important discussions. It would be good if people who take such positions would implement them in terms of meta-discussions. If the purpose of a meta-discussion is to avoid distraction from important issues then it seems like a really good idea to try and avoid distraction in the meta-discussion thread. I wonder whether a meta-discussion can provide anything other than a source of lulz for all the people who don t care about the issue in question. The meta-discussions in the Debian project seem to always result in nothing changing, not even when the majority of people who comment agree that the current situation is not ideal. When an almost identical meta-discussion happens regularly it seems particularly pointless to start such a discussion for the purpose of reducing off-topic content. Revisiting an old discussion can do some good when circumstances change or when someone has some new insight. I know that it s difficult to avoid being sucked into such discussions, when I was diagnosed with AS [2] I decided to try and minimise my involvement in such discussions but I haven t been as successful at doing so as I had hoped.

• [1] http://etbe.coker.com.au/2010/06/09/serious-non-serious-mailing-list/
• [2] http://etbe.coker.com.au/2009/11/08/im-an-aspie/

After one year in France, there's still something I cannot completely understand; I don't know if it is something common in Europe, or a artifact of the French law, or if it is just that French people like to do things so formally all the time... I was taking a look at the website of the local LUG, and was amazed that they have association loi de 1901 status, an administration council with 11 members, statute, and written bylaws. Also, to be a part of the association, you need to send a paper form and at least 10. According to the Wikipedia page , an association loi de 1901 is just a non-profit organisation, and it has that status even if it is not registered. But it seems that is not mandatory to have any of the hierarchical structure, written rules and the such! So it seems that any group of more than 10 that gets together to do something go through all this trouble when it is not needed, there should be some explanation for all this... Tags: Planet Debian, Planet Lugfi, Francia

My project. I m publishing my report earlier this week, because there was a lot to talk about. This week I started to make changes in the code going in the direction of what I want to do. I haven t started a final implementation, but I m studying about how what I want to do will affect the rest of the Garbage Collection (GC). I noticed the code in rts/sm/Sweep.c was simple and similar to what I m planning to do, so I started changing how it works. Sweep in the Glasgow Haskell Compiler (GHC) is done by a bitmap, which contains a bit for each word in a memory block, and is set to 1 when there s an object starting in the mapped area and 0 otherwise. When there s a block with no objects starting at it, that is, all bits of the bitmap are set to 0, the block is freed.

        if (resid == 0)
         
            freed++;
            gen->n_old_blocks--;
            if (prev == NULL)  
                gen->old_blocks = next;
              else  
                prev->link = next;
             
            freeGroup(bd);
         

The bits are analyzed in a group of BITS_IN(W_), where BITS_IN(W_) is the number of bits in a word.

        for (i = 0; i < BLOCK_SIZE_W / BITS_IN(W_); i++)
         
            if (bd->u.bitmap[i] != 0) resid++;
         

If more than of the groups are completely set to 0, the block is considered fragmented.

            if (resid < (BLOCK_SIZE_W * 3) / (BITS_IN(W_) * 4))  
                fragd++;
                bd->flags  = BF_FRAGMENTED;
             

Immix, the GC algorithm I plan to implement in GHC, divides the blocks of memory in lines. My initial plan was to identify free lines. I decided to consider a the size of a line fixed in BITS_IN(W_) words, because it will map to a word in the bitmap, and the code was already analyzing in groups of BITS_IN(W_) words. This was very easy with the current code.

            if (bd->u.bitmap[i] != 0) resid++;
            else printf("DEBUG: line_found(%p)\n", bd->start + BITS_IN(W_) * i);

This worked, and showed some free lines. I m sure there are other ways of logging in GHC, but printf was the simplest way I could thought of. I measured the occurrence of free lines using the bernouilli program from the NoFib benchmark suite, calling it with 500 +RTS -w, to make it uses sweep. In 782 calls to GarbageCollect(), sweep() was called 171 times, for 41704 blocks to be swept and found 230461 free lines. This gives us about 5.5 free lines per block, from the 8 lines in each block (on 64 bits systems). The problem is that the bitmap is marked only in the start of the objects allocated, so even in a line that all bits are marked with 0 we can t assume that it s completely free, because there may be an object that starts in the previous line that is using the space of the line. Checking only for the previous line doesn t work either, because a big object can span several lines. What we can do here is a variation of conservative marking, as proposed in the Immix paper, checking only the previous line and working only with objects smaller than a line. To make sure I was working only with objects smaller than a line, I had to mark the blocks that contains medium objects and avoid them when seeking free lines. The block flags are defined in includes/rts/storage/Block.h, so I included another flag in this file, BF_MEDIUM.

/* Block contains objects evacuated during this GC */
#define BF_EVACUATED 1
/* Block is a large object */
#define BF_LARGE     2
/* Block is pinned */
#define BF_PINNED    4
/* Block is to be marked, not copied */
#define BF_MARKED    8
/* Block is free, and on the free list  (TODO: is this used?) */
#define BF_FREE      16
/* Block is executable */
#define BF_EXEC	     32
/* Block contains only a small amount of live data */
#define BF_FRAGMENTED 64
/* we know about this block (for finding leaks) */
#define BF_KNOWN     128
/* Block contains objects larger than a line */
#define BF_MEDIUM    256

The GHC GC is generational, there is, objects are allocated in a generation and, after a time, the ones that are still being used are moved the next generation. This idea assumes the death probability of younger objects is higher, so few objects are moved to the next generation. Sweep and Immix work only in the last generation so, to mark blocks with medium objects we have to check the size of the objects that are moved to the next generation. This is done in the copy_tag function of rts/sm/Evac.c. I inserted a code that checks for the object size and marks the block when it s bigger than BITS_IN(W_).

STATIC_INLINE GNUC_ATTR_HOT void
copy_tag(StgClosure **p, const StgInfoTable *info,
         StgClosure *src, nat size, generation *gen, StgWord tag)
 
    StgPtr to, from;
    nat i;
    to = alloc_for_copy(size,gen);
    if(size > 8)  
        Bdescr(to)->flags  = BF_MEDIUM;
     

So I updated the code in rts/sm/Sweep.c to only inspect for free lines in blocks without BF_MEDIUM mark.

            if (bd->u.bitmap[i] != 0) resid++;
            else if(!(bd->flags & BF_MEDIUM))  
                printf("DEBUG: line_found(%p)\n", bd->start + BITS_IN(W_) * i);
             

This also worked. Now, in the 32012 blocks there were 189015 free lines, found in the same number of GCs, making about 5.9 free lines per block. We considered only blocks with small objects, but we didn t ignore the first line of each group of free lines. This can be achieved by checking if the previous line was also free.

            if (bd->u.bitmap[i] != 0) resid++;
            else if(!(bd->flags & BF_MEDIUM) && i > 0 && bd->u.bitmap[i] == 0)  
                printf("DEBUG: line_found(%p)\n", bd->start + BITS_IN(W_) * i);
             

Now, from the 32239 blocks, 165547 free lines were found, giving 5.1 free lines per block. But there are more things to improve. If the whole block is free, we want to free it, instead of marking it s lines as free. So it s better to mark the lines after we know that the blocks are not completely free. So I left the code that checks the bitmap as it was, and included a line check only for blocks that are not completely free. At this point, I also associated the fragmentation test with blocks with medium objects, because in blocks of small objects we plan to allocate in free lines, so fragmentation is not a (big) issue.

            if (resid < (BLOCK_SIZE_W * 3) / (BITS_IN(W_) * 4) &&
                (bd->flags & BF_MEDIUM))  
                fragd++;
                printf("DEBUG: BF_FRAGMENTED\n");
                bd->flags  = BF_FRAGMENTED;
             
            else if(!(bd->flags & BF_MEDIUM))  
                for(i = 1; i < BLOCK_SIZE_W / BITS_IN(W_); i++)
                 
                    if(bd->u.bitmap[i] == 0 && bd->u.bitmap[i - 1] == 0)  
                        printf("DEBUG: line_found(%p)\n", bd->start + BITS_IN(W_) * i);
                     
                 
             

The total ammount of blocks increased dramatically: the blocks that become fragmented and were not called again in sweep made a huge difference. From the 345143 blocks, 1633268 free lines were found, or about 4.7 free lines per block. 9434 blocks were free, so, from the remaining blocks, we have about 4.9 free lines per block. Something we ll need then is a way to access these lines latter. The simplest way I thought to achieve it is constructing a list of lines, in each the first word of each free line is a pointer to the next free line, and the first word of the last free line is 0. It s useful to keep reporting the lines to stdout, so that we can then follow the list and check if we went to the same lines.

                    if(bd->u.bitmap[i] == 0 && bd->u.bitmap[i - 1] == 0)  
                        StgPtr start = bd->start + BITS_IN(W_) * i;
                        printf("DEBUG: line_found(%p)\n", start);
                        if(line_first == NULL)  
                            line_first = start;
                         
                        if(line_last != NULL)  
                            *line_last = (StgWord) start;
                         
                        line_last = start;
                        *line_last = 0;
                     
                 
             
         
     
    for(line_last = line_first; line_last; line_last = (StgPtr) *line_last)  
        fprintf(stderr, "DEBUG: line_found(%p)\n", line_last);
     

I printed the inclusion of the lines on the list to stdout, and the walking on the list in stderr, so that it d be easy to diff. There was no difference between the lists. There re another improvements that can be made, like using a list of groups of free lines, but I think it ll be better to think about this after studying how the allocation in the free lines will be done. That s where I m going to now.

---

There are some minor things I learned, and thought they worth blogging. The current GHC uses three strategies for collecting the last generation: copying, mark-compact and mark-sweep. Copying is the default until the memory reaches 30% of the maximum heap size; after that, mark-compact is used. Sweep can be chosen by a Real Time System (RTS) flag, -w. To use mark-compact always, the flag is -c. I ve been submitting small patches to the cvs-ghc mailling list, mostly about outdated comments. Most of them were accepted, except for one which contained a lot of commentary, and that indeed was not completely correct. I corrected it and resend to the list, but the message is waiting for approval because the message header matched a filter rule. I believe this is because I replied the message generated from darcs. There s a very useful ghc option, specially for testing the compiler, because in this case you need to rebuild the source, even when there re no changes in it. It s -fforce-recomp, and it makes only sense when used with --make.

Robert Collins did a very nice writeup not so long ago of creating a Debian package with bzr-builddeb, but he starts from the assumption that upstream also uses bzr. As we all know, there are many projects that have their upstream sources in a VCS, but don't use bzr. Can we still get reasonable results from bzr-builddeb, including the ability to merge new upstream releases direct from the VCS, if, say, upstream is using git? Yes, we can! Of course, if you're happy with using git as the VCS for your Debian packaging already, there's probably no compelling reason for you to switch to bzr. But if you prefer to use bzr and have been frustrated at having to choose between being able to use the VCS client of your choice for your packages and being able to use your VCS client to access upstream revision history, read on. Thanks to the fine work of Jelmer Vernooij and friends, bzr-git has been usable for a while if you just want to track the default git branch. But what if you care about tracking multiple upstream branches? Enter bzr git-import, which we'll use to set up a bzr repo from scratch for our cifs-utils package, with a full import of all the branches of upstream's git tree. First we do some work to set up a shared bzr repository. As long as we're going to the effort of mirroring all the git branches, we probably want to publish them for other people to use, so we make sure our bzr repository is reasonably configured for sharing data between branches:

$ bzr init-repo --no-trees cifs-utils.server
Shared repository (format: 2a)
Location:
  shared repository: cifs-utils.server
$ cd cifs-utils.server

Then we use bzr git-import, provided by the bzr-git plugin, to do a full import of the upstream branches into a cleverly named subdirectory:

$ bzr git-import git://git.samba.org/cifs-utils.git upstream
[/                   ] Counting objects: 181, done.

Now we create our own local 'trunk' for the package, by branching from the upstream tag matching the release version we're going to package.

$ bzr branch -r tag:cifs-utils-4.0rc1 upstream/HEAD trunk
Branched 42 revision(s).

Do a little more prep work for future branches...

$ mkdir branches

And that's it. Now we have a bzr repo locally that we can push out to our hosting server of choice (N.B.: we could do this all directly on the server, but alioth doesn't currently have bzr-git installed):

$ rsync -az . alioth.debian.org:/bzr/pkg-samba/cifs-utils/
$

Now that we have a bzr repository, it's time to get ourselves a working directory and do some packaging. We're probably going to work with multiple branches locally as well, so we create another shared repository for local use, and get a copy of the trunk branch we created before.

$ bzr init-repo cifs-utils
Shared repository with trees (format: 2a)
Location:
  shared repository: cifs-utils
$ cd cifs-utils
$ bzr co bzr+ssh://bzr.debian.org/bzr/pkg-samba/cifs-utils/trunk

Now we grab the upstream tarball, and whip up some quick packaging with (what else?) debhelper 7:

$ wget ftp://ftp.samba.org/pub/samba/cifs-utils/cifs-utils-4.0rc1.tar.bz2
$ ln -s cifs-utils-4.0rc1.tar.bz2 cifs-utils_4.0~rc1.orig.tar.bz2
$ cd trunk
$ mkdir -p debian/source
$ echo '3.0 (quilt)' > debian/source/format
$ echo 7 > debian/compat
$ cp /usr/share/doc/debhelper/examples/rules.tiny debian/rules
$ dch --package cifs-utils --versio 4.0~rc1-1 --create 'Initial package'

Create debian/control by hand, generate an initial source package, and import it into bzr with bzr-builddeb.

$ debuild -uc -us -S -i
$ rm -r debian
$ bzr import-dsc ../*.dsc
$

Since we want to continue tracking upstream development, we need to periodically sync our bzr import of the git tree.

$ bzr git-import git://git.samba.org/cifs-utils.git bzr+ssh://bzr.debian.org/bzr/pkg-samba/cifs-utils/upstream
$

And when we find a new upstream version in that import that we want to package, bzr-builddeb makes this a snap, too.

$ cd cifs-utils
$ wget ftp://ftp.samba.org/pub/samba/cifs-utils/cifs-utils-$version.tar.bz2
$ cd trunk
$ bzr merge-upstream --v3 --version $version_with_epoch \
    ../cifs-utils-$version.tar.bz2 -r tag:cifs-utils-$version \
    bzr+ssh://bzr.debian.org/bzr/pkg-samba/cifs-utils/upstream/HEAD
No distribution specified, and no changelog, assuming 'debian'
Committing to: /tmp/tmpbzOVMs/upstream/
Committed revision 2.
All changes applied successfully.
The new upstream version has been imported.
You should now review the changes and then commit.
$ bzr diff
<review changes>
$ bzr commit -m "merge upstream $version"
Committing to: bzr+ssh://bzr.debian.org/bzr/pkg-samba/cifs-utils/trunk
modified debian/changelog
Committed revision 50.
$

And that's it! It's exciting to see signs of real interoperability between DVCSes at last. Thanks to everyone who's helped make it possible!

I was asked by email whether SE Linux could implement traditional Unix users and groups. The Strictly Literal Answer to that Question The core of the SE Linux access control is the domain-type model where every process has a domain and every object that a process can access (including other processes) has a type. Domains are not strongly differentiated from types. It would be possible to create a SE Linux policy that created a domain for every combination of UID and GID that is valid for a user shell given that such combinations are chosen by the sysadmin who could limit them to some degree. There are about 2^32 possible UIDs and about 2^32 possible GIDs, as every domain is listed in kernel memory we obviously can t have 2^64 domains, but we could have enough to map a typical system that s in use. Of course the possible combinations of supplemental groups probably makes this impossible for even relatively small systems, but we can use a simpler model that doesn t emulate supplemental groups. For files there are more possible combinations because anyone who is a member of a group can create a SETGID directory and let other users create files in it. But in a typical system the number of groups is not much greater than the number of users the maximum number of groups is typically the number of users plus about 60. So if we had 100 users then the number of combinations of UID and GID would be something like 100*(100+60)=16,000 it should be possible to have that many domains in a SE Linux policy (but not desirable). Then all that would be needed is rules specifying that each domain (which is based on a combination of UID and GID) can have certain types of access to certain other types based on them having either the same UID or the same GID. Such a policy would be large, it would waste a lot of kernel memory, it would need to be regenerated whenever a user is added, and it s generally something you don t want to use. No-one has considered implementing such a policy, I merely describe it to illustrate why certain configuration options are not desirable. The rest of this post is about realistic things that you can do with SE Linux policy and how it will be implemented in Debian/Squeeze. My previous post titled Is SE Linux Unixish? addresses this issue at a more conceptual level and also considers MAC vs DAC [1]. The History of mapping Unix Accounts to SE Linux Access Control In the early releases of SE Linux (long before it was included in Fedora) every user who could login to a system needed to have their user-name compiled into the policy. The policy specified which roles the user could access, the roles specified which domains could be accessed, and therefore what the user could do. The identity of files on disk was used for two purposes, one was logging (you could see who created a file) and the other was a permission check for the SE Linux patched version of Vixie cron which would not execute any command on behalf of a user unless the identity on the crontab file in the cron spool matched the identity used to run it this is an analogy of the checks that Vixie cron makes on the Unix UID of the crontab file (some other cron daemons do fewer checks). Having to recompile policy source every time you added a user was annoying. So a later development was to allow arbitrary mappings between Unix account names and SE Linux Identities (which included a default identity) and another later development was to have a utility program semanage to map particular Unix account and group names to SE Linux identities. This was all done years ago. Fedora Core 5 which was released in 2006 had the modular policy which included these features (apart from mapping Unix groups to SE Linux identities which was more recent). Fedora Core 5 also introduced MCS which was comprised of a set of categories that a security context may have. The sysadmin would configure the set of categories that each account would have. A recent development has been a concept named UBAC (User Based Access Control) which basically means that a process running directly on behalf of a regular user (IE with a SE Linux identity that s not system_u) can only access files that have an identity of system_u or which have the same identity as the process. This means that you can only access your own files or system files not files of other users which may have inappropriate Unix permissions. So for example if a user with a SE Linux identity of john gives their home directory the Unix permission mode of 0777 then a user with a SE Linux identity of jane can t access their files. Of course this means that if you have a group of people working together on a project then they probably need to all have the same Identity and in practice you would probably end up with everyone having the same identity. I ve given up on the idea of using UBAC in Debian. The Current Plan for Users and SE Linux Access Control in Debian My plan is to have things work in Squeeze in much the same way as in Lenny. You have a SE Linux identity assigned to a login session and everything related to it (including cron jobs) based on the Unix account name or possibly the Unix group name (if there are login entries for both the user-name and the group-name then the user-name entry has precedence). The mapping between Unix accounts and SE Linux identities is configured by the sysadmin and SE Linux identities don t matter much for the Targeted configuration (which is what most people use). The identity determines which roles may be used and also has a limit on the MCS categories. The MCS categories are also specified in the login configuration which has to be a sub-set of the categories used by the identity record. So for example the following is the output of a couple of commands run on a Debian/Unstable system. They show that the test Unix account is assigned a SE Linux identity of staff_u and an MCS range of s0-s0:c1 (this means it creates files by default at level s0 and can also write to other files at that level, but can also have read/write access to files at the level s0:c1 ). The staff_u identity (as shown in the output of semanage user -l can be used with all categories in the set s0:c0.c1023 where the dot means the set of categories from c0 to c1023 inclusive) but in the case of the test user only one category will be used. The test group however (as expressed with %test ) is given the identity user_u and is not permitted to use any categories.

# semanage login -l
Login Name    SELinux User    MLS/MCS Range           
%test         user_u          s0                     
__default__   unconfined_u    s0-s0:c0.c1023         
root          unconfined_u    s0-s0:c0.c1023         
system_u      system_u        s0-s0:c0.c1023         
test          staff_u         s0-s0:c1               
# semanage user -l
             Labeling   MLS/       MLS/                         
SELinux User Prefix     MCS Level  MCS Range         SELinux Roles
root         sysadm     s0         s0-s0:c0.c1023    staff_r sysadm_r system_r
staff_u      staff      s0         s0-s0:c0.c1023    staff_r sysadm_r
sysadm_u     sysadm     s0         s0-s0:c0.c1023    sysadm_r
system_u     user       s0         s0-s0:c0.c1023    system_r
unconfined_u unconfined s0         s0-s0:c0.c1023    system_r unconfined_r
user_u       user       s0         s0                user_r

I hope to get the policy written to support multiple user roles in time for the release of Squeeze. If I don t make it then I will put such a policy on my own web site and try to get it included in an update. The policy currently basically works for a Targeted configuration where the users are not confined (apart from MCS). How MMCS Basically Works The vast majority of SE Linux users run with the MCS policy rather than the MLS policy. For Debian I have written a modified version of MCS that I call MMCS. MMCS is mandatory (you can t relabel files to escape it) and it prevents write-down. If a process has the range s0-s0:c1,c3 then it has full access to files labelled as s0, s0:c1, s0:c3, and s0:c1,c3 and any files it creates will be labeled as s0. If a process has the range s0:c1-s0:c1,c3 then it has read-only access to files labelled as s0 and s0:c3 and read-write access to files labelled as s0:c1 and s0:c1,c3. This means that any secret data it accesses that was labelled with category c1 can t be leaked down to a file that is not labelled with that category. Now MCS currently has no network access controls, so there s nothing stopping a user from using scp or other network utilities to transfer files. But that s the way with most usable systems. I don t think that this is necessarily a problem, the almost total lack of network access controls in a traditional Unix model doesn t seem to concern most people. Now to REALLY Answer that Question SE Linux is a Mandatory Access Control (MAC) system, this makes it inherently different to a Discretionary Access Control (DAC) system such as traditional Unix access controls. Unix permissions are based on each file having a UID, a GID, and a set of permissions and each process having a UID, a GID, and a set of supplementary GIDs. If a user runs a setuid or setgid program then the process will have extra privileges. It also has a lot of stuff that most people aren t aware of such as real vs effective UIDs, the tag bit, setgid directories, and lots more including some quite arbitrary things like making ports <1024 special. SE Linux is based on every object (process, file, socket, etc) having a single security label which includes an identity, a role, a type, and a sensitivity label (MCS categories or an MLS range). There is no support for an object to have more than one label. The SE Linux equivalent to setuid/setgid files is a label for a file which triggers a domain transition when it s executed. This differs from setuid files in that the domain transition is complete (the old privileges can t be restored) and the transition is generally not to a strict super-set of the access (usually a different sub-set of possible access and sometimes to lesser access). These differences are quite fundamental. So really SE Linux can t implement traditional Unix access control. What SE Linux is designed to do is to provide a second layer of defense and to also provide access controls that have different aims than that of Unix permissions such as being mandatory and implementing features such as MLS.

• [1] http://etbe.coker.com.au/2008/08/25/is-se-linux-unixish/

Two years ago, while working on awesome, I joined the Freedesktop initiative to work on XCB. I had to learn the arcane of the X11 protocol and all the mysterious and old world that goes with it. Now that I've swum all this months in this mud, I just feel like I need to share my thoughts about what become a mess over the decades. When I was unborn

the Toto band were releasing their song "Africa" and some smart guys were working on a windowing system: the X Window System (this is its full name) which therefore has a (too) long history. The latest version of its protocol, the 11th one, has been designed in the 80's. You can learn more about the history in the Wikipedia article about X. In 2010, we still listen disco music and we still use various protocols designed in the 80's and even before X. Music have evolved, protocols have evolved, and so did X11. The problem is that X11 did not evolve that well. The guys at MIT-and-some other-places-with-very-smart-people-in-it created X version 1 in 1984, and updated it until X version 11 (the one we're still using) in 1987. Eleven version in 3 years, that was following the "release early, release often" model. But I don't know why, it just stopped to happen for the last 23 years¹. I don't know what changes have been made in the first 11 major versions of the X protocol, but I'm rather sure we should have deserve a couple of major version updates this last 2 decades. In my humble opinion, X11 was not designed to live 23 years. But hey, I'm not blaming anyone here: I was 4 years old and playing Lego when they released this latest version of the X protocol, so there is little chance I'd have done something better.

1. That's not totally true: they added (and then deprecated) many extensions. We won't fix. We'll work-around.

That is probably one of the guideline of the X protocol for the last years. And don't misread me: I'm not bashing anyone thereafter. Since the X11 protocol was aging, the X guys started to add extensions. They added tons of them over the years. This, in application of one of the early principles of X:

It is as important to decide what a system is not as to decide what it is. Do not serve all the world's needs; rather, make the system extensible so that additional needs can be met in an upwardly compatible fashion.

All of them with no exception were added because, bad luck, the X11 protocol did not anticipated the things that happened in the last 23 years, like video, OpenGL, multiple monitors, or the pleasure to draw oval windows. Some of this extensions are still in use, while some of them have been dropped. While this is not a bad thing to extends the protocol, it seems like a bad thing to try to fix the protocol with for example the XFixes extension, even with all the good intentions Keith Packard might have in his greatness. Actually it's even worst than you think

The X11 protocol (without extensions) defines about 120 types of requests: create a window, move a window, etc. Nowadays, there's at least 25 % of them which are useless: usage of server-side font, or the drawing of squares and polygon, are unused by any modern application or toolkit. All of this is superseded by requests from extensions, like the XRender one. The handling of multiple monitors displays has totally been screwed up. X11 has been designed to work in Zaphod mode (independent monitors). But Xinerama, and nowadays XRandR have replaced it up: recent X servers (released after ~2007) does not support Zaphod mode anymore, even if it's a core piece of the X11 protocol. Worst: on many requests, there's limitation or design flaws, like described in this document: Why X Is Not Our Ideal Window System by DEC researchers. We'll add more broken standard on top of that

Following its early principle, X does not define policies but only mechanisms, which seems like a good thing, Consequently, people started writing specifications to determine a number of stuff and dogmas: ICCCM. That was 22 years ago in 1988. It's useless to add that many things in this specification are now obsolete, useless, or that it misses many modern stuff. I was not the only one to think that. The people from what will be the major desktop environments, KDE and GNOME, saw that too in the 90's while I was learning to count. So they wrote EWMH, another standard that comes on top of ICCCM and extends it with nifty features like maximization, full screen mode, etc. The problem is that this standard has also been written by narrow-minded people who at that time, were working on GNOME or KDE (and maybe others). This desktop environments were having and still have some strong concepts of how should work a desktop: "it should have work-spaces", "a window is only on one workspace", "we only see a workspace at a time", "you do not have multiple screens", etc. Dude, we don't care: we have toolkits!

This vision of how the desktop should work have now been written in marble in all applications and libraries implementing EWMH, like GTK+ or Qt. Nowadays, everybody forgot about all of this standards. Toolkits have implemented this, circumvented the X11 protocol limitation and flaws, and nobody wants to look back. Like all standards, obviously some people implemented them badly. This had some side effects, like OpenOffice acting like a pager. We don't look back? Worst, we forgot where we came from!

With all these layers of bad designed standards, the desktop continued to evolve for more than a decade. They continued to add more standard, the more recent ones being based on D-Bus like the Desktop Notification Specification or the latest Status Notifier Specification developed by KDE. The Status Notifier is a new implementation of the good old system tray based on XEmbed, using D-Bus instead of the X11 mechanisms, and adding the possibility to show the system tray with something else than icons. This specification draft saw an important issue and design flaw raised by Wolfgang Draxinger in this thread on the XDG mailing-list. What Wolfgang points out, is that X is network-oriented, and D-Bus is not. Therefore, making the Status Notifier specification to use D-Bus to pass system tray messages around is a bad idea, since running a X application from host A on host B will draw the system tray on the wrong host! Apparently, reading the thread, this does not fear some of the KDE people:

of course this is a bizarre corner case not worth much thought. at least that's what you'll think until you actually run into it yourself (be it because you are testing something or because you are setting up some weird kiosk environment).

What Oswald describes as a corner case is an actual common use case for many of us. Of course, YMMV. From my point of view, this is a step back in the wrong direction. But we can conclude that the network part of X is now worthless, to at least KDE. I used to believe in XCB

When I joined Freedesktop, it was to work on XCB, the X C Binding. XCB is a nice, clean, 21st century technology based API to play with the X11 protocol. Its code is auto generated based on XML file describing the protocol. In comparison, Xlib is 80's obfuscated code with almost no comments and hard-coded things. Only a few people can understand some of its corner like its i18n or XKB implementations. And all its code is synchronous. For people not knowing it yet, X is a network protocol where you send request (like a GET in HTTP) and then get a response. Xlib forces the application to wait for the reply to its request, so the application is blocked until the X server sends the reply to the request. XCB on the other hand does not block and allows the application to send a batch of requests, do some other stuff in the mean time, and then gets the replies. It's like your Web browser would send one request at a time to a Web server, and would wait until you downloaded all the images one by one to display the page. In cases where X and all its clients are on the same host, the latency is small and not really visible, therefore the gain for XCB to be asynchronous is small. On slow network however, the gain can be huge, as proved in the rewrite of xlsclients with XCB by Peter Harris. One of the long standing goal of the XCB folks is to kick-out Xlib, to increase speed and hides latency in X11 applications. That requires to port many libraries, because almost none of them (Cairo being an exception) supports XCB. From where I stand, I don't really see if the work is worth it now. The desktop world is trusted by GNOME and KDE, meaning GTK+ and Qt. It seems none of this toolkits are interested to work on XCB, neither on the X protocol. They probably put hard effort in bypassing X limitation and flaws, and they now sit on top of crap of workarounds and broken-by-design-standard implementation. It seems to me they don't want to go back in the layers and improves things. They're too high to go back down and they don't see what the gain would be. Enlightenment with its EFL was the first toolkit to have an XCB back-end with the work of Vincent Torri. Unfortunately, the back-end is not maintained and nobody cares about it. Last time I tried it, it did not compile at all. X12 ?

There's a page called X12 on the Freedesktop wiki, listing all the things that should be fixed some days. Unfortunately, the list continues to grow up an no one talks about working on X12. On the other hand, there's a handset of people trying to work when they will have time on XKB2, the second version of the "let's-try-to-fix-up-the keyboard-part-of-the-protocol-we-wrote-23-years-ago-a-second-time" extension. To me, it does not seem X12 will happen in the next decade neither. Alternative ?

Do we got alternative to X ? There's Wayland, but it's far from being usable. There's DirectFB, but that's not very portable. None seems candidate to replace X some days to me. Anyhow, none of the main toolkits around support this alternative. GTK+ once supported DirectFB, but as far as I know, it is not supported nor works nowadays, as stated by Josselin Mouette. This is why recent versions of the Debian installer have migrated to X for the graphic part, thanks to Cyril Brulebois work. Conclusion

XCB has been around for more than half-a-decade, and very few people showed interested in it. As far as I can see, nobody is interested to use the X protocol and everybody tries to encapsulate it in some higher-level API as soon as possible to stop seeing it. This leads to poorly written application and toolkits, with a lot of ugly hack. All of that also means that starting to write applications and graphical toolkits based on XCB would be a very interesting project, but that would lead to spend too much time learning to circumvent the X protocol flaws, things that have been done in years by predecessors like Qt and GTK+. Major toolkits implementations have almost nothing to win in going back in the dark water of X. I guess most of their folks prefer to work on shiny 3D effects based on your GPS location, rather than redefining better basis for everyone. The manpower available in the X world is very small. Debian lacking of X maintainers is just the summit of that. There is very smart and very competent and skilled guys in the X world, as you can see by simply reading blog posts on Planet Freedesktop for example (me excluded). Unfortunately, there's not enough of them to cover all the things involved in X: input devices, graphics devices, new protocol extension specification and so on. The X server is really late, and it seems most of the developers prefers to work on the server itself than on the protocol behalf. Which is understandable. I'm curious to see where all of that will lead in the upcoming years. I've been walking in the X world hallways for about 3 years now, and I feel desktop alternatives to KDE and GNOME will all die sooner or later. The time were you could choose between a dozen "modern" window managers has passed away. After all, maybe that is simply Darwinism applied to computer software.

as a short reminder that there are still a few RC bugs waiting to be fixed here's a short list of the ones I've worked on in the last time:

• #571116 debsums: "debsums: overwrites /etc/apt.conf.d/90debsums without asking"
  upload NMU prepared by Giovanni Mascellani to DELAYED/2
• #578458 src:libcoro-perl: "libcoro-perl: FTBFS: E: Caught signal 'Terminated': terminating immediately"
  modify package to get more info (pkg-perl)
• #578638 libpam-ldap: "libpam-ldap: needs versioned dependency on libpam-runtime"
  make dependecy versioned (again), upload to DELAYED/2
• #581194 libpoe-component-irc-perl: "libpoe-component-irc-perl: Insufficient stripping of CR/LF allows arbitrary IRC command execution"
  upload new upstream release (pkg-perl)
• #581327 src:libpoe-component-sslify-perl: "libpoe-component-sslify-perl: FTBFS: tests failed"
  new upstream release + additional dependency (pkg-perl)
• #583351 libtime-y2038-perl: "libtime-y2038-perl: FTBFS"
  adjust build dependency to please sbuild (pkg-perl)
• #583418 src:libnet-z3950-zoom-perl: "libnet-z3950-zoom-perl: FTBFS: Nonexistent build-dependency: libyaz3-dev"
  correct build dependency (pkg-perl)
• #583462 src:libnet-https-any-perl: "libnet-https-any-perl: FTBFS: tests failed"
  fix test suite in debian/rules (pkg-perl)
• #583467 src:libdist-zilla-perl: "libdist-zilla-perl: FTBFS: tests failed"
  upload new upstream version (pkg-perl)
• #583751 src:ufraw: "ufraw-batch: fails to install"
  new RC bug reported

In response to a planet.d.o series (mentioned in #grml on IRC) of postings: In a sensible shell, Esc+# not only pushes it back but also re-enables the command. Try it out: l s Esc # Cursor-Up Esc #

tg@blau:~ $ #ls
tg@blau:~ $ ls

The command sticks in the history, and is not immediately shown in the next interactive input line, which I consider a plus in most use cases. Anyway, try mksh (just a-g i it), there are a lot of goodies. I found out about Ctrl-O only a year or so ago myself I wonder why schizo didn t write about how to do it in posh tho

[107108.433300] chrome[12262]: segfault at bbadbeef ip 0000000000fbea18 sp 00007fffcf348100 error 6 in chrome[400000+27ad000] When I first tried running the Google Chrome web browser [1] on SE Linux it recursively displayed the error message in the above picture, it first displayed the error and then displayed another error while trying to display a web page to describe the error. The kernel message log included messages such as the above message, it seems that some pointers are initialised to the value 0xbbadbeef to make debugging easier and more amusing. V8 error: V8 is no longer usable (v8::V8::AddMessageListener()) When I ran Chrome from the command-line it gave the above error message (which was presumably somewhere in the 8MB ~/.xsession-errors file generated from a few hours of running a KDE4 session). type=AVC msg=audit(1274070733.648:145): avc: denied execmem for pid=12833 comm= chrome scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process
type=SYSCALL msg=audit(1274070733.648:145): arch=c000003e syscall=9 success=no exit=-131938567594024 a0=7fd863b41000 a1=40000 a2=7 a3=32 items=0 ppid=1 pid=12833 auid=4294967295 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001 egid=1001 sgid=1001 fsgid=1001 tty=pts4 ses=4294967295 comm= chrome exe= /opt/google/chrome/chrome subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
type=ANOM_ABEND msg=audit(1274070733.648:146): auid=4294967295 uid=1001 gid=1001 ses=4294967295 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=12833 comm= chrome sig=11 V8 is the Google Javascript system which compiles JavaScript code and thus apparently needs read/write/execute access to memory [2]. In /var/log/audit/audit.log I saw the above messages (which would have been in the kernel message log as displayed by dmesg if I didn t have auditd running). The most relevant parts are that execmem access was requested and that it was by system call 9. From linux/x86_64/syscallent.h in the strace source I discovered that system call 9 on the AMD64 architecture is sys_mmap. Does anyone know a good way to discover which system call has a given number on a particular architecture without reading strace source code? Attempts to strace the Google Chrome process failed, Chrome gave the error Failed to move to new PID namespace after clone() failed. Clone was passed the flag 0 20000000 which according to /usr/include/linux/sched.h is CLONE_NEWPID. It seems that programs which create a new PID namespace (as Google Chrome does) can t be straced as the clone() call fails. It s a pity that Chrome doesn t have an option to run without using this feature, losing the ability to strace it really decreases my ability to find and report bugs in the program I m sure that the Google developers want people like me to be able to help them find bugs in their code without undue effort. Anyway the solution to this problem to allow it to run on the SE Linux Targeted configuration is to run the command chcon -t unconfined_execmem_exec_t /opt/google/chrome/chrome which causes the Chrome browser to run in the domain unconfined_execmem_t which is allowed to do such things. Of course we don t want Chrome processes to run unconfined, I think that the idea I had in 2008 for running Chrome processes in different SE Linux contexts is viable and should be implemented [3]. As a general rule if you are running a program from the command-line on SE Linux with the Targeted configuration (the default and most common configuration) then any time you see an execmem failure logged to the kernel message log or the audit subsystem then you can change the context of the program to unconfined_execmem_exec_t to make the problem go away. Note that this isn t necessarily a good thing to do, sometimes it s best to change the program to not require such access. But it seems that in this case the design of V8 requires write/execute memory access to pre-compile JavaScript code.

• [1] http://www.google.com/chrome
• [2] http://code.google.com/apis/v8/
• [3] http://etbe.coker.com.au/2008/09/02/google-chrome-the-security-implications/

So someone thought it might be a good idea to switch the default from the time-honoured Debian style ("booting foo... ok") to the RedHat style ("<left-align>booting foo... <right-align>[ok]"). I don't think the switch adds any value (it's not like it looked bad or anything in the past); in fact, I think it's a bad idea. And I even have a technical reason. On my 26" 1920x1200 screen (when the i950 driver detects it properly and actually sets the framebuffer to that resolution), the output looks like this: Now imagine you get to see that screen for about two to five seconds. Please tell me which two initscripts failed. And no, you cannot use a ruler. Bonus points for if you manage to do so while the text is also moving upwards, which tends to happen when systems boot. Also note that because kernel mode-settings has become the default, a lot more people are going to be using framebuffers. Am I the only one who thinks this is a bad idea?

If anybody is interested or can attend: Tomorrow and the day after (Wednesday and Thursday 12-13/05/2010) FLACSO (a leading Social Sciences faculty spanning countries all over Latin America) and IFE (Mexico's federal electoral authority) are presenting a seminar on e-voting: Electronic vote experiences in Mexico and around the world. Sadly, I will be unable to attend, as I will be on the road once again (Ecuador!). However, I hope those among my readers who are interested in the topic can attend or at least follow the audio and video transmission from the IFE website. The seminar will be held at IFE's auditorium Viaducto Tlalpan No. 100, Col. Arenal Tepepan, Delegaci n Tlalpan, c.p. 14610, M xico, DF. [update] If you don't know what is my stand on this topic (and can read Spanish), please read this short article. In short: I am against e-voting, and hope we are still in time (and can push at the right places) to avoid it becoming the rule in our country.

Here's why: Zoe Dianne Pollock was born at 12:30pm PDT, at Lucile Packard Children's Hospital, via Caesarean-section. Her birth weight was 2920 grams (6 lbs, 7 oz) and she's 49.5 centimetres (19.5 inches) long. As for why she was born 11 days early than her previously scheduled early arrival... Monday morning started off like any other normal Monday morning. I got up at 6am to go to the gym with Dan. I got home at around 8am. I asked Sarah if she'd felt any baby movement, and she said she hadn't. Even after some jiggling and a cold glass of orange juice, there was nothing. Not wanting a repeat performance of what happened last time, we wasted no time in heading to Labour and Delivery to get things checked out. When we were nearly at the hospital, Sarah felt some small movement, so that was a relief. When we got to the hospital, they performed a non-stress test as they have previously. They spent a good couple of hours with Sarah hooked up to the monitor, and then the on-call obstetrician asked us how we'd feel about just having the baby today. I asked if there was anything particularly concerning about the NST, and the OB said that she (the baby) was doing marvelously now, but was "less than marvelous" when we first came in. I haven't had a chance since to ask her if there was anything untoward observed during the delivery. Anyway, she (the on call OB) said that rather than have Sarah get stressed out for the following 11 days, she'd talked with our regular OB, and they felt that since she was at 37 weeks (and considered "full term") that it was okay to deliver at that point. At the end of the conversation, it was upgraded to a recommendation, rather than an option. So so much for an attempt at VBAC. We got to the hospital at around 9am, and I think they/we made the decision to deliver at about 10:30am. I had enough time to race home and grab the camera and race back again, and the next thing I knew we were all in the operating room, and Zoe was being delivered. It was amazing getting to see the "extraction". They dropped down the sheet that was blocking our view of the action right at the end, and I got to see (and photograph) Zoe's head and whole body being pulled out. She gave out a little cry, and Sarah and I totally lost it with relief. Things were a bit of a blur after that. I got to come over and meet Zoe while they were weighing her and measuring her, and then they bundled her up and let me take her back to Sarah's head-end on the operating table, so Sarah could get a look at her. Sarah handled this C-section better than last time. She didn't get any nausea, but she still got the itching and involuntary shivering, courtesy of the morphine. While they were still putting Sarah's insides back in, Zoe and I went to the nursery, where they put her under a heater for a little while to warm her up a bit. Then it was back to the recovery room to have a proper meeting with Sarah. Once Sarah was ready to move to the maternity ward, Zoe and I again returned to the nursery, where she got her first bath, had her umbilical cord trimmed some more, and her anti-theft device fitted to her umbilical cord clamp. Then it was off to the maternity ward. I think we were all in the maternity ward by 3pm. After a little while, we managed to get bumped to a private room, which was a lot better than the shared room (the other bed was vacant, but just having more space made a big difference), and that's where we've been ever since. I've stayed each night on the roll away bed, helping out with diaper (sorry Aussies, I've been here too long, and dealt with too many babies, I never think of them as "nappies" any more) changes, and burping and other miscellaneous tasks. Monday night was okay. Tuesday was a bit rough. Sarah didn't get any sleep on Monday night, and the anaesthesia totally wore off and she was in a fair bit of pain. She slept better on Tuesday night, and today, the breastfeeding has been going well, and the post-operative pain is well and truly under control. She's lost a bit of weight since delivery (as is to be expected). She was down to 5 lbs 14 oz (2664 grams) at last night's weigh-in, and at tonight's weigh-in she came in at 5 lbs 13 oz (2636 grams). So the weight loss is starting to plateau. We're already supplementing the breastfeeding with syringes of colostrum/milk that Sarah's pumped previously, so I hope the weight loss will have turned around by tomorrow night's weigh-in. The breastfeeding in general is going pretty well as of today. Mum and bub have both mastered the latch. I think it's just a matter of Sarah's milk coming in now. I've brought forward my 7 weeks paternity leave (an excellent benefit Google offers) to start as of Zoe's delivery. Sarah's Mum arrives on the 19th for 4 weeks, which will be great. We expect to be discharged from hospital on Friday. Luckily we were pretty much all ready for this happening a little bit earlier. We had our last baby classes on the weekend. The nursery is ready enough to bring a baby home to, so aside from Sarah's Mum being disappointed that Zoe's going to be a bit older when she first gets to see her, we're all good. The WiFi in the hospital is great. We've already Skyped with both grandmothers and they've had a chance to see Zoe. We've had a steady trickle of visitors, and the whole baby routine is making the time go pretty quickly.

Facebook recently launched the "Like" function, which basically can be embedded into arbitrary web sites. Naively, it does two things:

1. Provide a "Like" button for sharing the web site
2. Show you how many other users like the web site

Sounds good, doesn't it?But now reconsider: even when you don't use the "Like" function, facebook is in fact notified of which web sites you visit!.Encouraging you to "share" content with friends is the hanger for this function. This is what makes web masters install it on their sites: they expect to get some extra traffic from your friends, so they just add it.But whether you like it or not, it basically allows Facebook to track your complete web viewing habits. And it's the target web site that opts in, not the user! Combined with all the personal information Facebook already has on you, this is a major privacy concern. Combining this information might even be illegal in some countries (but probably not in the US where Facebook lives, privacy unfortunately has a low role here).The best workaround currently is to blacklist Facebooks "Like" function using some kind of AdBlock, for example using this element filter:

IFRAME[src^="http://www.facebook.com/plugins/like.php"]

But in general, we should try to make this kind of data aggregation illegal without explicit consent and force Facebook to make this an opt-in feature. Political work needed here ...P.S.: Make sure to check if your AdBlock actually blocks and not just hides. As far as I can tell, WebKit Adblock, including Chromes, only hide ads. Firefoxs AdblockPlus seems to be more powerful.P.P.S.: yes I've read the claim that Facebook doesn't track. No wait, all they basically said was that they are not going to announce at F8 they will be selling web surfing behaviour based ads to their customers. They actually did NOT state (or guarantee) they will NOT use data mining on this data. Just that you probably will not be able to buy eyeballs based on rules such as "has visited/liked disney.com" ...P.P.P.S.: I've been told that facebook.com/widgets/like.php also needs to be blocked, since some sites use this URI scheme. And of course, Privoxy and similar privacy-increasing proxies are a useful addition, too.

my current list of worked on RC bugs; not many for two weeks but I was on vacation for almost a week ...

• #574192 typespeed: "typespeed: package purge (after dependencies removal) fails"
  apply patch for postrm from BTS and upload to DELAYED/2
• #574217 libpdl-netcdf-perl: "libpdl-netcdf-perl: package purge (after dependencies removal) fails"
  fix postrm and upload to DELAYED/2
• #576639 libpath-dispatcher-perl: "Path::Dispatcher::Declarative is now a separate distribution, breaks prophet"
  upload after the split-off package is ACCEPTED (pkg-perl)
• #577861 src:libpadre-plugin-vi-perl: "libpadre-plugin-vi-perl: FTBFS: tests fail"
  rules: run under xvfb (pkg-perl)
• #577890 src:libpadre-plugin-autoformat-perl: "libpadre-plugin-autoformat-perl: FTBFS: tests fail"
  rules: run under xvfb (pkg-perl)
• #577909 src:libpadre-plugin-xml-perl: "libpadre-plugin-xml-perl: FTBFS: tests fail"
  rules: run under xvfb (pkg-perl)

Last Friday and Saturday the second R / Finance conference took place in Chicago on the UIC campus. As a co-organizer, it was a great pleasure to see so many users of R in Finance---from both industry and academia---come to Chicago to discuss and share recent work. There is a lot going on, and it is always good to exchange ideas with others sharing the same infrastructure. Participants appeared to enjoy the conference. My thanks to everybody who helped to put it together, from the local committee to the helping hands at UIC and of course the sponsors. I just put my slides from the Extending and Embedding R with C++ tutorial preceding the conference, as well as the RQuantLib: Interfacing QuantLin from R presentation (with Khanh Nguyen), up onto my presentations page. I do have a usb-drive with all conference presentations and will provide them via the R / Finance site in a few days. The only truly sour note is the fact that several presenters from Europe had their travels schedules turned upside down by the disruption to international air travel caused by the Icelandic volcano eruption and the resulting ash clouds. While we are glad to have had them for a little longer in Chicago, we understand that they are getting eager to return home. I hope this extended stay in the Windy City does not take away from the overall usefulness of the trip.

Account created for myaddress<at>glandium.org with hg_mozilla and mg_mozsrc bits enabled.

Yes, this means I now have commit access on hg.mozilla.org. Thanks to those who vouched for me, namely Justin Wood, Christian Biesinger and Benjamin Smedberg. And thanks to the Mozilla governance for having changed the commit access requirements just in time for me to take advantage of the new ones: under the old rules, it was required that the vouching superreviewer had never reviewed a patch from the person applying for commit access. Of the 31 superreviewers, 14 (almost half of them) already had reviewed one or more patches from me (which is not really unexpected, considering the number of patches I sent in the past). One could wonder why I never applied for access earlier, though.

let's face it After having tamed for a day and a half my INBOX, my IRC log, and my @replies, of an unexpected message flow about the election results, after having being pinged by the -press team to contribute a quote for a very nice and professional press release, after having fired mutt -s "Bits from the (newbie) DPL" debian-devel-announce@lists.debian.org, ... it's time to realize that I've been elected DPL. I still have a bunch of mixed feelings (happiness, fear, responsibility, etc.) to disentangle, but above all I'm really proud of our processes (well I don't mind the result either!). I'm grateful to the other candidates and to all the people that took part in campaigning discussions. As I've observed already, campaigning has been exciting for me. It wouldn't have been so without the courage of all candidates and the inquiries of all contributors. No wonder we have had both the highest percentage of voters of recent years (yes, WAT runs of course helped that), and an absolute number of voters close to that of past "heated" elections. In days in which most of the big players in the distro market are companies (and hence take money-driven decision), I can't be more proud to be a member of a huge volunteer project whose processes are driven by a truly do-ocratic and democratic constitution. See you in a bit. PS 1 in case you wondered, yes, I've fired mutt, but I'm far from having written something in the body of the mail! In the next few hours I'll first distill a personal TODO-list / detailed-plan out of my platform and of the inputs that I've already received. Then I'll finalize my first ever DPL bits to d-d-a. PS 2 In the meantime ... I'll surely be looking for a new "maintainer" for RCBW, any taker? PS 3 shameless plug! The mythical Debian Kilt is being weaved again, and you still have your chance of getting one in time for DebConf10. If you're interested, check out this post by Phil Hands and sign up on the wiki, I'm definitely getting one!

The DPL vote is over. I did not win, apparently. Let me start off by thanking the other candidates for running, and congratulating Stefano for winning. My own results aren't too bad; I beat 'none of the above' by a comfortable margin of almost 10 to 1, and ended up defeating Charles Plessy by a slightly smaller margin. My margin to NOTA was far better than during the previous DPL election that I participated in, though I did end up defeating more than half of the other candidates back then, which I didn't this time around. All in all, not enough to win, but enough to conclude that I might have a chance some other time. Margarita and Stefano were just better candidates this time around. My own vote was:

[ 2 ] Stefano Zacchiroli
[ 1 ] Wouter Verhelst
[ 4 ] Charles Plessy
[ 2 ] Margarita Manterola
[ 3 ] NOTA

If you run, you have to be serious about running, and support yourself. So I did. After that, I wasn't sure that Stefano would do a better job than Margarita (or vice versa), so I put them at the same spot. Finally, I became convinced during campaigning that Charles has a lot to learn still about what lives in the Debian community, and I am of the opinion that feeling the community is a vital requirement for a DPL; so that ruled him out. So why did I not win? Obviously because there were better candidates in the election, but the real question is: why is that the case? What did I do, or what did other candidates do, that meant they fared better than I? One possibility was given on IRC:

< svuorela> ol: and "I'm running because no other runs" is also
not a good way to get votes ...

Which is fair enough; but I did run with the intention of winning, and I did try to make that clear. I'm hoping that worked out okay, which would imply that there could be other reasons. I'd like to know about those. So if you voted, and did not place me on the top spot, I'd very much appreciate learning about your motivations for doing so especially so if you were one of the 39 people who would rather have redone the vote than see me win. Comments on this blog post are welcome, or by private e-mail if you'd rather not see them made public.

It takes a lot to prepare for a big trip if you want to really enjoy it. This time, we re going to Japan, and we bought some stuff to stay connected there. First, there s the new camera: that s a Sony 230. We haven t made a photo trip to see all its capabilities yet, but it looks like an excellent toy so far. You ll see probably more photos on this blog in the future. And there s the new laptop: a Packard-Bell Dot-M/A. Theoretically it s called a netbook, but in practice it has everything a real laptop has. The reason I chose this model is that it features Radeon (X1270) graphics and a 64-bit processor, all in a 11,6" laptop which is one of the cheapest of all. Lots of power in one kilogram for a low price, although the drawback is more cells in the battery. Getting the Dot-M/A to work under Debian I first tried to install lenny on it, and while it worked nicely there are several problems with hardware support.

1. The CPU runs extremely slow; you would think it is an Atom. It takes no less than one minute to boot a minimal installation. This is a very strange issue.
2. Wi-Fi doesn t work, even after installing the firmware.
3. 2D works out of the box, but 3D doesn t: the kernel doesn t recognize the PCI ID.
4. Frequency scaling doesn t work, it always runs at full speed which eats battery at an impressive pace.

Upgrading to squeeze solved the first three issues in a blink. The CPU is now as fast as you can expect from an Athlon 64 @1,2 GHz, there s wifi and 3D. OTOH I was hit by a GStreamer bug when the useless snd_pcsp module was loaded why isn t this thing blacklisted by default? ACPI nightmare CPU frequency scaling is another story. I discovered that the BIOS for such Athlon L110 computers does not expose P-states in the ACPI DSDT table. Which means Linux cannot tell at which frequencies it is supposed to work. However, thanks to the awesome work from a guy named Krists Krilovs and the awesome tutorial from the Gentoo wiki I was able to:

• rip the DSDT table from the CPU that s the easy part;
• disassemble it using Intel tools still easy;
• debug the table, which is written in an arcane language no one understands, and using references to a tutorial that was probably excellent until it disappeared from the intarwebs;
• integrate the P-states for the Athlon L110, basing again on the work of Krists Krilovs who wrote the corresponding ASL code;
• build a custom kernel using it that s the easy, but long part, that s done on a faster computer.

After a reboot, I immediately noticed the fan slowing down. Under GNOME, the CPU was no less than 10 C cooler and the CPU frequency applet started to work. <hrule> The Debian kernel maintainers deliberately chose not to provide support for loading a DSDT table from the initrd. There are very good reasons for this, and anyway it shouldn t be necessary to hack something as awful as that to have power saving support. The question remains: how do we deal with this madness? There needs to be some kind of support out-of-the-box for the Athlon L110, which is otherwise a very nice beast. Could the powernow-k8 module set hard-coded defaults when it detects this CPU model? It would be better than the current situation. Other pieces of the toy Otherwise this laptop is very good hardware. Among other things, I enjoyed:

• the keyboard which is very comfortable for this size;
• the awesome screen, quite small, yet 1366 768 and very bright and sharp;
• the quite fast SATA disk (~60 MB/s);
• the card reader, which makes a useful replacement for a CD drive;
• the webcam that worked out of the box;
• power management that works just as expected too.

There is one minor annoyance: the integrated RealTek Ethernet card is only 100 Mbits/s. With all this performance otherwise, you would have expected Gigabit, but well, not everyone has GigE at home yet.

It s no surprise that information visualization and related fields have been active research topics in the past decade. The widespread availability of large, valuable data sets has created a need for improved tools and techniques for making sense of it. This is highly technical work, requiring expertise in design, mathematics, software and other fields, and there is a vibrant community of professionals and amateurs who experiment and critique the latest methods. In the geeky blogs that I follow, I see more and more amateur interest in visualization. Visualization is starting to take on political significance as well, as evidenced by the appointment of information design pioneer Edward Tufte to a US government advisory panel to help explain economic policy to the American public. A technology is confirmed to be truly and vitally relevant, though, when it enters the mainstream consciousness in the form of humor. In the case of visualization, geeks have been trading funny charts and graphs for many years, but this phenomenon seems to have finally crossed the chasm into popular Internet culture with the advent of the Venn diagram meme. Now, anyone with an elementary education and a drawing program can create their own chuckle-inducing infographics and enjoy their 15 minutes of Twitter fame. Likewise for the X as seen by Y two-dimensional grids, revealing how various (stereotyped) groups perceive each other. This is the future, becoming more evenly distributed by the minute.