LibraryOdinLinux Mint

Amber LIB

The Amber Linux package library for Odin. Go-modelled package names. No package manager. Allocator-aware throughout. Import with amber:afs, amber:ahttp, amber:dbus.

import afs  "amber:afs"
import log  "amber:log"
import dbus "amber:dbus"
import pty  "amber:pty"

The name

Why Amber LIB?

Amber LIB is the single Amber Linux Odin library. The earlier split library pages described the same role from different points in the project: shared packages that fill the gaps between Odin's core library and native Linux Mint applications.

The name is now direct on purpose: Amber LIB is the library for Amber Linux. Code still imports through the Odin collection nameamber, so call sites stay short and readable:amber:afs, amber:ahttp, amber:dbus.

◈

Amber LIB in Odin

-collection:amber=./vendor/amber-lib

⬡

Naming philosophy

Package names mirror Go's standard library — fs,http, log, env. Familiar to any Go developer. Idiomatic for Odin.

◉

No package manager

Amber LIB is vendored directly into your project. Copy the packages you need. No fetching, no lockfiles, no surprises at build time.

Packages

Reference

StableBetaDevelopmentPlanned

Core

Core-only utilities modelled on the Go standard library.

Package	Description	Used in	Status
`amber:afs`	File and directory helpers: user dirs, home expansion, lexical absolute paths, and path expansion for files that may not exist yet.	Amberlin	Development
`amber:ahttp`	HTTP/1.1 server and client primitives on core:net: Serve_Mux, keep-alive, bounded workers, chunked streaming, and pooled clients.	—	Development
`amber:atime`	Compact duration formatting modelled on Go time.Duration.String, including sub-second units and negative values.	—	Beta
`amber:atls`	TLS API boundary over core:io.Stream. The public shape is present while the backend implementation is selected.	—	Planned
`amber:json`	JSON encode and decode. Allocator-aware; works with Odin's arena and pool allocators.	Ambrosia	Beta
`amber:log`	Structured logger with level filtering, key-value pairs, and optional ANSI colour output for terminal display.	kat800AmbrosiaAmber Theme	Stable
`amber:env`	Environment variable access and config-file loading. Reads .env files and XDG config paths.	kat800Ambrosia	Stable
`amber:strings`	String utilities complementing Odin's core:strings — split_lines, trim_indent, word_wrap.	—	Beta

Linux Desktop

Bindings and helpers for the Linux Mint desktop environment.

Package	Description	Used in	Status
`amber:dbus`	DBus session and system bus client. Method calls, signal subscription, and introspection. Used by Ambrosia.	Ambrosia	Development
`amber:gtk4`	GTK4 application helpers on top of vendor:gtk. Application lifecycle, window management, widget utilities.	kat800	Development
`amber:notify`	Desktop notifications via libnotify. Send, dismiss, and action-callback on desktop notifications from Odin.	—	Planned
`amber:xdg`	XDG Base Directory spec: config, cache, data, runtime directories resolved per the freedesktop.org standard.	kat800Ambrosia	Beta
`amber:gio`	GIO async I/O and GLib main loop integration. Needed for event-driven GTK4 applications.	kat800	Development

Agent & Process

Primitives for managing processes and terminal sessions — the engine behind kat800.

Package	Description	Used in	Status
`amber:proc`	Process spawn, signal, and wait. Fork/exec wrappers with pipe setup for stdin/stdout/stderr redirection.	kat800	Development
`amber:pty`	Pseudo-terminal pair allocation, resize (TIOCSWINSZ), and non-blocking master-fd polling. The PTY layer under kat800.	kat800	Development
`amber:pipe`	Named and anonymous pipe utilities. Connects agent stdout to Ambrosia, kat800 panes, and arbitrary consumers.	kat800Ambrosia	Development
`amber:agent`	Thin abstraction over a running AI agent subprocess: lifecycle, context injection, output streaming.	—	Planned

Usage

Amber LIB in practice

A small program that lists Ambrosia's clipboard entries over DBus, takes the latest, resolves an output path, and logs the result — using four Amber LIB packages and nothing else.

odinclipboard reader using amber:log · amber:afs · amber:env · amber:dbus

package main

import log  "amber:log"
import afs  "amber:afs"
import env  "amber:env"
import dbus "amber:dbus"

// Reads the latest Ambrosia clipboard entry and logs it.
// Every import is an Amber LIB package — no external fetching,
// no package manager, no version lockfile.

main :: proc() {
    logger := log.new_logger(.Info)
    defer log.destroy(&logger)

    config := env.get("AMBER_CONFIG", "~/.config/amber")
    log.info(&logger, "starting", "config", config)

    conn, err := dbus.session_connect()
    if err != nil {
        log.error(&logger, "dbus connect failed", "err", err)
        return
    }
    defer dbus.disconnect(&conn)

    entries, ok := dbus.call(
        &conn,
        dest    = "org.amberlinux.Ambrosia",
        path    = "/org/amberlinux/Ambrosia",
        iface   = "org.amberlinux.Ambrosia.Clipboard",
        method  = "List",
    )
    if !ok || len(entries) == 0 {
        log.warn(&logger, "clipboard empty")
        return
    }
    latest := entries[0] // newest first

    out_path, _ := afs.expand(env.get("AMBER_OUT", "~/clip.txt"), context.allocator)
    defer delete(out_path)
    log.info(&logger, "clipboard", "path", out_path, "bytes", len(latest))
}

How it is built

Written by AI agents, reviewed by a human

Amber LIB is largely written by AI agents — Claude, running inside kat800 sessions on a Linux Mint machine. This is not a disclaimer. It is the point.

Amber Linux exists to demonstrate what it looks like when AI agents are first-class tools on a local Linux desktop, not browser tabs pointed at a cloud API. Amber LIB is the most direct expression of that: the library that powers the tools was written by the tools' own workflow. kat800 runs the agent sessions. Ambrosia gives them persistent context. The agent writes Odin. A human reads, tests, and ships it.

The Go-modelled design is intentional. Go's standard library has one of the clearest, most consistent package interface styles in systems programming — every function name, every return convention, every allocation pattern follows a legible set of rules. Modelling Amber LIB on those rules means an AI agent can generate correct Amber LIB code from a Go example with minimal translation. It also means a developer already familiar with Go can read Amber LIB code without a learning curve.

Every package is expected to ship with tests before it is markedstable. Nothing reaches that label until it is used in production in at least one Amber Linux tool and has survived a full build and test cycle on Linux Mint.

⬡

AI writes, human reviews

Agent generates implementation. Developer reads every line, runs the tests, and makes the call on whether it ships.

◈

Go-modelled API surface

Package names, function signatures, and error conventions follow Go's standard library. Familiar to read; easy to generate.

◉

Grown from real use

Every package exists because a kat800 or Ambrosia feature needed it — nothing lands speculatively.

◧

Allocator-aware throughout

Every Amber LIB function that allocates takes an allocator. Arena, pool, stack — choose your memory strategy per call site.