Devil's Pie (someones favourite window manipulation tool) 0.20 is out. New features galore!

• Handle multiple expressions in a file (Lars Damerow)
• Add spawn_sync and spawn_async actions to start processes (David Decotigny)
• Add println, str, hex, and expand print (DD)
• Add window_xid matcher (DD)

Downloads are in the usual place.

Aigars Mahinovs mentioned that it would be nice if applications would not clutter the home directory with their config files as much. I agree a lot. Dotfiles for configuration suck badly. If you start a new application (or if you are in an early stage and have a small userbase), please follow the Freedesktop.org XDG base directory specification. I.e. use .config/applicationname instead of .applicationname for configuration files (unless an overriding environment variable is set), and .local/share/applicationname for data files. And for cache files, use .cache/applicationname (anyone writing a patch for firefox?) What I'd also like to propose is to reduce the number of different configuration file syntaxes. It sucks having to find out which syntax an application uses again and again, because every application is different. We probably won't be able to convince everybody on one format, but we could maybe cut it down to, like 3 formats, please? There is no reason that one application needs to start comments with "#" and another with ";" while a third application uses "//" but doesn't allow "/* comment */"... A small set of syntaxes (preferrably with standardized parsers) should be good enough for just about every application:

• key=value pairs, quotations optional, comments match "^\s*#"
• ini-style configuration files with limited nesting
• JSON syntax (nesting, all strings quoted)
• XML files (arbitrary nesting, mixed contents, repeated elements)

If we had just these few syntaxes and an appropriate schema description language, we could write generic configuration file editors. That would be very nice. Also we avoid having config file parser bugs by using libraries, and if someone prefers using e.g. gconf or dconf, this could be handled by the library, transparently for the application. (Note that many application lack error handling when writing their configuration files, especially when the disc is full... - they really should be using a library. IIRC xchat also has some bugs of this kind, I remember having tried to patch some of them once when we were preparing for the sarge release, just to find out that there might be many more of them...)

Thanks to the great work of Matthias we now have a great new logo for the Unmaintained Free Software wiki. Thats' all.

For etch, we will have apt security in place, so we can be sure that the stuff comes from the correct archive. But it is not possible to disable that checks only for one source, just for anything. Buildds uses at least one mirror: incoming.debian.org aka ftp-master.debian.org. There are two queues, the accepted autobuild queue and the main archive. The accepted autobuild queue is not signed at all, it does not provide a Release file. The archive needs some time to generate the Packages files each dinstall run and have broken sigs during this time. This means: buildds can't use APT security at all. And no, there is no other mechanism to ensure data integrity.

The buildd admin job is a rather dumb one. You get between 20 and 60 mails per day; most of them build logs. This logs, which are mostly sent unsecured through the public internet, have to be signed and the only available key is the personal key of the admin. So on one hand you have to make sure that the key is secure, on the other hand you have to find a way to sign a rather large amount of stuff. For the debian-kernel archive, which I operate, and the pkg-voip/pkg-gnome/pkg-kde-extras archive, which is operated by Kilian, we decided to sign the uploads automaticaly. Each buildd get its own key and the used DAK includes a patch which restricts this keys to do uploads of only binaries of the correct arches. This drasticaly reduces the time until a new package is uploaded; this means much less failed builds because a build dep is not yet built. Also it reduces the places where it is possible to do harm; you have to attack the buildd machine itself instead of the complete mail setup between buildd and admin.

First to answer why we need TDebs:

localepurge: Disk space freed in /usr/share/locale: 256828K
localepurge: Disk space freed in /usr/share/man: 4496K

Total disk space freed by localepurge: 261324K

Second, I will write my tdebs implementation proposal after posting this (although Aigars made a really good sythesis of the discutions we had in Extremadura and there is almost no room for improvement :-). I have posponed long enough.

A post by Scott James Remnant describes how to hide command-line options from PS output. It's handy to know that but that post made one significant implication that I strongly disagree with. It said about command-line parameters "perhaps they contain sensitive information". If the parameters contain sensitive information then merely hiding them after the fact is not what you want to do as it exposes a race condition!

One option is for the process to receive it's sensitive data via a pipe (either piped from another process or from a named pipe that has restrictive permissions). Another option is to use SE Linux to control which processes may see the command-line options for the program in question.

