[anandsuresh]

Love to see more adoption of Nix and NixOS.

I started my Nix journey a little over a year ago, and I regret not having switched sooner. A package-manager that also ships an operating system that can be customized from the bootloader up, using a purely functional programming language is the perfect configuration management tool!

It does have some rough edges, and I did lose some hair figuring things out early on, but it has been getting better with each passing day. Pretty much the entirety of my setup at home is now built by Nix and runs NixOS, including my Macbook Air (runs NixOS on ZFS), and two Mac-Minis that PXE-boot a custom NixOS served by a Raspberry Pi 4 running a custom NixOS configuration that also acts as a firewall connecting wirlessly to my ISP's router. The Mac-Minis also double as build machines which makes for a pretty smooth experience when I'm building anything on my work laptop (a 2020 Macbook Pro running Big Sur) that I dock with my CinemaDisplay, which is wired thru an unmanaged switch to the rest.

So far I haven't missed any packages that I could not find in nixpkgs, or customize just the way I wanted to. The community is pretty responsive and quick to merge any pull requests for fixes/upgrades. I would whole-heartedly recommend switching to Nix/NixOS/Nixpkgs.

[SkyMarshal]

Same. I've been meaning to take the time to learn and switch to NixOS for several years now, and finally had some time to do it this past spring.

I haven't been this happy and giddy with a new piece of technology since I completely eliminated Windows for Ubuntu back in 2009.

There was a learning curve that took several months, but now that I've got everything I had on Ubuntu running smoothly on NixOS, I could never go back. And this for my daily driver, not a server or anything.

My favorite part is how it enables rapid experimentation with different build configurations, without any concern about borking the current working build.

If the new build breaks something, a single command rolls it back to the prior working build.

If the new build crashes the system, just reboot and choose the prior working build in GRUB. When you're logged back in, call the rollback command to point the system back to the working build.

This makes learning and testing both Nix itself and your particular system build faster, easier, stress-free, and just downright fun, which is invaluable.

Declarative, deterministic, immutable OS builds is a significant step out of the tarpit of software complexity.

[anandsuresh]

Congrats on your journey out of the tarpit! :)

[SkyMarshal]

You too :)

[altgans]

I switched to NixOS half a year ago. The reason? I fell in love with literate programming (I use [1]); being able to write (and read) your whole OS configuration is the dream!

There are few bad sides to NixOS though.

The community consists mostly of programmers, which means I am missing some creative tools (mockups, mindmaps, ..). In the future I will be able to provide/build them myself, but it is not a smooth transition from my previous arch setup.

Also the whole documentation sucks: There are three (!) official manuals + the home-manager manual + Nix pills + YT + random blogs where I have to piece everything together.

Still I find NixOS superior to every other OS (windows, linux) I have tried so far. I just feel free and am not afraid to fuck up anything [2], as I can just go to a previous generation when it doesn't boot.

Lastly, I can save my whole config in git and am free to try new tools -- If I don't like them, I just remove their line in my config. No more chasing after random install folders! (Except in home..)

[1]: https://github.com/driusan/lmt [2]: All the "hacker" stuff: kernel modules, network hardening, ...

[skerit]

I really like the idea of NixOS, but there not being a single clear guide of how to set everything up (and the messy documentation) is the biggest thing holding me back. I also really don't like wasting so much time on tinkering with my system the way I used to do.

But I'm seeing so much Nix news these past few weeks, I guess it'll be better in a few years!

[altgans]

I think you can get going with little to no knowledge. Setup the system, choose a few cool options and packages, and go rebuild. Simple as that.

The difficulty comes from the advanced topics. Modularizing your setup, writing your own packages, generally going off the beaten path.

I did not do any of that (yet). I will in the future, but I am fine with my low-level setup. One machine, one user. A bit later I moved to Nix Flakes (which is just an additional wrapper file around the previously written config) and added a few overlays.

My trick: I downloaded every single public "NixOS" dotfile repository I could find, and then just used "ripgrep" to find anything I was interested in.

Another cool trick I read is setting up a VM to test a small config and get a feeling for it, and then decide if yo want to proceed.

[pxc]

NixOS' saving grace when it comes to the learning curve is that experimentation is extraordinarily safe, thanks to the declarative config and rollback functionality. If you don't know what you're doing, you can pretty painlessly get away with just fucking around.

[anandsuresh]

