I finally had my first flight cancelled on me yesterday. I suppose given that I've been flying a few times a year for at least the past 8 years (even if it's only back and forth to Northern Ireland) I should consider myself lucky. I arrived at Belfast City Airport at about 8am, for a 9:45am flight (the last time I flew from Belfast we hit really bad traffic, so we ended up overcompensating). On check in I discovered it was delayed by 15 minutes. Shortly after I'd made my way through security it was delayed by 45 minutes. Then they delayed it until midday. Then at 11:30 they said they'd have an announcement at midday. And then at 11:45 they cancelled it. Now, I was flying from Belfast to Norwich. There's only one such flight a day. So I'm a bit stuck. And by the time I get to the front of the refunds queue they've filled up the flight today (Saturday), leaving me the option of a direct flight to Norwich on Sunday, or any other flight leaving Belfast City on Friday that they have seats on. So I go to London Gatwick, supposed to leave at 14:30. And it gets delayed by 45 minutes straight after I check in. Thankfully it does actually take off at 15:15 and I manage to get to England. On the wrong side of London for Norwich, but hey, the trains are running. I negotiate the Gatwick Express, get a tube to Liverpool Street and get on a train to Norwich. Which then gets delayed for 25 minutes because a train breaks down in front of it. Bah. I finally get home just after 9pm, rather than the 11:30am or so I would have managed if my initial flight had taken off on time. The house is still in one piece, the plants haven't died, I have food again. Rar. And I know this is small fry compared to American flight horror stories, or the potential problems we could have had when Uncle Steve lost our clothes en route to Brazil, but it's the first time I've had a major problem with flights. (We'll ignore the fun I had when turning on my desktop machine and seeing "GRUB Read Error" displayed. Damn scanner had decided to frob the SCSI bus enough that the BIOS could boot grub but grub couldn't then see sda.)

Decklin wonders why Qt has a SQL plugin. The answer is because it's a full development environment (think: MFC), not a GUI toolkit (think: GTK). Hope that helps.

(Last I checked, it also had a full XML parser, full string and array/list handling, socket handling, file handling, etc, etc, ad nauseum.)

There is a certian attitude some people I know have about the 2.4 kernel that I find really annoying. It's basically that it's obsolete, unsupported, not worth bothering with, should be dropped immediately, etc. And that's a reasonable position until you look at the sheer mass of machines out there that have not been able to upgrade to 2.6 yet, and the many places where all the new stuff (initramfs generators come to mind and so might udev) surrounding 2.6 is simply not ready for users. And the total lack of care that many of these same people have about providing any kind of reasonable upgrade path for 2.6. Well, after trying each new 2.6 kernel on my fujitsu laptop as they came out over the years from 2.6.2 on, I've finally found one that seems usable on it as a replacement for 2.4. It's just passed the main smoke test of being able to suspend and resume while playing music and downloading a file without missing a beat (using apm; the apm vs acpi thing is much like the 2.4 vs 2.6 thing I mentioned above, except acpi is unlikly to work for anyone). I'm not sure it's the kernel itself that started working; my main problem before was disk access hanging on resume, and I've recently replacd my hard drive, and perhaps 2.6 only had problem with my old model of drive. So anyway, it works for me, therefore it is perfect, so I can now without any qualms enter the ranks of the 2.4 snobs.

Following up on my previous post, here's a new status update of the whole GNOME situation. Very soon after posting that roadmap, the two steps in the process were completed, with the ftpmasters freeing dbus into experimental, and seb128 doing a round of GTK+ family uploads. No big problems have been detected in GTK+ 2.8 in unstable, so those bits are going very well. As soon as dbus 0.60 hit experimental, both the KDE and GNOME camps got busy recompiling their stuff. KDE 3.5.0 moved from Alioth to experimental, and sjoerd got busy in a recompile quest to make sure GNOME was installable again in experimental. The dbus 0.60 transition in experimental was done in barely a few hours, and some extra dbus-using packages have been transitioning since then. So, what's holding our unstable upload? We first need to wait for KDE 3.4 enter testing, thus clearing the major blocker for the C++ ABI transition. The number of packages involved in this is so big it's not even funny, so it's quite complicated. In short, the GNOME team is sitting on their hands watching some C++ fun. There are a few more news bits though. Last night, there was a round of experimental updates, bringing most of the modules to their 2.12.2 versions (just 2 or 3 are missing now), and meta-gnome2 was again updated to support these versions. If you issue your usual aptitude install gnome-desktop-environment, you'll pull newer versions of most of the stuff, if that's the way you update your experimental packages. Also, the gnome package now supports gnome-screensaver. Give it a try, and be ready to purge xscreensaver if you're happy with it!

