diff --git a/README.md b/README.md index 4ad588a..9c5ebb9 100755 --- a/README.md +++ b/README.md @@ -1,203 +1,129 @@ # liminalOS This is a repository that implements liminalOS, my personal Linux distribution -based on [NixOS](https://nixos.org/). - -Time wasted writing Nix code: -![](https://wakatime.com/badge/user/018dc5b8-ba5a-4572-a38a-b526d1b28240/project/c59b3d5e-0c9c-4bd5-a752-e75522ab0cdc.svg) + [![wakatime](https://wakatime.com/badge/user/018dc5b8-ba5a-4572-a38a-b526d1b28240/project/de5e82f8-8a09-42cb-ae45-9c80f2ab5a41.svg)](https://wakatime.com/badge/user/018dc5b8-ba5a-4572-a38a-b526d1b28240/project/de5e82f8-8a09-42cb-ae45-9c80f2ab5a41) +based on [NixOS](https://nixos.org/). The most overengineered personal +computing environment, ever. Imagine having to `vim` into source code and +recompile an entire operating system to change a font. Yes, I use this on a +daily basis. This repository exposes a NixOS module that declares the entire liminalOS operating system. It aims to be an easy way to both set up a brand new system with my opinionated configurations, and also inject into an existing NixOS configuration. -Reference implementations of liminalOS on actual working systems is in -[./reference](./reference). +My reference implementations of liminalOS on actual working systems are +available [here](./reference). liminalOS is currently in a heavily experimental state, but it is used in production every day! -You can try it with `nix flake init -t github:youwen5/liminalOS#liminalOS`, -which will create a sample configuration flake along with corresponding files. +You can try it with `nix flake init -t github:youwen5/liminalOS`, which will +create a sample configuration flake along with corresponding files. Keep in +mind you'll have to do a little bit of work in these files to get a working +system configuration. Some Nix knowledge is expected, but comments are there to +help! -Many have written at length about the virtues of NixOS and _declarative -configuration_ and _immutability_ and such. I doubt what I have to say is -particularly novel, but I'll leave a few thoughts about Nix and NixOS and why -they do things better anyways. In particular, instead of immediately -evangelizing about the virtues of Nix, I'll first motivate the reasons for why -I chose a tool with exactly its properties, based on my use case (but not to -worry, the evangelizing will come later). +``` +flowchart TB + subgraph "Core System Layer" + NixOS["NixOS/Darwin Base"] + SysMod["System Modules"]:::sysmod + HM["Home Manager"]:::hm + end -Essentially: allow me to introduce you to the -origins of [NixOS God -Complex](https://www.reddit.com/r/NixOS/comments/kauf1m/dealing_with_post_nixflake_god_complex/). + subgraph "Platform Modules" + subgraph "Linux Modules" + LinuxCore["Linux Core"]:::linux + Desktop["Desktop Environment"]:::linux + Audio["Audio System"]:::linux + Gaming["Gaming Support"]:::linux + Graphics["Graphics"]:::linux + end -If you would like advice on whether or not to use NixOS: + subgraph "Darwin Modules" + DarwinCore["Darwin Core"]:::darwin + Homebrew["Homebrew"]:::darwin + WM["Window Management"]:::darwin + end + end -
see hlissner's breakdown, -reproduced below: Should I use NixOS? + subgraph "Home Manager Layer" + CommonMod["Common Modules"]:::hmmod + ShellEnv["Shell Environment"]:::hmmod + Tools["Essential Tools"]:::hmmod + + subgraph "Platform-Specific HM" + LinuxHM["Linux Config"]:::linux + Theming["Linux Theming"]:::linux + Hyprland["Hyprland Config"]:::linux + DarwinHM["Darwin Config"]:::darwin + end + end -Short answer: no. + subgraph "Package Management" + Packages["Custom Packages"]:::pkg + Overlays["Overlays"]:::pkg + end -Long answer: no really. Don't. + subgraph "Host Configuration" + RefHosts["Reference Hosts"]:::host + Templates["Host Templates"]:::host + end -Long long answer: I'm not kidding. Don't. + subgraph "Build System" + Flake["Flake Entry Point"]:::build + Builder["Build System"]:::build + end -Unsigned long long answer: Alright alright. Here's why not: + %% Relationships + NixOS --> SysMod + SysMod --> LinuxCore & DarwinCore + HM --> CommonMod + CommonMod --> ShellEnv & Tools + CommonMod --> LinuxHM & DarwinHM + LinuxHM --> Theming & Hyprland + DarwinCore --> Homebrew & WM + LinuxCore --> Desktop & Audio & Gaming & Graphics + Flake --> Builder + Builder --> RefHosts + Templates --> RefHosts + Packages --> Overlays + Overlays --> Builder -Its learning curve is steep. You will trial and error your way to -enlightenment, if you survive the frustration long enough. NixOS is unlike -other Linux distros. Your issues will be unique and difficult to google. A -decent grasp of Linux and your chosen services is a must, if only to -distinguish Nix(OS) issues from Linux (or upstream) issues -- as well as to -debug them or report them to the correct authority (and coherently). If words -like "declarative", "generational", and "immutable" don't put your sexuality in -jeopardy, you're considering NixOS for the wrong reasons. The overhead of -managing a NixOS config will rarely pay for itself with 3 systems or fewer -(perhaps another distro with nix on top would suit you better?). Official -documentation for Nix(OS) is vast, but shallow. Unofficial resources and -example configs are sparse and tend toward too simple or too complex (and most -are outdated). Case in point: this repo. The Nix language is obtuse and its -toolchain is not intuitive. Your experience will be infinitely worse if -functional languages are alien to you, however, learning Nix is a must to do -even a fraction of what makes NixOS worth the trouble. If you need somebody -else to tell you whether or not you need NixOS, you don't need NixOS. -
+ %% Click Events + click SysMod "https://github.com/youwen5/liminalOS/tree/main/modules" + click LinuxCore "https://github.com/youwen5/liminalOS/tree/main/modules/linux/core" + click DarwinCore "https://github.com/youwen5/liminalOS/tree/main/modules/darwin" + click HM "https://github.com/youwen5/liminalOS/tree/main/hm" + click CommonMod "https://github.com/youwen5/liminalOS/tree/main/hm/modules/common" + click ShellEnv "https://github.com/youwen5/liminalOS/tree/main/hm/modules/common/shellenv" + click Tools "https://github.com/youwen5/liminalOS/tree/main/hm/modules/common/essentials" + click Desktop "https://github.com/youwen5/liminalOS/tree/main/modules/linux/desktop-environment" + click Audio "https://github.com/youwen5/liminalOS/tree/main/modules/linux/audio" + click Gaming "https://github.com/youwen5/liminalOS/tree/main/modules/linux/gaming" + click Graphics "https://github.com/youwen5/liminalOS/tree/main/modules/linux/graphics" + click Homebrew "https://github.com/youwen5/liminalOS/blob/main/modules/darwin/homebrew.nix" + click WM "https://github.com/youwen5/liminalOS/blob/main/modules/darwin/yabai.nix" + click RefHosts "https://github.com/youwen5/liminalOS/tree/main/reference/hosts" + click Templates "https://github.com/youwen5/liminalOS/tree/main/templates/minimal" + click Packages "https://github.com/youwen5/liminalOS/tree/main/pkgs/by-name" + click Overlays "https://github.com/youwen5/liminalOS/tree/main/overlays" + click Theming "https://github.com/youwen5/liminalOS/tree/main/hm/modules/linux/theming" + click Hyprland "https://github.com/youwen5/liminalOS/tree/main/hm/modules/linux/desktop-environment/hyprland" + click Builder "https://github.com/youwen5/liminalOS/blob/main/lib/buildLiminalOS.nix" + click Flake "https://github.com/youwen5/liminalOS/blob/main/flake.nix" -
- - -> **lim·i·nal** -> 1. between or belonging to two different places, states, etc. - -The goal of liminalOS is to allow my computing environment to exist in -different computers at the same time, and to be absolutely unbreakable while -doing so. Let's talk about existing in multiple computers first, or otherwise -known as some form of "settings sync". To the typical user, stuck in the -_imperative world_, this sounds unrealistic at worst, and janky at best. -Generally, people encounter environment or settings syncing in two ways: either -the entire service is ran in the cloud, so it's really the _same_ environment -accessed from multiple places, or it's some often half baked opaque solution -involving you making an account and sending all your settings to a sync server -(see: Mozilla Firefox). - -The more technically minded may instead opt to create a "dotfiles" repository, -holding their vast corpus of meticulously crafted configuration files. These -repos often come with a janky `install.sh` that does its best to throw all the -files into the correct place. This usually works the first time, but trying to -keep the installed dotfiles in sync with a central repository is a whole other -problem. - -But these solutions are generally used for singular services or applications. -Keeping an entire _system_ synced up across computers down to the minute -configurations and applications seems incredibly unwieldy, through our usual -conception of how we interact with our operating systems. - -The more obsessive system tweakers might try a dotfile manager like `chezmoi` -or GNU Stow. I have not tried these so I make no judgements on their utility -for their intended purpose, but generally these solutions miss a key feature: -they provide the configuration, but don't install the software. But the -software and the configuration are fundamentally tied together; these are not -concerns to be separated. If the software is installed, it almost always needs -to be configured anyways. If the configuration exists, the software should be -installed. These solutions may work well for managing configuration, but they -have the same issue as before: you also need to install the software you're -configuring! - -So, *nix hackers reach for things like [Ansible](https://www.ansible.com/), that -promise automatic configuration of entire systems. Though Ansible was designed -to deploy cloud servers quickly through the Infrastructure-as-Code approach, -some people opt to use it for deploying their systems quickly as well. I have -not tried it, but from what I've heard, it works fine for simple deployment but -gets quite unwieldy for more complex purposes (especially for personal systems, -which aren't expected to be as ephemeral as servers). - -If you agree with the premises I've laid out up to this point, you might come -to the conclusion that I've made: to solve this issue, we need a solution that -does _all of it_. A unified tool for deploying software and managing systems. -And it must necessarily be declarative and reproducible, because that is the -only way to sanely manage a system. Imagine working on a programming project -where recompiling with the same source code would non-deterministically produce -different results based on the environment! - -Well, [Nix](https://nixos.org/) is the _purely functional_ package manager -(i.e. declarative, reproducible), and NixOS is a Linux distribution that is -managed entirely by Nix. Essentially, Nix provides a solution to the problem of -_software deployment_, and in fact was purpose built to do so in Eelco -Dolstra's seminal [PhD -thesis](https://edolstra.github.io/pubs/phd-thesis.pdf). NixOS is a system that -takes the power of Nix and applies it to declaratively configure an _entire -Linux system_. All of the software can be specified precisely using the Nix -expression language, a purely functional DSL used by Nix. And alongside the -software, it also configures it, effectively acting as a dotfile manager. -Indeed, many core NixOS services and a wide range of programs can be set up -through _NixOS modules_, where the program is installed and configured in the -same place. (and many programs like `fzf`, `btop`, etc have similar -corresponding `home-manager` modules). - -NixOS is also _immutable_, which means that the system cannot be modified after -it is built from the Nix files that declare it. How do you make changes to the -system then? Obviously, we just create a new system where the changed programs -and files are included, and the old ones are removed. But they are not deleted -from the hard drive, they still exist in the _Nix store_. So, the system can -provide precise atomic rollbacks between each "generation" of itself. Broke -your GRUB configuration so your system won't boot? Messed up your kernel -settings? Just select an older working generation from the boot menu and you -instantly have a working system again. You never worry about breaking things -during either routine or massive system updates. - -And because the system is fully declarative, and modifying the system is done -only through modifying its Nix configuration files, you can version and sync -them up with Git. This solves the problem of keeping system environments in -sync; now, you truly only have to keep one repository of all your configuration -in sync, and all the software installation and deployment is handled for you by -a system designed precisely for that purpose. - -This makes it possible for me to share common configuration between a multitude -of entirely distinct machines, including an `x86_64` desktop, an `x86_64` -laptop, an Apple Silicon Macbook running NixOS `aarch64` using [Asahi -Linux](https://asahilinux.org/), and the same Macbook running macOS with -`nix-darwin`, sharing `home-manager` configuration with NixOS. Specific -configuration necessary to adjust hardware-specific details between each -machines are isolated to the [hosts](./hosts) directory. - -This works exceptionally well, evidenced by the fact that I have (almost) the -exact same environment across three separate machines, spanning two entirely -distinct CPU architectures. - -In essence, the primary failure of deployment scripts, Ansible and the like is -that they are _imperative_ - they must specify precisely _how_ to set up the -system, down to minute details, whereas in a _declarative_ approach, the user -can simply specify what the system _should look like_, and abstractions take -care of the _how_. This is what NixOS does, and it gives you remote syncing, -versioning (via `git`), and rollbacks _for free_. - - -## Installation guide - -Currently there is no streamlined installer. Please see [the reference -implementations](./reference) for an idea on how to set up a liminalOS system. - -## FAQ - -### This looks like a collection of NixOS configuration files and modules. What makes it a distinct distribution? - -Most Linux[^1] users will agree that any self-respecting distribution must -include at least the following: installer, package manager, and some set of -default packages. Therefore, anything that implements the aforementioned items -must also be a Linux distribution. - -liminalOS comes with the Nix package manager (nobody said you need a _unique_ -package manager - Ubuntu and Debian are distinct distributions yet both use -`apt`), a custom desktop environment comprised of Waybar, Hyprland, rofi, as -well as various applications installed by default, and -[the means to generate an installer](https://nixos.wiki/wiki/Creating_a_NixOS_live_CD). -Therefore, liminalOS is a Linux distribution. QED.[^2] - -### Should I actually install this? - -Sure. + %% Styling + classDef default fill:#f9f9f9,stroke:#333,stroke-width:2px; + classDef sysmod fill:#a8d1f0,stroke:#333; + classDef hm fill:#b8e6b8,stroke:#333; + classDef hmmod fill:#d1f0a8,stroke:#333; + classDef linux fill:#f0a8a8,stroke:#333; + classDef darwin fill:#f0d1a8,stroke:#333; + classDef pkg fill:#d1a8f0,stroke:#333; + classDef host fill:#a8f0d1,stroke:#333; + classDef build fill:#f0f0a8,stroke:#333; +``` ## Hosts