From f07f4e2ce0dc69a566409cbceb1eb3cb9e4f004b Mon Sep 17 00:00:00 2001 From: Paul Buetow Date: Sun, 12 Oct 2025 11:11:13 +0300 Subject: Update content for html --- CLAUDE.md | 60 ------- about/index.html | 3 +- about/resources.html | 200 ++++++++++----------- gemfeed/2021-07-04-the-well-grounded-rubyist.html | 2 +- ...5-07-14-f3s-kubernetes-with-freebsd-part-6.html | 161 +++++++++++++++++ ...y-takeaways-from-the-well-grounded-rubyist.html | 2 +- gemfeed/atom.xml | 165 ++++++++++++++++- index.html | 2 +- uptime-stats.html | 32 ++-- 9 files changed, 445 insertions(+), 182 deletions(-) delete mode 100644 CLAUDE.md diff --git a/CLAUDE.md b/CLAUDE.md deleted file mode 100644 index 5a79f3e0..00000000 --- a/CLAUDE.md +++ /dev/null @@ -1,60 +0,0 @@ -# CLAUDE.md - -This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository. - -## Project Overview - -This is a static site generator project that uses **Gemtext** as the source format and generates multiple output formats. The project uses "Gemtexter" (a Bash-based static site generator) to convert Gemtext files into HTML, Markdown, and various feed formats. - -**Key Architecture:** -- **Source files**: Gemtext (`.gmi`) and template files (`.gmi.tpl`) in the `/gemtext` directory -- **Generated outputs**: HTML in `../html/`, Markdown in `../md/`, with caching in `../cache/` -- **Content structure**: Blog posts in `gemfeed/`, personal notes in `notes/`, about pages in `about/` -- **Template system**: `.gmi.tpl` files are processed to generate final `.gmi` files with dynamic content - -## Build Commands - -Since this project uses Gemtexter (a Bash-based static site generator), the build process involves: - -**Main generation command:** -```bash -# From the parent directory (/home/paul/git/foo.zone-content/) -# Look for gemtexter script or build scripts in the parent directory -``` - -**File structure patterns:** -- `.gmi.tpl` → `.gmi` (template processing) -- `.gmi` → `.html` + `.md` + feeds (multi-format generation) - -## Content Architecture - -**Template System:** -- Files with `.gmi.tpl` extension are templates that get processed -- Templates can include dynamic content like timestamps and automatic content generation -- Example: `index.gmi.tpl` generates `index.gmi` with current timestamp - -**Output Formats:** -- **Gemtext**: Native format for Gemini protocol (`.gmi` files) -- **HTML**: Web-ready format with embedded CSS and fonts -- **Markdown**: For GitHub Pages deployment -- **Atom feeds**: For blog subscription (XML format) -- **Gemfeeds**: Gemini-specific feed format - -**Content Organization:** -- `gemfeed/`: Blog posts with date-prefixed naming (YYYY-MM-DD-title.gmi) -- `notes/`: Book notes and technical references -- `about/`: Personal information and resource lists - -## Development Workflow - -1. **Content Creation**: Write new content in Gemtext format (`.gmi` files) -2. **Template Updates**: Modify `.gmi.tpl` files for dynamic content -3. **Generation**: Run Gemtexter to generate all output formats -4. **Multi-format Output**: Content automatically appears in HTML, Markdown, and feed formats - -## Important Notes - -- The current working directory is `/gemtext` but build tools are likely in the parent directory -- Generated files should not be edited directly - edit source `.gmi` or `.gmi.tpl` files instead -- The project generates a complete multi-format website from simple Gemtext sources -- Cache files in `../cache/` help with performance during regeneration \ No newline at end of file diff --git a/about/index.html b/about/index.html index 4b2bd7a6..2a21835b 100644 --- a/about/index.html +++ b/about/index.html @@ -55,7 +55,8 @@

Books on my wishlist



