What’s nice about Subversion is that it’s easy enough for most people to wrap their head around it and therefore it’s supported well. Admittedly it can make branching a pain. Actually, that isn’t quite true. It’s a bit like speed which itself doesn’t kill you, just the sudden impact does. Likewise he problem is not with branching, it’s the merging that can make you pull your hair out. But it’s gotten better at that over the past releases.

Another issue with Subversion is the central repository. I however think the central repository idea fits many projects or even individuals in need of revision control very well. And if you want to mirror a repository for bandwidth or high-availability reasons, well that’s possible too since version 1.4 or so. I know, these mirrors have to be read-only, otherwise it’ll easily get messy. If you want to be able to commit to some local mirror and push back your changes, you should consider SVK. It mirrors foreign repositories locally, lets you create local branches and merge them back. SVK has a few problems of its own, but I’m not going to get into them here. Point is, if your project works best so that there’s a central repository, Subversion is a sensible choice. Thanks to solutions like SVK, people will also be able to work offline (I’ve used it this way) or be able to follow a project and add their modifications without leaving their cave.

Distribution is not for everyone

Since lately people have been trying to convince us that central repositories are not the way of the future, and neither is Subversion because it’s not suitable at all in a distributed environment. But in all honesty, after many years of contributing to various Open Source projects I haven’t actually had the need for such an environment. I get Linus’ points about how the Linux Kernel is developed, how he receives patches from his lieutenants who in turn receive them from somebody else. Surely all that needs a distributed system. But I’m sorry, the projects I’ve worked on just don’t have the man power to have people do nothing else but review patches sent to them, merge them with their private branches, push them along to other people, etc. In our central repositories we’re happy with having a few knowledgeable people watch the commit list (we call them the “checkin police” in Zope) and make sure that code and patches committed as well as the log messages match our quality standards. For everything else there’s buildbot.

All that’s not to say that distributed revision control systems aren’t nice because they are. I do understand why their users are smug. But I just won’t have their arrogance. Subversion has served many of us well over the years and now all of a sudden we’re idiots if we still like it?

That said, all distributed systems can do what Subversion can do (except partial checkouts of the repository apparently) so they seem worth a look. After all you get more features and no drawbacks, right?

Sorting out the contenders

There seem to be three serious options when it comes to distributed version control that all have about the same feature set: Bazaar, Mercurial and Git. Actually, that’s not quite correct. If you’re like me and have to or want to work with several Subversion repositories, Mercurial isn’t an option. As nice as Mercurial may seem (though a bit weird in its understanding of branches), you’ll have to realize that only Bazaar and Git have decent Subversion plugins that allow you to pull and push to a Subversion repository.

Both Bazaar and Git are installed easily on OS X if you have MacPorts. Just beware that if you want to build Git with SVN support, you should install it as follows:

sudo port install git +svn

For the following tests I took one of my private Subversion repositories (the smallest one in which I keep all the files related to my work at the university) and tried interacting with it from Bazaar and Git.

Bazaar

The first thing you’ll hear about Bazaar is that while the documentation is pretty good, it’s slow. And boy they aren’t lying. I haven’t done any measurements, but it felt even slower than Subversion on operations like printing the status of the working copy.

Like with Mercurial, Bazaar’s command set is quite easy to grasp for people who’ve been brainwashed by Subversion. In other words, people like me. However, I can’t help but think that’s because Bazaar isn’t actually too far away from Subversion, conceptually speaking. Sure, it has local repositories and all that, but in essence it seems to be geared towards a central repository when it comes to sharing your work. Not that that’s a bad thing, as I tried to point out above. I just somehow expected more. For instance, let’s say you have a checkout of something. This checkout can only be bound to one branch in a remote repository at a time. That means you can’t push some work to several repositories at the same time.

Like SVK, Bazaar has the concept of a working copy directly associated with a remote branch and working copies that represent local branches. If you have one of the former, the unbind/bind feature is quite neat. It tells Bazaar to temporarily stop sending every commit to the remote repository (e.g. while you’re hacking away on the train). Once you’re back with network connectivity, you rebind to the remote branch and can push your changes. Unfortunately, Bazaar wants you to push all these changes as one revision (to Subversion) even if you made several commits when offline. I’d rather have it reflect the individual commits.

