I recently started using a new machine with two 20" flat panels used as one giant desktop with Xinerama. It's very nice and comfortable, but X isn't yet smart enough to manage the backgrounds of the two screens separately, and wants one image stretched across the whole desktop.

So here's how to turn two 1680x1050 images such as these into one 3360x1050 image with ImageMagick:

$ montage -size 3360x1050 -geometry +0+0 left-image.jpg right-image.jpg result.jpg

It's much easier than assembling the images manually in The Gimp.

I'm finally completely unpacked, it only took half a year or so. :-) I've turned the previously scary room-o-boxes into my server closet, with everything nicely shelved. Even my Atari is unpacked!

After the samba hype, it was time for me to take care of my pet package, namely geneweb, the "genealogy software with a Web interface" by Daniel de Rauglaudre. This is the only package which I'm maintainer or co-maintainer of which had no upstream version update between sarge (4.10-8) and etch (4.10-26). Back in February, Daniel finally agreed the only offering CVS snapshots as releases was not the best service he could do to his users (several of which are running proprietary operating systems and not very keen at compiling Ocaml code). And he released 5.00...a bit too late for etch. I quickly built a package for experimental, talked about it in the upstream mailing list...and quickly forgot about it (my genealogy work has been buried under Debian work for 3 years now). Finally, today I woke up and built/uploaded for unstable. I also moved from CVS to SVN on Alioth. Given that the CVS was, a while ago, my first steps with CVS, I just abandoned it and didn't even convert the history. The added value would be very low since I maintain this package alone since I took it over back in 2001.

Openbox Reading that keeping X in 3D mode tends to use more power convinced me to finally drop compiz. Back to metacity, I found it unusable. I've always used Super+Right mouse drag to resize windows, and metacity refuses to do that. I haven't found a way to resize windows with it other than dragging the super-thin, impossible-to-catch window corners or using the keyboard. I had a look at debtags search x11::window-manager (I found x11::window-manager using debtags tagsearch window) and picked openbox. Quite light, standardards-compliant, it seems to handle everything as it should (gnome panel, popups, fullscreen applications, name it). It has a very simple configuration dialog, just like metacity. Unlike metacity, it also has a configuration file in which I can tweak those things that are not in the configuration dialog. And it supports much more of those than metacity does. So, here are three use cases that weren't covered by metacity (or compiz, in case of RaiseLower) and are now fully covered by openbox:

• I now have resize on right-mouse-drag: useful because applications don't often start with the size I'd like them to.
• I now have RaiseLower on Super+Esc, to quickly see what's in that partly covered window and then but it back where it was.
• I can now move windows beyond the top edge of the screen, to reveal those "Ok" buttons of stupid dialogs that for some reason are taller than my screen.

And also, the fan of my laptop is not on all the time anymore. Updates:

• many people wrote me to say that it's possible to resize a window in metacity using Alt and middle mouse button drag; it is however impossible to configure it to use Alt and right mouse button drag, which would be nice to have on a touchpad.
• I've also been pointed out that it is possible to move a window beyond the top edge of the screen with metacity. It is not possible to do it with compiz, though.

Disjointed: Busy weekend: A brief trip to Glasgow, a lot of rat-lovin and a few minutes to hack on CFEngine package automation. I discovered insane performance problems with running Ruby on Rails applications under libapache2-mod-fastcgi so I switched to Apache2, mod_proxy & mongrel. The process wasn t as painless as I d expected so I might write it up shortly. In other rails-news: I can t get typo running on Etch. Migration from wordpress 2 fails in strange ways. Help?! In other news xmms on my AMD64 machine, reading /home/mp3 over an NFS share locks up every couple of days. Not sure if this is an AMD64 bit problem, or if the NFS usage is responsible. I should investigate. (The GUI is visible and responsible; but hitting next , play , etc, result in no action. I usually have to kill it then restart.)

6 weeks since my last post here, which I guess sums up how busy I am with things, primarily off-line but with a reasonable amount of development work coming out too. Thanks to Radu Spineanu xen-shell made it into the archive, and work has restarted on a multi-dom0 Xen control panel. So far there is a node daemon, a central server, and a shell-based admin tool, all written in Ruby. Coming soon a web-based control panel, implemented in Ruby on Rails. Exciting times.