In any case removing the data shortly after hostile parties have had a chance to see it is not the solution.

Apart from that it's a great post by Scott.

The new laptop I just bought had the bad habit of using the pc speaker at a loud level. It was deranging the coleagues at work when autocompletion yelded more than one result or none (it also scared me a few times during the last nights when I was configuring and testing the laptop).

So I unloaded the module (pcspkr) by hand and wanted to make the system not load it anymore.

So I thought that blacklisting it would do the trick. Probably some people know already that adding al line like:

blacklist pcspkr

in /etc/modprobe.d/blacklist doesn't work. The rest of you find out now. I found out at the next reboot, when I heard again the beep.

Ok, I googled a bit and found some info about restricting ipv6 modules being loaded so I though I could do the same for pcspkr. So I tried:

to change the line from /etc/modprobe.d/pnp-hotplug:

alias pnp:dPNP0800 pcspkr

into

alias pnp:dPNP0800 off

That didn't work either.

So, at this point I googled more and found some outdated information about update-modules.

That brought me to modprobe.conf(5) which pointed to the "right" solution.Write the following in some file in /etc/modprobe.d/ (I added it in blacklist, since it seemed the right place)

install pcspkr true

Which seems to do what I want.



Still something tells me that either:

1) there is a cleaner solution I am not thinking about

or

2) I could have told udev not to load the module... And I feel this solution should have to do something with these lines and "ACTION":

eddy@bounty /etc/udev $ grep -r pcspkr *
persistent-input.rules:DRIVERS=="pcspkr", ENV ID_CLASS ="spkr"
rules.d/z20_persistent-input.rules:DRIVERS=="pcspkr", ENV ID_CLASS ="spkr"



A clean solution would be appreciated.

This is just to say thank you once more to all who've made it possible. The circle in the graphic below marks the date when I made use of the newly available spam controls for my Debian mail account.

Or, Cleanliness is next to godliness The last time when I blogged about Spam fighting Mail Filtering With CRM114 Part 1, I left y'all with visions of non-converging learning, various ingenious ways of working around a unclean corpus, and perhaps a sinking feeling that this whole thing was more fragile than it ought to be. During this eriod of flailing around, trying to get mailtrainer to learn the full corpus correctly, I upgraded to an unpackaged version of crm114. Thanks to the excellent packaging effort by the maintianers, this was dead easy: get the debian sources using apt-get source crm114, download tghe new tarball from crm114 upstream, cp the debian dir over, and just edit the changelog file to reflect the new version. I am currently running my own, statically linked 20061103-Blame Dalkey.src-1. Cleaning the corpus made a major difference to the quality of discrimination. As mentioned earlier, I examined every mail that was initially incorrectly classified during learning. Now, there are two ways this can happen: That the piece of mail was correctly placed in the corpus, but had a feature that was different from those learned before; or that it was wrongly classified by me. When I started the chances were almost equally likely; I have now hopefully eliminated most of the misclassifications. When mailtrainer goes into cycles, retraining on a couple of emails round after round, you almost certainly are trying to train in conflicting ways. Cyclic retraining is almost always a human's error in classification. Some of the errors discovered were not just misclassifications: some where things that were inappropriate mail, but not Spam; for instance there was the whole conversation where someone one subscribed debian-devel to another mailing list, there was the challenge, the subscription notice, the un-subscription, challenge, and notice -- all of which were inappropriate, and interrupted the flow, and contributed to the noise -- but were not really Spam. I had, in a fit of pique, labelled them as Spam; but they were really like any other mailing list subscription conversations, which I certainly want to see for my subscriptions. crm114 did register the conversations as Spam and non-Spam, as requested, but that increased the similarity between Spam and non-Spam features -- and probably decreased the accuracy. I've since decided to train only on Spam, not on inappropriate mails; and let Gnus keep inappropriate mails from my eyes. I've also waffled over time about whether or not to treat newsletters from Dr. Dobbs Journal or USENIX as Spam or not -- now my rule of thumb is that since I signed up for them at some point, they are not Spam -- though I don't feel guilty about letting mailagent squirrel them away mostly out of sight. A few tips about using mailtrainer:

