Over the next few days, I m looking at the most popular articles from this site and my previous news website during 2008. I ll be doing it in three parts. Popularity is measured by page views from local access logs, but some articles were actually more popular in the months after they were first posted, so it s not completely accurate, but let s be forgiving over the holidays, OK?

January

I must have been writing rubbish because nothing got that popular at the start of the year, but some of my older pages continued to be popular throughout 2008:-

• Online Banking with GNU/Linux, Firefox-based browsers or Free Software (started in 2007) - I really should move that list to another address because I think it s going to be around for a while.
• alt.satellite.tv.europe Frequently Asked Questions (first posted in 2006) - again, could do with a better home.
• Annoying blog comment misfeatures: letter images - until people recognise the limitations of CAPTCHA , this is probably going to be a popular page.

February

• SPI Meeting Wed 27 Feb 1900Z irc.oftc.net/#spi - I think this started my regular meeting announcements, which has been a surprisingly popular series and has expanded into a whole category of SPI articles here.
• The Myth Of Deregulation - this was meant to be a marginal rant. Its popularity (and the subsequent comments - some of which were unpublishable or their authors requested removal) surprised me and so I started writing more about social enterprise, cooperatives-sw member businesses and how they interact with GNU/Linux software and web development.

March

• Annoying Judge Resurrects Software Patents in the UK - notable only for pointing out that Symbian is not a UK company. It was probably news to some software developers, which is probably why it made my popular articles list.
• Debian Project Leader IRC Debate or it might have been Random recent threads from planet debian - for the first part of the year, I m looking at what page spiked on which day, but I posted twice a few days apart, so I can t tell which article on the page was popular.

April

• UK mobile micropublishing choices? - for the trip that motivated that article, I used twitter, but I m actually updating identi.ca over XMPP from my mobile now.
• Better Free Software Organisations? - I ve read the Yunus book mentioned in the comments on the Advogato repost of this article and I ve a review which will appear on this site later. It includes a bit of a flaming of the simplistic and IMO factually-incorrect dismissal of cooperative businesses, so I wonder if it will get a few responses from Yunus-fans.
• Explaining web site improvements: what s important to you? It seems that April was a good time for asking questions: this is a third popular question-based article. The website discussed has now been approved and ordered from TTLLP, but the work is not yet scheduled.

That s the first few months of 2008 done. I ll post the next few months in a couple of days. Hope you re enjoying the holidays if you re having them. I m sure I am

Scenario You are maintaining a debian package with topgit. You have a topgit patch against version k and it is has been merged into upstream version m. You want to "disable" the topgit branch, so that patches are not auto-generated, but you are not brave enough to just

   tg delete feature/foo

You are brave enough to follow the instructions of a random blog post. Checking your patch has really been merged upstream This assumes that you tags upstream/j for version j.

git checkout feature/foo
git diff upstream/k

For each file foo.c modified in the output about, have a look at

git diff upstream/m foo.c

This kindof has to be a manual process, because upstream could easily have modified your patch (e.g. formatting). The semi-destructive way Suppose you really never want to see that topgit branch again.

git update-ref -d refs/topbases/feature/foo
git checkout master
git branch -M feature/foo merged/foo

The non-destructive way. After I worked out the above, I realized that all I had to do was make an explicit list of topgit branches that I wanted exported. One minor trick is that the setting seems to have to go before the include, like this

TG_BRANCHES=debian/bin-makefile debian/libtoolize-lib debian/test-makefile
-include /usr/share/topgit/tg2quilt.mk

Conclusions I'm not really sure which approach is best yet. I'm going to start with the non-destructive one and see how that goes. Updated Madduck points to a third, more sophisticated approach in Debian BTS.

In June 2007, I bought a new 9-cell-battery for my ThinkPad notebook. Since then, I recorded, via a cron job, every five minutes these bits of information:

• time
• design capacity
• reported last full capacity
• state (charging, discharging, charged)
• (dis)charge rate
• remaining capacity.

I had planned to make some detailed analysis of this, but I haven t gotten around to do more than this graph (warning, large), of which the following iis a cut out. Since I now got a new laptop (with a new battery), I ll share my records. I find it interesting that the last-full-state sometimes jumps up, closer to the design state. This could be re-calibration. Or the battery, after a while, re-scales iits output to appear less degraded. This might be checked by comparing the speed of discharge and charge at various points in time.If you want to do some analysis of your own, you can download the raw data (44354 data points). It has been anonymised by starting the time counter at zero, and shortening any gap of more than four hours to four hours. If you want to do some analysis in Haskell, you can take some code from my anonymizer script to parse the data. If you happen to find something interesting, appropriate crediting is appreciated.

In June 2007, I bought a new 9-cell-battery for my ThinkPad notebook. Since then, I recorded, via a cron job, every five minutes these bits of information:

• time
• design capacity
• reported last full capacity
• state (charging, discharging, charged)
• (dis)charge rate
• remaining capacity.

I had planned to make some detailed analysis of this, but I haven t gotten around to do more than this graph (warning, large), of which the following is a cut out. Since I now got a new laptop (with a new battery), I ll share my records. I find it interesting that the last-full-state sometimes jumps up, closer to the design state. This could be re-calibration. Or the battery, after a while, re-scales iits output to appear less degraded. This might be checked by comparing the speed of discharge and charge at various points in time.If you want to do some analysis of your own, you can download the raw data (44354 data points). It has been anonymised by starting the time counter at zero, and shortening any gap of more than four hours to four hours. If you want to do some analysis in Haskell, you can take some code from my anonymizer script to parse the data. If you happen to find something interesting, appropriate crediting is appreciated.

Open and voluntary membership is a point of principle for me, so I see SPI s membership structure as a big plus. As I wrote back in August:

In my opinion, a key difference of Software in the Public Interest is that it is managed by free software developers in a more-or-less democratic fashion. Even though I ve failed in two elections, I still think it s better than the alternatives.

One of the other major free software organisations has moved in the right direction this month, with the announcement that FSFE adds Fellowship representation to General Assembly. It s not perfect - I still disagree with fellowship being conditional on payment instead of effort - but I think getting democratic representation in FSF Europe is a big step forwards for free software developers. If only FSF.org would do that too. One challenge of representation is that members have a responsibility to oversee the organisation. That s a bit difficult if the board adds reports and resolutions to the agenda at the last minute, which happened at the December 2008 meeting. Ian Jackson has asked the board to arrange that all the appropriate notifications are sent and I ask other SPI members (contributing or non-contributing - both seem to be fine for this) to second it. Finally, happy Christmas or whatever other festival you re celebrating (if any).

I use public-key based access for a number of things and gpg-agent is a useful way to avoid having to repeatedly type the passphrases needed to unlock the private-keys. The agent prompts you for the passphrase and then uses the unlocked keys for a user-determined time-period. For a number of reasons it is a "good thing" if this prompting happens in a different interface from that where the key is being used. In an X window environment this is done by the pinentry-gtk avatar of pinentry which pops up a new window. However, I use screen to multiplex operations within a single terminal session, often without an X session. It used to bother me that I could not get pinentry-curses to pop up in a different window. No more ;). Here is a hack that seems to work.

1. Decide on some location like $HOME/.gnupg/pin-tty and assign it to the variable PINTTY.
2. Use the additional options --ttypath $PINTTY, --ttytype screen and --keep-tty for gpg-agent.
3. Start a screen window with the command screen -M -t pin socat -,raw,echo=0 PTY,link=$PINTTY

