So the Zune's big killer feature is (heavily DRM'd) wireless sharing of music. While I believe this will finally educate the masses about the evils of DRM, I would rather have a way to "recommend" a piece of music and offer a snippet for download to people near me, even without me being active in any way. If something like this catched on, and the transfer rates were acceptable, I could get a few new tunes on my daily commute, and learn about new artists this way. Throw in a rating system (doubling as spam protection), and a way for me to get the URLs of the artists' homepages for pieces I marked as "noteworthy" while they were playing into my browser easily, and this is the platform of teh phuture.

The stdarg API, which allows you to use a variable number of arguments to a function in C, is pretty fun. However, it's also pretty limited in what it allows, to a degree that it invites people to try and find workarounds to things you can't do with the API as it is documented. Unfortunately, this almost always breaks when the software is compiled on hardware that happens to be not your own, as there is a reason why stdarg is implemented the way it is: portability. A (not so) recent discussion on #debian-devel on OFTC showed to me how this confuses many people. Don't worry—it confused me too, the first time I had to think about it. The problem is that in order for stdarg to be able to do what it does, it needs to read function arguments from whereever they are stored. Where that actually is depends on the operating system and the hardware you're using; it could be on the stack, but e.g., the SPARC architecture actually has a mechanism to pass parameters using processor registers (although those are most likely not used when stdarg is in use, since the number of parameters that can be passed that way is obviously pretty limited). If parameters are on the stack, then you may be able to just access the memory as you would access any random variable; but it could also be the case that you need to take some specific steps to access the stack, or perhaps your architecture or operating system has some protection for stack-based security attacks, which would make it impossible to directly access memory on the stack that is actually part of another subroutine. So if you try to do anything that isn't defined in the stdarg api (like trying to figure out the number of arguments by peeking inside the va_list data type, or passing a va_list to another function without using the C99 va_copy macro) will break. Yes. Very sorry.

I've seen the Parcel Delivery Services email hoax twice in the last few weeks. Premium telephone services regulator ICSTIS issued a press release debunking it on 1 November 2006:

"This is in fact an urban myth. It is not possible for a GBP 15 charge to be made on connection."

I added a new tip about telephone number warnings to my email page.

I’m trying to set up a laptop which needs as much security and privacy as I can get. It turns out the main problem is that I want and need dual-boot: Windows XP Professional and Linux (Debian Etch). Now, Encrypting of all partitions used (except /boot of the Debian installation) is a must. Without dual-boot, this won’t be any problem, but not with the wish to dual-boot. The Linux side isn’t a real problem, I simply use a dm-crypt’ed partition as the only “physical” volume in an LVM volume group, which contains three logical volumes: Swap, / and /home. This means I only need to enter my LUKS/dm-crypt password once during boot. Shared partitions (shared between Windows and Linux) are also encrypted with dm-crypt/LUKS and decrypted by FreeOTFE (which is a really nice little OpenSource tool BTW), formatted as FAT32. The Windows side on its own won’t be too much of a problem either, since BestCrypt, PGP Whole Disk Encryption as well as DriveCrypt PlusPack (this probably isn’t a complete list) allow encryption of the Windows boot partition, but at least the latter two need their pre-boot authentication part (which is needed to be able to decrypt the Windows boot partition) to be installed into the MBR. Now, I wasn’t yet able to get Linux installed to the disk without breaking the Windows decryption. If anyone knows a program which allows encryption of the Windows boot partition and dual-booting into Linux, I would welcome a hint. Preferably, this solution should use grub as the primary boot manager.

I was approved by Debian NM FrontDesk team today, then, only one step remaining to dispatch my application.

• Step 1: Application
• Step 2: Identification
• Step 3: Philosophy and Procedures
• Step 4: Tasks and Skills
• Step 5: Recommendation
• Step 6: Front Desk Check
• Step 7: Debian Account Manager check and account creation

I hope to be DAM approved soon, go go! :) By the way, tomorrow I will have a skills test to get a driving license, wish me luck!

I don't know why, but debmirror (or Perl ?) fails to work with Solaris. For example this code

     while(($res = $gunzf->gzreadline($line) > 0) 
           && !($line =~ /^$/))   
       $buf = $buf . $line; 
      

