4. Our priorities are pancakes and beer We will be guidede by our need for pancakes and (preferable free) beer. We will place this interest first in our priorities. We wil support the needs of our users for knowledge of where to get many different kinds of pancakes and beers. We will not object to other kind of food and drinks, but pancakes and beer are our main common interesst and priorities. In furtherance of this need, we will provide guidance to beer and pancakes all over the world near and far away from Denmark.

For some reason the celebration of the Debian Social Contract was centered on Denmark. So I thought we might as well organize something in Denmark for real (some of us had talked about it some days ago). We have yet to decide if our main priority is beer or pancake so the plans aren’t quite final yet. lbaren has been mentioned. If you are interested in joining contact me. (Update: lbaren is closed for the month)

Wie ich bereits letztens beklagt habe, sind Callcenter die Pest des 21. Jahrhunderts.
Heute allerdings wurde dem Ganzen noch die Krone aufgesetzt.

Heute mittag rief mich der Vater meiner Freundin an, da die bei der Telekom-Hotline nichts von einer Bestellung w ssten und der Port ja sowieso noch gar nicht freigegeben w re. Also rief ich (mal wieder) nach Feierabend bei der Alice Hotline an. Komischerweise habe ich da eigentlich auch fast nur Frauen an der Leitung. Aber die heissen in keinster Weise alle Alice, auch wenn Ariane ebenfalls ein sch ner Name ist. Noch st rker bezweifle ich, da die Damen so h bsch aussehen, wie die Alice in der Werbung. Das w rde allerdings die Unf higkeit der Alice Hotline erkl ren, warum die nichts auf die Reihe bekommen. Man kennt ja durchaus den Spruch, wo der Intellekt in ein entsprechendes Verh ltnis zur Qualit t etwaigen Geschlechtsverkehrs gestellt wird. Sei's drum...

Nachdem ich ber geschlagene 10 Minuten a 14 /min auf die Weiterverbindung von der allgemeinen Hotline zur Abteiligung f r die K ndigungen warten musste, erz hlte mir die eher weniger als mehr nette Dame von der Alice Kundenbetreuung, da ja die K ndigungsbest tigung schon l ngst rausgegangen w re. Auf meinen Einwand, da diese noch in keinster Weise bei uns angekommen sei, meinte sie dann, da sie die gerne noch einmal rausschicken k nnte - so wie die gute Dame am letzten Dienstag dies auch schon machen wollte und wo die Best tigung ja dann am n chsten oder bern chsten Tag da sein sollte.
Dieses Mal hatte Alice, ehm, die Kundenveruntreuerin allerdings wohl dazu gelernt, was sie wohl auch aus der allgemeinen Hotline-T tigkeit zu h heren Weihen bef rdert hat - oder war das vielleicht doch nur die Best tigung f r obiges Sprichwort? Na jedenfalls meinte diese "Dame" dann auf meine Nachfrage, wann wir denn wohl mit dem Eingang der K ndigungsbest tigung rechnen k nnten, da sie das blo ins System eintr gt und der Brief dann wohl gegen Ende der Woche verschickt werden w rde.

Nun sollte man sich ja eigentlich als unbedarfter Kunde freuen, wenn ich blo nicht den Fehler gemacht h tte zu fragen, wann denn der Port abgeschaltet werden w rde. Denn das passiert auch gegen Ende der Woche.
Mit anderen Worten: wenn wir die K ndigungsbest tigung von Alice bekommen, brauchen wir sie gar nicht mehr, weil der Port eh schon freigegeben wurde.

Ohja, manchmal f hle ich mich bei Alice auch wie im Wunderland... seufz

