Repology is monitoring package repositories across Linux distributions. By now, Atom feeds of per-maintainer outdated packages that I was waiting for have been implemented.

So I subscribed to my own Gentoo feed using net-mail/rss2email and now Repology notifies me via e-mail of new upstream releases that other Linux distros have packaged that I still need to bump in Gentoo. In my case, it brought an update of dev-vcs/svn2git to my attention that I would have missed (or heard about later), otherwise.

Based on this comment, Repology may soon do release detection upstream similar to what euscan does, as well.

I've been wanting to get away from Wordpress for a while now. To get rid of dynamic code execution, of MySQL, of PHP, and Wordpress in particular. I finally completed that move.

The conversion to Static Site Generator Nikola took me a while, maybe I'll make time for another post with a few more details. There may still be a few rough edges, e.g. with the URL rewrite mapping. Please let me know if you notice anything broken.

I would like to apologize if any Blog Planet gets spammed by the change in feed entry IDs.

For the record, this is what the blog looked like for the past years:

Good bye, Wordpress.

EDIT 2018-05-29: Missing favicon restored

We had a case at work were multi-line output of a command should be turned into an array of lines. Here's one way to do it. Two Bash features take part with this approach:

• $'....' syntax (a dollar right in front of a single-tick literal) activates interpolation of C-like escape sequences (see below)
• Bash variable IFS — the internal field separator affecting the way Bash applies word splitting — is temporarily changed from default spaces-tabs-and-newlines to just newlines so that we get one array entry per line

Let me demo that:

# f() { echo $'one\ntwo  spaces' ; }

# f
one
two  spaces

# IFS=$'\n' lines=( $(f) )

# echo ${#lines[@]}
2

# echo "${lines[0]}"
one

# echo "${lines[1]}"
two  spaces

I wanted to write this post for a while now. It's about how different IT companies are, in Berlin. I find that interesting. The examples include what I have witnessed myself, at jobs but also interviews, and also tales from friends. I will leave the implications of that diversity to you. I expect to revise this post a few times in the future. Also, splitting things into disjoint categories turned out to be difficult, so it's somewhat arbitrary. Order does not necessarily reflect importance. With that being said, these are some examples for ways in which Berlin IT companies differ :

People

• Diverse mix —vs— 95% locals
• Daily English —vs— German all day long
• Mostly juniors —vs— mostly seniors
• Have developer colleagues —vs— be the only IT guy around
• IT and non-IT people mostly lunch together —vs— they hardly mix
• Colleagues selected by the team —vs— colleagues selected by management

Development

• Git —vs— Mercurial
• CI on master branch —vs— on all branches —vs— zero CI
• Beyond 90% line coverage —vs— no tests at all
• Mostly okay code —vs— mostly insane code
• Monoliths —vs— microservices —vs— something in between
• master branch always green —vs— in constant need of repair
• master branch has a single gatekeeper —vs— it has not
• Code review is waving through —vs— code review is collaboration, exchange, learning —vs— code review is not done
• Paid IDE —vs— free edition of commercial product

Operations

• Multiple live environments including staging —vs— production only
• Hotfixes applied live on the server —vs— hotfixes go through CI

Responsibilities

• Dedicated ops people —vs— devs doing ops work as well
• Trying to make everyone full-stack —vs— accepting preferences for frontend or backend
• Getting informed —vs— constant need to hunt information yourself
• Lots of freedom —vs— work drone on a road-map done entirely without you
• Growing software —vs— getting tickets done some way fast

Working hours

• 32h per week welcome/tolerated —vs— 40h per week enforced
• Official core hours from 10:00 to 15:00 (5h) —vs— 10:00 to 17:00 (7h!) —vs— 9:00 to 17:00 (8h!) —vs— …
• Core hours enforced/complained —vs— come in at 11:00, we're good
• Sleep at night —vs— be called by ops for help at 1am
• Home office by choice —vs— home office by explicit approval

Compensation

• Salary negotiated to the ground —vs— accepting what you asked
• Salary raised every 12 months by contract —vs— no plans to raise before you bring it up
• 25 —vs— 26 —vs— 28 —vs— 30 —vs— 40 days of vacation
• Vacation is negotiable —vs— vacation is enforced to be consistent across employees
• Overtime compensated —vs— overtime not compensated
• Overtime expected —vs— overtime avoided

Contract

• Permanent contract —vs— temporary contract
• Can be adjusted —vs— refusing to change anything "for administration reasons" (to then find out …)
• Is explained when you have questions about details —vs— is not explained
• Is German and English side by side —vs— German only
• Is mostly okay —vs— full of traps and raising eyebrows frequently

Rooms

• Sales people have calls right next to you —vs— on the hallway —vs— nowhere near
• 2 people per room —vs— 4 to 6 people per room —vs— 20+ people per room —vs— soccer field sized rooms
• Headphones, coming early, staying later to get work done —vs— healthy amount of distractions

Office

• No plants —vs— externally managed alibi plants —vs— 800 Euro budget to go buy some as a team next week
• Rather dark —vs— loads of light
• Windows to open —vs— air conditioning and no window opens in the building

Surroundings

• Variety of tasty lunch options nearby —vs— hardly any

Equipment

• Freely chosen —vs— mediocre presets —vs— same reflecting Apple box for everyone
• Healthy chair granted —vs— on demand —vs— they'd rather have you quit
• Motor-lift table —vs— screw-lift table —vs— fixed height (of unfit/unhealthy height)

Drinks / Food

• Machine-made sparkling tap water —vs— three types bottled mineral that are hardly ever run out
• Water, wide variety of soft drinks, juices and beer —vs— two boring options
• pay-yourself sweets —vs— free sweets —vs— no sweets
• Barely drinkable coffee from press to a single button —vs— "Siebträger" espresso machine for handmade gourmet coffee (i.e. the "Gentoo way")

