NixiN/nixin-web
NixiN/nixin-web
2
1
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

typo
All checks were successful
deploy to prod / Build and deploy site (push) Successful in 38s
Details

Browse source
This commit is contained in:
Douze Bé 2024-10-04 10:36:17 +02:00
parent 7e53156e25
commit ccada8875e
1 changed files with 10 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

20
technical-principles.md
View file

@ -7,14 +7,14 @@ We regularly update this list of technological choices as the project develop
We will keep the system modular and keep the modules simples, following the [Unix philosophy](https://en.wikipedia.org/wiki/Unix_philosophy) and the [KISS principle](https://en.wikipedia.org/wiki/KISS_principle) We will keep the system modular and keep the modules simples, following the [Unix philosophy](https://en.wikipedia.org/wiki/Unix_philosophy) and the [KISS principle](https://en.wikipedia.org/wiki/KISS_principle)
## Do not reinvent the wheel ## Do not reinvent the wheel
Wehenever possbile we will use existing software instead of writing our own code. And will favor widlely accepted standards instead of inventing our own file format, protocols, languages or frameworks. Whenever possible we will use existing software instead of writing our own code. And will favor widely accepted standards instead of inventing our own file format, protocols, languages or frameworks.
- Obviously we will use NixOS as the base operating system - Obviously we will use NixOS as the base operating system
- For storing passwords and secrets we will use zx2c4 passwordstore coupled with a git forge
- We will use git for version control of source code and configurations - We will use git for version control of source code and configurations
- For the forge we will intially use forgejo. At a latter time we may add support for alternative forges that have a more distributed nature, like [Radicle](https://radicle.xyz/), when they become mature enough. - For storing passwords and secrets we will use zx2c4 passwordstore coupled with a git forge
- For the forge we will initially use forgejo. At a latter time we may add support for alternative forges that have a more distributed nature, like [Radicle](https://radicle.xyz/), when they become mature enough.
- For deploying NixOS to remote machines we are considering using [krops](https://github.com/krebs/krops). But we are still evaluating it. - For deploying NixOS to remote machines we are considering using [krops](https://github.com/krebs/krops). But we are still evaluating it.
- For formating disks we will favor modern filesystems with snapshoting capability like zfs and btrfs - For formatting disks we will favor modern filesystems with snapshotting capability like zfs and btrfs
- ... - ...
## Eat your own dog food ## Eat your own dog food
@ -29,7 +29,7 @@ Not only will we version control our source code, but we will integrate version
## Focus on user experience ## Focus on user experience
## Prioritize security ## Prioritize security
- only open ports that are strictily necessary on the public interface. go through a VPN for everything else - only open ports that are strictly necessary on the public interface. go through a VPN for everything else
- use fail2ban or reaction - use fail2ban or reaction
- use a passwords manager - use a passwords manager
- ... - ...
@ -38,16 +38,16 @@ Not only will we version control our source code, but we will integrate version
Use best practices to write efficient code but do not write overly complicated solutions based on a-priori thinking of performance issue. Use best practices to write efficient code but do not write overly complicated solutions based on a-priori thinking of performance issue.
Only optimize what has been tested to be an issue. Only optimize what has been tested to be an issue.
## Do fast prototypes and releases cycles. ## Do fast prototypes and release cycles.
Even though we think that Rust would be a better language for developing the tools of the project we are starting the first version using Go because it is faster to develop with it and easier to find contributors with this languages. Even though we think that Rust would be a better language for developing the backend components of the project, we are starting the first version using Go because it is faster to develop with it and easier to find contributors with this languages.
## To flake or not to flake? ## To flake or not to flake?
There is a bit of controversy around flakes. They bring some interesting convenience when using NixOS and have spawned an extensive ecosystem. But they are not without drawbacks. We have decided to not use flakes for now. But we'll keep our architecture open for the users who want to use them. There is a bit of controversy around flakes. They bring some interesting convenience when using NixOS and have spawned an extensive ecosystem. But they are not without drawbacks. We have decided to not use flakes for now. But we'll keep our architecture open for the users who want to use them.
## There is only one timezone ## There is only one timezone
Experience has shown that using multiple time-zones for the servers of an infrastructure is a recipe for disaster. Experience has shown that using multiple time-zones for the servers of an infrastructure is a recipe for disaster.
Also, even if usning a single timezone, using the timezone of one country for an international project is a source of confusion and headaches for people. Also, even if using a single time zone, using the timezone of one country for an international project is a source of confusion and headaches for people.
Especially when that timezone is subject to daylight saving changes that are causing the clock to jump 1 hour forward or backward twice a year. Especially when that timezone is subject to daylight saving changes that are causing the clock to jump 1 hour forward or backward twice a year.
The only sensible choice is to set the servers time to UTC and to transalte the timestamps to the user's timezone when displaying them on an interface. The only sensible choice is to set the servers time to UTC and to translate the timestamps to the user's timezone when displaying them on an interface.
This is strongly opinion based. We may not not all agree on the subject. This is why we will make sure that it is easy for the users to choose their prefered timezone for setting up their servers. This is strongly opinion based. We may not not all agree on the subject. This is why we will make sure that it is easy for the users to choose their preferred time zone for setting up their servers.