read the full buffer instead of reading a block of text separated by empty spaces...
Multiline matching (m//m) fails to work too. So I rewrote almost the full Packages.gz parser in a dirty Perl way for a friend, and it works. I 0\/\/N3d you, fucking OS. And there's people wanting to port Debian to that, good luck

The last time I made any serious contributions to Wikipedia was back in 2001 or 2002. The community was exciting, friendly, and welcoming, and I enjoyed spreading the word as most non-technical people I knew had never heard of wikis or Wikipedia. Since then, I may have corrected the occasional typo or fixed a legal error, sometimes anonymously and sometimes under my account (apparently I “clarified the 13(c) protective arrangement issue” in the Urban Mass Transportation Act of 1970 back in the Fall of 2003, although I have no recollection of having done so), but I hadn’t started any new entries since the early days. At a recent presentation I attended by Sun’s Hal Stern, I learned that his eating club (Colonial Club) at Princeton University has a Wikipedia entry (as do all the other eating clubs). On further investigation, I learned there were no entries for any of the student cooperatives or other upperclassman eating options. To the uninitiated, it may be hard to understand why this matters beyond the insular Princeton community, but — suspend your disbelief just for a moment — the eating clubs have been called Princeton’s “peculiar institution” (a side-long reference to slavery) and have a storied and controversial history going back at least to the 1870’s (see, for example, this summary of the historical record from 1888-1993). It seemed to me that omitting the student cooperatives was akin to having a Wikipedia article on political parties that includes links to both the Republican and Democratic parties but leaves out any mention of the Green Party. Of course, the Green Party doesn’t wield the influence of either of the main parties, but its existence provides insight both into the American political system and the character of the two main parties. If no mention of the Green Party were included in Wikipedia, a foreign researcher attempting to learn about the American party system would come away with an incomplete and misleading understanding. The fact that the Green Party has not been particularly successful nationwide is, itself, interesting, useful, and relevant information. Although I wouldn’t pretend Princeton is as important or interesting as the American political system, it’s still a subject of scholarly investigation, and a topic that a fairly significant number of people are interested in learning about. I thought I would start basically a stub article for the Two Dickinson Street Co-op and spend a couple of days building it out and asking knowledgeable experts to contribute and add sources. Within a few seconds after I created the article, however, it was “speedily” deleted. A bit surprised, I tried to start an explanation as to why the entry warranted at least consideration for inclusion, and the article was deleted again and I found this message on my “talk” page:

This is your last warning.
The next time you vandalize a page, you will be blocked from editing Wikipedia. Diez2 14:55, 9 November 2006 (UTC)

I had gone from citizen to felon in two minutes flat! There then ensued several attempts to at least allow a debate on the deletion, but the article was unilaterally speedily deleted several times by several different editors. Even after one admin restored the article as not appropriate for “speedy deletion,” another admin stepped in and speedily deleted it again. I received some fairly acerbic retorts to my attempts — e.g. this: “We don’t have a page for every club in the world. If you want free web-hosting check out Myspace or usenet. Also anonymous postings do not make a topic notable or important.” (I’m not sure why he accused me of posting anonymously — I didn’t. Also, does “usenet” offer “free web-hosting?”) Finally, the deletion of the article was converted from a “speedy deletion” to a nomination as an “article for deletion” (‘AfD’), which allows at least for some discussion on the topic. The debate is ongoing — see it here — and some of the comments continue to be fairly corrosive. For example, one editor wrote:

• Strong Delete Fails WP:N, WP:V. It should be noted that on User_talk:Eagle_101 the editor of the article hs refused to give even just one reliable source of the article to assert it’s verifiability and notability. That alone should speak volumes for the article’s worth. Wizardry Dragon ^{(Talk to Me) ((My Contributions) (Page Moves) (Support Neutrality on Wikipedia)} 23:01, 10 November 2006 (UTC)

Another editor called the debate a “pointless waste of time” over a “vanity article,” although I can’t find that comment any longer. I admit that I created the article without knowing much about the process, and certainly with little understanding of the numerous acronyms, flags, and the several different ways an article can be killed. Apparently, I didn’t contest the speedy deletion properly, although it wasn’t clear to me from the deletion notice exactly what I was supposed to do, and I assumed the restoration of the article by another admin meant that it would persist for at least a few days. I thus deserve some of the blame for not doing more pre-posting diligence, but I was relying for the most part on my 2001-2002 experience where you could create an article, spend a few days improving it, invite others to contribute, etc., and articles with a colorable argument for inclusion would generally stay in. It seems the new Wikipedia is a much less kind and less gentle Wikipedia. As another participant in the process wrote to me:

This whole situation is so strange. It makes me feel like I just stumbled into somebody else’s trench warfare. The defenders of notability! I wonder how long the constant vigilance of volunteers will hold out…

Of course, a similar phenomenon has occured with many open source projects. Initially, the doors are wide open and everyone’s contributions are, if not welcome, then at least tolerated. I suppose it is a sign of Wikipedia’s success that the front gates are locked so tightly. Still, I wonder how many potential good faith contributors are now permanently alienated by an initial bad experience such as this one, and whether Wikipedia will ultimately suffer from it. Low barriers to entry have traditionally been a key element to attracting participants to peer production efforts, but they seem to break down in direct relationship to the project’s external importance. Incidentally, Stern’s edit to the Colonial Club entry, mentioning F. Scott FitzGerald’s characterization of the club, was quickly reverted by another editor as “nonsense.”

My post about securing an office received many comments, so many that I had to write another blog entry to respond to them and also add some other things I didn't think of before.

One suggestion was to use pam_usb to store passwords on a USB device. It sounds like it's worth considering, but really we need public key encryption. I don't want to have a USB device full of keys, I want a USB device that runs GPG and can decrypt data on demand - the data it decrypts could be a key to unlock an entire filesystem. One thing to note is that USB 2.0 has a bandwidth of 30MB/s while the IDE hard drive in my Thinkpad can sustain 38MB/s reads (at the start - it would be slower near the end). This means that I would approximately halve the throughput on large IOs by sending all the data to a USB device for encryption or decryption. Given that such bulk IO is rare this is feasible. There are a number of devices on the market that support public-key encryption, I would be surprised if any of them can deliver the performance required to encrypt all the data on a hard drive. But this will happen eventually.

Bill made a really good point about firewire. I had considered mentioning it in my post but refrained due to a lack of knowledge of the technology (it's something that I would disable on my own machines but in the past I couldn't recommend that others disable without more information). Could someone please describe precisely which 1394 (AKA Firewire) modules should be disabled for a secure system? If you don't need Firewire then it's probably best to just disable it entirely.

To enable encryption in Fedora Core 6 you need something like the following in /etc/crypttab:

home_crypt /dev/hdaX /path/to/key
swap /dev/hdaX /dev/random swap

Debian uses the same format for /etc/crypttab.

The Peregrine blog entry in response to my entry made some really good points. I wasn't aware of what SUSE had done as I haven't done much with SUSE in the past. I'm currently being paid to do some SUSE work so I will learn more about what SUSE offers, but given the SUSE/MS deal I'm unlikely to use it when I don't have to. Before anyone asks, I don't work for SUSE and given what they have just done I will have to reject any offer of employment that might come from them.

I had forgotten about rsh and telnet. Surely those protocols are dead now? I use telnet as a convenient TCP server test tool (netcat isn't installed on all machines) and never use rsh. But Lamont was correct to mention them as there may be some people still doing such things.

The Peregrine blog made an interesting point about Kerberised NFS being encrypted, I wasn't aware of this and I will have to investigate it. I haven't used Kerberos in the past because most networks I work on don't have a central list of accounts, and often there is no one trusted host.

I strongly disagree with the comment about iSCSI and AoE "Neither protocol provides security mechanisms, which is a good thing. If they did, the additional overhead would affect their performance". Lack of security mechanisms allows replay attacks. For example if an attacker compromises a non-root account on a machine that uses such a protocol for it's root filesystem, the victim might change their password but the attacker could change the data back to it's original values even it if was encrypted. Encryption needs to have sequence numbers embedded to be effective, this is well known - the current dmcrypt code (used by cryptsetup) encrypts each block with the block ID number so that blocks can not be re-arranged by someone who can't decrypt them (a weakness of some earlier disk encryption systems). When block encryption is extended to a network storage system I believe that the block ID number needs to be used as well as a sequence ID number to prevent reordering of requests. CPU performance has been increasing more rapidly than hard drive performance for a long time. Some fairly expensive SAN hardware is limited to 40MB/s (I won't name the vendor here but please note that it's not a company that I have worked for), while there is faster SAN hardware out there I think it's reasonable to consider 40MB/s as adequate IO performance. A quick test indicates that the 1.7GHz Pentium-M CPU in my Thinkpad can decrypt data at a rate of 23MB/s. So to get reasonable speed with encryption from a SAN you might require a CPU which is twice as fast as in my Thinkpad for every client (which means most desktop machines sold for the last two years and probably all new laptops now other than the OLPC machine). You would also require a significant amount of CPU power at the server if multiple clients were to sustain such speeds. This might be justification for making encryption optional or for having faster (and therefore less effective) algorithms as an option.

I believe that the lack of built-in security in the AoE and iSCSI protocols gives a significant weakness to the security of the system which can't be fully addressed. The CPU requirements for such encryption can be met with current hardware even when using a strong algorithm such as AES. There are iSCSI accellerator cards being developed, such cards could also have built in encryption if there was a standard algorithm. This would allow good performance on both the client and the server without requiring the main CPU.

Finally the Peregrine blog entry recommended Counterpane. Bruce Schneier is possibly the most widely respected computer security expert. Everything he does is good. I didn't mention his company in my previous post because it was aimed at people who are on a strict budget. I didn't bother mentioning any item that requires much money, and I don't expect Counterpane to be cheap.

Simon noted that developing a clear threat model is the first step. This is absolutely correct, however most organizations don't have any real idea. When advising such organizations I usually just invent a few possible ways that someone with the same resources and knowledge as I might attack them and ask whether such threats seem reasonable, generally they agree that such things should be prevented and I give further advice based on that. It's not ideal, but advising clients who don't know what they want will never give an ideal result.

One thing that I forgot to mention is the fact that good security relies on something you have as well as something you know. For logging in it's ideal to use a hardware security token. RSA sells tokens that display a pseudo-random number every minute, the server knows the algorithm used to generate the numbers and can verify that the number entered was generated in the last minute or two. Such tokens are sold at low prices to large corporations (I can't quote prices, but one of my clients had prices that made them affordable for securing home networks), I will have to discover what their prices are to small companies and individuals (I have applied to evaluate the RSA hardware). Another option is a GPG smart-card, I already have a GPG card and just need to get a reader (this has been on my to-do list for a while). The GPG card has the advantage of being based on free software.

One thing I have believed for some time is that Debian should issue such tokens to all developers, I'm sure that purchasing ~1200 tokens would get a good price for Debian and the security benefits are worth it. The use of such tokens might have prevented the Debian server crack of 2003 or the Debian server crack of 2006. The Free Software Foundation Fellowship of Europe issues GPG cards to it's members, incidentally the FSFE is a worthy organisation that I am considering joining.

There are basically two kinds of setups for mailing lists managed using Mailman, regarding posts from non-members :

• Accept posts from non-members. This lead to quite a lot of spam on the list, but also to no work for the moderators.
• Put posts from non-members in a moderation queue. This result in a spam-free mailing list, but also in a lot of work for moderators, and in posts delayed for days.

It would be great if Mailman could ask the sender for confirmation (either email-based or web-based) before accepting the mail or putting it in the moderation queue. This would greatly reduce the amount of spam on the list or in the moderation queue. This is also known as Mailman feature request #673265. A similar feature has apparently been in Sympa for nearly 4 years.

I was in a discussion about flash on a closed mailing list, so I'll post my comments here.

I believe that flash will soon be suitable for main storage on most desktop and laptop machines (which means replacing the vast majority of the hard drive market). Flash survives mechanical wear much better than hard drives (flash storage in a camera will usually survive the destruction of the camera), it produces less heat and less noise, and it has better seek times. It is more expensive, although the price is coming down and the main problem now is the number of writes that can be made.

Flash is widely regarded as being slow for bulk IO (benchmark results I have seen approach 10MB/s - while 60MB/s is common for cheap desktop IDE disks). I am not sure how much of this is inherent to flash technology and how much is due to the interface used to access the flash. I often work with Gig-E networks, but for my home use I only have 100baseT, so I have little need for more than 10MB/s IO rates at home.

It is generally regarded that a sector of flash storage wears out at between 10,000 and 1,000,000 writes depending on how recent the hardware is and who you talk to (some vendors are more optimistic than others regarding the usable life of their devices).

Let's assume that you have a 32G flash module running JFFS2 with an average of 2G free (30G of long-term data that doesn't change and 2G of space that is used for new files). Let's assume that the most pessimistic prediction for flash reliability of 10,000 writes happens to be correct. So if 10,000 writes are to be made to that 2G of space that means 20T of data written! If we assume that the machine will be obsolete in 5 years then that allows us an average of just over 10G of data written per day (20,000/365/5=10.9). On my laptop iostat reports the following after 5 days of uptime:

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
hda               1.94         9.94        20.33    4614118    9439808

I believe that this means an average of 20 blocks were written per second over the last 5 days with a block size of 4K (page size), this means 6.6G per day. Clearly something is wrong with my laptop as there should not be so many writes, but even so I wouldn't expect it to wear out within 5 years if I used only flash storage. Incidentally I do a lot of travelling and generally find that I'm lucky if a laptop hard drive lasts three years. So I could expect flash to last longer than a hard drive for my laptop use.

When flash fails I believe that only a small part of the data will be lost, which is better than the hard drive failure condition which is often to lose everything!

Also there is nothing preventing you from creating a RAID-1 of flash devices. Last time I checked the JFFS2 kernel code didn't support such things but that could be fixed if there was suitable hardware.

Note that JFFS2 is vastly preferable to using Ext3 or similar filesystems on a flash device. Flash needs wear-levelling (spreading the write load over all parts of the disk) for sane operation. JFFS2 has this built in to the filesystem, while Ext3 etc are designed to repeatedly write the same parts of the disk. This means that to use Ext3 you need a mapping layer that does wear-levelling which causes inefficiency. Also JFFS2 has compression built in (same method as gzip). This is good for smaller flash devices (EG the 32M storage that was common in iPaQs), and also reduces the wear on larger storage.

The biggest problem for me in using flash at the moment is the lack of support for XATTRs (needed for SE Linux) in JFFS2. KaiGai Kohei has been working on this, it's been a while since I checked on the progress so I'm not sure if it's got into the kernel.org repository yet.

Another problem with flash is that it is totally unsuitable for use as a swap device. This means that you need to have so much RAM that swap is not needed. Fortunately desktop machines with 2G of RAM are becoming common.

I finally got myself a nice digital camera. Nice as in, it fits in a pocket, it takes reasonably good-looking pictures, ant it's not a Canon so I can access it as an USB mass storage device. (For those who care, it's a Kyocera/Contax U4R.) So I've started using F-Spot (which is tremendously cool) and Gallery a bit more intensively than previously, and I noticed something curious: my pictures had wrong times. I thought that digital cameras stored them inside the picture files... Hmm. On to investigate. Time passes as I follow the threads of the information flow (use the source, Luke). Then I scream in horror. Then I go see something I hope is authoritative and therefore likely to have been well thought-out (read the spec, Luke). Then I scream some more. Let it be widely known that the Exif specification, which is the standard for embedding metadata into image files from digital cameras, encodes the date and time of the picture as a string. A fat, ugly, 20-character string. More precisely, the format is YYYY:MM:DD HH:MM:SS. I don't have anything against strings, they are rather easy to parse by humans (as demonstrated by strings /home/roland/images/photos/contax-u4r/kicx0700.jpg head). But they should be done right. In this case, it would have made a lot of sense to enlarge that string to 26 characters and add +ZZZZ or something similar. So as to be able to encode, say, a timezone, for instance, in order to, say, have dates and times that actually mean something, instead of something that may or may not be the current time plus or minus a random number of hours and minutes. I thought I could cheat by starting F-Spot with TZ=UTC f-spot (among my electronic gadgets, those that can't cope with timezones are set to UTC, with the exception of my alarm clock). The result is bizarre: the date is shown as being one hour late. I could understand if it were two (I'm at UTC+2 these days), but where does that one come from? I suppose I'll have to cheat differently, by keeping a patched version of F-Spot that interprets the TimeDate data from Exif as UTC, instead of using the current timezone. Or maybe I could do that in my hotplug script: it already rsyncs images from the digicam to the harddisk then makes sure the digicam's memory has at least $foo megabytes of free space on the card memory. I suppose it could also fiddle with the Exif tags on the fly. Anyway. People need to learn: text without encoding information is useless, cryptography without a web of trust is useless, and date/times without timezone info is useless. If one of my esteemed readers happens to be (or know) a member of the Exif specification group (I understand it's called "JEITA"), please tell them that this needs to be fixed in a future version of the spec. I suppose I'll have to live with it with my current digicam, but maybe the next one will be better in that regard. The pictures themselves are nice, though.

No, I didn't get a haircut, nor did I dye my hair blue (yet). I just partly un-transparentified my X-Face-based hackergotchi for Planet Debian and added that oh-so-classy semi-translucent drop shadow. And I also harmonised the colour scheme of my blog with the one on my pro site (yes, I'm a part-time free software freelance). Again, using a colour theme inspired from Manoj's script and blog article. I'm an absolute fashion victim. Must... not... put... "hacker emblem"... somewhere.

