EO Engineering Learning OS
CORE FOUNDATION · F01
Back to map ↑
NON-NEGOTIABLE FOUNDATION · TARGET L3 · 7–10 days
F01

Linux & operating systems

Operate an application by understanding the process, user, files, resources, ports, services and evidence beneath it.

01 / CONCEPT MAP

Know what the parts mean.

Learn each concept deeply enough to recognize it, place it in the system and reason about normal and failed behavior.

01

Filesystem hierarchy and paths

Define it · locate it · observe it · explain its failure mode.

02

Users, groups, ownership and permissions

Define it · locate it · observe it · explain its failure mode.

03

Processes, signals and resource use

Define it · locate it · observe it · explain its failure mode.

04

Services and systemd lifecycle

Define it · locate it · observe it · explain its failure mode.

05

Environment variables and packages

Define it · locate it · observe it · explain its failure mode.

06

Disk, memory, CPU and logs

Define it · locate it · observe it · explain its failure mode.

07

SSH and safe remote operations

Define it · locate it · observe it · explain its failure mode.

02 / SYSTEM FLOW

Trace it end to end.

Source files→Runtime user→Process→Listening port→systemd service→journal / logs→operator

For every transition: identify input, output, identity, protocol, state, trust boundary, evidence and owner.

03 / GUIDED BUILD

Build, observe and explain.

Documentation and AI are allowed. The engineer must review every output and demonstrate the result from direct evidence.

  1. 01Create a non-root application user
  2. 02Install and run FastAPI in a virtual environment
  3. 03Inspect PID, parent, user, files and listening socket
  4. 04Convert the process into a systemd service
  5. 05Set configuration through an environment file
  6. 06Reboot and prove automatic recovery
  7. 07Diagnose using journal and resource evidence
04 / INCIDENT

The service is active but unreachable after reboot. Inject a wrong working directory, missing environment variable and port conflict.

Required investigation

State impact → collect evidence → form competing hypotheses → test the cheapest discriminator → isolate root cause → contain → correct → verify.

Evidence pack

Timeline, relevant logs/metrics, failed assumptions, root cause, correction, verification and one prevention action.

AI ownership

AI may suggest causes and commands. The engineer must explain why each check is safe, what result is expected and how the result changes the hypothesis.

05 / DESIGN CHALLENGE

Defend the decision.

Define a production-ready Linux service boundary: user, directories, permissions, configuration, logs, restart policy and resource limits.

06 / VERIFY, SUBMIT & REVIEW

Submission evidence

Architecture review

  • Explain linux & operating systems without relying on memorized commands.
  • Draw the flow and name what crosses every arrow.
  • Identify the most likely, highest-impact and hardest-to-detect failure.
  • Show the evidence that proves the solution works.
  • Defend one security, reliability and cost trade-off.

Definition of Done

  • Acceptance criteria pass
  • Flow is drawn and explained
  • Security implications considered
  • Logs/metrics checked
  • Failure is tested
  • AI output is understood
  • Runbook is reusable
  • Mentor review passes
07 / MENTOR GUIDE

Do not score memory. Score the engineer’s ability to form a model, collect evidence, make a safe change and defend the trade-off.

1 Cannot explain2 Understands with gaps3 Implements and troubleshoots4 Designs and reviews