I wrote SPI gives away opensource.org and opensource.net and Bruce Byfield wrote SPI to transfer domain names to OSI - I think it's interesting to see how differently we view the disagreement. One possible reason for the difference is that the email discussion around this resolution happened on private lists. I saw the December meeting notice a couple of days before the meeting, sent the board a request that they fix member communications and then started a discussion about giving away the opensource domains with:

"SPI still holds the opensource domains because SPI is a membership controlled organisation and OSI was a self-perpetuating board; and OSI had not done enough to balance their bad licence proliferation work. Why isn't that mentioned in the proposal? Why does 2006-11-18.dbg.mjs.1 not mention 2005-07-26.bp.1? Is it good to keep reposting rejected proposals until they pass? Why is the SPI board being asked again to surrender the domains while OSI is unreformed?"

The reason I started the discussion on spi-private was Josh Berkus writing

"If you think it's important that we should drag it onto spi-private, though, I suppose we should."

which rather suggested a private list was the appropriate venue. As Neil wrote:

"Some discussion has occured on the spi-private mailing list as to how the opensource.org resolution has been handled by the board."

That's putting it mildly. I wrote about the lack of public discussion (as mentioned in my previous report):

"I still don't see how some board members reconcile their votes to give away community assets with their promises. How the devil does board expect members to oversee it when board hides its operations from our view?"

There is a report on the discussion at the next meeting, which will hopefully put the reasons on the public record at last. Unsurprisingly, the first January 2007 meeting agenda omitted my member communications request, but board member Jimmy Kaplowitz accepted my reminder.

Aigars Mahinovs mentioned that it would be nice if applications would not clutter the home directory with their config files as much. I agree a lot. Dotfiles for configuration suck badly. If you start a new application (or if you are in an early stage and have a small userbase), please follow the Freedesktop.org XDG base directory specification. I.e. use .config/applicationname instead of .applicationname for configuration files (unless an overriding environment variable is set), and .local/share/applicationname for data files. And for cache files, use .cache/applicationname (anyone writing a patch for firefox?) What I'd also like to propose is to reduce the number of different configuration file syntaxes. It sucks having to find out which syntax an application uses again and again, because every application is different. We probably won't be able to convince everybody on one format, but we could maybe cut it down to, like 3 formats, please? There is no reason that one application needs to start comments with "#" and another with ";" while a third application uses "//" but doesn't allow "/* comment */"... A small set of syntaxes (preferrably with standardized parsers) should be good enough for just about every application:

• key=value pairs, quotations optional, comments match "^\s*#"
• ini-style configuration files with limited nesting
• JSON syntax (nesting, all strings quoted)
• XML files (arbitrary nesting, mixed contents, repeated elements)

If we had just these few syntaxes and an appropriate schema description language, we could write generic configuration file editors. That would be very nice. Also we avoid having config file parser bugs by using libraries, and if someone prefers using e.g. gconf or dconf, this could be handled by the library, transparently for the application. (Note that many application lack error handling when writing their configuration files, especially when the disc is full... - they really should be using a library. IIRC xchat also has some bugs of this kind, I remember having tried to patch some of them once when we were preparing for the sarge release, just to find out that there might be many more of them...)

Belgium has decided on a € 60,- flat rate tax to use their highways. I'm not opposed at all against paying more for scarce resources, like asphalt, but prefer a system where there's more differentiation: pay extra for using roads at peak hours. The thing is that Belgians are compensated for the 60 euros but foreigners are not; a visitor is therefore punished to come to Belgium. I never expected that the Vlaams Blok-xenophobia would extend even in this direction. Thanks for the hospitality guys!

How often in life does one find a traffic light lying at the side of the road? And how many of those times does it concern a buslight? Well, it happened to me: I found the buslight shown here at the Archimedeslaan. It is the type of traffic light that only applies to busses, trams and their public transport friends. I believe this is specific to The Netherlands, so here's a diagram of the possible layouts (top row). It runs on 40V power, but as I had a maximum of 19V available (not counting the 230V from the wall) it looks a bit faint. The bulbs look like the same ones used in car lights, and everything you can do with the unit (open, replace lights, reconfigure light positions) can be done without tools. Nice design. I called the contractor that maintains the city's traffic lights, Dynamicon, and the guy on the phone said he'd pass my information on but didn't believe they needed it anymore. Now only to find a good use for it...

About a year and a half ago (has it been that long already?), I blogged about wanting to write some gobjects. People did give me pointers to some documentation then, but for various reasons I never looked into it in detail afterwards. Since yesterday, though, that's changed. For the last two days, I've been writing on something which I'll eventually release to the world as libgjs:

wouter@country:~/code/c/libgjs/src$ ./gjstest 
There are 1 joysticks on this system
Joystick 0 is a Logitech Inc. WingMan Gamepad Extreme,
	with 10 buttons and 4 axes.
wouter@country:~/code/c/libgjs/src$ 

