You can now try the “Nouveau” free software nVidia video drivers from Debian experimental. If you would like to try them:

• Ensure you are using Debian sid.
• Add experimental sources to your /etc/apt/sources.list.
• Run:
  • sudo apt-get update
  • sudo m-a update
  • sudo m-a a-i drm
  • sudo apt-get install xserver-xorg-video-nouveau
• Edit your /etc/X11/xorg.conf and specify the nouveau driver in the Device section.
• Restart X. You will need to remove the binary nvidia kernel module.

Editing your xorg.conf may be as simple as the replacing nvidia or nv with nouveau; nouveau won’t be chosen automatically over nv yet. If your xorg.conf has collected a lot of cruft over the years, see this wiki page for some pointers on what you can remove. For the status of the drivers with your particular card, please see upstream’s compatibility matrix. My experience has been positive; I have been using them for about two months on my dual-head 8600GT (NV50) setup with only a few small issues and a generally superior Gnometris experience. Some notes:

• If you find bugs (unrelated to the packaging), please report the problem upstream and not in the Debian bug tracker.
• At request of upstream, we are not providing 3D support. Please do not ask for it, as a wontfix tag often offends.
• Bonus points are awarded for removing the non-free nVidia driver; although installation of xserver-xorg-video-nouveau will remove nvidia-glx, purging nvidia-kernel-common and nvidia-kernel-source should remove all the module-assistant generated kernel modules. rms would be proud.

Many thanks to:

• Matthew Johnson (mjj29) for uploading.
• Julien Cristau (jcristau) for advice.
• Christopher Halse Rogers (ROAF) for his Ubuntu packages.
• The rest of the XStrikeForce, who do rather a lot of work you don’t really notice.

I love Zotero and now with this new news, my love, I think, will just grow.

Autobuilder Summary:
138 packages built successfully. 19 packages failed to cross build. 2 packages are tagged for a manual upload. (Dependency issues - rather than break the archive, these packages will not be uploaded until relevant dependencies have been fixed and uploaded.)
Stats
87% built OK
12% failed
Notes:

1. All these packages built previously and fail at the latest versions in Debian Sid. Many could be upstream errors. All exist in Emdebian at
   previous versions (only 1 failure is known to contain bugs in the current versions in Emdebian and this only affects GUI installations. Two other GUI packages contains bugs but build OK.).
