Don Marti writes about the idea of setting a Troll-bit on forum posts such that every reply would also be flagged. I’ve been thinking about how to solve such issues for mailing lists. I think that the way to do this is to create a new list for every contentious topic and automatically subscribe everyone who posted to the thread after the messages that were flagged as being too far off-topic. After that time anyone who tries to post to the main list with a matching subject or a header indicating that the message is a reply to an off-topic message would have their message redirected to the new list - and they would be automatically subscribed. This would keep the off-topic messages away from the main list and also serve as a minor dis-incentive for people to post to threads that start going off-topic as most people won’t want to be subscribed to the new list for off-topic messages. However such messages would still be archived (in a different section) so if the moderator mis-classified a thread it could still be reviewed by other people. Also when moderating such threads it would be interesting to experiment with consensus moderation of posts. If N subscribers of the list who post regularly use a web form to indicate that a certain post was too far off-topic and should spawn a new list then that could happen. I agree with Joey Hess’ rant about forums, so solving a problem for forums is not of interest to me, but hacking on a list server is something that I would do if I had enough spare time.

Share This

It's our second wedding anniversary on Monday, and because Sarah's not been to Napa Valley yet, and because this is probably the last opportunity to spend a bit of quality time away together before the pitter-patter of little feet, we've lashed out for a nice weekend away. We're staying two nights at the Gaia Napa Valley "hotel". It's really nice, but a lot more like a motel in most respects. I really like the environmentally-conscious initiatives they've taken though. I can highly recommend it, and the day spa attached is also excellent. Oh, and they have free wireless, which whilst surprising given how much they charge for things like in-house movies, is also a bonus. It was good enough to make laptop-based VoIP calls with. Today, we drove around aimlessly after our massages, in search of wine tastings (it was handy having a a ready-made designated driver). It seems the wineries here are all into charging for tastings, which in my opinion is a bit of a deterrent (in some cases) to purchasing. The charge varies between $5 and $15. Some wineries seem to refund the cost of the tasting if you make a purchase (which seems like the way to go in my opinion). We stopped for a late lunch at the Rutherford Grill, where I think I've had the most awesomely delicious rack of barbecue pork ribs I've ever had in this country. I cannot recommend that place enough. Apparently their rotisserie chicken is also to die for. We picked up thirteen bottles of wine in our travels this afternoon, so for the first time in ages, we'll actually have something in the wine rack at home. Tomorrow we're going on the Napa Valley Wine Train, which looks like it'll be fun. So now Sarah can say she's seen Napa.

Yesterday, a Spanish court decided to ban a sex cartoon of Spanish Royal Family. It was published by a satirical magazine, called El Jueves, which publishes every week cartoons of Spanish Royal Family, among political cartoons, or others talking about different issues. I am not going to argue here if this is censorship or not. I think that freedom has some limits, and if they have been surpassed, people doing that has to be judged. What I want to write about is more related to information and how it flows nowadays. As we have seen here, it is completely impossible to stop some document from spreading around the world in some hours, with hundreds of websites talking or showing it. Call it globalization or Internet. The effect is the same, information flows more quickly than what can be controlled. The measure taken by the court was the seizure of all copies of that magazine. Of course, reaction from other media was to publish the news including the banned cartoon. Also, tens of blogs show it, both in Spanish and in English, which has made that international media and news agencies also got the news, contributing to its spread even more. Soon, a local cartoon, that usually would be only knew by usual readers of El Jueves, has become a worldwide news item, with millions of people looking at it, commenting, republishing. And everything came from a bad choice: the court tried to set fences to information. This issue reminded me what also happened last two days, when waiting for the last Harry Potter's book to be published, it was known that it was yet available in every P2P netwok, and that some people had yet received it at home. Even, today, some newspapers published plot details of the book.

I'm working at the Palo Alto Coworking Space today for a few hours, since I'm in Palo Alto and since I'm interested in coworking. It's a great, open, airy space with a good WiFi connection and a lot of couches, windows, air and light. Good spot to work. It's also attached to the Socialtext office. Ross Mayfield just announced that they are seeking a new CEO, so I thought it'd be a good idea to throw my hat in the ring while I'm in the neighborhood anyways. Liz Henry caught me on virtual film. tags: socialtext wiki ceo2.0 sign coworking

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.