Eweek has an article on a new 1TB Seagate drive. Most home users don’t have a need for 1TB of storage (the only way I’ve ever filled a 300G drive is by using it for multiple backups) and enterprise customers generally want small fast drives (with 100G drives still being sold for servers). One interesting thing to note about this is the fact that the new drive is described as being able to sustain 105MB/s (although I suspect that is only for the first few zones of the disk - see my ZCAV results page for graphs of the performance of some typical disks). The previous disks that I have seen have topped out at about 90MB/s. However even if the drive could deliver 105MB/s over it’s entire capacity it would take almost 3 hours to perform a backup - increases in IO speeds have not been keeping up with capacity increases. Another interesting thing is the potential for using the same technology in low power 2.5 inch disks. While a 1TB disk isn’t going to be much use to me a 300G 2.5inch disk that uses less power will be very useful - and it might be possible to perform a backup of such a disk in a reasonable amount of time! The latest trend in PCs seems to be small form factor (SFF) and low power machines that don’t have space for two drives. If you want RAID-1 on your home machines for reliability then that isn’t very convenient. But two 2.5 inch disks can fit in less space than a single 3.5 inch disk and therefore all the SATA based SFF machines that are currently being shipped with a single 3.5 inch disk can be upgraded to a pair of 2.5 inch disks - this will be convenient for me when those machines start going cheap at auction next year! Even for servers the trend seems to be towards 2.5 inch disks. I recently bought a 2U HP server that supports up to 8 hot-swap SFF disks, I wonder how the performance of 8*SFF disks would compare to 4 of the bigger and faster disks. The next thing we need is a method of backing up large volumes of data. The 650M data CD came out when a 150M disk was considered big. The 4.7G data DVD started to become popular when 45G disks were considered big. Now almost everyone has 300G disks and 1TB disks are becoming available yet the best commonly available backup method is a double-layer DVD at 9.4G - it seems that the vast majority of home users that make backups are using cheap IDE disks to do so. Fortunately there are some new technology developments that may improve the situation. Call/Recall has developed technology that may permit multiple terabytes of storage on an optical disk. It’s yet to be seen whether their technology lives up to the claims made about it, but we have to hope. The current storage situation is getting unmanagable.

Share This

Ben Fowler writes about the issues related to nuclear power in Australia. He spends 8 paragraphs discussing the issues on the “Right” side of politics - of which 6 concern the an Australian nuclear weapons capability and then spends 3 out of 5 paragraphs related to the “Left” side explaining that he thinks that everyone who opposes nuclear power is a Luddite. Ben didn’t bother providing any links or statistics to back up his claims, so I’ll assist him in analysing these issues by providing some facts that we can discuss. In March Spain had wind power provide 27% of all electricity (making wind power the main source of power for the country). I blogged about this at the time. While Spain has an ongoing program of building new wind power stations the majority of wind turbines in Spain are quite old (the Model T of wind power) and not nearly as efficient as modern turbines that would be installed for Australian power plants. The Danish government has announced plans to use wind power for 75% of their electricity. Denmark has a much smaller land area than Australia, which means that generating so much electricity from wind power is more technically challenging for them than it would be for us. A larger land area means that when one area has low wind speeds other areas can be used to provide power. For home electricity generation wind turbines have not yet been proven to be practical. The linear speed of the blade is determined by the wind speed and the rotational speed is therefore a factor of the wind speed divided by the radius of the blades. This means that smaller turbines have higher rotational speeds which causes more noise (bad for getting council approval), also to avoid turbulence a wind turbine will ideally be some distance above the ground (8 meters is good) which again gives problems when getting approval. The O’Connor Hush Turbine is supposed to solve the noise component of this problem. It will be interesting to see whether home based wind power becomes practical in future - if so I would like to get an O’Connor turbine on my house! Home solar power has been proven to work well, in the form of both solar-electric and solar hot water (I know several people who have been happily using them for years). You don’t get cold showers when the sun isn’t shining, you instead use gas or electricity to heat the water (it’s a standard feature in a solar hot water system). Also your home electricity doesn’t go off when the sun stops shining, you have batteries that are charged during sunny times to run things overnight, and when they get flat you pay for power from the grid. It is quite realistic to stick solar power systems on every roof in the country. The added cost to the process of building or purchasing a house is negligible and the benefits include having electricity when mains power is unavailable (NB water is used in generating electricity from coal or nuclear power plants so a bad drought will eventually become a time of limited mains power). Even the smallest home solar electric system will produce enough electricity to power a fridge and freezer 24*7 so it’s a very useful backup for essential power. The government is subsidising the installation of solar electric systems, so it seems that they expect everyone to get one eventually. Dr. Ziggy Switkowski (the main advocate of nuclear power in Australia) says “the introduction of a carbon tax could make nuclear power the cheapest option by the 2020s”. In consecutive paragraphs Ben derides “carbon trading” and claims that nuclear power is “practical”. Unfortunately the main advocate of nuclear power in Australia does not believe that it is practical without a carbon tax. Ziggy also states that it would take at least 15 years to complete a nuclear power plant, unfortunately we don’t have the luxury of waiting for 15 years before starting to try and reduce the damage that we are doing to the environment. The Stern report makes the economic consequences of inaction quite clear. I am not a Luddite. I oppose nuclear power because of the risks related to accidental release of radioactive material and the routine release of radioactive material as part of the uranium mining process, and the dangers related to long-term storage of nuclear waste (let’s not assume that Star Trek science can make it all non-radioactive). Nuclear power is not cost effective for Australia and will take so long to develop that it won’t save us from the serious economic damage predicted by the best scientific models as presented in the Stern report. For large scale power generation wind power works now, can be easily implemented and has no hidden costs or risks. There will never be a Chernobyl type accident with wind power, it is inherently a safe technology. For small scale power generation (something you can add to your home) solar power works well, is not expensive (when considering the price of a house and especially when the government subsidy is counted) and has the potential to seriously reduce the amount of carbon dioxide produced.

