139 lines
6.8 KiB
Markdown
139 lines
6.8 KiB
Markdown
# The Void
|
|
|
|
_An opinionated dendritic nix configuration_
|
|
|
|
## The Concept
|
|
|
|
I have been trying to get consistent, across device experiences from the second that I
|
|
started using linux. I tried my best with arch, but I foolishly believed that just
|
|
remembering what packages I installed would be enough. Then I started managing my dotfiles
|
|
with GNU stow, but that only allowed for a single host per repo. I moved over to doot, and
|
|
simultaneously nixos.
|
|
|
|
I believed a dotfiles manager was my endgame. The final evolution, but it was far from
|
|
ideal. I had to manage a mess of dotfiles, submodules and nix packages that were
|
|
completely uncoupled from the apps that used them. Hyprland just assumed that I had all of
|
|
my apps installed, assumed that otter-launcher's config existed. Just by forgetting an app
|
|
or a toml file, I had the potential to brick my entire setup.
|
|
|
|
This is no longer the case.
|
|
|
|
The solution is similar to that of safely typed languages, like rust. Rust, instead of
|
|
having optional parameters like typescript, requires that a variable be passed to a
|
|
function, regardless of whether it contains anything. This leads to what is essentially a
|
|
fixed dependancy tree, where there are no points of failiure, only allowing for logic
|
|
errors and such. The same methodology can be applied to nix, using flake parts and wrapper
|
|
scripts.
|
|
|
|
Instead of defining the packages beside the app, and its config, you can use the config to
|
|
define the required binaries. By wrapping a config that contains a nix variable, ie a
|
|
binary, that binary is intrinsically linked to that config, and will therefore always be
|
|
installed. No more dependancy issues, and because the configs are defined within nix too,
|
|
no more potential for missing config files. Dotfile managers are no more, long live
|
|
dotfile managers. Any app with a `--config` flag can now be fully versioned and self
|
|
contained within one repo, config and all, accessible on any machine with nix.
|
|
|
|
One command for a truly reproducible, fully contained, configured system. This is the
|
|
endgame.
|
|
|
|
### Mandatory thing on AI
|
|
|
|
I am not completely against AI. However, asking an agent to write a load of code and then
|
|
posting it to reddit as if you made it yourself is disingenuous and (in my opinion) at
|
|
least slightly morally incorrect. Many a time I have seen a cool project on a subreddit
|
|
just for it to turn out to be ai generated garbage that I refuse to use out of principle.
|
|
|
|
I would go out on a limb and say that 99% of this codebase was written with no AI
|
|
assistance. Every config, every module, every obscure fix for a bug that only exists
|
|
because I'm using a dendritic pattern instead of being normal was programmed by hand by a
|
|
real human (yours truly). I'm not saying I had no assistance at all, there are sections
|
|
that are verbatim copied from the wiki of whatever app or language that I was using, but
|
|
by and large, no AI code has made it into this repo.
|
|
|
|
There may be commits somewhere saying that opencode refactored something, or that it
|
|
solved some obscure bug I was having, but after having those changes implemented for me, I
|
|
took it upon myself to understand what actually happened, in order to make maintaining
|
|
this config as easy as possible in the future.
|
|
|
|
This repo is not temporary. I daily drive this, and I intend to for many years to come.
|
|
Going forward, I will keep to the same standard of only using AI as a last resort, and
|
|
when needs must, only implementing and commiting changes that I fully understand and
|
|
could've eventually come to myself. Sometimes, at the end of a long coding session, a man
|
|
gets lazy. I could spend another 45 minutes fixing some quickshell update order bug, or I
|
|
could get deepseek to do it. In the end, it was a 5 line fix that, in hindsight, was
|
|
pretty obvious (lol).
|
|
|
|
## Usage
|
|
|
|
Usage is similar to any other flake, with everything in the module directory being an
|
|
output.
|
|
|
|
The folder structure is simply defined:
|
|
|
|
```
|
|
modules/
|
|
|- features/ - all available apps, every subfolder contains a seperate wrapped binary
|
|
|- attrs/ - attributes composed of other modules, no new features defined
|
|
|- system/ - basic system modules, no binaries. Should not be run standalone. (Think network and audio config)
|
|
|- hosts/ - available presets for machines. Output names match subfolder names, eg #HACKSTATION, and hostnames
|
|
```
|
|
|
|
### Nixos Configurations
|
|
|
|
Due to the host module referencing `/etc/nixos/hardware-configuration.nix`, so that it is
|
|
seperated from the repo, all rebuild commands will need `--impure`, unless you copy your
|
|
configuration into the repo.
|
|
|
|
HACKSTATION contains all features available (near enough), with mobile02 being a lighter
|
|
version of the system, looking the same visually, but with less bloat, only really having
|
|
firefox and a terminal.
|
|
|
|
It is recommended to clone the repo beforehand, but the system can be built directly from
|
|
remote. When cloning the repo, in order to properly evaluate the `vinix` and `nrs` shell
|
|
aliases, the config should be built from the directory you cloned it to, not from another
|
|
directory. When building from remote, or in any other scenario in which the `$PWD`
|
|
environment variable is not available, the zsh module will throw and evaluation warning,
|
|
but the build will not be hindered.
|
|
|
|
```bash
|
|
# Local Clone, . is the directory containing flake.nix
|
|
sudo nixos-rebuild switch --impure --flake .
|
|
|
|
# Build from remote
|
|
sudo nixos-rebuild switch --impure --flake "git+https://git.voidarc.co.uk/voidarc/nixos.git?ref=dendritic"
|
|
```
|
|
|
|
Both of these commands can be appended with a desired hostname in order to build that
|
|
configuration.
|
|
|
|
```bash
|
|
# Example of building mobile02 from a local repo
|
|
sudo nixos-rebuild switch --impure --flake .#mobile02
|
|
```
|
|
|
|
There is no default output, so if the current hostname doesn't match a host, you will get
|
|
an error. Building this config should be non destructive to any existing dotfiles, but
|
|
will remove all users (not home directories) from the system other than `user01`, who's
|
|
default password is `qwer`. No, that isn't my usual password.
|
|
|
|
### Binaries
|
|
|
|
Any binary can be run with the same base command (will change when merged to main)
|
|
|
|
```bash
|
|
nix run "git+https://git.voidarc.co.uk/voidarc/nixos.git?ref=dendritic#appname"
|
|
```
|
|
|
|
`appname` can be substituted for the name of any folder in the `modules/features` dir, ie
|
|
`kitty` or `otter-launcher`. Most if not all modules in a subdirectory will have a module
|
|
name corresponding to that directory. This only applies for `default.nix` files, so files
|
|
that have different names are not expected to follow this convention, even if there is not
|
|
ea `default.nix` in that directory.
|
|
|
|
## Issues and contributing
|
|
|
|
Because this is a private git server, there is no inline way to submit issues,
|
|
contributions, or feature ideas. If you should wish, you may send such requests to
|
|
<admin@voidarc.co.uk>, with the format found in CONTRIBUTING.md. Failure to follow the
|
|
format found there will most likely result in your email being ignored.
|