This past week I had a chance to look at a project I have been hoping to find time to try for a while now, KISS.
The project's website describes KISS as follows:
An ? independent Linux distribution with a focus on simplicity and the concept of less is more. The distribution targets only the x86-64 architecture and the English language.The website goes on to list a number of key features the KISS project provides:
- Uses a plain-text package system which is language agnostic and parseable with basic UNIX utilities.
- Uses a package manager written in 600 lines of POSIX sh (excluding blank lines and comments).
- Based on musl libc, BusyBox and the Linux kernel.
- All shell code is linted by and passes shellcheck (including each and every repository package).
- All packages are compiled from source by the package manager which automatically handles dependencies, patches, etc.
KISS seems to be crafted in such a way that the operating system will do very little automatically, leaving the user to build, install, and configure software in a mostly manual process.
Installing
The KISS project does not provide bootable ISO or IMG files. To install KISS we need another Linux distribution, or a live CD that can download a package and set up the KISS operating system in a chroot environment. First we download an archive that contains the KISS userland utilities. Then we can use the existing operating system or live CD to partition the disk, compile our own kernel, and install a boot loader.
The KISS environment is a 27MB download and we can optionally download a companion tool which sets up the chroot environment for us. We need to format a partition to use for KISS, mount it under a directory such as /mnt, unpack the KISS archive into this directory and then run the KISS chroot tool. This locks us into the KISS environment where we can run a series of commands listed in the project's documentation to set up the operating system.
From there we need to use the project's package manager, called kiss, to download, build, and install additional tools. These include filesystem support, the Linux kernel, optionally wireless networking tools, and a boot loader.
What I found was, after setting up a new partition and mounting it, all I was doing was copying and pasting commands from the KISS website into a terminal.
In essence just running "kiss build package ; kiss install package" over and over. It feels like this could all have been handled by a simple, one-page shell script which could have acted as a system installer for KISS.
Some people may read that above paragraph and conclude that I have entirely missed the point of KISS. The idea seems to be that the project does not do any hand holding and the user should do everything manually. After all, everything can be customized. However, I think there are three arguments against this line of thinking - and in favour of having a scripted installer. The first is that virtually everyone who installs KISS needs to run the same handful of commands, and will need to do so every time they go through the setup process. There is no variety or flexibility in the required commands, meaning there is no benefit to doing them manually. The second reason I would like to see this process scripted is it is easy for humans to make typos (which I did during one run-through) while a script never mis-types. My third argument is KISS provides a script to set up the initial chroot environment to assist users and avoid mistakes. If creating the chroot can be scripted, then why not the unchanging commands that immediately follow?
The philosophy of scripting installs aside, one of the few really manually parts of setting up KISS is downloading, configuring, and building the Linux kernel. We may optionally also need to download firmware blobs. How to do this is briefly covered in the KISS documentation, enough to probably get beginners through the process. However, customizing the kernel or enabling extra hardware support is not covered.
After that we need to install a boot loader (examples using GRUB to boot the operating system are shared in the documentation) and then we can exit the chroot and reboot the computer. Assuming we completed all the steps correctly and we do not need any special hardware support, then we should be able to boot into our new KISS operating system.
Early impressions
Assuming all went well during the setup process, KISS successfully boots into minimal, text-based environment where we can sign in as the root user. To be honest, the first time through I made a typo while installing GRUB and KISS (understandably) did not boot for me, but I was able to use the live environment and chroot to fix GRUB and get things working. Once we sign into the root account we can explore an environment that is mostly provided by BusyBox.
There are no manual pages, virtually no user accounts, background services, or a working network connection.
We do have access to a working compiler (thanks to the GNU Compiler Collection) and a small repository of software through the kiss package manager. We can use the dhcpcd command to enable networking, even setting this script to run at start-up to make our lives easier. Then we can use kiss to install new packages we need.
A fresh install of KISS used about 20MB of RAM on my machine and 3.2GB of disk space, including the kernel sources and firmware I had saved to the filesystem during the initial install. Once I had removed the source code and firmware packages KISS consumed about 1GB of disk space.
Software management
One of the few utilities the operating system includes is kiss, the package manager. The kiss utility can search for software in the project's repositories, download, build, and install new packages. It can also upgrade existing packages and list installed items. New packages are always built from source code.
The default repositories are quite small and this meant most of my searches for new packages returned no results. I found it easiest to browse the on-line repository from the project's GitHub account. If we need additional software there are third-party, community repositories with more software.
As KISS is a minimal operating system, the user is left to build on it and develop what they need.
We can turn KISS into a platform for just about anything, assuming we have the time and skills to install and configure the necessary software. There is virtually no hand holding though, we are expected to know what we are doing without manual pages, on-line support, or (for the most part) automation.
Conclusions
KISS is a project people will probably only want to use if they have a particular project or goal in mind. It is not particularly practical as a day to day operating system and, I would argue, it is not meant to be. The philosophy, work, and approach on display at the KISS project are all very interesting, and I will come back to those in a moment, but first I want to address the elephant in the room.
KISS, while described as a Linux distribution on the project's website, is not a Linux distribution by any definition I have encountered and I'd question whether it should be considered an operating system. There are three reasons I make this observation. The first is that KISS cannot bootstrap itself, it needs another operating system to get it up and running. Most operating systems can be booted from a DVD or USB thumb drive and install themselves. KISS requires we have a Linux distribution on hand to install it. This makes me question whether KISS is an operating system or, more likely, a meta operating system.
The second reason I believe KISS should not be considered a complete operating system (or a Linux distribution) is it does not include a kernel. Userland and package management tools are included, but there is no kernel by default. A kernel must be added separately by the user and it is hard to consider any project an operating system if it does not have a kernel included.
Which brings me to my third reason KISS is not a Linux distribution: the project does not distribute Linux. The KISS archive does not include Linux, and the package manager does not recognize any Linux package. KISS in no way provides or manages the Linux kernel which makes it very difficult to consider KISS a Linux distribution. Or even Linux-related, except that its userland is unlikely to work out of the box with any other kernel.
All of that is to say I do not think we can regard KISS as a Linux distribution or expect it to work like Linux distributions generally do. There is no direct apples-to-apples comparison we can make between a project like KISS and other do-it-yourself projects like Arch Linux or Tiny Core Linux.
An argument could be made that KISS is a meta distribution similar to Gentoo where users are expected to compile and customize their operating systems in detail with very little assistance.
KISS provides a distribution-like framework, like Gentoo, to help us craft our own operating system.
With all that being said, I do think KISS is a very interesting project and one worth looking at, especially if you are among those who feel operating systems are too bloated or enable too many features. KISS is really striving to trim the fat off Linux-based operating systems and related open source software, removing optional features and cutting out unnecessary tools. There is a patch provided in the KISS documentation, for example, which removes the need to have Perl installed before building Linux which nearly cuts the time required to perform the initial setup process in half. That is the sort of efficiency I can support.
The KISS project is always looking at ways to remove extra stuff users do not need, or that end-user programs do not require. The KISS blog often reports on changes to packages which greatly reduce their size, like this one which mentions Python's package size was trimmed by about 90-100MB. This work does not only benefit KISS users, the work is open source.
Any distribution, whether it is Fedora, Debian, or Arch can benefit from this kind of refinement. Upstream projects can also look at the work KISS is doing and cut out libraries or options which are not needed and which, when removed, do not negatively affect users.
All of this is to say that I am very intrigued and in support of the work the KISS project is doing.
I would certainly not want to run KISS on a workstation or server I was using day to day - the manual effort involved would drag my work to a crawl.
However, the work to reduce software size and improve performance that KISS is engaging in (and which is explained on the project's blog) will almost certainly benefit all of us in the long run.
I hope the packagers of mainstream Linux distributions are paying attention to KISS because we can all appreciate faster, slimmer software, especially if the features we use are still maintained.
