All the code

site/blog/2019-04-27-manage-dotfiles-with-git.md

@@ -0,0 +1,58 @@
+# Manage dotfiles with git
+
+I'm managing my dotfiles with git. My method serves me well for a few
+years already and so I think it's time to write it down.
+
+If you think git, you might think of a dotfile repository and dozens of
+symlinks into the home directory. This is precisely what kept me from
+using git until I discovered bare repositories.
+
+Create your dotfile repository with the `--bare` parameter
+
+<pre>
+git init --bare ${HOME}/.cfg
+</pre>
+
+This creates only a folder for git control files, which normally reside
+inside the `.git` folder within the repository.
+
+You can now tell git to use `${HOME}` as your work-tree directory. This
+makes git handle your home directory like all the files would be within
+the git repository. Now you can:
+
+<pre>
+git --git-dir=${HOME}/.cfg/ --work-tree=${HOME} add .vimrc
+git --git-dir=${HOME}/.cfg/ --work-tree=${HOME} commit -m "my .vimrc"
+</pre>
+
+If course it is silly to type out such a long command every time you
+want to interract with your dotfiles. So why not create an alias?
+
+<pre>
+alias config='git --git-dir=${HOME}/.cfg/ --work-tree=${HOME}'
+</pre>
+
+Put this in your `~/.bashrc` or `~/.kshrc` and you can now use the command
+`config` in the same way you usually use git.
+
+<pre>
+config add .vimrc
+config commit -m "my vimrc"
+</pre>
+
+Maybe you have been brave and typed `config status` already. This will
+list the content of your whole home directory as "untracked files". This
+is not what we want. We can run `git config` and tell it to stop doing
+this. But of course we must run our git, which is called `config`.
+
+<pre>
+config config --local status.showUntrackedFiles no
+</pre>
+
+Now git status will only check what's being tracked. So if you add
+your vimrc file and later change it, `config status` will show it,
+`config diff` will diff it...
+
+You can now use the power of git with your new `config` command.
+
+The solution is not perfect, but it comes pretty close...

site/blog/2019-10-17-LineageOS-on-Motorola-Z2-Force.md

