mikas blog

Linux is a great platform for dealing with all kinds of different file systems, partition tables etc. But one of the few annoying situations when working in IT forensics are Microsoft Windows dynamic disks, AKA LDM (Logical Disk Manager).

Thanks to libldm’s ldmtool this is no longer true. A short demonstration from a real-life IT forensics investigation (actual IDs/data randomized for obvious reasons):

# ldmtool
ldm> scan /dev/sdc*
[
  "1bad5bbc-a4b5-42e1-8823-001014b00003"
]
ldm> show diskgroup 1bad5bbc-a4b5-42e1-8823-001014b00003
{
  "name" : "FOOBAR-Dg0",
  "guid" : "1bad5bbc-a4b5-42e1-8823-001014b00003",
  "volumes" : [
    "Volume1"
  ],
  "disks" : [
    "Disk1",
    "Disk2"
  ]
}
ldm> show volume 1bad5bbc-a4b5-42e1-8823-001014b00003 Volume1
{
  "name" : "Volume1",
  "type" : "striped",
  "size" : 3907039232,
  "chunk-size" : 128,
  "hint" : "D:",
  "partitions" : [
    "Disk1-01",
    "Disk2-01"
  ]
}
ldm> show partition 1bad5bbc-a4b5-42e1-8823-001014b00003 Disk1-01
{
  "name" : "Disk1-01",
  "start" : 1985,
  "size" : 1953519616,
  "disk" : "Disk1"
}
ldm> create all
Unable to create volume Volume1 in disk group 1bad5bbc-a4b5-42e1-8823-001014b00003: Disk Disk2 required by striped volume Volume1 is missing
[
]
ldm> scan /dev/sdd*
[
  "1bad5bbc-a4b5-42e1-8823-001014b00003"
]
ldm> create all
[
  "ldm_vol_FOOBAR-Dg0_Volume1"
]
ldm>

The just created device mapper device then can be handled as usual:

# dmsetup ls | grep ldm
ldm_vol_FOOBAR-Dg0_Volume1        (254:4)
# mount /dev/mapper/ldm_vol_FOOBAR-Dg0_Volume1 /mnt/whatever

ldmtool just hit Debian unstable (and I intend to ship the tool with the upcoming version of Grml-Forensic).

I’ll be speaker at the Open Source Data Center Conference 2013 in Nuremberg/Germany on 17th and 18th April, talking about Continuous Integration/Delivery in the data-center. I was speaking at OSDC back in 2009 and very much enjoyed the conference – so I’m totally looking forward to OSDC 2013, hope to see you there!

2012 was a very special year for me, so it’s worth some words.

In April the Grazer Linuxtage event took place, being one of the major IT events in Austria nowadays. I’m one of its original founders and after being part of the main organisation team for ten times I decided to leave the organisation team. I’m looking forward to enjoying the event in 2013 as visitor, I’m sure the organisation team will provide an absolutely rocking event.

In August I officially launched the jenkins-debian-glue project. It turned out to have been worth all the effort to go public with it. I received plenty of feedback and people are hacking on such great things nowadays that I have to find some time soon to bring those nifty new features people came up with back into my mainline.

In December my wife and me moved to our new place, being a house we bought in Graz. I’m very happy that everything worked out as planned. Thanks to wonderful friends we managed to reach a very pleasing state of our new place within just a few weeks. Once again many many thanks (you know who I mean)!

Throughout the whole year I’ve had several challenging IT consulting gigs in and outside of Austria as well as interesting forensic investigations. Sadly most of them are settled under NDA. That’s still something I can’t get really used to as being someone who likes to share and talk about my work with similarly minded people.

The year ended with a real-life fork, being such a wonderful experience that I still can’t believe that it’s true.

Thanks 2012, totally looking forward to 2013!

On 31st of December 2012 my lovely wife has made ​​me the gift of my life: welcome to the world, Verena.