I recently came into posession of a collection of (smallish) WMV files containing photo slideshows. Unfortunately, they don't play on my DVD player, and SWMBO's laptop has No Hope of playing anything remotely like a video. So, technology to the rescue. Initially, I was just going to convert the movies into something that the DVD player would actually play, but by the time I had those, I was 95% of the way to doing the job properly, and it would (of course) look far nicer with menus and other Shinyness (instead of just a boring file menu), so I went all the way and made a complete DVD movie disc. The whole process was non-trivial to discover, but ultimately straightforward in practice (once you know the set of command line options to use), so I'm archiving this for posterity. I use Ubuntu Breezy. A lot of the packages I've used are under really heavy development, so slightly older versions may not work. If you're running another distro, finding compatible versions may be tricky (or not). Try the process with whatever you've got; if it works, great; if it doesn't work, try upgrading versions or something. Step 1: Convert Video Files To Something Less Bong Packages used: transcode 1.0.2-0ubuntu2 (trivial backport from Dapper; mail me if you want it, but the one in Breezy will probably work OK), mplayer 1.0-pre7cvs20050716-0.1ubuntu9, mjpegtools 1.6.3+rc2-0.0ubuntu2 As far as DVD players are concerned, WMV is non-existent (clever things). DVD players like some form of MPEG-2 video with AC3 or MP2/3 audio. So, we use transcode to convert the video. For WMV files in particular, only mplayer does the decoding right (the af6 plugin seemed to work, but the resizing didn't turn out too well). So, our command is:

 transcode -x mplayer -i $FILE.wmv -g 640x480 -e 44100,16,2 -o $FILE.tc --export_prof dvd-pal

Items of note:

• -g 640x480 is necessary because transcode currently can't ask mplayer for the size of the video. This will apparently be fixed in the near future, but until then, work out what size your input video is (run mplayer manually and look at it's output) and substitute for 640x480 in the above.
• -e 44100,16,2 exists for a similar reason to the above -- it's the sample rate, bits/sample, and channels of the incoming audio stream. Again, retrieve by running mplayer manually until transcode knows how to ask nicely.
• I've used -o $FILE.tc because what actually comes out of this transcode step is a separated audio/video stream, which needs to be multiplexed into a single stream (see next step). You actually get $FILE.tc.m2v and $FILE.tc.mpa files (the extensions get automatically appended).
• --export_prof dvd-pal sets a bunch of options behind the scenes so that everything gets output as PAL-compliant DVD video. Much easier than the alternatives. dvd-ntsc works nicely too, if you're stuck somewhere without decent chroma control.

As I mentioned, the output from the transcode run is two separate streams -- an audio and a video stream. We want to combine them. This is quite easy:

 mplex -f 9 -o $FILE.vob $FILE.tc.m2v $FILE.tc.mpa

This is a simple "glue them together" command -- the only interesting bit is -f 9, which simply specifies a particular MPEG-2 multiplexing method (full DVD-compatibility, or some such). If things aren't working out for you, try -f 8, which I believe also works. Since you'll probably have a bunch of video files to convert at once, you'll want to automate all of this with a shell script or shell 'for' loop. Step 2: Make a DVD Layout Packages used: qdvdauthor 0.0.10-0.1 This is the bit that I thought would be hard, but is actually amazingly easy (the previous step took me two days to get completely right, this bit took me about an hour). Fire up qdvdauthor, answer any stupid questions it might come up with. When the main screen comes up, click on the 'Add Movie' button on the left hand side, then select the first video you want to add. Repeat as required to add all of the videos you want. (Remember to add the VOB files you created earlier, and not the WMVs you might still have laying around. D'oh!) Clicking on the 'Video' tab on the left hand side should list all of your videos. Check they're all there, and are the correct size. Next, create or find a suitable background picture or video to make your main menu background. I've only tried with an image, but it seems to accept videos if you give them to it. Click on the 'Add Background' button on the main qdvdauthor screen. Pick your image. The image will probably need resizing; just go with the flow and pick the correct image size. Now you need to add those funky little menu items for selecting on. This is the really cool bit. Right-click on the background image you've got, and select 'Add Text'. Drag on the background to create a text box. You'll get a dialog come up, type some text in the bottom box, then click 'OK'. This'll create the text on the background. Drag it around if you need to. Finally, right-click the text and select 'Define as Button'. Another dialog box will appear. Rename the button if you like, then pick which video you want to play from the select box marked 'vmgm'. Click 'OK'. Repeat as necessary. That's all the hard stuff done. You can add a sound clip to play over and over again if you like, but I haven't done that yet, so you're on your own there. Step 3: Make the DVD For this step, I needed to compile toolame from source. Get it from http://toolame.sf.net/. This is super-simple. Basically, just click on the giant icon labelled 'DVD' in the top toolbar. Follow the prompts. Click 'OK' as necessary. When the process is done, check the 'Keep Open' checkbox quickly, and go over the output to ensure nothing completely crapped out. Assuming all is well, you can make your DVD image by running:

 mkisofs -dvd-video -udf -o /tmp/dvdimage.iso $DVD_DIR