Ingo J rgensmann blogged about a bug in the Debian serendipity package. Thanks, the misspelled variable has been fixed. It should be noted that dbconfig-common does support remote databases, but only at debconf priority "low". He also writes that Serendipity does not support static pages. Well, it does, but with one of the countless available plugins. This plugin is not packaged for Debian. I had this same problem for SquirrelMail in the past and am not sure what the best way is to resolve it. Packaging plugins separately (one plugin one package) seems obvious but has been rejected by the FTP-masters for bringing too much archive bloat. An alternative could be to create one package that aggregates a number of plugins. With of course the question which plugins would and would not get into it. Any other suggestions for plugin packaging are welcome.

According to turmzimmer, there are 53 RC bugs remaining in testing that are not fixed in unstable and are over 20 days old. This is great, because that number is down from about 80 a week or so ago; but that leaves a good number of harder bugs open that could probably use some attention from NMUers given that these are the bugs that are specifically not seeing turnaround from maintainers. Just think, if every developer fixed just one of these bugs, we would have 19 NMUs for each package, the ftp team would be pissed, and we could release just two weeks from now once ftp-master.d.o was able to clear the backlog! And remember, any bug not found in a standard 52-bug deck is a spare portabella mushroom.

One of the annoying features of reading several planets, is that you end up reading entries from people you otherwise respect, who seem to have various complexes about nonsensical issues. We all saw the month in which half of Debian decided it was cool to rip on Ubuntu, and now apparently it's the new cool thing to do if you work on Fedora.

