Roastidio.us Tagged with linux

Homebrew Release: Warnel Chawpiovs v1.5.0 (PC, Nintendo Switch, Android), adds 9 new heroes and significant performance improvements

Fri, 17 Jul 2026 17:09:28 +0000

I’ve just released version 1.5.0 of “Warnel Chawpiovs”, a homebrew game for PC (Windows, Linux, MacOS versions are now available), Nintendo Switch, and Android.

This new release fixes some significant rendering and performance issues. Specifically, there was a rendering problem in previous releases which made the game look very pixelated on any screen that wasn’t exactly 1920×1080. This should now be fixed, and the fix comes with some performance improvements in game.

Version 1.5.0 also brings 9 new heroes: Nebula, Gamora, Drax, Wolverine, Venom, Nightcrawler, Scarlet witch, Phoenix, and Valkyrie. I’ve tried to focus on heroes with a default “Justice” deck, as it has come to my attention that the number of Justice cards available in the Deck Editor was lagging a bit behind Aggression, Leadership and Protection.

(By the way, if you’re using and enjoying Warnel Chawpiovs, please do me a favor and spread the word, to friends or on social networks. Having a growing number of users helps me staying motivated to add more cards and features!)

Overall, the game now supports 36 heroes and 28 scenarios, which I estimate represents roughly 40% of all the cards in the original game (excluding campaigns)

This is a fan-created work and is not affiliated with, endorsed by, or sponsored by Fantasy Flight Games. All characters, settings, and related elements are the property of their respective owners.

What is Warnel Chawpiovs ?

Warnel Chawpiovs, aka WC, is a homebrew game for multiple platforms (included, but not limited to, Nintendo Switch, Android and Windows), based on the popular cooperative board game Marvel Champions. WC lets you play the popular card game with full rules enforcement. The game does the heavy lifting of handling all the rules, so you only have to focus on your strategy.

It also includes a full fledged deck editor (which, among other things, can import/export decks from popular fansite marvelcdb.com).

Please note that Warnel Chawpiovs doesn’t hold your hand. Although it automates all of the gameplay, you will still need a basic understanding of the original rules to know what’s going on. The rules can be found here if you’re interested: https://www.fantasyflightgames.com/en/products/marvel-champions-the-card-game/ (scroll down to the support/rules section and download “Learn to play“)

You can play on your own with one or multiple heroes, and there’s also a multiplayer mode, although I need to emphasize once again, multiplayer doesn’t exactly work*

Warnel Chawpiovs – What’s new in 1.5.0

Added 9 new heroes and their associated cards: Nebula, Gamora, Drax, Wolverine, Venom, Nightcrawler, Scarlet witch, Phoenix, and Valkyrie. This represents roughly 300 new cards.
Vastly improved the rendering on most devices. If the game looked heavily “pixelated” in previous releases to you, you might want to give this new version a try. Depending on your case, the game possibly went from “text is unreadable and images have an aliasing problem” to “this now looks ok”

Performance improvements ingame, which now should make the 4 heroes experience in particular much more playable.

1.5.0 Development notes and anecdotes

Performance: I thought 1.4.x was doing ok in terms of performance even with 4 heroes, but after trying a few games, it was clear that more effort was required on that front.

Warnel Champions uses the concept of “Alterants” (inherited from the Card Framework I’m using) which regularly computes any modification that a card might receive from another on the board (for example, a hypothetical card that says “your hero gets +1 ATK”). Making sure this information is constantly up to date but also not too computation-intensive is one of the main problems I’ve been trying to solve. I think I’ve done a good job now at avoiding unnecessary calls to this heavy function. It’s still not perfect in a 4 player game, but much better than in any previous release, as far as I can tell.

Heroes: I’m bringing 9 new heroes to this release. This is a new record, but I’m “cheating” a bit because I’m not bringing any new villains. Villains and encounters have been significantly more difficult to develop and test than hero cards, and I think the priority right now should be to support as many player cards as possible so that people can build any deck they want. Some of the new heroes are really fun. Nebula and Gamora are an interesting combination when playing two heroes, thanks to Nebula’s Nemesis treachery which literally forces your friend to attack you.

Scarlet Witch was probably the one that demanded the most additional work in the game engine, with her ability to modify boost icon counts at the last minute. To be perfectly honest, the way I implemented it isn’t perfect, and there are several cards in the game that will slightly break when Scarlet Witch interacts with them. Hopefully people won’t run into the issue too often, and eventually I might be able to fix that. In the meantime, her ability to alter a lot of boost icons makes her very powerful and quite fun to play.

How to install – Windows/Linux

Download the binaries below or on the github page:

Warnel Chawpiovs Download page

(alternatively on github)

extract anywhere on your computer, then run the binary file (Windows: WC.exe, Linux:WC.x86_64)

How to install – Android

Download the apk below or on the github page:

Warnel Chawpiovs Download page

(alternatively on github)

Copy the apk to your phone then install it with your phone’s file manager. You will need to enable “unknown sources” in your phone settings in order to install the APK.

Once you start the game it will need to download resources so it is recommended that your first launch is not on an expensive data plan

How to install – Nintendo Switch

You will need a hacked Nintendo Switch to run this game.

Download the binaries below or on the github page:

Warnel Chawpiovs Download page

(alternatively on github)

extract the WC folder inside your switch folder on your SD card.

Launch the homebrew Menu in “full speed” mode (not in applet mode). This is done by pressing the Right Should button (R) while launching a cartridge game.

From there, you can run the game

How to install – Mac OS

Download the binaries below or on the github page:

Warnel Chawpiovs Download page

(alternatively on github)

The Mac OS app isn’t officially signed, so in order to run it you can ctrl + click and select “open”

Running your First Game

The game will attempt to download any missing picture for new cards, as soon as you run it. This happens in the background and you can play while this happens. Again, that step is not needed if you have the appropriate “*.zip” resource files.

Once you’re in the game select “Sivgle Player”, then choose one hero and one villain, then click on launch.

Note: On your very first run, the game will only let you select one hero and one villain. This is intentional, as the game’s “adventure mode” requires you to win games in order to unlock more heroes and scenarios. If you don’t like this you can deactivate it in the options/gameplay menu, this will unlock all content.

Check the Videos below for examples of gameplay

Status of the Switch port

The Switch port is… slow. You might want to overclock your console when you play the game. I know it’s not ideal, but it makes the gameplay much more comfortable.

I would not recommend playing with more than one hero at the moment on Nintendo Switch, if only for performance reasons

Troubleshooting, bug reports, etc…

I do not have a dedicated forum or discord in place for this game yet. You can open issues on the github project, or contact me by email (wagic.the.homebrew at gmail), but please understand that I might dismiss or ignore most of those depending on free time and interest.

Known issues

Multiplayer should basically be considered broken for now.
Loading/Saving games is hit and miss depending on the hero/villain
Switch port is slow. You might want to overclock your console
The Mac port should be considered unsupported. I do not own any Apple products, which makes it impossible for me to verify (let alone debug) anything on that version.
There are still lots of issues with specific cards, but feel free to report issues you find on the github
- In particular multiple cards behave strangely when playing with more than one hero. This isn’t intentional so feel free to report those

Want more details?

check the Readme on github

What’s next:

There is still lots of work to do with this game. I am currently focusing on adding more cards to enjoy with a solo hero.

If by any miracle you are looking at my code and can help, in particular with multiplayer issues, please submit a PR on github

Download

Download page

Or on the project’s github page

* If you badly want to play Marvel Champions with friends online, the Marvel champions digital edition, another unofficial fan game, does a great job at it.

The post Homebrew Release: Warnel Chawpiovs v1.5.0 (PC, Nintendo Switch, Android), adds 9 new heroes and significant performance improvements appeared first on Wololo.net.

Download Debian ISO: With Easy Installation Guide

Fri, 17 Jul 2026 13:48:25 +0000

The world of Linux offers a vast landscape of distributions, but few are as respected, stable, and foundational as Debian. For many users, the journey into this powerful operating system begins with a single file: the Debian ISO. This file is more than just an installer; it’s a gateway to a free, open-source computing environment renowned for its robustness and commitment to software freedom.

Whether you’re a seasoned system administrator, a developer, or a curious newcomer, understanding how to obtain and use a Debian ISO properly is the first critical step. This guide will walk you through everything you need to know to get Debian up and running on your machine.

What Exactly is a Debian ISO?

An ISO image (often called an “ISO”) is a complete archive of everything on an optical disc, such as a CD or DVD, stored in a single file. In the context of Debian, the Debian ISO is an all-in-one file containing the entire operating system and its installer. You can use this file to create bootable installation media—typically a USB drive or a DVD—then use it to install Debian on your computer. It’s the digital blueprint for your new operating system.

Before You Download: Key Considerations

Before you click that download link, take a moment to answer a few questions to ensure you get the right version and have a smooth experience.

Choose Your Architecture: Modern computers are most likely amd64 (also known as x86-64). This covers most Intel and AMD processors. Other architectures like arm64 (for newer Raspberry Pis, servers, and ARM-based devices), armhf (for older ARM devices), ppc64el (POWER8 and POWER9), riscv64, and s390x (mainframes) serve specific hardware.
Desktop Environment vs. Network Install: Debian offers different types of ISOs.
- Live Images: These allow you to try Debian without installing it. You can boot directly from the USB drive and, if you like, launch the installer from the desktop. These are great for testing hardware compatibility.
- Full Installation Images: These are larger (~4 GB DVD ISOs) that contain a vast collection of software packages, allowing you to install without an internet connection.
- Network Install Images: This is the recommended method for most users. This is a very small ISO (~500 MB) that contains only the essential tools to start the installation. It then downloads all the latest packages directly from Debian’s servers during the install process, ensuring you get the most up-to-date software.
Check Your Hardware: Ensure your computer meets the minimum system requirements, which are quite modest by today’s standards. For a standard desktop installation, 2 GB of RAM and 10 GB of disk space are good starting points.

How to Download Debian ISO

You can obtain a Debian ISO image in several ways, each with its own advantages.

Method 1: Direct HTTP/FTP Download

The most straightforward method is to download the ISO directly from one of Debian’s many official mirrors worldwide. This is simple, but it relies on the stability of your internet connection, especially for the larger DVD images.

Network Install ISO

To use this, you will need a machine with an Internet connection.

Architecture	Image Type	Download Link (HTTP)
amd64	Netinst	Download
arm64	Netinst	Download
armhf	Netinst	Download
ppc64el	Netinst	Download
riscv64	Netinst	Download
s390x	Netinst	Download

amd64 is for standard 64-bit PCs and servers. 
arm64 is for modern, efficient devices like phones and newer single-board computers. 
armhf is for older 32-bit ARM devices like the Raspberry Pi 2. 
ppc64el is for IBM POWER servers. 
riscv64 is an open-source architecture for new embedded and experimental hardware. 
s390x is for IBM mainframe computers.

Complete Installation ISO

A larger, complete installation image that includes packages for all desktop environments, making it easier to install machines without an Internet connection.

Download | Torrent

Live Install ISO

You can try Debian by booting a live system from a CD, DVD, or USB key without installing any files to the computer. Only available for 64-bit PC

Desktop Environments	Download Links
Cinnamon	debian-live-13.6.0-amd64-cinnamon.iso
Debian Jr.	debian-live-13.6.0-amd64-debian-junior.iso
GNOME	debian-live-13.6.0-amd64-gnome.iso
KDE	debian-live-13.6.0-amd64-kde.iso
LXDE	debian-live-13.6.0-amd64-lxde.iso
LXQt	debian-live-13.6.0-amd64-lxqt.iso
MATE	debian-live-13.6.0-amd64-mate.iso
Standard	debian-live-13.6.0-amd64-standard.iso
Xfce	debian-live-13.6.0-amd64-xfce.iso

Method 2: Using a Torrent Client (Recommended)

For larger files, such as the Complete Debian ISO, using the provided Debian ISOtorrent is highly recommended. This method is often faster and more reliable because your client downloads parts of the file from multiple sources simultaneously. It also reduces the load on Debian’s main servers and helps you become part of the distribution network, ensuring the Debian ISO remains available to others.

Install a torrent client like qBittorrent, Transmission, or Deluge.
Click the “Debian ISO Torrent File” link from the table above to download the .torrent file, then open it with your client.

Architecture	Torrent Download Link
13.5.0 AMD 64-bit	debian-13.6.0-amd64-netinst.iso.torrent
13.5.0 AMD 64-bit – Education	debian-edu-13.6.0-amd64-netinst.iso.torrent
13.5.0 AMD 64-bit – MAC	debian-mac-13.6.0-amd64-netinst.iso.torrent
13.5.0 ARM 64-bit	debian-13.6.0-arm64-netinst.iso.torrent
13.5.0 ARMHF	debian-13.6.0-armhf-netinst.iso.torrent
13.5.0 PPC64EL	debian-13.6.0-ppc64el-netinst.iso.torrent
13.5.0 RISCV64	debian-13.6.0-riscv64-netinst.iso.torrent
13.5.0 S390X	debian-13.6.0-s390x-netinst.iso.torrent

Verifying Your Debian ISO Download

This is a critical step for security and integrity. It ensures that the file you downloaded is authentic and hasn’t been corrupted during transfer or tampered with.

Download the Checksum Files: Next to the ISO links on the official Debian page, you will find files like SHA256SUMS and SHA256SUMS.sign. Download these.
Generate Your ISO’s Checksum: On Linux or macOS, open a terminal and navigate to the folder containing your downloaded ISO. Type the following command. On Windows, you can use a tool like certutil in Command Prompt or a GUI tool like HashCheck.

sha256sum debian-13.5.0-amd64-netinst.iso

Compare the Checksums: Compare the long string of characters generated by the command above with the one listed for your specific ISO file in the SHA256SUMS file. They must match exactly.

Creating a Bootable USB Drive

With a verified Debian ISO in hand, you need to put it on a USB drive (at least 4 GB for netinst, and 8 GB or more for live images).

On Windows: Use tools like Rufus or Ventoy. Rufus is straightforward: select your USB drive, choose the downloaded ISO, and click “Start.”
On Linux: Use the dd command or a graphical tool like BalenaEtcher or Startup Disk Creator. Be extremely careful with the dd command, as selecting the wrong drive can erase your system.

sudo dd if=path/to/debian.iso of=/dev/sdX bs=4M status=progress oflag=sync

(Replace /dev/sdX with your actual USB device, e.g., /dev/sdb).

Booting and Installing

Insert the USB drive, restart your computer, and enter your BIOS/UEFI setup (usually by pressing F2, Delete, or F12 during boot). Change the boot order to prioritize your USB drive. Save and exit. The system will boot into the Debian installer or live environment, where you can begin your installation journey.

Conclusion

Downloading the correct Debian ISO is the fundamental and most important step in embracing one of the most stable and versatile operating systems available. By carefully selecting the right architecture and image type for your needs, opting for the efficient torrent download method, and rigorously verifying the file’s integrity, you lay a solid foundation for a successful installation.

The process, while detailed, ensures security and reliability—values at the very core of the Debian project. With your bootable USB drive ready, you are now prepared to experience the power, stability, and unparalleled freedom that Debian has offered to millions of users worldwide for decades. Welcome to the community.

For more Linux guides, visit here.

Igalia and Wind River Collaborate to Deliver Production-Ready Web Runtime for Embedded Linux Devices | Igalia

Fri, 17 Jul 2026 12:55:42 +0000

Igalia, an open source engineering consulting firm with over 25 years of experience in Linux-based systems and Web engine development, is pleased to announce a collaboration under the umbrella of the Yocto Project with Wind River, a global leader in embedded Linux platforms, to deliver a production-ready Web runtime for embedded devices.

The joint solution combines WPE WebKit, the open source Web engine port created and maintained by Igalia specifically for embedded Linux environments, with Wind River Linux, a commercially supported, Yocto-based embedded platform. Together, the two companies provide embedded product teams with a fully integrated, standards-based Web runtime backed by direct access to upstream maintainers.

A critical component of the solution is the meta-webkit Yocto layer, maintained by Igalia since 2017. This layer contains the necessary build recipes, supports multiple Yocto versions, and provides backported security fixes. It also serves as the foundation for upstream WebKit’s continuous integration (CI) infrastructure on real hardware targets, including the popular Raspberry Pi platform. This CI infrastructure allows to identify and resolve issues before they reach downstream product teams, meaningfully reducing risks for product teams.

Together, Wind River and Igalia provide embedded developers and product teams with:

A production-grade embedded Linux platform integrated with WPE WebKit
A standards-based Web runtime designed for constrained and headless devices
Direct access to upstream maintainers of WebKit and the WPE stack
A fully open source solution, minimizing dependency on proprietary frameworks

A Web engine provides a full application runtime that includes rendering, scripting, networking, and multimedia support, making it a compelling alternative to proprietary UI stacks. This is why modern embedded devices are increasingly adopting Web-based runtimes, including devices such as industrial human-machine interfaces, automotive systems, home appliances, smart TVs, and set-top boxes. Igalia’s deep and broad experience with Web engines, along with our foundational focus on open source development, gives us a unique skill set to bring to projects that use Web engines and similar open technologies.

This collaboration between Igalia and Wind River is the latest entry in our long history of helping others meld the power of the Web with their projects to deliver truly robust solutions, creating a strong foundation for building modern, Web-based embedded applications. It allows product teams to accelerate development, reduce integration complexity, and maintain long-term control over their software stacks using open source technologies. Embedded teams that need upstream support and long-term WebKit alignment now have a production-grade Linux platform to pair with it.

If you’d like to work with us, please get in touch to learn more and see how we can help your project get further, faster.

Building My Own GPS Stratum-1 Time Server on a Raspberry Pi - Jack Stromberg

Fri, 17 Jul 2026 07:05:30 +0000

Building My Own GPS Stratum-1 Time Server on a Raspberry Pi

Time silently hums away in the background, affecting everything we do today. Wake up, go to work, go to an appointment; all happen at specific times. Computers are no different, constantly logging time in logs, showing time in applications, and used for scheduling. In general, no one really cares about time because it's typically "accurate enough" for most tasks. Most computers just automatically have the correct time and are accurate down to a second or so, with most people perfectly content that it's technically approximately right. That being said, I'm neurotic and want nuclear-science-lab accuracy, knowing precisely what time it is.

While pool.ntp.org is a fantastic source of time, why settle when you can have sub-microsecond precision? No one is going to have a good time when you're technically having a bad time.

For this project, I wanted to see how precise time can be in my house, owning it end to end — no leaning on someone else's server out on the internet. In the industry, precision time is provided by what are called stratum-1 time servers and can sometimes be thousands of dollars. Given I'm cheap and don't have a money tree, I decided to build my own stratum-1 time server in a relatively affordable way: a Raspberry Pi that pulls time straight off the GPS satellites overhead and serves it to everything on my LAN, no internet required.

Along the way the project grew a second half, which is to visualize the satellite tracking and time sync. Once I had gpsd and chrony working, I wrote a small daemon that enables a live view of the calculated time, full gpsd + chrony stats, a satellite sky view, and an interactive 3D globe showing the GNSS constellation in space.

