This website

This website is generated using a customized toolchain, built with Markdown, the Template Toolkit, Perl, some filters in between, nginx, and rsync. Both the front-end and back-end run on OpenBSD.

This setup helps keeping administrative overhead to a minimum.

Perl is my programming language of choice, over the years I have accumulated experience with many modules.

Other websites

When I implement a website for others – and left with the choice – I use Drupal and its extensive collection of modules. I always keep the "separation of concerns" principle in mind and therefore stay away from PHP development, only using proven Drupal building blocks thus ensuring long-term maintainability.

Other tools

I have experience with SQL and several RDBMs (PostreSQL, MySQL/MariaDB, SQLite) as well as various web servers (nginx, Apache 2, httpd(8)).

Whenever possible I self-host my online tools. Beside this website I host my own mail service with a setup involving OpenSMTPd, spamd(8), dovecot, spamassasin, and clamav, among others.

I also have a radicale server providing CalDAV and CardDAV services. WebDAV is provided by a simple py-webdav setup.

At home I run a samba network file server that also provides network printing and scanning services, using cups and saned, respectively.

I even run a mini CA using openssl(1) – ah, well... – so that these services can be accessed when the user device requires a root CA to be installed.

Part of the monitoring is done using awstats, rrdtool, and of course tools in the base system such as pflog.

And so on and so forth...I like to get hands-on.

Why OpenBSD

There are so many reasons that make OpenBSD a very dependable system:

Quoting de Raadt on misc@ on April 04, 2014:

But unlike on other operating systems, those applications are ALWAYS compiled with PIE, and the stack protector is ALWAYS on, and the address space is ALWAYS heavily randomized, and libc and the base librares ALWAYS have various mitigations and other randomizations turned on. Approximately 100 mitigation components (large and small) add up, and apply to every single program run on such a machine in various ways (large and small).

It is not zero sum.

And on another message, same list same date:

The explanation is simple, we traded about 5% of application performance for built-in ALWAYS-ENABLED security mitigations that we found in research papers, or elsewhere, or invented ourselves. Because machines keep getting faster, our community barely noticed the performance loss.

But they notice that they were not getting holed.

That's worth praising.

And surely I should not have to mention the Heartbleed disaster to illustrate how critical this is.