Adding concerns about morality & protagonists to our design principles; fixing typos & whitespace
This commit is contained in:
parent
7e5c780075
commit
71369c06c9
2
PKGBUILD
2
PKGBUILD
@ -16,7 +16,7 @@ license=('custom')
|
||||
groups=()
|
||||
provides=("${pkgname}")
|
||||
conflicts=()
|
||||
replaces=("${pkgname,,}", "aninix-${pkgname,,}")
|
||||
replaces=("${pkgname,,}" "aninix-${pkgname,,}")
|
||||
backup=()
|
||||
options=()
|
||||
install=
|
||||
|
@ -31,9 +31,9 @@ For services that are hosting information like passwords, the device should be p
|
||||
## Privacy
|
||||
Guarantees of privacy are a major concern in designs. The AniNIX needs to be able to protect itself while doing its best to provide the same right to others. This ties in with concerns of Remote Access -- remote access that isn't by read-only transport requires an account which can be paired with an individual. This should be used for collaboration with the network and for maintaining user preferences.
|
||||
|
||||
However, tools like documentation and source code should be available from behind privacy tools and without identifying a user. When governments can outlaw information, as many repressive regimes in the Middle East and elsewhere have done, the AniNIX seeks to make sure that the peopke still have power by information.
|
||||
However, tools like documentation and source code should be available from behind privacy tools and without identifying a user. When governments can outlaw information, as many repressive regimes in the Middle East and elsewhere have done, the AniNIX seeks to make sure that the people still have power by information.
|
||||
|
||||
Furthermore, any communication across a wwider network should be encrypted. [WebServer](../Services/WebServer.md) controls most of this via the Let's Encrypt SSL certificate for the web apps, but SSH also encrypts its communication. Unencrypted communication is insecure and not private by default and should be prohibited as much as possible.
|
||||
Furthermore, any communication across a wider network should be encrypted. [WebServer](../Services/WebServer.md) controls most of this via the Let's Encrypt SSL certificate for the web apps, but SSH also encrypts its communication. Unencrypted communication is insecure and not private by default and should be prohibited as much as possible.
|
||||
|
||||
# End User Experience
|
||||
|
||||
@ -63,11 +63,21 @@ 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, documenation 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.
|
||||
|
||||
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 supercede the licensing or attribution of other packages -- applications, once installed, should only update the minimal allowable elements to be usable under AniNIX principles. Whereever 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.
|
||||
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:
|
||||
|
||||
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)
|
||||
1. The technological function being served, such as Password or DarkNet
|
||||
1. Cyber-themed science fiction with moral human protagonists
|
||||
1. This last is the most complicated but most fun category.
|
||||
1. Arguments must be clearly made in the etymology how the organization being selected is a commonly-accepted protagonist.
|
||||
1. The human-centric focus is to maintain alignment with the people using the systems.
|
||||
|
||||
# Maintainability
|
||||
Make sure that a project can be easily maintained. This means following the Development Best Practices and submitting Markdown documentation for the project.
|
||||
|
Loading…
Reference in New Issue
Block a user