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.