commit cc1b57129e055de0e766234b6a0f875ff89acd75
parent 41a823d9157ed9c88166765b210959e338360dd0
Author: phoebos <ben@bvnf.space>
Date: Tue, 28 Apr 2026 16:49:36 +0100
archive/Guidestones: convert to md
Diffstat:
2 files changed, 187 insertions(+), 193 deletions(-)
diff --git a/wiki/archive/Guidestones/index.md b/wiki/archive/Guidestones/index.md
@@ -0,0 +1,187 @@
+# 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.
+
+
diff --git a/wiki/archive/Guidestones/index.txt b/wiki/archive/Guidestones/index.txt
@@ -1,193 +0,0 @@
-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.
-
-
