Added Ollama+ZED editor

This commit is contained in:
2026-02-24 09:13:23 +01:00
parent 67cab4f26d
commit 54f21fe000
4 changed files with 701 additions and 166 deletions
+597 -166
View File
@@ -1,6 +1,5 @@
gf#+OPTIONS: toc:nil broken-links:t
#+PROPERTY: header-args :noweb yes :results silent :mkdirp yes
#+HTML: <div align="center">
#+HTML: <div>
#+HTML: <img src="./.github/images/nixos.svg" width="100px" alt="NixOS" />
@@ -29,8 +28,8 @@ gf#+OPTIONS: toc:nil broken-links:t
* Introduction
#+HTML: <div align="center"><img src="./.github/images/need to create screenshot.png" width="100%" alt="Screenshot" /></div>
This repository contains a literate NixOS configuration built using Emacs Org mode. The primary source of truth is this document itself, which embeds configuration blocks that are tangled into individual files. These generated files are evaluated as a NixOS flake, resulting in an immutable, reproducible system configuration.
#+HTML_HEAD: <style>code{font-size:1.2em;}</style>
This repository contains a literate NixOS configuration built using Emacs Org mode. The primary source of truth is *this document itself*, which embeds configuration blocks that are tangled into individual files. These generated files are evaluated as a NixOS flake, resulting in an immutable, reproducible system configuration.
This work is based on the foundational efforts of Sandeep Nambiar (https://github.com/gamedolphin).
All credit for the original structure, methodology, and guidance belongs to him. His work provided the architectural basis and practical direction upon which this repository is built. This project would not have been possible without his prior contributions, and much of the instructional approach preserved here originates from his documentation.
@@ -41,36 +40,378 @@ Customization is designed to occur primarily through modular .conf files, allowi
Before proceeding with installation, it is strongly recommended to read this documentation carefully. Understanding the structure and design philosophy will help ensure a smooth setup and provide the necessary context for extending the system effectively.
** What do you get?
This repository delivers a reproducible foundation built on NixOS, Home-Manager, and Flakes. It assumes a clean NixOS installation as a starting point, preferably minimal or headless, onto which the configuration is applied.
* Pre-requisites to edit this setup
- a NIXOS system installed (can be bare-bones)
- an internet connection
The system provides a predefined baseline configuration that installs and enables the essential components required for a functional and extensible environment. Rather than prescribing a complete desktop experience, it establishes the structural framework upon which such an environment can be composed.
To set up a connection from cli:
Core packages are installed as part of the base configuration. Additional software can be incorporated in a controlled and modular manner by extending configuration files.
** What you do not get
This repository does not provide a fully polished, bug-free desktop system with every default preconfigured and validated across all hardware combinations. It is a structured foundation, not a turnkey end-user distribution.
You should not expect graphical configuration tools, wizard-driven setup screens, or extensive GUI-based system management. Configuration is performed declaratively through Nix modules and supporting configuration files. Familiarity with reading logs, adjusting modules, and rebuilding the system is assumed.
Certain subsystems may require manual tuning depending on hardware, desktop environment, or portal backend selection. For example, XDG desktop portals can exhibit inconsistent behavior across compositors and applications, particularly in Wayland-based environments. File chooser dialogs, screen sharing, or drag-and-drop functionality may require additional configuration or troubleshooting.
This project favors clarity, reproducibility, and modular structure over convenience abstractions. As a result, some integration details are intentionally left explicit rather than hidden behind automated defaults.
In short, this repository provides a coherent and extensible base, not a finished consumer product. It is a work in progress.
* What Is a Literate System in the Context of NixOS?
A literate system combines documentation and implementation into a single, coherent source.
In this repository, that source is:
#+begin_src bash :tangle no block
# Check if NetworkManager service is running
systemctl status NetworkManager
# If not running, start it temporarily
sudo systemctl start NetworkManager
# Enable Wi-Fi radio (in case it is disabled)
nmcli radio wifi on
# List available Wi-Fi networks
nmcli device wifi list
# Connect to a Wi-Fi network (replace SSID and PASSWORD)
nmcli device wifi connect "SSID_NAME" password "YOUR_PASSWORD"
# Verify that the connection is active
nmcli connection show --active
# Optional: show device status
nmcli device status
README.org
#+end_src
* machine1 — template machine
Everything originates from this file:
- Architectural explanations
- Design decisions
- NixOS modules
- Home-Manager modules
- Generated documentation
There is no separation between “docs” and “code”.
The documentation explains the intent.
The source blocks define the system.
Org-mode turns that narrative into both executable configuration and readable documentation.
The README is not describing the system.
The README *is* the system.
** Two Types of Code Blocks
This literate system uses two different kinds of source blocks.
**1. Documentation Blocks**
These blocks exist purely for documentation purposes.
They generate visible code blocks in the exported documentation, but they do not create files.
Example:
#+begin_example
#+begin_src bash :tangle no
<tekst>
#+end_src
#+end_example
These are used to show commands, examples, or explanatory snippets in the generated documentation.
They are never tangled into the filesystem.
**2. File-Generating Blocks**
These blocks generate real =.nix= files and insert the same code into the documentation.
Example:
#+begin_example
** install_packages.nix
<tekst>
#+begin_src nix :tangle configuration/apps/install_packages.nix :noweb tangle :mkdirp yes
<nixos code>
#+end_src
#+end_example
Explanation:
- The headline =install_packages.nix= becomes a documentation chapter.
- The paragraph =<tekst>= explains what the module does.
- =<nixos code>= is exactly what will be written into the .nix module =configuration/apps/install_packages.nix=
- The same source block is rendered as a code block in the documentation.
This means:
- The explanation and the implementation live side-by-side.
- The documentation cannot drift away from the code.
- The generated .nix file is always derived from the canonical explanation.
** The Two Core Commands
There are exactly two commands that matter.
**1. Generate all .nix files**
#+begin_src bash :tangle no block
emacs README.org --batch -f org-babel-tangle
#+end_src
This command:
- Regenerates ./configuration
- Regenerates ./home
- Overwrites previously generated modules
- Ensures the system matches the README
**2. Generate documentation**
#+begin_src bash :tangle no block
emacs --batch -l org -l ox-html README.org -f org-html-export-to-html --kill
#+end_src
This command exports the same README into HTML documentation.
In practice you usually combine them:
#+begin_src bash :tangle no block
emacs README.org --batch -f org-babel-tangle && emacs --batch -l org -l ox-html README.org -f org-html-export-to-html --kill
#+end_src
First the system is generated.
Then the documentation is generated.
Both come from the same source.
** Editing Generated Files
The directories:
- ./configuration
- ./home
are fully generated by:
#+begin_src bash :tangle no block
emacs README.org --batch -f org-babel-tangle
#+end_src
Editing these files directly is allowed only temporarily, for experimentation or testing.
Structural or permanent changes must always be implemented in the corresponding section inside README.org.
If you change a file in ./configuration or ./home without updating the README, your changes will disappear on the next tangle.
Generated directories are output, not source.
** Recommended Workflow
This workflow allows safe experimentation while preserving literate structure.
1. Change any existing file in ./assets, ./home or ./configuration
2. Commit your experimental change
3. Test the configuration
4. If satisfied, migrate the change into README.org
5. Regenerate system and documentation
6. Commit again
7. Test again
Commands:
#+begin_src bash :tangle no block
git add .
git commit -m "experiment: local change"
sudo nixos-rebuild test --flake .#your_hostname
#+end_src
After confirming the change:
#+begin_src bash :tangle no block
emacs README.org --batch -f org-babel-tangle && emacs --batch -l org -l ox-html README.org -f org-html-export-to-html --kill
git add .
git commit -m "literate: structural update"
sudo nixos-rebuild test --flake .#your_hostname
#+end_src
If you are confident about your changes, you may skip steps 13 and edit README.org directly.
** Folder Structure Explained
The repository separates generated system code from non-generated supporting files.
*** ./assets
Contains non-generated assisting files such as:
- Icons
- Themes
- Static configuration files
These files are safe to edit directly.
*** ./assets/conf
Contains non-generated assisting configuration files that influence several aspects of builds.
Users are expected to modify these when needed.
*** ./configuration
Fully (re)generated by README.org.
Contains:
- All NixOS modules
- Service definitions
- System-level configuration
This directory is output.
*** ./hardware
Contains non-generated hardware.nix files detailing hardware-specific details.
This directory will likely be deprecated in the future.
*** ./home
Fully (re)generated by README.org.
Contains:
- All Home-Manager modules
- User-level configuration
- Shell and desktop configuration
*** ./machines
Contains one folder per machine you want to configure.
Each machine folder contains non-generated files detailing specifics for that machine:
- Host-specific overrides
- Hardware references
- Host definitions
These determine how shared modules apply to each system.
** Final Principle
A literate NixOS system guarantees:
- Single source of truth
- No divergence between documentation and configuration
- Reproducible system builds
- Clear architectural reasoning
- Controlled experimentation
You are not maintaining configuration files.
You are maintaining a structured narrative that builds an operating system.
** Base packages
The baseline package set is defined explicitly within the repository to ensure reproducibility:
#+begin_src bash :tangle no
- alsa-utils
- avy
- bibata-cursors
- brightnessctl
- cape
- catppuccin-gtk
- catppuccin-theme
- consult
- coreutils
- corfu
- crux
- dash
- diminish
- doom-modeline
- eat
- eldoc
- eldoc-box
- elephant
- emacs-pgtk
- envrc
- exec-path-from-shell
- expreg
- flatpak
- gnugrep
- gnused
- gptel
- hcl-mode
- hypridle
- hyprlandPlugins
- hyprlock
- hyprshell
- librsvg
- linuxPackages_latest
- magit
- magnetic-catppuccin-gtk
- marginalia
- nerd-icons
- nerd-icons-corfu
- nix-mode
- nixpkgs-fmt
- nushell
- ollama
- orderless
- papirus-icon-theme
- pulsar
- puni
- rg
- rust-mode
- rustic
- shell-pop
- sideline
- sideline-eglot
- sideline-flymake
- tuigreet
- vertico
- vundo
- walker
- which-key
- wpaperd
- xdg-desktop-portal-gtk
- yasnippet
- yasnippet-snippets
- zsh
#+end_src
** Additional packages
Additional software can be installed by extending the dedicated configuration files that define system and Flatpak packages:
#+begin_src bash :tangle no
├── assets
│   ├── conf
│   │   ├── apps
│   │   │   ├── flatpaks.conf
│   │   │   └── packages.conf
#+end_src
System packages are declared in =packages.conf= using their attribute names from Nixpkgs. The correct package names can be located through the official NixOS package search at https://search.nixos.org/packages.
Available Flatpak identifiers can be discovered using:
#+begin_src bash :tangle no
flatpak search <application-name>
#+end_src
or by browsing: https://flathub.org/.
The behavior and integration of Flatpak installation within the system are defined in =install_flatpaks.nix=, which reads the corresponding configuration files and ensures declarative installation.
This separation maintains clarity between system-level packages and user-facing Flatpak applications while preserving reproducibility and modular structure.
* Setting up your system manually
** Pre-requisites to build this setup
#+begin_src bash :tangle no block
- a NIXOS system installed with a user with sudo rights.
- an internet connection
- the folder henrovnix as you find it here
#+end_src
** Setup when Emacs not (yet) available
1. Copy the folder *henrovnix* to your machine
2. First setup an internet connection
#+begin_src bash :tangle no block
# Check if NetworkManager service is running
systemctl status NetworkManager
# If not running, start it temporarily
sudo systemctl start NetworkManager
# Enable Wi-Fi radio (in case it is disabled)
nmcli radio wifi on
# List available Wi-Fi networks
nmcli device wifi list
# Connect to a Wi-Fi network (replace SSID and PASSWORD)
nmcli device wifi connect "SSID_NAME" password "YOUR_PASSWORD"
# Verify that the connection is active
nmcli connection show --active
# Optional: show device status
nmcli device status
#+end_src
3. Replace *<defaultUser>* in all files with =your_user=
#+begin_src bash :tangle no block
find ~/Repos/nixos/henrovnix \
-type d -name ".*" -prune -o \
-type f -print0 \
| xargs -0 sed -i 's/=<defaultUser>=/your_user/g'
#+end_src
4. Replace *machine1* in all files with =your_hostname=
#+begin_src bash :tangle no block
find ~/Repos/nixos/henrovnix \
-type d -name ".*" -prune -o \
-type f -print0 \
| xargs -0 sed -i 's/machine1/your_hostname/g'
#+end_src
5. Rename the folder ./machines/machine1 to your hostname
#+begin_src bash :tangle no block
mv ./machines/machine1 ./machines/your_hostname
#+end_src
6. Create a hardware-configuration.nix and copy it into the folder =./machines/your_hostname= overwriting any existing file
#+begin_src bash :tangle no block
nixos-generate-config
#+end_src
7. Run the build command to set up the system for the first time
#+begin_src bash :tangle no block
sudo nixos-rebuild switch --flake .#your_hostname
#+end_src
* Testing and generating builds
At this stage, you should have a functional and reproducible system that can be edited, rebuilt, and extended according to your needs. The foundational structure is now in place, and further customization can occur incrementally through the modular configuration files.
From this point onward, development becomes iterative: modify configuration, rebuild the system, verify behavior, and refine. Because the system is declarative, every change remains explicit, reviewable, and reversible.
The following sections provide practical guidance for editing and rebuilding, along with an explanation of the repository structure. They describe how the various files relate to one another, how the modular layers are composed, and how the configuration evolved into its current form. Understanding this structure will make future modifications more predictable and easier to maintain.
Below are several useful commands for testing configurations, generating builds, and managing system generations. These commands support safe experimentation by allowing you to evaluate changes before switching to them permanently, and to roll back if necessary.
To generate the Nix files:
#+begin_src bash :tangle no
emacs README.org --batch -f org-babel-tangle
#+end_src
To generate this documentation:
#+begin_src bash :tangle no
emacs --batch -l org -l ox-html README.org -f org-html-export-to-html --kill
#+end_src
Test the build while being able to reboot to previous version
#+begin_src bash :tangle no
sudo nixos-rebuild test --flake .#machine1
@@ -81,24 +422,12 @@ sudo nixos-rebuild switch --flake .#machine1
#+end_src
Build and run in a virtual machine (qemu must be installed)
#+begin_src bash :tangle no
sudo nixos-rebuild build-vm --flake ~/nixos-henrov#machine1
sudo nixos-rebuild build-vm --flake .#machine1
# running the vm:
./result/bin/run-nixos-vm
#+end_src
un this VM with result/
#+begin_src bash :tangle no
emacs README.org --batch -f org-babel-tangle
#+end_src
Once the Nix files are generated, deploy using:
#+begin_src bash :tangle no
nixos-rebuild switch --flake .#<machine>
#+end_src
Other files in this repo include:
Other important files:
* ~flake.lock~ for pinning input versions.
* ~assets/*~ for non-Nix-managed artifacts such as images and wallpapers.
@@ -119,143 +448,143 @@ Generated outputs should not be edited directly. A CI workflow can tangle and co
* [[[https://nixos.org/][NixOS](https://nixos.org/][NixOS)]] evaluates Nix expressions into a complete system configuration that can be applied by rebuild operations.
** Repository layout and folder conventions
#+HTML: <p>
#+HTML: This repository contains system modules, user modules, and configuration fragments. The following directories are treated as separate layers:
#+HTML: <code>./configuration</code> (NixOS modules), <code>./home</code> (Home Manager modules), and <code>./assets/conf</code> (configuration fragments referenced or deployed by the modules).
#+HTML: </p>
#+HTML: <p>
#+HTML: To keep navigation consistent, the same internal substructure is used in all three locations. Each layer keeps its role; only the internal grouping is standardized.
#+HTML: </p>
<p>
This repository contains system modules, user modules, and configuration fragments. The following directories are treated as separate layers:
<code>./configuration</code> (NixOS modules), <code>./home</code> (Home Manager modules), and <code>./assets/conf</code> (configuration fragments referenced or deployed by the modules).
</p>
<p>
To keep navigation consistent, the same internal substructure is used in all three locations. Each layer keeps its role; only the internal grouping is standardized.
</p>
** Shared domain folders
#+HTML: <ul>
#+HTML: <li><code>core/</code> base settings and common infrastructure</li>
#+HTML: <li><code>desktop/</code> graphical session, compositor, UI components, and integration</li>
#+HTML: <li><code>apps/</code> application enablement and application-level configuration</li>
#+HTML: <li><code>services/</code> background services and daemons</li>
#+HTML: <li><code>security/</code> secrets handling and security-related configuration</li>
#+HTML: <li><code>dev/</code> developer tooling and editor configuration</li>
#+HTML: </ul>
<ul>
<li><code>core/</code> base settings and common infrastructure</li>
<li><code>desktop/</code> graphical session, compositor, UI components, and integration</li>
<li><code>apps/</code> application enablement and application-level configuration</li>
<li><code>services/</code> background services and daemons</li>
<li><code>security/</code> secrets handling and security-related configuration</li>
<li><code>dev/</code> developer tooling and editor configuration</li>
</ul>
** Full tree (including unchanged parts)
#+HTML: <p>
#+HTML: The tree below shows the full repository layout, with the standardized internal structure applied only inside
#+HTML: <code>configuration/</code>, <code>home/</code>, and <code>assets/conf/</code>.
#+HTML: </p>
#+HTML: <pre><code>.
#+HTML: ├── assets
#+HTML: │   ├── background.png
#+HTML: │   ├── conf
#+HTML: │   │   ├── apps
#+HTML: │   │   │   ├── flatpaks.conf
#+HTML: │   │   │   └── packages.conf
#+HTML: │   │   ├── core
#+HTML: │   │   │   ── lightdm.conf
#+HTML: │   │   ── desktop
#+HTML: │   │   │   ├── hypr
#+HTML: │   │   │   │   ├── bindings.conf
#+HTML: │   │   │   │   ── hyprland.conf
#+HTML: │   │   │   ├── wallpaper
#+HTML: │   │   │   │   ── wallpaper.conf
#+HTML: │   │   │   ── waybar
#+HTML: │   │   │   ├── config.jsonc
#+HTML: │   │   │   └── style.css
#+HTML: │   │   ├── dev
#+HTML: │   │   │   ├── hyprshell
#+HTML: │   │   │   │   ├── config.ron.bak
#+HTML: │   │   │   │   ── styles.css.bak
#+HTML: │   │   │   └── terminal
#+HTML: │   │   │   ├── alacritty.toml
#+HTML: │   │   │   ├── aliases.conf
#+HTML: │   │   │   ── enabled_shells.conf
#+HTML: │   │   │   ├── kitty.conf
#+HTML: │   │   │   ├── starship.toml
#+HTML: │   │   │   ── zsh.conf
#+HTML: │   │   ├── security
#+HTML: │   │   │   └── ssh
#+HTML: │   │   │   ── ssh-client.conf
#+HTML: │   │   └── services
#+HTML: │   ├── lock.png
#+HTML: │   ├── scripts
#+HTML: │   └── wallpapers
#+HTML: │   ── gif
#+HTML: │   ├── pictures
#+HTML: │   │   ├── background.png
#+HTML: │   │   ── background1.png
#+HTML: │   │   ├── background2.png
#+HTML: │   │   ── background3.png
#+HTML: │   │   ├── background4.png
#+HTML: │   │   ── background5.png
#+HTML: │   └── videos
#+HTML: │   ── dark_water_large.mp4
#+HTML: │   └── white_blobs_small.mp4
#+HTML: ├── configuration
#+HTML: │   ├── apps
#+HTML: │   │   ├── install_flatpaks.nix
#+HTML: │   │   └── install_packages.nix
#+HTML: │   ├── core
#+HTML: │   │   ├── boot.nix
#+HTML: │   │   ├── files.nix
#+HTML: │   │   ├── locale.nix
#+HTML: │   │   ├── networking.nix
#+HTML: │   │   ── nix-settings.nix
#+HTML: │   ├── default.nix
#+HTML: │   ── desktop
#+HTML: │   │   ├── audio.nix
#+HTML: │   │   ├── hyprland.nix
#+HTML: │   │   ── login-tuigreeter.nix
#+HTML: │   ── dev
#+HTML: │   │   └── terminal.nix
#+HTML: │   ── security
#+HTML: │   └── services
#+HTML: │   └── services.nix
#+HTML: ├── flake.lock
#+HTML: ├── flake.nix
#+HTML: ├── hardware
#+HTML: │   └── hardware.nix
#+HTML: ├── home
#+HTML: │   ├── apps
#+HTML: │   │   ├── defaults-apps.nix
#+HTML: │   │   ── theme.nix
#+HTML: │   ── default.nix
#+HTML: │   ├── desktop
#+HTML: │   │   ├── hyprexpo.nix
#+HTML: │   │   ├── hyprland.nix
#+HTML: │   │   ├── hyprlock.nix
#+HTML: │   │   ├── hypridle.nix
#+HTML: │   │   ├── hyprshell.nix
#+HTML: │   │   ├── walker.nix
#+HTML: │   │   ├── wallpaper.nix
#+HTML: │   │   ── waybar.nix
#+HTML: │   ── dev
#+HTML: │   │ ├── alacritty.nix
#+HTML: │   ├── dev.nix
#+HTML: │   ├── emacs
#+HTML: │   │   ├── default.nix
#+HTML: │   │   ├── early-init.el
#+HTML: │   │   ── init.el
#+HTML: │   ├── kitty.nix
#+HTML: │   ├── shells.nix
#+HTML: │   ── starship.nix
#+HTML: │   └── zsh.nix
#+HTML: ├── LICENSE
#+HTML: ├── machines
#+HTML: │   └── traveldroid
#+HTML: │   ├── configuration.nix
#+HTML: │   ├── hardware-configuration.nix
#+HTML: │   └── home.nix
#+HTML: ├── README.org
#+HTML: ├── secrets
#+HTML: │   └── secrets.yaml
#+HTML: └── user.nix
#+HTML: </code></pre>
The tree below shows the full repository layout, with the standardized internal structure applied only inside
#+begin_src bash :tangle no
├── assets
│   ├── conf
│   │   ├── apps
│   │   │   ├── flatpaks.conf
│   │   │   └── packages.conf
│   │   ├── core
│   │   │   ── lightdm.conf
│   │   │   ── lightdm-gtk-greeter.conf
│   │   ├── desktop
│   │   │   ├── hypr
│   │   │   │   ── bindings.conf
│   │   │   │   ├── hypridle.conf
│   │   │   │   ── hyprland.conf
│   │   │   │   ── hyprlock.conf
│   │   │   │   ├── hyprshell
│   │   │   │   └── scripts
│   │   │   ├── wallpaper
│   │   │   │   ├── gif
│   │   │   │   ├── pictures
│   │   │   │   ── videos
│   │   │   │   └── wallpaper.conf
│   │   │   └── waybar
│   │   │   ├── config.jsonc
│   │   │   ── style.css
│   │   ├── dev
│   │   │   └── terminal
│   │   │   ── alacritty.toml
│   │   │   ├── aliases.conf
│   │   │   ├── enabled_shells.conf
│   │   │   ── kitty.conf
│   │   │   ├── starship.toml
│   │   │   └── zsh.conf
│   │   ├── security
│   │   │   └── ssh
│   │   │   ── ssh-client.conf
│   │   └── services
│   ├── cursors
│   │   ── Bibata_Cursor-main
│   ├── icons
│   │   ── papirus-icon-theme-master
│   ├── lock.png
│   ── scripts
│   └── themes
│   ── Catppuccin-Mocha-Standard-Blue-Dark
├── configuration
│   ├── apps
│   │   ├── ai.nix
│   │   ├── install_flatpaks.nix
│   │   └── install_packages.nix
│   ├── core
│   │   ├── boot.nix
│   │   ├── files.nix
│   │   ├── locale.nix
│   │   ├── login-lightdm.nix
│   │   ── login-tuigreeter.nix
│   │   ├── networking.nix
│   │   ── nix-settings.nix
│   ├── default.nix
│   ├── desktop
│   │   ── audio.nix
│   │   ── hyprland.nix
│   ├── dev
│   │   ── terminal.nix
│   └── services
│   └── services.nix
├── flake.lock
├── flake.nix
├── hardware
│   └── hardware.nix
├── home
│   ├── apps
│   │   ├── ai.nix
│   │   ── defaults-apps.nix
│   │   ── theme.nix
│   ├── default.nix
│   ├── desktop
│   │   ├── hyprexpo.nix
│   │   ├── hypridle.nix
│   │   ├── hyprland.nix
│   │   ├── hyprlock.nix
│   │   ├── hyprshell.nix
│   │   ├── walker.nix
│   │   ── wallpaper.nix
│   │   ── waybar.nix
│   └── dev
│   ├── alacritty.nix
│   ├── dev.nix
│   ├── emacs
│   │   ├── default.nix
│   │   ── early-init.el
│   │   └── init.el
│   ├── kitty.nix
│   ── shells.nix
│   ├── starship.nix
│   └── zsh.nix
├── LICENSE
├── machines
│   ├── machine1
│   │   ├── configuration.nix
│   │   ├── hardware-configuration.nix
│   │   └── home.nix
│   └── traveldroid
│   ├── configuration.nix
│   ├── hardware-configuration.nix
│   └── home.nix
├── README.html
├── README.org
└── user.nix
#+end_src
** Notes
#+HTML: <ul>
#+HTML: <li>Only the internal layout of <code>configuration/</code>, <code>home/</code>, and <code>assets/conf/</code> is standardized; all other paths remain as currently organized.</li>
#+HTML: <li>The <code>services/</code> and <code>security/</code> folders are included for completeness even if initially empty in some layers.</li>
#+HTML: </ul>
<ul>
<li>Only the internal layout of <code>configuration/</code>, <code>home/</code>, and <code>assets/conf/</code> is standardized; all other paths remain as currently organized.</li>
<li>The <code>services/</code> and <code>security/</code> folders are included for completeness even if initially empty in some layers.</li>
</ul>
~YourNixCode(Input) -> System Configuration~
@@ -522,6 +851,7 @@ This section describes the main system configuration for the computers that I ha
{ pkgs, user, ... } :
{
imports = [
./apps/ai.nix
./apps/install_flatpaks.nix
./apps/install_packages.nix
./core/files.nix
@@ -557,6 +887,37 @@ This section describes the main system configuration for the computers that I ha
** Apps section
This section describes a way of installing packages, either through nixpkgs orr flatpak. What apps to instal is decided in the files ./assets/conf/apps/packages.conf and flatpaks.conf
** ai.nix
This module enables and configures the Ollama system service on NixOS, including optional GPU acceleration (CUDA or ROCm).
It ensures the Ollama CLI is available system-wide for interacting with local models.
It automatically pulls and prepares selected coding models (e.g., Qwen2.5-Coder and StarCoder2) at system activation.
#+begin_src nix :tangle configuration/apps/ai.nix :noweb tangle :mkdirp yes
{ config, lib, pkgs, ... }:
{
# Ollama server als systemd service
services.ollama = {
enable = true;
# Optioneel: "cuda" (NVIDIA) of "rocm" (AMD)
# Laat weg of zet op null/false als je CPU-only wilt.
acceleration = "cuda";
# acceleration = "rocm";
# Laat NixOS de modellen automatisch pullen zodra de service draait
# (via `ollama pull ...`)
loadModels = [
"qwen2.5-coder:7b"
"qwen2.5-coder:32b"
"starcoder2:15b"
# Alternatief:
# "starcoder2:7b"
# "starcoder2:latest"
];
};
# Installeer de CLI tool (handig voor 'ollama run', 'ollama list', etc.)
environment.systemPackages = [
pkgs.ollama
];
}
** install_packages.nix
#+begin_src nix :tangle configuration/apps/install_packages.nix :noweb tangle :mkdirp yes
{ config, lib, pkgs, flakeRoot, inputs, ... }:
@@ -1664,6 +2025,76 @@ You'll notice the color values in multiple places outside this as well.
}
#+end_src
** ai.nix
This Home-Manager module installs and configures the Zed editor in a user environment.
It integrates Ollama as a local LLM provider within Zeds AI settings for code assistance.
It also generates a Continue configuration file pointing to the local Ollama instance for compatible editors.
#+begin_src nix :tangle home/apps/theme.nix :noweb tangle :mkdirp yes.
{ config, lib, pkgs, ... }:
let
# Continue gebruikt tegenwoordig bij voorkeur config.yaml; config.json bestaat nog
# maar is “deprecated” in de docs. We schrijven hier bewust config.json omdat jij dat vroeg.
continueConfigJson = builtins.toJSON {
models = [
{
title = "Qwen2.5-Coder 7B";
provider = "ollama";
model = "qwen2.5-coder:7b";
apiBase = "http://localhost:11434";
}
{
title = "Qwen2.5-Coder 32B";
provider = "ollama";
model = "qwen2.5-coder:32b";
apiBase = "http://localhost:11434";
}
{
title = "StarCoder2 15B";
provider = "ollama";
model = "starcoder2:15b";
apiBase = "http://localhost:11434";
}
];
# Tab-autocomplete model (pas aan naar smaak/VRAM)
tabAutocompleteModel = {
title = "Qwen2.5-Coder 7B";
provider = "ollama";
model = "qwen2.5-coder:7b";
apiBase = "http://localhost:11434";
};
};
in
{
programs.zed-editor = {
enable = true;
# Zed-extensies (taal/LS/etc). "Continue" bestaat (nog) niet als Zed-extensie.
# Dit is de officiële HM interface voor Zed extensions.
extensions = [
"nix"
"toml"
"rust"
];
# Zed AI: Ollama als provider
# Zed kan modellen auto-discoveren die jij met Ollama gepulld hebt.
userSettings = {
language_models = {
ollama = {
api_url = "http://localhost:11434";
auto_discover = true;
# Optioneel: zet een grotere context voor alle Ollama modellen
# (Zed stuurt dit als `num_ctx` naar Ollama)
context_window = 8192;
};
};
};
};
# Continue config.json neerzetten (voor Continue in VS Code / JetBrains)
# Pad: ~/.config/continue/config.json
xdg.configFile."continue/config.json".text = continueConfigJson;
}
#+end_src
** Default-apps
This is where you can set defaults
#+begin_src nix :tangle home/apps/defaults-apps.nix :noweb tangle :mkdirp yes.
+1
View File
@@ -1,6 +1,7 @@
{ pkgs, user, ... } :
{
imports = [
./apps/ai.nix
./apps/install_flatpaks.nix
./apps/install_packages.nix
./core/files.nix
+64
View File
@@ -20,3 +20,67 @@
catppuccin.gtk.icon.enable = true;
catppuccin.cursors.enable = true;
}
{ config, lib, pkgs, ... }:
let
# Continue gebruikt tegenwoordig bij voorkeur config.yaml; config.json bestaat nog
# maar is “deprecated” in de docs. We schrijven hier bewust config.json omdat jij dat vroeg.
continueConfigJson = builtins.toJSON {
models = [
{
title = "Qwen2.5-Coder 7B";
provider = "ollama";
model = "qwen2.5-coder:7b";
apiBase = "http://localhost:11434";
}
{
title = "Qwen2.5-Coder 32B";
provider = "ollama";
model = "qwen2.5-coder:32b";
apiBase = "http://localhost:11434";
}
{
title = "StarCoder2 15B";
provider = "ollama";
model = "starcoder2:15b";
apiBase = "http://localhost:11434";
}
];
# Tab-autocomplete model (pas aan naar smaak/VRAM)
tabAutocompleteModel = {
title = "Qwen2.5-Coder 7B";
provider = "ollama";
model = "qwen2.5-coder:7b";
apiBase = "http://localhost:11434";
};
};
in
{
programs.zed-editor = {
enable = true;
# Zed-extensies (taal/LS/etc). "Continue" bestaat (nog) niet als Zed-extensie.
# Dit is de officiële HM interface voor Zed extensions.
extensions = [
"nix"
"toml"
"rust"
];
# Zed AI: Ollama als provider
# Zed kan modellen auto-discoveren die jij met Ollama gepulld hebt.
userSettings = {
language_models = {
ollama = {
api_url = "http://localhost:11434";
auto_discover = true;
# Optioneel: zet een grotere context voor alle Ollama modellen
# (Zed stuurt dit als `num_ctx` naar Ollama)
context_window = 8192;
};
};
};
};
# Continue config.json neerzetten (voor Continue in VS Code / JetBrains)
# Pad: ~/.config/continue/config.json
xdg.configFile."continue/config.json".text = continueConfigJson;
}
+39
View File
@@ -1,3 +1,26 @@
README.org
emacs README.org --batch -f org-babel-tangle
emacs --batch -l org -l ox-html README.org -f org-html-export-to-html --kill
emacs README.org --batch -f org-babel-tangle && emacs --batch -l org -l ox-html README.org -f org-html-export-to-html --kill
emacs README.org --batch -f org-babel-tangle
git add .
git commit -m "experiment: local change"
sudo nixos-rebuild test --flake .#your_hostname
emacs README.org --batch -f org-babel-tangle && emacs --batch -l org -l ox-html README.org -f org-html-export-to-html --kill
git add .
git commit -m "literate: structural update"
sudo nixos-rebuild test --flake .#your_hostname
- a NIXOS system installed with a user with sudo rights.
- an internet connection
- the folder henrovnix as you find it here
# Check if NetworkManager service is running
systemctl status NetworkManager
# If not running, start it temporarily
@@ -12,3 +35,19 @@ nmcli device wifi connect "SSID_NAME" password "YOUR_PASSWORD"
nmcli connection show --active
# Optional: show device status
nmcli device status
find ~/Repos/nixos/henrovnix \
-type d -name ".*" -prune -o \
-type f -print0 \
| xargs -0 sed -i 's/=<defaultUser>=/your_user/g'
find ~/Repos/nixos/henrovnix \
-type d -name ".*" -prune -o \
-type f -print0 \
| xargs -0 sed -i 's/machine1/your_hostname/g'
mv ./machines/machine1 ./machines/your_hostname
nixos-generate-config
sudo nixos-rebuild switch --flake .#your_hostname