Today I just noticed the following advert on one of my web pages:
MINIX3 is a new reliable
free operating system. Smaller
than Linux. Try it It’s free!
www.minix3.org This made me think about some of the potential ways of advertising free software projects. It seems that in some ways Google Adwords is not the only way that can be used for advertising free software, and in some ways isn’t the most effective. I believe that the most effective method would be to ask people to advertise the project. I am generally positive towards the aims of the Minix project and am happy to give them some free advertising if asked (I’ve just given them a free advert above without being asked). While Google adlinks and equivalent things in blog posts are easy to set up, effective advertising may require something more. A series of pictures (in different sizes and color schemes) for the link would help, and the project would ideally have a specific landing site for people who see the advert. Someone who sees an advert targeted to newbies will have different requirements from the web site to someone who already knows about it and typed the URL in from memory! For a big campaign you would probably want to have multiple landing sites for different adverts targetted at different people. One example of how this can be used is my Bonnie++ page which gets about 6000 hits a month - many of which are from users of proprietary Unix. Linux users often have Bonnie++ as part of their distribution and don’t have much of a need to visit my web site so I expect that even though the vast majority of Bonnie++ users run Linux the proportion of site visitors might not be so strongly in favour of Linux. I would be happy to place an advert on that page to encourage proprietary Unix users to use the most free distribution of Linux if someone was to prepare the advert and give me some HTML code I can easily add to my site. To some extent the web site for every free software project could be used to advertise some related projects (or projects that are liked by the people who run the site). If you are a contributor to a free software project that you think I would like then feel free to prepare an advert and send it to me. If it fits with what I’m doing then I’ll give you some free advertising! Blogs are also a good mechanism for advertising free software projects, but it seems that this is already being used a lot - having said that… As a gratuitous plug: my favourite distribution of Linux is Debian (here are my Debian blog entries) and I run NSA Security Enhanced Linux (SE Linux) on all my machines (here are my SE Linux blog entries).

Share This

>> Thank you for your message to the Adaptec Customer Service department.
>> Your case # is 000000000005432. (NB: not the real number.)

*ROTFL*  Exactly how many customer requests do they expect to handle?

If the answer is "about 100/day", which sounds somewhat high to me given the above number, then space will last roughly three times as long as the time until this nice planet will die a fiery death in its expanding sun's outer heliosphere.

Maybe somebody was afraid of the Year-100-Billion problem

I've spent the last week and a bit in Edinburgh, at DebConf7. I found it took me a couple of days to adjust for some reason, but after I'd managed to lose all sense of time everything went much better. I'll probably spend the next week recovering and catching up with real life. I have to say I don't feel I achieved a whole lot while I was there. When I went to my first DebConf (DebConf4, in Brazil) I spent a lot of time hacking and making progress on things. I didn't manage to do so well in Finland, nor this year. I'm not sure that's entirely what DebConf is about though. I saw a lot of people; the UK crowd who turn up to most things, people I hadn't seen since Finland, and those who I hadn't see since Brazil (and must try harder to see more often). And of course several names I was able to put to faces. This is a really useful part of such events - I find it's much easier to deal with people online once I've met them in real life and have an idea where they're coming from. Having said I didn't achieve much I did many to leave with a lot of things in my personal todo list. I had the calendar conversation a couple of times again, at greater length, resulting in being told that I should just do it. So I need to think about a proper design. I started looking at Just Writing Code, but the problem is such that I believe a more rigorous approach is required. Another item was ARM hacking; I sat in on the ARM BOF and caught the end of the Emdebian stuff, as well as talking to Wookey and Neil Williams quite a bit about it. Wookey's convinced me that working on mainline Balloon2 support is still useful, even if everyone is more interested in Balloon3. And I thought a bit about starting to do some AM work again, assuming I can find enough time to do a decent job of it. Mao was sadly lacking; I got a couple of games in, but not the number I'd come to expect from previous DebConfs. I think the trick is to find Marga sooner... In addition to the travel to Edinburgh we ended up with a daytrip to the Isle of Bute - thanks to Patty Langasek for organising this. We managed not to lose anyone, and had a visit to a public loo from 1898. Post DebConf a bunch of us ended up in Solva for a party to celebrate Daniel and Rob's civil partnership. It was well worth the travelling, and good to see people who hadn't been at DebConf. Finally, on the way back home, we detoured via Stonehenge. Anyway. Now I'm back home, Katherine's turned up for a bit and hopefully I'll manage to do some of my todo list. See y'all next year in Argentina, assuming I can find the funds.