Now everytime a program asks gpg-agent to use a secret-key, it will invoke pinentry-curses which will connect to the pin window under screen; the latter will warn you (-M) that something is asking for a passphrase. It would be nice if one did not have to invoke socat and screen could do step (3) directly. Is there any way to integrate the use of gpg-agent with openvpn when the latter uses SSL keys? There may be some security issues with such use! I can't see any at the moment but I may be wrong. :-(

Recently much ink has been spilled on the forms of micro-writing (Twitter, Facebook status updates, micro-blogging) that have captivated the hearts, minds, and especially keyboards of those, like me, who spend a lot of time in front of the blue screen (whether a computer or a phone). Lately, perhaps in part because I was home bound for days, I went on a status-update frenzy, updating my Facebook feed like there was no tomorrow and checking in as often to read the short nuggets left by friends. Despite this recent bonanza, I don t admit to all my friends of this addiction as some of them seem to really dislike no the more accurate term is detest this linguistic genre. Generally, it seems to me, there are those that love these messages, and then there are those who disparage them for being inane, short blasts of egotistical information that reflect and worse, reinforce the rampant, raw, unfiltered American love with self, performing the individual, and all that related jazz. I am sympathetic with the haters and at times, I admit I feel nothing but the hate (and perhaps this is why I have yet to Twit) but after thinking about it I have decided I am not really in their camp. Why? Well, something I do when I am thinking through phenomenon is ask: What Would Bakhtin Think (WWBT) as he is a theorist that I adore for he avoids so many of the traps, mostly of binary thinking, that befall most academic theorists. The answer to WWBT, at least from the way I read him, would be that he would dig and find something quite significant about these linguistic ephemera. Bakhtin, who was a Russian literary critic and thinker , thought highly of the novel as a genre for, unlike poetry, it provides a window into everyday life, into the depths and heights of the prosaic, which, however prosaic, is actually where all the extraordinary stuff of life resides. For in the humdrum of life is where he locates wonder, magic, suffering, laughter, mystery, love, oppression, and joy even if its significance often slips right on by our awareness, our perceptual world, until it is unearthed by such genres as the novel (and I would add film). You really can t get more mundane than these micro-statements, though albeit they can be fantastically funny, frustratingly opaque, devilishly satiric, and in rare occasions, poetic; and it is for all these reasons that I find them personally enjoyable and analytically valuable. So much of our life is seeped and steeped in the mundane and yet it is whizzes by us without much reflection. We certainly don t have much of a window into the mundane lives of others, especially in any real time sense. These updates are short pauses, like a temporal parenthesis (which any reader of this blog can I tell I am fond of) or a pleasant hiccup. While many say that they are egotistical blasts, I experience them otherwise, especially when I find myself smiling, laughing, wondering not at what I say but what others throw out there. For with the short update, I am transported, however ephemerally and momentarily, to your mundane world and share in the pleasures of life as is. And for those that remain unconvinced, at least take my word that Bakhtin is worth paying attention to (that is, if you pay attention to academic theory), here is a review essay that might convince you (subscription required but I will try to post a full copy later)

Following a thread on Planet GNOME, I decided to add a few more warning options to my main upstream projects. I started with:
-g -O2 -g2 -Wall -Werror -Wdeclaration-after-statement -Wno-pointer-sign -Wcast-align -Wbad-function-cast -Wmissing-declarations -Winline -Wsign-compare -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wl,--as-needed


