What is this?
~~~~~~~~~~~~~
minibase is a set of small userspace tools for Linux intended to
boot the system and provide a lightweight but reliable foundation
to build the rest of the system on.

The tools are written in raw syscalls, statically linked, and have
no external dependencies, not even libc. Any reasonably recent gcc
or clang toolchain targeting the right CPU architecture can be used
to build the package. Once built, the executables should run on any
CPU-compatible Linux system providing the right syscalls (for most
tools, that means kernel version 3.x and above).

Currently supported targets: x86_64 arm arm64 rv64.


What's inside / Current status
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The project is highly experimental and (at this point) incomplete.
Some tools are missing, and some still need work.

  * Small basic unix tools (cat, ls, du, df etc).
  * Several small linux-specific tools (systime, sync, dmesg etc).

  * Simple non-interactive command interpreter (msh)
  * Early-stage boot utils (switchroot, modprobe, mount).

  * Non-encrypted block device locator (findblk)
  * Encrypted device locator and passphrase prompt tool (passblk)
  * Support tooling for disc encryption (dektool, dmcrypt)
  - No fsck for any fs yet.
  
  * Process supervisor suite (init, super, reboot, svc),
    split-stage implementation similar to daemontools or runit.
  
  * udevd stub.
  * syslogd and related tools.
  * Unprivileged mount tooling (mountd, pmount).
  * Controlled privilege escalation tool (sudo).

  * VT/DRM/input multiplexer (vtmux) aka that part of systemd-logind
    everyone keeps asking about [weston only atm].
  * Non-graphical greeter stub.

  * Networking interface manager (ifmon).
  * DHCP client (dhcp).
  * Wi-Fi (WPA2) supplicant and connection manager (wsupp).
  * manual interface setup tools (ip4cfg, ip4info) [incomplete].
  - No sntpd yet.

  - No package manager / download tool yet.

  - No interactive shell yet.

With everything in place, the system should be able to boot, on minibase
alone, up to the point where it's ready to download, install and start GUI.


How to build and try the tools
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To see how a proper build looks like, run

    ./configure
    make
    make install     # default DESTDIR is ./out

See https://github.com/arsv/miniroot for a bootable buildroot system.

To try the tools without booting anything, configure and build
the project in devel mode:

    make clean
    ./configure devel
    make

Most tools can then be run from their source directories.
Tools that need configuration often have devel-mode configuration right
in their respective directories. Modifying the code, rebuilding and trying
again should work as well.

Some (like ifmon) need root privileges, but should work just fine under su
on conventional systems from their source directories. The usual warnings
about running stuff as root apply.

The only big exception is vtmux. It cannot be test-run on a system that is
supposed to remain usable during the process. A standalone box with some
sort of remote (SSH) connection is the bare minimum.


What's the intended hardware for this?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
minibase is being written primarily with a personal laptop in mind.

This choice only affects certain tools (super, ifmon, vtmux) which either
allow or expect some user interaction. For unattended or headless systems,
it would be better to replace them with simpler equivalents, which may get
written at some point but are not a priority right now.


How is it different from busybox?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Busybox is a multi-call binary, minibase is a bunch of standalone
statically linked binaries.

Busybox provides mostly POSIX- or GNU-compatible tools.
Minibase is not meant to be compatible with either.

Busybox needs a proper libc toolchain to build, minibase only needs
a freestanding compiler and a linker. On the other hand, busybox can
be built for any target given libc supports while minibase only supports
four targets at this moment.

The set of tools is also quite different. Busybox provides more POSIX-style
text manipulation tools (grep, patch, vi) while minibase is mostly about
linux-specific system services (KMS VTs, network, disk encryption).


How is it different from common/GNU tools?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
About the same way busybox is, and minibase is not restricted by POSIX
compatibility concerns. It's effectively a different OS, a Linux but
not GNU/Linux, but one that still allows running parts of the GNU system
atop of it.

Unlike the GNU system (and to some degree busybox) minibase is designed
to not rely on suid bits or file capabilities. Anything that requires
privilege escalation in Linux is done via IPC to privileged services.


How is it different from systemd?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Smaller, simpler and easier to build. Much less dependencies.
Hopefully less invasive in respect to the system atop.
No D-bus, or any bus for that matter, only p2p IPC via unix sockets.

Different approach to system security. Minibase is meant for personal
computing devices while systemd apparently targets mainframes.


Compatibility
~~~~~~~~~~~~~
The tools are *NOT* meant to be POSIX-, GNU-, or anything else compatible.


Licensing
~~~~~~~~~
GNU Public License version 3, see COPYING.

Limited closed-box license (along the lines of Apache 2 w/ export restrictions)
may or may not get added in the future.

The code in lib/sys, lib/bits and lib/arch constitutes the public interface
of the Linux kernel. No claims are made for that code, and it should not be
copyrightable anyway. If unsure, grab corresponding fragments from either
the kernel sources (GPLv2) or the musl libc (MIT license).

The code in lib/crypto is mostly BSD-licensed. See README there.


Credits
~~~~~~~
The whole project was inspired and initially heavily influenced by busybox.
Certain decision from skarnet/s6 project also played significant role.

Syscall code (static inline functions with asm volatile blocks)
follows musl. Because musl folks got it right.

The Rust coreutils project provided great deal of inspiration,
specifically by showing how not to write coreutils.


See also
~~~~~~~~
https://busybox.net/
http://www.landley.net/toybox/
http://www.fefe.de/embutils/
http://skarnet.org/software/ (portable-utils, linux-utils)
http://suckless.org (ubase and sbase)
http://jdebp.eu/Softwares/nosh/
http://b0llix.net/perp/
https://swtch.com/plan9port/

https://www.gnu.org/software/coreutils/coreutils.html
https://www.kernel.org/pub/linux/utils/util-linux/
https://github.com/uutils/coreutils

https://github.com/mit-pdos/xv6-public (userspace tools)