A few months ago, the Washington Post featured an article about Joshua Bell playing his violin (which happens to be a Stradivarius) in a Washington metro station. Contrary to their expectations, nobody stopped by to listen. The article tries to find reasons for why this happened, digging into theories by a number of famous philosophers. While those are undoubtedly not far from the truth, let me dig up another theory: Joshua Bell may be one of the best musicians in the world; that doesn't mean he's one of the best street musicians in the world. You see, if you play your Stradivarius in a concert hall, you don't have to do much to get people's attention. If your name is Joshua Bell and you play in the New York Opera House, people pay good money to get a seat months in advance, they circle the date on their calendar, and they look forward to it for weeks. When the big day arrives, they dress up, they drive up to the opera house, they queue for the privilege of being allowed to show their tickets and being allowed in, they take their seats, and they wait in excitement and anticipation until the big moment arrives. If your name is Joshua Bell and you play your Stradivarius in a concert hall, people will clap their hands you before you've even started. You'd better make it be good, or they'll demand their money back. If, however, you play on the street, then that's a completely different matter. You don't get to have people circle the date of your street concert months in advance. You have exactly one second to let them know you're playing. You don't get to have an audience that will clap their hands the very moment they see you turn the corner; instead, you'll see an audience that would rather you did not stand in the middle of the way like that, so that they would not have to look out for you. In short, you don't get their attention on a silver platter; instead, you have to earn it. As someone who's done street music in the past, I can tell you that earning someone's attention isn't something you will do by playing the most difficult music that can be found. You should remember that you've got just a few seconds to catch someone's attention; from the moment they vaguely hear someone's playing, until that time when they're getting annoyed at the volume your, no doubt wonderful, instrument is making. If you want people to stop and listen, you need to do it in that very short timeframe. A wild and fast virtuoso piece, while sure to get you a great reaction by an audience in an opera house, is only a very noisy thing if you just get a few seconds of it—even if those few seconds are by the best violin player alive. The best way to get someone's attention is to give them something they recognize. The article notes the reactions from a few passers-by. It did not surprise me that of the three or four people who actually stopped and listened, one recognized the violinist as Joshua Bell, and the other had been a violinist himself in a previous life. Both had something they recognized, which made both stop for a few moments to check what they were seeing. That's what gave them more time to appreciate how truly beatifull this music was, and that's why they waited. The real way to get people to stop, to get a crowd around you, and to have them to listen to you, is not to play what gets you the best results in an Opera House or other concert hall. Instead, you should play something that will catch people's attention. A brilliant piece that is unknown will not do that. A funny variation on "Oh When The Saints" will, because people recognize the music. That's not to say that street musicians should only play stuff like "Oh When The Saints". Getting money from playing on the street has more to it than just the music you're playing; just as important is the place where you're playing, and the time when you're doing it:

• If you're playing in a busy hallway, then people will just hurry along. Stopping gets them angry other people walking in their back, so that doesn't happen. If, on the other hand, you play on a large market square or some such, then people are much more likely to stand and listen—people walk in all directions there at the same time, so you have to look out anyway.
• If you're playing in a closed metro station, you'd better not use an instrument that's too loud. If you do, that will make people move away from you, rather than towards you, because they'll notice they can not talk on their cell phones or some such. If they have to pass by where you're playing to get to where they're going, they'll increase their speed so that they're faster past you. Both options give you less time to catch their attention.
• If you're playing on a monday morning during rush hour, you're not going to be getting a load of success. Everyone is going to work, and you're just something in the background, not much more interesting than the guy who's changing the billboard. If, OTOH, you're playing in a busy shopping mall on a sunny saturday afternoon, you'll get a large crowd anyhow.