Rund 4,5 Jahre später ist es nochmals soweit: ich bin gesiedelt, wieder innerhalb von Graz, diesmal in etwas (zumindest geplant) langlebigeres. Die neue Adresse findet man wie üblich im Whois-Record meiner Domains.

In the last few days several IT events published recordings/slides from their events. I haven’t had the time to take a closer look at the material yet but there might be some gems among them so I thought it’s worth spreading the word:

• Devopsdays Rome/Italy 2012: videos from the talks
• PuppetConf 2012: videos from the talks
• Barcelona Ruby Conference 2012: videos from the talks
• DjangoCon US 2012: videos from the talks
• Jenkins User Conference San Francisco 2012: slides from the talks

Since I’m not aware of a ready-to-go solution, this issue once again came up at a company where I’m doing Jenkins/CI consulting for and the solution involves some trickiness you need to be aware of I’m hereby documenting it.

If you have a build pipeline inside your Jenkins setup you might have so called upstream jobs which trigger downstream jobs. If such a downstream job fails you might want to set the build state of the upstream job to “failure” as well.

First of all install the Groovy Postbuild Plugin as well as the Copy Artifact Plugin. (The Copy Artifact Plugin is not strictly needed, you can also choose a different approach for artifact handling, but the plugin works very well for me.)

In the upstream job you have to archive artifacts. Otherwise the script that we will use in the downstream job doesn’t have a connection to the upstream job through the getUpstreamBuilds() method. If you don’t have any artifacts then just create a simple textfile and use that as artfifact file. After the artifact step you can place the trigger for the downstream job. This is the relevant part for a working sample configuration for such an upstream job:

In the downstream job make sure to grab the artifacts from the upstream job. Then use build steps or whatever you need as usual. This is the relevant part for a working sample configuration for such a downstream job:

Finally use the following Groovy script as the Groovy Postbuild action:

upstreamBuilds = manager.build.getUpstreamBuilds();

if(!upstreamBuilds) {
  manager.listener.logger.println("Error: could not identify upstream build");
} else {
  upstreamJob = upstreamBuilds.keySet().iterator().next();
  lastUpstreamBuild = upstreamJob.getLastBuild();
  buildResult = manager.build.result;

  if(lastUpstreamBuild.getResult().isBetterThan(buildResult)) {
    manager.listener.logger.println("Adjusting build state of upstream job to build result of this job, being " + buildResult);
    lastUpstreamBuild.setResult(buildResult);
  }
}

That’s it. Now every time your downstream job fails it should set the according upstream job to “failure” as well.

Far away from Rosetta Code, but that’s what Frank and I came up with when explaining 100000₂:

Guile:

guile <<< \#b100000
guile -c '((@@ (ice-9 format) format) #t "~d~%" #b100000)'

Racket:

racket -e '#b100000'

Ruby:

ruby -e 'puts "100000".to_i(2)'

Python:

python -c 'print int("100000", 2)'

Perl:

perl -e 'print 0b100000'

Zsh:

zsh -c 'print $((2#100000))'
zsh -c 'print $((2#1<<5))'

bc:

echo "ibase=2; 100000" | bc

Clojure:

clojure -e '2r100000'

Scala:

scala -e 'Console.println(Integer.parseInt("100000", 2))'

Octave:

octave -q --eval 'bin2dec("100000")'

AWK:

echo 100000 | awk '{r=0;for(i=1;i<=length;i++){r*=2;r+=(substr($0,i,1)!="0")} print r}'

C:

tcc -run - <<< $'#include <stdlib.h>\nint main() { printf ("%d\\n", strtol("100000", NULL, 2)); return 0;}'

Haskell:

runhaskell <<< 'import Data.Char; main = putStrLn $ show $ foldl1 ((+) . (*2)) $ map (digitToInt) "100000"'

CLISP:

clisp -q -x '#b100000'

jenkins-debian-glue is an open source project of mine which recently celebrated its first birthday and it’s time to finally write about it.

