Operating Systems Programming — Linux, Windows, Distributed Systems

What "operating systems programming" actually means here

Most freelance and agency engagements stop at the application layer — the framework, the database, the UI. Operating systems programming is the layer below that: the process model, the file system, the network stack, IPC, threading, signals, scheduling, and the daemons or services that run in the background of every production system. I take engagements where the load-bearing problem sits in that layer — and I bring the systems thinking the rest of the practice already runs on (written specifications before code, verification before delivery, evidence over assertions) to OS-level work.

What I build

In plain terms: I build the background services and infrastructure that make a high-volume business application actually run reliably — the parts that do not have a user interface but that fail loudly and visibly when they break. The technical breakdown:

• Linux daemons and Windows services. Long-running background processes that handle scheduled jobs, file ingestion, message processing, and inter-system communication. systemd unit files for Linux; Windows Service / IHostedService for Windows; structured logging, health checks, restart policies, and graceful shutdown.
• Distributed systems work. Multi-node coordination — leader election, distributed locks, message queues, eventual-consistency patterns, retry and idempotency design. Redis, PostgreSQL advisory locks, RabbitMQ, Kafka, NATS depending on the constraint.
• Backend performance and concurrency. When the bottleneck is the OS — file descriptor exhaustion, port exhaustion, thread-pool starvation, signal handling, or the wrong I/O model — I diagnose and fix it. strace / lsof / perf for Linux, ETW / Process Explorer for Windows.
• Docker and container engineering. Production-grade container builds with minimal base images, multi-stage compilation, health checks, init-process choice (tini, dumb-init), graceful shutdown wired through the orchestrator. Both Docker and Podman, Kubernetes when the buyer is already there.
• System integration and IPC. Named pipes, Unix domain sockets, shared memory, message queues — the unglamorous plumbing that connects multiple processes on one host or across a network.

Kernel-adjacent work — what I will and will not take

I work in user space with deep familiarity of the kernel boundary — system calls, /proc, /sys, sysfs, eBPF observability, cgroups, namespaces. I am not a kernel module author and I will not take engagements that require shipping out-of-tree kernel modules; that work belongs to specialists. The honest line: if your problem is "we need a Linux daemon that does X under Y load," that is in scope. If your problem is "we need a kernel module for filesystem-level hooking," I will refer to a network contact with that specialty.

Who hires me for OS-level work

Engineering leaders whose backend has a performance ceiling they cannot raise from inside the framework. Operations teams whose production daemons fail in ways that need a real systems-programmer to diagnose. Platform teams building internal infrastructure where the freelance market is mostly Python-script-ware and they need someone with the OS-internals background to do it right. Microsoft-shop enterprises that need a Windows Service done correctly the first time. Linux-shop SaaS founders whose backend has crossed the throughput where naive Node.js or naive Python stops working.

How the engagement is shaped

The discovery phase is heavier than usual for OS-level work. Before any code is written, I want to see the production logs, the strace / perf output, the load profile, and the current architecture diagram. The diagnostic phase frequently reveals that the load-bearing fix is not where the buyer originally thought it was. The written specification names the actual root cause, the fix plan, and the verification harness — exactly the same shape as the Laravel and .NET engagements, but with the diagnostic phase weighted differently.

Languages and stacks I use for OS-level work

C and C++ when the engagement demands it. Rust for new daemons where the buyer is open to the choice. Go for the operations-tooling and distributed-systems middle ground. C# / .NET for Windows Service engagements. PHP CLI for Laravel-shop buyers who want the daemon inside the existing stack. The right language is the one that fits the buyer's existing ops capability and the actual problem — not the one that is fashionable.