I want a declarative OS. Is NixOS it?

I'm sick and tired of having my ad-hoc modifications eventually bit rot.

Should I try NixOS? Is it a meme?

Can I achieve similar goals with just plain Gentoo? (I'm not afraid of high compile times.)

Attached: u6q10wkbjcg71.png (939x702, 346.36K)

Other urls found in this thread:

grahamc.com/blog/erase-your-darlings
twitter.com/SFWRedditVideos

Yes it is a meme. Literally can't make install one-off software without integrating it into their whole ecosystem as a package with its own config file for declaring that, etc. Or at least that's how it was on Guix.
The idea's not the worst, but it's too puritan about it and that causes problems. Completely axing compatibility with the FHS for example.

Entirely gave up on the OS when I realized I wanted to install VMWare, and that was just the first thing in mind

I am not too attached to FHS: I never do make install. I either run it from the build artifacts directory, or just create a proper .deb for it.

>Can I achieve similar goals with just plain Gentoo?
yes, but it won't be declarative, just the regular linux distro but better

In essence, I want minimalism and centralize my modifications so there is no bitrot in my configs. How would doing ad hoc modifications in /etc/ look like in Gentoo? Is it as comfy as ?

Everything rots.
Except the greatest OS ever made.

Attached: A1200.png (1024x768, 63.65K)

I know, I know. But everything these days is turning to shit. Pic rel was the best engine but now you have to use Chrome if your work involves interacting with the (((modern web))).
That is why I'm even considering NixOS even though Potteringware must die in a fire.

Attached: Presto.svg.png (1280x1321, 196.77K)

Amiga OS is still under active development.
Just need a Mon keked m68k proc to run it

what's the actual use case?
if upstream releases a new major version that breaks your old config, no distro can save you.

you're going to have to roll it yourself.
i've looked for this too - i hate the rot of random modifications too, and have taken an extremist approach for my personal system.
i settled on a set of hideous homebrew arch install scripts that don't provide login access to the machine at all, so if i want to change something, i have to alter the setup scripts and reinstall the system.
all these scripts do is set up a barebones kvm+qemu+libvirt hypervisor that prepares two guest systems - another arch system as a guest which using a similar setup but that grants root/login access obviously, and a windows system that does the same kind of shit but using the windows autounattend system plus a hacky hellscape of powershell setup files to set up my shit.
nightly, a cron job regenerates these two machines from their install scripts and the only things that persist are volumes i've expressly selected (home documents/pictures/etc, dev files, etc. no config, all config should be done via an install script. classifying config vs data has been tricky but not awful)
the end result is that i'm forced to commit my machine state as code either to have it last the night or to make any change to the base system at all.

The actual use case is keeping track of breakage, rather than learning about it whenever I need to set up a new system. Consider doing update my system state in the middle of a work day: if I just do it and forget to document it properly, then the next time I need to replicate my config somewhere I will need to debug this. If my config is centralized (e.g. configuration.nix or flags in /etc/portage) I can just go about my day.

This outcome is EXACTLY what I want except more lightweight and not involving a complete regeneration of a VM from scratch every time I want to install a package or edit a dotfile :-)

>then the next time I need to replicate my config somewhere
that's a really convoluted way of saying "never"

I wish... I have multiple desktops and laptops with ~identical configs

only the base system requires complete regeneration to make changes like adding packages. my workspace vm gives me the ability to add packages, but it's lost overnight. this has been really handy for building tools and one-off dev projects, where i can blindly install whatever i need without concern, then the next day it's cleaned back up. if i want to persist the new package, i need to add it to a list, but i have a set of helper scripts that assist with persisting certain things by adding things to config or adding folders to whitelists, but it's all opt-in instead of opt-out

FAANGs use Chef, Ansible, or Puppet for configuration management of their workstation fleets

Lot of NixOS haters who have never used it in this thread. I've used NixOS on a cluster of servers for work and for my desktop for about a year, I don't think I'll ever be able to use another linux distro (maybe guix if they unfuck it). It is perfect for forcing you to move your ad hoc modifications to a central list.

This is a blatant lie, cooking up a nix derivation to install some random shit off github takes like 5 minutes and once you do it the package is managed by the package manager which is superior to having to remember which random git repos you want installed.

grahamc.com/blog/erase-your-darlings

You can accomplish the same thing using nix-shell, it lets you install ad hoc dependencies that are only available in that specific shell environment (even if the dependencies are not installed as part of the main system environment). Say I want to start a new C project, I would run nix-shell -p gcc valgrind gdb, and that would drop me in to a shell with access to those tools even if they weren't installed. You can create a shell.nix in the project root where you list your dependencies, and then when you run nix-shell, it will automatically load them.

>grahamc.com/blog/erase-your-darlings
dope
>"Destroying the whole server doesn’t leave you much room to forget the little tweaks you made along the way."
this is why i started developing my system years ago. i use it for my personal servers and personal computers, and use a variation of it for a lot of my work servers. my coworkers were uncertain at first as they came on board but have grown to appreciate how obviously-declared server state is.
i'll experiment with this nixos thing, but i'm quite entrenched in my own system and its conventions at this point, and it's grown to accommodate my needs quite specifically.
>nix-shell
also dope.
when i started this adventure, no such projects existed to my knowledge. i'm really pleased to know someone is forging a publicly usable version of such a system. i really think it's beneficial to have my system state limited to a set of named, versioned, snapshotted data volumes plus a git repo of config and code. it inspires confidence in my system state and ability to mutate it and experiment without fear.

How would you recommend one start? I currently have NixOS is a VM and am going through Nix Pills but so far it is all very much intro about nix-shell itself, not about using it as a primary system. I'm afraid they will mostly cover things relevant to a dev environment or creating containers which is not my short-term goal, even if I want to use these eventually.
I have done SICP, programmed C++, done LFS so am familiar with Linux but want to be productive with NixOS ASAP.

Your system sounds pretty slick and accomplishes the same goal, just want to make sure NixOS is on as many people's radar as possible because I think it's such an underappreciated tool.

The nix pills are mostly for dev work, you only need to start digging in to those once you want to create your own packages and even then I'd still recommend just reading existing default.nix's from nixpkgs to get a sense for how things are done first.

If you really want to dive in, you really just need a configuration.nix, the nixos package search, and the nixos options search. There's a few packages with pretty intensive setups that they hide behind extra options (steam), or more involved setups (ZFS) where you really want to read the dedicated page for it, but I configured my NixOS install more or less blind for the first time and just learned new stuff as the need arose. Once you have your initial packages installed, it really is a *justwerks* system up to the point where you want to start modifying existing packages, at which point the learning curve becomes very very steep.