... with Linux kernel patching! Yes, I'm into it again. After my latest patches, which were in the usb subsystem (just stylefixes,... but hey! I'm just getting my feet wet with it!), I'm doing a little bit stylefixing again (in the cdrom driver). But I'm looking forward to do some greater patches, to split up (very) long functions into smaller ones. I'm just curious how I can test my patches. I submitted an email to the kernelnewbies mailinglist and I'm really looking forward to the replies! I'll update my blog after I tried to test my code!

tags: #linux #programming

git is a distributed version control system by Linus Torvalds, the father of the Linux operating system. I use it on an everyday basis when developing code or even when writing texts (papers for my university or similar stuff).

I prepared a workshop on git for my local Unix group, called “Unfug” (german for “mischief” or “horseplay”) which is a shortcut for “Unix friends and user group” in September. Last week, at the 5th of December, the first part of the talk was delivered by me, today (12th of Dec.) the second part will follow. I arranged this workshop in two parts, as there is too much stuff to cover for one session. The normal length of such a talk is one hour, and I used 90 mins for the first part, which is much enough (and of course the length of normal lessons at our university)!

The sources

This workshop is also public available (LaTeX source) at github, as I version-controlled it with git! You can download it and use it for your own stuff under terms of Creative Commons License. For detailed information have a look at the license file, which is shipped with the repository.

The idea of the workshop

The idea of the workshop is not to get the participants from beginner level to professionals. It gives them a basic idea how to work with git (basics as committing and branching) and mentions all other stuff (rebasing, workflows, integration in bash, vim, etc.) and is therefor just kind of an overview. The participants should be able to google around wanted stuff on their own afterwards, as they already heared what is possible with git and how it is called.

Your contribution is wanted!

Please note that the workshop is written in german as well as the commit messages are. I would love if you would submit an english version if you want to, but I don't know if latex supports compilation to english or to german. If you have an easy solution for this, please send me a pull request for your patches! Questions and suggestions are heavily welcome!

tags: #git #tutorial

I added some bash scripts to a repository I currently maintain for a project at my university. We wanted some scripts to generate git repository statistics and parse them to CSV, to be able to plot them with gnuplot lateron easily. The idea is that we can simply invoke make to build the whole thing with updated git statistics and everything (it is a tex document). Here are some of these scripts...

The full history, please, James!

First, let us generate a CSV which contains the full history, including (short) commit hashes, author names, dates and the header of the commit messages:

git log —date=local —pretty=format:“%h%x09%an%x09%ad%x09%s”

As simple as git is, as simple is this script. It's kind of cryptic, as we print x09, which is a tabulator, but it works perfectly! You can also change the --date part to iso to generate ISO dates!

Weekend work, or what?

With this neat piece of bash, we can check how much work was done at weekend days:

for i in Mon Tue Wed Thu Fri Sat Sun do echo -en “$i\t” echo $(git shortlog -n —format='%ad %s'| grep “$i ” | wc -l) done

Example output:

Mon 53 Tue 58 Wed 85 Thu 69 Fri 49 Sat 16 Sun 32

Neat, isn't it?

Do we work at night?

Well, the stuff about the weekdays is really neat, but we can also check if the commiters are morning grouches:

for i in seq -w 0 23 do echo -ne “$i\t” echo $(git shortlog -n —format='%ad %s' | grep “ $i:” | wc -l) done

Example output for this:

00 14 01 9 02 0 03 0 04 0 05 0 06 0 07 0 08 0 09 1 10 5 11 10 12 6 13 15 14 69 15 13 16 21 17 39 18 44 19 21 20 17 21 23 22 36 23 19

As you can see, we work the whole day, from 9 AM until 1 AM! But I think as the project goes on, we will also fill the gap between 2 AM and 8 AM! I hope you found this stuff interesting! I don't know much about gnuplot, the gnuplot part will be done by another project member (hopefully), but I guess this should be easily parseable by gnuplot!

tags: #git

I heard about NixOS at the unfuck conference at my university the very first time. And I was impressed (although I was very tired at the moment the talk came up).

NixOS is, from my point of view, the next generation OS. The idea behind the package managing and handling of dependencies is just the way it should've been all the time. No longer “will this update crash my system or not?” fearing! So, finally, I installed NixOS on my secondary device this week. I had a Debian running Gnome3 on it beforehand, so I wanted to keep my /home directory.

I first burned a USB drive with a NixOS live image on it and started it. It shipped with KDE, which was not my taste (but way better than Gnome3 of course), but hey – on this kindof old machine, it just ran like hell! It was very fast compared to this Gnome crap!