2. Some of the packages in the repository (including some of the failures) are not used in *any* of the default emsandbox configurations. Two need to be removed from the repository completely.
3. Some fixes are waiting for updates in Debian, either new uploads migrating to mirrors or pending fixes awaiting upload by me. (Probably tomorrow.)
4. The history of each package is now available via the Emdebian Autobuilder Report. The package name links to the history of previous build attempts for this package. The version string links to the repository data for the current version in Emdebian. The result of the build links to the build log.
5. A comparison with Debian unstable is constantly updated.
6. 254 source packages exist in Emdebian but only 137 are currently built by the autobuilder. The rest will be built when new versions are uploaded to Debian (in some cases, that won't be until after Lenny). If I get time, I'll add build logs for these packages.
7. The repository contains a fair number of packages that we don't currently use. This is a reflection of the problems of determining the "path" through the dependencies when starting at the bottom (glibc uClibc etc.). Bear this in mind when considering new architectures and new package sets. The process involves a lot of trial and error, particularly as cross-building potentially alters the dependency path at each iteration.

Problems

1. libselinux and libsepol have just been uploaded with a bug fix that is needed for e2fsprogs and file cross-builds, amongst others. Waiting
   for the ARM mirror to receive the new builds, hopefully tomorrow.
2. gtk+2.0 fails to cross-build because the patches now try to build the udeb which comes up against a bug in dpkg-cross. I'll be uploading the new version (including a couple of other bug fixes) tonight. (Final testing currently in progress.). The Gtk package also needs some work to run /usr/lib/libgtk2.0-0/update-gdkpixbuf-loaders so that the icons can be read in the GUI.
3. pango1.0 also needs a fix to update the pango modules. This is usually done at build time but it means running a cross-built binary. It is a minor task and not CPU intensive so I plan to do this in postinst. Without this fix, no text is rendered in the GUI, only empty glyphs.
4. xfonts-base is way too large still. More work is needed here to optimise just what is meant by the 'fixed' font for X, precisely which font files can be removed, which might be needed outside C or English locales etc.
5. Other packages not currently cross-building include: (NOTE: Some of these build logs are VERY large.)
   • adduser - needs to be removed from the repository, it is perl and we implement it via busybox.
   • cups cupsys - /usr/include/pthread.h:653: warning: '__regparm__' attribute directive ignored.
   • gcc-4.2 - needs to be removed from the repository, it no longer builds libgcc1 which was the main reason for cross-building it.
   • glib2.0 - more generated content: /bin/sh: line 2: /usr/bin/glib-genmarshal: No such file or directory
   • gnomevfs - hasn't built for ages and isn't usable anyway due to dependency issues. Currently preventing the use of gpe-filemanager. Due to be replaced by GIO in Debian.
   • libusb - build failure, so far resistant to usual fixes.
   • ncurses - build failure - uses gcc in wide char support build.
   • ntp - build failure - assembly error. authkeys.c:445: error: invalid 'asm': invalid operand for code 'w'
   • pcre3 - build failure - apparently simply unresolved symbols resistant to usual fixes.
   
   
   • slang2 - possibly needs a patch update, tries to build -pic archives and then fails.
   • xorg-server - build failure: make[4]: *** No rule to make target -L/usr/arm-linux-gnu/lib', needed by Xprt'. Stop.

Of the problems above, only problems 2, 3 and 4 (gtk, pango and xfonts-base) are "critical" as these are the only ones where the current packages are sufficiently broken that the new version is essential before Emdebian can make a "release" of a series of three root filesystems for ARM. Sizes are still larger than desired - a fix for that requires changes in glibc which I hope to investigate during DebConf.

Any help on the above issues is appreciated.

Problem-solving:
$ emsource -c $package
$ cd /path/to/$package
$ emdebuild

If you have SVN access, use 'emdebuild --svn-only' to commit your changes (even if your changes don't solve all the problems).

Without SVN access, post the result of 'svn diff ../emdebian*' to this list (or 'svn diff ../debian*' if you have added a patch for the upstream code to debian/patches/).

Platforms:
All the above is based solely on Emdebian ARM for balloon3:
Linux balloon 2.6.25.2-pxa270 #1 Sun May 18 22:38:11 BST 2008 armv5tel unknown
balloon3 in CUED case
http://balloonboard.org/gallery/300/balloon3-0v1-fpga.jpg

AFAICT no other ARM platforms have been tested.

I have a few fixes for the balloon3-config package that also needs an update in Emdebian - I've had some feedback from the touchscreen driver
upstream that we might be trying to use the wrong device (/dev/input/mice is the wrong target for the symlink, we can set whatever device we want in /etc/X11/xorg.conf and the driver will use that in preference to /dev/event0). As this is device-specific, /etc/X11/xorg.conf will be put into balloon3-config which is available via Emdebian SVN.

Looking through mail logs. After 7 days or so of spamassassin churning, I've managed to process about 20 days of e-mail and caught up to email since 5 days ago. Looking at some bugs to see if something is urgent.

'churro' is the name of the Debian i18n server (i18n.debian.net), hosted by the Extremadura region in Merida (IIRC). That server was setup back in september 2006, during the first Extremadura i18n meeting. Since then, a lot of hidden work happened on it, mostly moving all scripts that build statistics pages from Debian localization data, for instance the Central Debian translation statistics. Thomas Huriaux, then Nicolas Fran ois, have been the people building all this, with the help of Felipe Augusto van de Wiel for the system administration. Churro for instance has neat statistics pages, built by Nicolas Fran ois. These would just need to be packaged with nice web pages to give a great website for stats junkies(See that example showing how Swedish decreased over time, then revived recently....or that other one showing German reaching the 100% Grail). The DDTP also uses churro as server which is an important brick for having translated package descriptions (which is now an achieved lenny release goal). And now, since this week-end, I think we can say that Pootle is partly in production. The Pootle server is now hooked directly to the VCS of some parts of Debian-Installer related packages (including the core D-I itself) and, since last night, I am not the only one using it...:-) That small bit:

Author: pootle-guest
Date: Sun Jul 13 20:48:15 2008
New Revision: 54294
Log:
Commit from Debian/Pootle l10n server by user pi. 413 of 413 messages translated (0 fuzzy).
Modified:
   trunk/packages/po/sublevel3/eu.po

... indeed shows that Piarres Beobide Ega a, the Basque team coordinator, just committed an update to D-I SVN, through Pootle. We're still working on organizing all that scattered stuff, to finally turn churro into the central point for Debian localization and internationalization work but I think that the i18n team can really be proud of the achieved work, already. PS: as churro turned out to be hard to pronounce for German mouths, please note that it is also called 'spaetzle' :-)

I have just uploaded new SE Linux policy packages for Debian/Unstable which will go into Lenny (provided that the FTP masters approve the new packages in time). The big change is that there are no longer separate packages for strict and targeted policies. There is now a package named selinux-policy-default which has the features of both strict and targeted. When you install it you get the features of targeted. If you want the strict features then you need to run the following commands as root: semanage login -m -s user_u __default__
semanage login -m -s root root Then you can logout and login and you get the main benefit of the strict policy (users being constrained). IE you can convert from targeted to strict without a reboot! The above only changes the access for user login sessions (and cron jobs). To fully convert to the strict policy you need to remove the unconfined module with the command “semodule -r unconfined“, currently that results in a system that doesn’t boot - I’m working on this and will have it fixed before Lenny. Also it’s possible to have some users unconfined and some restricted in the way that strict policy always did. When running in the full strict configuration you need to run the command “newrole -r sysadm_r” immediately after logging in as root. When you login you default to staff_r which doesn’t give you the access needed to perform routine sys-admin tasks. Due to the change in the function of the policy packages (in terms of not having a strict package) it made sense to revise the naming (Fedora 9 has a package named selinux-policy-targeted which also provides the strict configuration - I don’t want to do that and don’t have as much legacy as Fedora). This is why I decided to not have package names that include the word “policy” twice. Of course all policy packages get new names, but the ones that matter needed new names anyway. Another new feature is the package selinux-policy-mls, as the name suggests this implements Multi Level Security [1]. I don’t expect that the MLS policy will boot in enforcing mode in a regular configuration at this time (you could probably hack it to boot in permissive mode and switch to enforcing mode just before it starts networking). I uploaded it in this state so that people can start testing it (there is a lot of testing that you can do in permissive mode) and so that it can get added to the package list in time for Lenny. I expect that I’ll have it booting shortly (it should not be much more difficult than getting the strict configuration booting). In terms of the use of MLS, I don’t expect that anyone will want to pay the money needed for LSPP [2] certification. NB The wikipedia page about LSPP really needs some work. I believe that the main benefit for having MLS in Debian is for the use of students. I periodically get requests from students for advice on how to get a job related to military computer security. Probably the best advice I can offer is to visit the career section of an agency from your government that works on computer security issues, for US readers the NSA careers page is here [3]. The second best advice I can offer is to work on MLS support in your favourite free OS. Not only will you learn about technology that is used in military systems but you will also learn a lot about how your OS works as MLS breaks things. ;) Finally I’d like to thank Manoj for all his work. For a while I didn’t have time to do much work on SE Linux and he did a lot of good work. Recently he seems to have been busy on other things and I’ve had a little more time so I’m taking over some of it.

