Dienstag, 4. Dezember 2018

MacOS "Mojavody"

I usually use my machine for work and communication (no game has ever been played on it), I do like some eye-candy. When I had my first Mac it was Snow Leopard - and, wow, that was an eye catcher. It was the same for all the big cats that followed.

Then came MacOS 10.10 "Yosemite" and with it came Apple's new design language, and that was all flat. I disliked it from the first day. So what was I to do? I loved my machine, had a productive working environment running on it, but hated to look at it? For Yosemite the solution was "Flavours2", a theming engine with a selection of fairly acceptable themes.

Safari on "Mojavody"

Samstag, 28. Juli 2018

Die Errichtung des Moskauer Patriarchats

Höhlenkloster Kyiv, Quelle: Wikipedia, Lizenz: Creative Commons
Aktuell wird ja eine mögliche Autokephalie der ukrainischen Orthodoxen Kirche diskutiert und auch von manchen als realistisch betrachtet, nachdem der Ökumenische Patriarch Bartholomäus von Konstantinopel erklärt hatte, dieses Ansinnen wohlwollend zu betrachten.

Die orthodoxe Kirche des Kyiver Patriarchats war im Jahr 1686 aus der Zuständigkeit Konstantinopels gelöst und dem Moskauer Patriarchat - also der russischen Staatskirche - untergeordnet worden [1]. Mit der Unabhängigkeit der Ukraine entstanden in der Ukraine zwei von Moskau unabhängige orthodoxe Kirchen [2], [3], die beide als nicht kanonisch anerkannt sind - weswegen man sich eben um die Erteilung des Status der Autokephalie bemüht.

Aus der Richtung russischer Kirchen- und Regierungskreise wird gegen diese Bemühungen aus allen Rohren geschossen - das Moskauer Patriarchat sei die einzig legitime Kirche für die Ukraine, und das müsse und könne auch nur so bleiben.

Bei all den kirchenrechtlichen Verwicklungen, über die gern die Experten entscheiden sollen (oder auch nicht), ist es dennoch interessant, wie eigentlich damals die Kirche des damals eher provinziellen Moskau zu ihrem Patriarchen kam.

Hier sind einige Quellen, die das ein wenig beleuchten.

Mittwoch, 25. Juli 2018

Wenn reboot -f versagt...

Auch Linuxe können mal komplett vermurkst sein (Zombie-Prozesse, die sich nicht beenden lassen etc.). Das kann bis zu dem Punkt gehen, wo ein reboot -f keinen Effekt hat.
Solange man noch eine Shell hat, muss man aber dennoch nicht aufstehen, um einen Neustart zu erzwingen:
echo 1 > /proc/sys/kernel/sysrq
echo b > /proc/sysrq-trigger
So. Auch das ist persistiert :)

Samstag, 9. Juni 2018

Gendern - demokratische Pflicht?

Kürzlich stieß ich über die sozialen Netze auf einen Artikel von Henning Lobin und Damaris Nübling in der Süddeutschen, in dem anlässlich eines am 8. Juni vom Deutschen Rechtsschreibrat diskutierten Vorschlags des Landes Berlin zur Einführung des Gendersternchens in die deutsche Rechtschreibnorm[1] die Autoren leidenschaftlich für "geschlechtergerechte Schreibung" eintraten.


Hier heißt es u.a., dass wer die Gleichstellung der Geschlechter wolle, sie auch beide [explizit] ansprechen müsse. Neben dem in diesem Kontext leider schon obligatorischen Verweis auf Vorstöße der AfD gegen das sprachliche Gendern wird anhand einiger Beispiele zu beweisen versucht, dass die Trennung von grammatischen vom biologischen Geschlecht, die dem generischen Maskulinum zugrunde liege, falsch sei und die Sprache auch in diesem speziellen Kontext die Wahrnehmung des Menschen "lenke".

Freitag, 18. Mai 2018

Centralised Logging with EFK and hot/warm in Kubernetes

Everybody is talking about centralised logging these days, and most seem to agree that EFK (Elasticsearch, Fluentd, Kibana) is a good combination for accomplishing this. The Kubernetes repo on github contains something to start and play with, but it is far from production-ready:
  1. The Kibana version used there is rather old
  2. Elasticsearch is not production-ready (single node instance, no decoupling of resource-hungry indexing and long-term, read-only storage)
While (1) can be overcome rather easily, (2) poses a bit more of a challenge - how can we create a production-ready Elasticsearch service using Kubernetes? The Elasticsearch folks propose the so-called "hot/warm" architecture for addressing this:
  • "hot" nodes running on fast and expensive hardware (fast CPUs, lots of memory, SSDs) do all the indexing of anything coming in. 
  • All data older than a configurable period of time is moved to so-called "warm" nodes running on potentially slower and less expensive hardware with large disks (usually HDDs). No indexing takes place here, data is kept read-only for queries only.