Not just that. The ability to enter a sandboxed shell environment, play around with as many packages as you can get your hands on, and then exit back to my clean machine is my absolute favorite feature!!!

SO many times in the past, I'd be concerned about installing new things because they'd break my otherwise pristine developer environment. Yes, rvm/nvm/virtualenv and others help, but they fail to hold a candle to the nix-shell!

[SkyMarshal]

>I really like the idea of NixOS, but there not being a single clear guide of how to set everything up (and the messy documentation) is the biggest thing holding me back.

Yeah this part is messy, and why I always disclaim that I had a learning curve of several months to make the transition. However, my system setup is a little more complex than the standard install - mirrored ZFS root drives on dual m.2 drives, with mirrored boot partitions. That wasn't in the docs, needed a blog post to explain it [1].

>I also really don't like wasting so much time on tinkering with my system the way I used to do.

I've found that once you get everything configured to your liking, you spend similar or less time tinkering than on other OS's, just because the entire system config is captured in a single config file now. There's some up-front learning and work required, but after that it's smooth sailing.

[1]:https://elis.nu/blog/2019/08/encrypted-zfs-mirror-with-mirro...

[SkyMarshal]

I should add, to be fair to NixOS and the team, that there are three main official documenation sections: Nix, nixpkgs, and NixOS:

https://nixos.org/manual/nix/stable/

https://nixos.org/manual/nixpkgs/stable/

https://nixos.org/manual/nixos/stable/

Anyone looking into transitioning to NixOS should take a leisurely weekend and just read through all three of those first. Being at least familiar with all of what's there will make getting up and running a lot smoother.

[SkyMarshal]

>The community consists mostly of programmers, which means I am missing some creative tools (mockups, mindmaps, ..). In the future I will be able to provide/build them myself, but it is not a smooth transition from my previous arch setup.

Any time you need a package that's not in nixpkgs, feel free to submit a packaging request for it:

https://github.com/NixOS/nixpkgs/issues/new/choose (Issues -> New Issue -> Packaging Request)

Especially if you explain that it's a popular tool in the creative community, that kind of thing is useful for the Nix packaging team to be made aware of. Even if someone doesn't package it right away, there's a good chance it will make it into the next 6-month release cycle.

[k__]

Cool.

I just played around with R the other day and it would use MD too to generate HTML/PDF.

It uses Knitr.

https://kbroman.org/knitr_knutshell/pages/Rmarkdown.html

[altgans]

That sounds like a nice way to do it, too. I heard about it before, but don't know R, so I didn't really consider it.

The reason I chose lmt is that it correctly keeps the markdown language syntax of the code blocks. That means I can put my literate config into my Zettelkasten [1] or [2] and watch it pretty-print in the browser.

There are also literate [3] and org-babel [4], but I don't think they are future proof. .lit is a random format and .org basically requires Emacs+orgmode.

1: https://github.com/srid/emanote

2: https://wiki.dendron.so/

3: https://github.com/zyedidia/Literate

4: https://orgmode.org/worg/org-contrib/babel/intro.html

[k__]

Do these things work with any programming language? Like, do they still allow for "squiggly lines" (linter/static typing) in the editor?

[altgans]

