KISS đź’‹  News  Blog  Install KISS  Team  Guidestones

Screenshots  Package System  Testimonials  Style

FAQ  Software  Contact  Donate  Wiki  GitHub ->

+-------------------------------------------------------+
|                                                       |
|                  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                                       |
|                                                       |
+-------------------------------------------------------+

+-------------------------------------------------------+
|                                                       |
|                       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   |
|   opens 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.            |
|                                                       |
| * The same rules above 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 and  |
|   secondly, for yours.                                |
|                                                       |
| * Prefer extensibility through scripts over baking    |
|   every additional feature into the package manager.  |
|                                                       |
+-------------------------------------------------------+

+-------------------------------------------------------+
|                                                       |
|                    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.                                        |
|                                                       |
+-------------------------------------------------------+

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 world­wide basis. (C) Dylan Araps 2019-2020 View page source