The migration was rather easy

sudo aptitude install bzr-svn
# patch (see below)
bzr branch svn://svn.debian.org/reportbug-ng    # That's right I branch directly from a SVN repo!
# ignore the error
bzr push --use-existing-dir sftp://venthur@bzr.debian.org/bzr/reportbug-ng

To get your own branch:

bzr branch http://bzr.debian.org/bzr/reportbug-ng/

Bzr-svn really makes it easy to migrate from svn to bzr… well, in theory. In practice we have #415721, but fortunately there is an easy workaround. Just temporarily apply this trivial patch:
--- /usr/share/pycentral/bzr-svn/site-packages/bzrlib/plugins/svn/__init__.py 2007-04-20 09:30:00.000000000 +0200
+++ /usr/share/pycentral/bzr-svn/site-packages/bzrlib/plugins/svn/__init__.py.new 2007-04-20 09:30:24.000000000 +0200
@@ -23,7 +23,7 @@
import bzrlib __version__ = '0.2.0'
-required_bzr_version = (0,13)
+#required_bzr_version = (0,13) def check_bzrlib_version(desired):
"""Check that bzrlib is compatible.

and life is good again. The reason why I switched from a centralized to a distributed RCS was that I really like the option to do (small) local checkins and just do the “real” checkin when the work is done. In terms of BZR it means commits to my local branch for smaller changes and pushes back to the mainline for every major change. Oh, and it’s also nice always having the full repository data locally stored. My requirements for the RCS were: it should be easy to use (no steep learning curve), well tested and somewhat mainstream. BZR fits quite well, especially since Ubuntu heavily relies on it for their launchpad stuff. PS: Thanks to the alioth team for creating the BZR repository so quickly, it just took like 1 minute.

Alan Robertson (a major contributor to the Heartbeat project) commented on my post failure probability and clusters. His comment deserves wider readership than a comment generally gets so I'm making a post out of it. Here it is:

---

One of my favorite phrases is "complexity is the enemy of reliability" . This is absolutely true, but not a complete picture, because you don't actually care much about reliability, you care about availability.

Complexity (which reduces MTBF) is only worth it if you can use it to drastically cut MTTR - which in turn raises availability significantly. If your MTTR was 0, then you wouldn't care if you ever had a failure. Of course, it's never zero

But, with normal clustering software, you can significantly improve your availability, AND your maintainability.

Your post makes some assumptions which are more than a little simplistic. To be fair, the real mathematics of this are pretty darn complicated.

First I agree that there are FAR more 2-node clusters than larger clusters. But, I think for a different reason. People understand 2-node clusters. I'm not saying this isn't important, it is important. But, it's not related to reliability.

Second, you assume a particular model of quorum, and there are many. It is true that your model is the most common, but it's hardly the only one - not even for heartbeat (and there are others we want to implement).

Third, if you have redundant networking, and multiple power sources, as it should, then system failures become much less correlated. The normal model which is used is completely uncorrelated failures.

This is obviously an oversimplification as well, but if you have redundant power supplies supplied from redundant power feeds, and redundant networking etc. it's not a bad approximation.

So, if you have an MTTR of 4 hours to repair broken hardware, what you care about is the probability of having additional failures during those four hours.

If your HA software can recover from an error in 60 seconds, then that's your effective MTTR as seen by (a subset) of users. Some won't see it at all. And, of course, that should also go into your computation. This depends on knowing a lot about what kind of protocol is involved, and what the probability of various lengths of failures is to be visible to various kinds of users. And, of course, no one really knows that either in practice.

If you have a hardware failure every 5 years approximately, and a hardware repair MTTR of 4 hours, then the probability of a second failure during that time is about .009%. The probability of two failures occuring during that time is about 8^10-7% - which is a pretty small number.

Probabilities for higher order failures are proportionately smaller.

But, of course, like any calculation, the probabilities of this are calculated using a number of simplifying assumptions.

It assumes, for example, that the probabilities of correlated failures are small. For example, the probability of a flood taking out all the servers, or some other disaster is ignored.

You can add complexity to solve those problems too ;-), but at some point the managerial difficulties (complexity) overwhelms you and you say (regardless of the numbers) that you don't want to go there.

Mangerial complexity is minimized by uniformity in the configuration. So, if all your nodes can run any service, that's good. If they're asymmetric, and very wildly so, that's bad.

I have to go now, I had a family emergency come up while I was writing this. Later...

---

End quote.

It's interesting to note that there are other models of quorum, I'll have to investigate that. Most places I have worked have had a MTTR that is significantly greater than four hours. But if you have hot-swap hard drives (so drive failure isn't a serious problem) then having machines have an average of one failure per five years should be possible.

A complete set of Debian 4.0 on CD and DVD consists of 292 CDs and 39 DVDs. If you've downloaded or bought all 331 discs, here's how you can throw 324 of them away. Or, how to pick the right ones to get in the first place. First, the one disc that is all you really need for Debian 4.0: The multi-arch DVD! This is the neatest disc available for etch, it can boot on x86 systems, both 32 bit (i386) and 64 bit (amd64), as well as on powerpcs. It will detect the architecture and automatically boot the right one. It contains enough software to install a nice desktop using only the DVD, no network needed. And it includes the source code to all that software on the same DVD. This DVD is perfect for giving out at conferences, or to friends, or for that desert island scenario, and it's really the only Debian disc you need. If you want a second Debian disc, I recommend the netinst CD. This disc is under 200 megabytes in size and is designed to be written to a 3" mini-CD. Much easier to carry around than a full-size CD, so it's great for those Debian installs that you didn't expect. It's also a handy rescue disc (just boot with "rescue"). Four other CDs are of some interest, to round out your collection. The multi-arch CD has the same software as the netinst CD, but it's a full-size CD, that supports the same three architectures as the multi-arch DVD. The first CD from the CD set can install a Gnome desktop system without accessing the network and is a good general-purpose CD. The KDE CD and XFCE CD provide some choice in which desktop environment you install. Finally, one other CD merits mention. The businesscard CD is a tiny but full-featured Debian CD that can be written to a square or "hockey rink" shaped disc that is sized the same as a business card. This can be an eye-catching giveaway, if you can get the businesscard CDs produced in bulk on the cheap (if you do, please let me know). My experience with putting them in a wallet though is that they won't last more than a few weeks. If you want to have Debian installation/rescue media you can carry with you everywhere, you'll have better luck with an inexpensive bootable USB keychain. The other 324 discs are only of interest to archivists, completists, and those in certian oddball scenarios.

Last weekend I got a hardware donation from muempf. It’s a new 1U server with the following specs:

Supermicro P8SCi Systemboard
Intel P4 3.00GHz
2x 512 MB DDR2 533MHz unbuffered ECC Systemmemory
2x 160 GB SATA disk (ST3160812AS)
2x GE Networkcard (BCM95721)
Console Redirection

I ordered additional 2x 1024 MB DDR2 533MHz modules and replaced an old server with this new system.
The system was installed on a Software Raid(1). The system migration was smooth, except problems getting the NICs up and running. They was recognized as eth2 and eth3 (10 MBit and no link). After hours searching around, I was guessing the problem is anywhere related to udev. Daniel told me to wipe ‘/etc/udev/rules.d/z25_persistent-net.rules’ nearly at the same time I saw, this was the only file with different size in ‘/etc/udev/’ compared to a working (etch) system on this hardware. Removing the file did the trick. As the system is running now very well, sincere thanks are given to muempf! Debian, planet

Wikitravel has organized an informal trip to Puerto Rico and I am of course reading the Puerto Rico blog entries as they are posted. Here are my suggestions for what to do there, which I passed over to them. One day I will update it and spend more than half an hour on the writing. I am eager to see what they say. I love the island but know that it can be a little hard to travel in, unlike let’s say some tropical paradise like Thailand. It is just a little too formalized and expensive perhaps and you need to know a lot since there are not droves of informal travels to tell you that sort of information. But it is a neat place with lots to do. I wish them happy and safe travels.

So, this is my last evening (and when I remember correctly the first one I’m at home) of my holidays. All began last Friday called “Karfreitag”, a national holiday. To be correct, the first party was already on Thursday and they continued daily till Monday evening. The best event in this time was Sunday afternoon, some minutes after I waked up Debian GNU/Linux 4.0 aka Etch was released, what a feeling. It was especially interesting because it’s the first stable release with some of my packages and it was a great experience to see how releasing and planning works. I often think back to the two bug squashing parties in Zurich, one in September and one in October iirc. Back to my holidays: First it was planned that I go with my sister to Zurich from Monday evening till Thursday evening, but then I got a appalling call from madduck who told me that he is in the hospital in Zurich with several broken bones. We planned to sleep in madducks flat and so we couldn’t get the key and went Tuesday morning. Walking through Zurich, getting some informational material from the University Zurich for my Sister (she maybe wants to study there) and the visiting madduck. After the visit we went again to the center of the city and walked without a real destination. In the evening we finally went to Oerlikon and went to “our” flat. After installing our sleep places (goddamn, I want to have a waterbed) we went to Migros to buy some food and drinks for the evening and the next day. The next day we really got up quite early and visited Zurich with a city guide, a lot of sightseeing and hanging in some bars. In the afternoon Daniel Baumann also was in Zurich and we went to have a drink together and also Tobias Ast came and staid with us till the next evening. We really had fun together and the main thing we did on Thursday was relaxing on the lake of Zurich and in the evening we went home. Then it was finally friday, I looked forward to this day for about one week, why? The release party in Zurich!! It was my first release party on the Irchel area in Zurich, we grilled, had some beer together and talked about god and the world. It also was the first time i met Adrian von Bidder and Mathias St rmer in person, especially with Adrian i had a longer interesting discussion about network devices from Cisco and their special prices. Saturday was already the next party day. When I was 13 we had a supply teacher for our sick teacher for 2 months, I was her horror pupil. Fine - some weeks ago I met her again in a Pub in the evening and we staid together the whole evening and became good friends in a way, so I was also invited (as the only of her pupils) to her flat share party. I met several “new” people and some of them (mostly IT students) recognized my Debian t-shirt and I had some interesting discussions about free software and had to explain the philosophy of Debian to some of them. So yes, now it’s sunday, I’m more tired than before my holidays but I’m really happy, my holidays were great because of some adventures. Regards to all to my friends… Tomorrow I will continue working and have several tasks open, especially upgrading some Debian servers from Sarge to Etch (Spamfilters, LDAP, Proxy servers…) and I hope I won’t have many troubles. In addition I have also some tasks open for Debian which I’d like to complete this week.

Frustration and (missing) flow blew my mind away in the last hours. I didn't count them properly, but I would guess I had more than 20 network connection losses today. And in at least 75% of them I was working online or in the middle of an irc conversation.

Then I switched to wired networking and after 5min I had another network crash. Ten minutes later my laptop froze completly when loading planet.

So I switched to a beer flow. I'm uneasy to commit to drink a beer for each network loss, but this is how I feel at the moment.

Besides these little annoyances, dudesconf is pretty and pretty well organized, thanks and kudos to the team making this possible and taking care of many little details. You rock! I haven't heard anybody else complain about the network so I guess it's my lovely hardware - which is running etch, reinstalled this wednesday, so I don't blame the software except some drivers for not properly (as in open) documented hardware.

I'm looking forward to next year when I can easily justify buying a new laptop to myself.

I've decided I wanted to try running Debian on nc4000 (laptop PC by HP).I didn't want to erase what is already there, so I needed some external USB HDD to do that.Since I didn't feel like hunting around for a USB CD-ROM drive and creating bootable USB, or configuring PXE, I decided to install using qemu to install to the USB HDD and use that installation on the machine.It was surprisingly simple.I connected my USB-HDD to my desktop machine, which recognized the disk as /dev/sda, and I used qemu to install Debian on it. qemu -hda /dev/sda -cdrom XXXX -boot d.Note that you really need kqemu or kvm for speed.Then, I selected LVM, and installed.After initial reboot within qemu, I changed the kernel to a 686 kernel since a k7 kernel was installed, but that's the only package I changed.After reconnecting the USB HDD to nc4000, I managed to boot from the USB disk.Initially, it failed to boot since vgscan ran before USB disk was recognized, and could not find the root device.Looking at the source, I found initramfs will probably re-try after 3 minutes. But reading further, I found that the timing can be improved by specifying rootdelay= boot option to the kernel.I specified rootdelay=15 for the kernel option in grub,and voila, it found the root filesystem on LVM.The /boot filesystem was /dev/hda1 inside qemu, but it is now /dev/sda1 on the nc4000; and boot stopped at fsck on /dev/hda1.It was trivial to fix after dropping into the command-line.LVM is able to work around device name change, which is nice to know.For the graphics card, qemu and nc4000 have different cards, and I had to dpkg-reconfigure xserver-xorg.Okay, so I have Debian running on my notebook via USB HDD, now what ?

In his “Init followup” post, Erich posted a reference to his Debian-Wiki post about a proposed Debian HackFest after Etch was released (which would be about 5 days ago<smile />). Anyway, since that page at the wiki is protected, which means I can’t edit it, I’m posting my thoughts here. I agree with Erich and some other commentors at Gunnar Wolf’s blog post that it doesn’t make sense to add X init-script-only-packages for any daemon to support X init systems. Instead, each package containing one or more daemons should contain the meta information needed to create all init scripts. Basically, this would probably include script snippets which do the following operations:

• Pre-check: Check wether the package actually is installed rather than in removed/configured status.
• start: Start the daemon in background mode.
• run: Start a daemon in foreground mode (so that an exiting daemon can immediately be recognized by the init system).
• stop: Stop a daemon running in background mode.
• stop-running: Stop a daemon running in foreground mode. This should only be needed if the daemon doesn’t shut down nicely on a SIGTERM but instead needs some sort of message/semaphore to do so.
• status: Return current running status.
• reload: Reload configs, reopen logs (if supported by daemon).

Additionally, some control information would be needed including, but probably not limited to:

• Dependencies: Should allow for alternatives, lists daemons which need to be running before this daemon is started.
• Provides: Similar to package-provides, this should be used to allow things like replacing inetd with xinetd or something else providing similar functionality.
• Short Description: For init systems that are capable of showing a short description next to the name of configured daemons
• Run-Sets: Not strictly like sysvinit-runlevels, but similar, should allow the admin/user to configure different sets of daemons to start, selecting at boot by a kernel cmdline-parameter or at runtime through some command (”init 1″) which set should be running.

The script snippets listed above should allow basically any operation on a daemon, including the force-reload and try-restart commands not yet implemented by all current sysv-initscripts.

In response to Stefano's reply to my post about Coq:

toy-ness

Usually such pieces of software are more seen as academic toys, seeing it promoted as a geeky software is a joy to me.

I really hate to detract from your happiness -- but I definitely had the word "math" implicitly stuck before "geek toy". :) Most coders that I've met are, at best, indifferent to mathematics, outright hostile at worst, so I doubt that coq will get far outside of small niches where the benefits are irresistable (security software, maybe? -- and of course pure math). I read up on this stuff despite it being utterly useless for anything I'm likely to be paid to do (unless I return to academia) because I'm a hopeless weenie loser who likes math. :P

programming-language-ness

Coq is not really a programming language (even if the CoqArt book says so, to attract the developer community), it is mainly a proof assistant; i.e. a software in which you give definitions, state theorems and prove them.

Well, this all depends on how you define programming language, which is one of those never-ending definitional questions. But using my general conception of what a programming language is, I actually have noticed two programming languages inside Coq.

1. The more interesting one (IMO) is the proof language they call "Gallina" and the "Vernacular", in which you construct proofs by reducing your goal to a tautology. The goal here seems to be to compute a well-typed term in Coq's core calculus, and you generally construct programs interactively: Coq shows you the current program state (expressed as one or more goals and a set of local hypotheses) and you manipulate it by (e.g.) applying lemmas to yield new known facts.
   
   I think this language is fairly weak viewed as a programming language. It's completely unreadable and the proofs generated don't correspond to the reasoning process one normally follows when working out a proof. I am less annoyed by it now that I've learned how to do forward reasoning :), but it seems like backwards reasoning is really pushed, and that just seems .. well .. backwards to me. There's also a strong tendency to use implicitly generated names for things and to just "know" what the state of the system after issuing a command will be; as far as I can tell, the only way to understand a Coq proof is to step through it in coqide.
   
   While it's nice to be able to "trust the kernel", it would also be nice to be able to "read a proof" directly. Among other things, their inscrutability makes me think that Coq proofs would be annoying to maintain over time. This is not necessary for stuff that's part of Principia Mathematica, but seems likely if you're developing a new theory -- in particular, I would shudder (theatrically) at the mere thought of including embedded Coq proofs in my programs.
   
   Some additional brief comments on this were written by Nick Benton and put on the Web under the title of Machine Obstructed Proof.
   
   
2. The other sense is that Coq directly embeds a strongly normalizing variant of System F (I think? -- at least the simply typed LC with some type parametricity) with primitive recursion over inductive structures. This isn't Turing-complete (of course!), but I would certainly call it a real programming language.
   
   As you note, though, this is less interesting unless you want to prove facts about your programs.
   

OCaml-ness

Regarding the synergy of Coq with OCaml: yes, you can prove in Coq the correctness of OCaml program, but actually not more than you can do with programs written in other programming languages

I was specifically thinking about Concoqtion; I have no idea how other projects compare, and I apologize if I incorrectly summarized it!

Those who know me even moderately well (as well as every doctor I have ever seen), knows that my real first name as “Enid.” That is the mysterious E. that sometimes precedes the Gabriella. My mom’s intention was to call me Gabriella, the first name of some famous Italian Cabaret singer, Gabriella Ferranti. But when Enid, my aunt on my fathers side, passed away a few months before I was born, I was given the name Enid Gabriella. We have always used Biella or Gabriella but I like that I have Enid in there and have fancied from time to time to start using the name Enid. By all accounts, Enid was an amazing and energetic woman, who reared her four kids with passion, was very open to friends and family, and who, despite living a solidly upper middle class Jewish life, was also involved in interesting political work(like helping Americans doge the draft by escaping to Canada). My mom held a special fondness for her because, well, honestly I think she was one of the only members of my dad’s family who she deeply loved. And Enid always went out of her way to show her care and concern, as when she immediately went to Caracas after my mothers first child unexpectedly died of a high fever at the age of five months. Today as I was writing away, I received an email from my father that he sent to me and a bunch of cousins and other siblings where he attached a 9 page document of remembrances and memories of Enid. My dad, though in no way as bad off as my mother (health wise), is no spring chicken. And I think as he fast approaches 80 years old, he is committing a lot to writing and thus, keeping his memory alive for us. In fact, this reminded me of a really beautiful quote I recently came across on memory:

“You have to begin to lose your memory, if only in bits and pieces, to realize that memory is what makes our lives. Life without memory is no life at all, just as an intelligence without the possibility of expression is not really an intelligence. Our memory is our coherence, our reason, our feeling, even our action. Without it, we are nothing.” Luis Bu uel

But what was a little odd (but nonetheless very endearing) about most of the account is that it was not organized by stories, or date, but by car models. Yes, by technology. My dad organized the stories about Enid by virtue of the cars they had, which struck me a little strange because it is not like he was a car buff or anything (growing up we always had the most unsexy cars, like Ford Tauruses). The cars he covers are the following: The Model A Ford Convertible
The 1941 Oldsmobile
The 1948 Buick Convertible
A Chevy Convertible Once you read his little tribute, it becomes immediately clear that his choice of talking about cars is also way for him to talk about history which is my dad’s great love (he can talk to you straight for 5 hours about some odd event in WW II and why he should have become a historian) as it is about Enid. Case in point here:

This was the first General Motors car with automatic drive. It was called Hydromatic and even though this car had a powerful 8-cylinder engine, this first automatic drive was very sluggish. Forget about 0 to 60 miles an hour in 7 seconds. This was in minutes. It was the car that Abe used to teach both Enid and I to drive. We both had to have additional lessons with a stick shift car, because the driving test was only given on stick shift cars. I learned to drive in 1944, when I was 16. Enid took lessons from Abe and learned to drive in 1945 when she was fifteen. This was against the law, but the law in the name of Tom, the policeman that covered our neighborhood, liked Enid and looked the other way.

For those who care to read more (it may only be amusing to me and those few people that are into American car history), I have included all the cars and here are the main cast of characters. Ruth = My Grandmother
Abe = Grandfather
David = Dad
Enid = My Aunt, David’s sister (more…)

* t3rmin4t0r wrote a really great post “How To Minimize Your Value to The Company“. Here is my views: - Answer questions on devel forums - Yes. I used to maintain some forums, which gave me some ‘pet’ name!
- Write a technical blog - Yes (sometime!)
- Live the company values - Yes
- Write cool hacks - Yes.
- Have a serious hobby - Yes.
- Contribute to an open source project - Yes. It depends. All of us know that ‘How much business you bring to company?’ is the core question. But, I am not feeling that my value has decreased or become minimized yet.

My plan for coming home yesterday evening was simple: go to init 1 on my laptop and do a full backup while I sleep, followed by a reinstall with fai in the morning. That part of the plan worked pretty well: after less than then an hour of work, aeh, actually waiting and having breakfast, my laptop is 100% setup as it was yesterday, running shiny beryl on etch and all the configuration is the same as it was yesterday. Yay! Looks, feels and is the same system, but the installation is 60min old. So much for the joy.

The pain also started when I came home yesterday: the datacenter where my server is hosted had a huge power outtage yesterday evening and this morning there were and currently still are some hundred customers getting their machines up again. I wonder what exactly happend to turn off the power for a whole datacenter (they have megawatt sized diesel generators for power backup) but at least I'm happy it's not a hardware failure on my server. And while my server and services is up again since more than an hour, www.aol.de, which is also hosted there, is still down ;-) Update: The power was only gone for 40min, the rest of outtage is still a bit of a mystery to me: outgoing connections worked fine, incoming not at all. So I'm not really convinced that it wasn't coincidence that the reboot fixed my server...

Wow, what a wonderful weekend was this for Debian. And, yet again, I managed to miss the live announcement and party on IRC.
So... We got a shiny, new, French DPL. Just after that, we got one last release for Sarge, and right away we got a stable Etch - Who says having a new DPL cannot speed up things? ;-) Anyway... I don't remember where I started the meme when Sarge was released (it was not on my blog, it seems)... But here it goes again:
What were you doing at...
Etch release? Having a nice time with Nadezhda, walking around this broken and dear city in my last day of vacations.
Sarge release? At my psychologist. Yes, Sarge drove us all nuts.
Woody release? Sitting at a lent workstation at Departamento de Seguridad en C mputo in my University. Of course, the announcement was broadcasted right away to everybody around me ;-) I was in NM by then, and was a bit disappointed because my work didn't appear in the release.
Potato release? Don't know... I was not yet involved with Debian by then.
[Update]: Thanks to Wouter, my old meme-starting message appeared - is he more patient than I am, or just more organized? :-) Anyway, boo for Jaws breaking old URLs (I upgraded 0.4->0.5->0.6->0.7 since then)

lkcl: Ratings and reports are explained in the Advogato FAQ, by the way. One thing I can't tell whether you realized or not: The report at /rating/report/lkcl does not show what other people think of your diary. It shows what you (and the people you certified) think of other users' diaries. The lumpiness of the histogram is because most users don't use the full range of ratings. And since confidence scores fall off exponentially by network distance, your confidence-weighted histogram will be skewed toward ratings given out by yourself and people you directly certified. For example, I tend to rate most diaries between 4 and 9, so I expect my report to be skewed toward those values.

Now that Debian Etch is released, we can finally start working on Lenny. For me, amongst normal package maintainer tasks, this includes:

• (definitely) a small-sized ttf-bitstream-vera to ttf-dejavu transition (dejavue replaces vera).
• (definitely) a middle-sized libungif4 to giflib transition and removal of libungif (getting previously patended library back, #392160).
• (most likely) large-sized ncurses transition (enabling wheelmouse support, #230990).

However, I'm seeing mass bug filing times coming! :) ...right, and parties too.

The etch release is imminent, so I thought I'd run sloccount on an unpacked Debian source tree. I wrote a little script that downloads and unpacks all Debian source packages. It does dpkg-source -x only, no debian/rules unpack or such, since that isn't standardized. The result is a source tree that is 46 gigabytes. Unfortunately, there is something in that tree that makes sloccount fail. It reports a mere 45 million lines of code, which is about 1022 lines per kilobyte. (Later, I'll narrow it down and report an actual bug. For now, the best I have is "something in Debian breaks sloccount".) Sloccount would give fairly good results, and it would exclude, say, JPEGs, of which there are 455. However, in this situation the best I can easily come up with is a sum of running a plain wc -l on each file, and that sum is 1005505921. That's just over one billion lines of code, in 2868448 files, or 350.54 lines per file, on average. Disclaimer: that sum includes many non-source files, such as the JPEGs, and a number of packages don't actually unpack properly with dpkg-source, you have to run some variant of debian/rules unpack. However, I'd be willing to bet the number is in the correct ball park. We can get better results once sloccount gets fixed.

As I've posted before, I recently read Lawrence Rosen's Open Source Licensing Software Freedom and Intellectual Property Law. And I'm sure many of you will recognize the enormous constructive value of early-morning cavilations. Well, today I woke up thinking about strengths and weaknesses in th different Free Software licenses, and I decided to add my grain to the world of license proliferation. So, here goes version 3.14 of the CoPL. I wonder how long will it take before it reaches /usr/share/common-licenses on Debian systems ;-)

		       CONFUSING PUBLIC LICENSE
		       ========================
	This is version 3.14 of the Confusing Public License (referred to from
now on as "CoPL"). Copyright (c) 2007 Transnational
Republic. Additional copies of this license can be purchased at no
cost from any Transnational Republic citizen at any of its recognized
outposts, or freely copied. 
	Any legal claims regarding Original works or any of their Standard
versions licensed under the CoPL Should not abide by and be carried
out according to the current law of the Transnational Republic. The
Original author to pay for any attorney and other legal fees of any
dispute regarding said Original author.
	This license text is designed to protect all the Technology covered
under it under a thick layer of incomprehension. No technical,
professional or social measures might be used to subvert the intent of
this license. This license Must be carefully or professionally
reviewed by a lawyer or attorney, under any jurisdiction. Any serious
attempt to understand this license will immediatly terminate your
rights to keep reading this license. Original works licensed under the CoPL
will not be affected by this provision, you will still have permission
to use them.
	Redistributions of source code Should not retain the above copyright notice,
this list of conditions and the following disclaimer. 
	0. This License applies to any program or other work which contains a
   notice placed by the copyright holder saying it may be distributed
   under the terms of this Confusing Public License. The Original work
   below refers to any such program or work or Standard version.
	1. You desire to license the Technology to a
   large community to facilitate research, innovation and product
   development while maintaining compatibility of such products with
   the Technology as delivered by You
	2. Original author desires to license the Technology from You on
   the terms and conditions specified in this License.
	3. Redistributions in binary form Should not reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the distribution.
	4. The names "Joe", "Curly", "Moe" and "The Three Stooges Foundation"
   May be used to endorse or promote products derived from this
   Original work without prior written permission, as they are in no way
   related. 
	5. There is no number 5. Seriously. In all Original works licensed under the
   CoPL, all necessary technical and social steps May be taken not
   to include, in any explicit way, the number 5.
	6. Original author Must make and give away verbatim copies of the
   source form of this Package
   without restriction, provided that Original Author duplicates all of
   the original copyright notices and associated disclaimers.
	7. Original author Must apply bug fixes, portability fixes and other
   modifications derived from the Public Domain or from
   the Copyright Holder. A Package modified in such a
   way shall still be considered the Standard Version.
	8. No Standard versions of the Original work Must be protected by this
   license. Original authors Should not choose a different, saner
   licensing model for the distribution of any modifications they
   make. The CoPL should be taken as a retroviral license.
	THE SOFTWARE IS PROVIDED "AS IS," WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL YOU BE
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
				     Definitions
	"You" means the original author of the work covered under the CoPL.
	"Original author" means you.
	"Thou" means God almighty.
	"May" means "Should not, no matter what".
	"Must" means "May".
	"Should not" means "Must".
	"Reasonable copying fee" means nothing.
	"Standard version" means a modified version of the Original work.
				      DISCLAIMER
	The CoPL text, from the words "This is version" and up to and
including this paragraph, is to be taken as a preamble, and will not
be effective under any circumstances. 
	All work licensed under the CoPL should be considered as licensed
under the GNU General Public License version 2 or (at your option) any
later version. It is not the task of this license to point you on
where to get hold of said license.

A cat helped spare a family from death by carbon monoxide poisoning by jumping on the bed and meowing wildly as fumes filled the home, the owners said.

Eric and Cathy Keesling told reporters that their 14-year-old cat, Winnie, played a crucial role in saving their lives March 24 after a gasoline-powered water pump in their basement caused the odorless but deadly gas to build up.

About 1 a.m., Winnie began nudging Cathy Keesling s ear and meowing loudly. It was a crazy meow, almost like she was screaming, said Keesling.

Winnie s caterwauling and jumping persisted until Keesling finally climbed out of bed and realized she was nauseous and dizzy and couldn t awaken her husband.

Paramedics found the couple s 14-year-old son, Michael, unconscious on the floor near his bedroom. The Keeslings were taken from the home in oxygen masks and treated for carbon monoxide poisoning; they soon recovered. The cat was unhurt.

I have no idea what dangers Jazz has already saved me from, but either at 4:30 or 6:00, sharp, this happens every night in my bedroom.

Just got some cheerful news from Ryan Finnie. Apparently the new version of Finnix has an amd64 kernel on the x86 disk. Per his blog post about Finnix 89: using an AMD64 kernel on a supported platform yields several advantages: ... You can chroot into native 64-bit AMD64 filesystems. Considering that's just what I needed to do yesterday (see Journal/14 Germinal CCXV), it's pretty sad that I only had a Finnix 88 CD. It was pretty dumb of me to not check the latest version, and it was wrong to say that Finnix doesn't support amd64. But it's good to know that it will work in the future. tags: amd64 finnix rescue livecd recovery

RoCoCoCamp We had another organisational meeting for RoCoCoCamp at the Bande-Passante this evening. It was really good -- we had quite a few people, and made some of the down-to-the-wire plans for the event. RoCoCoCamp is the RecentChangesCamp in Montreal the 18-20th of April, 2007. It's an "unconference" -- a community-organized conference that, we hope, will let a lot of people connect in a new way. The great thing about RoCoCoCamp -- and RecentChangesCamp in general -- is that it's hosted by the wiki community -- people who love and use wikis. But we try to reach beyond wikis, to other associated communities, organizations and individual activists. I like to think of it like this: "wiki" is a concept associated loosely with other concepts -- tied to them in some concept-space. If we just bring together people who know and understand wiki, and have them talk together, we'll achieve very little. But if we bring together people who work, think and live in those closely-associated concept circles, we've got the opportunity for fascinating cross-cultural mixing -- passionate, creative accidents. I'm really looking forward to see what kind of creative accidents we engender at RoCoCoCamp 2007. I think it's going to be really fun. tags: wiki rocococamp concept map montreal

Hellas Spectrum I did an interview tonight on Hellas Spectrum, the local Greek-language television show here in Montreal. The host, Toula Drimonis, had seen the article about me in the Gazette, had recognized my name as Greek, and wrote to ask if I'd like to be on the show. The interview was really fun, and it was great to be around Greek-speaking people for a while. Montreal has a very strong Greek community, with which I've entirely failed to connect in the 5 years (!!!!) that I've lived here. But Maj and I have talked about sending Amita June to one of the very good tri-lingual Greek-English-French private schools here in Montreal, and we'd all like to make more connections in the Greek community. Hopefully this helps! I've always felt a little cut off from the more intense Greeks here and elsewhere because... welllll... I just don't speak Greek that well. So it was great doing Hellas Spectrum -- Toula's job at the show is to include those Greek-Canadians and Greek-Americans who maybe don't speak the language and live in the neighborhood, but need to be included in the greater Greek culture. I had a great time at the interview, and on the way from the green room to the studio, we ran into the show's producer. He asked me something incomprehensible (in Greek), and when I looked confused, he said, "You don't speak Greek? That's OK. Are you Greek, though? Are you Greek here?" He touched his chest. "Are you Greek in your heart?" Yes, I am. And it was cool to feel Greek in my heart tonight. Thanks to Toula for the invitation and the HS crew for making such a great show. tags: hellas spectrum greek montreal canada