Yesterday my ordered HP Thin Client T5725 arrived. The clue is, Debian sarge is and no moving parts (no noise) are inside. It’s a really nice thin client and it can be used as Surfstation out of the box. There is also a “HP Connection Administrator” which can manage ‘Citrix‘, ‘rdesktop‘ and ‘XDMCP‘ connections.
After taking a short overview, I decided to update to etch. This was a kind tricky, cause packages did need to update in correct order to save the HP packages. Due the switch from Xfree to xorg with etch, the graphical frontend for configuring the X server didn’t work anymore, but in my environment this is no issue.
So now I’m really happy with a HP Thin Client and bleeding edge software on it, for xdmcp use. ;) Debian, hacking, Linux, opensource, planet

I have purchased a new screen, and I have chosen an Acer AL2002W, mainly because of its low price. It is a 20″ wide screen, with a native resolution of 1680×1050 @60Hz. For now, it seems to be good value for money, and working with this screen is very confortable (I previously used a standard 4:3 17″ screen at 1280×1024). While configuring Xorg was painless (with both free nv and proprietary nvidia drivers), I still haven’t managed to get the framebuffer working with the native resolution of the screen. As vesafb doesn’t seem to be able to use a 1680×1050 resolution (hwinfo --framebuffer only gives 4:3 modes), I have tried to patch my kernel with vesafb-tng, which haven’t yield better results. While nvidiafb allows me to get a 1680×1050 framebuffer, it conflicts with proprietary nvidia driver, preventing it from being loaded. With the free nv driver, I can’t have the display centered both in console and in X (they both use the same mode, and the screen is able to stroe user modes at the condition the new display information habe 1Khz difference for horizontal frequency or 1Hz for vertical frequency or the syn signal polarities are different from the default modes). By the way, I have noticed that two of my laptops have the same Intel 915 video chipset, and one only is able to have a 1280×800 framebuffer (using the undocumented vga=0x362 code). I can’t understand the reason of this difference.

Tasks 0.5 is now released. This release has features a port to OpenMoko and several bug fixes.