This build stands on the shoulders of the classic jacobdeane.com GPS time server guide, with two deliberate modernizations:

chrony instead of ntpd. chrony has native PPS support and a clean socket backend, so you skip the from-source NTP compile entirely.
Current Raspberry Pi OS paths. On Bookworm (and Trixie) the boot config lives at /boot/firmware/config.txt, not the old /boot/config.txt (which is now just a placeholder).

How it all fits together

Before wiring anything up, here's a quick overview :

GPS/RTC HAT (u-blox + PPS)           Raspberry Pi 3 / 4 (host)
 ┌───────────────────────────┐    ┌──────────────────────────────────────────────┐
 │  receiver                 │    │                                              │
 │   • NMEA over UART  ──────┼──▶│  /dev/serial0 ─▶ gpsd ─┐                      │
 │   • PPS on GPIO18   ──────┼──▶│  /dev/pps0 ────────────┼─▶ chrony (stratum 1) │
 └───────────────────────────┘   │                        │        │  serves NTP │
                                 │   gpsd JSON :2947 ─┐    │        ▼   to LAN    │
                                 │   chronyc -c ──────┼────┴─▶ Rust daemon        │
                                 │   (optional) NAVCEN ───▶  :8080 (configurable) │
                                 │                    ├─▶ /data     (SSE telemetry)│
                                 │                    ├─▶ /satinfo  (opt. sat info)│
                                 │                    └─▶ /         (dashboard)   │
                                 └───────────────────────────────┬───────────────┘
                                                                │
                                                   browser ◀────┘  dashboard

The timekeeping path — gpsd reads NMEA + PPS and feeds chrony; chrony disciplines the kernel clock and serves NTP to my network. This is what makes it a stratum-1 server. If you stop reading after Part 6, you've got a fully working time server.
The telemetry path — a small daemon written in Rust that reads the same gpsd data plus chrony's stats and streams them to the dashboard over Server-Sent Events. It's strictly read-only and has zero effect on timekeeping accuracy.

What you'll need

Here's the parts list I used:

Part	Notes
Raspberry Pi 3 or 4	Both work identically here. The Pi 4 has dedicated Gigabit Ethernet; on the Pi 3, Ethernet shares the USB bus, so keep other USB devices off it. The Pi 5 needs different UART steps and isn't covered.
GPS HAT with PPS	I used the Uputronics Raspberry Pi GPS/RTC Expansion Board, and it's what this guide is written against. PPS is mandatory for stratum-1; NMEA alone is only good to a few hundred milliseconds.
GPS antenna (active, timing-grade)	Amphenol PCTEL 3978D-HR-DH-W — the exact antenna I used: a weatherproof (IP67) GPS L1 dome antenna with a built-in LNA + filter (~40 dB gain) and a TNC-female connector. A real step up from a puck. Needs a clear-ish view of the sky.
Antenna mounting bracket	Amphenol PCTEL MMK1925 — the stainless-steel L-bracket for the WS397x-series dome (fits the 3978D). This and the antenna above are what I actually mounted.
Antenna coax	A run with the right ends for your antenna and HAT (see the note below). I didn't spring for timing-grade coax — I used a cheap SMA extension cable like this one and it's been perfectly fine.

All in all, the project cost ~$240 (inc. shipping, tax, etc). I didn't include the cost of a raspberry pi since I had one unused from a prior project, but assuming you bought a new Pi; you are ~$360.

Notes before we get started

Check your HAT's PPS pin. This guide assumes GPIO18 (the Uputronics default). Some HATs (e.g. Adafruit) use GPIO4. Adjust the gpiopin= value accordingly. Guess wrong and PPS will simply never show up.

Antenna connector & bias (if you're using the dome antenna above). The 3978D outputs TNC female, while most GPS HATs (Uputronics included) use SMA — so plan a coax run with the right ends (TNC-male at the antenna, SMA-male at the HAT) or grab an adapter. It's an active antenna (built-in LNA), so the HAT has to supply DC bias voltage on the coax; the Uputronics HATs do this, but confirm yours does. Being IP67 and bracket-mounted, it's meant to live outdoors on a mast with a clear sky view.

You don't have to mount it outdoors. The 3978D is a weatherproof, IP67, mast-mount dome. It's built to bolt onto a roof and shrug off the weather. I didn't put it on a roof. I bolted it to its MMK1925 bracket, set the whole thing up in my attic under asphalt shingles and 5/8" OSB, and ran it back to the HAT with a cheap SMA extension cable instead of proper timing-grade coax. On paper that's leaving signal on the table three different ways. In practice it's been tracking ~16-20 satellites and holding a sub-microsecond lock the entire time. So: buy the better antenna over fancy cable if you are on a limited budget and don't let "needs a clear view of the sky" scare you into a rooftop install (especially if you are HOA bound and limited to what you can mount outside). An attic on the sky-facing side of the house is likely going to do it for you.

Part 1 — The base OS

Flash Raspberry Pi OS Lite (64-bit) with Raspberry Pi Imager. In the Imager's advanced settings (the gear icon), enable SSH and set the hostname (I'll use timeserver for this guide) and locale before writing. Note: this Pi runs headless, which means you don't have a monitor connected to it, so you want to be able to reach it on first boot.

A word on Bookworm vs Trixie. As of mid-2026 there are active reports of a Trixie serial regression where the GPIO UART stops receiving GPS data on hardware that worked fine on Bookworm (a suspected kernel/PL011 driver issue). For a device whose entire job is reliable time, Bookworm might be the safer choice today; but so far things have worked fine for me. The config paths and overlays are identical — but if NMEA never appears despite correct wiring, jump to the Trixie diagnostic in Troubleshooting. There's also a Debian 12 vs 13 appendix at the bottom.

Boot, SSH to the Pi, and update first:

sudo apt update && sudo apt full-upgrade -y
sudo reboot

Part 2 — Freeing up the hardware UART

Here's the first "gotcha" the Pi throws at you. The Pi 3/4 wire the good UART (PL011) to the onboard Bluetooth by default. We need that UART for the GPS, and we also need to stop Linux from using the serial port as a login console.

2a. Disable the serial login shell (but keep the hardware port)

sudo raspi-config

Under Interface Options → Serial Port:

login shell accessible over serial? → No
serial port hardware enabled? → Yes

Choose Finish but don't reboot yet, we've got more config to add, and I'd rather reboot once.

2b. Disable Bluetooth to reclaim the UART

sudo vi /boot/firmware/config.txt

New to vi? Here's the reader's digest: press i to start typing (insert mode), make your edits, then hit Esc and type :wq followed by Enter to write and quit. If you fat-finger something and want to bail without saving, Esc then :q! throws your changes away. That's genuinely 90% of what you need to survive vi.

Add this at the end (we'll drop the PPS line in here too in Part 3, so it's a single reboot):

# Reclaim the PL011 UART for GPS by disabling onboard Bluetooth
enable_uart=1
dtoverlay=disable-bt

Older guides use dtoverlay=pi3-disable-bt; the current canonical name is just disable-bt. raspi-config may have already added an enable_uart=1 line — a duplicate is harmless, but you can keep just one if it bugs you.

Then stop the Bluetooth-UART service:

sudo systemctl disable hciuart

On a Lite image (and commonly on Trixie) this may report Unit hciuart.service does not exist — and that's totally fine. It ships with the pi-bluetooth package, which isn't always installed, and disable-bt already turns Bluetooth off at the device-tree level. The overlay is what actually matters here; this step is just belt-and-suspenders.

Part 3 — Enabling PPS

PPS (pulse-per-second) is the secret sauce. NMEA sentences tell you what second it is; the PPS pulse tells you exactly when that second begins, down to the nanosecond. No PPS, no real stratum-1.

3a. Load the PPS-over-GPIO overlay

Still in /boot/firmware/config.txt, add (adjust gpiopin for your HAT):

# Pulse-Per-Second input on GPIO18
dtoverlay=pps-gpio,gpiopin=18

Then load the kernel module at boot and reboot so both the UART and PPS changes take effect:

echo 'pps-gpio' | sudo tee -a /etc/modules
sudo reboot

3b. Verify raw GPS and PPS

First confirm the UART is on the GPIO header, then read raw NMEA:

ls -l /dev/serial0        # expect: /dev/serial0 -> ttyAMA0
sudo cat /dev/serial0

Always use /dev/serial0 — it's a symlink that always points to whichever UART is on the GPIO header, so you don't have to care whether it's ttyAMA0 or ttyS0 today. Ctrl-C to stop.

If you see garbled characters instead of clean $GNRMC/$GNGGA lines, don't panic, that's a baud-rate mismatch, not a fault. Bytes are flowing; the port's just reading them at the wrong speed. Set the rate explicitly and re-read until it's clean:

sudo stty -F /dev/serial0 9600 raw   && sudo cat /dev/serial0   # common u-blox default
sudo stty -F /dev/serial0 38400 raw  && sudo cat /dev/serial0
sudo stty -F /dev/serial0 115200 raw && sudo cat /dev/serial0   # mine with the Uputronics unit

Write down the rate that produces readable NMEA, you'll need it for gpsd in Part 4. It's a property of your GPS module, not the OS. Many u-blox modules use 9600, but others (including some Uputronics units) run at 115200. Mine was 115200.

Now confirm the pulse itself. This needs a satellite fix; most HATs blink a timepulse LED once they've locked:

sudo apt install -y pps-tools
sudo ppstest /dev/pps0

You want a new assert line every second, timestamped right on the whole second:

source 0 - assert 1699999590.000001416, sequence: 197334 - clear ...
source 0 - assert 1699999591.000000698, sequence: 197335 - clear ...

No output usually just means no fix yet, wait a couple mins or try moving the antenna to a different location. If you are running the antenna in a faraday cage, expect no results since it won't find a satellite.

Part 4 — gpsd

sudo apt install -y gpsd gpsd-clients
sudo vi /etc/default/gpsd

Point it at your HAT (using the baud rate you found in Part 3b):

START_DAEMON="true"
USBAUTO="false"
DEVICES="/dev/serial0 /dev/pps0"
GPSD_OPTIONS="-n -s 115200"

-n polls the GPS immediately at boot; -s 115200 pins the serial speed so gpsd doesn't autobaud its way into garbage. Enable and check:

sudo systemctl enable --now gpsd
sudo systemctl restart gpsd      # ensure it picks up the new config
gpsmon        # or: cgps -s

gpsmon shows the raw feed (fast-scrolling UBX packets are normal and healthy); cgps -s gives a calmer table. You want a 3D fix, satellites with good SNR, low DOP values, and a PPS line with a near-zero offset. That PPS line is the confirmation I was chasing.

Tip: gpsd takes exclusive control of the port. If you want to cat /dev/serial0 again for debugging, stop gpsd first: sudo systemctl stop gpsd gpsd.socket.

Part 5 — chrony with the socket backend

sudo apt install -y chrony

Here's the key design point, and the reason chrony is such an upgrade over the old ntpd dance: gpsd hands the precise PPS timestamp to chrony through a Unix socket (chrony's SOCK refclock). gpsd automatically writes to /run/chrony.<device>.sock once chrony has created it — neatly sidestepping the classic headache where chrony drops privileges and can no longer read /dev/pps0 directly.

sudo vi /etc/chrony/chrony.conf

Add this at the end:

# --- GPS + PPS reference clocks -------------------------------------------

# Coarse absolute time from gpsd (NMEA) via shared memory.
# 'noselect' = never sets the clock, only gives the PPS pulse a whole-second
# label. Tune 'offset' after calibration (Part 7d) if PPS won't lock.
refclock SHM 0 refid GPS precision 1e-1 offset 0.0 delay 0.2 noselect

# Precise PPS via gpsd's socket. gpsd writes here automatically.
# 'lock GPS' anchors each pulse to the GPS second above.
refclock SOCK /run/chrony.pps0.sock refid PPS lock GPS prefer

# Serve time to your LAN (adjust to your subnet) and keep serving during
# brief GPS dropouts.
allow 192.168.0.0/24
local stratum 1

# Optional internet fallback if the antenna fails. Remove for air-gapped use.
pool 2.debian.pool.ntp.org iburst

Restart both, in order — chrony first, so its socket exists by the time gpsd starts:

sudo systemctl restart chrony
sudo systemctl restart gpsd

Confirm the socket exists (it should be owned by root and actually be a socket — note the leading s in the permissions):

ls -l /run/chrony.*.sock      # expect /run/chrony.pps0.sock

Part 6 — Confirming you've actually got a stratum-1 server

Give it 5 minutes to settle, then watch the sources roll in:

watch -n 2 chronyc sources -v

You're looking for #* next to PPS. The asterisk means it's the selected source disciplining the clock. It starts at #? (not enough samples yet), climbs its reachability register (0 → 1 → 3 → 7 → 17 → 37 → 77 → 377), then finally promotes to #*. The internet servers drop to ^- (background sanity checks) once PPS takes over. Watching that register tick up is weirdly satisfying:

MS Name/IP address   Stratum Poll Reach LastRx Last sample
=========================================================================
#? GPS                     0    4  377     14   +42ms[  +42ms] +/- 200ms
#* PPS                     0    4  377     13   -242ns[ -324ns] +/- 1095ns
^- 2.debian.pool.ntp.org   2    6   77     45   -437us[ -436us] +/-  13ms

Then confirm the server itself:

chronyc tracking

Look for Stratum : 1, Reference ID … (PPS), and a System time offset down in the sub-microsecond range. That, right there, is a working stratum-1 time server. I may have taken a screenshot.

Reading the numbers: System time / Last offset are your current accuracy (nanoseconds-to-microseconds once locked). RMS offset looks alarming at first (hundreds of µs) because it's a rolling average still dominated by the noisy warm-up; it falls steadily the longer it runs, so don't judge it too early. Root delay near zero and Reference ID = PPS confirm a direct hardware lock.

The falseticker trap. chrony will reject PPS if the GPS (NMEA) label is more than ±200 ms off the true second. If PPS stays stuck at #?, that's almost always the culprit, calibrate the offset (Part 7d).

At this point the time server itself is done. Below is the fun part of visualizing the setup. If you just wanted accurate time, congratulations, you can stop here.

Part 7 — The telemetry daemon

Now to create a live dashboard to visualize everything. The daemon does four things:

Connects to gpsd's JSON socket on 127.0.0.1:2947 — the same protocol libgps speaks, so I get identical data without any C FFI.
Polls chrony once a second with chronyc -c tracking (the -c flag hands back machine-readable CSV from chrony's command socket).
Merges both, streams them to the browser over SSE at /data, and serves the dashboard.
(Optional, off by default) fetches and caches the NAVCEN GPS almanac and serves it at /satinfo for satellite-health enrichment (more in Part 8).

Get the code, the daemon and dashboard live on GitHub: JackStromberg/gps-timeserver-daemon. Clone it directly onto the Pi:

sudo apt install -y git
git clone https://github.com/JackStromberg/gps-timeserver-daemon.git
cd gps-timeserver-daemon
ls -al

You should end up with:

gps-timeserver-daemon/
├── Cargo.toml
├── src/main.rs
└── static/index.html      # already set to live mode (USE_SIMULATION = false)

7a. Install Rust and build

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh   # press Enter for defaults
source "$HOME/.cargo/env"
cargo --version                                                  # should print a version
sudo apt install -y build-essential                              # C linker (Lite images lack it)
cd gps-timeserver-daemon
cargo build --release

cargo: command not found right after installing? The installer can't modify an already-running shell's PATH. Run source "$HOME/.cargo/env" (or just open a new terminal). If ls ~/.cargo/bin/cargo doesn't exist, the install didn't finish — re-run the curl … | sh line.

error: linker 'cc' not found? Install build-essential (above) and rebuild.

Fair warning: the first build on a Pi is slow. It compiles tokio, axum, reqwest, and the whole rustls TLS stack from scratch (several minutes), and it may look completely frozen at the final link step. That's normal. Subsequent builds are incremental and quick.

7b. Run it

./target/release/gps-timeserver-daemon

It prints its listen address and stays running (it's serving, so it won't hand you back a prompt). Open http://<pi-ip>:8080 from a browser on your LAN and you should see the dashboard light up.

The port is configurable — see Part 8. If 8080 is already taken (a Docker service, say), you'll get AddrInUse; set a different PORT rather than editing code.

7c. The `/data` contract

The daemon emits one JSON object per second in this shape (the dashboard reads exactly these field names):

{
  "timestamp": "2026-07-07T12:34:56Z",
  "time":   { "gps_time": "...", "system_time": "...", "offset_us": 0.42,
              "time_since_last_fix": 0.3, "leap_seconds": 18 },
  "gps":    { "mode": 3, "satellites_visible": 12, "satellites_used": 9,
              "hdop": 0.8, "vdop": 1.1, "pdop": 1.3, "gdop": 1.5, "tdop": 0.7,
              "ept": 0.005, "latitude": 51.5, "longitude": -0.12, "altitude": 35.2,
              "epx": 3.1, "epy": 4.2, "epv": 6.0, "track": 0.0, "speed": 0.0,
              "climb": 0.0, "eps": 0.5 },
  "chrony": { "reference_id": "PPS", "stratum": 1, "system_time": 0.0000004,
              "last_offset": 0.0000004, "rms_offset": 0.0000012,
              "frequency_ppm": -2.3, "residual_freq_ppm": 0.001, "skew_ppm": 0.02,
              "root_delay": 0.00001, "root_dispersion": 0.00002,
              "update_interval": 16.0, "leap_status": "Normal" },
  "device": { "path": "/dev/serial0", "driver": "u-blox", "subtype": "...",
              "bps": 115200, "parity": "N", "native": true, "cycle": 1.0, "mincycle": 1.0 },
  "version":{ "release": "3.25", "proto_major": 3, "proto_minor": 15 },
  "satellites": [
    { "prn": 5, "system": "GPS", "elevation": 70, "azimuth": 251, "snr": 42, "used": true }
  ]
}

Telemetry::to_json() in src/main.rs is the single source of truth for this contract — if you want to add a field, that's the one place to touch.

7d. Calibrating the GPS offset (optional)

If PPS refuses to lock, let it run ~15 minutes, then read the measured GPS offset:

chronyc sourcestats

Take the GPS source's Offset (say +512ms), convert to seconds, and set it as offset on the SHM 0 line in chrony.conf (e.g. offset 0.512). Restart chrony. This nudges the NMEA label back inside the ±200 ms window so PPS gets accepted — the fix for that falseticker trap I mentioned above.

Part 8 — Configuration via environment variables

I wanted to be able to change behavior without recompiling, so the daemon reads a handful of environment variables at startup. Set them when running manually, or via Environment= lines in the systemd unit (Part 9).

Variable	Default	Purpose
`PORT`	`8080`	Port to bind (binds `0.0.0.0:PORT`).
`LISTEN_ADDR`	(unset)	Full `host:port`; overrides `PORT`. Use `127.0.0.1:8088` to serve only locally, `0.0.0.0:8088` for the LAN.
`SATINFO_ENABLED`	(off)	`1`/`true`/`yes`/`on` enables the optional NAVCEN satellite-info fetcher. Off means the daemon makes zero outbound network calls — safe for air-gapped setups.
`SATINFO_INTERVAL_HOURS`	`168` (weekly)	How often to refresh the NAVCEN data. The constellation changes only a few times a year, so weekly (or `720` ≈ monthly) is plenty.
`SATINFO_URL`	NAVCEN YUMA almanac	Override the source if needed.

The optional satellite-info fetcher

When SATINFO_ENABLED=1, a background task fetches the NAVCEN GPS almanac (US Coast Guard, public-domain US-government data), caches it in memory, and serves it at /satinfo. The dashboard uses it to add live health status to each GPS satellite's hover tooltip. On failure it retries in an hour; on success it waits the full interval. Left disabled (the default), /satinfo returns {"enabled": false} and the dashboard silently falls back to its built-in reference table — so nothing breaks either way.

Quick checks once you've enabled it:

journalctl -u timeserver-dashboard -n 20 --no-pager   # look for: satinfo: fetched N satellites
curl -s localhost:8080/satinfo | head -c 300          # expect "enabled":true and a satellites object

On data sources & licensing (not legal advice): NAVCEN is public-domain US-government data — no account, redistribution-safe. The dashboard's built-in reference table is assembled from public GPS records. If you instead point live mode at CelesTrak, respect their access etiquette (cache; don't poll more than roughly every 2 hours) and cite them. There's a fuller Licensing appendix at the bottom.

