Update content for gemtext

5 files changed, 16 insertions, 16 deletions

diff --git a/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi b/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi
index ddfcb3b6..207d27b4 100644
--- a/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi
+++ b/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi
@@ -3,7 +3,7 @@
 > Published at 2024-03-30T22:12:56+02:00
 
 ```
-Art by Michael J. Penick (mod. by Paul B)
+Art by Michael J. Penick (mod. by Paul B.)
 
         __________
        / nsd tower\                                             (
@@ -29,16 +29,16 @@ _____|_:_:_|  (o)-(o)  |_:_:_|--'`-.     ,--. ksh under-water (((\'/
 
 I have always wanted a highly available setup for my personal websites. I could have used off-the-shelf hosting solutions or hosted my sites in an AWS S3 bucket. I have used technologies like BGP, LVS/IPVS, ldirectord, Pacemaker, heartbeat, heartbeat2, Corosync, keepalived, DRBD, and commercial F5 Load Balancers for high availability at work. 
 
-But still, my personal sites were never highly available. All those technologies are great for professional use, but I was looking for something much more straightforward for my personal space—something as KISS (keep it simple and stupid) as possible.
+But still, my personal sites were never highly available. All those technologies are great for professional use, but I was looking for something much more straightforward for my personal space - something as KISS (keep it simple and stupid) as possible.
 
 It would be fine if my personal website wasn't highly available, but the geek in me wants it anyway.
 
-> PS: ASCII-art reflects the OpenBSD under-water world with all the tools available in the base system.
+> PS: ASCII-art reflects an OpenBSD under-water world with all the tools available in the base system.
 
 ## My auto-failover requirements
 
 * Be OpenBSD-based (I prefer OpenBSD because of the cleanliness and good documentation) and rely on as few external packages as possible. 
-* Don't rely on the hottest and newest tech (don't want to migrate everything to a new and fancier technology next month).
+* Don't rely on the hottest and newest tech (don't want to migrate everything to a new and fancier technology next month already).
 * It should be reasonably cheap. I want to avoid paying a premium for floating IPs or fancy Elastic Load Balancers.
 * It should be geo-redundant. 
 * It's fine if my sites aren't reachable for five or ten minutes every other month. Due to their static nature, I don't care if there's a split-brain scenario where some requests reach one server and other requests reach another server.
diff --git a/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi.tpl b/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi.tpl
index 5ef32b35..e94b727e 100644
--- a/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi.tpl
+++ b/gemfeed/2024-04-01-KISS-high-availability-with-OpenBSD.gmi.tpl
@@ -3,7 +3,7 @@
 > Published at 2024-03-30T22:12:56+02:00
 
 ```
-Art by Michael J. Penick (mod. by Paul B)
+Art by Michael J. Penick (mod. by Paul B.)
 
         __________
        / nsd tower\                                             (
@@ -29,16 +29,16 @@ _____|_:_:_|  (o)-(o)  |_:_:_|--'`-.     ,--. ksh under-water (((\'/
 
 I have always wanted a highly available setup for my personal websites. I could have used off-the-shelf hosting solutions or hosted my sites in an AWS S3 bucket. I have used technologies like BGP, LVS/IPVS, ldirectord, Pacemaker, heartbeat, heartbeat2, Corosync, keepalived, DRBD, and commercial F5 Load Balancers for high availability at work. 
 
-But still, my personal sites were never highly available. All those technologies are great for professional use, but I was looking for something much more straightforward for my personal space—something as KISS (keep it simple and stupid) as possible.
+But still, my personal sites were never highly available. All those technologies are great for professional use, but I was looking for something much more straightforward for my personal space - something as KISS (keep it simple and stupid) as possible.
 
 It would be fine if my personal website wasn't highly available, but the geek in me wants it anyway.
 
-> PS: ASCII-art reflects the OpenBSD under-water world with all the tools available in the base system.
+> PS: ASCII-art reflects an OpenBSD under-water world with all the tools available in the base system.
 
 ## My auto-failover requirements
 
 * Be OpenBSD-based (I prefer OpenBSD because of the cleanliness and good documentation) and rely on as few external packages as possible. 
-* Don't rely on the hottest and newest tech (don't want to migrate everything to a new and fancier technology next month).
+* Don't rely on the hottest and newest tech (don't want to migrate everything to a new and fancier technology next month already).
 * It should be reasonably cheap. I want to avoid paying a premium for floating IPs or fancy Elastic Load Balancers.
 * It should be geo-redundant. 
 * It's fine if my sites aren't reachable for five or ten minutes every other month. Due to their static nature, I don't care if there's a split-brain scenario where some requests reach one server and other requests reach another server.
diff --git a/gemfeed/atom.xml b/gemfeed/atom.xml
index 0bfcbebe..a8ae9366 100644
--- a/gemfeed/atom.xml
+++ b/gemfeed/atom.xml
@@ -1,6 +1,6 @@
 <?xml version="1.0" encoding="utf-8"?>
 <feed xmlns="http://www.w3.org/2005/Atom">
-    <updated>2024-03-30T22:13:12+02:00</updated>
+    <updated>2024-03-30T22:16:56+02:00</updated>
     <title>foo.zone feed</title>
     <subtitle>To be in the .zone!</subtitle>
     <link href="gemini://foo.zone/gemfeed/atom.xml" rel="self" />
@@ -15,7 +15,7 @@
             <name>Paul Buetow aka snonux</name>
             <email>paul@dev.buetow.org</email>
         </author>
-        <summary>Art by Michael J. Penick (mod. by Paul B)</summary>
+        <summary>Art by Michael J. Penick (mod. by Paul B.)</summary>
         <content type="xhtml">
             <div xmlns="http://www.w3.org/1999/xhtml">
                 <h1 style='display: inline'>KISS high-availability with OpenBSD</h1><br />
@@ -23,7 +23,7 @@
 <span class='quote'>Published at 2024-03-30T22:12:56+02:00</span><br />
 <br />
 <pre>
-Art by Michael J. Penick (mod. by Paul B)
+Art by Michael J. Penick (mod. by Paul B.)
 
         __________
        / nsd tower\                                             (
@@ -49,17 +49,17 @@ _____|_:_:_|  (o)-(o)  |_:_:_|--&#39;`-.     ,--. ksh under-water (((\&#39;/
 <br />
 <span>I have always wanted a highly available setup for my personal websites. I could have used off-the-shelf hosting solutions or hosted my sites in an AWS S3 bucket. I have used technologies like BGP, LVS/IPVS, ldirectord, Pacemaker, heartbeat, heartbeat2, Corosync, keepalived, DRBD, and commercial F5 Load Balancers for high availability at work. </span><br />
 <br />
-<span>But still, my personal sites were never highly available. All those technologies are great for professional use, but I was looking for something much more straightforward for my personal space—something as KISS (keep it simple and stupid) as possible.</span><br />
+<span>But still, my personal sites were never highly available. All those technologies are great for professional use, but I was looking for something much more straightforward for my personal space - something as KISS (keep it simple and stupid) as possible.</span><br />
 <br />
 <span>It would be fine if my personal website wasn&#39;t highly available, but the geek in me wants it anyway.</span><br />
 <br />
-<span class='quote'>PS: ASCII-art reflects the OpenBSD under-water world with all the tools available in the base system.</span><br />
+<span class='quote'>PS: ASCII-art reflects an OpenBSD under-water world with all the tools available in the base system.</span><br />
 <br />
 <h2 style='display: inline'>My auto-failover requirements</h2><br />
 <br />
 <ul>
 <li>Be OpenBSD-based (I prefer OpenBSD because of the cleanliness and good documentation) and rely on as few external packages as possible. </li>
-<li>Don&#39;t rely on the hottest and newest tech (don&#39;t want to migrate everything to a new and fancier technology next month).</li>
+<li>Don&#39;t rely on the hottest and newest tech (don&#39;t want to migrate everything to a new and fancier technology next month already).</li>
 <li>It should be reasonably cheap. I want to avoid paying a premium for floating IPs or fancy Elastic Load Balancers.</li>
 <li>It should be geo-redundant. </li>
 <li>It&#39;s fine if my sites aren&#39;t reachable for five or ten minutes every other month. Due to their static nature, I don&#39;t care if there&#39;s a split-brain scenario where some requests reach one server and other requests reach another server.</li>
diff --git a/index.gmi b/index.gmi
index 053bc44b..383e987e 100644
--- a/index.gmi
+++ b/index.gmi
@@ -1,6 +1,6 @@
 # foo.zone
 
-> This site was generated at 2024-03-30T22:14:16+02:00 by `Gemtexter`
+> This site was generated at 2024-03-30T22:16:56+02:00 by `Gemtexter`
 
 ```
    |\---/|
diff --git a/uptime-stats.gmi b/uptime-stats.gmi
index 408c0d8b..0c0f6411 100644
--- a/uptime-stats.gmi
+++ b/uptime-stats.gmi
@@ -1,6 +1,6 @@
 # My machine uptime stats
 
-> This site was last updated at 2024-03-30T22:14:16+02:00
+> This site was last updated at 2024-03-30T22:16:56+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.