According to a particularly obnoxious entry, the quality or otherwise of Ubuntu's kernel[0] does 'damage to the free software community'. Now, they've focussed on binary drivers. Which is fair enough: I am personally quite uncomfortable with binary drivers, and extremely unimpressed with Ubuntu's recent move towards binary drivers by default. While I respect the fact that they still encourage users to install free drivers, providing them by default is not a winning move, in my opinion. But I'm not going to discuss this further right now, because if I do, the terrorists win.

The reason the terrorists win, is because some people like to furiously handwave and make strawmen. Apparently now, everyone who's ever touched Ubuntu is rabidly for binary drivers, but the problem here is the handwave from criticism of Fedora's alleged community into yet another ramble about the kernel tree and binary drivers.

I certainly hope the Fedora community is more mature than this, both in general, and in their ability to have a constructive debate about the level of its community involvement. Right now, it is not even disputed that there is effectively none. At first glance, they may appear similar, but if you look further, the similarities vanish. Anyone can come in and get involved in the decision making in Ubuntu, but more important than that, the process is at least completely transparent, so you can see what's going on, on public lists, at every step. Fedora does not have this: decisions magically appear On High from RHEL types. This is not necessarily a bad thing, and does not necessarily result in a lower-quality distribution, but if everyone could just accept this as being true and move on, rather than bitterly baiting a successful community distribution about it, I think everyone would be a lot happier.

