One month with Emacs and counting - Part 1 Straight to the point: since mid September I've been using Emacs, trying to evaluate whether I was willing to switch from Vim to it. Yup, that's true, me (user of Vim since the day I've started using GNU/Linux 10 years ago, (not so) active maintainer in Debian of vim and related packages, author of some popular Vim extensions and of vim-addon-manager) it's considering switching to Emacs. What is worse is that I've de facto already switched. May jamessan forgive me. OK, that was the hardest part to write, now ... This choice will have an impact on me: partly because I'm quite sure several fellow DDs will start making fun of this story , and partly because as many geeks I've always had strong opinions on the editor war. Switching side ain't easy. Hence, I've decided to write a small (2-3) series of blog posts on the issue, to future memory. The post you are reading is about why, since a few months ago, I wasn't willing to give Emacs a try, and how I've changed my mind. Why I wasn't willing to give Emacs a try, but then changed my mind I love knowing tools which can improve my workflow, no matter the task. Editors happen to be at the intersection of many tasks, hence knowing well his own editor and feeling satisfied about it is quite important. This is even more so for free software hackers which, for a reason or another, happen to use the very same editor for a lot of different tasks; in my case: programming, conf file hacking (i.e., playing the sysadm role), mail writing, and everything in between. I've started using vi on Solaris around 1998, then switched to Vim starting from version 4.0, and then followed all its releases up to 7.0. I consider my "Vim karma" to be quite hight and I've delivered several talks about using Vim for LUGs and other free software-related events. Still, I've always been hit bit several minor nuisances and glitches of Vim which couldn't be fixed by simple configuration tuning or add-on implementations (more on this in a future post). In the quest for the perfect workflow, those glitches have made me try several times other editors hoping for more satisfying work environments. Of course Emacs was one of them, which I've tried repeatedly during the years; the last time was circa 2006. For one reason or another, after a few days of experiments, I've always decided to give up with it. Why? Various reasons, listed below, together with an explanation of what (I think) has changed since then.

1. Poor Unicode/multibyte support. Support for whatever Unicode encoding was close to null. It was not available in the legacy editor, and you had to use something called MULE, to be specifically enabled. That was so 60's, and rather hard to use. Now (apparently starting from Emacs 22.1, June 2007) finally you have built-in Unicode support and the needed two variables for setting the input encoding and the file encoding, which is basically all you need. Looks easy once you have it ...
2. Lack of "modern" UI toolkit support. Yes, I do live in a console and invoke my editor from it, but nevertheless for long coding sessions I do also love having a nice GTK+ window containing my editor using settings which smoothly integrated with the graphical settings of my desktop environment. Maybe I'm getting old, maybe GNOME has changed my perceptions, but why the heck I had to tolerate different monospace fonts in my gnome-terminal wrt my GUI editor I never understood. Firing up Emacs was like getting back in time of 15 years, and if a geek having a maximized terminal on most of its workspaces had this feeling, then something was really wrong. This has changed: starting again from Emacs 22.1, the editor has frown support for that "bleeding edge" technology called GTK+. Finally you can use Pango font faces and avoid the time travel feeling when switching from a terminal to your GUI.
3. "Dead upstream" syndrome. As we all know by experience, choosing a free software product is not only a matter of evaluating bugs and features, there are other environmental factors. A notable example is how active upstream is. A few of us will use a product affected by the "dead upstream" syndrome. That's exactly what I was feeling about Emacs. The first argument I can offer to back that feeling is again the Emacs release history (noted that "small" hole between 2001 and 2007? Rest In Peace release early, release often ...). The second argument is the bug tracking system: there was none, bug discussions happened only on the development mailing list and the bug tracker was a text file on CVS! (Yes, Vim doesn't have a proper BTS either, but I was looking for reasons to switch from it and hence looking for something better in several respects.) That has changed completely, as I discovered only at this year DebConf thanks to gismo. 2007 has enjoyed 1 Emacs release and 2008 already two. They do have a BTS now and guess what? is dear old debbugs. According to my first experiences as Emacs bug reported the maintainers are very reactive and also friendly in dealing with bug reporters. Finally, also keeping up with snapshot releases in Debian is entirely trivial, thanks to Romain's repository.
4. Poor performances & memory consumption. This goes in the direction of probably the most popular joke used by Vim zealots in the editor war: Emacs is a nice operating system, but lacks a good editor, or something such. In the past I had the impression that starting Emacs was really slow and that generally the memory footprint was too high to be acceptable. You know what: starting a full-blown gvim with a good deals of add-ons (and I used quite a lot of them, that's why vim-addon-manager was born) is not that faster. And on the contrary, firing up an emacsclient is way faster than starting up a new gvim instance. Regarding memory consumption Emacs is still "gaining" the battle. Still, one has to keep in mind the different workflow: with Vim you are encouraged to enter and exit the editor (not without drawbacks, as I'll discuss in a future post), while with Emacs you always use the same one. It turns out that via emacsclient the resulting feeling is the same as having multiple editors (as you can fire them up as separate windows or in separate consoles), still sharing all user memory. A final comment on memory consumption while looking at my top sorted by decreasing RSS memory: the top process is xulrunner (from the browser) with 356Mb, then Xorg (159M), pidgin (128Mb !!!!), trackerd, gnome-terminal, gnome-panel, ..., Emacs shows up with 51 Mb at the 7th position. Yes, it is not the thinnest editor in the world, but on average machine it doesn't really matter at all.

