I am the psychotherapist. Please, describe your problems. Each time
you are finished talking, type RET twice. I am worried about Debian. Are you worried often? Yes! I see... Well, why do you say this is so? The Debian project seems to be quite dysfunctional. What makes you believe the debian project seems to be quite dysfunctional? We keep having these massive flame wars. Earlier you said you felt worried? What causes you to be worried? It doesn't seem right that a group of people who ostensibly have the same goal should bicker so much. And its the same topics over and over again. Is it because a group of people who ostensibly have the same goal should bicker so much that you came to me? Yes. You are a very cheap^wgood therapist. It has been suggested that Debian could profit from therapy. Does it bother you that debian could profit from therapy? I would hope that a group of mature, intelligent, professionals could settle their differences on their own. Maybe your plans have something to do with this? I have no plans really. I just want to work on a great Linux distribution. How does it feel to want? What we have built is so great but sometimes it seems that Debian doesn't get taken seriously when outsiders see all this infighting. What happens when outsiders see all this infighting? They think we are just amateurs and they wonder why they should make their future endeavors dependant on a bunch of flighty narcissists. Do you really think that?

No of course I don't. Debian is just as good if not better than most "serious" operating systems and most of the time Debian developers do work together well and settle their differences amicably. But there are a few people who can't and they really hurt our image. I see... Tell me more.

There are some people who just can't work with each other and our current way of dealing with such conflicts is at a dead end. As long as issues are left unresolved and they are forced together, these negative people will just keep bickering and bringing the rest of us down. What are your feelings towards bickering and bringing the rest of us down? I feel that at this point only answer is for the people who can't alter their behavior to be asked to leave or to remove themselves. What do you think? Speaking as a trained psychiatrist I think you are all bonkers and I'm switching to gNewSense.

While its not the normal action people usually expect from me, I just felt the need to have a little posting saying Thanks to somebody. Who? Well. All of you doing work on a regular basis, like * Application Managers, who regularly process people that want to get Debian Developer status. They are doing a lot of work, asking questions, giving tips and in the end submit their report. Usually thats a process of multiple days up to some months work, depending on the time the Applicant and the AM has. * FrontDesk. who makes sure that the process keeps on running by managing all sorts of weird things people come up with, * Sponsors, who help non-DDs to get their package into the Debian Archive, * The release team, who always tries to get the best possible release out of the door, * All those people that make Debian what it is - the biggest and best distribution ever, * everyone that goes and fixes bugs in debian packages to keep the quality as high as possible, * all people that help people by answering questions on one of our mailinglists, on IRC or in web forums, * every upstream author that releases his software under a free license and happily works together with distribution maintainers to make their software the best it can be, * all those that help to organize DebConf, the yearly Debian Conference with all the time-consuming tasks that that includes, * the people that keep the infrastructure running that allows us to develop our own little gems, like the Debian Admins, SPI Admins, Alioth Admins, IRC Network Operators and anyone who provides and maintains machines for a free project out there, * those behind everyone I mentioned - the families. Who have to look for something else during the time people do all the mentioned work, * everyone who can resist feeding a flamewar, Did I forgot someone? I’m sure I did, so - start your own post and say thanks, without people spending a lot of their spare time you would not have such a great distribution to use and ease your life! Have a good new year and continue the good work!

Two Fridays ago, on the 15th of December, I finished my support contract with Canonical. Last Wednesday, or just 5 days after leaving Canonical, was my last day working for LliureX, the Valencian Debian-based educational distro which is being developed by the Conselleria de Cultura, Educaci i Esport. Definitely an intense week... In both cases, terminating the contract was my decision. I was working for Canonical for a small amount of hours per month, and I enjoyed doing it as it allowed me to work along with the great people who are developing Launchpad in a unique company like Canonical, but at some point my stress started to pile up and freeing time for myself seemed a good thing to do. I also had been working at LliureX for 2.5 years and I was starting to feel I had to move on, as the project has changed a bit since I joined it and because I think I need to see new things and explore new challenges. And the challenge is called ITI, a CS research institute in the Universitat Polit cnica de Val ncia, where I'll start working in a pair of weeks thanks to ex-lliurex co-worker Sergio. My main task will be sysadmin work, but the ITI gets many interesting contracts every few months, and I suspect I'll be working with Debian and Ubuntu at work very soon. The new job is pretty close to my house and the idea is that being in the University campus and having some more free time will allow me to retake a few activities like completing my studies, resuming some of my triathlon training (you've gotta see the awesome athletics ring and olympic swimming pool just 100 metres away from the institute!) and other stuff I have been neglecting for way too long. I leave behind quite a few friends and many good people, and getting used to the idea of not speaking or chatting to them on a daily basis isn't that easy. To compensate, I'm sure I'll meet lots of cool people next year. Bones festes!

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!]