Wonderful, isn't it? Obviously the above doesn't require the 306 LOC that I've written now (which isn't much, but that's mostly because I had to read a lot of documentation in between); but when finished, the API of that library will be approximately something like this:

if(gjs_joystick_get_max>=0)  
	GjsJoystick *joystick = gjs_joystick_new(0);
	if(joystick->buttons >= 1)  
		g_signal_connect(joystick, "button-pressed",
			start_firing, NULL);
		g_signal_connect(joystick, "button-released",
			stop_firing, NULL);
		g_signal_connect(joystick, "axis-moved",
			move_crosshair, NULL);
	 
	gjs_joystick_set_interval(1);
 

where start_firing, stop_firing and move_crosshair are, obviously, callback functions (they get the button or axis number as a parameter). The set_interval function sets the time between two polls of the kernel device file; this will use the glib mainloop, but it'll also be possible to use a different event loop with gjs_joystick_poll and/or gjs_joystick_poll_all. As of now, it's almost finished; only the signals seem to be something I'm having issues with still. But that's only a matter of not having used gdb enough—I'm sure I'll get there. What gave me the sudden idea to write this library? Something silly, really: for a project I'm currently negotiating, it might be nice if I knew how GObject works; and what better way to find that out than by writing something fun for it? Exactly. Update: Bugs squashed, and the library (along with a small test/demo application) is available. Please try it out and let me know what you think.

Yesterday I went to see An Inconvenient Truth with Hieke at LHC: the documentary by Al Gore about global warming. Already a classic, and well worth a visit. Gore is an excellent, erudite speakererudite, has convincing arguments and is surprisingly humourous. The film consists mainly of a recording of a speech he's been giving for about twenty years on the topic of global warming. He supports his views with clear arguments. The film is not at all fatalistic: a good point was his emphasis that we need not "go from denial to despair" but that it's actually quite well possible to solve the problem. If there's policical will. The only downside is the distinctly "American" flavour that the film has: intermezzos about his family and some emotional personal events in his life. And every person that Gore quotes is "my friend". But these points are really minor. A must see.

Web applications suffer from a lot of security issues. This may be attributed in part to the ease of use of the most popular web scripting language, but I think the most important cause is that it's inherently easier to exploit web applications. They run in a browser that will run JavaScript code that has access to login data when any small piece of information hasn't been explicitly sanitised. While one would not recognise copy-pasting rm -rf / from a web page into a terminal as a security issue, when a web application user clicks a malicious link it is, because these links can be obscured in various ways. A relatively new issue is the Cross Site Request Forgery (CSRF/XSRF). In short: a malicious site has a hidden form that POSTs to the web application. If the user presses some harmless-looking button, it will be submitted to the original web application which then accepts it because the user has the right cookie. There have been lots of web applications that have introduced some kind of shield against CSRF, mostly it boils down to the form having a random string inserted which is checked upon form submission. I do not think that this is sufficient: it will fend off the most simple attacks, but an attacker investing a little more time can use things like AJAX to request the form from the remote website, get the random string out of it and put it into the malicious form. Won't this kind of "protection" only provide a false sense of security? Is there a technique that web application developers can use to to thoroughly prevent CSRF with their app?

Then I look at the destruction these cats have caused. I look at the damage to the really nice dining suite we bought shortly before moving over here. The leather chairs are scratched terribly. The nice wooden table top has scratches in it as well, because they liked to use it as a playground. I was setting the table tonight because we ve got people coming round for dinner (it s been a while), and I saw first hand the extent of the damage. I was so pissed off I could have cried.

If you have a little patience, you can cut their nails either with a cat nail trimmer (5 euros I paid, and that s the best money I ever spent on these cats, aside from neutering) or plain normal human nail clippers.

I have been doing it for Vi and Emacs since they were kittens, and then for Jazz when he replaced Emacs and who had never had his nails trimmed. I even do it for Lola, who is declawed and a very alpha female cat, on her back paw's nails.

Sure, it takes patience, it is best not to do it by force, so wait until they are happily asleep and pet them, then cut one. Get them used to you touching their nails, by making them go out of their claw when you pet them. Do one nail at a time, until they are all used to it and will just let you go through the whole 4 paws at once.

You can google around for techniques, but start reading this. The whole about.com site is filled with great advice for cat owners.

My furniture is still in good shape after two years of cats at home, yes, they love to bite the curtains, they scratch my favourite chair, they drop stuff on the floor and break it, they help me in whatever I am doing (painting, sawing, making the bed...), and they steal cat toys away from me and hide them in secret cat hiding places.

But things are just things, stuff is just stuff, curtains are replaceable, so is furniture. Start trimming their nails the sooner the better, and do not regret these three furry friends found you.

Here's my contribution to the next DWN:

Some developers continue to whine in inappropriate places [1] about others being paid by Dunc-Tank for their work on Debian.
[1] http://www.debian.org/News/weekly/2006/42/