Part 9 — Running it at boot

I want this thing to just come back on its own after a power blip, so let's give it a systemd unit:

sudo vi /etc/systemd/system/timeserver-dashboard.service

[Unit]
Description=GPS Timeserver Dashboard
After=network-online.target gpsd.service chrony.service
Wants=network-online.target

[Service]
# Adjust User and paths to where you put the project.
User=pi
WorkingDirectory=/home/pi/gps-timeserver-daemon
ExecStart=/home/pi/gps-timeserver-daemon/target/release/gps-timeserver-daemon
Restart=on-failure
RestartSec=3

# Optional configuration (see Part 8):
Environment=PORT=8088
# Environment=SATINFO_ENABLED=1
# Environment=SATINFO_INTERVAL_HOURS=168

[Install]
WantedBy=multi-user.target

WorkingDirectory matters more than it looks. The daemon serves static/index.html relative to where it runs, and systemd does not inherit your shell's current directory. Point this at the wrong place and you'll get a 404 for the dashboard.

Enable and verify:

sudo systemctl daemon-reload
sudo systemctl enable --now timeserver-dashboard
systemctl status timeserver-dashboard          # expect: active (running)
journalctl -u timeserver-dashboard -n 5 --no-pager   # confirm the listen address

Whenever you edit the unit file (say, to change an Environment= line), run sudo systemctl daemon-reload and then sudo systemctl restart timeserver-dashboard. Skipping the reload is the classic "my change didn't take" gotcha. systemctl show timeserver-dashboard -p Environment prints what systemd is actually passing, which is handy when you're sure you fixed it but it disagrees.

One nice quality-of-life note: editing only static/index.html (HTML/CSS/JS) needs no rebuild and no restart — the daemon serves it from disk at request time. Just hard-refresh the browser (Ctrl-Shift-R). Only changes to src/main.rs or Cargo.toml require cargo build --release.

Part 10 — Serving time to the rest of the network

Everything so far only disciplines the Pi's own clock. To let other machines sync from it, chrony has to answer NTP requests — and it refuses by default, which is a good safety default but not what we want here.

10a. Match the allow line to your LAN

hostname -I               # your Pi's IP, e.g. 192.168.1.50

If the Pi is 192.168.1.50, your subnet is likely 192.168.1.0/24. Edit chrony.conf so the allow line matches — a whole subnet (allow 192.168.1.0/24), a single host (allow 192.168.1.100), or allow all only if you deliberately mean to serve the public — then restart:

sudo systemctl restart chrony

10b. Confirm it's serving

sudo ss -ulnp 'sport = :123'    # something should be bound to UDP 123
chronyc clients                 # machines that have requested time (empty until clients connect)

If you run a firewall on the same Raspberry Pi (ufw, nftables, or Docker-managed iptables), open NTP: sudo ufw allow 123/udp. A plain Lite install has no firewall and needs nothing.

10c. Point your clients at the Pi

Your Pi is stratum 1, so anything syncing to it becomes stratum 2 — perfect for a LAN. Here's how I pointed a few common clients at it:

Router: set its NTP server to the Pi's IP — this pushes time locally to every device automatically, using it as an ntp source.
Linux: add server <pi-ip> iburst to /etc/chrony/chrony.conf, restart chrony.
Windows: w32tm /config /manualpeerlist:"<pi-ip>" /syncfromflags:manual /update then w32tm /resync.
macOS: System Settings → General → Date & Time, or sudo sntp -sS <pi-ip>.

Verify from a client with chronyc -h <pi-ip> tracking, sntp <pi-ip>, or ntpdate -q <pi-ip>. Back on the Pi, chronyc clients will list everyone pulling time from you.

Part 11 — Actually using the dashboard

Open http://<pi-ip>:<port> (default 8080, or 8088 in my examples above). Everything updates once per second from the live feed.

Time header. A large clock with millisecond precision, plus GPS time, system time, and the chrony offset. The UTC / Local toggle under the clock switches every time on the page between UTC and your browser's local zone, and it remembers your choice across reloads.

Orbital globe (the hero panel, and my favorite). A holographic Earth with each GNSS satellite placed in true 3D from its azimuth/elevation, color-coded by constellation, with beams running from the satellites in use down to a marker at your location.

Drag to rotate (mouse or touch): horizontal spins around the poles, vertical tilts.
Home button (top-right) or double-click the globe to glide back to the default view.
Hover a satellite for its details: PRN, constellation, elevation, azimuth, SNR, and whether it's in the solution — plus, for GPS, catalog facts (block, manufacturer, clock type, launch year, name, SVN) and, if /satinfo is enabled, live health.
Hover a legend entry (GPS/GLONASS/Galileo/BeiDou/SBAS) for a one-line explanation of that constellation.