In the next post: how to switch from Vim to Emacs, without loosing your mental sanity. (Whether I did succeed wrt sanity is up to the reader to judge.)

I’m not sure which is the second-largest of the projects supported by Software in the Public Interest, but I thought that OpenOffice.org was up there with them. It’s been a bit of a surprise to me that SPI hasn’t done more for them since they joined back in March: only about $1,000 has been donated that way, none spent and I’ve not noticed their liaison being very active yet. Following the release of OpenOffice.org 3.0, I took a bit of a closer look. Stuff Michael Meeks is doing: Measuring the true success of OpenOffice.org suggests that the project is much smaller than I thought:

“In a healthy project we would expect to see a large number of volunteer developers involved, in addition - we would expect to see a large number of peer companies contributing to the common code pool; we do not see this in OpenOffice.org. Indeed, quite the opposite we appear to have the lowest number of active developers on OO.o since records began: 24, this contrasts negatively with Linux’s recent low of 160+. Even spun in the most positive way, OO.o is at best stagnating from a development perspective. “

OpenOffice.org is a project that produces something I don’t use much, but I recognise the significance of it. I’ve looked at contributing a couple of times in the past (nothing major, just bug reports and offers of help), but got utterly lost in the maze of websites and copious verbose descriptions written in management buzzspeak. (I spotted a “Report a Bug” link taking me to a page titled “Submit an Issue” for example.) Looking again now, OOo doesn’t seem much easier to navigate. I did find that SPI doesn’t appear to be listed on their donation page yet, which probably explains the low donation amount. Another confusing thing: they don’t use bugzilla, but a less accessible fork called Issue Tracker. Even simple contributions seemed to want multiple registrations to websites, mailing lists and whatnot - that seemed to contradict a claim that “Joining OpenOffice.org is purely optional” - and a confused email question to an address listed on the website got a rejection/error in reply. I’m sorry to say that I got confused, discouraged and moved onto other, easier things that I’d use more. Anyone else looked at contributing? How did it go for you? Anyone understand how this associated project works?

Bonfire Onlooker by dominicspics (cc-by) Of all the things I wanted to do yesterday, testing TTLLP’s disaster recovery plan was not one of them. I often suggest customers make disaster recovery plans, but I don’t like having to use them. One of our server farms suffered a serious hardware failure and slowly died during the day. (It didn’t catch fire - the title is a silly reference to lp0 on fire.) The current stinging electricity bills means that there’s an emphasis on power-saving now that wasn’t there 4 or so years ago, when we still built servers ourselves, before WEEE and cheap big-brand systems. Today’s servers aren’t quite as resilient, because each extra piece of hardware in use takes extra power. There are some much cleverer tactics now, but they don’t catch everything before it goes “bang” and we can’t just bring the “spare” hardware into action if it’s not installed yet. Replacement hardware will be installed as soon as possible, as well as some extra hardware that will help protect against a similar failure in future. The slow failure of the server also means that we lost some emails, voicemails and instant messages from 10am to 2pm yesterday. If one was yours, please resend. Most services have been rerouted or temporarily replaced with help from friendly associates. Three important services that haven’t yet are: 1. our financial system (which gets updated in batches anyway), 2. our task tracking (which is newer than our recovery plan and I need reminding about its backups, but at worst all the current data exists in other places) and 3. our newsletter server. I’ve copied the customer newsletter subscriptions to an older listserver, to send out news of our recovery, but the member newsletters (with GPG integration and so on) will wait for the replacement hardware. I’m hoping we can recover some things from the old server filesystem, else I’ll recreate it from the last release (that’ll teach me to hack it on the live server!). In the meantime, I’ve still most of yesterday’s work to do…

