From a30460cc038708e3a01cbe8cf4d90c6572e26784 Mon Sep 17 00:00:00 2001 From: Paul Buetow Date: Fri, 21 Feb 2025 10:54:55 +0200 Subject: added the science of living --- notes/the-science-of-living.gmi | 51 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 notes/the-science-of-living.gmi diff --git a/notes/the-science-of-living.gmi b/notes/the-science-of-living.gmi new file mode 100644 index 00000000..675446f6 --- /dev/null +++ b/notes/the-science-of-living.gmi @@ -0,0 +1,51 @@ +# "Science of Living" book notes + +These notes capture key points from "The Science of Living" by Stuart Farrimond. These are for my personal use, but you might find them useful, too. + +## Morning Routine + +Don't check email or to-do lists in the first hour after awakening to avoid anxiety. Drink coffee 2 to 3 hours after waking when cortisol levels are waning. To wake up, try a cold splash shower in the morning to raise cortisol levels, similar to a caffeine kick. Light exercise in the morning can increase mood and mental performance. + +## Sleep Hygiene + +Take a warm bath 90 minutes before sleep to promote good sleep. Avoid washing for too long to retain the body's natural oils. Try to get at least 7 to 8 hours of sleep for optimum rest. Don't exercise after 8 PM to ensure good sleep. + +## Nutrition and Digestion + +Consume foods with lots of fiber, aiming for 30g per day. Avoid highly processed foods and prefer minimally processed grains like unrefined oats over highly refined cornflakes. Fiber slows down digestion and keeps you satiated. Juices are sugary and bad for your teeth. + +## Oral Health + +Bad breath can be related to microorganisms in your mouth. Fluoride helps prevent tooth decay rather than the frequency of brushing. Use toothpaste with 1450-1500 ppm fluoride and leave it in your mouth for optimal effect. Brush gently and avoid using mouthwash for 30 minutes after brushing to prevent washing away the fluoride. Use plaque-disclosing tablets to see missed parts while brushing. + +## Hydration + +* Only drink water as much as you feel thirsty, e.g., one and a half liters daily. +* Avoid eating when stressed, as it can lead to overeating and increased hunger. + +## Exercise + +* 37 percent of the genes can influence eagerness to exercise. +* Only light exercise is recommended in the morning. +* Mood-enhancing jogging or cross-training releases more endorphins than aerobic exercise. +* Exercise is best done near meal times. + +## Productivity + +Virtual commuting can help mark the start and end of the workday. Physical tasks are better done in the afternoon. Background music can improve productivity. Taking regular breaks can help you think outside the box. Incorporating plants can improve productivity by up to 15% and reduce CO2. + +## Emotional and Social Well-being + +Engage in weekly intimacy, which can increase happiness with a partner. Trans fats are harmful, but regular fats can make food taste better. The brain influences brown fat, acting like a body oven. Hugs, even with animals, have emotional benefits and can reduce stress. + +## Intuition and Decision-Making + +Trust professional intuition only if you are familiar with the situation. The more complex the problem, the better it is to rely on gut instinct rather than overanalyzing. + +## Miscellaneous + +Watching a scary movie can amplify your feelings for another person. + +E-Mail your comments to `paul@nospam.buetow.org` :-) + +=> ../ Back to the main site -- cgit v1.2.3 From f90450069a28c6d424d159ad8d09f41fb1ec5f44 Mon Sep 17 00:00:00 2001 From: Paul Buetow Date: Fri, 21 Feb 2025 11:09:29 +0200 Subject: Update content for gemtext --- about/resources.gmi | 174 +++++++++++------------ gemfeed/atom.xml | 130 ++++++++--------- index.gmi | 2 +- notes/fluent-forever.gmi | 6 + notes/index.gmi | 2 + notes/love-people-use-things.gmi | 108 ++++++++++++++ notes/when.gmi | 3 + uptime-stats.gmi | 295 +-------------------------------------- 8 files changed, 273 insertions(+), 447 deletions(-) create mode 100644 notes/fluent-forever.gmi create mode 100644 notes/love-people-use-things.gmi diff --git a/about/resources.gmi b/about/resources.gmi index a70b80d3..cda2be87 100644 --- a/about/resources.gmi +++ b/about/resources.gmi @@ -35,101 +35,101 @@ You won't find any links on this site because, over time, the links will break. In random order: -* Java ist auch eine Insel; Christian Ullenboom; -* Hands-on Infrastructure Monitoring with Prometheus; Joel Bastos, Pedro Araujo; Packt -* Modern Perl; Chromatic ; Onyx Neon Press +* 100 Go Mistakes and How to Avoid Them; Teiva Harsanyi; Manning Publications +* The Docker Book; James Turnbull; Kindle * Systemprogrammierung in Go; Frank Müller; dpunkt -* The Go Programming Language; Alan A. A. Donovan; Addison-Wesley Professional -* Effective Java; Joshua Bloch; Addison-Wesley Professional -* Concurrency in Go; Katherine Cox-Buday; O'Reilly -* Pro Puppet; James Turnbull, Jeffrey McCune; Apress +* The Kubernetes Book; Nigel Poulton; Unabridged Audiobook +* Developing Games in Java; David Brackeen and others...; New Riders +* Perl New Features; Joshua McAdams, brian d foy; Perl School * Object-Oriented Programming with ANSI-C; Axel-Tobias Schreiner -* Think Raku (aka Think Perl 6); Laurent Rosenfeld, Allen B. Downey; O'Reilly -* The KCNA (Kubernetes and Cloud Native Associate) Book; Nigel Poulton +* DNS and BIND; Cricket Liu; O'Reilly +* Distributed Systems: Principles and Paradigms; Andrew S. Tanenbaum; Pearson +* Raku Recipes; J.J. Merelo; Apress +* Go Brain Teasers - Exercise Your Mind; Miki Tebeka; The Pragmatic Programmers +* Funktionale Programmierung; Peter Pepper; Springer +* Java ist auch eine Insel; Christian Ullenboom; +* The Go Programming Language; Alan A. A. Donovan; Addison-Wesley Professional * The DevOps Handbook; Gene Kim, Jez Humble, Patrick Debois, John Willis; Audible -* Ultimate Go Notebook; Bill Kennedy -* Higher Order Perl; Mark Dominus; Morgan Kaufmann -* Tmux 2: Productive Mouse-free Development; Brain P. Hogan; The Pragmatic Programmers -* Data Science at the Command Line; Jeroen Janssens; O'Reilly +* Programming Perl aka "The Camel Book"; Tom Christiansen, brian d foy, Larry Wall & Jon Orwant; O'Reilly * Systems Performance Tuning; Gian-Paolo D. Musumeci and others...; O'Reilly -* Effective awk programming; Arnold Robbins; O'Reilly -* The Practise of System and Network Administration; Thomas A. Limoncelli, Christina J. Hogan, Strata R. Chalup; Addison-Wesley Professional Pro Git; Scott Chacon, Ben Straub; Apress -* Learn You a Haskell for Great Good!; Miran Lipovaca; No Starch Press -* Go Brain Teasers - Exercise Your Mind; Miki Tebeka; The Pragmatic Programmers -* The Docker Book; James Turnbull; Kindle -* Amazon Web Services in Action; Michael Wittig and Andreas Wittig; Manning Publications -* Polished Ruby Programming; Jeremy Evans; Packt Publishing +* Higher Order Perl; Mark Dominus; Morgan Kaufmann +* 97 things every SRE should know; Emil Stolarsky, Jaime Woo; O'Reilly +* Site Reliability Engineering; How Google runs production systems; O'Reilly +* Effective Java; Joshua Bloch; Addison-Wesley Professional +* Leanring eBPF; Liz Rice; O'Reilly * Learn You Some Erlang for Great Good; Fred Herbert; No Starch Press -* Perl New Features; Joshua McAdams, brian d foy; Perl School * Raku Fundamentals; Moritz Lenz; Apress * DevOps And Site Reliability Engineering Handbook; Stephen Fleming; Audible -* Developing Games in Java; David Brackeen and others...; New Riders +* The Pragmatic Programmer; David Thomas; Addison-Wesley +* Ultimate Go Notebook; Bill Kennedy +* The KCNA (Kubernetes and Cloud Native Associate) Book; Nigel Poulton * Clusterbau mit Linux-HA; Michael Schwartzkopff; O'Reilly -* Programming Perl aka "The Camel Book"; Tom Christiansen, brian d foy, Larry Wall & Jon Orwant; O'Reilly +* Modern Perl; Chromatic ; Onyx Neon Press * C++ Programming Language; Bjarne Stroustrup; -* Distributed Systems: Principles and Paradigms; Andrew S. Tanenbaum; Pearson +* Concurrency in Go; Katherine Cox-Buday; O'Reilly * Terraform Cookbook; Mikael Krief; Packt Publishing -* DNS and BIND; Cricket Liu; O'Reilly -* 100 Go Mistakes and How to Avoid Them; Teiva Harsanyi; Manning Publications -* Funktionale Programmierung; Peter Pepper; Springer -* Kubernetes Cookbook; Sameer Naik, Sébastien Goasguen, Jonathan Michaux; O'Reilly -* Site Reliability Engineering; How Google runs production systems; O'Reilly -* Raku Recipes; J.J. Merelo; Apress -* 97 things every SRE should know; Emil Stolarsky, Jaime Woo; O'Reilly -* The Pragmatic Programmer; David Thomas; Addison-Wesley -* Leanring eBPF; Liz Rice; O'Reilly +* Tmux 2: Productive Mouse-free Development; Brain P. Hogan; The Pragmatic Programmers +* Effective awk programming; Arnold Robbins; O'Reilly * 21st Century C: C Tips from the New School; Ben Klemens; O'Reilly -* The Kubernetes Book; Nigel Poulton; Unabridged Audiobook +* Pro Puppet; James Turnbull, Jeffrey McCune; Apress +* Think Raku (aka Think Perl 6); Laurent Rosenfeld, Allen B. Downey; O'Reilly +* The Practise of System and Network Administration; Thomas A. Limoncelli, Christina J. Hogan, Strata R. Chalup; Addison-Wesley Professional Pro Git; Scott Chacon, Ben Straub; Apress +* Hands-on Infrastructure Monitoring with Prometheus; Joel Bastos, Pedro Araujo; Packt +* Data Science at the Command Line; Jeroen Janssens; O'Reilly +* Learn You a Haskell for Great Good!; Miran Lipovaca; No Starch Press +* Kubernetes Cookbook; Sameer Naik, Sébastien Goasguen, Jonathan Michaux; O'Reilly +* Polished Ruby Programming; Jeremy Evans; Packt Publishing +* Amazon Web Services in Action; Michael Wittig and Andreas Wittig; Manning Publications ## Technical references I didn't read them from the beginning to the end, but I am using them to look up things. The books are in random order: +* BPF Performance Tools - Linux System and Application Observability, Brendan Gregg; Addison Wesley * Understanding the Linux Kernel; Daniel P. Bovet, Marco Cesati; O'Reilly +* The Linux Programming Interface; Michael Kerrisk; No Starch Press * Implementing Service Level Objectives; Alex Hidalgo; O'Reilly * Relayd and Httpd Mastery; Michael W Lucas -* Algorithms; Robert Sedgewick, Kevin Wayne; Addison Wesley -* BPF Performance Tools - Linux System and Application Observability, Brendan Gregg; Addison Wesley * Groovy Kurz & Gut; Joerg Staudemeier; O'Reilly -* The Linux Programming Interface; Michael Kerrisk; No Starch Press +* Algorithms; Robert Sedgewick, Kevin Wayne; Addison Wesley ## Self-development and soft-skills books In random order: -* Solve for Happy; Mo Gawdat -* Deep Work; Cal Newport; Piatkus -* Who Moved My Cheese?; Dr. Spencer Johnson; Vermilion +* Psycho-Cybernetics; Maxwell Maltz; Perigee Books * The Bullet Journal Method; Ryder Carroll; Fourth Estate -* Digital Minimalism; Cal Newport; Portofolio Penguin -* 101 Essays that change the way you think; Brianna Wiest; Audible -* The Daily Stoic; Ryan Holiday, Stephen Hanselman; Profile Books -* Consciousness: A Very Short Introduction; Susan Blackmore; Oxford Uiversity Press -* Atomic Habits; James Clear; Random House Business -* Staff Engineer: Leadership beyond the management track; Will Larson; Audible -* The Phoenix Project - A Novel About IT, DevOps, and Helping your Business Win; Gene Kim and Kevin Behr; Trade Select -* Time Management for System Administrators; Thomas A. Limoncelli; O'Reilly * The Power of Now; Eckhard Tolle; Yellow Kite -* Search Inside Yourself - The Unexpected path to Achieving Success, Happiness (and World Peace); Chade-Meng Tan, Daniel Goleman, Jon Kabat-Zinn; HarperOne +* 101 Essays that change the way you think; Brianna Wiest; Audible * The Off Switch; Mark Cropley; Virgin Books -* Buddah and Einstein walk into a Bar; Guy Joseph Ale, Claire Bloom; Blackstone Publishing -* Ultralearning; Anna Laurent; Self-published via Amazon -* Stop starting, start finishing; Arne Roock; Lean-Kanban University -* The Good Enough Job; Simone Stolzoff; Ebury Edge -* So Good They Can't Ignore You; Cal Newport; Business Plus +* Eat That Frog!; Brian Tracy; Hodder Paperbacks +* Influence without Authority; A. Cohen, D. Bradford; Wiley +* Search Inside Yourself - The Unexpected path to Achieving Success, Happiness (and World Peace); Chade-Meng Tan, Daniel Goleman, Jon Kabat-Zinn; HarperOne * The Joy of Missing Out; Christina Crook; New Society Publishers -* The Complete Software Developer's Career Guide; John Sonmez; Unabridged Audiobook +* Who Moved My Cheese?; Dr. Spencer Johnson; Vermilion +* The Good Enough Job; Simone Stolzoff; Ebury Edge +* The Daily Stoic; Ryan Holiday, Stephen Hanselman; Profile Books +* Ultralearning; Scott Young; Thorsons +* Staff Engineer: Leadership beyond the management track; Will Larson; Audible +* Solve for Happy; Mo Gawdat * Soft Skills; John Sommez; Manning Publications -* Influence without Authority; A. Cohen, D. Bradford; Wiley -* Eat That Frog!; Brian Tracy; Hodder Paperbacks +* The 7 Habits Of Highly Effective People; Stephen R. Covey; Simon & Schuster UK +* Time Management for System Administrators; Thomas A. Limoncelli; O'Reilly +* Eat That Frog; Brian Tracy +* The Obstacle Is The Way; Ryan Holiday; Profile Books Ltd +* Atomic Habits; James Clear; Random House Business +* The Phoenix Project - A Novel About IT, DevOps, and Helping your Business Win; Gene Kim and Kevin Behr; Trade Select * Never Split the Difference; Chris Voss, Tahl Raz; Random House Business * Getting Things Done; David Allen +* The Complete Software Developer's Career Guide; John Sonmez; Unabridged Audiobook +* Digital Minimalism; Cal Newport; Portofolio Penguin +* Consciousness: A Very Short Introduction; Susan Blackmore; Oxford Uiversity Press +* Deep Work; Cal Newport; Piatkus +* Buddah and Einstein walk into a Bar; Guy Joseph Ale, Claire Bloom; Blackstone Publishing +* Stop starting, start finishing; Arne Roock; Lean-Kanban University +* Ultralearning; Anna Laurent; Self-published via Amazon * Slow Productivity; Cal Newport; Penguin Random House -* Ultralearning; Scott Young; Thorsons -* The Obstacle Is The Way; Ryan Holiday; Profile Books Ltd -* The 7 Habits Of Highly Effective People; Stephen R. Covey; Simon & Schuster UK -* Eat That Frog; Brian Tracy -* Psycho-Cybernetics; Maxwell Maltz; Perigee Books +* So Good They Can't Ignore You; Cal Newport; Business Plus => ../notes/index.gmi Here are notes of mine for some of the books @@ -137,22 +137,22 @@ In random order: Some of these were in-person with exams; others were online learning lectures only. In random order: -* Functional programming lecture; Remote University of Hagen +* Ultimate Go Programming; Bill Kennedy; O'Reilly Online * Developing IaC with Terraform (with Live Lessons); O'Reilly Online -* The Well-Grounded Rubyist Video Edition; David. A. Black; O'Reilly Online -* AWS Immersion Day; Amazon; 1-day interactive online training * Apache Tomcat Best Practises; 3-day on-site training -* Linux Security and Isolation APIs Training; Michael Kerrisk; 3-day on-site training +* F5 Loadbalancers Training; 2-day on-site training; F5, Inc. +* Structure and Interpretation of Computer Programs; Harold Abelson and more...; +* MySQL Deep Dive Workshop; 2-day on-site training * Scripting Vim; Damian Conway; O'Reilly Online -* The Ultimate Kubernetes Bootcamp; School of Devops; O'Reilly Online * Algorithms Video Lectures; Robert Sedgewick; O'Reilly Online -* Red Hat Certified System Administrator; Course + certification (Although I had the option, I decided not to take the next course as it is more effective to self learn what I need) -* MySQL Deep Dive Workshop; 2-day on-site training -* Structure and Interpretation of Computer Programs; Harold Abelson and more...; -* Ultimate Go Programming; Bill Kennedy; O'Reilly Online * Cloud Operations on AWS - Learn how to configure, deploy, maintain, and troubleshoot your AWS environments; 3-day online live training with labs; Amazon +* The Well-Grounded Rubyist Video Edition; David. A. Black; O'Reilly Online +* Linux Security and Isolation APIs Training; Michael Kerrisk; 3-day on-site training * Protocol buffers; O'Reilly Online -* F5 Loadbalancers Training; 2-day on-site training; F5, Inc. +* Red Hat Certified System Administrator; Course + certification (Although I had the option, I decided not to take the next course as it is more effective to self learn what I need) +* Functional programming lecture; Remote University of Hagen +* The Ultimate Kubernetes Bootcamp; School of Devops; O'Reilly Online +* AWS Immersion Day; Amazon; 1-day interactive online training ## Technical guides @@ -168,46 +168,46 @@ These are not whole books, but guides (smaller or larger) which I found very use In random order: -* Maintainable +* Hidden Brain +* BSD Now * Fork Around And Find Out -* Deep Questions with Cal Newport * Backend Banter * Dev Interrupted -* Hidden Brain -* The Changelog Podcast(s) * The Pragmatic Engineer Podcast * The ProdCast (Google SRE Podcast) -* BSD Now * Cup o' Go [Golang] +* Deep Questions with Cal Newport * Fallthrough [Golang] +* The Changelog Podcast(s) +* Maintainable ### Podcasts I liked I liked them but am not listening to them anymore. The podcasts have either "finished" (no more episodes) or I stopped listening to them due to time constraints or a shift in my interests. -* CRE: Chaosradio Express [german] -* Java Pub House -* Modern Mentor * FLOSS weekly +* CRE: Chaosradio Express [german] * Ship It (predecessor of Fork Around And Find Out) +* Modern Mentor +* Java Pub House * Go Time (predecessor of fallthrough) ## Newsletters I like This is a mix of tech and non-tech newsletters I am subscribed to. In random order: -* VK Newsletter -* The Pragmatic Engineer * Andreas Brandhorst Newsletter (Sci-Fi author) -* The Imperfectionist -* byteSizeGo -* Golang Weekly -* Monospace Mentor -* Changelog News * Applied Go Weekly Newsletter +* byteSizeGo * Register Spill +* The Pragmatic Engineer * Ruby Weekly +* Golang Weekly +* VK Newsletter * The Valuable Dev +* Changelog News +* Monospace Mentor +* The Imperfectionist # Formal education diff --git a/gemfeed/atom.xml b/gemfeed/atom.xml index 7f86085a..69b4940b 100644 --- a/gemfeed/atom.xml +++ b/gemfeed/atom.xml @@ -1,6 +1,6 @@ - 2025-02-13T10:21:17+02:00 + 2025-02-21T11:07:08+02:00 foo.zone feed To be in the .zone! @@ -1289,33 +1289,33 @@ Jan 26 17:36:32 f2 apcupsd[2159]: apcupsd shutdown succeeded by Lorenzo Bettini http://www.lorenzobettini.it http://www.gnu.org/software/src-highlite --> -
export EDITOR=hx
-export VISUAL=$EDITOR
-export GIT_EDITOR=$EDITOR
-export HELIX_CONFIG_DIR=$HOME/.config/helix
-
-editor::helix::random_theme () {
-    # May add more theme search paths based on OS. This one is
-    # for Fedora Linux, but there is also MacOS, etc.
-    local -r theme_dir=/usr/share/helix/runtime/themes
-    if [ ! -d $theme_dir ]; then
-        echo "Helix theme dir $theme_dir doesnt exist"
-        return 1
-    fi
-
-    local -r config_file=$HELIX_CONFIG_DIR/config.toml
-    local -r random_theme="$(basename "$(ls $theme_dir \
-        | grep -v random.toml | grep .toml | sort -R \
-        | head -n 1)" | cut -d. -f1)"
-
-    sed "/^theme =/ { s/.*/theme = \"$random_theme\"/; }" \
-        $config_file > $config_file.tmp && 
-        mv $config_file.tmp $config_file
-}
-
-if [ -f $HELIX_CONFIG_DIR/config.toml ]; then
-    editor::helix::random_theme
-fi
+
export EDITOR=hx
+export VISUAL=$EDITOR
+export GIT_EDITOR=$EDITOR
+export HELIX_CONFIG_DIR=$HOME/.config/helix
+
+editor::helix::random_theme () {
+    # May add more theme search paths based on OS. This one is
+    # for Fedora Linux, but there is also MacOS, etc.
+    local -r theme_dir=/usr/share/helix/runtime/themes
+    if [ ! -d $theme_dir ]; then
+        echo "Helix theme dir $theme_dir doesnt exist"
+        return 1
+    fi
+
+    local -r config_file=$HELIX_CONFIG_DIR/config.toml
+    local -r random_theme="$(basename "$(ls $theme_dir \
+        | grep -v random.toml | grep .toml | sort -R \
+        | head -n 1)" | cut -d. -f1)"
+
+    sed "/^theme =/ { s/.*/theme = \"$random_theme\"/; }" \
+        $config_file > $config_file.tmp && 
+        mv $config_file.tmp $config_file
+}
+
+if [ -f $HELIX_CONFIG_DIR/config.toml ]; then
+    editor::helix::random_theme
+fi
 

 

 So every time I open a new terminal or shell, editor::helix::random_theme gets called, which randomly selects a theme from all installed ones and updates the helix config accordingly.

@@ -1324,16 +1324,16 @@ http://www.gnu.org/software/src-highlite -->
 by Lorenzo Bettini
 http://www.lorenzobettini.it
 http://www.gnu.org/software/src-highlite -->
-
[paul@earth] ~ % editor::helix::random_theme
-[paul@earth] ~ % head -n 1 ~/.config/helix/config.toml
-theme = "jellybeans"
-[paul@earth] ~ % editor::helix::random_theme
-[paul@earth] ~ % head -n 1 ~/.config/helix/config.toml
-theme = "rose_pine"
-[paul@earth] ~ % editor::helix::random_theme
-[paul@earth] ~ % head -n 1 ~/.config/helix/config.toml
-theme = "noctis"
-[paul@earth] ~ %
+
[paul@earth] ~ % editor::helix::random_theme
+[paul@earth] ~ % head -n 1 ~/.config/helix/config.toml
+theme = "jellybeans"
+[paul@earth] ~ % editor::helix::random_theme
+[paul@earth] ~ % head -n 1 ~/.config/helix/config.toml
+theme = "rose_pine"
+[paul@earth] ~ % editor::helix::random_theme
+[paul@earth] ~ % head -n 1 ~/.config/helix/config.toml
+theme = "noctis"
+[paul@earth] ~ %
 

 

 
A better version


@@ -1344,33 +1344,33 @@ http://www.gnu.org/software/src-highlite -->
 by Lorenzo Bettini
 http://www.lorenzobettini.it
 http://www.gnu.org/software/src-highlite -->
-
export EDITOR=hx
-export VISUAL=$EDITOR
-export GIT_EDITOR=$EDITOR
-export HELIX_CONFIG_DIR=$HOME/.config/helix
-
-editor::helix::theme::get_random () {
-    for dir in $(hx --health \
-        | awk '/^Runtime directories/ { print $3 }' | tr ';' ' '); do
-        if [ -d $dir/themes ]; then
-            ls $dir/themes
-        fi
-    done | grep -F .toml | sort -R | head -n 1 | cut -d. -f1
-}
-
-editor::helix::theme::set () {
-    local -r theme="$1"; shift
-
-    local -r config_file=$HELIX_CONFIG_DIR/config.toml
-
-    sed "/^theme =/ { s/.*/theme = \"$theme\"/; }" \
-        $config_file > $config_file.tmp && 
-        mv $config_file.tmp $config_file
-}
-
-if [ -f $HELIX_CONFIG_DIR/config.toml ]; then
-    editor::helix::theme::set $(editor::helix::theme::get_random)
-fi
+
export EDITOR=hx
+export VISUAL=$EDITOR
+export GIT_EDITOR=$EDITOR
+export HELIX_CONFIG_DIR=$HOME/.config/helix
+
+editor::helix::theme::get_random () {
+    for dir in $(hx --health \
+        | awk '/^Runtime directories/ { print $3 }' | tr ';' ' '); do
+        if [ -d $dir/themes ]; then
+            ls $dir/themes
+        fi
+    done | grep -F .toml | sort -R | head -n 1 | cut -d. -f1
+}
+
+editor::helix::theme::set () {
+    local -r theme="$1"; shift
+
+    local -r config_file=$HELIX_CONFIG_DIR/config.toml
+
+    sed "/^theme =/ { s/.*/theme = \"$theme\"/; }" \
+        $config_file > $config_file.tmp && 
+        mv $config_file.tmp $config_file
+}
+
+if [ -f $HELIX_CONFIG_DIR/config.toml ]; then
+    editor::helix::theme::set $(editor::helix::theme::get_random)
+fi
 

 

 I hope you had some fun. E-Mail your comments to paul@nospam.buetow.org :-)

diff --git a/index.gmi b/index.gmi
index 3de12a6b..6af7e9f9 100644
--- a/index.gmi
+++ b/index.gmi
@@ -1,6 +1,6 @@
 # foo.zone
 
