Roger Cicero will be going for germany to the Eurovision song contest. With his song "Frauen regier'n die Welt" ("Women rule the world"), which he sings with the impression of being able to himself rule any woman. :-) His mix is very uncommon: it's swing, but with german lyrics, about love and life, flirting and with a well-dosed amount of macho in it, but not serious but always joking and cool. YouTube has some video clips with his music. Note that I don't think "Frauen regier'n die Welt" is his best song. Scroll down at least to "Murphys Gesetz" ("Murphys Law", and congrats for not incorrectly adding an apostrophe, it's correct this way...) Last.FM has some excerpts from songs I like better. I don't know if 'we' have any chance with him (last years' winner was Lordi, some 'schocker' hard-rock-heavy-metal band dressing up like halloween monsters), but he won't come out last for sure. Demographics of the Eurovision contest aren't too favourable for germany, nor are are European relations. But being a swing dancer, this is just really cool, because it gives my hobby a wider audience. :-) P.S. If you want to learn Swing dancing in Munich: the Lindy Hop course at Boogie-Bären starts again this tuesday, and I can also recommend the classes of Swing and the city (thats Cat and Chris); there is a beginners and intermediate workshop next weekend with world champions Markus & Bärbel together with Cat and Chris. And of course every monday there is a teaser class at Cord. P.P.S. I'd really love to see Roger Cicero perform together with some good Lindy dancers as show act. Probably a different song then, though.

I always assumed the diff algorithm to be quite standard and used anywhere there is a diff function, well it seems it is not, and it also seems that human readability is very dependent on the tool you use: Here is what diff -u, git diff and tla diff give:

@@ -42,10 +42,9 @@
 include $(DEPTH)/config/autoconf.mk
-include $(topsrcdir)/config/rules.mk
+EXTRA_COMPONENTS = nsKillAll.js
-libs::
-       $(INSTALL) $(srcdir)/nsKillAll.js $(DIST)/bin/components
+include $(topsrcdir)/config/rules.mk
 clean::
        rm -f $(DIST)/bin/components/nsKillAll.js

This is the least human readable output. In comparison, svn diff, svk diff and bzr diff do output:

@@ -42,11 +42,10 @@
 include $(DEPTH)/config/autoconf.mk
+EXTRA_COMPONENTS = nsKillAll.js
+
 include $(topsrcdir)/config/rules.mk
-libs::
-       $(INSTALL) $(srcdir)/nsKillAll.js $(DIST)/bin/components
-
 clean::
        rm -f $(DIST)/bin/components/nsKillAll.js

Mercurial outputs:

@@ -42,10 +42,9 @@
 include $(DEPTH)/config/autoconf.mk
+EXTRA_COMPONENTS = nsKillAll.js
+
 include $(topsrcdir)/config/rules.mk
-
-libs::
-       $(INSTALL) $(srcdir)/nsKillAll.js $(DIST)/bin/components
 clean::
        rm -f $(DIST)/bin/components/nsKillAll.js

which is pretty similar. I got too fed up with tla and baz to try more (and didn’t even go up to committing a file in baz, so there’s no diff result for it)

The book SE Linux by Example has been reviewed on Slashdot.

The issue of Perl scripts was raised for discussion. It is of course true that a domain which is permitted to run the Perl interpreter can perform arbitrary system calls - it can therefore do anything that SE Linux permits that domain to do. This is in fact a demonstration of how SE Linux does the right thing! If you want to restrict what can be done when executing the Perl interpreter then you can have a domain_auto_trans() rule to have Perl run in a different domain.
Restricting Perl (as used by one particular program) is actually easier than restricting a complex application run by users such as Firefox. Users want to use Firefox for web browsing, local HTML file browsing, saving files that are downloaded from the web, running plugins, and more. Granting Firefox access to perform all those tasks means that it is not restricted from doing anything that the user can do.

A claim was made that a novice users would not understand how to use SE Linux. The fact is that they don't need to. I know many novice computer users who are running SE Linux systems, it just works! It's more advanced users that have to learn about SE Linux because they configure their machines more heavily.

The essential difference between path-based access control and Inode based access control is that the standard Unix commands to control file access (chmod, chown, and chgrp) all operate on Inodes. If a file has 1000 hard links then I can restrict access to all of them via a single chmod or chcon (the SE Linux command that is comparable to chmod) command. AppArmor does things differently and implements an access control model that is vastly different to the Unix traditions. SE Linux extends the Unix traditions with Mandatory Access Control.

Granting different levels of access to a file based on the name of the link which is used is a horror not a feature.


I wrote this as a blog entry rather than a /. comment because my lack of Karma means that less people will read my /. comments than my blog.

South-by-Southwest is well and truly over now. I had a really good time. I don't have quite as much fun at general-Web conferences as at wiki-specific conferences, but I think it's also healthy for me to look outside my own narrow niche every once in a while and see what other people are doing. I think overall the conference was pretty great, although I don't feel like the passion of 2006 was here in 2007. I will say that I find it disconcerting that there are so few wiki people at SxSW. I think there should be considerably more, and I'm going to urge some intelligent and thoughtful people to come to Austin next year and get on panels. Practically every aspect of blogging gets covered at SxSW, but mine was the only wiki-specific panel this year. We're taking a week on the coast near Galveston to recharge batteries and get our work lives back on track. Then it's off to Las Vegas for the IA Summit. Maj will be in the conference area -- I'll be baby-sitting at New York New York or something. tags: sxsw07 austin wiki galveston las vegas

Dear LazyWeb Two questions:

• N800 movies. What ffmpeg or mencoder or transcode parameters should I use to convert video to run on the media player on my Nokia N800?
• Zip code of Canada. In the US, when you try to charge a tank of gas using pay-at-the-pump, frequently you're asked for the ZIP code of the billing address of your credit card. But if your residential address is in Canada (or anywhere outside the US), you don't have a ZIP code attached to the card. I usually go inside to the cashier and pay there, but I wonder: is there a special code you could use (like "00000") that means "I don't have a US ZIP code"? If not, why not?

Thanks for any answers (see Contact for how to get them to me). tags: lazyweb n800 zip code credit card canada

Twittering again It seems like Twitter is waking up from its own SXSW07 hangover and sending out the thousands of backlogged twits that weren't delivered at the right time. I don't think in the age of EC2 any public Web site should go AWOL due to too much traffic. Twitter suffered just the kind of surge that EC2 (and S3) are there to solve. tags: twitter ec2 sxsw07

(Update: Yes, Gunnar, the policy says that the debian/rules file must be a makefile, so if you do something else, you have a serious bug because of a policy break. Of course, probably there is nothing that should stop one from using, let's say bash, or python or perl, from a technical PoV.)

Erich has a wish list for Lenny.

What draw my attention was the very first "define and deploy a standard way of packaging software, that can be used for like 90% of packages", later he mentions rationale "other distributions (e.g. *BSD ports, Gentoo?) are ahead of us in this respect, having a standard way of packaging and building things and keeping track of changes."; these two quotes contain the real essence of Gentoo's success in the area of fast development.

A half a year ago I did an experiment in packaging a rpm, a deb and an ebuild for the same piece of software. What I observed back then made me think a lot about the entry level knowledge needed for a person to create a decent package for those types of package systems.

With the risk of being flamed by many people that will miss my point, I will tell you from the start that the deb would have been the most painful if had to start from scratch. Second would have been the rpm due to lack of good/updated documentation and the clear winner in lack of pain points was the ebuild. In reality places were switched between the deb and the rpm.

And before I start, please understand that what I want to point out is that the building system in debian is showing its age and we should do something about it, and is not about pointing people to documentation; it is about making things behave more sanely by default and not about having to read a whole day to understand why the package fails to install a file you just added then to find that you had to add the destination path to a debian/dirs file etc...


The deb had to be the most difficult. Not because I didn't do it before, or because it was hard, but because there are a lot of things that need to be done because the package management is not smart enough to do it by default (i.e. class inheritance does not exist, like is the case for the ebuilds or the macros for rpms).

The Debian approach is backwards, is reversed with regard to the others and the way it should be by default, to allow easier understanding of the packaging. You can, by default, make a package that is tweaked a lot. There is no concept (if you don't count cdbs which is boo-ed a lot by some people) or possibility to just say "make this package a package that is a standard linux app with the regular ./configure && make && make install recipe". And I don't count such a recipe the templates based on dh_make, that is way too verbose. A new maintainer wannabe has difficulties understanding why are those lines in there, and what they do, and most importantly, why is that order correct and no other. Another question which is legitimate is "is that the minimum or can that be trimmed"? (Follow debian-mentors and see how many people leave the .ex files just because they are afraid they will not know how to generate them again.)

Even the rpm has a concept of standard stuff to do for a package, there are some macros that implement that. And that is more logical for an untainted mind (as in not yet debianized) than what we have in the dh_make template, or worse, a clean and new debian/rules file. Why should one care to learn the ways and philosophy of make just to make a small package?


Let me tell you something that will feel like knife stab for many people in our community: the clear winner was the ebuild, not because I was smart or exciting, but because:

• it was dead simple to make a working one
  
• the documentation is really verbose and complete
• there is a default behaviour for every ebuild, even for a minimalist ebuild
• if your ebuild has a special need, the ebuilt can override the default behaviour by redefining the function (target, in debian/rules-speech), but you don't need to, in most cases
• there are some already defined classes which can be inherited to obtain a tweaked default behaviour (imagine typical cmake build system, typical autotools build system, typical kde build system - and iirc, this can include build dependencies)
• all the information about the package is centralized in one file which is human readable from the start, plus that is obvious, or one can understand fast what a field/function/variable means from the start, without digging through the documentation continuously
  

I did the ebuild in one day's work (it was less, but some will not believe me, so I'd say 1 day is reasonable enough) starting from absolutely 0 knowledge about the packaging system (if you don't count knowing to emerge package as knowledge).

What is done properly in the portage system is the fact that there are some default classes which your ebuild can inherit to behave more like a certain type of packages (base - a generic recipe, gnome, kde, games, sourceforge - they download tarballs directly, if needed - ...)

Why this is not possible for deb right now? Simple, we have it as a rule in the policy that the debian/rules file is a makefile. So even if one would implement a class-like model for deb packages, you'd still have the debian/rules file as a make file...

Gentoo implemented initially portage's default behaviour (and as a consequence, the "classes") in shell, later they migrated some parts to python and the whole portage is implemented in python now (while classes are implemented in bash). I am not saying that we should put python in essential, God forbid, probably the emdebian guys would stab me :-), I am saying that possibilities exist, alternatives should be possible.

I know, some will just say "show me the code", "making such a change over the entire archive is insane" or "the makefile is a really good way to do things like installing and building, after all, that's what it was designed for". Yes, all of these will miss the point, which is having nothing-to-do as a default policy for a package is a bad policy, it should be an empty/default package will use a standard recipe to build itself, and that recipe should be implemented in the build system.


And if you still don't believe me, just look at these few ebuilds and tell me you'd not be able to write them after a quarter after seeing one the first time and skimming over the docs or/and knowing what a regular gentoo user knows (what a keyword is, what is a slot). Also compare with the debian counter parts and don't forget the different building aids that we have.

http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/amphetamine/amphetamine-0.8.10.ebuild?view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/amphetamine/debian/rules?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/amphetamine/debian/control?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/amphetamine/debian/postinst?op=file&rev=0&sc=0

http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/holotz-castle/holotz-castle-1.3.8.ebuild?rev=1.3&view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/holotz-castle/debian/rules?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/holotz-castle/debian/control?op=file&rev=0&sc=0


http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/late/late-0.1.0.ebuild?rev=1.10&view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/late/debian/rules?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/late/debian/postinst?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-games/packages/trunk/late/debian/postrm?op=file&rev=0&sc=0


http://sources.gentoo.org/viewcvs.py/gentoo-x86/games-arcade/ppracer/ppracer-0.3.1.ebuild?rev=1.15&view=markup
http://svn.debian.org/wsvn/pkg-games/packages/trunk/ppracer/debian/rules?op=file&rev=0&sc=0


One more thing, the ebuilds mostly need not be updated when an upstream release occurs, they just need to be copied and given a different filename.

Eddy Petri or wrote quite an interesting text about the shortcomings of the .deb packaging format, specially comparing it to Gentoo's ebuilds. And, basically, it all comes down to this phrase:

Why this is not possible for deb right now? Simple, we have it as a rule in the policy that the debian/rules file is a makefile. So even if one would implement a class-like model for deb packages, you'd still have the debian/rules file as a make file

Now... Is debian/rules really expected to be a makefile, or it is just customary for it to be so? Look at the very top of your rules files - you will see they (at least, almost) always start with #!/usr/bin/make -f - That means, of course, that you can omit the fact they are makefiles. While packaging/debugging, I often run -say- fakeroot debian/rules build && fakeroot debian/rules clean. That, my friend, is closer to the invocation you often use for a shell script than for a makefile. I don't know if we have tools that rely on having rules called via make (and that should be easy to correct if needed), but I really don't see it problematic at a first glance to create packages based on something different than a makefile.
Recently, I've been tempted by CDBS. I still don't fully understand its flow, and it's still mostly a dark-magic beast for me, but at least I am comfortable using it for my everyday packaging work (hey, pkg-perl group, I'll be bugging you again with my weird ideas soon ;-) ), but it surely has the advantages you quote in your message: It takes part of the complexity away. Of course, it introduces some extra bits. By using CDBS, the packaging entry level is considerably lowered - but the real understanding of properly maintaining a package becomes somewhat more difficult.
Or is it just me clinging to the comfort of having learned my way around writing debian/rules?

Eddy, while I agree that ebuilds look a lot cleaner, shorter or easier than typical debian/rules + debian/control, you should consider a few things:

• There is cdbs in Debian, which provides a lot of help in packaging “easy” packages. Note though that I don’t really like the hidden magic it does.
• ebuilds don’t have to handle architecture independent data, since Gentoo doesn’t have such packages. If Debian wouldn’t have architecture independent data, debian/rules would look easier immediately.
• Updating an easy package (i.e. one without Debian specific patches) to a new upstream usually is a no-brainer in Debian as much as in Gentoo.
• With ebuild classes, you still have to know/learn which class matches your package best, so you still need to know what each class actually does. That isn’t too different to understanding dh_* stuff, if you ask me.

So all in all, I’m quite certain that the amount of learning needed to create a correct ebuild is lower than that needed to create a Debian source package, but I don’t think that packaging for Debian is hard either. And finally, Erich is quite right that a central repository for all Debian packaging scripts would be a nice thing. However it would be quite hard to determine the right VCS to use for that. Most de-central VCSes I glanced over need manual intervention on the “server” side to include patches from local developer branches. And of course there is the problem of several packages having a non-clean upstream tarball they need to repack for each release as well as several packages having a tarball which includes more than one single upstream tarball. You would need to find a way to handle those as well.

Eddy, the problem with packaging software is that it is not a once-off thing, but the package needs constant maintenance, and for that, I need to be able to understand how the build process works (on a large scale). While at first the rules file generated by dh_make seems huge, it is actually quite easy to understand if you have the output of "apropos dh_" printed out and are not afraid to look at the occasional manpage.

Yesterday ICANN published an interesting article about last attack of root servers (6 February 2007): see http://www.icann.org/announcements/announcement-08mar07.htm . The paper is not so detailed and technical as one should expect, anyway it is worth to read it.

It seems that also the remaining root servers should move to anycast. I think this is good, but it will works reliable with TCP? Do someone use TCP to query DNS servers? Why is it not disabled? It seems that all root servers accept TCP ( dig @l.root-servers.net. . NS +tcp).

A side note: as you can see, root servers don't give you yet the IPv6 addresses of root servers. Now they do some test, prior to broke the root server 512-bytes packet rule. We are still away to the full IPv4/IPv6 inter-operative nets.

The last recommendation is: "ISPs should only accept DNS queries from trusted sources (i.e., their own customers) rather than allow anyone to use their servers." . This rule (on recursive queries) is already a well know rule, and I I think it is less problematic of mail-rely (ev. with SPF), but on the other side, we are moving to the point that we should trust our ISP and our ISP will firewall "non-proxied" traffic.

As last point, the fact sheet cite two wikipedia articles. Wikipedia is so good, or there are not better (updated) documentation on the net?

Christian is talking about problems with suspend-to-RAM and suspend-to-disk and the major cause of issue being the non-free Conexant HSF modem driver.

Since I got my new laptop I had my share of issues with suspend-to-*.

At the beginning everything worked fine, out of the box. Then (I think) I realized that my video card (damned ATI) was not working in accelerated mode, so I decided to fix that and since the card is too new to be even listed as existing on radeon driver's support page, I had to use fglrx.

Then I made the DRI work but suspend-to-ram ceased to work (after a few testing->experimental; experimental--> upstream updates, both ways); I started using the experimental driver (8.31.5-1) which proved to be stable enough (this time) just for suspend-to-disk, if it had dri enabled, or suspend-to-ram, if not having DRI enabled.

I even made a patch to help the maintainer update faster the package (I added a get-orig-source rule in debian/rules).

Now I have ported the patches in the debian package and updated it to 8.33.6 and I am running that. Problems include: consoles are not accessible, but suspend-to-ram and dri work. I will submit a bug with the patch to updated fglrx package.

I expect that I'll try soon to update to 8.34.8 in the hope that I will get all the things working: suspend-to-*, consoles, dri.

Web Hosting - A Market for Lemons

This is a really irritating problem for hired webmasters. Too often, my prospective customers go and buy from someone else who has a slicker sales team but does a terrible job. Then what can you do? I'm honest with them about the flaws if they ask, but it'll be months before they have the money to fix their mistake - or sometimes years before they can escape their contract lock-in. Depressingly, this ends with "we find that there really aren't any good solutions to the lemons problem".

RIMU Rules

Tip from a coop ISP about a global hosting provider.

xinit considered harmful

Warning about a bad machine supplier.

Web Hosting Chat - The Number 1 in Web Hosting discussion Forums - powered by vBulletin

Possible information source about web hosting

Project Management Source: Ten Golden Rules

If I tried a little harder, I could probably make a top 10 top 10s.

10 Stupid Mistakes Made by the Newly Self-Employed

I think I've done half of these.

10 Business Lessons From a Snarky Entrepreneur

A more positive list from the same author.

10 Ways to Relaxify Your Workspace

Could I even do Top 10 Steve Pavlina Top 10s?

problog: work from home

Oh OK, here's a different author. Are all of these positives, though?

Little Known Ways to Brand on the Cheap: 99 Tips for Poor Web Startups

I keep returning to this list. Lots of good ideas.

Digit news - Most B-to-B Web sites fail

and we need those good ideas, as the statistics are horrible.

A Cambridge Co-operator: Fairtrade Fortnight

This is nearly over. Rush to your local co-op, co-operative food, co-op scottish or Welcome to get a big discount now.

Co-operatives' merger to create group to rival Sainsbury's Guardian Unlimited Business

Soon we'll be bigger than Sainsbury's.

Co-operative Bank February 07 eNews

Where some of the profits from the co-op group goes...

A Cambridge Co-operator: Phone Co-op Annual Results

A different co-op which I'm also in.

VoIP for Business 2007 - Welcome to the essential business communications experience!

Interesting, but I still can't get my office VoIP phone to work reliably...

Are .com and .net domains best? @ Problogger

The masses say .com, but my three .uk domains are going fine for my target audience. I wonder about .coop and .eu, but there's not much incentive yet.

Margaret Hodge announces Companies Act Implementation timetable Small Business Service

Argh a confusing consultation. Is it worth replying?

I originally was quite reluctant to post on Planet Debian about the DPL race, but hey, this is the campaigning period, anyway. My choice not to go into too much detail about what I'll do about Debian seems to spark some confusion. I initially thought of adding a rather verbose explanation for that to my platform; but as the initial version of my platform got quite long and convoluted, it got cut. Perhaps that wasn't a very good idea, so here goes: One observation I've made over the years is that DPL candidates often come up with all sorts of grandiose plans about what should be done to improve Debian. These plans are usually the result of some observation they've made, and consequently some thinking they've put in so as to come up with what they think is the most reasonable solution to the problem at hand. The only problem with this approach is that, if you're not involved in whatever you have ideas on, you'll probably end up suggesting things which the people that are involved do not think is a good idea to do. Which would consequently mean that you'll either have to do it all by yourself (since you can't force DDs to do something against their will, and we have a constitution to back that up), or that they convince you that it's not a good idea, and you end up not doing whatever you promised to do during your campaign anyway. First, this is silly. If you don't know whether you can or will keep a promise, you should not make it. But apart from that, it's also a problem; if you get elected mainly because you promise to do one thing and then don't end up doing it, or do something else instead, then you've got yourself a very good reason not to be liked in the community. Which isn't something a DPL should aim for, I believe. So rather than coming up with a detailed plan of all the things I'd do once elected, I decided to come up with a detailed plan of all the things that need work. The exact stuff that gets done about them would then be decided after having a chat (on IRC or otherwise) with the people involved, directly or otherwise, and after considering what other people's opinion on the matter is, if I know said opinion. Does that give me a carte blanche, as Julien suggests? Well, yes and no. Yes, because every Debian Developer who runs for DPL is essentially asking for a carte blanche; after all, the DPL has the ability to speak for the developer body, unless overruled by GR. No, because I don't think doing whatever I want and everyone else be damned is an even remote sign of maturity, and because I promised not to seek the controversy in making decisions (while not avoiding it at all cost either).

I tried to setup VMWare today, to be able to have some virtual machines to test random stuff. My laptop only has a small HD, so I want to have all the VM stuff on my huge external USB drive. Also I only use them occasionally, so that pretty much rules out Xen. So I decided to give VMWare a try. VMWare has always been a desaster installation-wise. It took me like 5 runs to get it installed properly; you need to apply some patches or it won't work with current kernels etc. After these tries it had installed without any further error messages and the GUI also came up easily. However none of the VMs I created did anything; apparently they're supposed to at least show some BIOS like screen. Instead I only get the error message "Unable to change virtual machine power state: The process exited with an error: End of error message." And of course it doesn't tell me which process or anything else that could help debugging it. Shutdown also doesn't work properly - stopping vmware leaves a vmware-serverd process running that needs to be killed with -9. As usual, commercial software is totally disappointing. [Update: so neither the vmmon shipped with VMWare nor the one from vmware-any-any-update108 worked; keep your eyes open for update109. I managed to patch vmmon myself, in include/compat_kernel.h move the if/else part up to the front, as it is in update108.]

I just uploaded a minor update of Pyroman to unstable and the pyroman download page on alioth. I added support for a complete interface wildcard, and added example configuration files for a single-host setup. Pyroman is a firewall configuration tool I wrote for managing the firewall of a small network consisting of four zones and servers with a dozen different tasks. It plays very well in setups with DMZ, wireless networks, intranet etc. and all kinds of different services. Key benefits are the very simple syntax, safeguards (extensive syntax checks, rollback on failure, safety timeout option for remote administration), scriptability in python and high performance, since it does not run dozens of iptables commands, but generates a script file for iptables-restore. For more benefits, see the pyroman homepage. The next version will probably feature an XML syntax additionally; while the current Python syntax is very powerful and readable, it's pretty much impossible to write a GUI for editing the policy when written this way. That's why I'd like to add an XML syntax (that can be intermixed with Python statements, but only the XML-defined parts will be editable in the GUI) that supports the key parts of configuration (if you want the rules to be generated on the fly from some database or whatever, you'll still be able to do that in Python!): making it easier to write a GUI for it.

I just like open source too much to not be constantly bumping into things that I would love to improve or fix... I have way too much fun getting my hands dirty with something new. Today's adventure regards my need to stream large quantities of data from a ruby on rails installation, covered previously here: http://journal.dedasys.com/articles/2006/06/08/streaming-programmatically-generated-content-from-rails The current block is that ActiveRecord doesn't deal with a "stream" of results, but rather, fetches everything into one big, fat array and then deals with that. Luckily, I'm not the only person to have found this suboptimal: http://dev.rubyonrails.org/ticket/6921 However, as I comment there, to truly make things work, some low level coding is required. For mysql, since it doesn't seem to support cursors to the degree that something more standards-compliant like Postgresql does, the answer lies in the C library and language interfaces built on top of it: http://dev.mysql.com/doc/refman/5.0/en/mysql-use-result.html Unfortunately, Ruby's C API, or at least the versions that I downloaded, don't properly support fetching things one record at a time. It didn't take more than a few minutes to whip this up: http://dedasys.com/freesoftware/patches/mysql-ruby.patch (although there's a good possibility it could be improved...) However, according to this posting, the upstream maintainer may not be terribly responsive, and the project isn't really run as much of an open source project, with a public mailing list, bug tracker, version control, and so forth. Perhaps it's time to create that infrastructure?

Lots of short, sharp items today that I want to get down.

LinuxQuestions.org supports OpenID First, I'm psyched to see that LinuxQuestions Wiki now supports OpenID. Jeremy gave the scoop in The LQ Wiki Now Supports OpenID. I was glad to see that LQ's on the OpenID path. It's a really strong community site, and I think it'll benefit greatly from opening up the authentication process. tags: linuxquestions jeremy garcia lqwiki openid

Wikia and OpenID Angela Beesley had some comments on my Journal/7 Vent se CCXV posting about wikiHow's support of OpenID. In that posting, I said that I thought companies with lots of wikis, like Wikia or wiki farms, might have a disincentive to participate in the OpenID network. Angela put me straight on the issue in a post on WikiAngela about OpenID. I'm glad to hear that Wikia is considering supporting the protocol. Then again, it's hard to believe that an Open Content, Open Source company is really going to go out of its way to avoid open standards and open login. tags: wikia openid angela

DemoCampMontreal1 I had a good time last night at DemoCampMontreal1. I gave the first demo -- on, of course, the MediaWiki OpenID extension -- and I had some technical difficulties that didn't let me show off all the functionality. Which was kind of a bummer, but there were lots of questions about it from the audience, so that kind of made up my time. The room was packed, by the way -- pretty much anyone who's anyone in Montreal tech was there. I'm looking forward to DemoCampMontreal2 on 29 March! tags: democampmontreal1 openid montreal demo

certifi.ca One of the best ways to establish credentials on the Web is to use a signed SSL certificate in your browser. It's fast, incredibly secure, and once you get it set up you can just forget it. They're also practically immune to phishing. Unfortunately, most people don't even know what browser certificates are, how they work, or what to do with them. Consequently, most Web sites don't support browser certificate authentication. Vicious cycle. But, one of the cool things about OpenID is that you can disconnect the authentication method from the Web site you're using. Most OpenID identity providers still use username/password combos for authentication, which is why critics have said that the standard is vulnerable to phishing attacks. I wanted to see if it were possible to set up an OpenID identity provider that used browser certificates as the only authentication system. So, in my copious free time, I've hacked up certifi.ca. It's based on the cool PHP OpenID Server that JanRain made, but I've ripped out all the password stuff, and now it runs on luscious certificatey goodness. I'm going to be enhancing the service in the near future, but I wanted to get feedback from folks interested in OpenID as soon as possible. I'm using it for my primary OpenID delegate, and it seems to be working great. Please give it a try and let me know what you think (admin@certifi.ca). tags: openid pkix ca browser certificates certifi.ca

DemoCampMontreal1 on Montreal Poutine There's an article on DemoCampMontreal1 on Midnight Poutine. That's me up on the stage, in the photo! tags: me democampmontreal1 midnight poutine

Nepean Hotspurs Selects win On Saturday, a Muslim girl named "Azzy" Mansour, from Ontario playing in a soccer tournament in Laval was ejected from the tournament (by a Muslim referee, notably) for wearing a hijab -- reportedly because it was a safety hazard. (Montreal Gazette story, registration required.) Admirably, her entire team forfeited the tournament in protest. I'm not excited about Quebec's reactionary activity around Muslim, Sikh, and other religious community's different clothing rules. However, I understand that Quebecois -- and French people -- have a different idea of personal freedom than Americans. I try to be understanding and put myself in the Quebec headspace for this kind of stuff. Mostly, though: I admire the soccer team, the Nepean Hotspurs Selects, for standing up for their teammate and their friend. A lot of teams might have gone ahead and played without her, and it took some courage to drop out of a tournament they'd had high hopes for. They're sixth-grade girls, but they've learned something about integrity that most adults never learn. Kudos to them. tags: quebec hijab soccer nepean hotspurs selects

David, though I feel your pain with this, I think the PHP5 code is much closer to what other languages do and is therefor the following the “least surprise” rule. However, breaking existing code with a compiler/interpreter upgrade is of course a bad thing. But in this very special case, I think that the plus side puts in more weight than the negative side. When reading PHP code others wrote (which is what I do with PHP most of the time, with just a few hundred lines of PHP code ever written by myself), I always wondered why

$f=new Foobar();
$a=$f;
$a->do_something();
if ( $a->fetch() != $f->fetch() )
echo “they differ\n”;


would ever print anything. At least until I hit myself with the php-cluebat again, remembering that $a=$object assigns a copy of $object to $a, not a reference like most other languages tend to do.

I recently came across two old and unrelated writings about law, both of which are worth reading, especially for people with strong opinions but no formal training. The first is this piece, entitled Seven Ways in Which Code Equals Law (And One in Which It Does Not), by recently-appointed New York Law School professor James Grimmelmann and EFF Legal Director Cindy Cohn. Several observations are particularly appropriate for the slashdot crowd (and, to a lesser extent, certain members of the Debian community and others who grew up on a diet of BASIC, Pascal, and then C and later perl). I especially like this bit about “hacking the law”:

Some people, seeing this connection, and remembering the values of good code, try to improve the legal system by treating it as a computer. People come to me with ideas for hacking the law. The government says that cryptography is a weapon, they say, but the Bill of Rights says we have the right to bear arms. So that means we have a Constitutional right to use cryptography. But the legal system isn t a computer. If you can t convince a judge that what you re proposing is consistent with the values underlying a law, your argument will go nowhere. People go to jail every year because they think they ve found a way to hack the Sixteenth Amendment. The income tax is illegal, they say, or, The income tax is voluntary, see, it says so right here, and then they get convicted of tax evasion and sent to jail. We did convince several judges about the Constitutional dimension of cryptography, but the claim started from the values of the First Amendment, not a mechanical reading of its words. It s a category mistake to treat the legal system as just another architecture with its own specialized language. Code and law are different ways of regulating; they have different textures. All of those people who are required to make the legal system work leave their mark on its outcomes: they make a certain amount of drift and discretion almost inevitable. Code doesn t have such a limit: it can make perfectly hard-nosed bright-line rules and hold everyone in the world to them. Code is capable of a kind of regulatory clarity and intensity that law can only state, never really achieve.

I don’t entirely agree with the other article, entitled What I Ate For Breakfast and Other Mysteries of Judicial Decision Making by outspoken Ninth Circuit Judge Alex Kozinski (unofficial site maintained by Aaron Swartz, wikipedia entry). For example, I think critical legal studies has resulted in some interesting insights, some of which actually have practical applciation. Still, Judge Kozinski makes an important point about the numerous factors that act as a check on discretion in judicial decisionmaking:

It is popular in some circles to suppose that judicial decision making can be explained largely by frivolous factors, perhaps for example the relationship between what judges eat and what they decide. Answering questions about such relationships is quite simple - it is like being asked to write a scholarly essay on the snakes of Ireland: There are none. But as far back as I can remember in law school, the notion was advanced with some vigor that judicial decision making is a farce. Under this theory, what judges do is glance at a case and decide who should win - and they do this on the basis of their digestion (or how they slept the night before or some other variety of personal factors). If the judge has a good breakfast and a good night’s sleep, he might feel lenient and jolly, and sympathize with the downtrodden. If he had indigestion or a bad night’s sleep, he might be a grouch and take it out on the litigants. Of course, even judges can’t make both sides lose; I know, I’ve tried. So a grouchy mood, the theory went, is likely to cause the judge to take it out on the litigant he least identifies with, usually the guy who got run over by the railroad or is being foreclosed on by the bank. This theory immodestly called itself Legal Realism. Just to prove that even the silliest idea can be pursued to its illogical conclusion, Legal Realism spawned Critical Legal Studies. As I understand this so-called theory, the notion is that because legal rules don’t mean much anyway, and judges can reach any result they wish by invoking the right incantation, they should engraft their own political philosophy onto the decision-making process and use their power to change the way our society works. So, if you accept that what a judge has for breakfast affects his decisions that day, judges should be encouraged to have a consistent diet so their decisions will consistently favor one set of litigants over the other. I am here to tell you that this is all horse manure. And, like all horse manure, it contains little seeds of truth from which tiny birds can take intellectual nourishment. The little truths are these: Under our law judges do in fact have considerable discretion in certain of their decisions: making findings of fact, interpreting language in the Constitution, statutes and regulations; determining whether officials of the executive branch have abused their discretion; and, fashioning remedies for violations of the law, including fairly sweeping powers to grant injunctive relief. The larger reality, however, is that judges exercise their powers subject to very significant constraints. They simply can’t do anything they well please.

Finally, I will link, but not embed, this video of the Anna Nicole Smith court order, for an entirely different perspective on the legal process. You almost don’t really want to have to see this stuff.

A few days from now is the first BarCamp we've had in a while: DemoCampMontreal1. DemoCamp is a BarCamp variation with a much shorter time frame (a couple of hours, rather than all day) and strict rules about presenting. Demo-ers cannot use Powerpoint slides (or even OpenOffice Impress slides!); they have to demo working code. I'm going to be doing the first demo of the first DemoCamp, which should be pretty fun. What will I be demoing? The OpenID extension for MediaWiki, of course. I'd like to show folks who have MW installs how to get OpenID enabled on their sites, and I'd like to show other developers how to (easily) integrate OpenID into their existing software. I don't think it's necessarily that hard. DemoCampMontreal1 is on Tuesday, Feb 27 2007 at 6:30PM at the SAT. Everybody's invited, and as an extra bonus, t-shirts from BarCampMontreal1 will be there, for attendees. Cool! tags: democampmontreal1 democamp montreal barcamp democampmontreal barcampmontreal openid mediawiki wiki sat

MLUG now has OpenID Lurking in #mlug (Montreal Linux Users Group) on Freenode, I caught a cross-discussion about OpenID being enabled on http://mlug.ca/ . Which is great news -- I'm excited to be able to use OpenID on some of my favorite sites. tags: mlug openid lug

Creative Commons 3.0 I'm excited to see the announcement that the Creative Commons 3.0 licenses have been released. The 3.0 licenses were in part the product of the Debian-Creative Commons Workgroup, which tried to smoothe the rough edges of the CC licenses that made them incompatible with the Debian Free Software Guidelines. See the Debian Creative Commons Workgroup report for more info. We didn't get everything we wanted from the negotiations, but we did get the essential problems out of the way. I think that the 3.0 licenses are compatible with the DFSG, and that works licensed solely under CC 3.0 should be allowed into Debian main. But we probably have some discussion on debian-legal ahead of us on the subject. tags: cc cc3.0 debian

Dead tablet walking So, I think I mentioned that I borrowed a Nokia N800 tablet last week at the LWOSS. I took it to bed two nights ago -- it's a really good computer for reading in bed -- and the battery died on the nightstand overnight. When I plugged it in in the morning, it went into some kind of zombie fugue. It booted up, spun in place for a little bit, then shut itself down and rebooted again automatically. I couldn't get it to stop with the normal power button, so I eventually pulled the battery to make it stop. But if I put the battery back in, it went into its Roomba-bumping-into-a-wall loop again. Frustrated, I ended up re-flashing the entire system. That solved the problem, but I have to admit some regret at losing all my settings. It won't take that much work, but I'm going to backup to a mini-SD once it's done. tags: nokia n800 reboot loop