Sometimes, I m becoming really pestered by the number of issues, especially hardware issues, that remain prominent in the Linux system after so many years. And I m convinced that one of the root causes is the kernel development model. While far to be the only one, you understand a lot when you have a look at it. The stable API nonsense To explain the development model, the kernel documentation contains a document written by Greg Kroah-Hartman called stable_api_nonsense.txt. I think this document gets one thing very right: advertising it is complete nonsense. Many things in this document can get you a good laugh if you are used to software development, unfortunately they are not funny given how much they affect us as users and developers. Let s start with the executive summary:

You think you want a stable kernel interface, but you really do not, and you don't even know it. What you want is a stable running driver, and you get that only if your driver is in the main kernel tree. You also get lots of other good benefits if your driver is in the main kernel tree, all of which has made Linux into such a strong, stable, and mature operating system which is the reason you are using it in the first place.

What it should say instead is:

You know you want a stable kernel interface, but you don't have it, and we will never provide it. You want stable interfaces to focus on fixing bugs in your driver instead of updating it for interface changes, and to make integration of your driver in the main kernel tree easy. You would get a lot of good benefits if your driver was in the main kernel tree, but it won't make it unless you adapt to our bizarre processes, all of which have made the Linux kernel into a constantly moving target which is the reason many hardware vendors don't want to support it in the first place.

Our compiler does not have the same ABI as yours This is what happens when the only thing that interests people in charge is to code. Writing this means that these developers have no interest in making the system usable. This becomes more unbearable when such technically sharp people make up false technical arguments:

Depending on the version of the C compiler you use, different kernel data structures will contain different alignment of structures, and possibly include different functions in different ways (putting functions inline or not.)

Really, I wonder how the Microsoft developers, the GNOME guys, the glibc guys, and basically all library developers who know what they are talking about, manage to have stable ABIs despite the compiler changing all the time. One of the incredibly complicated techniques they use is to only rely on guaranteed functionality of the C specification, instead of doing many clever and funky hacks. For things more related to development itself, there are also incredibly complicated techniques like opaque structures, which save a lot of ABI breakage. Actually the only thing you need, if you design your ABI properly, is to be rigorous.

Depending on what kernel build options you select, a wide range of different things can be assumed by the kernel

This statement of a problem also contains the solution: stop making available build options no one cares about (remember, people install binary packages from their distributions) to guarantee stability instead. Instead of implementing the solution, kernel developers deliberately choose to deal with this insanity in the worst possible way: by encouraging it. Only lame developers need stable APIs But the nonsense doesn't stop to the ABI, which after all is merely a problem for distributors. To be more annoying to developers themselves, let s make up reasons to break the API all the time:

Linux kernel development is continuous and at a rapid pace, never stopping to slow down. As such, the kernel developers find bugs in current interfaces, or figure out a better way to do things.

Explained this way, it looks like a good thing. If you've done serious development or integration, you know that actually it is a problem. If you never slow down to look at what you've done, you're only going to add new bugs while you're trying to fix the others.

When they do so, function names may change, structures may grow or shrink, and function parameters may be reworked. If this happens, all of the instances of where this interface is used within the kernel are fixed up at the same time, ensuring that everything continues to work properly.