The biggest difference is -- yes, basically all the Ubuntu core developers are employed by Canonical. These people were handpicked from the Debian community originally, and now a great deal of them start as Ubuntu community members, and are employed by Canonical because having them work full-time on this stuff would be awesome. The process is still entirely transparent: being employed is a mark of recognition (sorry), and a request to continue working on this even more, rather than a pre-requisite to being able to do anything. Witness Fedora Core vs. Fedora Extras, for example: there are quite a few packages that non-Red Hat employees are prevented from meaningfully contributing to.

So, the summary in a nutshell: binary drivers bad (and Ubuntu moves towards promoting same even worse), Fedora 'community' not at all, handwaves bad, refusal to get involved with a meaningful debate about community governance and structure without engaging in petty mudslinging and pointless handwaves inexcusable.

(Disclaimer: I am not involved with any distributions, nor do I have any professional affiliation with them either. I'm just an irritated observer.)

[0]: I don't claim to have any insider knowledge here; the only point at which its quality or otherwise has become an issue for me lately, is a random hang in gettimeofday() in a corner case recently, which I've been too lazy to isolate and report as a proper bug; I worked around it in the X server anyway.

I m a fan of statistics, so I created a small perl script that reads your gaim message history and, for the top 10 contacts, creates graphs: One for the total bytes chatted, one for the bytes chatted on each day, and two with weighted averages, over one week and one month timespan. You need the perl modules in libgd-graph-perl and libxml-xpath-perl, and my script. Run it and it will output the four png s in the current directory.I don t have examples, as the output is far too private to put up here, and I m too lazy to create interesting test data. There is a lot you can discover in these graphs: When you got to know someone (or when he started IMing), when you were not good terms with someone etc.

A feature I'd like to see in an SCM is a refactoring aware merge tool. When I have one branch that has had most namespace, class and method names changed (I used to use CamelCase), merging another branch into that doesn't work well, because there are a lot of scattered little changes that each inhibit changes for a few lines before and after. Given enough discipline on behalf of the person doing the refactoring (in my case, me), the commit that introduced these changes can be reduced to a set of substitutions, which then can be applied to the last version in the branch being merged, and this should reduce the conflicts to a small few (mainly whitespace changes, probably).

All mozilla-based browsers have a feature called "userContent.css". It was designed to allow you to override page CSS with your own, e.g. for accessibility reasons. It has mostly been used by people to remove ads, and I'll share two examples with you. Create ~/.gnome2/epiphany/mozilla/epiphany/chrome/userContent.css (you'll probably need to create the chrome directory, too; other browsers use similar path names) and put these two rules in there:

a[href$=".pdf"]:after  font-size: 10px; color: red; content: " [PDF]"; 
iframe[src*="devart.adbureau.net"]  display:none !important; height: 0;  
@-moz-document domain("mail.google.com")   button#ac_tr   color: red !important;   button#ac_dl   color: red !important;    

The first one will postfix a red [pdf] to any link going to a PDF file. This is very valueable especially with Google scholar. The second rule is an example on how to hide elements. This example hides some ads on deviantart. You can easily pick a wider term or grab some of the existing rulesets. The third rule will color the ">deviantart. You can easily pick a wider term or grab some of the existing rulesets. The third rule will color the ">deviantart. You can easily pick a wider term or grab some of the existing rulesets. The third rule will color the "delete" button in Gmail red, so you find it easier. Since it moves around (UI hazard; "delete forever" replaces "archive" button in spam and trash folders.) this is quite nice to have. But if you want to go for default ads filtering, I'd suggest to use some of the adblock extensions. These userContent tricks are mostly useful for adding rules that the extension didn't catch.

Editing LaTeX, the Vim way Uwe presented latexmk as its way of previewing LaTeX output while editing in Vim. While I don't know latexmk myself, I'm using quite a lot LaTeX recently (my Ph.D. thesis is getting huuuge) and I'm co-maintaining vim-latexsuite in Debian. With vim-latexsuite what he wants can be achieved quite easily too. I keep on editing in Vim and can exploit the following shortcuts (where <Leader> is usually mapped to backslash):