• Make sure you have a clean corpus
• Try and make it so that your have roughly equal numbers of Ham and Spam
• Don't let mailtrainer quit after a set number of rounds. I use a ridiculous repeat count of about 100 -- never expecting to reach anywhere close to that. Instead, I set the streak to a number = number of Spam + number of Ham + 10. This means that mailtrainer does not quit until it has processed every email in the corpus correctly without needing to retrain. Letting mailtrainer quit after it repeated the corpus twice, but before it got a streak of correct classifications left me with a filter with horrible accuracy.
• Make sure you have a clean corpus (yes, really)
• While the ratio of similarities between .css files to the differences between .css files is a fun metric, and I use it as an informal, rough benchmark while training, it is not really correlated to accuracy, so don't get hung up on it, like I was. Usually, the value I get when training from scratch on my corpus is somewhere around 7.5; but over time the ratio degrades (falling to about 5), while the filter accuracy keeps increasing.
• Train only on errors. The good news is that both mailtrainer and mailreaver already do so, so this is easy rule to follow. The reason is that you should only be doing minimal training, in case you have to modify/change the underlying rule in the future. So your filter should be trained to correctly classify the mails you get, but don't shoot for overwhelming scores.
• Use mailreaver. It has the nice behaviour of asking for retraining when it is unsure of some mail, and it caches mail for some time which really helps in training and rebuilding .css files. The reason mailreaver learns faster than mailtrainer is just this feature, I think.
• Stash mails you train on in your corpus, and don't hesitate to re-run mailtrainer over your corpus again after you have been training the unsure emails. When you train single emails, the changed filter may no longer correctly classify some email in the corpus you train with. Running mailtrainer over the corpus adjusts the filter to correctly classify every mail again. I generally retrain about once a week, though I no longer retrain from scratch, unless I change the classification algorithm.

• echo 1 > /proc/sys/vm/block_dump
  
  The above command sets a sysctl to cause the kernel to log all disk writes. Below is a sample of the output from it. Beware that there is a lot of data.
  
  Jan 10 09:05:53 aeon kernel: kjournald(1048): WRITE block XXX152 on dm-6
  Jan 10 09:05:53 aeon kernel: kjournald(1048): WRITE block XXX160 on dm-6
  Jan 10 09:05:53 aeon kernel: kjournald(1048): WRITE block XXX168 on dm-6
  Jan 10 09:05:54 aeon kernel: kpowersave(5671): READ block XXX384 on dm-7
  Jan 10 09:05:54 aeon kernel: kpowersave(5671): READ block XXX400 on dm-7
  Jan 10 09:05:54 aeon kernel: kpowersave(5671): READ block XXX408 on dm-7
  Jan 10 09:05:54 aeon kernel: bash(5803): dirtied inode XXXXXX1943 (block_dump) on proc
  


• Prefixing a bash command with ' ' will prevent a ! operator from running it. For example if you had just entered the command " ls -al /" then "!l" would not repeat it but would instead match the preceeding command that started with a 'l'. On SLES-10 a preceeding space also makes the command not appear in
  the history while on Debian/etch it does (both run Bash 3.1).
  


• LD_PRELOAD=/lib/libmemusage.so ls > /dev/null
  
  The above LD_PRELOAD will cause a dump to stderr of data about all memory allocations performed by the program in question. Below is a sample of the output.
  
  

  Memory usage summary: heap total: 28543, heap peak: 20135, stack peak: 9844
           total calls   total memory   failed calls
   malloc          85          28543              0
  realloc          11              0              0   (in place: 11, dec: 11)
   calloc           0              0              0
     free          21          12107
  Histogram for block sizes:
      0-15             29  30% ==================================================
     16-31              5   5% ========
     32-47             10  10% =================
     48-63             14  14% ========================
     64-79              4   4% ======
     80-95              1   1% =
     96-111            20  20% ==================================
    112-127             2   2% ===
    208-223             1   1% =
    352-367             4   4% ======
    384-399             1   1% =
    480-495             1   1% =
   1536-1551            1   1% =
   4096-4111            1   1% =
   4112-4127            1   1% =
  12800-12815           1   1% =
  

Russel Coker wrote in etbe: some random Linux tips: Prefixing a bash command with ‘ ‘ will prevent a ! operator from running it. For example if you had just entered the command ” ls -al /” then “!l” would not repeat it but would instead match the preceeding command that started with a ‘l’. On SLES-10 a preceeding space also makes the command not appear in the history while on Debian/etch it does (both run Bash 3.1). It’s pretty easy to get the Bash shell to ignore lines starting with a space in its history: Just add