• [1] http://en.wikipedia.org/wiki/Multilevel_security


• [2] http://en.wikipedia.org/wiki/Labeled_Security_Protection_Profile


• [3] http://www.nsa.gov/careers/

Share This

The following is not a joke:

• KDE4 needs java for best performance

more precise, soprano, used by nepomuk (semantic desktop thingie), has a sesame backend (java) and a redland backend (c++). According to upstream and others, the sesame backend is way faster than the redland backend. In the soprano svn dir (and in the pristine tarball), there are a few jars put in precompiled:

• openrdf-sesame-2.1.2-onejar.jar
• slf4j-api-1.5.2.jar
• slf4j-simple-1.5.2.jar

This isn’t completely beautiful, but as they all are bsd licensed, it is at least legal.
But it isn’t good enough for debian, as we ship sources and build them. (I think I have heard at least fedora mumble something similar)
The two last jar files, the slf4j ones, are available packaged in debian in the libslf4j-java package. but openrdf-sesame is not available. If some persons out there has java knowledge, debian packaging knowledge, preferably knowledge of debian java policy and some spare time, packaging openrdf-sesame would be much apprecaited. And after that, getting the soprano sesame backend built is next goal. Thanks in advance. applications welcome.

Subbiah Arunachalam forwarded a link to an interview of Professor P. Balaram regarding Open Archives. (Balaram is currently the director of the Indian Institute of Science, Bangalore so he is in a position to influence national policy in such matters). I broadly agreed with his views and I posted a comment which I am reproducing here. Primarily, there are differences between different disciplines. The quotes below are from the interview.