Your mileage varies? Interesting differences missing? Surprised? Drop me a mail!

Last updated 2020-04-05

I recently dockerized a small Django application. I build the Dockerfile in a way that the resulting image would allow running the container as if it was plain manage.py, e.g. that besides docker-compose up I could also do:

# For a psql session into the database:
docker-compose run <image_name> dbshell

# Or, to run the test suite:
docker-compose run <image_name> test

To make that work, I made this Docker entrypoint script:

#! /bin/bash
# Copyright (C) 2018 Sebastian Pipping <sebastian@pipping.org>
# Licensed under CC0 1.0 Public Domain Dedication.
# https://creativecommons.org/publicdomain/zero/1.0/

set -e
set -u

RUN() {
    ( PS4='# ' && set -x && "$@" )
}

RUN wait-for-it "${POSTGRES_HOST}:${POSTGRES_PORT}" -t 30

cd /app

if [[ $# -gt 0 ]]; then
    RUN ./manage.py "$@"
else
    RUN ./manage.py makemigrations
    RUN ./manage.py migrate
    RUN ./manage.py createcustomsuperuser  # self-made

    RUN ./manage.py runserver 0.0.0.0:${APP_PORT}
fi

Management command createcustomsuperuser is something simple that I built myself for this very purpose: Create a super user, support scripting, accept a passwords as bad as "password" or "demo" without complaints, and be okay if the user exists with the same credentials already (idempotency). I uploaded createcustomsuperuser.py as a Gist to GitHub as it's a few lines more. Back to the entrypoint script. For the RUN ./manage.py "$@" part to work, in the Dockerfile both ENTRYPOINT and CMD need to use the [..] syntax, e.g.:

ENTRYPOINT ["/app/docker-entrypoint.sh"]
CMD []

For more details on ENTRYPOINT quirks like that I recommend John Zaccone's well-written article "ENTRYPOINT vs CMD: Back to Basics".

Say you have created a favicon.ico for your website and want to serve that file outside of the usual /static/images prefix, at /favicon.ico. Other favicon approaches use a code-30x redirect on HTTP level. I would rather save that extra request. Here is what I ended up with:

import os

from django.conf import settings
from django.views.static import serve

urlpatterns += [
    url(r'^(?P<path>favicon\.ico)$', serve, name='favicon',
        kwargs={'document_root': os.path.join(settings.STATIC_ROOT,
                                              'images')}),
]

Licensed under CC0 1.0 Public Domain Dedication.

Probably not new but was new to me: Just ran into this Larry the Cow tattoo online: http://www.geekytattoos.com/larry-the-gender-challenged-cow/

When system-wide pip turns out too old (e.g. for lacking support for pip check), one may end up trying to update pip using a command like:

sudo pip install --upgrade pip

That's likely to end up with this message:

Not uninstalling pip at /usr/lib/python2.7/dist-packages, owned by OS

That non-error and the confusion that easily happens right after is why I'm writing this post. So let's look at the whole thing in a bit more context on a shell, a Debian jessie one in this case:

# cat /etc/debian_version 
8.10

# pip install --upgrade pip ; echo $?
Downloading/unpacking pip from https://pypi.python.org/packages/b6[..]44
  Downloading pip-9.0.1-py2.py3-none-any.whl (1.3MB): 1.3MB downloaded
Installing collected packages: pip
  Found existing installation: pip 1.5.6
    Not uninstalling pip at /usr/lib/python2.7/dist-packages, owned by OS
Successfully installed pip
Cleaning up...
0

# pip --version
pip 1.5.6 from /usr/lib/python2.7/dist-packages (python 2.7)

Now the interesting part is that it looks like pip would not have been updated. That impression is false : Latest pip has been installed successfully (to /usr/local/bin). One of two things is going on here: a) Unexpected Path resolution order You have /usr/bin/ before /usr/local/bin/ in $PATH, e.g. as with root of Debian jessie, so that the new pip has no chance of winning the race of path resolution for pip. For example:

# sed 's,:,\n,g' <<<"$PATH"
/bin
/sbin
/usr/bin
/usr/sbin
/usr/local/bin
/usr/local/sbin
/opt/bin
/usr/lib/llvm/5/bin
/usr/lib/llvm/4/bin

b) Location hashing at shell level Your shell has hashed the old location of pip (as Bash would do) and "hides" the new version from you in the current shell session. To see that in action, we utilize Bash builtins type and hash:

# type pip
pip is hashed (/usr/bin/pip)

# pip --version
pip 1.5.6 from /usr/lib/python2.7/dist-packages (python 2.7)

# hash -d pip

# type pip
pip is /usr/local/bin/pip

# pip --version
pip 9.0.1 from /usr/local/lib/python2.7/dist-packages (python 2.7)

So in either case you can run a recent pip from /usr/local/bin/pip right after pip install --upgrade pip, no need to resort to get-pip.py or so, in fact.

This "crazy" vulnerability in LibreOffice only came to my attention recently:

LibreOffice < 6.0.1 - '=WEBSERVICE' Remote Arbitrary File Disclosure (exploit-db.com)

Please make sure yours peers update in time.

Some people care if software is free of cost or if it has the best features, above everything else. I don't. I care that I can legally inspect its inner workings, modify and share modified versions. That's why I happily avoid macOS, Windows, Skype, Photoshop. I ran into these two pieces involving Gentoo in the Gallery of Free Software lovers and would like to share them with you:

Images are licensed under CC BY-SA 4.0 (with attribution going to Free Software Foundation Europe) as confirmed by Max Mehl.