Here’s a detailed page about the philosophy behind vanilla.
The project consists of simple tools with minor knowledge and time to master.
For example: vanilla does not ship many tools to perform configuration or automated processes, instead the user has full control over the system and use editors to configure the system.
Following this principle, the init system which is vinit won’t detect service dependencies and start them automatically. Instead, the user simply change the SERVICES variable in the /etc/vinit.conf file. No
systemctl enable nor
rc-update or any other tool to learn.
While vanilla loves and embraces the UNIX principles, it also tries to deliver modern software and technologies. As such, we focus on providing recent packages and keep deprecated ones out. Example, while Python 2 is provided yet for some projects that are still not Python 3 compatible, it will be removed once it is no longer needed.
As an other modern principle, vanilla does not produce x86 releases and all architectures are strictly no-multilib.
Another modernity choice, vanilla does not follow FHS but instead uses a rather simple hierarchy:
A lot of modern distributions do rolling-release (including Void, Arch, Gentoo). While this can be convenient for people who wants bleeding edge technologies, it can also be inefficient or frustrating. Example, you have installed a distribution in January and realized in May that you need some other programs. You’ll probably have to update the system because your local package cache is outdated and your new program is now depending on a system library which also has been updated. Then, if you have local program you may also need to rebuild all of them.
Instead, vanilla provides fixed versions released every year with new updates for people who wants modern packages but with stability during a specific release. Furthermore, ABI/API is honored and thus user is able to rebuild packages for customization purpose without any risk of shared libraries being broken.
Along with the fixed releases, version are supported until N+3. This means if 6.0 is released, 5.0 and 4.0 gets still security fixes but 3.0 gets EOL’ed.
On the other hand, people who really wants to have a bleeding edge system can simply run the development version which is similar to those distributions.
In the emergence of embedded devices and small platforms, vanilla makes ARM a first class citizen with prebuilt packages for both arm and aarch64 architectures.
All packages and tools provided by vanilla are opensource. vanilla does not contain any kind of non-free repository, thus there is no nvidia driver provided at all.
Scripts, files, tools and software that is written by vanilla developers are covered under the well known ISC license which permits absolutely free reuse without any cost.
Also, in contrast to some other distributions, vanilla ships ffmpeg or other packages that are opensource but with some constraints.
As the distribution name suggests: packages are kept as close as possible to upstream to match installation as if done directly by the user. What changes that vanilla performs are:
_tss), see below.
Also, there is no policy against packages that are provided. For example, emulators are shipped while some distributions have strictly forbidden them.
Like Gentoo, vanilla can be customized with ease by rebuilding packages. All packages are built in both binary and source form. The binary package is the direct usable package meant to be installed on the system while the source package provides essential files including the upstream sources to rebuild the package from source.
Also, the command incoming
vpod command which is what poudriere is to FreeBSD is meant to perform mass rebuild for a whole vanilla build from scratch.
The vanilla distribution is dedicated to be lightweight by default. Package dependencies are kept to the bare minimum following upstream defaults and other dependencies are always marked as optional. Thus if you install CMake but don’t need or use
cmake-gui then you don’t have to install Qt 5 and all of its dependencies.
The reference C library is musl and the final goal is to have LLVM as compiler and toolchain instead of GNU. All packages are built using libc++, libc++abi, libunwind and compiler-rt from LLVM unless they are not compatible with those yet.
Note: in contrast to popular belief, LLVM is more lightweight than GCC.
Vanilla does not follow the mainstream hype of doing declarative init scripts. Instead it uses custom pure POSIX shell scripts with our very own minimalist init system. In contrast to declarative scripts, shell scripts allows you to define your own commands for several purposes (e.g.
/etc/vinit.d/postgresql init). Plus, since the init scripts are considered as configuration files they are perfectly editable by the system administrator for more customization.
Also, it stays simple and does not use any tool. The main boot script will simply invoke the user defined scripts listed in the /etc/vinit.conf file without any dependency check.
Development and UX style encourages strong coding conventions. For example, there is a convention regarding what tools are supposed to output and the same style is applied to the whole init scripts. Even though it’s purely cosmetic thing it improves user experience by having clean and well designed homogeneous distribution.
Also, you will see that package options are also standardized to unique names for a easier customization.
Example, the following options are available for many packages:
Some software require their own UNIX users and groups to operate. We explicitly create or alter their names to start with an underscore when they are meant to be totally private and not used by the end user.
For example, openssh uses
_sshd rather than upstream’s default
sshd. This has the benefit to be clear at a glance which users and groups can be manipulated by the end user.
Packages are not split into different parts (like -doc, -dev, -dbg), they are provided as if installed manually. On the other hand,
vpk will offer an exclusion system which allows excluding files while installing packages. In that way it’s easier for the user to skip non essential files such as GNU info, headers, documentation or manual pages.
Packages are also kept entirely in their pure form. A few exception may happen for large packages that provides both utilities and libraries. The util-linux, llvm and elfutils come to mind but this is evaluated per package and avoided as much as possible.