Everything is said. In the Linux kernel, changes are not done in a continuous way. Every non-minor change is going to have an impact on hundreds of different modules. The amount of work needed to accomplish these changes is absolutely insane. When a project like GNOME decides to phase-out an API, it takes several years before being actually replaced. In the kernel, it can simply happen between two minor releases, together with a rewrite of the whole ATA stack. The lolution Of course, Greg KH has a simple solution for you, in the What to do section.

So, if you have a Linux kernel driver that is not in the main kernel tree, what are you, a developer, supposed to do? Releasing a binary driver for every different kernel version for every distribution is a nightmare, and trying to keep up with an ever changing kernel interface is also a rough job.

No shit !

Simple, get your kernel driver into the main kernel tree.

Simple, isn't it? Unfortunately this is not going to happen while you are too busy adapting it for the constantly moving interfaces. This is quite feasible if you are writing a driver for an Ethernet network adapter, but for a video card this is another story, and for a virtualization layer? Well, the Xen developers have been struggling for years to integrate their technology in the kernel, and it is still far from done. No wonder why you get good drivers only for ethernet cards and not for 3D cards or even wifi chips. This doesn t go without other, worse consequences for users and distributors. Not everyone can afford to run Ubuntu, Debian unstable or Fedora, especially if they have simple requirements like not changing the whole system every 6 months. Corporate users using Debian stable, RHEL, SLES or Ubuntu LTS need a stable kernel that doesn t move, and that doesn t break everything when upgraded. The introduction of projects like DKMS to distribute drivers in a sourceful way while keeping them easily installable is a step in the good direction, despite being a workaround for a broken situation underneath. However these efforts are ruined by the constantly changing APIs that will go on requiring changes to the sources as well as the binaries. Why it can still work In fact, with such processes, you can wonder how it is possible that the system is actually usable. The answer is simple: while being smaller than many other projects, the Linux kernel has much, much more developers. A rough estimation shows that Linux has 2000 developers, many of which are paid full-time to work on it, to work on a 15 Mloc codebase. You can compare it with X.org, which has a few dozens of developers for 3 Mloc. Or with GNOME, 400 developers for 20 Mloc. With OOo, 150 developers for 10 Mloc. Yes, you need 10 times as many people to maintain the kernel code than for another comparable project. That's of course what happens when you keep them busy with a permanent refactoring of the code. This development method, while certainly having the advantage of bringing lots of innovation and fast integration of new features, is also driving away a very large portion of the open source community to work on rewriting Firewire stacks every 6 months. And as long as they are busy with this, they are not writing correct X drivers nor fixing bugs in the applications.

Sorry about the lack of updates, I have been really busy! Anyway, dsyslog 0.5 will be out soon, with TLS support. Audacious2 development is moving along quickly again, we might actually get an alpha release out before the beginning of 2009. Once I get dsyslog 0.5 out, I am going to start looking at NMUs in Debian to squash so we can get Lenny out… so the next few weeks should be pretty exciting.

I’ve just set up a poll on my site asking: what topics do you want to read here? Since this July, when cycling and most local and political themes were split off into other blogs, this site has been mostly Web Development and GNU/Linux topics, with an SPI article appearing most weeks, and minor themes of Koha news and ideas and general internet/telecoms issues around ThePhoneCoop. Finally, Drupal, OSCommerce and general business topics appear less frequently. By traffic, the SPI series seems by far the most popular (but at least one of those is heavily spam-attacked now, so I’d discount it), followed by other political themes, then the technical posts. I suspect that politics is getting a temporary boost because of the US and Canadian elections, even though I’ve not written about them much. But is there some other theme that people want to read about? The poll box on the right column lets you tick as many or as few as you want. It requires javascript, but if you don’t have javascript, please leave a comment on my site. If you want to suggest a new topic which I should add, please leave that in a comment too.