-> This site was generated at 2025-02-16T11:18:30+02:00 by `Gemtexter`
+> This site was generated at 2025-02-21T11:07:02+02:00 by `Gemtexter`
 
 Welcome to the foo.zone. Everything you read on this site is my personal opinion and experience. You can call me a Linux/*BSD enthusiast and hobbyist. I mainly write about tech, IT, programming and sometimes also about self-improvement here. And I also like coding.
 
diff --git a/notes/fluent-forever.gmi b/notes/fluent-forever.gmi
new file mode 100644
index 00000000..b053c9a8
--- /dev/null
+++ b/notes/fluent-forever.gmi
@@ -0,0 +1,6 @@
+These are my personal book notes from Gabriel Wyner's "Fluent Forever: How to learn any Language fast and never forget it" They are for myself, but I hope they might be useful to you too.
+
+
+E-Mail your comments to `paul@nospam.buetow.org` :-)
+
+=> ../ Back to the main site
diff --git a/notes/index.gmi b/notes/index.gmi
index d6666d2c..4ad174ec 100644
--- a/notes/index.gmi
+++ b/notes/index.gmi
@@ -4,6 +4,7 @@
 
 => ./when.gmi 'When: The Scientific Secrets of Perfect Timing' book notes
 => ./the-stoic-challenge.gmi 'The Stoic Challenge' book notes
+=> ./the-science-of-living.gmi 'Science of Living' book notes
 => ./the-pragmatic-programmer.gmi 'The Pragmatic Programmer' book notes
 => ./the-power-of-neuroplasticity.gmi 'The Power of Neuroplasticity' book notes
 => ./the-obstacle-is-the-way.gmi 'The Obstacle is the Way' book notes
@@ -13,6 +14,7 @@
 => ./never-split-the-difference.gmi 'Never split the difference' book notes
 => ./mind-management.gmi 'Mind Management' book notes
 => ./mental-combat.gmi 'Mental Combat' book notes
+=> ./love-people-use-things.gmi Love People, Use Things
 => ./joy-on-demand.gmi 'Joy On Domand' book notes
 => ./influence-wihout-authority.gmi 'Influence without Authority' book notes
 => ./eat-that-frog.gmi 'Eat That Frog' book notes
diff --git a/notes/love-people-use-things.gmi b/notes/love-people-use-things.gmi
new file mode 100644
index 00000000..6c1191fb
--- /dev/null
+++ b/notes/love-people-use-things.gmi
@@ -0,0 +1,108 @@
+# Love People, Use Things
+
+These are my personal book notes from "The Minimalist"'s "Love People, Use Things" They are for myself, but I hope they might be useful to you too.
+
+## The Pursuit of Minimalism and Meaning
+
+Love people and use things. Ask yourself, "Does this item serve a purpose in my life? Or does it spark joy?" People often believe that possessing item A will bring everlasting happiness. However, after obtaining item A, a new desire for the next item emerges. Happiness from these possessions is fleeting as you return to your baseline mood. 
+
+* Be careful with accumulating items, as they require maintenance: replacing or charging batteries, software updates, fixing, cleaning, etc.
+* Owning more reduces time for what truly matters. 
+
+### Sentimental Items
+
+* For sentimental items you don't use, consider taking a photo or video and then discarding them.
+* Pursue happiness by seeking freedom, not possessions. True freedom is elusive and immeasurable.
+
+### Advertising and Services
+
+* Free services bombard you with advertisements; it's better to pay for services where creators, not advertisement companies, hold influence.
+* Spending on services makes your choices intentional. Time is your most valuable currency, so spend it wisely.
+* Reach a state of "enough" in possessions. While more is always possible, ensure there is "enough."
+
+### Financial Considerations
+
+When purchasing something new, consider:
+1. Can you afford it, both financially and mentally?
+2. Does it serve a meaningful purpose? Does it truly improve your life?
+
+* Consider the hidden costs: storage, maintenance, psychological strain.
+
+### Decluttering Tips
+
+* Avoid bringing unnecessary items into your space.
+* Limit "just in case" items; you may never need them. Focus on emergency items only within reason.
+* "When" items—things you'll definitely use—are acceptable (e.g., stock of toilet paper, toothpaste, or whiskey if you enjoy it).
+
+### Categorizing Possessions
+
+Everything fits into three categories:
+
+* Essentials
+* Non-essentials
+* Junk
+
+## Embracing Truth and Overcoming Fear
+
+Truth is preferable to lies, though it can be uncomfortable, facilitating the prevalence of dishonesty. Simplify life to expose the truth, stripping away its hiding places.
+
+* Manufactured fears inhibit pursuing personal desires. Fear often keeps us holding onto things "just in case."
+* Ask yourself, "What am I afraid of?" The answer is often irrational or rooted in manufactured fears.
+
+### Health and Well-being
+
+* The best medicine is free: good food, sleep, exercise, sunshine, and stress reduction. Avoid unnecessary medication.
+* If stagnant, try diverse, unconventional methods. Failure is likely, but experimentation is vital.
+
+### Managing Stress
+
+* Identify major stressors and address them. 
+* Resist the fear of missing out; prioritize current focus over FOMO.
+* True power lies in maintaining focus.
+
+* Each item you own must either serve a purpose or bring lasting joy.
+
+### The 90-90 Rule
+
+* If you haven't used an item in the last 90 days and won't use it in the next 90, let it go. This covers both seasonal changes.
+
+## Core Values
+
+* Health: Without it, nothing else matters, not even possessions.
+* Relationships: Share your life with someone.
+* Passion, Fulfillment, and Creativity
+* Intentional Growth: If not growing, you're decaying.
+* Constructive Contribution
+
+* Index funds outperform gold.
+* Technology can transform people into unthinking "zombies."
+* Embrace digital minimalism, shifting from constant doing to simply being.
+
+## Practical Minimalism
+
+"Don't Upgrade" Rule:
+
+* Advertising invests millions in inciting desire. Counter this by questioning each upgrade. Once something breaks, decide to leave it, fix, or replace it only if necessary.
+* Consider downgrading if it significantly enriches your life.
+* Use time for writing, reading, or exercising.
+
+## Imperfection and Creativity
+
+* Avoid letting perfect be the enemy of good. "Good enough" is the new perfect.
+* Continuous slow progress is key. Perfectionism should not stifle creativity.
+* All work, even by professionals, has imperfections.
+
+## Attitude Towards Possessions
+
+* Appreciate someone else's joy to eliminate jealousy.
+* Don't cling to items; be prepared to abandon them swiftly. Detachment offers flexibility, crucial for self-care.
+
+## Home and Possessions
+
+* An expensive watch doesn't grant more time. Keep only what adds genuine value.
+* Prioritize high-quality, enduring items. Though initially costly, they save money and time for meaningful activities.
+* A minimalistic home can include a reminder of life's absurdities, emphasizing substance over material extravagance.
+
+E-Mail your comments to `paul@nospam.buetow.org` :-)
+
+=> ../ Back to the main site
diff --git a/notes/when.gmi b/notes/when.gmi
index 3bfad7b4..4dc50412 100644
--- a/notes/when.gmi
+++ b/notes/when.gmi
@@ -81,6 +81,9 @@ Life satisfaction tends to dip in midlife, around the forties, but increases aro
 
 These insights from "When" can guide actions to optimize performance, well-being, and satisfaction across various aspects of life.
 
+Other book notes of mine are:
+
+
 E-Mail your comments to `paul@nospam.buetow.org` :-)
 
 => ../ Back to the main site
diff --git a/uptime-stats.gmi b/uptime-stats.gmi
index 3461981d..c71995c6 100644
--- a/uptime-stats.gmi
+++ b/uptime-stats.gmi
@@ -1,6 +1,6 @@
 # My machine uptime stats
 
-> This site was last updated at 2025-02-16T11:18:30+02:00
+> This site was last updated at 2025-02-21T11:07:08+02:00
 
 The following stats were collected via `uptimed` on all of my personal computers over many years and the output was generated by `guprecords`, the global uptime records stats analyser of mine.
 
@@ -13,296 +13,3 @@ Also check out my blog post:
 
 => ./gemfeed/2023-05-01-unveiling-guprecords:-uptime-records-with-raku.gmi Unveiling `guprecords.raku`: Uptime records with Raku
 
-## Top 20 Boots's by Host
-
-Boots is the total number of host boots over the entire lifespan.
-
-```
-+-----+----------------+-------+
-| Pos |           Host | Boots |
-+-----+----------------+-------+
-|  1. |  alphacentauri |   671 |
-|  2. |           mars |   207 |
-|  3. |         *earth |   168 |
-|  4. |       callisto |   153 |
-|  5. |       dionysus |   136 |
-|  6. |      tauceti-e |   120 |
-|  7. |      *makemake |    61 |
-|  8. |        *uranus |    59 |
-|  9. |          pluto |    51 |
-| 10. |      mega15289 |    50 |
-| 11. |          *t450 |    43 |
-| 12. |    *fishfinger |    42 |
-| 13. |       mega8477 |    40 |
-| 14. |         phobos |    40 |
-| 15. |            sun |    33 |
-| 16. |      *blowfish |    33 |
-| 17. |   *mega-m3-pro |    29 |
-| 18. |           moon |    20 |
-| 19. |         vulcan |    19 |
-| 20. |        tauceti |    16 |
-+-----+----------------+-------+
-```
-
-## Top 20 Uptime's by Host
-
-Uptime is the total uptime of a host over the entire lifespan.
-
-```
-+-----+----------------+-----------------------------+
-| Pos |           Host |                      Uptime |
-+-----+----------------+-----------------------------+
-|  1. |         vulcan |   4 years, 5 months, 6 days |
-|  2. |            sun |  3 years, 9 months, 26 days |
-|  3. |        *uranus |   3 years, 9 months, 5 days |
-|  4. |          uugrn |   3 years, 5 months, 5 days |
-|  5. |      *blowfish |   3 years, 2 months, 4 days |
-|  6. |         *earth |  3 years, 1 months, 26 days |
-|  7. |      deltavega |  3 years, 1 months, 21 days |
-|  8. |          pluto | 2 years, 10 months, 29 days |
-|  9. |    *fishfinger |   2 years, 6 months, 2 days |
-| 10. |        tauceti |  2 years, 3 months, 19 days |
-| 11. |      mega15289 | 1 years, 12 months, 17 days |
-| 12. |      tauceti-f |  1 years, 9 months, 18 days |
-| 13. |       mega8477 |  1 years, 3 months, 25 days |
-| 14. |          host0 |   1 years, 3 months, 9 days |
-| 15. |      *makemake |  1 years, 2 months, 23 days |
-| 16. |      tauceti-e |  1 years, 2 months, 20 days |
-| 17. |          *t450 |  1 years, 1 months, 17 days |
-| 18. |       callisto | 0 years, 10 months, 31 days |
-| 19. |  alphacentauri | 0 years, 10 months, 28 days |
-| 20. |       babylon5 |  0 years, 9 months, 25 days |
-+-----+----------------+-----------------------------+
-```
-
-## Top 20 Score's by Host
-
-Score is calculated by combining all other metrics.
-
-```
-+-----+----------------+-------+
-| Pos |           Host | Score |
-+-----+----------------+-------+
-|  1. |        *uranus |   338 |
-|  2. |         vulcan |   275 |
-|  3. |            sun |   238 |
-|  4. |         *earth |   217 |
-|  5. |          uugrn |   211 |
-|  6. |  alphacentauri |   201 |
-|  7. |      *blowfish |   200 |
-|  8. |      deltavega |   193 |
-|  9. |          pluto |   182 |
-| 10. |    *fishfinger |   158 |
-| 11. |       dionysus |   156 |
-| 12. |      mega15289 |   147 |
-| 13. |        tauceti |   141 |
-| 14. |      *makemake |   122 |
-| 15. |      tauceti-f |   108 |
-| 16. |      tauceti-e |    96 |
-| 17. |          *t450 |    89 |
-| 18. |       callisto |    86 |
-| 19. |       mega8477 |    80 |
-| 20. |          host0 |    76 |
-+-----+----------------+-------+
-```
-
-## Top 20 Downtime's by Host
-
-Downtime is the total downtime of a host over the entire lifespan.
-
-```
-+-----+----------------+-----------------------------+
-| Pos |           Host |                    Downtime |
-+-----+----------------+-----------------------------+
-|  1. |       dionysus |  8 years, 3 months, 16 days |
-|  2. |        *uranus |  6 years, 4 months, 15 days |
-|  3. |  alphacentauri | 5 years, 11 months, 18 days |
-|  4. |      *makemake |   2 years, 9 months, 6 days |
-|  5. |           moon |   2 years, 1 months, 1 days |
-|  6. |       callisto |  1 years, 5 months, 15 days |
-|  7. |      mega15289 |  1 years, 4 months, 24 days |
-|  8. |          *t450 |  1 years, 2 months, 13 days |
-|  9. |           mars |  1 years, 2 months, 10 days |
-| 10. |      tauceti-e |  0 years, 12 months, 9 days |
-| 11. |         sirius |  0 years, 8 months, 20 days |
-| 12. |         *earth |  0 years, 6 months, 14 days |
-| 13. |         deimos |  0 years, 5 months, 15 days |
-| 14. |            *f2 |   0 years, 2 months, 9 days |
-| 15. |        joghurt |   0 years, 2 months, 9 days |
-| 16. |            *f0 |   0 years, 2 months, 8 days |
-| 17. |            *f1 |   0 years, 2 months, 8 days |
-| 18. |          host0 |   0 years, 2 months, 1 days |
-| 19. |      fibonacci |  0 years, 1 months, 11 days |
-| 20. |          cobol |   0 years, 1 months, 8 days |
-+-----+----------------+-----------------------------+
-```
-
-## Top 20 Lifespan's by Host
-
-Lifespan is the total uptime + the total downtime of a host.
-
-```
-+-----+----------------+-----------------------------+
-| Pos |           Host |                    Lifespan |
-+-----+----------------+-----------------------------+
-|  1. |        *uranus | 9 years, 12 months, 20 days |
-|  2. |       dionysus |  8 years, 6 months, 17 days |
-|  3. |  alphacentauri |  6 years, 9 months, 13 days |
-|  4. |         vulcan |   4 years, 5 months, 6 days |
-|  5. |      *makemake | 3 years, 10 months, 30 days |
-|  6. |            sun |  3 years, 10 months, 2 days |
-|  7. |         *earth |  3 years, 7 months, 10 days |
-|  8. |          uugrn |   3 years, 5 months, 5 days |
-|  9. |      mega15289 |   3 years, 4 months, 9 days |
-| 10. |      *blowfish |   3 years, 2 months, 5 days |
-| 11. |      deltavega |  3 years, 1 months, 21 days |
-| 12. |          pluto | 2 years, 10 months, 30 days |
-| 13. |    *fishfinger |   2 years, 6 months, 4 days |
-| 14. |           moon |  2 years, 4 months, 25 days |
-| 15. |        tauceti |  2 years, 3 months, 22 days |
-| 16. |       callisto |  2 years, 3 months, 13 days |
-| 17. |          *t450 |  2 years, 2 months, 29 days |
-| 18. |      tauceti-e |  2 years, 1 months, 29 days |
-| 19. |      tauceti-f |  1 years, 9 months, 20 days |
-| 20. |           mars |  1 years, 8 months, 19 days |
-+-----+----------------+-----------------------------+
-```
-
-## Top 20 Boots's by KernelMajor
-
-Boots is the total number of host boots over the entire lifespan.
-
-```
-+-----+----------------+-------+
-| Pos |    KernelMajor | Boots |
-+-----+----------------+-------+
-|  1. |  FreeBSD 10... |   551 |
-|  2. |     Linux 3... |   550 |
-|  3. |     Linux 5... |   162 |
-|  4. |     Linux 4... |   161 |
-|  5. |  FreeBSD 11... |   153 |
-|  6. |    *Linux 6... |   134 |
-|  7. |  FreeBSD 13... |   116 |
-|  8. |  *OpenBSD 7... |    85 |
-|  9. |   Darwin 13... |    40 |
-| 10. | *FreeBSD 14... |    38 |
-| 11. |  *Darwin 23... |    33 |
-| 12. |   FreeBSD 5... |    25 |
-| 13. |     Linux 2... |    22 |
-| 14. |   Darwin 21... |    17 |
-| 15. |   Darwin 15... |    15 |
-| 16. |   Darwin 22... |    12 |
-| 17. |   Darwin 18... |    11 |
-| 18. |   OpenBSD 4... |    10 |
-| 19. |   FreeBSD 7... |    10 |
-| 20. |   FreeBSD 6... |    10 |
-+-----+----------------+-------+
-```
-
-## Top 20 Uptime's by KernelMajor
-
-Uptime is the total uptime of a host over the entire lifespan.
-
-```
-+-----+----------------+------------------------------+
-| Pos |    KernelMajor |                       Uptime |
-+-----+----------------+------------------------------+
-|  1. |     Linux 3... | 15 years, 10 months, 25 days |
-|  2. |  *OpenBSD 7... |    6 years, 3 months, 6 days |
-|  3. |  FreeBSD 10... |    5 years, 9 months, 9 days |
-|  4. |     Linux 5... |  4 years, 10 months, 21 days |
-|  5. |     Linux 4... |   2 years, 7 months, 22 days |
-|  6. |  FreeBSD 11... |   2 years, 4 months, 28 days |
-|  7. |    *Linux 6... |   2 years, 4 months, 15 days |
-|  8. |     Linux 2... |  1 years, 11 months, 21 days |
-|  9. |   Darwin 13... |   1 years, 3 months, 25 days |
-| 10. |   FreeBSD 6... |    1 years, 3 months, 9 days |
-| 11. | *FreeBSD 14... |   1 years, 1 months, 17 days |
-| 12. |  *Darwin 23... |   0 years, 11 months, 9 days |
-| 13. |   OpenBSD 4... |   0 years, 8 months, 12 days |
-| 14. |   Darwin 21... |    0 years, 8 months, 2 days |
-| 15. |   Darwin 18... |    0 years, 7 months, 5 days |
-| 16. |   Darwin 22... |   0 years, 6 months, 22 days |
-| 17. |   Darwin 15... |   0 years, 6 months, 15 days |
-| 18. |   FreeBSD 5... |   0 years, 5 months, 18 days |
-| 19. |  FreeBSD 13... |    0 years, 4 months, 2 days |
-| 20. |   Darwin 20... |    0 years, 3 months, 7 days |
-+-----+----------------+------------------------------+
-```
-
-## Top 20 Score's by KernelMajor
-
-Score is calculated by combining all other metrics.
-
-```
-+-----+----------------+-------+
-| Pos |    KernelMajor | Score |
-+-----+----------------+-------+
-|  1. |     Linux 3... |  1045 |
-|  2. |  FreeBSD 10... |   406 |
-|  3. |  *OpenBSD 7... |   399 |
-|  4. |     Linux 5... |   317 |
-|  5. |     Linux 4... |   175 |
-|  6. |  FreeBSD 11... |   159 |
-|  7. |    *Linux 6... |   158 |
-|  8. |     Linux 2... |   121 |
-|  9. |   Darwin 13... |    80 |
-| 10. |   FreeBSD 6... |    75 |
-| 11. | *FreeBSD 14... |    71 |
-| 12. |  *Darwin 23... |    59 |
-| 13. |   OpenBSD 4... |    39 |
-| 14. |   Darwin 21... |    38 |
-| 15. |   Darwin 18... |    32 |
-| 16. |   Darwin 22... |    30 |
-| 17. |   Darwin 15... |    29 |
-| 18. |  FreeBSD 13... |    25 |
-| 19. |   FreeBSD 5... |    25 |
-| 20. |   Darwin 20... |    11 |
-+-----+----------------+-------+
-```
-
-## Top 20 Boots's by KernelName
-
-Boots is the total number of host boots over the entire lifespan.
-
-```
-+-----+------------+-------+
-| Pos | KernelName | Boots |
-+-----+------------+-------+
-|  1. |     *Linux |  1029 |
-|  2. |   *FreeBSD |   903 |
-|  3. |    *Darwin |   134 |
-|  4. |   *OpenBSD |    95 |
-+-----+------------+-------+
-```
-
-## Top 20 Uptime's by KernelName
-
-Uptime is the total uptime of a host over the entire lifespan.
-
-```
-+-----+------------+------------------------------+
-| Pos | KernelName |                       Uptime |
-+-----+------------+------------------------------+
-|  1. |     *Linux |   27 years, 5 months, 8 days |
-|  2. |   *FreeBSD | 10 years, 12 months, 19 days |
-|  3. |   *OpenBSD |  6 years, 10 months, 15 days |
-|  4. |    *Darwin |   4 years, 4 months, 20 days |
-+-----+------------+------------------------------+
-```
-
-## Top 20 Score's by KernelName
-
-Score is calculated by combining all other metrics.
-
-```
-+-----+------------+-------+
-| Pos | KernelName | Score |
-+-----+------------+-------+
-|  1. |     *Linux |  1817 |
-|  2. |   *FreeBSD |   772 |
-|  3. |   *OpenBSD |   439 |
-|  4. |    *Darwin |   285 |
-+-----+------------+-------+
-```
-
-- 
cgit v1.2.3


From 5e092ac80ee333ef9a98d197f397e6c16a53534e Mon Sep 17 00:00:00 2001
From: Paul Buetow 
Date: Fri, 21 Feb 2025 11:15:38 +0200
Subject: Update content for gemtext

---
 about/resources.gmi              |  178 +++---
 gemfeed/atom.xml.tmp             | 1265 ++++++++++++++++++++++++++++++++++++++
 index.gmi                        |    2 +-
 notes/fluent-forever.gmi         |   74 +++
 notes/index.gmi                  |    3 +-
 notes/love-people-use-things.gmi |    2 +-
 uptime-stats.gmi                 |    2 +-
 7 files changed, 1433 insertions(+), 93 deletions(-)
 create mode 100644 gemfeed/atom.xml.tmp

diff --git a/about/resources.gmi b/about/resources.gmi
index cda2be87..8e3a0a1c 100644
--- a/about/resources.gmi
+++ b/about/resources.gmi
@@ -35,101 +35,101 @@ You won't find any links on this site because, over time, the links will break.
 
 In random order:
 
+* The KCNA (Kubernetes and Cloud Native Associate) Book; Nigel Poulton
+* C++ Programming Language; Bjarne Stroustrup;
+* Learn You a Haskell for Great Good!; Miran Lipovaca; No Starch Press
+* 21st Century C: C Tips from the New School; Ben Klemens; O'Reilly
+* Leanring eBPF; Liz Rice; O'Reilly
 * 100 Go Mistakes and How to Avoid Them; Teiva Harsanyi; Manning Publications
-* The Docker Book; James Turnbull; Kindle
-* Systemprogrammierung in Go; Frank Müller; dpunkt
-* The Kubernetes Book; Nigel Poulton; Unabridged Audiobook
-* Developing Games in Java; David Brackeen and others...; New Riders
-* Perl New Features; Joshua McAdams, brian d foy; Perl School
-* Object-Oriented Programming with ANSI-C; Axel-Tobias Schreiner
-* DNS and BIND; Cricket Liu; O'Reilly
-* Distributed Systems: Principles and Paradigms; Andrew S. Tanenbaum; Pearson
 * Raku Recipes; J.J. Merelo; Apress
+* The DevOps Handbook; Gene Kim, Jez Humble, Patrick Debois, John Willis; Audible
 * Go Brain Teasers - Exercise Your Mind; Miki Tebeka; The Pragmatic Programmers
-* Funktionale Programmierung; Peter Pepper; Springer
-* Java ist auch eine Insel; Christian Ullenboom; 
+* DNS and BIND; Cricket Liu; O'Reilly
+* Effective awk programming; Arnold Robbins; O'Reilly
 * The Go Programming Language; Alan A. A. Donovan; Addison-Wesley Professional
-* The DevOps Handbook; Gene Kim, Jez Humble, Patrick Debois, John Willis; Audible
-* Programming Perl aka "The Camel Book"; Tom Christiansen, brian d foy, Larry Wall & Jon Orwant; O'Reilly
-* Systems Performance Tuning; Gian-Paolo D. Musumeci and others...; O'Reilly
-* Higher Order Perl; Mark Dominus; Morgan Kaufmann
-* 97 things every SRE should know; Emil Stolarsky, Jaime Woo; O'Reilly
-* Site Reliability Engineering; How Google runs production systems; O'Reilly
-* Effective Java; Joshua Bloch; Addison-Wesley Professional
-* Leanring eBPF; Liz Rice; O'Reilly
-* Learn You Some Erlang for Great Good; Fred Herbert; No Starch Press
-* Raku Fundamentals; Moritz Lenz; Apress
 * DevOps And Site Reliability Engineering Handbook; Stephen Fleming; Audible
+* Pro Puppet; James Turnbull, Jeffrey McCune; Apress
+* The Kubernetes Book; Nigel Poulton; Unabridged Audiobook
 * The Pragmatic Programmer; David Thomas; Addison-Wesley
-* Ultimate Go Notebook; Bill Kennedy
-* The KCNA (Kubernetes and Cloud Native Associate) Book; Nigel Poulton
-* Clusterbau mit Linux-HA; Michael Schwartzkopff; O'Reilly
-* Modern Perl; Chromatic ; Onyx Neon Press
-* C++ Programming Language; Bjarne Stroustrup;
-* Concurrency in Go; Katherine Cox-Buday; O'Reilly
-* Terraform Cookbook; Mikael Krief; Packt Publishing
+* Site Reliability Engineering; How Google runs production systems; O'Reilly
+* Kubernetes Cookbook; Sameer Naik, Sébastien Goasguen, Jonathan Michaux; O'Reilly
+* Higher Order Perl; Mark Dominus; Morgan Kaufmann
+* Hands-on Infrastructure Monitoring with Prometheus; Joel Bastos, Pedro Araujo; Packt 
+* Learn You Some Erlang for Great Good; Fred Herbert; No Starch Press
+* Object-Oriented Programming with ANSI-C; Axel-Tobias Schreiner
+* Polished Ruby Programming; Jeremy Evans; Packt Publishing
+* Amazon Web Services in Action; Michael Wittig and Andreas Wittig; Manning Publications
+* Effective Java; Joshua Bloch; Addison-Wesley Professional
+* 97 things every SRE should know; Emil Stolarsky, Jaime Woo; O'Reilly
+* Systems Performance Tuning; Gian-Paolo D. Musumeci and others...; O'Reilly
+* Developing Games in Java; David Brackeen and others...; New Riders
+* Systemprogrammierung in Go; Frank Müller; dpunkt
+* Programming Perl aka "The Camel Book"; Tom Christiansen, brian d foy, Larry Wall & Jon Orwant; O'Reilly
 * Tmux 2: Productive Mouse-free Development; Brain P. Hogan; The Pragmatic Programmers 
-* Effective awk programming; Arnold Robbins; O'Reilly
-* 21st Century C: C Tips from the New School; Ben Klemens; O'Reilly
-* Pro Puppet; James Turnbull, Jeffrey McCune; Apress
+* Distributed Systems: Principles and Paradigms; Andrew S. Tanenbaum; Pearson
+* Concurrency in Go; Katherine Cox-Buday; O'Reilly
+* Modern Perl; Chromatic ; Onyx Neon Press
+* Ultimate Go Notebook; Bill Kennedy
 * Think Raku (aka Think Perl 6); Laurent Rosenfeld, Allen B. Downey; O'Reilly
+* Funktionale Programmierung; Peter Pepper; Springer
 * The Practise of System and Network Administration; Thomas A. Limoncelli, Christina J. Hogan, Strata R. Chalup; Addison-Wesley Professional Pro Git; Scott Chacon, Ben Straub; Apress
-* Hands-on Infrastructure Monitoring with Prometheus; Joel Bastos, Pedro Araujo; Packt 
+* The Docker Book; James Turnbull; Kindle
+* Java ist auch eine Insel; Christian Ullenboom; 
+* Clusterbau mit Linux-HA; Michael Schwartzkopff; O'Reilly
+* Raku Fundamentals; Moritz Lenz; Apress
+* Perl New Features; Joshua McAdams, brian d foy; Perl School
+* Terraform Cookbook; Mikael Krief; Packt Publishing
 * Data Science at the Command Line; Jeroen Janssens; O'Reilly
-* Learn You a Haskell for Great Good!; Miran Lipovaca; No Starch Press
-* Kubernetes Cookbook; Sameer Naik, Sébastien Goasguen, Jonathan Michaux; O'Reilly
-* Polished Ruby Programming; Jeremy Evans; Packt Publishing
-* Amazon Web Services in Action; Michael Wittig and Andreas Wittig; Manning Publications
 
 ## Technical references
 
 I didn't read them from the beginning to the end, but I am using them to look up things. The books are in random order:
 
+* Relayd and Httpd Mastery; Michael W Lucas
 * BPF Performance Tools - Linux System and Application Observability, Brendan Gregg; Addison Wesley
-* Understanding the Linux Kernel; Daniel P. Bovet, Marco Cesati; O'Reilly
 * The Linux Programming Interface; Michael Kerrisk; No Starch Press 
-* Implementing Service Level Objectives; Alex Hidalgo; O'Reilly
-* Relayd and Httpd Mastery; Michael W Lucas
-* Groovy Kurz & Gut; Joerg Staudemeier; O'Reilly
+* Understanding the Linux Kernel; Daniel P. Bovet, Marco Cesati; O'Reilly
 * Algorithms; Robert Sedgewick, Kevin Wayne; Addison Wesley
+* Groovy Kurz & Gut; Joerg Staudemeier; O'Reilly
+* Implementing Service Level Objectives; Alex Hidalgo; O'Reilly
 
 ## Self-development and soft-skills books
 
 In random order:
 
-* Psycho-Cybernetics; Maxwell Maltz; Perigee Books
-* The Bullet Journal Method; Ryder Carroll; Fourth Estate
-* The Power of Now; Eckhard Tolle; Yellow Kite
-* 101 Essays that change the way you think; Brianna Wiest; Audible
-* The Off Switch; Mark Cropley; Virgin Books
-* Eat That Frog!; Brian Tracy; Hodder Paperbacks
-* Influence without Authority; A. Cohen, D. Bradford; Wiley
 * Search Inside Yourself - The Unexpected path to Achieving Success, Happiness (and World Peace); Chade-Meng Tan, Daniel Goleman, Jon Kabat-Zinn; HarperOne
-* The Joy of Missing Out; Christina Crook; New Society Publishers
+* The Obstacle Is The Way; Ryan Holiday; Profile Books Ltd
+* Psycho-Cybernetics; Maxwell Maltz; Perigee Books
 * Who Moved My Cheese?; Dr. Spencer Johnson; Vermilion 
+* Eat That Frog; Brian Tracy
 * The Good Enough Job; Simone Stolzoff; Ebury Edge
-* The Daily Stoic; Ryan Holiday, Stephen Hanselman; Profile Books
+* Stop starting, start finishing; Arne Roock; Lean-Kanban University  
+* Digital Minimalism; Cal Newport; Portofolio Penguin
+* Solve for Happy; Mo Gawdat
+* Slow Productivity; Cal Newport; Penguin Random House
+* So Good They Can't Ignore You; Cal Newport; Business Plus
+* The Joy of Missing Out; Christina Crook; New Society Publishers
 * Ultralearning; Scott Young; Thorsons
 * Staff Engineer: Leadership beyond the management track; Will Larson; Audible
-* Solve for Happy; Mo Gawdat
-* Soft Skills; John Sommez; Manning Publications
+* Deep Work; Cal Newport; Piatkus
+* The Bullet Journal Method; Ryder Carroll; Fourth Estate
 * The 7 Habits Of Highly Effective People; Stephen R. Covey; Simon & Schuster UK
-* Time Management for System Administrators; Thomas A. Limoncelli; O'Reilly
-* Eat That Frog; Brian Tracy
-* The Obstacle Is The Way; Ryan Holiday; Profile Books Ltd
+* Eat That Frog!; Brian Tracy; Hodder Paperbacks
 * Atomic Habits; James Clear; Random House Business
-* The Phoenix Project - A Novel About IT, DevOps, and Helping your Business Win; Gene Kim and Kevin Behr; Trade Select
-* Never Split the Difference; Chris Voss, Tahl Raz; Random House Business
 * Getting Things Done; David Allen
-* The Complete Software Developer's Career Guide; John Sonmez; Unabridged Audiobook
-* Digital Minimalism; Cal Newport; Portofolio Penguin
+* The Daily Stoic; Ryan Holiday, Stephen Hanselman; Profile Books
 * Consciousness: A Very Short Introduction; Susan Blackmore; Oxford Uiversity Press
-* Deep Work; Cal Newport; Piatkus
-* Buddah and Einstein walk into a Bar; Guy Joseph Ale, Claire Bloom; Blackstone Publishing
-* Stop starting, start finishing; Arne Roock; Lean-Kanban University  
+* Influence without Authority; A. Cohen, D. Bradford; Wiley
+* The Power of Now; Eckhard Tolle; Yellow Kite
+* 101 Essays that change the way you think; Brianna Wiest; Audible
+* Soft Skills; John Sommez; Manning Publications
 * Ultralearning; Anna Laurent; Self-published via Amazon
-* Slow Productivity; Cal Newport; Penguin Random House
-* So Good They Can't Ignore You; Cal Newport; Business Plus
+* The Off Switch; Mark Cropley; Virgin Books
+* Time Management for System Administrators; Thomas A. Limoncelli; O'Reilly
+* The Phoenix Project - A Novel About IT, DevOps, and Helping your Business Win; Gene Kim and Kevin Behr; Trade Select
+* Buddah and Einstein walk into a Bar; Guy Joseph Ale, Claire Bloom; Blackstone Publishing
+* Never Split the Difference; Chris Voss, Tahl Raz; Random House Business
+* The Complete Software Developer's Career Guide; John Sonmez; Unabridged Audiobook
 
 => ../notes/index.gmi Here are notes of mine for some of the books
 
@@ -137,22 +137,22 @@ In random order:
 
 Some of these were in-person with exams; others were online learning lectures only. In random order:
 
-* Ultimate Go Programming; Bill Kennedy; O'Reilly Online
-* Developing IaC with Terraform (with Live Lessons); O'Reilly Online
+* Scripting Vim; Damian Conway; O'Reilly Online
+* Protocol buffers; O'Reilly Online
+* Functional programming lecture; Remote University of Hagen
+* MySQL Deep Dive Workshop; 2-day on-site training
 * Apache Tomcat Best Practises; 3-day on-site training
-* F5 Loadbalancers Training; 2-day on-site training; F5, Inc. 
 * Structure and Interpretation of Computer Programs; Harold Abelson and more...; 
-* MySQL Deep Dive Workshop; 2-day on-site training
-* Scripting Vim; Damian Conway; O'Reilly Online
 * Algorithms Video Lectures; Robert Sedgewick; O'Reilly Online
-* Cloud Operations on AWS - Learn how to configure, deploy, maintain, and troubleshoot your AWS environments; 3-day online live training with labs; Amazon
-* The Well-Grounded Rubyist Video Edition; David. A. Black; O'Reilly Online
-* Linux Security and Isolation APIs Training; Michael Kerrisk; 3-day on-site training
-* Protocol buffers; O'Reilly Online
 * Red Hat Certified System Administrator; Course + certification (Although I had the option, I decided not to take the next course as it is more effective to self learn what I need)
-* Functional programming lecture; Remote University of Hagen
 * The Ultimate Kubernetes Bootcamp; School of Devops; O'Reilly Online
+* F5 Loadbalancers Training; 2-day on-site training; F5, Inc. 
+* Developing IaC with Terraform (with Live Lessons); O'Reilly Online
 * AWS Immersion Day; Amazon; 1-day interactive online training 
+* Ultimate Go Programming; Bill Kennedy; O'Reilly Online
+* Linux Security and Isolation APIs Training; Michael Kerrisk; 3-day on-site training
+* The Well-Grounded Rubyist Video Edition; David. A. Black; O'Reilly Online
+* Cloud Operations on AWS - Learn how to configure, deploy, maintain, and troubleshoot your AWS environments; 3-day online live training with labs; Amazon
 
 ## Technical guides
 
@@ -168,46 +168,46 @@ These are not whole books, but guides (smaller or larger) which I found very use
 
 In random order:
 
-* Hidden Brain
+* Maintainable
+* Deep Questions with Cal Newport
 * BSD Now
 * Fork Around And Find Out
-* Backend Banter
+* Hidden Brain
+* The Changelog Podcast(s)
 * Dev Interrupted
+* Cup o' Go [Golang]
+* Backend Banter
 * The Pragmatic Engineer Podcast
 * The ProdCast (Google SRE Podcast)
-* Cup o' Go [Golang]
-* Deep Questions with Cal Newport
 * Fallthrough [Golang]
-* The Changelog Podcast(s)
-* Maintainable
 
 ### Podcasts I liked
 
 I liked them but am not listening to them anymore. The podcasts have either "finished" (no more episodes) or I stopped listening to them due to time constraints or a shift in my interests.
 
-* FLOSS weekly
+* Go Time (predecessor of fallthrough)
+* Java Pub House
 * CRE: Chaosradio Express [german]
+* FLOSS weekly
 * Ship It (predecessor of Fork Around And Find Out)
 * Modern Mentor
-* Java Pub House
-* Go Time (predecessor of fallthrough)
 
 ## Newsletters I like
 
 This is a mix of tech and non-tech newsletters I am subscribed to. In random order:
 
-* Andreas Brandhorst Newsletter (Sci-Fi author)
-* Applied Go Weekly Newsletter
-* byteSizeGo
-* Register Spill
 * The Pragmatic Engineer
-* Ruby Weekly
 * Golang Weekly
-* VK Newsletter
-* The Valuable Dev
-* Changelog News
+* Applied Go Weekly Newsletter
 * Monospace Mentor
+* The Valuable Dev
 * The Imperfectionist
+* VK Newsletter
+* Ruby Weekly
+* Andreas Brandhorst Newsletter (Sci-Fi author)
+* Register Spill
+* byteSizeGo
+* Changelog News
 
 # Formal education
 
diff --git a/gemfeed/atom.xml.tmp b/gemfeed/atom.xml.tmp
new file mode 100644
index 00000000..03f1b688
--- /dev/null
+++ b/gemfeed/atom.xml.tmp
@@ -0,0 +1,1265 @@
+
+
+    2025-02-21T11:13:36+02:00
+    foo.zone feed
+    To be in the .zone!
+    
+    
+    gemini://foo.zone/
+    
+        Random Weird Things - Part Ⅱ
+        
+        gemini://foo.zone/gemfeed/2025-02-08-random-weird-things-ii.gmi
+        2025-02-08T11:06:16+02:00
+        
+            Paul Buetow aka snonux
+            paul@dev.buetow.org
+        
+        Every so often, I come across random, weird, and unexpected things on the internet. I thought it would be neat to share them here from time to time. This is the second run.
+        
+            

+                
Random Weird Things - Part Ⅱ


+

+Published at 2025-02-08T11:06:16+02:00

+

+Every so often, I come across random, weird, and unexpected things on the internet. I thought it would be neat to share them here from time to time. This is the second run.

+

+2024-07-05 Random Weird Things - Part Ⅰ

+2025-02-08 Random Weird Things - Part Ⅱ (You are currently reading this)

+

+
+/\_/\           /\_/\
+( o.o ) WHOA!! ( o.o )
+> ^ <           > ^ <
+/   \    MOEEW! /   \
+/______\       /______\
+

+

+
Table of Contents


+

+

+
11. The SQLite codebase is a gem


+

+Check this out:

+

+SQLite Gem

+

+Source:

+

+https://wetdry.world/@memes/112717700557038278

+

+
Go Programming


+

+
12. Official Go font


+

+The Go programming language has an official font called "Go Font." It was created to complement the aesthetic of the Go language, ensuring clear and legible rendering of code. The font includes a monospace version for code and a proportional version for general text, supporting consistent look and readability in Go-related materials and development environments. 

+

+Check out some Go code displayed using the Go font:

+

+Go font code

+

+https://go.dev/blog/go-fonts

+

+The design emphasizes simplicity and readability, reflecting Go's philosophy of clarity and efficiency.

+

+I found it interesting and/or weird, as Go is a programming language. Why should it bother having its own font? I have never seen another open-source project like Go do this. But I also like it. Maybe I will use it in the future for this blog :-) 

+

+
13. Go functions can have methods


+

+Functions on struct types? Well, know. Functions on types like int and string? It's also known of, but a bit lesser. Functions on function types? That sounds a bit funky, but it's possible, too! For demonstration, have a look at this snippet:

+

+
+
package main
+
+import "log"
+
+type fun func() string
+
+func (f fun) Bar() string {
+        return "Bar"
+}
+
+func main() {
+        var f fun = func() string {
+                return "Foo"
+        }
+        log.Println("Example 1: ", f())
+        log.Println("Example 2: ", f.Bar())
+        log.Println("Example 3: ", fun(f.Bar).Bar())
+        log.Println("Example 4: ", fun(fun(f.Bar).Bar).Bar())
+}
+

+

+It runs just fine:

+

+
+
❯ go run main.go
+2025/02/07 22:56:14 Example 1:  Foo
+2025/02/07 22:56:14 Example 2:  Bar
+2025/02/07 22:56:14 Example 3:  Bar
+2025/02/07 22:56:14 Example 4:  Bar
+

+

+
macOS


+

+For personal computing, I don't use Apple, but I have to use it for work. 

+

+
14. ß and ss are treated the same


+

+Know German? In German, the letter "sarp s" is written as ß. ß is treated the same as ss on macOS.

+

+On a case-insensitive file system like macOS, not only are uppercase and lowercase letters treated the same, but non-Latin characters like the German "ß" are also considered equivalent to their Latin counterparts (in this case, "ss").

+

+So, even though "Maß" and "Mass" are not strictly equivalent, the macOS file system still treats them as the same filename due to its handling of Unicode characters. This can sometimes lead to unexpected behaviour. Check this out:

+

+
+
❯ touch Maß
+❯ ls -l
+-rw-r--r--@ 1 paul  wheel  0 Feb  7 23:02 Maß
+❯ touch Mass
+❯ ls -l
+-rw-r--r--@ 1 paul  wheel  0 Feb  7 23:02 Maß
+❯ rm Mass
+❯ ls -l
+
+❯ touch Mass
+❯ ls -ltr
+-rw-r--r--@ 1 paul  wheel  0 Feb  7 23:02 Mass
+❯ rm Maß
+❯ ls -l
+
+

+

+
15. Colon as file path separator


+

+MacOS can use the colon as a file path separator on its ADFS (file system). A typical ADFS file pathname on a hard disc might be:

+

+
+ADFS::4.$.Documents.Techwriter.Myfile
+

+

+I can't reproduce this on my (work) Mac, though, as it now uses the APFS file system. In essence, ADFS is an older file system, while APFS is a contemporary file system optimized for Apple's modern devices.

+

+https://social.jvns.ca/@b0rk/113041293527832730

+

+
16. Polyglots - programs written in multiple languages


+

+A coding polyglot is a program or script written so that it can be executed in multiple programming languages without modification. This is typically achieved by leveraging syntax overlaps or crafting valid and meaningful code in each targeted language. Polyglot programs are often created as a challenge or for demonstration purposes to showcase language similarities or clever coding techniques.

+

+Check out my very own polyglot:

+

+The fibonatti.pl.c Polyglot

+

+
17. Languages, where indices start at 1


+

+Array indices start at 1 instead of 0 in some programming languages, known as one-based indexing. This can be controversial because zero-based indexing is more common in popular languages like C, C++, Java, and Python. One-based indexing can lead to off-by-one errors when developers switch between languages with different indexing schemes.

+

+Languages with One-Based Indexing:

+

+
    
+
  • Fortran
    • 
+
  • MATLAB
    • 
+
  • Lua
    • 
+
  • R (for vectors and lists)
    • 
+
  • Smalltalk
    • 
+
  • Julia (by default, although zero-based indexing is also possible)
    • 
+


+foo.lua example:

+

+
+
arr = {10, 20, 30, 40, 50}
+print(arr[1]) -- Accessing the first element
+

+

+
+
❯ lua foo.lua
+10
+

+

+One-based indexing is more natural for human-readable, mathematical, and theoretical contexts, where counting traditionally starts from one.

+

+
18. Perl Poetry


+

+Perl Poetry is a playful and creative practice within the programming community where Perl code is written as a poem. These poems are crafted to be syntactically valid Perl code and make sense as poetic text, often with whimsical or humorous intent. This showcases Perl's flexibility and expressiveness, as well as the creativity of its programmers.

+

+See this Poetry of my own; the Perl interpreter does not yield any syntax error parsing that. But also, the Peom doesn't do anything useful then executed:

+

+
+
# (C) 2006 by Paul C. Buetow
+
+Christmas:{time;#!!!
+
+Children: do tell $wishes;
+
+Santa: for $each (@children) { 
+BEGIN { read $each, $their, wishes and study them; use Memoize#ing
+
+} use constant gift, 'wrapping'; 
+package Gifts; pack $each, gift and bless $each and goto deliver
+or do import if not local $available,!!! HO, HO, HO;
+
+redo Santa, pipe $gifts, to_childs;
+redo Santa and do return if last one, is, delivered; 
+
+deliver: gift and require diagnostics if our $gifts ,not break;
+do{ use NEXT; time; tied $gifts} if broken and dump the, broken, ones;
+The_children: sleep and wait for (each %gift) and try { to => untie $gifts };
+
+redo Santa, pipe $gifts, to_childs;
+redo Santa and do return if last one, is, delivered; 
+
+The_christmas_tree: formline s/ /childrens/, $gifts;
+alarm and warn if not exists $Christmas{ tree}, @t, $ENV{HOME};  
+write <<EMail
+ to the parents to buy a new christmas tree!!!!111
+ and send the
+EMail
+;wait and redo deliver until defined local $tree;
+
+redo Santa, pipe $gifts, to_childs;
+redo Santa and do return if last one, is, delivered ;}
+
+END {} our $mission and do sleep until next Christmas ;}
+
+__END__
+
+This is perl, v5.8.8 built for i386-freebsd-64int
+

+

+More Perl Poetry of mine

+

+
19. CSS3 is turing complete


+

+CSS3 is Turing complete because it can simulate a Turing machine using only CSS animations and styles without any JavaScript or external logic. This is achieved by using keyframe animations to change the styles of HTML elements in a way that encodes computation, performing calculations and state transitions. 

+

+Is CSS turing complete?

+

+It is surprising because CSS is primarily a styling language intended for the presentation layer of web pages, not for computation or logic. Its capability to perform complex computations defies its typical use case and showcases the unintended computational power that can emerge from the creative use of seemingly straightforward technologies.

+

+Check out this 100% CSS implementation of the Conways Game of Life:

+

+

+

+CSS Conways Game of Life

+

+Conway's Game of Life is Turing complete because it can simulate a universal Turing machine, meaning it can perform any computation that a computer can, given the right initial conditions and sufficient time and space. Suppose a language can implement Conway's Game of Life. In that case, it demonstrates the language's ability to handle complex state transitions and computations. It has the necessary constructs (like iteration, conditionals, and data manipulation) to simulate any algorithm, thus confirming its Turing completeness.

+

+
20. The biggest shell programs 


+

+One would think that shell scripts are only suitable for small tasks. Well, I must be wrong, as there are huge shell programs out there (up to 87k LOC) which aren't auto-generated but hand-written!

+

+The Biggest Sell Programs in the World

+

+My Gemtexter (bash) is only 1329 LOC as of now. So it's tiny.

+

+Gemtexter - One Bash script to rule it all

+

+I hope you had some fun. E-Mail your comments to paul@nospam.buetow.org :-)

+

+Back to the main site

+            

+        
+    
+    
+        f3s: Kubernetes with FreeBSD - Part 3: Protecting from power cuts
+        
+        gemini://foo.zone/gemfeed/2025-02-01-f3s-kubernetes-with-freebsd-part-3.gmi
+        2025-01-30T09:22:06+02:00
+        
+            Paul Buetow aka snonux
+            paul@dev.buetow.org
+        
+        This is the third blog post about my f3s series for my self-hosting demands in my home lab. f3s? The 'f' stands for FreeBSD, and the '3s' stands for k3s, the Kubernetes distribution we will use on FreeBSD-based physical machines.
+        
+            

+                
f3s: Kubernetes with FreeBSD - Part 3: Protecting from power cuts


+

+Published at 2025-01-30T09:22:06+02:00

+

+This is the third blog post about my f3s series for my self-hosting demands in my home lab. f3s? The "f" stands for FreeBSD, and the "3s" stands for k3s, the Kubernetes distribution we will use on FreeBSD-based physical machines.

+

+2024-11-17 f3s: Kubernetes with FreeBSD - Part 1: Setting the stage

+2024-12-03 f3s: Kubernetes with FreeBSD - Part 2: Hardware and base installation

+2025-02-01 f3s: Kubernetes with FreeBSD - Part 3: Protecting from power cuts (You are currently reading this)

+

+f3s logo

+

+
Table of Contents


+

+

+
Introduction


+

+In this blog post, we are setting up the UPS for the cluster. A UPS, or Uninterruptible Power Supply, safeguards my cluster from unexpected power outages and surges. It acts as a backup battery that kicks in when the electricity cuts out—especially useful in my area, where power cuts are frequent—allowing for a graceful system shutdown and preventing data loss and corruption. This is especially important since I will also store some of my data on the f3s nodes.

+

+
Changes since last time


+

+
FreeBSD upgrade from 14.1 to 14.2


+

+There has been a new release since the last blog post in this series. The upgrade from 14.1 was as easy as:

+

+
+
paul@f0: ~ % doas freebsd-update fetch
+paul@f0: ~ % doas freebsd-update install
+paul@f0: ~ % doas freebsd-update -r 14.2-RELEASE upgrade
+paul@f0: ~ % doas freebsd-update install
+paul@f0: ~ % doas shutdown -r now
+

+

+And after rebooting, I ran:

+

+
+
paul@f0: ~ % doas freebsd-update install
+paul@f0: ~ % doas pkg update
+paul@f0: ~ % doas pkg upgrade
+paul@f0: ~ % doas shutdown -r now
+

+

+And after another reboot, I was on 14.2:

+

+
+
paul@f0:~ % uname -a
+FreeBSD f0.lan.buetow.org 14.2-RELEASE FreeBSD 14.2-RELEASE 
+ releng/14.2-n269506-c8918d6c7412 GENERIC amd64
+

+

+And, of course, I ran this on all 3 nodes!

+

+
A new home (behind the TV)


+

+I've put all the infrastructure behind my TV, as plenty of space is available. The TV hides most of the setup, which drastically improved the SAF (spouse acceptance factor).

+

+New hardware placement arrangement

+

+I got rid of the mini-switch I mentioned in the previous blog post. I have the TP-Link EAP615-Wall mounted on the wall nearby, which is my OpenWrt-powered Wi-Fi hotspot. It also has 3 Ethernet ports, to which I connected the Beelink nodes. That's the device you see at the very top.

+

+The Ethernet cables go downward through the cable boxes to the Beelink nodes. In addition to the Beelink f3s nodes, I connected the TP-Link to the UPS as well (not discussed further in this blog post, but the positive side effect is that my Wi-Fi will still work during a power loss for some time—and during a power cut, the Beelink nodes will still be able to communicate with each other).

+

+On the very left (the black box) is the UPS, with four power outlets. Three go to the Beelink nodes, and one goes to the TP-Link. A USB output is also connected to the first Beelink node, f0. 

+

+On the very right (halfway hidden behind the TV) are the 3 Beelink nodes stacked on top of each other. The only downside (or upside?) is that my 14-month-old daughter is now chaos-testing the Beelink nodes, as the red power buttons (now reachable for her) are very attractive for her to press when passing by randomly. :-) Luckily, that will only cause graceful system shutdowns!

+

+
The UPS hardware


+

+I wanted a UPS that I could connect to via FreeBSD, and that would provide enough backup power to operate the cluster for a couple of minutes (it turned out to be around an hour, but this time will likely be shortened after future hardware upgrades, like additional drives and a backup enclosure) and to automatically initiate the shutdown of all the f3s nodes.

+

+I decided on the APC Back-UPS BX750MI model because:

+

+
    
+
  • Zero noise level when there is no power cut (some light noise when the battery is in operation during a power cut).
    • 
+
  • Cost: It is relatively affordable (not costing thousands).
    • 
+
  • USB connectivity: Can be connected via USB to one of the FreeBSD hosts to read the UPS status.
    • 
+
  • A power output of 750VA (or 410 watts), suitable for an hour of runtime for my f3s nodes (plus the Wi-Fi router).
    • 
+
  • Multiple power outlets: Can connect all 3 f3s nodes directly.
    • 
+
  • User-replaceable batteries: I can replace the batteries myself after two years or more (depending on usage).
    • 
+
  • Its compact design. Overall, I like how it looks.
    • 
+


+The APC Back-UPS BX750MI in operation.

+

+
Configuring FreeBSD to Work with the UPS


+

+
USB Device Detection


+

+Once plugged in via USB on FreeBSD, I could see the following in the kernel messages:

+

+
+
paul@f0: ~ % doas dmesg | grep UPS
+ugen0.2: <American Power Conversion Back-UPS BX750MI> at usbus0
+

+

+
apcupsd Installation


+

+To make use of the USB connection, the apcupsd package had to be installed:

+

+
+
paul@f0: ~ % doas install apcupsd
+

+

+I have made the following modifications to the configuration file so that the UPS can be used via the USB interface:

+

+
+
paul@f0:/usr/local/etc/apcupsd % diff -u apcupsd.conf.sample  apcupsd.conf
+--- apcupsd.conf.sample 2024-11-01 16:40:42.000000000 +0200
++++ apcupsd.conf        2024-12-03 10:58:24.009501000 +0200
+@@ -31,7 +31,7 @@
+ #     940-1524C, 940-0024G, 940-0095A, 940-0095B,
+ #     940-0095C, 940-0625A, M-04-02-2000
+ #
+-UPSCABLE smart
++UPSCABLE usb
+
+ # To get apcupsd to work, in addition to defining the cable
+ # above, you must also define a UPSTYPE, which corresponds to
+@@ -88,8 +88,10 @@
+ #                            that apcupsd binds to that particular unit
+ #                            (helpful if you have more than one USB UPS).
+ #
+-UPSTYPE apcsmart
+-DEVICE /dev/usv
++UPSTYPE usb
++DEVICE
+
+ # POLLTIME <int>
+ #   Interval (in seconds) at which apcupsd polls the UPS for status. This
+

+

+I left the remaining settings as the default ones; for example, the following are of main interest:

+

+
+# If during a power failure, the remaining battery percentage
+# (as reported by the UPS) is below or equal to BATTERYLEVEL,
+# apcupsd will initiate a system shutdown.
+BATTERYLEVEL 5
+
+# If during a power failure, the remaining runtime in minutes
+# (as calculated internally by the UPS) is below or equal to MINUTES,
+# apcupsd, will initiate a system shutdown.
+MINUTES 3
+

+

+I then enabled and started the daemon:

+

+
+
paul@f0:/usr/local/etc/apcupsd % doas sysrc apcupsd_enable=YES
+apcupsd_enable:  -> YES
+paul@f0:/usr/local/etc/apcupsd % doas service apcupsd start
+Starting apcupsd.
+

+

+
UPS Connectivity Test


+

+And voila, I could now access the UPS information via the apcaccess command; how convenient :-) (I also read through the manual page, which provides a good understanding of what else can be done with it!).

+

+
+
paul@f0:~ % apcaccess
+APC      : 001,035,0857
+DATE     : 2025-01-26 14:43:27 +0200
+HOSTNAME : f0.lan.buetow.org
+VERSION  : 3.14.14 (31 May 2016) freebsd
+UPSNAME  : f0.lan.buetow.org
+CABLE    : USB Cable
+DRIVER   : USB UPS Driver
+UPSMODE  : Stand Alone
+STARTTIME: 2025-01-26 14:43:25 +0200
+MODEL    : Back-UPS BX750MI
+STATUS   : ONLINE
+LINEV    : 230.0 Volts
+LOADPCT  : 4.0 Percent
+BCHARGE  : 100.0 Percent
+TIMELEFT : 65.3 Minutes
+MBATTCHG : 5 Percent
+MINTIMEL : 3 Minutes
+MAXTIME  : 0 Seconds
+SENSE    : Medium
+LOTRANS  : 145.0 Volts
+HITRANS  : 295.0 Volts
+ALARMDEL : No alarm
+BATTV    : 13.6 Volts
+LASTXFER : Automatic or explicit self test
+NUMXFERS : 0
+TONBATT  : 0 Seconds
+CUMONBATT: 0 Seconds
+XOFFBATT : N/A
+SELFTEST : NG
+STATFLAG : 0x05000008
+SERIALNO : 9B2414A03599
+BATTDATE : 2001-01-01
+NOMINV   : 230 Volts
+NOMBATTV : 12.0 Volts
+NOMPOWER : 410 Watts
+END APC  : 2025-01-26 14:44:06 +0200
+

+

+
APC Info on Partner Nodes:


+

+So far, so good. Host f0 would shut down itself when short on power. But what about the f1 and f2 nodes? They aren't connected directly to the UPS and, therefore, wouldn't know that their power is about to be cut off. For this, apcupsd running on the f1 and f2 nodes can be configured to retrieve UPS information via the network from the apcupsd server running on the f0 node, which is connected directly to the APC via USB.

+

+Of course, this won't work when f0 is down. In this case, no operational node would be connected to the UPS via USB; therefore, the current power status would not be known. However, I consider this a rare circumstance. Furthermore, in case of an f0 system crash, sudden power outages on the two other nodes would occur at different times making real data loss (the main concern here) less likely.

+

+And if f0 is down and f1 and f2 receive new data and crash midway, it's likely that a client (e.g., an Android app or another laptop) still has the data stored on it, making data recoverable and data loss overall nearly impossible. I'd receive an alert if any of the nodes go down (more on monitoring later in this blog series).

+

+
Installation on partners


+

+To do this, I installed apcupsd via doas pkg install apcupsd on f1 and f2, and then I could connect to it this way:

+

+
+
paul@f1:~ % apcaccess -h f0.lan.buetow.org | grep Percent
+LOADPCT  : 12.0 Percent
+BCHARGE  : 94.0 Percent
+MBATTCHG : 5 Percent
+

+

+But I want the daemon to be configured and enabled in such a way that it connects to the master UPS node (the one with the UPS connected via USB) so that it can also initiate a system shutdown when the UPS battery reaches low levels. For that, apcupsd itself needs to be aware of the UPS status.

+

+On f1 and f2, I changed the configuration to use f0 (where apcupsd is listening) as a remote device. I also changed the MINUTES setting from 3 to 6 and the BATTERYLEVEL setting from 5 to 10 to ensure that the f1 and f2 nodes could still connect to the f0 node for UPS information before f0 decides to shut down itself. So f1 and f2 must shut down earlier than f0:

+

+
+
paul@f2:/usr/local/etc/apcupsd % diff -u apcupsd.conf.sample apcupsd.conf
+--- apcupsd.conf.sample 2024-11-01 16:40:42.000000000 +0200
++++ apcupsd.conf        2025-01-26 15:52:45.108469000 +0200
+@@ -31,7 +31,7 @@
+ #     940-1524C, 940-0024G, 940-0095A, 940-0095B,
+ #     940-0095C, 940-0625A, M-04-02-2000
+ #
+-UPSCABLE smart
++UPSCABLE ether
+
+ # To get apcupsd to work, in addition to defining the cable
+ # above, you must also define a UPSTYPE, which corresponds to
+@@ -52,7 +52,6 @@
+ #                            Network Information Server. This is used if the
+ #                            UPS powering your computer is connected to a
+ #                            different computer for monitoring.
+-#
+ # snmp      hostname:port:vendor:community
+ #                            SNMP network link to an SNMP-enabled UPS device.
+ #                            Hostname is the ip address or hostname of the UPS
+@@ -88,8 +87,8 @@
+ #                            that apcupsd binds to that particular unit
+ #                            (helpful if you have more than one USB UPS).
+ #
+-UPSTYPE apcsmart
+-DEVICE /dev/usv
++UPSTYPE net
++DEVICE f0.lan.buetow.org:3551
+
+ # POLLTIME <int>
+ #   Interval (in seconds) at which apcupsd polls the UPS for status. This
+@@ -147,12 +146,12 @@
+ # If during a power failure, the remaining battery percentage
+ # (as reported by the UPS) is below or equal to BATTERYLEVEL,
+ # apcupsd will initiate a system shutdown.
+-BATTERYLEVEL 5
++BATTERYLEVEL 10
+
+ # If during a power failure, the remaining runtime in minutes
+ # (as calculated internally by the UPS) is below or equal to MINUTES,
+ # apcupsd, will initiate a system shutdown.
+-MINUTES 3
++MINUTES 6
+
+ # If during a power failure, the UPS has run on batteries for TIMEOUT
+ # many seconds or longer, apcupsd will initiate a system shutdown.
+
+

+So I also ran the following commands on f1 and f2:

+

+
+
paul@f1:/usr/local/etc/apcupsd % doas sysrc apcupsd_enable=YES
+apcupsd_enable:  -> YES
+paul@f1:/usr/local/etc/apcupsd % doas service apcupsd start
+Starting apcupsd.
+

+

+And then I was able to connect to localhost via the apcaccess command:

+

+
+
paul@f1:~ % doas apcaccess | grep Percent
+LOADPCT  : 5.0 Percent
+BCHARGE  : 95.0 Percent
+MBATTCHG : 5 Percent
+

+

+
Power outage simulation


+

+
Pulling the plug


+

+I simulated a power outage by removing the power input from the APC. Immediately, the following message appeared on all the nodes:

+

+
+Broadcast Message from root@f0.lan.buetow.org
+        (no tty) at 15:03 EET...
+
+Power failure. Running on UPS batteries.                                              
+

+

+I ran the following command to confirm the available battery time:

+

+
+
paul@f0:/usr/local/etc/apcupsd % apcaccess -p TIMELEFT
+63.9 Minutes
+

+

+And after around one hour (f1 and f2 a bit earlier, f0 a bit later due to the different BATTERYLEVEL and MINUTES settings outlined earlier), the following broadcast was sent out:

+

+
+Broadcast Message from root@f0.lan.buetow.org
+        (no tty) at 15:08 EET...
+
+        *** FINAL System shutdown message from root@f0.lan.buetow.org ***
+
+System going down IMMEDIATELY
+
+apcupsd initiated shutdown
+

+

+And all the nodes shut down safely before the UPS ran out of battery!

+

+
Restoring power


+

+After restoring power, I checked the logs in /var/log/daemon.log and found the following on all 3 nodes:

+

+
+Jan 26 17:36:24 f2 apcupsd[2159]: Power failure.
+Jan 26 17:36:30 f2 apcupsd[2159]: Running on UPS batteries.
+Jan 26 17:36:30 f2 apcupsd[2159]: Battery charge below low limit.
+Jan 26 17:36:30 f2 apcupsd[2159]: Initiating system shutdown!
+Jan 26 17:36:30 f2 apcupsd[2159]: User logins prohibited
+Jan 26 17:36:32 f2 apcupsd[2159]: apcupsd exiting, signal 15
+Jan 26 17:36:32 f2 apcupsd[2159]: apcupsd shutdown succeeded
+

+

+All good :-) See you in the next post of this series!

+

+Other BSD related posts are:

+

+2025-02-01 f3s: Kubernetes with FreeBSD - Part 3: Protecting from power cuts (You are currently reading this)

+2024-12-03 f3s: Kubernetes with FreeBSD - Part 2: Hardware and base installation

+2024-11-17 f3s: Kubernetes with FreeBSD - Part 1: Setting the stage

+2024-04-01 KISS high-availability with OpenBSD

+2024-01-13 One reason why I love OpenBSD

+2022-10-30 Installing DTail on OpenBSD

+2022-07-30 Let's Encrypt with OpenBSD and Rex

+2016-04-09 Jails and ZFS with Puppet on FreeBSD

+

+E-Mail your comments to paul@nospam.buetow.org :-)

+

+Back to the main site

+            

+        
+    
+    
+        Working with an SRE Interview
+        
+        gemini://foo.zone/gemfeed/2025-01-15-working-with-an-sre-interview.gmi
+        2025-01-15T00:16:04+02:00
+        
+            Paul Buetow aka snonux
+            paul@dev.buetow.org
+        
+        I have been interviewed by Florian Buetow on `cracking-ai-engineering.com`  about what it's like working with a Site Reliability Engineer from the point of view of a Software Engineer, Data Scientist, and AI Engineer.
+        
+            

+                
Working with an SRE Interview


+

+Published at 2025-01-15T00:16:04+02:00

+

+I have been interviewed by Florian Buetow on cracking-ai-engineering.com  about what it's like working with a Site Reliability Engineer from the point of view of a Software Engineer, Data Scientist, and AI Engineer.

+

+See original interview here

+Cracking AI Engineering

+

+Below, I am posting the interview here on my blog as well.

+

+
Table of Contents


+

+

+
Preamble 


+

+In this insightful interview, Paul Bütow, a Principal Site Reliability Engineer at Mimecast, shares over a decade of experience in the field. Paul highlights the role of an Embedded SRE, emphasizing the importance of automation, observability, and effective incident management. We also focused on the key question of how you can work effectively with an SRE weather you are an individual contributor or a manager, a software engineer or data scientist. And how you can learn more about site reliability engineering.

+

+
Introducing Paul


+

+Hi Paul, please introduce yourself briefly to the audience. Who are you, what do you do for a living, and where do you work?

+

+My name is Paul Bütow, I work at Mimecast, and I’m a Principal Site Reliability Engineer there. I’ve been with Mimecast for almost ten years now. The company specializes in email security, including things like archiving, phishing detection, malware protection, and spam filtering.

+

+You mentioned that you’re an ‘Embedded SRE.’ What does that mean exactly?

+

+It means that I’m directly part of the software engineering team, not in a separate Ops department. I ensure that nothing is deployed manually, and everything runs through automation. I also set up monitoring and observability. These are two distinct aspects: monitoring alerts us when something breaks, while observability helps us identify trends. I also create runbooks so we know what to do when specific incidents occur frequently.

+

+Infrastructure SREs on the other hand handle the foundational setup, like providing the Kubernetes cluster itself or ensuring the operating systems are installed. They don't work on the application directly but ensure the base infrastructure is there for others to use. This works well when a company has multiple teams that need shared infrastructure.

+

+
How did you get started?


+

+How did your interest in Linux or FreeBSD start?

+

+It began during my school days. We had a PC with DOS at home, and I eventually bought Suse Linux 5.3. Shortly after, I discovered FreeBSD because I liked its handbook so much. I wanted to understand exactly how everything worked, so I also tried Linux from Scratch. That involves installing every package manually to gain a better understanding of operating systems.

+

+https://www.FreeBSD.org

+https://linuxfromscratch.org/

+

+And after school, you pursued computer science, correct?

+

+Exactly. I wasn’t sure at first whether I wanted to be a software developer or a system administrator. I applied for both and eventually accepted an offer as a Linux system administrator. This was before 'SRE' became a buzzword, but much of what I did back then-automation, infrastructure as code, monitoring-is now considered part of the typical SRE role.

+

+
Roles and Career Progression


+

+Tell us about how you joined Mimecast. When did you fully embrace the SRE role?

+

+I started as a Linux sysadmin at 1&1. I managed an ad server farm with hundreds of systems and later handled load balancers. Together with an architect, we managed F5 load balancers distributing around 2,000 services, including for portals like web.de and GMX. I also led the operations team technically for a while before moving to London to join Mimecast.

+

+At Mimecast, the job title was explicitly 'Site Reliability Engineer.' The biggest difference was that I was no longer in a separate Ops department but embedded directly within the storage and search backend team. I loved that because we could plan features together-from automation to measurability and observability. Mimecast also operates thousands of physical servers for email archiving, which was fascinating since I already had experience with large distributed systems at 1&1. It was the right step for me because it allowed me to work close to the code while remaining hands-on with infrastructure.

+

+What are the differences between SRE, DevOps, SysAdmin, and Architects?

+

+SREs are like the next step after SysAdmins. A SysAdmin might manually install servers, replace disks, or use simple scripts for automation, while SREs use infrastructure as code and focus on reliability through SLIs, SLOs, and automation. DevOps isn’t really a job-it’s more of a way of working, where developers are involved in operations tasks like setting up CI/CD pipelines or on-call shifts. Architects focus on designing systems and infrastructures, such as load balancers or distributed systems, working alongside SREs to ensure the systems meet the reliability and scalability requirements. The specific responsibilities of each role depend on the company, and there is often overlap.  

+

+What are the most important reliability lessons you’ve learned so far?

+

+
    
+
  • Don’t leave SRE aspects as an afterthought. It’s much better to discuss automation, monitoring, SLIs, and SLOs early on. Traditional sysadmins often installed systems manually, but today, we do everything via infrastructure as code-using tools like Terraform or Puppet.
    • 
+
  • I also distinguish between monitoring and observability. Monitoring tells us, 'The server is down, alarm!' Observability dives deeper, showing trends like increasing latency so we can act proactively.
    • 
+
  • SLI, SLO, and SLA are core elements. We focus on what users actually experience-for example, how quickly an email is sent-and set our goals accordingly.
    • 
+
  • Runbooks are also crucial. When something goes wrong at night, you don’t want to start from scratch. A runbook outlines how to debug and resolve specific problems, saving time and reducing downtime.
    • 
+


+
Anecdotes and Best Practices


+

+Runbooks sound very practical. Can you explain how they’re used day-to-day?

+

+Runbooks are essentially guides for handling specific incidents. For instance, if a service won’t start, the runbook will specify where the logs are and which commands to use. Observability takes it a step further, helping us spot changes early-like rising error rates or latency-so we can address issues before they escalate.

+

+When should you decide to put something into a runbook, and when is it unnecessary?

+

+If an issue happens frequently, it should be documented in a runbook so that anyone, even someone new, can follow the steps to fix it. The idea is that 90% of the common incidents should be covered. For example, if a service is down, the runbook would specify where to find logs, which commands to check, and what actions to take. On the other hand, rare or complex issues, where the resolution depends heavily on context or varies each time, don’t make sense to include in detail. For those, it’s better to focus on general troubleshooting steps.  

+

+How do you search for and find the correct runbooks?

+

+Runbooks should be linked directly in the alert you receive. For example, if you get an alert about a service not running, the alert will have a link to the runbook that tells you what to check, like logs or commands to run. Runbooks are best stored in an internal wiki, so if you don’t find the link in the alert, you know where to search. The important thing is that runbooks are easy to find and up to date because that’s what makes them useful during incidents.  

+

+Do you have an interesting war story you can share with us?

+

+Sure. At 1&1, we had a proprietary ad server software that ran a SQL query during startup. The query got slower over time, eventually timing out and preventing the server from starting. Since we couldn’t access the source code, we searched the binary for the SQL and patched it. By pinpointing the issue, a developer was able to adjust the SQL. This collaboration between sysadmin and developer perspectives highlights the value of SRE work.

+

+
Working with Different Teams


+

+You’re embedded in a team-how does collaboration with developers work practically?

+

+We plan everything together from the start. If there’s a new feature, we discuss infrastructure, automated deployments, and monitoring right away. Developers are experts in the code, and I bring the infrastructure expertise. This avoids unpleasant surprises before going live.

+

+How about working with data scientists or ML engineers? Are there differences?

+

+The principles are the same. ML models also need to be deployed and monitored. You deal with monitoring, resource allocation, and identifying performance drops. Whether it’s a microservice or an ML job, at the end of the day, it’s all running on servers or clusters that must remain stable.

+

+What about working with managers or the FinOps team?

+

+We often discuss costs, especially in the cloud, where scaling up resources is easy. It’s crucial to know our metrics: do we have enough capacity? Do we need all instances? Or is the CPU only at 5% utilization? This data helps managers decide whether the budget is sufficient or if optimizations are needed.

+

+Do you have practical tips for working with SREs?

+

+Yes, I have a few:

+

+
    
+
  • Early involvement: Include SREs from the beginning in your project.
    • 
+
  • Runbooks & documentation: Document recurring errors.
    • 
+
  • Try first: Try to understand the issue yourself before immediately asking the SRE.
    • 
+
  • Basic infra knowledge: Kubernetes and Terraform aren’t magic. Some basic understanding helps every developer.
    • 
+


+
Using AI Tools


+

+Let’s talk about AI. How do you use it in your daily work?

+

+For boilerplate code, like Terraform snippets, I often use ChatGPT. It saves time, although I always review and adjust the output. Log analysis is another exciting application. Instead of manually going through millions of lines, AI can summarize key outliers or errors.

+

+Do you think AI could largely replace SREs or significantly change the role?

+

+I see AI as an additional tool. SRE requires a deep understanding of how distributed systems work internally. While AI can assist with routine tasks or quickly detect anomalies, human expertise is indispensable for complex issues.

+

+
SRE Learning Resources


+

+What resources would you recommend for learning about SRE?

+

+The Google SRE book is a classic, though a bit dry. I really like 'Seeking SRE,' as it offers various perspectives on SRE, with many practical stories from different companies.

+

+https://sre.google/books/

+Seeking SRE

+

+Do you have a podcast recommendation?

+

+The Google SRE prodcast is quite interesting. It offers insights into how Google approaches SRE, along with perspectives from external guests.

+

+https://sre.google/prodcast/

+

+
Blogging


+

+You also have a blog. What motivates you to write regularly?

+

+Writing helps me learn the most. It also serves as a personal reference. Sometimes I look up how I solved a problem a year ago. And of course, others tackling similar projects might find inspiration in my posts.

+

+What do you blog about?

+

+Mostly technical topics I find exciting, like homelab projects, Kubernetes, or book summaries on IT and productivity. It’s a personal blog, so I write about what I enjoy.

+

+
Wrap-up


+

+To wrap up, what are three things every team should keep in mind for stability?

+

+First, maintain runbooks and documentation to avoid chaos at night. Second, automate everything-manual installs in production are risky. Third, define SLIs, SLOs, and SLAs early so everyone knows what we’re monitoring and guaranteeing.

+

+Is there a motto or mindset that particularly inspires you as an SRE?

+

+"Keep it simple and stupid"-KISS. Not everything has to be overly complex. And always stay curious. I’m still fascinated by how systems work under the hood.

+

+Where can people find you online?

+

+You can find links to my socials on my website paul.buetow.org

+I regularly post articles and link to everything else I’m working on outside of work.

+

+https://paul.buetow.org

+

+Thank you very much for your time and this insightful interview into the world of site reliability engineering

+

+My pleasure, this was fun.

+

+
Closing comments


+

+Dear reader, I hope this conversation with Paul Bütow provided an exciting peak into the world of Site Reliability Engineering. Whether you’re a software developer, data scientist, ML engineer, or manager, reliable systems are always a team effort. Hopefully, you’ve taken some insights or tips from Paul’s experiences for your own team or next project. Thanks for joining us, and best of luck refining your own SRE practices!

+

+E-Mail your comments to paul@nospam.buetow.org or contact Florian via the Cracking AI Engineering :-)

+

+Back to the main site

+            

+        
+    
+    
+        Posts from October to December 2024
+        
+        gemini://foo.zone/gemfeed/2025-01-01-posts-from-october-to-december-2024.gmi
+        2024-12-31T18:09:58+02:00
+        
+            Paul Buetow aka snonux
+            paul@dev.buetow.org
+        
+        Happy new year!
+        
+            

+                
Posts from October to December 2024


+

+Published at 2024-12-31T18:09:58+02:00

+

+Happy new year!

+

+These are my social media posts from the last three months. I keep them here to reflect on them and also to not lose them. Social media networks come and go and are not under my control, but my domain is here to stay. 

+

+These are from Mastodon and LinkedIn. Have a look at my about page for my social media profiles. This list is generated with Gos, my social media platform sharing tool.

+

+My about page

+https://codeberg.org/snonux/gos

+

+
Table of Contents


+

+

+
Posts for 202410 202411 202412


+

+
October 2024


+

+
First on-call experience in a startup. Doesn't ...


+

+First on-call experience in a startup. Doesn't sound a lot of fun! But the lessons were learned! #sre

+

+ntietz.com/blog/lessons-from-my-first-on-call/

+

+
Reviewing your own PR or MR before asking ...


+

+Reviewing your own PR or MR before asking others to review it makes a lot of sense. Have seen so many silly mistakes which would have been avoided. Saving time for the real reviewer.

+

+www.jvt.me/posts/2019/01/12/self-code-review/

+

+
Fun with defer in #golang, I did't know, that ...


+

+Fun with defer in #golang, I did't know, that a defer object can either be heap or stack allocated. And there are some rules for inlining, too.

+

+victoriametrics.com/blog/defer-in-go/

+

+
I have been in incidents. Understandably, ...


+

+I have been in incidents. Understandably, everyone wants the issue to be resolved as quickly and others want to know how long TTR will be. IMHO, providing no estimates at all is no solution either. So maybe give a rough estimate but clearly communicate that the estimate is rough and that X, Y, and Z can interfere, meaning there is a chance it will take longer to resolve the incident. Just my thought. What's yours?

+

+firehydrant.com/blog/hot-take-dont-provide-incident-resolution-estimates/

+

+
Little tips using strings in #golang and I ...


+

+Little tips using strings in #golang and I personally think one must look more into the std lib (not just for strings, also for slices, maps,...), there are tons of useful helper functions.

+

+www.calhoun.io/6-tips-for-using-strings-in-go/

+

+
Reading this post about #rust (especially the ...


+

+Reading this post about #rust (especially the first part), I think I made a good choice in deciding to dive into #golang instead. There was a point where I wanted to learn a new programming language, and Rust was on my list of choices. I think the Go project does a much better job of deciding what goes into the language and how. What are your thoughts?

+

+josephg.com/blog/rewriting-rust/

+

+
The opposite of #ChaosMonkey ... ...


+

+The opposite of #ChaosMonkey ... automatically repairing and healing services helping to reduce manual toil work. Runbooks and scripts are only the first step, followed by a fully blown service written in Go. Could be useful, but IMHO why not rather address the root causes of the manual toil work? #sre

+

+blog.cloudflare.com/nl-nl/improving-platform-resilience-at-cloudflare/

+

+
November 2024


+

+
I just became a Silver Patreon for OSnews. What ...


+

+I just became a Silver Patreon for OSnews. What is OSnews? It is an independent news site about IT. It is slightly independent and, at times, alternative. I have enjoyed it since my early student days. This one and other projects I financially support are listed here:

+

+foo.zone/gemfeed/2024-09-07-projects-i-support.gmi (Gemini)

+foo.zone/gemfeed/2024-09-07-projects-i-support.html

+

+
Until now, I wasn't aware, that Go is under a ...


+

+Until now, I wasn't aware, that Go is under a BSD-style license (3-clause as it seems). Neat. I don't know why, but I always was under the impression it would be MIT. #bsd #golang

+

+go.dev/LICENSE

+

+
These are some book notes from "Staff Engineer" ...


+

+These are some book notes from "Staff Engineer" – there is some really good insight into what is expected from a Staff Engineer and beyond in the industry. I wish I had read the book earlier.

+

+foo.zone/gemfeed/2024-10-24-staff-engineer-book-notes.gmi (Gemini)

+foo.zone/gemfeed/2024-10-24-staff-engineer-book-notes.html

+

+
Looking at #Kubernetes, it's pretty much ...


+

+Looking at #Kubernetes, it's pretty much following the Unix way of doing things. It has many tools, but each tool has its own single purpose: DNS, scheduling, container runtime, various controllers, networking, observability, alerting, and more services in the control plane. Everything is managed by different services or plugins, mostly running in their dedicated pods. They don't communicate through pipes, but network sockets, though. #k8s

+

+
There has been an outage at the upstream ...


+

+There has been an outage at the upstream network provider for OpenBSD.Amsterdam (hoster, I am using). This was the first real-world test for my KISS HA setup, and it worked flawlessly! All my sites and services failed over automatically to my other #OpenBSD VM!

+

+foo.zone/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi (Gemini)

+foo.zone/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.html

+openbsd.amsterdam/

+

+
One of the more confusing parts in Go, nil ...


+

+One of the more confusing parts in Go, nil values vs nil errors: #golang

+

+unexpected-go.com/nil-errors-that-are-non-nil-errors.html

+

+
Agreeably, writing down with Diagrams helps you ...


+

+Agreeably, writing down with Diagrams helps you to think things more through. And keeps others on the same page. Only worth for projects from a certain size, IMHO.

+

+ntietz.com/blog/reasons-to-write-design-docs/

+

+
I like the idea of types in Ruby. Raku is ...


+

+I like the idea of types in Ruby. Raku is supports that already, but in Ruby, you must specify the types in a separate .rbs file, which is, in my opinion, cumbersome and is a reason not to use it extensively for now. I believe there are efforts to embed the type information in the standard .rb files, and that the .rbs is just an experiment to see how types could work out without introducing changes into the core Ruby language itself right now? #Ruby #RakuLang

+

+github.com/ruby/rbs

+

+
So, #Haskell is better suited for general ...


+

+So, #Haskell is better suited for general purpose than #Rust? I thought deploying something in Haskell means publishing an academic paper :-) Interesting rant about Rust, though:

+

+chrisdone.com/posts/rust/

+

+
At first, functional options add a bit of ...


+

+At first, functional options add a bit of boilerplate, but they turn out to be quite neat, especially when you have very long parameter lists that need to be made neat and tidy. #golang

+

+www.calhoun.io/using-functional-options-instead-of-method-chaining-in-go/

+

+
Revamping my home lab a little bit. #freebsd ...


+

+Revamping my home lab a little bit. #freebsd #bhyve #rocky #linux #vm #k3s #kubernetes #wireguard #zfs #nfs #ha #relayd #k8s #selfhosting #homelab

+

+foo.zone/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi (Gemini)

+foo.zone/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.html

+

+
Wondering to which #web #browser I should ...


+

+Wondering to which #web #browser I should switch now personally ...

+

+www.osnews.com/story/141100/mozilla-fo..-..dvocacy-for-open-web-privacy-and-more/

+

+
eks-node-viewer is a nifty tool, showing the ...


+

+eks-node-viewer is a nifty tool, showing the compute nodes currently in use in the #EKS cluster. especially useful when dynamically allocating nodes with #karpenter or auto scaling groups.

+

+github.com/awslabs/eks-node-viewer

+

+
Have put more Photos on - On my static photo ...


+

+Have put more Photos on - On my static photo sites - Generated with a #bash script

+

+irregular.ninja

+

+
In Go, passing pointers are not automatically ...


+

+In Go, passing pointers are not automatically faster than values. Pointers often force the memory to be allocated on the heap, adding GC overhad. With values, Go can determine whether to put the memory on the stack instead. But with large structs/objects (how you want to call them) or if you want to modify state, then pointers are the semantic to use. #golang

+

+blog.boot.dev/golang/pointers-faster-than-values/

+

+
Myself being part of an on-call rotations over ...


+

+Myself being part of an on-call rotations over my whole professional life, just have learned this lesson "Tell people who are new to on-call: Just have fun" :-) This is a neat blog post to read:

+

+ntietz.com/blog/what-i-tell-people-new-to-oncall/

+

+
Feels good to code in my old love #Perl again ...


+

+Feels good to code in my old love #Perl again after a while. I am implementing a log parser for generating site stats of my personal homepage! :-) @Perl

+

+
This is an interactive summary of the Go ...


+

+This is an interactive summary of the Go release, with a lot of examples utilising iterators in the slices and map packages. Love it! #golang

+

+antonz.org/go-1-23/

+

+
December 2024


+

+
Thats unexpected, you cant remove a NaN key ...


+

+Thats unexpected, you cant remove a NaN key from a map without clearing it! #golang

+

+unexpected-go.com/you-cant-remove-a-nan-key-from-a-map-without-clearing-it.html

+

+
My second blog post about revamping my home lab ...


+

+My second blog post about revamping my home lab a little bit just hit the net. #FreeBSD #ZFS #n100 #k8s #k3s #kubernetes

+

+foo.zone/gemfeed/2024-12-03-f3s-kubernetes-with-freebsd-part-2.gmi (Gemini)

+foo.zone/gemfeed/2024-12-03-f3s-kubernetes-with-freebsd-part-2.html

+

+
Very insightful article about tech hiring in ...


+

+Very insightful article about tech hiring in the age of LLMs. As an interviewer, I have experienced some of the scrnarios already first hand...

+

+newsletter.pragmaticengineer.com/p/how-genai-changes-tech-hiring

+

+
for #bpf #ebpf performance debugging, have ...


+

+for #bpf #ebpf performance debugging, have a look at bpftop from Netflix. A neat tool showing you the estimated CPU time and other performance statistics for all the BPF programs currently loaded into the #linux kernel. Highly recommend!

+

+github.com/Netflix/bpftop

+

+
89 things he/she knows about Git commits is a ...


+

+89 things he/she knows about Git commits is a neat list of #Git wisdoms

+

+www.jvt.me/posts/2024/07/12/things-know-commits/

+

+
I found that working on multiple side projects ...


+

+I found that working on multiple side projects concurrently is better than concentrating on just one. This seems inefficient at first, but whenever you tend to lose motivation, you can temporarily switch to another one with full élan. However, remember to stop starting and start finishing. This doesn't mean you should be working on 10+ (and a growing list of) side projects concurrently! Select your projects and commit to finishing them before starting the next thing. For example, my current limit of concurrent side projects is around five.

+

+
Agreed? Agreed. Besides #Ruby, I would also ...


+

+Agreed? Agreed. Besides #Ruby, I would also add #RakuLang and #Perl @Perl to the list of languages that are great for shell scripts - "Making Easy Things Easy and Hard Things Possible"

+

+lucasoshiro.github.io/posts-en/2024-06-17-ruby-shellscript/

+

+
Plan9 assembly format in Go, but wait, it's not ...


+

+Plan9 assembly format in Go, but wait, it's not the Operating System Plan9! #golang #rabbithole

+

+www.osnews.com/story/140941/go-plan9-memo-speeding-up-calculations-450/

+

+
This is a neat blog post about the Helix text ...


+

+This is a neat blog post about the Helix text editor, to which I personally switched around a year ago (from NeoVim). I should blog about my experience as well. To summarize: I am using it together with the terminal multiplexer #tmux. It doesn't bother me that Helix is purely terminal-based and therefore everything has to be in the same font. #HelixEditor

+

+jonathan-frere.com/posts/helix/

+

+
This blog post is basically a rant against ...


+

+This blog post is basically a rant against DataDog... Personally, I don't have much experience with DataDog (actually, I have never used it), but one reason to work with logs at my day job (with over 2,000 physical server machines) and to be cost-effective is by using dtail! #dtail #logs #logmanagement

+

+crys.site/blog/2024/reinventint-the-weel/

+dtail.dev

+

+
Quick trick to get Helix themes selected ...


+

+Quick trick to get Helix themes selected randomly #HelixEditor

+

+foo.zone/gemfeed/2024-12-15-random-helix-themes.gmi (Gemini)

+foo.zone/gemfeed/2024-12-15-random-helix-themes.html

+

+
Example where complexity attacks you from ...


+

+Example where complexity attacks you from behind #k8s #kubernetes #OpenAI

+

+surfingcomplexity.blog/2024/12/14/quic..-..ecent-openai-public-incident-write-up/

+

+
LLMs for Ops? Summaries of logs, probabilities ...


+

+LLMs for Ops? Summaries of logs, probabilities about correctness, auto-generating Ansible, some uses cases are there. Wouldn't trust it fully, though.

+

+youtu.be/WodaffxVq-E?si=noY0egrfl5izCSQI

+

+
Excellent article about your dream Product ...


+

+Excellent article about your dream Product Manager: Why every software team needs a product manager to thrive via @wallabagapp

+

+testdouble.com/insights/why-product-ma..-..s-accelerate-improve-software-delivery

+

+
I just finished reading all chapters of CPU ...


+

+I just finished reading all chapters of CPU land: ... not claiming to remember every detail, but it is a great refresher how CPUs and operating systems actually work under the hood when you execute a program, which we tend to forget in our higher abstraction world. I liked the "story" and some of the jokes along the way! Size wise, it is pretty digestable (not talking about books, but only 7 web articles/chapters)! #cpu #linux #unix #kernel #macOS

+

+cpu.land/

+

+
Indeed, useful to know this stuff! #sre ...


+

+Indeed, useful to know this stuff! #sre

+

+biriukov.dev/docs/resolver-dual-stack-..-..resolvers-and-dual-stack-applications/

+

+
It's the small things, which make Unix like ...


+

+It's the small things, which make Unix like systems, like GNU/Linux, interesting. Didn't know about this #GNU #Tar behaviour yet:

+

+xeiaso.net/notes/2024/pop-quiz-tar/

+

+
My New Year's resolution is not to start any ...


+

+My New Year's resolution is not to start any new non-fiction books (or only very few) but to re-read and listen to my favorites, which I read to reflect on and see things from different perspectives. Every time you re-read a book, you gain new insights.<nil>17491

+

+Other related posts:

+

+2025-01-01 Posts from October to December 2024 (You are currently reading this)

+

+E-Mail your comments to paul@nospam.buetow.org :-)

+

+Back to the main site

+            

+        
+    
diff --git a/index.gmi b/index.gmi
index 6af7e9f9..524b38e0 100644
--- a/index.gmi
+++ b/index.gmi
@@ -1,6 +1,6 @@
 # foo.zone
 
-> This site was generated at 2025-02-21T11:07:02+02:00 by `Gemtexter`
+> This site was generated at 2025-02-21T11:13:28+02:00 by `Gemtexter`
 
 Welcome to the foo.zone. Everything you read on this site is my personal opinion and experience. You can call me a Linux/*BSD enthusiast and hobbyist. I mainly write about tech, IT, programming and sometimes also about self-improvement here. And I also like coding.
 
diff --git a/notes/fluent-forever.gmi b/notes/fluent-forever.gmi
index b053c9a8..cff5b65f 100644
--- a/notes/fluent-forever.gmi
+++ b/notes/fluent-forever.gmi
@@ -1,5 +1,79 @@
+# "Fluent Forever" book notes
+
 These are my personal book notes from Gabriel Wyner's "Fluent Forever: How to learn any Language fast and never forget it" They are for myself, but I hope they might be useful to you too.
 
+## Introduction to Language Learning
+
+Fluent Forever is a unique approach to mastering a new language, emphasizing the importance of frequent exposure, effective memorization techniques, and playful engagement with the language. Here are detailed notes on how to make the language learning process more efficient and enjoyable.
+
+## Frequency Dictionary
+
+* Focus on the 2,500 most frequent words in any language.
+* Use Anki flashcards to memorize the first 100 of these words effectively.
+
+## Phrase Book
+
+* Having a phrase book can be helpful. If you don't have one, consider acquiring it for quick reference.
+
+## Learning Methods and Strategies
+
+* **Don't Translate:** Avoid relying on translations. Even when using flashcards, strive for direct associations within the target language.
+* **Enjoy the Process:** Only when you enjoy the learning process will you consistently succeed, much like the endorphins motivating a person to maintain a six-pack.
+* **Playful Engagement:** Watch movies and series in the target language; engagement should be playful, not just safe.
+
+## Additional Resources
+
+* Visit fluentforever.com/languages for additional resources.
+* Use two types of dictionaries: bilingual for translation and monolingual for deeper understanding.
+* Consider using a private tutor for personalized guidance.
+
+## Memory and Recall Techniques
+
+* **Spaced Repetition:** Focus more on recalling information rather than reviewing it. This technique drastically improves retention by challenging your memory.
+* **Memory Techniques:** Make new words memorable by connecting them with sounds, images, and personal experiences. The saying goes, "neurons that fire together wire together."
+* **Personal Connections:** The strongest memory connections are personal; relate new vocabulary to personal experiences or memories.
+* **Imagery:** Use Google Images to find pictures connected to new words. Visual aids make recall more effective.
+
+## Vocabulary Acquisition
+
+* **Incremental Learning:** Start with easier, concrete words and gradually learn more abstract ones.
+* **Recall Over Review:** Spend the majority of your study time on recall. It's best to recall words just before you forget them.
+
+## Timing and Efficiency
+
+* **Optimization of Recall:** Correct timing is crucial, neither too early (to avoid overwhelming yourself with too many words) nor too late (when completely forgotten).
+* **Challenge and Interest:** Ensure learning remains challenging and interesting to encourage effective retention.
+* **Flashcards:** Create personal flashcards over using pre-made ones; this ensures relevance and meaning for you personally. Using images in flashcards aids memorability.
+
+## Sound and Pronunciation
+
+* **Pronunciation Practice:** If unfamiliar with a language's sounds, you are effectively learning two languages. Practice as early as possible, focusing on minimal pairs to discern subtle differences.
+* **International Phonetic Alphabet (IPA):** Learn pronunciation through the IPA to avoid relying solely on spelling where pronunciation is not straightforward.
+* **Backchaining Technique:** Learn pronunciation by practicing from the end of a word to the beginning.
+
+## Comprehensive Input
+
+* Language learning requires diverse inputs: a combination of reading, listening, and speaking activities.
+* Don't rely solely on one medium, like books or TV. Supplement with active conversation and real-life interactions.
+
+## Writing and Grammar
+
+* Regular writing practice is crucial for reinforcing grammatical understanding. Get your writing corrected to identify and learn from mistakes.
+* Use grammar books for reference, but focus on creating your examples and flashcards to internalize rules.
+
+## Media and Real-life Exposure
+
+* Listen to native speakers and watch shows without subtitles to immerse yourself fully in the language.
+* Begin with carefully selected series or films and gradually progress to podcasts and audiobooks.
+
+## Continuous Practice
+
+* Regular practice and courage to make mistakes resemble children's language acquisition, offering a swift path to fluency.
+* Focus on your interests and tailor your learning toward the vocabulary and contexts relevant to you.
+
+## Summary
+
+Learning a language requires dedication, strategy, and enjoyment. By leveraging techniques like spaced repetition, personal associations, and playful engagement, language acquisition becomes more effective and sustainable.
 
 E-Mail your comments to `paul@nospam.buetow.org` :-)
 
diff --git a/notes/index.gmi b/notes/index.gmi
index 4ad174ec..6a781844 100644
--- a/notes/index.gmi
+++ b/notes/index.gmi
@@ -14,9 +14,10 @@
 => ./never-split-the-difference.gmi 'Never split the difference' book notes
 => ./mind-management.gmi 'Mind Management' book notes
 => ./mental-combat.gmi 'Mental Combat' book notes
-=> ./love-people-use-things.gmi Love People, Use Things
+=> ./love-people-use-things.gmi 'Love People, Use Things' book notes
 => ./joy-on-demand.gmi 'Joy On Domand' book notes
 => ./influence-wihout-authority.gmi 'Influence without Authority' book notes
+=> ./fluent-forever.gmi 'Fluent Forever' book notes
 => ./eat-that-frog.gmi 'Eat That Frog' book notes
 => ./career-guide-and-soft-skills.gmi 'Software Developmers Career Guide and Soft Skills' book notes
 => ./a-monks-guide-to-happiness.gmi 'A Monk's Guide to Happiness' book notes
diff --git a/notes/love-people-use-things.gmi b/notes/love-people-use-things.gmi
index 6c1191fb..790579d1 100644
--- a/notes/love-people-use-things.gmi
+++ b/notes/love-people-use-things.gmi
@@ -1,4 +1,4 @@
-# Love People, Use Things
+# "Love People, Use Things" book notes
 
 These are my personal book notes from "The Minimalist"'s "Love People, Use Things" They are for myself, but I hope they might be useful to you too.
 
diff --git a/uptime-stats.gmi b/uptime-stats.gmi
index c71995c6..33dd2ac8 100644
--- a/uptime-stats.gmi
+++ b/uptime-stats.gmi
@@ -1,6 +1,6 @@
 # My machine uptime stats
 
-> This site was last updated at 2025-02-21T11:07:08+02:00
+> This site was last updated at 2025-02-21T11:13:36+02:00
 
 The following stats were collected via `uptimed` on all of my personal computers over many years and the output was generated by `guprecords`, the global uptime records stats analyser of mine.
 
-- 
cgit v1.2.3


From 30b9c0e750f8682d2cec1955bedd38739c664de1 Mon Sep 17 00:00:00 2001
From: Paul Buetow 
Date: Fri, 21 Feb 2025 17:08:02 +0200
Subject: Update content for gemtext

---
 about/resources.gmi                                |  176 +--
 gemfeed/atom.xml.tmp                               | 1265 --------------------
 index.gmi                                          |    2 +-
 notes/97-things-every-sre-should-know.gmi          |  311 +++++
 notes/97-things-every-sre-should-know.gmi.tpl      |  289 +++++
 notes/implementing-service-level-objectives.gmi    |   83 ++
 .../implementing-service-level-objectives.gmi.tpl  |   74 ++
 notes/index.gmi                                    |    3 +
 notes/site-reliability-engineering.gmi             |   90 ++
 notes/site-reliability-engineering.gmi.tpl         |   74 ++
 uptime-stats.gmi                                   |    2 +-
 11 files changed, 1014 insertions(+), 1355 deletions(-)
 delete mode 100644 gemfeed/atom.xml.tmp
 create mode 100644 notes/97-things-every-sre-should-know.gmi
 create mode 100644 notes/97-things-every-sre-should-know.gmi.tpl
 create mode 100644 notes/implementing-service-level-objectives.gmi
 create mode 100644 notes/implementing-service-level-objectives.gmi.tpl
 create mode 100644 notes/site-reliability-engineering.gmi
 create mode 100644 notes/site-reliability-engineering.gmi.tpl

diff --git a/about/resources.gmi b/about/resources.gmi
index 8e3a0a1c..030e3b0f 100644
--- a/about/resources.gmi
+++ b/about/resources.gmi
@@ -35,101 +35,101 @@ You won't find any links on this site because, over time, the links will break.
 
 In random order:
 
-* The KCNA (Kubernetes and Cloud Native Associate) Book; Nigel Poulton
-* C++ Programming Language; Bjarne Stroustrup;
-* Learn You a Haskell for Great Good!; Miran Lipovaca; No Starch Press
-* 21st Century C: C Tips from the New School; Ben Klemens; O'Reilly
-* Leanring eBPF; Liz Rice; O'Reilly
-* 100 Go Mistakes and How to Avoid Them; Teiva Harsanyi; Manning Publications
-* Raku Recipes; J.J. Merelo; Apress
-* The DevOps Handbook; Gene Kim, Jez Humble, Patrick Debois, John Willis; Audible
-* Go Brain Teasers - Exercise Your Mind; Miki Tebeka; The Pragmatic Programmers
-* DNS and BIND; Cricket Liu; O'Reilly
-* Effective awk programming; Arnold Robbins; O'Reilly
-* The Go Programming Language; Alan A. A. Donovan; Addison-Wesley Professional
-* DevOps And Site Reliability Engineering Handbook; Stephen Fleming; Audible
-* Pro Puppet; James Turnbull, Jeffrey McCune; Apress
+* Learn You Some Erlang for Great Good; Fred Herbert; No Starch Press
+* Clusterbau mit Linux-HA; Michael Schwartzkopff; O'Reilly
+* Programming Perl aka "The Camel Book"; Tom Christiansen, brian d foy, Larry Wall & Jon Orwant; O'Reilly
+* Think Raku (aka Think Perl 6); Laurent Rosenfeld, Allen B. Downey; O'Reilly
+* Java ist auch eine Insel; Christian Ullenboom; 
 * The Kubernetes Book; Nigel Poulton; Unabridged Audiobook
 * The Pragmatic Programmer; David Thomas; Addison-Wesley
-* Site Reliability Engineering; How Google runs production systems; O'Reilly
-* Kubernetes Cookbook; Sameer Naik, Sébastien Goasguen, Jonathan Michaux; O'Reilly
-* Higher Order Perl; Mark Dominus; Morgan Kaufmann
-* Hands-on Infrastructure Monitoring with Prometheus; Joel Bastos, Pedro Araujo; Packt 
-* Learn You Some Erlang for Great Good; Fred Herbert; No Starch Press
-* Object-Oriented Programming with ANSI-C; Axel-Tobias Schreiner
-* Polished Ruby Programming; Jeremy Evans; Packt Publishing
-* Amazon Web Services in Action; Michael Wittig and Andreas Wittig; Manning Publications
 * Effective Java; Joshua Bloch; Addison-Wesley Professional
-* 97 things every SRE should know; Emil Stolarsky, Jaime Woo; O'Reilly
 * Systems Performance Tuning; Gian-Paolo D. Musumeci and others...; O'Reilly
-* Developing Games in Java; David Brackeen and others...; New Riders
+* Ultimate Go Notebook; Bill Kennedy
 * Systemprogrammierung in Go; Frank Müller; dpunkt
-* Programming Perl aka "The Camel Book"; Tom Christiansen, brian d foy, Larry Wall & Jon Orwant; O'Reilly
-* Tmux 2: Productive Mouse-free Development; Brain P. Hogan; The Pragmatic Programmers 
-* Distributed Systems: Principles and Paradigms; Andrew S. Tanenbaum; Pearson
-* Concurrency in Go; Katherine Cox-Buday; O'Reilly
+* Go Brain Teasers - Exercise Your Mind; Miki Tebeka; The Pragmatic Programmers
+* Polished Ruby Programming; Jeremy Evans; Packt Publishing
+* Perl New Features; Joshua McAdams, brian d foy; Perl School
+* 21st Century C: C Tips from the New School; Ben Klemens; O'Reilly
+* 100 Go Mistakes and How to Avoid Them; Teiva Harsanyi; Manning Publications
 * Modern Perl; Chromatic ; Onyx Neon Press
-* Ultimate Go Notebook; Bill Kennedy
-* Think Raku (aka Think Perl 6); Laurent Rosenfeld, Allen B. Downey; O'Reilly
+* Distributed Systems: Principles and Paradigms; Andrew S. Tanenbaum; Pearson
+* Terraform Cookbook; Mikael Krief; Packt Publishing
+* The DevOps Handbook; Gene Kim, Jez Humble, Patrick Debois, John Willis; Audible
+* Raku Recipes; J.J. Merelo; Apress
+* C++ Programming Language; Bjarne Stroustrup;
 * Funktionale Programmierung; Peter Pepper; Springer
+* Raku Fundamentals; Moritz Lenz; Apress
+* Amazon Web Services in Action; Michael Wittig and Andreas Wittig; Manning Publications
+* Higher Order Perl; Mark Dominus; Morgan Kaufmann
+* DevOps And Site Reliability Engineering Handbook; Stephen Fleming; Audible
 * The Practise of System and Network Administration; Thomas A. Limoncelli, Christina J. Hogan, Strata R. Chalup; Addison-Wesley Professional Pro Git; Scott Chacon, Ben Straub; Apress
+* Site Reliability Engineering; How Google runs production systems; O'Reilly
+* Leanring eBPF; Liz Rice; O'Reilly
+* Effective awk programming; Arnold Robbins; O'Reilly
+* Pro Puppet; James Turnbull, Jeffrey McCune; Apress
+* Learn You a Haskell for Great Good!; Miran Lipovaca; No Starch Press
+* Object-Oriented Programming with ANSI-C; Axel-Tobias Schreiner
 * The Docker Book; James Turnbull; Kindle
-* Java ist auch eine Insel; Christian Ullenboom; 
-* Clusterbau mit Linux-HA; Michael Schwartzkopff; O'Reilly
-* Raku Fundamentals; Moritz Lenz; Apress
-* Perl New Features; Joshua McAdams, brian d foy; Perl School
-* Terraform Cookbook; Mikael Krief; Packt Publishing
+* The KCNA (Kubernetes and Cloud Native Associate) Book; Nigel Poulton
+* Kubernetes Cookbook; Sameer Naik, Sébastien Goasguen, Jonathan Michaux; O'Reilly
+* Hands-on Infrastructure Monitoring with Prometheus; Joel Bastos, Pedro Araujo; Packt 
+* Tmux 2: Productive Mouse-free Development; Brain P. Hogan; The Pragmatic Programmers 
+* Concurrency in Go; Katherine Cox-Buday; O'Reilly
+* 97 things every SRE should know; Emil Stolarsky, Jaime Woo; O'Reilly
+* The Go Programming Language; Alan A. A. Donovan; Addison-Wesley Professional
+* DNS and BIND; Cricket Liu; O'Reilly
 * Data Science at the Command Line; Jeroen Janssens; O'Reilly
+* Developing Games in Java; David Brackeen and others...; New Riders
 
 ## Technical references
 
 I didn't read them from the beginning to the end, but I am using them to look up things. The books are in random order:
 
-* Relayd and Httpd Mastery; Michael W Lucas
 * BPF Performance Tools - Linux System and Application Observability, Brendan Gregg; Addison Wesley
+* Implementing Service Level Objectives; Alex Hidalgo; O'Reilly
+* Algorithms; Robert Sedgewick, Kevin Wayne; Addison Wesley
 * The Linux Programming Interface; Michael Kerrisk; No Starch Press 
+* Relayd and Httpd Mastery; Michael W Lucas
 * Understanding the Linux Kernel; Daniel P. Bovet, Marco Cesati; O'Reilly
-* Algorithms; Robert Sedgewick, Kevin Wayne; Addison Wesley
 * Groovy Kurz & Gut; Joerg Staudemeier; O'Reilly
-* Implementing Service Level Objectives; Alex Hidalgo; O'Reilly
 
 ## Self-development and soft-skills books
 
 In random order:
 
-* Search Inside Yourself - The Unexpected path to Achieving Success, Happiness (and World Peace); Chade-Meng Tan, Daniel Goleman, Jon Kabat-Zinn; HarperOne
-* The Obstacle Is The Way; Ryan Holiday; Profile Books Ltd
-* Psycho-Cybernetics; Maxwell Maltz; Perigee Books
-* Who Moved My Cheese?; Dr. Spencer Johnson; Vermilion 
-* Eat That Frog; Brian Tracy
-* The Good Enough Job; Simone Stolzoff; Ebury Edge
-* Stop starting, start finishing; Arne Roock; Lean-Kanban University  
-* Digital Minimalism; Cal Newport; Portofolio Penguin
-* Solve for Happy; Mo Gawdat
-* Slow Productivity; Cal Newport; Penguin Random House
+* The Complete Software Developer's Career Guide; John Sonmez; Unabridged Audiobook
+* Ultralearning; Anna Laurent; Self-published via Amazon
+* The Daily Stoic; Ryan Holiday, Stephen Hanselman; Profile Books
 * So Good They Can't Ignore You; Cal Newport; Business Plus
-* The Joy of Missing Out; Christina Crook; New Society Publishers
+* Atomic Habits; James Clear; Random House Business
 * Ultralearning; Scott Young; Thorsons
 * Staff Engineer: Leadership beyond the management track; Will Larson; Audible
-* Deep Work; Cal Newport; Piatkus
-* The Bullet Journal Method; Ryder Carroll; Fourth Estate
 * The 7 Habits Of Highly Effective People; Stephen R. Covey; Simon & Schuster UK
-* Eat That Frog!; Brian Tracy; Hodder Paperbacks
-* Atomic Habits; James Clear; Random House Business
-* Getting Things Done; David Allen
-* The Daily Stoic; Ryan Holiday, Stephen Hanselman; Profile Books
-* Consciousness: A Very Short Introduction; Susan Blackmore; Oxford Uiversity Press
-* Influence without Authority; A. Cohen, D. Bradford; Wiley
+* Who Moved My Cheese?; Dr. Spencer Johnson; Vermilion 
+* The Off Switch; Mark Cropley; Virgin Books
 * The Power of Now; Eckhard Tolle; Yellow Kite
-* 101 Essays that change the way you think; Brianna Wiest; Audible
+* The Joy of Missing Out; Christina Crook; New Society Publishers
+* The Bullet Journal Method; Ryder Carroll; Fourth Estate
+* Influence without Authority; A. Cohen, D. Bradford; Wiley
+* Consciousness: A Very Short Introduction; Susan Blackmore; Oxford Uiversity Press
+* The Good Enough Job; Simone Stolzoff; Ebury Edge
+* Eat That Frog!; Brian Tracy; Hodder Paperbacks
 * Soft Skills; John Sommez; Manning Publications
-* Ultralearning; Anna Laurent; Self-published via Amazon
-* The Off Switch; Mark Cropley; Virgin Books
 * Time Management for System Administrators; Thomas A. Limoncelli; O'Reilly
+* Search Inside Yourself - The Unexpected path to Achieving Success, Happiness (and World Peace); Chade-Meng Tan, Daniel Goleman, Jon Kabat-Zinn; HarperOne
+* Getting Things Done; David Allen
+* Psycho-Cybernetics; Maxwell Maltz; Perigee Books
+* The Obstacle Is The Way; Ryan Holiday; Profile Books Ltd
+* Never Split the Difference; Chris Voss, Tahl Raz; Random House Business
+* 101 Essays that change the way you think; Brianna Wiest; Audible
+* Digital Minimalism; Cal Newport; Portofolio Penguin
+* Solve for Happy; Mo Gawdat
+* Eat That Frog; Brian Tracy
 * The Phoenix Project - A Novel About IT, DevOps, and Helping your Business Win; Gene Kim and Kevin Behr; Trade Select
+* Stop starting, start finishing; Arne Roock; Lean-Kanban University  
+* Deep Work; Cal Newport; Piatkus
 * Buddah and Einstein walk into a Bar; Guy Joseph Ale, Claire Bloom; Blackstone Publishing
-* Never Split the Difference; Chris Voss, Tahl Raz; Random House Business
-* The Complete Software Developer's Career Guide; John Sonmez; Unabridged Audiobook
+* Slow Productivity; Cal Newport; Penguin Random House
 
 => ../notes/index.gmi Here are notes of mine for some of the books
 
@@ -137,30 +137,30 @@ In random order:
 
 Some of these were in-person with exams; others were online learning lectures only. In random order:
 
-* Scripting Vim; Damian Conway; O'Reilly Online
-* Protocol buffers; O'Reilly Online
-* Functional programming lecture; Remote University of Hagen
-* MySQL Deep Dive Workshop; 2-day on-site training
 * Apache Tomcat Best Practises; 3-day on-site training
 * Structure and Interpretation of Computer Programs; Harold Abelson and more...; 
-* Algorithms Video Lectures; Robert Sedgewick; O'Reilly Online
 * Red Hat Certified System Administrator; Course + certification (Although I had the option, I decided not to take the next course as it is more effective to self learn what I need)
 * The Ultimate Kubernetes Bootcamp; School of Devops; O'Reilly Online
-* F5 Loadbalancers Training; 2-day on-site training; F5, Inc. 
 * Developing IaC with Terraform (with Live Lessons); O'Reilly Online
+* MySQL Deep Dive Workshop; 2-day on-site training
+* Functional programming lecture; Remote University of Hagen
+* Protocol buffers; O'Reilly Online
+* Scripting Vim; Damian Conway; O'Reilly Online
+* Cloud Operations on AWS - Learn how to configure, deploy, maintain, and troubleshoot your AWS environments; 3-day online live training with labs; Amazon
+* The Well-Grounded Rubyist Video Edition; David. A. Black; O'Reilly Online
+* F5 Loadbalancers Training; 2-day on-site training; F5, Inc. 
 * AWS Immersion Day; Amazon; 1-day interactive online training 
+* Algorithms Video Lectures; Robert Sedgewick; O'Reilly Online
 * Ultimate Go Programming; Bill Kennedy; O'Reilly Online
 * Linux Security and Isolation APIs Training; Michael Kerrisk; 3-day on-site training
-* The Well-Grounded Rubyist Video Edition; David. A. Black; O'Reilly Online
-* Cloud Operations on AWS - Learn how to configure, deploy, maintain, and troubleshoot your AWS environments; 3-day online live training with labs; Amazon
 
 ## Technical guides
 
 These are not whole books, but guides (smaller or larger) which I found very useful. in random order:
 
 * Raku Guide at https://raku.guide  
-* Advanced Bash-Scripting Guide 
 * How CPUs work at https://cpu.land
+* Advanced Bash-Scripting Guide 
 
 ## Podcasts
 
@@ -168,46 +168,46 @@ These are not whole books, but guides (smaller or larger) which I found very use
 
 In random order:
 
-* Maintainable
-* Deep Questions with Cal Newport
+* The Pragmatic Engineer Podcast
 * BSD Now
-* Fork Around And Find Out
 * Hidden Brain
-* The Changelog Podcast(s)
+* Fork Around And Find Out
+* Deep Questions with Cal Newport
+* Fallthrough [Golang]
 * Dev Interrupted
-* Cup o' Go [Golang]
-* Backend Banter
-* The Pragmatic Engineer Podcast
 * The ProdCast (Google SRE Podcast)
-* Fallthrough [Golang]
+* Maintainable
+* Backend Banter
+* The Changelog Podcast(s)
+* Cup o' Go [Golang]
 
 ### Podcasts I liked
 
 I liked them but am not listening to them anymore. The podcasts have either "finished" (no more episodes) or I stopped listening to them due to time constraints or a shift in my interests.
 
 * Go Time (predecessor of fallthrough)
-* Java Pub House
 * CRE: Chaosradio Express [german]
-* FLOSS weekly
-* Ship It (predecessor of Fork Around And Find Out)
 * Modern Mentor
+* Ship It (predecessor of Fork Around And Find Out)
+* Java Pub House
+* FLOSS weekly
 
 ## Newsletters I like
 
 This is a mix of tech and non-tech newsletters I am subscribed to. In random order:
 
-* The Pragmatic Engineer
-* Golang Weekly
 * Applied Go Weekly Newsletter
 * Monospace Mentor
-* The Valuable Dev
-* The Imperfectionist
+* The Pragmatic Engineer
+* byteSizeGo
+* Register Spill
+* Golang Weekly
 * VK Newsletter
 * Ruby Weekly
+* The Valuable Dev
 * Andreas Brandhorst Newsletter (Sci-Fi author)
-* Register Spill
-* byteSizeGo
 * Changelog News
+* The Imperfectionist
 
 # Formal education
 
diff --git a/gemfeed/atom.xml.tmp b/gemfeed/atom.xml.tmp
deleted file mode 100644
index 03f1b688..00000000
--- a/gemfeed/atom.xml.tmp
+++ /dev/null
@@ -1,1265 +0,0 @@
-
-
-    2025-02-21T11:13:36+02:00
-    foo.zone feed
-    To be in the .zone!
-    
-    
-    gemini://foo.zone/
-    
-        Random Weird Things - Part Ⅱ
-        
-        gemini://foo.zone/gemfeed/2025-02-08-random-weird-things-ii.gmi
-        2025-02-08T11:06:16+02:00
-        
-            Paul Buetow aka snonux
-            paul@dev.buetow.org
-        
-        Every so often, I come across random, weird, and unexpected things on the internet. I thought it would be neat to share them here from time to time. This is the second run.
-        
-            

-                
Random Weird Things - Part Ⅱ


-

-Published at 2025-02-08T11:06:16+02:00

-

-Every so often, I come across random, weird, and unexpected things on the internet. I thought it would be neat to share them here from time to time. This is the second run.

-

-2024-07-05 Random Weird Things - Part Ⅰ

-2025-02-08 Random Weird Things - Part Ⅱ (You are currently reading this)

-

-
-/\_/\           /\_/\
-( o.o ) WHOA!! ( o.o )
-> ^ <           > ^ <
-/   \    MOEEW! /   \
-/______\       /______\
-

-

-
Table of Contents


-

-

-
11. The SQLite codebase is a gem


-

-Check this out:

-

-SQLite Gem

-

-Source:

-

-https://wetdry.world/@memes/112717700557038278

-

-
Go Programming


-

-
12. Official Go font


-

-The Go programming language has an official font called "Go Font." It was created to complement the aesthetic of the Go language, ensuring clear and legible rendering of code. The font includes a monospace version for code and a proportional version for general text, supporting consistent look and readability in Go-related materials and development environments. 

-

-Check out some Go code displayed using the Go font:

-

-Go font code

-

-https://go.dev/blog/go-fonts

-

-The design emphasizes simplicity and readability, reflecting Go's philosophy of clarity and efficiency.

-

-I found it interesting and/or weird, as Go is a programming language. Why should it bother having its own font? I have never seen another open-source project like Go do this. But I also like it. Maybe I will use it in the future for this blog :-) 

-

-
13. Go functions can have methods


-

-Functions on struct types? Well, know. Functions on types like int and string? It's also known of, but a bit lesser. Functions on function types? That sounds a bit funky, but it's possible, too! For demonstration, have a look at this snippet:

-

-
-
package main
-
-import "log"
-
-type fun func() string
-
-func (f fun) Bar() string {
-        return "Bar"
-}
-
-func main() {
-        var f fun = func() string {
-                return "Foo"
-        }
-        log.Println("Example 1: ", f())
-        log.Println("Example 2: ", f.Bar())
-        log.Println("Example 3: ", fun(f.Bar).Bar())
-        log.Println("Example 4: ", fun(fun(f.Bar).Bar).Bar())
-}
-

-

-It runs just fine:

-

-
-
❯ go run main.go
-2025/02/07 22:56:14 Example 1:  Foo
-2025/02/07 22:56:14 Example 2:  Bar
-2025/02/07 22:56:14 Example 3:  Bar
-2025/02/07 22:56:14 Example 4:  Bar
-

-

-
macOS


-

-For personal computing, I don't use Apple, but I have to use it for work. 

-

-
14. ß and ss are treated the same


-

-Know German? In German, the letter "sarp s" is written as ß. ß is treated the same as ss on macOS.

-

-On a case-insensitive file system like macOS, not only are uppercase and lowercase letters treated the same, but non-Latin characters like the German "ß" are also considered equivalent to their Latin counterparts (in this case, "ss").

-

-So, even though "Maß" and "Mass" are not strictly equivalent, the macOS file system still treats them as the same filename due to its handling of Unicode characters. This can sometimes lead to unexpected behaviour. Check this out:

-

-
-
❯ touch Maß
-❯ ls -l
--rw-r--r--@ 1 paul  wheel  0 Feb  7 23:02 Maß
-❯ touch Mass
-❯ ls -l
--rw-r--r--@ 1 paul  wheel  0 Feb  7 23:02 Maß
-❯ rm Mass
-❯ ls -l
-
-❯ touch Mass
-❯ ls -ltr
--rw-r--r--@ 1 paul  wheel  0 Feb  7 23:02 Mass
-❯ rm Maß
-❯ ls -l
-
-

-

-
15. Colon as file path separator


-

-MacOS can use the colon as a file path separator on its ADFS (file system). A typical ADFS file pathname on a hard disc might be:

-

-
-ADFS::4.$.Documents.Techwriter.Myfile
-

-

-I can't reproduce this on my (work) Mac, though, as it now uses the APFS file system. In essence, ADFS is an older file system, while APFS is a contemporary file system optimized for Apple's modern devices.

-

-https://social.jvns.ca/@b0rk/113041293527832730

-

-
16. Polyglots - programs written in multiple languages


-

-A coding polyglot is a program or script written so that it can be executed in multiple programming languages without modification. This is typically achieved by leveraging syntax overlaps or crafting valid and meaningful code in each targeted language. Polyglot programs are often created as a challenge or for demonstration purposes to showcase language similarities or clever coding techniques.

-

-Check out my very own polyglot:

-

-The fibonatti.pl.c Polyglot

-

-
17. Languages, where indices start at 1


-

-Array indices start at 1 instead of 0 in some programming languages, known as one-based indexing. This can be controversial because zero-based indexing is more common in popular languages like C, C++, Java, and Python. One-based indexing can lead to off-by-one errors when developers switch between languages with different indexing schemes.

-

-Languages with One-Based Indexing:

-

-
    
-
  • Fortran
    • 
-
  • MATLAB
    • 
-
  • Lua
    • 
-
  • R (for vectors and lists)
    • 
-
  • Smalltalk
    • 
-
  • Julia (by default, although zero-based indexing is also possible)
    • 
-


-foo.lua example:

-

-
-
arr = {10, 20, 30, 40, 50}
-print(arr[1]) -- Accessing the first element
-

-

-
-
❯ lua foo.lua
-10
-

-

-One-based indexing is more natural for human-readable, mathematical, and theoretical contexts, where counting traditionally starts from one.

-

-
18. Perl Poetry


-

-Perl Poetry is a playful and creative practice within the programming community where Perl code is written as a poem. These poems are crafted to be syntactically valid Perl code and make sense as poetic text, often with whimsical or humorous intent. This showcases Perl's flexibility and expressiveness, as well as the creativity of its programmers.

-

-See this Poetry of my own; the Perl interpreter does not yield any syntax error parsing that. But also, the Peom doesn't do anything useful then executed:

-

-
-
# (C) 2006 by Paul C. Buetow
-
-Christmas:{time;#!!!
-
-Children: do tell $wishes;
-
-Santa: for $each (@children) { 
-BEGIN { read $each, $their, wishes and study them; use Memoize#ing
-
-} use constant gift, 'wrapping'; 
-package Gifts; pack $each, gift and bless $each and goto deliver
-or do import if not local $available,!!! HO, HO, HO;
-
-redo Santa, pipe $gifts, to_childs;
-redo Santa and do return if last one, is, delivered; 
-
-deliver: gift and require diagnostics if our $gifts ,not break;
-do{ use NEXT; time; tied $gifts} if broken and dump the, broken, ones;
-The_children: sleep and wait for (each %gift) and try { to => untie $gifts };
-
-redo Santa, pipe $gifts, to_childs;
-redo Santa and do return if last one, is, delivered; 
-
-The_christmas_tree: formline s/ /childrens/, $gifts;
-alarm and warn if not exists $Christmas{ tree}, @t, $ENV{HOME};  
-write <<EMail
- to the parents to buy a new christmas tree!!!!111
- and send the
-EMail
-;wait and redo deliver until defined local $tree;
-
-redo Santa, pipe $gifts, to_childs;
-redo Santa and do return if last one, is, delivered ;}
-
-END {} our $mission and do sleep until next Christmas ;}
-
-__END__
-
-This is perl, v5.8.8 built for i386-freebsd-64int
-

-

-More Perl Poetry of mine

-

-
19. CSS3 is turing complete


-

-CSS3 is Turing complete because it can simulate a Turing machine using only CSS animations and styles without any JavaScript or external logic. This is achieved by using keyframe animations to change the styles of HTML elements in a way that encodes computation, performing calculations and state transitions. 

-

-Is CSS turing complete?

-

-It is surprising because CSS is primarily a styling language intended for the presentation layer of web pages, not for computation or logic. Its capability to perform complex computations defies its typical use case and showcases the unintended computational power that can emerge from the creative use of seemingly straightforward technologies.

-

-Check out this 100% CSS implementation of the Conways Game of Life:

-

-

-

-CSS Conways Game of Life

-

-Conway's Game of Life is Turing complete because it can simulate a universal Turing machine, meaning it can perform any computation that a computer can, given the right initial conditions and sufficient time and space. Suppose a language can implement Conway's Game of Life. In that case, it demonstrates the language's ability to handle complex state transitions and computations. It has the necessary constructs (like iteration, conditionals, and data manipulation) to simulate any algorithm, thus confirming its Turing completeness.

-

-
20. The biggest shell programs 


-

-One would think that shell scripts are only suitable for small tasks. Well, I must be wrong, as there are huge shell programs out there (up to 87k LOC) which aren't auto-generated but hand-written!

-

-The Biggest Sell Programs in the World

-

-My Gemtexter (bash) is only 1329 LOC as of now. So it's tiny.

-

-Gemtexter - One Bash script to rule it all

-

-I hope you had some fun. E-Mail your comments to paul@nospam.buetow.org :-)

-

-Back to the main site

-            

-        
-    
-    
-        f3s: Kubernetes with FreeBSD - Part 3: Protecting from power cuts
-        
-        gemini://foo.zone/gemfeed/2025-02-01-f3s-kubernetes-with-freebsd-part-3.gmi
-        2025-01-30T09:22:06+02:00
-        
-            Paul Buetow aka snonux
-            paul@dev.buetow.org
-        
-        This is the third blog post about my f3s series for my self-hosting demands in my home lab. f3s? The 'f' stands for FreeBSD, and the '3s' stands for k3s, the Kubernetes distribution we will use on FreeBSD-based physical machines.
-        
-            

-                
f3s: Kubernetes with FreeBSD - Part 3: Protecting from power cuts


-

-Published at 2025-01-30T09:22:06+02:00

-

-This is the third blog post about my f3s series for my self-hosting demands in my home lab. f3s? The "f" stands for FreeBSD, and the "3s" stands for k3s, the Kubernetes distribution we will use on FreeBSD-based physical machines.

-

-2024-11-17 f3s: Kubernetes with FreeBSD - Part 1: Setting the stage

-2024-12-03 f3s: Kubernetes with FreeBSD - Part 2: Hardware and base installation

-2025-02-01 f3s: Kubernetes with FreeBSD - Part 3: Protecting from power cuts (You are currently reading this)

-

-f3s logo

-

-
Table of Contents


-

-

-
Introduction


-

-In this blog post, we are setting up the UPS for the cluster. A UPS, or Uninterruptible Power Supply, safeguards my cluster from unexpected power outages and surges. It acts as a backup battery that kicks in when the electricity cuts out—especially useful in my area, where power cuts are frequent—allowing for a graceful system shutdown and preventing data loss and corruption. This is especially important since I will also store some of my data on the f3s nodes.

-

-
Changes since last time


-

-
FreeBSD upgrade from 14.1 to 14.2


-

-There has been a new release since the last blog post in this series. The upgrade from 14.1 was as easy as:

-

-
-
paul@f0: ~ % doas freebsd-update fetch
-paul@f0: ~ % doas freebsd-update install
-paul@f0: ~ % doas freebsd-update -r 14.2-RELEASE upgrade
-paul@f0: ~ % doas freebsd-update install
-paul@f0: ~ % doas shutdown -r now
-

-

-And after rebooting, I ran:

-

-
-
paul@f0: ~ % doas freebsd-update install
-paul@f0: ~ % doas pkg update
-paul@f0: ~ % doas pkg upgrade
-paul@f0: ~ % doas shutdown -r now
-

-

-And after another reboot, I was on 14.2:

-

-
-
paul@f0:~ % uname -a
-FreeBSD f0.lan.buetow.org 14.2-RELEASE FreeBSD 14.2-RELEASE 
- releng/14.2-n269506-c8918d6c7412 GENERIC amd64
-

-

-And, of course, I ran this on all 3 nodes!

-

-
A new home (behind the TV)


-

-I've put all the infrastructure behind my TV, as plenty of space is available. The TV hides most of the setup, which drastically improved the SAF (spouse acceptance factor).

-

-New hardware placement arrangement

-

-I got rid of the mini-switch I mentioned in the previous blog post. I have the TP-Link EAP615-Wall mounted on the wall nearby, which is my OpenWrt-powered Wi-Fi hotspot. It also has 3 Ethernet ports, to which I connected the Beelink nodes. That's the device you see at the very top.

-

-The Ethernet cables go downward through the cable boxes to the Beelink nodes. In addition to the Beelink f3s nodes, I connected the TP-Link to the UPS as well (not discussed further in this blog post, but the positive side effect is that my Wi-Fi will still work during a power loss for some time—and during a power cut, the Beelink nodes will still be able to communicate with each other).

-

-On the very left (the black box) is the UPS, with four power outlets. Three go to the Beelink nodes, and one goes to the TP-Link. A USB output is also connected to the first Beelink node, f0. 

-

-On the very right (halfway hidden behind the TV) are the 3 Beelink nodes stacked on top of each other. The only downside (or upside?) is that my 14-month-old daughter is now chaos-testing the Beelink nodes, as the red power buttons (now reachable for her) are very attractive for her to press when passing by randomly. :-) Luckily, that will only cause graceful system shutdowns!

-

-
The UPS hardware


-

-I wanted a UPS that I could connect to via FreeBSD, and that would provide enough backup power to operate the cluster for a couple of minutes (it turned out to be around an hour, but this time will likely be shortened after future hardware upgrades, like additional drives and a backup enclosure) and to automatically initiate the shutdown of all the f3s nodes.

-

-I decided on the APC Back-UPS BX750MI model because:

-

-
    
-
  • Zero noise level when there is no power cut (some light noise when the battery is in operation during a power cut).
    • 
-
  • Cost: It is relatively affordable (not costing thousands).
    • 
-
  • USB connectivity: Can be connected via USB to one of the FreeBSD hosts to read the UPS status.
    • 
-
  • A power output of 750VA (or 410 watts), suitable for an hour of runtime for my f3s nodes (plus the Wi-Fi router).
    • 
-
  • Multiple power outlets: Can connect all 3 f3s nodes directly.
    • 
-
  • User-replaceable batteries: I can replace the batteries myself after two years or more (depending on usage).
    • 
-
  • Its compact design. Overall, I like how it looks.
    • 
-


-The APC Back-UPS BX750MI in operation.

-

-
Configuring FreeBSD to Work with the UPS


-

-
USB Device Detection


-

-Once plugged in via USB on FreeBSD, I could see the following in the kernel messages:

-

-
-
paul@f0: ~ % doas dmesg | grep UPS
-ugen0.2: <American Power Conversion Back-UPS BX750MI> at usbus0
-

-

-
apcupsd Installation


-

-To make use of the USB connection, the apcupsd package had to be installed:

-

-
-
paul@f0: ~ % doas install apcupsd
-

-

-I have made the following modifications to the configuration file so that the UPS can be used via the USB interface:

-

-
-
paul@f0:/usr/local/etc/apcupsd % diff -u apcupsd.conf.sample  apcupsd.conf
---- apcupsd.conf.sample 2024-11-01 16:40:42.000000000 +0200
-+++ apcupsd.conf        2024-12-03 10:58:24.009501000 +0200
-@@ -31,7 +31,7 @@
- #     940-1524C, 940-0024G, 940-0095A, 940-0095B,
- #     940-0095C, 940-0625A, M-04-02-2000
- #
--UPSCABLE smart
-+UPSCABLE usb
-
- # To get apcupsd to work, in addition to defining the cable
- # above, you must also define a UPSTYPE, which corresponds to
-@@ -88,8 +88,10 @@
- #                            that apcupsd binds to that particular unit
- #                            (helpful if you have more than one USB UPS).
- #
--UPSTYPE apcsmart
--DEVICE /dev/usv
-+UPSTYPE usb
-+DEVICE
-
- # POLLTIME <int>
- #   Interval (in seconds) at which apcupsd polls the UPS for status. This
-

-

-I left the remaining settings as the default ones; for example, the following are of main interest:

-

-
-# If during a power failure, the remaining battery percentage
-# (as reported by the UPS) is below or equal to BATTERYLEVEL,
-# apcupsd will initiate a system shutdown.
-BATTERYLEVEL 5
-
-# If during a power failure, the remaining runtime in minutes
-# (as calculated internally by the UPS) is below or equal to MINUTES,
-# apcupsd, will initiate a system shutdown.
-MINUTES 3
-

-

-I then enabled and started the daemon:

-

-
-
paul@f0:/usr/local/etc/apcupsd % doas sysrc apcupsd_enable=YES
-apcupsd_enable:  -> YES
-paul@f0:/usr/local/etc/apcupsd % doas service apcupsd start
-Starting apcupsd.
-

-

-
UPS Connectivity Test


-

-And voila, I could now access the UPS information via the apcaccess command; how convenient :-) (I also read through the manual page, which provides a good understanding of what else can be done with it!).

-

-
-
paul@f0:~ % apcaccess
-APC      : 001,035,0857
-DATE     : 2025-01-26 14:43:27 +0200
-HOSTNAME : f0.lan.buetow.org
-VERSION  : 3.14.14 (31 May 2016) freebsd
-UPSNAME  : f0.lan.buetow.org
-CABLE    : USB Cable
-DRIVER   : USB UPS Driver
-UPSMODE  : Stand Alone
-STARTTIME: 2025-01-26 14:43:25 +0200
-MODEL    : Back-UPS BX750MI
-STATUS   : ONLINE
-LINEV    : 230.0 Volts
-LOADPCT  : 4.0 Percent
-BCHARGE  : 100.0 Percent
-TIMELEFT : 65.3 Minutes
-MBATTCHG : 5 Percent
-MINTIMEL : 3 Minutes
-MAXTIME  : 0 Seconds
-SENSE    : Medium
-LOTRANS  : 145.0 Volts
-HITRANS  : 295.0 Volts
-ALARMDEL : No alarm
-BATTV    : 13.6 Volts
-LASTXFER : Automatic or explicit self test
-NUMXFERS : 0
-TONBATT  : 0 Seconds
-CUMONBATT: 0 Seconds
-XOFFBATT : N/A
-SELFTEST : NG
-STATFLAG : 0x05000008
-SERIALNO : 9B2414A03599
-BATTDATE : 2001-01-01
-NOMINV   : 230 Volts
-NOMBATTV : 12.0 Volts
-NOMPOWER : 410 Watts
-END APC  : 2025-01-26 14:44:06 +0200
-

-

-
APC Info on Partner Nodes:


-

-So far, so good. Host f0 would shut down itself when short on power. But what about the f1 and f2 nodes? They aren't connected directly to the UPS and, therefore, wouldn't know that their power is about to be cut off. For this, apcupsd running on the f1 and f2 nodes can be configured to retrieve UPS information via the network from the apcupsd server running on the f0 node, which is connected directly to the APC via USB.

-

-Of course, this won't work when f0 is down. In this case, no operational node would be connected to the UPS via USB; therefore, the current power status would not be known. However, I consider this a rare circumstance. Furthermore, in case of an f0 system crash, sudden power outages on the two other nodes would occur at different times making real data loss (the main concern here) less likely.

-

-And if f0 is down and f1 and f2 receive new data and crash midway, it's likely that a client (e.g., an Android app or another laptop) still has the data stored on it, making data recoverable and data loss overall nearly impossible. I'd receive an alert if any of the nodes go down (more on monitoring later in this blog series).

-

-
Installation on partners


-

-To do this, I installed apcupsd via doas pkg install apcupsd on f1 and f2, and then I could connect to it this way:

-

-
-
paul@f1:~ % apcaccess -h f0.lan.buetow.org | grep Percent
-LOADPCT  : 12.0 Percent
-BCHARGE  : 94.0 Percent
-MBATTCHG : 5 Percent
-

-

-But I want the daemon to be configured and enabled in such a way that it connects to the master UPS node (the one with the UPS connected via USB) so that it can also initiate a system shutdown when the UPS battery reaches low levels. For that, apcupsd itself needs to be aware of the UPS status.

-

-On f1 and f2, I changed the configuration to use f0 (where apcupsd is listening) as a remote device. I also changed the MINUTES setting from 3 to 6 and the BATTERYLEVEL setting from 5 to 10 to ensure that the f1 and f2 nodes could still connect to the f0 node for UPS information before f0 decides to shut down itself. So f1 and f2 must shut down earlier than f0:

-

-
-
paul@f2:/usr/local/etc/apcupsd % diff -u apcupsd.conf.sample apcupsd.conf
---- apcupsd.conf.sample 2024-11-01 16:40:42.000000000 +0200
-+++ apcupsd.conf        2025-01-26 15:52:45.108469000 +0200
-@@ -31,7 +31,7 @@
- #     940-1524C, 940-0024G, 940-0095A, 940-0095B,
- #     940-0095C, 940-0625A, M-04-02-2000
- #
--UPSCABLE smart
-+UPSCABLE ether
-
- # To get apcupsd to work, in addition to defining the cable
- # above, you must also define a UPSTYPE, which corresponds to
-@@ -52,7 +52,6 @@
- #                            Network Information Server. This is used if the
- #                            UPS powering your computer is connected to a
- #                            different computer for monitoring.
--#
- # snmp      hostname:port:vendor:community
- #                            SNMP network link to an SNMP-enabled UPS device.
- #                            Hostname is the ip address or hostname of the UPS
-@@ -88,8 +87,8 @@
- #                            that apcupsd binds to that particular unit
- #                            (helpful if you have more than one USB UPS).
- #
--UPSTYPE apcsmart
--DEVICE /dev/usv
-+UPSTYPE net
-+DEVICE f0.lan.buetow.org:3551
-
- # POLLTIME <int>
- #   Interval (in seconds) at which apcupsd polls the UPS for status. This
-@@ -147,12 +146,12 @@
- # If during a power failure, the remaining battery percentage
- # (as reported by the UPS) is below or equal to BATTERYLEVEL,
- # apcupsd will initiate a system shutdown.
--BATTERYLEVEL 5
-+BATTERYLEVEL 10
-
- # If during a power failure, the remaining runtime in minutes
- # (as calculated internally by the UPS) is below or equal to MINUTES,
- # apcupsd, will initiate a system shutdown.
--MINUTES 3
-+MINUTES 6
-
- # If during a power failure, the UPS has run on batteries for TIMEOUT
- # many seconds or longer, apcupsd will initiate a system shutdown.
-
-

-So I also ran the following commands on f1 and f2:

-

-
-
paul@f1:/usr/local/etc/apcupsd % doas sysrc apcupsd_enable=YES
-apcupsd_enable:  -> YES
-paul@f1:/usr/local/etc/apcupsd % doas service apcupsd start
-Starting apcupsd.
-

-

-And then I was able to connect to localhost via the apcaccess command:

-

-
-
paul@f1:~ % doas apcaccess | grep Percent
-LOADPCT  : 5.0 Percent
-BCHARGE  : 95.0 Percent
-MBATTCHG : 5 Percent
-

-

-
Power outage simulation


-

-
Pulling the plug


-

-I simulated a power outage by removing the power input from the APC. Immediately, the following message appeared on all the nodes:

-

-
-Broadcast Message from root@f0.lan.buetow.org
-        (no tty) at 15:03 EET...
-
-Power failure. Running on UPS batteries.                                              
-

-

-I ran the following command to confirm the available battery time:

-

-
-
paul@f0:/usr/local/etc/apcupsd % apcaccess -p TIMELEFT
-63.9 Minutes
-

-

-And after around one hour (f1 and f2 a bit earlier, f0 a bit later due to the different BATTERYLEVEL and MINUTES settings outlined earlier), the following broadcast was sent out:

-

-
-Broadcast Message from root@f0.lan.buetow.org
-        (no tty) at 15:08 EET...
-
-        *** FINAL System shutdown message from root@f0.lan.buetow.org ***
-
-System going down IMMEDIATELY
-
-apcupsd initiated shutdown
-

-

-And all the nodes shut down safely before the UPS ran out of battery!

-

-
Restoring power


-

-After restoring power, I checked the logs in /var/log/daemon.log and found the following on all 3 nodes:

-

-
-Jan 26 17:36:24 f2 apcupsd[2159]: Power failure.
-Jan 26 17:36:30 f2 apcupsd[2159]: Running on UPS batteries.
-Jan 26 17:36:30 f2 apcupsd[2159]: Battery charge below low limit.
-Jan 26 17:36:30 f2 apcupsd[2159]: Initiating system shutdown!
-Jan 26 17:36:30 f2 apcupsd[2159]: User logins prohibited
-Jan 26 17:36:32 f2 apcupsd[2159]: apcupsd exiting, signal 15
-Jan 26 17:36:32 f2 apcupsd[2159]: apcupsd shutdown succeeded
-

-

-All good :-) See you in the next post of this series!

-

-Other BSD related posts are:

-

-2025-02-01 f3s: Kubernetes with FreeBSD - Part 3: Protecting from power cuts (You are currently reading this)

-2024-12-03 f3s: Kubernetes with FreeBSD - Part 2: Hardware and base installation

-2024-11-17 f3s: Kubernetes with FreeBSD - Part 1: Setting the stage

-2024-04-01 KISS high-availability with OpenBSD

-2024-01-13 One reason why I love OpenBSD

-2022-10-30 Installing DTail on OpenBSD

-2022-07-30 Let's Encrypt with OpenBSD and Rex

-2016-04-09 Jails and ZFS with Puppet on FreeBSD

-

-E-Mail your comments to paul@nospam.buetow.org :-)

-

-Back to the main site

-            

-        
-    
-    
-        Working with an SRE Interview
-        
-        gemini://foo.zone/gemfeed/2025-01-15-working-with-an-sre-interview.gmi
-        2025-01-15T00:16:04+02:00
-        
-            Paul Buetow aka snonux
-            paul@dev.buetow.org
-        
-        I have been interviewed by Florian Buetow on `cracking-ai-engineering.com`  about what it's like working with a Site Reliability Engineer from the point of view of a Software Engineer, Data Scientist, and AI Engineer.
-        
-            

-                
Working with an SRE Interview


-

-Published at 2025-01-15T00:16:04+02:00

-

-I have been interviewed by Florian Buetow on cracking-ai-engineering.com  about what it's like working with a Site Reliability Engineer from the point of view of a Software Engineer, Data Scientist, and AI Engineer.

-

-See original interview here

-Cracking AI Engineering

-

-Below, I am posting the interview here on my blog as well.

-

-
Table of Contents


-

-

-
Preamble 


-

-In this insightful interview, Paul Bütow, a Principal Site Reliability Engineer at Mimecast, shares over a decade of experience in the field. Paul highlights the role of an Embedded SRE, emphasizing the importance of automation, observability, and effective incident management. We also focused on the key question of how you can work effectively with an SRE weather you are an individual contributor or a manager, a software engineer or data scientist. And how you can learn more about site reliability engineering.

-

-
Introducing Paul


-

-Hi Paul, please introduce yourself briefly to the audience. Who are you, what do you do for a living, and where do you work?

-

-My name is Paul Bütow, I work at Mimecast, and I’m a Principal Site Reliability Engineer there. I’ve been with Mimecast for almost ten years now. The company specializes in email security, including things like archiving, phishing detection, malware protection, and spam filtering.

-

-You mentioned that you’re an ‘Embedded SRE.’ What does that mean exactly?

-

-It means that I’m directly part of the software engineering team, not in a separate Ops department. I ensure that nothing is deployed manually, and everything runs through automation. I also set up monitoring and observability. These are two distinct aspects: monitoring alerts us when something breaks, while observability helps us identify trends. I also create runbooks so we know what to do when specific incidents occur frequently.

-

-Infrastructure SREs on the other hand handle the foundational setup, like providing the Kubernetes cluster itself or ensuring the operating systems are installed. They don't work on the application directly but ensure the base infrastructure is there for others to use. This works well when a company has multiple teams that need shared infrastructure.

-

-
How did you get started?


-

-How did your interest in Linux or FreeBSD start?

-

-It began during my school days. We had a PC with DOS at home, and I eventually bought Suse Linux 5.3. Shortly after, I discovered FreeBSD because I liked its handbook so much. I wanted to understand exactly how everything worked, so I also tried Linux from Scratch. That involves installing every package manually to gain a better understanding of operating systems.

-

-https://www.FreeBSD.org

-https://linuxfromscratch.org/

-

-And after school, you pursued computer science, correct?

-

-Exactly. I wasn’t sure at first whether I wanted to be a software developer or a system administrator. I applied for both and eventually accepted an offer as a Linux system administrator. This was before 'SRE' became a buzzword, but much of what I did back then-automation, infrastructure as code, monitoring-is now considered part of the typical SRE role.

-

-
Roles and Career Progression


-

-Tell us about how you joined Mimecast. When did you fully embrace the SRE role?

-

-I started as a Linux sysadmin at 1&1. I managed an ad server farm with hundreds of systems and later handled load balancers. Together with an architect, we managed F5 load balancers distributing around 2,000 services, including for portals like web.de and GMX. I also led the operations team technically for a while before moving to London to join Mimecast.

-

-At Mimecast, the job title was explicitly 'Site Reliability Engineer.' The biggest difference was that I was no longer in a separate Ops department but embedded directly within the storage and search backend team. I loved that because we could plan features together-from automation to measurability and observability. Mimecast also operates thousands of physical servers for email archiving, which was fascinating since I already had experience with large distributed systems at 1&1. It was the right step for me because it allowed me to work close to the code while remaining hands-on with infrastructure.

-

-What are the differences between SRE, DevOps, SysAdmin, and Architects?

-

-SREs are like the next step after SysAdmins. A SysAdmin might manually install servers, replace disks, or use simple scripts for automation, while SREs use infrastructure as code and focus on reliability through SLIs, SLOs, and automation. DevOps isn’t really a job-it’s more of a way of working, where developers are involved in operations tasks like setting up CI/CD pipelines or on-call shifts. Architects focus on designing systems and infrastructures, such as load balancers or distributed systems, working alongside SREs to ensure the systems meet the reliability and scalability requirements. The specific responsibilities of each role depend on the company, and there is often overlap.  

-

-What are the most important reliability lessons you’ve learned so far?

-

-
    
-
  • Don’t leave SRE aspects as an afterthought. It’s much better to discuss automation, monitoring, SLIs, and SLOs early on. Traditional sysadmins often installed systems manually, but today, we do everything via infrastructure as code-using tools like Terraform or Puppet.
    • 
-
  • I also distinguish between monitoring and observability. Monitoring tells us, 'The server is down, alarm!' Observability dives deeper, showing trends like increasing latency so we can act proactively.
    • 
-
  • SLI, SLO, and SLA are core elements. We focus on what users actually experience-for example, how quickly an email is sent-and set our goals accordingly.
    • 
-
  • Runbooks are also crucial. When something goes wrong at night, you don’t want to start from scratch. A runbook outlines how to debug and resolve specific problems, saving time and reducing downtime.
    • 
-


-
Anecdotes and Best Practices


-

-Runbooks sound very practical. Can you explain how they’re used day-to-day?

-

-Runbooks are essentially guides for handling specific incidents. For instance, if a service won’t start, the runbook will specify where the logs are and which commands to use. Observability takes it a step further, helping us spot changes early-like rising error rates or latency-so we can address issues before they escalate.

-

-When should you decide to put something into a runbook, and when is it unnecessary?

-

-If an issue happens frequently, it should be documented in a runbook so that anyone, even someone new, can follow the steps to fix it. The idea is that 90% of the common incidents should be covered. For example, if a service is down, the runbook would specify where to find logs, which commands to check, and what actions to take. On the other hand, rare or complex issues, where the resolution depends heavily on context or varies each time, don’t make sense to include in detail. For those, it’s better to focus on general troubleshooting steps.  

-

-How do you search for and find the correct runbooks?

-

-Runbooks should be linked directly in the alert you receive. For example, if you get an alert about a service not running, the alert will have a link to the runbook that tells you what to check, like logs or commands to run. Runbooks are best stored in an internal wiki, so if you don’t find the link in the alert, you know where to search. The important thing is that runbooks are easy to find and up to date because that’s what makes them useful during incidents.  

-

-Do you have an interesting war story you can share with us?

-

-Sure. At 1&1, we had a proprietary ad server software that ran a SQL query during startup. The query got slower over time, eventually timing out and preventing the server from starting. Since we couldn’t access the source code, we searched the binary for the SQL and patched it. By pinpointing the issue, a developer was able to adjust the SQL. This collaboration between sysadmin and developer perspectives highlights the value of SRE work.

-

-
Working with Different Teams


-

-You’re embedded in a team-how does collaboration with developers work practically?

-

-We plan everything together from the start. If there’s a new feature, we discuss infrastructure, automated deployments, and monitoring right away. Developers are experts in the code, and I bring the infrastructure expertise. This avoids unpleasant surprises before going live.

-

-How about working with data scientists or ML engineers? Are there differences?

-

-The principles are the same. ML models also need to be deployed and monitored. You deal with monitoring, resource allocation, and identifying performance drops. Whether it’s a microservice or an ML job, at the end of the day, it’s all running on servers or clusters that must remain stable.

-

-What about working with managers or the FinOps team?

-

-We often discuss costs, especially in the cloud, where scaling up resources is easy. It’s crucial to know our metrics: do we have enough capacity? Do we need all instances? Or is the CPU only at 5% utilization? This data helps managers decide whether the budget is sufficient or if optimizations are needed.

-

-Do you have practical tips for working with SREs?

-

-Yes, I have a few:

-

-
    
-
  • Early involvement: Include SREs from the beginning in your project.
    • 
-
  • Runbooks & documentation: Document recurring errors.
    • 
-
  • Try first: Try to understand the issue yourself before immediately asking the SRE.
    • 
-
  • Basic infra knowledge: Kubernetes and Terraform aren’t magic. Some basic understanding helps every developer.
    • 
-


-
Using AI Tools


-

-Let’s talk about AI. How do you use it in your daily work?

-

-For boilerplate code, like Terraform snippets, I often use ChatGPT. It saves time, although I always review and adjust the output. Log analysis is another exciting application. Instead of manually going through millions of lines, AI can summarize key outliers or errors.

-

-Do you think AI could largely replace SREs or significantly change the role?

-

-I see AI as an additional tool. SRE requires a deep understanding of how distributed systems work internally. While AI can assist with routine tasks or quickly detect anomalies, human expertise is indispensable for complex issues.

-

-
SRE Learning Resources


-

-What resources would you recommend for learning about SRE?

-

-The Google SRE book is a classic, though a bit dry. I really like 'Seeking SRE,' as it offers various perspectives on SRE, with many practical stories from different companies.

-

-https://sre.google/books/

-Seeking SRE

-

-Do you have a podcast recommendation?

-

-The Google SRE prodcast is quite interesting. It offers insights into how Google approaches SRE, along with perspectives from external guests.

-

-https://sre.google/prodcast/

-

-
Blogging


-

-You also have a blog. What motivates you to write regularly?

-

-Writing helps me learn the most. It also serves as a personal reference. Sometimes I look up how I solved a problem a year ago. And of course, others tackling similar projects might find inspiration in my posts.

-

-What do you blog about?

-

-Mostly technical topics I find exciting, like homelab projects, Kubernetes, or book summaries on IT and productivity. It’s a personal blog, so I write about what I enjoy.

-

-
Wrap-up


-

-To wrap up, what are three things every team should keep in mind for stability?

-

-First, maintain runbooks and documentation to avoid chaos at night. Second, automate everything-manual installs in production are risky. Third, define SLIs, SLOs, and SLAs early so everyone knows what we’re monitoring and guaranteeing.

-

-Is there a motto or mindset that particularly inspires you as an SRE?

-

-"Keep it simple and stupid"-KISS. Not everything has to be overly complex. And always stay curious. I’m still fascinated by how systems work under the hood.

-

-Where can people find you online?

-

-You can find links to my socials on my website paul.buetow.org

-I regularly post articles and link to everything else I’m working on outside of work.

-

-https://paul.buetow.org

-

-Thank you very much for your time and this insightful interview into the world of site reliability engineering

-

-My pleasure, this was fun.

-

-
Closing comments


-

-Dear reader, I hope this conversation with Paul Bütow provided an exciting peak into the world of Site Reliability Engineering. Whether you’re a software developer, data scientist, ML engineer, or manager, reliable systems are always a team effort. Hopefully, you’ve taken some insights or tips from Paul’s experiences for your own team or next project. Thanks for joining us, and best of luck refining your own SRE practices!

-

-E-Mail your comments to paul@nospam.buetow.org or contact Florian via the Cracking AI Engineering :-)

-

-Back to the main site

-            

-        
-    
-    
-        Posts from October to December 2024
-        
-        gemini://foo.zone/gemfeed/2025-01-01-posts-from-october-to-december-2024.gmi
-        2024-12-31T18:09:58+02:00
-        
-            Paul Buetow aka snonux
-            paul@dev.buetow.org
-        
-        Happy new year!
-        
-            

-                
Posts from October to December 2024


-

-Published at 2024-12-31T18:09:58+02:00

-

-Happy new year!

-

-These are my social media posts from the last three months. I keep them here to reflect on them and also to not lose them. Social media networks come and go and are not under my control, but my domain is here to stay. 

-

-These are from Mastodon and LinkedIn. Have a look at my about page for my social media profiles. This list is generated with Gos, my social media platform sharing tool.

-

-My about page

-https://codeberg.org/snonux/gos

-

-
Table of Contents


-

-

-
Posts for 202410 202411 202412


-

-
October 2024


-

-
First on-call experience in a startup. Doesn't ...


-

-First on-call experience in a startup. Doesn't sound a lot of fun! But the lessons were learned! #sre

-

-ntietz.com/blog/lessons-from-my-first-on-call/

-

-
Reviewing your own PR or MR before asking ...


-

-Reviewing your own PR or MR before asking others to review it makes a lot of sense. Have seen so many silly mistakes which would have been avoided. Saving time for the real reviewer.

-

-www.jvt.me/posts/2019/01/12/self-code-review/

-

-
Fun with defer in #golang, I did't know, that ...


-

-Fun with defer in #golang, I did't know, that a defer object can either be heap or stack allocated. And there are some rules for inlining, too.

-

-victoriametrics.com/blog/defer-in-go/

-

-
I have been in incidents. Understandably, ...


-

-I have been in incidents. Understandably, everyone wants the issue to be resolved as quickly and others want to know how long TTR will be. IMHO, providing no estimates at all is no solution either. So maybe give a rough estimate but clearly communicate that the estimate is rough and that X, Y, and Z can interfere, meaning there is a chance it will take longer to resolve the incident. Just my thought. What's yours?

-

-firehydrant.com/blog/hot-take-dont-provide-incident-resolution-estimates/

-

-
Little tips using strings in #golang and I ...


-

-Little tips using strings in #golang and I personally think one must look more into the std lib (not just for strings, also for slices, maps,...), there are tons of useful helper functions.

-

-www.calhoun.io/6-tips-for-using-strings-in-go/

-

-
Reading this post about #rust (especially the ...


-

-Reading this post about #rust (especially the first part), I think I made a good choice in deciding to dive into #golang instead. There was a point where I wanted to learn a new programming language, and Rust was on my list of choices. I think the Go project does a much better job of deciding what goes into the language and how. What are your thoughts?

-

-josephg.com/blog/rewriting-rust/

-

-
The opposite of #ChaosMonkey ... ...


-

-The opposite of #ChaosMonkey ... automatically repairing and healing services helping to reduce manual toil work. Runbooks and scripts are only the first step, followed by a fully blown service written in Go. Could be useful, but IMHO why not rather address the root causes of the manual toil work? #sre

-

-blog.cloudflare.com/nl-nl/improving-platform-resilience-at-cloudflare/

-

-
November 2024


-

-
I just became a Silver Patreon for OSnews. What ...


-

-I just became a Silver Patreon for OSnews. What is OSnews? It is an independent news site about IT. It is slightly independent and, at times, alternative. I have enjoyed it since my early student days. This one and other projects I financially support are listed here:

-

-foo.zone/gemfeed/2024-09-07-projects-i-support.gmi (Gemini)

-foo.zone/gemfeed/2024-09-07-projects-i-support.html

-

-
Until now, I wasn't aware, that Go is under a ...


-

-Until now, I wasn't aware, that Go is under a BSD-style license (3-clause as it seems). Neat. I don't know why, but I always was under the impression it would be MIT. #bsd #golang

-

-go.dev/LICENSE

-

-
These are some book notes from "Staff Engineer" ...


-

-These are some book notes from "Staff Engineer" – there is some really good insight into what is expected from a Staff Engineer and beyond in the industry. I wish I had read the book earlier.

-

-foo.zone/gemfeed/2024-10-24-staff-engineer-book-notes.gmi (Gemini)

-foo.zone/gemfeed/2024-10-24-staff-engineer-book-notes.html

-

-
Looking at #Kubernetes, it's pretty much ...


-

-Looking at #Kubernetes, it's pretty much following the Unix way of doing things. It has many tools, but each tool has its own single purpose: DNS, scheduling, container runtime, various controllers, networking, observability, alerting, and more services in the control plane. Everything is managed by different services or plugins, mostly running in their dedicated pods. They don't communicate through pipes, but network sockets, though. #k8s

-

-
There has been an outage at the upstream ...


-

-There has been an outage at the upstream network provider for OpenBSD.Amsterdam (hoster, I am using). This was the first real-world test for my KISS HA setup, and it worked flawlessly! All my sites and services failed over automatically to my other #OpenBSD VM!

-

-foo.zone/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi (Gemini)

-foo.zone/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.html

-openbsd.amsterdam/

-

-
One of the more confusing parts in Go, nil ...


-

-One of the more confusing parts in Go, nil values vs nil errors: #golang

-

-unexpected-go.com/nil-errors-that-are-non-nil-errors.html

-

-
Agreeably, writing down with Diagrams helps you ...


-

-Agreeably, writing down with Diagrams helps you to think things more through. And keeps others on the same page. Only worth for projects from a certain size, IMHO.

-

-ntietz.com/blog/reasons-to-write-design-docs/

-

-
I like the idea of types in Ruby. Raku is ...


-

-I like the idea of types in Ruby. Raku is supports that already, but in Ruby, you must specify the types in a separate .rbs file, which is, in my opinion, cumbersome and is a reason not to use it extensively for now. I believe there are efforts to embed the type information in the standard .rb files, and that the .rbs is just an experiment to see how types could work out without introducing changes into the core Ruby language itself right now? #Ruby #RakuLang

-

-github.com/ruby/rbs

-

-
So, #Haskell is better suited for general ...


-

-So, #Haskell is better suited for general purpose than #Rust? I thought deploying something in Haskell means publishing an academic paper :-) Interesting rant about Rust, though:

-

-chrisdone.com/posts/rust/

-

-
At first, functional options add a bit of ...


-

-At first, functional options add a bit of boilerplate, but they turn out to be quite neat, especially when you have very long parameter lists that need to be made neat and tidy. #golang

-

-www.calhoun.io/using-functional-options-instead-of-method-chaining-in-go/

-

-
Revamping my home lab a little bit. #freebsd ...


-

-Revamping my home lab a little bit. #freebsd #bhyve #rocky #linux #vm #k3s #kubernetes #wireguard #zfs #nfs #ha #relayd #k8s #selfhosting #homelab

-

-foo.zone/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.gmi (Gemini)

-foo.zone/gemfeed/2024-11-17-f3s-kubernetes-with-freebsd-part-1.html

-

-
Wondering to which #web #browser I should ...


-

-Wondering to which #web #browser I should switch now personally ...

-

-www.osnews.com/story/141100/mozilla-fo..-..dvocacy-for-open-web-privacy-and-more/

-

-
eks-node-viewer is a nifty tool, showing the ...


-

-eks-node-viewer is a nifty tool, showing the compute nodes currently in use in the #EKS cluster. especially useful when dynamically allocating nodes with #karpenter or auto scaling groups.

-

-github.com/awslabs/eks-node-viewer

-

-
Have put more Photos on - On my static photo ...


-

-Have put more Photos on - On my static photo sites - Generated with a #bash script

-

-irregular.ninja

-

-
In Go, passing pointers are not automatically ...


-

-In Go, passing pointers are not automatically faster than values. Pointers often force the memory to be allocated on the heap, adding GC overhad. With values, Go can determine whether to put the memory on the stack instead. But with large structs/objects (how you want to call them) or if you want to modify state, then pointers are the semantic to use. #golang

-

-blog.boot.dev/golang/pointers-faster-than-values/

-

-
Myself being part of an on-call rotations over ...


-

-Myself being part of an on-call rotations over my whole professional life, just have learned this lesson "Tell people who are new to on-call: Just have fun" :-) This is a neat blog post to read:

-

-ntietz.com/blog/what-i-tell-people-new-to-oncall/

-

-
Feels good to code in my old love #Perl again ...


-

-Feels good to code in my old love #Perl again after a while. I am implementing a log parser for generating site stats of my personal homepage! :-) @Perl

-

-
This is an interactive summary of the Go ...


-

-This is an interactive summary of the Go release, with a lot of examples utilising iterators in the slices and map packages. Love it! #golang

-

-antonz.org/go-1-23/

-

-
December 2024


-

-
Thats unexpected, you cant remove a NaN key ...


-

-Thats unexpected, you cant remove a NaN key from a map without clearing it! #golang

-

-unexpected-go.com/you-cant-remove-a-nan-key-from-a-map-without-clearing-it.html

-

-
My second blog post about revamping my home lab ...


-

-My second blog post about revamping my home lab a little bit just hit the net. #FreeBSD #ZFS #n100 #k8s #k3s #kubernetes

-

-foo.zone/gemfeed/2024-12-03-f3s-kubernetes-with-freebsd-part-2.gmi (Gemini)

-foo.zone/gemfeed/2024-12-03-f3s-kubernetes-with-freebsd-part-2.html

-

-
Very insightful article about tech hiring in ...


-

-Very insightful article about tech hiring in the age of LLMs. As an interviewer, I have experienced some of the scrnarios already first hand...

-

-newsletter.pragmaticengineer.com/p/how-genai-changes-tech-hiring

-

-
for #bpf #ebpf performance debugging, have ...


-

-for #bpf #ebpf performance debugging, have a look at bpftop from Netflix. A neat tool showing you the estimated CPU time and other performance statistics for all the BPF programs currently loaded into the #linux kernel. Highly recommend!

-

-github.com/Netflix/bpftop

-

-
89 things he/she knows about Git commits is a ...


-

-89 things he/she knows about Git commits is a neat list of #Git wisdoms

-

-www.jvt.me/posts/2024/07/12/things-know-commits/

-

-
I found that working on multiple side projects ...


-

-I found that working on multiple side projects concurrently is better than concentrating on just one. This seems inefficient at first, but whenever you tend to lose motivation, you can temporarily switch to another one with full élan. However, remember to stop starting and start finishing. This doesn't mean you should be working on 10+ (and a growing list of) side projects concurrently! Select your projects and commit to finishing them before starting the next thing. For example, my current limit of concurrent side projects is around five.

-

-
Agreed? Agreed. Besides #Ruby, I would also ...


-

-Agreed? Agreed. Besides #Ruby, I would also add #RakuLang and #Perl @Perl to the list of languages that are great for shell scripts - "Making Easy Things Easy and Hard Things Possible"

-

-lucasoshiro.github.io/posts-en/2024-06-17-ruby-shellscript/

-

-
Plan9 assembly format in Go, but wait, it's not ...


-

-Plan9 assembly format in Go, but wait, it's not the Operating System Plan9! #golang #rabbithole

-

-www.osnews.com/story/140941/go-plan9-memo-speeding-up-calculations-450/

-

-
This is a neat blog post about the Helix text ...


-

-This is a neat blog post about the Helix text editor, to which I personally switched around a year ago (from NeoVim). I should blog about my experience as well. To summarize: I am using it together with the terminal multiplexer #tmux. It doesn't bother me that Helix is purely terminal-based and therefore everything has to be in the same font. #HelixEditor

-

-jonathan-frere.com/posts/helix/

-

-
This blog post is basically a rant against ...


-

-This blog post is basically a rant against DataDog... Personally, I don't have much experience with DataDog (actually, I have never used it), but one reason to work with logs at my day job (with over 2,000 physical server machines) and to be cost-effective is by using dtail! #dtail #logs #logmanagement

-

-crys.site/blog/2024/reinventint-the-weel/

-dtail.dev

-

-
Quick trick to get Helix themes selected ...


-

-Quick trick to get Helix themes selected randomly #HelixEditor

-

-foo.zone/gemfeed/2024-12-15-random-helix-themes.gmi (Gemini)

-foo.zone/gemfeed/2024-12-15-random-helix-themes.html

-

-
Example where complexity attacks you from ...


-

-Example where complexity attacks you from behind #k8s #kubernetes #OpenAI

-

-surfingcomplexity.blog/2024/12/14/quic..-..ecent-openai-public-incident-write-up/

-

-
LLMs for Ops? Summaries of logs, probabilities ...


-

-LLMs for Ops? Summaries of logs, probabilities about correctness, auto-generating Ansible, some uses cases are there. Wouldn't trust it fully, though.

-

-youtu.be/WodaffxVq-E?si=noY0egrfl5izCSQI

-

-
Excellent article about your dream Product ...


-

-Excellent article about your dream Product Manager: Why every software team needs a product manager to thrive via @wallabagapp

-

-testdouble.com/insights/why-product-ma..-..s-accelerate-improve-software-delivery

-

-
I just finished reading all chapters of CPU ...


-

-I just finished reading all chapters of CPU land: ... not claiming to remember every detail, but it is a great refresher how CPUs and operating systems actually work under the hood when you execute a program, which we tend to forget in our higher abstraction world. I liked the "story" and some of the jokes along the way! Size wise, it is pretty digestable (not talking about books, but only 7 web articles/chapters)! #cpu #linux #unix #kernel #macOS

-

-cpu.land/

-

-
Indeed, useful to know this stuff! #sre ...


-

-Indeed, useful to know this stuff! #sre

-

-biriukov.dev/docs/resolver-dual-stack-..-..resolvers-and-dual-stack-applications/

-

-
It's the small things, which make Unix like ...


-

-It's the small things, which make Unix like systems, like GNU/Linux, interesting. Didn't know about this #GNU #Tar behaviour yet:

-

-xeiaso.net/notes/2024/pop-quiz-tar/

-

-
My New Year's resolution is not to start any ...


-

-My New Year's resolution is not to start any new non-fiction books (or only very few) but to re-read and listen to my favorites, which I read to reflect on and see things from different perspectives. Every time you re-read a book, you gain new insights.<nil>17491

-

-Other related posts:

-

-2025-01-01 Posts from October to December 2024 (You are currently reading this)

-

-E-Mail your comments to paul@nospam.buetow.org :-)

-

-Back to the main site

-            

-        
-    
diff --git a/index.gmi b/index.gmi
index 524b38e0..c4ce2b13 100644
--- a/index.gmi
+++ b/index.gmi
@@ -1,6 +1,6 @@
 # foo.zone
 
-> This site was generated at 2025-02-21T11:13:28+02:00 by `Gemtexter`
+> This site was generated at 2025-02-21T17:05:13+02:00 by `Gemtexter`
 
 Welcome to the foo.zone. Everything you read on this site is my personal opinion and experience. You can call me a Linux/*BSD enthusiast and hobbyist. I mainly write about tech, IT, programming and sometimes also about self-improvement here. And I also like coding.
 
diff --git a/notes/97-things-every-sre-should-know.gmi b/notes/97-things-every-sre-should-know.gmi
new file mode 100644
index 00000000..ff511964
--- /dev/null
+++ b/notes/97-things-every-sre-should-know.gmi
@@ -0,0 +1,311 @@
+# "97 Things Every SRE Should Know" book notes
+
+These are my personal book notes of Emil Stolarsky's and Jaime Woo's "97 Things Every SRE Should Know". They are for myself, but I hope they might be useful to you too.
+
+## Table of Contents
+
+* ⇢ "97 Things Every SRE Should Know" book notes
+* ⇢ ⇢ Introduction
+* ⇢ ⇢ Observability
+* ⇢ ⇢ The ancient art of writing things down
+* ⇢ ⇢ The teams health
+* ⇢ ⇢ Sharing responsibilities
+* ⇢ ⇢ The roles and the solo SRE
+* ⇢ ⇢ Being customer-focused
+* ⇢ ⇢ Don't have all the answers
+* ⇢ ⇢ Runbooks
+* ⇢ ⇢ Alerts per shift
+* ⇢ ⇢ Balancing velocity
+* ⇢ ⇢ The power in knowing how to be self-sufficient
+* ⇢ ⇢ Prioritize towards the overall reliability goal
+* ⇢ ⇢ The quiet time vs the burnout
+* ⇢ ⇢ Error budget as a learning budget
+* ⇢ ⇢ Introducing SRE
+* ⇢ ⇢ Heroes and On-Call Practices
+* ⇢ ⇢ Prevent failures through improved system design
+* ⇢ ⇢ On-call health and postmortems
+* ⇢ ⇢ Time Management and Cultural Considerations
+* ⇢ ⇢ Alert volume vs effectiveness
+
+## Introduction
+
+That willingness to learn makes sense for SREs, given the need to work with complex systems. The systems change constantly, and the role requires someone wanting to ask questions about how they work. Curiosity is a trait found in many SREs.
+
+It's normal (and fine) for some of our work to deal with immediate needs, but teams that operate only on the urgent side of the Eisenhower matrix are limited in what they can achieve. Nothing is ever perfect, so don’t aim for it. Ensure instead that you’re aiming to be reliable just enough of the time. Because that’s where the power is.
+
+* Why didn’t it work like it did yesterday? What changed?
+* It was as though production were a foreign land, and they needed me to accompany them as a translator.
+* Any of us could see that it was slow; explaining why was next-level interesting.
+* The harder and more subtle the bug, the more interested and energized they become.
+* When we get together with other infrastructure engineers over a pint, we boast about the outages we have seen, the bugs we have found, and the "you-won’t-believe-what-happened-last-holiday" stories.
+
+## Observability
+
+Observability would swamp most observability systems with an obscene amount of storage and scale. It would simply be impractical to pay for a system capable of doing that. Observability helps your investigation of problems pinpoint likely sources. Observability is not for debugging your code logic. It is for figuring out where in your systems to find the code you need to debug.
+
+## The ancient art of writing things down
+
+When it comes to reliability, we’re used to discussing new advances in the field, but one of the most powerful forces for reliability is also one of the oldest: the ancient art of writing things down.
+
+* A culture of documenting our ideas helps us design, build, and maintain reliable systems.
+* It lets us uncover misunderstandings before they lead to mistakes, and it can take critical minutes off outage resolution.
+* A culture of writing things down reduces ambiguity and helps us make better decisions.
+
+An SLO of 99.9% only tells you anything if you know what the service’s owners consider “available” to mean. If there’s an accompanying SLO definition document that explains that a one-second response is considered a success, and you were hoping for 10-millisecond latencies, you’ll reevaluate whether this backend is the one for you.
+
+* Writing shortens incidents too.
+* Writing takes longer in the short term, but if you take a little extra time to describe what’s happening, you’ll help others save time by reading your mind.
+
+## The teams health
+
+To decide, you must know what you value most in a job and what you can expect from companies. As we fine-tune SLOs and iterate on rotation design, it’s equally important to keep in touch with the pulse of the team’s health, and constantly ask: As a group, are we working in a way that is sustainable over the long haul?
+
+* Emotional exhaustion: spending too much time caring too much.
+* Depersonalization: feeling less empathy for others.
+* Decreased sense of accomplishment.
+
+The second notion was, “No one pays for generalists; you need to specialize.” Now I’m an SRE. Burnout is a challenge. It will happen a few times, and each time you think, “I’ll never fall for that again." Again, you will work too hard, too long, without reward or appreciation. It can permanently damage your health. 
+
+* The young and invincible assume it won’t happen to them.
+* Life is a marathon, not a sprint.
+
+Dilemmas get easier when you ask, “In ten years, what will I wish I’d done?” Feeling financially trapped makes situations far worse. We work for managers, not companies. Ensure you are only 80% sure you can do the jobs you apply for, so you stretch yourself. Managers aren’t your friends; they are your agents. Fire them if you don’t like the community, work, or money they bring you.
+
+The efforts and personal sacrifices of engineers are meaningless if they do not resonate at a strategic level. The Space Shuttle Challenger was approved for launch by NASA managers seeking to avoid delays in an already beleaguered schedule, despite known engineer concerns about the safety of the orbiter vehicle in subzero launch temperatures.
+
+* When engineers engineer and leaders lead in isolated vacuums, introspective behaviors, shared empathy, and mutual trust for each other cannot flourish.
+* SRE offers a shared language for leveling the playing field between engineers and leaders.
+* Measure, analyze, decide, act, reflect and repeat: that’s site reliability engineering in six words.
+
+## Sharing responsibilities
+
+Embracing the idea “you build it, you run it” empowers everyone in your organization with shared responsibility for reliability and broad use of your team’s skills.
+
+* Through sharing the pain of running production services, opportunities to develop shared empathy and technical understanding necessary at scale are improved.
+* You can’t fix it all.
+* Adding SRE to your company one task at a time and making things better.
+* We're not aiming for perfection; we’re just looking for better.
+* Take small steps, with the understanding that when dealing with complex, unpredictable things, the plan can’t specify everything.
+
+## The roles and the solo SRE
+
+Three roles: incident manager, expert/operator, and communications. Typically, incident management roles include an incident commander, technical lead, and communications lead. Incident management is a natural progression after observability.
+
+The most important point to remember in being a solo SRE is that although you can effect change within your organization, you cannot do it alone, so don’t try to carry the weight of your organization’s problems on your shoulders.
+
+* SLOs must be able to evolve over time.
+* SLIs, SLOs, and error budgets are the bedrock of site reliability engineering.
+* Having a hard mandate about when to ship code probably doesn’t make much sense in many situations, but using this data to help you figure out what your team should be focused on does.
+* Use your error budget status to figure out when to experiment.
+* Ensure you’re not being more reliable than you advertise.
+* At startups, SRE is often an afterthought behind shiny new features.
+
+## Being customer-focused
+
+SRE is about being customer-focused. Regardless of the stage of development, it is critical to understand the bottlenecks in your system and communicate them to stakeholders. There is likely to be a strong push to ignore SRE capability work and focus on new features. However, for most enterprises, introducing SLOs and error budgets to business-critical services remains a key differentiator for establishing SRE.
+
+* If SLOs are not status quo in your organization, be prepared to invest a significant amount of time teaching stakeholders about the importance of SLOs.
+* Textbook implementations of SRE rarely translate well in enterprises, given the diversity of businesses.
+* Toil work measurement reduction from SLO improvements should always be quantifiable.
+
+## Don't have all the answers
+
+There is unfortunate pressure on people to feel like they have all the answers. In meetings, we often see someone tap dancing nervously around an answer they don’t have, especially when asked by someone higher up the management chain. It’s not our role as engineers and leaders always to have the answers.
+
+* A simple tactic to get your work recognized: write a document listing your accomplishments.
+* Ensure that you’re being reliable enough.
+
+## Runbooks
+
+Once a mental model can be recorded, reproduced, and shared, it becomes a general-purpose abstraction. It speeds communication and gives people standard tools to refer to when reasoning about behavior, outages, and proposed changes to the system.
+
+* Runbooks (also known as playbooks) are not a silver bullet (nothing is). They share all of documentation’s pitfalls: accuracy, quality, maintainability, drift.
+* Runbooks are generally concerned with known unknowns, and we cannot anticipate every problem.
+* Teams overinvest in runbooks, creating new sources of toil.
+* Inaccurate or outdated runbooks can be more dangerous than no runbooks.
+* Runbook creation, maintenance, and review should be a whole-team activity.
+* Having too many runbooks is an anti-pattern.
+
+Runbooks cannot and will not solve every incident. But that’s fine. As incidents become more novel, there is a point at which an investment in runbooks starts to show diminishing returns.
+
+* Playbooks: It’s infeasible to assume that any playbook is absolutely complete, so expect it to be a tool that cannot fill the entire role of an SRE.
+* Playbooks help an on-caller resolve issues but can contain too much or too little detail.
+* Playbooks should ideally only contain the basics.
+* The last anti-pattern is being too prescriptive.
+
+## Alerts per shift
+
+* Severity and qualification of the user-visible impact.
+* Alerts per shift: The maximum of 10 alerts per shift.
+* On-call rotation: A minimum of eight people should be in the rotation, assuming week-long shifts and a primary/secondary setup.
+* SRE happiness: A survey using an emoji rating is sent to SREs after each on call, aiming for an average of ☺. This is different from previous SLOs in that it is qualitative instead of quantitative.
+
+In a transitory phase, people who are more often on call will get two mandatory consecutive days of recovery to prevent burnout.
+
+* If the maximum number of alerts has been attained, the pager will be taken by someone else on the team to allow proper recovery time. Dealing with too much toil, having night shifts, and constantly being the first line of defense against outages can take a toll on SREs and the systems they work on. Prompt SREs to take time off when they encounter particularly stressful on calls.
+
+## Balancing velocity
+
+As SREs, we see our job as balancing velocity with reliability. 
+
+> You Don’t Know for Sure Until It Runs in Production.
+
+We often view production as a house of cards–like a fragile ecosystem that needs to be approached with care, silk gloves, or bunker gear. Incident reviews are a perfect opportunity to target and remove detrimental complexity. Incidents give us the space to zoom out and notice detrimental complexity.
+
+Simpler systems that aren’t perfect are usually better than complex ones. We often think of incidents in terms of TTx (time to x), like time to detect or time to mitigate, but these metrics provide little insight into what makes an incident interesting.
+
+*If an engineer is a hero, there’s a gap in the process, the infrastructure, or the tooling.
+* Metrics Are Not SLIs (The Measure Everything Trap).
+
+"Measure everything" is a trap. Metrics are raw numbers: how many items in a queue, how many days since the last failure. SLIs are combinations of metrics that tell a story: like if the queue keeps filling at the current rate.
+
+* SLIs provide evidence of service efficiency and longevity.
+* Important to revisit your SLIs constantly.
+* When woken up in the night, will this metric help me or the team get the service back up faster?
+* Will this metric be useful for alerting?
+* Most metrics will never be looked at or read.
+
+## The power in knowing how to be self-sufficient
+
+There is power in knowing how to be self-sufficient, in having the tools and the fearlessness to track answers down through layers of abstractions. SLOs are about quantifying delivered service, setting appropriate expectations, and changing tactics when things aren’t going well.
+
+* Time is the scarcest of resources in engineering.
+* It starts with a commitment at the company level to enable engineers to consistently address reliability concerns on a project.
+
+## Prioritize towards the overall reliability goal
+
+Part of the solution is to prioritize working on something small towards the overall reliability goals every day, rather than working on it for a week and then moving on, never to return.
+
+* If SREs are constantly engaged with other teams, what about the SRE backlog?
+* Adopt a shared-goals model to balance reducing the automation backlog and engaging with other teams.
+* Requires a deep curiosity for how things work.
+* Requires unrealistic expectations of complete knowledge from SREs.
+* Organizations hire SREs assuming they code well, understand systems deeply, know monitoring and alerting, can run any service, debug production issues, and improve performance.
+* Usually doesn’t count on performance reviews and isn’t recognized as delivering impact. Not included in the team’s planning.
+
+Mentoring others becomes part of this. It requires time, energy, dedication, and goodwill, so it is considered additional work. 
+
+* It is okay to accept an average solution that works and let the engineer improve it over time.
+* Stepping back during an incident so others can learn and step up.
+* Integrating mentoring into the team’s day-to-day work is a building block that can make it more inclusive and help it thrive.
+* When running services, we use baselines.
+* Incident heroism can produce results but may also overshadow others and prevent them from gaining confidence.
+
+## The quiet time vs the burnout
+
+Quiet time in the morning can be used to work on tasks with fewer interruptions. Remote ICs (individual contributors) have opportunities to be productive differently than before, like time-shifting work or breaking up their day.
+
+* Problem-solving requires creativity, which requires free space.
+* On the flip side from burnout, creativity thrives in semi-constrained spaces.
+* Many insights result from detaching from a problem and finding insight elsewhere.
+
+It's important for mental and physical health to create and maintain personal margin to avoid burnout. Renewing activities counter environmental uncertainty: breaks, changes of scenery, and exercise. Incidents are unplanned investments in understanding systems. The learning budget is where you explore new, creative approaches.
+
+## Error budget as a learning budget
+
+Also known as the error budget, this leftover part is where or when the service does not meet the objective. It's more helpful to think about this as the learning budget. Shouldn't we just be open that we’re all committed to reliability and have leadership prioritize it? Sure, in a perfect world, but driving culture change means being passionate about the vision and patient enough to know folks need training wheels.
+
+Focus not just on a single night; rather, lay the groundwork for creating an operationally mature organization. We are creatures of habit—sudden changes of routine and operating outside our comfort zone attract doubt. Changing too much too quickly leads to confusion and skepticism.
+
+## Introducing SRE
+
+Bringing SRE means overcoming inertia and requires substantial investment in time to educate and continuously reinforce practices and behaviors.
+
+Change is hard, especially in large organizations. Focus initially on the most critical behaviors to adapt and help spread awareness.
+
+* Identify culture carriers in your organization who empower others and build trust.
+* A team of rock-star SREs doesn’t guarantee success.
+
+discuss several sources of complexity. The biggest and hardest to deal with is state. State influences control flow, but the number of potential software states increases exponentially with variables. Separating the SRE team from development teams—sometimes by creating a Center of Excellence—causes problems rather than solving them.
+Elitism and knowledge constraints are issues.
+
+* One solution can be embedding SREs into dev teams.
+* Don’t underestimate the power of documentation.
+* Defining SLOs for your service, step by step.
+* Two pages defining SLOs (high level).
+* The biggest mistakes in engineering organizations often involve not creating well-structured and discoverable technical documentation.
+* Others may doubt the maturity of the company in adopting SRE principles without proper documentation.
+* Basic arguments for SLOs might conflict with existing goals, requiring patient explanation.
+
+SLOs, SLIs, and error budgets will require convincing within the organization. Some may prioritize feature velocity over reliability work. Once engineering, operations, and product teams buy in, it's essential to engage senior leadership. The benefits of SRE practices, such as greater release velocity and early insights into the user experience, should be emphasized to them.
+
+The key argument to leadership is that SRE practices will provide better feature velocity over time.
+
+## Heroes and On-Call Practices
+
+Heroes are necessary, but hero culture is not. A hero culture can easily form, but an SRE mindset helps combat this. If no action is required, tweak thresholds or delete alerts. Treat every page as an exceptional circumstance. Include on-call behaviors in developmental and career progression frameworks. On-callers should shadow experienced engineers to practice incident response. Trial by fire is not a prerequisite for being good on call. Best improvement ideas often come from the on-callers themselves.
+
+Regular retrospectives and reflection improve on-call experiences. Good communication and collaboration multiply team efficiency. Successful teams frequently meet to improve processes and keep documentation up to date.
+
+* Technical literacy and hands-on experience contribute to on-call satisfaction.
+* Effective onboarding and training are essential.
+* For clarity, ask, “Will this make sense if you’ve just been woken up?”
+* Provide a clear escalation path with contact details and thresholds.
+
+## Prevent failures through improved system design
+
+When a cascading failure occurs, many issues arise simultaneously, overwhelming systems. Even prepared teams can struggle to mitigate without serious user impact. A more effective strategy involves preventing failures through improved system design.
+
+* SLIs, SLOs, and SLAs define service health.
+* Availability and reliability are continuously measured.
+* Postmortems focus on customer impact.
+* Health checks quickly detect service failures.
+
+## On-call health and postmortems
+
+On-call health is crucial. Postmortems should analyze alerts for noise and automate recurring tasks. Action items from retrospectives should be timely completed.
+
+* Link SLAs to on-call health to get a full picture of service quality.
+* Error budgets concern not just availability but the quality of that availability.
+* Performance budgets set limits on various performance metrics.
+* Observability tools are designed for high cardinality data queries.
+* Important tasks are prioritized; unimportant tasks are delegated or ignored.
+* A roadmap helps avoid being trapped by immediate tasks.
+
+## Time Management and Cultural Considerations
+
+* SREs traditionally spend no more than 50% on ops work, with the rest coding.
+* Over time, “at least 50% code” shifted to “at most 50% ops.”
+* Fifty percent ops work sounds viable, but not fifty percent toil.
+
+Toil reduction should be a goal across all engineering disciplines. Reliability and operability demand proactive planning, not just reactive fixes. An SRE team should ensure systems need less human intervention to function. It's crucial to make SRE contributions visible to prevent organizational decay. While we cannot track prevented incidents, preventive efforts are invaluable.
+
+* In a complex world, avoid attributing issues solely to human error.
+* Recognize tooling, operational, and resource gaps.
+* An SRE mindset will be key in hiring for every engineering role.
+* All engineers can incorporate SRE practices without needing dedicated SRE teams.
+* Effective communication and precise writing are invaluable for reliability.
+* SRE adoption is cultural, not merely about automating operations.
+
+Remember, engineering will always face breakages, which can lead to burnout. Mental health is a priority. Error budgets provide data for better decision-making. When faced with incidents outside SREs' control, cultural shifts ensure long-term success.
+
+Building a successful team in large enterprises is challenging. A culture emphasizing knowledge sharing, collaboration, and preparation is more beneficial than runbooks alone.
+
+* Mitigation tooling helps in incident management.
+* Identify escalation paths: developers, back-end teams, or dedicated incident teams.
+* Use consoles, logs, and inspection tools for problem-solving.
+
+SREs protect critical systems, facing excitement and risk of burnout. Reliable systems require quick improvements and avoidance of delay-inducing processes. Modernize systems incrementally, focusing on small, frequent deployments to manage risk.
+
+Establishing a solid SRE culture is vital for sustainable success. Comprehensive documentation should not undergo the same review as code. Heroes do their best work as part of a team; a hero culture isn’t essential.
+
+* Building happy, healthy on-call rotations fosters better outcomes.
+* Incentivize, reduce pain points, mentor, and iterate rapidly.
+
+## Alert volume vs effectiveness
+
+The volume of alerts isn’t as critical as handling them effectively. Trust, ownership, communication, and collaboration underpin successful teams, improving processes and reliability. Like maintaining fire safety, regularly test systems to prevent outages.
+
+* Prioritize long-term impacts over daily distractions.
+* SREs need to set limits on toil to mature as a discipline.
+* Engineers must communicate risks clearly and prepare for future gaps exposed by incidents.
+* Individuals understand only parts of complex systems.
+
+Introducing SRE courses in academia would signify a new era in engineering.
+
+Other book notes of mine are:
+
+
+E-Mail your comments to `paul@nospam.buetow.org` :-)
+
+=> ../ Back to the main site
diff --git a/notes/97-things-every-sre-should-know.gmi.tpl b/notes/97-things-every-sre-should-know.gmi.tpl
new file mode 100644
index 00000000..67564bc6
--- /dev/null
+++ b/notes/97-things-every-sre-should-know.gmi.tpl
@@ -0,0 +1,289 @@
+# "97 Things Every SRE Should Know" book notes
+
+These are my personal book notes of Emil Stolarsky's and Jaime Woo's "97 Things Every SRE Should Know". They are for myself, but I hope they might be useful to you too.
+
+<< template::inline::toc
+
+## Introduction
+
+That willingness to learn makes sense for SREs, given the need to work with complex systems. The systems change constantly, and the role requires someone wanting to ask questions about how they work. Curiosity is a trait found in many SREs.
+
+It's normal (and fine) for some of our work to deal with immediate needs, but teams that operate only on the urgent side of the Eisenhower matrix are limited in what they can achieve. Nothing is ever perfect, so don’t aim for it. Ensure instead that you’re aiming to be reliable just enough of the time. Because that’s where the power is.
+
+* Why didn’t it work like it did yesterday? What changed?
+* It was as though production were a foreign land, and they needed me to accompany them as a translator.
+* Any of us could see that it was slow; explaining why was next-level interesting.
+* The harder and more subtle the bug, the more interested and energized they become.
+* When we get together with other infrastructure engineers over a pint, we boast about the outages we have seen, the bugs we have found, and the "you-won’t-believe-what-happened-last-holiday" stories.
+
+## Observability
+
+Observability would swamp most observability systems with an obscene amount of storage and scale. It would simply be impractical to pay for a system capable of doing that. Observability helps your investigation of problems pinpoint likely sources. Observability is not for debugging your code logic. It is for figuring out where in your systems to find the code you need to debug.
+
+## The ancient art of writing things down
+
+When it comes to reliability, we’re used to discussing new advances in the field, but one of the most powerful forces for reliability is also one of the oldest: the ancient art of writing things down.
+
+* A culture of documenting our ideas helps us design, build, and maintain reliable systems.
+* It lets us uncover misunderstandings before they lead to mistakes, and it can take critical minutes off outage resolution.
+* A culture of writing things down reduces ambiguity and helps us make better decisions.
+
+An SLO of 99.9% only tells you anything if you know what the service’s owners consider “available” to mean. If there’s an accompanying SLO definition document that explains that a one-second response is considered a success, and you were hoping for 10-millisecond latencies, you’ll reevaluate whether this backend is the one for you.
+
+* Writing shortens incidents too.
+* Writing takes longer in the short term, but if you take a little extra time to describe what’s happening, you’ll help others save time by reading your mind.
+
+## The teams health
+
+To decide, you must know what you value most in a job and what you can expect from companies. As we fine-tune SLOs and iterate on rotation design, it’s equally important to keep in touch with the pulse of the team’s health, and constantly ask: As a group, are we working in a way that is sustainable over the long haul?
+
+* Emotional exhaustion: spending too much time caring too much.
+* Depersonalization: feeling less empathy for others.
+* Decreased sense of accomplishment.
+
+The second notion was, “No one pays for generalists; you need to specialize.” Now I’m an SRE. Burnout is a challenge. It will happen a few times, and each time you think, “I’ll never fall for that again." Again, you will work too hard, too long, without reward or appreciation. It can permanently damage your health. 
+
+* The young and invincible assume it won’t happen to them.
+* Life is a marathon, not a sprint.
+
+Dilemmas get easier when you ask, “In ten years, what will I wish I’d done?” Feeling financially trapped makes situations far worse. We work for managers, not companies. Ensure you are only 80% sure you can do the jobs you apply for, so you stretch yourself. Managers aren’t your friends; they are your agents. Fire them if you don’t like the community, work, or money they bring you.
+
+The efforts and personal sacrifices of engineers are meaningless if they do not resonate at a strategic level. The Space Shuttle Challenger was approved for launch by NASA managers seeking to avoid delays in an already beleaguered schedule, despite known engineer concerns about the safety of the orbiter vehicle in subzero launch temperatures.
+
+* When engineers engineer and leaders lead in isolated vacuums, introspective behaviors, shared empathy, and mutual trust for each other cannot flourish.
+* SRE offers a shared language for leveling the playing field between engineers and leaders.
+* Measure, analyze, decide, act, reflect and repeat: that’s site reliability engineering in six words.
+
+## Sharing responsibilities
+
+Embracing the idea “you build it, you run it” empowers everyone in your organization with shared responsibility for reliability and broad use of your team’s skills.
+
+* Through sharing the pain of running production services, opportunities to develop shared empathy and technical understanding necessary at scale are improved.
+* You can’t fix it all.
+* Adding SRE to your company one task at a time and making things better.
+* We're not aiming for perfection; we’re just looking for better.
+* Take small steps, with the understanding that when dealing with complex, unpredictable things, the plan can’t specify everything.
+
+## The roles and the solo SRE
+
+Three roles: incident manager, expert/operator, and communications. Typically, incident management roles include an incident commander, technical lead, and communications lead. Incident management is a natural progression after observability.
+
+The most important point to remember in being a solo SRE is that although you can effect change within your organization, you cannot do it alone, so don’t try to carry the weight of your organization’s problems on your shoulders.
+
+* SLOs must be able to evolve over time.
+* SLIs, SLOs, and error budgets are the bedrock of site reliability engineering.
+* Having a hard mandate about when to ship code probably doesn’t make much sense in many situations, but using this data to help you figure out what your team should be focused on does.
+* Use your error budget status to figure out when to experiment.
+* Ensure you’re not being more reliable than you advertise.
+* At startups, SRE is often an afterthought behind shiny new features.
+
+## Being customer-focused
+
+SRE is about being customer-focused. Regardless of the stage of development, it is critical to understand the bottlenecks in your system and communicate them to stakeholders. There is likely to be a strong push to ignore SRE capability work and focus on new features. However, for most enterprises, introducing SLOs and error budgets to business-critical services remains a key differentiator for establishing SRE.
+
+* If SLOs are not status quo in your organization, be prepared to invest a significant amount of time teaching stakeholders about the importance of SLOs.
+* Textbook implementations of SRE rarely translate well in enterprises, given the diversity of businesses.
+* Toil work measurement reduction from SLO improvements should always be quantifiable.
+
+## Don't have all the answers
+
+There is unfortunate pressure on people to feel like they have all the answers. In meetings, we often see someone tap dancing nervously around an answer they don’t have, especially when asked by someone higher up the management chain. It’s not our role as engineers and leaders always to have the answers.
+
+* A simple tactic to get your work recognized: write a document listing your accomplishments.
+* Ensure that you’re being reliable enough.
+
+## Runbooks
+
+Once a mental model can be recorded, reproduced, and shared, it becomes a general-purpose abstraction. It speeds communication and gives people standard tools to refer to when reasoning about behavior, outages, and proposed changes to the system.
+
+* Runbooks (also known as playbooks) are not a silver bullet (nothing is). They share all of documentation’s pitfalls: accuracy, quality, maintainability, drift.
+* Runbooks are generally concerned with known unknowns, and we cannot anticipate every problem.
+* Teams overinvest in runbooks, creating new sources of toil.
+* Inaccurate or outdated runbooks can be more dangerous than no runbooks.
+* Runbook creation, maintenance, and review should be a whole-team activity.
+* Having too many runbooks is an anti-pattern.
+
+Runbooks cannot and will not solve every incident. But that’s fine. As incidents become more novel, there is a point at which an investment in runbooks starts to show diminishing returns.
+
+* Playbooks: It’s infeasible to assume that any playbook is absolutely complete, so expect it to be a tool that cannot fill the entire role of an SRE.
+* Playbooks help an on-caller resolve issues but can contain too much or too little detail.
+* Playbooks should ideally only contain the basics.
+* The last anti-pattern is being too prescriptive.
+
+## Alerts per shift
+
+* Severity and qualification of the user-visible impact.
+* Alerts per shift: The maximum of 10 alerts per shift.
+* On-call rotation: A minimum of eight people should be in the rotation, assuming week-long shifts and a primary/secondary setup.
+* SRE happiness: A survey using an emoji rating is sent to SREs after each on call, aiming for an average of ☺. This is different from previous SLOs in that it is qualitative instead of quantitative.
+
+In a transitory phase, people who are more often on call will get two mandatory consecutive days of recovery to prevent burnout.
+
+* If the maximum number of alerts has been attained, the pager will be taken by someone else on the team to allow proper recovery time. Dealing with too much toil, having night shifts, and constantly being the first line of defense against outages can take a toll on SREs and the systems they work on. Prompt SREs to take time off when they encounter particularly stressful on calls.
+
+## Balancing velocity
+
+As SREs, we see our job as balancing velocity with reliability. 
+
+> You Don’t Know for Sure Until It Runs in Production.
+
+We often view production as a house of cards–like a fragile ecosystem that needs to be approached with care, silk gloves, or bunker gear. Incident reviews are a perfect opportunity to target and remove detrimental complexity. Incidents give us the space to zoom out and notice detrimental complexity.
+
+Simpler systems that aren’t perfect are usually better than complex ones. We often think of incidents in terms of TTx (time to x), like time to detect or time to mitigate, but these metrics provide little insight into what makes an incident interesting.
+
+*If an engineer is a hero, there’s a gap in the process, the infrastructure, or the tooling.
+* Metrics Are Not SLIs (The Measure Everything Trap).
+
+"Measure everything" is a trap. Metrics are raw numbers: how many items in a queue, how many days since the last failure. SLIs are combinations of metrics that tell a story: like if the queue keeps filling at the current rate.
+
+* SLIs provide evidence of service efficiency and longevity.
+* Important to revisit your SLIs constantly.
+* When woken up in the night, will this metric help me or the team get the service back up faster?
+* Will this metric be useful for alerting?
+* Most metrics will never be looked at or read.
+
+## The power in knowing how to be self-sufficient
+
+There is power in knowing how to be self-sufficient, in having the tools and the fearlessness to track answers down through layers of abstractions. SLOs are about quantifying delivered service, setting appropriate expectations, and changing tactics when things aren’t going well.
+
+* Time is the scarcest of resources in engineering.
+* It starts with a commitment at the company level to enable engineers to consistently address reliability concerns on a project.
+
+## Prioritize towards the overall reliability goal
+
+Part of the solution is to prioritize working on something small towards the overall reliability goals every day, rather than working on it for a week and then moving on, never to return.
+
+* If SREs are constantly engaged with other teams, what about the SRE backlog?
+* Adopt a shared-goals model to balance reducing the automation backlog and engaging with other teams.
+* Requires a deep curiosity for how things work.
+* Requires unrealistic expectations of complete knowledge from SREs.
+* Organizations hire SREs assuming they code well, understand systems deeply, know monitoring and alerting, can run any service, debug production issues, and improve performance.
+* Usually doesn’t count on performance reviews and isn’t recognized as delivering impact. Not included in the team’s planning.
+
+Mentoring others becomes part of this. It requires time, energy, dedication, and goodwill, so it is considered additional work. 
+
+* It is okay to accept an average solution that works and let the engineer improve it over time.
+* Stepping back during an incident so others can learn and step up.
+* Integrating mentoring into the team’s day-to-day work is a building block that can make it more inclusive and help it thrive.
+* When running services, we use baselines.
+* Incident heroism can produce results but may also overshadow others and prevent them from gaining confidence.
+
+## The quiet time vs the burnout
+
+Quiet time in the morning can be used to work on tasks with fewer interruptions. Remote ICs (individual contributors) have opportunities to be productive differently than before, like time-shifting work or breaking up their day.
+
+* Problem-solving requires creativity, which requires free space.
+* On the flip side from burnout, creativity thrives in semi-constrained spaces.
+* Many insights result from detaching from a problem and finding insight elsewhere.
+
+It's important for mental and physical health to create and maintain personal margin to avoid burnout. Renewing activities counter environmental uncertainty: breaks, changes of scenery, and exercise. Incidents are unplanned investments in understanding systems. The learning budget is where you explore new, creative approaches.
+
+## Error budget as a learning budget
+
+Also known as the error budget, this leftover part is where or when the service does not meet the objective. It's more helpful to think about this as the learning budget. Shouldn't we just be open that we’re all committed to reliability and have leadership prioritize it? Sure, in a perfect world, but driving culture change means being passionate about the vision and patient enough to know folks need training wheels.
+
+Focus not just on a single night; rather, lay the groundwork for creating an operationally mature organization. We are creatures of habit—sudden changes of routine and operating outside our comfort zone attract doubt. Changing too much too quickly leads to confusion and skepticism.
+
+## Introducing SRE
+
+Bringing SRE means overcoming inertia and requires substantial investment in time to educate and continuously reinforce practices and behaviors.
+
+Change is hard, especially in large organizations. Focus initially on the most critical behaviors to adapt and help spread awareness.
+
+* Identify culture carriers in your organization who empower others and build trust.
+* A team of rock-star SREs doesn’t guarantee success.
+
+discuss several sources of complexity. The biggest and hardest to deal with is state. State influences control flow, but the number of potential software states increases exponentially with variables. Separating the SRE team from development teams—sometimes by creating a Center of Excellence—causes problems rather than solving them.
+Elitism and knowledge constraints are issues.
+
+* One solution can be embedding SREs into dev teams.
+* Don’t underestimate the power of documentation.
+* Defining SLOs for your service, step by step.
+* Two pages defining SLOs (high level).
+* The biggest mistakes in engineering organizations often involve not creating well-structured and discoverable technical documentation.
+* Others may doubt the maturity of the company in adopting SRE principles without proper documentation.
+* Basic arguments for SLOs might conflict with existing goals, requiring patient explanation.
+
+SLOs, SLIs, and error budgets will require convincing within the organization. Some may prioritize feature velocity over reliability work. Once engineering, operations, and product teams buy in, it's essential to engage senior leadership. The benefits of SRE practices, such as greater release velocity and early insights into the user experience, should be emphasized to them.
+
+The key argument to leadership is that SRE practices will provide better feature velocity over time.
+
+## Heroes and On-Call Practices
+
+Heroes are necessary, but hero culture is not. A hero culture can easily form, but an SRE mindset helps combat this. If no action is required, tweak thresholds or delete alerts. Treat every page as an exceptional circumstance. Include on-call behaviors in developmental and career progression frameworks. On-callers should shadow experienced engineers to practice incident response. Trial by fire is not a prerequisite for being good on call. Best improvement ideas often come from the on-callers themselves.
+
+Regular retrospectives and reflection improve on-call experiences. Good communication and collaboration multiply team efficiency. Successful teams frequently meet to improve processes and keep documentation up to date.
+
+* Technical literacy and hands-on experience contribute to on-call satisfaction.
+* Effective onboarding and training are essential.
+* For clarity, ask, “Will this make sense if you’ve just been woken up?”
+* Provide a clear escalation path with contact details and thresholds.
+
+## Prevent failures through improved system design
+
+When a cascading failure occurs, many issues arise simultaneously, overwhelming systems. Even prepared teams can struggle to mitigate without serious user impact. A more effective strategy involves preventing failures through improved system design.
+
+* SLIs, SLOs, and SLAs define service health.
+* Availability and reliability are continuously measured.
+* Postmortems focus on customer impact.
+* Health checks quickly detect service failures.
+
+## On-call health and postmortems
+
+On-call health is crucial. Postmortems should analyze alerts for noise and automate recurring tasks. Action items from retrospectives should be timely completed.
+
+* Link SLAs to on-call health to get a full picture of service quality.
+* Error budgets concern not just availability but the quality of that availability.
+* Performance budgets set limits on various performance metrics.
+* Observability tools are designed for high cardinality data queries.
+* Important tasks are prioritized; unimportant tasks are delegated or ignored.
+* A roadmap helps avoid being trapped by immediate tasks.
+
+## Time Management and Cultural Considerations
+
+* SREs traditionally spend no more than 50% on ops work, with the rest coding.
+* Over time, “at least 50% code” shifted to “at most 50% ops.”
+* Fifty percent ops work sounds viable, but not fifty percent toil.
+
+Toil reduction should be a goal across all engineering disciplines. Reliability and operability demand proactive planning, not just reactive fixes. An SRE team should ensure systems need less human intervention to function. It's crucial to make SRE contributions visible to prevent organizational decay. While we cannot track prevented incidents, preventive efforts are invaluable.
+
+* In a complex world, avoid attributing issues solely to human error.
+* Recognize tooling, operational, and resource gaps.
+* An SRE mindset will be key in hiring for every engineering role.
+* All engineers can incorporate SRE practices without needing dedicated SRE teams.
+* Effective communication and precise writing are invaluable for reliability.
+* SRE adoption is cultural, not merely about automating operations.
+
+Remember, engineering will always face breakages, which can lead to burnout. Mental health is a priority. Error budgets provide data for better decision-making. When faced with incidents outside SREs' control, cultural shifts ensure long-term success.
+
+Building a successful team in large enterprises is challenging. A culture emphasizing knowledge sharing, collaboration, and preparation is more beneficial than runbooks alone.
+
+* Mitigation tooling helps in incident management.
+* Identify escalation paths: developers, back-end teams, or dedicated incident teams.
+* Use consoles, logs, and inspection tools for problem-solving.
+
+SREs protect critical systems, facing excitement and risk of burnout. Reliable systems require quick improvements and avoidance of delay-inducing processes. Modernize systems incrementally, focusing on small, frequent deployments to manage risk.
+
+Establishing a solid SRE culture is vital for sustainable success. Comprehensive documentation should not undergo the same review as code. Heroes do their best work as part of a team; a hero culture isn’t essential.
+
+* Building happy, healthy on-call rotations fosters better outcomes.
+* Incentivize, reduce pain points, mentor, and iterate rapidly.
+
+## Alert volume vs effectiveness
+
+The volume of alerts isn’t as critical as handling them effectively. Trust, ownership, communication, and collaboration underpin successful teams, improving processes and reliability. Like maintaining fire safety, regularly test systems to prevent outages.
+
+* Prioritize long-term impacts over daily distractions.
+* SREs need to set limits on toil to mature as a discipline.
+* Engineers must communicate risks clearly and prepare for future gaps exposed by incidents.
+* Individuals understand only parts of complex systems.
+
+Introducing SRE courses in academia would signify a new era in engineering.
+
+Other book notes of mine are:
+
+<< template::inline::rindex book-notes
+
+E-Mail your comments to `paul@nospam.buetow.org` :-)
+
+=> ../ Back to the main site
diff --git a/notes/implementing-service-level-objectives.gmi b/notes/implementing-service-level-objectives.gmi
new file mode 100644
index 00000000..49c97130
--- /dev/null
+++ b/notes/implementing-service-level-objectives.gmi
@@ -0,0 +1,83 @@
+# "Implementing Service Level Objectives" book notes
+
+These are my personal book notes of Alex Hidalgo's "Implementing Service Level Objectives: A Pratical Guide to SLIs, SLOs, and Error Budgets" They are for myself, but I hope they might be useful to you too.
+
+## Table of Contents
+
+* ⇢ "Implementing Service Level Objectives" book notes
+* ⇢ ⇢ Introduction
+* ⇢ ⇢ Importance of Documentation
+* ⇢ ⇢ Implementation Phases
+* ⇢ ⇢ ⇢ The Three Phases of SLO Implementation
+* ⇢ ⇢ ⇢ Phase 1: Defining SLOs
+* ⇢ ⇢ ⇢ Phase 2: Collecting SLIs
+* ⇢ ⇢ ⇢ Phase 3: Utilizing SLOs
+* ⇢ ⇢ Best Practices
+
+## Introduction
+
+Service Level Objectives (SLOs) are a fundamental component in ensuring service reliability, enhancing engineering effectiveness, and aligning organizational goals. Below is a comprehensive guide to understanding and implementing SLOs, focusing on the critical documentation required and the three phases of SLO implementation.
+
+## Importance of Documentation
+
+Documentation Support: Strong documentation is essential in supporting both you and your organization throughout the SLO implementation process. It provides clarity and guidance, making the transition smoother and more efficient.
+
+## Implementation Phases
+
+### The Three Phases of SLO Implementation
+
+* 1. Define the SLO
+* 2. Collect the SLOs
+* 3. Use the SLO
+
+### Phase 1: Defining SLOs
+
+Strategy Document:
+
+Create a one-page strategy document. This document is vital in the initial 'crawl' phase, outlining what you are trying to achieve, why, and how. It should be concise, allowing anyone to read it in less than ten minutes. It's crucial to get this document right, as it answers:
+
+* What will we get out of creating SLOs?
+* How will SLOs improve service reliability?
+* How will it help engineering teams?
+* Ensure the document is reviewed and signed off by leadership to garner support.
+
+SLO Definition Document:
+
+Draft a two-page document providing a high-level definition of SLOs, including examples of effective ones. This should guide engineers by making SLO implementation accessible and generate interest without overwhelming them with volumes of information.
+
+FAQ Document:
+
+Compile a FAQ document to address anticipated questions as teams begin their SLO journey. Example questions include:
+
+* What if my user is another service? Do I still need to care about SLOs?
+* What if my service's dependencies don't have SLOs?
+* How many SLOs should a service have? How many SLIs?
+
+### Phase 2: Collecting SLIs
+
+Instrumentation Guide:
+
+Once the high-level SLO definition is clear, provide a detailed guide on how to instrument services to collect SLIs. Be specific and include examples from your organization's monitoring platforms. Address scenarios like collecting latency data, using percentiles, and instrumenting different types of services. Offer code snippets to facilitate the instrumentation process.
+
+### Phase 3: Utilizing SLOs
+
+Use Case Documentation:
+ 
+* Document any existing SLO implementations to provide a concrete example for early adopters. 
+* Define where all related artifacts will be stored (e.g., a wiki paired with a code repository).
+* Ensure these resources are easily discoverable and navigable by users.
+
+## Best Practices
+
+Quality Documentation:
+
+* Ensure all documentation undergoes the same quality control process as code.
+* Structured and discoverable documentation is critical for successful implementation across engineering organizations.
+
+This systematic approach to SLO implementation, supported by robust documentation, will help your organization effectively adopt SLOs and improve overall service reliability.
+Other book notes of mine are:
+
+
+E-Mail your comments to `paul@nospam.buetow.org` :-)
+
+=> ../ Back to the main site
diff --git a/notes/implementing-service-level-objectives.gmi.tpl b/notes/implementing-service-level-objectives.gmi.tpl
new file mode 100644
index 00000000..0c763e46
--- /dev/null
+++ b/notes/implementing-service-level-objectives.gmi.tpl
@@ -0,0 +1,74 @@
+# "Implementing Service Level Objectives" book notes
+
+These are my personal book notes of Alex Hidalgo's "Implementing Service Level Objectives: A Pratical Guide to SLIs, SLOs, and Error Budgets" They are for myself, but I hope they might be useful to you too.
+
+<< template::inline::toc
+
+## Introduction
+
+Service Level Objectives (SLOs) are a fundamental component in ensuring service reliability, enhancing engineering effectiveness, and aligning organizational goals. Below is a comprehensive guide to understanding and implementing SLOs, focusing on the critical documentation required and the three phases of SLO implementation.
+
+## Importance of Documentation
+
+Documentation Support: Strong documentation is essential in supporting both you and your organization throughout the SLO implementation process. It provides clarity and guidance, making the transition smoother and more efficient.
+
+## Implementation Phases
+
+### The Three Phases of SLO Implementation
+
+* 1. Define the SLO
+* 2. Collect the SLOs
+* 3. Use the SLO
+
+### Phase 1: Defining SLOs
+
+Strategy Document:
+
+Create a one-page strategy document. This document is vital in the initial 'crawl' phase, outlining what you are trying to achieve, why, and how. It should be concise, allowing anyone to read it in less than ten minutes. It's crucial to get this document right, as it answers:
+
+* What will we get out of creating SLOs?
+* How will SLOs improve service reliability?
+* How will it help engineering teams?
+* Ensure the document is reviewed and signed off by leadership to garner support.
+
+SLO Definition Document:
+
+Draft a two-page document providing a high-level definition of SLOs, including examples of effective ones. This should guide engineers by making SLO implementation accessible and generate interest without overwhelming them with volumes of information.
+
+FAQ Document:
+
+Compile a FAQ document to address anticipated questions as teams begin their SLO journey. Example questions include:
+
+* What if my user is another service? Do I still need to care about SLOs?
+* What if my service's dependencies don't have SLOs?
+* How many SLOs should a service have? How many SLIs?
+
+### Phase 2: Collecting SLIs
+
+Instrumentation Guide:
+
+Once the high-level SLO definition is clear, provide a detailed guide on how to instrument services to collect SLIs. Be specific and include examples from your organization's monitoring platforms. Address scenarios like collecting latency data, using percentiles, and instrumenting different types of services. Offer code snippets to facilitate the instrumentation process.
+
+### Phase 3: Utilizing SLOs
+
+Use Case Documentation:
+ 
+* Document any existing SLO implementations to provide a concrete example for early adopters. 
+* Define where all related artifacts will be stored (e.g., a wiki paired with a code repository).
+* Ensure these resources are easily discoverable and navigable by users.
+
+## Best Practices
+
+Quality Documentation:
+
+* Ensure all documentation undergoes the same quality control process as code.
+* Structured and discoverable documentation is critical for successful implementation across engineering organizations.
+
+This systematic approach to SLO implementation, supported by robust documentation, will help your organization effectively adopt SLOs and improve overall service reliability.
+Other book notes of mine are:
+
+<< template::inline::rindex book-notes
+
+E-Mail your comments to `paul@nospam.buetow.org` :-)
+
+=> ../ Back to the main site
diff --git a/notes/index.gmi b/notes/index.gmi
index 6a781844..df3f12bc 100644
--- a/notes/index.gmi
+++ b/notes/index.gmi
@@ -10,6 +10,7 @@
 => ./the-obstacle-is-the-way.gmi 'The Obstacle is the Way' book notes
 => ./staff-engineer.gmi 'Staff Engineer' book notes
 => ./slow-productivity.gmi 'Slow Productivity' book notes
+=> ./site-reliability-engineering.gmi 'Site Reliability Engineering' book notes
 => ./search-inside-yourself.gmi 'Search Inside Yourself' book notes
 => ./never-split-the-difference.gmi 'Never split the difference' book notes
 => ./mind-management.gmi 'Mind Management' book notes
@@ -17,10 +18,12 @@
 => ./love-people-use-things.gmi 'Love People, Use Things' book notes
 => ./joy-on-demand.gmi 'Joy On Domand' book notes
 => ./influence-wihout-authority.gmi 'Influence without Authority' book notes
+=> ./implementing-service-level-objectives.gmi 'Implementing Service Level Objectives' book notes
 => ./fluent-forever.gmi 'Fluent Forever' book notes
 => ./eat-that-frog.gmi 'Eat That Frog' book notes
 => ./career-guide-and-soft-skills.gmi 'Software Developmers Career Guide and Soft Skills' book notes
 => ./a-monks-guide-to-happiness.gmi 'A Monk's Guide to Happiness' book notes
+=> ./97-things-every-sre-should-know.gmi '97 Things Every SRE Should Know' book notes
 
 That were all notes. Hope they were useful!
 
diff --git a/notes/site-reliability-engineering.gmi b/notes/site-reliability-engineering.gmi
new file mode 100644
index 00000000..67f57a7b
--- /dev/null
+++ b/notes/site-reliability-engineering.gmi
@@ -0,0 +1,90 @@
+# "Site Reliability Engineering" book notes
+
+These are my personal book notes of Niall Richard Murphy's "Site Reliability Engineering: How Google Runs Production systems". They are for myself, but I hope they might be useful to you too.
+
+## Table of Contents
+
+* ⇢ "Site Reliability Engineering" book notes
+* ⇢ ⇢ Key Concepts in SRE
+* ⇢ ⇢ ⇢ Role of an SRE:
+* ⇢ ⇢ ⇢ Error Budget
+* ⇢ ⇢ ⇢ On-call Management
+* ⇢ ⇢ ⇢ Reliability Metrics
+* ⇢ ⇢ ⇢ Service Indicators
+* ⇢ ⇢ ⇢ Metrics and Error Rates
+* ⇢ ⇢ ⇢ Testing and Monitoring
+* ⇢ ⇢ ⇢ Automation and Human Involvement
+* ⇢ ⇢ ⇢ SRE Work Distribution
+* ⇢ ⇢ ⇢ Post-mortem Practices
+* ⇢ ⇢ ⇢ Load Testing
+* ⇢ ⇢ ⇢ Criticality and Throttling
+* ⇢ ⇢ ⇢ Toil Management
+* ⇢ ⇢ ⇢ Efficient Operations
+
+## Key Concepts in SRE
+
+### Role of an SRE:
+
+Ideally, SREs should spend no more than 50% of their time on operational work. The focus should primarily be on development activities. Systems should self-heal automatically.
+
+### Error Budget
+
+No development work should occur when the error budget is exceeded for a whole quarter, requiring strong management support. Error budgets help resolve conflicts between development and operational work by creating a common incentive, allowing both product development and SRE teams to balance innovation with reliability. Removes need for negotiations on the number of feature changes allowed.
+
+### On-call Management
+
+An on-call engineer should encounter a maximum of two events per eight hours to ensure sufficient time for cleanup and post-mortems. This allows thorough investigation and learning without overwhelming engineers. Monitoring should alert only when human interaction is required. Logs should be used for later forensics and not require immediate attention. Uptime is calculated with successful requests included, potentially by source, considering volume, partial writes, and HTTP response codes.
+
+### Reliability Metrics
+
+* Reliability is a function of Mean Time to Failure (MTTF) and Mean Time to Repair (MTTR).
+* Playbooks can improve MTTR.
+* Self-healing is optimal for operational efficiency.
+* Capacity is a function of comprehensive capacity planning, critically viewed by SREs for performance improvements.
+
+### Service Indicators
+
+Choose an appropriate number of SLIs/KPIs to maintain focus without missing vital aspects of system performance. KPIs and SLIs are crucial for real-time metrics like uptime, latency, and throughput, often aggregated for analysis. Risk tolerance should be set in collaboration with product teams for user-facing services.
+
+### Metrics and Error Rates
+
+Accurate measurement involves considering all system components, including infrastructure error rates from networking, hardware, etc. High availability solutions (HA) and ISP background error rates can influence the impact of network outages on the error budget.
+
+### Testing and Monitoring
+
+Regular DR/Chaos testing is essential to gauge the impact of outages (like DC outages) on availability. Comprehensive testing ensures systems can handle variable loads without catastrophic failure. Monitoring and alert systems should swiftly address concerns, measuring latency on errors to distinguish 'slow' from 'fast' failures.
+
+### Automation and Human Involvement
+
+While automation can replace manual error resolution, maintaining human expertise is vital to operate systems when automation fails or becomes opaque over time.
+
+### SRE Work Distribution
+
+Google SREs, for example, allocate their work as 25% on-call, 25% non-urgent operations, and 50% engineering tasks.
+
+### Post-mortem Practices
+
+Creating post-mortems is a learning opportunity, not a punishment. They must be deliberate and not merely procedural. Post-mortems should be comprehensive to ensure lessons are applied effectively.
+
+### Load Testing
+
+ Proper load testing identifies when a system begins rejecting traffic and observes how it handles excess load. Systems should be tested at the subsystem level to identify different thresholds.
+
+### Criticality and Throttling
+
+Client-side rate limiting can implement adaptive throttling based on error counts. Systems should be designed to prioritize requests of higher criticality.
+
+### Toil Management
+
+Toil should account for less than 50% of an SRE's work currently and must be minimized. Toil is repetitive, manual work that could be automated. A balance must be struck, as occasional toil can prove insightful, but excessive toil detrimentally affects morale and productivity. Different engineers have varied thresholds for tolerating toil, influencing job satisfaction and retention.
+
+### Efficient Operations
+
+Toil, overhead, and non-operational tasks should be distinguished from core operational activities, which do not relate to direct HR or interview processes. Monitoring alerts should inform the necessary actions with clear context ("the what and the why") to minimize unnecessary manual efforts.
+
+Other book notes of mine are:
+
+
+E-Mail your comments to `paul@nospam.buetow.org` :-)
+
+=> ../ Back to the main site
diff --git a/notes/site-reliability-engineering.gmi.tpl b/notes/site-reliability-engineering.gmi.tpl
new file mode 100644
index 00000000..d4036d44
--- /dev/null
+++ b/notes/site-reliability-engineering.gmi.tpl
@@ -0,0 +1,74 @@
+# "Site Reliability Engineering" book notes
+
+These are my personal book notes of Niall Richard Murphy's "Site Reliability Engineering: How Google Runs Production systems". They are for myself, but I hope they might be useful to you too.
+
+<< template::inline::toc
+
+## Key Concepts in SRE
+
+### Role of an SRE:
+
+Ideally, SREs should spend no more than 50% of their time on operational work. The focus should primarily be on development activities. Systems should self-heal automatically.
+
+### Error Budget
+
+No development work should occur when the error budget is exceeded for a whole quarter, requiring strong management support. Error budgets help resolve conflicts between development and operational work by creating a common incentive, allowing both product development and SRE teams to balance innovation with reliability. Removes need for negotiations on the number of feature changes allowed.
+
+### On-call Management
+
+An on-call engineer should encounter a maximum of two events per eight hours to ensure sufficient time for cleanup and post-mortems. This allows thorough investigation and learning without overwhelming engineers. Monitoring should alert only when human interaction is required. Logs should be used for later forensics and not require immediate attention. Uptime is calculated with successful requests included, potentially by source, considering volume, partial writes, and HTTP response codes.
+
+### Reliability Metrics
+
+* Reliability is a function of Mean Time to Failure (MTTF) and Mean Time to Repair (MTTR).
+* Playbooks can improve MTTR.
+* Self-healing is optimal for operational efficiency.
+* Capacity is a function of comprehensive capacity planning, critically viewed by SREs for performance improvements.
+
+### Service Indicators
+
+Choose an appropriate number of SLIs/KPIs to maintain focus without missing vital aspects of system performance. KPIs and SLIs are crucial for real-time metrics like uptime, latency, and throughput, often aggregated for analysis. Risk tolerance should be set in collaboration with product teams for user-facing services.
+
+### Metrics and Error Rates
+
+Accurate measurement involves considering all system components, including infrastructure error rates from networking, hardware, etc. High availability solutions (HA) and ISP background error rates can influence the impact of network outages on the error budget.
+
+### Testing and Monitoring
+
+Regular DR/Chaos testing is essential to gauge the impact of outages (like DC outages) on availability. Comprehensive testing ensures systems can handle variable loads without catastrophic failure. Monitoring and alert systems should swiftly address concerns, measuring latency on errors to distinguish 'slow' from 'fast' failures.
+
+### Automation and Human Involvement
+
+While automation can replace manual error resolution, maintaining human expertise is vital to operate systems when automation fails or becomes opaque over time.
+
+### SRE Work Distribution
+
+Google SREs, for example, allocate their work as 25% on-call, 25% non-urgent operations, and 50% engineering tasks.
+
+### Post-mortem Practices
+
+Creating post-mortems is a learning opportunity, not a punishment. They must be deliberate and not merely procedural. Post-mortems should be comprehensive to ensure lessons are applied effectively.
+
+### Load Testing
+
+ Proper load testing identifies when a system begins rejecting traffic and observes how it handles excess load. Systems should be tested at the subsystem level to identify different thresholds.
+
+### Criticality and Throttling
+
+Client-side rate limiting can implement adaptive throttling based on error counts. Systems should be designed to prioritize requests of higher criticality.
+
+### Toil Management
+
+Toil should account for less than 50% of an SRE's work currently and must be minimized. Toil is repetitive, manual work that could be automated. A balance must be struck, as occasional toil can prove insightful, but excessive toil detrimentally affects morale and productivity. Different engineers have varied thresholds for tolerating toil, influencing job satisfaction and retention.
+
+### Efficient Operations
+
+Toil, overhead, and non-operational tasks should be distinguished from core operational activities, which do not relate to direct HR or interview processes. Monitoring alerts should inform the necessary actions with clear context ("the what and the why") to minimize unnecessary manual efforts.
+
+Other book notes of mine are:
+
+<< template::inline::rindex book-notes
+
+E-Mail your comments to `paul@nospam.buetow.org` :-)
+
+=> ../ Back to the main site
diff --git a/uptime-stats.gmi b/uptime-stats.gmi
index 33dd2ac8..80f1de07 100644
--- a/uptime-stats.gmi
+++ b/uptime-stats.gmi
@@ -1,6 +1,6 @@
 # My machine uptime stats
 
-> This site was last updated at 2025-02-21T11:13:36+02:00
+> This site was last updated at 2025-02-21T17:05:20+02:00
 
 The following stats were collected via `uptimed` on all of my personal computers over many years and the output was generated by `guprecords`, the global uptime records stats analyser of mine.
 
-- 
cgit v1.2.3