Another downside in the communication with a Subversion repository is that it leaves turds in the repository, that is special directory properties that it uses to track which revision it has synced. In this respect it’s similar to SVK.

Git

Having read tutorials and guides a la “Git for SVN refugees”, I must get the impression that Git is surrounded by a cloud of fanboyism. Fanboyism per se is tolerable, but as I said above, I don’t like when it’s mixed with arrogance. I know that Subversion isn’t the bee’s knees, that’s why I’m reading this tutorial. You don’t have to tell how stupid I’ve been using Subversion all along and not helping Linus come up with Git.

That said, once you look past the fanboyism, you’ll realize Git is actually quite well composed. The commands are a bit weird at first but so far each one has done exactly what I expected it to do. Its concept of remote and local branches is absolutely easy to understand and since Linus designed it to do kernel development, you can easily manage a gazillion local and remote branches, do merges between them, etc. I’ll admit that it feels a bit weird in the beginning, but you’ll soon appreciate the niftiness.

Something that definitely takes getting used to is the way it represents branches. A checkout and a repository are inseparably the same thing, therefore switching between branches happens within the same checkout. I’m not yet entirely sure yet what to think of that, all I know is that you might easily forget which branch you’re currently in and do something to a branch that you meant to do in another one. That’s not a big problem with Git, though, because you can easily roll back commits. What is annoying, however, is that you can’t switch branches or rebase your changes on top of the latest changes from the repository you’re tracking (e.g. SVN) while having local modifications. I tend to keep local modifications in my working copy almost forever, for instance when I have a canonical version of a configuration file in the repository and I change it locally for a test installation. Git has ways around that annoyance, too, for instance I could use git stash to hide the local modifications temporarily, or I could make a local branch in which I can check in the modifications but never push them back to the tracked repository, just pull the latest changes.

Git’s Subversion integration is superb. There’s an excellent tutorial for people who’ve deserted from Subversion/SVK to Git. It also mentions how to interact with a Subversion repository. In fact, generally you read that Git’s supposedly not as well documented as, say, Bazaar. I can’t come to that conclusion. I’ve rarely needed the online user guide, the man pages are quite well sorted out. You’ll actually see them by either typing man git-cmd or git cmd --help.

The winner

So which is it going to be? Well, despite Bazaar’s Python bonus and Git’s initial weirdness, I’ve gone with Git for now. On the server side I’m keeping my Subversion repositories, at least for now. Because at some university machines or on Windows I only have a Subversion client (I suppose I could compile Git myself, not that the uni sysadmins like seeing such a thing). Also, I’ve set up my Subversion repository access via HTTP/HTTPS. That means I can view my repositories with a simple web browser or download the HEAD with wget if I don’t happen to have a Subversion client at hand at all. Finally, keeping Subversion around gives me the possibility to change my mind again and go for something else.

When I bought my 2nd gen MacBook Pro 15″ in late 2006, it was the top of the range with a Core2 Duo (Merom) processor clocked a 2.33 GHz, 2 GiB RAM and a 160 GB harddisk. Two years later it may look a bit shabby compared to the 5th gen Unibody MacBooks, but its inner values suggest that it can still take them on in a benchmark. Surely it wouldn’t be better but I suspect it would still put up a good fight, as a draw between the 4th gen and 5th gen MacBook Pros in the GeekBench results suggests.[1]

One thing that makes a huge difference in the real world is RAM which is why I decided to spend about € 50.- on two 2 GiB DDR2 bars. I now have 4 GiB installed, though my chipset can only address 3 GiB (which I knew beforehand). I can report that this has made the machine a bit smoother when running many apps in parallel (which in my case is, uh, always). It’s not exactly warp drive, though.

