Projects
A collection of applications, services, themes, and tutorials for sharing AI agents on top of Linux Mint Cinnamon on X11.
Applications
Native Linux Mint Cinnamon apps designed around the stable X11 desktop people actually use.
Services
DBus and system services that expose your machine's context — clipboard, notes, files — to local agents.
Themes
Cohesive desktop themes that respect Mint's slower, steadier visual language instead of fighting it.
Libraries
New Odin libraries and package surfaces for building modern native tools on an older, reliable Mint base.
Amberlin
AppA GTK chat client and AI harness, in development: models on your own GPU or a DGX Spark on the LAN, one D-Bus call away from every Mint application — with desktop context from Ambrosia.
Amberlin Settings
ToolWhich model Amberlin runs, and whether this machine can run it: the quantisation, CPU or CUDA, the video memory it wants and the bytes still to fetch — with an estimated figure never dressed up as a measured one.
Ambrosia
ServiceEverything you've copied, run, opened, bookmarked or noted — searchable, one keypress away. Six domains, one D-Bus contract (org.amberlinux.Ambrosia).
Copal
AppThe desktop overlay: one keypress covers the screen with everything in the Ambrosia store — notes, bookmarks, clipboard, recent files — magnified under wherever you are looking. Copal is the still-workable resin, Ambrosia the hardened amber.
Amber Theme
ThemeFive desktop profiles for Linux Mint from one token pipeline — GTK 3, GTK 4, libadwaita, the Cinnamon shell, window borders and folder icons. Phosphorus, the default, is the 1980s amber CRT homage.
Amber Odin
PackageA Debian package wrapper for the upstream Odin compiler. Installs a predictable /usr/bin/odin on Linux Mint without colliding with Ubuntu's unrelated odin package.
Amber LIB
LibraryThe Amber Linux package library for Odin. Go-modelled packages for filesystem paths, HTTP, DBus, GTK4, PTYs and more, with allocator-aware APIs throughout.
Built for the desktop that stays useful
Amber Linux celebrates Linux Mint's pace. Cinnamon on X11 is not old-fashioned here; it is the stable target that makes native tools worth finishing. Amberlin is the current proof: a GTK4/Odin chat client with a pure-Odin AI back end — local text, speech and transcription through hand-written ONNX Runtime bindings — built with shared Amber libraries for the Mint desktop that already works.
Stable desktop target
Linux Mint Cinnamon on X11 gives Amber Linux a desktop contract that changes slowly enough to build against seriously.
Modern libraries, older base
Amberlin uses the newer Amber LIB and GTK4/Odin bindings while still fitting the older, dependable Mint desktop people already run.
Native over novelty
The point is not to chase every display-server or toolkit trend. The point is to make local AI tools feel native on a real Mint machine.
Odin — the Amber language
Amber Linux is written in Odin — a systems programming language created by Ginger Bill over the last ten years. Every tool in the stack — Ambrosia, Amberlin, Copal, Amber Theme and Amber LIB — is built with a predictable Amber Odin compiler package and shared Odin collections. Amberlin now uses those newer libraries on the same steady Linux Mint Cinnamon X11 base the rest of the stack targets. Together they make my case for Odin as a first-class choice for native Linux Mint applications: near-C performance, C bindings that need no scaffolding, and code that is a pleasure to read and write.
Near-C performance
Odin compiles to native machine code with no garbage collector and no hidden allocations. Memory is managed through explicit allocators — arenas, pools, stacks — that you choose per-subsystem. Linux Mint applications written in Odin have the same runtime profile as their C equivalents, with far fewer of the footguns.
C bindings without scaffolding
The foreign keyword makes calling any C library a matter of a single declaration. GTK4, libvte, GLib, DBus-GLib — the entire Linux desktop stack is immediately available. No wrapper generators, no FFI scaffolding, no C header translation scripts. Declare it, call it, ship it. Amberlin's back end proves it at scale: I bound the ONNX Runtime C API by hand — every entry of its function table, offset-checked against the header — and it now drives three neural networks on the desktop, so Amberlin can speak, listen and answer locally.
Beautiful syntax
Odin reads like the language I always wished C would become. Procedures, packages, distinct types, multiple return values, tagged unions, and a context system for allocators and logging — all expressed without boilerplate.
Linux-native by design
Odin's core library includes POSIX bindings, a core:sys/linux package for direct syscalls, and first-class support for building shared libraries. Everything you need to write applications that integrate with the operating system rather than working around it.
package amber_app
import "core:fmt"
import gtk "vendor:gtk/gtk4"
// C bindings: declare with the foreign keyword and call immediately.
// No scaffolding. No wrapper generation.
@(default_calling_convention = "c")
foreign gtk.lib {
gtk_window_set_title :: proc(win: ^gtk.Window, title: cstring) ---
gtk_window_present :: proc(win: ^gtk.Window) ---
}
// Multiple return values instead of exceptions or error types.
// The caller decides what to do with the failure case.
read_clipboard :: proc() -> (text: string, ok: bool) {
raw := ambrosia_latest_clip() // org.amberlinux.Ambrosia.Clipboard over D-Bus
if raw == nil { return "", false }
return string(raw), true
}
activate :: proc(app: ^gtk.Application, _: rawptr) {
win := gtk.application_window_new(app)
gtk_window_set_title(win, "Amber App")
if clip, ok := read_clipboard(); ok {
fmt.printfln("Clipboard context loaded: %s", clip)
}
gtk_window_present(win)
}
main :: proc() {
app := gtk.application_new("com.amberlinux.example", .FLAGS_NONE)
defer gtk.g_object_unref(app) // defer: cleanup on scope exit
gtk.g_signal_connect(app, "activate", activate, nil)
gtk.application_run(app, 0, nil)
}Ginger Bill's ten-year achievement
Odin is the work of Ginger Bill (Bill Hall), who began the language around 2016 with a conviction that systems programmers deserved something better than C — not a language that hid what it did behind abstractions, but one that was honest, fast by default, and genuinely pleasant to write. No hidden allocations. No surprise garbage collection pauses. No boilerplate inherited from decades of backwards compatibility decisions nobody wanted to own.
Ten years later, Odin is a mature, production-ready language with a comprehensive core and vendor library, a compiler that produces excellent code, and a reputation in the game development and systems programming communities for being the language people actually enjoy coming back to. That is a rare thing. I find Odin a language I look forward to working in — most languages are tools you tolerate.
Amber Linux bets on Odin as the right foundation for native Linux Mint software. The vision is simple: Odin should be the first language a developer reaches for when they want to write a Linux Mint application — not because there is no choice, but because it earned the spot.