voidarc/nixos
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

added prettierrc and formatted readme

Browse Source
This commit is contained in:
voidarc
2026-08-16 10:57:52 +01:00
parent 9764a025a9
commit c0a5c4312f
2 changed files with 100 additions and 28 deletions
Download Patch File Download Diff File Expand all files Collapse all files

120
README.md
View File

@@ -1,38 +1,75 @@
# The Void
*An opinionated dendritic nix configuration*
_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.
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.
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.
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.
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.
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.
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
@@ -43,12 +80,21 @@ modules/
### 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.
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 is the heavier system, mobile02 is minimal and has no specialist hyprland config.
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.
It is recommended to clone the repo beforehand, but the system can be built directly from remote
```bash
# Local Clone, . is the directory containing flake.nix
sudo nixos-rebuild switch --impure --flake .
@@ -56,19 +102,37 @@ 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.
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`.
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`
`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.