Would you please cut down your childish behaviour a bit more? Can someone else maybe step up and do DWN instead? I'm sooo getting tired of this (and you). (Granted: at least you didn't claim that everybody is demotivated because of this, or that it delayed the etch release. Thats why I added the "more" in the previous paragraph; also what you wrote is likely correct - I can't judge your true motiviations, if you are actually demotivated or if you just don't like AJs hair color.) It's a very subjective point of view, and while somewhat marked as such ("because its editor can't ignore other duties while the Debian project is indirectly paying some developers"; however there are six editors listed at the end!) I find it inappropriate to put this into DWN (which should try to be obejctive). To me, it's just another lame attempt of you to voice your disagreement with Dunc-Tank (again, note that you have been heard by the whole community, there is no censoring being done) in an unfair way (because I couldn't voice my opinion in the same place). Did you at least talk about this paragraph with the other "editors"? (Note: I'm not directly pro dunc-tank, and I find the way AJ introduced it not too appropriate; my suggestion would have been to ask him kindly to step down from having a position in the dunc-tank board. However I'm certainly not demotivated by it, but I find it both good that key people of Debian are being paid without having additional responsibilities to some company, and that there is now a way to donate to Debian that won't just eventually maybe be used for something, but where I can clearly mark it for.)

Here's my contribution to the next DWN:

Some developers continue to whine in inappropriate places [1] about others being paid by Dunc-Tank for their work on Debian.
[1] http://www.debian.org/News/weekly/2006/42/

Would you please cut down your childish behaviour a bit more? Can someone else maybe step up and do DWN instead? I'm sooo getting tired of this (and you). (Granted: at least you didn't claim that everybody is demotivated because of this, or that it delayed the etch release. Thats why I added the "more" in the previous paragraph; also what you wrote is likely correct - I can't judge your true motiviations, if you are actually demotivated or if you just don't like AJs hair color.) It's a very subjective point of view, and while somewhat marked as such ("because its editor can't ignore other duties while the Debian project is indirectly paying some developers"; however there are six editors listed at the end!) I find it inappropriate to put this into DWN (which should try to be obejctive). To me, it's just another lame attempt of you to voice your disagreement with Dunc-Tank (again, note that you have been heard by the whole community, there is no censoring being done) in an unfair way (because I couldn't voice my opinion in the same place). Did you at least talk about this paragraph with the other "editors"? (Note: I'm not directly pro dunc-tank, and I find the way AJ introduced it not too appropriate; my suggestion would have been to ask him kindly to step down from having a position in the dunc-tank board. However I'm certainly not demotivated by it, but I find it both good that key people of Debian are being paid without having additional responsibilities to some company, and that there is now a way to donate to Debian that won't just eventually maybe be used for something, but where I can clearly mark it for.) [Yes, I am aware that others are just as annoyed by my responses to Joey&co. Especially when they happen to agree with him. Nevertheless he maybe shouldn't be abusing DWN!]

eBox is growing a lot lately, and updating screenshots is always a cumbersome task, so, prompted by a workmate, I decided to do something to get automatic screenshots. The first step was to get an automatic way to install eBox from scratch to have something to get screenshots from. That was quite easy using the Xen facilities available in Debian. I only had to write a role for xen-create-image and now I can get an eBox up and running in a couple of minutes executing a simple “xen-create-image –role ebox –hostname ebox-screenshots”. Using eBox introspection capabilities and some Perl magic, it was quite easy to autogenerate a list of the URLs that we should take screenshots from. Once we had the URL list and a running eBox all we have to do was to have a browser logging in the eBox web interface and loop through the URLs taking screenshots. To achieve that I resorted to Ruby, Konqueror, KSnapshot and DCOP, and it took less than 40 lines of code to do it. The first problem was spawning Konqueror and KSnapshot instances and getting a DCOP reference for them, but that was easily done using Ruby’s fork, which is quiet convenient:

konqpid = Kernel.fork exec("konqueror --geometry 1024x768+0+0")
ksnappid = Kernel.fork exec("ksnapshot")
konqwin = KDE::DCOPRef.new("konqueror-# konqpid ","konqueror-mainwindow\#1")
ksnapshot = KDE::DCOPRef.new("ksnapshot-# ksnappid ","interface")
The second problem I faced was logging in the eBox interface, I had to enter the password and submit the form. Fortunately Konqueror’s DCOP interface offers a really nice “evalJS” function:

konqwin.openURL("https://# ip /ebox/")
konqhtml = KDE::DCOPRef.new("konqueror-# konqpid ","html-widget1")
konqhtml.evalJS("document.getElementById('credential_0').value = 'ebox'")
konqhtml.evalJS("document.login.submit()")

and we’re in! Now we only have to loop through the urls taking the screenshots. I had a little problem because ksnapshot expects you to click the left mouse button before taking the screenshot. Fortunately that could be easily fixed using xte from the xautomation package to simulate the click.