1. <Leader>ll compile the current LaTeX source, the generated format depends on the value of g:Tex_DefaultTargetFormat (I use dvi, for a reason explained below);
2. <Leader>lv fire up a viewer for the compiled format, in my case this runs xdvi;
3. <Leader>ls move the DVI viewer to the point the cursor is currently at in Vim, highlighting (in xdvi) with a rectangle the current paragraph (believe me, this is amazing);
4. CTRL+Mouse Click (this in xdvi) do the opposite of (3), i.e. move Vim to the point in the LaTeX source file corresponding to where we clicked in xdvi.

I don't really understand why Uwe want to see working previews in PDF format, to me PDF is just the final output. DVI is much better (especially for (3) and (4) above, but also because it takes less time to be generated). Oh, and of course vim-latexsuite is able to do a lot more, like deciding whether LaTeX needs to be run again to fix dangling references, use the quickfix window to jump to compilation error, and so on ... End of the SPAM PS these are my latex-specific vim settings from my ~/.vim/after/ftplugin/tex.vim

setlocal tw=80
setlocal ts=8
setlocal sts=1
setlocal sw=1
setlocal iskeyword+=\\
setlocal makeprg=make
setlocal keywordprg=:help
"setlocal formatoptions+=a
setlocal spell
vmap ,b "zdi\textbf <C-R>z <ESC>
vmap ,e "zdi\emph <C-R>z <ESC>
vmap ,t "zdi\texttt <C-R>z <ESC>
  " Latex-Suite