If I publish a paper in Nature, for example, it can be made freely available in my institute's repository after six months. Some journals let archived papers be made available immediately.

... and again later ...

But many publishers have no problem with the open archives approach, even if some still require a delay.

In our discussions with Elsevier we were assured that the policy of that publisher is to allow authors to use institutional repositories at any time (but see the caveats below).

One issue that is yet to be resolved, however, is copyright. I argue that we should be permitted to put in the repository the full text article as it appears in a journal.

There is a difference between "full text" and "as it appears in the journal". If the journal has put in any effort at all into re-formatting your text/images in order to get it to conform with their journal standard, then the copyright for that re-formatting work (usually a combination of manual labour and software) belongs to the journal. For example, Elsevier insists that you do not put the PDF (or other) image file of the exact form of the journal publication in your institute repository. I personally find this quite acceptable since papers in the Mathematical Sciences are perfectly readable in the form in which the authors submit them to the journal. However, re-creating a distributable PDF or other online form of one's paper may be far more difficult in other disciplines --- I have no idea.

For this, countries such as India should have a law specifying that the copyright for articles published with publicly-funded research always vests with the authors and their institutions.

One need not wait for copyright law to change. The directors of each of the research institutes can insist that every paper sent for publication should be made available in the form of a research report with the institute library. By extension, the electronic form of this report would be in the institutional repository. One way to ensure compliance is to only allow reports that are available in the institute library to be used for evaluation (for promotions and the like). The scientists would then refrain from giving up all copyright to their publishers. In my (limited) experience, publishers will not object to authors retaining the right to make copies as long as such copies are not independently sold. Unfortunately, scientists as "the silent compliant mob" does not fit with my experience. In all matters which relate to science administration (and publications are at the centre of that), scientists are by-and-large "status quo"-ists. It will need a strong push from those at the top of the ladder to change the status quo. Professor P. Balaram is certainly one of those at "the top of the ladder" so I would like to see more action to match his words! Update: Fixed the URL thanks to Abhishek Dasgupta. Also clarified the last sentence.

Autism Vox has a post about the recent autism defense for Han Reiser's case. It will be interesting to see play out (and I am as baffled as she is about the Duckbill Platypus. Is it just supposed to be a stand-in for strange?)

So recently there have been a few posts by people discussing the idea of distributed bug reporting systems. This is topical, becuse I've been working on something vaguely related - a support system. Why is a support system, or ticketing system, related to a bug tracker? To answer that you must first clarify what you mean by a support system (or a bug tracker for that matter). There are two distinct types of support systems:

"Full"

This is a system which does "everything". Each submitted support, or bug, request has an associated status, severity, priority and work log. It might be assigned to multiple people through its lifetime, and it might be moved around various internal queues. Example: Request Tracker.

"Minimal"

A reported ticket is an email submission. A "ticket" from start to finish is nothing more than a collection of mails upon a particular topic - there is no assigned "owner", no "priority", no object-specific attributes at all.

I've neither the time, patience, or desire to create any system like the first one. But I've become increasingly dissatisfied with my current support system, roundup, for various reasons. So I need something new. Previously I ruled out several support systems and most of my objections still stand, although I admit I've not really looked again. I will certainly do so shortly. So what have I done? Well I figure I care very little about queues, priorities, reports, and all that stuff. (On the basis that priority is mostly in the ticket itself, and that I'm the sole recipient of the submissions. Previously I had a partner to share them, but these days just me.) I want something that is basically e-mail centric. That reduces the functionality of my support system to two distinct parts:

Ticket Submission