Watching my sister's Welsh boyfriend slowly learn Finnish, I'm reminded of the fact that the language is often considered difficult. At any rate, it is spoken by a very small percentage of the world's population. Some Finns therefore think they can safely use it abroad to talk about anything, even if it is embarrassing or sensitive. I've found that not to be true. There's other Finns everywhere. There's always someone who will hear and understand if you say something not meant for outsiders. A couple of anecdotes might prove this. In 1990, I was abroad for the first time, in Eindhoven, the Netherlands, for an ACM programming competition. I and a team mate spent one evening in a local bar, talking with each other. After a while we were interrupted by a Finnish woman who lives in Eindhoven. Luckily, we hadn't said anything too bad, she just recognized fellow Finns and wanted to say hi. In 1999, I was in London for a conference, and had a bit of free time, which I spent walking on Oxford Street. At some point, I was walking behind two young men, in their early twenties. They were speaking fairly loudly, commenting on the physiological features of the woman walking in front of them. The woman eventually stopped, turned around, and started swearing at them. Loudly. In Finnish. My theory is that Finns are slowly taking over the world by spying on each other abroad. That's why there's always at least two Finns anywhere.

Just finally got round to watching cars (bought it earlier in the week, just watched it, damned glad I bought it). I'm a pixar film fan, so when cars was announced as the last film last year before moving to another distributor I was a little pessamistic as to what the quality of the film was going to be, I must say, I'm still very happy with pixar - now, let's see what happens now that they're owned by the evil giant that is Disney - hopefully they'll still leave the pixar team as is and we'll get lots more quality films with lots of imagination behind them. (Yes, OK - I'm a big kid, and I also like most of the stuff that comes out of dreamworks studios, though they tend to have less story line - shrek is rather good though). So, yeah - just thought I'd post to say... If you haven't seen Cars, go get a copy, watch it, it's fun :) In case I totally avoid mentioning it tomorrow (quite likely), Merry Christmas peeps. Have a good one, don't drink too much :)

Character list for the Amis language We mapped the available glyphs and accents for the Amis language. The letters in alphabetical order:

    a c d f n  h i k l m n o p r s t u w y

Everyone of them can get an acute, grave or circumflex accent on top. Literally on top: i would get the dot PLUS the accent on top. The only exception is for the letter n , which gets the dot on top of the g replaced by the accents. Some accent combinations are missing in Unicode, like accented d, f, h and k, and i with dot and accents. So we need an extension of Unicode. Then we need an input method that would insert n instead of g and allow to type all the accent combinations. Here is the full character set:

    a              
    c       ?      
    d       ?  ?  ?
    f       ?  ?  ?
    n       ? n  n  [1]
    h       ?  ?   
    i       ?  ?  ? [2]
    k       ?     ?
    l       ?     ?
    m       ?     ?
    n             ?
    o              
    p       ?     ?
    r       ?     ?
    s       ?      
    t       ?  ?  ?
    u              
    w              
    y              

[1] the gliph for 'n ' is actually missing, because it needs to be a single character: since it is a letter, backspace and delete need to erase all of it in a single shot. [2] missing because of the accent on top of the dot. Question marks mark where a character is currently missing in Unicode. We have a problem because Unicode would not want anymore latin accent combinations, so we will need to use character combinations and hope that fonts and applications display them well. This raises the issue that hitting delete or backspace on a character built using combining accents would delete only half of it. For consistency of interaction, it can make sense to use combining accents for all the combinations, even if an accented letter does exist in Unicode. This would avoid backspace and delete to have different behaviors, for example, on s-grave and s-acute. The accents are not taken into account when sorting. Uppercase letters are not used.