• Add an OpenMoko frontend (Rob Bradford)
• New icons from Andreas Nilsson to match the Pimlico style
• Use a SexyIconEntry for the URL entries if available (Diego Escalante Urrelo, #241)
• Fix layout of widgets in the task editor (Diego Escalante Urrelo, #236)
• Chain up focus events in the new task label fixing warnings and IM
• Add some padding around the editor dialog (#323)
• Improve messages for translation
• Translate the menu bar
• Fix license to refer to Tasks not Sound Juicer
• Remove Application from the desktop file

More information, screeenshots, and tarballs can be downloaded from the Pimlico site. There are no packages yet, but I hope to have those online shortly.

Busy day yesterday; the first day of RoCoCoCamp, and the first day seeing a lot of friends and friendly faces from out of town. I was out of bed at 6AM yesterday. I stopped at St. Viateur Bagel on Mont Royal and got 10 dozen bagels -- enough for our expected crowd. I got to SAT at about 8AM, just in time to start the coffee machines. The big percolators I rented for the event require about an hour to make coffee, so if people were going to be coming in at 9AM, I really wanted to get them started by 8. Alain Bernardeau from computation.to got there soon after, and set up the spare computers his organization is lending us. Brandon Sanders, Mark Dilley and Nathan R also came in early, looking for work to do. I got them all into the job of setting up the food for breakfast. By 9AM we were trucking along, and I figured I'd go try a cup of joe, which should be ready. But all I got from the carafe was cold water. The percolators draw so much current that they'd blown a circuit. Guillaume, the SAT tech, and I tried about 8 different ways to keep them running, but nothing worked. Finally he put them on the 220V industrial circuit, which they didn't blow. Awesome, but at 9:30AM, with almost everyone there, we had no expectation of coffee for another hour. Yikes! But by the time people started filtering into the circle for starting the event proper, coffee was rolling and I was much relieved. Our facilitator, Deborah Hartmann, gave a great bilingual introduction to Open Space Technology and got the ball rolling. I always have a moment of dread during the beginning of a Open Space event: what if this is the time that Open Space doesn't work? But it did, again, which is great. The first session I went to was Zach Copley's, about consensus-supporting software features. Brandon Sanders had some great cases from AboutUs's adult content policy. We shared a lot of Wikitravel's culture, too. I also stopped in to talk about Wikitravel:RDF with Reini Urban, who was demoing Semantic MediaWiki. It's a neat project, and it's a different tack than I've taken with Wikitravel. I'd like to see the two approaches harmonized at some time in the future. Lunch came quickly, and we had far too much to eat. I spent a lot of time talking to Simon Law about possibly using Open Space in some way for BarCampMontreal. I think it's a good idea -- it's growing to a point where our current format is straining under the load. We also talked about ubiquitous wikis and the cool browser Amaya, where Web pages are in edit mode by default. It's a good idea. After lunch I had a chance to hang out with Earle Martin of Open Guides and talk about wiki and the geospatial web. Mark Jarowski of Wikevent was there, and together we've decided to hammer out a RDF vocabulary for exchanging RDF data about business listings. It's the kind of productive talk I like having. I also spent some time with Jack Herrick talking about wiki entrepreneurship. Jack had a prepared presentation about wikiHow's business experience, which was really great, and provided a great case study for talking about commercialization of wikis in general. With Angela Beesley and Ray King around us, we had most of the interesting wiki content businesses represented. Pretty neat. It was a really productive first day, but by the time we got around to 5PM I was exhausted. Maj, Zach, Mark, Niko and I all went to our new house at 4690 rue Pontiac to meet Allegra and their two daughters, No ma and baby Anoushka. We got pizza and had beers and sat on our new couch and had a good old time. Technorati's rocococamp tag shows a lot of other positive responses on the Web: Matt Forsythe's sketches from RoCoCoCamp, NathanR's continuing paranoia, CITIZENShift (which quotes me, when I was talking about wiki entrepreneurship), and Patrick Tanguay.

I'm off to SAT again this morning. Should be a fun one, and I hope to get a little more time to myself before the event starts today. tags: rocococamp barcamp barcampmontreal recentchangescamp wiki wikitravel

In a perfect world, software would work perfectly. Unfortunately... well, you know the drill. Since GCC 4.2 is upcoming, our resident GCC guy doko asked me to find someone to have a look at updating the Debian patches for GCC 4.1 so that they'd apply. Since I need to learn about GCC anyway for the Debian/ColdFire project (which nobody seems to be working on except for me), I started looking into it myself. The procedure is simple enough: uncomment lines in debian/rules.patch, and fix those m68k-specific patches that break. The first one was easy. debian/patches/m68k-gc.dpatch has been integrated upstream, so is no longer necessary. The second one was slightly more involved. But only slightly so; the patch tried to change libffi/src/m68k/sysv.S, which had received some three extra lines that conditionally add a .note.GNU-stack section. These three lines weren't there at first; but the .S file was otherwise entirely unchanged, so fixing this was rather easy. The next one is, uh, pretty hard. gcc/config/m68k/m68k.md is a file of 7k LOC in the GCC-specific "RTL" pseudo-assembly language, which I'm not at all familiar with. Yet, anyway. As a bonus, the first hunk in this file which fails to apply does so because that bit of this code has been changed rather significantly from GCC 4.1 to 4.2. Meaning:

1. I need to figure out how this RTL code works
2. I need to figure out what this particular RTL code block does
3. I need to figure out what the point of this particular patch was
4. I need to figure out how to write a patch (in RTL) which semantically does the same thing as what the original patch was doing. Without breaking the changes between 4.1 and 4.2

Wish me luck. At least the first two parts are almost finished; after skimming through chapters 12 and 14 of gccint.info, this hugging code almost makes sense to me. (oh, and if that last link doesn't make any sense to you, ask me for my fortune file at debconf) (which is in less than a month! whee! excitement!)

Or how online media can affect shares markets. Reading Enrique Dans' blog I have found an interesting entry on how a wrong piece of news published in an online medium made Apple shares to drop more than 4% in 6 mins. The history starts when Engadget published a false ticket talking about a delay in iPhone and Lepard releases. A supposed real internal mail from Apple was leaked to them, stating that delay. Actually that was a hoax. A spoofed mail that trespassed Apple mail servers and was delivered to a bunch of Apple employees, one of them leaking it to Engadget. About one hour and a half later, Apple sent another mail to their employees stating the untruth of the previus mail, and Engadget quickly published a rectification. But, in the meantime, the word spread fast and shares drop the 4% percent I mentioned before and with a lot of volume, which is an important signal for brokers that something is going wrong and that you have to sell your shares, increasing the effect in a snow ball way. The shares price drop meant Apple's market capitalization was 4 billion less (as US billions here) in 6 minutes. Information is crucial nowadays. But the speed at which it spreads is even more important.

Thing I longer wanted to happen is now becoming reality - Gammu is getting new public API. Man reasons for the change are:

• ABI stability. - Till now almost every change in internals of any driver lead to ABI change. If we would correctly increase so name on each ABI change, we would be somewhere near 200, what is not something we could be proud of.
• Centralisation of variables cleanup. - Currently all phone drivers have to do some common things in each function. New API allows to centralise those operations in one place.
• Exposing of internals. - Old API exposed too much of Gammu internals, what could be misused by programmers and could lead to unexpected behaviour when some internals are changed.

The work is not yet still complete, but the API is getting final shapes right now, so you still have chance to change something. While doing such big change, I decided also to complete documentation of all public functions. This is also currently work in progress, but arising API documentation is already available. If you are developer using Gammu library, you will have to change some things in your code. To document these changes, new Porting guide has been created. I suggest you not to start with this right now as the API is really not complete and might change a lot during next days.

A while ago I decided I wanted to make a couple of nice little apps for my Nokia 6600.

• Bluetooth AutoOff - disable Bluetooth and/or hide it after a configurable period of time
• PicGodfather - automatically change the template by which photos are named in the camera app, based on date (I can't think of another reasonable schema)

After my successful adventure with pys60 I decided/realized that the Python API does not contain appropriate functions for what I need in my apps, so I decided to setup the development environment for C++ with Carbide C/C++ (the recommended IDE for S60 development for Nokia).

Of course, the IDE is a Windows application and the reason for which Nokia doesn't provide an IDE for Linux (is expected since they are developing maemo and are so into OS) eludes me.
On top of that, I have an Debian Etch amd64 installation[1], so that's more fun.

Fortunately, thanks to Robert Millan and Ove Kaaven, wine is installable from unstable on amd64 and a chroot is not needed[2] anymore.


Now let's see the dependency tree:

• Carbide
  
• ActivePerl
• ScriptHost
• mfc42.dll
• correct mix of native and built-in dlls in wine configuration
  

Yes, that is all ... summarized. And you can imagine I went though leaps and bounds and wasted a night with this to find out the hard way.

If you don't care about the reasons/story, you can skip to the paragraph where I ran into license issues.

So, first Carbide needs Active Perl. Not any version, but ActivePerl-5.6.1.635. You will find out after you install Carbide c++.

Active Perl, by default, will refuse to install in wine. It relies on some Script Host support.
Good news: it is available on Microsoft's support pages. Bad news: the file is not provided until you go through some crazy scheme[3] to certify you have a genuine Windows installation.

Of course, the genuine stuff failed to work in wine, duh, but having a windows XP OS in qemu was really useful... to try to go further.

Now that I mentioned the Windows XP machine in qemu you might be wondering 'why didn't you installed Carbide c++ in there and start hacking in qemu?' . Well, I wish it was that simple! Believe it or not, the installation in the Windows virtual machine failed in a muuuuch earlier stage it initially did in Wine! It failed in the unpacking phase of the installation, while in Wine that part worked without problems (default config is for Windows XP emulation). Talk about irony!

After a while of trying, I took the risky path (maybe I should install an antivirus, as suggested by wine) and downloaded the kit for the script host stuff from some site on the net (shhh!). Good. I don't remember if I used cabextract or if it worked quite straight forward, but the special configuration entry in Wine Configurator suggests otherwise.

Back to Active-Perl. Now we can try again to install it.

wine msiexec ActivePerl-5.6.1.635-MSWin32-x86.msi

Guess what? The installation failed now, too. After some time of poking, I realised the bastard was looking for mfc42.dll in the installation. There was no word about that in the error message, only in the wine logs there were some hints. No wonder Windows users learn very early to ignore error messages (the error message was plain uninformative).

Where to get mfc42.dll from? The virtual machine! I tried to send them via email, but the link was too slow. Now I realised I could have used winscp, but I didn't thought of that at the time.

The rescue did come this time from M$, but with some effort. It appears that mfc42.dll is by default present on XP, so you only find it for download in some kit (vc6redistsetup_enu.exe) for Windows 9x. That works (lost some time to figure that out, too) since the kit contains a mix of 9x, NT and independent dlls. I think this installation didn't work and I had to cabextract the files by hand and copy them in system32. I registered the mfc42.dll module, after copying it in windows/system32.

wine msiexec /y mfc42.dll

Well, now I have everything installed Carbide should start... Well, no! License issues! I got a message about not having a license for the installation. Ain't that great? I just installed the thing and is the free/handicapped version. What gives? Well, in Carbide C++ 1.2, the Express part of the kit is broken and doesn't install the license file.

So, I installed the professional version since it had a longer trial period, hoping that now I'll be able to see the IDE and start working.

After this, I tried several times to start Carbide itself, but it failed at different points in time. I "just"[4] configured wine for this app to set the order to 'native,builtin' for msvcrt, ole32, oleacc and shdocw and got further.

Hopeless attempts follow....

At this point I got stuck. There was still some error from ole32.dll (apparently), but I couldn't go further.

I tried to install the 1.1 trial version. Got stuck. In any way I couldn't start Carbide c++ :-(( .

GRAND FINALE!

In the end, I also tried the deprecated CodeWarior. Guess what? It installed and ran immediately. Although I am not sure if any of the previous poking had anything to do with it.



[1] I have some packages from unstable
[2] although I had one, I wanted to get rid of it, since gnash started to perform better in the latest versions - still not satisfactory, but OK
[3] some browser plugin WPGInstall.exe, iirc and some app which should send your privat^W^W^Wanalise your system to generate some code that should identify your system as genuine
[4] this also took me some time... start, identify the dll, change the order, restart...

Well, today started out really anxious and is ending pretty reasonably. (Or so I think -- maybe tomorrow is going to be really nuts). First, RoCoCoCamp buzz is just nuts! Lots of people are blogging about it, planning to attend, and having fun talking about it. I count at least Patrick Tanguay, Sekhmet Design, Montreal Tech Watch, Montreal Tech League (no relation), Michel LeBlanc, Fred Ngo, Sylvain Carle, Rhymin' Simon Law, NathanR, Creative Commons Canada (thanks for the shout-out, gang!), Adrien O'Leary, Andreas Gohr (coming all the way from Berlin!). We're flirting with almost 100 people on the participants list, which I think is going to mean about 120-150 people. So I'm no longer worried that not enough people are going to come. Last night I got a quote for someone to provide coffee in the morning and at afternoon break for all three days... for $1800! So this morning I rented three coffee percolators (one for regular, one for decaf, and one for tea) and a bunch of cups and plates from Celebrations up on Jean-Talon. Maj and I shopped for coffee this afternoon. Total cost? $250. That means more money left over for pizza Saturday night! It means some more hassle for me and for the attendees, but I think we can handle it. Tomorrow morning early I have to stop in at St. Viateur and get 10 dozen bagels for the whole gang. I think many people who are attending don't know Montreal bagels, so they'll be in for a treat. Of course, some of the Montrealers will be mad I didn't get rival Fairmount Bagels instead. Tough for them. I know tomorrow is going to be crazy, but tonight I'm feeling pretty mellow. My good friend Zach Copley is on his way into town right now; we're working together on the kei.ki project and it will be great to have him here. Tomorrow Mark and Allegra arrive. So many good folks are going to be at RoCoCo: I think it's going to be a lot of fun. tags: rocococamp recentchangescamp stviateur coffee keiki wiki barcamp

Ren’Py is an engine that supports the creation of visual novels and storytelling. I fell in love with it since I first saw it, almost two years ago, and some of my friends know how much work I’ve devoted to that package so that it’s finally in Debian in a proper state, including submitting many patches to upstream. Lots of thanks go to Ana for all her help and support with this package. Ren’Py is designed to make writing complete visual novels as easy as possible. The engine supports, of course, conversations between the two characters, but also images, different transitions between pictures, music and sound, so playing a game can be a complete multimedia experience. The engine itself is based in Python and SDL (in fact, it is based in python-pygame). Anyway, ccording to the manual, you don’t need to know any programming, or be able to program, to use Ren’Py. Even though right now there are a lot of games made with Ren’Py available for downloading, most of them are released pre-compiled (for a certain version of python, including the whole interpreter and libraries in the release), and usually targeted towards Windows (even though Ren’Py is supported on Windows, Mac OS X, and Linux, and can be made to run on other platforms). Of course all the authors of the games are welcome if they want to publish them as Free Software, anyway my plans go towards using the engine for developing educative applications. My only problem is that I need to draw the characters I’ll use throughout the tutorias, which is something I’m not especially good at. I’ve got myself a book on how to draw manga and anime characters, but it’s probably taking a while until I’m proficient enough at that. I’ll try to find someone to help me with that. In fact, it would be great to release a free set of characters that newbie creators of stories could use as a starting point. Lets see if I can find an artist for that. The main drawback I see is that the dependencies might be too much to put the engine in a small embedded portable gadget to be able to play a visual novel anywhere. Who knows, maybe in the future.

A long time ago, I wrote the system that still manages the Cuerpo Acad mico Historia del Presente group in the Universidad Pedag gica Nacional. Yes, I'm happy a good portion of my project, which took me over a year of work... But I must admit a nice deal of shame as well.
Of course, it comes from not properly understanding the domain data and information volume my system would be working with - and coming up with a stupid way to implement searches. I won't get too much in detail because, even if you had access to the full search facility in the system (no, it's not available for the general public), I would not like a swarm of curious people to make last week's events come back... Anyway, the group works by daily filling in tens or hundreds of articles in the system, and having some interesting search sessions every couple of months.
I knew the performance problem was caused by an inefficient searching mechanism (explicitly, category exclusion is the prime killer). I knew loadavg jumped through the roof, memory usage did so as well... But it was not until some weeks ago we installed the mighty Munin on the machines at UPN that we got this jewel - Thanks, Victor, for putting the graphics somewhere they can be shown! ;-)
So... How much does memory usage increase during searches?

Whoa. The system has 640MB real RAM. It has as well 1GB swap. Don't ask me how the hell it reports it was using ~2GB swap - but still... And how is our load average?

Have you ever seen a (single CPU, Pentium 4 1.7GHz) Linux system with a loadavg of 80?! For those who don't know, loadavg gives you the general status on how many jobs are pending scheduling by the CPU. 1 means that all of the CPU's time during a specified timeframe was used (and, on single-core systems, it's the optimal usage level). On this machine, things start getting uncomfortable at 6 or 7. I had never before seen values even half this large.
Sigh... Well, in my defense, I must say I've warned them about this problem for over two years. My contract with them has long passed - I've repeatedly recommended them to hire somebody to fix it. So far, they have not.

After a long time talking this as a mere potential would-be-nice thing, finally we are putting some action behind our words: One week from now, Sergio Mendoza and I will start a ~2 month long extracurricular course on Debian. The students? We have 12 students of the Facultad de Ciencias at my University. The students are pre- and post-graduate (licenciatura and maestr a), from the Phsyics and Astronomy areas. Sergio got this group as he is a teacher and researcher at Instituto de Astronom a.
While this first iteration is completely extra-curricular, unofficial and by invitation only, we expect this pilot course to be later presented as an official course in the Faculty.
Many people will remember I usually don't like general courses on Unix, Debian or whatever. What made me accept this time - even more, be enthusiastic about it? First of all, the requirements: We assume the students already know their way (at least as users) in a multiuser Unix-like system, so we won't be hand-holding them all the way through. Second, the focus: Sergio (who is among the first Debian users in Mexico and who got us our first full Debian mirror - which is actually a bit sick, but awaiting for prompt hardware upgrade ;-) ) wants them to focus on becoming developers. Not only developing science-oriented applications and libraries, but properly packaging and integrating them in Debian (and, hopefully, some of them will become interested in joining the project). We will also spend a good portion of the course on teaching them good practices on system adminsitration, teaching the principles behind what we do (i.e. I'm looking forward to participating, and in this case as one of the more students, in the sessions where different cryptography-related topics will be explained, starting from their mathematical foundations and going all the way up towards the implementation, where I'm more comfortable at).
It will be a nice experiment. I will be away for at least five of the lessons (Blame Debconf!), but I'm really looking towards the process and the results.
We will be making rough documentation of what we teach. We don't have a planned complete program, as we want to go with the group's real skills and interests, planning not more than three lessons ahead. This will be, however unofficial it is, my first time in front of a group in a university-esque setting (i.e. not short sessions, not capacitation built for a company, but with people eager to learn what we want to teach. I'll post again on this topic :)

I asked an interviewee how long it takes for a disk seek, and he replied that he thought it was between 4 and 8 milliseconds. Speaking with colleagues, the conventional wisdom was that it was around 10 ms. I was unsatisfied so I thought I would try it for myself.


time sudo perl -we '$disk="/dev/sda"; $n=1500; $blocks= blockdev --getsz $disk ; if (!$blocks) print "Enter capacity in manufacturer GB\n: "; $blocks=1953125*(
) ; use Time::HiRes "time"; open DISK, $disk; $start=time; for (0..$n) seek DISK, int(rand($blocks))*512, 0; sysread DISK, $x, 512 die; $now=time; $times[int(($now-$start)*1000)]++; $x=$now-$start; $s2+=$x**2; $s+=$x; $start=$now ; for (0..$#times) if ($t=$times[$_]) $tot+=$t; $median =$_ if $tot>=$n/2; printf "%3d %s\n", $_, "x" x ($t/2) . ($t%2?":":"") ; printf "\nTook %3.4gs for %d seeks of %s (%d GB)\n", $s, $n, $disk, $blocks/2097152; printf "Mean: %2.03gms; Median: %d-%dms; Std dev: %2.03gms\n", 1000*$s/$n, $median-1, $median, 1000*sqrt($s2/$n - ($s/$n)**2);’


It should be obvious that before you run this, you should check for yourself that it doesn’t do anything dangerous. Or at least check that $disk is set appropriately for your hardware and operating system. If you don’t have blockdev, estimate the number of 512-byte blocks and set $blocks to that value. (There are 1953125 blocks in a hard disk manufacturer’s "Gigabyte".) The graph it produces prints an ‘x’ for two seeks of a given number of milliseconds and a trailing ‘:’ if there was one left over. For me, on my one year old Linux 2.6.18 workstation with a 160 "GB" Western Digital (WDC WD1600JS — quoted seek time 8.9 ms) the typical output is:

  0 :
  3 :
  4 :
  5 x:
  6 xxxx:
  7 xxxxxxx
  8 xxxxxxxxxxx:
  9 xxxxxxxxxxxxxxxxx
 10 xxxxxxxxxxxxxxxxxxxxxxx
 11 xxxxxxxxxxxxxxxxxxxxxxxxxxxx:
 12 xxxxxxxxxxxxxxxxxxxxxxxxx
 13 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:
 14 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 15 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:
 16 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 17 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:
 18 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:
 19 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 20 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 21 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 22 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:
 23 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:
 24 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:
 25 xxxxxxxxxxxxxxxxxxxxxxxxxxxxx:
 26 xxxxxxxxxxxxxxxxxx
 27 xxxxxxxxxxxxxxx
 28 xxxxxx:
 29 xxxxx:
 30 xxxx
 31 :
 32 :
 34 x
 35 :
 57 :
Took 27.69s for 1500 seeks of /dev/sda (149 GB)
Mean: 18.5ms; Median: 17-18ms; Std dev: 5.24ms
real    0m27.859s
user    0m0.116s
sys     0m0.044s

Why might I care? 18 milliseconds is almost a lifetime compared with anything else a modern PC does. It’s slower than my monitors’ refresh period! I can read around 1 MB from disk, 10 MB over a GigE link or 20 MB from RAM in this time. I can ping from Ireland to England, crossing 40 routers there and back, in the time it takes for my disk head to seek. Every time you read something from a previously unread file, it costs on average EIGHTEEN MILLISECONDS even before it starts reading. That’s just 55 in a second. This has obvious implications for I/O program performance, i.e. that of most servers. If anyone has a concern about my method, I’d be interested to hear it. I’d also like to see the timings for different disks. Either post the whole histogram or just the stats, plus the make and model of the disk. On Linux you can get this from dmesg or hdparm -I device. Update: I’ve made the script more robust under non-existence of blockdev.

I did rebuild the brand new version of wordpress for etch. New user requests and etch-bpo stated:

* Is the backport neccessary? I don’t think we should upload packages to bpo
simply because we can do it if you can install the package directly from
testing without any recompilation we shouldn’t add it to bpo. Pinning
exists.

So I’m not allowed to upload it to backports.org, but I did upload it to my repro, like the following other packages:

• backuppc
• collectd (from experimental)
• fuzzyocr3 (from experimental)
• gallery2
• libfile-rsyncp-perl
• php-suhosin
• xen-shell

You can download it by using the following line in sources.list:

deb ftp://ftp.cyconet.org/debian etch-backports main non-free contrib backports, bpo, Debian, opensource, Packaging, planet, wordpress