Naturally, replacing /tmp/dvdimage.iso and $DVD_DIR with appropriate values. Lastly, cook the ISO to appropriate media with something like:

 cdrecord -dao -eject -v speed=2 dev=1,0,0 /tmp/dvdimage.iso

Assuming all went according to plan, you should have a physical DVD you can stick in your DVD player and watch to your heart's content. Congratulations! You just did all of this in about a 50th of the time it took me.

My current long-term learning project is Ruby on Rails, the ultra-hyped web application framework from David Heinemeier Hansson and friends. I like it (primarily because I can see a lot of my own abortive ideas from a web app framework for PHP I used to develop), but there is one big thing about it (or, rather, it's surrounding hype) that irritates me. Throughout the Rails literature (webpages, magazine and webzine articles, and the book Agile Web Development With Rails), there is a consistent message -- that, because everything is written in Ruby, you don't have to learn any new programming languages to write Rails applications. This is a wonderful theory -- no large XML config files to define my database schemas, and no castrated and irritating HTML template system to learn. From defining table relationships to printing a select tag, It's All Ruby, All The Time. Sweet, right? Sort of. The problem is that you won't find the language primitive to declare a one-to-many relationship in the Pickaxe (the definitive Ruby language reference book -- like "the Camel" for Perl, "the Bat" for Sendmail, or "the Turkey" for PHP). Defining a separate namespace in Rails for all of these operations is, of course, necessary, since the language didn't already define these operations. But, once you've defined a whole new set of methods to do all of these operations, you can look back on your hard work and see -- what? A new language -- one specifically designed to describe webapps. Don't get me wrong -- domain-specific languages are teh r0x0r. If everyone had to do all of their HTML manipulation by hand, programmers would be even more insane than they are. But, when you're writing your application in Rails, you're not speaking "pure Ruby". Your syntax and basic structure is Ruby, but your methods and attributes are new, different, and All Rails. It may not be a separate programming language in the usual sense, but by the time you've added a whole new pile of classes, methods, and attributes (not to mention whole new ways of structuring your application), how much importance is the use of the @ symbol to signify an instance variable, compared to the whole new set of methods to learn? Natural languages, of course, have similar issues. Most western european languages share a lot of common characteristics -- similar character sets, punctuation sets, and they read left-to-right. So I can look at a page of German or French, and identify most-to-all of the salient features (hey look, an 'a'!), and even grok the meaning of a few of the words (familiar to me, probably, because English misappropriated them from wherever they came from) but I still have no hope whatsoever of understanding the meaning of the passage as a whole. The language syntax looks familiar, but those nouns and verbs don't have any meaning to me. You can't plonk a Rails app in front of even a seasoned Ruby developer and expect them to immediately jump in and start hacking on it like they've been writing it all their life. The language syntax looks familiar, but those methods and attributes don't have any meaning to them. This is nothing peculiar to Rails, of course. If you want someone to hack on your Hibernate or Spring app, you'll get better results if you advertise for a Hibernate or Spring programmer than a Java programmer. But Rails advocates regularly say "it's all just Ruby, so there's nothing new to learn!", and that's Just Wrong, in my opinion. As an aside, if you're looking around for something a bit different, do seriously consider Rails (or just Ruby, if you don't need a webapp framework). It's different from the "usual" suspects (C, C++, and "the Ps" -- PHP, Perl, and Python), and pleasantly so. If you judge your programming languages by the old adage "a programming language that doesn't change the way you think about programming isn't worth learning", Ruby will score well. I know it's helped me think about my programming differently already, especially my Python programming (and thanks to Anthony Baxter for answering all of my esoteric python questions at OSDC a couple of weeks ago).