Although you've not behaved very good, Santa Claus has a present for you: the entire GNOME 2.16.2 desktop in experimental. All core applications are here, only some bindings are still missing. Which means it's time for the most courageous to test it. With the experimental APT source configured, it should be a matter of apt-get install -t experimental gnome-desktop-environment. Be warned, it's still rough around the edges:

• GTK+ makes liferea crash repeatedly;
• there are a few glitches in the file chooser;
• there is only one working icon theme (the default one);
• evince seems to crash on some files;
• the keyboard switching stuff doesn't work at all.

But there are also many pleasant speed and UI improvements in most modules. Unfortunately for many, it is currently only available on amd64. Now, if a group of reindeers could rebuild it on i386, the children would be much happier. Otherwise, I will take some time to rebuild them in an i386 chroot in a few days.

Joey and Josselin, I'm calling you childish, not because you "stand" your principles, but because of the way you try to convince others that your principles are better. What you are using is:

• Insults ("lying", and for the record, FUD means twisting the facts and telling only half the story, and you are twisting the facts, as I detailed in my post; "should read constitution", which of course means to imply that I'm trying to deny you some constitutional right, which I'm not, I'm just asking you to stop spreading FUD)
• Blackmail and threats ("I'll stop contributing" [if dunc-bank is paying anyone], "reduced it much less than I could, probably much less than I should")
• Schadenfreude (the libpng mishap of the new maintainer; noone broke libpng intentionally. That is not a nice character trait, and pollutes the community)
• You seriously annoy people by going on and on and on, while everybody has already understood your opinion and arguments (and just happens to have a different opinion)
• Playing big words without actual content ("read the constitution 2.1.1", which btw. also states that you "must not actively work against these rules and decisions properly made under them"; your attempt at a GR failed, and you are working against these decisions on planet; I've however never said that you're oblieged to still work for Debian if you don't like the decision)

Actually, I'm by now convinced that it would have been better for Debian, if you would just have really left. Your behaviour in the last months makes you qualify as "poisonous people" (except these usually aren't big contributors). In my opinion, your infighting has harmed the project, it gives people the impression that being involved in Debian means mostly having to deal with such things. While it's not - Debian is still fun to me, although I have little time, and didn't manage to go to the last few Debian meetings here in Munich - all these fights are a nuisance to me. Even though I'm not actually affected by them (neither Dunc-Tank, because it doesn't demotivate me, nur the powerpc fights, nor some other fights on -private), the way they are dicussed on the Debian lists does annoy me. Again: if anything is cutting on my motiviation, it's your behaviour (this btw. includes the powerpc issue and fighters, too, especially Sven Luther who has probably sent as many mails as all others together, just reiterating the same things again and again). So if you are planning to become a Debian contributor, learn to use the "delete" button in your email clients, and don't be afraid to just delete whole threads. Certain threads are just a waste of time and bring negative emotions. So: Joey, Josselin: grow up, and accept that people sometimes have a different opinion, and you can achieve more by accepting that your opinions differ and just try to make the most of it anyway. Reminding them of your differences won't make them change their mind, nor will it make them like you any better. Fortunately, most people in the project (well, everybody except me?) seem to obey above "poisoned people" recommendations, and just ignored your posts on this issue. I didn't, and one of the reasons it that I feared Joeys first post could grab some media attention, and I felt there should be at least one post saying that, well, the debian-installer and some other RC bugs are probably also a cause of the delay, and it's probably not worth rehashing the dunc-bank issue. So far, I've only seen one news article citing aba that the delay was caused by the debian installer among others, no "the delay is due to dunc-bank demotivating all developers" FUD.