jenkins-debian-glue allows you to build Debian and Ubuntu packages directly from the Jenkins continuous integration system. It retrieves package sources from a version control repository, adjusts debian/changelog (handle version number + mention changes that took place) and builds according source and binary packages out of it. Its lintitan integration provides Q/A reports about the resulting source and binary Debian packages.

It started as a small pet project of mine to get integration of Debian packaging inside Jenkins. I mainly had the needs for the Grml project in mind and starting with Grml 2011.12 every release (including also all the daily builds) was built using Jenkins since then. It turned out that my project would also be a perfect match for one of my customers, Sipwise GmbH. In December 2011 the sip:provider 2.4 was the first stable release that was built 100% through Jenkins and featuring jenkins-debian-glue.

Thanks to special needs and the open source friendliness of Sipwise I could invest further time into the project. Recently the project got even some further drive thanks to interest by some fellow Debian Developers, most notably are the icinga, nagios-plugins,… packages and the PostgreSQL in Debian Hackathon.

Now if you’re also interested in it: there’s an automated deployment procedure available for your service to get started with the whole jenkins-debian-glue and Jenkins stack in less than 10 minutes, working just fine on Debian as well as Ubuntu.

For further details please head over to jenkins-debian-glue.org or check out this 6:36min screencast (safe for work, no audio :)):

This embedded video doesn’t work for you? Try heading over to YouTube.

So, dieser Blogartikel gurkt schon ewig in den Entwürfen rum, also endlich mal raus damit…

Die “123gold Trauring-Lounge Graz” hat am 1. März 2011 ihr Geschäft eröffnet. Das kam gerade recht für das Event des Jahres und so haben meine Liebste und ich uns dort nach einem passenden Paar Trauringe umgesehen. Die Verkäuferin Frau S. wirkte nervös und chaotisch aber freundlich und bemüht, so haben wir die etwas chaotische Beratung in Kauf genommen.

Unsere gewünschten Ringe wurde bestellt und waren rechtzeitig für das Event zur Abholung bereit. Die Ringe waren ein wenig zu groß, aber da uns versprochen wurde, dass eine Verkleinerung des Ringes für 25€ möglich ist und wir uns ob der Größe einfach unsicher waren, war uns das in dem Moment egal. Marianne war der Ring schließlich für den Alltagsgebrauch ganz klar zu groß und daher hat sie sich nach der Hochzeit auf den Weg in das Geschäft gemacht. Doch auf einmal hieß es, dass die Verkleinerung in ihrem Fall doch mehr kostet als angekündigt, weil wegen des eingesetzten Diamantes der Ring neu eingeschmolzen werden muss. Sie ging zur Konkurrenz ums Eck – dem Juwelierladen Weikhart – und dort wurde ihr gesagt, dass der Ring ganz klar um 2 Nummern zu groß ist, aber die Anpassung leider nicht von Weikhart durchgeführt werden kann, da der Diamant-Einsatz eine spezielle Behandlung durch den Hersteller/Produzenten benötigt. Marianne hat in den sauren Apfel gebissen und sich den Ring bei der Trauring-Lounge kleiner machen lassen.

