Hey folks, we released some minutes ago finally Debian-Edu/Skolelinux 3.0r0 “Terra” which is based on Debian 4.0 with some modifications to work out-of-the box. Here are the releasenotes: Oslo - July 22., 2007 Skolelinux 3.0 is ready. This is an community release with comprehensive support from regional and national projects in Germany, Spain, France, Greece and Norway. The Skolelinux project is now a part of Debian under the name Debian-Edu. Several other projects have made additional functionality to Skolelinux tailored for national needs. Skolelinux now supports more than 50 countries.

Whats new in Skolelinux 3.0:

• based on Debian 4.0 “etch” and therefore compatible to LSB 3.1, using kernel 2.6.18 and KDE 3.5.5
• Full support for networked Thin clients, LowFat (diskless) clients, Workstations and Laptops. With the LowFat clients users got full PC functionality with extremely low maintenance cost. The use of LowFat clients gives full support for sound, video, USB memory stick’s and DVDs without the need for a local installation.
• Skolelinux now got more than 80 applications selected for pedagogic uses, supporting more than 50 languages. Many new applications are introduced in addition to popular classic as GCompris, KDE-Edu, Iceweasel (unbranded version of Firefox) and OpenOffice.org.
• Installation is a breeze: Both the installation and source code for all software are now distributed on a single DVD now supporting three different processor platforms as i386, PowerPC and AMD64. This makes it more easy to choose hardware, and to study the recipes behind the software. Those interested can exercise their freedom to learn, participate and share knowledge more easily. Installation CDs are also available, but requires a working Internet connection for installation.

About Skolelinux Skolelinux is a complete tailored software solution for the needs of any educational institution or school. It is a ready computer system were the school does not need to piece together the components. Skolelinux is the result of the work of the Debian Edu project and Debian Edu is an official Debian subproject. It is installed in a great number of schools in Norway, Germany, France and other countries. Municipalities and Commercial Service Providers run Skolelinux across multiple schools, operated and maintained centrally. Service providers report that the “lowfat clients” require half the maintenance cost of other desktop alternatives. The next milestone of Skolelinux development will be to merge the Debian-based LinEx distro into Debian Edu. Currently LinEx is used by more than 250,000 students and public employees in the region of Extremadura in Spain.

In depth “Lowfat clients” is also known as Diskless workstations. They run applications locally on the client. All software comes from the server instead of locally from the client hard drive. Recommended minimum requirement for client machines is > 256 MB RAM and 800 MHz CPU. Skolelinux now got improved tools for system surveillance and maintenance. Roadmap for next merging of LinEx and Debian-Edu: * http://wiki.debian.org/DebianEdu/LinEx2DebianEdu-Roadmap Please note that the documentation for the 3.0 Terra release is only available in English at the moment and contains some rough edges. We have considered releasing before the end of the summer holidays more important and we will fix those rough edges in the coming weeks, when we also expect more translations to show up. Those fixes will be included in the upcoming 3.0 r1 release.

In the past something-over-half-a-year (wow, time flies like crazy), i have shuffled my (virtual) toolbox fairly significantly. In the desktop department, I no longer use the full KDE desktop, only a few applications from KDE 3 (that is mostly konqueror, plus some of kdeedu). I still use amarok, although by now mostly just to manage my iPod, since it is outright laptop-hostile. Most of the time, it’s better (and much more power-efficient) to use iPod hooked into usb for power, at least as long as the music is there. For the rest, i now use the commandline players to play single albums (just music123 for most formats). For the window manager, i have opted for xmonad, after briefly using ion3 and a faint attempt at wmii (which didn’t quite work for me). Xmonad, however, works great and its simplicity is quite amazing. Despite its absolute minimalism, it is, after some getting used to, much more usable than the rest of WMs i have used. For terminal, i use urxvt, which is lighter and apparently also faster than konsole (i may reconsider that choice when KDE 4 konsole comes out). With xmonad, i don’t really need tabs anymore, i’m not sure why, but it may be related to more general change in my workflow. In the version control department, i am now using darcs for all the projects where i decide. I no longer use svk, since i no longer really know how to. Not working with it for a while, i lost the ability to use it efficiently (which possibly hints at the fact it is somewhat too complex). On the other hand, i am much happier with darcs, also since it is much more forgiving about mistakes and generally very deterministic. It requires some insight to be used efficiently i suppose, but this is mostly due to differences with more traditional systems (i believe). Today, i have finally moved my ikiwiki to darcs, which was the last thing using subversion/svk (well, i have only been able to use it through ssh and local svn for some months now, so i generally didn’t use it at all). This hopefully means that i will be able to add more content to this page and blog as well, since it is less effort now. I am still using emacs (GNU emacs 22, xemacs didn’t quite work for me when i have tried it — i have a somewhat nontrivial setup, too). I intend to try out vimpulse at some point, in addition to viper, to supersede my emacs-lisp hacks for visual line selection. I have also started working on replacing my internet-facing services, since they are running in an “emergency” (ie, not really working well) mode, after the xen system broke down completely (it was mostly un-upgradable due to fragility of xen packages and of the whole xen system — and since the setup relied on working xen for even basic internet connectivity, upgrades were extremely painful). I am migrating to a solution based on user-mode-linux, and moving all the services to a less power-hungry and less noisy machine (an oldish pentium 3 box). When this is complete, i should be able to read my private mail sanely again, since currently the spam filters don’t work and my inbox is mostly trash. This is unrelated to the xen breakdown, my mail used to be handled by a machine at a company i used to do admin work for. However, they removed my accounts (and therefore access to my mail) without a line of prior notice. I still have control over my domain at least (although there will be a problem when it gets to expire, i will have to arrange a transfer with the said company, i suppose). Morale of the story: never do that. (Yeah, and in the spirit of the post, i am still using mutt for reading mail).