diff --git a/about/resources.html b/about/resources.html index 2818672a..b49e1156 100644 --- a/about/resources.html +++ b/about/resources.html @@ -50,52 +50,52 @@ In random order:


Technical references


@@ -103,56 +103,56 @@ 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:


Self-development and soft-skills books



In random order:


Here are notes of mine for some of the books

@@ -161,22 +161,22 @@ Some of these were in-person with exams; others were online learning lectures only. In random order:


Technical guides



@@ -194,61 +194,61 @@ In random order:


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.


Newsletters I like



This is a mix of tech and non-tech newsletters I am subscribed to. In random order:


Magazines I like(d)



This is a mix of tech I like(d). I may not be a current subscriber, but now and then, I buy an issue. In random order:


Formal education



diff --git a/gemfeed/2021-07-04-the-well-grounded-rubyist.html b/gemfeed/2021-07-04-the-well-grounded-rubyist.html index 75d538d5..14332626 100644 --- a/gemfeed/2021-07-04-the-well-grounded-rubyist.html +++ b/gemfeed/2021-07-04-the-well-grounded-rubyist.html @@ -135,7 +135,7 @@ Hello World
Other Ruby-related posts:

-2025-10-11 Key Takeaways from The Well-Grounded Rubyist
+2025-10-11 Key kakeaways from The Well-Grounded Rubyist
2021-07-04 The Well-Grounded Rubyist (You are currently reading this)

Back to the main site
diff --git a/gemfeed/2025-07-14-f3s-kubernetes-with-freebsd-part-6.html b/gemfeed/2025-07-14-f3s-kubernetes-with-freebsd-part-6.html index 9af59a5d..df04504e 100644 --- a/gemfeed/2025-07-14-f3s-kubernetes-with-freebsd-part-6.html +++ b/gemfeed/2025-07-14-f3s-kubernetes-with-freebsd-part-6.html @@ -49,6 +49,13 @@
  • ⇢ ⇢ Mounting the NFS datasets
  • ⇢ ⇢ Troubleshooting: Files not appearing in replication
  • ⇢ ⇢ Configuring automatic key loading on boot
    • +
  • ⇢ ⇢ Troubleshooting: zrepl Replication Not Working
    • +
  • ⇢ ⇢# Check if zrepl Services are Running
    • +
  • ⇢ ⇢# Check zrepl Status for Errors
    • +
  • ⇢ ⇢# Fixing "No Common Snapshot" Errors
    • +
  • ⇢ ⇢# Network Connectivity Issues
    • +
  • ⇢ ⇢# Encryption Key Issues
    • +
  • ⇢ ⇢# Monitoring Ongoing Replication
  • ⇢ CARP (Common Address Redundancy Protocol)
  • ⇢ ⇢ How CARP Works
  • ⇢ ⇢ Configuring CARP
    • @@ -787,6 +794,160 @@ paul@f1:~ % doas zfs set \
  • Always verify datasets are mounted after reboot with zfs list -o name,mounted
  • Critical: Always ensure the replicated dataset on f1 remains read-only with doas zfs set readonly=on zdata/sink/f0/zdata/enc/nfsdata

    • +

    Troubleshooting: zrepl Replication Not Working


    +
    +If zrepl replication is not working, here's a systematic approach to diagnose and fix common issues:
    +
    +#### Check if zrepl Services are Running
    +
    +First, verify that zrepl is running on both nodes:
    +
    + +
    # Check service status on both f0 and f1
+paul@f0:~ % doas service zrepl status
+paul@f1:~ % doas service zrepl status
+
+# If not running, start the service
+paul@f0:~ % doas service zrepl start
+paul@f1:~ % doas service zrepl start
+
    +
    +#### Check zrepl Status for Errors
    +
    +Use the status command to see detailed error information:
    +
    + +
    # Check detailed status (use --mode raw for non-tty environments)
