I've been working a little bit more on the folding tagcloud for Debian packages. I've added closing of folds, and the code for displaying selected tags as well as matching packages is in place, too (you'll need to use a different .json data to actually see results though). To make it truly interactive, i.e. allow the selection of multiple tags until you get some results, I need to add more data files. So I'll have to decide now if I'm going to use a CGI (the "traditional" method), which will likely need to have some caching, or if I'll just precalculate everything into static .json files. I could even store them as .gz on the webserver; any browser with ajax capabilities should be able to do gzip decompression on the fly. This would offer maximum performance and security, but it means I'll need more magic in the javascript (and Javascript is ugly). Or I'll do a combination of both, use a tiny CGI serving the precalculated data; the CGI could then easily be replaced with a dynamic-caching CGI later. SVG rendering for the tag cloud would probably be also very cool. With some smart layouting algorithms, it could become much more cloud-like. And there could probably be a nice animation when "subclouds" are unfolded, pusing away the other folds. However, that would be much slower. Any animation means a slowdown, since it adds extra delays.

I doubt the current vote can delay etch when accepted. There are many different GR suggestions out there to get additional exceptions for etch. And there is no dobut at all such expections will get accepted with a gigantic majority.

I see more danger to delay etch when the GR is not accepted but voted down. Then people will have much less ground for what to get exceptions and far less common ground on what to base all the GRs that are to come. And given the large amount of proposals on debian-vote, having many more GR will not help to get etch out.

Also note that if the GR is not accepted, there are many people believing that the current rules still apply and these rules are: source is needed for all bits in the Debian distribution, and much more things has to be ripped out than those misterious 6 months if no additional exceptions are voted on.

If the proposal we are currently voting on (http://www.debian.org/vote/2006/vote_004) would be accepted, this would mean:

• The debian-installer has to be changed prior to release of Etch. This change alone would delay by at least 6 months, according to Joey's estimations.
• Even fonts and videos would fall into the category where we would need source - but what is the source of a font? or a video stream? (and yes, fonts are "works that are executed by other means", i.e. displayed on the screen) That is a great new place for lots of new discussions that don't really help our users, but will definitly waste lots of time.
• We would be in a very bad situation e.g. with the debian-keyring (and all other sort of crypthographic stuff) - I definitly don't plan to distribute the sources for my public key (as the sources can also be used to generate the private key).

In summary, this proposal would delay the release of Etch by at least 6 months, probably even one year. Of course, any of the pending GRs can still overrule the result of this GR, but - that is not something we should be proud about, or even plan. On a personal basis, if this GR becomes effective would also mean that I failed to manage the release of Etch.

From: secretary@debian.org
To: Daniel Burrows 
Subject: Acknowledgement for your vote

Spam detection software, running on the system "jester", has
identified this incoming email as possible spam.  The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email.  If you have any questions, see
the administrator of that system for details.

Content analysis details:   (5.8 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 1.0 NO_REAL_NAME           From: does not include a real name
 1.5 RCVD_NUMERIC_HELO      Received: contains an IP address used for HELO
 1.0 BAYES_60               BODY: Bayesian spam probability is 60 to 80%
                            [score: 0.7536]
 2.3 EMPTY_MESSAGE          Message appears to be empty with no Subject: text

The original message was not completely plain text, and may be unsafe to
open with some email clients; in particular, it may contain a virus,
or confirm that your address can receive spam.  If you wish to view
it, it may be safer to save it to a file and open it with an editor.

(but what if the editor is Emacs and it has a Lisp virus?? ;-) )

I deploy my Rails applications with Capistrano to an Ubuntu machine, which uses the excellent Debian style layout of Apache 2 configuration files. To keep things tidy, I like to place the Apache configuration file inside the config directory of the Rails project, along with the rest of the configuration for the Rails application and Mongrel. With the help of a couple of Capistrano rules I can then ensure that, on deployment, the latest Apache configuration file is also sent to the server:

# after setup, do a one-time link in
task :after_setup do
  sudo "ln -nfs # current_path /config/# application         
     /etc/apache2/sites-available/"
end
# cause apache2 to re-read. you probably have this rule anyway
task :restart do
  # if you're running mongrel_cluster, uncomment the following line
  # restart_mongrel_cluster
  sudo "/usr/sbin/apache2ctl graceful"
end

The first time round you'll probably want to do a2ensite yourapp manually, but this could easily be added into the after_setup rule. Not rocket science, but a pleasing bit of configuration that keeps things tidy.

All the soarings of my mind begin in my blood.
-Rainer Maria Rilke I have made it back from NYC after a pretty intense few days spent at the Open Minds Conference and Icarus-hosted workshops, Get Your Freak On. Both were incredibly interesting and I felt the ambivalent rush of excitement and fear that follows the prospect of working on a new project. While I have spent some time researching critiques of psychiatry, I have not spent all that much time with the people involved, academically and personally, in the various movements. And there is nothing like seeing in the flesh and blood some very passionate political work to get the intellectual excitement brewing. The first time I went to a survivor conference and protest I was living in San Francisco, deeply involved in my hacker research. I learned about the movement from a civil libertarian John Gilmore, who drew inspiration from psychiatric survivors to develop his free speech arguments for drug legalization. I had never heard of them and was intrigued so I naturally poked around the web. And I was fortunate to find out that their conference was being held the following weekend less than 10 blocks from where I was living at the time. I made time to go and unsurprisingly, it was a powerful event, perhaps the most stunning conference I had ever been to. There was something awfully inspiring about a political movement in which the members had experienced heavy doses of trauma, often through heavy doses of “treatment” and yet found the energy, will, and life to engage in political action, and in a society that does most everything to dampen the fire of politics. This weekend was no less inspirational. Even at the academic conference, the personal stories of trauma, survival, and the complex ethical decisions of choice in a landscape dominated by one medical model, erupted frequently. These were important eruptions that sometimes probably for some felt out of place in an academic setting where such outpourings are discouraged, buried deep away never to disturb the calm and rationality of talks. But without them, the conference would have felt dry, staid, and sterile, which would precisely have been the most disappointing atmosphere to have created for this environment. All the talks were engaging and illuminating and it was great to see and hear many folks working on these topics and especially working to carve out a different political and somatic reality. For me, the talks by David Oaks and Jackie Orr were the most electric and hopefully I will soon get the videos of them as well as most others (as I (tried) to tape most of the conference) up for those who are interested. In the meantime, David Oaks has already
released his talk, which is worth checking out. One of the more interesting parts of the conference was that it gave a clear indication of one of the great successes and strengths of the mad movement, which is its staying power, its ability to survive (even if not necessarily known to wider publics) generation after generation, which is more surprising given that the vitality of so many of the political movements of the 1960s and 1970s, vanished or languished. This continuity was marked by David Oaks keynote speech entitled “Unite for a Nonviolent Revolution in the Mental Health System: What 30 Years in the Mad Movement Have Taught Me” and just by the fact that he and Celia Brown were there, both who have been involved for decades. Beyond that, it was also the new faces, the new groups, that include Icarus, and the
Freedom Center, that attest to the ability for this Mad Movement to thus far escape the cruel ravages of time and its intervention, often causing rifts within and across generations. Sasha Dubrul who gave a talk during the activist panel and founded Icarus four years ago talked about the deep alienation he felt when he first had encountered the rhetoric of psychiatric survivors and, even despite his deeply critical stance against psychiatry. He wanted to create an organization and a message and a place that resonates with our actual experiences of mental illness rather than trying to fit out lives into a conventional framework. It is a message that swoops into many territories that includes a stiff, unrelenting critique of psychiatry and the pharma industry all the while admitting that not everyone can survive without pharmaceutical drugs (and being deeply grateful for this), all the while also providing pathways to alternatives. It is not easy territories to navigate, due to the and cracks and crevices between positions but then again, most of life is filled with these bumpy textures and not a smooth plane free contradictions. If Icarus was born in part because existing organizations did not adequately address existing needs and desires, it did not grow and move away from existing organization but moved closer to them and is now is in alliance with
MindFreedom. And this is key. Difference in a political movement adds vitality, depth, opportunity but this can only be brought into healthy fruition with alliances. Otherwise, deep fragmentation follows, which given the already deeply fragmented nature of our lives, and of the political landscape, can end in political stasis. But so far, the Mad Movement has over years taken “mad anger” to fight a mad system, and given the last 30 years, I am sure will provide many more decadesof mad pride.

It sucks that despite (and apparently maybe because of) not being a BT customer any more, they can still delay my new phone line and broadband until a fortnight after moving in. (Ask not how I am online at the moment, for it is truly evil.) It sucks more that online forms for some essential services won't let you register a change of address if you don't have a telephone number. Bad Anglian Water. Bad North Somerset Council. It sucks even more that online forms for Wessex Water try to make you agree to even more restrictive terms than if you use the equivalent paper forms - I'm pretty sure their online terms break the Unfair Terms in Consumer Contracts Regs, but I'm not starting that fight just now.

Happy new year, everyone! I was away over the weekend, working hard on Ignition 2006, and I missed the big day here in front of the computer. Instead I was out under the stars with Montreal Burners, having Burning Man fun out in the wt:Eastern Townships. I'm not sure if it happened this year, but I think next year it would be great to have a Debian:BSP in wt:Black Rock City. OK, sure, it'd be super-nerdy, and the connectivity is pretty spotty, but there are some long, hot afternoons out there and I know that there are at least two DDs that are on the Playa pretty regularly (me and Don Armstrong). I wonder if there are more? I wonder if we had a BSP, if lots more would show up? tags: debian don armstrong bruleurs new year french revolutionary calendar

Usability So, my current computer usability problem has to do with the rockin' secure shell program OpenSSH. Here's what happens: I'm on a box and I have a new login goin' on. And I have to ssh to another box, and I get the message:

Enter passphrase for /home/evan/.ssh/id_rsa: 

This happens because I haven't run ssh-add when I logged in, to store the passphrase for the key with the current ssh-agent. So now I have two options:

1. enter my password and then possibly forget to run ssh-add before running ssh again
2. kill the current ssh instance, run ssh-add, then run ssh again

Both options suck. What would be nice is if I could enter my passphrase, and have that count as if I had run ssh-add. Like, after I enter it, the ssh client could say:

Add this key to your current ssh-agent session [Y/n]?

...and then ssh would add the key, like ssh-add does, and continue with the login. Wouldn't that be great? I think this is the biggest usability problem I run up against in my daily work life. Which, y'know, is pretty good. [You might want to look into libpam-ssh] [See also http://advogato.org/person/mbrubeck/diary.html?start=90 ] tags: ssh usability wishlist

Wikimania 2007 in Taipei I have to say that I'm a little wistful that wt:Alexandria wasn't chosen for Wikimania 2007. We had a really good bid to hold the event in Alexandria at the Bibliotheca Alexandrina, the "new" Library of Alexandria. I was getting pretty excited about going to the Mediterranean next year. But I think that Taipei is going to be a fantastic place to hold Wikimania, too. Holding the event in wt:East Asia will make it much easier for people there , in wt:Southeast Asia, and in wt:Australia or wt:New Zealand to come to the event. A Wikimania in East Asia will focus attention on the non-English-language and non-European efforts of the Wikimedia Foundation. Taiwan also has a really strong local Wikimedian group, with Wikimedia Taiwan soon on its way. Finally, a Wikimania in wt:Taiwan will re-emphasize the wp:Blocking of Wikipedia in mainland China. Jimmy Wales has said on the record that Wikimedia will not censor its Chinese-language projects to comply with the PRC's firewall (the so-called wp:Great Firewall of China), and I'm sure an official event in the ROC will further highlight that point. Personally, I'm looking forward to a trip to Taipei, which will be a good excuse for some more exploration of Taiwan. And I want to congratulate the Taipei bid team. I was impressed by the amount of work that went into the Alexandria bid, and I'm sure they did a lot of work for Taipei, too. I know the Alexandria crew is optimistic for next year: starting the steps for making a Wikimedia local chapter in Egypt, and continuing to develop relationships with the local technology companies as sponsors. Should be interesting... it might be worth a trip after all! tags: wikimania wikimania 2007 alexandria taipei

upstart is a replacement for the init daemon, the process spawned by the kernel that is responsible for starting, supervising and stopping all other processes on the system. The existing daemon is based on the one found in UNIX System V, and is thus known as sysvinit. It separates jobs into different “run levels” and can either run a job when particular run levels are entered (e.g. /etc/init.d/rc 2) or continually during a particular run level (e.g. /sbin/getty). The /etc/init.d/rc script is also based on the System V one (and is in the sysv-rc package), it simply executes the stop then start scripts found in /etc/rcN.d (where N is the run level) in numerical order. Why change it? Running a fixed set of scripts, one after the other, in a particular order has served us reasonably well until now. However as Linux has got better and better at dealing with modern computing (arguably Linux’s removable device support is better than Windows’ now) this approach has begun to have problems. The old approach works as long as you can guarantee when in the boot sequence things are available, so you can place your init script after that point and know that it will work. Typical ordering requirements are:

• Hard drive devices must have been discovered, initialised and partitions detected before we try and mount from /etc/fstab.

• Network devices must have been discovered and initialised before we try and start networking.

This worked ten years ago, why doesn’t it work now? The simple answer is that our computer has become far more flexible:

• Drives can be plugged in and removed at any point, e.g. USB drives.

• Storage buses allow more than a fixed number of drives, so they must be scanned for; this operation frequently does not block.

• To reduce power consumption, the drive may not actually be spun up until the bus scan so will not appear for an even longer time.

• Network devices can be plugged in and removed at any point.

• Firmware may need to be loaded after the device has been detected, but before it is usable by the system.

• Mounting a partition in /etc/fstab may require tools in /usr which is a network filesystem that cannot be mounted until after networking has been brought up.

We’ve been able to hack the existing system to make much of this possible, however the result is chock-full of race conditions and bugs. It was time to design a new system that can cope with all of these things without any problems. What we needed was an init system that could dynamically order the start up sequence based on the configuration and hardware found as it went along. Design of upstart upstart is an event-based init daemon; events generated by the system cause jobs to be started and running jobs to be stopped. Events can include things such as:

• the system has started,

• the root filesystem is now writable,

• a block device has been added to the system,

• a filesystem has been mounted,

• at a certain time or repeated time period,

• another job has begun running or has finished,

• a file on the disk has been modified,

• there are files in a queue directory,

• a network device has been detected,

• the default route has been added or removed.

In fact, any process on the system may send events to the init daemon over its control socket (subject to security restrictions, of course) so there is no limit. Each job has a life-cycle which is shown in the graph below: The two states shown in red (“waiting” and “running”) are rest states, normally we expect the job to remain in these states until an event comes in, at which point we need to take actual to get the job into the next state. The other states are temporary states; these allow a job to run shell script to prepare for the job itself to be run (“starting”) and clean up afterwards (“stopping”). For services that should be respawned if they terminate before an event that stops them is received, they may run shell script before the process is started again (“respawning”). Jobs leave a state because the process associated with them terminates (or gets killed) and move to the next appropriate state, following the green arrow if the job is to be started or the red arrow if it is to be stopped. When a script returns a non-zero exit status, or is killed, the job will always be stoped. When the main process terminates and the job should not be respawned, the job will also always be stopped. As already covered, events generated by the init daemon or received from other processes cause jobs to be started or stopped; also manual requests to start or stop a job may be received. The communication between the init daemon and other processes is bi-directional, so the status of jobs may be queries and even changes of state to all jobs be received. How does it differ from launchd? launchd is the replacement init system used in MacOS X developed as an “Open Source” project by Apple. For much of its life so far, the licence has actually been entirely non-free and thus it has only become recently interesting with the licence change. Much of the goal of both systems appears initially to be the same; they both start jobs based on system events, however the launchd system severly limits the events to only the following:

• system startup,

• file modified or placed in queue directory,

• particular time (cron replacement),

• connection on a particular port (inetd replacement).

Therefore it does not actually allow us to directly solve the problems we currently have; we couldn’t mount filesystems once the “filesystem checked” event has been recived, we couldn’t check filesystems when the block device is added and we certainly couldn’t start daemons once the complete filesystem (as described by /etc/fstab) is available and writable. The launchd model expects the job to “sit and wait” if it is unable to start, rather than provide a mechanism for the job to only be started when it doesn’t need to wait. Jobs that need /usr to be mounted would need to spin in a loop waiting for /usr to be available before continuing (or use a file in a tmpfs to indicate it’s available, and use that modification as the event). This is not especially surprising given that Apple have a high degree of control over both their hardware and the actual underlying operating system; they don’t need to deal with the wide array of different configurations that we have in the Linux world. Had the licence been sufficiently free at the point we began development of our own system, we would probably have extended launchd rather than implement our own. At the point Apple changed the licence, our own system was already more suitable for our purposes. How does it differ from initng? Initng by Jimmy Wennlund is another replacement init daemon intended to replace the sysvinit system used by Linux. It is a dependency-based system, where upstart is an event-based system. The notion of a dependency-based system is interesting to talk about at this point. Jobs declare dependencies on other jobs that need to happen before the job itself can be started. Starting the job causes its dependencies to be started first, and their dependencies, and so on. When jobs are stopped, if running jobs have no dependencies, they themselves can be stopped. It’s a neat solution to the problem of ordering a fixed boot sequence and the problem of keeping the number of running processes to a minimum needed. However this means that you need to have goals in mind when you boot the system, you need to have decided that you want gdm to be started in order for it, and its dependencies, to be started. Initng uses run levels to ensure this happens, where a run level is a list of goal jobs that should be running in that run level. It’s also not clear how the dependencies interact with the different types of job, a dependency on Apache would need the daemon to be running where a dependency on “checkroot” would need the script to have finished running. Upstart handles this by using different events (“apache running” vs. “checkroot stopping”). Again while interesting, Initng does not solve the problems that we wanted to solve. It can reorder a fixed set of jobs, but cannot dynamically determine the set of jobs needed for that particular boot. A typical example would be that if the only dependency on the job that configures networking is the mount network filesystems job, then should that job fail or notbe a goal (e.g. because there are no network filesystems to be mounted) the result is that network devices themselves will not be configured. You could make everything a goal, and just use the dependencies to determine the order, however this is less efficient than just ordering the existing sysv-rc scripts (which can be done at install time). Another example is that often you simply don’t know whether something is a dependency or not without reading other configuration, for example the mount network filesystems may be a dependency of everything under /usr or may just be a dependency of anything allowing the user to login if it just mounts /home. The difference in model can be summed up as “initng starts with a list of goals and works out how to get there, upstart starts with nothing and finds out where it gets to.” How does it differ from Solaris SMF? SMF is another approach to replacing init developed by Sun for the Solaris operating system. Like initng it’s a dependency-based system, so see above for the differences between those systems and upstart. SMF’s main focus is serive management; making sure that once services are running, they stay running, and allowing the system administrator to query and modify the states of jobs on the system. Upstart provides the same set of functionality in this regard, services are respawned when they fail and system administrators can at any time query the state of running services and adjust the state to their liking. Will it replace cron, inetd, etc? The goal of upstart is to replace those daemons, so that there is only one place (/etc/event.d) where system administrators need to configure when and how jobs should be run. In fact, the goal is that upstart should also replace the “run event scripts” functionality of any daemon on the system. Daemons such as acpid, apmd and Network Manager would send events to init instead of running scripts themselves with their own perculiar configuration and semantics. A system administrator who only wanted a particular daemon to be run while the computer was on AC power would simply need to edit /etc/event.d/daemon and change “on startup” to “on ac power”. What about compatibility? There’s a lot of systems administrators out there who have learned how Linux works already and will not want to learn again immediately, there’s also a large number of books that cover the existing software and won’t cover upstart for at least a couple of years. For this reason, compatibility is very important. upstart will continue to run the existing scripts for the forseeable future so that packages will not need to be updated until the author wants. Compatibility command-line tools that behave like their existing equivalents will also be implemented, a system administrator would never need to know that crontab -e is actually changing upstart jobs. Does it use D-BUS?

“To D-BUS people, every problem seems like a D-BUS problem.” —Erik Troan

The UNIX philosophy is that something should do just one job, and do it very well. upstart’s one job is starting, supervising and stopping other jobs; D-BUS’s one job is passing messages between other jobs. D-BUS does provide a mechanism for services to be activated when the first message is sent to them, thereby starting other jobs. Some people have taken this idea and extended it to suggest that all a replacement init system need do is register jobs with D-BUS and turn booting into a simple matter of message parsing. This seems wrong to me, D-BUS would need to be extended to supervise these services, provide means for them to be restarted and stopped; as well as deal with being process #1 which means cleaning up after children whose parent’s have died, etc. It seems far simpler to arrange for D-BUS to send an event to init when it needs a service to be started, and focus on being a very good message passing system. The IPC mechanism used by upstart is not currently D-BUS because of various problems, however it’s always been expected that even if init itself doesn’t communicate with D-BUS directly, there would be a D-BUS proxy that would ensure messages about all init jobs and events would be given to D-BUS and D-BUS clients could send messages to init to query and change the state of jobs. What is the implementation plan? Because this is process #1 we are changing, we want to make sure that we get it right. Therefore instead of releasing a fully-featured daemon and configuration to the world, we’re developing it in the following stages:

1. Principal development; at the end of this stage the daemon has been implemented and can manage jobs as described.
2. Replacement of /sbin/init while running the existing sysv-rc scripts. This is the shake-down test of the daemon, can it perform the same job as the existing sysvinit daemon without any regressions?
3. /etc/rcS.d scripts replaced by upstart jobs. These consitute the majority of tasks for booting the system into at least single-user mode, and contain many of the current ordering problems and race conditions. If the daemon solves the problems here, it will be a success.
4. Other daemon’s scripts replaced by upstart jobs on a package-by-package basis; this will be an ongoing effort during which upstart will continue running the existing sysv-rc scripts as well as its own jobs. During this time the event system may be tweaked to ensure it truly solves the problems we need.
5. Replcement of cron, atd, anacron and inetd. This will happen alongside the above and result in a single place to configure system jobs.
6. Modification of other daemons and processes to send events to init instead of trying to run things themselves.

The current plan is that we will be at least part of the way into stage #3 by the time edgy is released, with that release shipping with upstart as the init daemon and the most critical rcS scripts being run by it to correct the major problems For edgy+1 we hope to have completed stage #5 and be at least part of the way into the implementation of stage #6. From the start of development of edgy+2, no new packages will be accepted unless they provide upstart jobs instead of init scripts and init scripts will be considered deprecated. What state is it in now? The init daemon has been written and is able to manage jobs as described above, receiving events on the control socket to start and stop them. This has now been uploaded to the Ubuntu universe component in the upstart package for testing before it becomes the init daemon. We welcome any experienced users who want to help test this; install the package and follow the instructions in /usr/share/doc/upstart/README.Debian to add a boot option that will use upstart instead of init. If your system boots and shut downs normally (other than a slightly more verbose boot without usplash running) then it is working correctly. Other types of events will be added as required during development and testing. Currently only a basic client tool (initctl) has been written, compatibility tools such as shutdown will be written over the next week or two before it replaces our sysvinit package.

It’s been over a year now since my last proper upload to Debian, and nine months since I announced my intent to put aside working on Debian for a while. With Matthew Garrett’s resignation from Debian, several people have compared it to my own “resignation” from Debian. It has got my thinking about whether I currently intend to ever end my “Sabbatical” and return as an active Debian Developer. I think that the end of my love-affair with Debian started at Debconf last year where several developers treated those of us who also worked on Ubuntu quite rudely. Someone was attacked for wearing an Ubuntu t-shirt at the conference, while someone else was applauded for wearing a “Fuck Ubuntu” t-shirt. That’s where I realised that maybe I didn’t have as much in common with these people as I thought I did. I still don’t understand why Debian singles Ubuntu out for this kind of treatment, we’re still the only derviative distribution that makes all of our patches to Debian available, yet Ubuntu is claimed to not do anything at all. Another example is that Ubuntu is being asked to change the Maintainer field of every package, something no other derivative is being asked to do or has ever been asked to do. Martin Krafft has had some interesting things to say about this strange relationship in the past. If that was the start of my falling out with Debian, I think that Debian considering removing documentation and firmware from the distribution, especially the documentation, was another point I started wondering whether I shared anything in common with the project anymore. Call me strange, but I think that one of the fundamental purposes of a Linux distribution is to be useful to its users. If nobody can use the distribution because it doesn’t support their hardware, and even if it did, all the documentation has been stripped out; I started to wonder what it’s aims are. It became increasingly apparent that the only users Debian was considering a priority were its own developer. And the third thing is simply a matter of Fun. Fun for me, at the moment at least, has been to build a system that fits together extremely nicely with each component doing the right thing. For Ubuntu this has meant being a driving force for it being Linux 2.6 only, with reliance on udev for hardware, etc. Upstart is just a continuation of these goals, getting a system which all “just works”, even if it means throwing out a few things people were previously fond of. All of these things would have been impossible to do in Debian itself. Getting upstart installable required changes to twelve different packages, including sysvinit itself; at a worst case, this would have required the agreement of twelve different maintainers in Debian. It’s often exhausting just persuading one of the reason for the change, persuading a dozen would have been a herculian effort. Perhaps Matthew is right, what Debian lacks is a single leadership. There’s nobody in Debian I could have gone to for approval over the changes I wanted to make, whose decision developers cannot overrule. Ubuntu has such people (the Technical Board and sabdfl), which gives the project an obvious direction instead of a couple of hundred people all pulling in different directions. In a way, I don’t feel that I’ve left Debian. I feel like I was happily going along, only to realise the mob had gone in a different direction and with no easy way of rejoining the group.

Lots of happy GRs! It's GR season, and everyone is rushing to produce a nice GR that would make Debian oh so much better than it already is. But some of us either lack the fantasy, or the grammatical competence, or just the time to contribute to this important effort. For those people, I prepared a handy polygen grammar that they can use. Here is today's GR:

1. After the release, the Donors widly do not take the Community in order to overruling this resolution in the interest of the Debian Release Managers for the purpose of promoting more prompt action.
2. The Debian Project Leader has the support of Debian for apologising the funds as seems subsidiary and reasonable for the purpose of promoting cooperation between Debian and the Debian Release Managers.
3. The Delegates broadly fund the swift funds for funding the Debian FTP Masters for the duration of the mandate for the purpose of the RMs.
4. For the purpose of being 100% Free Software, the Debian Project subsidiaryly can overrule the core proprietary drivers in main in order to apologising the needed funds for the Cabal promptly in the benefit of having a more harmful Project.
5. As seems harmful and experimental, the Debian Release Managers are devalued by the Debian FTP Masters in order to disbursing the copyright holder for the duration of the mandate for the purpose of Debian.
6. The Leader lets it be known that the Developers are approved by the Donors to reasonably revoking the Developers-controlled plan during the forthcoming release in the benefit of promoting more potential action.
7. Promptly, the Debian FTP Masters can be approved by the Delegates to establishing the reasonable Developers following internal discussion in the interest of our users and Free Software.
8. Effectively, the Delegates have the reasonable support of the Developers for neededly cooperating with the firmware in main with immediate effect, during the forthcoming release of Debian for the purpose of Everyone.
9. Debian reasonably funds the Community for broadly revoking the donations in the interest of Everyone for the purpose of having a more appropriate Debian Secretary.
10. In the interest of promoting more needed action, Everyone is of the core opinion that the Developers cannot be authorised by the Delegates to establishing the Developers-controlled Debian Release Managers as seems reasonable and needed for the purpose of reducing the delays of the New Maintainer queue.

I wish this GR generator helps to satisfy all our GR needs, and will finally free some time for people to work on making etch a really great distribution for all of us to run and love.

Today's the "day of Genius" in the French Revolutionary Calendar -- a festival to celebrate human reason, innovation, and inspiration. Something that deserves our respect and attention. My big genius accolades today are for the people who put on the Piknic Electronik Summer Sundays in Montreal. We stopped by the last one for 2006 yesterday, and it was a great time. Our friend John Usher (in town to defend his Ph.D. thesis) came along with us, but we also met friends Jeff and Anne-Marie, Lou and Candace and little Olive, Patti and Meg and Lucinda and Damian and Douglas and... lots of folks. Piknic remains one of my favorite parties in Quebec. An afternoon dance party under a giant Calder stabile on a beautiful island park in the St. Laurence River? Truly genius! I hope Piknic 2007 keeps growing and going with the mellow, friendly atmosphere that it's had in the past. tags: montreal piknic electronik party genius

Web 2.0 Conference So, I'm sad to see that the Web 2.0 Conference in San Francisco in November is sold out. Maj and I made plans to visit SF during this time just to get to the conference, but I guess it's all filled up. Now I'm trying to track down a spare ticket or two. Anybody got a miracle? tags: web2.0 web2con san francisco miracle

R RS There's now a draft version of the Revised Report on the algorithmic language Scheme (R RS). It's not much news for folks who read the recent status report on R RS, but it's still pretty interesting. Most of the good ideas seem to have gotten into the spec, and the icky idea of doing immutable pairs seems to be gone now. Check out http://www.r6rs.org/ for a copy of the draft spec and a signup form for the discussion list. tags: r rs scheme spec

SxSW Panels and Wiki I'm pretty excited to see that the new 2007 South-by-Southwest Interactive panel voting interface is up today. I proposed a panel called Commercialization of Wikis: Open Community that Pays the Bills, to discuss different ways that private companies are creating wikis and investing in Wiki technology. I was surprised to hear that, for SxSW Interactive 2007, it's the only proposed Wiki panel! If you're thinking about SxSW 2007, or if you just feel like voting on things, please drop by and give the wiki panel your support. tags: wiki sxsw sxsw2007

Ms. P. I'm really proud of my cousin, Lisa Prodromo, who's a teacher in Chicago. Lisa's from the poor branch of the family that can't afford a "u" at the end of their name, but she's overcome that hardship and is now a really great English teacher. She's got a blog at http://www.msprodromo.com/ for her students, but I'm waiting for her to bust out with one for grownups, too. Anyways, she was just nominated for the prestigious Golden Apple award, a Chicago-area teachers award. I'm sure she's going to win. tags: lisaprodromo u msprodromou teaching chicago golden apple : What's the protocal for commenting here in your bliki? Edit now and ask questions later has always worked for me, so I'll try that. When am I got to get an introduction to the illustrious Chicago Ms. P? We're doing some scheming here in Chicago and would love to include her. --TedErnst

It's the Festival of Virtue today in the French Revolutionary Calendar -- the first of the five wp:sansculottides, festival days at the end of the year just before the fall equinox. The day is dedicated to singing the praises of individuals who've shown especially good qualities. I'd probably start off with the great people involved in Wikitravel -- they've been hugely successful at self-organizing and creating an incredible collection of high-quality travel guides. I'm always amazed at the persistence and goodwill of this great group of unselfish and dedicated travellers. Another is the great local local Montreal Burning Man community, putting together Ignition 2006, the regional burn event here in Quebec. There are people coming out of the woodwork to make this a fun campout, and I'm really looking forward to the event next weekend. There's still a lot to do, but I think it's going great. Who else? The thousands of people making and sharing Open Source software and Open Content music, images, and text continue to astound me. When we're in the thick of it, it's hard to remember how generous and giving you have to be to dedicate time and energy to sharing Free Information with the world and with posterity. It is a saintly pursuit and it deserves praise and support. tags: vertu equinox ignition open source

Yesterday was my turn as "primary care giver" (PCG) with Amita June, so I took the opportunity to do some shopping. I was on Autoroute 40 on my way out to the Ikea on rue Cavendish around 1PM when they had a breaking bulletin on the CBC. Yes, the Dawson C gep shooting -- they were sending a reporter to the scene. For those of you outside Montreal, yes, I and my family are fine, and we don't have any friends who were affected by the shooting. It's been strange in town, but we're physically safe and sound. Thanks to everyone who's asked. tags: montreal dawson shooting

Piknic Electronik On a more cheery note, this upcoming Sunday is the last Piknic Electronik for 2006. The last picnik is always quite sweet, and as usual Ninja Tune will be closing out the season. Smart, fun Kid Koala and, my personal fave, Ghostbeard, are on the lineup. Should be a great time, and it's supposed to be sunny on Sunday, so a nice day to be in Parc Jean Drapeau. tags: piknic electronik ninjatune montreal music

Ignition 2006 Burning Man just finished up last week, and here in Montreal the local Burning Man community is having a campout and bonfire to celebrate. The so-called "regional burn", called Ignition, is going to happen 22-24 September in the wt:Eastern Townships; more info on the Br leurs wiki. Maj and I are the regional coordinators for Burning Man activities, and we've been busy the last few weeks lining up the basics (tickets, toilets, insurance... check, check, check). Now we're looking forward to seeing what folks will be doing this time around. Our local Burning Man community is fabuloso -- the people are extra cool. tags: burning man montreal regional burn bruleurs ignition

You would be forgiven for thinking that using Mongrel clusters to serve Rails applications was only a good idea if you have Apache 2.2 installed, as this is what most of the instructions on the web advise. However, there are good reasons for still running Apache 2.0, one of them being that it's the most up to date version packaged in Debian and Ubuntu Linux. So, without mod_proxy_balancer, what can you do? A simple solution is to use the randomizing feature in mod_apache's rewrite map feature. Say for instance you had 3 Mongrel servers, running on ports 4000 to 4002 on localhost. First create a file map.txt containing these numbers:

ports  4000 4001 4002 

Then ensure the following directives are present in your virtual host configuration:

ProxyRequests Off
ProxyPassReverse / http://localhost:4000/
ProxyPassReverse / http://localhost:4001/
ProxyPassReverse / http://localhost:4002/
ProxyPreserveHost On
RewriteEngine On
RewriteMap  servers rnd:/path/to/your/map.txt
RewriteRule ^/(images stylesheets javascripts)/?(.*) $0 [L]
RewriteRule ^/(.*)$ http://localhost:$ servers:ports /$1 [P,L]

Of course, Apache config is complex and I advise you to test this properly — it's possible if you are not careful to leave your web server as an open proxy. Thanks to Matt Biddulph for pointing out this method to me. I've written it up as nobody else seemed to have done so thus far.

Good news for the Free Software world: From Harald Welte's blog, who started the gpl-violations.org project:

Today I have receive news that we've won the first regular civil court case on the GPL in Germany. This is really good news, since so far we've only had a hand full of preliminary injunctions been granted (and an appeal case against an injunction), but not a regular civil trial. The judge has ruled, but the details of the court order have not been publicised yet. I'll publicised the full details as soon as thus details are available in the next couple of weeks.

See also this Heise News article (German).

Perhaps somebody knows it... I crawled the web for it, but didn't find a real hint for my problem. Say one player (called A) in a no-limit round goes all-in. Player B calls the all-in. Player C raises. Player A does not participate in any further betting. Player B folds. The side-pot containing the raise of player C is given back to him. All three, A, B and C, are in the main pot, but B folded after the raise of C. So my question follows: Is B eligible to win the main pot, even if the hand was folded after a raise? My definition of folding is to pass the cards on to the dealer. When we played yesterday the other guy (B) told me (C), that even if he folded after my raise he could still win the main pot, so there is a showdown with three pairs of hole cards.