# Ubuntu 24.04.3 LTS "Daily Driver" Documentation — Independent Review & Refinement ## The Short Version We have a near-complete, well-structured setup guide for a reproducible Ubuntu Desktop 24.04.3 LTS developer workstation. It works. It's been tested by its author. Now we need fresh eyes: someone who will provision a brand-new VM, follow every instruction exactly as written, document every stumble, and then help us take it from "good" to "insanely great." This documentation will become the public front door to an open-source project we're building — the first thing any developer sees. It needs to be worthy of that moment. --- ## Required Background Prior job experience has demonstrated "jedi level" excellence in a prior project. You treat infrastructure as craft and documentation as art. For this engagement specifically: you also know how to break things. You can follow instructions literally, spot what's missing, and articulate why it matters. ## Skills & Background Desired ### Technical - Ubuntu 24.04 LTS (daily driver level comfort) - Bash scripting (you can read and reason about idempotent, fail-fast shell patterns) - Package management: apt, Snap, Homebrew on Linux - Python virtual environments (uv preferred, venv acceptable) - VSCodium or VS Code extension management - Rudimentary Rust/Cargo installation and environment configuration (or willingness to learn quickly) - Runme.dev or similar literate devops tooling (or willingness to learn quickly) ### Critical Thinking & Editorial Judgment - Ability to follow instructions *exactly as written* without unconsciously filling in gaps from personal knowledge - Eye for sequencing errors, ambiguous phrasing, missing steps, and broken assumptions - Comfort articulating *why* something is confusing, not just *that* it is - Clear, concise technical writing in English ### Documentation - Markdown proficiency (tables, code blocks, structure) - Ability to write atomic, step-by-step instructions - Comfort with screenshot creation and annotation ### Skills and interests that will matter for future projects (not required for this initial engagement, but a significant plus) No one person will have all of these — nor do we expect them to. This is a map of where the work is heading. Familiarity with several of these areas (and curiosity about the rest) is what we're looking for. - Linux CLI tool installation, configuration, and troubleshooting beyond the basics - GitHub repository administration (branch protection, collaborator management, Actions/CI/CD workflows) - Claude Code — hands-on usage experience - GSD (Get Shit Done) for Claude Code — hands-on usage experience or willingness to learn - Google ADK (Agent Development Kit) — hands-on usage experience or willingness to learn - Curating external learning resources (finding the single best **existing** tutorial or video for a given topic) - Odoo Community Edition — on-premise installation (via remote VPN), accounting module activation while remaining "pure open source", system administration, backup strategy (including Google cloud-based standby), and ability to write end-user "how-to" guides for new non-technical bookkeeping staff transitioning from Intuit QuickBooks - Cloud system administration fundamentals Future work involves documenting and integrating AI-assisted workflows — spanning software development, document management, and operational automation — built on top of the daily-driver foundation. --- ## What You're Receiving Upon hire, you will be given access to a private GitHub repository containing a polished, Runme-compatible Markdown guide authored by another team member. The guide covers: - System prerequisites and dependency installation - Rust toolchain (custom install paths) - VSCodium (via Snap) with telemetry hardening - Homebrew for Linux (dev CLI tools) - Runme CLI + VSCodium extension - yt-dlp + ffmpeg (media tools) - MarkItDown (via uv/Python) - An embedded Rust utility (gemini-to-md) for converting Google AI Studio JSON to Markdown The documentation is organized into manual steps (environment setup) followed by automated Runme-executable blocks. It includes a beginner-friendly appendix. It has been tested by me on VMWare Workstation Pro VM. Your job is not to rewrite it — it is to stress-test it, identify gaps, and then refine it into something exceptional. --- ## Phase 1: Independent Blind Review 1. Provision a fresh Ubuntu Desktop 24.04.3 LTS virtual machine (any x86-64/AMD64-compatible hypervisor — I use VMware Workstation Pro). 2. Follow the README from top to bottom, exactly as written, as if you have zero background on this project 3. Do not skip steps. Do not improvise. Do not fix problems silently. If a step is ambiguous, do what a bright-but-literal 11-year-old would do: try exactly what the words say, and note what happens. (Note: this documentation targets two audiences, which is explained further in Phase 2 below.) 4. Document every friction point: failures, confusing phrasing, missing steps, incorrect paths, sequencing issues, broken image references, anything that slowed you down or required you to "figure it out" 5. Deliver a concise written summary (roughly 2 pages) of your findings, impressions, and prioritized recommendations **Deliverable:** approximately 2 pages of honest, unvarnished feedback. Not a rubber stamp. I'm paying for your critical judgment. --- ## Phase 2: Refinement to "Insanely Great" Phase 2 begins only after Phase 1 is complete and we've discussed your findings. The documentation must serve two audiences simultaneously: 1. **A bright, determined 11-year-old** — every step is explicit and self-contained. Nothing is assumed. This doesn't mean simplistic; it means atomic clarity. For calibration, watch this 3-minute video: https://www.youtube.com/watch?v=KNKgBBn_Fsg — notice how the narrator explains what a "left click" does before asking the user to do it. That's the bar. (We won't use video — only words and screenshots in Markdown.) 2. **A wandering "Jedi" DevOps engineer** — someone who lands on this repo, skims the README, and thinks: *these people care about craft. I want to contribute.* The documentation should be clean, professional, and radiating quiet competence. Serving both audiences in one document is the hardest part. I feel the current version does it reasonably well. Your job is to close the remaining gaps. ### Phase 2 Principles - **Preserve the existing voice and structure** unless you have a strong, clearly articulated reason to change it. This is refinement and gap-filling, not a rewrite. - **"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."** — Antoine de Saint-Exupéry - Take whatever time you need. Cost is not a concern for Phase 2. "Insanely great" is the only deadline. ### Phase 2 may include (but is not limited to): - Adding missing screenshots with annotation - Fixing sequencing or path issues found in Phase 1 - Improving beginner-friendliness without patronizing experts - Expanding or refining the appendix - Ensuring all Runme blocks are properly named, idempotent, and executable - Polishing prose for clarity and concision --- ## Hard Constraints (Non-Negotiable) ### 1. Backward Compatibility is Paramount Existing machines running this setup will not be updated. Any changes to paths, environment variables, or tooling choices would create drift. Unacceptable. Locked decisions include: | Item | Current Implementation | Do NOT Change | |------|----------------------|---------------| | Rust paths | `~/rust/rustup` and `~/rust/cargo` | No defaults | | Editor | VSCodium via Snap | Not VS Code | | Dev CLI tools | Homebrew | Not apt/snap for these | | Python tooling | uv with `~/.venvs/` | Not pip/conda | | App packaging | apt + Snap + Homebrew only | No Flatpak | ### 2. Ubuntu 24.04.3 LTS Only Target exactly Ubuntu Desktop 24.04.3 LTS — not earlier, not later, not server. ### 3. No Containerization No Docker, Podman, LXC, Kubernetes, devcontainers, or "run it in a container" approaches. ### 4. No Enterprise Complexity No AD/LDAP/SSO, no Puppet/Chef/Ansible Tower, no Terraform/Packer. ### 5. Runme.dev is the Engine All documentation must be Runme-compatible Markdown executable from VSCodium. --- ## How We Work - **Communication:** Freelancer.com chat. I respond within 12 hours, often much faster. - **Pace:** Non-urgent. This is a marathon, not a sprint. I have a full-time day job; you probably do too. That's fine. - **Version control:** GitHub private repo. PRs welcome but not required — whatever fits your workflow. - **Feedback style:** I give candid, sometimes verbose feedback. I welcome the same in return. I have strong preferences but change my mind when persuaded. - **Creative friction is expected and welcome.** I will sometimes disagree with your recommendations. That's by design, not disrespect. The best documentation emerges from honest debate. --- ## Post Phase 2 A long-term, indefinite engagement is envisioned for the right person. The skills listed under "Skills and interests that will matter for future projects" above reflect where this work is heading. --- ## References ### Core Stack (this project) - Runme: https://runme.dev/ - Ubuntu 24.04.3: https://releases.ubuntu.com/24.04/ - VSCodium: https://vscodium.com/ - Homebrew on Linux: https://docs.brew.sh/Homebrew-on-Linux - Rust / rustup: https://rustup.rs/ - uv (Python package manager): https://docs.astral.sh/uv/ - yt-dlp: https://github.com/yt-dlp/yt-dlp - ffmpeg: https://www.ffmpeg.org/ - MarkItDown: https://github.com/microsoft/markitdown ### Future Projects (background reading, not required now) - https://docs.anthropic.com/en/docs/claude-code - https://github.com/gsd-build/get-shit-done - https://google.github.io/adk-docs/ - https://docs.github.com/en/actions - https://en.wikipedia.org/wiki/Odoo