Forem: Andrea Mancuso

The Strategic Value of Algebraic Data Types

Andrea Mancuso — Wed, 11 Feb 2026 15:06:27 +0000

In software management, "technical debt" is often discussed as an abstract concept. However, a significant portion of that debt stems from a specific source: impossible states. Algebraic Data Types (ADTs) are a disciplined way of defining what is allowed in a system so that invalid configurations simply cannot exist.

The problem: systems that allow nonsense

Most software today is built using "loose" data modeling. Consider a standard user profile:

is_logged_in (True/False)
is_admin (True/False)

On the surface, this is simple. But this design allows for a logical contradiction: a user who is not logged in but is marked as an admin.

It's the digital equivalent of saying someone is not in the building, yet they are currently in the executive boardroom. It shouldn't be possible, yet the code allows it. When a system permits these "impossible states," engineers must write defensive checks (if/else statements) everywhere to prevent bugs. Over time, this results in:

Increased testing overhead.
Slower development cycles.
Higher maintenance costs.
Subtle, hard-to-track production incidents.

The Solution: Structural Integrity

Instead of using various "flags" to describe a user, an ADT approach defines the user as exactly one of a few specific roles:

Anonymous (No extra data)
LoggedIn (Contains a username and specific permissions)

In this model, there is no physical way to be "Anonymous" and an "Admin" simultaneously. The system's architecture makes the error impossible to code.

Three Business Consequences

1. Reliable Production Environments Bugs are often the result of "edge cases" where data ends up in a combination the developer didn't foresee. ADTs eliminate these edge cases by design. The system doesn't just catch errors; it refuses to represent them.

2. Safer, Faster Iteration
When you need to change the system—for example, adding a new "Guest" tier—the compiler acts as an automated auditor. It forces the developer to update every single part of the application that handles users. Nothing is left to memory, and nothing breaks silently.

3. Lower Cognitive Load
Engineers no longer need to remember complex hidden rules (e.g., "The admin flag only counts if the login flag is also true"). The rules are encoded into the structure of the data itself. This significantly reduces onboarding time for new hires and lowers long-term maintenance costs.

The AI Advantage

As more organizations look toward AI-assisted coding, data structure becomes even more critical. AI tools are significantly more accurate when the "possibility space" of a system is narrow and explicit.

If a system clearly defines that a user is either Anonymous or LoggedIn, the AI doesn't have to guess which combinations of flags are valid. This leads to fewer "hallucinations" in the code and more reliable automated suggestions.

Summary: Risk Control Through Design

Think of ADTs like internal accounting controls. You can either spend resources training people not to make illegal entries, or you can design the ledger so that illegal entries cannot be typed in the first place.

One approach relies on constant human vigilance; the other relies on structure. Algebraic Data Types provide a structural reduction in risk, making your software more predictable, your developers more efficient, and your systems more resilient to change.

The trivialization of server management: the hidden costs and risks

Andrea Mancuso — Wed, 22 Oct 2025 18:21:06 +0000

Or: Why "Just get a VPS" is dangerously incomplete advice

The deployment illusion

The VPS market has exploded from $2.4 billion in 2018 to over $5 billion in 2024. What was once the guarded domain of seasoned sysadmins is now a playground for anyone with a credit card. But here's what nobody talks about: we've made deployment easy while security remains hard.

According to Cloudflare's Q1 2023 DDoS Threat Report, attackers have shifted from compromising IoT devices to enslaving vulnerable and misconfigured VPS servers, building botnets that are up to 5,000 times more powerful than IoT-based ones. Meanwhile, security research consistently shows that misconfiguration is a top security threat, with OWASP ranking Security Misconfiguration in their Top 10, noting that 90% of applications were tested for some form of misconfiguration.

A cautionary tale (mine)

In 2014, I spun up a VPS for a company project. I knew enough to deploy but not enough to know what I didn't know. Password authentication was left enabled on SSH; a single configuration line: PasswordAuthentication no.

I discovered the breach when the company owner asked about a CPU spike. Not through monitoring or alerts, through the bill.

This wasn't sophisticated. Attackers simply scanned for port 22, tried common usernames, and brute-forced passwords. It still works today because we're creating vulnerable servers faster than ever.

That experience is what makes me twitchy about VPS recommendations. One checkbox. One config line. That's all it took.

The confidence gap

Developers believe they're doing it right:

"I disabled root login!" (but left password auth enabled)
"I have a firewall!" (allowing 0.0.0.0/0 on port 22)
"I keep things updated!" (manually, when remembered)

Unlike code that crashes immediately, a poorly secured server might run fine for months until compromised. By then, you're part of a botnet and don't know it. And unlike a failing test suite, your VPS won't warn you when it's compromised. It'll just start sending spam for someone else.

The social dynamics: Nobody admits they're bad at security. Can't ask without looking incompetent. Can't tell your boss you shouldn't be doing this. Can't admit to peers you're winging it.