urls.each url
konqwin.openURL("https://# ip /ebox/# url ")
name = "# konqwin.caption.split(/-/)[1].strip.gsub(/ /,'_') "
ksnapshot.slotGrab
system("xte 'mousemove 100 100' 'mouseclick 1'")
ksnapshot.save("# outpath /# name .png")

The code I pasted lacks a bit of initialization and some sleeps I put there to synchronize the stuff, but basically that’s all. I just love Ruby, KDE and DCOP

Zack asked for website meta languages for redoing his homepage. Well, I redid my homepage last february, using XML and XSLT. A monster XSLT stylesheet, because I wanted to keep my template outside of the stylesheet. I can not recommend XSLT. Using it for templating is quite messy. XSLT is okay if you want to transform one representation of the data to another; it's not if you want to add a lot of surrounding markup and things like a sitemap and similar navigation tools. This is next to impossible in pure XSLT, it gets better once you have some extensions (dubbed EXSLT, and supported by pretty much any xslt processor) or maybe with XSLT2. String manipulation is also a pain (at least with XSLT1); I gave up on generating a nice "last modified" date from my subversion tag. Supposedly XSLT2 has some functions that could make this easier (i.e. for parsing and printing datetime information), but the common approach with XSLT is to only supply the required minimum of function you need, and I'm not aware of an easy way to add custom functions, not to mention any large standard library that can efficiently be used (which is the true strength of Java, Python and C#, that they bring a huge collection of pre-written ready-to-use code with them). Of course there are some efforts to write XSLT libraries (especially for XSLT2), and this aforementioned EXSLT is some kind of standard library that even might be efficiently implemented in some interpreters - you can't rely on it to be there and to just work. XSLT isn't useless, but when it comes to presenting data to humans or writing clean, compact code it's not satisfactory at all. I'd give you my Makefile and XSLT file, if they weren't that messy... too many features; I'm generating two languages, a partially expanded navigation menu, etc. - my XSLT is 10k, my sitemap currently 4.5k, the template file is 5k. Anyway. Half a year ago, my favourite templating language was KID templating. I used it for some small projects such as my DNSoupdate tool to edit DNS zones via the DNS protocol (requires a nameserver such as bind which has support for DNS update, uses encryption). It was a perfect match for such tiny pages, but I'm no longer that convinced I still like it for larger projects. What's good about Kid: XML templating language, Python based, easy to use in whichever way you want by writing a few lines of python (i.e. easy to write a Makefile to generate a static version of you homepage) What's not good about Kid: only works with a Python interpreter. I'd prefer to have a templating language that can be used from multiple languages. However the Kid syntax relies on Python, which is really bad. Also I'd prefer to have some component-render model for more complex websites. The current setup is IMHO okay if you have one default layout and one content layout; but if you have multiple components that could be combined differently on the pages, it gets too messy. With my turbogears experiments, Kid was also not very performant (but that might as well be Turbogears fault). Right now, I'd probably still go with Kid. But I've been having a look at JSP 2.1, and JSF / Facelets in particular. There are some things about facelets that I really like (for example, that they use a proper XML syntax, instead of this bastardized almost-XML that JSP usually (ab-)uses). There is also some stuff that I don't like (e.g. the massive overengineering of everything surrounding it), and I have no idea how easy it will be to generate static pages in a scripted fashion, i.e. using it without a real webserver. Or I might just write it all in python, which is a nice language for manipulating XML, usually. Please don't just send me an email with your favourite templating engine. Like zack, I'm only interested in XML-based templating engines, which does not apply to most templating solutions out there. Clearsilver for example is another bastardization of XML. I'm aware of TAL/METAL, and find them quite interesting, but they were also not having this kind of componentization that I'm usually thinking in. [Update: some people have pointed me to Genshi, which is mostly Kid compatible. However, it still has mostly the same problems, e.g. the templates being not reusable in other languages than python, and that certain constructs are a pain to do (e.g. the page_specific_css recipe with more than one css file). Others have pointed me to smarty, but it's string-based and doesn't ensure valid XML output. (Which is very useful for e.g. generating atom or rss output) For example this is probably valid in smarty: if 0 <b> /if </b> - allowing errors is bad. Oh, and smarty is PHP, which is broken by design, a no-go. The best match to my ideas so far is XML::Template (for Perl, Python, Ruby, PHP) which is pretty close to what I've been doing manually when not using a templating solution. I don't know yet how well it handles recursion - I need recursive templates for the navigation menu on my homepage.]

Time for a gadget update. I've bought an iPod Shuffle last month which was an excellent buy. It's very simple and just does what it needs to do, nothing more and nothing less. Thanks Steve. Google was nice enough to send me a digital photo frame that can load flash cards containing photos, movies and mp3s. Thanks! It looks a lot better than all the loose pictures. I bought some technical stuff at the traditional IBA computerjunk-for-charity auction, namely an old spotty keyboard, two USB ports and a CueCat barcode scanner: .C3nZC3nZC3nZE3fZE3n1CNnY.bNjW.CxzZCNnWE3rZC3nZCq. It scans a lot of the items I have around the house, but I'm still not sure to what actual use I'll be able to put it. If Jaap succeeds on making a RAID array out of the two floppy drives he bought, I'm doubling his bid. XS4ALL sent me a 3 megapixel digital video camera (!), a USB Voice over IP phone and to top it off a gift voucher for a free vlaai. I'm overwhelmed with the generosity, thanks a lot guys!

So, today, I finally stopped the l10n NMU campaign. It started on Sept. 25th with the "Intent to Work" on hesiod. The last package I worked on has been isync today. The goal of that campaign was closing as many longstanding l10n bug reports as possible. The main goals were decided during the i18n work meeting in Extremadura, back in September. We focused on po-debconf translations, mostly, which are an easy target for NMUs. Thomas Huriaux extracted the data from the BTS and ranked packages with regards to the number of pending l10n bugs and their age. Lucas Wall reactivated a coordination page which we already used back in early 2006 when a first version of such a campaign was run. During that campaign, I worked on 102 packages. 89 of them got all their pending l10n bugs closed, 5 of them got most of their l10n bugs closed (remaining "l10n" bugs were either not really related to localisation and strange things which I left aside), 8 packages were ignored either because their respective maintainers wanted to handle the bugs themselves or because they were tagged for removal. Meny packages have also been handled by their respective maintainers, either because the NMU announcements woke them up...or because of their natural release process. I have to point out that the level of collaboration of package maintainers has been great (except for those who are MIA, and there are quite a few) with only one very proeminent exception (just guess which one). Thijs Kinkhorst and Tobias Toedter also contributed to the campaign. Thanks to them as well. As a side effect, we also made many of these packages as lintian-clean as we could, trying to balance between too invasive NMUs and trivial fixes. IIRC, I only introduced 3 or 4 RC bugs doing so (which I fixed immediately of course). A few RC bugs were also fixed by the NMUs and even a security bug has been hunted down (for screen). Meny thanks to all package maintainers, translators and everybody who helped during that work. It has been a great time. Just look at the result. Now heading to the improvement of the next pet project of the i18n task force: the Debian i18n server.

For various reasons, Software in the Public Interest (SPI) owned the domains opensource.org and opensource.net, which have been managed by the Open Source Initiative (OSI) for most of their life. This supported various SPI goals and also gave a possibility of community control of opensource.org/net just in case it was ever needed. OSI does not offer much opportunity for community control, as it is a self-appointing board. (Regular readers may remember that the principles of democratic member control, autonomy and concern for community are important to me.) I was watching as the SPI board voted in favour of giving away the opensource domains, proposal 2006-11-18.dbg.mjs.1 on the agenda. The vote happened without any discussion in the meeting. From memory (I guess logs will appear on the SPI site eventually):- David Graham ("SPI must also be involved in the promotion of and education about open source") proposed and voted for this action that stops SPI being involved in this promotion and education about open source; Michael Schultheiss ("I look forward to SPI's future expansion") (amended and?) voted for this action that reduces SPI; Neil McGovern ("achieve a greater degree of involvement [...] from the community in general") voted for this action that lessens SPI's involvement; Jimmy Kaplowitz ("It is important that it continue holding in trust the money and other legal assets belonging to its member projects [...] fulfill some more of its stated corporate purposes, involving education of the general public about free software and about computers in general") voted for this action that drops these assets and reduces involvement in education of the general public; Bdale Garbee ("would like to close this issue one way or another, once and for all") seemed willing to vote for anything which prevented further discussion - of course, only surrendering the domains could close it once and for all, as this is a one-way trapdoor topic - but had apologised for absence from the meeting; Martin "Joey" Schulze had apologised for absence from the meeting; Josh Berkus (nothing obviously relevant in his platform) abstained - consistent but disappointing; I think Branden Robinson was missing. Ian Jackson ("SPI's role is to provide a stable legal entity which can hold assets") voted against this action so that SPI would keep holding these assets. Bravo! Sources: The quotes above are the board's own promises in their election platforms, as listed on the SPI site in 2003 2006 apart from Bdale Garbee's platform which wasn't at the link given in 2004 so that quote is from the minutes of the previous meeting If some board members are willing to give away assets for no good reason, that strikes at one of SPI's core methods: holding assets for the community. What can we trust about this board? Their platforms are full of fine sentiments, but how do their actions reflect their platforms? This may be a mostly-dormant issue until the next election. If you want any of SPI's assets, just ask. If your request is rejected (as SPI rejected the opensource domain give-away before), just keep asking new sets of voters until they agree.

As anyone who follows my blog knows, I’m fond of linking to other sites with brief little quotes that either get me thinking or reinforce points I’m trying to make elsewhere. (Credit where credit is due: Dave Winer and Doc Searls both do this very effectively, and I’m just shamelessly copying them, down to the quoting style they typically use.) One of the quotes I’ve had queued up for a long time is this one from Jon Udell:

I have a confession to make. Sometimes, when I m trying out an unfamiliar open source component, I cheat. Even if the software I m working on will deploy to Linux, I ll sometimes develop it on Windows first. Why? Because on Windows, an open source component is likely to come with an installer that just works.

He’s right. Unless an application is included with your Linux distribution of choice, installing that application on Linux is a nightmare compared to Windows. Here’s an example. To install Sun’s Java Studio Creator on Windows, I just click on the .exe on Sun’s web site, which downloads the file and places it on my desktop. I double click the .exe (after, of course, checking it for viruses) and am up and running in a few minutes. In contrast, on Linux, I click on the .bin, which downloads the file and.. up pops a text editor showing me a /bin/sh script. Nice. Fortunately, I know what that is, so I save the script to a file on my desktop. I double click the file, and.. up pops a dialog box telling me the file isn’t executable. Nice. Fortunately, I know what that means, so I drop into a shell and run chmod +x ./creator-2_1-linux-ml.bin. I double click the file again, and there’s a nice graphical installer now. Finally, it looks like everything is going my way. Halfway through, though, the installation fails, telling me I need to install the RPMs for compat-libstdc++ and compat-libstdc++-dev. Nice. Assuming I even know what an “RPM” is, I then realize: I’m running Debian, and Debian doesn’t use RPM. Maybe I know about alien, but even if I do, where do I go about getting the compat-libstdc++ and compat-libstdc++-dev RPMs? At this point, I’ll probably hit Google—that is, if I haven’t already thrown up my hands in disgust and gone back to Windows. After a bit of Googling, I find this page, which tells me on Debian what I really need is libstdc++2.10-glibc2.2 and libstdc++2.10-dev. Of course! I should have known that. (Note: I’m being sarcastic.) After installing those two packages, I restart the installer (which, thankfully, knows how to deal with the fact that it’s already half installed, but that won’t always be true). The installation finishes this time, and the installer kindly offers to start the program for me. However, after poking around a bit and exiting back to the desktop, I don’t see a menu entry or a desktop icon, so I’m not sure how I’m going to find it again (and I hope I don’t have to explain why cd’ing to ~/sun/Creator2_1/bin is not an answer). Anyone who has ever installed software on Linux is familiar with this song and dance. If it’s in your distro of choice, you’re only an apt-get or a yum install away from running it. But if not, you’d better know what you’re doing, have a lot of patience, and understand how to construct effective Google search terms. (And, no, moving everything into the distribution is not a very good option. Remember that one of the key tenets of open source is decentralization, so if the only solution is to centralize everything, there’s something fundamentally wrong with this picture.) Oh, well. At least I didn’t have to check for viruses! Fortunately, some of the problems I experienced are bugs. The above was done on a pre-release Debian etch system over the summer, so it’s likely the problems have been fixed. I repeated the experiment on an Ubuntu edgy system, and it didn’t open the text editor, nor did it complain about an incompatible C++ environment. However, there were still no menu entries or desktop icons, and there was an additional problem too in that when I double clicked the file, it opened it in CrossOver Office, which I also have installed. Regardless, even if it works better on some distros than others, there’s still no usable solution until ISVs and end users alike can depend on things consistently working regardless of the distro being used. Again, fortunately, we have solutions to parts of the problem already. The LSB abstracts away the differences between the runtime environments of the various distros, so the Java Studio Creator installer could have simply said “you must install the LSB environment” rather than trying to deal with the hundreds of little variations in both the environments and the package namespaces that provide them (e.g., compat-libstdc++ vs. libstdc++2.10-glibc2.2). Better yet, on distros that provide the LSB environment in their default configuration, the installer doesn’t have to do anything. And Project Portland promises to give us a consistent interface for creating menu entries, desktop icons and such things. However, far too few applications take advantage of the LSB today (though that’s changing), and Project Portland isn’t in any of the distros yet (though we’re looking at bundling its primary deliverable, xdg-utils, with the LSB 3.2 SDK to work around that). Finally, even though the LSB provides ISVs with a consistent way to create an LSB compliant executable, there’s no consistent way to deliver an LSB compliant application that’s easy to install and that integrates well with the distribution’s package system. Yes, the LSB includes RPM today, but for a variety of reasons, ISVs don’t want to use RPM, and as already mentioned, not all distributions support RPM natively. Fortunately, once again, this isn’t just a rant. The LSB tackled these very issues at the LSB face to face and Packaging Summit last week in Berlin, Germany, and we think we have a way forward that’s acceptable to all involved: Linux distribution vendors who already have well established package systems and systems management tools built around them; ISVs who need to support multiple platforms and so don’t want to support the Linux specific RPM format or who otherwise want more control over the installation experience; and end users who want to use the software management facilities their distributions provide, whether that’s RPM or something higher level like APT and yum. More in part 2…

Makers of Dojo, Prototype, jQuery and Mochikit, I salute you.It is immensely gratifying that there are those with the courage and sense to make JavaScript in the browser workable for the rest of us. Like many busy developers, I've steered myself away from hacking JavaScript for many years. Cross-browser incompatibilities, the troubles of debugging and the relatively small reward for effort have kept me focusing on the server side (not to mention the temptation JavaScript poses to those prone to stray from the REST religion).This is now starting to change. The immense efforts of JavaScript developers are providing frameworks that allow developers to work on the client side with something approaching the elegance and concision that we can now wield on the server side.One of the wonderful things about the web is that it has become the forum for its own improvement. JavaScript has ensured that this is now true of the browser too. New techniques can be proved in script before they ever need baking into a markup language.Even the most ardent of declarative programming hacks will appreciate the way toolkits such as jQuery allow painting of behaviour onto pages rather than littering semantic markup with snippets of script.The problem that faces us now is: which JavaScript framework to choose?As is my habit in programming languages, I've found myself move from framework to framework depending on the actual tools available. Starting off in Prototype as it came with Rails, paying a happy visit to jQuery because of Thickbox, considering Dojo because of its rich text editor, and now being wowed by Plotkit and thus checking out Mochikit.So, here's an idea for aspiring XTech presenters: we'd love to hear more about these toolkits. Experiences, future plans for the kits themselves, and how developers should choose between them.

• XTech 2007 call for participation. Closes this weekend, so hurry! 

The other day I had was tinkering with that cute little poster child of Web 2.0, Flickr. Looking for a lightweight way to incorporate some photos into a web site, I headed to their feeds page to find some XML to use.Before you read on, don't forget that the XTech 2007 call for participation ends this week. The result was interesting. Flickr have a variety of outputs in RSS dialects, but you just can't get at the raw data using XML. The bookmarking service del.icio.us is another case in point. My friend Matt Biddulph recently had to resort to screenscraping in order to write his tag stemmer, until some kind soul pointed out there's a JSON feed.Both of these services support XML output, but only with the semantics crammed awkwardly into RSS or Atom. Neither have plain XML for public consumption (some is available behind a registration protected API), but do support serialization via other formats. We don't really have "XML on the Web". We have RSS on the web, plus a bunch of mostly JSON and YAML for those who didn't care for pointy brackets.Did we as supporters of XML get it wrong somehow? I think we did. The success of the XML project and the W3C as a unifying forum was seductive, and we felt more bound to the edicts of the W3C than we thought. Our justified love of open standards inadvertently promoted a straitjacketed approach to using XML. XML was felt to need a schema language.What we missed was that settling on schemas for data serialization represented much more of an up-front commitment than most developers could really make. The rise of agile programming techniques further emphasizes the hazards of prematurely freezing a design.Schemas never really came with great evolution or migration strategies.
And of course it didn't help that both DTDs and W3C XML Schema are pretty darn obscure. Somehow we never got the word out, despite the "standalone" XML declaration, that it's OK to spread schema-less XML around.We had of course the Simple XML movement, but it came to little. Other voices pointed the way forward. Walter Perry notably promoted an agenda that required little a priori agreement between communicators, but it gained little ground in common thought. Ironically it took James Clark to push the agenda of developer convenience, with the RELAX NG compact syntax giving us all permission not to think in angle brackets.Meanwhile, busy developers with work to do on the web have created non-XML syntaxes such as JSON and YAML. Though I deliberately closeted myself in XML for a long time, I have come to appreciate the utility of these syntaxes.One of the more intriguing developments is that the Semantic Web crowd, while still very much W3C oriented, have really proved themselves more flexible in their attitude than the XML world at large. RDF/XML is hardly the only acceptable way to approach the throne of Tim, and the man himself threw out XML syntax pretty early on with the development of the N3 scribble format. More recently, the work on GRDDL to scrape semantics from HTML has shown the semweb folks' amenability to outside initiatives such as microformats.Maybe it's not such a bad world, as making an XML mapping of YAML, JSON and friends isn't really very hard. I'd just like to get the message out to web application developers that Plain Old XML is fine by me. I live in hope yet that the rise of REST will hit this home.So while markup has most definitely won on the web, it's a shame XML hasn't yet achieved as much as it could. It's not too late for an injection of pragmatism and a little less constraint.

On our recent stay in London we passed through Neal's Yard: a nice and tranquil enclosure in the busy Seven Dials neighbourhood (Covent Garden). Here you'll find a number of establishments that cater specifically to those that can appreciate a vegetarian or organic lifestyle. Right around the corner is Neal's Yard Diary, an excellent cheese shop, selling only cheeses from the UK, including of couse very good Stilton and Cheddar. The neighbourhood around Seven Dials sports a number of nice specialty shops. Well worth a visit. We had dinner at the Souk Medina restaurant. Surprisingly large when compared to its modest entrance, it serves a large Moroccan menu with plenty of vegetarian choice. The entourage may remind one of Efteling's Fata Morgana, without being over the top. Seated at knee-level tables on comfortable pillows, we enjoyed a range of Moroccan specialties, a bottle of wine and a pot of mint tea. The price was very modest. Highly recommended!

Back in June, I wrote about my switch to VPSLink for my virtual private server (VPS) host.

Now it's 6 months later, my initial contract is up, and it's time to consider whether to renew it.

Overall, VPSLink has worked out reasonably well. I have their Link-4 plan, which provides 512MB RAM, 20GB of disk storage, and 500GB of bandwidth for $40/mo (or down to $33/mo if you pay for 12 months in advance).

Reliability and Uptime

VPSLink has been reasonably reliable. I wouldn't say that they have been exceptionally reliable, though.

Some outages:

• Back in July, the server was down for more than 8 hours. vpslink support blamed it on filesystem corruption; they rebooted, the system came up, FS went into readonly mode, so they went back down for fsck. I don't know what FS they use.


• In October, an outage of about 30-60 minutes that apparently was due to load problems on the host. The control panel also was broken during this time. Apparently there is a reboot queue, and the system can only reboot one customer's VPS at a time, and everybody wanted to reboot. But the UI was not really designed for this situation and presented very confusing status messages.


• In November, a kernel panic caused an outage of about 60 minutes.


• Various other outages that were resolved fast enough that I never emailed them about it.

They have generally responded to support requests in a reasonable amount of time, and support has been approximately as helpful as I'd expect.

Overall, there've been a few issues but, aside from that 8-hour outage in July, nothing especially remarkable.

Automated Tools

VPSLink has a "control panel" where you can reboot, start, or stop your virtual machine. You can see how much bandwidth you've used in a month, your IPs, and billing information.

You can also create support requests and view the status of support requests there. You can also view all correspondence on a given ticket, and add new correspondence to it -- a nice touch that's useful if your email is down because your VPS is down.

The reboot/start/stop facility didn't work during one outage, though.

Resources

The 20GB of disk space is nice to have, though I never used it all. No complaints there.

But the memory setup is rather strange. This may be because VPSLink is using OpenVZ instead of its more popular (and featureful) commercial counterpart Virtuozzo, or something such as Xen.

Those that have used OpenVZ/Virtuozzo know there is a /proc/user_beancounters file in the virtual environment that reports on the limits of resources allocated to your virtual server. VZ lets the server admins regulate the amount of resident RAM, swap, inodes, pending IP connections, amount of virtual RAM, etc, etc. About 3 dozen items in total.

Unlike some companies like JohnCompanies, VPSLink was not willing to make any adjustments to this file for me. For instance, my mail server may need more simultaneous open files than they have by default, but they wouldn't work with me to make reasonable adjustments.

But the larger problem was with regard to RAM. This was particularly annoying. VPSLink does not permit any access to swap, so the 512MB is what you get. But tools like top show the entire memory allocation on the host, and are mostly useless in tracking down your own usage.

You can look at the privvmpages entry in /proc/user_beancounters to get an idea of your current usage, but that's it. There is a script on their wiki that will turn this into a more useful number, but again, it's not the most helpful.

The minute you try to allocate anything past 512MB, your processes start getting killed. According to /proc/user_beancounters, even though my system normally hovers around 70% of that 512MB allocated, I've had 290,567 instances where a process has been refused its request to allocate memory since the last reboot. Such instances usually cause a process to crash.

Other Virtuozzo companies like JohnCompanies will give you "burstable RAM", so if others aren't using their full RAM allocation at the moment that your machine goes over your regular limit, you can go over it to a certain extent. That was very effective at preventing crashes during times of higher than usual memory usage, and I never had trouble with this at JohnCompanies.

I've had a lot of trouble with VPSLink because of these hard, no-exceptions limits. Getting hit by the Google bot at the same time as the MSN bot could raise memory usage enough that processes would start getting killed. Depending on which process it is, it could take down cron, apache, the mail server, whatever. And there is no log of which processes die because of this.

In normal circumstances, this wouldn't pose even a noticeable impact to a server; inactive bits could be swapped out, etc.

I am also suspicious of exactly how OpenVZ calculates memory usage. Since moving to a physical Linux box, my memory usage seems to be much lower than the privvmpages would seem to indicate, even though it's running the exact same code.

So I had some outages on my server that were caused by OpenVZ memory limits, which didn't get listed in the overall outages above.

This problem is the #1 reason I'm leaving VPSLink.

Performance

Overall performance has been acceptable. The CPU speed appears to be reasonable and about as expected.

The disk performance has been more problematic, however. It tends to be rather slow. There have been times when I can type "ls" in a directory with about 10 files and it takes 5-10 seconds to respond. And I wasn't even using "-l".

Now that sort of thing is certainly the exception. But it makes databases -- and websites that rely on databases -- very slow.

The performance measurements over at RealMetrics also show VPSLink as being at the bottom of the pack for disk performance.

Overall

VPSLink is a reasonable value, and if monthly cost is important to you, probably a good choice. Don't expect it to be spotless, though. I would call the overall experience pretty average. Nothing too spectacular in either direction in any respect.