I'm adding -Wredundant-decls (which itself has highlighted a bug in QOF 0.7.5, fixed in 0.8.0 SVN). and -Wwrite-strings which caught lots of nasty bugs. (You know the ones, you're confident that a string is newly allocated and needs a g_free but then the program seg.faults in operation and you can't find why?) Also added -Wformat-security, -Wswitch-enum, -Winit-self - the first one to not cause any new errors and -Wmissing-include-dirs (which I'm glad to say raised no errors because it is checking my autotools foo). Test project for this run: pilot-qof. Changes now in CVS (yes, CVS - why not? pilot-qof is stable enough that it doesn't need any of the SVN features that caused migration of other projects).

Later, I'll add the same warnings to QOF and gpe-expenses upstream.

Since I've ranted a little recently lets do another public bugfix. The last few times people seemed to like them, and writing things down helps me keep track of where I am, what I'm doing, and how soon it will be "beer o'clock". So I looked over the release critical bug list, looking for things that might be easy to fix. One bug jumped out at me:

• gnomad2: segfault on start up / vorbis comment headers
• (Original report)

I installed the package:

skx@gold:~$ apt-get install gnomad2
..
The following NEW packages will be installed
  gnomad2 libmtp7 libnjb5 libtagc0
..

Once I copied an .mp3 file to my home directory, with the .ogg suffix I got a segfault on startup:

skx@gold:~$ cp /home/music/Audio/RedDwarf-back-to-reality.mp3 ~/foo.ogg
skx@gold:~$ gnomad2
..
LIBMTP_Get_First_Device: No Devices Attached
PDE device NULL.
TagLib: Ogg::File::packet() -- Could not find the requested packet.
TagLib: Vorbis::File::read() - Could not find the Vorbis comment header.
[segfault]
skx@gold:~$

So I downloaded the source ("apt-get source gnomad2"), and the dependencies for rebuilding ("apt-get build-dep gnomad2"). This allowed me to rebuild it locally:

skx@gold:/tmp/gnomad2-2.9.1$ ./configure --enable-debug && make
skx@gold:/tmp/gnomad2-2.9.1$ cd src/

And now it can be run under GDB.

skx@gold:/tmp/gnomad2-2.9.1/src$ gdb ./gnomad2
GNU gdb 6.8-debian
...
(gdb) run
Starting program: /tmp/gnomad2-2.9.1/src/gnomad2
...
LIBMTP_Get_First_Device: No Devices Attached
PDE device NULL.
[New Thread 0x41dcd950 (LWP 23593)]
TagLib: Ogg::File::packet() -- Could not find the requested packet.
TagLib: Vorbis::File::read() - Could not find the Vorbis comment header.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x41dcd950 (LWP 23593)]
0x00007fc89e0340b0 in taglib_tag_artist () from /usr/lib/libtag_c.so.0
(gdb)

Interestingly the crash comes from a library, libtag_c.so.0. So either:

• The bug is realy in the libtag module.
• The gnomad2 package doesn't handle a failure case it should.

Time to guess which that is. Charitably we'll assume any library that segfaults will be quickly fixed, because it will have more users than a single program.. Moving on we can look at the gnomad2 source for mentions of taglib. Several mentions are found, but src/tagfile.c is clearly the correct place to look. That file contains the following code:

void
get_tag_for_file (metadata_t *meta)
 
  gchar *tmppath = filename_fromutf8(meta->path);
  TagLib_Tag *tag;
  const TagLib_AudioProperties *properties;
  TagLib_File *file = taglib_file_new(tmppath);
  if(file == NULL)  
    g_printf("could not open file %s", tmppath);
    g_free(tmppath);
    return;
   
  g_free(tmppath);
  tag = taglib_file_tag(file);
  properties = taglib_file_audioproperties(file);
  gchar* artist = taglib_tag_artist(tag);
  ..

This looks like a great place to explore because opening a file to read the tags is most likely where the crash is going to be coming from. Interestingly we see the code:

• Calls taglib_file_new to get a handle of some kind relating to the file.
• Tests for errors with that operation.
• Calls taglib_file_tag to fetch tag information using the handle, and indirectly the file.
• But then uses taglib_tag_artist to fetch the artist (?I guess?) without testing the handle previously obtained was valid.

Let us guess that the file opening is succeeding but that the tag structure fetched via taglib_file_tag is NULL - and this causes the crash. A quick edit:

  g_free(tmppath);
  tag = taglib_file_tag(file);
  if(tag == NULL)  
    g_printf("tag was null");
    return;
   
  properties = taglib_file_audioproperties(file);
  gchar* artist = taglib_tag_artist(tag);