Procmail Sucks

OK sucks is a bit strong: It is both insanely extensible and utterly horrid to work with. I wish there were a decent perl replacement for Procmail. Seems to me that regexps and piping through external programs covers 99% of the average procmail use cases. Perl has a lot of modules already existing for working with mbox files, maildirs, and even messages. It seems that parp should be that project but it hasn’t been touched since 2002. PMS is another dead project. Does anything exist already? Or am I stuck in procmail hell? I’d be tempted to start my own project … "down that path lies madness"

Tom Short, author of Rpad, emailed me today saying that he was running the newest Quantian inside an instance of the free (as in beer) VMware Player. And indeed, lo and behold, it works. Quite well, actually. Hhere is what I did:

Grab the VMware Player

I tried the rpm first, but the installation needs some post-installation mojo for kernel modules, networking, etc which the alien-created deb did not provide. So take the tarball, expand it and configure the player running vmware-install.pl All defaults were sane on my Kubuntu desktop, no complaints.

Adapt the definition of the .vmx file

Tom sent me this Quantian.vmx file based on something from Damn Small Linux. It worked for me (TM) -- accept the suggested creation of a new uuid.

Launch vmplayer

And select the (suitably adapted) Quantian.vmx. At the bootprompt, say 'knoppix' or 'linux24' And the bootprocess should proceed. Tom reported he also needed the Knoppix cheatcode 'noscsi'. I didn't.

I then tried to be cute and started two Quantian instances (which can be done if you copy the .vmx file to a new file), started both in kernel 2.4 and tried openMosix, It didn't start immediately, presumably because the test for /proc/hpc got tricked by the /proc filesystem of the non-openMosix host. A quick 'mkdir mfs; /etc/init.d/openmosix start' later, things started to roll. However, while the two machines 'saw' each other, no actual job sharing seemed to occur. They also did not 'see' the laptop running outside the hosted VMware setting even though all machines were on the same 192.168.1. subnet. Maybe a simple configuration issue, maybe not. All in all, a pleasant surprise that I was able to set all this up in a couple of minutes. Update: Fixed URL for the Quantian.vmx file.

I’m coding a new CGI application, tentatively entitled BabyOp. It is software to run a babysitting coop; I suppose it is a species of “social software.” The idea is to be able to track hours credits, schedule babysitting times, centralize contact information and other details about babysitting requirements. I considered using something like Zope or Drupal for the application, but I’ve never liked developing exclusively through a web-interface and found myself having to do a fair bit of “actual” coding to get the results I wanted. I realize there is a command-line interface for Zope, but it’s really pretty limited. I had some plans a couple of years ago when I designed my wedding site in Zope to extend it to be more useful, but sadly never got around to it. So I’m back in my comfort zone, perl. I’ve written a fair amount of unmanageable perl code, however, CoopOrder probably being a shining example (it was also my first perl program). I’ve certainly improved since then, and the fact that I’ve received several patches from others for randomplay suggests that my coding style is getting to a half-decent point. I’d really like to get it right this time, though. One thing I’ve learned over the years is always to look for a module to do what you want before setting out to do it yourself, since chances are the module writer is a better coder than you (or at least, than me!). To that end, I’m using CGI::Application, HTML::Template, and DBIx::Abstract, among others. I’m also trying to keep things really granular and avoiding long subroutines. Certainly taking the HTML out of the perl code helps with that. I’m amazed at how often my code now just “works” on the first try, similar to esr’s story about his first look at Python (“Brace yourself: this code only took me about ninety minutes to write—and it worked correctly the first time I ran it.”) I’m trying to figure out if it would be sensible to make this application more fully object oriented. Growing up in the ’70s and ’80s and having done a lot of database programming, I’ve always been unfortunately pathologically declarative. (My first major package was in Clipper—I was 13 years old). I find it a lot easier to modify a pre-existing object oriented package than to design my own. But then again, does it really make sense to attempt an object-oriented design where there is really only one important “object” — in this case, the babysitting unit?