So for the last week or so I have been manically trying not to lose Really Important Stuff like documents, passports, files etc as I have just moved from Canada to NYC and have made a brief stop in PR to visit my mom. Well the last thing I expected to lose—my laptop—is of course what is gone, vanished, entirely. There is a small chance that the TSA at the Newark airport has it but I won’t find out till Monday as their lost and found unit is closed during the weeked. I never thought that I would so want the TSA to help me out, although they, and the whole crazy security protocols, are part of the reason my laptop is gone. I made a backup of my computer right before leaving Canada, but I did it pretty quickly and did not check if it was really ok. All the really really important stuff is also backed up in email, or printed on paper, so Total F*cking Disaster is not imminent, just Total Disaster. So I won’t find out if I have my computer contents until Wed evening when I return to NYC. Since there is not much I can do here, I will cross my fingers and hope for the best. When I got home to PR, at 3:30 am to find no computer, I was pretty devastated. But instead of brooding over it, I switched into emergency mode, spending the next hour changing all sorts of passwords at 4 am, stealing the wireless from the hotel that is next door to my mom’s apartment (thankfully my SO was with me, donning a laptop). Although I did not store any on my computer, I did have my userid information in various places and I am pretty sure my computer was not off but only on sleep mode.. Yuck. After waking up after a few hours of sleep, I was pretty shocked that a good portion of my life is potentially gone, but then again, my mother’s alzheimers shocked me in other ways. Not too much has changed, though her memory loss, not surprisingly, is worse. In some ways, the fact that her data loss is permanent, that you can’t make a back up of the memories that are gone, that the data loss is so much more important than what you can have on a computer, has put things in some perspective, although I wish I only had the computer data loss to deal with instead.

I have just been reading the LinuxWorld Community blog which seems to be mostly Don Marti’s personal blog (currently there seems to be no-one else blogging on that site). One thing that disappointed me is that the theme designer made it look good at a width of 1000 pixels and no other size. At a smaller width the adverts on the right are cut off (more of a problem for the site owner than for the readers) and at a larger width you have a thin column of text in the middle of the screen. A quick test revealed that while my own blog looks good in wide windows it doesn’t work too well in 800 pixel width and gets very bad at lower widths - my blog would be essentially unusable at 640×480 resolution as the text column in the middle (the most important column) is the one that reduces in size. The LinuxWorld blog has a minimum size of 1000 pixels for the scaling so it allows horizontal scrolling in 640 pixel width and remains quite readable. The top entry in a google search for web size stats is Browser News which claims that 12% of web browsers are on 800 pixel wide screens. The next link I found claims that as of January 2007 there are 26% of web users with screens that have higher than 1024×768 resolution and 14% with 800×600. Apart from the first couple of months of blogging my blog has always looked good in screens greater than 1000 pixels wide, but not having it work at 800×600 is a problem. The first thing I did was alter the style.css file for the Blueline theme for Wordpress to use 100% of the display width (not 86%). Wasting 14% of the screen width is not a good thing when using a width-intensive three-column theme. This change made my blog work well in 800 pixel width and be bearable in 640 pixel width. The other change was to use min-width: 700px; in the style.css sections blogtitle, container, and navigation. This means that at 640 pixel width the text column will take more than 1/3 of the screen and should be quite readable (unless the reader has an unusually large font setting). The down-side to this is that if your window width is less than 700 pixels then you will have some horizontal scrolling, but I think that this is an acceptable trade-off. I was forced to confront this issue when talking to a prospective client about the potential for blogs to be used in his business, he loaded up my blog on an ancient windows machine and it didn’t look very good at all, this coincidentally happened a few hours after I had been reading the LinuxWorld blog on a big screen.

Share This

The recent announcement that sparc32 is to be retired seems to be regretted by many. Various suggestions on what should or could be done have been put forth. Here's mine: let's at least create some minimal project infrastructure for a (hypothetical) sparc32 port. So, there now exists a sparc32 Wiki page and a sparc32 mailing list. All that remains is people who actually do stuff.

Daniel Martin commented:

"Often, dustups like these are the result of upstream not caring about one or more of the following: 1) Licenses. Many people will release code with no license attached to it at all, which means (Thanks to the wonders of the Berne convention) that no one else can distribute it. 2) Patent restrictions (the gif patent issue is now dead, but there's still patents on some other graphic formats) 3) Restrictions against selling the software for commercial gain, using the software in the military, in biotech, etc. The netpbm copyright file seems to include instances of each of these. I don't know how it escalated into being unable to build based on upstream."