In part 1, I described the problem of software installation on Linux; in part 2, I’ll describe the solution we came up with at the recent LSB Packaging Summit. After reading through the comments to part 1, let me first point out that our goal is to create a vibrant third party software ecosystem around Linux—you know, like the one Microsoft has built around Windows. No, it’s not about imitating Microsoft. It’s about being competitive. A platform is only as good as the applications that run on it. Bottom line: Many third parties have built their businesses around proprietary software, and we can’t just ignore them. And “ecosystem” implies decentralized, which I argued in part 1 was a key tenet of open source development anyway, i.e., this should be playing to one of our core strengths. So, if your “solution” is to tell ISVs (independent software vendors) to give us their source code so the distributions can include it because that’s just how we do things, you can safely skip the rest of the post below. You’re simply not going to agree that any of this is a problem. Ok. Assuming our goal is to create a vibrant third party software ecosystem (and everyone still reading agrees that’s a good goal, right?), we have the following challenges. First of all, the distribution vendors are hugely invested in their existing package systems, and for the most part, those package systems work extremely well. As I said in part 1, “if [an application] is in your distro of choice, you re only an apt-get or a yum install away from running it.” (I’m saying it again here because some of the commenters apparently didn’t see that. The tricky bit is “in your distro of choice”, which by definition is not the case with third party software.) Furthermore, a variety of highly sophisticated systems management solutions are built above those package systems, such as Red Hat Network and Novell ZENworks. This is a pretty important consideration, because these days, the “software management problem” largely involves managing software across the entire infrastructure, not just a single system. What problem then? This: ISVs have thus far been reluctant to use the native package systems. Why? THEY’RE hugely invested in “package systems” for other platforms, and every Linux specific thing they have to support costs money. In a world where decisions are ruled by cost vs. benefit, this is a pretty important consideration too. How do ISVs handle this today? For the most part, they ignore the package systems on Linux and do their own thing. Trouble is, while doing their own thing gives ISVs the flexibility to work cross platform, it ultimately makes their products integrate poorly in the broader systems management context because the package systems know nothing about them. What is needed is a way to bridge the gap between what the distros provide and what the ISVs want. But how? First off, we have to understand what ISVs want. The answer is simple: ISVs want to treat Linux as a single platform, which means they want to offer a single package for Linux, much as they do for Windows. So, if one commenter is right that “[t]he problem is that people (including software distributors) believe there s such [a] thing as ‘Linux’ as a target platform” and that “[i]f you re distributing software for ‘Linux’ then it won t be simple to install it, ever”, well, then Linux is destined to suffer the fate of UNIX. I’m not ready to give up so easily. Several commenters suggested that what we need is a brand new package system. That’s a non-starter—for one thing, the distros aren’t going to be too keen on replacing something they’re hugely invested in, and if ISVs aren’t going for RPM today, why would they go for something different tomorrow? No, to find a way forward, we need an evolutionary step from where we are today. From there, perhaps we can do more, but even the first steps can be quite valuable in their own right. To help find those first steps, we put some of the leading minds in Linux packaging in the same room (including the maintainers of RPM at Red Hat and Novell and the authors/maintainers of APT, yum, alien, and klik) along with ISVs large and small, server and desktop. The discussion pretty quickly converged on constructing a single API that could be implemented across the various package systems, because APIs make for nice evolutionary steps and can, done right, mask underlying implementation differences. Question is, what do ISVs need in such an API? Limiting the scope is key here, because providing an API that spans all the functionality of, say, RPM and dpkg is overwhelming to the point of being unworkable, not to mention more work to implement, which in turn makes it less likely to get into the distros so that ISVs can count on it being there, the whole point of this exercise in the first place. Fortunately, the ISVs don’t really need much. At the most basic level, an installer just needs to be able to query the system to see if it’s LSB compliant, and if it is, what version of the LSB it’s compliant with; and it needs to be able to “register” with the package system, so the package system knows about it, including what files it has installed. And that’s really about it. Importantly, because we assume an environment that’s LSB compliant, we don’t have to worry about dependencies, because everything is covered by the single LSB dependency, and dependency management is 95% of the package systems right there. We still need minimal dependency support—components can extend the LSB, and applications can depend on those other components being installed—but we’re talking on the order of a handful of components, not the tens of thousands of components typical package systems have to deal with. We only had a day, so we obviously don’t have a complete solution yet. For one thing, we barely touched on the issue of uninstallation (should we allow applications to register GUI uninstallers?), and the issue of how applications go about changing the system configuration still needs discussion (in a lot of cases, the assumption of LSB compliance means the installer is going to be well behaved, but there’s undoubtedly corner cases to be explored). And it’s going to take time for the API to be implemented and put into widespread enough use that ISVs can depend on it. However, everyone in the room did come to consensus pretty quickly that this was an important problem, and that providing a simple API that provides the minimum necessary functionality was the way to go. Perhaps most exciting, the very people whose support are needed to put the API into widespread use were in that room, and active participants in the discussion too. Everyone is certainly motivated: The distros get more applications, which makes the shared platform more attractive; and ISVs get lower cost, which tilts the cost vs. benefit equation in their favor, making Linux versions more economically attractive and potentially opening new markets. Because this is just a start, the FSG is launching a Packaging workgroup to continue the discussion we started at the Packaging Summit. If you’re interested in this topic, I’d encourage you to join the mailing list and get involved. There’s still plenty to be done. Update: One more thing: In addition to making it easier for ISVs to better support Linux by simply extending their existing installation scripts, the API approach really comes into its own when you imagine it implemented in things like Autopackage and InstallAnywhere. Let the market decide!

