NAME
mouse —
guide to the MOUSE system
DESCRIPTION
MOUSE is a source-built workstation system using the NetBSD kernel and ABI and a deliberately selected base system called World. World includes the MERDE desktop and never includes pkgsrc. Bootstrap pkgsrc into /usr/local after installation when optional software is wanted; see ports(7). World can be built for AArch64, RISC-V 64, and x86_64. The release live installer and QEMU runner currently support AArch64 and x86_64; RISC-V 64 is experimental pending a fresh build, image, check, and interactive run.
This page is the root of the MOUSE manual tree. The following pages describe the system and its boundaries:
- hier(7)
- The filesystem layout and the ownership boundary between World, Ports, mutable state, and source trees.
- world(7)
- What MOUSE installs as World, why it belongs there, and where to begin with its commands and subsystems.
- wifi(7)
- How an administrator configures wired and wireless networking.
- ports(7)
- How optional software is obtained, built, installed, updated, and kept separate from World.
- installation(7)
- How to partition a disk and install MOUSE from live media.
- build(7)
- How to construct World, images, checks, and the manual website from /usr/src.
- development(7)
- Where MOUSE code and policy live, how external sources are managed, and which files are generated.
STARTING THE SYSTEM
cheesed(8) is PID 1 and hands service execution to OpenRC. rc.conf(5) is the sole persistent service-enable policy. Use rc-service(8) to inspect or operate a service and rc-status(8) to inspect runlevels.
With the default desktop stack, lidm(1) provides either a graphical MERDE login or a terminal login, according to lidm-config(5). The graphical session begins with merde(1); its configuration and control interfaces are described by merde-config(5) and merdectl(1). Without that stack, OpenRC starts a console login.
SYSTEM MAP
- Administration
- Start with intro(8), doas(1), useradd(8), passwd(1), and sysctl(8).
- Files and storage
- Start with hier(7), mount(8), disklabel(8), cgdisk(8), gpt(8), zpool(8), and zfs(8).
- Networking
- Start with wifi(7), ifconfig(8), route(8), dhcpcd(8), wpa_supplicant(8), ssh(1), and sshd(8).
- Software development
- World includes Clang, BSD make for the MOUSE graph, GNU make for upstream projects, pkgconf, Python, CMake, Git, and curl. See build(7) for constructing MOUSE, development(7) for changing it, world(7) for their place in the system and ports(7) for building optional software against them.
- Desktop
- Start with lidm(1), merde(1), merde-run-dialog(1), merde-bar(1), and havoc(1).
FINDING DOCUMENTATION
Use man(1) when a page name is known and apropos(1) to search page names and descriptions. intro(1) introduces ordinary commands and intro(8) introduces administration commands.
The installed MOUSE version is recorded in /etc/mouse-release.
MANUAL SECTIONS
MOUSE uses section 1 for user commands, section 5 for configuration formats, section 7 for system descriptions and procedures, and section 8 for privileged administration commands and daemons. Upstream pages retain their upstream sections. See intro(7) for the general manual-section conventions and development(7) for the MOUSE documentation policy.
RATIONALE
NetBSD provides MOUSE with a well-documented kernel and userspace ABI together with broad hardware support. Those properties make the substrate practical to understand, maintain, and bring to both of MOUSE's primary architectures without defining a new operating system interface from scratch.
pkgsrc was selected for Ports because it is well documented, has an extensive package collection, supports most Unix-like operating systems, and keeps both configuration and routine operation simple. Its portability also keeps package recipes separate from assumptions that only hold on MOUSE.
Routine local administration is deliberately attributable to a named user. The “root” and “toor” accounts are locked, members of “wheel” authenticate before doas(1) grants root privileges, and sshd(8) is disabled until explicitly enabled and then accepts public-key authentication only. The unauthenticated root shell on the physical console during catastrophic early-boot failure is the deliberate exception: if boot, service policy, or authentication has failed that severely, depending on a higher failed layer would make recovery impossible. Physical console access is therefore the final recovery trust boundary.
SEE ALSO
apropos(1), man(1), build(7), development(7), hier(7), ports(7), wifi(7), world(7), cheesed(8)