A good street musician knows these things, and applies them even without knowing. He'll instinctively know whether it's a good day to do street music, and he'll rather go to a bar and have a hot drink if it's not. So why didn't Joshua Bell get a crowd around him? Easy: he isn't a very good street musician.

Ok, I'm officially back. Yup, when you have a meeting just over your regular lunch time and are suddenly seen as the guy who will fix the institute's video needs just because you worked manning cameras with the amazing DC7 video team, it just means you are back home. Lets see how several projects that have sprang up in the last couple of weeks (both at DebConf and at work) start materializing.
Anyway... DebConf was great. Just great. This time I had time both to feel I was useful and productive (mainly doing video-related stuff, although on some other points as well), to attend several interesting talks (although manning the camera did not leave my attention as complete as I would have liked), to have several nice chats, to play a good couple of hands of Mao - Hell, thanks to Kitty, I managed even to have some chats _while_ having a hand of Mao!
Of course, I was not productive neither with my Real Life duties nor with with the Debian stuff I wanted to hack on - In fact, the most productive period during the two and a half weeks I was away (excluding probably the two days I spent understanding/hacking Pentabarf with Dami n) was the flight back - During the ~12hr we were on the air, I managed to read the second half of my book, to review two chapters for a thesis, to write a (really simple) article and to work on another one.
Anyway... Thanks to everybody. I had a great time, and am only looking forward towards Argentina.
Ah, and I also got The Debconf Flu.

The Search Keys extension for Firefox is perhaps my favorite plugin. I tweaked it so it will work with Google Patent Search as well. The only additional code needed is in the searchkeys.js file:

 
name: "Google Patents",
test: function (uri)   return uri.host.indexOf("google") != -1 && uri.path.substr(0,9) == "/patents?";  ,
testLink: function (linkNode)   return (linkNode.className == "big");  
 ,

I added a new minor version number and posted it here for download. Hopefully the patch will be adopted upstream.

Share This

My first trip to DebConf ended yesterday evening (EDT). Fortunately, the trip back to Indy was much smoother than the trip to Edinburgh (my long rant on that harrowing experience will be posted when I finish it ). I had a great time at DebConf and hope to see familiar faces as well as meet new people at future DebConfs. Hope to see you in Argentina.

Parents and educators should be aware about what kind of games their children play. In the current state, this means that the parents must be gamers themselves to know about that, because there’s no way of knowing whether a game includes sex, violence, sexism, etc. until you play it. The idea is to provide a way of classifying games so that parents can know in advance whether the game involves certain culture-dependent controversial stuff, and being able to use that when considering what games they want their children to play, or what games they want to play themselves. Not that I’m the proper one to make the classification myself, but it should be done by teachers and educators, who I think are the best suited for this kind of task. In any case I’m willing to lead and coordinate the project, with the support of just some Spanish teachers for the moment. I hope that in the future teachers of other cultures will like to get involved too and the system can evolve to a multicultural one. The result should be as culturally independent as possible, but that would only be possible if members of different cultures help. There’s no way to provide a totally objective classification of moral stuff, so instead of trying to make the classification as aseptic as possible, it might make more sense to make it the other way round: trying to have all the different possible points of view, even when some of them might not even fit my own beliefs. Links:

• TIGRS , The Independent Game Rating System (Wikipedia)
• PEGI, Pan European Game Information (Wikipedia)
• ESRB, Entertainment Software Rating Board (Wikipedia)
• DebTags, Debian Package Tags (Categories for Debian packages)
• Previous discussion about this in the Debian Games Team Mailing List: 1, 2. 3