Rebuild, and the segfault is gone. We have a winner. Now we just need to file a patch... ObFilm: 300

I wanted to report a success story with topgit which is a rather new patch queue managment extension for git. If that sounds like gibberish to you, this is probably not the blog entry you are looking for. Some time ago I decided to migrate the debian packaging of bibutils to topgit. This is not a very complicated package, with 7 quilt patches applied to upstream source. Since I don't have any experience to go on, I decided to follow Martin 'madduck' Krafft's suggestion for workflow. It all looks a bit complicated (madduck will be the first to agree), but it forced me to think about which patches were intended to go upstream and which were not. At the end of the conversion I had 4 patches that were cleanly based on upstream, and (perhaps most importantly for lazy people like me), I could send them upstream with tg mail. I did that, and a few days later, Chris Putnam sent me a new upstream release incorporating all of those patches. Of course, now I have to package this new upstream release :-). The astute reader might complain that this is more about me developing half-decent workflow, and Chris being a great guy, than about any specific tool. That may be true, but one thing I have discovered since I started using git is that tools that encourage good workflow are very nice. Actually, before I started using git, I didn't even use the word workflow. So I just wanted to give a public thank you to pasky for writing topgit and to madduck for pushing it into debian, and thinking about debian packaging with topgit.

during the ongoing avalanche of posts on Planet and on Debian mailing lists where you ask everyone to be friendly and considerate, you have so far:

• deliberately framed the discussion in a gender-oriented fashion to throw away unjustified accusations of sexism;
• inflated a 85-post long mudslinging thread with my name in the topic (which is the Google version of publicly throwing stones at people);
• vomited on people on an IT news site and helped the site spreading misinformation about the Project;
• shown your own frustration by trying to find hidden sexual references in messages you find offensive;
• and I m probably missing a lot since I m not reading all that crap.

Pretty please. What you mean is Go fuck yourself , but the way you are saying it is no more friendly and actually much more rude. If you meant Go fuck yourself , why not just say it?

• I would have felt better since it s much less insulting.
• You would have felt better since it s really a relief to say it frankly.
• Everyone else would have felt better since this would have ended the discussion instead of polluting the lists with useless wanking.

You are just lying to yourselves if you think your contributions to a flamewar are more friendly than others. As for those starting discussions on the community and on the code of conduct: do you want a community like Ubuntu where everyone can be scornful and prepare lousy tricks, but always preserving the appearances (thanks to a mandatory broomstick), or a community like the Linux kernel, where people say frankly what they think, even if what they think is I hope you were on crack while writing that ? I know which one I choose. I may disagree with their technical development model, but at least they know that a software community is not a group of friends. And that is a sign of maturity.

So my current Apple PowerBook is now 4 years old, and starting to show its age. Some parts of it have been replaced (keyboard, hard disk, bottom cover, and battery), and now it's starting to have issues again. It's not breaking down completely just yet, but seen its age, I might as well start looking for something new rather than having it fixed. I bought this PowerBook because I wanted a laptop that did not have an Intel or AMD processor at its core, which at the time meant either apple or tadpole; since, however, tadpole is only for the rich and famous (seriously well, perhaps being famous is not a requirement), and apple now also only has intel-based laptops, I guess I'm stuck with intel stuff. Besides, a 1.2Ghz SPARC is slower than my current 1.3Ghz PowerPC. So, dear lazyweb, I'd appreciate any suggestions about good laptops. What 'good' means, in my eyes, is the following:

• Long battery life. And I mean long. My current laptop has 4 hours on a new battery, which is not really short, but I find that to be somewhat unsatisfactory.
• Good Linux support. The days when I used to enjoy fiddling with software configuration for three months until everything works just about right are over. I'd prefer to buy, install Debian, and be there 99% of the way.
• A wireless chipset that does not require ndiswrapper, binary kernel blobs, or similar kludges. This is really part of the previous item, but important enough that I thought I'd mention it.
• Bluetooth. I guess this is somewhat standard these days, but one can't be too careful.
• No nvidia. I don't want to have to deal with their braindamage again.
• A full-sized keyboard. That is, it doesn't have to be a 17" laptop with numeric keypad and everything, but I do not want smaller keys than normal. I'll be using this laptop as my main workstation for several years to come and I do not like the prospect of developing RSI, so it had better have a good keyboard.
• Durable. As my business partner likes to say: "wouter is an expert in breaking laptops". Obviously I don't do that on purpose, but a laptop that is to be my laptop ought to be able to survive a few bumps here and there.

I guess the above list is quite long, and realize that my ideal laptop might just not exist; but hey, it never hurts to try, right? If it does not come preloaded with Windows, that's a plus; but OTOH, wiping a hard disk is not hard. I should also note that I'm not really interested in the low-price laptops that are available everywhere these days. Those usually have much lower performance, too small a screen, and other cutbacks that make the laptop be less than interesting for me. This is for work, not play.

Yes, it's that time of the year again... it's almost Christmas, which means that I once again updated my 10 + 100 Creative Commons Christmas Songs blog article I originally wrote in 2005. That's a collection of a lot of freely downloadable, Creative Commons licensed Christmas music. Some of the older entries in the list are no longer available unfortunately, some only needed a URL update, and I also added more than 30 new songs this year. This currently makes a total of 256 CC Christmas songs (more will probably be added over the next few days), so head over to the full song list and get those downloads started... (Photo: Wikipedia. Author: Malene Thyssen. License: GFDL 1.2 / CC-BY-SA 2.5)

Seriously. It reads more like a worked example, without enough of the underlying theory. It doesn't help that I have a slightly more complicated situation, in that I have a filesystem on a logical volume that spans 6 physical volumes. So maybe writing all of this down will help... I know the disk with the problem: /dev/sdc I know the LBA of the sector where the rot starts: 754238963 I know that the physical volume is on /dev/sdc1 and that the partition starts at sector 63 (via sfdisk -luS /dev/sdc) Therefore, within /dev/sdc1, we're talking about block number 754238899 (754238963 - 64) I know the physical extent size is 4096 Kb (via pvdisplay -c /dev/sdc1 awk -F: ' print $8 '). In LBA block size this becomes 8192 (2 x 4096) I know the physical extents start 192K (into the partition, presumably) (via pvs -o+pe_start /dev/sdc1) This is where the Bad block HOWTO starts to quicken the pace a bit on me... I'm supposed to take the physical partition's bad block number (754238899) and divide it by the size of the physical extent (in LBA block size) (8192). So that'd be 92070. This is where I think I end up completely departing the HOWTO, because my filesystem spans multiple physical volumes. Here's my general musings... lvdisplay --maps /dev/data/srv tells me this about /dev/sdc1:

  Logical extent 272326 to 391559:
    Type                linear
    Physical volume     /dev/sdc1
    Physical extents    0 to 119233

So I'm inferring from this, given that I know I want physical extent 92070 of this device, that this corresponds to logical extent 92103 (again, I'm expressing this in LBA block size, so that's (272326 / 8192) + 92070 So now I supposedly know the logical extent (in LBA size) of the bad block. Now what? I think I'm wandering up too many layers, closer to the physical filesystem, but I'll continue wandering around... So presumably at this point, I just want to convert the logical extent to an actual filesystem block number. Maybe the logical extent number divided by the extent filesystem block size divided by the LBA block size? 92070 / (4096 / 512) = 11508. That feels awfully low though. The dd test suggests this is incorrect. At this point I'm feeling fairly lost. If someone out there is reading this, and they've done this before, I'd love to hear from you.

So it turns out if you wait long enough, you do get to piece the information together:

