FNU — Foundry is Not Unix

A set of BSD-licensed software that helps OpenProninx grow without touching the GPL.

FNU is not a replacement for OpenProninx. It is a collection of software developed alongside OpenProninx — a supervisor, a health monitor, a kernel IPC device, a storage volume model. OpenProninx is the operating system. FNU is what runs on top of it and ties it together.

Why FNU exists

The GNU project and the GPL were built on a philosophy that source code must remain perpetually open and that any software touching GPL code inherits its terms. We disagree with this entirely. The GPL is not a freedom license — it is a restriction license that tells you what you must do with your own work. We want no part of it.

PRONINX, the predecessor to OpenProninx, had no service layer of its own. It was a bare kernel and shell. When Foundry Tech Inc. took over development as OpenProninx, the question became: what replaces the GNU userland tools that most Unix-like systems quietly depend on? The answer is FNU — built from scratch, BSD-licensed, no GPL lineage.

FNU stands for Foundry is Not Unix. The name is a deliberate echo of GNU's own recursive acronym, and the message is the opposite: where GNU layers restrictions on top of Unix ideas, FNU layers permissive software on top of an original kernel.

What FNU is

PSH (Proninx Shell) — the native interactive command-line shell of OpenProninx, built as part of the FNU userland. It exposes FNU service commands (services, health, start/stop/restart health) directly as built-ins, renders a user@PSH [/path] $ prompt, and replaces the old bare PRONINX shell.
fnufetch — a compact, BSD-licensed neofetch-style system information tool. Prints the fox logo next to OS, kernel, arch, uptime, process count, human-readable memory stats, userland identity, and an ANSI palette. Replaces the older minimal info built-in.
A service supervisor (fnusvc) that starts, monitors, and restarts registered services without a shell script or external init framework.
A health monitor (fnu-health) that periodically samples system state and makes it available to administrative commands.
A kernel IPC device (fnustate) that gives userspace services a place to read and write volatile state without touching the disk — essential for running cleanly on a read-only system image.
A named volume model (FNU Root, FNU Data) that gives storage roles a clear semantic rather than treating every block device as interchangeable.
A block device abstraction layer that sits above IDE, AHCI, NVMe, and the ramdisk without forcing each driver to know about the others.
A product identity framework (inc/product.h) that separates version, vendor, and name from the ABI headers.

What FNU is not

Not an operating system. OpenProninx is the operating system.
Not a GNU replacement project. We are not trying to reimplement bash, coreutils, or glibc. We are building what OpenProninx specifically needs.
Not a compatibility layer. FNU software is written for OpenProninx. It does not aim to run on Linux or any other system.
Not a package manager or distribution. There are no packages, no repositories, no update manifests in FNU.

License

Every FNU component is distributed under the BSD 3-Clause License, the same as OpenProninx itself. This is intentional and non-negotiable. No component will ever depend on GPL or LGPL code. If a required library exists only under GPL terms, we write our own or do without.

The BSD 3-Clause License permits use, modification, and redistribution with or without source, in any product, commercial or otherwise, with no obligation to publish changes. That is the level of freedom we consider acceptable.

Relationship to OpenProninx

FNU began development at the same time as OpenProninx. The kernel was written knowing that fnusvc would be PID 2; the FNU State device was added to the kernel specifically so the supervisor could communicate with the shell without a writable disk. They grew together.

This means FNU is not bolted on. The kernel exports FNU_STATE as a first-class character device. The virtual filesystem resolves /fnusvc.command and /fnusvc.status directly in the inode layer. FNU is the service architecture of OpenProninx — but it remains a distinct set of software with its own identity.

Component	Location	Role
PSH (Proninx Shell)	`user/sh.c`	Native FNU command shell — `user@PSH [/path] $` prompt, true `pwd` (via `getcwd(2)`), robust `cd`, fixed line editor, FNU service built-ins, command trees, execs external binaries.
`fnufetch`	`user/fnufetch.c`	Pretty system information — dual-size fox ASCII logos (scaled for small and large resolutions), live CPU hardware info, calibrated clock speeds, drives (via `diskinfo`), displays, RAM stats, and 16-color ANSI palette.
`fbset`	`user/fbset.c`	Framebuffer and display mode switcher — query supported adapter video modes and switch resolutions.
`init`	`user/init.c`	SysVinit-style PID 1 — handles boot bring-up and clean system teardown (FreeBSD-style death sequence).
`fnusvc`	`user/fnusvc.c`	Service supervisor — manages login instances across 4 Virtual Terminals (`/dev/tty1..4`) and supervised services like `fnu-health`.
`fnu-health`	`user/fnu-health.c`	Periodic health observer; writes uptime, processes, free RAM
`fnustate`	`kern/fnustate.c`	Kernel in-memory IPC device; three volatile channels
FNU DevFS	`kern/fs.c`	Virtual file resolution for `/dev/tty1..4`, `/dev/console`, `/fnusvc.*`, and `/.fnuhealth`
FNU Block Device	`kern/blockdev.{c,h}`	Unified read/write abstraction above IDE, AHCI SATA, NVMe, and ramdisk drivers
FNU Storage	`kern/storage.c`	Hybrid GPT volume model, FNU Root and FNU Data volume discovery and validation
Product Identity	`inc/product.h`	Name, version (Core 0.1.6-dev), vendor, and expansion string

FNU is growing — and it is partially replaceable

FNU is not finished. New components are added as OpenProninx needs them. There is no target feature list or compatibility promise — what goes in is whatever the system needs next, as long as it is BSD-licensed and written from scratch.

As for replacing FNU components: it depends on which layer you mean.

Component	Replaceable without kernel changes?	Detail
`fnusvc`, `fnu-health`, `fbset`, `fnufetch`	Yes, completely.	These are ordinary userspace processes. The kernel has no opinion about what PID 2 is. Write your own supervisor in any language, compatible or not — the kernel will not notice.
`fnustate` — in-memory IPC device	Partially.	The kernel calls `fnustateinit()` at boot and hard-codes the virtual paths `/fnusvc.command`, `/fnusvc.status`, and `/.fnuhealth` in the filesystem layer. Removing it requires editing four kernel files (`main.c`, `file.h`, `fs.c`, `defs.h`). Small edits, but they are there. You can replace it with your own IPC mechanism; the kernel will not break, but you have to do the wiring.
FNU Block Device (`blockdev.c`)	No — this is kernel infrastructure.	The UFS2 driver calls `blockdev_read` and `blockdev_write` in dozens of places. The storage discovery layer depends on it. The `FNU_` prefix in the header guards is cosmetic; the code itself is a core kernel component. Removing it breaks UFS2 and all optional storage volumes.
FNU Storage volume model (`storage.c`)	No — same reason.	This is the UFS2 volume discovery and validation layer. Without it, optional data volumes at `/data` do not appear. It can be extended or rewritten, but there must be something equivalent for UFS2 to function.
Product identity (`inc/product.h`)	Yes, trivially.	Four `#define` strings. Change them to anything.

In short: the userspace service layer is entirely yours to replace. The kernel IPC wiring requires a few lines of edits. The block device and storage layers are real kernel infrastructure and must be present in some form — they just happen to carry the FNU name because everything here was built together.