Joey and Josselin are trying to bring dunc wars back. Please ignore the trolls. They're talking more FUD than ever. And yes, I consider this behaviour childish, too. Basically they claim that dunc tank is to blame for the etch release delay. Sure, blame AJ for the attr breakage. And the libpng disaster. And the FransPop and others vs. Sven Luther issue. And the installer delays. Especially the latter. The installer has never ever before delayed a Debian release, so obviously AJ and his dunc tank are to blame. (Well, actually I think that this kind of infighting done wrt Sven Luthers access to the debian-installer repository or the anti-dunc-tank-evangelists that really harms the project: this can really take a lot of fun out of Debian, more than dunc-tank ever could. But pointing at the installer is more fun, you know...) So Joey, Josselin: please, grow up. Stop trying to harm the project just because you disagree with a decision some months ago. Thank you, aba, for working e.g. on helping sorting out the libpng issues and doing a quick NMU for the attr breakage. And all the other release work you've been doing before, during and after dunc-tank funding. Your work is heavily appreciated because it's constructive.

Given the recent articles or blog posts that may lead some people to think that dunc bank made people work against Debian, maybe some explanations are needed. Dunc-bank is a single web page that some humourless people may find unfunny, YMMV, but that is nothing else than satirical. There was no conspiracy, undermining work, or power games. People claiming the contrary are just making complete fools of themselves. Really. The people that contributed to dunc-bank, meaning that did report most of the RC bugs in the last month are for some, even disgruntled when it comes to dunc-bank (I'm thinking e.g. of Lucas Nussbaum that did a full archive rebuild and reported many bugs). No, dunc-bank is not the evil masonery club that some depict. The sole thing I think really happened, is that people are nowadays really concerned about QA, and that there is a whole lot of issues that can be tracked automatically, at home (a good ADSL line and a GHz grade CPU is largely enough to do an archive rebuild in a week nowadays). What is really a shame in fact, is that those checks are not performed by Debian for any package, and on a regular basis. The other factor is that I think many people had concerns with etch quality, as many discussions in the past month may have let think that its quality could suffer from the announced release date. Now that this bad joke is now officially a dead-line, I think this is less and less a concern. That said, Yes, I do think some people that usually did good work in debian diminished their work considerably, and that it hurt the release. We lost some developpers (our locales + X-keyboard expert and that's a huge loss), some orphaned a lot of packages, and recent events do show that you can't improvise beeing the libpng maintainer a month before the release, and so on. Yes it's true that recent events and surroundings in Debian^[1] have led people to feel they are strangers to what Debian is becoming. And blaming them for not beeing supportive is very distateful and shocking. When you do pursue actions, that will lead to big changes in the community, then blaming the community members for those changes is a shame. So no, you can't blame the people behaviours (that have been reduced to dunc-bank supporters because that's so easy) for etch beeing late, because you can't blame the direct consequences of an action for beeing the cause of its failure.

Russell, 0.0.0.0 is not the same thing as 127.0.0.1. You may get the same behaviour in some cases due to some implementation details, but that does not mean that both are the same! 127.0.0.1 means "The host this software is running on". In contrast, 0.0.0.0 means "Any host"; it can be used in software as the C constant "INADDR_ANY". While it is true that connecting to 0.0.0.0 from software such as ping will yield the same result as connecting to 127.0.0.1, it is absolutely not true that listening to 0.0.0.0 (in a bind(2) kind of way) yields the same result as listening to 127.0.0.1. After all, in the latter case you will only accept connections that originate from localhost; in the former case, you will accept any connection, whether from localhost, the local network, or the big and evil Internet. I presume you will have at least some firewall in between, but still. That being said, however, 127.0.0.2 is an alias for 127.0.0.1. So is 127.0.1.0. And 127.255.0.1. And, really, anything in the 127/8 network range. Now that has no utility—there can be use in having a /24 reserved for loopback, but a /8? Who would ever need 16M ip addresses for the local host? Is there even an operating system that can keep track of that many IP addresses? Oh well. not as if I care. And, after all, IPv6 has fixed that little issue. Although it might be fair to say that they overcompensated there a little bit.