According to Jurij Smakov's announcement, the Debian port for 32bit SPARC machines is about to be retired. This is really sad in my opinion, as we should rather support more architectures instead of less architectures. After all, Debian is "The Universal Operating System" [1]. Now, I know that my opinion doesn't matter much in this case, but many other people who own sparc32 boxes seem to feel the same, judging from the thread which was started by the announcement. Also, I do realize that nobody wants to retire the port just for fun. To my understanding there is one major problem which needs to be sorted out in order to "save" the sparc32 support in Debian (and also in Linux!): There is no Linux kernel maintainer for the sparc32 Linux code at the moment! This seems to be the root of the whole problem. It makes maintaining a Debian port for sparc32 really hard, as you can surely imagine. Also, there seem to be too few people who actively work on the surrounding toolchain stuff (gcc, binutils, etc) which is also very important. My suggestion would be to not drop the Debian support for now, but rather set the status to "needs help" or something and actively search for contributors and/or maintainers. Heck, list it on Unmaintained Free Software, or write a "call for help" Slashdot article, post the issue on all Linux-/Debian-/SPARC-related mailing lists etc. etc. (or write funny blog posts, heh). I guess if two or three experienced SPARC developers would step up and take care of the kernel and toolchain maintenance for sparc32, there would be no reason to drop it anytime soon. Anyone?

What should have been a routine “remove DIMMs and run memtest until things work” procedure to solve a memory error became a lot more complex due to poor error handling in Xen. The following error occured because the tdb database /var/lib/xenstored/tdb was corrupt. To fix it you must rm the file and kill the xenstored process (which will otherwise recreate the file with the same corrupt data). It took me a few hours to work this out. # xm create -c smtp
Using config file “/etc/xen/smtp”.
Error: (28, ‘No space left on device, while writing /local/domain/0/backend/vbd/
18/768/online : 1′) Strangely the command “/etc/init.d/xend restart” does not restart xenstore or xenconsole (which is why running “/etc/init.d/xend stop” before rm’ing the file didn’t do any good). After fixing the above problem I encountered the following error condition. It seems that there is no support for restarting daemons such as xenstored. So I had to reboot the machine. After that it worked. # xm create -c smtp
Using config file “/etc/xen/smtp”.
Error: Device 0 (vif) could not be connected. Hotplug scripts not working. I’ve filed Debian bug 433780 about this.

Share This

It seems that moving a cat is *really* expensive! We're not willing to consider sending her to a shelter just to be killed, but we're hoping to find someone in Montreal, Kingston or Toronto who can take her and love her.

She's 13 years old, declawed, likes to cuddle up. She can be a bit tempermental, but can be pet with a bit of practice. She's been feeling a bit put-out lately since Leif has been born, so someone willing to love her alot would be really appreciated. She's in good health and doesn't need any special pills or food beyond the usual "older cat" food.

Comments here or jbailey@raspberryginger.com if you're interested or know someone.

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

Not so long time ago i used to be a hardcore photography taker. I would carry a camera everywhere i went, and took hundreds of pictures. I even had a darkroom where to develop my b&w films. But digital came, and it was easier to shoot, check, re-shoot, erase,… you know, all the “benefits” you get with a digital: you care less what you are shooting because it is inexpensive to erase what went not-so-good. It all started again getting into shape last month, before our trip to Spain and France, when i gave my girlfriend my Polaroid camera. She was amazed and bought some film for it. In Barcelona we found a lomography shop, where i purchased a fisheye2 camera. And it finally happened 2 weeks ago when i revisited a flickr.com page of a guy who lives in NY and takes pictures daily. I was amazed, and following some links i ended up learning about Lomography.com and the Lomo LC-A’s. It was monday last week when i purchased a sealed, unused Lomo LC-A for 80e and few hours later i had my first film in several years in the shop for development. Now it is 2 weeks later (almost) and i have purchased few other items: a wide angle for my serviced old Pentax ME-1, few 120 rolls for my Yashica D, some more 35mm rolls for it (i will mod the case with some foam to insert 35mm rolls and take full 3.8×6 takes), an Olympus XA, a Minox 35ML and a couple of old FEDs. All together for less than 350e. My flicker page already reflects the activity i have been enjoying here and there. I admit it needs some cleanup, some pro upgrade and some descriptions added, but with time i will get there.

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.

In answer to zobel's post, here is how to fight efficiently against those nasty spams. Well, there is a wonderful tool, called clamav that you know already for sure. What is less known is that there are people that have had the idea to use clamav to fight spams as well. They provide constantly renewed spam signatures that fight against the jpgs/gifs/... that are too many those days. I use this script twice a day to update my signatures, and it works well. I use this setup on a medium sized mail server with excellent results, here are the numbers for the last 30 days. The mail server had:

 2.357.038 connections attempts
 1.841.425 mails have been greylisted[]
 ---
   510.193 mails have been rejected
   238.869 of those thanks to clamav (~50%) 
 ---
   502.580 mails have been accepted for delivery
 1.564.130 mails have been delivered to users