+paul@f0:~ % doas zrepl status --mode raw
+
+# Look for error messages in the replication section
+# Common errors include "no common snapshot" or connection failures
+
    +
    +#### Fixing "No Common Snapshot" Errors
    +
    +This is the most common replication issue, typically occurring when:
    +
    +
    +**Error message example:**
    +
    +no common snapshot or suitable bookmark between sender and receiver
+
    +
    +**Solution: Clean up conflicting snapshots on receiver**
    +
    + +
    # First, identify the destination dataset on f1
+paul@f1:~ % doas zfs list | grep sink
+
+# Check existing snapshots on the problematic dataset
+paul@f1:~ % doas zfs list -t snapshot | grep nfsdata
+
+# If you see snapshots with different naming (e.g., @daily-*, @weekly-*)
+# these conflict with zrepl's @zrepl_* snapshots
+
+# Destroy the entire destination dataset to allow clean replication
+paul@f1:~ % doas zfs destroy -r zdata/sink/f0/zdata/enc/nfsdata
+
+# For VM replication, do the same for the fedora dataset
+paul@f1:~ % doas zfs destroy -r zdata/sink/f0/zroot/bhyve/fedora
+
+# Wake up zrepl to start fresh replication
+paul@f0:~ % doas zrepl signal wakeup f0_to_f1_nfsdata
+paul@f0:~ % doas zrepl signal wakeup f0_to_f1_fedora
+
+# Check replication status
+paul@f0:~ % doas zrepl status --mode raw
+
    +
    +**Verification that replication is working:**
    +
    + +
    # Look for "stepping" state and active zfs send processes
+paul@f0:~ % doas zrepl status --mode raw | grep -A5 "State.*stepping"
+
+# Check for active ZFS commands
+paul@f0:~ % doas zrepl status --mode raw | grep -A10 "ZFSCmds.*Active"
+
+# Monitor progress - bytes replicated should be increasing
+paul@f0:~ % doas zrepl status --mode raw | grep BytesReplicated
+
    +
    +#### Network Connectivity Issues
    +
    +If replication fails to connect:
    +
    + +
    # Test connectivity between nodes
+paul@f0:~ % nc -zv 192.168.2.131 8888
+
+# Check if zrepl is listening on f1
+paul@f1:~ % doas netstat -an | grep 8888
+
+# Verify WireGuard tunnel is working
+paul@f0:~ % ping 192.168.2.131
+
    +
    +#### Encryption Key Issues
    +
    +If encrypted replication fails:
    +
    + +
    # Verify encryption keys are available on both nodes
+paul@f0:~ % doas zfs get keystatus zdata/enc/nfsdata
+paul@f1:~ % doas zfs get keystatus zdata/sink/f0/zdata/enc/nfsdata
+
+# Load keys if unavailable
+paul@f1:~ % doas zfs load-key -L file:///keys/f0.lan.buetow.org:zdata.key \
+    zdata/sink/f0/zdata/enc/nfsdata
+
    +
    +#### Monitoring Ongoing Replication
    +
    +After fixing issues, monitor replication health:
    +
    + +
    # Monitor replication progress (run repeatedly to check status)
