Compile and install software

Compile and install software in Linux — with the four heights of help laid out: do it now, make it easier for the next person to accept, work out the right move when you are stuck, and learn the pattern so it stops coming back.

4prompt heights
Open it in the interactive atlas →

The four heights

The same task, four distances: today's deadline, the next reviewer, the stuck moment, the pattern.

Execute — do the immediate task

+
I need the new compression utility compiled and installed on the build farm. Pull version 2.4.1…
I need the new compression utility compiled and installed on the build farm. Pull version 2.4.1 source from the upstream tarball, compile with optimizations for x86_64, run the unit tests, install into /usr/local, update the symlink so the system uses the new binary, and verify the md5sum matches the artifact we built. Do those steps on build1 and build2 and report any test failures.

Improve — make it easier to accept

+
Before I build and install this on the fleet, make the package easy for reviewers. Put the compile…
Before I build and install this on the fleet, make the package easy for reviewers. Put the compile flags and target architecture up front, list test failures and how to reproduce them locally, make the install path and symlink change obvious, and flag any ABI or library version changes that would make a reviewer hesitate to upgrade on the build farm.

Decide — diagnose the stuck moment

+
I built and installed version 2.4.1 on build1; compile logs look clean and unit tests passed, but…

Compilation succeeded but the installed binary segfaults

I built and installed version 2.4.1 on build1; compile logs look clean and unit tests passed, but the binary crashes with a segmentation fault on startup. The QA lead expects a stable build for tomorrow; I do not know whether this is due to missing runtime libraries, optimization flags, or an untested code path. What is the most likely diagnosis and the fastest, least disruptive step to get a working binary for QA tonight?

Become — change the pattern

+
Over the last quarter we repeatedly produce builds that pass unit tests but fail immediately in…

We keep shipping builds that fail at runtime despite green compiles

Over the last quarter we repeatedly produce builds that pass unit tests but fail immediately in production or QA with runtime errors. Each time we chase environment differences and waste days. Where are we repeatedly making the same mistake, and what single practice change would catch these runtime regressions before a release goes out?

Next to this one

Other operating system work people do in Linux.

Every task here came from the work, not from a feature list — which is why the prompts name what you want done and never the button that does it. The tool changes; the work does not.
Copyright © LLOS.ai · 2026 — original pedagogy, voice, and design — all rights reserved.

The rest of the map

Same library, five ways in.