An email to sumbit@example.com should result in three actions:

• A message being sent back to the submitter. "Hey got your ticket. We'll fix it. Love you long time.". (Set the reply-to address appropriately!)
• A message to the site admin(s) saying "Hey, you've got a new ticket submission. Deal."
• A new ticket being created/stored somewhere.

(There are additional nice things to have - such as SMS alerts outside 10:00-17:00, etc, but those are trivial bolt-ons.)

Ticket Updates

When a mail comes in to "ticket-XXXX@example.org" - which was setup in the submission process, or when a mail arrives with subject "[issueXXXX]" we need to append the correspondance to the existing ticket. If that ticket doesn't exist we report an error. If the ticket is closed we re-open it.

So, what do we have? A script that is conceptually simple, and can be invoked via a pipe transport of Exim4. A script that just reads the submitted email from STDIN and only has to decide a couple of things based pretty much on the contents of the "To:" and "Subject:" headers. Simple, no? OK it was actually amazingly simple once broken down. The amazing part is that it all works. I figured that I'd manage new tickets by writing them to mbox files - simple to do. Simple to understand. So the process goes:

• New email arrives to "submit@example.org"
• /home/steve/tickets/1 is created with the received message written to it.
• I get a mail to steve@steve.example.org.uk saying "new ticket!!!".
• I reply to the ticket by opening /home/steve/tickets/1 in mutt - where my muttrc ensures that when I reply the from address is the ticket address, and there is an automatic CC.
• The cycle turns, and more discussion happens until we're all happy the ticket is "done"..
• A mail to ticket-xxxx-done@example.org" closes the ticket by moving it from ~/tickets/ to ~/tickets/archived/.

There are a couple of helper scripts:

• ticket-close - close a ticket manually.
• ticket-list - show all open tickets
• ticket-view - open a ticket in mutt