+paul@f0:~ % doas zrepl status --mode raw | grep -A10 BytesReplicated
+
+# Or install watch from ports and use it
+paul@f0:~ % doas pkg install watch
+paul@f0:~ % watch -n 5 'doas zrepl status --mode raw | grep -A10 BytesReplicated'
+
+# Check for new snapshots being created
+paul@f0:~ % doas zfs list -t snapshot | grep zrepl | tail -5
+
+# Verify snapshots appear on receiver
+paul@f1:~ % doas zfs list -t snapshot -r zdata/sink | grep zrepl | tail -5
+
    +
    +This troubleshooting process resolves the most common zrepl issues and ensures continuous data replication between your storage nodes.
    +

    CARP (Common Address Redundancy Protocol)



    High availability is crucial for storage systems. If the storage server goes down, all NFS clients (which will also be Kubernetes pods later on in this series) lose access to their persistent data. CARP provides a solution by creating a virtual IP address that automatically migrates to a different server during failures. This means that clients point to that VIP for NFS mounts and are always contacting the current primary node.
    diff --git a/gemfeed/2025-10-11-key-takeaways-from-the-well-grounded-rubyist.html b/gemfeed/2025-10-11-key-takeaways-from-the-well-grounded-rubyist.html index 75950fb3..1b893408 100644 --- a/gemfeed/2025-10-11-key-takeaways-from-the-well-grounded-rubyist.html +++ b/gemfeed/2025-10-11-key-takeaways-from-the-well-grounded-rubyist.html @@ -258,7 +258,7 @@ p hash.values_at(:a, :c)
    Other Ruby-related posts:

    -2025-10-11 Key Takeaways from The Well-Grounded Rubyist (You are currently reading this)
    +2025-10-11 Key kakeaways from The Well-Grounded Rubyist (You are currently reading this)
    2021-07-04 The Well-Grounded Rubyist

    Back to the main site
    diff --git a/gemfeed/atom.xml b/gemfeed/atom.xml index eadcfbbb..e119c57b 100644 --- a/gemfeed/atom.xml +++ b/gemfeed/atom.xml @@ -1,6 +1,6 @@ - 2025-10-11T15:44:10+03:00 + 2025-10-12T11:09:49+03:00 foo.zone feed To be in the .zone! @@ -265,7 +265,7 @@ p hash.values_at(:a, :c)
    Other Ruby-related posts:

    -2025-10-11 Key Takeaways from The Well-Grounded Rubyist (You are currently reading this)
    +2025-10-11 Key kakeaways from The Well-Grounded Rubyist (You are currently reading this)
    2021-07-04 The Well-Grounded Rubyist

    Back to the main site
    @@ -2664,6 +2664,13 @@ content = "{CODE}"
  • ⇢ ⇢ Mounting the NFS datasets
  • ⇢ ⇢ Troubleshooting: Files not appearing in replication
  • ⇢ ⇢ Configuring automatic key loading on boot
    • +
  • ⇢ ⇢ Troubleshooting: zrepl Replication Not Working
    • +
  • ⇢ ⇢# Check if zrepl Services are Running
    • +
  • ⇢ ⇢# Check zrepl Status for Errors
    • +
  • ⇢ ⇢# Fixing "No Common Snapshot" Errors
    • +
  • ⇢ ⇢# Network Connectivity Issues
    • +
  • ⇢ ⇢# Encryption Key Issues
    • +
  • ⇢ ⇢# Monitoring Ongoing Replication
  • ⇢ CARP (Common Address Redundancy Protocol)
  • ⇢ ⇢ How CARP Works
  • ⇢ ⇢ Configuring CARP
    • @@ -3402,6 +3409,160 @@ paul@f1:~ % doas zfs set \
  • Always verify datasets are mounted after reboot with zfs list -o name,mounted
  • Critical: Always ensure the replicated dataset on f1 remains read-only with doas zfs set readonly=on zdata/sink/f0/zdata/enc/nfsdata

    • +

    Troubleshooting: zrepl Replication Not Working


    +
    +If zrepl replication is not working, here's a systematic approach to diagnose and fix common issues:
    +
    +#### Check if zrepl Services are Running
    +
    +First, verify that zrepl is running on both nodes:
    +
    + +
    # Check service status on both f0 and f1
+paul@f0:~ % doas service zrepl status
+paul@f1:~ % doas service zrepl status
+
+# If not running, start the service
+paul@f0:~ % doas service zrepl start
+paul@f1:~ % doas service zrepl start
+
    +
    +#### Check zrepl Status for Errors
    +
    +Use the status command to see detailed error information:
    +
    + +
    # Check detailed status (use --mode raw for non-tty environments)