export HISTCONTROL=ignorespace

to your ~/.bashrc. Alternatively, ignoredups ignores duplicates and ignoreboth ignores both. It’s also possible to tell Bash to ignore lines which match a specific pattern. For example,

export HISTIGNORE=" *:~/*"

will ignore any command starting with a space (emulation the ignorespace option to HISTCONTROL) or starting with ~/ (any program/script in or below your directory). Personally, I just use “HISTCONTROL=ignoreboth“.

Justification. Currently there is a huge mess of files and folders that start with a “.” in any users home folder. There is no structure or policy on how applications should choose file and folder names for data that needs to be stored in users home directory. Additionally there is no established consistency between Gnome, KDE and most other applications. Gnome application have part of their configuration information in gconf folder and other part in a gnome subfolder. KDE applications have a complex structure under .kde/. And most other applications either have one file directly in users home folder or have their own dot-folder there. Problems. There are two major problems with current ad-hoc approach:

1. Namespace pollution of users home space. In any desktop system “ls -al” in the home folder would be a very lengthy affair. Moreeven this namespace is folded - KDE and Gnome apps live in their own subfolders.
2. Lack of structure in folders makes it much harder to properly understand their purpose. For example, if a user has misconfigured an application and would like to reset it to default settings, it currently could be hard to figure out how to do that. Especially without losing his data in that application.

Proposal. I propose to implement a policy on where an application can store data and configuration information in users home folder. Such specification would be proposed as an extension for FHS, first implemented in Debian and then promoted for inclusion upstream and in other distributions. Structure. I propose a following structure for a users home folder:

• data/appname/ - each application, that stores user data in application-specific format, will have to store this data into this folder. Only configuration information that is essential to load this data would be permitted into this folder (in hidden dot files). For example, Evolution could store emails and email access information here.
• .conf/appname/ - each application that stores any configuration information whould have to store all of it in this folder. GConf will have to also store applications configuration info here. If this folder would be deleted, application must revert to default configuration, but still be able to fully access user data in data/appname/ or other, generic folders (below). For example, if .conf/evolution/ is erased, then on next start-up Evoution should still be able to access all email that is stored in data/evolution/ without any configuration wizards.
• .tmp/appname/ - each application that would need to create temporary files that survive reboot, would put them here. These folders can be safely deleted at any time with no data or configuration loss. For example, Firefox cache information and Nautilus thumbnail cache would have to be here.
• Desktop/ - the desktop folder, just like it is now
• Media folders - (Documents/, Photos/, Videos/, Music/, …) a suggestion of basic document structure for user to use or ignore. Applications dealing with particular media types would default to use files from such folders, but should also cope with working with any other folders on users choice. For example, a screensaver with slideshow function would by default use photos from Photos/, but will have to have a configuration option for user to change that setting.
• Additionally I would propose having a .mounts/ folder where applications could mount user specific media and other mounts, such as FUSE. For example, FUSE could be used for automatic archive introspection.

Benefits The main benefit for such system for me is twofold:

• SBackup can be configured to exclude .tmp/ and .mounts/ by default thus saving significant space in backups.
• A tool can be made to restore settings and/or data for specific applications in an uniform fashion.

So, any suggestions on the idea and on where this should be best discussed?

Lilypond is a great piece of software, but its documentation is sucky as hell. I've been trying to tweak the output of a particular piece of music which turned out to have just one system on the final page using the default settings, so that this final staff would end up on the first page, too. The documentation on how to do this, however, is less than helpful. If there is a mistake that could've been made by the people who wrote the manual, be sure they made it:

• In the "lilypond-internals" manual, there is mention of the fact that a particular variable needs to be a "moment", but no mention of how to do it; in fact, the default setting that is listed there for that variable is listed as #<Mom 1 4>, but trying to use that will give you a syntax error. It took me 15 minutes of trying, and finally more or less accidentally stumbling upon an actual example somewhere which sets a moment variable, to figure out how to do it; the right syntax is #(ly:make-moment 1 4)
• In the section on horizontal spacing, there is no single mention of the fact that settings on horizontal spacing apply to the score as a whole, and cannot be changed on a per-measure basis, or halfway the score in other ways. A pretty important detail, in my opinion.
• Yet, even if settings on horizontal spacing can only be made on a per-score basis, you still have to modify them by using \override commands somewhere in between your notes. Logic? Not really.
• In the section on horizontal spacing in the 2.10 version of the manual, there is also no reference to the new \newSpacingSection command, which allows one to split the score up in multiple sections in which the horizontal spacing can be changed anyway. Way to go.
• Even after reading and understanding most stuff in both manuals about horizontal spacing, my attempts still resulted in no visible changes on the page, and I have no clue why. There is no message, no way to be sure whether I did the wrong thing, or whether I did do stuff correctly but that it failed because of unrelated reasons.

Really, I would be very happy if the lilypond authors were to just find someone who actually knows how to write decent documentation.

One of the most typical religious traditions in Spain, within the Xmas celebrations, is the Kings’ day (”D a de Reyes”), which is celebrated every year on the 6th of January remembering the arrival of the three Kings to bring their presents to baby Jesus. It is quite typical to have presents that day, and one of the things I got this year was an external 2.5′’ HD case with multimedia playing capacity. I also got a 120 Gb 2.5′’ HD for it. The strongest point I had for it was that my brother already has one and it seems to support many file formats and codecs without problem. In my very short experience with it, just a few days for the moment, it has been able to reproduce all the films I have tried. The main drawback is that it only supports VFAT/FAT32 and NTFS partitions, and only 2 different partitions, no more. Thus, I had to cope with NTFS if I wanted to use the whole HD. I created one VFAT partition as big as supported by that filesystem (32 Gb, with a file limit of 4 Gb) just in case I need it when I go to some friends’ house, and another NTFS partition for the rest of the disk. The next point was to be able to read and write to it from my Debian-powered computer. Reading NTFS is no problem at all, as it seems to be built-in in the kernel by default, but for being able to write on it, I had to use ntfs-3g. It seems to work perfect for me, on an Intel-compatible 32bit computer.

Long-ago San Francisco Cacophony Society leader and early Burning Man organizer John Law is calling for the release of the Burning Man trademark into the public domain. An interesting story and some interesting questions about process. Burning Man is an event and a culture dear to my heart; I wonder how this is going to work out. Thanks to Scott Beale for his story on the subject; he knows the principals much better than I do. tags: burning man john law trademark public domain

Dear Lazyweb So, I was trying to read some documentation on my little Toshiba Port g and also lie down on the couch and also drink a beer, and these three activities weren't mutually compatible and I spilled some beer on my keyboard (and lap). Doh. I dried it off as best I could, and turned it upside-down like a teepee to dry overnight so the booze and moisture and sugar would go out of the computer instead of further in. Which seems to have paid off: the computer's running fine now. Except that the 'R' and 'G' keys don't work. They're not particularly sticky, they just don't register any key events when pressed. So, my question: what's my next step? Is there some trick I can do? Or am I just going to have to get good at lipograms? Drop me a line at evan@prodromou.name if you have any ideas. tags: lazyweb r g toshiba laptop beer keyboard