I finally catched up with Gammu backlog from holidays and now it is time to move it a bit further. Automatic testing During this week I set up CDash instance for acquiring results of automatic nightly checks of Gammu. Each night Gammu is build on several hosts (currently Debian x86_64, Debian x86, SUSE x86_64 and crosscompilation for Windows on Debian) and results are posted to the dashboard. If you have some other architecture which could participate in testing, you are welcome to contribute! It is simple - just checkout svn, create build directory and configure there Gammu using cmake. You can enable coverage tests (-DCOVERAGE=ON). Then just run every night make Nightly for regular testing or make NightlyMemoryCheck to do dynamic allocation analysis. There is more detailed documentation in sources (INSTALL file). Thanks to this, I can hopefully sooner spot regressions and possible problems on different architectures. Roadmap With upgrade of Mantis, new feature called roadmaps arrived. I started to use it for planning features in future Gammu releases, so you can see what bugs should be fixed in future releases in Gammu roadmap. Currently there are not much things planned, because till now I had to focus only on bug fixing, but I think with 1.21.0 we have reached much better quality than in past releases and now is time to do some important changes in the core. Nokia phone required As you can already see in roadmap, I plan some bigger changes to Gammu core. I currently have on Sony-Ericsson phone and I would not be able to properly test how these changes will affect Nokia drivers. So for start I will need at least Nokia Series 40 3rd edition phone. Nokia 6233 (or 6234) currently looks as a reasonable choice, but if you have any hints for cheaper one with similar features, just drop me an email. Perfect would be if somebody would have half broken phone (I do not intend to use it for anything else than Gammu development, so broken camera, speaker, microphone or display does not really matter) and will be willing to donate it to me. If this will not work out, I'll have to buy used one and I will try to collect funds for this. If you want to contribute, check my donations page for possibilities.

I have blogged about it before, but I will blog about it again as it is that cool: SISU. According to its author, Ralph Amissah, “Susu was born of the need to find a way, with minimal effort, and for as wide a range of document types as possible, to produce high quality publishing output in a variety of document formats.” And really what it does it makes reading on the web a whole lot easier. He can only throw up Free Material and so his options are a little limited but he has recently added Christopher Kelty’s Two Bits, making it easier to read than ever. We just finished reading a about 3 chapters of the book for my class (wish I had known about the SISU for my students but oh well, next time) and here is the latest entry from one of my students covering the birth and development of F/OSS and ending with some questions about Free Culture. Good stuff, if I can say so myself.

I have blogged about it before, but I will blog about it again as it is that cool: SISU. According to its author, Ralph Amissah, “Susu was born of the need to find a way, with minimal effort, and for as wide a range of document types as possible, to produce high quality publishing output in a variety of document formats.” And really what it does it makes reading on the web a whole lot easier. He can only throw up Free Material and so his options are a little limited but he has recently added Christopher Kelty’s Two Bits, making it easier to read than ever. We just finished reading a about 3 chapters of the book for my class (wish I had known about the SISU for my students but oh well, next time) and here is the latest entry from one of my students covering the birth and development of F/OSS and ending with some questions about Free Culture. Good stuff, if I can say so myself.

Today, I tried to switch one of my personal repositories for debian-related scripts from bzr to git, just like I've done for pmount. The trick was that this time, I wanted to only move a part of the repository, not the full repository. I had only been working before with CVS and SVN who have the idea of modules, which is not the case for bzr or git. So I made the mistake of using a single bzr for several projects, which I realize now is not a very good idea... In any case, I managed to drop some parts and here is how I did it; the trick was precisely to use SVN as an intermediate storage medium, using the following configurations files. First, bzr2svn.conf

[DEFAULT]
verbose = True
patch-name-format = ""
[project]
source = bzr:source
target = svn:target
start-revision = INITIAL
state-file = tailor.state
[bzr:source]
repository = /home/vincent/debian-devel/bzr/scripts
[svn:target]
repository = file:///tmp/testtai
module = biniou

and svn2git.conf:

[DEFAULT]
verbose = True
patch-name-format = ""
[project]
source = svn:source
target = git:target
start-revision = INITIAL
root-directory = /home/vincent/tmp/debian-mr-copyright-mode
state-file = tailor.state
[svn:source]
repository = file:///tmp/testtai
module = biniou/debian-mr-copyright-mode
[git:target]
git-command=/usr/bin/git

Then, all that is left to do is to run tailor on the resulting configuration files:

~ tailor -D -c bzr2svn.conf
~ tailor -D -c svn2git.conf