+paul@f0:~ % doas zrepl status --mode raw
+
+# Look for error messages in the replication section
+# Common errors include "no common snapshot" or connection failures
+
    +
    +#### Fixing "No Common Snapshot" Errors
    +
    +This is the most common replication issue, typically occurring when:
    +
    +
    +**Error message example:**
    +
    +no common snapshot or suitable bookmark between sender and receiver
+
    +
    +**Solution: Clean up conflicting snapshots on receiver**
    +
    + +
    # First, identify the destination dataset on f1
+paul@f1:~ % doas zfs list | grep sink
+
+# Check existing snapshots on the problematic dataset
+paul@f1:~ % doas zfs list -t snapshot | grep nfsdata
+
+# If you see snapshots with different naming (e.g., @daily-*, @weekly-*)
+# these conflict with zrepl's @zrepl_* snapshots
+
+# Destroy the entire destination dataset to allow clean replication
+paul@f1:~ % doas zfs destroy -r zdata/sink/f0/zdata/enc/nfsdata
+
+# For VM replication, do the same for the fedora dataset
+paul@f1:~ % doas zfs destroy -r zdata/sink/f0/zroot/bhyve/fedora
+
+# Wake up zrepl to start fresh replication
+paul@f0:~ % doas zrepl signal wakeup f0_to_f1_nfsdata
+paul@f0:~ % doas zrepl signal wakeup f0_to_f1_fedora
+
+# Check replication status
+paul@f0:~ % doas zrepl status --mode raw
+
    +
    +**Verification that replication is working:**
    +
    + +
    # Look for "stepping" state and active zfs send processes
+paul@f0:~ % doas zrepl status --mode raw | grep -A5 "State.*stepping"
+
+# Check for active ZFS commands
+paul@f0:~ % doas zrepl status --mode raw | grep -A10 "ZFSCmds.*Active"
+
+# Monitor progress - bytes replicated should be increasing
+paul@f0:~ % doas zrepl status --mode raw | grep BytesReplicated
+
    +
    +#### Network Connectivity Issues
    +
    +If replication fails to connect:
    +
    + +
    # Test connectivity between nodes
+paul@f0:~ % nc -zv 192.168.2.131 8888
+
+# Check if zrepl is listening on f1
+paul@f1:~ % doas netstat -an | grep 8888
+
+# Verify WireGuard tunnel is working
+paul@f0:~ % ping 192.168.2.131
+
    +
    +#### Encryption Key Issues
    +
    +If encrypted replication fails:
    +
    + +
    # Verify encryption keys are available on both nodes
+paul@f0:~ % doas zfs get keystatus zdata/enc/nfsdata
+paul@f1:~ % doas zfs get keystatus zdata/sink/f0/zdata/enc/nfsdata
+
+# Load keys if unavailable
+paul@f1:~ % doas zfs load-key -L file:///keys/f0.lan.buetow.org:zdata.key \
+    zdata/sink/f0/zdata/enc/nfsdata
+
    +
    +#### Monitoring Ongoing Replication
    +
    +After fixing issues, monitor replication health:
    +
    + +
    # Monitor replication progress (run repeatedly to check status)