Auch mein Ring war zu groß, besonders bei kalten Fingern war es störend. Ich habe aber erst später den Weg in die Trauring-Lounge geschafft. Unsere damalige Verkäuferin war dann leider nicht mehr anzutreffen. Der erste Hammer kommt aber sofort: die Verkäuferin gibt mir falsche Modellringe zum Probieren in die Hand, denn innen sind diese komplett anders geformt als mein Exemplar. Das ist genau das, was sich im Nachhinein als der Grund für die falschen Ringgrößen herausstellte. Nach meinem diesbezüglichen Hinweis habe ich dann zwischen zwei Modellen der richtigen Passform entscheiden müssen. Die Variante die zwei Nummern kleiner war als mein Ring kam mir eine Spur zu klein vor, die größere Variante wiederum kam mir zu locker vor. Die Dame konnte mir aber meine Entscheidung nicht leichter machen (im Gegenteil, mit dem Hinweis auf die Option einer Zwischengröße hat sie mich noch weiter verunsichert). So habe ich mich erst mal nach den Kosten für die Anpassung erkundigt. Nach meinem Hinweis darauf, dass wir bereits ursprünglich beim Kauf schlecht beraten wurden – denn auch damals bekamen wir nicht die zu unserem Modell passenden Proberinge zum Probieren – bot mir die Verkäuferin einen Preisnachlass um 10€ an. Doch sollte es jetzt statt der ursprünglich versprochenen 25€ auf einmal 35€ pro verkleinerter Größe – sprich 70€ für 2 Größen kleiner – kosten. Die 60€ empfand ich als Hohn und als letztes Angebot wurde mir noch eine Anpassung um 35€ angeboten. Daraufhin habe ich den Laden verlassen um mir in einem anderen Juwelierladen ein Angebot einzuholen.

Im Juwelierladen Weikhart gleich auf der anderen Seite vom Hauptplatz habe ich daraufhin die Situation geschildert und bekam eine äußerst kompetente und freundliche Beratung. Im Vergleich zur Trauring-Lounge wurde mir die Entscheidung für die Größenwahl leicht gemacht, denn die Verkäuferin hat mir den Ring – ganz im Gegensatz zur Konkurrenz – nicht nur auf den Finger gesteckt, sondern auch “herumprobiert”. Es wäre eine ganz klare Angelegenheit: 2 Nummern zu groß. Aufgrund einer ungewöhnlichen Legierungsart wurde auch sofort Rücksprache mit dem Goldschmied gehalten, ob die Änderung denn auch möglich sei. Ich könnte den Ring am nächsten Tag abholen, da der Aufwand aber aufgrund der ungewöhnlichen Legierung noch nicht abschätzbar sei können sie mir noch nicht garantieren, wie viel es ausmachen würde. Als Preisbereich wurden 10 bis 25€ genannt. Für mich war die Entscheidung damit natürlich eine klare Sache. Keine vier Stunden später erhalte ich bereits den Anruf, dass ab sofort mein Ring abgeholt werden kann. Das habe ich dann auch getan, und gezahlt habe ich dafür 10(!) Euro.

Der direkte Vergleich der Beratung war wie Tag zu Nacht, von den Kosten ganz abgesehen. Da man Trauringe üblicherweise nur einmal im Leben kauft können wir unsere Geschichte nur teilen, was hiermit getan sei. Unser Fazit und was ihr daher bitte wissen und weitererzählen sollt:

tl;dr: Finger weg von der 123gold / Trauring-Lounge Graz

Am Samstag, dem 28. April finden heuer wieder die Grazer Linuxtage statt!

Die Suche nach Vorträgen und Projektständen wurde soeben offiziell eröffnet. Wenn du ein spannendes Thema oder Projekt hast, über das du vor einem interessierten Publikum reden möchtest ist das deine Chance. :)

Die Grazer Linuxtage feiern heuer ihren 10. Geburtstag(!) und wir erwarten auch diesmal wieder mehr als 500 Besucher auf einem der größten IT-Events in Österreich.

Disclaimer: Die Grazer Linuxtage sind für ein buntgemischtes Thema bekannt. Wir beschränken uns aber weder auf Linux, noch mußt du dir ein supertechnisches Thema aussuchen. Von Anwendersoftware und Projektvorstellungen, über Themen für Systemadministratoren und Softwareentwickler, bis hin zu freier Kultur und Technik ist alles mit dabei. Ganz besonders freuen wir uns über Vorträge für Einsteiger (du musst definitiv kein Superduperüberdrüber-Geek sein um bei uns vorzutragen – weder wir noch unser Publikum beißen!).

Wir freuen uns über deine Vortrags- und/oder Projektstand-Einreichung über Linuxtage.at.