This has been delayed for a few days, for reasons I explain in another post, so my remaining debconf posts will be published quite quickly, every few hours. Monday started with me nearly asleep in the back of the Debian-Med session. Interesting stuff and I'm starting to get involved in supplying web apps to the health sector, but I must watch the session back. Then bureado's excellent debian in venezuela talk and a big shock for me when I got called out. The afternoon and evening were mentioned in the last post. Tuesday opened with me confused in the Xen session and then I went to a good-looking session on combining the debian-installer, ubuntu OEM bits, backuppc and openvpn but lkcl didn't show. (His diary suggests he was around. Wonder what happened.) I kicked the session along a bit and learned stuff from others about preseeding, FAI, backuppc, bacula, amanda and so on, but it didn't seem like anyone had plugged these together in quite the same way. At the end of the session, I bumped into Eddie Bleasdale who it seems is working with Phil Hands and lkcl on a very interesting project. He spoke more about it in a meeting the afternoon, hoping that Phil would arrive to handle the technical side. Phil timed his entry to perfection, about 30 minutes after the end of the talk. In between the hijacked talks, I went for a walk up to the top of Arthur's Seat and back with jumpula and someone else whose name I've forgotten - sorry! Oh, and what is it with all the loldebian posts this week?

DebConf7 finished today. This was my first DebConf, and probably not my last one :-) I had a really interesting time in Edinburgh, despite the weather (but at least we are prepared for DebConf8 now!). The organization team really did a fantastic work, the venue was gorgeous, etc, etc, etc. Again, I was positively surprised by how nice everybody was at DebConf. It’s weird to think that the same people are part of the regular flames on the mailing lists. Which proves that most flames are just caused by people being passionate about Debian, and looking for the best for the project, and not by people trying to be annoying, like one could think :) I gave a talk about the usual QA stuff I’m doing: archive-wide rebuilds, piuparts runs, and how to make all this more efficient by working inside the collab-qa project. So far, it’s not like a lot of people have been joining the project, which is kind of a failure. But at least everybody seem to think that the idea is good. I also gave a lightning talk about Debian Package of the Day, which I didn’t plan to give originally (I think I never prepared slides in such a short time). I think it was well received, and we even got a new submission half an hour after the talk. I even managed to clear some tasks on my TODO list during Debconf, the most visible one being the “automated monthly mails to maintainers of packages with serious problems”. I was quite afraid of being flamed, but I sent 250 mails, and only one person replied aggressively. I also got a lot of positive feedback, so the next batch will probably use slightly less strict criterias. And of course, the most important result of debconf was the numerous discussions, that resulted in a lot of good and interesting ideas.

So Debconf7 has come to an end, and I’m pretty sure this has been my best Debconf so far. Although I did not manage to attend many talks and discussions, and did not socialize as much as I would’ve wanted with the people I did not already know (does Mao count as socializing?), I’ve on the other hand felt good throughout all its duration, which is great. On the productivity side, I think I’ve done okay. Strangely enough it’s not been Debian the main target of my hack hours, God only knows why. Instead, I made a couple of contributions to Bazaar, one of the new generation distributed version control systems. But I’m sure my Debian work will gain momentum in the near future, so no worries. Finally, I must say I’m in debt with a bunch of people who thought it was worth having me attend, and brought me here when it seemed it was too late. I’m very grateful for that, really. As always, thanks to the orga team for their terrific work, and hope to make it to Argentina next year. Update 1: Forgot to say, I went to the Genderfuck party in The Forest. It was pretty cool, and a first. Update 2: Brittish Airways lost my luggage (and I seem not to be alone in this). P.S.: I think I’ve got the Debconf flu. \o/

• Rain! Damn weather. Though London is just as bad.
• Took 5 hours from Teviot to my place in London by air. I’ll probably go by train next time I visit Scotland. Though the views from the aeroplane window in seat 1A coming in from the west to LCY were AMAZING. I saw Picadilly, the gerkin, my house in E3 4QJ and other spectacular stuff.
• Got a bit of work done in DebCamp, not so much in DebConf. Though I attended quite a few BoFs and what-not
• Made new friends and it was great to see some old ones! The Debian community is a friendly bunch.
• I’ll miss the Indian food at the mosque. I won’t miss the cafeteria, except for the nice staff
• My room mates were all super cool. No loud snorers except myself. Phew! The hostel and staff were good too.
• I learnt a couple of vim tricks. Fixing the default way it auto completes with the elusive “wildmode” option .vimrc
• I switched with chsh to zsh-beta. .zshrc. Hopefully shared history with screen will work behave now.
• I discovered some Iceweasel bookmark tricks for use with the debian BTS
• I learnt my external USB2 drive is just as fast as the internal one with hdparm speed testing
• I learnt more about distributed SCM with git and bzr. I’ll probably try and learn both.
• Night venue was cool. Adjoining Forest cafe was funny.
• Edinburgh is a pleasant city.
• Was cool to demo Webconverger at DebianDay and tell people about it. I’ve received some good feedback and with Debian live improving like it is, it will only get better.
• I can’t believe the last 2 weeks went so quickly. There is a lot more to say, though I’ll keep this blog entry short.
• I’ll link my talk’s video when I see it up. Otherwise see the slides with FullerScreen.
• Last but not least, thanks to the organisers. You’re awesome!