As you can see, on 4 mails that are considered for delivery (after the greylisting), 1 is rejected thanks to clamav. That's 25% of the incoming mails that get simply dropped, and that has almost 0 false positives^[2]. Another note about greylisting: a quick reader could think that 1.8M - (2.3M - 0.5M - 0.5M) ~= 0.5M of mails are greylisted for nothing. That's not the case at all, the 2.3M are connection attempts. And we have some SMTPs that we talk to a lot (as it's the mail server of the Alumni of my school, we talk to the school MX a lot e.g.) and some of the connections carry up to dozens of mail on a regular basis. Our estimation is that in a regular day, greylisted mails that are submitted again are around the thousands, meaning some dozens of thousands a month, which is ridiculously small. And among them, sadly, most are still spams. These good ratios exists because we use conditional greylisting: we greylist IPs that look suspcicious only. But I already talked about that, and it's not really the matter of this post.

Patrick Sinkewitz has tested positive for testosterone, and German public broadcasters ARD and ZDF have instantly canceled reporting on the tour except for more doping "news". The Germans broadcasters are going out of their mind in their witchhunt. Luckily the rest of the world seems more sensible. A.S.O. asks whether they're supposed to stop doing tests if apparently one positive is enough for ARD and ZDF to cancel everything. Manager Luuc Eisenga of the T-Mobile team asserts that newspapers will keep on reporting about business news even if one company is accused of fraud. Dutch public broadcaster NOS says: "We're here to report on what happens in the tour, not to exercise moral judgement over it." I'm happy that I can just continue to watch the tour even if one cyclist crosses the line.

due to the constant high volume of incoming spam containing attachments
which are not easy parseable for our filters, the listmasters decided
now to block the following types of attachments: Content-Type: image/(gif jpeg)
Content-Type: application/pdf This is only a temporary solution, until we have better methods to
filter out spam mails containing these types of attachments. If you know better solutions, let us know! listmaster

I’ve just uploaded a new version of reportbug-ng including an Italian and a Hebrew pony and a cool enhancement to the buglist filter: Now the filter doesn’t try to match the whole string anymore but splits the input by whitespaces and tries to match all words. Now you can even exclude words by prepending a leading minus to it. The Syntax for the filter is: [-]keyword [[-]keyword2] ... Multiple keywords are separated by whitespaces and can have a leading minus. A leading minus means “exclude” the whitespaces represent the logical AND. Some Examples:

• foo bar -baz means all bugs containing the words foo, bar and not baz
• outstanding -wishlist means all bugs which are outstanding and not wishlist
• -resolved will show all open bugs

Please note the the filter does look into the actual bugreports (the fulltext), it currently tries to match against the packagename, the bugnumber, the summary, the status and the severity. The best thing about this new filter? It’s not even slower than the old one, the only delay you’ll notice is when filtering packages with a huge amount of bugs (like wnpp) and even there the filter just needs a fraction of a second. The delay of a few secons comes acutally from the QTable when I remove all the rows not matching the filter. QTable.hideRow(int) and -showRow(int) seem to be very expensive even when I temporary disable all graphic updates for this widget during this operation. If someone knows a trick to circumvent this, please tell me (you may get a pony…). This feature isn’t spectacular, but it should make filtering big buglists a lot easier.

Today I found an e-mail with the subject re new sm thing in my inbox. I almost deleted it, as I thought it to be spam with explicit content of some kind. On second thought, I did write a program called sm recently, so I read the message and indeed, no spam, just comments to the program. A bit like LaTeX where, when you google for it (especially on google images), you do not get results related to the excellent type setting program...In other news, screen-message has been featured on debaday today. I also got a bunch of nice feature ideas, but I m reluctant to implement them: I want sm to be a very simple tool, with no thinking or docs reading needed. I m afraid that if I implement all the nice ideas that others and I have, sm would become a big, complicated beast but I m keen to hear your opinions on that.

Currently at GUADEC. We had the joint OpenedHand/Collabora party last night, which explains the headache I guess. Also I'm glad I bought spare jeans because somehow a glass of Pimms managed to get all over them. I also saw KDE 4 running today. Best quote: Well at least maximise works. Alex's GVFS talk was good this morning, I totally love it and can't wait for it to land in glib. The file monitoring API alone makes me want to have Alex's babies (but it appears I've been beaten to it). I've already written an application using libgio, which was amazingly simple. It's a shame that so many people were asking questions during the talk instead of waiting until the end, because he had to skip the last few slides.

If you use quilt to manage your patches, particularly in Debian packages, you may be interested in reading this. If you just want to try it, here’s my ~/.quiltrc:

 QUILT_PATCH_OPTS="--unified-reject-files" 
 QUILT_REFRESH_ARGS="--no-timestamps --no-index" 
 QUILT_DIFF_ARGS="--no-timestamps --no-index --color=auto" 
 QUILT_PATCHES="debian/patches" 
 QUILT_COLORS="diff_hdr=1;32:diff_add=1;34:diff_rem=1;31:diff_hunk=1;33:diff_ctx=35:diff_cctx=33" 

Of these, I would recommend everybody to use --no-timestamps, both in diff, but more importantly in refresh. It omits timestamps in the resulting diff, which helps when doing debdiff and else. I find the other one, --no-index, also useful, but that’s probably a matter of taste; it omits the SVN-like “Index” header. --color=auto should probably also be there; it’s just like in ls, it colors diff output if stdout is a terminal. If you don’t like the default quilt colors, you may want to try the QUILT_COLORS option above. Or just adjust it to your needs; figuring out the name of each color item took a bit of digging, so you may find it useful even if you don’t like my colors. Finally, I’ve found that setting QUILT_PATCHES to debian/patches is useful to have quilt work even on a clean tree where there is no patches symlink in the toplevel directory. --unified-reject-files produces reject files in unified format, which I find more readable. I hope somebody finds some of this useful. :-)

Bruce Schneier writes about Correspondent Inference Theory which deals with situations when the motives of an individual or group are inferred by the results of their actions. Both his article and the MIT article on which it is based only consider the results of terrorist actions against the US and allied countries. I believe that this is a serious mistake by Bruce, the MIT people, and most people who write about terrorism. The most sensible writing about Terrorism is by Noam Chomsky. Noam considers the definition of Terrorism in both propaganda and literally. By the literal definition of terrorism the US government is responsible for more than it’s fair share of terrorist acts performed around the world. There is no reason to believe that people in the Middle-East are any less intelligent than people in the US and Europe. It seems obvious that some of the people who’s countries are destroyed by violence sponsored by the US government will believe that the US is entirely inhabited by blood-thirsty monsters. The number of US citizens who realise what their government does and approve is very low as is the number of Muslims who know what Al Quaeda does and approve of it. The US government claims that it wants democracy in the Middle-East, and Osama bin Laden claims to want the US military out of the Middle-East. If the US forces were withdrawn from Saudi Arabia then it would probably lead to a significant increase in democracy in the region (it couldn’t get any less democratic) - both sides could get what they claim to want. The discussion of the MIT paper seems to be largely based on the fact that Correspondent Inference causes the US government (and other governments) to decrease the probability of doing anything that might meet the terrorist goals. But no-one has mentioned the possibility that the same may apply to the probability of non-state organisations doing anything that might meet the goals of the US government. The wars in Iraq and Iran have significantly decreased the capabilities of the US military, they can’t recruit enough new soldiers and the current soldiers have reduced effectiveness due to long tours of duty with short breaks. The US economy is stagnating partly due to the direct effects of financing the wars, partly due to the way the airline security theatre has hurt trade and tourism, and partly because everyone has been concentrating on other things instead of fixing the economy. When two states have a war there is always the possibility of it being ended by a peace treaty or one side surrendering. With modern communications fighting can end in a matter of hours after a cease-fire has been arranged between states. But when non-state forces are involved things become much more difficult to manage. A state can make a deal with one non-state group only to discover that another non-state group (or a dissident faction within the original group) doesn’t like the treaty and continues fighting. With non-state terrorist acts connected to Al Quaeda in the US, the UK, Spain, and Indonesia (and more acts apparently planned in other countries) it’s obvious that we aren’t going to get a clean or quick solution to this problem. It seems to me that the only way the US and allied countries can escape from Correspondent Inference is to withdraw from the Middle-East entirely. If the people of Iran or Palestine want to elect a government that you don’t like then let it go (that’s what democracy is about anyway). If a dictator seizes control of Iraq then either leave him in control or provide air-support to any province that wants to rebel and establish a democratic government. Either make a stand on the principle of support for freedom and democracy or do nothing on the principle of letting people in other countries sort out their own problems. An invasion for the wrong reasons might fool people on the other side of the world but is unlikely to fool many people who live in the target country.

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.