Share This

Floris Bruynooghe commented:

"My experience is that European (including UK) drivers can't cope with wide roads, resulting in even more dangerous behaviour. Wide roads with on-road cycling lanes are probably pretty good. But they need to be clearly separated by a double line sort of like in Belgium, combine that with UK quality road surface (on average) and you might have someting usable. The cycle lanes on UK A roads are a joke though, a very good example of how not to do it."

I assume this means the converted edge strips that you see on some fast roads (note: not all edge strips have been marked as cycle lanes and you especially shouldn't use unmarked ones). There's one of those in Milton Keynes, alongside the A5D dual carriageway. My main complaint against them is that they are too narrow and you get HGVs passing close enough to pull you around. Also, you have to cross every slip road/ramp which is a fairly unpleasant experience at busy times. Redway Route Types The unique Redway network was built in several phases. To be fair, I can't recommend the original network for anything other than low-speed connecting use, but the later, straighter additions (the "cross-city Redways" mentioned in the 1998 paper and my introduction a couple of posts ago) to the original plan early in the 1990s improved matters immensely. Although the different types are mentioned in the introductions, this difference seems entirely ignored by the accident data, which is my main complaint against the papers. There's no way of comparing like with like, as far as I can tell. You can split the accident data for 60/70mph grid roads from the 30/40mph link roads and 30mph estate roads, but you can't split the long-distance maybe-40kph cross-city Redways from the maybe-20kph estate Redways. Based on my years cycling around the city, I expect that the difference between grid Redways and grid roads is pretty small and that local Redways are far worse than local roads, but I can't prove or disprove that from his data. What's more, none of the studies I've seen differentiate between construction phases or route types, which is like only having combined accident figures for the Fosse Way and the M1. It suggests interesting topics for further studies, but how can anyone draw useful conclusions about cycle track design in general from it?

The German parliament changed the law on 25th may 2007.

It's now forbidden to build, program, give, distribute or get software, which can be used to attack computers. that's something i do on a daily basis. (think nmap)

so it is only a question of time that i get caught.

German pressrelease of the CCC

Those who program C are used to seeing function / subroutine definitions in header files. Not so in Fortran, there people use the C pre-processor to put Header files in subroutine definitions. Don't try this at home, folks. Again, names changed to protect the afflicted ...

subroutine  funmame( param1,
	      param2, param3,
#ifdef FOO32
	     foo, bar,
#endif
	      param7, param8, 
#include "basarg.h"
	     )

Remarkably, basarg.h included:

	C Comment.
	param5, param6,
#ifdef SOMETHING
        param10, param20,
#endif

There were in fact dozens of parameters in basarg.h.. And even a higher.h that included basarg.h but had more parameters ... Tags programming, bizarre, work, fortran

After noticing the Library of Congress Blog (thanks for the anonymous link correction) via librarian.net, I asked the British Library and they told me they had a blog for the London in Maps exhibition and will soon launch a new content blog called Sacred. Which other libraries are blogging?

So this Monday was the 111th running, as they call it, of the venerable Boston Marathon, and my first time there. After the fairly serious storm warnings -- and the corresponding health warnings, delivered through two emails from the race organizers and a handout at registration, we got very, very lucky as the rain more or less stopped shortly after the start. And there was relatively little wind, and mostly laterally, rather than the 'in your face' gusts at the projected 30 to 50 mph.
There were actually six of us running from our little informal group in River Forest / Oak Park, and fellow rookie Russ and I decided to 'take it easy' and just 'go for a long run'. I ended up with a fairly even pace between 7:45 and 8:10, averaging 7:57 for a total of 3:28:24, or a few seconds faster than my very first marathon in Chicago. Which is quite pleasant, given the conditions, and the hillier course. The race went pretty well for all six us, which is nice too. Given how we trained together, it is neat how we all ended up within seven minutes of each other. The race itself is quite stunning. With the required qualifying time comes a 'seeding' system for the start, so one tends to run most of the course with runners of fairly similar speed. That made for nice cameraderie on the course -- and for beautiful sights of nothing but runners rolling through the hills of Massachusetts. I think I'll be back next year.

Note: This article is part of my Testing stuff with QEMU series.

From Wikipedia:

MenuetOS is an operating system with a monolithic preemptive, real-time kernel, including video drivers, all written in FASM assembly language, for 64-bit and 32-bit x86 architecture computers, by Ville Mikael Turjanmaa. MenuetOS development has focused on fast, simple, efficient implementation. It has a graphical desktop, games, and networking abilities (TCP/IP stack), yet still fits on one 1.44MB floppy disk. It also facilitates easy, full-featured assembly language programming. This stands in marked contrast to the (as of 2007) widespread view that assembly languages are useful mainly for old and embedded systems.

Testing (the GPL'd) MenuetOS in QEMU is easy:

wget http://mesh.dl.sourceforge.net/sourceforge/menuet/M32-084.ZIP
unzip M32-084.ZIP
qemu -fda M32-084.IMG -m 384
There's also Menuet 64, written in 64-bit assembly, but that's not open source'd for some strange reason I don't understand. But you can try that one, too (the binary images, that is), using QEMU:

wget 'http://www.menuetos.be/download.php?CurrentMenuetOS'
unzip M64-059.ZIP\?3.1
qemu-system-x86_64 -fda M64-059.IMG


• My “travel” talk suggestion is accepted for Debian Day at Debconf7. See you there!
• How many DDs eat 150 emails for breakfast? Some people on this HTML WG are hilarious.
• Wordpress should be in etch. Thanks for everyone’s input on this.
• The Debian live based Webconverger “browser live system” is BETA! See about Webconverger for more information.
• My Cornwall house sitting days are over and now I need to find a (hopefully debian) contract (my CV) so I can one day afford more travel adventures.

One more day of comments to this and I think it will become the longest-running item on my blog. Thanks to everyone who's helped so far. Added: BW-Bank, Etrade, ING Direct, Nordea, RBC Banque Royale, Swedbank Updated: Cooperative Bank (business) Linked to other lists: Australia and New Zealand, Denmark, Germany, Worldwide

[UPDATE: I'm closing comments on this post, because the spammers have discovered it -- dnb]

Lars says:

The uncomfortability of Synaptic may be partly due to the fact that it is
a different model from Windows: you get all your programs from one place,
instead of anywhere on the Internet, partly due to just not using Synaptic
much at all, and partly due to Synaptic not being perhaps as easy to
understand as possible. I personally find Synaptic to be very nice, and
use it regularly, but I am biased by having used Debian package managers
for over a decade.

Now, synaptic is a lot nicer for users than scary console frontends like aptitude. But it's really a tool for "power users". Here's a quick list just of what I see when I start it (bearing in mind that my UI design skills suck):

• The "quick introduction" screen that pops up is way too long. The fact that it needs to be so long is already bad.
  
• There's a huge, and I mean HUGE list of sections down the left. What are these? Which one do I look in? For that matter, what is "gnome", and are "shells" programs for the seashore?
  If I want to find software for processing video, do I look in "graphics" or "multimedia"? (and what are these funny "(contrib)" markers?) Which of the huge number of packages in each section do I want? From the point of view of a new user (especially), this categorization is useless, not to mention often wrong or misleading.
  
• The four buttons in the lower-left, which change the display, are a good idea, but they don't say what they do. A label saying something like "Group By" would go a long way here.
  
• I think the version numbers in the main display probably provide too much information for a novice user. They won't really know what to make of them, and if they need the information it can be provided on demand; as it is, it's just one more distraction to sort through while looking for what they really want. The extra space could, e.g., be used to provide more room for the status column (currently labeled "S").
  

So much for superficial observations. There are a few more things that I see that are worth more discussion.

Mechanics of selecting packages

To change the state of a package, you click on the unlabeled little box to its left, then select the correct option from a list containing "Unmark", "Mark for Installation", "Mark for Upgrade", "Mark for Reinstall"...you get the idea. Even if only one option is valid, the menu still appears with all but one option grayed out, and you have to select the one you want.

This is complicated, cumbersome, and surprising. It also introduces terminological confusion, since "Unmark" isn't really what you think of when you go to cancel an installation or whatever.

The best option I can think of here is a pulldown menu (which I believe the GTK+ list widget (god, I almost wrote "control") supports). The menu should default to the current state, e.g., "not installed", and should have options that describe what will be done with the package, e.g., "install", and so on. Only valid actions should appear on the menu. The Package menu should probably adapt in the same way as you select packages. I don't recall offhand how GTK+ menus work, but if possible commonly used commands like "remove" should be closer to the mouse when the menu appears than uncommon commands like "reinstall".

Another choice I can see, if you want to avoid menus, would be something like this: have two checkboxes, one for "install" and one for "upgrade". "install" would be checked for installed packages and not checked for not-installed packages. Checking or clearing it would mark packages for installation or deletion. "upgrade" would mark or unmark packages that were installed for upgrade. Of course, this introduces a redundant column for not-installed packages, which I don't like. It also seems to me that it would be less obvious what's going on for new users. But it would be more efficient for power users (who should all be using aptitude anyway ;-) ).

Progress bar madness

I haven't extensively used synaptic, but several core misfeatures of apt and our archive pretty much guarantee that if it displays progress bars for key operations like loading the cache or updating the package lists, the progress bars either run multiple times (i.e., don't actually tell you how close to finishing you are) or actually go BACKWARDS -- yes, BACKWARDS.

The great package hunt

Maybe the biggest problem is that unless you know what package you're looking for, basically all our package interfaces are useless. There are lots of fancy searching features you could add, but actually a quick test in synaptic suggests to me that this would be going in the wrong direction. Unlike aptitude, synaptic includes descriptions, and searches for stuff users might actually want (like, say, "burn CD") seem to turn up relevant results (i.e., software that burns CDs).

I'm sure the search algorithm could be improved (with inexact matching, better indexing (a package description suffix tree?), etc), but the big problem I see is that you tend to get back several dozen results, many of which are libraries, development packages, command-line software or software that doesn't work; some of the other software is software that can burn CDs but whose purpose is not to burn CDs (e.g., backup software).

How can we solve this? The first thing that springs to mind for me is to use popularity-contest data to weight the list. I know it's not terribly accurate, and it has some skewing problems (stuff in the default install will be favored), but I suspect it would greatly bias the results in terms of software that's useful to many people (using the "recently used" tallies might especially help here).

I don't have many other good ideas on the searching problem; I've seen vague suggestions of counting reverse dependencies, but this doesn't seem like a good metric of useful software to me; trying to extract more information from the short and sometimes inaccurate package descriptions seems like a really hard problem to me. (Google can do cool statistical analysis partly because it has so much data to work with AIUI; even a single Web page typically has orders of magnitude more information than a package description)

Another issue is the problem of finding related software once you've installed one piece. We have "suggests" and "enhances", but they aren't exactly displayed in a prominent or easy-to-understand way by any frontend. I think it might be good to display a clickable list of suggested packages somewhere visible (e.g., at the top of the description box) when the user has selected a package for installation. We could even display a little bar, like on (eg) Amazon: "Debian suggests installing these packages..." ;-)