Enrique Dans writes about the "The Coming Battle: Apple's iPhone vs. Corporate IT Departments". He makes an interesting point on how this new gadget can be a point of friction between managers of IT departments and their employees using this kind of gadgets, usually corporate executives. Syncing the database with RIM devices, or redirecting email accounts (iPhone is not capable of using corporate Blackberry or MS Exchange servers), can be a problem in corporate world. If you read those articles, they blame iPhone for not supporting all these enterprise-class software. Basically, IT departments are blaming iPhone for not supporting their competition systems, and they are not requiring all them (and themselves) to be using standards, which were just designed to avoid this kind of problems. They are afraid. No more comments.

Enrique Dans writes about the "The Coming Battle: Apple's iPhone vs. Corporate IT Departments". He makes an interesting point on how this new gadget can be a point of friction between managers of IT departments and their employees using this kind of gadgets, usually corporate executives. Syncing the database with RIM devices, or redirecting email accounts (iPhone is not capable of using corporate Blackberry or MS Exchange servers), can be a problem in corporate world. If you read those articles, they blame iPhone for not supporting all these enterprise-class software. Basically, IT departments are blaming iPhone for not supporting their competition systems, and they are not requiring all them (and themselves) to be using standards, which were just designed to avoid this kind of problems. They are afraid. No more comments.

