Articles | Coders' Compass Publishing

What is RSS, and How Do I Subscribe to Coders' Compass?

Subhomoy Haldar — Mon, 01 Jun 2026 12:00:00 +0530

Introduction

You’ve probably seen the little RSS icons next to Articles and Free chapters in the footer and on the section pages. If you’re new to RSS, those icons might not mean much to you. This post aims to fill in the missing pieces. We explain what RSS is, why we publish through it, and then briefly, how to read our posts in a feed reader of your choice.

What Does RSS Mean?

RSS (short for Really Simple Syndication) is a small, machine-readable file that a website publishes alongside its regular pages. Every time we publish a new article, our RSS file updates with that article’s title, a summary, and a link back to the full version. A feed reader repeatedly checks our RSS file on your behalf and shows you what is new. More importantly, it is software that you control.

This hails from an earlier era of the internet. The standard goes back to the late 1990s, and the protocol-level history is summarised well on the Wikipedia page for RSS. A close cousin called Atom does the same job with a slightly different XML format. Most feed readers can handle both interchangeably, so the distinction rarely matters in practice.

Why Would I Need It?

Unlike email newsletters and social media timelines, a feed reader provides three distinct advantages:

No account or email address is needed. You add our feed URL to your reader, and you’re done. We never learn that you subscribed, which is the entire point.
No algorithm reorders your reading. Posts appear in the order they were published. A week of silence from us means no new updates in your feed reader. You won’t find any surprise filler, “people you may know” features, or engagement loops here.
Portability. Your subscription list is yours. Most readers export to an OPML file, and any other reader will import that file. You have the freedom to use any platform you choose.

How Do I Set Up Feed Readers?

There is no single best reader. Your ideal choice hinges on your preference for self-hosting, your primary reading device (mobile or desktop), and your budget (which is often $0). The shortlist below is FOSS-first. In the interest of full transparency, this post’s author operates Miniflux as the back-end and CapyReader on Android.

Durable Subscription Options

Miniflux is a minimalist, fast, single-binary self-hosted reader written in Go. Licensed under Apache 2.0. Note that it requires PostgreSQL. You can self-host it with Docker Compose. If self-hosting feels like too much, the same developers run a hosted plan at miniflux.app for roughly $15/year (excellent value). The project also accepts donations via Liberapay.
FreshRSS is also multi-user PHP self-hosted reader with Docker Compose setup and broader database support. Released under the AGPL-3.0 licence and accepting donations via its Liberapay.

Both speak the long-standing Google Reader and Fever APIs, so a wide range of mobile and desktop clients can sync against either of them (confirmed by the official docs: Miniflux, FreshRSS).

Options For Reading On Your Devices

NetNewsWire is a native macOS and iOS app under the MIT licence. Syncs via iCloud. There is no paid tier; the project runs on volunteer time. If you really want to help, they suggest some excellent ways to do so while spending no money on them.
CapyReader is an Android client (also on F-Droid) that pairs cleanly with Miniflux, FreshRSS, and other Fever/Google Reader back-ends. The developer accepts donations on Ko-fi.
NewsFlash is a GTK reader for Linux desktops, suitable for GNOME users who would like a native experience. Written mostly in Rust, it is a spiritual successor to FeedReader. It is licensed under GPL v3. The ecommended way of helping the project is to volunteer your time.

Web-Hosted Options

If you would rather not self-host or install an app, two well-known web readers cover that ground: Inoreader and Feedly. Both are closed-source and use a freemium model. Inoreader’s Pro tier sits around €80/year, and Feedly now positions itself primarily as an AI-driven enterprise intelligence platform, with its free tier capped at 100 sources. You can still use them as free starter accounts. We mention them to ensure the list accurately reflects the non-FOSS landscape.

Once you have chosen a reader, the rest of this post applies to all of them.

Prerequisite: a feed reader installed and open, with its “Add subscription” (or “New feed”) screen visible.

Step 1. Copy whichever feed URL matches what you want to follow:

1# Articles:
2
3https://www.coderscompass.org/articles/index.xml
4
5# Free chapters:
6
7https://www.coderscompass.org/free-chapters/index.xml

Step 2. Paste the URL into the “Add subscription” field in your reader.

Step 3. Confirm. Your reader should fetch the feed within a few seconds and show a list of recent posts. If it does not, double-check the URL has not picked up any leading or trailing whitespace.

If pasting the explicit .xml URL is fiddly, most readers also accept the homepage URL https://www.coderscompass.org/ and discover the feeds automatically through the <link rel="alternate"> tags we include in the HTML head. Either route works.

Troubleshooting

The reader fetched the feed but shows nothing. Most readers poll on an interval. Wait a few minutes and refresh, or trigger a manual refresh from the reader’s menu.
The reader refuses the URL. Try the homepage URL https://www.coderscompass.org/ instead and let the reader auto-discover.
Your reader complains about TLS. We serve HTTPS with a current certificate, so no action is needed on your side. If the reader still complains, it is almost certainly out of date.

That should be everything you need to get our articles and chapters into your reading rhythm. If you run into any issues, ask for help in the comments below, or get in touch with us.

Never Locked Out: Monitoring SSH Reachability with Uptime Kuma and Tailscale

Subhomoy Haldar — Mon, 18 May 2026 12:00:00 +0530

Introduction

This is a small, focused application of Uptime Kuma. Out of the many things you can monitor with it, a TCP port check is one of the simplest. I use it to watch port 22 on every machine in my Tailscale tailnet, so I find out about a broken SSH path before I’m trying to fix something else and discover I’m locked out.

If you haven’t set up Uptime Kuma yet, we have a dedicated article on installing it.

Why Monitor SSH?

SSH is the entry point to remote machines. This door rarely fails loudly. sshd can crash after an upgrade, a kernel update may need a reboot you forgot to do, a host firewall rule can quietly start dropping inbound 22, or a careless edit to sshd_config might lock out your user with no one noticing. In every case, the box keeps running. You only realise the door is shut when you next try to walk through it, which is usually the moment you actually need it.

A passive check every minute or two costs next to nothing and transforms “that machine won’t let me in” into a notification that arrives hours sooner.

Note that this covers the necessity of monitoring. By itself, it will not do much unless you have a fallback mechanism for regaining access to your machine(s). We talk about it in this section.

Prerequisites

A working Uptime Kuma instance with at least one notification channel configured.
Tailscale installed on the machines you want to monitor, with MagicDNS enabled.
The Uptime Kuma host on the same tailnet, so it can resolve MagicDNS names and reach the other machines over the WireGuard mesh.
sshd listening on port 22 on each target machine. If you’ve moved SSH to a different port, substitute that everywhere below.

Verification

Before adding monitors, confirm the Uptime Kuma host can actually reach each machine over Tailscale. Run these from the host that runs Uptime Kuma.

Check that Tailscale is up:

1tailscale status

You should see a list of peers in your tailnet with their MagicDNS short names in the first column.

Resolve a MagicDNS short name to a 100.x.y.z Tailscale address:

1tailscale ip gandalf

Replace gandalf with one of your machine names. Expected output:

1100.64.0.12
2fd7a:115c:a1e0::abcd

Confirm port 22 actually answers from this host:

1nc -zv gandalf 22

Expected output:

1Connection to gandalf (100.64.0.12) 22 port [tcp/ssh] succeeded!

If any of those fail, fix the Tailscale side first. Uptime Kuma will see exactly what your shell sees.

Add a TCP Port Monitor

In the Uptime Kuma dashboard, click Add New Monitor. Set Monitor Type to TCP Port.

Fill in the form:

Friendly Name: something like SSH: gandalf. When you have a dozen machines, prefixing with SSH: lets you filter the dashboard at a glance. For further organisation, you can create groups of monitors in Uptime Kuma as well.
Hostname: the MagicDNS short name (gandalf) or the Fully Qualified Domain Name (FQDN): gandalf.tailnet-name.ts.net. Tailscale will resolve either over the tailnet. I personally use the FQDN.
Port: 22 for SSH.
Heartbeat Interval: 300 seconds (five minutes) is a sensible default for SSH. It’s fast enough to find out before you need the box, slow enough to keep sshd logs quiet. Drop to 60 for snappier alerts on a fast-moving network.
Retries: 2 is plenty.
Heartbeat Retry Interval: 300 seconds. Matches the heartbeat interval. Two unsuccessful retries before alerting will manage minor, temporary issues without unnecessary warnings.
Notifications: attach whichever channel you’ve configured (email, ntfy, Discord, Telegram, and so on).