Some brief highlights of the last three months of Debian Eee PC development. Thermal and ACPI breakage resolved in 2.6.26-7 We’re pleased to see that in the upload to Sid of linux-image-2.6.26-1-686 version 2.6.26-7, the pair of 2.6.26 bugs we’ve been tracking that have made it difficult for Eee users to upgrade their systems have been resolved. Since then 2.6.26-8 has been uploaded and is expected to enter Lenny this week due to a freeze exception. Once the new kernel has migrated we will move quickly to build and release a new installer that includes it. Ath5k wifi works on Eee PC in Linux 2.6.27 Jean-Christophe reports that ath5k works in Linux 2.6.27 on the Eee PC 701, and just needs a small patch to work with our eeepc-acpi-scripts package. This is good news for those of us with models 701, 900, 900A and 1000HD who have been wanting to get off of the non-free Madwifi drivers and onto DFSG free drivers. New Eee PC model 701SD wifi support in the works Users of the new Eee PC Model 701SD have just started showing up looking for support in mainstream Linux distros. Martin Filtenborg confirmed using our Eee PC Live image with the GPL’d rtl8187se driver from Realtek that we can at least use it to connect to an unencrypted AP, get an IP address and ping other hosts. Of course, it is one thing to have a working vendor-supplied driver and quite another to have mainstream support. We’ll make do with what we have now, but will be seeking a mainstream solution as soon as possible. We’re seeking more testers and developers to work on this. To date, an ITP has not been filed, as it is not yet clear who is going to carry this work forward. Chasing the 5 second boot An interesting discussion on Arjan van de Ven and Auke Kok’s work to get an Eee 901 to boot in 5 seconds took place this month. While the Debian Eee PC team is not making work on this a priority, we’ll keep an eye on it to see if Debian can incorporate some or all of the techniques they used so that our users can benefit without making radical changes to their systems. Working towards mainstream support for rt2860 Our filing of an ITP for rt2860 (the wifi driver for models 901, 1000 and 1000H) was followed by discussion about how to separate out the GPL’d driver from the embedded non-free firmware so that it can at least go into contrib. Glenn Saberton has been working on rewriting the build system around kbuild and separating out the firmware. Numerous improvements to ACPI scripts Since my last progress report, there have been numerous improvements to the eeepc-acpi-scripts package to deal with all of the various models we now support and make the scripts more robust and flexible. Check out the changelog for details.

mutt has excellent OpenPGP and GPG support. However different clients send GnuPG encrypted/signed data in different ways. Lots of people seem to be using FireGPG these days so that they can use GnuPG within the GMail/Hotmail/Yahoo! web clients.

Here's the procmail rule I used to convert almost all incoming emails to the OpenPGP/MIME format:

:0
* !^Content-Type: multipart/
* !^Content-Type: application/pgp
 
 :0 fBw
 * ^-----BEGIN PGP MESSAGE-----
 * ^-----END PGP MESSAGE-----
   formail \
     -i "Content-Type: application/pgp; format=text; x-action=encrypt"

 :0 fBw
 * ^-----BEGIN PGP SIGNED MESSAGE-----
 * ^-----BEGIN PGP SIGNATURE-----
 * ^-----END PGP SIGNATURE-----
   formail \
     -i "Content-Type: application/pgp; format=text; x-action=sign"
 

However, this didn't actually work with FireGPG and the way that it puts encrypted messages inline. I eventually found out that putting this in my ~/.muttrc would fix it:

set pgp_auto_decode=yes