Why do prioprietary pieces of software often have names like the above? (Other examples: Macromedia Flash, Chipmunk Scripts Guestbook, Mojo Mail, PeopleSoft PeopleTools, Golden FTP Server Pro, Invision Power Board) A walk though the CVE lists will turn up hundreds of hilarious examples of similar names. It's easy to guess whether a given security hole in that list affects Debian based just on the form of the software name even if one has never heard of the program before. Even free software projects that seem to partake of a proprietary mindset show it in the names: Mozilla FireFox, OpenOffice, Mozilla Thunderbird. So different than w3m, vim, mutt. A whole pile of history, cultural, and, I imagine, linguistic difference. Even if at first saddled with such a name, many free software projects seem to evolve in the other direction: Debian Installer -> d-i, X Window System -> xorg. As someone who can't name software, I find this strangely fascinating.

Tom Short, author of Rpad, emailed me today saying that he was running the newest Quantian inside an instance of the free (as in beer) VMware Player. And indeed, lo and behold, it works. Quite well, actually. Hhere is what I did:

Grab the VMware Player

I tried the rpm first, but the installation needs some post-installation mojo for kernel modules, networking, etc which the alien-created deb did not provide. So take the tarball, expand it and configure the player running vmware-install.pl All defaults were sane on my Kubuntu desktop, no complaints.

Adapt the definition of the .vmx file

Tom sent me this http://dirk.eddelbuettel.com/blog/computers/linux/debian/quantix/Quantian.vmx file based on something from Damn Small Linux. It worked for me (TM) -- accept the suggested creation of a new uuid.

Launch vmplayer

And select the (suitably adapted) Quantian.vmx. At the bootprompt, say 'knoppix' or 'linux24' And the bootprocess should proceed. Tom reported he also needed the Knoppix cheatcode 'noscsi'. I didn't.

I then tried to be cute and started two Quantian instances (which can be done if you copy the .vmx file to a new file), started both in kernel 2.4 and tried openMosix, It didn't start immediately, presumably because the test for /proc/hpc got tricked by the /proc filesystem of the non-openMosix host. A quick 'mkdir mfs; /etc/init.d/openmosix start' later, things started to roll. However, while the two machines 'saw' each other, no actual job sharing seemed to occur. They also did not 'see' the laptop running outside the hosted VMware setting even though all machines were on the same 192.168.1. subnet. Maybe a simple configuration issue, maybe not. All in all, a pleasant surprise that I was able to set all this up in a couple of minutes.

Ok, so I lied a bit yesterday. I’ve found some time and prepared Wordpress 2.0 RC3 packages. Please give some feedback before this Friday. It was a weird svn-upgrade.

deb http://hendry.iki.fi/debian/ unstable/
deb-src http://hendry.iki.fi/debian/ unstable/

I didn't want to migrate to 2.6.x kernels, since I really don't like its current development approach, but unfortunately I had to, because my usb cable for mobile phone works only with this branch.
So from now I'm not-so-happy 2.6 user ;)
At least now I can exchange data with phone, so Debian logo is now on the screen.

It’s more than a year since the first development release of Backup Manager, this easy-to-use tool for archiving your data under Linux. Version 0.6 which has just been released, provides a set of features for letting you implement your own backup strategy.
Backup Manager is able to use any existing infrastructure for achieving this goal: FTP or SSH accounts, CD/DVD burning devices…
A couple of different backup methods are available: tarballs (incremental or not), dumps (MySQL, SVN) and a generic method which uses content sent on stdout by an arbitrary command. An effort has been given regarding localisation, the program is now translated in 5 languages: French, German, Spanish, Italian and Vietnamese. The user guide has been writen and is available in different formats. Hopefully, the debian package will come very soon…

This time tomorrow I'll be on a plane heading to Israel in a circuitous route for a much needed vacation in Israel. It appears that the weather in Israel had turned from sunny and hot into a real winter so that we won't feel too bad comparing the weather of Israel and Ireland. The Haaretz forecast says there will actually be rain, of which I had enough here. We will escape the empty Maynooth of Christmas for the split personality (Rehovot/Carmiel) of Hanukka with the families, for some much needed stuffing with home-made Sufganiyot and other not-necessarily-related-to-Hanukka foods. A union with a newly purchased Canon 350D is also much expected :-)
This will replace a Canon Elan7 film camera of which pictures that the local development shop manages to screw the image scanning and creates washed-out colours.