Save it, then repeat for every machine you care about. To save time, clone the first and change the hostname for the rest. A dashboard with one tile per machine takes minutes to set up and pays for itself the first time something quietly breaks.

Going Further: Catching Accidental Public Exposure

Let us now consider the inverse problem. The setup above tells you when SSH stops working over the tailnet. It doesn’t tell you when SSH works from somewhere it shouldn’t. If a host firewall rule lapses, or sshd ends up bound to a public interface after a careless config edit, your tailnet-only assumption breaks silently.

A second Uptime Kuma instance running outside your tailnet (say, on a small VPS or a friend’s home server) can catch this. Add a TCP Port monitor for the public hostname or IP of each machine on port 22, and turn on Uptime Kuma’s Upside Down Mode. With that toggled, “reachable” registers as DOWN. The notification fires when SSH is unexpectedly reachable from the public internet.

Note: I haven’t deployed this myself. The boxes are firewalled at the cloud-provider level, and I’ve trusted that single layer. If you do set it up, the wiring is the same shape as a normal TCP monitor. There’s a toggle to flip the monitoring to alert if something’s up instead of down.

There are other alternative approaches available. Upside Down mode on Uptime Kuma is pragmatic because we’re already self-hosting Uptime Kuma and we don’t want another tool to maintain.

Fallback Paths Before You Need Them

Monitoring alerts you to a failure. The actual fix needs to be administered through fallback paths. The belt and braces approach means one supports the other; they aren’t interchangeable.

Confirm that the out-of-band console from your provider works on VPS-hosted machines prior to losing SSH access. Hetzner Cloud’s Rescue System or the console, Akamai Linode’s Lish, and DigitalOcean’s Recovery Console all let you in over the provider’s own channel when the network path is broken. The equivalents on AWS, OCI, and Vultr work the same way. Boot one of your droplets into rescue mode now, log in once, and bookmark/save the page.

For machines I can physically touch, the fallback is dumber and more reliable: a USB keyboard, a working HDMI cable, and a display I’ve tested. I do this check before installing Tailscale on any machine I bring online, so I know I can recover the box even when the network is broken.

The full stack ends up being: Tailscale to reach the box, an Uptime Kuma monitor to tell me when that stops working, and an out-of-band path for the day both layers fail at once.

Conclusion

A simple TCP port monitor on port 22 over Tailscale’s Magic DNS is a very small but very powerful application of Uptime Kuma. This automation has saved me from guessing “when did this particular machine go down?” You can apply this same technique for any TCP service that you want to keep an eye on inside your tailnet. It can be a Redis instance, a Postgres database, a Minecraft server, or anything that listens on a port.

How do you keep yourself from getting locked out of your own machines? Share it in a comment below!

A Dead Man's Switch for Docker Compose Updates with Uptime Kuma

Subhomoy Haldar — Fri, 15 May 2026 10:00:00 +0530

Introduction

If you self-host a few Docker Compose stacks, keeping them updated means:

SSH-ing in
cd-ing into each app directory
running docker compose pull && docker compose up -d for each one.

Once you have more than two or three stacks, this gets tedious. And if a pull fails at 03:00 on a Sunday, you probably won’t notice until something stops working days later.

Watchtower used to handle this. It watched running containers and pulled new images automatically. The original project was archived by its maintainers on 17 December 2025 with no further releases planned. There are good alternatives now: nicholas-fedor/watchtower is a maintained fork, What’s Up Docker (WUD) does image-update notifications, and Diun handles registry-level change detection.

We went with a different approach:

two shell scripts
a couple cron entries
a push monitor on Uptime Kuma.

The scripts are about thirty lines total. There’s no daemon to run, no configuration file to maintain. Cron triggers the update weekly, and Uptime Kuma tells us whether it worked.

Uptime Kuma is a self-hosted monitoring tool. We have a dedicated article on setting it up.

Working Principle: The Dead Man’s Switch

The technique we’re using has a name. A dead man’s switch is a control that defaults to “stop” and must be actively held open by a live signal. The term comes from late-1800s electric trams and trains, where the operator’s handle is spring-loaded so that if the operator slumps or releases the handle, the controller cuts power and engages the brakes. The pattern saw widespread adoption in US transit after the Malbone Street wreck of 1918.

The same inverted logic drives this pipeline. Each successful run of update.sh ends with a curl ping to the Uptime Kuma push monitor. The monitor’s 7d+1h window is the “held-open” interval. If cron never fires, the script aborts before reaching the notifier, the server is offline, or the network is dropping requests. As a result, no ping arrives. After the retries expire, the monitor flips to down and Kuma fires whatever notification channel you’ve configured. The script died and the switch flips to alert us: something went wrong.

Note: We sometimes send a ping within the held-open interval for failures detected by the script. We sent a signal through to Uptime Kuma even though the interval has not closed yet. That’s when we’re absolutely sure that something’s definitely gone wrong and we should get informed about it right away.

Several services exist purely for this pattern: Healthchecks.io is the canonical open-source one, Dead Man’s Snitch is the commercial counterpart that popularised the name, and Prometheus ships a Watchdog alert so you can use a dead man’s switch to monitor your own alerting pipeline. Uptime Kuma’s push-type monitor is the same mechanism — we use it here because we already self-host Kuma and don’t want another service to maintain.

Prerequisites

Docker version 20.10 or later with the Compose plugin.
One or more Docker Compose stacks you already run, each in its own directory (e.g. ~/apps/it-tools/docker-compose.yaml).
A working Uptime Kuma instance with the ability to create a Push-type monitor.
SSH access to the server that runs your Docker stacks, and the ability to edit the crontab on it.

Verification

Everything from this point on happens on the remote server, not your local machine. Set up your keys (recommended) and SSH in first:

1ssh user@your-server

Let’s check that the required tools are available next:

1docker --version

Expected output:

1Docker version 29.0.1, build eedd9698e9

Check that Docker Compose is installed:

1docker compose version

Expected output:

1Docker Compose version 2.40.3

Check that curl is available (we need it for the push notification):

1curl --version

Expected output (first line is enough):

1curl 8.12.1 (x86_64-pc-linux-gnu) ...

Check that you can access the crontab:

1crontab -l

This should either print your current crontab or say no crontab for <user>. Either is fine.

Finally, confirm your Compose stacks are where you expect them:

1ls ~/apps/*/docker-compose.yaml

You should see a path for each stack you manage.

Create the Push Monitor in Uptime Kuma

Open your Uptime Kuma dashboard and click Add New Monitor. Set the Monitor Type to Push.

Give it a name like Weekly Updates. The important setting is the Heartbeat Interval. Since we’re running our update once a week, we want Uptime Kuma to expect a heartbeat roughly every seven days. That’s the dead man’s switch interval, held open by each weekly ping. Set the interval to seven days plus one hour (608,400 seconds). The extra hour means that if the update starts a few minutes late or takes longer than usual, Uptime Kuma won’t mark it as down straight away.

Set Retries to 2 and Heartbeat Retry Interval to 3600 seconds (1 hour). If Kuma misses the expected heartbeat, it’ll wait and retry twice at one-hour intervals before marking the monitor as down. This avoids false alarms if the update script takes even longer or the push request gets lost.

After saving the monitor, Uptime Kuma shows you a push URL. It looks like this:

1https://your-uptime-kuma.example.com/api/push/REPLACE_WITH_YOUR_TOKEN?status=up&msg=OK&ping=

Copy this URL. We’ll need it in the update script. The URL accepts three query parameters: status (up or down), msg (a short message), and ping (response time in ms, which we leave empty). You can see how the endpoint works in the source code. Anyone with the token can push status to the monitor, but they can’t read anything from your Kuma instance.

IMPORTANT: Keep it out of public repositories. Treat this like a password, keep it a secret!

The Notifier Script: `notify_kuma.sh`

This script pushes a status (up or down) with a short message to your Uptime Kuma push monitor. We keep it as a separate file so we can reuse it for other cron jobs later.

 1#!/bin/bash
 2# notify_kuma.sh: Push a status update to an Uptime Kuma push monitor.
 3
 4set -euo pipefail
 5
 6USAGE="Usage: notify_kuma.sh <up|down> <message> <push-url>"
 7
 8STATUS="${1:?$USAGE}"
 9MSG="${2:?$USAGE}"
10PUSH_URL="${3:?$USAGE}"
11
12# Simple "space to +" encoding for the query string
13ENCODED_MSG="${MSG// /+}"
14
15FULL_URL="${PUSH_URL}?status=${STATUS}&msg=${ENCODED_MSG}&ping="
16
17HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" "$FULL_URL")
18
19if [ "$HTTP_CODE" -ne 200 ]; then
20 echo "WARNING: Uptime Kuma push failed with HTTP $HTTP_CODE" >&2
21fi

It takes three arguments: status (either up or down), msg (a short human-readable message), and the push url. It does a space-to-+ encoding on the message so it works in the URL query string, then calls curl and checks for an HTTP 200 response. If the push fails, it prints a warning to stderr. You’ll see it in the cron logs if you decide to set up a log file.

The ping= parameter is left empty. Uptime Kuma treats that as “no latency measurement”, which makes sense for a batch job. Feel free to drop it from the script if it feels unnecessary.

The Update Script: `update.sh`

This script cleans up disk space, loops through your Compose stacks, pulls new images, restarts services, and calls the notifier at the end.

 1#!/bin/bash
 2# update.sh: Pull and restart Docker Compose stacks, then notify Uptime Kuma.
 3
 4SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 5
 6KUMA_URL="https://your-uptime-kuma.example.com/api/push/REPLACE_WITH_YOUR_TOKEN"
 7
 8# Add your Compose stack directories here, one per line.
 9APPS=(
10 "/home/<user>/apps/paperless-ngx"
11 "/home/<user>/apps/it-tools"
12 # "/home/<user>/apps/another-stack"
13)
14
15echo "Pruning unused Docker resources..."
16docker system prune -f
17docker image prune -af
18echo "Docker cleanup complete."
19
20FAILED=0
21
22for APP in "${APPS[@]}"; do
23 echo "Updating: $APP..."
24 cd "$APP" || { echo "ERROR: Could not cd into $APP" >&2; FAILED=1; continue; }
25
26 if docker compose pull && docker compose up -d; then
27 echo "OK: $APP updated successfully"
28 else
29 echo "FAIL: $APP had errors" >&2
30 FAILED=1
31 fi
32done
33
34if [ "$FAILED" -eq 0 ]; then
35 "$SCRIPT_DIR/notify_kuma.sh" up "All stacks updated successfully" "$KUMA_URL"
36else
37 "$SCRIPT_DIR/notify_kuma.sh" down "One or more stacks failed to update" "$KUMA_URL"
38fi

Here’s each part in more detail:

Disk Cleanup

docker system prune -f removes stopped containers, unused networks, dangling images, and unused build cache.

docker image prune -af then removes all unused images (not only dangling ones) on a weekly schedule, old image tags build up and this reclaims the space.

You will re-download layers if you later docker run an older tag, but for a weekly homelab job that’s a reasonable trade-off. The Docker documentation on pruning covers this in more detail.

The `APPS` Array

Each entry is an absolute path to a directory containing a docker-compose.yaml. Edit this list to match your setup.

The Update Loop

For each app, the script cds into the directory (the || means a missing directory won’t stop the whole script), then runs docker compose pull && docker compose up -d.

The && between pull and up -d matters: if the pull fails (say, a network timeout), we don’t restart the containers with stale images. If something fails, the FAILED flag gets set, but the loop keeps going. A problem with one stack doesn’t stop the others from updating.

The Notification

After the loop finishes, the script calls notify_kuma.sh once. It sends up if everything worked, down if anything failed.

Make both scripts executable, and restrict update.sh your user only since it contains the push URL:

1chmod +x ~/apps/update.sh ~/apps/notify_kuma.sh
2chmod 700 ~/apps/update.sh

For most homelab setups this is sufficient. If you want to go stricter, you could pull the push URL from a secret manager at runtime instead of hardcoding it in the script. We mention phase.dev for secret management later in this article as an option.

Scheduling With Cron

Add two entries to your crontab with crontab -e:

17 3 * * 0 /home/<user>/apps/update.sh >> /home/<user>/apps/update.log 2>&1
241 3 * * 0 /home/<user>/apps/update.sh >> /home/<user>/apps/update.log 2>&1

This runs the update script every Sunday at 03:07, and again at 03:41. We use odd minutes (7 and 41 instead of 0 and 30) so the job doesn’t fire at the same time as logrotate, backup scripts, or anything else pinned to the top or bottom of the hour. It’s a small thing, but it avoids timing collisions. Use any number you wish, or stick to clean multiples of half-hours, if that’s your preference.

The duplicate entry about half an hour later is there because stacks sometimes fail on the first attempt for reasons that resolve on their own. For example: a transient registry timeout, a sibling container still starting up. Running it again a bit later catches those, and when the first run already succeeded, the second one does nothing. Images are already pulled, containers are already running.

Both runs append to update.log. This log grows over time. You can configure logrotate for it, or just truncate it manually with truncate -s 0 ~/apps/update.log when needed. If you don’t want to look at the logs for this script (I don’t), you can leave out the >> /.../update.log 2>&1 bit.

How It Looks In Practice

Our Uptime Kuma dashboard shows the Weekly Updates monitoring group with its heartbeat history. Green bars are successful runs, orange ones are pending or waiting for retries, and red means retry window exceeded and it’s marked a proper failure with notification. You can see all three states at a glance.

If you have notifications configured in Uptime Kuma (Discord, Telegram, email, ntfy, Apprise, and many others), you’ll get an alert when the monitor goes down. You will be notified about failures, and the first success after a failure.

A Note on Secret Management

You might not want .env files sitting next to your Compose files. One option is Phase, an open-source secret manager (source on GitHub). You can prefix your Compose commands with phase run to inject secrets as environment variables at runtime:

1phase run --env prod docker compose up -d

This keeps secrets out of the filesystem. We’ll cover setting up Phase in a dedicated article.

For an open-source audit of Uptime Kuma (telemetry, licence, push endpoint behaviour) and ways to support the project, see our Uptime Kuma article.

Conclusion

The whole setup is two scripts, a couple cron entries, and a push monitor. Your Docker Compose stacks get pulled and restarted weekly, and you only hear about it when something goes wrong.

Let us know if you’ve done something similar. Like per-stack backups before updating, Slack notifications, or used a different monitoring tool.

Uptime Kuma: Self-Hosted Monitoring Tool

Subhomoy Haldar — Sun, 19 Apr 2026 12:00:00 +0530

Introduction

Uptime Kuma is a self-hosted monitoring tool. You point it at your services, and it checks whether they’re up. It can check via HTTP, TCP, DNS, ping, or push. If something goes down, it sends you a notification through whichever channel you prefer: email, Discord, Telegram, Slack, ntfy, and many others.

The project is created by Louis Lam and is available on GitHub under the MIT licence. The latest release at the time of writing is v2.3.0, published on 1 May 2026.

If you run any self-hosted services, you probably want to know when they go down before your users do. Uptime Kuma handles that with a clean dashboard and a deployment that takes five minutes or fewer.

Prerequisites

Docker version 20.10 or later with the Compose plugin.
A Linux server (Debian or Ubuntu recommended) or any system capable of running Docker containers.
An optional reverse proxy if you want to expose it securely (e.g., Caddy, Traefik, or Nginx).

Verification

Before proceeding with the installation, verify that Docker is installed.

1docker --version

You should see output similar to:

1Docker version 29.0.1, build eedd9698e9

Verify Docker Compose is installed:

1docker compose version

Expected output:

1Docker Compose version 2.40.3

Installation

Choose or create an appropriate directory, such as ~/apps/uptimekuma. Some folks prefer the /opt/docker/<appname> pattern.

Create a docker-compose.yaml file:

 1services:
 2 uptimekuma:
 3 container_name: uptimekuma
 4 image: docker.io/louislam/uptime-kuma:2
 5 restart: unless-stopped
 6 networks:
 7 - caddy-network
 8 ports:
 9 - "3001:3001"
10 volumes:
11 - ./data:/app/data
12 # Uncomment to enable the Docker Container monitor type.
13 # - /var/run/docker.sock:/var/run/docker.sock:ro
14 logging:
15 driver: "json-file"
16 options:
17 max-size: "1m"
18 max-file: "1"
19
20networks:
21 caddy-network:
22 external: true

Note: The default port is 3001. Change the port mapping if that’s already in use on your server. If you’re using a reverse proxy like Caddy, you can remove the ports section entirely and route traffic through the Docker network instead.

Pull the image and start the container:

1docker compose pull && docker compose up -d

Access Uptime Kuma at http://localhost:3001 (or your configured address). On first launch, you’ll be asked to create an admin account.

HTTPS

On a Private Tailscale Network

If you want free HTTPS without configuring certificates manually, you can use Tailscale Serve. After installing Tailscale on your server:

1tailscale serve --bg --https=3001 localhost:3001

This exposes your Uptime Kuma instance over HTTPS on your Tailscale network. Omit the external caddy network if you do not plan to expose it publicly behind a reverse proxy like Caddy.

On the Public Internet With Caddy

If you want to access Uptime Kuma publicly, use HTTPS. You can achieve this with a reverse proxy like Caddy, especially if you have it configured with the rate-limit plugin.

The docker-compose.yaml above already includes a caddy-network for this purpose. Point your Caddy configuration at the uptimekuma container on port 3001.

Monitor Types

When you click Add New Monitor, the default type is HTTP(s). It sends a GET request to a URL and checks the response code.

Uptime Kuma supports several other monitor types:

HTTP(s): checks a URL for a specific status code or keyword in the response body.
TCP: connects to a host and port. Useful for databases, mail servers, or anything that listens on a port. We use this to keep tabs on SSH across a Tailscale tailnet.
Ping: ICMP ping to check whether a host is reachable.
DNS: queries a DNS server and checks the result against an expected value.
Push: the monitored service pushes a heartbeat to Uptime Kuma instead of the other way around. Useful for cron jobs and batch scripts. We use this for a dead man’s switch on weekly Docker Compose updates.
Docker Container: monitors whether a specific container is running via the Docker socket.
Steam Game Server: checks game server availability.
MQTT: subscribes to an MQTT topic and watches for messages.
And more! The full list of types is in the server/monitor-types/ directory in the source.

Each monitor can have its own check interval, retries, and notification settings.

Notifications

Uptime Kuma supports over 50 notification methods. You can configure multiple notification channels per monitor or set up default notifications that apply to all monitors.

To add a notification method, go to Settings > Notifications > Setup Notification (or click Set Up Notification when creating a monitor).

Here’s an example using SMTP email:

Fill in your SMTP server details (host, port, username, password) and the sender/recipient addresses. Click Test to send a test notification and confirm it works before saving.

Other popular options include Discord webhooks, Telegram bots, Slack incoming webhooks, ntfy, Apprise, Gotify, PagerDuty, and Pushover. The full list is visible in the notification type dropdown.

Status Pages

Uptime Kuma can generate public or internal status pages that show the current state of your monitors. This is useful if you want to share uptime information with users or a team without giving them access to the full dashboard.

You can create status pages from Status Pages in the top navigation bar. Each page gets its own URL and can include whichever monitors you choose.

One limitation: visitors can’t subscribe to status page updates. On services like Atlassian Statuspage, users can sign up for email or SMS alerts when something changes. Uptime Kuma doesn’t have this yet. It’s been requested several times but hasn’t been implemented. For now, notifications only go to channels configured by the admin, not to end users directly.

Open-Source Audit

Similar to what we did in our IT-Tools article, we checked what Uptime Kuma does on the server side. Each claim below links to a specific file in the repository at the v2.3.0 tag.

Licence and authorship. Uptime Kuma is MIT-licensed. The primary maintainer is Louis Lam, with additional area maintainers. The latest release, v2.3.0, was published on 1 May 2026, and the project sees frequent merges from contributors.
No outbound telemetry by default. The server-side code under server/ doesn’t phone home. We found no evidence of analytics SDKs, fetch calls to external services, or tracking endpoints.
Update check is client-side only. The “new version available” banner is a client-side fetch against the GitHub Releases API. Your server doesn’t call out to check for updates. It’s just informational for whoever is viewing the dashboard.
Push endpoint behaviour. The route handler for /api/push/:pushToken confirms the URL format used by push monitors. The token in the URL is the only credential. No additional authentication is applied.

If any of this changed (say, telemetry was quietly introduced) the community would notice and fork. Same trust model as any open-source self-hosted tool.

Supporting the Project

If you get value out of Uptime Kuma, consider giving back:

Sponsor Louis Lam on GitHub Sponsors.
Contribute on GitHub: the project is written in Node.js and Vue.js. Bug reports, feature requests, and pull requests are welcome at the repository. Make sure to read the code of conduct and contributing guide before contributing.
Help with translations: Uptime Kuma supports many languages and translation contributions are always appreciated.

Practical Applications

Congratulations on setting up Uptime Kuma! Now, what can you actually do with it? A few usages have earned their own articles on this site, with more on the way:

Monitoring SSH reachability across a Tailscale tailnet: a TCP Port monitor on port 22 for every machine, with notes on upside-down monitoring for accidental public exposure, and on out-of-band fallback paths for the day Tailscale (or your local network) is the problem.
A dead man’s switch for Docker Compose updates: a push-monitor pattern that triggers an alert when cron goes silent. Weekly docker compose pull && docker compose up -d across your stacks, with a single notification when something fails.

A few more applications we use ourselves but haven’t yet written up, each likely worth its own walk-through:

Status pages for self-hosted services shared with family or a small group, despite the subscription limitation noted in the previous section.
A “are my backups still running?” push monitor pointed at the success-tail of your backup script, with a heartbeat window matched to the backup cadence.

Let us know in the comments if any of these are worth reading, and we’ll prioritise them.

Conclusion

Uptime Kuma gives you a self-hosted monitoring dashboard with a five-minute Docker deployment. It covers the common monitoring patterns (HTTP, TCP, DNS, ping, push), has a wide range of notification integrations, and can generate status pages.

Have you set up Uptime Kuma or another monitoring tool? Share your experience in the comments.

SearXNG: Self-Hosted Private Search Aggregator

Subhomoy Haldar — Mon, 19 Jan 2026 17:57:30 +0530

Introduction

SearXNG is a free, open-source metasearch engine that aggregates results from over 70 search engines while respecting your privacy. Unlike traditional search engines, SearXNG doesn’t track your searches, build a profile on you, or serve you advertisements.

When you use popular search engines like Google or Bing, your queries are logged, analysed, and used to build an advertising profile. Even privacy-focused alternatives like DuckDuckGo are proprietary and require trust in a third party. By self-hosting SearXNG, you take complete control over your search experience. Your queries stay on your server, and you can verify exactly what the software does by examining the source code.

One particularly useful feature is SearXNG’s ability to output results as JSON. This makes it an excellent tool for integrating web search capabilities into local LLM applications like Open WebUI, with no need for API keys or worrying about rate limits.

Prerequisites

Docker version 20.10 or later installed on your system. Newer versions of Docker include the Docker Compose plugin.
A Linux server (Debian or Ubuntu recommended) or any system capable of running Docker containers.
Basic familiarity with the terminal.

Verification

Before proceeding with the installation, verify that Docker is installed.

1docker --version

You should see output similar to:

1Docker version 29.0.1, build eedd9698e9

Verify Docker Compose is installed:

1docker compose version

Expected output:

1Docker Compose version 2.40.3

Installation

SearXNG uses Redis (or Valkey, a Redis-compatible alternative) for cacheing and rate limiting. The Docker Compose configuration below sets up both services.

Choose or create an appropriate directory, such as ~/self-hosting/searxng.

Create a docker-compose.yaml file:

 1services:
 2 redis:
 3 container_name: redis
 4 image: docker.io/valkey/valkey:8-alpine
 5 command: >-
 6 valkey-server --save 30 1
 7 --loglevel warning
 8 restart: unless-stopped
 9 networks:
10 - searxng
11 volumes:
12 - ./data/redis:/data
13 user: "1000:1000"
14 cap_drop:
15 - ALL
16 cap_add:
17 - SETGID
18 - SETUID
19 - DAC_OVERRIDE
20 logging:
21 driver: "json-file"
22 options:
23 max-size: "1m"
24 max-file: "1"
25
26 searxng:
27 container_name: searxng
28 image: docker.io/searxng/searxng:latest
29 restart: unless-stopped
30 networks:
31 - searxng
32 ports:
33 - "8080:8080"
34 volumes:
35 - ./data/searxng:/etc/searxng:rw
36 environment:
37 - SEARXNG_BASE_URL=http://localhost:8080/
38 - UWSGI_WORKERS=2
39 - UWSGI_THREADS=2
40 cap_drop:
41 - ALL
42 cap_add:
43 - CHOWN
44 - SETGID
45 - SETUID
46 logging:
47 driver: "json-file"
48 options:
49 max-size: "1m"
50 max-file: "1"
51
52networks:
53 searxng:

Note: Adjust the SEARXNG_BASE_URL environment variable to match your server’s IP address or hostname. If you’re deploying on a local network, use your server’s IP (e.g., http://192.168.0.90:8080/). The port mapping can also be customised—change 8080:8080 to something like 8090:8080 if port 8080 is already in use.

Pull the images and start the containers:

1docker compose pull && docker compose up -d

Access SearXNG at http://localhost:8080 (or your configured address).

HTTPS

On Private Tailscale Network

If you want free HTTPS without configuring certificates manually, you can use Tailscale Serve. After installing Tailscale on your server:

1tailscale serve --bg 8080

This exposes your SearXNG instance over HTTPS on your Tailscale network.

On the Public Internet With Caddy

If you want to access your SearXNG instance publicly, it is strongly recommended that you use HTTPS. You can achieve this with a reverse proxy like Caddy, especially if you have it configured with the rate-limit plugin.

Features and Use Cases

SearXNG offers several interesting advantages over traditional search engines.

Ad-Free Search Results

All search results pass through your server, which means you see the actual results with no sponsored content or advertisements. This alone makes self-hosting worthwhile. You do not need to scroll past “promoted results” to find what you’re actually looking for.

Search results aggregated from Google, Qwant, Startpage, and DuckDuckGo. Completely ad-free.

LLM Integration via JSON API

SearXNG can output search results as JSON, making it trivial to integrate with local LLM applications. If you’re running Open WebUI or similar tools, you can use SearXNG as a web search backend without:

Paying for API access to search providers
Managing API keys
Hitting rate limits

You can perform a (practically) unlimited number of searches through your own instance. The JSON output (look up how to enable it) includes useful metadata like which engines returned each result, relevance scores, and content snippets.

Aggregated Multi-Engine Results

Depending on your configuration, SearXNG queries multiple search engines simultaneously and combines the results. This provides several benefits:

Results that are heavily weighted on one engine might not appear prominently on others. Aggregation surfaces these differences.
You get a more comprehensive view of information.
If one engine has poor coverage for a topic, others may fill the gap.

The default configuration queries Google, Bing, DuckDuckGo, Qwant, Startpage, and many others. You can customise which engines to use through the settings interface.

Privacy Considerations

While SearXNG prevents search engines from tracking your queries directly, there’s an important caveat: your IP address is still visible to the search engines when SearXNG queries them on your behalf. This means search providers might still build a profile based on the searches coming from your server’s IP.

To mitigate this, consider one of the following approaches:

Use a VPN container: Run Gluetun alongside SearXNG to route all search queries through a VPN. This masks your server’s IP address.
Use a shared VPN exit node: If you have access to a VPN service with shared IP addresses, your queries will blend in with traffic from other users.

This might be overkill for most home users. The benefits of no tracking cookies, personalised advertising, or search history are already a substantial improvement over using search engines directly. It is worth partially implementing this over not implementing this at all.

Supporting the Project

SearXNG is maintained by a volunteer community. The project doesn’t appear to have a direct donation mechanism, but you can support it in other ways:

Contribute code: The project is written primarily in Python and welcomes contributions on GitHub.
Report bugs and suggest features: Use the issue tracker to help improve the project.
Help with translations: SearXNG supports multiple languages, and translation contributions are always welcome.
Join the community: The Matrix channel (#searxng:matrix.org) is active and welcoming to newcomers.

Running a public instance (if you have the resources) also helps the broader community access privacy-respecting search.

Conclusion

SearXNG provides a practical way to reclaim control over your search experience. The deployment is straightforward with Docker Compose, and the benefits are immediate: ad-free results, no tracking, and a free web search API.

SearXNG is worth considering for those who are concerned about privacy or wish to avoid advertisements. Self-hosting offers the advantage of integrating with local LLMs for web search. The configuration above should get you running in under ten minutes.

Have you set up SearXNG or another privacy-focused search solution? Share your experience in the comments.

It-Tools: Self Hosted Collection of Developer Tools and It Utilities

Subhomoy Haldar — Mon, 08 Dec 2025 10:13:15 +0000

Introduction

IT-Tools is a self-hosted collection of handy tools for IT usage. It includes converters, formatters, prettifiers, and many other utilities that developers and IT professionals use regularly. The project is created by Corentin Thomasset and is available on GitHub under the GPL-3.0 licence.

We have an instinct to search for tools like YAML or JSON formatters, word counters, and very simple hosted web tools. The problem with them is that we don’t know what’s happening with potentially sensitive data we hand over to them. It’s not recommended to paste private, possibly confidential information onto publicly available websites where we don’t know who the owner is and what’s being done with the data. You will definitely get scowled at by your senior developer!

By self-hosting this collection of tools and keeping them within your private network, you have better control over where your data is being copy-pasted. This project is also open source, so you can check if by some means your data is being uploaded to a third-party service. We’ve checked the IT-Tools repository and confirmed there’s no Plausible integration in the self-hosted version. See the Analytics on the Public Instance section for details. It’s very unlikely, and it would erode all the trust in the project if something were found in the source code. Following such an event, there definitely would be forks of the project, and we would migrate to them as a community.

Prerequisites

Docker version 20.10 or later installed on your system. Newer versions of Docker include the Docker Compose plugin. Refer to the Verification section to ensure you have everything set up properly.
An optional reverse proxy if you want to expose it securely (e.g., Caddy, Traefik, or Nginx)

Verification

Before proceeding with the installation, verify that Docker is installed.

1docker --version

You should see output similar to:

1Docker version 29.0.1, build eedd9698e9

Optionally, verify Docker Compose is installed:

1docker compose version

Expected output:

1Docker Compose version 2.40.3

Installation

This is one of the simplest Docker deployments you can have. You don’t even need any volumes with this. It can be a stateless container.

Note: The image is available from both Docker Hub (corentinth/it-tools:latest) and GitHub Container Registry (ghcr.io/corentinth/it-tools:latest). Both are official and maintained. We use the Docker Hub version for brevity.

Using Docker Run

1docker run -d \
2 --name it-tools \
3 --restart unless-stopped \
4 -p 8080:80 \
5 corentinth/it-tools:latest

Using Docker Compose

Sometimes you want a more permanent version control way of deploying your tools. We can achieve this using a Docker Compose file.

Choose or create an appropriate directory. Something like ~/self-hosting/it-tools.

Create a docker-compose.yaml file:

1services:
2 it-tools:
3 image: corentinth/it-tools:latest
4 container_name: it-tools
5 restart: unless-stopped
6 ports:
7 - “8080:80”

Then within that directory run:

1docker compose up -d

Test the Deployment

Access the application at localhost:8080.

Available Tools

As of December 2025, the latest version is v2024.10.22-7ca5933, released on 22 October 2024.

Quickly search for tools using the keyboard shortcut.

IT-Tools includes over 100 utilities organised into convenient categories. Here’s the list of tools available by category:

Cryptographic Utilities

Token generator
Hash text (MD5, SHA1, SHA256, SHA224, SHA512, SHA384, SHA3, RIPEMD160)
Bcrypt
UUIDs generator
ULID generator
Encrypt / decrypt text
BIP39 passphrase generator
HMAC generator
RSA key pair generator
Password strength analyser
PDF signature checker

Generate random tokens for various use cases.

Converters

Date-time converter
Integer base converter
Roman numeral converter
Base64 string encoder/decoder
Base64 file converter
Colour converter
Case converter
Text to NATO alphabet
Text to ASCII binary
Text to Unicode
YAML to JSON converter
YAML to TOML
JSON to YAML converter
JSON to TOML
List converter
TOML to JSON
TOML to YAML
XML to JSON
JSON to XML
Markdown to HTML

Encode and decode Base64 strings easily.

Tools for the Web

Encode/decode URL-formatted strings
Escape HTML entities
URL parser
Device information
Basic auth generator
Open graph meta generator
OTP code generator
MIME types
JWT parser
Keycode info
Slugify string
HTML WYSIWYG editor
User-agent parser
HTTP status codes
JSON diff
Outlook Safelink decoder

Images and Videos

QR Code generator
Wi-Fi QR code generator
SVG placeholder generator
Camera recorder

Generate QR codes for URLs, text, and more.

Development

Git cheat sheet
Random port generator
crontab generator
JSON prettify and format
JSON minify
JSON to CSV
SQL prettify and formatter
chmod calculator
Docker run to Docker compose converter
XML formatter
YAML prettify and format
Email normaliser
Regex Tester
Regex cheat sheet

Convert Docker run commands to Docker compose files.

Network

IPv4 subnet calculator
IPv4 address converter
IPv4 range expander
MAC address lookup
MAC address generator
IPv6 ULA generator

Mathematics

Math evaluator
ETA calculator
Percentage calculator

Measurement

Chronometer
Temperature converter
Benchmark builder

Text Utilities

Lorem ipsum generator
Text statistics
Emoji picker
String obfuscator
Text diff
Numeronym generator
ASCII Art Text Generator

Generate placeholder text for your projects.

Data Processing Tools

Phone parser and formatter
IBAN validator and parser

Analytics on the Public Instance

The publicly hosted version of IT-Tools uses Plausible as an analytics platform, as evidenced by the plausible.plugin.ts file in the source code. However, when you self-host it using the Docker image, there is no analytics tracking.

The Dockerfile does not include any environment variables or configuration for Plausible
The Plausible plugin requires explicit configuration to function, which is absent in the self-hosted deployment.
All tools are Vue.js components that process data locally within the browser.

Other than this, there’s no evidence of data being sent to any third parties. All tools are Vue.js components that process data within themselves. Some of them use local storage, but none of them do any data transfers. There are no traces of any HTTP usage.

Conclusion

Overall, IT-Tools is a nifty collection of handy tools all in one place. It’s highly recommended that you try it. The deployment is straightforward, and having these tools self-hosted (ideally within your local network) means you can use them without worrying about data privacy.

If you derive a lot of value from this little tool, we recommend sponsoring Corentin on GitHub so that we can keep this wonderful project going! You can also buy Corentin a coffee.

Know any other such tools worth self-hosting? Let us know in the comments!

Comparing TODIM and CPT-TODIM for Social Sustainability Assessment in G7 Countries

Vaishnudebi Dutta — Tue, 09 Sep 2025 00:00:00 +0000

Background

This paper came from a question we asked: if you want to rank countries on how “socially sustainable” they are, which algorithm should you use? Many multi-criteria decision-making (MCDM) algorithms exist, yet most research focuses on a single one. We wanted to dig deeper.

We focused on TODIM and its enhanced variant CPT-TODIM because they’re based on prospect theory. People are more affected by losses than by gains, as the Nobel Prize-winning idea suggests. This makes them well-suited for decisions where subjective judgement matters.

The Problem in Plain English

Suppose you want to rank the G7 countries (Canada, France, Germany, Italy, Japan, UK, USA) on social sustainability. You have 14 criteria: average wage, employment rate, income inequality, women in politics, education levels, and so on. How do you combine all these numbers into a single ranking?

Most algorithms work by computing a “distance” to some ideal solution. The country closest to the ideal wins. The problem is that by compressing all that multi-dimensional data into a single distance score, you lose nuance. Two very different countries might end up with similar distances, making the ranking unstable.

TODIM takes a different approach. Instead of evaluating countries based on their distance from a theoretical ideal, this method involves a criterion-by-criterion comparison of every country. For each pair, it asks: “Is Country A better or worse than Country B on this criterion? By how much?” Then it weighs losses more heavily than gains (because that’s how humans think). The result is a more stable ranking that doesn’t flip the alternatives around when you add or remove options.

CPT-TODIM extends this by adding parameters that model risk attitudes more precisely. It transforms the criterion weights using cumulative prospect theory, giving decision-makers finer control over how gains and losses are perceived.

Measuring Rank Reversals

We assessed algorithm stability through rank reversal analysis. Rank reversal occurs when removing one option changes the ordering of the remaining choices. We tested each algorithm by removing one G7 country at a time and checking if the remaining rankings shifted:

Algorithm	Rank Reversals (out of 7 removals)
CoCoSo	4 (FR, IT, JP, USA removals)
TODIM	2 (CA, DE removals)
CPT-TODIM	1 (DE removal only)

CoCoSo proved unreliable, with more than half of removals causing rank reversals. Both TODIM variants displayed minimal reversals, with CPT-TODIM being the most stable.

Abstract

Social sustainability objectives within the framework of sustainable development goals (SDGs) are critical aspects of balanced societies. Governments must constantly assess their performance to accomplish social sustainability goals. This paper evaluates the performance of seven industrialised nations: members of the Group of Seven (G7), in a streamlined manner. The rank sum weighting approach was used to quantify the subjectivity of experts’ judgements. In order to assess social sustainability performance for G7 countries, TODIM (TOmada de Decisão Interativa e Multicritério) and Cumulative Prospect Theory TODIM (CPT-TODIM) are implemented to compare the social sustainability performance of the G7 nations. Furthermore, sensitivity analysis is performed over 1000 different weight permutations of the criteria and alternatives from the original roster are removed to evaluate and contrast the two Multi-Criteria Decision-Making (MCDM) algorithms used to gain a deeper understanding of the strengths and limitations of each approach such as rank reversal problem. This analysis has also led to the conclusion of CPT-TODIM outranking both TODIM and CoCoSo algorithms. Analysis of 2020 OECD iLibrary data using both algorithms revealed that France emerged as the most socially sustainable country among the G7 nations.

Publication Details

Journal: International Journal of Information Technology & Decision Making
Published: 9 September 2025
DOI: 10.1142/S021962202550097X
Publisher: World Scientific
ISSN: 0219-6220 (Print), 1793-6845 (Online)
Open Access: Accepted Author Manuscript (University of Bristol) available under CC BY 4.0

Authors

Vaishnudebi Dutta (Corresponding Author, University of Bristol)
Subhomoy Haldar

Keywords

Social sustainability, multi-criteria decision-making, prospect theory, TODIM, CPT-TODIM, sensitivity analysis

Code and Data

The Python code for running the comparative and sensitivity analysis is available on GitHub: Coders-Compass/social-sustainability

The study uses 2020 data from the OECD iLibrary.

Access the Publication

The publisher version is available through the DOI link (closed access). In the interest of open access, the accepted author manuscript is freely available from the University of Bristol research repository under a Creative Commons Attribution 4.0 license, made open access under the university’s Scholarly Works Policy.

The paper contains the complete mathematical derivations, sensitivity analysis heat maps, and policy implications for each G7 country.

Probability of Real Roots in a Quadratic Equation with Uniform(α,β) Coefficients

Subhomoy Haldar — Wed, 29 Mar 2023 00:00:00 +0000

Background

This paper is a direct follow-up to our earlier work on the symmetric case, where we found that the probability of obtaining real roots of a quadratic equation is approximately 62.7% when coefficients are drawn from $U(-\theta, \theta)$.

The question that follows naturally is what happens when we remove the symmetry constraint?

What if the coefficients come from $U(\alpha, \beta)$ for any real numbers $\alpha$ and $\beta$?

The generalisation was more challenging than expected. We could apply simplifications for the symmetric case. For this instance, we had to employ a more powerful approach of obtaining the value - vector calculus. Our co-author Mukesh Chaudhary provided the insight necessary to proceed.

The Problem in Plain English

Consider the quadratic equation $Ax^2 + Bx + C = 0$. It has real roots when $B^2 \geq 4AC$. We want to find the probability of this happening when $A$, $B$, and $C$ are independently drawn from a uniform distribution $U(\alpha, \beta)$.

The geometric intuition follows: when we have three independent real values, we’re essentially working in a 3D space where each point $(A, B, C)$ represents one set of coefficients. Out of this entire cube, only certain sub-regions satisfy the discriminant condition $B^2 \geq 4AC$.

The probability we’re after is the volume of this “solution region” divided by the total volume.

The shape of this solution region is rather intricate. In the symmetric case, we could work around the complexity. But in the general case, we needed to compute these volumes properly using vector calculus.

The Key Finding

Unlike the symmetric case, which gives a single probability (62.7%), the general case produces different probabilities depending on the relationship between $\alpha$ and $\beta$. We derived the following algorithm that handles all cases:

Algorithm to calculate the probability of obtaining a real root when the coefficients are sampled from the continuous distribution $U(\alpha, \beta)$, where $\alpha, \beta \in \mathbb{R}$ :

Calculate the scaling factor $\theta = \dfrac{\text{signum}(\alpha) \cdot \text{signum}(\beta)}{\max(|\alpha|, |\beta|)}$
Find the ratio $f = \min(|\alpha|, |\beta|) \cdot \theta$, and its absolute value $r = |f|$
Calculate total volume of the cube as $V = (1 - f)^3$
Pre-compute $V_0 = \dfrac{5}{36} + \dfrac{\log 2}{6} \approx 0.2544$ It is also recommended to compute: $r^2$, $r^3$, $r^{\frac{3}{2}}$, $\dfrac{\log r}{6}$
If $f = 0$, return $V_0 \approx 0.2544$
If $f \in \left[\dfrac{1}{2}, 1\right]$, return $0$
If $f \in \left[\dfrac{1}{4}, \dfrac{1}{2}\right)$, return $\left(-V_0 - \dfrac{\log r}{6} + r^2 - \dfrac{8}{9}r^3\right) \div V$
If $f \in \left(0, \dfrac{1}{4}\right)$, return $\left(V_0 - 2r + \dfrac{16}{9}r^{\frac{3}{2}} + r^2 - \dfrac{8}{9}r^3\right) \div V$
If $f \in \left[-\dfrac{1}{2}, 0\right)$, return $\left(V_0 + 2r + 3r^2 + r^3\left(2V_0 - \dfrac{\log r}{6} - \dfrac{8}{9}\right)\right) \div V$
If $f \in \left[-1, -\dfrac{1}{2}\right)$, return $\left(2(V_0 + r + r^2) + \dfrac{\log r}{6} + r^3\left(2V_0 - \dfrac{\log r}{6}\right)\right) \div V$

The constant $V_0 = \dfrac{5}{36} + \dfrac{\log 2}{6}$ appears throughout the formula and represents the base probability in certain limiting cases.

Abstract

The roots of a quadratic equation $Ax^2 + Bx + C = 0$ are real if the discriminant $B^2 - 4AC$ is non-negative. In this paper, the coefficients are taken as independently and identically distributed $U(\alpha, \beta)$, where $\alpha, \beta \in \mathbb{R}$. The exact probability of obtaining real roots is derived through simplification by considering the ratio of the endpoints. Vector calculus is used to derive the final formula, which is experimentally verified using Monte Carlo simulation.

Publication Details

Journal: Journal of the Indian Society for Probability and Statistics
Volume: 24, Pages 135–149
Published: March 2023
DOI: 10.1007/s41096-023-00149-6
Publisher: Springer India
ISSN: 2364-9569 (Online)

Authors

Keywords

Quadratic equation, continuous uniform distribution, probability, Monte Carlo simulation, vector calculus

This paper extends our earlier result for the symmetric case, where coefficients were drawn from $U(-\theta, \theta)$. That work established the foundational approach and the 62.7% probability for the symmetric distribution.

Access the Publication

The full paper is available through the DOI link above. It contains the complete mathematical derivations, proofs, and Monte Carlo simulation results that verify the formula. We also show a render of the acceptable volume within the unit cube that represents the region where roots are real.

Implications of Agricultural Practices on Vegetation and Terrestrial Invertebrates in Riparian Zones

Vaishnudebi Dutta — Fri, 30 Sep 2022 00:00:00 +0000

Background

Riparian zones are the strips of land that run alongside rivers, streams, and wetlands. They act as transition areas between water and land, supporting a remarkable range of life. The vegetation growing in these zones filters sediment, regulates nutrients, stabilises stream banks, and moderates water temperature. Invertebrates (insects, spiders, beetles, and similar creatures) living in this zone depend on this vegetation for food, shelter, hunting grounds, and breeding sites.

Farmers increasingly use riparian land for agriculture. The rising population drives demand for more cultivable area, and riparian zones, with their fertile, well-watered soil, become tempting targets. The trouble is that clearing vegetation for farming removes the habitat that invertebrates rely on, setting off a chain of ecological consequences.

Field studies have documented these effects at various locations around the world, but mathematical models capturing the three-way interaction between riparian vegetation, terrestrial invertebrates, and agricultural production have been rare. This paper fills that gap by proposing a nonlinear model built from differential equations, then analysing its behaviour to identify the conditions under which all three can coexist.

The Problem in Plain English

Picture a stretch of riverbank. Trees and shrubs grow along it, providing cover for spiders, beetles, and other small creatures. These invertebrates do useful things: some eat crop pests, others help pollinate nearby fields, and their activity contributes to healthy soil. The vegetation also acts as a buffer, trapping excess nitrogen and phosphorus before it reaches the water.

Now imagine a farmer clears part of that riverbank to plant crops. The vegetation shrinks, and so does the habitat for invertebrates. Fewer invertebrates mean fewer natural pest controllers and pollinators, which can actually hurt the farm’s own output in the long run.

The paper captures this situation with three variables that change over time:

$V(t)$ - the amount of riparian vegetation
$I(t)$ - the population of terrestrial invertebrates
$A(t)$ - the agricultural production

Each variable is governed by a differential equation describing how it grows, shrinks, and interacts with the others. Vegetation grows logistically (it can only get so big given finite land and water) but gets reduced by both farming and invertebrate consumption. Invertebrates grow from vegetation but face internal competition and harm from agricultural activity. Agriculture also grows logistically but gets a boost from invertebrates (through pest control and pollination).

Key Findings

The mathematical analysis identified six possible long-term states the system could settle into:

Equilibrium	What it means
$E_0$	Everything collapses: no vegetation, no invertebrates, no agriculture
$E_1$	Only agriculture survives; vegetation and invertebrates are gone
$E_2$	Only vegetation survives; no invertebrates or agriculture
$E_3$	Vegetation and agriculture coexist, but invertebrates have vanished
$E_4$	Vegetation and invertebrates coexist, but there is no agriculture
$E_5$	All three coexist: vegetation, invertebrates, and agriculture together

The most important result concerns $E_5$, the coexistence state. The paper shows it exists and is stable when:

$$\theta\beta > \left(1 + \frac{\alpha}{r}\right)\delta$$

In words: the benefit that invertebrates draw from vegetation ($\theta\beta$) must outweigh the damage that agriculture inflicts, scaled by how much farming erodes vegetation’s capacity to regrow. If agriculture encroaches too aggressively, this condition breaks, and the system collapses to $E_3$ - a system with farms and some vegetation, but no invertebrates.

The sensitivity analysis reinforces this picture. The two most influential parameters are:

$r$ (vegetation’s intrinsic growth rate) - higher values stabilise the system and help all three components reach equilibrium faster
$\gamma$ (competition among invertebrates) - stronger competition reduces invertebrate numbers, which hurts agricultural output because fewer invertebrates mean less natural pest control

When the depletion rate $\alpha$ (how fast farming destroys vegetation) is too high, the system destabilises. The simulations show growing oscillations and eventual collapse.

What This Means

The mathematics formalises something ecologists have long suspected: riparian buffers - the uncultivated, vegetated strips next to waterways - are worth protecting. They sustain invertebrate populations that benefit farming through pollination, pest suppression, decomposition, and water quality regulation. Pushing agriculture into these zones might yield short-term gains, but the model shows it risks destabilising the entire system.

Abstract

Uncontrolled land-use owing to agricultural practices has not only resulted in depletion of vegetation, but has also worsened the habitat of terrestrial invertebrates living in riparian zones. With these dynamic interactions in mind, a nonlinear model is developed using a set of differential equations, including riparian vegetation, terrestrial invertebrates, and agricultural production as system variables. The model is based on the notion that terrestrial invertebrates totally depend on riparian vegetation for their survival and utilization of riparian zones for agricultural purposes not only cause the loss of riparian vegetation, but of terrestrial invertebrates as well. The generated differential-equation system is examined for equilibrium solutions, their existences and stabilities. The mathematical analysis demonstrates the conditions under which agricultural production, riparian vegetation, and terrestrial invertebrates can coexist and create a stable system. These intuitive conclusions are supported by quantitative results using numerical simulation and differential sensitivity analysis. The qualitative as well as quantitative findings suggest that excessive utilization of forested riparian land for agricultural practices may cause destabilization of the system and therefore, they should be put under check in riparian zones.

Publication Details

Journal: International Journal of Applied and Computational Mathematics
Volume: 8, Article 268
Published: 30 September 2022
DOI: 10.1007/s40819-022-01471-6
Publisher: Springer Nature
ISSN: 2349-5103 (Print), 2199-5796 (Online)

Authors

Vaishnudebi Dutta (Department of Mathematics, Birla Institute of Technology, Mesra, Ranchi)
Abhinav Tandon (Corresponding Author, Department of Mathematics, Birla Institute of Technology, Mesra, Ranchi)

Keywords

Riparian vegetation, Agriculture, Mathematical model, Differential equation, Stability analysis, Sensitivity analysis

Access the Publication

The paper is available through the DOI link on Springer. It contains the complete mathematical derivations, proofs, phase portraits, time-series graphs, and sensitivity analysis bar charts.

Probability of Real Roots in a Quadratic Equation with Uniform(-θ,θ) Coefficients

Subhomoy Haldar — Fri, 12 Mar 2021 00:00:00 +0000

Background

I wrote this paper towards the end of my Integrated Master of Science (IMSc) in Mathematics and Computing at Birla Institute of Technology, Mesra. Working under the guidance of Dr. Soubhik Chakraborty, I came across an interesting problem that had seen some discussion in the early 20th century but had been largely forgotten since.

The question is deceptively simple:

If you pick random numbers for the coefficients of a quadratic equation, what’s the chance that it has real roots?

This turned out to be a wonderful exercise in probability theory. Beyond the mathematics itself, the goal was to show that there are still unexplored corners in well-trodden areas of mathematics waiting to be revisited.

The Problem in Plain English

Consider the quadratic equation $Ax^2 + Bx + C = 0$. We know from school that it has real roots when the discriminant $B^2 - 4AC$ is non-negative. It takes an interesting angle when we ask: what if $A$, $B$, and $C$ are random numbers drawn independently from the same uniform distribution?

We looked specifically at the symmetric case where each coefficient comes from $U(-\theta, \theta)$, meaning any value between $-\theta$ and $+\theta$ is equally likely.

The Key Finding

The probability of obtaining real roots is approximately 62.7%.

This result comes from analysis of the probability distribution of $B^2$ and the conditions under which $B^2 \geq 4AC$. The calculation simplifies considerably when $AC \leq 0$ (which happens half the time), because then the discriminant is automatically non-negative.

We verified this theoretical result experimentally through Monte Carlo simulation, running thousands of random trials to confirm the calculation.

Abstract

In this paper, we seek to find out the probability of obtaining real roots of a quadratic equation $Ax^2 + Bx + C = 0$, with $A \neq 0$, when the coefficients are independent, identically distributed uniform variates. The exact value of the roots can be obtained from the coefficients and the discriminant indicates if the roots are real or imaginary. Here, we consider the uniform distribution $U(-\theta, \theta)$ and find the probability of obtaining a real root to be 62.7%. This is done through simplification of the problem, analysis of the probability distribution of $B^2$ for both $U(-1, 1)$ and $U(0, 1)$, and final evaluation using conditional probability. Calculations are simplified by the fact that $B^2 \geq 4AC$ is always true when $AC \leq 0$. We leverage on the fact that the probability of obtaining real roots when coefficients are sampled from $U(0, \theta)$ is 25.4%. We verify the result experimentally through Monte Carlo simulation and present the desired supporting data accordingly.

Publication Details

Journal: Journal of Applied Mathematics and Computation
Volume: 5, Issue 1, Pages 48-55
Published: 12 March 2021
DOI: 10.26855/jamc.2021.03.006
Publisher: Hill Publishing Group Inc.
ISSN: 2576-0653 (Online)

Authors

Subhomoy Haldar
Dr. Soubhik Chakraborty (Supervisor)

Keywords

Quadratic equation, continuous uniform distribution, probability, Monte Carlo simulation

Follow-up Work

This paper laid the groundwork for a more general result. In a subsequent paper, we extended the analysis to the case where coefficients come from $U(\alpha, \beta)$ for any real numbers $\alpha$ and $\beta$, removing the symmetry constraint. That work was published in the Journal of the Indian Society for Probability and Statistics in 2023.

Access the Publication

The full paper is available as open access through the DOI link above. It contains the complete mathematical derivations, proofs, and simulation harness.

Articles | Coders' Compass Publishing

What is RSS, and How Do I Subscribe to Coders' Compass?

Introduction

What Does RSS Mean?

Why Would I Need It?

How Do I Set Up Feed Readers?

Durable Subscription Options

Options For Reading On Your Devices

Web-Hosted Options

Subscribe To Coders’ Compass

Troubleshooting

Never Locked Out: Monitoring SSH Reachability with Uptime Kuma and Tailscale

Introduction

Why Monitor SSH?

Prerequisites

Verification

Add a TCP Port Monitor

Going Further: Catching Accidental Public Exposure

Fallback Paths Before You Need Them

Conclusion

A Dead Man's Switch for Docker Compose Updates with Uptime Kuma

Introduction

Working Principle: The Dead Man’s Switch

Prerequisites

Verification

Create the Push Monitor in Uptime Kuma

The Notifier Script: notify_kuma.sh

The Update Script: update.sh

Disk Cleanup

The APPS Array

The Update Loop

The Notification

Scheduling With Cron

How It Looks In Practice

A Note on Secret Management

Conclusion

Uptime Kuma: Self-Hosted Monitoring Tool

Introduction

Prerequisites

Verification

Installation

HTTPS

On a Private Tailscale Network

On the Public Internet With Caddy

Monitor Types

Notifications

Status Pages

Open-Source Audit

Supporting the Project

Practical Applications

Conclusion

SearXNG: Self-Hosted Private Search Aggregator

Introduction

Prerequisites

Verification

Installation

HTTPS

On Private Tailscale Network

On the Public Internet With Caddy

Features and Use Cases

Ad-Free Search Results

LLM Integration via JSON API

Aggregated Multi-Engine Results

Privacy Considerations

Supporting the Project

Conclusion

It-Tools: Self Hosted Collection of Developer Tools and It Utilities

Introduction

Prerequisites

Verification

Installation

Using Docker Run

Using Docker Compose

Test the Deployment

Available Tools

Cryptographic Utilities

Converters

Tools for the Web

Images and Videos

Development

The Notifier Script: `notify_kuma.sh`

The Update Script: `update.sh`

The `APPS` Array