Father-Daughter Night Maj started French classes at the fantastico Montreal YMCA Language School. (I'm taking classes in German at the Montreal Goethe Institute starting next week; we came up with the idea of taking language classes independently.) Since Mama was out of the house from 5PM to 9PM, I got to do most of the evening prep for the night. Which was fun. I made Amita June and myself some ravioli and ros sauce, and we put a bowl in the fridge for Maj, too. Then we watched about 20 minutes of Babe, which had lots of cows and ducks and chickens and stuff she likes watching, but I was too worried that someone was going to get killed and eaten to enjoy watching it with her. So we did a bath -- she figured out how to make her rubber duck squirt water into the air, and that was worth about 20 minutes of giggles right there. Then we read some books, and by that point she was really ready for bed, and fell right asleep. We've been doing really good this week with going to sleep. I mentioned before that she's weaning from night nursing, so I'm doing most of the putting-to-bed and keeping-asleep work around here. It's been fun and rewarding; sleeping babies are great. tags: amitajune ymca babe maj french language lessons

Snow! It snowed today in Montreal! Just a little bit, but still. Hooray for us. tags: montreal winter snow

Googie I also stumbled across the word Googie architecture this evening. Interesting term and comfort food for the California native's soul. tags: googie architecture california

yulblog Tomorrow night (20 Niv se or 10 January for those of you who still use that oppressive Gregorian calendar) we've got the misnomered First Wednesday Get-Together for yulblog. The date was moved back from the very first Wednesday of the month to the second Wednesday to give some space around New Year's Day. I think the novelty has got people interesting in attending; I've talked to more than one person who's going to go. So, I'm going too. At the Quincaillerie at 980 Rachel, 8PM. tags: yulblog first wednesday quincaillerie

Effin' MyBlogLog So, I signed up for that MyBlogLog a while ago (see Journal/29 Frimaire CCXV), just to see how it worked. But I disconnected it from my own site since I thought the click-tracking was a little invasive. But I must have some cookies still left around, because I keep looking at sites like Read/WriteWeb, which has a nice article about OpenID, and I'm reading along and then there's a picture of me right on the page. Inserted from the MyBlogLog script, but it scares the crap out of me when it happens. Effin' MyBlogLog! tags: mybloglog readwriteweb

Just spent a long weekend (Thursday night to Monday afternoon) in Finland. Hanna invited me over a while ago with a promise of sauna and ice swimming, and I'm a sucker for travelling to parties these days... *grin*. Unfortunately, the weather in Finland (just like in the UK) at the moment is ridiculously warm for the time of year. When I visited in November for the BSP, there was some snow on the ground and temperatures were as cold as I expected. This time, there was no sign of any snow and I was worried that we might not get any ice...! Lars was kind enough to offer me some crash space at short notice for my visit (there's nothing like last-minute organisation for this kind of jaunt!). On Friday we met up with Jesus, Jeroen, Hanna, Pixie and Dave for lunch and some wandering around in the middle of Helsinki. Then on to some bars later for some drinks and food. I could get used to this... :-) On Saturday, we got up early, bought large amounts of food and drink to take with us, and caught the bus north-west out of Helsinki towards central Finland. 90 minutes on the bus and in a taxi, and we were dropped off at Hanna's family's cottage by the lake below: As we got there, the temperature was dropping just enough that we could actually see the ice forming on the lake. Beautiful! In the middle of nowhere in the forest, things were incredibly quiet and peaceful. We lit the fire for the the sauna, and wandered off for a walk through the forest. Later on, beer, sauna and (almost) ice swimming. Naked geeks! I must admit that I chickened out a little - coming out of the sauna into freezing temperatures slowed me down a little. By the time I reached the bottom of the steps to the lake surface, I couldn't force myself into the lake fully. I got three toes wet, then ran back inside into the warm... :-) Dave was more resilient (in and out FIVE times!), but it looks like he maybe overdid things. He crashed out later and was acting quite oddly for a while - we worked out that he was probably dehydrated. We carried on drinking and snacking at the cottage, then headed back into Helsinki for the bars and clubs later that night. More of the same on Sunday along with a cinema visit, and I was thoroughly exhausted and ready to head back to the UK on Monday. Thanks very much to Hanna, Lars, Jesus and the others for making my trip so much fun. Helsinki is a lovely place to visit, although probably too expensive for me to manage it too often. I'm saving already for the next time! I've put my photos online as usual.

I’ve just released pommed v1.1, which adds support for (some) PowerBook laptops. If your laptop is not supported, send us the content of /proc/device-tree/model and we’ll send you a test-tarball. gpomme received some improvements in this release:

• spanish translation
• now behaves correctly on multiple head setups
• supports loading an alternate theme using -t
• the background tile has been redone, it’s now nice & clean

The original tarball (available on Alioth, pommed project) contains an alternate theme for gpomme, named Tango. It’s not included in the Debian package because the Tango icons from FreeDesktop.org are licensed under CC BY-SA 2.5 which we don’t consider DFSG-free. It’s a nice, clean theme for gpomme which you’ll probably prefer over the default one. Copy it to /usr/share/gpomme/themes and run gpomme -t Tango to use it. If anybody knows where to find the SVG sources for the Crystal icon theme, I’m all ears. Thanks to Eduardo Bellido Bellido for the spanish translation and the multiple head patch for gpomme. Thanks to Daniel G. Siegel for the Tango theme.