+paul@f0:~ % doas zrepl status --mode raw | grep -A10 BytesReplicated
+
+# Or install watch from ports and use it
+paul@f0:~ % doas pkg install watch
+paul@f0:~ % watch -n 5 'doas zrepl status --mode raw | grep -A10 BytesReplicated'
+
+# Check for new snapshots being created
+paul@f0:~ % doas zfs list -t snapshot | grep zrepl | tail -5
+
+# Verify snapshots appear on receiver
+paul@f1:~ % doas zfs list -t snapshot -r zdata/sink | grep zrepl | tail -5
+
    +
    +This troubleshooting process resolves the most common zrepl issues and ensures continuous data replication between your storage nodes.
    +

    CARP (Common Address Redundancy Protocol)



    High availability is crucial for storage systems. If the storage server goes down, all NFS clients (which will also be Kubernetes pods later on in this series) lose access to their persistent data. CARP provides a solution by creating a virtual IP address that automatically migrates to a different server during failures. This means that clients point to that VIP for NFS mounts and are always contacting the current primary node.
    diff --git a/index.html b/index.html index 7cdb2637..144ac20c 100644 --- a/index.html +++ b/index.html @@ -13,7 +13,7 @@

    Hello!



    -This site was generated at 2025-10-11T15:44:10+03:00 by Gemtexter
    +This site was generated at 2025-10-12T11:09:49+03:00 by Gemtexter

    Welcome to the foo.zone!

    diff --git a/uptime-stats.html b/uptime-stats.html index ac248067..ddb3824f 100644 --- a/uptime-stats.html +++ b/uptime-stats.html @@ -13,7 +13,7 @@

    My machine uptime stats



    -This site was last updated at 2025-10-11T15:44:10+03:00
    +This site was last updated at 2025-10-12T11:09:49+03: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.

    @@ -36,7 +36,7 @@ +-----+----------------+-------+-------------------------------+ | 1. | alphacentauri | 671 | FreeBSD 11.4-RELEASE-p7 | | 2. | mars | 207 | Linux 3.2.0-4-amd64 | -| 3. | *earth | 206 | Linux 6.16.10-200.fc42.x86_64 | +| 3. | *earth | 207 | Linux 6.16.10-200.fc42.x86_64 | | 4. | callisto | 153 | Linux 4.0.4-303.fc22.x86_64 | | 5. | dionysus | 136 | FreeBSD 13.0-RELEASE-p11 | | 6. | tauceti-e | 120 | Linux 3.2.0-4-amd64 | @@ -46,8 +46,8 @@ | 10. | *f0 | 62 | FreeBSD 14.3-RELEASE | | 11. | uranus | 59 | NetBSD 10.1 | | 12. | pluto | 51 | Linux 3.2.0-4-amd64 | -| 13. | *mega-m3-pro | 50 | Darwin 24.6.0 | -| 14. | mega15289 | 50 | Darwin 23.4.0 | +| 13. | mega15289 | 50 | Darwin 23.4.0 | +| 14. | *mega-m3-pro | 50 | Darwin 24.6.0 | | 15. | *fishfinger | 46 | OpenBSD 7.7 | | 16. | *t450 | 44 | FreeBSD 14.2-RELEASE | | 17. | *blowfish | 43 | OpenBSD 7.7 | @@ -67,8 +67,8 @@ +-----+----------------+-----------------------------+-----------------------------------+ | 1. | vulcan | 4 years, 5 months, 6 days | Linux 3.10.0-1160.81.1.el7.x86_64 | | 2. | *blowfish | 3 years, 10 months, 2 days | OpenBSD 7.7 | -| 3. | sun | 3 years, 9 months, 26 days | FreeBSD 10.3-RELEASE-p24 | -| 4. | *earth | 3 years, 9 months, 26 days | Linux 6.16.10-200.fc42.x86_64 | +| 3. | *earth | 3 years, 9 months, 29 days | Linux 6.16.10-200.fc42.x86_64 | +| 4. | sun | 3 years, 9 months, 26 days | FreeBSD 10.3-RELEASE-p24 | | 5. | uranus | 3 years, 9 months, 5 days | NetBSD 10.1 | | 6. | uugrn | 3 years, 5 months, 5 days | FreeBSD 11.2-RELEASE-p4 | | 7. | *fishfinger | 3 years, 1 months, 28 days | OpenBSD 7.7 | @@ -163,7 +163,7 @@ | 3. | alphacentauri | 6 years, 9 months, 13 days | FreeBSD 11.4-RELEASE-p7 | | 4. | vulcan | 4 years, 5 months, 6 days | Linux 3.10.0-1160.81.1.el7.x86_64 | | 5. | makemake | 4 years, 4 months, 7 days | Linux 6.9.9-200.fc40.x86_64 | -| 6. | *earth | 4 years, 3 months, 15 days | Linux 6.16.10-200.fc42.x86_64 | +| 6. | *earth | 4 years, 3 months, 19 days | Linux 6.16.10-200.fc42.x86_64 | | 7. | *blowfish | 3 years, 10 months, 3 days | OpenBSD 7.7 | | 8. | sun | 3 years, 10 months, 2 days | FreeBSD 10.3-RELEASE-p24 | | 9. | uugrn | 3 years, 5 months, 5 days | FreeBSD 11.2-RELEASE-p4 | @@ -192,7 +192,7 @@ | 1. | FreeBSD 10... | 551 | | 2. | Linux 3... | 550 | | 3. | *FreeBSD 14... | 215 | -| 4. | *Linux 6... | 186 | +| 4. | *Linux 6... | 187 | | 5. | Linux 5... | 162 | | 6. | Linux 4... | 161 | | 7. | FreeBSD 11... | 153 | @@ -200,15 +200,15 @@ | 9. | *OpenBSD 7... | 99 | | 10. | Darwin 13... | 40 | | 11. | Darwin 23... | 30 | -| 12. | *Darwin 24... | 25 | -| 13. | FreeBSD 5... | 25 | +| 12. | FreeBSD 5... | 25 | +| 13. | *Darwin 24... | 25 | | 14. | Linux 2... | 22 | | 15. | Darwin 21... | 17 | | 16. | Darwin 15... | 15 | | 17. | Darwin 22... | 12 | | 18. | Darwin 18... | 11 | | 19. | OpenBSD 4... | 10 | -| 20. | FreeBSD 6... | 10 | +| 20. | FreeBSD 7... | 10 | +-----+----------------+-------+
    @@ -224,7 +224,7 @@ | 2. | *OpenBSD 7... | 7 years, 6 months, 29 days | | 3. | FreeBSD 10... | 5 years, 9 months, 9 days | | 4. | Linux 5... | 4 years, 10 months, 21 days | -| 5. | *Linux 6... | 2 years, 12 months, 23 days | +| 5. | *Linux 6... | 2 years, 12 months, 26 days | | 6. | Linux 4... | 2 years, 7 months, 22 days | | 7. | FreeBSD 11... | 2 years, 4 months, 28 days | | 8. | *FreeBSD 14... | 2 years, 3 months, 24 days | @@ -255,7 +255,7 @@ | 2. | *OpenBSD 7... | 484 | | 3. | FreeBSD 10... | 406 | | 4. | Linux 5... | 317 | -| 5. | *Linux 6... | 206 | +| 5. | *Linux 6... | 207 | | 6. | Linux 4... | 175 | | 7. | *FreeBSD 14... | 161 | | 8. | FreeBSD 11... | 159 | @@ -282,7 +282,7 @@ +-----+------------+-------+ | Pos | KernelName | Boots | +-----+------------+-------+ -| 1. | *Linux | 1081 | +| 1. | *Linux | 1082 | | 2. | *FreeBSD | 1080 | | 3. | *Darwin | 155 | | 4. | *OpenBSD | 109 | @@ -298,7 +298,7 @@ +-----+------------+-----------------------------+ | Pos | KernelName | Uptime | +-----+------------+-----------------------------+ -| 1. | *Linux | 28 years, 1 months, 15 days | +| 1. | *Linux | 28 years, 1 months, 18 days | | 2. | *FreeBSD | 12 years, 2 months, 24 days | | 3. | *OpenBSD | 8 years, 2 months, 7 days | | 4. | *Darwin | 4 years, 12 months, 18 days | @@ -314,7 +314,7 @@ +-----+------------+-------+ | Pos | KernelName | Score | +-----+------------+-------+ -| 1. | *Linux | 1865 | +| 1. | *Linux | 1866 | | 2. | *FreeBSD | 862 | | 3. | *OpenBSD | 523 | | 4. | *Darwin | 329 | -- cgit v1.2.3