GHC, cross-compilation, linker behaviour, platform engineering and build systems. Inspect the record.
Senior systems engineering · Singapore ↔ Europe
Hard systems problems.
Solved while Europe sleeps.
Compiler, platform, build and infrastructure work delivered in reviewable increments from Singapore. Hand off the hard part and start the next European workday with code, tests, findings or a decision.
Direct senior attention · Public evidence · Upstream-minded
The technical owner stays close to the problem and the result.
Upstream where practical; maintainable private work where necessary. Explore public work (opens in a new tab).
Live overlap for decisions and asynchronous execution for progress.
What we solve
Engineering below the framework layer.
We work where compilers, runtimes, operating systems, build systems and deployment constraints meet. GHC, Haskell and Nix are part of the public record—not the boundary of the work.
Compilers & language tooling
Compiler internals, backends, linkers, runtimes, source maps, cross-compilation and toolchain bring-up.
Platform enablement
ARM64, Apple Silicon, Linux, mobile, virtualisation and compatibility layers—from first execution to production behaviour.
Build, CI & release
Nix, Hydra, heterogeneous runners, binary caches, reproducible builds, release engineering and difficult failure diagnosis.
Focused systems R&D
Prototype difficult technical ideas, reduce uncertainty with working evidence and turn viable experiments into maintainable systems.
Fit is determined by the systems boundary, not by the application language.
Selected public evidence
Credibility you can inspect.
Public code, issue history, releases and technical writing let engineers inspect the work before a conversation starts.
Selected Linux user-space binaries on macOS—without Docker or a full guest operating system.
hyper-linux
Problem
Linux executables are normally brought to macOS through containers or full virtual machines, adding weight and operational distance.
Work
hyper-linux uses Apple’s Hypervisor.framework, ELF loading and Linux-to-macOS syscall translation to run AArch64 Linux binaries—and x86_64 Linux binaries through Rosetta—inside lightweight per-process virtual machines.
What it demonstrates
Virtualisation, ABI translation, executable loading, syscall semantics, platform integration and systems debugging.
Event-driven CI around Hydra, GitHub and Attic.
hydra-tools
Problem
Poll-driven integration creates delayed feedback, API pressure and awkward pull-request status handling.
Work
hydra-tools provides event-driven bridges for GitHub webhooks and checks, Hydra jobsets and build events, and automatic Attic cache population.
What it demonstrates
CI architecture, Nix/Hydra integration, event-driven systems, production-oriented tooling and operational failure handling.
A decade of compiler, linker and cross-compilation work.
GHC and cross-platform engineering
Problem
Bring GHC and Haskell workloads to ARM, Android, iOS and Darwin targets while addressing the compiler, linker, Template Haskell, toolchain and build-system constraints exposed by those platforms.
Work
Public cross-compilers, target-prefixed toolchains, linker diagnosis, build-system changes, upstream discussions and a substantial engineering archive.
What it demonstrates
Compiler internals, platform bring-up, cross-compilation, linker behaviour, build systems, upstream stewardship and long-term technical continuity.
Additional public work
- Experimentalsourcemap-toolsSource-map visualisation and editing tools. (opens in a new tab)
- ExperimentalfarseeC11 RFB/VNC and RDP terminal client. (opens in a new tab)
- Experimentaltimui.hSingle-header C99 immediate-mode terminal UI. (opens in a new tab)
- ExperimentalpeernixPeer-to-peer Nix store sharing for macOS. (opens in a new tab)
- Landmarktoolchain-wrapperTarget-prefixed toolchain wrappers for Raspberry Pi, Android and iOS workflows around GHC and Haskell. (opens in a new tab)
How we work
The handoff is only useful when the work is inspectable.
Live overlap resolves ambiguity. Everything else is organised so another engineer can reproduce, review, reverse and continue the work.
Work in the client’s system.
Use the real repository, build and failure context. Record access boundaries before work starts.
Make evidence durable.
Keep reproductions, traces, benchmarks, decisions and known dead ends with the change—not in a meeting transcript.
Escalate decisions early.
Surface missing access, conflicting constraints and architectural trade-offs while live overlap is available.
Upstream deliberately.
Coordinate with maintainers when public changes are practical; document the private integration when they are not.
Engagements
Start with the smallest useful commitment.
Most engagements begin with a bounded problem, a concrete decision or a reviewable milestone.
Diagnostic sprint
Typical output. Reproduction, findings, options, risk assessment and a recommended implementation path.
Focused implementation
Typical output. Reviewed change, tests, documentation, operational notes and handover.
Embedded senior engineering
Typical output. Integrated ownership of a defined workstream, delivered in regular reviewable increments.
Upstream stewardship
Typical output. Upstream-ready changes, maintainer coordination, revision follow-through and a plan for any remaining private integration.
A good fit when…
- The failure crosses compiler, runtime, operating-system, build, CI, release, or deployment boundaries.
- The team is losing time to uncertainty, reproduction failure, or specialist bottlenecks.
- A technical owner can provide access and make—or escalate—the necessary decisions.
Probably not the right fit when…
- The requirement is generic application development or the lowest possible hourly rate.
- The request is undifferentiated staff augmentation with no bounded technical responsibility.
- The requirement is 24/7 operations or on-call support that has not been separately agreed.
Who does the work
Direct senior attention.
Moritz AngermannPrincipal Systems Engineer
Moritz has more than a decade of public work around GHC, Haskell, cross-compilation, linker behaviour, ARM64, build systems and open source. zw3rk applies that depth more broadly to compiler, platform and infrastructure problems where continuity and technical ownership matter more than headcount.
The person discussing the problem remains accountable for the technical result. Any additional contributors should be identified before they access client work.
The name blends Zwerg, the German word for dwarf, with Werk, meaning work or craft. The original dwarf head remains the company mark.
“Hard systems problems” is not a euphemism for complexity theatre. It means reducing an uncertain technical problem to reproducible evidence, a reviewable change and a decision the team can act on.
From the engineering archive
GHC, cross-compilation, linker behaviour and build systems.
Foundational writing, kept as dated evidence rather than presented as current news.
The tail of an off-by-one error in GHC’s linker
A non-deterministic AArch64 Mach-O failure, followed from CI symptoms into GHC’s internal static linker.
Read article (opens in a new tab)Building GHC: The stages
A practical explanation of bootstrap compilers, stage one, stage two and the package databases between them.
Read article (opens in a new tab)Why use a cross compiler?
Power, resource and environmental constraints—and the trade-offs between cross compilation and emulation.
Read article (opens in a new tab)Start with the hard part
Bring the problem everyone else calls “too niche.”
Share the environment, failure mode, constraints and outcome you need. We will first determine whether the problem is a fit, what evidence is missing and the smallest useful next step.