KISS GUIDESTONES

Below are a set of notes which make KISS... KISS. I felt the need to define in as much detail as possible philosophy behind the distribution.

There is no requirement to follow or even agree with my words. Some of the technical details for how packages are written will apply to package inclusion in the official repositories however.

Bear in mind, I develop and release KISS for free. I owe you nothing. Any help I provide is at my own discretion. KISS is my gift to you from the love of what I do. I hope you find it as useful as I have.

— Dylan Araps

These guidestones will be in perpetuity. Until a sufficiently good reason to alter them is provided (such as security concerns, kernel requirements), these will continue to be the guiding principles behind the direction of KISS.

— Dilyn Corner

USERS

• KISS is the vessel with which to shape your system in your own way and to optionally share your ideas with others.

• Every user has the means to keep their entire system up-to-date without the need for or reliance on the BDFL. Every KISS install contains the entirety of the repositories with full history.

• If a piece of software is missing, package it! If it is suitable for inclusion in the repositories, send a pull request. If it is not, keep it in your own repository and/or share it with others.

• Don't ask a question to ask a question. If you have a question, out with it or forever hold your peace.

• If you have a problem, think about it first. Present as much information as possible and logs if applicable. The more information given to those willing to help, the higher the chance and quicker the speed of resolution.

• Most importantly. LEARN TO LEARN. Don't jump into irc at a moment's notice. Try and solve the issue yourself first. Learn to solve your own problems, gain a better understanding over your system and take control. Be a doer.

KISS

• There must always be a sole commander-in-chief in charge of the distribution. There must never be a below governance structure.

• With great power comes great responsibility. The user must have some kind of brain in their skull and must exercise its use where necessary.

• Prefer less software over more software where possible. e.g If all a library does is make the cursor spin while waiting for a program to launch, it should be purged.

• Favour usability over ideals. If software B is simpler than software A but is missing essential functionality (for all users), software A shall be the default provider.

• User choice matters. Maintain this strict philosophy while at the same time keeping the ability to go against this philosophy open to all.

• The ends do not justify the means. A package, fix, feature or what have you will not be implemented if it requires gross hacks to accomplish.

• Only target the English language. English is the World Language. What we write our code in and what we use to communicate.

• All shell code must be written in a safe way, pass the shellcheck linter and match the style of any existing code.

• All distribution tooling and shell code must be written in a portable way. Otherwise, the user will be locked into a single coreutils and shell.

• One exception is made for sed -i as it is too useful to let go of. The -i flag has rather good support across implementations regardless.

• Avoid the next new shiny thing until or unless certain that it brings real improvements over what it is intended to replace.

• The above excludes versions of the same software. Software should always be kept up-to-date unless there is a blocker in doing so.

• Continue to work towards the removal of unneeded software, patching existing software or writing replacements if required.

• There shall never be rules centred around speech or the way in which one must carry themselves to communicate. Do unto others as you would have them do unto you.

OFFICIAL REPOSITORIES

• The number of packages in the repositories shall never exceed that which is maintainable by a single person with minimal effort.

• Any packages unsuitable for the repositories must be kept in user or 3rd-party repositories.

• The repositories (excluding Community) must remain a useful base containing everything up to a Graphical session with a browser and media player. They shall go no further.

• All software in the repositories must be F(L)OSS. See above point if proprietary software is needed.

• The build process of a package should not require a network connection, otherwise signature verification and checksums are useless.

• Avoid patches for single line changes. Patches require rewriting on changes of the sources whereas a simple call to 'sed' can stand the test of time.

• Avoid running autogen.sh or autotools in builds if pre-generated files already exist.

• Sources must use HTTPS where possible. If no HTTPS source is available one must be sought out or created by the BDFL of KISS.

• Install files to /usr/{bin,lib,share} always. The singular directory ensures simplicity and keeps KISS tooling and user scripts simple.

• The following list of software must never make its way into the repositories as their inclusion will open the floodgates for software which unoptionally depends on them.

  dbus, systemd, polkit, gettext, intltool, pulseaudio, pipewire, pam, wayland, logind, ConsoleKit, libsn, electron and all DEs.

• These above rules may apply to other software at the discretion of the BDFL.

• No package shall ship with telemetry enabled by default and if at all feasible it must be patched out entirely.

COMMUNITY REPOSITORIES

• The community repository is maintained by the users of KISS. Each maintainer is responsible for the packages they have opted to add.

• The BDFL's only responsibility is to review pull requests sent to this repository.

• Only the maintainer of a package is allowed to make any changes to said package. Don't send pull requests for packages you do not own.

• Contact the maintainer of the package via their set git email if you would like to report an out-of-date package or request changes.

PACKAGE MANAGER

• The package manager must not exceed 1000 lines of code. This number excludes blank lines and comments which make up around 50% of the program's current size.

• The user is smart, the package manager is dumb. The package manager is written under the assumption that the user has some kind of functioning brain in their skull.

• There are some things which can't be, shouldn't be, and won't be automated. Firstly, for my sanity. Secondly, for yours.

• Prefer extensibility through scripts over baking every additional feature into the package manager.

• Circular dependencies are a bug and not a feature. See: freetype-harfbuzz

INIT SYSTEM

• The user should not be tied to a single provider of PID 1. No unrelated piece of software should require a specific init be in use.

• No software violating the above rule shall be included in the official repositories as it paves the road for the inclusion of software that will explicitly depend on it.

• The boot and shutdown scripts shall be written in an init-agnostic fashion and work with all init systems which require it as a means of starting the machine.