I rebooted and chose the install option in the boot manager. I got a root shell.

I had a documentation. I followed the docs. It worked.

Now I have a NixOS machine that just works, running i3 as Window manager (copied configuration scripts from my main machine for convenience). I installed chromium (as I need this browser for video chatting). I had to override some build stuff for chromium, but luckily my build configuration was already available, so I didn't need to build it on my own (which would take years on this machine, still).

I would recommend NixOS to every linux guy out there, as it is the kind of approach that freaks your mind out while beeing so obviously the right way to do it (it = package management, configuration handling)

tags: #linux #nixos #nix

As I already wrote, I'm using ghost as blogging platform in here. I want to collect some initial thoughts on it in here.

Ghost vs. ...

I used Wordpress, jekyll and nanoc before. And I want to compare them with ghost. You may think they are not comparable, as Wordpress is a content management system, jekyll and nanoc are static site compilers and ghost is a simple blogging platform, but I think they really are!

Wordpress

Wordpress is the most known CMS out there, besides Drupal and Typo3. It is really user-friendly (or was when I used it, which was almost 3 years ago). I really like Wordpress as content management system, and maybe I have to deal around with it at the beginning of next year, but I don't like some things which it is related to... First of all, I really don't like that it is written in PHP. PHP as is, is a terrible language. I even would say it is a cruel language, as it allows things which are absolutely not sane at all. For example, this is absolutely valid PHP code:

php $nothing = NULL; $nothing->foo = "foo";

Not to mention that PHP is slow. I don't want a slow blog. I want a fast blog! The second thing is that Wordpress is big. It became just to big for normal blogging. The whole infrastructure is a mess. I wrote a wordpress theme some day, and I struggled figuring out what exactly to do and why and so on.

jekyll / nanoc

jekyll and nanoc are static site compilers. They compile content into static html files, which are much faster at loading speed (static html can be served in so much less time, you can't imagine)! Also, plain html is much more secure than some running code on your web server, as it is not hackable. The negative thing on this is: you have to do some setup. I know, there is octopress, which is really good at “click and play” and so on, but it is still too much effort for me. Ruby is slow, too! But I don't have to care, as the site compiles on my own device. It can take hours (which would be really annoying, but fortunately these static site compilers are really good optimized), I would never mind, as the pages are still served in nearly no time by the web server.

ghost

Well, ghost is not as much click-and-play as octopress or wordpress. But it is almost. And I can start submitting content to my page in almost no time. It took me one hour to figure out how to get it running on my system. I'm not familiar with this node.js stuff and everything, just read through one or two tutorials I found at google. And it works. It is not as fast as static web pages, but it is also not as slow as Wordpress. I think it works good for me in manner of speed. It is not really as much as nerdy as I usualy prefer my software to be, as it has a neat graphical interface and everything. But it works really well for me. It is not “What you see is what you get” but it has a preview for the markdown I wrote, which is really nice (I sometimes wish I would have this for the latex stuff I write)! It is really much point-and-click stuff, but I never said I wouldn't use such a thing. I just said I don't like this kind of stuff. But I think I will stick to ghost, as I really like it by now!

tags: #blog #ghost

I always wanted to provide some vim tips for advanced vim users. I always feared the feedback, but I think I should do it now.

Use the leader!

Oh my god! Use it! You will get so much faster when using the leader on a regular basis. Of course you have to map it to your mostly used actions, but it can be such an performance win!

Here goes mine. Note that my leader is mapped to my space key:

let mapleader = ““ map w :w& map q :q nnoremap za onoremap za vnoremap zf map sc :SyntasticCheck map nt :NERDTreeToggle %:p:h map tb :TagbarToggle map ut :UndotreeToggle map vr :VimroomToggle map ig IndentGuidesToggle map ga :Git add %:p map gs :Gstatus& map gc :Gcommit -v -q map gd :Gdiff map gb :Gblame map gp :!git push map m :Make map h h map j j map k k map l l map s s map v v

You can find these mappings in my vimrc at github as well. Use it!

Don't use the arrow keys!

This is very critical for your speed when using vim. Never, ever use the arrow keys!

map map map map

You will get faster by lightyears!

This were two tips which are very critical when talking about speed when using vim. I don't know whether these match your idea of 'advanced vim tips', but they are very important to me. I got a performance increase by around 50% just by using hjkl instead of the arrow keys as well as I got faster by the same amount with the leader mappings.

Use them. Tell me what you think.

GPG: 20CA0F94

tags: #vim