During this week-end I tried to give initial impulses on several projects of interest for me : DebianEduFrench: a new mailing list has just been setup for this project. We intend to foster cooperation between several French educational Debian-based projects. We’ll try to integrate their work into Debian directly to avoid needless duplication of effort. This follows my last call for help on debian-devel-announce. If you speak French and have good packaging skills, you’re welcome to join and help us on the mailing list. Collaborative maintenance infrastructure: this one started as a project to handle orphaned packages but after the talk we gave at the Debian-QA meeting in Darmstadt, we agreed that it is of broader interest: in particular for mentoring future Debian developers. This tool could also interest Ubuntu which has in fact already started something covering a part of this proposal: REVU (development web site). So I crosspossted a call in several Debian & Ubuntu lists in order to create a little team to work on this project and make it happen. But there’s still room for discussions as nothing is in stone yet … That’s enough for one week-end !

"All revision control systems suck. This one just sucks less."

That's roughly what I'll say when I find one worth it. I've used rcs, cvs, svn, prcs, tla, arx, monotone and probably some I've forgotten. They all suck, in different ways. I'm now really reluctant to install a new revision control system unless there's a clear benefit. Matthew Palmer:

"Subversion is the One True Revision Control System and we should all just Stop Worrying and Learn To Love The Handcuffs"

Current target of my wrath is subversion, the lardy cake of revision controls. Over 5 times the footprint of CVS gets you atomic commits, but similar design problems with centralised servers and corruptable roots. Server choice is either a pserver-look one or an apache server with all the trimmings. The licence isn't even GPL-compatible, so forget about neat integration into some editors and development tools. Finally, if CVS is "extremely dead" despite its last release in October 2005, then SVN must be buried and rotting because it hasn't released since August. I tend to prefer distributed systems, especially when done well with standard protocols so that I can copy the archive somewhere close to me and work with it at relatively high speed, or off-line. It also gives the benefit that I merge when I want to, rather than being forced to choose between commit and branch. Centralised systems seem to make branching needlessly fiddly. Beyond that, I strongly prefer a system which can generate tarballs and patches (as far as possible) so that the rest of the world doesn't have to install the binaries (even if they can). That's about the base level of compatibility for now and any new tool should at least try to support it, even if the export loses some information. (I'm currently using a small shell script which just automates tarballs and patches, to help me move between my two computers here. I know it's only a 90% solution, but it's one I understand and can put some faith in. I need to have faith in my RCS. I like little less than losing work. Next step is to automate updates and merges, rather than doing them by hand.)

To Wouter: No, I never used anything else than CVS for everything serious. Whenever I tried any of them for something (mostly because someone else used it for something I wanted to work on) they simply broke. I don't want debug my tools or use funny workarounds but get some work done on what I use the tools for. Using anything not in a Debian stable release is hardly acceptable for me (remember, it are tools), but when then even when the testing or unstable versions are not enough for simple tasks, it's just too bleeding edge for me.

"only suggests you haven't seen many large projects in the heat of code change"

That's simply a matter of style. If a checkin means a full compile, manually reading the diff and a minimal checking for correctness, writing Changelog entries and possibly adopting the documentation there is simply no need to handle checkins with a sub-minute resulution.

"Far too often have I seen people afraid to reorganize their code because that would lose history on the files."

That's a major problem, but the problem is the fear. No rcs will ever be able to track history for even most common possible reorganisations of code. Limiting yourself to what your rcs can cope with is the main problem, the abilities of your rcs are a minor one.

"How about the fact that upstream CVS development is rather extremely dead, [...]"

I prefer tools being able to do what I need over tools that will be able to adopt my needs normaly. Active development means when I encounter a bug I either have to wait a year until it does no longer bother me, or wait a week and update software on every computer I want to use on, possibly localy in my user account if I do no administrate the computer or the behaviour changes so much other usages are broken. Leading to problems to live within my disk quota and so on.

Don't understand me wrong, I'm not against SVN. I guess now (several years after everyone was already told to not use that old fashioned CVS, but not SVN version N but version N+1, because N was too brokenr; for several versions of N) it is quite useable. And things like atomic commits might even make it favoruable over CVS for larger projects. But not every project can be within the top ten list of size, coding and commit styles differ. But I believe for many people, the ratio of advantages to disadvantages still points into another direction.