Dev guide

2026-04-03 05:43:13 -04:00
parent 2d26a0b8d1
commit 6259c25d4c
25 changed files with 1207 additions and 25 deletions
@@ -0,0 +1,65 @@
+# Chapter 7 — “Apps” beyond the shell (what is realistic today)
+
+Bare OS does not have an app store, sandboxed widgets, or a second GUI runtime inside the image. An **application** here is usually:
+
+- a **workflow** built from the **shell**, **`/bin`** tools, and files on the **personal** drive; or  
+- a **custom kernel** + utilities; or  
+- a **host Pear app** that changes boot behavior.
+
+This chapter orients you without over-promising.
+
+---
+
+## The default “app”: shell + `/bin` + git
+
+Most user goals are met by:
+
+- Scripts in **`$HOME`** (`run(ctx, argv)`).
+- Pipelines and redirection (simulated stdin/stdout).
+- **`git`** for repositories on the VFS (see [Handbook ch.8](../handbook/08-git-on-bare-os.md)).
+
+That is the **intended** application platform for end users.
+
+---
+
+## initd and background flavor
+
+The booter registers **initd**-style disposers via [`bare-initd.js`](../packages/bare-os-booter/lib/bare-initd.js). The stock system uses this lightly (e.g. kernel logger). **Extending** this usually means **host** booter changes: register a start function during `executeKernel`, not from arbitrary `/bin` scripts.
+
+Read [`bare-initd.js`](../packages/bare-os-booter/lib/bare-initd.js) before adding long-running tasks—teardown must be explicit (`stopBareInitd`).
+
+---
+
+## Cron
+
+**`crontab`** stores user jobs; the scheduler invokes **`ctx.execLine`** per job. “Apps” that need periodic behavior can install cron lines—again, expressed as **shell lines**, not separate processes.
+
+---
+
+## HDMS and `/mnt`
+
+After identity unlock, optional **HDMS** mounts may appear under **`/mnt`**. Utilities use **`ctx.vfs`**; HDMS integration is advanced and covered narratively in the handbook (identity + HDMS chapter). User scripts should prefer **`vfs.readFile`** / **`writeFile`** over hard-coding drive objects.
+
+---
+
+## Replacing the kernel
+
+A heavier “app” might ship a **different `/boot/init.js`**—for example a menu-driven UI using **`readLine`** or a non-interactive worker when **`BARE_OS_SKIP_REPL=1`**. You still have the **single JavaScript realm** per session; there is no fork into a second Bare process from inside the image.
+
+---
+
+## When you actually need a new Pear app
+
+If you need **multiple OS images**, **custom networking**, or **native addons** not suitable for `AsyncFunction` utilities, create a **new Pear application** that embeds or forks the booter pattern—this is **host** development (Chapter 1), not `/bin` development.
+
+---
+
+## See also
+
+- [Chapter 3 — Kernel](03-kernel-boot-init.md)
+- [Handbook — Booter runtime](../handbook/04-the-booter-runtime.md)
+- [Handbook — Identity, vault, HDMS](../handbook/05-identity-vault-and-hdms.md)
+
+---
+
+[← Extending /bin](06-extending-bin-coreutils.md) · [Testing →](08-testing-and-debugging.md)