.
.
.
Too many illegal blocks in inode 209158151.
Clear inode? yes
Restarting e2fsck from the beginning...
/srv contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Entry 'denemo_0.7.7-3.1_hppa.deb' in /debian/pool/main/d/denemo (211845291) has deleted/unused inode 209158151.  Clear? yes
.
.
.

I'm watching paint dry while e2fsck does its thing on a ~2TB filesystem (the one with all the good stuff on it on mirror.linux.org.au). I'd seen a spate of kernel errors during the week about "attempt to access beyond end of device" so I figured it was due for one. Let's take this output for example:

apollock@disco:~$ sudo e2fsck -y /dev/data/srv
e2fsck 1.40-WIP (14-Nov-2006)
/srv contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Inode 209158151 has illegal block(s).  Clear? yes
Illegal block #12 (1620503259) in inode 209158151.  CLEARED.
Illegal block #13 (2992116621) in inode 209158151.  CLEARED.
Illegal block #14 (1657577172) in inode 209158151.  CLEARED.
Illegal block #15 (1168774619) in inode 209158151.  CLEARED.
Illegal block #16 (993415032) in inode 209158151.  CLEARED.
Illegal block #18 (1611893880) in inode 209158151.  CLEARED.
Illegal block #20 (2939071693) in inode 209158151.  CLEARED.
Illegal block #21 (1714919190) in inode 209158151.  CLEARED.
Illegal block #22 (1450852455) in inode 209158151.  CLEARED.
Illegal block #23 (3482149179) in inode 209158151.  CLEARED.
Illegal block #24 (4143923374) in inode 209158151.  CLEARED.
Too many illegal blocks in inode 209158151.
Clear inode? yes
Restarting e2fsck from the beginning...
/srv contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
.
.
.

How much more work would it be to tell the administrator the name of the file associated with inode 209158151? That'd be a lot more useful to most mere mortals than the inode number. I suppose if the filesystem is in a really bad state, ascertaining that information may be difficult... Time to play with debugfs while I continue watching paint dry...

Mike Hommey took some inefficient shell scripting to task. I feel obligated to point out that more $file wc awk ' print $1 ' is not the same as wc -l $file. To get the same output, you're going to need one of:

cat $file   wc -l

or

wc -l $file   awk ' print $1 '

I suspect cat is going to have a faster startup time than awk... (On my system, gawk is an order of magnitude bigger than cat)

Dear Julien, that proposal is not about censoring mails sent in by people. Think to it as that "karma" thing many sites have. And yes, I'm one of those in favour of such project. I'm a free software,speech guy, but just hate all the flames seen lately on -devel. We must find a way to stop that, or at least to control it. Again, it's not censorship, as I read it, all messages would go in. Citing:

I have also seen opinions that other "obvious" ways of addressing the issue,
such as moderation of the lists or a new organizational entity, which
would act as a list watchdog, is not the way to go, as it adds yet
another layer of bureacracy and raises the usual questions of choosing
the "right" people for the privileged position.

It's just an alternative way of expressing opinions about a mail. Consider it as those "+1"/"-1" mails that you can often see.

I have been positively surprised to find out that some people are taking seriously the fact that some people are being put off from actively participating in Debian s discussions because doing so would lead to offensive behaviour and personal attacks, and to try to find a solution to the fact that a very vocal minority is dominating the silent majority. Of course, some people are happy with the statu quo and strongly opposes to changing anything in that direction, not very surprisingly. The part about I m really starting to think that this Project could do a lot better without some people is crystal clear and needs no comments. I m not really sure that the current social environment can be fixed just with technical measures. Another proposal talks about some mailing lists extracted from the official ones but with the offending comments filtered out. I must confess that I find this idea very interesting and that I might think about rejoining such a list. Of course, technical details on how to properly and effectively implement any of this methods, or even a mixed one, can be very tricky.