Thanks for the info. I'm still surprised debian doesn't keep a (maybe big) patchset rather than a fork on this one. I don't remember what put me off it, but maybe imagemagick isn't so bad...

Being a good Debian user

Notes: the bulk of this article was written on the 17th; updates were added in later; this article is really long, you might want to read it in more sessions

Debian's arm port uses hardfloat. This means that apps like rrdtool (graph function) take ages to run because there is no floating point unit. In order to make this faster you'll want to use soft-float emulation. But this support needs to be present in all depended upon libs, including libc, which is an ABI incompatible change which would break all binaries. I can't use the yet-in-development-and-unofficial armel port since the machine has to be up and running almost 24/7 and I can't afford downtime.

So what to do?

Well, obviously use another soft-float enable libc, like uclibc, in parallel withe the hrad-float enabled libc. Debian Sid contains uclibc development libs, but building the whole toolchain is a pain. There is no real support in the distro itself and building on the arm machine is kind of out of the question. I tried a little in a debootstrapped chroot on the native machine, but this was a pain and I was stuck tring to figure out how to disable whitles and bells for rrdtool since I didn't needed any of the perl, tcl or python support. So I stopped, went to bed and decided I'll continue the next day (the day I wrote the biggest part of this article). The future looked dark, trying to build a softfloat uclibc rrdtool on a system that wasn't prepared for that and from which softfloat was pulled away somewhere during etch's development stage....

Deciding to go with the competition - native building

From link to link I found out that gentoo has arm-softfloat-linux-uclibc port, among others, so I decided to use that on the target machine (a NSLU2) in a chroot. Well I stumbled on the low computing power, when I tryed to emerge sync the tree. I gave up un that and tried to use emerge-websync. It looked better, but I didn't got too far with this either since the machine ended up being overloaded, with figures varying from 3 to 8 for the load average (all of them).

Deciding to go with the competition - cross building

It was time to bring in the big guns and I decided I was going to crossbuild those binaries, probably statically since it meant lower risk for things to break on the target machine.


Since I observed that gentoo has a nice tool called crossdev which actually uses emerge (the equivalent of dpkg+apt in Debian world) to make the cross chain tool and saw that they have some really good documentation and a development version of an arm-softfloat-linux-uclibc, I decided I could .

So I went on and downloaded the latest stage3 tarball for x86 (so I can have a gentoo system to start with), made all the necessary things and created a gentoo chroot. I emerge sync-ed, updated portage, installed crossdev (following the nice instructions on the gentoo embedded site about the subject). This took a while, but it went like a breeze. I made the necessary arangements to be able to cross build packages (setting SYSROOT, making that nice xmerge script).

As my goal was to make an arm-softfloat-linux-uclibc binary for rrdtool I tried directly to xmerge rrdtool (of course, first just pretended -p).

Finding bugs in the packages

First bug

All went fine until I found freetype which for some weird reason detected the i486-pc-linux-gnu-gcc compiler as i486-pc-linux-gnu (observe the missing trailing -gcc). I looked over the logs and determined that the CC_BUILD environment variable was not set. So exported CC_BUILD=i486-pc-linux-gnu-gcc and xmerged the library.