December, release time. I’m currently involved in the release management of three major projects and it’s not always about fun. So lets make it more fun: https://github.com/mika/commit-sounds

Revision one in the Subversion repository of the FAI project dates back to the 27th of June 2000. Over the last few months we were discussing the switch to Git. At the last FAI meeting we decided to finally switch to Git and I volunteered to drive the migration. Today I officially did the migration.

I’ve been using git-svn to handle the FAI svn repository for at least as long as I’m wearing the FAI stable release manager hat. But the tags, author information,… inside my git-svn checkout weren’t ready for official publishing yet…

There are at least two different well known and referenced svn2git implementations out there. I decided to give the one hosted on github a shot because it’s mentioned at http://help.github.com/import-from-subversion/. It basically uses git-svn and just does the few annoying steps for you that I’d had to do manually otherwise. For more complex repositories the other svn2git implementation might be worth a try, especially since it’s supported by the svneverever tool. svneverever supports more flexible rules regarding the repository layout (it was used for switching Gentoo’s Portage from Subversion to Git). Luckily we didn’t need it in our situation and I had experience with git-svn on the FAI repository already, so…

Converting the repository was as simple as running:

% svn2git svn://svn.debian.org/svn/fai --authors ../fai-svnauthors

The ../fai-svnauthors file contains all the “svnuser = Realname <mail@example.org>” mappings to get the author information right. Some 41 minutes later svn2git finished its work. Finally I pushed the result to the FAI repository at github.

If you’re interested in the repository size of svn vs. git:

• svn repository (server side): 155MB
• svn checkout (client side): 318.3MB (4.3MB trunk, 301MB tags, 13MB branches)
• git-svn checkout: 13MB
• git repository/checkout: 7.1MB

The “Directory specific shell configuration with Zsh” is a rocking feature I use in all my projects when working on the command line. I just created a screencast where I’m showing this feature in action, including its configuration:

This embedded video doesn’t work for you? Try heading over to YouTube.

Since its my first screencast please let me know what you think of it. Waste of time? Want to see further screencasts about Zsh, Grml,…? Is there any other platform than YouTube better suited for such screencasts (for the creator as well as the visitor’s point of view)? Is there anything specific I might consider changing in upcoming screencasts?

For a (german) talk I’ll be giving soon I was interested in a list of open source projects which use Jenkins. Jenkins is a great open source continuous integration server. I was wondering whether such a list exists but since it doesn’t exist yet I created my own and Kohsuke Kawaguchi (creator of Hudson/Jenkins) suggested to blog about it. There we go. :)

• Apache
• Bazar
• cocos2d-x
• ConfigureMe/DistributeMe/MoSKito
• coreboot
• Creativecommons
• Django CMS
• Doom Port Build Service
• Eclipse Communication Framework
• Freeswitch
• Grml
• iceScrum
• JBoss
• Jenkins
• JMRI
• JRuby
• KDE
• Linaro
• Mahara
• Mozilla
• Nuxeo
• OpenQuake
• Pentaho
• Piwik
• Plone
• PODAM
• Pylons Project
• Saiku
• Scala-Tools
• SQLAlchemy
• SQLAlchemy-migrate
• Tapestry 5 modules breadcrumbs + tagselect
• TYPO3
• UTGB (University of Tokyo Genome Browser) Toolkit
• Wicket Stuff
• Zikula

Open source projects using Jenkins, though Jenkins service not accessible for the public (yet):

• Evolvis
• Fusionforge
• Icinga
• Joomla
• OpenJDK 7 for OS/X
• Openstack
• sip:provider CE

And Cloudbees hosts some OSS projects providing Jenkins as a service.

Update [2011-09-05]: I put the list to the jenkins wiki under https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins -> https://wiki.jenkins-ci.org/pages/viewpage.action?pageId=58001258

Update [2011-08-29]: thanks for all the feedback, I’ve updated the list accordingly.
If you’re aware of another open source project using Jenkins please leave it in the comments, I’ll update the list accordingly then.