If you want warp drive you’ll have to change, well, the drive! Most of the time when you’re waiting for your computer to do something (open an application, find a file, etc.), it’s not because it’s lacking processing power. It’s because it has to read files that are randomly scattered all over the harddisk. Harddisks are terrible at random access. They’re a bit like good old lazy V8s: huge capacity, but reluctant to change pace (and incidentally, not great in terms of power consumption).

Fortunately, there are alternatives to harddisks called Solid State Drives (SSDs) which are supposed to be much better at random access. But while most of the affordable ones merely provide impulse power, two models actually seem[2] to deserve to be called warp drives: the Samsung SSD and Intel’s X25-M.[3] These two are pretty much neck to neck in most of the benchmark, and since the Intel has the same price per capacity ratio but a bit more capacity (80 GB vs 64 GB) than the Samsung, I chose to buy the X25-M. Due to the strong demand for this device, it took me a while to secure one for a reasonable amount of money and so it finally arrived earlier this week.

Unboxing Intel X25-M (3)

Unboxing Intel X25-M (3)

Now, 80 GB isn’t much these days and certainly a step down from my 160 gigabytes of V8 muscle. But I wanted the best of both worlds, speed and capacity, so I decided to ditch the optical drive and trade it in for some harddisk space. After all, software isn’t distributed on CDs or DVDs anymore (except for proprietary operating systems, perhaps), nor are music and movies. Should I ever require an optical drive (e.g. to watch a rented movie), chances are good I’m at home where I can use my external USB/Firewire thingy.

On the 5th gen MacBooks, replacing the optical drive with a harddrive is, at least in theory, trivial because the optical drive is SATA as well. On previous MacBooks, the optical drive has a PATA connector so you’ll need a small controller that translates from ATA to SATA. In either case you’ll want to fit the harddrive into a cage that has the same dimensions and mounting points as an optical drive.

MCE Technologies offers a solution for this called OptiBay, custom tailored for the MacBook or MacBook Pro. If you purchase the harddrive cage by itself, it’s $129. Add $43 to that for international shipping with FedEx. A cheaper solution comes from newmodeus: an HDD cage that’s intended to take the place of a removable optical drive that some laptops have. It’s a mere $42. Shipping with regular US postal service costs just $8 and it only took a few days to get to Germany. The only minor inconvenience was that unlike UPS or FedEx, the regular postal service doesn’t do the customs stuff for you, so I had to go to the local customs office and pick it up. Normally I would have to have paid German V.A.T. on it, but since this is a business expense, I didn’t.

Unboxing the newmodeus HDD optical bay (3)

Unboxing the newmodeus HDD optical bay (3)

Unfortunately, the MacBook Pro doesn’t have a regular size optical drive. It’s thinner which means the cage won’t fit as is. I had to “adapt” it therefore with some cutting tools (a fine metal saw or a sharp side cutter will do, use sandpaper to smoothen the edges). I also removed the top lid and the front cover since those are unnecessary in the MacBook Pro. With these adaptions, the cage fit rather nicely into the empty space that the optical drive had left.

Fitting the HDD cage to the size of the MBP optical drive

Fitting the HDD cage to the size of the MBP optical drive

All this means I now have a fast SSD drive for the operating system, apps, personal data, etc. and my old big harddisk for large files such as my MP3 collection and movies (for which random access isn’t as crucial anyway). But has it worked?

Oh yes. The system is biblically fast. Even while I was copying all my data files over from the old harddrive to the SSD, every single application still opened in an instant. OpenOffice is up and running within 2 seconds. System upgrades now take longer to download than to perform. When automatic login is enabled, the system boots from power off to a fully functioning UI in less than 10 seconds… I could go on.

Admittedly there are a few disadvantages. The “adapted” cage isn’t the best soundproof location to install a harddisk. The CD/DVD slot right in front of the mounting position doesn’t help either. So the noise has slightly gone up, but it’s hardly noticeable, really. I also have no idea whether the motion sensor will put the harddrive to sleep in case the MacBook Pro falls (don’t care about that much, though). And then there’s power consumption. I haven’t done any tests yet, but I have the feeling it’s a bit worse than what it was before. It’s hard to tell because I failed to do a proper test before the operation. One thing I’d quite like to find out is whether the OS X can put the harddisk to sleep once in a while. It only has my MP3 collection and other large files, so it’s quite possible to completely avoid using the harddisk when on the road.

