Compare commits
2 commits
b57633fba0
...
5efd795211
Author | SHA1 | Date | |
---|---|---|---|
|
5efd795211 | ||
2581265ded |
2 changed files with 31 additions and 23 deletions
|
@ -86,12 +86,21 @@ export default {
|
||||||
this.networkingDomain = ''
|
this.networkingDomain = ''
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
selectServices(services) {
|
selectServices(bundleId, services) {
|
||||||
services.forEach((s) => {
|
if (this.nixinBundles.includes(bundleId)) {
|
||||||
if (this.nixinServices.indexOf(s) === -1) {
|
services.forEach((s) => {
|
||||||
this.nixinServices.push(s)
|
if (this.nixinServices.indexOf(s) === -1) {
|
||||||
}
|
this.nixinServices.push(s)
|
||||||
})
|
}
|
||||||
|
})
|
||||||
|
} else {
|
||||||
|
services.forEach((s) => {
|
||||||
|
const index = this.nixinServices.indexOf(s);
|
||||||
|
if (index > -1) {
|
||||||
|
this.nixinServices.splice(index, 1);
|
||||||
|
}
|
||||||
|
})
|
||||||
|
}
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
@ -144,7 +153,7 @@ export default {
|
||||||
<div v-for="bundle in availableBundles">
|
<div v-for="bundle in availableBundles">
|
||||||
<label>
|
<label>
|
||||||
<input type="checkbox" v-model="nixinBundles" :id="bundle.id" :value="bundle.id"
|
<input type="checkbox" v-model="nixinBundles" :id="bundle.id" :value="bundle.id"
|
||||||
@click="selectServices(bundle.services)" />
|
@change="selectServices(bundle.id, bundle.services)" />
|
||||||
{{ bundle.name }}
|
{{ bundle.name }}
|
||||||
</label>
|
</label>
|
||||||
</div>
|
</div>
|
||||||
|
|
|
@ -1,28 +1,21 @@
|
||||||
# Technical principles
|
# Technical principles
|
||||||
|
|
||||||
ToDo: intro on best practices that drive the technical choices
|
This page lists the technical principles we adhere to for developing NixiN and the technological choices that we have made.
|
||||||
|
Most of the principles we list here are known best software development practices that are well documented on the web or in books. So we will not describe them in detail or argument on why we should follow them and they appear here only as title under which we are putting some technological choices
|
||||||
|
|
||||||
## KISS principle
|
## KISS "Keep it simple, stupid!"
|
||||||
"Keep it simple, stupid!"
|
|
||||||
|
|
||||||
## Do not reinvent the wheel
|
## Do not reinvent the wheel
|
||||||
ToDo: nixos
|
ToDo: nixos
|
||||||
ToDo: passwordstore
|
ToDo: passwordstore
|
||||||
ToDo: krops
|
ToDo: krops
|
||||||
|
|
||||||
## There is only one timezone
|
|
||||||
Experience has shown that using multiple time-zones for the servers of an infrastructure is a recipe for disaster.
|
|
||||||
Also, using the timezone of one country for an international project is a source of confusion and headaches.
|
|
||||||
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.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
## Eat your own dog food
|
## Eat your own dog food
|
||||||
The project is bootstrapped using an infrastructure that is based on Proxmox, Debian and YunoHost for hosting its website and git forge.
|
The project is bootstrapped using an infrastructure that is based on Proxmox, Debian and YunoHost for hosting its website and git forge. Currently only the forgejo action runners used for CI/CD are hosted on NixOS servers.
|
||||||
Currently only the forgejo action runners used for CI/CD are hosted on NixOS servers.
|
|
||||||
But the goal is to host the whole project using itself as soon as possible. That is using NixOS servers managed with the tools and principles developed within the NixiN project.
|
But the goal is to host the whole project using itself as soon as possible. That is using NixOS servers managed with the tools and principles developed within the NixiN project.
|
||||||
|
|
||||||
|
## Version control everything
|
||||||
|
|
||||||
## CI/CD
|
## CI/CD
|
||||||
|
|
||||||
## Focus on user experience
|
## Focus on user experience
|
||||||
|
@ -39,10 +32,16 @@ Only optimize what has been tested to be an issue.
|
||||||
## Do fast prototypes and releases cycles.
|
## Do fast prototypes and releases 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 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.
|
||||||
|
|
||||||
|
|
||||||
## ToDo
|
## ToDo
|
||||||
favor modern filesystems with snapshoting capability like zfs and btrfs
|
favor modern filesystems with snapshoting capability like zfs and btrfs
|
||||||
|
|
||||||
|
|
||||||
## To flake or not to flake?
|
## To flake or not to flake?
|
||||||
There is a bit of controversy around flakes. They bring some intereting 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
|
||||||
|
Experience has shown that using multiple time-zones for the servers of an infrastructure is a recipe for disaster.
|
||||||
|
Also, using the timezone of one country for an international project is a source of confusion and headaches.
|
||||||
|
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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
Loading…
Reference in a new issue