(While trying to fix this issue I entered #gentoo-embedded on freenode and actually met Yuri Vasilev, whom I had met in Edinburgh, at DebConf. Look for the video about Ligusk if you are interested about his project to make a Debian like distribution based on Gentoo. It was nice to meet a friendly "face" - as much you can say that online.)


I reported the bug (already there is a patch, I haven't tested, but looks ok) and the workaround in the gentoo bugzilla... after creating an account, since I never used that BTS before.

Second bug

Next pain was libart_lgpl whose upstream, for some comfortability reason chose to detect the target type sizes (and basically ignoring inttypes.h) with a small program which was built with the cross compiler which later was supposed to be ran on the host. I don't think is necessary to say that i failed, of course, since the binary was an ARM binary, while the host was an x86 machine. Yupee! not.

Ok, two bugs, no softfloat rrdtool yet. I reported this second bug and tried to work around the issue. Since I didn't really used too much a gentoo system, I wanted to know details and what possibilities I had. I got some really nice tips from "solar" (aka Ned Ludd) on #gentoo-embedded. He pointed out that while building a package one can press CTRL+z, do some stuff, like altering the Makefile.in file in the build directory and then fg back. Ok, cool.

All I need now is somebody with direct access to an arm machine that can compile and run for me the program in question. seanius on #debian-devel was kind enough to do this for me and, to my surprize, I got the same output header file as I got in the host x86 chroot. But that detail is not important, let's just compile that rrdtool. Well, first libart_lgpl...

Ok, I CTRL+Z-ed the build process just after the configure stage ended, cd-ed into the build directory, I tampered with the Makefile.in file and changed that line from

./gen_art_config > gen_art_config.h

into

cp /gen_art_config.h.arm gen_art_config.h

Haha! In your face! Ok, nasty did was done so I fg-ed and went on confident that I will get my hands on that rrdtool very soon. The package build ended succesfully, without any other suprizes, so I went for the graal!


xmerging rrdtool, the bugs don't stop

xmerge -v rrdtool

Bla, bla, bla.... bla, bla, bla, what do you know, there are a few IEEE math function tests in the configuration script of rrdtool. They failed. I don't know why, but I have a feeling that this should be happening on softfloat or even maybe the rrdtool source is not that cross compile aware. I didn't care that much, so I did what I knew best, tampering with an ongoing build.

This time is was a little bit harder to catch since I had to wait for the source to unpack (well, there is a larger frame, but that is the rough timing) and at that moment CTRL+Z the build.

I didn't had much time to waste, so after looking shortly over the tests I realized I should just ignore the error and look for the "failing command" that was interrupting my beloved build. Muhahah!

Thank God for verbose error messages, I could find the place fast and chaged the two "exit 1" statements into two harmless 'echo "Ignoring IEEE math errors"', sic. I had to do this a few times since I got the timping wrong, at some point I got the syntax wrong (at which point I remembered the cp trick I did earlier and saved the modified file in /configure.rrdtool )...

xmerging rrdtool and the 4th bug

After passing past this stage, I got a compilation error which, judging from the command, meant that the linker tried to link the target (arm) binary against the host (x86) libraries.

Oooook, this is not going to stop me! I look at the Makefile.in to try understand why this happened and then realized it wasn't worth it for me to try to fix it the right way. So I cheated once again! Muhaha, I just ran some useful commands which I'll let you feast your eyes to:

ln -sf /usr/arm-softfloat-linux-uclibc/usr/lib/libart_lgpl_2.so /usr/lib/
ln -sf /usr/arm-softfloat-linux-uclibc/usr/lib/libpng12.a /usr/lib/
ln -sf /usr/arm-softfloat-linux-uclibc/usr/lib/libfreetype.so /usr/lib/

Ok, good to go. Of course, I had to stop again the build to copy the "fixed" configure script that ignored IEEE math errors, but that is already history.

And, believe it or not, actually the build succeded. I had a cross built rrdtool using shared libraries built against softfloat ucllibc. No guarantees about its correctness, but it built!

This is when I decided to start writing this article.

Still there are things to do

I will have to do a few things before being happy about the victory:

• check that all the resulted binaries are indeed ARM ELF files, and not Intel x86. It appears the shared libs are already.
• done, they are (checked the next day)
• figure out qpkg (is a utility from portage-utils which seems to be a way to make binary packages) to package somehow the result of this work or maybe just ignore it and use plain cp
• see how I can fit together both the softfloat uclibc binaries and the native debian binaries on the same filesystem, including ld.so configuration...
• but I fear this will be a nightmare, so I might decide to go with static compilation of rrdtool, which I don't think it will be quite straight forward given the experiences describe above; there could be also the size issue to take into account, and since the NSLU2 has only 32MB of RAM, this could be problematic
• I think I'll have to use a statically linked binary after all (note added late, the second day)
  
• see if the rrdtool binary really works and if all the work payed off, performance wise - it should, taking into account what I have heard from wookey during the debconf7 talk about the armel (warning, 73MB ogg file) port
• be happy with the solution I got or wait for the Debian armel port to catch up and switch to that asap
• if I'll have to do the switch I'll probably think of ways of migrating the whole system from arm to armel, and not to reinstall everything; this might prove useful for the whole debian armel port, when people are working on migration plans, since arm will be deprecated in favour of armel

Metro, the free newspaper distributed at train stations, has published an article about the Korenslag television show last Thursday. To my great surprise, they used two photo's to illustrate the article - photo's taken directly from my web site. This without any contact, or without any credit. I've sent them an email expressing my dissent with this and I've asked them to come up with a solution for this situation. If they'd asked beforehand I'm certain that they would have gotten my permission if they'd put a photocredit as they do with nearly every other photo in their newspaper. I'm curious what their response is going to be. Here's a scan of the article, the original photos are here: 1, 2.

Eric S. Raymond has apparently begun work on a new version of Emacs' built-in version control (VC) mode which addresses one of VC's historical shortcomings: its file-centric model. VC was originally designed for RCS, which tracks each file individually.

"NewVC" now has the basic infrastructure to manipulate changesets for backends that support them (Subversion, Arch, Bazaar, Mercurial); there's no UI yet but it looks promising... This change was long overdue, committing several files in one go is a must-have nowadays even with less advanced tools like CVS and having a common framework can only be good. Over the years, a number of more advanced interfaces like PCL-CVS and psvn.el have been developed to compensate for VC's defects, all with subtly different keybindings, which makes for a rather annoying experience.

I bet the folks over at DVC aren't too pleased though, since NewVC will probably make DVC mostly irrelevant.

As if being hospitalised after crashing into a spectator wasn't enough, Patrick Sinkewitz has been told he's tested non-negative for testosterone. I think that is the same test that Floyd Landis failed, which I'm still unsure about. In an outrageous move, ARD/ZDF (visible at 19 and 13 east) have stopped live tour coverage "until clarification of the Patrik Sinkewitz case" whatever that means. Will they resume if it the second test is positive too? I doubt it. If I remember correctly, ARD/ZDF have been threatening to drop the Tour de France for at least a year and maybe more. Finally, they get an excuse to replace proper tour coverage with more cheap, bland daytime TV like Z-list interviews, soaps and cookery shows - or continuous criticism of the Tour de France, like they had today. In the Expatica report, ZDF chief producer Nikolaus Brender said:

"We can't screen an event involving some teams and riders under suspicion of doping."

(That's strange. Of course they can. They have before and I bet they'll still show motorsport, football, horse-racing, golf, wrestling, and so on if they get them. They just don't want to show cycling.)

"We want to show by this gesture that we're ready to support cycling only if it's clean, that's to say without banned doping sustances."

(That's actually quite a high standard: over 180 participants, none of them cheating. That's a lot harder than 20 drivers or 30 footballers all being clean - even then, they don't always manage it and I don't see ARD/ZDF dropping those sports every time one player is accused of doping. Never mind all the smaller cheating attempts which are easier in many other sports than cycling.)

"It's a warning to cycling and to every other sport,"

It's a warning that ARD/ZDF's TV producers are short-sighted and don't care about the viewers. At least Eurosport Germany continues with live coverage every day! Let's keep watching and see how the chips fall for Sinkewitz. Are ARD/ZDF fee-payers raising hell about this absurd decision? I hope so.

Two movies again this week: first we went to see "Harry Potter and the Order of the Phoenix" which was quite nice. For people who have read the book and know how things work: quite some parts got reduced/removed. Who am I kidding, I mean, the book is immensly long, noone was expecting to have everything in the movie, did they? If they did, they were fooling themself.
For those who haven't read it: the remaining parts were mostly consistent and well done. There was just one thing that iritated me a bit with respect to the Thestrals on which they flew which Hermione and Ron weren't able to see—I expected to have at least a small scene with their scared faces and/or when mounting them. But appart from that it was pretty nice. :) Second movie was "Live Free or Die Hard". I really was looking forward to it, being an longtime Bruce Willis fan—and I wasn't disappointed. At. All! Everything was great. The action was nice but not the sole part of the movie. The dialogues were more than just interesting, and the story had it's nice parts, too. And I liked that Kevin Smith was in the movie. His role was great. :D

The ABC reports that an oil shortage is predicted soon. The International Energy Agency predicts that oil supply problems will start within the next five years. Oil production has been dropping over the last two years (we have passed the “peak oil” point) and demand is steadily increasing. Regardless of wars oil prices will increase significantly in the near future. According to the Australian Bureau of Statistics the average age of Australian cars was 10.7 years at the end of 1998. So the vast majority of the current fuel-hungry cars on Australian roads will still be in use in five years time - if the owners can afford them. The government needs to start providing tax incentives for fuel efficient cars and to end tax incentives for inefficient cars. Currently 4WD vehicles have reduced taxes and the tax deduction for a business car is based on the engine size (get a less efficient car and get a bigger tax deduction). The government claims to be protecting the economy (at the expense of the environment). But with the way things currently work the economy will be destroyed in less than five years. Even though the government cares little for the environment (in spite of the effect that climate change is having on farmers) they need to do something if they want to fulfill their claims of protecting the economy! Thanks to Chris Samuel for informing me of this.

Share This

Since I'm a member of the set of people "somebody better suited to explaining it" mentioned in Silvia Pfeiffer's "A Long Story of Logins", I suppose it falls to me to explain what the hell we actually did to make the thing work. A quick recap, for anyone who hasn't read Silvia's article: the Vquence website is a very AJAXy, Web 2.0 style video socialisation site. Since we want the site to be available to all as much as possible, we don't lock any part of the site away behind a "login required" page unless we absolutely have to. An unpleasant side effect of this is that, when it does does come time for you to login, pushing you off to a separate "please login" page is going to be, well, a pest. There's all sorts of state about what the user is up to (it's a web-based video mashup creator, after all) that we need to submit -- but only after the user has logged in. Enter the realm of the Web 2.0 Login. Instead of sending the user to a login page, getting them to login, and then redirecting them back to where they want to go, you just have some sort of popup form that, when submitted to, does a background request and logs the user in behind the scenes. This isn't a new concept by any means -- for example, try voting up or down a link on reddit when you're not logged in. However, most sites that implement this sort of thing (based on our brief informal survey around the office) don't protect the password information in any way -- it goes over the wire as a plaintext HTTP request. We don't like this, so we wanted to send the login form over HTTPS. And there began our problems. The trivial implementation of a Web 2.0 Login page is as you'd expect -- the AJAX stalwart, XmlHttpRequest, POSTing to a handler somewhere that validates the login, sets a session, and sends back some javascript to change the page layout a bit to show you're logged in. We had this working nicely, until we started testing on our staging environment, where HTTPS comes into play... You see, XmlHttpRequest doesn't like making a request to a domain other than the one that the main page comes from -- for security. It also thinks that the same hostname via a different protocol counts as a different domain, for the purposes of this security check. (I can see the theoretical reasoning for it, but it is a bit weird for HTTP to HTTPS transitions) So if you want to POST to https://www.vquence.com/something using XmlHttpRequest, you need to be doing it from a page which is retrieved from somewhere in https://www.vquence.com/ as well. We considered just turning on HTTPS across the board, but that would have all sorts of unpleasant ramifications, so we decided against that. But the problem remained, how do we get the user's credentials to our server in a secure manner with a minimum of unpleasantness? We came up with all sorts of options. This is where the infamy of "bug #93" started -- it's a monster of a bug log. Lots of it is me going "we could do this, but it'd suck, or we could do this, but it would suck". Finally, Silvia (I think) suggested we look at using an iframe. "Eeew" was the general response, but it might at least give us a way to set a part of the page to HTTPS, which we could use as a launching point for our XmlHttpRequest call. While researching how to make this all work (I had, to my great pride, never inflicted an iframe on the world before), I managed to come across a few articles on how you can use a hidden iframe to handle requests instead of using XmlHttpRequest. Basically, the trick is that you do a regular POST on your main page, but set the target of the form to a hidden iframe in your page. A general discussion of the principle is available At the Apple Developer site, and there's also a Rails plugin that implements the concept rather nicely. When I found these, I briefly danced for joy. My quest was over. POST to the iframe, the iframe get some JS back from the server, JS mangles the main page's layout to show the user is now logged in... aaaand profit. Like fun it was. My implementation was short and sweet -- a true work of genius (if I do say so myself). Everything worked like a charm. Until we got it back into staging. Then cross-domain security bit me again. Naturally, if you don't want XmlHttpRequest calls to perform cross-domain, you probably don't want iframes for different sites to be manipulating each other's content either. That's exactly what happened -- the iframe can't manipulate the main page's layout as we need it to. Why I didn't think of this before I charged mightily ahead I don't know. My only defence is that I've never claimed to be a web development guru. Sneaky tricks will defeat any security measure, though. For instance, we control both sites (http and https), so we can send the user back to the unsecured site after login and then that location (still in the hidden iframe) can manipulate the main page layout. Redirect to the rescue! That worked really well in Firefox, even with HTTPS in staging. We were saved. At least until IE came along. Bloody Microsoft, ruining all my cunning plans. IE complains when a HTTPS site redirects (using the Location HTTP header) to a HTTP site. You apparently can't turn this off. I was shocked that Microsoft cared so much about their user's data security -- it's certainly not the first thing I think of when I think "Microsoft". My faith in the world was restored when Silvia pointed me to a workaround for the problem -- if you send the redirect in a <meta http-equiv="refresh"> tag instead of a Location header, IE is more than happy to let it pass. Because obvously a chunk of HTML that says "HTTP equivalence" is completely different to a HTTP header. Sheesh. To snatch defeat from the jaws of victory, after all this brilliant hacking, I managed to make a newbie error with the contents of the http-equiv by setting the content to "0;http://www.vquence.com/blah" instead of "0;url=http://www.vquence.com/blah" (note the url=, because I sure didn't). IE complained by looping infinitely on the source URL, while Firefox just made sense of it and did the right thing. I managed to waste most of an hour of three of us over that little stuff-up. Go me! (Sorry about that guys, by the way) Feeling very chuffed, I went home for the evening. The next morning saw a browser compatibility defect in my queue -- Safari didn't like the new setup. Instead of doing the right thing, clicking on the login button would create a new tab instead of logging in. The fix? Changing the style of the hidden iframe from "display: none" to "width: 1px; height: 1px; border: 0" did the trick. Fark. So much for "hidden" iframes. What's particularly funny is that Apple's own tutorial on hidden iframes says to avoid "display: none" because NS6 doesn't like it, but doesn't mention it's own glaring deficiency in this area. So, what are the lessons learned?

• Firstly, IE is different. I knew this already, but living in an all-Linux, not-normally-a-web-frontend-developer world, I need to be reminded every now and then.
• Safari is differently different. Being a former Konqueror user, and wrangling with that browser's retardations in an earlier existence, I should have been ready for this one.
• "Code to the standards" is a crock of shit. That's not to say that we shouldn't encourage it, but I'm fairly sure that the HTML 4.01 standard is silent on whether or not an iframe with it's display property set to none is a valid target for a form submission (I had a quick look, and nothing jumped out at me). Anyone who dismisses the difficulties of web development with a hand wave and a casual "just code to the standards" will get a double-spaced, 24pt printed and bound copy of all of the W3C standards dropped on their head from a tall building.
• No matter what security measure you think has stopped you, there's always a workaround. Can't do a XmlHttpRequest to a different domain? POST to a hidden iframe (you can post to any domain you want, too -- so much for cookie security). Want to run JS you got back from POSTing to a different domain? Just redirect back to the first domain. Can't redirect from a HTTPS to a HTTP page? Don't use a HTTP redirect, use a meta refresh. Sigh.
• Hidden iframes are cool. While I'm firmly in the "frames are evil" camp, they're a nice freaky behind-the-scenes tool if you want to do something more than what a simple XmlHttpRequest gives you. It's like having a whole separate scratch-pad of a browser you can play with, and the user never has to see it.
• Web development is frustrating. I don't do a whole heap of it (I'm more a backend code / infrastructure guy), so when I do some web UI work, I have to re-learn exactly how much of a pain it is to have to cater to the needs of a bunch of different browsers, each with their own quirks and irritations. Suddenly supporting a bunch of different Linux distros seems so much less frustrating.

More than a year after gnucash upstream made the transition from glib1 to glib2, Debian has finally been able to do the same with the binaries. Problems in g-wrap and gnucash had led to libglib1.2 remaining as part of the dependency chain of gnucash as well as libglib2.0-0 (build-deps and runtime).

NMU's of g-wrap and gnucash have finally removed the last vestiges of libglib1.2 from my systems. Yippee!

My Overview showing the incoming packages which will migrate into the NMU section in due course.

g-wrap

gnucash

Seeing Yellow seems to have encouraged hundreds of people to contact their printer manufacturers and complain about tracking dots. Lots of reports (like this one) are popping up on blogs and being sent to me in email. There are reports in upcoming magazines. And as far as I know, nobody has been visited by the US Secret Service yet. I spent half an hour on the phone with HP. I filed a technical support request about the yellow dots and had to speak with the engineer for a while before I was able to convince him that this was definitely not a malfunctioning printer. He checked out seeingyellow.com while on the phone with me and seemed to be genuinely shocked and concerned. He said he would talk to the other technical support people in the color laser group and would write up a report to send up the chain of command. I even had him promise not to turn me into the Secret Service. Please, lets keep the calls coming! We really are making a difference. Another thing people might do is call laser printer manufacturers before they buy a printer and talk to sales representatives. Demand an assurance that the printer they sell you will not surreptitiously print intentionally identifiable information. Explain that you will buy from the first printer manufacturer who can give you such an assurance. So far, no company has. I was thinking about how it was slightly funny that Brother prints tracking dots in their color laser printers. One might say that tracking dots are courtesy of Big Brother, and Big HP, and Big Toshiba, and Big Xerox, and all the other big printer color laser printer manufacturers.

We went camping this weekend near Nominingue, northeast of Mont Tremblant. It was fun -- we met our friends Jeff and Anne-Marie, who'd biked there from Tremblant during the day. Maj and Amita June and I brought tons of food and big tents and stuff in the car. Our drive up was nice; Amita kept saying, "Camping!" every few minutes to emphasize how excited she was about going camping. She's getting much better about longer road trips. She entertains herself, reading books or telling herself stories or looking out the window and thinking out loud. Occasionally we sing songs or color together. The night was rainy, though, and Amita June slept in a dry but loud tent all night. At about 6AM she woke up angry. "Purple house, NOW!", she said, talking about our house in Montreal, with purple trim. "Shhh, Amita!" Maj said. "We're sleeping in the sleeping bag. We're camping!" "NO CAMPING!" said Amita. So the two of them got up and walked down to Lac Nominingue, while I got some rest. Later that morning, all the people in the campgrounds around us were smiling. "No camping! Camping no!" became a pretty popular refrain. Ah, well. At least they had a sense of humour about it. tags: amitajune laurentides camping travel maj jeff annemarie

Inefficient days Long day today. Brian got back from Halifax (Nova Scotia) on Friday, so we once again have a full house. Which is fun, but it makes it hard to work at home. I went out to Caff ArtJava near our house early this morning, but their le Sans Fil? connection was down. So I came home to pick up my bike to ride to La ka, but the back tire had a hole in it. And I didn't have a pump. Gar. So I spent a couple of hours working out that situation, and by that time I needed to go pick up our moving van. Maj found a great teak "wall unit" on Montreal Craigslist, and we need the shelves for our living room. So I got a van to pick up the pieces -- it was far too big to fit in our car. And, since my friend Niko wanted to go to IKEA, I traded him an afternoon with the van for help with my wall unit. He and Maj went off to IKEA as planned, and me at Amita went to the wading pool at Parc La Fontaine. It was a great time, although it's a long walk. I've had a hard time getting Amita onto the back of my bike -- she got pinched once when we were putting on her helmet, and since then she's wanted nothing to do with helmets, bikes, or nothing. If I force her helmet on and stick her in the seat, she loves it, but it's hard to trick her into it. She screams bloody murder when I try to put the helmet on her. But the pool was fun -- we chased each other up and down through the water. She fell asleep during the walk home, and I managed to get a little work done this afternoon. But Maj and Niko got back around 5:30, and Niko had a comedy show at 7PM and couldn't help me out -- the welcher! So I got Brian to come instead. The furniture was heavy -- really heavy. Teak is a heavy dang wood. Getting it out of the guy's house was really hard, and getting it up to our second-floor living room was Sisyphean. I'm amazed we didn't break any limbs. But at the end of it all, we had a great-looking new living room, and Maj had made a delicious gazpacho with polenta on the side. Yum! Hopefully the rest of the week is going to be more productive that today. Niko and I launch a new site at next week's DemoCampMontreal3 (as he so lugubriously pointed out in this blog post). And another group of partners will be launching kei.ki during Wikimania 2007, which is coming up soon. On top of that, we leave on Thursday for my brother's "commitment ceremony" in San Francisco, announced about 2 weeks in advance. We were lucky we had lots of miles so we could make the trip, but it still really cuts down on our Montreal summer experience. tags: maj furniture craigslist amitajune brian niko teak

Daniel Jacobowitz asked:

"Do these banks actually send billing information via email? The US banks I've dealt with (and other things, like most utility companies) only send you notifications to go to their encrypted web site to get your bill."

Good question. Actually, I don't know. I already have web access to my bank statements, so it would be strange to describe that as email billing. My emailed phonecoop bill is the actual bill as a PDF file attached to an email, along with a zipped CSV file containing fuller call data. I don't mind that being unencrypted too much because I download it from their mailserver with TLS, which doesn't seem too risky. Another phone company sends me an emailed bill as plain text, also unencrypted - I should go stop that one. Looking at the other utilities, it seems like two of them send email notices telling you to use their (horribly broken) web sites to get the bill, while the water company try to screw you if you sign up to their web services, and don't seem say how their system works. So, I'll not be signing up for any more of these just yet. What idiots are describing "email notices that ask you to download from the web" as email billing, which UK companies actually offer proper email billing and do any encrypt email yet?

Thanks to suggestion by Georg Lehner, Gammu Phone Database now support additional searching by supported features. So from now, you can easily search which phones support MMS (well I think this list contains few false positives, but that's what users have entered). In addition to this, you can grab data in CSV format. It does not contain everything what is displayed online, especially emails are not exposed at all, but it might be useful to do some more complex statistics or queries. Format of this file might change in future, so please be smart enough when writing some parser for it ;-).

In a comment on my post about memory errors Chris Samuel referred me to an interesting post on the Beowulf mailing list about memory errors. In that list posting Joe Landman says “it is pretty easy to deduce which chip is problematic (assuming it is ram) based upon the address” and then describes how to use Machine Check Exception (MCE) data from an error detected/corrected by the ECC system. Damn the vendors of motherboards for switching to 8-bit RAM just when it was about to be useful to have 9-bit RAM! 286 class machines had 9 bits of RAM per byte with one bit used for parity. Parity errors were extremely rare, largely due to the fact that memory errors could affect more than one bit at a time and therefore would often give a correct parity - if multiple bit errors were totally random then parity might be expected to pass 50% of the time! The Pentium was the first commonly used CPU to operate with a 64bit memory bus. If it had 9 bits per byte it would have had 72 bit wide memory buses - a Hamming Code could use this to detect and correct single-bit errors, detect all double-bit errors, and detect some errors involving more bits. This would mean that some errors would be recoverable and would display the location of the memory problem instead of being fatal and giving no information. Now it’s become a standard feature in servers to have ECC memory (at significantly greater cost) and most desktop machines don’t have ECC support - I wonder whether this is aimed at price-gouging people who need reliable servers (they can’t use cheap RAM from desktop machines). Unfortunately due to issues of electricity use, noise, and price I have to run all the servers that are most important to me on desktop PC hardware. Is anyone selling ECC RAM in desktop systems? I am particularly interested in machines that are a couple of years old so I can get them cheap at auction…

Share This

Like most geeks, I run my own mail server. The burden of administering it is much less than the increased flexibility in filtering incoming mail, let alone dealing with SPAM. My mail server configuration has remained pretty static the entire time, and controversially, I’ve always used qmail. The reason for this dates back to my first sysadmin job in the mid-to-late nineties, and the decision in those days did tend to be sendmail or qmail; with the security conscious choosing the latter. qmail’s delivery system is a little odd, everything on the left hand side up to the first “-” is considered a user, and everything after can be used for filtering. The default local delivery component takes this into account, so e-mail to scott-foo can be filtered by the /home/scott/.qmail-foo file. This gives a pretty natural way to deal with mailing lists; you subscribe with a unique address for that list, and all the mail goes into the right folder automatically. This has served me reasonably well over the years, with heavy patching across the daemon to add features such as LDAP integration, and SPAM filtering that I wanted. Unfortunately it’s been getting to burdensome to maintain. Since it’s not true open source software, and is effectively abandoned upstream, it’s not as up to date as I’d like. SPAM filtering tends to take place in the local delivery loop, rather than at SMTP time; and due to the strange delivery system, it’s unreasonably hard to perform any kind of sender verification or greylisting. Since every special address is filtered differently, it’s quite hard to add common filtering unless it’s pre-planned and you use addresses with a common prefix. The clincher has been dealing with super-sites like Launchpad which send huge amounts of different e-mails to a single address, and no facility to separate that from your published contact address. I needed a better mail server. So I’ve now moved to exim. I was surprised by how quickly I was able to pick it up, I did the migration in two day outages. The first to simply migrate delivery and stash the mail in one big folder, and the second to customise the delivery and filtering to my liking. I’ve also re-subscribed to mailing lists with single addresses again, so now I have a single filter rule which happily can filter Launchpad mails around as well. Happily I’ve been able to make a change I’ve wanted to for a while, home and work e-mail is separated into different Maildir/ trees; and mailing list subscriptions made with the most appropriate address. The magic of dovecot lets me create a fake scott+canonical user that uses the alternate Maildir tree, while still retaining my user permissions, etc. Overall I’m pleased with the new setup, and how the migration went. SpamAssassin needs some tuning as a little SPAM is still getting through, but otherwise it seems to be working well.