Die Open Source Experts Group Steiermark veranstaltet am 1. September 2011 das Event “20 Jahre Linux” in Graz. Gemeinsam mit Alfred Bach, Jan Kleinert und Klaus Knopper bin ich als Vortragender anzutreffen. Ich würde mich über ein paar bekannte Gesichter im Publikum freuen. Der Eintritt ist frei, weitere Details unter oseg.at.

Everyone loves stats, ok well – at least I do. I was doing some research with regards to package maintenance within the Debian distribution and since the results might be interesting for someone else – there we are.

On 19th of August 2011 there have been:

• 16935 unique source packages in Debian/sid
• 9977 packages with Vcs-* field in Debian/sid
• 6957 packages without a Vcs-* field in Debian/sid

Therefore ~59% of all packages in Debian/sid are officially managed with a version control system (VCS). Now, which VCS do those packages use?

1. Svn: 4939
2. Git: 4377
3. Darcs: 284
4. Bzr: 247
5. Hg: 61
6. Cvs: 31
7. Arch: 28
8. Mtn: 10

I’ve retrieved the numbers from the Ultimate Debian Database (UDD). Sadly there’s a bug in UDD regarding the Vcs-Type information, see #637524. Therefore I’ve extracted a list of 80 packages where a Vcs-Browser header is available but the Vcs-Type entry is empty in UDD. 29 packages of them are managed inside CVS but don’t appear as such in UDD, so I manually corrected the number for CVS in the numbers above. The remaining 51 packages have a Vcs-Browser field set but lack the according Vcs-* entry, some of them pointing to upstream VCS instead of the according Debian package repository, some of them result in 404 errors, etc. As a result I’ve reported bugs where applicable (#638466, #638468, #638469, #638470, #638471, #638472, #638474, #638475, #638476, #638477, #638479, #638482, #638486, #638488, #638493, #638497, #638501, #638475, #638475, #638502, #638503, #638505, #638506, #638508, #638509, #638510, #638511, #638512, #638513, #638516, #638518, #638519, #638520, #638522, #638523, #638524, #638525, #638526, #638527, #638528, #638529, #638530, #638516, #638531).

Disclaimer: I found Debian’s Statistics wiki page and Zack’s VCS usage stats after starting to play with my own stats. AFAICT Zack’s slightly higher numbers are the result of looking at multiple versions for the same source packages, as you’ll see when comparing numbers from UDD’s sources_uniq view (which I used) with either 1) UDD’s sources table, 2) source table count from projectb or 3) Package count from http://$DEBIAN_MIRROR/debian/dists/unstable/{main,contrib,non-free}/source/Sources.bz2.

Conclusion: 9316 packages are officially managed with Subversion and Git as of today, representing ~94% of the VCS managed packages. This means ~55% of all the Debian (source) packages are available through either a Git or Subversion repository – and that’s actually the number I was originally interested in.

Thanks to Alexander Wirt, Christian Hofstaedter, Gerfried Fuchs, Jörg Jaspert and Michael Renner for hints in forming up the final stats results.

Ich habe soeben “Das Git-Buch – Verteilte Versionsverwaltung für Code und Dokumente” von Valentin Haenel und Julius Plenz gelesen. Das deutschsprachige Buch füllt 328 Seiten und konkurriert mit freien Büchern wie dem Git Community Book, Pro Git und Git In the Trenches. Das Inhaltsverzeichnis des Buches sieht wie folgt aus:

1. Einführung und erste Schritte
2. Grundlagen
3. Praktische Versionsverwaltung
4. Fortgeschrittene Konzepte
5. Verteiltes Git
6. Workflows
7. Git auf dem Server
8. Git automatisieren
9. Zusammenspiel mit anderen Versionsverwaltungssystemen