@@ -0,0 +1,42 @@
+# LineageOS on Motorola Z2 Force
+
+Whenever there is a major LineageOS Update, chances are that I forgot
+the flashing process. So here are the notes.
+
+Disclaimer: Due to the missing tools to flash from OpenBSD, I use my
+work computer, which runs windows.
+
+*Required Downloads:*
+
+* [Android Platform Tools](https://dl.google.com/android/repository/platform-tools-latest-windows.zip)
+  (contains adb and fastboot)
+* [Motorola Smart Assistant](https://support.lenovo.com/us/en/downloads/ds101291) (contains USB drivers for fastboot)
+
+*Prepare:*
+
+- Install motorola smart assistant
+- Extract  platform-tools  make  sure  you're  in  the  platform  tools
+  directory or that they are in your $PATH.
+
+*Update steps:*
+
+- > Boot into bootloader (power+down)
+- $ fastboot flash boot_a <lineageos_recovery>.img
+- $ fastboot flash boot_b <lineageos_recovery>.img
+- > Boot into bootloader (power+down) -> Boot Recovery
+- > Factory Reset -> Wipe data / factory reset + Wipe System
+- > Apply update -> adb sideload
+- $ adb sideload <lineageos>.zip
+- $ adb sideload <addons>.zip
+- > Reboot
+
+$ == commandline activity<br>
+&gt; == phone activity
+
+*Notes:*
+
+* "adb devices" works without USB drivers
+* "fastboot devices" shows nothing if USB drivers are not installed
+* This phone has two boot areas and therefore "fastboot flash boot" will
+  fail. The areas "boot_a" and "boot_b" must be used instead. If "boot_a"
+  and "boot_b" are flashed differently, booting will fail.

site/blog/2019-10-24-building-an-openbsd-kernel.md

@@ -0,0 +1,47 @@
+# Building an OpenBSD Kernel
+
+I'm running OpenBSD-current for a while in order to support my port.
+It's only one port at the moment, but that's a start, right?
+
+Anyway... every once in a while I stumble over a patch on the OpenBSD
+mailing list I want to try and this requires me to apply the patch and
+build the Kernel with it. But how?
+
+Well, the documentation is where
+[where you would expect it](https://www.openbsd.org/faq/faq5.html#Custom).
+
+*Download the kernel source*
+
+<pre>
+# cd /usr
+# cvs -qd anoncvs@anoncvs.ca.openbsd.org:/cvs checkout -P src
+</pre>
+
+*Update the kernel source (if you downloaded it a while ago)*
+
+<pre>
+# cd /usr/src
+# cvs -q up -Pd
+</pre>
+
+*Configure Kernel*
+
+<pre>
+# cd /usr/src/sys/arch/amd64/conf
+# cp GENERIC.MP MYKERNEL
+# config MYKERNEL
+</pre>
+
+*Build and install kernel (amd64)*
+
+<pre>
+# cd /sys/arch/amd64/compile/MYKERNEL
+# make clean
+# make
+# make install # the old kernel is /obsd now
+</pre>
+
+That's it. Reboot.
+
+This is ONLY the Kernel. If you need to build the whole system, please
+consult the OpenBSD documentation. The manpage release(8) is a good start.

site/blog/2020-05-17-browser-dark-mode.md

@@ -0,0 +1,55 @@
+# Browser Dark Mode
+
+Dark Mode luckily has become a thing also in the non-unix world. Finally
+browsers can be used with dark interfaces and websites can have
+alternative color schemes.
+
+However, in other operating systems, there is a global toggle for dark
+mode, which also switches the browser into it. This is not the case on
+linux and unix systems.
+
+## Chrome / Chromium / Iridium
+
+Chrome and Chromium starting with version 73 can be tought to start in
+dark mode:
+
+<pre>
+$ chrome --enable-features=WebUIDarkMode --force-dark-mode
+</pre>
+
+Then go to chrome://settings/?search=themes and switch the theme to
+"Classic".
+
+## Firefox
+
+Firefox learned the dark mode in release 70.
+
+  0. Go to "about:config"
+  1. Enter "ui.systemUsesDarkTheme" into the search bar
+  2. Click "Number" and then "+"
+  3. Enter "1" and click the check mark
+
+Right click on a free spot in the icon bar and select "customize". At
+the bottom left of the screen, you can switch to a dark theme.
+
+Note: If you've set privacy.resistFingerprinting to "true" the CSS dark
+mode switching won't work. Kudus to
+[@andinus@tilde.zone](https://tilde.zone/@andinus) for figuring this out.
+
+There you go, both browsers are in dark mode now. The UI should be dark
+and also websites that support the `@media (prefers-color-scheme: dark)`
+directive should make use of it.
+
+You can test it on my webpage ([https://codevoid.de](https://codevoid.de)). The
+light version has a light gray background and a blue font. The dark version has
+a dark gray background and an orange font.
+
+## vim-browser (vimb)
+
+<pre>
+$ echo "set dark-mode=true" &gt;&gt; ${HOME}/.config/vimb/config
+</pre>
+
+## luakit
+
+Open `:settings` and check `application.prefer_dark_mode`

site/blog/2020-11-14-openbsd-fde.md

@@ -0,0 +1,32 @@
+# OpenBSD FDE Setup
+
+This is a condensed version of [OpenBSD FDE
+FAQ](https://www.openbsd.org/faq/faq14.html#softraid).
+
+Boot installer, drop to shell with "s"
+
+<pre>
+# cd /dev && sh MAKEDEV sd0
+# dd if=/dev/urandom of=/dev/rsd0c bs=1m
+# fdisk -iy -g -b 960 sd0 # GPT / without -g and -b for MBR
+# disklabel -E sd0
+</pre>
+
+Note, switch to kbd en before setting the password as this is
+what you have on the boot prompt.
+
+<pre>
+# bioctl -c C -l sd0a softraid0
+# dd if=/dev/zero of=/dev/rsd1c bs=1m count=1
+</pre>
+
+Ctrl+D to restart the installer. Choose sd1 as install target.
+
+If sd1 is not present:
+
+<pre>
+# cd /dev && sh MAKEDEV sd1
+</pre>
+
+When the installer later asks about installing with MBR or GPT layout, 
+choose MBR. Even if you boot via UEFI/GPT.

site/blog/2021-01-09-mutt-inline-patch-macro.md

@@ -0,0 +1,74 @@
+# Mutt inline patch handling
+
+Developers like to send diffs inline in emails. They do this, because it's fast
+and easy to read through them, comment on them and also to apply them. Some
+version control systems also take over the email text into the patch description
+as well.
+
+Up to now, my workflow was manual. I had to save the email somewhere, then open
+a terminal, cd to the direcory the patch shall be applied in and call the patch
+utility with the path to the saved email as argument.
+
+No more.
+
+This mutt macro takes the current visible email and copies it to a temporary
+file (/tmp/mutt-patch.diff). Then it executes the portpatch.sh shell script. All
+with one push on ctrl+s while looking at the email.
+
+The macro must be written in one line and ^S can be entered with the keyboard
+sequence ctrl+v ctrl+s:
+
+<pre>
+macro pager ^S "&lt;shell-escape&gt;rm -f /tmp/mutt-patch.diff&lt;enter&gt;&lt;copy-message&gt;/tmp/mutt-patch.diff&lt;enter&gt;&lt;enter-command&gt;echo 'Saved as /tmp/mutt-patch.diff'&lt;enter&gt;&lt;shell-escape&gt; ~/.mutt/scripts/portpatch.sh /tmp/mutt-patch.diff&lt;enter&gt;"
+</pre>
+
+The portpatch.sh script:
+
+<pre>
+#!/bin/sh
+# needs converters/qprint
+clear
+
+echo '---------------------------------------------------------------------'
+grep -E 'Subject: |^Index|^RCS|^diff --git|^file +|^[-+]{3} ' "${1}"
+echo '---------------------------------------------------------------------'
+
+printf "Apply patch on path [defaults to /usr/ports]? "
+read -r _path
+
+printf "Fix quoted-printable mangeled patch? [y/N]: "
+read -r _qprint
+
+case ${_qprint} in
+    [y|Y]) _catcmd="qprint -d"; ;;
+        *) _catcmd="cat"; ;;
+esac
+
+printf "Strip? [0]: "
+read -r _strip
+
+${_catcmd} "${1}" | doas patch -Ep${_strip:=0} -d ${_path:=/usr/ports}
+cd ${_path} && ksh
+</pre>
+
+The script shows some relvant bits from the email patch that are handy 
+to determine on which path the patch shall be applied.
+
+Next it allows the user to enter a different path. I mostly use /usr/ports, so
+this is the default. Then the patch is applied and a ksh shell is opened for
+further work.
+
+Quitting the shell brings me back to mutt to work on the next email.
+
+Sometimes someone sends a mangled patch encoded in quoted-printable. My script
+allows to fix this with qprint.
+
+Git diffs mostly need strip 1 to cut off the a/ b/ in front of the file path, so
+the script is asking for that too. For most patches on ports@, the defaults are
+fine and hitting enter 2 times works as intended.
+
+*...and if everyone would generate patches from the /usr/ports root, it wouldn't
+even be necessary to enter the path.*
+
+This is quite friggin handy.
+

site/blog/2021-05-19-gnupg-quickstart.md

@@ -0,0 +1,213 @@
+# GnuPG Quickstart
+
+I love GPG and the way it works. I know there are many that complain
+about it because it has flaws. My stance on this is that I prefer
+battle-tested software with known flaws to something with unknown flaws.
+
+Anyway, this should get you started with GnuPG
+
+## Prerequisites
+
+Install gpg and pinentry.
+
+<pre>
+# pkg_add gnupg pinentry
+</pre>
+
+## You need a Key
+
+If you want to lock and unlock stuff, you need a key. This is how you 
+get to one:
+
+<pre>
+$ gpg --generate-key
+</pre>
+
+Hop through the wizard until you see these lines:
+
+<pre>
+pub   rsa3072 2021-05-19 [SC] [expires: 2023-05-19]
+      BA696588D9A04AD9F70DA33EC54733F6DBECC2C1
+uid                      John Doe &lt;j.doe@example.com&gt;
+sub   rsa3072 2021-05-19 [E] [expires: 2023-05-19]
+</pre>
+
+If you see an error like:
+    gpg: agent_genkey failed: Permission denied
+
+Add the following entry and try again.
+
+<pre>
+$ echo "allow-loopback-pinentry" &gt;&gt; ~/.gnupg/gpg-agent.conf
+</pre>
+
+Congratulations, you got yourself a GPG Key. This long gibberish is your 
+full GPG Key ID. Most of the time, you can simply use the last 8 
+characters. So the short version of this GPG Key is DBECC2C1.
+
+You can set it as default key, so it's used to encrypt stuff when no
+explicit key is given.
+
+<pre>
+$ echo "default-key DBECC2C1" &gt;&gt; ~/.gnupg/gpg.conf
+</pre>
+
+## Share the key with your people
+
+If you want someone to be able to encrypt something for you, send him or 
+her the output of:
+
+<pre>
+$ gpg --export -a DBECC2C1
+</pre>
+
+You can also use your email address instead of the Key ID, if you have
+only one key with it. This key is public. So put it on some webspace and
+add a link to your email header or signature.
+
+## Upload the key so people can find it (optional)
+
+You can also upload your key to a key server. For this, configure a 
+keyserver:
+
+<pre>
+$ echo "keyserver hkps://keys.openpgp.org" &gt;&gt;  ~/.gnupg/gpg.conf
+</pre>
+
+Then send your key to it:
+
+<pre>
+$ gpg --send-keys DBECC2C1
+</pre>
+
+## You got a key from someone
+
+Add a key from someone else to gnupg, so you can use it to encrypt data 
+for this person. If the key is on your harddrive, use:
+
+<pre>
+$ gpg --import &lt;pubkeyfile.asc&gt;
+</pre>
+
+The file ending here is kind of undefined. Some call it .asc, .gpg, .pub
+or .key. If the key is on a key server, you can import it like so:
+
+<pre>
+$ gpg --recv-key 52BE43BA
+</pre>
+
+This would import my key. You can look at it now with:
+
+<pre>
+$ gpg --list-keys 52BE43BA
+</pre>
+
+## Encrypt a file
+
+This encrypts the file plain.txt with the public key DBECC2C1.
+
+<pre>
+$ gpg --encrypt -r DBECC2C1 file.txt
+</pre>
+
+Now you have file.txt.gpg, which is the encrypted version
+
+## Decrypt a file
+
+GnuPG automaticall figures out what key it can use to decrypt a file. So 
+this will output the content of file.txt on the terminal. If you want 
+to save the output in a file, add -o file.txt.
+
+<pre>
+$ gpg -d file.txt.gpg 
+$ gpg -d file.txt.gpg -o file.txt
+</pre>
+
+## Choose a better password prompt (optional)
+
+You can change the way gpg asks for the password:
+
+<pre>
+$ cat ~/.gnupg/gpg-agent.conf
+[...]
+pinentry-program /usr/local/bin/pinentry-curses
+[...]
+</pre>
+
+Options are:
+
+  - pinentry (sometimes also called pinentry-tty)
+  - pinentry-curses
+  - pinentry-gtk2: pkg_add pinentry-gtk2
+  - pinentry-gnome3: pkg_add pinentry-gnome3
+  - pinentry-dmenu: https://github.com/ritze/pinentry-dmenu
+
+*Note: If you use a console pinentry program and want to use gpg with a
+GUI tool (like thunderbird), the password prompt will be invisible and
+gpg/thunderbird will freeze.*
+
+Makes sense, doesn't it?
+
+## Start GPG Agent for password caching (optional)
+
+Put this in your .kshrc or .bashrc:
+
+<pre>
+export GPG_TTY=$(tty)
+gpg-connect-agent /bye
+</pre>
+
+## Make a Backup (not so optional)
+
+There is no handholding cloud or support team you can call when you 
+messed up or deleted your key. So back it up safely.
+
+Either you backup your ~/.gnugp directory, or you export the secret 
+keys and backup them safely.
+
+<pre>
+$ gpg --export-secret-keys -a DBECC2C1 &gt; gpg_key_backup.sec
+</pre>
+
+Seriously, don't skip this step.
+
+## Configure Mutt (optional)
+
+Install mutt with the gpgme flavor. Gpgme is the "new way" of handling 
+gpg in mutt.
+
+<pre>
+# pkg_add mutt--gpgme
+</pre>
+
+If you're not on OpenBSD, check with `mutt -v` if it was compiled with
+the `--enable-gpgme` option. Then enable it in mutt.
+
+<pre>
+$ cat ~/.muttrc
+[...]
+crypt_use_gpgme = yes
+[...]
+</pre>
+
+In the mutt compose view, you can now select Security Options.
+
+<pre>
+        From: c0dev0id &lt;c0@example.com&gt;
+          To: j.doe@example.com
+          Cc:
+         Bcc:
+     Subject: Hello my friend
+    Reply-To:
+         Fcc: =Sent
+    Security: Sign, Encrypt (PGP/MIME)
+     Sign as: &lt;default&gt;
+</pre>
+
+You can change the setting with the key "p", which should bring up a
+selection menu.
+
+    PGP (e)ncrypt, (s)ign, sign (a)s, (b)oth, s/(m)ime or (c)lear?
+
+*That's it! GPG is not difficult. You need to know a few bits, but these are not
+more difficult than many other things we do on a daily basis.*

site/blog/2021-09-26-memory-management.md

@@ -0,0 +1,69 @@
+<i>Disclaimer: I'm trying to learn this stuff. Now a year later, I think
+I got some terminology wrong. The process address space is not one, but
+many pages. How many depends on the page size.</i>
+
+# Memory management, virtual and residential memory
+
+Memory management is a complex topic and most can be left for the kernel 
+to handle. But having a fundamental idea about where memory is
+allocated greatly helps in understanding top(1) and the memory footprint
+of applications.
+
+## Process memory address space (page)
+
+When a process starts up, the kernel assigns it a so called memory page.
+The page size depends on the architecture. On amd64 it's 2^64 - 1 bytes.
+
+Every memory allocation this process performs, returns a pointer to some
+place within this page. Forcing a pointer outside this page, will cause
+a SEGFAULT.
+
+<pre>
+char *w = 1; // segfault
+char *w = malloc(12); // returns pointer within page
+</pre>
+
+# Memory allocation (virtual memory)
+
+Let's say we allocatate 2G of memory:
+
+<pre>
+char *m = malloc(2*1073741824); // 2*1G in bytes
+</pre>
+
+This will grab 2G of consecutive address space within the process memory.
+At this point, the memory is likely available but not guaranteed. The
+allocation shows up in top(1) as "SIZE" or on linux as "VIRT"ual memory.
+This memory is not actually used. So nothing has been written to the
+physical RAM chip in your computer.
+
+# Using memory (residential memory)
+
+Once memory gets used, it will actually use up space on your RAM chip.
+
+<pre>
+memset(m, 'u', 1073741824);
+</pre>
+
+Now we've written the character "u" to the first 1G of our allocated
+memory. If we look at top(), we'll see something like this:
+
+<pre>
+  PID      TID PRI NICE  SIZE   RES STATE     WAIT      TIME    CPU COMMAND
+96621   569318   3    0 2048M 1027M sleep/12  ttyin     0:01  1.66% ./a.out
+                          ^     ^
+        allocated memory -'     `- used (written) memory
+</pre>
+
+Note 1: When memory is swapped to disk, it leaves the residential bucket and
+can be seen as swap-&gt;used.
+
+Note 2: Stack memory will also show up as residential when used. Unused stack
+memory will *not* show up as virtual memory.
+
+Note 3: Residential memory includes shared memory as well. If you see 10
+chrome processes which are consuming 300MB of residential memory each, this
+does *not* mean that chrome as a whole is using 3000MB.
+
+TODO: Find out how the shared memory part of RES can be seen on OpenBSD.
+(Linux has SHR in top)