Life & much, much more

Things I should’ve done earlier.

On Linux, there are things that you know are better but you don’t switch because you’re comfortable where you are. Here’s a list of the things I’ve changed the past year that I really should’ve done earlier.

  • screen -> tmux
  • irssi/quassel -> weechat + relay
  • apache -> nginx
  • dropbox -> owncloud
  • bash -> zsh
  • bootstrapping vim-spf -> my own tailored and clean dotfiles
  • phing -> make
  • sahi -> selenium
  • ! mpd -> mpd (oh why did I ever leave you)
  • ! mutt -> mutt (everything else is severely broken)
  • a lot of virtualbox instances -> (much less hassle, with support for selenium too!)

… would be interested to know what else I could be missing out on! :)

Spread the love


  1. nginx is a great webserver. Easy to configure and much more lightweight than Apache. I would choose it over Apache if I ever hosted on a VPS.

  2. Absolutely right, hari!

    Only one issue: nginx is not too happy when presented with not-so-common HTTP verbs such as OPTIONS, which is a must-have when I’m developing a discoverable API. So I must live with having nginx proxy over to Apache … just for the API :)

    Also, in an attempt to see if I could write a module for nginx to support OPTIONS (disclaimer: I don’t know C), I did peek inside the codebase and failed miserably. I did come across – which has a lovely quote describing nginx:

    Nginx is not “an established C project”, it’s the insane product of Igor’s twisted mind. It’s a brilliant totally asynchronous giant state machine – which is how it’s so blindingly fast – because everything is non-blocking, and everything is super efficient.

    That said, half the efficiency comes because everything is totally open-coded. Every piece of state machine is right there in hand-spun C. Amazingly long-winded code, which makes it hard to understand immediately what’s going on if you don’t already have the entire state machine in your head!

  3. I know. A lot of clever stuff in C is very abstruse for even experienced programmers, let alone newbies.

    But I am surprised at your choice of ‘make’. I am sure there are more modern and better build systems out there than GNU make.

  4. The choice of `make` is only understood by looking at what I switched “from”. In this case `phing`. Phing is an Ant-based (hence XML) build tool built in PHP and marketed towards the PHP community. While people familiar with Ant will feel at home with Phing, it has two disadvantages:

    1. Building PHP apps is much simpler than compiled languages. A simple set of bash commands written in Make suffices rather than the complex setup that Ant works well with. This means that my Makefile ends up being much smaller and simpler.

    2. It introduces PHP is a build-time dependency! Not only that, Phing is an uncommon tool so most developers will need pull it in before being able to build the software. This is very irksome.

    So the choice of `make` is only limited to the PHP projects, which benefit from very simple bash instructions, conveniently grouped into targets.

    Ant, cmake, et alternatives are still being used outside the PHP projects, of course :)

    What would you recommend, I know you are doing Python?

  5. I haven’t been coding lately, but when I do, I haven’t used any build tools in python projects. When I need to build any resources or stuff, I usually do a manual compile.

    For redistribution I usually use the built-in distutils to create the distributable package and git for the source repository. Of course, I could also use pysetuptools as well.

  6. Ah OK – the projects I work on use CI, and expect daily deploys of multiple versions with their own dependencies on a single host, so the ability to package properly wrt virtual environments is very important.

Leave a Reply

Your email address will not be published. Required fields are marked *