Last Thursday, I was at a conference called Listening to the Social Entrepreneur. Here are some short notes about the plenary session, which were written at the time, along with thoughts on the workshops that I’ve just written up. HCT Group - credit crunch opportunity - business with ethics - transport - dislike 3rd sector term - difference between social enterprise and charity - optimism. Haley House - ex-soup kitchen staffed by ex-homeless, bakery, bank donated equipment, financial picture - catering grew 36% cafe grew 21% september, cooking classes; recipe for success: collaborate with experienced partner, secure enough capital or equivalent, align venture with mission; plan for sustainability; future… Roskilde university - relevance of academic research - why references for things I know - hard to have your feelings discussed. (meeting last Monday?) - don’t care what it’s called - too much jargon - several ways of learning, conceptual doesn’t seem useful but will later. CICs. Four flags of SEs - eship, er, e, econ. Bikeworks - practitioner and academic. Formation, setup, establishment, sustain. SE changes; viewpoint: academic, researchers, help us. Useless website. Then came three workshops of varying usefulness: Procurement Versus Marketplace was an interesting idea and reminded me why I avoided public-sector projects for years: I’m better at negotiated than at rules-based selling. I also was told (with a straight face) by a development trust worker that cooperatives are simply profit-sharing schemes, which was very disappointing. Social verses Business Goals seemed pretty ill-conceived. The reason why many people work in social enterprises is because we don’t believe we should choose between them. It’s an integrated, multi-faceted approach. Born or Made? was an interesting examination of the people powering social enterprises. Food for thought, but I’m not sure it really produced much. But I’m not that sure whether any of the workshops had much of a productive purpose. The final plenary session was confusing. I was sat further back, the sound system was intermittent and echoy and the talks seemed truncated and still, but maybe I was just tired. A lot of people had left by this point. I stayed on for the networking reception and met a few interesting people, but left earlyish to meet another TTLLP member on the light railway. The venue was OK (I think the main hall problems were more sound system and operation than the hall itself) and coffee, lunch and reception were well-catered. In conclusion, it was an interesting conference, but I don’t feel that we got much out of it, apart from some thoughts from a workshop session. I suspect it was more useful for the researchers than for the entrepreneurs. There weren’t many opportunities for professional development or sales or even putting things into consultations or . I’m not sure I’d spend best part of two days work (attending plus travel plus costs) on another similar event.

I've been neglecting pmount for such a long time I feel ashamed about it. Thanks to tailor and a neat post, I've just switched it to a git repository at git://git.debian.org/git/pmount/pmount.git to get more work done (I don't like bzr too much in the end, don't flame me, it's just a matter of personal taste...). I hope that I'll be able to reduce the amazing number of bugs that have accumulated there...

A couple of days ago I attended a lecture about the Drizzle database server [1]. Drizzle is a re-write of MySQL for use in large web applications. It is only going to run on 64bit platforms because apparently everyone uses 64bit servers - except of course people who are Amazon EC2 customers as the $0.10 per hour instances in EC2 are all 32bit. It’s also designed to use large amounts of RAM for more aggressive caching, it’s being optimised for large RAM at the expense of performance on systems with small amounts of RAM. This is OK if you buy one (or many) new servers to dedicate to the task of running a database. But if a database is one of many tasks running on the machine, or if the machine is a Xen instance then this isn’t going to be good. There are currently no plans to support replication between MySQL and Drizzle databases (although it would not be impossible to write the support). The good news is that regular MySQL development will apparently continue in the same manner as before, so people who have small systems, run on Xen instances, or use EC2 can keep using that. Drizzle seems just aimed at people who want to run very large sharded databases. Now I just wish that they would introduce checksums on all data transfers and stores into MySQL. I consider that to be a really significant feature of Drizzle.

• [1] http://en.wikipedia.org/wiki/Drizzle_(database_server)

Share This

Anand Kumria wrote:

If IBM were to go bankrupt, would the government step in? Unlikely. Investors would lose (money), staff — another word for investors — would lose (jobs), but customers would win (their computers would keep working). Some customers would win more than others (especially those who had the equipment on lease); if no one is collecting, why pay?

