AniNIX/Wiki
AniNIX/Wiki
3
0
Fork 0
Code Issues 9 Pull Requests 3 Releases Activity

Further rewrite on etymology

Browse Source
This commit is contained in:
DarkFeather 2024-03-30 15:14:19 -05:00
parent 4ce7f84632
commit f67cbe3b8f
Signed by: DarkFeather
GPG Key ID: 1CC1E3F4ED06F296
1 changed files with 3 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
Policies/Design_Principles.md
View File

@ -63,13 +63,11 @@ With the rise of the smartphone, remotely accessible services should offer a sim
## Etymology
The AniNIX attaches a unique name, such as Sora for OpenLDAP or Yggdrasil for Emby, to packages and services it instantiates. The reason for this is that the name defines a scope of functionality the AniNIX expects to rely on -- should the underlying package change, such as replacing Plex Media Server with Emby, documentation and AniNIX packages will use the same name.
The AniNIX attaches a unique name, such as Sora for OpenLDAP or Yggdrasil for Emby, to packages and services it instantiates. The reason for this is that the name defines a scope of functionality the AniNIX expects to rely on -- should the underlying package change, such as replacing Plex Media Server with Emby, documentation and AniNIX packages will use the same name. We also need a naming convention for unique code we are writing, like Uniglot & TheRaven
Names given should be chosen for relevance to the function being provided (Singularity being a pull service, Foundation being the basis on which we're built, etc.) and for ease of memory. Only the most basic services, such as IRC, WebServer, and SSH, will be left unnamed.
These names are not intended to supersede the licensing or attribution of other packages -- applications, once installed, should only update the minimal allowable elements to be usable under AniNIX principles. Wherever possible, this should be done via the application's provided interface, such as enabling dark modes. We also should not remove any links that the application provides to its own documentation, licensing, or websites. This means that AniNIX etymology only applies to administrators and is otherwise invisible to end users. Where the AniNIX is deploying services created by others, we should only use the names in two places: DNS and Kapisi roles. This makes it possible for others to look up the service as we swap out tools without overriding the attribution once the service is accessed.
These names are not intended to supersede the licensing or attribution of other packages -- applications, once installed, should only update the minimal allowable elements to be usable under AniNIX principles. Wherever possible, this should be done via the application's provided interface, such as enabling dark modes. We also should not remove any links that the application provides to its own documentation, licensing, or websites. This means that AniNIX etymology only applies to administrators and is otherwise invisible to end users.
Additionally, these names should be selected from one of the following categories:
Names given should be chosen for relevance to the function being provided (Singularity being a pull service, Foundation being the basis on which we're built, etc.) and for ease of memory. Only the most basic services, such as IRC, WebServer, and SSH, will be left unnamed. Additionally, these names should be selected from one of the following categories:
1. A natural phenomenon that describes the function, such as Singularity or Aether
1. Mythological figures that provide wisdom (such as Odin for Yggdrasil, Raven, and Wolfpack), truth (like Wiccan Grimoire), and morality (such as Maat)