Xen (a system for running multiple virtual Linux machines) and has some obvious benefits for testing Heartbeat (the clustering system) - the cheapest new machine that is on sale in Australia can be used to simulate a four node cluster. I’m not sure whether there is any production use for a cluster running under Xen (I look forward to seeing some comments or other blog posts about this). Most cluster operations run on a Xen virtual machine in the same way as they would under physically separate machines, and Xen even supports simulating a SAN or fiber-channel shared storage device if you use the syntax phy:/dev/VG/LV,hdd,w! in the Xen disk configuration line (the exclamation mark means that the volume is writable even if someone else is writing to it). The one missing feature is the ability to STONITH a failed node. This is quite critical as the design of Heartbeat is that a service on a node which is not communicating will not be started on another node until the failed node comes up after a reboot or the STONITH sub-system states that it has rebooted it or turned it off. This means that the failure of a node implies the permanent failure of all services on it until/unless the node can be STONITH’d. To solve this problem I have written a quick Xen STONITH module. The first issue is how to communicate between the DomU’s (Xen virtual machines) and the Dom0 (the physical host). It seemed that the best way to do this is to ssh to special accounts on the Dom0 and then use sudo to run a script that calls the Xen xm utility to actually restart the node. That way the Xen virtual machine gets limited access to the Dom0, and the shell script could even be written to allow each VM to only manage a sub-set of the VMs on the host (so you could have multiple virtual clusters on the one physical host and prevent them from messing with each other through accident or malice). xen ALL=NOPASSWD:/usr/local/sbin/xen-stonith Above is the relevant section from my /etc/sudoers file. It allows user xen to execute the script /usr/local/sbin/xen-stonith as root to do the work. One thing to note is that from each of the DomU’s you must be able to ssh from root on the node to the specified account for the Xen STONITH service without using a password and without any unreasonable delay (IE put UseDNS no in /etc/ssh/sshd_config. The below section (which isn’t in the feed) there are complete scripts for configuring this. (more…)

Share This

Following my previous entry about playing around with LVM, LUKS and the device mapper, I documented myself about internals involved in pvmove, which is more of a challenge, considering there is no such documentation. I could find no useful documentation for either the device mapper or LVM. A bit of good old UTSL later, I could elaborate how to do what I wanted, and realized it was even possible to do in shell script. So here you are : a shell script to transform an LVM physical volume to a LVM over LUKS physical volume,. I’ll detail in between how it works. As the previous script, use at your own risk, it comes with no warranty.
Note you theorically can still access the filesystems underneath without problems. It’s an in-place and live conversion. Also note this is more a proof of concept than a proper, risk-less and well-written solution.


set -e
dev=$1
luks=$(mktemp)
cryptdev=$(basename $dev)_crypt
pvsize=$(pvs -o pe_start,pv_size --units s --noheadings --nosuffix "$dev" awk ' print $1 + $2 ')
devsize=$(blockdev --getsz "$dev")
mchunk=8


The script takes the physical volume device to convert as an argument. Note there is no check for the validity of its value.

• luks will be the temporary file where we are going to create a temporary LUKS volume.
• pvsize is the full size of the LVM physical volume, i.e. the size of all the physical extents (pv_size) + the LVM headers and metadata (pe_start).
• devsize is the raw device size.
• mchunk is the size in blocks of chunks for the mirror target, see below.


dd of="$luks" seek=$devsize count=0 bs=512 2> /dev/null
luksdev=$(losetup -f)
losetup "$luksdev" "$luks"
trap "losetup -d \"$luksdev\"; rm -f \"$luks\"" EXIT


Next, we create a sparse luks file the same size as the device (in case luksFormat would use the size somehow, but I believe it doesn’t), and a loopback device on this file. The trap is here to avoid leaving the loopback device and the file when an error occurs later (though during the conversion itself, it will be pointless).


cryptsetup luksFormat -q "$luksdev"
cryptsetup luksOpen "$luksdev" $ cryptdev _real
read start length crypt format key IVoff cdev offset <<EOF
$(dmsetup table $ cryptdev _real)
EOF


We create a LUKS device, so that we can get the encryption key ($key), and the size of the LUKS header ($offset). Note you need to add –showkey to the dmsetup table command on sid.


if [ $(expr $devsize - $pvsize) -lt $offset ]; then
  echo Not enough free space after LVM physical volume
  cryptsetup luksClose $ cryptdev _real
  exit
fi


Check we have enough space after the LVM physical volume to offset everything by the size of the LUKS header. If not, you can still try again after you reduce the size of the LVM physical volume by an extent.


if [ $(expr $devsize % $offset % $mchunk) -gt 0 ]; then
  echo Last
  cryptsetup luksClose $ cryptdev _real
  exit
fi


This is another check to avoid surprises at the end, when dealing with the last chunk. As the script is written for the moment, it doesn’t support cases where this last chunk is not a multiple of $mchunk. So we need to abort in these.


read major minor <<EOF
$(stat -t "$dev" awk ' print $10,$11 ')
EOF
maps=$(dmsetup deps awk -F: "/\($major, $minor\)/ print \$1 ")
dmsetup create $cryptdev <<EOF
0 $length linear $dev 0
EOF
dmsetup reload $ cryptdev _real <<EOF
$start $length crypt $format $key $IVoff $dev $offset
EOF
dmsetup resume $ cryptdev _real
for map in $ maps ; do
  dmsetup table "$map" sed s,$major:$minor,/dev/mapper/$cryptdev, dmsetup reload "$map"
  dmsetup resume "$map"
done


Here, we create the dev_crypt device mapper that is our fake LUKS device, which starts as a simple linear mapper and will end as a complete crypt mapper. This fake LUKS device is inserted as an intermediate mapper between the LVM device mapper and the real device. So, the LVM device mapper will have this fake LUKS device as backend, and, at the beginning, the fake LUKS device maps linearly to the real device. Note we look for all device mappers using the real device as backend before creating the fake LUKS device to avoid finding the fake LUKS device in the list. Also note dmsetup reload only loads a new table in the INACTIVE slot, and dmsetup resume makes this inactive table LIVE.


cursor=$length
chunk=$offset
while [ $cursor -gt 0 ]; do
  cursor=$(expr $cursor - $chunk)
  if [ $cursor -lt 0 ]; then
    chunk=$(expr $chunk + $cursor)
    cursor=0
  fi
  (
  [ $cursor -ne 0 ] && echo 0 $cursor linear $dev 0
  echo $cursor $chunk mirror core 1 $mchunk 2 $dev $cursor /dev/mapper/$ cryptdev _real $cursor
  [ $cursor -lt $(expr $length - $chunk) ] && echo $(expr $cursor + $chunk) $(expr $length - $cursor - $chunk) crypt $format $key $(expr $IVoff + $cursor + $chunk) $dev $(expr $offset + $cursor + $chunk)
  ) dmsetup reload "$cryptdev"
  dmsetup resume "$cryptdev"
  chunks=$(expr $chunk / $mchunk)
  while ! dmsetup status "$cryptdev" grep "$chunks/$chunks"; do
    true
  done
done


This is where the main work is done : moving the data around. We actually just let the device mapper deal with the data duplication, $offset blocks by $offset blocks ($offset being the LUKS header size), using a mirror target for the chunk being moved. So our disk looks like the following:

We use the extra dev_crypt_real device (the previously remapped LUKS device) as the encryption backend for the mirror.
I haven’t figured a better way to wait for the end of the mirroring than to do a loop checking with dmsetup status, dmsetup wait doesn’t seem to be very helpful here.
Anyways, this is the part of the script where you don’t want a crash to occur. Because if it does, all you can do is start on a rescue system, and try to find where the encrypted part of the disk start to setup a device mapper by hand.
And you’d better have the luks temporary file in a directory that is neither in RAM (think tmpfs) nor in the LVM you are converting (/tmp in a default etch install is, for instance ; note the script works nevertheless fine in this case). Also note the trap will remove the luks temporary file if the script exits…


dmsetup reload "$cryptdev" <<EOF
$start $length crypt $format $key $IVoff $dev $offset
EOF
dmsetup resume "$cryptdev"
dmsetup remove "$ cryptdev _real"
dd if="$luks" of=$dev count=$offset bs=512 2> /dev/null


Final steps of the conversion : our dev_crypt device becomes a full LUKS volume, so we can remove dev_crypt_real and add the LUKS headers at the top of the device we converted. At this moment, the LUKS volume is setup just as if it had been setup by cryptsetup. For LVM to recognize the change properly, you need to run pvscan. Once you ran it, you can do whatever you want with LVM. Now, you may want to add the following to your /etc/crypttab file:


$cryptdev $dev none luks


i.e. hda5_crypt /dev/hda5 none luks if the device was /dev/hda5. And if the LVM volume you converted contains your root filesystem, you should run (for Debian systems):


update-initramfs -u


I tested this successfully under qemu and will give it a shot on my laptop some time soon. Now, because I had a hard time not finding much about the mirror target of the device mapper, here is what I could gather about it. The target syntax is as follows:


<logical_start_sector> <num_sectors> mirror [ core disk ] <num_params> <param> ... <num_mirrors> [ <destination > <start_sector> ] ...


logical_start_sector, num_sectors, destination and start_sector have the same meaning as in other targets.
core and disk are two different log types (to track differences between mirrors), respectively in memory and on disk.
num_params and params depend on the log type:

• for core, num_params can be either 1 or 2.
  The first parameter is region_size, which is the size (in blocks) of the chunks the mirror log tracks for synchronization. It can’t be less than the page size divided by 512, i.e. 8 on x86, must be a power of 2, and must not exceed num_sectors. Apparently, it is not a problem if num_sectors is not a multiple of region_size.
  The optional second parameter is either sync or nosync, meaning of which I’m not sure. I think it determines whether the mirror should do the initial synchronization (sync) or not (nosync).
• for disk, num_params can be either 2 or 3, with params being log_device (device where the logs are kept), region_size, as above, and an optional sync or nosync, as above too.

num_mirrors is the number of mirrors and for each mirror, we have a pair destination and start_sector. [ Update: after a quick look at the device mapper source code in Linus’s git tree, updated the mirror target description ]

Debian had OpenMPI package since early last year when Florian Ragwitz made some initial stabs at packaging. The package has seen a number of NMU and patches since then, but was generally getting cobwebs ... which was too bad because OpenMPI seems to have some wind behind its sails upstream. Unfortunately, little of that got packaged for Debian. After some discussions on and around the debian-science list, a new maintainer group was formed on Alioth under the pkg-openmpi name. Tilman Koschnick (who had already helped Florian with patches), Manuel Prinz, Sylvestre Ledru and myself have gotten things in good enough shape in reasonably short time. And I have just uploaded a lintian-clean package set openmpi_1.2.3-0 to Debian, where it is expected to sit in the NEW queue for a little bit before moving on to the archive proper. The changelog entry (which will appear here eventually) shows twelve bugs closed. Our plan is to provide a stable and well maintained MPI implementation for Debian. OpenMPI is the designated successor to LAM, and apart from MPICH2, everybody seems to have thrown their weight behind OpenMPI. So we will try to work with the other MPI maintainers to come up with sensible setups, alternatives priorities and the likes. If you are interested in MPI and would like to help, come join us at the Alioth project pkg-openmpi. Last but not least, thanks to Florian for the initial packaging, and to Clint Adams, Mark Hymers, Andreas Barth, and Steve Langasek (twice even) for NMUs.

Back in 2000, I started to get back into photography. I bought a Canon Elan IIe 35mm SLR camera, some lenses, and a flash. I took color photos various places, and then bought some standard Kodak T-Max black and white film. I shot some photos, and then tried to get this film processed.

Turns out it's not terribly easy to pay someone to process black and white film. Very few of the local photo places will do it. The place I usually used was willing to send it off to Kodak for me. Lacking a darkroom at home, and any interest in doing darkroom work myself, I sent it off to Kodak.

Kodak processed my film just fine, but the prints they made were terrible. It looked as if their enlarger was seriously out of focus. Everything was fuzzy on the prints. The local shop agreed to send them back for re-printing. On try 2, they were somewhat better but not much.

Now, B&W photos should normally be sharper than color photos, so this was nanoying.

I kept looking, and nobody locally could print B&W photos. I even tried one roll of B&W C-41 film (that's color-process film that takes photos in black and white). It stank about as much as I thought it would. I did eventually find one local lab that could take B&W negatives and, via a digital process, print the photos on color paper. They came out far more crisp than Kodak's processing on real B&W paper!

Now, 7 years later, I've been shooting some photos with my Canon Digital Rebel XTi digital SLR camera that I want to print in black and white. There are any number of color labs that I can send them off to, and get results as sharp as one would expect from a color photo. I'd been doing that with reasonable results. But I wasn't satisfied with "reasonable", so I searched some B&W groups on Flickr to see what people were doing to make B&W prints from a digital source.

It was there that I learned of mpix.com, the online service of the USA's largest pro photo lab. They offer printing on true B&W photo paper from digital (or film) sources. They're a pro lab, so they ought to do this really well. They of course also do color printing. Plus all the other things you'd expect from a pro lab, such as red-eye removal, glasses glare removal, color retouching, choice of photo paper, etc.

I sent off my first order for B&W prints to them yesterday. I can't wait to see how they turn out. I'm excited -- I think they'll be great.

Automatic completion for Closes: entry in Vim DebConf is always cool: it's the place where 2 minute chats with people can turn into cool hacks. It just happened to me: 2 minutes with Dancer and Gismo chatting about apt-listbugs and kaboom: in the next upload of Vim you will get for free (as in the free drinks Sun offered us a couple of days ago) completion of Closes: entry in your debian/changelog. Just start typing Closes: # and after the # execute CTRL-X CTRL-O (the key to invoke "omni completion", see ":help omni-completion" in the Vim online help). At that point apt-listbugs will be invoked by Vim, it will contact the BTS using the SOAP interface to retrieve outstanding bugs, and will offer you a list of bugs to choose from. A brief description of the bug report will be shown as well in a preview window (see ":help preview"). Once you've made your choice, the appropriate "#XXXX" entry will be input where your cursor was. Super-cool! Here are a couple of screenshot to wet your appetite: , . If you can't wait for the next Vim upload take my current debchangelog.vim and put it in /usr/share/vim/vimcurrent/ftplugin/.