I’m wondering here where Anand got the idea that once a company went bankrupt, that you don’t need to pay to that company anymore. When a company goes bankrupt, at least in Germany the following happens: A trustee/liquidator is selected. This liquidator is then collecting the information who owes money to the company and who still needs to get (how much) money from it. The liquidator also has to check the option of selling company assets (which might include the contracts of customers that still have to pay) to fulfill the debts of the bankrupt company. After he turned all assets into money, the money is distributed among those who still have to get money from the bankrupt company. Anyway, regarding his main argument that the (average) customer of a company (bank in this case) should never have to pay for the failed speculations of that company, I somehow have to agree with him. Someone putting money into a regular bank account or papers with fixed interest rate should never lose his money. But there are also customers buying bank shares with a chance of higher revenue than with fixed interest rate papers. These should suffer from failure of the bank management, as they more or less explicitly wanted to be tied to the success (or failure) of the bank. However, this is mostly irrelevant, since the failure of so many “investment banks” has side affects that might cost the average inhabitant of the affected countries even more than the discussed rescue plans. One of these effects is that the banks are now much more conservative regarding lease and mortgage plans, effectively leaving many home owners with no option to fulfill previous obligations (remaining debt after a previous mortgage expired can’t be refinanced by a new mortgage), causing them to have to sell their homes to pay the first mortgage. This is in some way stupid because this causes people who were perfectly paying their mortgage rates to loose their house, while the bank which would be giving them a new mortgage could get a new and good customer, improving their income. On the other hand, if the other side effects of the current crisis cause those “good” mortgage customers to loose their jobs, they might turn into bad customers who are unable to pay their rates. All in all, this is a spiral that could cause the whole economy to break down (a small example: The bank is not giving out mortgages, so no one will build new houses so the builders loose their jobs so they don’t pay their mortgage rates anymore,…. - over simplified, but still shows what I mean). Unless the spiral is terminated in time, before too drastic things happen. All in all, I do understand why the politicians try to rescue those banks (or at least the customers of those banks), though I think that in an economy with slightly higher regulation, there wouldn’t be the need for such a rescue plan. I know there are some german banks affected by the crisis as well (among them Hypo Real Estate and others), but the average private customer of such banks shouldn’t loose money due to the regulations we have in place. In general, there should be some security fund which makes sure that private customers never loose money put into regular bank accounts or fixed interest papers, vice-versa, banks should calculate mortgages so that they can be pretty sure their customers are actually able to pay off their rates - it doesn’t make sense if someone starts off having to pay 500$/month for their mortgage and has to pay over 1000$ a few years (as in 2-3 years) later, because the bank raised the interest that much. I have no problem with people loosing money from shares of banks or other companies directly or indirectly through investment funds.

Marking up email on the Web is not a pretty picture in 2008.

• Weaver daemon used by Gmane (seems complicated to setup)
• Hypermail (51k SLOC) used at suckless
• Hypermess (56k SLOC C) used by the W3C
• Mailman’s Pipermail used for Python mail archives (not a drop in replacement for hypermail or maintained according to upstream)
• MHonArc (280k SLOC of perl) used by Debian lists
• lurker (10k+ CPP) used by the free network group
• zest 1k of Python (looks like an interesting research project which I have not managed to get working yet…)

Notable mail archiving services:

• Google Groups for Usenet archives and much more, with a killer search feature
• The Mail Archive which uses MHonArc

Random thoughts:

• I think the thread view is the most important feature. Google’s approach to threading mail as a bunched up conversation works quite well, though I still prefer the tree threaded structure that mutt does so well.
• Mailman implements RFC2369, though the W3C doesn’t seem to support this, though it does use Archived-At: which is quite useful. Google doesn’t seem to employ archive links to HTML sadly.
• I am not fond of framed views that I’ve seen some mail archiving services provide.
• Has anyone really studied how a RFC2822 mail message should be marked up in HTML? 3.1. Formats of Archived Message does not address the problem.

Any other relevant RFCs, tools or tips I might have missed?

they were hanging out in California. Being warm. (That's Angie's comment. I'm still wearing sandals. Although I saw a Montrealer shudder at me today. That was worth it. I think I'll keep wearing them all week, even if it causes me to lose my toes)

but.. BUT! that's not the exciting part!

This is: http://www.realtor.ca/PropertyResults.aspx?Mode=5&id=1487634

This evening we accepted the counter-offer on the place.

The timeline so far: arrived Saturday, looked at places 10:30 Sunday morning. Made offer 7pm. They made a counter-office at 8:30pm. We accepted the counter-office at 6:30pm today.

Next up: Review property agreement. Find someone to sign all the paperwork for us when we're out of town. Pray that CMHC aren't rat bastards. Inspection on Saturday at 1pm.

Oh, and none of this includes going to the house party on Saturday night, the last minute finding of a hotel as our friend's place had a pipe burst where we were going to stay. Finding out that another friend had a place to stay. Me forgetting my laptop at the hotel. We saw the midwife this morning. And I went to work today.

Sometimes I think that Aikido Rondori has nothing on my life. =)