let g:Tex_CompileRule_dvi = 'latex -interaction=nonstopmode -src-specials $*'
if v:servername != ""
 let g:Tex_ViewRule_dvi = 'xdvi -editor "vim --servername ' . v:servername . ' --remote +\%l \%f"'
endif

Today, I started with the well-known experiment by making sure I'm not dropped out from social security for taking part there. After that was started, I invested some time on a long-standing wishlist bug on bts.turmzimmer.net, so that one can see even the RC-bugs related to a (source) package which would be ignored otherwise if at least one bug would be shown. This required some more code cleanup first. Now everything should work. I started the afternoon with creating a list of open tasks that are not marked as RC bugs, and dependencies between those. During that, I learned that the security teams thinks that we lost the security sparc autobuilder - not something that makes me happy, and something that needs to be fixed independent of Etch. Actually, it seems the autobuilder is just recovering, but I'll continue looking at it. apt-keys One item open on the list of open tasks is the final usage of apt-keys (which involves me in more than one way), so I started a testbed for having the Release-file signed by more than one key, and check whether apt is still happy. Adding another signature turned out to be quite easy with just adding it to the Release.gpg-file. If there is more than one signature on the release-file, but not all keys are know to apt, apt warns, but doesn't stop:

W: There are no public key available for the following key IDs:
010908312D230C5F

If however there is a bad signature, apt fails, even if there is also a good signature. (And please note, if the key is unknown, the signature is not bad but unknown - this gives the interesting behaviour that removing a trusted key by apt-key my remove the need to explicitly confirm to go on with the upgrade.) Summary on apt-keys Current behaviour is ok, we just need to sign one file extra with each stable (point) release, and this can be done with: gpg --no-default-keyring --secret-keyring srm-secring.gpg -b --armor etch/Release >> etch/Release.gpg (or rather, sign off-line, and append on ftp-master). The behaviour with multiple keys might look a bit strange, but IMHO we can live with it. I'm currently preparing to use real keys, and publish the result on some place where anybody could test it (for the latest sarge point release), and I hope we can put it on for the next point release on ftp-master.