All these are minor issues, really. If you want to speed up your machine, forget everything else. Just get an SSD. And not just any, get one of the warp drives. The really good news is, however, you don’t have to compromise on space. If you’re like me and don’t need your optical drive much, you can have your cake and eat it, too. Warp drive and good old V8 muscle.

Both drives installed

Both drives installed

P.S.: If you’d like to attempt this at home, don’t worry, it’s not difficult. Fitting the cage to the right size was the hardest part, but if you’re willing to spend a bit more money, you can avoid that altogether by buying the OptiBay. You need a few good tools (Torx T6, Philips PH00 and PH0 screwdrivers, pair of tweezers). Then simply follow the excellent instructions on the iFixIt website.

[1] I know that the 4th gen machines have a newer generation processor, but its clock-speed is only marginally faster. And yes, they have a slightly faster chipset and graphics card, but how much of a difference is that going to make. As the benchmark shows, the factor 1.5 speed up of the frontside bus (667 to 1033 MHz) has nearly remained without effect.

[2] Judging from the various test reports I’ve read on different SSD models.

[3] These are MLC models and therefore affordable (which is the criterion here). Certainly there are faster SLC models, but they’re much less affordable.

I ♥ US keyboards

December 6, 2008

Think about it. If you’re a developer and involved in Open Source projects (or alternatively, if you’re employed by an international organization), most of your natural language communication will be in English and, crucially, everything else will be, well, code or something similar to code (XML, LaTeX, Mathematica, etc.). As it happens, code needs characters such as @, {}, [], \, |, which are easily accessible on a US keyboard but not on localized keyboards because they trade the special characters for umlauts and other language-specific keys.

For instance, on a typical European keyboard, nearly all of those special characters that you need in code have to be typed using the right Alt key (which is called Alt Gr for “alternate graphics”) plus some other key. That not only means you’ll have to leave the home row and resort to finger origami, it also slows you down because you’ll no doubt have to look at the keyboard while typing. (It’s much worse on the Mac because Apple refuses to label the keys with the special character that they’d produce, therefore making people having to guess where things are).

So I ask you, if you’re a developer, what are you going to need more often? Umlauts or those characters that predominate in code? Why make typing the characters you need all the time more difficult than typing the characters you only need occasionally? Don’t worry, I’m not suggesting a radically new keyboard layout. But wouldn’t it make more sense to turn the tables on those umlauts? In other words, what I am suggesting is a hacker-friendly US keyboard, simply enhanced with language-specific characters accessible with Alt Gr.

The German Linux Magazine suggested this several years ago already and showed how to do it for German umlauts on X11. Ever since I’ve been on the Mac, I’ve been using a similar custom keyboard layout (I call it “U.S. German”). It’s a U.S. layout, but it allows me to type umlauts with Option+vowel, ß with Option+s and € with Option+e. I created it with Alex Eulenberg’s excellent keyboard layout generator, starting out with the U.S. layout and blank Option key mappings, and then adding my own mappings like so:

   Oa $00e4  :: auml
  OSa $00c4  :: Auml
   Oo $00f6  :: ouml
  OSo $00d6  :: Ouml
   Ou $00fc  :: uuml
  OSu $00dc  :: Uuml
   Os $00df  :: szlig
   On $00f1  :: ntilde
  OSn $00d1  :: Ntilde
   Oe $20ac  :: euro

After having saved the resulting file properly in OS X’s library path and logging out, I was able to chose the keyboard layout from System Preferences and have used nothing but ever since. Here’s a screenshot of the Keyboard Viewer app when pressing the Option key:

usgerman-keylayout