Status panels. GPS Status, Chrony Status, Position & Navigation, and System Info. Hover any metric label (they've got a dotted underline) for an explanation of what it means and what a good value looks like — HDOP, TDOP, EPX/EPY/EPV, the chrony offsets, and so on. I added these mostly so I'd stop having to look them up myself.

Sky view + satellite table. Polar az/el plot, plus a detailed per-satellite table.

Satellite-info modes (dashboard side)

Near the top of the <script> in static/index.html:

SATINFO_MODE — 'daemon' (default; asks this server's /satinfo, no CORS, falls back to the built-in table if the server has fetching disabled), 'offline' (built-in table only, never fetches), 'celestrak' (fetch CelesTrak directly from the browser; may hit CORS), or 'off'.
The built-in table always supplies block/manufacturer/clock/name/launch; /satinfo adds live health on top.

Previewing with simulated data

static/index.html ships with const USE_SIMULATION = false; (live). To preview the UI without any hardware — say you're building this on your laptop before the HAT arrives — open a copy with it set to true. It generates fake data (a fixed location, invented satellites, a locked stratum-1 state) so every visual works offline.

Heads up: the globe and all hover tooltips are mouse-based, so the hover interactions won't appear on touchscreens (dragging the globe still works via touch).

Part 12 — Optional: running the dashboard in Docker

You can containerize the dashboard daemon — but keep gpsd + chrony on the host. The kernel clock is a single host-wide resource; putting chrony in a container means granting it SYS_TIME and steering the host clock across the container boundary — extra layers wrapped around your most timing-sensitive component. The daemon, on the other hand, is a read-only consumer and containerizes cleanly with zero precision impact.

Here's an example multi-stage Dockerfile:

# Build
FROM rust:1-bookworm AS build
WORKDIR /app
COPY Cargo.toml Cargo.lock* ./
COPY src ./src
RUN cargo build --release

# Runtime
FROM debian:bookworm-slim
RUN apt-get update && apt-get install -y --no-install-recommends \
      chrony ca-certificates && rm -rf /var/lib/apt/lists/*
WORKDIR /app
COPY --from=build /app/target/release/gps-timeserver-daemon /usr/local/bin/
COPY static ./static
CMD ["gps-timeserver-daemon"]

Note that chrony is installed here only for its chronyc client (the daemon shells out to it) — the container does not run a chrony daemon. Run it sharing the host network and chrony's command socket:

docker build -t timeserver-dashboard .

docker run -d --name timeserver-dashboard \
  --network host \
  -e PORT=8088 \
  -e SATINFO_ENABLED=1 \
  -v /run/chrony:/run/chrony:ro \
  --restart unless-stopped \
  timeserver-dashboard

--network host lets the daemon reach host gpsd at 127.0.0.1:2947 and keeps PORT/LISTEN_ADDR working normally.
Mounting /run/chrony gives the container's chronyc access to chrony's command socket.
You do not need --device=/dev/serial0 or /dev/pps0 here — the daemon never touches the hardware directly; it reads gpsd and chronyc. (Those devices only matter if you were containerizing gpsd/chrony too, which, again, I'd steer you away from.)

Troubleshooting

Here's a running list of things I've stumbled across:

Symptom	Likely cause / fix
`cat /dev/serial0` shows nothing	UART not freed. Confirm `dtoverlay=disable-bt` is in `/boot/firmware/config.txt` (not `/boot/`), `hciuart` disabled, rebooted. Check `ls -l /dev/serial0` points to `ttyAMA0`.
`cat /dev/serial0` shows garbled text	Baud-rate mismatch (not a fault). Set the rate with `stty -F /dev/serial0 <rate> raw` and re-read; use the working rate in gpsd's `-s`.
Silent serial on Trixie only, same HW worked on Bookworm	Suspected Trixie UART/PL011 regression. Diagnose: `pinctrl poll 14-15 &`, then trigger GPS data — if GPIO15 (RX) never changes level, no bytes are reaching the pin (a kernel issue, not your config). Try `linux-modules-extra-raspi`, pin an older kernel, or fall back to Bookworm.
`ppstest` prints nothing	No fix yet, or wrong PPS pin. Give it sky view; verify `gpiopin=` (4 vs 18).
chrony PPS stuck at `#?`	GPS/NMEA offset > 200 ms → falseticker. Calibrate the `SHM 0` offset (Part 7d); make sure `/dev/pps0` is in gpsd `DEVICES` and `/run/chrony.pps0.sock` exists.
Dashboard "Waiting for data..."	Daemon can't reach gpsd. Check `systemctl status timeserver-dashboard` and that gpsd is up on `:2947`.
Dashboard returns 404	`WorkingDirectory` in the unit doesn't point at the project root, so `static/index.html` isn't found. Fix the path, `daemon-reload`, restart.
Daemon exits with `AddrInUse`	The port's taken (e.g. Docker on 8080). Set `Environment=PORT=8088` (or another free port); `sudo ss -ltnp 'sport = :8080'` shows the culprit.
`/satinfo` shows `enabled:false`	`SATINFO_ENABLED` not set/true, or `daemon-reload` skipped after editing the unit. `systemctl show … -p Environment` to verify.
`/satinfo` `enabled:true` but `count:0`	NAVCEN fetch/parse failed (check the `error` field and the journal). Network blip → it retries within an hour; persistent → check outbound HTTPS.
`cargo: command not found`	PATH not loaded: `source "$HOME/.cargo/env"`. If `~/.cargo/bin/cargo` is missing, re-run the rustup installer.
`cargo build` → `linker 'cc' not found`	`sudo apt install -y build-essential`, then rebuild.
Clients can't sync	The `allow` subnet in `chrony.conf` has to match your LAN; open UDP/123 if you run a firewall.
Satellites look frozen on the globe	Expected! GPS is MEO (~2 orbits/day) and moves only gradually in az/el; the receiver also updates angles slowly. Check back in 20–30 min and the pattern will have shifted.

What you end up with

So where does all this leave you? Two things:

A stratum-1 NTP server disciplined by GPS + PPS, accurate to the microsecond or better, serving your whole LAN with no internet dependency. Every device on my network now sets its clock from a little box in my attic pulling time straight out of the sky, and I find that quietly delightful.
A live dashboard showing the calculated time, full gpsd + chrony stats with hover explanations, an interactive 3D constellation globe with per-satellite detail, and a sky view — all fed by the same hardware over SSE, with a clean JSON contract you can extend however you like.

If you want to keep tinkering, there are really just two files worth revisiting: src/main.rs (where Telemetry::to_json() defines the data contract) and static/index.html (METRIC_HELP, GPS_SAT_DB, and the render functions). Everything I'd want to customize lives in one of those two places.

If you made it this far, congrats on your new clock! Your clock is now more accurate than it has any reason to be!

Appendix A — Debian 12 (Bookworm) vs Debian 13 (Trixie)

Both work; most steps are identical. I verified everything on Debian 12 & 13 exactly as written above.

Topic	Debian 12 / Bookworm	Debian 13 / Trixie
Boot config path	`/boot/firmware/config.txt`	Same
`disable-bt` / `pps-gpio` overlays	Same	Same
Serial device	`/dev/serial0 → ttyAMA0` (always prefer `serial0`)	Same
`systemctl disable hciuart`	Usually succeeds	Often `Unit … does not exist` — harmless
GPIO UART receiving GPS	Reliable	Regression risk (mid-2026): no RX bytes despite correct config. Diagnose with `pinctrl poll 14-15`; may need `linux-modules-extra-raspi`, an older kernel, or Bookworm
gpsd / chrony	Stock; config as written	Newer; same config syntax, `chronyc -c tracking` CSV unchanged
Recommendation	Preferred for a time server	Works, but verify the serial link early

Remember: serial baud rate is a property of your GPS module, not the OS — it's handled identically on both.

Appendix B — Environment variables (quick reference)

Daemon (systemd Environment= or shell):

Dashboard (static/index.html constants):

Appendix C — Licensing & data sources

Not legal advice. For personal, non-commercial use you're clear on all of the below.

GPS orbital/almanac data is US-government, public-domain. NAVCEN (US Coast Guard) serves it with no account and is redistribution-safe — the recommended live source here.
CelesTrak (an alternative live source) redistributes the same government data and adds convenient PRN/block labeling. Respect their access etiquette: cache results and don't poll more than roughly once every two hours; cite CelesTrak; note that it isn't an official source. Commercial redistribution is a "contact them first" situation.
The dashboard's built-in reference table is factual data (which PRN, block, launch year, manufacturer) assembled from public records; facts aren't copyrightable.
For anything commercial or internet-facing at scale using, review each source's current terms directly.

Linux Creator Linus Torvalds To Anti-AI Devs: Go Fork Yourself | HotHardware

Fri, 17 Jul 2026 02:40:46 +0000

The strength of open-source software is that it's open, which is to say that anyone can contribute to it. Sometimes, this also means that your project can attract persons with conflicting worldviews. No open-source project is bigger than Linux itself, and recently the Linux Kernel project has been grappling with calls from certain contributors who feel that Linux should take an assertive anti-AI stance. Top-level maintainer and Linux creator Linux Torvalds has "put his foot down" on the issue, and his stance is clear: Linux is about the technology, not ideology.

Replying to a post where prominent Googler Roman Guschin remarks on the AI use recommendations of the Software Freedom Conservancy by calling them "anti-LLM in general", Torvalds spoke up to agree, saying that "Linux is not one of those anti-AI projects, and if somebody has issues with that, they can do the open-source thing and fork it." This is the same ethos Linus has always applied; he's spent decades saying "show me the code" regardless of the controversy of the moment.

Indeed, Torvalds' post isn't exactly pro-AI. He's certainly not demanding anyone to use it, nor even really advocating for its use, and he acknowledges that it has been problematic for Linux and free software in the past. His stance is made clear when he says "We're not forcing anybody to use it, but I will very loudly ignore people who try to argue against other people from using it." The physics of "very loudly ignoring" someone aside, the point is that anti-AI sentiment, especially that driven by ideology, is not welcome in the Linux Kernel project.

It's important to understand some of the context here. There's a relatively small but very noisy contingent of programmers who are also highly active politically, and the vast majority of this group are anti-AI ideologues. Linus has consistently resisted attempts to make kernel governance revolve around anything other than technical merit, and so he is understandably not keen to have this extremely American culture war imported into the very core of Linux. It's not really about AI in the first place; it's about ideology, tribalism, and political leverage, all advanced under the guise of "social justice."

Again, AI isn't perfect; it has caused real problems for open-source projects. However, it's also a legitimately powerful tool, and besides, human programmers submit plenty of crummy code and problematic patch requests without the help of AI. Torvalds acknowledges this by saying "anybody who points to the problems at AI had better be looking in the mirror and pointing at themselves at the same time. Because it's not like natural intelligence is always all that great either."

Ultimately the message is against holy wars and pro-technology. Concluding his message, Torvalds specifically says "This is *NOT* some kind of 'social warrior' project, never has been, and never will be. In the kernel community we do open source because it results in better technology, not because of religious reasons. And so we make decisions primarily based on technical merit." It's a clear response to ideologues who would seek to subvert the purity of the Linux Kernel project, and from my point of view, it's heartening to see in a world where most organizations seem all too eager to bend the knee to exactly this sort of advocacy.

_{Top image by World Economic Forum / CC BY-SA 2.0}

Huawei HG8245H, can't read some system files

Fri, 17 Jul 2026 00:00:49 +0000

I have modem Echolife HG8245H (V3R016C10S150). I'm using telnet to connect it. I need to read some files from this modem. There's a shell mode I can enter, but it is nerfed badly:

SU_WAP>shell BusyBox v1.18.4 (2016-10-11 19:35:35 CST) built-in shell (ash) Enter 'help' for a list of built-in commands. profile close core dump WAP(Dopra Linux) # ? exit getcustominfo.sh restorehwmode.sh

These are all commands I can do in this mode. There is another way to look at the directories:

SU_WAP>wap list path / bin boot dev etc html lib libexec linuxrc mnt proc root sbin share sys tmp uer usr var

It works like 'ls'. But I can not read any file:

SU_WAP>wap list path /var/wifi.txt /var/wifi.txt success!

Commands like 'cat' aren't working. Does anybody know is there any way to read these files if you're connecting modem through telnet? Maybe this is not possible with this firmware?
Thank you:)

We Built a New Editor. Want to Try It? – Simplenote

Thu, 16 Jul 2026 15:21:04 +0000

A few months ago, Automattic launched Radical Speed Month: a company-wide sprint during which teams picked a passion project and built something real. Here at Simplenote, one of those projects focused on the editor. Could we make Markdown feel more immediate in Simplenote? Still plain text at its core, but easier to read and write? The result is a “What You See Is What You Get” (WYSIWYG) Markdown editor prototype for the Simplenote desktop app, and we’re ready for you to try it!

What we built

Simplenote isn’t changing what a note is. Your notes are still Markdown (or plain text). They still sync everywhere. What’s new, however, is how writing feels on desktop. Headings, bold, italic, strikethrough, and list markers appear styled inline as you type Markdown. **bold** becomes bold, # heading becomes a large heading. Need help with Markdown syntax? The new toolbar is there to help.

Now it’s your turn! Give us your feedback and help us shape the future of the Simplenote editor.

Try the prototype

This build is available for Windows, macOS, and Linux as a pre-release desktop download:

Or browse all files on the GitHub release page.

One app at a time: Quit any open copy of Simplenote before installing or launching this build.

Returning to the official app: Your notes stay in your account no matter which build you’re running. If you replaced your usual Simplenote install, you’ll be prompted to switch back when a new release is available — or simply reinstall the latest version anytime from simplenote.com.

Tell us what you think

If this editor makes writing easier, we want to hear about it. If something doesn’t feel quite right, we want to hear about that too. Please drop us an email at support@simplenote.com.

Patchless

Thu, 16 Jul 2026 10:14:51 +0000

Comments

TLS Certificate Validation on Linux · Ivan Tomica

Thu, 16 Jul 2026 01:11:13 +0000

We all know the drill. You type https:// into the browser, a padlock shows up, and everyone collectively agrees not to think about what just happened. That works fine right up until the moment some application on your server starts throwing certificate verify failed while curl against the same endpoint works perfectly. Or the other way around. That’s usually the point where people discover that “the system trusts the certificate” is a much less well-defined statement than it sounds.

So let’s unpack what actually happens when a program on a Linux system decides whether to trust a TLS certificate, and why two programs on the same machine can happily disagree about it.

What the server actually sends

During the TLS handshake, the server doesn’t just send its certificate. It sends (or at least it should send) a whole chain:

the leaf certificate, issued for the actual hostname
one or more intermediate certificates, which issued the leaf

What it does not send is the root certificate. There would be no point. A root the client doesn’t already have is worthless, since the entire trust model rests on the client having its own local copy of the roots it considers trustworthy. A root certificate arriving over the network from the very party you’re trying to verify would be about as convincing as an email signature saying “definitely not a scammer”.

The client’s job is then to build a path from the leaf it received, through the intermediates, up to a root it already knows and trusts. Each certificate in the chain is signed by the next one up, so the client verifies signatures link by link until it lands on something from its local trust store. If it can’t complete that path (missing intermediate, unknown root, whatever), the connection is refused.

That “missing intermediate” case deserves a special mention because it’s a classic. A misconfigured server that sends only the leaf will work fine in browsers (they cache intermediates seen elsewhere and can even fetch them on demand) and fail miserably with OpenSSL-based tools, which do no such fetching. If you’ve ever had a site that “works in Chrome but not in curl”, there’s a very good chance this was it.

Chain building is only part of the story though. Along the way the client also checks:

validity dates - is the certificate expired, or not yet valid
hostname - does the name you’re connecting to appear in the certificate’s Subject Alternative Names
key usage constraints - is the intermediate actually allowed to issue certificates
revocation - in theory via CRL or OCSP, in practice this one gets skipped or soft-failed far more often than anyone in the industry likes to admit

All of that is mechanical. The interesting question is the last step: what exactly is that “local trust store” the chain has to terminate in?

The system trust store

On Linux, root certificates are just files on disk. There’s no TPM magic, no registry, nothing exotic. Just a directory full of PEM-encoded certificates and a couple of symlink/concatenation tricks on top.

The certificates themselves typically come from the distribution’s ca-certificates package, which in turn repackages the Mozilla root program’s list. So when people say “the system trusts this CA”, what they really mean is “Mozilla trusts this CA, Debian repackaged that decision, and my system installed it”. A fun chain of custody to think about, but it works remarkably well.

Where things get less uniform is where those files live and how you add your own. Every distribution family has its own idea:

Debian-based systems keep the bundle in /etc/ssl/certs/ca-certificates.crt, and you add local CAs by dropping them into /usr/local/share/ca-certificates/ and running update-ca-certificates
Red Hat-based systems use /etc/pki/ca-trust/, you drop files into /etc/pki/ca-trust/source/anchors/ and run update-ca-trust
and then there’s everyone else, each with a slightly different path and update command

The update command’s job is to take all the sources (the distro bundle plus your local additions) and regenerate the various formats applications expect: a single concatenated PEM bundle, a hashed directory for OpenSSL’s lookup, sometimes a Java keystore too. Modern distributions increasingly funnel all of this through p11-kit, which acts as a central broker so that different crypto libraries can share one trust source. Increasingly. Not universally. Remember that word, it’s about to matter.

Here’s where it falls apart

The dirty secret is that “the system trust store” is a gentleman’s agreement, not an enforcement mechanism. Nothing in the kernel or anywhere else forces an application to use it. TLS validation happens entirely in userspace, inside whatever TLS library the application happens to link against, and that library reads whatever trust source it was configured to read.

And applications, as it turns out, love bringing their own.

The TLS library landscape alone already fragments things. OpenSSL, GnuTLS, and NSS each have their own default lookup paths, which distros patch to point at the system store with varying degrees of consistency. But the real fun starts one layer up:

Java ships its own keystore (cacerts), managed with its own tool (keytool), in its own format, completely oblivious to anything in /etc/ssl. Some distributions wire it up to the system store, some don’t, and the JVM you downloaded as a tarball certainly doesn’t
Node.js compiles Mozilla’s root list into the binary. The certificates your Node application trusts were decided when that Node version was built
Python - the standard library uses OpenSSL’s defaults, which usually means the system store. But the popular requests library pulls in certifi, which is Mozilla’s bundle shipped as a pip package. So a single Python process can contain two different trust stores depending on which import a given code path uses
Browsers famously do their own thing entirely, Firefox with NSS and its own root program, Chrome nowadays with its own root store as well
Go reads the system store, but like nearly everything else it honors SSL_CERT_FILE and SSL_CERT_DIR overrides, as do OpenSSL-based tools, joined by app-specific variables like NODE_EXTRA_CA_CERTS and REQUESTS_CA_BUNDLE

From the application vendor’s perspective this is all perfectly rational. Shipping your own trust store means consistent behavior across every platform, no dependency on the distro getting things right, no surprises from whatever the local admin did to /etc/ssl. Java behaves the same on Linux, macOS, FreeBSD, and that one Windows machine nobody wants to touch, precisely because it ignores all of them equally.

From the sysadmin’s perspective, it means the question “does this machine trust my CA?” has no single answer. The machine doesn’t trust anything. Applications do, each in their own way.

The private CA obstacle course

Where this bites hardest is internal infrastructure. You run your own CA (for internal services, a MitM-ing corporate proxy, a homelab, doesn’t matter) and now you need your systems to trust it. The naive expectation is one step: add the CA to the system store, run the update command, done.

The actual experience tends to be more of a scavenger hunt:

add the CA to the system store - curl, wget and most C-linked things are now happy
discover the Java service still fails, keytool -importcert into its cacerts
discover the Node service still fails, set NODE_EXTRA_CA_CERTS
discover the Python service still fails because certifi, set REQUESTS_CA_BUNDLE
discover some container image fails because it has its own /etc/ssl inside, completely separate from the host’s
repeat for every runtime, tool, and container you’ll ever deploy

That last point about containers is worth an extra sentence: an application in a container brings its own filesystem, which means its own trust store, which means all of the above nested one level deeper. Your host trusts the CA just fine, but the process inside the container is validating against the /etc/ssl that came with the image, blissfully unaware of anything you did on the host. The usual fix is to mount the host’s CA bundle over the container’s copy, either as a read-only bind mount or, in Kubernetes, as a volume pointed at the right path.

None of this is broken, strictly speaking. Every one of those applications is behaving exactly as designed. It’s just that “as designed” was decided by a dozen different projects with a dozen different philosophies, and you get to integrate the result.

There’s also a legitimate flip side: an application controlling its own trust chain isn’t only an annoyance, it can be a feature. Pinning, meaning trusting only your specific CA, or even one specific certificate, instead of the two-hundred-ish public roots, dramatically shrinks the attack surface for that one connection. A backend service that talks exclusively to your internal API has no business trusting every certificate authority on the planet. The same mechanism that makes private CAs annoying to roll out is what makes this kind of hardening possible at all.

The trust model itself is fine. Chain building, signatures, local roots, all of it is well-designed and battle-tested. What Linux doesn’t have is a single enforcement point for it, and honestly, it never claimed to. “The system trust store” is a default, a convention that most things follow and nothing has to.

So the next time an application refuses a certificate that every other tool on the box accepts, skip the stage of doubting your sanity and go straight to the useful question: which trust store is this thing actually reading?

Is Denuvo's Dominance Finally Beginning to Crack?

Wed, 15 Jul 2026 22:21:49 +0000

🚧

Editor's note: we have not verified the details or the implementation of this workaround. If you chose to try it, you do so at your own risk!

For nearly a decade, Denuvo has been the PC gaming industry's most formidable form of anti-tamper protection. Publishers have relied on it to safeguard high-profile launches, while cracking groups have increasingly struggled to keep pace. In recent years, successful bypasses have become so rare that many viewed Denuvo as effectively unbeatable. It looks like that perception may finally be starting to change.

This week, members of the CrackWatch community declared "the year of the Linux desktop" after a new Linux-based method emerged that can launch an increasing number of Denuvo-protected games without triggering the DRM. Activity on certain forums has accelerated alongside the announcement, with users documenting compatibility reports and testing additional titles as the technique continues to evolve.

What makes this development particularly unusual is the role Linux gaming has played in the bypass. Rather than removing Denuvo from a game's executable or distributing modified files, the new approach combines hypervisor techniques with Linux compatibility layers such as Proton and Wine. Running Windows games through Proton changes the execution environment, while the hypervisor method appears to take advantage of those differences to bypass Denuvo's protections without producing a traditional crack. Exactly why it works is still being investigated by the community, but the result is a growing list of games that can be launched under Linux where the same approach does not work on native Windows installations.

That distinction is important. Proton itself is not a Denuvo bypass, nor did Linux originate the underlying hypervisor technique. Instead, Linux has become an unexpected platform where the method has proven effective, giving the Linux gaming community an unusually prominent role in what is shaping up to be one of the biggest challenges Denuvo has faced in years.

Whether this proves to be a short-lived loophole or the beginning of a broader shift remains to be seen. Denuvo has weathered numerous challenges throughout its history, and its developers have consistently updated the technology in response to new attack methods.

Even so, this is arguably the strongest challenge the DRM has faced in years. Beyond the piracy discussion, Denuvo has long been a flashpoint in debates surrounding game preservation, offline ownership, Linux gaming, and the long-term accessibility of purchased PC titles. If this Linux-based approach continues to mature, it could mark the first real sign that the industry's most dominant DRM solution is no longer as untouchable as it once seemed.

ℹ️

Traditional Denuvo cracks modify or remove the DRM from a game's executable. The new method instead focuses on the environment the game runs in. By combining virtualization (a hypervisor) with Linux compatibility layers like Proton, it can allow some protected games to run without altering the game's files. Because of this, many in the community describe it as a bypass rather than a conventional crack.

Read more: Gaming, Linux Gaming, Linux, News, PC Gaming, proton, Steam

With Google recently announcing they're dismantling their search platform, there's no better time to add The Bryant Review as one of your preferred sources.

About the Author:

dash

Passionate about retro gaming, game preservation, open-source software, and retro handhelds. I tell the stories behind games, hardware, and the people building them. Usually testing a new handheld, using Linux or F-Droid, or replaying a classic.

aol/trusty-boot-key: Set up a flash drive to "multi-boot" OS images from a menu. - Codeberg.org

Wed, 15 Jul 2026 00:39:33 +0000

Trusty Boot Key - TBK

"Submitted for your approval, a Trusty Boot Key—with all GPL¹ code…"—Rod Serling

Need a "trusty boot key" to load operating systems? A USB flash-drive for troubleshooting and experimentation? Read on.

The theme and fonts still need work, but you get the idea. Other themes are easy to install as well.

[1] If you're one of those folks that worries about the GPL—no need. This is an application and has no affect on other projects.

Rationale

We were quite impressed with the ease of use of Ventoy, but dismayed by its security posture, especially in light of the not-so recent xz backdoor fiasco. No bad news as of yet, but its hard to imagine a better way to install low-level malware across the globe. :-/

While looking around for a "Safe-Toy" alternative, we found a number of projects attempting to bring comparable ease of use to a GRUB multi-boot system on a similar removable drive.

But the projects were hard to grok. Complicated menus, clunky, redundant code, abandoned/archived repos, and tons of info about BIOS this, MBR, GRUB 1.0, and 16-bit that…

Huh, what is this, 1996? Haha. (These were already hitting their limits during the Clinton Administration.)

Support

UEFI (firmware)
GPT partition table
amd64 architecture

That's it. A.k.a. a modern P.C. To simplify development and docs we've removed everything related to ancient BIOS, MBR, and <= 32-bit architectures. Yes—it's been about twenty years since we had one of those in the house. There's still a late 2013 MBP running acceptably here, with UEFI and 64-bit support, currently pushing thirteen years old.

If you're a vintage computing enthusiast on a souped-up 486/DX9, fine—this project isn't for you. Otherwise, there are likely free computers offered thru your local craigstlist meeting the ~2010 specs listed above, sometimes even left on a sidewalk or trash-bins in larger cities. If you're willing to spend upwards of perhaps… ~$250? One could probably find something more formidable from the last decade.

ARM, R-V?

While it's possible we could support ARM64 or even RISC-V systems in the future, there are none of those laying around handy at the moment. Oh wait, there is an RPi 4 in a drawer nearby… Unsure how to get started on that however, and there's still a lot to do.

Operating Systems

Everything Linux seems to work, although on older images you may have to write some kernel parameters into a support file. We've done that work for loopback.cfg-compatibles and a few very popular other distros, but will need your help for the more obscure ones. See contributing below.

Windows, BSD?

These aren't able to work from a .iso loopback device. Some folks say that creating a partition and unpacking the .iso there works.

Update: Tried Windows 10 and the installer starts up, although with an error. See the customization section later on.

How does it work?

First, we'll help you create a removable drive with a layout like so:

╭───────┬──────────────────╮
│  ESP  │  Data Zone --->  │
╰───────┴──────────────────╯

What you see above is a disk diagram, cut in two (or more) parts. (Well, a unit of storage perhaps—they don't look like frisbees internally any longer.)

We can divide a storage device into sections according to function, each optimized for its needs. In this situation each section is called a "partition," and nearly always contains a "file-system" to catalog the files. These different filesystems have tradeoffs of their own, typically relating to both functionality and compatibility.

The first partition above is the "E.S.P.," a recursive acronym that expands to the "E.F.I" System Partition standard. It uses the venerable and simplistic FAT filesystem, that just about any operating system since the 80s can read. This is a standard for boot partitions that gives much more flexibility than the old-fashioned boot sector.

We'll help you create the partitions and install "GRUB" up in there. That is GNU GRUB, a slender operating system masquerading as a boot loader. Interesting in that we thought we done with it, moving several desktops to systemd-boot in recent years. UEFI machines generally don't need all that functionality any more, it comes standard. But the flexibility of ol' grub here is of great benefit to mounting and running .iso files for a "trusty boot key."

"High-way to the data zone…"

The second partition should be much larger and where you're gonna drop those phat eye-soes or "boot images", in other words. These might load a number of operating systems temporarily as well as for permanent installation. Supported binaries (think memtest86) and .efi files should work as well.

Currently, we are using the ext4 filesystem for the data partition. This is a tough one to decide on, as each of the main choices has significant drawbacks:

FAT32 - most compatible, but no files larger than 4GB, ruling out many .iso files.
Exfat - very compatible, though the Ubuntu family doesn't support booting from it.
UDF - widely compatible, though obscure and often forgotten. The Bluehat family doesn't support booting from it. No Apple support inside a partition.
Ext4 - compatible with all Linux (except debian netinst), permissions a minor annoyance on a removable drive. Not typically supported elsewhere.

It seemed that exfat was the best choice at first, but as mentioned the Ubuntu family doesn't support booting from it. Ext4 is a good choice for a Linux-centric user, but you may want to change it back to exfat if you'll be using it often with Windows machines or Macs. (See the "customization" section later on for instructions.)

(There is a third optional partition however, so one could pick their two favorites if necessary.)

Install

This project should be currently considered BETA quality. However, there's been a lot of work put in to make these scripts robust and avoid errors to the extent Bash and grub-script allows—including the use of shellcheck, defensive programming, extensive error checking and avoidance, and plenty of testing.

There still could be an issue or two lurking however—the code has been changing—no warranty expressed or implied. Recommend starting with a throwaway key, and reading everything the installer below tells you closely.

Get TBK:

Near the top right of the page ⤴, you'll see a git repo URL to clone from:

git clone ssh://git@codeberg.org/aol/trusty-boot-key.git
    # or
    git clone ssh://git@codeberg.org/aol/trusty-boot-key.git

No git? Well, next to that is a link with a [⋯] icon, click on that to download an archive from the menu, and then unpack it.

The scripts inside currently need these packages to run, it's best to install them beforehand:

adwaita-mono-fonts - perhaps adwaita-fonts
dosfstools
grub2 grub2-efi-x64-modules - may be just grub in your distro
parted
udevadm - from systemd so probably have it
udisks2
maybe exfatprogs ntfsprogs, etc for other filesystems.

It's also a good idea to put yourself in the disks group, so you don't have to run sudo for the update script:

sudo usermod -aG disk $USER
    # You can log out and back in to reload groups or run:
    exec su -l $USER

About Linux Device Names:

Linux removable disk device names have the format: /dev/sdXN

This means in the /dev/ device folder there's a file where the first part of the name is sd, which stood for "SCSI disks" in the old days. Then another lower-case letter for the particular drive (here X), and an optional partition number at the end (here N). i.e.:

/dev/sda    # whole device
    /dev/sda1   # first part

The GNOME Disks, GParted, or KDE partition manager are helpful to see what is connected to your system. The first one is useful while installing TBK, in that it reacts to changes happening live as you work, allowing a birds-eye view.

To install to the drive itself:

Beware! Setup-drive.sh will carve up and format your disk.

Note: The X below represents a removable drive, likely a or b, but potentially a later letter. Do not give a partition number at the end—this one wants the whole device:

cd ./trusty-boot-key  # this repo

    ./setup-drive.sh DEVICE  # aka /dev/sdX  - no number

Then follow instructions, which is basically to hit the "y" key and hit ENTER several times.

If successful, the setup-drive script will do the full grub-update steps mentioned below. So if you went through that, no need to do it again below. (Good idea to read however.)

Update GRUB and/or Menus

To update the config files there is another convenience script.

Note: This one wants to update the ESP, so do give a partition number at the end—which should be 1. X will be the same lower letter of the alphabet used above:

./update-tbk.sh DEVICE_NUM  # aka /dev/sdX1 - include part. num 1

An update will be needed if you've done a git pull for the latest version of TBK, updated the config file, or you've written some custom "grub script" yourself.

On rarer occasions you may want to rebuild and upgrade grub itself or the font it uses. Adding a module as a built-in requires this, and external module additions are conveniently installed as well:

./update-tbk.sh -g DEVICE_NUM  # aka /dev/sdaN

Use

When setup is done, drop some images into the os-images folder (of the second partition of the removable drive), pop it in the target, and restart! You may have to hit F12 at startup time or another key to select the boot drive. A common firmware boot-manager hot key—consult your system documentation.

Secure boot—not supported yet! Not sure that we will as it's a pain in the rear. Can you help?

Sorting the OS Images Menu

Despite excessive functionality in other areas, GRUB is only able to sort menu entries though some very hacked-up grub script, and just barely. We were able to implement a bubble sort, though there is no list or array type, so item-swap is done through string operations. Very low performance! Not been a problem so far with a dozen images or so. Twenty might be doable on a fast machine? Dunno, we'll see how that plays out. For this reason, sort can be turned off for now, see below.

If one moves the files off the drive and then returns them the operation typically will be performed in alphabetical order, meaning they'll be sorted on disk. If not, try rsync. This should speed up the sorting performance as well. Better yet, copy them manually in the order of use. e.g. most used image copied first, second second etc. Then turn off sorting.

Customization

You can easily place custom entries into the menu by placing grub-script into a file at the following location:

$prefix/custom.cfg

Prefix is grub-speak for the main grub2 folder. In this case, at the root of the ESP partition of your removable drive. The first and smaller partition.

If this file is found, the contents inside will be evaluated. Make sure it is syntactically correct or it will break things afterward. Starting very simply and building from there is the best way.

_config.sh

One can also edit the _config.sh file in the repo when ready to get serious with customization. The default localization for example, (currently limited to a few western languages due to font restrictions).

You can also add additional grub modules, change labels and the theme, the size of the first partition, and even the filesystem of the second (or third!) partition, among other things.

Themes

There are three levels of quality. A VGA-style text-mode interface is available in a pinch with the Escape key pressed at early boot time. Called '' (none) in _config.sh.

We're using a simple theme by default, which has HD resolution, a unicode font, and some color.

The graphical version included is a lightly-modified Slaze theme by adi1090x/uGRUB. Choose in _config.sh and remember to run update with the -g option once to build the grub theme modules and install them:

./update-tbk.sh -g /dev/sdX1

Themes then need to be copied to /grub2/themes/$THEME_NAME folders. The theme file currently must be named theme.txt.

Windows

Not currently working. It loads but install fails with a "Needs media driver error."

What we tried…

Condolences—good tech, unethical management, and we understand some folks are trapped. The .iso is a no-go however, so here's how to (not-quite) get it working with TBK.

Now that you understand _config.sh and custom.cfg, you'll want to edit _config and choose a filesystem or two, depending if you are a dabbler or a devotee…

Dabbler:

Recommend making a third partition. Fat32 or exfat is probably easiest, we also tried NTFS with compression enabled.
Find VOL2_END and change it to 80%, $SIZE - 10GB, or whatever leaves enough space for the .iso contents and your needs. Select the filesystems.
Let setup-drive.sh carve up and format the disk.
Unpack the .iso into the third partition. (7zip can handle as well if your mounter is not working.)
Copy ./grub/examples/windows.cfg to grub/custom.cfg, edit/augment as desired.
Run ./update-tbk.sh DEVICE_NUM, use -g also only if you've changed the module list/font after setup.
Boot and load the TBK menu. Load ntfs and/or ntfscomp from the Utils menu first if need be.

Devotee:

Consider one big second partition with a "native" filesystem.

(Windows may not install from a folder.)
Move the ntfs modules to the _GRUB_BUILTINS list as you will likely be using them often, to avoid having to load manually every time.

Was not able to get this to work and pointed to: https://askubuntu.com/questions/1227291/grub-boot-from-windows-iso/1525482

Might work for you.

FreeBSD

We understand the process is quite likely similar to the Windows section above, substituting UFS2 or ZFS for NTFS. Haven't yet tried it. Let us know if it works.

Help and Utils menus

There's a help menu that has a few useful entries for someone not that familiar with GRUB or PC technology in general, but is interested in learning.

Support modules, such as a serial console or additional filesystem support can be loaded as well, all from the Utilities and Drivers menu.

Troubleshooting

By default this starts up in graphics mode at 1920x1080 resolution with and a medium-large font. Which should be the bare minimum these days. However, maybe you're in a pinch, hacking on a machine in the closet with a relic of a monitor and that's not gonna work.

Well, at startup up you can hold down the -shift- key to skip the graphics term and use the standard monochrome (GOP? VGA?) console instead. (One sacrifice we make to the ancients.)

Update: that functionality with the keystatus --shift key doesn't seem to work on our EDK2 machine. So trying sleep, and you'll need to hit the Escape key instead, quickly at first boot to bypass graphics mode!

Graphics modes

The videoinfo command might be your friend in this case, it will list supported modes and you can go back down to a fallback resolution with the following incantation:

set gfxmode="1024x768x32,auto"

Which was a fancy resolution in the early years. ;-) Now that I think of it, staying in the monochrome console probably makes more sense in that case. But, if you've read this far then you've learned how to handle other situations, like if the text is too big, or way too small on your 8k!

Tested

This has been tested installing from:

Fedora 44
Arch 26.07

So far. Doesn't use many fancy features so should run in older versions, but we'll see.

With these images, that have loaded successfully:

.iso files
.efi files
memtest86 binaries that use the linux boot protocol.

Recommended Images

Arch - Up to date desktop, rolling
Fedora - Up to date desktop, every 6-month release
Mint - Long-term support (LTS) desktop, 2-year release
Tails - Anonymity
Kali - Forensics, pentesting
Memtest86 - RAM tester
UEFI Shell - The shellx64.efi works.
Mosby - looked interesting.

For memtest you can download the "Binary Files" link, unpack the archive and copy the *_x86_64 file to the /os-images folder on the data partition of the removable drive.

Inspiration and Thanks

Also cribbed a number of grub scripting techniques from these similar projects:

Not to mention looking at the grub.cfg of the many ISO images themselves.

Dev Guide

Contributing Support Files

Need support for your favorite distro? Please make a merge request with your menuentry stanza in a name.cfg file under the support folder. The script filename must match the prefix of the boot image filename, up until the first dash or period -., with a .cfg extension at the end.

I suggest getting started by looking in the last two repos linked above for example boot commands and arguments for your product of choice. Also, mount your .iso file of interest as a loopback drive or open with an archiver. Looking around the folders will give quite a bit of information, such as paths to the kernel etc.

Then refactor the script using the guidelines below.

Repo Tour

In addition to the two main scripts mentioned already, additional descriptions follow:

Root folder - besides setup and update, it also includes these Bash support scripts:
- setup-drive.sh - carves up the flash drive, destroyer of worlds.
- update-tbk.sh - updates the settings and menus of GRUB, optionally GRUB itself and/or its fonts.
- generate-cfg.sh - builds the grub/options.cfg using a template.
- _config.sh - numerous customization variables are here
- _error_checks.sh - looks for issues before allowing setup- and update- to proceed.
- _lib.sh - clean up and output routines.
docs - contains several text files, explaining various topics.
grub - the folder where the main .cfg files are located.
- grub.cfg - main entry point. Loads the rest, some at startup, others on demand.
- lib.cfg - library functions, init graphics, calendar, sort, etc.
- options.cfg - file to hold settings received from Bash.
- search.cfg - the main loop that looks for files under os-images
- utils.cfg - where the utility submenu entries are
- help.cfg - where the help entries are
grub/support - Where we place .cfg files that either directly apply to an .iso file, or if they apply to a group they can be named with an underscore at the front.
grub/examples Experiments from before we learned about loopback.cfg, good coding examples of grub-script.

Guidelines

Use defensive scripting (test -f, etc), though keep in mind we've already validated the existence of the image file, or we wouldn't have made it to your script.
Use existing files for style guidelines, Remove redundant code.
A comment on what obscure boot parameters do and when they are required is helpful. Since you're validating the entry, it is a good time to experiment.
Use plenty of whitespace—we're not running out on the these short files. Four space indents, and single blank lines between significant, dense, or commands of differing functionality.

Long boot options are probably better indented on their own lines, using a backslash to continue the line is supported in grub script.
If a number of complicated parameter combos are recognized, you may want to create a submenu for several entries to be chosen.
Use a unicode character in front of the entry title as an icon.

Currently using ◎ for recognized isos, ⟳ for loopback.cfg support, ⌁ for executable binaries like .efi, and ⏵ for sub-menus. Ⓔ is given for yet unrecognized files that need to use the "e" key for the script to be written to successfully boot.

If there is a cool looking character that matches even better that's fine as well, however note that the font is currently limited to points <= 0xFFFF, and does not support everything under that, which eliminates most Asian writing systems, emojis, and more. #TODO
Use the mkloop function (search.cfg) to make your loop device. When used, and you 1) return from an image menu, or 2) there is an error and you are thrown back to the main menu, the next choice will avoid the "device already exists!" error.

Variables

In your script, you'll have the following variables at your disposal:

$P1 - Grub-style path to the first partition of the removable drive.
$P2 - Grub-style path to the second partition of the removable drive.
$root - Grub-style path to the ESP of the removable drive.
$prefix - the folder typically at/called $root/grub2
$full_path - Full grub-style path to the current image file, including (drive,) notation.
$path - Unix-style /absolute/path to the file, without (drive,) notation.
$filename - The whole filename, without path.
$basename - The alpha-numeric front of the filename, up to the first dash or period -.. Would call it a prefix, but that name is taken. :-/

Standard?

Wouldn't it be great if there were a standard for booting these things and we did not have to make a custom loader script for almost every one?

If anyone knows anything about that or would like to start one, let's hear it. Oh—well:

Loopback.cfg

Looking thru the eye-sos, we found several references to a loopback.cfg and finally an URL. That wiki seems to be down, but did dig the page up from the wayback: loopback.cfg

The loopback.cfg file must be found at the path /boot/grub/loopback.cfg.

That is the case, except for Blue Hat distros which use grub2. :-/ Ok, found a way around that. Support could be better.

Trustworthy Technology

That's all folks! Learn more about this project, and what inspired it, at trustworthy.technology.

Kollect: The Native KDE Link Collector I Built for Myself

Tue, 14 Jul 2026 22:08:58 +0000

I have a very predictable failure mode when reading the web. I open an interesting article, decide I will come back to it later, and leave the tab open. Then I do the same thing another twenty times. The tabs stop being a reading list and become archaeological layers.

Browser bookmarks never fixed this for me. They are good at preserving a URL, but a URL and a title are not enough to answer the question I actually have two weeks later: why did I save this? Read-it-later services answer more of that question, but most of them turn a small personal collection into another account, another cloud database, and often another web application.

So I built Kollect.

Kollect is a small native KDE Plasma 6 link collector. I paste a URL, and it immediately files the link into the current ISO week. In the background it fetches the page and asks an OpenRouter model to extract a useful title, publication date, author, tags, a primary topic, and a short summary. The result is a collection I can skim later instead of a graveyard of titles I no longer recognise.

This is not a product announcement. I have not published the application or its source, and there is no download link hiding at the end of this article. It is a personal 0.1 application built around my own workflow. But the design came together cleanly enough that it is worth documenting, especially because it combines several things I care about: a genuinely native Linux desktop, boring local files, optional self-hosting, secrets in KWallet, and distribution-native packaging.

Table of Contents
What using it looks like
A native Plasma application, on purpose
Local-first means ordinary files
Enrichment without turning the app into a chatbot
Secrets belong in KWallet
One interface, two storage backends
The optional server
Packaged as a Fedora application, not a build directory
Things I deliberately did not build
The part I like most

What using it looks like

The main interaction is intentionally uneventful. Paste or type a link into the field and press Enter. That is it.

There are a few other paths because the best capture tool is the one that does not interrupt what I am doing:

Ctrl+Shift+V adds whatever URL is currently on the clipboard.
A URL can be dragged and dropped anywhere onto the window.
kollect https://example.net/article adds a URL passed on the command line.
The desktop file registers Kollect as an HTTP and HTTPSURL handler, so it can receive links from other desktop applications.

The entry appears immediately with a pending indicator. Metadata fetching is asynchronous, so a slow website or API call does not freeze the interface. When enrichment completes, the raw URL turns into a recognisable headline with a topic and tags. If fetching fails, the entry remains in the collection, changes to an error state, and can be retried from the context menu.

Links are grouped into folders such as 2026w29. The current week is expanded by default, older weeks are collapsed, and both weeks and entries are sorted newest first. Clicking an entry opens the detail page shown in the screenshot: the original URL, author, publication date, topic, tags, collection time, and summary. From there I can open the page, copy its URL, re-fetch metadata, or delete the entry.

That last part matters. Kollect does not try to become a browser. It remembers and organises links, then hands them back to the browser when I actually want to read them.

A native Plasma application, on purpose

Kollect is not an Electron application, a local web server with a tray icon, or a Python GUI wearing a vaguely native stylesheet. The desktop client is C++20 with Qt 6, KDE Frameworks 6, QML, and Kirigami.

The executable owns the application logic and exposes one KollectApp object to QML. The interface is split into three small QML files:

Main.qml contains the application window, global drawer, capture field, weekly list, drag-and-drop area, and delete confirmation.
DetailPage.qml renders one selected entry and its actions.
SettingsDialog.qml configures OpenRouter and the optional sync server.

Kirigami provides the application structure, actions, responsive pages, form layout, inline messages, passive notifications, spacing, and icon integration. Qt Quick Controls uses org.kde.desktop, so widgets follow the active Plasma style rather than drawing a separate visual universe inside the window. The application uses the system icon theme and standard KDE shortcuts such as the Preferences, Close, and Quit keys.

This buys more than appearance. The global drawer behaves like a KDE global drawer. Actions can move between the toolbar and overflow areas as space changes. Labels are selectable where that is useful. Notifications use the expected Plasma presentation. The result feels at home on my desktop because it is built out of the same primitives as the rest of the desktop.

The C++ side follows the usual Qt model/view boundary. LinkModel is a QAbstractListModel which presents both week headers and entries to the QMLListView. Roles expose the title, URL, topic, tags, timestamp, state, and summary. A store emits entryAdded, entryUpdated, entryRemoved, or reloaded, the model rebuilds or updates the relevant row, and QML reacts. The view does not need to know whether that store is a directory on disk or an HTTPAPI.

That separation became the key to the entire design.

Local-first means ordinary files

The default backend is LocalLinkStore, and it stores the collection here:

~/.local/share/kollect/
├── 2026w28/
│   └── example-org-an-interesting-article.toml
└── 2026w29/
    ├── vermaden-wordpress-com-gitlab-on-freebsd.toml
    └── lwn-net-articles.toml

There is one directory per ISO week and one TOML document per link. A real entry looks roughly like this:

url="https://vermaden.wordpress.com/2026/07/09/gitlab-on-freebsd/"added_at="2026-07-14T16:38:21"status="done"headline="GitLab on FreeBSD"date="2026-07-09"tags=["freebsd","gitlab","server","git","postgresql","nginx"]topic="FreeBSD"author="vermaden"summary="A step-by-step guide to installing and configuring a self-hosted GitLab server on FreeBSD. The setup uses a dedicated bhyve VM and a PostgreSQL, Redis, Nginx, and GitLab-CE backend stack."

This is deliberately not a single opaque database. I can inspect the files with less, search them with rg, copy one entry, synchronise the directory with any file tool, put it in a private Git repository, or write a conversion script ten years from now without first reconstructing an abandoned application’s database schema.

The file name is derived from the host and the last meaningful URL path segment, normalised to a lowercase slug and capped at 80 characters. If two links in a week produce the same slug, Kollect adds -2, -3, and so on. Duplicate URLs are rejected across the whole collection before a file is created.

Writes go through QSaveFile. That gives the local backend an important property for almost no complexity: a new document is written and committed atomically instead of truncating the existing file in place. A crash during a metadata update should not leave half a TOML document behind. Deleting the final entry in a week also removes the now-empty week directory.

The state machine is tiny and visible in the data:

pending  ->  done
   |
   +----> error  ->  pending (manual re-fetch)

The URL is persisted in pending state before any network request begins. Metadata is helpful, but it is not allowed to decide whether the link itself survives.

Enrichment without turning the app into a chatbot

The AI part of Kollect is intentionally narrow. There is no chat panel and no prompt box. A model is used as a structured metadata extractor because web pages are inconsistent and because a useful two-to-four sentence reminder is hard to derive from <meta> tags alone.

For each queued entry, Kollect performs two network operations:

It fetches the page with Qt’s network stack, follows redirects only when they do not downgrade security (Qt’s NoLessSafeRedirectPolicy), and reads at most 2 MiB. A 30-second timeout covers both this request and the OpenRouter call that follows.
It removes scripts, styles, SVG, templates, comments, and HTML markup, decodes entities with QTextDocument, normalises whitespace, and keeps at most 14,000 characters of readable text.

That text and the URL go to OpenRouter’s chat-completions endpoint. The request demands one JSON object with exactly the fields Kollect understands: headline, date, tags, topic, author, and summary. In production I use the Chinese MiniMax M3 model under the OpenRouter identifier minimax/minimax-m3. It is more than capable enough for website summaries and, as of July 14, 2026, costs $0.30 per million input tokens and $1.20 per million output tokens. The model is a normal setting and can be replaced without rebuilding the application. Kollect also requests JSON response formatting and defensively extracts the outermost { ... } span because models occasionally wrap JSON in a Markdown fence despite being told not to.

Jobs run through a simple in-process queue, one at a time. That avoids a burst of page downloads and API calls when I paste several links in quick succession. It also makes error handling predictable: finish or fail one entry, then schedule the next job on the Qt event loop.

There is an obvious privacy boundary here which should not be hand-waved away. Local storage does not mean offline processing. Enrichment sends the link and extracted page text to OpenRouter and whichever model provider handles the selected model. Anyone using this design should make that decision consciously and should not feed it private pages or sensitive intranet URLs. Without an API key, the link is still collected, but enrichment ends in an error state.

Secrets belong in KWallet

Kollect needs two credentials: the OpenRouter API key and, when server mode is enabled, a bearer token. On Plasma, both belong in KWallet.

The client talks directly to org.kde.kwalletd6 over D-Bus, opens the user’s network wallet asynchronously since that call may display an unlock dialog, and stores passwords under a dedicated Kollect folder. Loading is additionally deferred until the Qt event loop is running, so no secret can be reported before the rest of the application has connected to the corresponding signals. Metadata jobs and remote requests wait until the corresponding secret has been resolved instead of racing application startup.

Non-secret settings live in ~/.config/kollectrc through KConfig: model name, server URL, username, and whether the remote backend is enabled. An older API key found in that config is migrated into KWallet the first time a wallet becomes available and then removed from the config file.

There are pragmatic fallbacks. If KWallet is unavailable, secrets can be stored in the config file, and the OpenRouter key can come from OPENROUTER_API_KEY. That is useful in unusual sessions and during development, but KWallet is the intended path on a normal Plasma desktop.

One interface, two storage backends

I originally needed Kollect on one machine, so local TOML was the right starting point. Then came the predictable next requirement: the same collection on more than one workstation.

I did not want to destroy the local design by making the server mandatory. Instead, LinkStore defines the operations the rest of the application needs, while two implementations provide persistence:

QML  <->  LinkModel  <->  KollectApp
                \             /
                 \           /
                  LinkStore
                 /         \
        LocalLinkStore   RemoteLinkStore
           TOML files       JSON/HTTP

At startup, KollectApp reads the configuration and constructs exactly one backend. Everything above it stays the same. Adding an entry, updating metadata, deleting it, detecting duplicates, sorting weeks, and feeding the view all use the shared abstraction.

The remote backend is deliberately small. Once a token is available, it loads the user’s complete collection with GET /entries. An entry update is a full-document PUT to /entries/{week}/{entry_id}, and deletion uses the corresponding DELETE. The JSON representation carries the same fields as the TOML representation, so switching storage does not change what an entry means.

Server mode also has a one-time Upload Local Collection action. It reads the existing TOML backend, skips URLs or IDs already present remotely, and pushes the rest. Local files are left untouched.

It is important to call this what it is: an alternative remote store, not bidirectional offline synchronisation. In server mode the server is the source of truth and the client needs a network connection. There is no conflict-resolution algorithm, offline write journal, or background merge between TOML and SQLite. Building those features would be possible, but they would turn a clean storage switch into a distributed-systems project. For my use, an honest online backend is the better tradeoff.

The optional server

The server is a separate, compact Python application built with FastAPI, SQLAlchemy 2, Pydantic, and SQLite. Its complete public surface is five operations:

Method	Path	Purpose
`POST`	`/auth/login`	Exchange a username and password for a bearer token
`GET`	`/entries`	Return the authenticated user’s collection
`PUT`	`/entries/{week}/{entry_id}`	Create or replace a complete entry
`DELETE`	`/entries/{week}/{entry_id}`	Delete one entry
`GET`	`/healthz`	Liveness check without authentication

User passwords are hashed with Argon2. Login creates a random 32-byte URL-safe token, returns it once, and stores only its SHA-256 hash in the database. A leaked SQLite file therefore does not directly reveal reusable bearer tokens. Every entry is keyed by user, week, and entry ID, and a uniqueness constraint prevents the same user from collecting one URL under multiple IDs. Different users are isolated and may independently save the same URL.

Administration is intentionally CLI-only. The server package provides commands to create users, change passwords, and list accounts. I do not need an admin web interface for a private service with a handful of users, and not building one means there is no admin web interface to secure.

The API tests cover the parts that would hurt if they broke: failed login, missing and invalid tokens, the full CRUD round trip, duplicate URL conflicts, and isolation between two users.

Deployment is equally unsurprising. A small python:3.12-slim image installs the server package, runs as UID 1000, and keeps SQLite under /data. A rootless Podman Quadlet binds it to 127.0.0.1:8000, stores data in a named volume, restarts on failure, and can start with the user’s systemd session. If I expose it beyond localhost, it goes behind a TLS-terminating reverse proxy because the bearer token is an HTTP header, not magic.

Packaged as a Fedora application, not a build directory

I run Fedora on my Plasma desktops, so Kollect is packaged as an RPM. This sounds like a finishing detail, but it changes how an application feels in daily use. A program launched out of ~/src/project/build/ is still a project. A program installed through RPM, visible in the application launcher, tracked by the package database, and removable cleanly is part of the system.

The package uses Fedora’s CMake macros and declares the actual build stack:

CMake, GCC C++, and Extra CMake Modules
Qt 6 base and declarative development packages
KDE Frameworks 6 KConfig, KCoreAddons, and KI18n development packages
Kirigami and qqc2-desktop-style as explicit QML runtime requirements

That last point is easy to miss. RPM dependency generation sees linked ELF libraries rather well, but QML imports loaded at runtime are not always inferred. Declaring Kirigami and the desktop Qt Quick style explicitly prevents the classic result where the package installs successfully and the application immediately fails because a QML module is absent.

The RPM installs the kollect executable and org.kde.kollect.desktop, then validates the desktop file during %check. The build helper derives the version from the spec, creates a clean source archive from the current Git HEAD, and hands that tarball to rpmbuild. The package is therefore reproducible from committed source rather than whatever untracked experiment happens to be lying in the worktree.

For development, the underlying build remains conventional:

cmake-Bbuild-DCMAKE_BUILD_TYPE=RelWithDebInfo
cmake--buildbuild-j"$(nproc)"
./build/kollect

For daily use, I install the RPM. KDE gets a proper desktop entry, %uURL handling, the standard bookmarks icon from the current icon theme, and a binary under the normal system prefix.

Things I deliberately did not build

Small applications stay pleasant when they are allowed to have boundaries. Kollect 0.1 does not have browser extensions, full-text article archiving, reading progress, a mobile client, collaborative lists, server-side metadata workers, or magical offline conflict resolution.

It also does not currently extract metadata locally. The model call is useful, but it introduces cost, network dependence, and the privacy boundary described above. A future local model or deterministic extractor could fit behind the existing MetadataFetcher interface, but I would only add it when it improves the actual workflow rather than the feature list.

The server is optional because a server should remain optional for a link collector. The TOML backend is not a demo mode that exists until a user signs up. It is the simplest complete version of the application and the one with the best long-term ownership story. Remote storage solves a real multi-machine problem, but it is allowed to remain an add-on.

The part I like most

Kollect is not technically enormous. That is exactly why I like it.

It takes one recurring irritation, too many tabs and too little context, and gives it a narrow desktop-shaped solution. The interface is native to Plasma. The default data format is readable without Kollect. Writes are atomic. Secrets use the desktop wallet. The AI model has one constrained job. The remote service can be self-hosted, but the application does not require it. Fedora gets a real package rather than a curl | bash installer.

Most importantly, I know where the data is and what every moving part does. If I stop maintaining the client tomorrow, the local collection remains a directory of TOML files. If I stop running the server, SQLite remains a documented database full of ordinary rows. There is no export button I need to trust and no service whose business model has to survive longer than my bookmarks.

That is the kind of personal software I want more of: small, native, inspectable, and built to solve the problem in front of me without trying to own everything around it.

Big Blue thinks small, again, with POWER tower

Tue, 14 Jul 2026 18:05:25 +0000

IBM has again teased small hardware, this time in the form of an update for its smallest POWER server.

The model S1112, teased Tuesday in a customer announcement, is a 2U, single-socket POWER11 server IBM offers in rack-mountable and what the company calls “Tower/deskside configuration.”

The rackable model can handle a ten-core POWER processor. The Tower/deskside form factor machine must make do with a four-core engine

REG AD

IBM seems to have two roles in mind for the new machines: edge deployments and standalone use by those who are taking their first strides into using the last remaining proprietary minicomputer ecosystem.

REG AD

One is edge deployments. The other is as an entry-level box, with the description of the tower unit suggesting its very existence means “even the smallest customers” can use it as an on-ramp to more POWER implementations.

News of the S1112 marks the second time in a week that IBM has gone low with modest hardware. Last week Big Blue teased the z 17 ME2, a rackable mainframe that it said completed its range by offering a smaller and cheaper piece of hardware.

MORE CONTEXT

The twin launches continue IBM’s policy of creating smaller versions of its enterprise hardware, albeit well after launch of big iron: the first POWER 11 boxes landed in July 2025 and the first z17 series mainframes debuted in April of the same year.

The S1112 includes a quartet of DIMM slots and can handle up to 512GB of DDR5 memory. The box runs IBM i, AIX, and Linux – or all three because it supports IBM’s PowerVM virtualization tools.

In an almost certain non-coincidence, Big Blue on Tuesday also announced upgrades for PowerVM including improved automation and support for the S1112.

Big Blue has also looked after users of bigger POWER fleets, by expanding the number of Spyre accelerators – IBM’s neural processing units – that POWER servers can support from eight to twelve. IBM pitches POWER as a capable AI platform, so allowing it to use more accelerators can’t hurt.

IBM plans to start selling most of the kit described above on July 24, although customers who crave the S1112 to deploy in Taiwan will have to wait until September. 15. Would-be buyers in South Africa, India, and China must wait longer still, until December 11. ®

Meetily: Privacy-First AI Meeting Assistant for Windows, macOS & Linux

Tue, 14 Jul 2026 16:24:25 +0000

Meetily is a free and open-source AI meeting assistant that records, transcribes, and summarizes meetings completely on your own device. Its not like other cloud-based meeting assistants, It keeps your conversations private by processing everything locally while supporting multiple AI providers for intelligent meeting summaries.

OmniRoute: Connect All AI Models & Providers Through One API

Tue, 14 Jul 2026 16:24:25 +0000

OmniRoute makes it easy to connect your favorite AI tools to hundreds of AI providers through a single endpoint. With automatic provider switching, smart routing, token optimization, and support for popular coding assistants, it helps you build AI applications without worrying about rate limits or changing APIs.

A highly available WireGuard VPN setup

Tue, 14 Jul 2026 14:10:51 +0000

WireGuard is a communication protocol and free and open-source software that implements encrypted virtual private networks (VPNs), and was designed with the goals of ease of use, high speed performance, and low attack surface.

My Journey to WireGuard

Tinc Logo.

I’ve been using it in my home lab setup since about 2020. When, in the end of 2021, it was finally merged into the Linux mainline with release 5.9, I started to replace my former Tinc-VPN setup with it. Tinc-VPN is another great open source VPN solution. Unfortunately, its development has stalled over the last years which motivated me to look for alternatives. In contrast to WireGuard, Tinc runs as a user-space daemon and uses tun / tap devices which adds a significant processing overhead. Like WireGuard, it is also using UDP for tunneling data, but falls back to TCP in situations where direct datagram connectivity is not feasible. Another big advantage of Tinc is its ability to form a mesh of nodes and to route traffic within it when direct P2P connections are not possible due to firewall restrictions. At the same time, this mesh is also used for facilitating direct connections by signaling endpoint addresses of NATed hosts.

Tinc's mesh capability.

This mesh functionality made Tinc quite robust against the failure of single nodes as usually we could route traffic via other paths.

Highly Available WireGuard server setup

To counteract this shortcoming, this blog post will present a highly available WireGuard setup using the Virtual Router Redundancy Protocol (VRRP) as implemented by the keepalived daemon.

That said, it is worth noting that this setup does will not bring back some of the beloved features of Tinc. Both meshing, the peer and and endpoint discovery features of Tinc are currently and will never be supported by WireGuard. Jason A. Donenfeld the author of WireGuard focused the design of WireGuard on simplicity, performance and auditability. Hence advanced features like the ones mentioned will only be available to WireGuard by additional agents / daemons which control and configure WireGuard for you. Examples for such are Tailscale, Netmaker and Netbird.

The setup presented in this post is a so called active / standby configuration consisting of two almost equal configured Linux servers running both WireGuard and the keepalived daemon. As the name suggest only one of those two servers will by actively handling WireGuard tunneling traffic while the other one stands by for the event of a failure or maintenance of the active node.

VRRP Wireguard Setup.

Requirements

Before get started some requirements for the setup:

2 Servers running Linux 5.9 or newer.
A working Wireguard configuration.
A local L2 network segment two which both servers are connected.
Upstream connectivity without NATing via gateway connected to the network segment (usually provided by your internet or hosting provider).
An unused address to be used as Virtual IP (VIP) which roamed between the two servers by VRRP.

An important point is here the assumption that we are running both servers in the same switched network segment as this is a requirement for VRRP. We are also assuming that the upstream gateway performs no NATing. This guide covers only IPv6 addressing. However all steps can be also adapted or repeated for a dual stack or IPv4-only setup.

Detailed steps

Here are some of the specifics for my setup which need to be adapted by you:

Server Key (same use by both servers)
- Private: YIEDx+A2ONo5+uv3mrk/p7ileL3T5QQ8hleQK0IYEEI=
- Public:XGubrkGtuECdvoykKeUiNMigk2onfLCPfEo9Im+vmx8=
Peer Key (In this example we only have a single peer)
- Private:OIbpWVIVVBOtWfwkmXkFRN7Q/jBdfYtsGt7j97aHx1Q=
- Public:3NGl6gTOGs6ai0RE91VmVFgF+N4gw1EBG11KOeiKJAg=
Public Server Subnet: 2001:DB8:1::/64
- Gateway: 2001:DB8:1::1
- Virtual IP: 2001:DB8:1::2
- Server A: 2001:DB8:1:::3
- Server B: 2001:DB8:1::4
WireGuard Tunnel Subnet: 2001:DB8:2::1/64
- Server: 2001:DB8:2::1 (same used by both servers)
- Peer: 2001:DB8:2::2
Interface names
- Wireguard: wg1
- Upstream: eno1

Prepare servers
We start of preparing the two servers by installing WireGuard and keepalived:
```
sudoaptinstallkeepalivedwireguard-toolsiproute2
```
Next we configure a WireGuard interface on both servers using exactly the same configuration file at /etc/wireguard/wg1.conf:
```
[Interface]

Address= 2001:DB8:2::1/64

PrivateKey= YIEDx+A2ONo5+uv3mrk/p7ileL3T5QQ8hleQK0IYEEI=

ListenPort= 51800



[Peer]

PublicKey= 3NGl6gTOGs6ai0RE91VmVFgF+N4gw1EBG11KOeiKJAg=

AllowedIPs= 2001:DB8:2::2/128

PersistentKeepalive= 25
```
Similarly, a reciprocal configuration file is needed on the client side which skip here for brevity. Before proceeding, we activate the interface on both servers:
```
systemctlenable--nowwg-quick@wg1



wgshowwg1# Check if interface is up
```

Configuring Keepalived

Create a configuration file for keepalived at /etc/keepalived/keepalived.conf

global_defs {

enable_script_security

script_user root

}



# Check if the server the WireGuard interface configured

vrrp_script check_wg {

script "/usr/bin/wg show wg1"

user root

}



vrrp_instance wg_v6 {

interface eno1

virtual_router_id 52

notify /usr/local/bin/keepalived-wg.sh



state BACKUP # use BACKUP for Server B

priority 99 # use 100 for Server B



virtual_ipaddress {

2001:DB8:1::1/64

}



track_script {

check_wg

}

}

Create a notification script for keepalived at /usr/local/bin/keepalived-wg.sh

#!/usr/bin/env bash



TYPE=$1

NAME=$2

STATE=$3

PRIO=$4



WGIF=wg1



case${STATE}in

MASTER)

iplinksetupdev${WGIF}

;;



BACKUP|FAULT|STOP|DELETED)

iplinksetdowndev${WGIF}

;;



*)

echo"unknown state"

exit1

esac

Now start the keepalived daemon:

chmod+x/usr/local/bin/keepalived-wg.sh

systemctlenable--nowkeepalived

Testing the fail over
In our configuration, Server A has a higher VRRP priority and as such will be preferred if both servers are healthy. To test our setup, we simply bring down the WireGuard interface on Server A and observe how the VIP gets moved to Server B. From the WireGuard peers perspective not much changes. In fact no connections will be dropped during the fail-over. Internally, the clients WireGuard interface renegotiate the handshake. However, that step is actually not observable by the user.
Run the following commands on Server A while alongside test the connectivity from the client side through the tunnel via ping -i0.2 2001:DB8:2::1:
```
# Check that keepalived has moved the VIP to interface eno1

ipaddrshowdeveno1



# Bring down the Wireguard interface

wg-quickdownwg1



# Keepalived should now have moved the VIP to Server B

ipaddrshowdeveno1
```

Going further

In my personal network, I operate a Interior Gateway Protocol (IGP) to dynamically route traffic within and also towards other networks. Common IGPs are OSPF, ISIS or BGP. In my specific case, both Servers A & B run the Bird2 routing daemon with interior and exterior BGP sessions.

So how does the WireGuard HA setup interoperates with my interior routing? Quite well actually. As my notify script (keepalive-wg.sh) will automatically bring up / down the interface, the routes attached to the interface will be picked up by Bird’s direct protocol.

I am also planning to extend my WireGuard agent cunīcu (/cunicu/cunicu ) to support the synchronization of WireGuard interface configurations between multiple servers.

Background

Surprisingly, the setup works by using Keepalived and does not require any iptables or nftables magic to rewrite source IP addresses. I’ve seen some people mentioning that SNAT / DNAT would be required to convince WireGuard to use the virtual IP instead of the server addresses. However, in my experience this was not necessary.

Another concern has been that the backup Wireguard interface still might attempt to establish a handshake with its peers. This would quite certainly interfere with the handshakes originated by the current master server. However, also this has not been proven to be the case. I assume the fact that our notify script brings down the WireGuard interface on the backup server causes them to cease all communication with its peers.

Gaining Root Access on Netgear Nighthawk Mobile 5G/LTE Routers

Tue, 14 Jul 2026 14:10:51 +0000

This blog posts covers the required steps to gain root access via Telnet on Netgear Nighthawk Mobile 5G/LTE Routers. Its the first post in a small series covering my experiences playing around with this device.

Last month I obtained one of Netgear’s latest mobile 5G routers, the Netgear Nighthawk M5 (model MR5200-100EUS) . Being one of the most expensive consumer 5G routers, I was lucky to get a fairly good second hand deal from eBay.

Netgear Nighthawk M5 mobile 5G/LTE Router.

The router is powered by Qualcomm’s® Snapdragon™ X55 5G Modem-RF system. Looking closer at the internals of the device by checking the FCC filing for the closely related American model MR5100, we can see that the system consists of a Qualcomm SDX55 chipset which combines both the mobile baseband and application processors.

Gaining Root Access

Gaining root access to the device is actually fairly simple in comparison to rooting modern Android-based devices. The router exposes an open TCP port providing an AT command interface. However, this port is only accessible via a tethered USB connection, not via Wifi.

Using this AT command interface, we can interact with the modem, unlock an extended command set which allows us enable a Telnet daemon.

Detailed Steps

Install the Sierra Wireless debug tools from bkerler (/bkerler/edl )
```
sudoaptinstallpython3git

gitclonehttps://github.com/bkerler/edl.git

cdedl

sudopythonsetup.pyinstall
```
(More detailed installation instructions are covered in the README file of the repo.)
Connect your machine via USB-C to the Netgear router
Make sure to disconnect from the Netgear Wifi
Open a terminal an connect to the AT command interface via netcat (nc)
(Make sure not to miss the -c option as it will the enable nc to use the proper CRLF line-endings which are required for the AT interface).
```
nc-c192.168.1.15510
```
Once connected to the AT command interface, you need to request a unlock challenge code by sending
```
AT!OPENLOCK?
```
The previous command will return a challenge code which we use to generate a corresponding response code via the previously installed sierrakeygen.py tool:
```
sierrakeygen.py-l<replace_with_challenge_code>-dSDX55
```
The previous command will print out another AT+OPENLOCK command which you need to copy verbatim back to your AT command session.
Run the following AT commands to enable the Telnet daemon
```
AT!TELEN=1

AT!CUSTOM="RDENABLE", 1

AT!CUSTOM="TELNETENABLE", 1
```
You can now close the AT command session by pressing Ctrl+C.
Power-cycle the Netgear Router to start the Telnet daemon
Voila, you can now telnet into the device via both the tethered USB-C cable or Wifi.
```
nc-c172.23.156.12923

��������

mdm1623sdxprairie

/# uname -a

uname-a

Linuxsdxprairie4.14.117#1 PREEMPT Thu Aug 19 23:42:26 UTC 2021 armv7l GNU/Linux
```
Disclaimer: Please be aware that the device security is now breached as all devices connected to the Wifi or USB can gain root access to the device. The root Telnet login requires no password.

Next steps

Before proceeding we should make sure that we can bring the device back to a secure state by replacing the Telnet by an Secure Shell (SSH) daemon. In one of the next posts of this series, I will be building a statically linked version of the Dropbear SSH server to replace Telnet.

Before continuing my reverse engineering efforts on the device, I would like to ensure that I will not brick the router while doing so by dumping the firmware and extract all the details from it. This will allow us to hopefully restore the device by flashing the original firmware. Maybe we will be able to run OpenWRT on it.

I have also designed a wall mount for the router which allows me to mount it permanently into by van.

Running a Xilinx hw_server as Docker Container

Tue, 14 Jul 2026 14:10:51 +0000

Dockerized Xilinx hw_server Setup.

This article describes the necessary steps to run a Xilinx hw_server as a Docker container.

Xilinx’s hw_server is a command line utility which handles JTAG communication between a Xilinx FPGA board and usually the Vivado IDE. It can be used to configure the FPGA bitstream, connect to the embedded logic analyzer cores (ILA) or perform debugging of processor cores via GDB and the Xilinx System Debugger (XSDB). The hw_server is usually used when those tasks shall performed remotely as the connection between Vivado or XSDB is established via TCP connection and allows us to run it on a remote system.

Running the hw_server as a Docker container has the benefit that its installation is simplified to starting a Docker container by running:

dockerrun\

--restartunless-stopped\

--privileged\

--volume/dev/bus/usb:/dev/bus/usb\

--publish3121:3121\

--detach\

ghcr.io/stv0g/hw_server:v2021.2

It also allows us to run the hw_server on architectures which are not natively supported by Xilinx such as the commonly used Aarch / ARM64 and ARMv7 architectures found in Raspberry Pis.

This is enabled by Dockers support for running container images for non-native architectures. I am using the aptman/qus Docker image (/dbhi/qus ) to setup this user-mode emulation. The qemu-user-static (qus) image is a compilation of utilities, examples and references to build and execute OCI images (aka docker images) for foreign architectures using QEMU’s user-mode emulation.

Run the following commands to run the hw_server on a embedded device:

# Install docker

sudoapt-getupdate&&sudoapt-getupgrade

curl-sSLhttps://get.docker.com|sh



# Start Docker

sudosystemctlenable--nowdocker



# Enable qemu-user emulation support for running amd64 Docker images

# *Note:* only required if your system arch is not amd64!

dockerrun--rm--privilegedaptman/qus-s---px86_64



# Run the hw_server

dockerrun--restartunless-stopped--privileged--volume/dev/bus/usb:/dev/bus/usb--publish3121:3121--detachghcr.io/stv0g/hw_server:v2021.2

This setup has been tested with a Raspberry Pi 4 running the new 64-bit Debian Bullseye Raspberry Pi OS.

The pre-built Docker image for the hw_server of Vivado 2021.2 is available via:

/stv0g/xilinx-hw-server-docker (Packages)

Detailed instructions can be found at Codeberg: /stv0g/xilinx-hw-server-docker .

Encrypted credentials for Amazon AWS command line client

Tue, 14 Jul 2026 14:10:51 +0000

In this quick post I will show you how to use the password manager “password-store”¹ to securely store your credentials used by the Amazon Webservices command line client.

AWS CLI Logo.

The installation for Mac and Linux system is fairly easy:

pipinstallawscli

The credentials are stored as key-value pairs inside a PGP-encrypted file. Every time you call the AWS CLI tool, your keys will be decrypted and directly passed to the aws tool.

Use pass to add your keys in the store:

passeditproviders/aws

An editor opens. Use the following format:

User: stv0g

Access-Key: AKB3ASJGBS3GOMXK6KPSQ

Secret-Key: vAAABn/PMAksd235gAs/FSshhr42dg2D4EY3

Add the following snippet to your ~/.bashrc:

functionaws{

localPASS=$(passproviders/aws)

localAWS=$(whichaws)



# Start original aws executable with short-lived keys

AWS_ACCESS_KEY_ID=$(sed-En's/^Access-Key: (.*)/\1/p'<<<"$PASS")\

AWS_SECRET_ACCESS_KEY=$(sed-En's/^Secret-Key: (.*)/\1/p'<<<"$PASS")$AWS$@

}

Then use the cli tool aws as usual:

awsiamlist-access-keys{"AccessKeyMetadata": [ {"UserName":"stv0g",...`

I covered password-store already a few times earlier: Use YubiKey and Password-store for Ansible credentials, Workshop: Security Token. ↩

Use Yubikey and Password-store for Ansible credentials

Tue, 14 Jul 2026 14:10:51 +0000

I spent some time over the last months to improve the security of servers and passwords. In doing so, I started to orchestrate my servers using a configuration management tool called Ansible. This allows me to spin-up fresh servers in a few seconds and to get rid of year-old, polluted and insecure system images.

Ansible loves Yubico.

My ‘single password for everything’ has been replaced by a new password policy which enforces individual passwords for every single service. This was easier than I previously expected:

To unlock the ‘paranoid’ level, I additionally purchased a Yubikey Neo token to handle the decryption of my login credentials in tamper-proof hardware. ‘pass’ is just a small shell script to glue several existing Unix tools together: Bash, pwgen, Git, xclip & GnuPG (obeying the Unix philosophy). The passwords are stored in simple text files which are encrypted by PGP and stored in a directory structure which is managed in a Git repository.

Yubikey Neo und Neo-n.

There are already a tons of tutorials which present the tools I describes above. I do not want to repeat all of it. So, this post is dedicated to solve some smaller issues I encountered.

Use One-Time passwords across multiple servers

The Yubikey Neo can do much more than decrypting static passwords via GnuPG:

Generate passwords:
- fixed string (insecure!)
- with Yubico OTP algorithm
- with OATH-HOTP algorithm
Do challenge response authentication
- via FIDO’s U2F standard
- with HMAC-SHA1 algorithm
- with Yubico OTP algorithm

Some third-party services already support FIDO U2F standard or traditional OATH-{H,T}OTP TFA, like used by the Google authenticator app. I suggest to have a look at: https://twofactorauth.org.

For private servers there are several PAM modules available to integrate OTP’s or Challenge Response (CR) methods. Unfortunately, support for CR is not widespread across different SSH- and mail clients.

So, you want to use OTP’s which leds to another problem: OTP’s rely on a synchronized counter between the hardware token and the server. Once you use multiple servers, those must be synchronized as well. I’m using a central Radius server to facilitate this.

Integrate `pass` into your Ansible workflow

Ansible uses SSH and Python scripts to manage several remote machines in parallel. You must use key-based SSH authentication, because you do not want to type every password manually! Additionally you need to get super user privileges for most of your administrative tasks on the remote machine.

The SSH authentication is handled by gpg-agents --enable-ssh-support option and a PGP key on your token.

To get super user privileges, I use the following variable declaration my Ansible group_vars/all file:

---

ansible_sudo_pass:"{{ lookup('pipe', 'pass servers/' + inventory_hostname) }}"

There is a separate root password for every server (e.g. pass servers/lian.0l.de). I wrote some Ansible roles to easily and periodically rotate these passwords.

Integrate ‘pass’ into OS X

There are already several plugins and extensions to integrate the pass password store into other Programs like Firefox and Android.

A prompt for the password you want.

I added support for OS X by writing a small AppleScript which can be found here: /zx2c4/password-store/contrib/pass.applescript .

A notification with countdown.

コマンドで重複行を排除して一度だけ表示する

Mon, 13 Jul 2026 20:16:42 +0000

awkで簡単にできます:

awk '!seen[$0]++'

はじめに
コマンドで重複行を排除して一度だけ表示する
- コマンド解説
- 実行例
おわりに
参考

はじめに

コマンドで重複行を排除して一度だけ表示する方法の備忘録を残します。

The English translation of this post is here.

コマンドで重複行を排除して一度だけ表示する

下記コマンドで、重複行を排除して一度だけ表示可能です:

awk '!seen[$0]++'

コマンド解説

awk '!seen[$0]++'

$0: 現在処理している行全体
seen[$0]: "現在処理している行全体"をキーとする連想配列"seen"の値
seen[$0]++: "現在処理している行全体"をキーとする連想配列"seen"の値をインクリメント
- その行が初めて出てきた場合: 未定義 → 0
- その行が既にカウントされている場合: 値が1増加
!seen[$0]++: NOT演算子付きでbool判定
- その行が初めて出てきた場合: !0 = true
- その行が既にカウントされている場合: !1(以上) = false
awk '!seen[$0]++': その行が初めて出てきた場合のみtrueとなり表示

よって、このコマンドで重複行を排除して一度だけ表示することができます。

実行例

下記のようなファイルlist.txtの内容を、先ほどのコマンドで重複行を排除して表示してみます。

apple
banana
apple
orange
banana
grape
apple

実行コマンド:

cat list.txt | awk '!seen[$0]++'

出力結果:

apple
banana
orange
grape

このように、重複行を排除して一度だけ表示されることが確認できました。

おわりに

以上、コマンドで重複行を排除して一度だけ表示する方法のメモでした。

どなたかの参考になれば幸いです。

Follow @bioerrorlog

[関連記事]

www.bioerrorlog.work

参考

The GNU Awk User’s Guide

ZimaBoard2: The Full Review

Mon, 13 Jul 2026 19:27:36 +0000

👍

The product featured in this article was provided to the author free of charge for the purpose of review. That means:

Nobody was paid to write or publish this review.
The vendor did not get editorial input in, nor advanced screening of, this article.
This article may include affiliate links (which will have a tag icon).
We earn a modest commission off any purchase you make using our links at no additional cost to you.
This article was written in accordance with our Ethics Statement.

The ZimaBoard 2 is a great, low power NAS for enthusiasts, DIYers, hobbyists, and folks looking to start dabbling with self-hosted at home. I've been playing around with it for quite some time (thanks to IceWhale for sending it over to me to review) and I'm happy to note that it's a very fun device to play with!

What's in the box?

Specifications

CPU	x86 Intel N150 4 cores 4 threads 2.9GHz
RAM	DDR5 @ 6,400 MHz 8GB or 16GB
Storage	Dual native SATA 32GB or 64GB eMMC
Networking	Dual 2.5GbE
Expansion	PCIe & USB
I/O	USB 3.0 & Mini DisplayPort
Setup	ZimaOS GUI
Power	Fanless, ~6W idle
Cost	8GB RAM/32GB eMMC - $339 16GB RAM/64GB eMMC- $399

ZimaBoard2's Device Info screen

This particular model is the 8GB RAM/32GB eMMC variant which I feel is quite reasonably priced for what you get.

The Intel N150 is fitting for this class of NAS. With 4 cores and 6MB of cache, you're not going to be doing extremely heavy stuff (like a local AI chat bot without a GPU/ASIC to assist) but it's still more than enough to run a VM or install some of the built-in apps.

This package

In the box, the ZimaBoard2 came with the device, a little fan, a custom SATA/power breakout cable, two screwdrivers, a bunch of fasteners, a mini DisplayPort to HDMI adapter, and a DC power adapter. If I have one complaint about the form factor of this device, it's that adapter. It's pretty big and uses a barrel jack connection.

The box that this ships with can be upcycled into a stand for the ZimaBoard along with two 3.5" SATA drives. Neat touch!

💢

The mini DisplayPort to HDMI adapter included in the box did not work for me no matter what I tried. I connected it to my ATEM Mini Extreme ISO, my daily driver LG monitors, my old Sony WEGA tube TV (yes, it has HDMI), and I even tried a portable monitor. It was simply e-waste.

IceWhale shipped me the ZimaBoard2 along with an aluminum hard drive bay. The ZimaBoard fastens directly to it and can accommodate up to two 5 1/4" drives. This hard drive bay also comes with a PCIe riser.

Initial Setup

The ZimaBoard 2 is easy to set up. The first thing you should do is remove the bottom of the chassis and find the fan header and connect the included fan to it.

Then remove the nearby screw located in the top of the chassis and fasten the fan to it.

Make sure that the fan's wires won't get pinched and replace the bottom of the enclosure. But don't replace the screws just yet!

Find the longer fasteners that came with the HDD bay, align the holes in the bay to the chassis and then tighten the screws down one by one.

From there, you can populate the bay with up to two 5 1/4" drives and connect them via the included power/SATA cable.

Connect this to your network, (optionally) connect a monitor, and plug in the power...

Software

Now, you'll want to go to a computer on the same network and start the software setup process.

Head into your browser and navigate to casaos.local.

If this doesn't work, you'll need to type in the IP address of your ZimaBoard into the address bar. To find this, you can connect a monitor to the DisplayPort and the readout will tell you.

I apologize for the photo. I don't have a great way of capturing DisplayPort video

💡

Alternatively, you can inspect your DHCP leases!

From here, you'll want to follow the initial setup guide...

Get started with the ZimaBoard 2

Update

One mistake I made in my first impressions video was that I didn't upgrade the OS immediately.

ZimaOS 1.6.2 Murjek update

Well, actually, the OS didn't tell me that an update was available until the day after I filmed that video. I'm not sure why, but either way it meant some of the problems I had in the video were solved by a simple upgrade.

I recommend updating as soon as possible. The latest updates are terrific. This also means that the screenshots I'm using in the Disk Setup portion are on the older version of the OS.

The Dashboard

Like any NAS, the ZimaBoard2 has a GUI that's accessible through your web browser.

Built-in apps include the App Store, Files, Backup, ZVW (virtual machine manager), PeerDrop, Settings, and a link to the IceWhale Community.

Most of these are pretty self-explanatory, but before we get to any of that, we need to set up our hard drive.

Disk Setup

When you connect a drive, you'll see this prompt on the dashboard:

Click the "Manage" button to start the setup process.

Click the "Start" button.

On this screen, you can combine multiple drives to appear as a single disk. This is useful to increase throughput and aggregate capacity. Since I only have one drive, I just chose 'Single use.'

Here, you can select "Need Format" to start the format process. You can also click the other button to see drive details.

If your drive is already formatted with a support filesystem, you won't need to format.

Provide the format details including the name of this volume:

ZimaOS disk formatting configuration

Once formatting is finished, click "Enable" to continue.

ZimaOS disk configuration

Now that we have a drive set up, we can start uploading files!

My glasses! I can't see without my glasses!

Use Cases

If you're considering picking one of these up, there are a few excellent use cases.

#0 Built-in Functionality

You can use the built in apps like Files, ZVM, and Backup.

Files allows you to manage your own files in a personal cloud. It also lets you share your files with other people!

Backup helps you manage your backups across multiple devices.

ZVM gives you a tidy GUI to manage virtual machines. Super handy for downloading vendor-created appliance-like ISOs for something like Home Assistant.

There's also the App Store that will let you get other apps up and running quickly!

#1 JellyFin (or other media server)

If you didn't know, I'm a JellyFin fiend. It's a fantastic, amazing, all-in-one self-hosted streaming app that gives you access to your media collection and stream from it like your own personal Netflix.

Setting up Jellyfin on the ZimaBoard is really straightforward.

Just head into the app store and Jellyfin should be towards the top. Select it and click Install:

Install Jellyfin from the ZimaOS App Store

Installation process for Jellyfin on the ZimaOS App Store

Once it's finished, you can then click the Jellyfin icon to launch your newly-installed application!

#2 Home Assistant

Home Assistant in another terrific use case. If you've ever wanted to get into home automation, Home Assistant will be your jam.

Again, find Home Assistant in the App Store and mash that "Install" button. Once it's done installing, click the icon!

#3 qBittorrent

If you are a benevolent person who loves Linux, you might be interested in seeding your favorite distro's ISOs. And why wouldn't you? It's just a kind, loving thing to do.

But you may also not want to leave your desktop or laptop on all the time. That's where qBittorent comes in.

Like the other apps here, click the icon to launch it. The first time you click it, you'll see this screen:

Before you log in, though, make sure you update the Download directory. This is done in the Settings modal and not in qBittorrent. Click the edit icon on the above screen!

Scroll down to the "Volumes" section and click the folder icon for the second field /DATA.

Pick your HDD-Storage and make a new folder:

Once you've done that, click "Save" in the Settings modal.

The username is admin, but you're going to need to find the password. Open the qBittorrent menu and select "Settings." Then, in the top right corner, select the terminal icon. From here, choose the "Logs" file and you'll see the password toward the end of the log file.

How to find your temporary password for qBittorrent

Once you open qBittorrent, you'll see the login screen.

Finally, click the gear icon and navigate to the WebUI tab. Set a Password and click Save.

#5 PFSense Firewall

The modem/router that your ISP provided you (probably) sucks. And sucks really badly, at that. That's why I set up my own firewall many moons ago. There are lots of reasons to create your own firewall that I won't go into here. Suffice it to say: Wendell from Level1Techs told me it was the preferred option and who am I to disagree with Wendell?

PFSense is considered the premier DIYer's firewall system and, to my surprise, Zima's official docs have a pretty thorough guide for setting it up!

👉

I haven't personally tried setting up PFsense on the ZimaBoard 2.

Final Thoughts

The ZimaBoard2 is a terrific NAS for hobbyists, enthusiasts, and entry-level users.

The hardware is awesome. I love the form factor, the expandability with the PCIe port, and the dual 2.5Gbit NIC setup. It feels sturdy, industrial, and the optional hard drive bay is a welcome addition.

I have to say that the ZimaOS/CasaOS UI is incredible and makes managing Docker containers absolutely painless. Plus, CasaOS is FOSS under the Apache license, and it's written in Go! Gotta love that.

Also of note: I've got Jellyfin, Home Assistant, and qBittorrent running and the system resources leaves room for even more applications in the future!

ZimaOS dashboard's system resources readout while running Home Assistant, Jellyfin, and qBittorrent!

I am very pleased with this device and it's a welcome addition to my homelab!

With Google recently announcing they're dismantling their search platform, there's no better time to add The Bryant Review as one of your preferred sources.

About the Author:

Gardiner Bryant

I'm an educator, free software advocate, and storyteller. My passion lies in Linux gaming, self-hosting, the fediverse, and the human stories behind the tech we use every day. I believe in privacy, justice, community, and integrity.

First look at the New GPU Cooler Prototype

Mon, 13 Jul 2026 18:33:30 +0000

For the past while I’ve been working on a major redesign of my high performance gpu cooler project.

The rapid ascent of the LLM into the collective consciousness has sent the big players into a frenzy over datacenter GPUs. This is putting accelerating downward pressure on the price of all used compute GPUs, even the historically pricey stuff. P100s can be had for ~$100, V100 16GB are selling for ~$500, any day now the lower VRAM Ampere cards are going to drop below $1000…

We need a new cooler that can support any of these 300W GPUs, can be installed as densely as the cards, and is easy on the ears for homelab use. Pictured below are four prototype coolers installed on Tesla P100s:

Four PCBs installed on Four P100s on the Open Bench Table build.

Detail shot of the PCBs.

Nested PCBs.

Rightward looking coolers on the GPUs.

Like always, if you’re interesting in beta testing one of these coolers, send me a note. I’ve been keeping a list of people that have reached out since the original post and will likely be sending out a batch of coolers for feedback early next year.

Endgame EOL’d GPU Box?

Nominally out of date, the X99 Intel E5-* Xeon CPUs remain a favorite among homelabbers. CPUs are cheap, and the cores are plentiful. Relevant to the engineer interested in local LLM usage is the fact that that many of the workstation-class motherboards for these CPUs can mechanically support four x16 GPUs without breaking the bank.

In my mind, the Kepler, Maxwell and Pascal (to a lesser extent) series of NVidia compute GPUs sit in the same place. Irrelevant to volume businesses but potentially useful to small shops with specialized workloads.

In a way, I’ve been building up to a system like this for a while but having a suitable GPU cooler has remained the limiting factor. There are also a bunch of amazing builds out there covering similar ground but I feel they probably ran into the same cooling-related problems I did. Now that the new cooler has matured to a working prototype, I can finally build this system and see how much performance we can squeeze out of these old parts.

Benchmarking

In service of the cooler project, my collection of these enterprise GPUs is nearly the full set from Kepler to Pascal. I have a few motherboards and CPUs that fit the bill as well to make a benchmarking effort worthwhile. These are the different hardware combinations I plan on trying:

GPUs:

1x, 2x, 3x K80 (Will cause PCIe speed downgrades)
1x M10
1x M40
1x M60
1x M40 + 1x M60
1x P40
1x, 2x, 3x, 4x P100 (Will cause PCIe speed downgrades)
1x V100
1x V100 + 1x P100

I’ll re-run the interesting results from the above sets of hardware on these different CPUs to see what changes:

CPUs:

Intel Xeon E5-2687W v4 12-Core @ 3.00GHz (40 PCIe Lanes)
Intel Xeon E5-1680 v4 8-Core @ 3.40GHz (40 PCIe Lanes)

As for the actual tests, I’ll hopefully be able to come up with an ansible playbook that runs the following:

vLLM throughput with llama3-8b weights
Folding@Home, BIONIC, Einstein@Home and Asteroids@Home
ai-benchmark.com
llama-bench
I’ll probably also write something to test raw ViT throughput as well.

Without running anything, I’d bet that all of this effort is going to tell us what we already know:

The later generation GPUs will perform better.
Adding more GPUs does increase performance but with diminishing returns.

Still though, I’d like to have some hard numbers before saying anything authoritatively.

All of this testing will also yield a lot of relevant data to the larger cooler project. One of the most complicated issues in the design is the process of going from the external temperature of the GPU to the internal core temperature. It is absolutely possible to model the relationship. Physical or numerical models, regression models, random forest models etc are all effective at doing the conversion. These methods require a lot of real-world data for training or testing. I’ve been harvesting this data for this purpose pretty much as long as I’ve run the compute cards in my lab:

Archival photo of old temperature measurement setup.

Probe thermistor attached with a 3D printed part. Didn't work very well.

Washer thermistor - You would loose a bet about how poorly this performs.

First iteration of standalone PCB for the temperature sensor.

This benchmarking project, as well as the subsequent server build with the winning config is a great source for this modeling data as well. In this direction, I made a harness to have each of the new coolers talk to the host via USB

Overview showing the cable routing piece installed on the open bench table.

Detail shot of the cable routing.

Printed piece.

The host also records nvidia-smi output so all of the different variables can be compared on the same time series.

See you next time

Unlike a lot of my posts, this one isn’t going to end with links to code or CAD. The cooler has come a long way since the original publication, but is still a work in progress. Regarding the Endgame EOL’d GPU Box, I’ll probably be developing the benchmark and running through the different configs on stream this fall.

First batch of PCBs

The post First look at the New GPU Cooler Prototype appeared first on esologic.

1kW of GPUs on the OpenBenchTable

Mon, 13 Jul 2026 18:33:29 +0000

In the conclusion of my previous homelab post, I pled to the eBay gods begging for a 4xP100 system. My prayers were heard, possibly by a malevolent spirit as a V100 16GB for $400 surfaced. More money than I’d be willing to spend on a P100 but the cheapest I’d ever seen a V100, I fell to temptation. To use all four cards, I needed something bigger than the Rosewill RSV-R4100U. Enter the OpenBenchTable, and some 3d printed parts I designed to be able to securely mount four compute GPUs:

OBT had been on my radar for a while and will serve as a great… test bench for work related to this computer. Amazingly, the manufacturers are honest about the Open part of the name and the CAD files for the chassis are freely available to download and build off of. The rest of the computer is the standard set of cheap and cheerful X99 parts:

	Product	Price
Motherboard	ASUS X99-E	$192.00
CPU	Intel Xeon E5-1680 v4	$94.95
CPU Cooler	Noctua NH-L9x65	$59.95
Memory	4x 32GB DDR4	$94.95
Power Supply	Corsair HX1500i 1500W	$147.70
Case	OBT v2	$199.00
Storage	1TB WD Blue NVMe	$54.00
GPU 1-3	P100 16GB	$360.00
GPU 4	V100 16GB	$400.00

	Total	$1,602.55

Even though Ollama was invoked in the previous post, these days I’ve been back at my roots working on an AI image processing project. For the curious though, this box can do over 5 tokens/second on Deepseek R1 70B. I’ve done no optimization whatsoever and could actually use some pointers on the best way to benchmark a system like this. Here are more photos of the build:

Build overview showing coolers.

Only the PC on the bench.

Build overview, system on the bench.

Over 1kW pulled from the wall into the GPUs.

I livestreamed the migration of the system to the OpenBenchTable and the design of the PCIe bracket, here is that in 30 seconds:

https://esologic.com/wp-content/uploads/2025/03/migration_spedup_hq_2_noaudio.mp4

PCIe Bracket Mount for OpenBenchTable

The actual “project” here is the 3D printed PCIe bracket mount. Printed in PETG, this piece provides a significantly more rigid mounting surface to hold the GPUs in place. The OpenBenchTable ships with 4 long standoffs, plenty for the normal user but in my case about half as many as I actually needed. The power cables on the GPU are stiff, and want to yank the cards towards eachother. The result is the PCIe rod forms a long moment arm and the GPUs can easily wiggle around, potentially shorting out on their neighbor. The printed piece keeps neighboring cards separated and rigidly held in place.

Bracket mounted without GPUs.

Detail shot of bracket to OBT mate using 18mm bolts.

Bracket populated with GPUs.

Bracket nut pockets.

Printed "washer" holding brackets in place.

Print surface, note the use of supports.

Support detail.

Another support detail.

Like in pretty much all of my printed assemblies recently, I opt for nut pockets rather than threaded inserts here to keep things clean. When it’s quiet at night, I can hear my collection of hundreds of threaded inserts crying out from their parts bin on my shelf, pleading for attention. Eventually they’ll get used, but the nut pocket technique hasn’t let me down so far.

Honestly though, having now manufactured and assembled this piece, printed threads would probably do the job here.

I’ve published this part on printables. It’s great that the STEP file for OBT v2 is available to build off of. I’m extremely happy to spend more on any hardware product that comes with design files.

The BOM is really simple for this part:

18mm M3 bolts for fixing the bracket to the OBT
12mm M3 bolts and M3 nuts for fixing the GPU to the bracket.

Pico + Coolers

You’ll notice a Raspberry Pi Pico mounted above the GPUs connecting to sensors on the outer surface of the center two cards. Maybe you’re also wondering about the 12 fans nested behind the cards as well.

Nested coolers.

Top fans intake area.

This whole system is related to another project, a follow up to my tesla cooler project from 2021. The interest from readers and my personal interest in that project has accelerated over the years initial publication, and I’ve been working to release a more powerful follow up that addresses the shortcomings with the design from that post.

If that is something you’re interested in, if quietly air-cooling many accelerator GPUs is a problem you have, leave a comment, send me an email (dev@esologic.com) or follow the blog because there is going to be a lot more on this in the coming months and I need beta testers.

The post 1kW of GPUs on the OpenBenchTable appeared first on esologic.

Hardware for Engineering Stream

Mon, 13 Jul 2026 18:33:29 +0000

My beloved blog post still sits on the throne as the most effective format for engineering projects. To me, Inlining code, photographs, CAD models and schematics in an interactive way trumps other mediums. This level of interactivity closes the gap between reader and material, allowing an independent relationship with the subject outside of the story being told by the author.

Working on stream to an online audience has a similar effect, the unedited and interactive format yielding a real understanding of the creators process and technique.

For a while there, I’d settled into a nice habit of broadcasting project development live on twitch. Two moves later, things have settled down enough in my personal life that I feel it’s time to try to get back into this habit.

Before we get started again, I took some time to improve the ergonomics (both hardware and software) of my stream setup. The following documents a few smaller projects, all in service of these upcoming broadcasts.

RasRig

Being able to capture the flow between the computer and the workbench is a critical requirement for engineering streams. This necessitates having a bunch of different cameras in a bunch of different places throughout the work space. In my case, I wanted a cost-effective way to have at least three different simultaneous shots of the bench. After some experimentation, I found that mjpg-streamer running on a Raspberry Pi using a camera connected via the CSI port can do a great job of getting video into OBS.

Because video is transmitted over the network, it makes it easy to add cameras via my existing ethernet infrastructure or via WiFi, no need to route HDMI or SDI cables everywhere. Additionally, the ecosystem of CSI cameras is much larger than you’d think, as the NVidia Jetson boards are also compatible with the port. You can even get HDMI capture cards that output into the CSI port, so HDMI cameras, or video inputs could be integrated.

In general, I’m fine with acquiring more pi-ish hardware because I know it’ll get integrated into other projects should streaming become less desirable.

Software

Things like changing the resolution/FPS and exposure settings are also very easy to do because the Pi’s are networked. They’re also, well, Raspberry Pi’s. They have a practically infinite amount of expansion. Things like subject tracking, automatic exposure changing, alerting; all on the table for future projects. Ansible makes provisioning new cameras really simple, I’ve published the software to do this on GitHub.

Mechanical Hardware

Ansible is cool, but the CAD is the interesting bit at this stage. There are currently three different camera plates that support:

The standard Raspberry Pi camera module.
The Raspberry Pi HQ camera.
Those cheap OV5647 wide angle modules found on amazon.

There’s also a “plate” for use with massive c-mount microscope lenses as well. It’s easier to see these as a 3D render:

This is a single configuration using the Raspberry Pi 3B, and wide angle camera:

To start off my next series on stream, I’ve stood up three assemblies for three different camera angles.

An ultra-wide angle establishing shot. This is a launch Raspberry Pi which works great.
Overhead bench camera.
Microscope camera.

The settings for these can be found in the ansible hosts file in the repo. These are photos of the builds:

RasRig config, RPi 3B, with HQ camera and lens.

Detail of HQ camera.

Another angle of rasrig config.

Detail of assembly.

Detail of Pi.

Sloped edge allows access to GPIO pins, I use these for power.

Microscope config.

Huge microscope lens.

Could also use smaller lenses with this setup.

Detail of tripod mount.

Launch Model B RasRig config.

Wide angle lens installed.

Detail showing the adapter plate.

For a while, in my previous setup, I was using the official raspberry Pi display as a microscope monitor. This is still supported by the hardware:

Here’s a photo of that setup:

RasRig Bill of Materials

All of the printed parts, for all configurations are available on Printables.

Depending on what configuration you choose, your hardware needs will be a bit different. Things are grouped here by physical component:

pi-protector-switch-mount:

You could use a M2.5 nut here if you don’t want to use the protector.

plate-body:

6.4mm M3 Threaded Inserts for the three “bracing” bolts.
Those “bracing” bolts are always M3x70mm in all camera plate configurations.
3.8mm M3 Threaded Inserts for the two front facing bolts.
The front facing bolts will change depending on your config.
0.3″ 1/4″-20 Threaded Inserts for the three tripod mounts.

Camera Module:

In both the plate-camera-microscope and plate-camera-short-downward-hq, the same hardware is used to mount the camera to the printed piece.

plate-camera-microscope-arm:

The front facing bolts here are M3x25mm.

plate-camera-module-or-wide-angle:

The camera module:

For the wide-angle camera module config:

In both of these configs, and for the plate-camera-short-downward-hq config, M3x20mm bolts are used.

Desktop Microphone Stand

Stand with microphone installed.

Thread built into the anti-vibration mount.

M8 bolt next to stand.

M8 bolt installed.

This is my second time designing and publishing a desktop microphone stand. This time around for the Samson C02 condenser microphone. The microphone ships with a shock mount that has a 5/8″-27 thread in the bottom, which is large enough to be 3D printable. The rod with the thread mates with a base using a big ‘ol M8x110mm bolt that also adds rigidity. Pretty simple!

During the stream, this mic will sit on the bench, so I can switch between the two spots without having the go grabbing for another microphone.

The XLR cable for the mic is the only new run between my computer workstation and the bench. It plugs into the USB sound interface I use, along with the other CO2 that is used as the desktop mic. The software stack for the microphones is a bit indirect:

Equalizer APO is installed, used for modifying the input audio.
The software preamp built into Equalizer APO is used to boost the input sound level, which is a bit quiet out of the interface.
An AI noise reduction plugin removes hiss and self-noise and room noise. The resulting audio quality is good enough, and I really would like to avoid a massive SM7B-style microphone.
Audio from the mics flows through the Peace Plugin, EQ-ing the sound.
Then, in OBS, I create two mono audio sources based on the two halves of the interface.

I’d like to have a compressor to prioritize voice audio over desktop audio for the stream, but I haven’t gotten that far yet.

The printable pieces for this Desktop Microphone Stand are available on Printables.

C-Stand Workbench Mount

C-Stand with light, low over the workbench.

C-Stand mounted to bench.

Detail of bench mount.

Six 50mm bolts lock things in place.

Detail of bench mount piece.

Detail of outer piece.

Stabilizer and foot.

Detail of stabilizer.

Outer piece re-used for stabilizer.

Detail of captive M3 nuts.

Detail of stabilizer.

Used to retain stabilizer using friction.

Foot detail.

Foot detail, retaining pin still works!

More of the retaining pin.

This has been a wishlist project of mine since I moved into this apartment. I bought this c-stand several years ago and have gotten so much use out of it ever since. It’s big, it’s heavy and it has no problem performing non-photography related tasks. I’ve used it to hold lights, microphones, cameras, cooling fans and photo backdrops.

However, my new space is pretty small, and I don’t have the floor space for the legs.

This design essentially removes the need for the “turtle base” (the legs), bolting the base directly to the workbench. There’s a strong chance I make another one of these for the other side of the bench later on, I’m loving this that much.

This is kind of hard to photograph, here’s the 3D model I used:

This will light the shots provided by the overhead RasRig cameras during stream, and gives me a ton of flexibility to be able to change out lights and increase/decrease intensity as needed.

For mechanical hardware:

Are used by the printed pieces to fix the pole in place.

This is pretty specific to my setup, but if you’d like to print your own the files are on Printables.

Sadly, this new lighting setup forced my old desk lamp into retirement. To commemorate his many years of fantastic work, I built him a new perch where he can enjoy his twilight years as an overhead lamp.

Articulating Ball Head Arm

Frustratingly, you can’t really buy separate arms without the desk mounting poles for desk-mount arm kits commonly found on amazon. I use the arm that came with this kit for the microscope camera described above, but I wanted to add another arm to hold the other overhead camera. These overhead bench shots add a lot of depth to the stream.

The ball head I use is a bit overkill, but again it’s something I know I can re-use very easily down the road.

The hardware here is really simple:

Printed parts again are on Printables.

Stream Demo!

So how does this all look? I shot a context video for the project I’m going to be working on first on the stream:

I’m still not 100% happy with the audio pipeline, and I think I’d like to get a macropad for scene switching but I think we’re good to go.

The post Hardware for Engineering Stream appeared first on esologic.

Roastidio.us Tagged with linux

Homebrew Release: Warnel Chawpiovs v1.5.0 (PC, Nintendo Switch, Android), adds 9 new heroes and significant performance improvements

What is Warnel Chawpiovs ?

Warnel Chawpiovs – What’s new in 1.5.0

1.5.0 Development notes and anecdotes

How to install – Windows/Linux

How to install – Android

How to install – Nintendo Switch

How to install – Mac OS

Running your First Game

Status of the Switch port

Troubleshooting, bug reports, etc…

Known issues

Want more details?

What’s next:

Download

Download Debian ISO: With Easy Installation Guide

What Exactly is a Debian ISO?

Before You Download: Key Considerations

How to Download Debian ISO

Method 1: Direct HTTP/FTP Download

Network Install ISO

Complete Installation ISO

Live Install ISO

Method 2: Using a Torrent Client (Recommended)

Verifying Your Debian ISO Download

Creating a Bootable USB Drive

Booting and Installing

Conclusion

Igalia and Wind River Collaborate to Deliver Production-Ready Web Runtime for Embedded Linux Devices | Igalia

Building My Own GPS Stratum-1 Time Server on a Raspberry Pi - Jack Stromberg

Building My Own GPS Stratum-1 Time Server on a Raspberry Pi

How it all fits together

What you'll need

Notes before we get started

Part 1 — The base OS

Part 2 — Freeing up the hardware UART

2a. Disable the serial login shell (but keep the hardware port)

2b. Disable Bluetooth to reclaim the UART

Part 3 — Enabling PPS

3a. Load the PPS-over-GPIO overlay

3b. Verify raw GPS and PPS

Part 4 — gpsd

Part 5 — chrony with the socket backend

Part 6 — Confirming you've actually got a stratum-1 server

Part 7 — The telemetry daemon

7a. Install Rust and build

7b. Run it

7c. The /data contract

7d. Calibrating the GPS offset (optional)

Part 8 — Configuration via environment variables

The optional satellite-info fetcher

Part 9 — Running it at boot

Part 10 — Serving time to the rest of the network

10a. Match the allow line to your LAN

10b. Confirm it's serving

10c. Point your clients at the Pi

Part 11 — Actually using the dashboard

Satellite-info modes (dashboard side)

Previewing with simulated data

Part 12 — Optional: running the dashboard in Docker

Troubleshooting

What you end up with

Appendix A — Debian 12 (Bookworm) vs Debian 13 (Trixie)

Appendix B — Environment variables (quick reference)

Appendix C — Licensing & data sources

Linux Creator Linus Torvalds To Anti-AI Devs: Go Fork Yourself | HotHardware

Huawei HG8245H, can't read some system files

We Built a New Editor. Want to Try It? – Simplenote

What we built

Try the prototype

Tell us what you think

Share this:

Patchless

TLS Certificate Validation on Linux · Ivan Tomica

What the server actually sends

The system trust store

Here’s where it falls apart

The private CA obstacle course

Is Denuvo's Dominance Finally Beginning to Crack?

7c. The `/data` contract

Integrate `pass` into your Ansible workflow