But basically one script and mutt does it all. So far it's been tested and it is rockin'! (Look at me, hangin' with the cool kids!) Obviously it is pretty Steve-specific, and there is only a toy CGI process for viewing history online, but I'm actually feeling pretty good about it. Once I've closed all my existing tickets I will probably migrate over to it. At least this handles (read: ignores) MIME - which makes it a clear winner of roundup, which just eats, bounces, or corrupts submitted multipart messages. ObQuote: Flash Gordon

Yay! I just handed in my Diploma thesis in Computer Science (approx. Masters degree). It will still be some weeks until it has been graded, the dean has signed the diploma etc., but I'm pretty much done.The topic of my thesis is

Statistical Approaches for Robustifying Correlation Clustering Algorithms

so my field of research is Data Mining, in particular Data Clustering and Outlier Detection. My particular contribution is to improve the accuracy of PCA results in the presence of noise.Some ideas of the thesis are also just being published at the 20th International Conference on Scientific and Statistical Database Management (SSDBM) July 9-11, 2008, Hong Kong, China and the associated proceedings (Springer LNCS volume 5069):

Hans-Peter Kriegel, Peer Kröger, Erich Schubert and Arthur Zimek. A General Framework for Increasing the Robustness of PCA-based Correlation Clustering Algorithms

Other related publications will follow (an outlier detection method using parts of my thesis will be submitted to a journal soon, too). And in case the first name on that list rings a bell: he did some major contributions to multi-dimensional data structures such as the R*-Tree, X-Tree and Buddy Tree, and has since been very active in data mining.I'll be giving a short talk at the graduate seminar next week, and I'll probably publish the slides on my web page. But they will only be a short excerpt of my work due to time limitations of the talk.So basically, I'm jobless now! :-)I still have plenty of related ideas to continue research, and my advisor asked me if I'd like to continue with a PhD degree (so you can assume the grade of the thesis won't be too bad). However, the university is always short on open positions, and I don't know if I'll be able to get one (a research proposal is pending). Therefore, I'm looking for a position that allows be to pursue data mining and/or clustering research. Part time jobs are fine if they are well enough paid, although it of course would be best if the job would just include related research. If the job is located outside of Munich, a contact to a local university with a strong data mining research group is needed. (In Munich I obviously already have contacts to a strong research group.)As you might figure from me posting on Planet Debian, Planet GNOME and similar, I'm fairly experienced in OpenSource and Linux (something like 19 years of programming experience, 13 years of Linux experience). So I'm not just a fresh graduate, but a doer when it comes to coding. (Which is partially why I'd prefer a job outside of the university!)Anyone with interesting job offers (Google Munich anyone? I've been trying to get a back channel contact with you for weeks), please just drop me an email at erich AT debian DOT org.P.S. No, that doesn't mean I'm only looking for jobs in the data mining field. It would just be more convenient.

So, I have noticed and it has been brought to my attention that my entries are only partially displayed. I have checked my settings in Word Press, they are set to display my entire entries. Is there some other aspect of WP, feed burner or my RSS address that could ...

Does a GPG pass-phrase provide a real benefit to the majority of users? It seems that there will be the following categories of attack which result in stealing the secret-key data:

1. User-space compromise of account (EG exploiting a bug in a web browser or IRC client).
   
2. System compromise (EG compromising a local account and exploiting a kernel vulnerability to get root access).
   
3. Theft of the computer system while powered down when the system was configured to not use swap or to encrypt the swap space with a random key at boot time.


4. Theft of a computer system while running or that did not have encrypted swap.


5. Theft of unencrypted backup media.

Category 1 will permit an attacker to monitor user processes and intercept one that asks for a GPG pass-phrase as well as to copy the secret key. Category 2 will do the same but for all users on the system. Category 3 will give the potential for stealing the private key (if it’s not encrypted) but no direct potential for getting the pass-phrase. Category 4 has the potential for copying a pass-phrase from memory or swap. I am inclined to trust Werner Koch (and anyone else who submitted code to the GPG project) to have written code to correctly lock memory and scrub pass-phrase data and decrypted private key data from memory after use. But I really doubt the ability of most people who write code to interface with GPG to do the same. So every time that a GUI program prompts for a GPG pass-phrase I think that there is the potential for it to be stored in swap or to remain indefinitely in RAM. Therefore stealing a machine that does not have it’s swap-space encrypted with a random key (which is the most practical way of encrypting swap) or stealing a running machine (as mentioned in a previous post [1]) can potentially grant a hostile party access to the pass-phrase. So it seems to me that out of all the possible ways of getting access to a GPG private key, the only ones where a pass-phrase ones is going to really do some good are categories 3 and 5. While it’s good to protect against those situations, it seems to me that the greatest risk to a GPG key is from category 1, with category 2 following close behind. I previously wrote about the slow progress towards using SE Linux and GPG code changes to make it more difficult to steal the secret key [2] - something that I’ve been occasionally working on over the last 6 years. Now it seems to me that the same benefits can and should be made available to people who don’t use SE Linux. If a system directory such as /var/spool/gpg was mode 1770 then gpg could be setgid to group “gpg” so that it could create and access secret keys for users under /var/spool/gpg while the users in question could not directly access them. Then the sys-admin would be responsible for backing up GPG keys. Of course it would probably be ideal to have an option as to whether a new secret key would be created in the system spool or in the user home directory, and migrating the key from the user home directory to the system spool would be supported (but not migrating it back). This would mean that an attacker who compromised a local user account (maybe through a vulnerability in a web browser or MUA) would not be able to get the GPG secret key. They could probably get the pass-phrase by ptracing the MUA (or some other GUI process that calls GPG) but without the secret key itself that would not do as much good - of course once they had the pass-phrase and local access they could use the machine so sign and decrypt data which would still be a bad thing. But it would not have the same scope as stealing the secret key and the pass-phrase. I look forward to reading comments on this post.

• [1] http://etbe.coker.com.au/2008/02/17/hot-plug-and-how-to-defeat-it/


• [2] http://etbe.coker.com.au/2008/06/06/se-linux-support-gpg/

Share This

Some time ago, I added a
Spammers Hall of Shame to my first website, codehelp.co.uk.

"... sites that send me unsolicited commercial email can expect a poison
response. If such companies are arrogant enough to not even read the
contents of this page, then I shall post details of their incompetence
here."

It's not often that I add a new one - generally when the spammer in question tries to claim that it is not spam and pretends to have taken an interest in the site when it is plainly obvious that the About page has been completely ignored. It takes a special kind of idiocy to get onto the list - something that motivates me to a noticeable level of annoyance. The vast majority of spam doesn't come anywhere close. It has to be something that has some indication of being supposedly "customised" for me and my website(s) yet equally takes absolutely no notice of the content of that website, specifically the content explicitly added to About that should have been noticed by anyone with half a brain.

Anyway, my latest poison pen is now available for everyone to see.

True, it gives their spam email a wider airing but it's not as if codehelp.co.uk is anything but a very quiet backwater of the internet so it's not going to affect traffic in any real way. I just get annoyed when idiots who claim to be professionals do not have the simple courtesy of reading.

In a similar tone:
http://qof-gen.sourceforge.net/#free

Though I'd mention that I'm thinking a lot about distributed bug tracking right now. LWN had an article a while ago about distributed bug tracking, and one interesting suggestion that came out of it was that a bug report could somehow be passed around from one project to another while still somehow remaining the same bug report and connecting together the info from the different systems it passed through. That would really be excellent, but getting there seems hard, since there are many different bug tracking systems, all incompatible, and all storing incompatible data. Launchpad tries to pull together info from all of them in a centralised, top-down way. I'm thinking much more decentralised, ad-hoc, and bottom-up. And more subversive. Amoung other things, I'm thinking about microformats. Anyway, I think it would be good to get a group of interested people together to look over my ideas once they're a bit more refined, and generally beat on the distributed bug tracking problem. If you're interested, get in touch.

I learned a new word today, thunk. At first, given the context, I thought it meant text (as in program code) hunk, but the Hacker's Dictionary suggests it's actually more a term for a closure. For those not familiar with what a closure is, it's a "thunk" of encapsulated code created by the compiler which is dynamically generated and managed. Stealing the Wikipedia example: Nested functions are probably the closest thing to a closure you can get with C (I've talked about nested functions and trampolines before). However, because the stack disappears it's not nearly as useful, I think the term for these is lexical closures, because it's basically a way to share some stack and restrict name-spaces. Amusingly, the code using the term "thunk" was assembler, so my first search was for thunk gas (as in GNU Assembler). This of course lead to endless articles on the high price of gas — a non-renewable fossil fuel running out and capitalists realising inelastic demand can be used to line their pockets? Whoda' thunk it!

Forget it, there's no fucking way in hell to accomplish that. The last 6 months of my life had been turned upside-down, it's too much work, too much pressure... My performance at the University (which was never too good) degraded, sometimes I took too much time from my paid work, not to mention the abandon of almost all my other Debian duties. That is enough to drive you nuts, but there's more: a couple of event at my jobs resulted in lots of overwork around March-April and even more in the last month... Sum all this up, and you find that the only way to keep doing things is to rob precious sleeping hours: to finish pending work, to prepare the exams, and from time to time to have a little fun. The result is a grumpy mood, a aching back, and a tendency to get into arguments easily. My apologies to all the people that I mistreated, specially Marga, who's in a similar state of madness. So I really hope that DC8 turn out to be a great conference, and that everybody will have a good time. So all this would be justified. Tags: Planet Debian, Planet Lugfi

A month ago, I picked up a copy of Benjamin Nugent's American Nerd, and finally got around to reading it the last few days. The prospect of reading an entire book on nerds was exciting I was a nerd after all but I have to admit, I was also a ...

Wow, a pile of people seem to have friended me recently. I wish this thing sent me email when that happened.

Anyhow, I've friended those of you who:

1) I could figure out WTH you are; and
2) I don't mind you seeing the occasional either slightly personal rant, or information about where my travels.
3) From what I've seen on your journals, I won't gouge my eyes out reading them on my friends page.

I'll try to check there more often. And maybe I'll figure out who some of the rest of you are. =)

...are the last remaining packages before I am happy (or before someone adds a package with templates or adds templates to a package) udev, nut, flash-kernel, dtc, root-system are the additional missing ones before my German friends are happy. Your package is listed there? Make us happy, upload with translation fixes and win a beer at Debconf8 (or 9, or 10...). Your package is not listed there? Make us happy by NOT uploading with new or changed debconf templates without sending a call for translation update (hint: "man podebconf-report-po"). Anyway, this rush to 100% is much much more peaceful and easy than the same rush for Etch (where I think that French sustained 100% for about one week).