Es geht schnell zur Sache: die fürs Verständnis besonders wichtigen Themen Index und Objektmodell sind bereits nach rund 60 Seiten solide absolviert. Bei dickeren Büchern habe ich immer Angst, dass die Seiten mit Auszügen aus Manpages oder Kommandozeilenoutput gefüllt sein könnten, das ist aber hier definitiv nicht der Fall. Die Erklärungen sind knackig und präzise geschrieben, es wird nicht lange um den heißen Brei geredet.

Es gibt anschauliche Beispiele und es wird nicht nur das wie erklärt, sondern auch das warum und was der Hintergrund von einem anfangs vielleicht noch komisch anmutendem Konzept ist. Fortgeschrittene Themen wie reflog und filter-branch werden praxisnahe behandelt und auch meine Lieblinge wie –color-words, interaktives Rebasen, git grep und cherry-picking kommen vor.

Ich habe einiges dazu gelernt, wie z.B. ‘git show id:datei’, ‘git gui blame’, den Einsatz von ‘git rerere‘ und wie man eine GPG-Signatur in einen Blob steckt. Dass die sehr nette patch-Option ‘-p’ in vielen Tools funktioniert war mir bereits bekannt, dass die verbose-Option ‘-v’ aber etwa beim Commiten nützlich sein kann war mir neu. Der Hinweis auf mergeinfo-Support in git-svn mit Git Version 1.7.4 kam mir ebenso wie die Gegenüberstellung von Submodules zu Subtrees gerade recht.

Zu Beanstanden habe ich nur eine Kleinigkeit: Im Absatz über gute Commit-Nachrichten fehlt mir ein Hinweis auf englischsprachige Commit-Nachrichten als empfehlenswerter Standard. Das Buch richtet sich natürlich an deutschsprachiges Publikum und daher sind die deutschen Commit-Nachrichten in den Beispielen verzeihbar, aber deutschsprachigen Commit-Nachrichten möchte zumindest ich in keinem Repository begegnen, an dem mehrere Personen beteiligt sind.

Aus der Stichwortliste was ich gerne erwähnt gefunden hätte sind folgende Punkte offen geblieben: das praktische Tool git-wtf, das Konsolenfrontend tig sowie der mit speziellen Tools versehene Workflow gitflow. Zu git-svn fällt mir noch die addAuthorFrom/useLogAuthor-Thematik ein. Sehr praktisch für den Alltag finde ich weiters url insteadOf/pushInsteadOf. Im Kapitel zu Github hätte vielleicht noch ein Hinweis auf eines der hilfreichen Tools wie git-pull-request Platz gehabt. Dass Tools wie git-buildpackage und gitpkg im Debian-Paketbau beliebt sind und diverse Frontends für Emacs und Vim existieren hätte aber vermutlich das Buch inhaltsmäßig gesprengt oder das Risiko mit sich gebracht, dass die Informationen für ein Buch zu schnell überholt sein könnten.

Mein Fazit: Selbst mit über 3 Jahren Erfahrung und als Anhänger von Git hat mich das Buch nicht gelangweilt, sondern das vorhandene Wissen gefestigt und neues dazugestellt. Das Buch liefert solides Wissen in angenehm lesbarer Form und ich kann es Einsteigern wie Fortgeschrittenen empfehlen. Man hat damit den passenden Überblick und die richtigen Stichwörter um sich durch die diversen Manpages und die Weite des Internets zu kämpfen und Git voll genießen zu können.

Disclaimer: Ich habe vom Verlag ein kostenloses Exemplar zur Verfügung gestellt bekommen.

I was giving a skills exchange session about Zsh at DebConf 11. I wasn’t expected to prepare the session, but since there was no video projector available in the meeting room I started to work on some notes.

Looks like I suffer from presentation driven development, so the notes turned out to become bigger than expected. If you’re interested in my Zsh pony then head over to grml.org/zsh-pony.

PS: I plan to provide the zsh pony at github, but my org-mode file still causes an error 500 at github. Github support is already aware of it. In the meantime I’m happy to receive feedback, patches and contributions via mail.