Hacker News Reader

Comment by AnarchismIsCool | Hacker News Reader

I know it's becoming the new "I use arch btw" meme but if you go down this route I highly recommend using nix as the distro. Ideally you can just leave these systems running once they're working and using nix means all your system state is logged in git. No more "wait, how did I fix that thing 6mo ago?" or having to manually put the system back together after a Ubuntu dist upgrade explodes. Every change you've made, package you've installed, and setting you've configured is in the git log.

I find myself referring to my git repo frequently as a source of documentation on what's installed and how the systems are set up.

View on HN

I use nix btw.

I totally agree. It (nix and nixos) is/are such a pain so often. But, wow... when you get things to work it is glorious.

Quickly and easily syncing system/user/application configurations across multiple devices is incredible. The declarative approach means that the often laborious effort it takes me to get things to work pays off when I finally figure it out and realize I never have to do that again - and since it's declarative, I now have a documented functional configuration/example to grow and expand from.

My current project is to learn Nix development environments by building "Linux from Scatch" from Nix. I am making progress slowly, but every success is cemented and replicatable.

LLMs definitely help distill the sparse/scattered documentation, but I am finding a good amount of grit is still required.

All in all, I am very much enjoying Nix and hope to utilize it more in my homelab.

I got into Guix and then failed. Now I realise it's because I didn't fully understand the nix philosophy underneath. Can you recommend any good tutorial points for an intermediate/experienced unix person?

I just feel it doesn't have to be this way. We can get the benefits of nix without the hardness of nix. It's just someone hasn't taken the time to make this "thing" yet.

It's annoying enough that I won't use nix personally. I've used it at work so I'm quite knowledgeable with it.

IMO, this thing is Nix, it just needs better UI and a lot better documentation.

The problem I've realized is that for many core Nix developers, the source is the documentation. Which doesnt scale.

Luckily the ecosystem is literally getting better by the hour right now. There's been a huge uptick in interest and lots of people are writing really good documentation and starter templates.

> It's just someone hasn't taken the time to make this "thing" yet.

DietPi [1] has one massive (15KLoC) bash script [2] for system config.

[1] https://dietpi.com

[2] https://github.com/MichaIng/DietPi/blob/master/dietpi/dietpi...

Not exactly an easy nix alternative

Easy for users, one step backup and restore of system-wide state.

Less easy for developers, but code is mature and stable in production for years.

> sparse/scattered documentation

I've been hearing more and more from people switching over to NixOS, so hopefully the docs will get better as well

I wish Nix had a shallower learning curve (or that I was smarter). It's been on my list of wishes to play with, but that list is long, and getting Nix over the hump hasn't been something I've been able to do yet. The concept makes sense to me, but when I see a new package or app I want to play with, I can get there with docker-compose and a VM more quickly than I can wrap my head around doing it in Nix.

If you get the base system up you don't have to exclusively use their containerization system. I have a mix of nix environments and k3s deployments that are saved off in another git repo. There are advantages to purity but practically speaking you can just do what's convenient.

Its just a matter of repetition. It will eventually click if you go back enough times (at least it did for me after like 4 tries). The biggest thing to getting your mind adjusted to the syntax is to understand that nix is just 1 big JSON blob. All the syntax is there to facilitate merging/updating that ball of JSON in a deterministic way.

You might try to generate your docker containers using nix as a first step. Not sure if it will be more approachable for you, but at least its 1 less new thing to adjust to.

I’m going through the NixOS journey right now, and it’s a combination of easier than I thought, but also more frustrating than it should be.

Getting a basic system going seemed about as easy as Arch (if you consider Arch easy). But adding flakes and home manager to the mix is where things have run off the rails a bit for me.

I think a lot of the steepness of the learning curve comes from trying to go all in on flakes/home manager up front, and a lot of the online discussions and quick starts being oriented towards this goal. I’ve since scaled back my aspirations a bit and I’m focusing on just understand core NixOS with a monolithic config file until it makes more sense to my brain.

If you haven’t get, check out vimjoyer’s channel on YouTube. His content has been the most helpful for me by far, and it got me a basic setup going that I’m now iterating on. What I do love is that I feel like I can iterate with confidence. I have no idea what I’m doing for the most part but I know I can get myself back to a working state.

I think it will be worth the time investment in the long run, but yeah, it’s been a bit weird and the lack of a canonical approach makes it hard to break into the ecosystem.

For what it's worth, I personally do use Arch for my homelab and still achieve cattle not pets because the Arch install media comes with cloud-init so I simply keep a cloud-config with the modules to build a server from scratch on a separate USB stick with a drive that has "cidata" on a label and plug that into a machine along with the install media before hitting the power button. I don't know if Nix would have been easier but cloud-init just lets you run scripts that you presumably already know how to write if you're the kind of person who does this sort of thing. No need for a DSL.

Someone is going to chime in with "boo yaml" and sure, but a person interested in running a homelab is almost certainly a person who manages a bunch of servers for work too and there's no escaping cloud-init, Ansible, Kubernetes, or something using yaml that you're not going to have a choice about. Assuming the point of a homelab is at least partly to practice what you do on the job without the possibility of destroying something owned by someone else (which is what this guy says his reason was), you may as well get used to the tools you're going to have to use anyway and not make your home setup too much different than the environment you manage at work.

Of course, I know a lot of people on Hacker News are not like me and this guy and use "homelab" to mean they want to self-host media servers, chat, and photo sharing and what not for their family and friends, not have a mini data-center as a practice ground for the real data center they manage in their day job.

Same, I originally had a bunch of RasPi's in my lab running differing versions of Raspbian until I got tired of the configuration drift and finally Nixified all of them. Writing a single Nix Flake and being able to build declarative SD card installation images for all of them makes managing a bunch of different machines an absolute dream (tutorial here[0], for those interested).