For lmt/markdown: I believe yes, to the extend the editor allows for it. It is seemingly just like regular mardkown code blocks. I get the correct syntax high-light in the ``` code blocks. I don't have lint/LSP setup yet (currently moving to Neovim), so I can't say anything about that.

Literate/.lit: I don't know, I guess not.

Emacs/orgmode: Yes, this also does syntax highlight. And you can edit the code-block in a separate window as if it was a "real" source code file. I've been using this for almost two years now. Personal opinion: I don't think the benefits of Emacs outweight the cons.

[amelius]

> I just feel free and am not afraid to fuck up anything

Until you have to install the latest NVidia drivers, I suppose.

[altgans]

Luckily not [1].

1: https://nixos.org/manual/nixos/stable/#sec-x11-graphics-card...

[amelius]

That's because someone already did the porting and testing for you. But what if you want the latest video and CUDA drivers?

[joepie91_]

"not afraid to fuck up anything" likely refers more to the ability to rollback the system to any (non-deleted) previous revision of the system configuration, directly from the bootloader, which means you can easily recover even from a broken kernel.

This applies regardless of whether you are packaging/updating something in the package set yourself, or using something that someone else packaged.

[Apaec]

> That's because someone already did the porting and testing for you

The same happens on all package managers...

[amelius]

No, you can get the installer directly from the NVidia website, but only for selected platforms. If you're on a different platform, you'll have to wait until somebody ported (read: hacked) the release (or do it yourself).

[Filligree]

No, that’s not any harder than anything else.

[dnr]

Hate to make a boring me-too comment, but I feel the same: I've been using it a bit over a year, and I wish I had started even sooner. Now I've got two laptops and a NUC, plus two odroid-hc4's, all on NixOS. All the system configuration that used to be half-broken ansible and a pile of scripts (plus all the one-off hacks that weren't even captured anywhere) is now nice pure nix configuration. I've nix-ified builds for a bunch of personal projects too.

Yeah, it took a few months to learn, and there are still lots of rough edges, but going back to a non-Nix linux distro would feel like going back to windows. I agree with the sibling comment that it makes me feel happy and giddy, like no other technology I've learned recently.

[spindle]

A boring "me too" from me too!

[whateveracct]

> So far I haven't missed any packages that I could not find in nixpkgs, or customize just the way I wanted to.

And it's honestly not that hard to package things that aren't yet Nixified. Any C project is easy - I've learned more about cmake from mkDerivation that anywhere else.

And overlays make it easy to make tweaks to a build without straight-up forking. Beautiful!

[joepie91_]

> I've learned more about cmake from mkDerivation that anywhere else.

This is something I find really fascinating about Nix (or more precisely nixpkgs) that gets overlooked a lot: it is essentially a giant database that documents how different build tools work, how different projects are built, and so on, in an exhaustive and consistent manner.

That can be an extremely valuable resource to have in your back pocket, even if you're not actually using Nix!

[anandsuresh]

Could not agree more. I've learned more about build systems and different compilers by reading through Nix code than any other endeavor in the past.

[spindle]

I always think it's worth mentioning explicitly that NixOS makes it not just possible to put everything including the root file system on ZFS, it makes it completely easy.

[GekkePrutser]

It's not unique at that though. FreeBSD has had this for a decade. And Ubuntu is adding it now as an installer option.

PS: I do like the idea of NixOS and its USPs which are indeed unique :)

For me what's stopping me is the learning curve. I don't mind learning per se but if I put the time in it I'd like it to be for something that's useful in more places. Like ansible.

[pxc]

What's interesting about NixOS' seamless NixOS support is that ZFS can't be included in the Linux kernel, and so that kind of integration takes more work with Linux distributions, so relatively few distros have it down pat.

BSDs don't face that kind of integration challenge, since they can just ship ZFS support directly in their kernels. They have recently faced an integration challenge of their own, though: rebasing their ZFS implementations on OpenZFS (f.k.a. ZFS on Linux).

Anyway ZFS is great and I hope OpenZFS' multiplatform support gets so good it can become popular on Linux, *BSD, and macOS all at the same time. :D

[altgans]

Can you elaborate a bit more on why ZFS is great? I am currently thinking about doing "one final install" for my system, and am undecided between BTRFS and ZFS.

I noticed that most "hip" people use ZFS, but based on my meager research it seems actually recommended and designed for "big" data-center setups.

Why is ZFS good for small PC setups?

---

If am being honest I just want something that works reliably, is easy to extend and doesn't require maintenance. Maybe ext4 is good enough?

[pxc]

If you have a single disk, BTRFS is probably as good as ZFS for you.

ZFS is mature and featureful, and it's easy to performance tune specific subdirectories using 'datasets' (on BTRFS you can do some of the same stuff with 'subvolumes'). It has good utilities for backup, including over the network. It always supports up to date, efficient compression (these days, zstd). It's good at pooling, so you don't need LVM if you want to be flexible about 'partitioning'.

One genuine advantage it has over BTRFS other than stable softraid support is that it's cross-platform among Unices, including (in incipient form) even macOS. So experience you gain in administering it would be transferable that way. (OTOH, Windows has a pretty mature BTRFS driver, but ZFS on Windows is even more recent (and difficult) an effort than ZFS on Mac).

Truthfully, ext4, BTRFS, and ZFS are all fast and stable, and once you set them up your filesystem, you'll probably hardly think about it. (If you go with ext4, I'd set it up on LVM to make it easier to extend or 'repartition' in case you wanna structure things differently or add another distro or whatever.)

Linux's heritage and continued use as a server OS makes it rich with fast, reliable, flexible, feature-complete filesystems. All three of your options here are better than what's on offer on any Windows or Mac desktop, so you kinda can't go wrong, so don't overthink it. Just pick something you feel like learning or whose documentation strikes you as agreeable and interesting. Whatever you choose will serve you fine until your disk dies or you get bored. :)

[joepie91_]

> I don't mind learning per se but if I put the time in it I'd like it to be for something that's useful in more places. Like ansible.

Depending on whether you mean "used by more people" or "applicable to more problems"... if the latter, tools like morph or NixOps might be of interest to you, which essentially extend Nix to "across multiple remote machines", which means that de facto you end up with an orchestration tool like Ansible or Puppet.

[SkyMarshal]

>It's not unique at that though. FreeBSD has had this for a decade. And Ubuntu is adding it now as an installer option.

Right, but FreeBSD isn't Linux, if you want both ZFS and the Linux ecosystem, then I would argue NixOS is the best at that right now.

I tried Ubuntu and ZFS recently in a VM just to see how it worked. The installer handles a simple, standard ZFS config just fine. But if you want to do anything more complex, then you're doing manual configuration, at which point it's better to just use NixOS, where all the manual config is done in the main NixOS config file.

[heinrichhartman]

#MeToo. I am using two OSX machines and two remote Linux machines for my day-2-day private/work related stuff.

Nix+home-manager allows me to have all productivity tools consistently available across all platforms with minimal effort [1].

Dotfiles/shell config lives in a separate folder [2] and is not managed in nix.

Tangent: Secrets are are encrypted with git-crypt (https://github.com/AGWA/git-crypt) and live in the same repo [3]. I generate GPG keys for every new host I am working on and check in the public keys to the repo as well, then "approve" them from an authorized host using `git-crypt add-gpg-user ... && git push` [4]. This gives strong encryption without managing passwords by hand. [Copy of private key is kept in bitwarden as backup].

Getting the hang of Nix took me a while. I wrote-up my journey to get the latest-gratest emacs installed here [5]. But now I am over the bump, and it's adding value to my workfows. E.g. I switched some projects from docker to nix-shell for lightweight virtual-envs, e.g. [6].

[1] https://github.com/HeinrichHartmann/dotfiles/blob/master/nix...

[2] https://github.com/HeinrichHartmann/dotfiles/tree/master/.sh...

[3] https://github.com/HeinrichHartmann/dotfiles/tree/master/sec...

[4] https://github.com/HeinrichHartmann/dotfiles/tree/master/pub...

[5] https://www.heinrichhartmann.com/posts/2021-08-08-nix-emacs/

[6] https://github.com/HeinrichHartmann/HeinrichHartmann.github....

[yissp]

> #MeToo

maybe best to avoid that https://en.m.wikipedia.org/wiki/Me_Too_movement

[AnIdiotOnTheNet]

> Love to see more adoption of Nix and NixOS.

I don't want a 'journey' to use my OS. I don't want to learn a whole new language and set of overengineered abstractions to solve what I see as, at most, 5% more of application installation problems that are already 75% solved by package managers[0]. If the Nix community wants more people using Nix, they'll have to make it more attractive for those of us who do not want to waste so much time needlessly learning new stuff to do the same things we're already doing.

[0] which are already an overengineered and under-delivering solution in my opinion.

[kokada]

> I don't want a 'journey' to use my OS. I don't want to learn a whole new language and set of overengineered abstractions to solve what I see as, at most, 5% more of application installation problems that are already 75% solved by package managers[0]. If the Nix community wants more people using Nix, they'll have to make it more attractive for those of us who do not want to waste so much time needlessly learning new stuff to do the same things we're already doing.

This is fair, but keep in mind that package managing is only a small part that what Nix solves, and it is a much superior solution than anything else that I know (Docker for example is not really reproducible because you can't trace all dependencies; this seems like a philosophic issue but I saw some containers breaking because some dependency inside the container was updated without nobody knowing).

If we take NixOS, it also solves the issue with configuration, and with some auxiliary tools it also solves issues with deployment. You have alternatives for both of the issues too, but the fact that NixOS is much more integrated than any tooling (like Ansible, Puppet, etc) means you have much more flexibility. Also, don't forget atomic upgrades and fallback.

Eventually, instead of "wasting time", NixOS starts to save time by becoming the most reliable OS you ever used: you will never waste time anymore reinstalling your system from scratch, or if your hardware broke, you will never waste days trying to get your system to the same way it was. Also, because nixpkgs is enormous, you also tend to save time by not looking at "oh, this program seems cool, how can I install it on my computer since I never heard of this XYZ language?", and them installing the package manager from the language in 5 different ways because you have no clue. And even when you need to package the program yourself, nixpkgs has many abstractions that makes it much easier.

So instead of wasting time, Nix and NixOS is an investment. You may choose to invest your time right now to save later or not. Either way is fine.

Just to finish the topic, I fully concur yo you that we as a community needs to have better documentation.

[sjustinas]

That's absolutely fair, I don't think either the parent or the NixOS devs implied in any way that it should be the right fit for everyone or 100% of the Linux distro market share is the end goal.

For me, the benefits outweigh the quirks of the language. As my alternatives to manage multiple machines consist of: wonky Bash scripts, similar tooling but bolted-on on top of the distro and with no built-in rollbacks (Ansible, Puppet, etc.), or trying to get everything right manually, Nix does not seem like the worst out of this bunch.

[ris]

What I'm hearing is "I really don't like the way traditional systems are designed and I don't want to have to learn anything new!"

Nix is different, unapologetically so, that's the issue. And if it had to be more orthodox to win over a few more itinerant users that would make the whole thing pointless.

[AnIdiotOnTheNet]

I'm not asking it to be more 'orthodox', I'm asking to not have to spend months scouring poor documentation to learn a new language and toolchain to gain the very few benefits Nix provides over the existing systems. If Nix is so inherently complicated it cannot deliver that, then why would I want it?

Ultimately I want less complication in my life, not more, and Nix very much does not provide that from what I can see.

[e3bc54b2]

Traditional systems have complexity too. Its just not up front.

I like to compare it to fossil fuels and global warming. Traditional systems get one started quick, but eventually build a large fragile system that gets harder to fix/rebuild the longer it goes on.

Nix is different, it forces you to do your work upfront. But once setup, you pretty much can (and to my attestation do) forget it is in place. You do have to learn setting a anything a and everything. But you only do it once. If the house burns down, you don't need to remember what you had. You don't need to remember what to setup in what order. You don't have to find out you forgot something in the middle of something else. In other words, the onus is no longer on you.

That last sentence is incredibly liberating. I stopped worrying having black screens after updates and pretty much stopped having rescue disc, because rescue functionality comes built in the system. It sounds cultish, and it kinda is, but as I said in previous comment on Nix, it is the worst system management tool, except all the others.

[ris]

Oh, I use Nix because it does provide less complication in my life. It's just necessary to wrap your head around a few core principles first, which can be a little mind-bending when you start out (no fixed /usr locations? huh?)

[zeec123]

It is like saying I don’t want spending months to learn git to gain the very few benefits of a version control system. I much prefer to share my code with my coworkers via usb-sticks. Yeah this is less complicated in the short term.

[AnIdiotOnTheNet]

I honestly don't want to learn git precisely because there are version control systems that accomplish the things I need in a much simpler way. I only bother using git at all because some FOSS projects I've worked with use it. Hell, my impression is that most people who use git don't bother really learning it, they just keep a recipe book of how to branch, commit, etc. and then rely on stack overflow to un-fuck the repo after they accidentally blow it up.

[anandsuresh]

I could not agree more. Most people, IMO, are workflow junkies! It doesn't matter how good/bad/ugly the tool is; if it works, it stays forever! And git is a perfect example of a tool that is complex, but survives because it became the gold-standard for FOSS.

Having said that, wouldn't you agree that same recipe-book approach is also true for traditional system configuration/administration?

[anandsuresh]

Nix operates at the cusp of some of the most complex and obscure parts of the technology stack: operating systems, compiler toolchains, and package managers. These inherently complex components require a fair bit of commitment to fully comprehend in order to be used well. You can get a lot of mileage skimming through some tutorials to become productive, but to really utilize it to its full potential requires a fair bit of investment. You don't have to be an automotive expert to drive a car, but if you're looking to race, it behooves oneself to invest the time it takes to gain the expertise.

Nix takes a very different approach to system configuration than the traditional ways. Because it treats the entirety of the operating system (bootloader, kernel, user-land, services, account management, etc.) as a single composable unit, it is forced to break some old rules that date back to the oldest days of Unix and are (now) considered to be written in stone. The deviation from the Unix Filesystem Hierarchy is, IMO, required to make systems more composable and maintainable, and is inherently a good thing in the long run. Portable development environments eliminate "works-on-my-laptop" scenarios and ensure everyone on the team is always in sync with each other and CI/CD. Reproducible builds that can be rolled back after a botched deployment are a huge win. And delivering all of these features in a single tool requires breaking some of the old rules, and that is always met with resistance due to the inertia of "it works fine for me".

To be honest, there is no reason why you should give up what works well for you. Having said that, for those that are looking beyond the traditional tools like shell-scripts, Ansible, Chef, Puppet, and others, Nix offers all that is needed to easily build and maintain composable software stacks. Docker comes close to delivering some of the same features as Nix, but comparing the two is a bit like comparing system configuration using shell scripts to Chef/Ansible.

Yes; one does have to learn a new language and its idiosyncrasies. But that is also true of things like Rust. As a seasoned C programmer, I am able to write "good" C code. But that is not a statement about C's ability to scale to larger teams. Rust requires developers to give up their old ways of thinking and "give in" to the Rust-way. The longer you fight the borrow-checker, the more painful it gets. But once you give in, you are able to write code that is safer for use within large teams, thus delivering more momentum in the long run. It is not that it can't be built with C; it requires a communal way of thinking about software complexity that is forged by experience and tempered by camaraderie, and tools like Rust and Nix are excellent supplements.

I do agree with you that the documentation leaves a lot to be desired. I've always considered the FreeBSD Handbook to be the gold-standard for technical documentation and Nix has its work cut out to reach that stage of maturity. But I have full confidence in the Nix community's ability to deliver.

[pxc]

> it is forced to break some old rules that date back to the oldest days of Unix and are (now) considered to be written in stone.

On the other hand, one of Nix's greatest strengths is that in many respects, its innovations are conservative. It brings software building and distribution forward in terms of reproducibility and isolation (like containers do) but (unlike containers) also retains the traditional package management virtues of granularity, efficiency, and sharing common resources (dependencies) when possible.

[rgoulter]

> I don't want a 'journey' to use my OS. I don't want to learn a whole new language and set of overengineered abstractions to [do development work]

This is pragmatic.

Nix somewhat reminds me of the kinds of mindsets that enjoy learning Vim/Emacs, or learning how to use 40%-sized keyboards like the Planck. -- I think it takes curiosity to be interested in that kindof stuff.

[IshKebab]

I agree. I love the idea of Nix. At least what I think is the idea - basically Bazel as a package manager. But the actual implementation is inaccessible.

If someone could make a user-friendly implementation of the Nix concept I think it would be very popular.

[joepie91_]

> set of overengineered abstractions

While there are definitely a lot of remaining documentation and usability issues with Nix as it stands today, the core model is far from 'overengineered' - if anything, it's orders of magnitude less complex than the organically-grown cobbled-together pile of tools and conventions that 'traditional' distros are made out of.

Nix having a well-defined, complete, specified-upfront, coherent model doesn't make it 'overengineered'; it just means that the tools were designed from the start to help you manage the complexity of system management, rather than just kind of leaving it implicit and letting the end user and/or packager deal with the fallout later through an ever-growing collection of workarounds and patches and scripts.

It's completely valid to decide that NixOS is not (yet) for you due to the learning curve that still exists; I frequently warn people away from NixOS (when they are not prepared to deal with that) for this precise reason. But please don't conflate that with 'bad design'.

[pxc]

> [package managers] are already an overengineered and under-delivering solution in my opinion.

This is kinda nuts to me. Every time I use a system that doesn't offer proper package management, it makes me wish I had a decent package manager. What do you think is better than a modern package manager for solving the same problems?

[muth02446]

This super interesting to me as I am currently PXE booting Ubuntu which is a pain every two years when I switch the new LTS release. Do you have some pointers or configs to your setup?

[anandsuresh]

Not in any usable form. But I do intend to blog about it once I clean it up.

[bambambazooka]

Is your config available? It sounds very interesting and complete. Especially the PXE boot from a pi sounds great!

[anandsuresh]

Not in any usable form. But I do intend to blog about it once I clean it up. :)

[ashtonkem]

There’s a small amount of homelab stuff I need to spend the time porting to nixos. Grafana is in there, for example, but pihole is not. I currently run a weird mix of VMs because of this, and I’d like to make that more homogenous.