The tools that could help (but often don't get mentioned)

Modern defaults are better. Ubuntu Cloud Images disable password SSH by default. Infrastructure as Code (Ansible, Terraform, OpenTofu) can codify security into reusable scripts. Automation tools exist for updates and monitoring.

Immutable infrastructure offers another path: Container-based operating systems like Flatcar, CoreOS, or Bottlerocket shift the paradigm entirely. Instead of securing a mutable server, you deploy immutable images, use declarative configuration, and replace rather than update. This reduces the security surface significantly but it's a different mental model that requires learning container orchestration.

Here's the problem: When someone says "just get a VPS," they don't follow with "but first spend 40 hours learning Terraform/OpenTofu" or "consider if immutable infrastructure fits your use case."

The responsible advice is: Learn IaC, script everything, automate from day one, or use immutable infrastructure. That's honest. But it's not what people mean by "just get a VPS."

The true cost of "$5/Month"

Initial setup: 4-8 hours

SSH keys, firewall, fail2ban, automatic updates, SSH hardening, web server, SSL certificates, monitoring, backups.

Ongoing maintenance: 2-4 hours/month

Security patches, kernel updates, certificate renewals, log analysis, dealing with attacks, backup verification.

When things break: 4-48 hours

Server unresponsive at 2 AM, failed certificate renewals, kernel panics, compromised servers.

Annual time investment:

First year: 28-80 hours (setup + 12 months maintenance)
Subsequent years: 24-48 hours minimum
Plus incidents (unpredictable)
Add 20-40 hours if you learn IaC to do it properly

That "$5/month VPS" costs 48-120 hours in year one if you do it right. Price your time accordingly.

Required knowledge domains

Baseline Survival Skills:

Linux system administration (packages, processes, permissions)
Basic firewall configuration
SSH key management and hardening
SSL/TLS certificate management

Professional Security Skills:

Network security (attack vectors, DDoS mitigation, intrusion detection)
Log analysis and forensics
Backup strategies and disaster recovery testing
Incident response procedures

Even the "baseline" assumes significant systems knowledge most developers don't have. And "just get a VPS" rarely distinguishes between a hobby blog and a production system. People often use the same casual advice for both.

The tool that disappeared

Debian had a harden package to help secure servers. It was removed in 2015 due to poor maintainability. Ironically, right as the VPS market exploded and first-time server operators skyrocketed. Today there's no simple apt install debian-hardening. You must manually configure everything or use third-party scripts of varying trustworthiness.

The gap between VPS accessibility and available hardening tools has grown wider every year.

Modern tools still miss the mark

"AI-managed VPS" gives you a chatbot that answers questions. You still configure everything. It's "Stack Overflow in chat form," not automatic security.

Coolify and Dokploy simplify application deployment (SSL, reverse proxy, orchestration) but don't handle underlying server security. You still need to harden SSH, configure firewalls, manage updates, and set up intrusion detection.

The alternative: shared hosting

For $5-10/month, shared hosting handles security updates, SSL, backups, DDoS mitigation, and monitoring. Quality varies, and most providers don't publish security audit results.

The advantage isn't superior security, it's transferred responsibility. When something breaks, it's their problem. You're paying for peace of mind, not necessarily better security.

For personal blogs, portfolios, and side projects, these constraints often beat the burden of VPS management.

The vendor lock-in paradox

Here's the irony: while everyone warns about PaaS vendor lock-in, VPS creates its own lock-in through accumulated complexity.

PaaS lock-in (what everyone fears): Proprietary APIs, platform-specific configs, migration effort.

VPS lock-in (what nobody mentions): Years of accumulated server configuration, custom security hardening, tribal knowledge, undocumented tweaks, and the dread of recreating it all.

The escape hatch: Infrastructure as Code. Script everything with Terraform/Ansible from day one and migration becomes trivial. But most people don't do this. Instead, they SSH in, make manual changes, and accumulate state.

Try migrating a two-year-old manually-configured VPS. You'll spend days recreating everything, assuming you even documented it.

VPS flexibility is real. But how many times have you actually migrated providers? Or has "flexibility" just meant "freedom to accumulate technical debt"?

What should exist (and why it doesn't yet)

The most comprehensive solutions are debian-cis by OVH and harbian-audit by HardenedLinux. Both are production-grade hardening frameworks based on CIS benchmarks. OVH uses debian-cis for their PCI-DSS infrastructure; harbian-audit extends this with STIG compliance checks and supports Debian 9-12, CentOS 8, and Ubuntu 22.

They include 230-270+ automated checks, audit and apply modes, and can achieve 80-85% compliance on a blank system. HardenedLinux even provides pre-hardened AMI images.

But: Even these require significant systems knowledge. They're professional tools for people who already understand server hardening—not one-click solutions for beginners.

What about managed services? AWS Lightsail, managed Kubernetes nodes, and similar offerings do provide better defaults and handle much of the security burden. But they're managed services with less flexibility, not bare VPS with root access. Moreover, they're typically much more expensive than a regular VPS.

The missing product: A bare-metal VPS with full root access that's simultaneously secure by default:

SSH: keys only, non-standard port, fail2ban configured
Firewall: sensible defaults
Automatic security updates: enabled
Monitoring: basic alerting configured
And still: full root access to break anything

Why it doesn't exist: This is a support trade-off, not just a technical failing. The core value proposition of a traditional VPS is flexibility, which is often mutually exclusive with enforced security defaults. If a provider enforces a non-standard SSH port or disables password auth, they risk breaking beginners' custom setups and generating support tickets. It's easier to provide a blank slate and let users break their own servers.

The tools exist. The product incentives don't align with creating it.

Responsible Advice

If recommending VPS, include:

The reality: "You're responsible for security, updates, backups, monitoring—not trivial"
Actual resources: Complete hardening checklists, not just "use fail2ban"
Time expectations: "4-8 hours initially, 2-4 hours monthly, plus emergencies"
Consider alternatives: "Would managed hosting or PaaS work better?"
Real consequences: Compromised data, crypto mining, DDoS participation, legal liability

Conclusion

We've solved deployment. We haven't solved responsibility.

The VPS boom democratized deployment but not security. We've created an ecosystem where "just get a VPS" is common advice, but "learn IaC first" isn't.

The result? Growing numbers of vulnerable servers maintained by well-meaning developers who don't know what they don't know.

"Just get a VPS" is incomplete advice. The complete version is: "Get a VPS, learn Infrastructure as Code, automate everything, and accept the time investment." That's honest yet rarely said.

Your $5 VPS isn't cheap. It's a subscription to either anxiety or learning.

If you choose VPS: learn IaC properly, use established security configurations (debian-cis, Ansible roles), distinguish between hobby and production risk, and budget 48-120 hours in year one.

Or recognize that managed infrastructure might be more pragmatic. Infrastructure isn't your product. It's the foundation that should be stable enough to forget about.

Until "learn IaC first" becomes as common as "just get a VPS," we'll keep creating the problem we're trying to solve.

Can you really forget about that $5/month VPS?

Resources

If you do choose the VPS path, start here:

CIS Debian Linux Benchmark - Industry-standard hardening guidelines
debian-cis by OVH - Automated CIS benchmark hardening (used in OVH production)
harbian-audit by HardenedLinux - Extended hardening with STIG compliance (includes pre-hardened images)
Mozilla Server Side TLS Guidelines - SSL/TLS configuration best practices

Have you been burned by VPS management? Share your stories in the comments. No judgment.

Running Rust Binaries on Shared Hosting: A Practical Approach to Type Safety on a Budget

Andrea Mancuso — Fri, 17 Oct 2025 18:33:15 +0000

The Problem

I was tired of PHP's type system. Even with PHPStan and Psalm, there's no substitute for real compile-time guarantees. But I'm also practical - I don't want to pay for a VPS, maintain a server, manage security updates, configure databases, set up backups, and babysit infrastructure when shared hosting costs < $10/month and handles all of that for me.

The constraint: How do you get the benefits of compiled, statically-typed languages (Go, Rust) on restrictive shared hosting that only officially supports PHP?

The Solution: PHP as a thin wrapper

The approach is relatively simple:

PHP receives the HTTP request
PHP serializes request context (headers, body, query params) to JSON
PHP spawns your compiled binary as a subprocess
Binary reads JSON from stdin, does its work, outputs response
PHP captures stdout and returns it to the client

It's essentially CGI-style execution, but bypassing the hosting provider's CGI restrictions by going through PHP.

Implementation

PHP Side (simplified)

<?php
$context = [
    'method' => $_SERVER['REQUEST_METHOD'],
    'uri' => $_SERVER['REQUEST_URI'],
    'query' => $_GET,
    'headers' => getallheaders(),
    'body' => file_get_contents('php://input') // may want to limit this
];

// may want to set a timeout
$process = proc_open(
    './myapp',  // Your compiled binary
    [
        0 => ['pipe', 'r'],  // stdin
        1 => ['pipe', 'w'],  // stdout
        2 => ['pipe', 'w']   // stderr
    ],
    $pipes
);

if (is_resource($process)) {
    // Send context to binary
    fwrite($pipes[0], json_encode($context));
    fclose($pipes[0]);

    // Get response
    $output = stream_get_contents($pipes[1]);
    $errors = stream_get_contents($pipes[2]);

    fclose($pipes[1]);
    fclose($pipes[2]);

    $exitCode = proc_close($process);

    if ($exitCode === 0) {
        echo $output;
    } else {
        http_response_code(500);
        echo json_encode(['error' => 'Process failed', 'stderr' => $errors]);
    }
}

Go Side (simplified)

package main

import (
    "database/sql"
    "encoding/json"
    "fmt"
    "io"
    "os"

    _ "github.com/go-sql-driver/mysql"
)

type Context struct {
    Method  string              `json:"method"`
    URI     string              `json:"uri"`
    Query   map[string][]string `json:"query"`
    Headers map[string]string   `json:"headers"`
    Body    string              `json:"body"`
}

type Response struct {
    Data interface{} `json:"data"`
}

func main() {
    // Read context from stdin
    input, err := io.ReadAll(os.Stdin)
    if err != nil {
        fmt.Fprintf(os.Stderr, "Failed to read input: %v\n", err)
        os.Exit(1)
    }

    var ctx Context
    if err := json.Unmarshal(input, &ctx); err != nil {
        fmt.Fprintf(os.Stderr, "Failed to parse context: %v\n", err)
        os.Exit(1)
    }

    // Your business logic here
    result, err := handleRequest(ctx)
    if err != nil {
        fmt.Fprintf(os.Stderr, "Request failed: %v\n", err)
        os.Exit(1)
    }

    // Output response
    fmt.Println("Content-Type: application/json\n")
    json.NewEncoder(os.Stdout).Encode(result)
}

func handleRequest(ctx Context) (*Response, error) {
    // Connect to database (use Unix socket for shared hosting)
    db, err := sql.Open("mysql", "user:pass@unix(/var/run/mysqld/mysqld.sock)/dbname")
    if err != nil {
        return nil, err
    }
    defer db.Close()

    // Your query logic
    rows, err := db.Query("SELECT * FROM my_table")
    if err != nil {
        return nil, err
    }
    defer rows.Close()

    // Process results...
    var data []interface{}
    // ... populate data ...

    return &Response{Data: data}, nil
}

Building for shared hosting

The critical part: statically link your binary so it doesn't depend on the host's glibc version.

# For Go (pure Go, no cgo)
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o myapp \
    -a -ldflags '-extldflags "-static"' .

# Verify it's static
ldd myapp  # Should say "not a dynamic executable"

Upload via SFTP/SSH and set executable permissions:

chmod +x myapp

Database connection gotcha

Shared hosting typically blocks direct TCP connections to MySQL. Use Unix sockets instead:

// Unlikely to work on shared hosting:
db, err := sql.Open("mysql", "user:pass@tcp(localhost:3306)/dbname")

// Should work on shared hosting:
db, err := sql.Open("mysql", "user:pass@unix(/var/run/mysqld/mysqld.sock)/dbname")

You will need to find your socket path; you may use phpinfo() for this.

Performance results (YMMV)

Single row query:

Total time: 40ms
Memory: ~2.4 MB

700 rows (406 KB JSON):

Total time: 493ms
Memory: ~2.4 MB
Breakdown:
- PHP + spawn overhead: ~38ms
- MySQL query: ~350ms
- JSON encoding: ~50ms
- Pipe I/O: ~55ms

Memory usage is pretty good - Node.js would use >40 MB for the same workload.

Security Considerations

Important: Processes spawned on shared hosting are typically not sandboxed. Your binary runs with the same permissions as your PHP scripts - it can read/write any files your account can access and make any network connections allowed by your hosting provider.

This means:

Validate all input rigorously - Never trust data passed from PHP to your binary
Don't expose this pattern to untrusted users - This approach is for your own applications, not multi-tenant systems
Sanitize file paths - Be careful with any file operations
Limit what your binary can do - Follow principle of least privilege
Monitor resource usage - Shared hosts will kill processes that consume too much CPU/memory

The security model is essentially the same as running PHP scripts - your code runs in your account's context with no additional isolation. Design accordingly.

Why This Works

Advantages:

Real type safety - Compile-time guarantees, no runtime surprises
Performance - Compiled binaries are fast
Low memory - 2-10 MB vs 50-200 MB for typical app servers
No server maintenance - Let your host handle updates, security patches, database management, backups
Cheap hosting - Works on < $10/month shared hosting (though some providers disable proc_open and such)
Language choice - Use Go, Rust, or any compiled language that can generate a fully static binary
Familiar deployment - Just upload files via FTP/SFTP

Trade-offs:

Process spawn overhead - ~30-40ms per request (mitigated with caching)
No persistent state - Each request is isolated (use external storage/cache)
Complexity - Two codebases (PHP wrapper + binary)
Build step - Must compile for Linux x86_64
Limited isolation - Binaries run with your account's full permissions

Conclusion

This approach bridges two worlds: the accessibility of shared hosting and the robustness of compiled languages. It's far from perfect - you sacrifice some performance for compatibility - but for side projects and small applications, it's a sweet spot of cost, safety, and simplicity.

You get:

Solid type-safe business logic (if you use Rust)
Reasonable performance (sub-second responses)
Minimal memory footprint
< $10/month hosting with zero infrastructure management
Managed database, backups, and security updates already included in your hosting plan

Do I ultimately recommend this? For low traffic websites, educational purposes, why not. For production grade systems you may want to run your VPS or go for a containerized approach.

When OCaml Met C++: A Love Story in Signatures and Suffering

Andrea Mancuso — Mon, 02 Jun 2025 12:42:57 +0000

I didn't want to. Nobody wants to.
But when you're building a system that signs JSON and realize half your toolchain disagrees on what "canonical" means, you either give up... or you write bindings to a C++ implementation of RFC 8785 and plug it into OCaml.

So yeah. I chose violence.

The Problem

OCaml is great. But it doesn't come with a JSON canonicalizer - not for JCS at least. And I needed deterministic output to sign and verify my infrastructure DSL files in rezn. Rust was yelling. I had no choice.

The Solution

Found a solid implementation of JCS in Go
Asked o3 to convert it to C++
Politely suggested that reinventing a JSON parser was masochism - settled on nlohmann/json...
Write a clean C wrapper around it
Hook it into OCaml with ctypes or FFI bindings
Get deterministic output and working signatures

The Outcome

Now rezn-dsl emits canonical JSON blobs that pass signature checks - regardless of what language consumes them. Rust is finally happy.
I could've spent the weekend chilling. Instead, I shipped something. I'll take it.

Lessons Learned

Canonicalization is real and terrifying.
FFI is an art form.
Sometimes it’s faster to wrap C++ than reimplement a spec.

Design-by-Contract for Infrastructure: Stop Praying Your YAML Will Work

Andrea Mancuso — Sat, 24 May 2025 19:13:44 +0000

Let's face it: modern infrastructure is a Rube Goldberg machine built on top of YAML spaghetti, hope, and CI pipelines that pass only because someone disabled half the tests. We slap layers of "best practices" on top of chaos and call it DevOps. But what if we could actually trust our infrastructure definitions?

Enter Design-by-Contract for Infrastructure, an idea that sounds like it came from someone who's sick of debugging "why didn't this container start?" for the 18th time this week.

What Is It?

Design-by-Contract (DbC) comes from the world of software correctness. Eiffel popularized it, but the core idea is simple: instead of "hope it works," you define preconditions, postconditions, and invariants for your code and violations are caught immediately.

Now imagine that same rigor applied to your infrastructure:

Preconditions: Is the image published? Are secrets available? Does the target node meet requirements?
Postconditions: Did the pod reach Running state? Is the service reachable?
Invariants: Each replica must be on a separate availability zone. All configs must be valid JSON. Ports must be unique per host.

It’s not about "linting" your YAML. It's about contractual guarantees, embedded in the system, validated pre- and post-deployment.

Why This Matters

Infrastructure is code with side effects, but we treat it like a text file that only matters if CI doesn't puke.

This leads to:

"It worked on staging" — the classic lie, because nobody validated the actual contract between systems.
Shadow failures — like autoscalers spinning phantom replicas that do nothing.
Undiagnosed drift — where Terraform says "no changes", but your traffic is silently routing to /dev/null.

Design-by-Contract forces us to formalize expectations, which:

Prevents invalid states from being deployed in the first place.
Allows runtime checks to validate that contracts remain satisfied.
Offers machine-verifiable documentation for how the infrastructure is supposed to behave.

What It Could Look Like

Imagine something like this:

pod "api" {
  image     = "my-app:latest"
  replicas  = 3
  ports     = [4000]

  contract {
    pre  = image.exists && config.valid_json && env.contains("DATABASE_URL")
    post = state == "Running" && all(replicas, r => r.ready)
    invariant = ports.unique && zone.distribution == "balanced"
  }
}

This is not Kubernetes YAML. It's what Kubernetes should have been if it hadn't been designed by a committee under Stockholm Syndrome.

Isn't This Just Policy?

No. Policies are rules someone defines externally, often enforced after something is already broken.

Contracts are embedded within the system definition. They travel with the code, they're checked before and after execution, and they fail loud and early.

Is Anyone Doing This?

Not really. There are hints:

Terraform has depends_on, but no real validation layer.
Pulumi gets closer with real programming constructs, but still lacks native contract semantics.
Rezn (if it ever sees the light of day) might bake this in from the start.

But right now, the space is wide open for someone to say: YAML isn't good enough. My infrastructure deserves guarantees.

Final Thoughts

Design-by-Contract for Infrastructure isn; t a silver bullet, but it's a bullet. And it sure beats firing blindly into production and hoping nothing explodes.

If we truly believe in "infrastructure as code", then it's time we gave it the same respect we give application logic: contracts, guarantees, and no more "undefined behavior".

Setting Up a Wi-Fi Access Point on Raspberry Pi with 5 GHz and Client Mode

Andrea Mancuso — Wed, 07 May 2025 20:36:14 +0000

If you want to use your Raspberry Pi as a Wi-Fi access point (AP) that connects to an existing shared Wi-Fi network and acts as a hotspot for other devices, here's how you can set it up.

This setup leverages hostapd, dnsmasq, and iptables to enable a seamless Wi-Fi AP, allowing for a faster and more reliable connection.

Prerequisites

A Raspberry Pi (with a Wi-Fi 6 USB dongle or built-in support)
Wi-Fi router or AP
A stable shared Wi-Fi network to connect to
Basic understanding of the terminal and Raspberry Pi networking
A text editor (e.g., nano or vim)

Step 1: Install Required Software

First, ensure your Raspberry Pi is up to date and install the necessary software packages:

sudo apt update
sudo apt upgrade -y
sudo apt install hostapd dnsmasq iptables-persistent

Step 2: Configure `hostapd` for 5 GHz Wi-Fi

Create the configuration file for hostapd:

sudo nano /etc/hostapd/hostapd.conf

Insert the following configuration:

interface=wlan1
driver=nl80211
ssid=PiRouter
hw_mode=a
channel=36
ieee80211d=1
ieee80211n=1
ieee80211ac=1
wmm_enabled=1
country_code=country_code_2_letter_ISO
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=your_secure_password
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP

Replace country_code_2_letter_ISO with your country code, i.e. US.
Replace your_secure_password with your desired WPA2 passphrase.
hw_mode=a sets it to 5 GHz.
ieee80211ac=1 enables 802.11ac for Wi-Fi 6 speeds.
channel=36 is a good 5 GHz channel to start with.

Step 3: Configure DHCP and DNS with `dnsmasq`

Edit the dnsmasq configuration file:

sudo nano /etc/dnsmasq.conf

Add the following:

interface=wlan1
dhcp-range=192.168.50.10,192.168.50.50,12h

This sets up the DHCP range for devices that will connect to the Pi's Wi-Fi.

Step 4: Enable IP Forwarding and NAT

Enable IP forwarding by uncommenting the appropriate line in the sysctl configuration file:

sudo nano /etc/sysctl.conf

Uncomment the line:

net.ipv4.ip_forward=1

Apply the changes:

sudo sysctl -p

Set up Network Address Translation (NAT) to route traffic from your connected devices to the internet:

sudo iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
sudo iptables -A FORWARD -i wlan1 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i wlan0 -o wlan1 -j ACCEPT

To make these iptables rules persist after reboot, run:

sudo netfilter-persistent save

Step 5: Start Services

Enable and start the hostapd and dnsmasq services:

sudo systemctl enable hostapd
sudo systemctl start hostapd
sudo systemctl enable dnsmasq
sudo systemctl start dnsmasq

Step 6: Reboot and Test

Finally, reboot the Raspberry Pi:

sudo reboot

After rebooting, your Raspberry Pi should now be broadcasting the PiRouter SSID. Devices should be able to connect to it, and DHCP should assign IPs in the 192.168.50.x range.

Troubleshooting

Slow speeds? Make sure you’ve configured WMM (wmm_enabled=1), 802.11ac (ieee80211ac=1), and check for interference in the 5 GHz band.
Devices not connecting? Ensure that your device supports 802.11ac or ax for higher speeds.
No IP address? Double-check the dnsmasq config for correct DHCP range and ensure wlan1 is properly assigned an IP.

Conclusion

With just a few steps, you can turn your Raspberry Pi into a powerful Wi-Fi access point. This setup will improve your network’s performance and allow you to share your internet connection over 5 GHz Wi-Fi, with high-speed access and support for multiple devices.

Feel free to tweak the configuration to fit your needs, and let me know if you have any questions!

Let me know if you’d like me to tweak anything or add more details!

Multi-Arch Docker Builds at €14/Month - Just 2 VPSs

Andrea Mancuso — Sat, 26 Apr 2025 16:37:12 +0000

You don't need QEMU, GitHub Actions, or expensive CI services to build multi-architecture Docker images. With just two VPSs (one cheap ARM machine and one cheap x86 machine) you can build and push native linux/amd64 and linux/arm64 containers without emulation, without performance penalties, and without a monthly surprise bill. My setup costs just €14/month in total and reliably builds for both architectures using Docker's buildx feature.

The key is combining docker buildx with SSH-based Docker contexts: each VPS becomes a node in a custom builder instance. The x86 VPS builds amd64 images locally, while the ARM VPS handles arm64 images natively. BuildKit takes care of the rest: parallel builds, multi-platform manifests, and direct pushes to the registry. It's clean, fast, and yours. No cloud CI, no opaque runners; just you, your servers, and full control over your builds.

Set up the local amd64 docker node:

docker buildx create --name multiarch --use --platform linux/amd64

Set up the remote arm64 docker node:

docker context create arm-vps --docker "host=ssh://user@your.arm.vps.ip"

Append the arm64 remote builder:

docker buildx create --append --name multiarch --platform linux/arm64 arm-vps

Inspect:

docker buildx inspect multiarch --bootstrap

Name:          multiarch
Driver:        docker-container
Last Activity: 2025-04-26 16:31:34 +0000 UTC

Nodes:
Name:                  multiarch0
Endpoint:              unix:///var/run/docker.sock
Status:                running
BuildKit daemon flags: --allow-insecure-entitlement=network.host
BuildKit version:      v0.20.2
Platforms:             linux/amd64*, linux/amd64/v2, linux/amd64/v3, linux/amd64/v4, linux/386
Labels:
 org.mobyproject.buildkit.worker.executor:         oci
 org.mobyproject.buildkit.worker.hostname:         baab70c53c2d
 org.mobyproject.buildkit.worker.network:          host
 org.mobyproject.buildkit.worker.oci.process-mode: sandbox
 org.mobyproject.buildkit.worker.selinux.enabled:  false
 org.mobyproject.buildkit.worker.snapshotter:      overlayfs
GC Policy rule#0:
 All:            false
 Filters:        type==source.local,type==exec.cachemount,type==source.git.checkout
 Keep Duration:  48h0m0s
 Max Used Space: 488.3MiB
GC Policy rule#1:
 All:            false
 Keep Duration:  1440h0m0s
 Reserved Space: 9.313GiB
 Max Used Space: 93.13GiB
 Min Free Space: 47.5GiB
GC Policy rule#2:
 All:            false
 Reserved Space: 9.313GiB
 Max Used Space: 93.13GiB
 Min Free Space: 47.5GiB
GC Policy rule#3:
 All:            true
 Reserved Space: 9.313GiB
 Max Used Space: 93.13GiB
 Min Free Space: 47.5GiB

Name:                  multiarch1
Endpoint:              arm-vps
Status:                running
BuildKit daemon flags: --allow-insecure-entitlement=network.host
BuildKit version:      v0.20.2
Platforms:             linux/arm64*, linux/arm/v7, linux/arm/v6
Labels:
 org.mobyproject.buildkit.worker.executor:         oci
 org.mobyproject.buildkit.worker.hostname:         aba4522bbd7d
 org.mobyproject.buildkit.worker.network:          host
 org.mobyproject.buildkit.worker.oci.process-mode: sandbox
 org.mobyproject.buildkit.worker.selinux.enabled:  false
 org.mobyproject.buildkit.worker.snapshotter:      overlayfs
GC Policy rule#0:
 All:            false
 Filters:        type==source.local,type==exec.cachemount,type==source.git.checkout
 Keep Duration:  48h0m0s
 Max Used Space: 488.3MiB
GC Policy rule#1:
 All:            false
 Keep Duration:  1440h0m0s
 Reserved Space: 9.313GiB
 Max Used Space: 93.13GiB
 Min Free Space: 47.5GiB
GC Policy rule#2:
 All:            false
 Reserved Space: 9.313GiB
 Max Used Space: 93.13GiB
 Min Free Space: 47.5GiB
GC Policy rule#3:
 All:            true
 Reserved Space: 9.313GiB
 Max Used Space: 93.13GiB
 Min Free Space: 47.5GiB

As you can see, the local node builds amd64 images, the remote node builds arm64 images.

I hope you find this useful.

Running Phoenix applications on RISC-V: A Practical Report

Andrea Mancuso — Sun, 20 Apr 2025 00:17:49 +0000

As part of a personal experiment, I attempted to run a Phoenix LiveView application - RawPair - on a RISC-V SBC (Milk-V Mars, Debian Trixie). The goal was to evaluate how viable it is to self-host modern web stacks on emerging architectures.

Here's a summary of the process and findings.

What Worked

Platform: Debian Trixie (testing) Device: Milk-V Mars (riscv64)

Installed components:

Elixir 1.18.3
Erlang 27.3.3
Node.js 22
PostgreSQL
Docker (docker.io package)
Phoenix application code built and compiled successfully
ttyd compiled from source
Supervisord used for process management
Basic Phoenix endpoint launched and connected to the database

What Didn't Work Out of the Box

Tailwind CSS CLI

Phoenix LiveView's default asset pipeline depends on the Tailwind CLI (tailwind package), which wraps a native binary written in Rust (tailwindcss-oxide). The official Tailwind releases do not include builds for the riscv64 architecture.

This resulted in:

Runtime errors stating the architecture was unsupported
The Phoenix build process failing during mix assets.build
Incompatibility with Tailwind's scanning and compilation steps

Workarounds attempted

Using Docker to run Tailwind in an arm64 container via QEMU emulation (proved too slow)
Manually building Tailwind from source (required TurboRepo, also unavailable on RISC-V)
Manually building TurboRepo from source (679 Rust modules)

What's the Core Issue?

Tailwind's CLI requires a precompiled binary to run. On unsupported platforms like riscv64, no fallback mechanism exists. While the broader Phoenix stack is portable and builds fine on RISC-V, Tailwind currently introduces an architectural dependency that breaks compatibility.

Potential Solutions

Using the Play CDN for Tailwind in limited cases (not viable if using @apply or purging unused classes)
Replacing Tailwind with a CSS approach that doesn't require native compilation (far from straightforward on Phoenix-based applications)
Requesting RISC-V support upstream (see: Tailwind GitHub issue)

Summary

Running Phoenix + PostgreSQL on RISC-V is possible and surprisingly smooth with Debian Trixie.

Tailwind CSS currently blocks full compatibility due to its architecture-dependent binary.

This experience highlights the challenges of using modern frontend tooling on emerging platforms.

I'm documenting this in case others attempt something similar or are evaluating frontend stack portability.

Is the browser always the right tool for the job?

Andrea Mancuso — Fri, 15 Nov 2024 20:39:47 +0000

For over two decades, we've been building web applications on a foundation that dates back to an era of static documents. The Document Object Model (DOM) and Cascading Style Sheets (CSS), both born in the late '90s, were designed for a simpler web. Today, we’re asking them to style and manage complex, highly interactive applications. Is it any wonder they struggle to keep up?

"CSS wasn’t built for managing the intricate layouts of complex applications—it was built to make your hyperlinks blue and underline your headings."

A System Straining Under Modern Demands

When the DOM and CSS were introduced, web pages were static and lightweight. Today, applications often render tens of thousands of DOM elements simultaneously. This is where the cracks start to show:

Reflows and Repaints: Every change to the DOM can trigger a cascade of recalculations across tens of thousands of elements. This process is computationally expensive, especially in data-heavy applications like dashboards or real-time trading platforms.
CSS Selectors at Scale: The browser has to evaluate complex selectors across the entire DOM, leading to inefficiencies. A simple rule like .header > div must traverse and match elements against a tree containing thousands of nodes.
Limited GPU Utilization in the Browser: One of the biggest frustrations with traditional web-based applications is that the browser only offloads some CSS operations to the GPU. While certain CSS properties—such as transforms, animations, and opacity—can be GPU-accelerated, the majority of styles are still processed on the CPU. This creates a bottleneck, especially in complex, dynamic applications.

Nested Layers of Complexity

Modern frameworks like React or Angular mitigate some DOM inefficiencies but often exacerbate the problem by introducing their own layers of abstraction. Virtual DOMs, while helpful, still rely on underlying DOM updates to reflect changes on-screen.

The Result: A Bottleneck for Performance

Despite modern optimizations, rendering thousands of elements with dynamic layouts and animations remains a challenge for the browser. This is particularly evident when compared to native or GPU-driven applications, where every pixel can be directly controlled.

A Different Approach with XFrames

XFrames takes a different approach to building user interfaces by skipping the DOM and CSS entirely. Instead of relying on the traditional browser rendering pipeline, XFrames directly harnesses the power of the GPU to deliver high-performance, scalable user interfaces—without the bottlenecks. Also, unlike frameworks like Electron, which rely on two distinct layers — one for application logic and another for rendering via a browser process — XFrames integrates both logic and rendering into a single process (with the possibility to use Node workers for even higher performance and scalability). This eliminates the need for costly IPC communications between processes.

Direct GPU Rendering: One of the main advantages of XFrames is its ability to send rendering instructions directly to the GPU. Unlike the browser, which can only offload certain CSS properties to the GPU, XFrames maximizes GPU utilization for everything—from layout to animations—ensuring smooth, responsive interfaces that are native-like in performance.
Deterministic Layouts with Yoga: Rather than relying on complex CSS rules and reflows, XFrames uses Yoga, a layout engine designed for performance and flexibility. Yoga calculates layouts in a deterministic and efficient manner, which means it can handle even the most complex UIs without triggering unnecessary recalculations or reflows, resulting in a seamless experience.
Cross-Platform Performance: Whether you’re building a desktop application or a web app using WebAssembly, XFrames supports multiple platforms out of the box. This is achieved by bypassing the limitations of the browser and leveraging native rendering capabilities, making it possible to develop high-performance applications that work consistently across different environments.
Eliminating the DOM Overhead: By bypassing the DOM, XFrames eliminates the overhead of managing thousands of DOM elements. Instead of a slow, CPU-bound rendering cycle, XFrames sends precise instructions to the GPU for rendering, ensuring your application stays fast even as it scales.

Why Choose XFrames?

Simplicity: You no longer need to fight with CSS and the DOM to get the performance you need. With XFrames, you can focus on building your application’s functionality and user experience without worrying about performance degradation as your UI becomes more complex.
Scalability: XFrames was built with modern, data-intensive applications in mind. Whether you're developing a real-time trading platform or an interactive dashboard, XFrames can handle the rendering workload without breaking a sweat.
Performance: From the ground up, XFrames is designed to be lean and fast, leveraging the GPU for every aspect of the UI.

Ready to Unlock Next-Gen Performance?

With XFrames, you can break free from the traditional DOM and CSS bottlenecks while still leveraging WebAssembly for cross-platform compatibility. Whether you're building for the web or desktop, XFrames ensures that your application can take full advantage of GPU-driven rendering, delivering native-like performance without sacrificing flexibility.

XFrames is still under heavy development and, whilst it is not quite production-ready, getting involved now means that you would be helping shape its development and influence its roadmap.
So far, XFrames has been tested on WebGPU-enabled browsers (Chrome, Edge, Firefox Nightly) and Node.js (through OpenGL 3) on Windows 11 (x64), Ubuntu 22+ (x64), Fedora 41 (x64), Debian Trixie (x64), Raspberry OS (arm64 on a Raspberry Pi 5).

Give it a try and let us know your feedback!

Forem: Andrea Mancuso

The Strategic Value of Algebraic Data Types

The problem: systems that allow nonsense

The Solution: Structural Integrity

Three Business Consequences

The AI Advantage

Summary: Risk Control Through Design

The trivialization of server management: the hidden costs and risks

The deployment illusion

A cautionary tale (mine)

The confidence gap

The tools that could help (but often don't get mentioned)

The true cost of "$5/Month"

Required knowledge domains

The tool that disappeared

Modern tools still miss the mark

The alternative: shared hosting

The vendor lock-in paradox

What should exist (and why it doesn't yet)

Responsible Advice

Conclusion

Resources

Running Rust Binaries on Shared Hosting: A Practical Approach to Type Safety on a Budget

The Problem

The Solution: PHP as a thin wrapper

Implementation

PHP Side (simplified)

Go Side (simplified)

Building for shared hosting

Database connection gotcha

Performance results (YMMV)

Security Considerations

Why This Works

Conclusion

When OCaml Met C++: A Love Story in Signatures and Suffering

The Problem

The Solution

The Outcome

Lessons Learned

Design-by-Contract for Infrastructure: Stop Praying Your YAML Will Work

What Is It?

Why This Matters

What It Could Look Like

Isn't This Just Policy?

Is Anyone Doing This?

Final Thoughts

Setting Up a Wi-Fi Access Point on Raspberry Pi with 5 GHz and Client Mode

Prerequisites

Step 1: Install Required Software

Step 2: Configure hostapd for 5 GHz Wi-Fi

Step 3: Configure DHCP and DNS with dnsmasq

Step 4: Enable IP Forwarding and NAT

Step 5: Start Services

Step 6: Reboot and Test

Troubleshooting

Conclusion

Multi-Arch Docker Builds at €14/Month - Just 2 VPSs

Running Phoenix applications on RISC-V: A Practical Report

What Worked

What Didn't Work Out of the Box

Tailwind CSS CLI

Workarounds attempted

What's the Core Issue?

Potential Solutions

Summary

Is the browser always the right tool for the job?

A Different Approach with XFrames

Why Choose XFrames?

Ready to Unlock Next-Gen Performance?

Step 2: Configure `hostapd` for 5 GHz Wi-Fi

Step 3: Configure DHCP and DNS with `dnsmasq`