The only issue is remotely deploying Nix configs. The only first-party tool, nixops, is all but abandoned and unsupported. The community driven tools like morph and deploy-rs seem promising, but they vary in terms of Flakes support and how much activity/longevity they seem to have.

[0] https://blog.janissary.xyz/posts/nixos-install-custom-image

I can vouch for deploy-rs. Used it for years without issues. Flake support is built in and activity is pretty good.

Disclaimer: I am a relatively active contributor

Im really happy with nixinate if you havent tried it. Basically does the bare minimum so theres no real concern over continued development.

> ...or having to manually put the system back together after a Ubuntu dist upgrade explodes.

I avoid this by running Gentoo Linux on my Linux machines. I've heard people say good things about Arch, but I've never used it.

Ubuntu is just bad... I say this as someone who used Ubuntu for a few years waaay back when (and was _really_ pleased that I finally could recommend a reliably, easy-to-use Linux distro to nontechnical folks), but swore off of it after the second or third in-place upgrade (in a row) that left my system nonfunctional in ways that required the sysadmin knowledge I'd gained from going through the well-documented Gentoo setup process (and from tinkering over the years) to repair.

Friends don't let friends use Ubuntu.

Agreed - I'm willing to use Ubuntu LTS on servers that are basically glorified LAMP machines (LCMP?) - but for home servers, nothing has beat Gentoo, not only for the full understanding of "what I have" but also having direct control over what I've got running, including quite a bit of customizability if needed.

Gentoo on ZFS is kinda nice.

I want to love arch, but it is way too complicated. I _love_ complicated things, but arch just didn't seem worth it.

My home lab journey was:

manual installs -> Ansible -> Docker + Docker Compose -> Kubernetes (I told you I loved complicated things)

I kept everything source controlled. This repo documents my long journey: https://github.com/shepherdjerred/servers

Docker and Docker Compose are nearly perfect. Here's an example of what that looked like for me: https://github.com/shepherdjerred/servers/blob/839b683d5fee2...

I mostly moved to Kubernetes for the sake of learning. Kubernetes is very cool, but you have to put in a large amount of effort and learning before it becomes beneficial.

Ansible is nice, but I didn't feel like it met all of my needs. Getting everything to be idempotent was quite hard.

I use a single to set everything up, including docker and docker compose. most applications are running in docker compose. but ansible allows me to handle all the hard drive mounts and other stuff that can't be run inside docker containers.

That's not a bad idea!

I didn't mind manually installing Docker, configuring fstab, etc., since it was such little work.

I actually went the complete opposite way and I run RHEL (Red Hat Enterprise Linux - with the developer subcription) or RockyLinux at home.

Because:

> "wait, how did I fix that thing 6mo ago?"

Such things just don't happen. That thing (RHEL/RockyLinux) just doesn't break. I do update software once every six (or more) months, reboot and it just works.

I have notes on how I did stuff, if necessary. I used to keep ansible playbooks but they were just an overkill. Does it even make sense to write a playbook for a system that I'll reinstall in three or four years ? Probably not.

One of my main systems at home has been running RHEL 8 for 3-4 years, still happily getting updates. I plan on replacing the whole box, with another one running RockyLinux 9.

And I'm moving from RHEL to RockyLinux because I just don't want the yearly annoyance of having to renew the Developer Subscription license.

That's how reliable it is: I have to look up my notes once a year, and it's too much.

I run most of my stuff in containers anyway, and podman is just great.

>I have notes on how I did stuff, if necessary. I used to keep ansible playbooks but they were just an overkill. Does it even make sense to write a playbook for a system that I'll reinstall in three or four years ? Probably not.

Yea, sure, except what if the one-time configuration was in a Nix file that will continue being exactly as useful for years?

Folks applying the Ansible mindset to NixOS are missing the point. NixOS is *not like a runbook*. It's declarative, it's prescriptive, it's not some god-forsaken state machine that tries to paper over the horrors of modern computing. It IS the definition of my computers, not some glorified pile of scripts and conditional checks encoded in fking jinja. The same as it's been mostly for 8 years now.

x doubt

Which part? Like, that's what NixOS is. My config repo is declarative, describes in its history every machine I've owned. You could rebuild them at any point in time and get an identical exact machine image out.

Idk, this is why it's hard to talk about nix with people that think they know it but then also openly doubt things that you will one day take for granted if you take the time to learn it.

When people say Nix is declarative do they mean like SQL/Prolog?

> Yea, sure, except what if the one-time configuration was in a Nix file that will continue being exactly as useful for years?

Still useless. Software change, the configs i make today might not make sense or even work in 3-5 years.

Nix and stuff (ansible etc) only make sense if you have to reinstall your systems multiple times in a single week (fine if your hobby is reinstalling linux on your laptop).

But if you do a full reinstall once every five years then it’s largely an exercise in futility.

Except that Nix literally solves that problem by abstracting over the underlying config.

Y'all don't know what you're talking about and once again the Ansible comparison belies in.

>reinstall once every five years then it’s largely an exercise in futility.

You are as wrong as you think your are right, I'd know I've been using NixOS for 8 years. You're just wrong.

Nearly every time I do an Ubuntu dist upgrade, there is some relatively easy to solve but critical problem. A couple examples from a few years back: default route was lost, network interfaces were renamed. In both cases, remote connectivity was obviously lost. Good thing it was in my basement...

Ansible code in git solves the same problem for ANY distro

Once you stop templating yaml you will never go back.

Seriously as someone who has used ansible a lot and nix a bit, I'd take NixOS over Ansible+Debian/Fedora any day.

No, no it doesn't. It doesn't solve the same problem, at all, certainly not holistically like NixOS.

Reply on news.ycombinator.com