When I originally posted this on my old blog, I got an email from somebody at Aachen University’s Comp. Sci. department who had the same idea, but put a bit more effort in it and produced an even nicer version. So instead of providing my own layout here, I suggest you use the one form their website. Alternatively you could use the generator and come up with your own. I also hear good things about Ukulele, a visual keyboard layout editor. I have no idea about Windows, but I’d be thrilled to hear if people have managed to come up with something for it as well.

Whatever you do, don’t be a slave to your localized keyboard just because you need the occasional umlaut, accent or slashed vowel. There are better ways for us developers. I ♥ US keyboards.


P.S.: One should note that US keyboards are even physically different (the Return key has different proportions and it lacks a key that European keyboards have). Since you couldn’t buy a Mac in Europe with a physical US layout until recently, my laptop has a physical European layout (which sucks). The physical US layout makes much more sense on a Mac since you can jump through applications with Command+Tab and through windows of a particular application with Command+`, which on a physical US layout is right above the Tab key.

(Non-German speakers please move on, nothing to see here. Come back tomorrow.)

Die deutsche Sprache krankt nicht nur an den zunehmenden Anglizismen, sondern auch an der vermeintlichen Gleichstellung weiblicher und männlicher Substantivformen. Zugegeben, der Zwiebelfisch hat dies in seinen berühmten Büchern bereits ausführlich behandelt. Ich will dennoch ein paar weitere Punkte beleuchten, die ich schon seit einiger Zeit mal loswerden wollte.

Den Spieß mal umgedreht

Die übliche und ein wenig kurzsichtige Argumentationslinie geht ungefähr so: Wenn jemand “Liebe Kollegen” sagt, dann ist das ja diskriminierend, weil er die Kolleginnen nicht anspricht. Das ist insofern kurzsichtig, als dass früher eine solche Anrede erwiesenermaßen und mit einer absoluten Selbstverständlichkeit auch die weiblichen Mitarbeiter eingeschlossen hat. Ich persönlich finde es schon ganz schön anmaßend, wenn mir jemand vorwirft, ich ignoriere meine weiblichen Mitarbeiter bewusst, nur weil ich “Liebe Kollegen” sage. Ganz im Gegenteil, ich würde nie daraufkommen und möchte auch bitte nicht darüber belehrt werden, wie ich mich auszudrücken habe.

(Genauso verhält es sich im Übrigen mit den Stellenanzeigen, in denen ein “Betriebswirt (m/w)” gesucht wird. Warum müssen die Firmen dort “(m/w)” schreiben, wenn doch wohl klar ist, dass sie Bewerbungen von Frauen wie von Männern akzeptieren? Darüberhinaus ist es eine unnütze Angabe, denn Dank des Allgemeinen Gleichstellungsgesetzes (AGG) darf eine Firma niemanden wegen seines Geschlechtes zurückweisen. Das halte ich zwar auch für Unsinn, denn wenn ich ein Modell für Damenunterwäsche beschäftigen möchte, nutzt mir ein Mann herzlich wenig, aber das ist ein anderes Thema.)

Es funktioniert einfach nicht

Abgesehen davon, dass die zusätzliche -innen Form (“Kolleginnen und Kollegen”) fürchterlich viel Geblabber erzeugt, aber keinen wirklichen Mehrwert in die Sprache bringt, funktioniert sie auch nicht immer. Beispiele: Mensch oder Gast. Spätestens hier werden die selbsternannten Sprachverbesserer erkennen müssen, dass Mensch und Gast maskuline Substantive sind und für Männlein und Weiblein gleichermaßen gelten, ohne dass eine -in Form vonnöten oder gar möglich wäre. Niemand würde schimpfen, wenn ich meine Kollegen zu mir nach Hause einlüde und sie mit “Liebe Gäste” anspräche. Warum soll es dann politisch inkorrekt sein, “Liebe Kollegen” zu sagen? Es will mir einfach nicht einleuchten.

Der Ausweg ist eine Sackgasse

Engagierte Leute mit Sprachgefühl haben diese Probleme natürlich erkannt und mittels der Gerundiumsform Abhilfe geschaffen. So ist es an Deutschlands Universtitäten üblich, die Studenten als “Studierende” zu bezeichnen (in Österreich ist es sogar Gesetz), denn es gilt “die Studierende” gleichermaßen wie “der Studierende”. Alles im Lot, oder?

Leider weit gefehlt. Die Verwendung des Partizips drückt eine Handlung aus und wie jeder weiß sind die wenigstens Studenten auch wirklich studierende (sic!). Denn wer Kraftfahrer von Beruf ist, ist ja nicht immer ein Kraftfahrender, genausowenig wie ein Marathonläufer nur ab und zu ein Marathonlaufender ist. Was wäre zudem ein Student, der Auto führe? Das wäre ja ein kraftfahrender Studierender. Also bitte, niemand kann gleichzeitig ein Kraftfahrzeug lenken und dabei studieren. Es ist einfach Unsinn.

Google now officially supports the CalDAV interface for iCal. Thanks to a little tool they provide, it’s a breeze to set it up. However, it does have two rather inconvenient disadvantages:

  • So far I’ve been using iCal locally to manage my various calendars. If I wanted to use Google Calendar from now on (through iCal, of course), then I’d first like to import all my data into Google Calendar. It’s not obvious to me whether this is now possible out of the box and if so, how.
  • A quick test revealed that working with the calendars is possible offline. iCal will synchronize with the online calendar once you’re connected again. That’s nice and certainly the Right Thing ™ to do here. The Google-based calendars are also synchronized to my iPhone. Again, this is what I’d expect. However, the iPhone won’t be able to add or modify an event in any of the Google-based calendars. Since I add appointments and other things right away to my iPhone’s calendar when I’m on the road, I wouldn’t want to give up this feature just to have my calendar available through the Google web interface.

While experimenting with this, I grew rather fond of the idea of being able to access my calendar through the Google web interface and synchronize it with multiple machines. So I started investigating alternative solutions that wouldn’t cripple the iPhone’s possibilities:

  • Spanning Sync and NuevaSync are over-the-air synchronization services. While NuevaSync seems to be a general service for any platform, Spanning Sync is specifically designed to work with Macs. Both services have one thing in common, though, and that’s their means of synchronization. Your PIM data will go to their servers where it’ll be processed and what have you, and then be synchronized with, say, Google Calendar or the other devices you want it to synchronize. Given that I already have to trust one company with my personal data (Google), I’d rather not involve yet another one, thankyouverymuch. Oh, and the service isn’t free, obviously.
  • GCALDaemon is an open-source command line tool written in Java, thus cross-platform, that allows you to synchronize your Google Calendars with local ones, for instance ones that you have on the file system or ones that it publishes via HTTP, so that your CalDAV client can the subscribe to it. Setting it all up is quite straight-forward, thanks to its graphical configuration editor. However, after half an hour of trying to synchronize a calendar between iCal and Google Calendar and finally giving up, I came across several reports saying that it doens’t work with Leopard’s iCal (because the newer iCals save calendar data in a different manner, apparently) or that it only works if you use some Perl hackery. I think NOT.
  • gSync is mentioned positively in several blogs, but apparently it’s no longer being developed. The main site is down (hence no link). Avoid.
  • BusySync is a little piece of software that installs a new pane in the OS X System Preferences. It allows you to either subscribe Google-based calendars locally or publish a local calendar to Google. The difference to CalDAV is that to iCal, the calendars will always look like a local one. That means the iPhone will work just as before. I’ve tried this now and it works like a charm. (BusySync will also do more, for instance publish your calendar over LAN, but I don’t need that).

BusySync isn’t free, it’s $25 per computer. Right now I’m using a demo version, but I’m considering purchasing it. I only need it on one machine, the one that I use to synchronize my iPhone with. The other machines that I might want to access my calendar from could simply subscribe to the calendar via CalDAV.

One thing that BusySync doesn’t seem to do is synchronizing contacts from Address Book. If it did that, I’d be getting out the checkbook right now…

Follow

Get every new post delivered to your Inbox.