It might also be interesting (if this is considered acceptable; since the data is anonymous I don't see a problem) to analyze the popcon data to find out what packages are being installed in tandem. I don't know if we have enough information to do it, but it could turn out to be really useful to be able to click on a package and see other packages that are popular with users who installed that package. Going back to online stores again, those "other people who bought 'Types and Programming Languages' also bought 'Introduction to Category Theory'" links are amazingly useful, and something similar would probably be a big help in Debian.

In a previous entry, I explained how you can be assimilated to an Ubuntu developer without even being an official Debian developer, and of course without prior notice. I am now quite ashamed: I have just discovered that this was already discussed some time ago (read: months before my post), and led to the following results:

• If the package is in universe or multiverse, the Maintainer field will be set to Ubuntu MOTU Developers

• If the Maintainer field is modified, the old value will be saved in a field named XSBC-Original-Maintainer

However, packages where my name appears either in the Maintainer or in the XSBC-Original-Maintainer field still “belong” to me in Launchpad (see https://launchpad.net/~julienv/+packages for example).
However, I am not responsible for the bugs of these packages (see https://bugs.launchpad.net/~julienv/+assignedbugs) Now that my blog is syndicated on Planet Debian, I ask it again:

Am I supposed to look on Launchpad for bugs reported against the packages I maintain in Debian?

Obviously, if a bug wasn’t reported by a Debian user, it might mean nobody suffers from it, but fixing it could avoid future bug report anyway (except if this particular bug is very specific to Ubuntu). In order to improve the Debian maintainers’ work, I think it would be great that the PTS integrates the bugs in Launchpad in a simple way. This would allow us to easily subscribe to the bugs, and eventually get a notice if the bug is fixed, or at least allow us to be aware of the issue.

I have a Debian wish for lenny:

• define and deploy a standard way of packaging software, that can be used for like 90% of packages. (It doesn't 'have' to be CDBS, it can be something 'better' for a reasonable definition of better. CDBS is the closest of the packaging tools I've tried so far, I've had single line package scripts with CDBS for many packages)
• Put the maintainer scripts into version control, it should be something with a central repository, but that of course allows maintainers to easily do a local branch. Especially for backports. Maybe SVN with SVK is okay.
• Use a standardized patch system along with a toolchain, quilt-like
• Link this patch management to upstream watching, so that patches applied upstream can automatically 'disappear'

Why do we really have to make a distinction between NMUs and maintainer uploads? I agree that we need to have someone (which can be a group) be responsible for packages and need to keep track of that to detect unmaintained packages (as well as to have someone track bug reports). With this central repository, we could have NMUs committed to the packages directly, and make contribution easier in general. For example, right now transations are usually added to a package via a bug report. The maintainer then needs to go through these bug reports (and some packages have so many open bugs I doubt the maintainer has a real overview over them; so he might easily miss some easy to fix ones), extract the patch and apply it to his package after review. With this central patch tracking system, the translators could just commit the translation change to the package directly, and it will end up in the next upload automatically. (Note that I'm not trying to force all packages to be maintained this way. I agree that for some packages it's not really appropriate. In general it should be left to the maintainers discretion. However I guess many team-maintained packages are handled in a similar way already, and I'd like to use that for my packages as well, even when not having Co-Maintainers. I'm also aware that when fixing security issues, you might not want to make your changes world visible immediately. This can however be done using SVK if we end up using SVN, for example.) Some rationale for this suggestion:

• Promotes team maintainance
• Offers another easy way of contribution (especially for sponsorees)
• Better change and version tracking
• Standard way of packaging makes NMUs and adoption easier
• Makes it easier to work on many packages when needed (e.g. new GCC version fixes, porters, translations, upstart support, SELinux support, Python, all kinds of transitions)

In fact I think that other distributions (e.g. *BSD ports, Gentoo?) are ahead of us in this respect, having a standard way of packaging and building things and keeping track of changes. Anyway, just my € 0.02 [Yes, I'm aware that this was covered in the DPL debate, but IMHO the point of different packaging preferences falls a bit short, and probably needs to be addressed first, before being able to have a central VCS for all packages. Also I think we should be able to find a common VCS we can all live with, or at least 90% of packages.] [And yes, I'm aware that this is a controversial topic that can easily start yet another flameware. But we need to find a way of keeping flamewars down anyway...]

I recently wrote an article or two about distributed version control systems.

I've been using Darcs since 2005. I switched to Darcs, in fact, 10 days after the simultaneous founding announcements of git and Mercurial.

Overall, I have been happy. I continue to believe that it is the most distributed of the distributed VCSs, which is a Good Thing.

However, I have lately started having trouble with Darcs hanging while working on my Debian packages. My post to the Darcs user list drew out a few other people whith this problem, which is a design flaw of Darcs.

So I revisited the VCS landscape. I re-examined git, Mercurial, and bzr. I eventually decided to give Mercurial a try. I avoided git because I write some code that is portable to Windows, and git isn't (or isn't very well). Also, git is complex to pick up for me, and I certainly don't want to force something complex onto my contributors. bzr seemed to still have some strange behaviors that it's had for awhile, and I couldn't find even one advantage of it over Mercurial. So off I went with Mercurial.

I quickly learned a bit of a philosophical difference from Darcs to Mercurial.

Darcs avoids conflicts at all costs. Mercurial makes handling conflict easy and, in many cases, automatic.

It is exactly this Darcs behavior that permits both is excellent "darcs send" feature (still unmatched in any other VCS), but also causes its hang problems.

I found Mercurial quite pleasant to work with, and *fast*. It seems to be edging out git in speed tests sometimes these days.

It is easy to get started with Mercurial. The mq system -- similar to quilt or other patch-management programs -- is really quite an amazing hybrid between patch management and version control. I frankly don't see any need for other patch-management tools anymore.

Mercurial has a "patchbomb" feature where you can select a range of changesets to send off, and it will generate nice emails with one changeset per email, and send them to your selected destination, optionally with an introductory message. The normal way of interacting with other Mercurial users is via the hg export/import commands, which send around simple unified diffs plus some additional header information, optionally in the git extended diff format.

I am happy with Mercurial and am in the process of converting my Debian repositories from Darcs to Mercurial. I'm going to keep my personal code in Darcs for the moment because "darcs send" is still easier than "hg email", but that may change before long, depending on how my experience goes.

I'd encourage others to give Mercurial a try. The community is also very nice and helpful.

I have contributed patches to Tailor to make it make exact copies of Darcs repos into Mercurial, which are now in its Darcs repo. There is also a thread on the Mercurial list with some of my initial questions/concerns coming from a Darcs perspective.

Wrein, I'm not going to create a wordpress account.
As you can see I already have unmaintained blogs here and there. :-)