310 lines
14 KiB
Markdown
310 lines
14 KiB
Markdown
+++
|
|
title = "Baguette - OS, tools and stuff"
|
|
+++
|
|
|
|
# Baguette OS - concise overview
|
|
|
|
Baguette OS status: Work In Progress.
|
|
A beta will be available circa mid-2020.
|
|
|
|
## Objectives, for simple users
|
|
|
|
BaguetteOS aims at provide a simple unix-like system, with an **unified web interface**.
|
|
|
|
**No command-line required for simple users.** *let users be just users*<br />
|
|
Simplicity should not only comes from an interface, but be inherent to the whole system.
|
|
If the OS is simple, there is no need to hack it.
|
|
|
|
**Unified interface is better than features.**<br />
|
|
We will provide the basic features then build up.
|
|
We do not want a patchwork of very different software, each of them having their own particularities.
|
|
|
|
**Online services.** *day-to-day use*<br />
|
|
The web interface should cover online services, providing an unified experience for main usages: mails, calendar, instant messaging, personal website, file sharing, etc.
|
|
|
|
**One-click management.** *service installs, updates, etc.*<br />
|
|
The web interface should handle basic system and network configurations, such as adding users, dhcp, DNS, backups, etc.
|
|
|
|
**Well-known, reliable software.**<br />
|
|
BaguetteOS relies on robust and independant software.
|
|
At no point the user should be forced to reinstall, a borked configuration has to be easily fixed.
|
|
|
|
**Hardware support.** *new or old, fast or slow, it doesn't matter*<br />
|
|
We provide support for RPi and other small cards: if our kernel runs on it, it has to work.
|
|
Minimal hardware requirement should be around 100 MB RAM, 50 MB disk.
|
|
|
|
**Documentation.** *simple, reliable, useful, all-in-one-place*<br />
|
|
Similar to the OpenBSD FAQ: updated, complete, concise and well-written.
|
|
|
|
## Objectives, for advanced users and contributors
|
|
|
|
**A knowable OS.** *simplicity at (almost) all cost*<br />
|
|
Any interested user should be able understand the role of every part of the base system: no compromise.
|
|
This means having a very small and consistent set of tools, easy to learn, easy to remember.
|
|
|
|
**Basic system and network management.** *with the simpliest tools ever*<br />
|
|
We provide a web interface that should handle basic system and network configurations, such as adding users, firewall management, dhcp, DNS, backups, etc.
|
|
CLI tools are available to manage your services, they are design to be simple, consistent and reliable.
|
|
|
|
**Robust system.** *for real*<br />
|
|
Static compilation for system tools *(at least)*: there is almost no way to get a borked system with an update (yes, almost, people are creative these days).
|
|
|
|
**Officially supported and documented services.** *so you are sure to get them working*<br />
|
|
We use some services for our own personal usage, so we will provide support for them.
|
|
For instance: gitea, postgresql, a building plateform and a continuous integration tool, etc.
|
|
|
|
**Simple to contribute to.**
|
|
We want fewer and simpler tools as possible: Baguette OS has very few requirements, and automatic verifications.
|
|
Baguette OS do not suffer from any cumbersome historical decisions: no overly engineered package format, no stupidly complex tooling, etc.
|
|
|
|
**One need, one tool.** *this time for real*<br />
|
|
Installing an application or a library is done by [package][package].
|
|
Other methods are not supported **and the base system will never require them**.
|
|
We avoid to rely on `pip`, `cpanm`, or other third party package manager and dependency tree.
|
|
More on that in the [technical section](#technical-choices).
|
|
|
|
Starting, stopping, or configuring a service is done by [service][service].
|
|
This program alone is used to manage services on the OS.
|
|
Users should not be required to manually configure each software; instead, most of the configuration should be done upstream using templates.
|
|
Users should be able to change the default configuration through command-line options.
|
|
Manual configuration is the last option.
|
|
|
|
**Slotting.**
|
|
[Slotting](#slotting) by default helps to install many programs with peculiar library version requirements.
|
|
No difference between stable and development versions.
|
|
|
|
**Easy to write documentation.**
|
|
Online documentation is written in Markdown (thanks Zola), and man pages too thanks to `scdoc`.
|
|
Every tool is shipped with a man page: no man page, no integration in base.
|
|
|
|
## OS content
|
|
|
|
- kernel: linux + headers (but most of the system should be kernel-agnostic)
|
|
- libc: musl, but any other libc can be easily added
|
|
- init: sysv init
|
|
- /etc/rc: CRUX-like
|
|
- coreutils: `toybox` (or `busybox`)
|
|
- shadow (todo: check if not already included in busybox)
|
|
- building tools:
|
|
- LLVM + Clang
|
|
- autotools (for sysv init and libarchive)
|
|
- libarchive
|
|
- `m4` (required at least for bootstrapping)
|
|
- make: `gnu-make` for compatibility reasons
|
|
- shells:
|
|
- `zsh` for users (not root by default)
|
|
- `ash` (because of busybox) or `ksh`
|
|
- documentation:
|
|
- a full hand-book like the OpenBSD FAQ
|
|
- manpages, written mostly with `scdoc` so anyone can contribute
|
|
- our tools
|
|
- services: [service][service]
|
|
- package management: [package][package]
|
|
- packaging: `packaging`
|
|
|
|
## Inspiration
|
|
|
|
- OpenBSD: security, therefore simplicity, no compromise
|
|
- PFSense: system and (even advanced) networking administration, yet through a simple website
|
|
- Plan9: everything is a file *no seriously guys*
|
|
- suckless and cat-v: simplicity, code readability and reusability
|
|
- morpheus: static compilation for the OS, demystified
|
|
|
|
# Baguette OS - detailed explanation
|
|
|
|
## Features and objectives
|
|
|
|
|
|
## custom tools
|
|
|
|
- [package][package]: package manager
|
|
- basics: install, remove, search and provide informations about a package
|
|
- rootfs creation
|
|
- used by `packaging` to create low-cost build environments<br />
|
|
[package][package] knows the minimal set of binaries and configuration required to build the target, so it only installs the minimal environment to perform compilation.<br />
|
|
This environment is low-cost since we hardlink binaries into the building rootfs.<br />
|
|
Inspired by the *proot* tool on OpenBSD.
|
|
- slotting by default: no need for custom environments for each software
|
|
- packages format:
|
|
- .tar
|
|
- meta.spec
|
|
- files.tar.xz
|
|
- db format:
|
|
- world
|
|
- installed
|
|
- [package-name]/[slot]/manifest
|
|
- [package-name]/[slot]/meta.spec
|
|
- configuration:
|
|
- list of repositories
|
|
- authorized package signing keys
|
|
- packaging variables (cflags, makeflags, and so on)
|
|
- `packaging`: create packages
|
|
- uses simple, declarative recipe files
|
|
- create build environments to test packages before validation
|
|
- [service][service]: service management
|
|
- add an init script for a service, for a specified domain
|
|
- example: `service add wordpress example.com`
|
|
- the init script verifies if a configuration file is installed<br />
|
|
The configuration file is created if not present.<br />
|
|
Configuration templates are provided for all services.
|
|
- the service can be installed in a specific environment (read: a custom rootfs) ← NOT IMPLEMENTED (also, environments == domains atm)
|
|
- example: `service add wordpress example.com testingenv`
|
|
- `service` provides an unified way to configure the system<br />
|
|
It alleviates the need for manual configuration. For example, adding a wordpress service will automatically change the `nginx` configuration, create a new database and a new user in `mariadb` for this specific service.<br />
|
|
If several `nginx` are required, ports will be registered and automatically managed for each instance, no need for user input.<br />
|
|
Behind the scene, it's a simple token system with configuration templating!<br />
|
|
No heavy machinery here, and we'll keep it that way.
|
|
- `build.cr` (temporary name): Makefile creation
|
|
- create makefiles from simple declarative configuration file
|
|
- can replace most build systems
|
|
- FIXME: design something using .spec format
|
|
- `tap-aggregator`: quality assurance & test results aggregation
|
|
- `webhooksd`
|
|
- automatic verification of the recipes on new application or library version
|
|
- automatic cross-compilation (x86_64, ARM, others will follow)
|
|
- `libipc`: an IPC communication library
|
|
- currently used for
|
|
1. the administration dashboard
|
|
2. the web interface for the services
|
|
3. `todod` (a kanban) 4. several other tools we use for collaboration
|
|
- provides a way to communicate between clients and services
|
|
- uses simple unix sockets behind the scene
|
|
- transparent remote communications
|
|
- clients and services do not need remote communication
|
|
- any client can join remote services via any communication protocol
|
|
- any service is implicitly accessible from anywhere, anyhow
|
|
- C library with Crystal bindings (other languages coming soon)
|
|
- we create services, not libraries<br />
|
|
Therefore, languages are irrelevant: you can use any *library* in any language.
|
|
|
|
|
|
## <a name="technical-choices"></a> Technical choices
|
|
|
|
**Linux kernel**, but we are lurking on the OpenBSD one.<br />
|
|
Linux is compatible with most hardware and software, it is fast and we can easily compile a custom version to remove most of the bloat for server usage.
|
|
Still, we don't want to rely on Linux-specific components.
|
|
At some point, our system will be kernel-agnostic and will be able to run on any BSD as well.
|
|
|
|
**Musl libc.**<br />
|
|
It has a reasonable amount of features, it is efficient, provides reasonable binary sizes and static compilation.
|
|
Musl is simple, reliable and remove all glibc-specific functions.
|
|
Others can be added easily, which is useful for compatibility and comparisons, through [slotting](#slotting).
|
|
|
|
**Bootable system and rootfs available.**<br />
|
|
A bootable system to install in virtual machines or bare metal, a rootFS to use BaguetteOS from any other OS, including non-Linux ones.
|
|
|
|
**SysV-style init + CRUX rc**.<br />
|
|
The init could come from toybox or another minimalist project.
|
|
No systemd BS.
|
|
|
|
|
|
**Slotting.**<br />
|
|
|
|
**Custom file system hierarchy.**<br />
|
|
Our FS is not FHS-compliant, partially because of the origin-based slotting.
|
|
There is a strict separation between core system and third party software.
|
|
- */usr/baguette* for core system programs
|
|
- */usr/bad* for unslottable software
|
|
- */usr/third-party* for other software
|
|
|
|
**Crystal language for system tools.** *Syntax and productivity of Ruby, the speed of C*<br />
|
|
It is as simple to learn as a dynamic language, while at the same time being almost as fast as C.
|
|
Technically, Crystal is strongly typed which catches errors at compile-time, but with type inference so it is not cumbersome to use.
|
|
Applications are compiled in a simple (static) binary, easy to deploy.
|
|
There is a good documentation, we used it for long enough to tell.
|
|
Technical choices are reasonable and documented.
|
|
Finally, Crystal has a large library with all we need for our system components.
|
|
|
|
- coreutils: busybox<br />
|
|
- */etc/rc/*: forked from CRUX<br />
|
|
- Building tools<br />
|
|
- LLVM + Clang
|
|
- tar -> bsdtar
|
|
- webhooks (libarchive), cpio -> bsdcpio (libarchive)
|
|
- autotools (for SySV init and libarchive)
|
|
- m4
|
|
- make: gnu-make (since it is required for many projects)
|
|
- `crystal` since we use this language for our tools in the base system
|
|
- shells<br />
|
|
- sh -> zsh
|
|
|
|
## Still in discussion
|
|
|
|
For the simple users, we want to provide an unified web interface to manage the system and online services.
|
|
We currently use `Crystal` to work on service back-ends for a variety of projects, we are satisfied on a technical level and we are productive, it is highly probable we continue using it.
|
|
The front-end is still in discussion: we currently use `livescript` and it is way more usable than plain JS, but it is painful to debug.
|
|
|
|
So, we need a language for both administration dashboard and online services, here some examples we find interesting for the job:
|
|
- Purescript
|
|
- haskell-like syntax, with a smaller set of notions
|
|
- strongly typed, with type inference
|
|
- good documentation
|
|
- useful compilation errors
|
|
- no runtime error
|
|
- Elm
|
|
- as Purescript but with way fewer documentation
|
|
- less generic code
|
|
- still very young
|
|
- WASM
|
|
- seems to be a very young tech, with no real good language or documentation
|
|
- Zig has wasm as a Tier 1 support, we should investigate
|
|
|
|
# <a name="slotting"></a> Providing software: the right way
|
|
|
|
The usual way to provide software is to maintain a version of a software or a library, package it into a distribution, then provide it as *the* OS version of the software.
|
|
In the long run, software and libraries change, which is no big deal since maintainers verify the consistency of the different versions provided by the OS.
|
|
TODO
|
|
|
|
**Problem:** what happens when two programs need a different version of a library?
|
|
|
|
**Problem:** what happens when two libraries are compatible but you want both on your system (see libressl and openssl)?
|
|
|
|
**Problem:** what happens when you want to provide a **very** long term support for your users (see companies running decade-old databases)?
|
|
|
|
Baguette OS has a simple and safe way to let users and maintainers provide packages: `slotting`.
|
|
Official OS packages are installed under `/usr/baguette/`, for non-essential programs.
|
|
Here, the slot is `baguette`.
|
|
Any package outside the official ones are in another named slot.
|
|
|
|
TODO
|
|
|
|
**This in nothing new, however not often used, and still maybe the best way to handle the problem.**
|
|
|
|
|
|
- usual directories under root: bin, sbin, lib, boot, dev, proc, sys, home, mnt, root, run, tmp
|
|
- etc
|
|
- rc
|
|
- services
|
|
- environments
|
|
- templates
|
|
- var
|
|
- cache
|
|
- srv
|
|
- "env-name" (see [service][service])
|
|
- etc
|
|
- data
|
|
- cache
|
|
- run
|
|
- usr
|
|
- local: things that are installed by the local system administrator without using packages
|
|
- baguette: things provided by the system that are not necessary for it to run (and boot, and restart, and do system things)
|
|
- "repo"
|
|
- lib
|
|
- libexec: try to avoid using it whenever possible. May or may not stay.
|
|
- bin
|
|
- share
|
|
- man
|
|
- include
|
|
- bad: things that cannot be properly installed or slotted somewhere else
|
|
|
|
# Roadmap
|
|
|
|
We currently aim at providing a rootfs with our tools, when we will have enough spare time to contribute.
|
|
|
|
|
|
|
|
[service]: https://git.baguette.netlib.re/Baguette/service
|
|
[package]: https://git.baguette.netlib.re/Baguette/package
|
|
[packaging]: https://git.baguette.netlib.re/Baguette/packaging
|
|
|