FREQUENTLY ASKED QUESTIONS
________________________________________________________________________________
May you find what you seek.
[0.0] Index
________________________________________________________________________________
- Why should I use KISS? [1.0]
- What does KISS mean? [2.0]
- Something something BUS factor of ONE. [3.0]
- Software [4.0]
- Why isn't SOFTWARE packaged? [4.1]
- Can you package SOFTWARE for me? [4.2]
- What init does KISS use? [4.3]
- What coreutils does KISS use? [4.4]
- Does DRM work in browsers? [4.5]
- Kernel [5.0]
- Why doesn't my kernel boot? [5.1]
- Why doesn't KISS support initramfs? [5.2]
- Why must I compile my own kernel? [5.3]
Must I keep the kernel headers package in sync with my kernel? [5.4]
- GCC [6.0]
- C compiler cannot create executables. [6.1]
[1.0] Why should I use KISS?
________________________________________________________________________________
That's up to you to decide.
[2.0] What does KISS mean?
________________________________________________________________________________
KISS is an acronym for "Keep it simple stupid" (notice _no_ comma).
Stupid does not refer to the user. To quote Wikipedia:
> The principle is best exemplified by the story of Johnson handing a team of
design engineers a handful of tools, with the challenge that the jet aircraft
they were designing must be repairable by an average mechanic in the field
under combat conditions with only these tools.
> Hence, the "stupid" refers to the relationship between the way things break
and the sophistication available to repair them.
[3.0] Something something BUS factor of ONE.
________________________________________________________________________________
Every user of the distribution owns their system in its entirety. The management
of the distribution which extends to the management of updates to the user's
system is entirely optional.
All KISS systems contain the full sources for the distribution and each user
has the means of managing and maintaining their machine on their lonesome (or
by forming a collective and secondary "upstream").
This includes:
* The repositories with full git history.
The repository updates are simply a 'git pull' which results in each user
having a full copy of the git repositories on their machine at /var/db/kiss/.
* The package manager and the kiss-* scripts.
As these are all simple shell scripts, the installed "binaries" _are_ the
unchanged source code. All of these are self-contained and separate programs.
The 'kiss-outdated' script allows one to check their system for outdated
packages against the repology.org database independent of whether or not
repology has support for KISS itself.
The 'kiss-export' script allows one to convert an installed package back into
a redistributable and installable binary tarball. Simply run
'kiss-export pkg_name' and a tarball will be created in the current directory.
* The distribution's documentation.
As the website sources are merely plain .txt files, the docs are available
in /usr/share/doc/kiss and are readable in less, vim or the program of your
choosing.
* The init scripts.
In addition to the reasoning given for the package manager above, KISS has no
lock-in regarding how the machine boots. Were the init scripts to disappear,
there would be no real loss.
To continue further, the init scripts need not change. There is no need to
update them. Any extensions to them can be made via the /etc/rc.d directory
or the /etc/rc.conf file.
What all of this means is that were the GitHub or website to go down, there
would be no loss in code, documentation or the distribution itself.
It also extends to each user having everything they will need to continue the
distribution for themselves or for other users. A change of git remote is all
that is needed in the latter case.
KISS was designed to be maintainable by a single person. The repositories are
kept small and focused. There is no requirement or _need_ for infrastructure of
any kind.
A user today could choose to go their own way with their system. Everything
they need is already in the existing system. The power is in your hands.
You are free.
[4.0] SOFTWARE
________________________________________________________________________________
[4.1] Why isn't SOFTWARE packaged?
____________________________________________________________________________
No one has packaged it yet.
[4.2] Can you package SOFTWARE for me?
____________________________________________________________________________
No.
[4.3] What init does KISS use?
____________________________________________________________________________
KISS uses busybox init by default. There is however, no lock-in and the user
may use whatever they like. The distribution's boot up scripts are written
in an init-agnostic way and act as a base for every init to use.
[4.4] What coreutils does KISS use?
____________________________________________________________________________
KISS uses busybox coreutils by default. There is however, no lock-in and the
user may use whatever they like. All shell code is written in portable POSIX
shell and coreutils invocations.
NOTE: Some utilities have no standard specification and where their use is
required, we adhere to common options between implementations.
[4.5] Does Widevine DRM work in browsers?
____________________________________________________________________________
No. The DRM is incompatible with KISS' C library (musl). Nothing can be
done to fix this as the DRM is not open source.
Workaround: Run your browser inside a chroot, sandbox, container, namespace,
virtual machine, etc (within a glibc based distribution).
[5.0] Kernel
________________________________________________________________________________
[5.1] Why doesn't my kernel boot?
____________________________________________________________________________
The kernel not booting can be a variety of issues. This is almost always
related to a configuration issue in the kernel, /etc/fstab or the
bootloader.
KISS doesn't use an initramfs so the configuration of the kernel may have
different requirements to other distributions.
1. The drivers for your disk controller, drives and filesystems must not be
built as kernel modules. They should be set to =y in your .config or [*]
when using make menuconfig.
Essentially, every driver the kernel requires to detect and mount the
drive containing the root filesystem, must be built as a part of the
kernel binary.
2. Multi-drive systems must use PARTUUID or UUID in place of /dev/sdXX in
the bootloader configuration to ensure that the kernel will find the
right drive.
[5.2] Why doesn't KISS support initramfs?
____________________________________________________________________________
KISS technically supports booting via an initramfs, it just doesn't require
or provide one. As a user you have the means to set this up yourself for
your system.
Full disk encryption is also possible without the use of an initramfs in
modern kernels (see dm-mod.create).
The initramfs concept is an ugly, complicated and largely optional mess.
Thank god it isn't a requirement.
[5.3] Why must I compile my own kernel?
____________________________________________________________________________
The kernel must be compiled by the user for a variety of reasons.
1. The user maintains full control over all aspects of their kernel and
further, their entire system. There is no lock-in into a specific set of
kernel sources, version, use of proprietary firmware, patches, config,
etc.
The user decides:
- Which kernel to use (sources and version).
- When to update their kernel.
- Whether to use proprietary firmware blobs.
- Which patches to use (if any).
- How the kernel is configured (endless options).
- How many kernels they'd like to keep.
- Compiler options (-O3, -march=native, etc).
You as a user might actually learn something too. You may come to
understand your hardware, what drivers it needs, how the kernel works
from a configuration perspective, etc.
You should have a better understanding of this part of the system
afterwards and you'll be able fix any issues at this level with relative
ease.
Remember, it's only hard the first time. Once a working config is
created, no further work should need to be done each time you update
your kernel.
If the new kernel version has an issue with your hardware, simply boot
another from your backups. If new hardware was added, simply run
'make menuconfig' and add what is needed.
I'll say what I always say. Nothing prevents anyone from providing kernel
binaries and an initramfs generation tool for KISS. Just don't wait on
the BDFL to do it for you.
2. Eases distribution maintenance for the BDFL. Shipping a generic binary
demands a humongous, module heavy configuration with support for
everything under the sun. An initramfs is then a requirement to boot
this damn monstrosity.
Then there'd be endless support requests for tweaks, additions and
removals to the distribution config and the burden of updating the kernel
on every release.
Does KISS ship the latest kernel? The long term support kernel? Both?
Some users require firmware so we'd need two separate binaries, one for
linux-libre and another for regular linux.
What if the latest kernel has issues on some hardware? New builds and
binaries must be released with backported patches.
It's a large maintenance burden for something which can simply be solved
by the user doing this themselves. The user maintains full control over
every aspect of their kernel and is solely responsible for it.
[5.4] Must I keep the linux-headers package in sync with my kernel's
version to maintain a working system?
____________________________________________________________________________
The kernel headers in KISS are pinned to an LTS kernel version and are only
updated when there are changes of interest in the kernel or headers
themselves (usually by users requesting new features available in the newer
headers).
The headers are backwards compatible and are fully usable with a matching or
_newer_ kernel version. There are two cases where you'd be required to
update the headers yourself.
1. To run a kernel _older_ than the default headers.
2. To make use of features in your _newer_ kernel version.
Further reading:
https://www.kernel.org/doc/Documentation/kbuild/headers_install.txt
[6.0] GCC
________________________________________________________________________________
[6.1] C compiler cannot create executables.
____________________________________________________________________________
This is almost always an error in your CFLAGS/CXXFLAGS. Ensure that you have
used -ONUM (CAPITAL O) and not (lowercase o) or (zero 0).
If the above doesn't fix the issue, try building the package with:
$ CFLAGS= CXXFLAGS= LDFLAGS= kiss b pkg
________________________________________________________________________________
Dylan Araps (C) 2019-2021
The registered trademark Linux(R) is used pursuant to a sublicense from the
Linux Foundation, the exclusive licensee of Linus Torvalds, owner of the mark
on a worldwide basis.