That sometimes journalists have obvious reading problems, well, isn't a too new thing. One has to deal with that, e.g. by appending more text to the cited blog entry. If someone inside the Debian community fails for the same is way more disappointing for me. I have never stated that "[I] couldn't compensate this" - that is just totally wrong. I think that dunc-tank helped us with release of Etch, but the help could have been greater if some people wouldn't behave as childish as they do. And I also try to look both ways, and not be singled-minded about it. There is another thing I learned as well during the last 12 hours - people don't appreciate if one tries to summarise openly what happened, and look both ways. Is it so wrong to look in both directions, and not only say "that and that were the improvements"? I thought at least within Debian we don't want to fall the usual management mistake of only speaking about how great everything is, but be honest to ourselfs. People starting to rip only half of the words out, citing them out of the context, and inventing new quotes don't help with that.

If you agree you might understand why I blog about the sign in front of a restaurant I just passed by. Compare "buffet libre" with "all you can eat".

Aaron Leventhal of IBM has more details on the relationship between iAccessible2 and the UNIX/Linux accessibility API (ATK/AT-SPI) as well as the motivations behind iAccessible2’s evolutionary approach:

[A]n evolutionary path was needed for applications which already had MSAA (IAccessible) support… [and] an API was needed that did not require separate accessibility implementations for each platform. […] The IAccessible2 interface itself collects important ATK features from other areas, as well some completely new methods and features… For the most part, features were added either to bring Windows capabilities up to the level of ATK/AT-SPI, or in order to support the features of ARIA (previously known of DHTML accessibility). […] [W]hat we’re doing is expanding MSAA while matching ATK/AT-SPI to a very helpful degree. […] [B]ecause IAccessible2 is backwards-compatible with MSAA, the current support of Windows screen readers and other assistive technologies can continue to work on applications that add IAccessible2 support. However, the newer IAccessible2 capabilities will also be exposed, and thus newer assistive technologies will be able to take advantage of them.

Peter Korn of Sun weighs in as well. (Via Andy Updegrove.)

I have a new fridge freezer. It has a hole in the back of the fridge. I can see through it to the outside world. This is apparently a drainage duct and part of the deicing/condensation thingy-ma-jig. It strikes me as just wrong. Won't all the cold escape? Simon tells me it's only a small hole and his fridge has one too, but I'm not convinced. I'll have to hide it behind some beer so I forget about it.

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! 

There are only a few days left until the close of the XTech 2007 call for participation. XTech 2007 will be held 15-18 May 2007 in Paris, France.
As I wrote last month, the theme for this year's conference is "The Ubiquitous Web", reflecting the many ways, places and devices through which we now interact with and are affected by the web. XTech 2007 will be comprised of four thematic tracks:

• Applications: web applications, vocabularies, publishing, content management, case studies
• Browser Technologies: browsers, mobile, user interface, related issues and standards.
• Core Technology: the heart of web technology, markup, protocols, semantics and more.
• Open Data: technology, experiences and policy behind open access to data.

All these topic suggestions are of course just that; don't feel you are limited to topics mentioned explicitly in the call.XTech is always topical, so to take that angle, we'll be expecting to hear about things such as Second Life, mobile and geolocative services, progress in open standards, Ajax toolkits, OpenDocument vs Microsoft Open XML, copyright, identity, best design practices and more.Just a few more tips based on submissions so far:

• Don't worry if you can't decide which track your submission falls into: just say so in the notes, and the programme committee can place it appropriately.
• If you have something super-secret you can't talk about yet, but can do by May 2007, write to me personally and we'll try to come to a suitable arrangement.
• If you have a great excuse why you need just a few more days to respond to the call, also let me know.

Otherwise, propose away!