NixOS: How does daily driving fare for time-strapped users?

fool@programming.dev · edit-2 12 days ago

NixOS: How does daily driving fare for time-strapped users?

algernon@lemmy.ml · 12 days ago

I’ve been daily driving NixOS for about a year now, switched from over two decades of running Debian. I’ll try to answer your questions from my perspective:

How much can I grok in a week?

If you have some experience with functional programming or declarative configs (think Ansible), then it’s a lot easier. You can definitely learn enough in a week to get started. One year in, my Nix knowledge is very light still, and I get by fine. On the other hand, there’s a lot of Nix I simply don’t use. I don’t write reusable Nix modules, and my NixOS configuration isn’t split into small, well manageable files. It’s a single 3k lines long, 130k sized flake.nix. Mind you, it’s not complete chaos: it is generated from an Org Roam document (literate programming style; my Org Roam files are 1.2mb in size, clocking in at a bit below 10k lines).

With that said, it took me about a month of playing and experimenting with NixOS in a VM casually, a couple of hours a week, to get comfortable and commit to switching. It’s a lot easier once you switched, though.

How quick is it to make a derivation?

For most things, a couple of minutes tops. I found it easier to create derivations than creating Debian packages, and I was a Debian Developer for two decades, had a lot more and lot deeper understanding of Debian packaging practices. It’s not trivial, but it’s also not hard. The first derivation is maybe a bit intimidating, but the 10th is just routine.

Regarding make install & co, you can continue doing that. I use project-specific custom flakes and direnv to easily set up a development environment. That makes development very easy. For installing stuff… I’d still recommend derivations. A simple ./configure && make && make install is usually very easy to write a derivation for. And nixpkgs is huge, chances are, someone already wrote one.

How quick is it to install something new and random?

With a bit of self control and liberal use of direnv & flakes, near instant.

How long do you research a new package for?

https://search.nixos.org/packages, you can search for a package, and you can explore its derivation. The same page also provides search for NixOS options, so you can explore available NixOS modules to help you configure a package.

Can you set up dev environments quickly or do you need to write a ton of configs?

Very easy, with a tiny amount of practice. Liberal use of flakes & direnv, and you’re good to go. I can’t comment much on Python, because I don’t do much Python nowadays, but JavaScript, Go, Rust, C, C++ have been very easy to build dev environments for.

What maintenance ouchies do you run into? How long to rectify?

None so far. If it builds, it usually works. I do need to read release notes for packages I upgrades, but that’s also reasonably easy, because I can simply “diff” the package version between my running system, and the configuration I just built: I can see which packages were upgraded, and can look up their release notes if need be. In short, about the same effort as upgrading Debian was (where I also rarely ran into upgrade/maintenance gotchas).

Do I need to finagle on my own to have /boot encrypted?

If you use the NixOS installer, then yeah, you do have to fiddle with that a bit more than one would like. If you install via other means (eg, build your own flake and use something like nixos-anywhere to install it), then it’s pretty easy and well supported and documented.

Feel free to ask further question, I’m happy to elaborate on my experience so far.

a Kendrick fan@lemmy.ml · 11 days ago

With that said, it took me about a month of playing and experimenting with NixOS in a VM casually, a couple of hours a week, to get comfortable and commit to switching. It’s a lot easier once you switched, though.

yeah, OP should probably setup NixOS in a vm first and apply all their configs in there

fool@programming.dev · edit-2 11 days ago

So instead of commenting inside of nix files, you put nix files into .org documents and collate them so you can make your nix files an OS and a website and a zettelkasten-looking set of linked annotated nodes.

That puts a stupid grin on my face (ᐖ )

Dammit I was sure I was just going to stick with Arch until I saw this

Questions:

You have home on tmpfs. Isn’t that volatile? Where do you put your data/pictures/random git projects? Build outputs? How’s your RAM? (Sorry if I’m missing something obv)
What’s your bootup like?
Another commenter mentioned difficulties in setting up specialized tools w/o containerizing, and another mentioned that containers still have issues. Have you run into a sitch where you needed to workaround such a problem? (e.g. something in wine, or something that needs FHS-wrangling)

algernon@lemmy.ml · 10 days ago

So instead of commenting inside of nix files, you put nix files into .org documents and collate them so you can make your nix files an OS and a website and a zettelkasten-looking set of linked annotated nodes.

Yup! And writing it in Org allows me to structure the configuration any way I like. It makes it a whole lot easier to group things that belong together close to each other, and I never have to fight the Nix language to do so. I can also generate easily browsable, rich documentation that explains what’s what and why, which helps me tremendously, because a year after I installed and configured something, I will not remember how and why I did it that way, so my own documentation will help me remember.

Generating code from docs (rather than the other way around) also means that I’m much more likely to document things, because the documentation part is the more important part. It… kinda forces a different mindset on me. And, like I said, this allows me to structure the configuration in a way that makes sense to me, and I am not constrained by the limitations of the Nix language. I can skip a tremendous amount of boilerplate this way, because I don’t need to use NixOS modules, repeating the same wrapping for each and every one of them. Also feels way more natural, to be honest.

You have home on tmpfs. Isn’t that volatile? Where do you put your data/pictures/random git projects? Build outputs? How’s your RAM? (Sorry if I’m missing something obv)

It is volatile, yes, in the sense that if I reboot, it’s lost. I am using Impermanence, for both /home and /. The idea here is that anything worth saving, will be recorded in the configuration, and will be stored on a persistent location, and will get bind mounted or symlinked. So data, pictures, source code, etc, live on an SSD, and they get symlinked into my home. For example, the various XDG userdirs (~/Downloads, etc), I configured them to live under ~/data, and that dir lives on persistent storage and gets symlinked back.

My root and /home are both set to 128Mb, intentionally small, so that if anything starts putting random stuff there, it will run out of space very fast, and start crashing and complaining loudly, and I’ll know that I need to take care of it: either by moving the data to persistent storage, or asking whatever is putting stuff there to stop doing that. My /tmp (where temporary builds end up) is 2Gb, and sometimes I need to remount it at 10gb (hi nerdfonts!), but most of the time, 2g is more than enough.

I have 32Gb RAM, but only ~2.5g is used for tmpfs purposes (2g of it on /tmp itself), and most of the time, the majority of that is unused and as such, available for other things. My wife’s laptop with 16Gb RAM uses a similar setup, with 512mb for /tmp, and that works just as fine.

I do have 64Gb of swap on a dedicated SSD, though, and that helps a lot. I currently have 3GB ram free, and 37G of swap used, but don’t feel any issues with responsiveness. I don’t even know what’s using my swap! Everything feels snappy and responsive enough.

What’s your bootup like?

A few seconds from poweron to logging in. By far the slowest part of it is the computer waiting for me to enter my password.

❯ systemd-analyze
Startup finished in 8.667s (kernel) + 29.308s (userspace) = 37.975s
graphical.target reached after 29.307s in userspace.

Looking at systemd-analyze blame and systemd-analyze critical-path, most of that userspace time is due to waiting for the network to come online (18s), and for docker to start up (7s). Most of that is done parallel, though. Boot to gdm is waaay faster than that.

Another commenter mentioned difficulties in setting up specialized tools w/o containerizing, and another mentioned that containers still have issues. Have you run into a sitch where you needed to workaround such a problem? (e.g. something in wine, or something that needs FHS-wrangling)

I haven’t run into any issues with containers, and I’m using a handful of them. docker, podman, flatpak all work fine out of the box (after setting up permanent storage for their data, so they don’t try to pull 10gb containers into my 128mb root filesystem :D). Wine… I’m using Wine via Lutris to play Diablo IV, and it has worked without issues so far out of the box, I didn’t have to fight to make it work.

I did run into a few problems with some stuff. AppImages for example require running them with appimage-run, but you can easily set up binfmt_misc to automatically do that for you, so you can continue your curl https://example.com/dl/Example.AppImage -o Example.AppImage && chmod +x Example.AppImage && ./Example.AppImage practices after that.

There’s also cases where downloaded binaries don’t work out of the box, because they can’t find the dynamic linker. I… usually don’t download random third party binaries, so I don’t often run into this problem. The one case where I did, is Arduino tooling. I have a handy script in my (arduino-powered) keyboard firmware to patch those with patchelf. But if need be, there’s buildFHSEnv, which allows us to build a derivation that simulates an FHS environment for the software being packaged. So far, I did not need to resort to that. Come to think of it… using buildFHSEnv would likely be simpler for my keyboard firmware than the patching. I might play with that next time I’m touching that repo.

ravhall@discuss.online · 12 days ago

Sounds like you have a lot of time.

SturgiesYrFase@lemmy.ml · 12 days ago

Or had a lot of time, and have streamlined their setup to the point that they don’t spend nearly any time on the fiddly bits, because they now have next to no time.

ravhall@discuss.online · 12 days ago

True. I love to fiddle, but not on my daily driver.

SturgiesYrFase@lemmy.ml · 12 days ago

I also love to fiddle, but the ADHD steers the ship a lot, and so I sometimes end up bricking my install… I’d say it’s a thing I’m working on, but you seem nice…and I’d hate to lie to you.

ravhall@discuss.online · 12 days ago

We are floating in the same boat, my friend. ;)

SturgiesYrFase@lemmy.ml · 11 days ago

✊🤜🤛 the struggle is real fam

fool@programming.dev · 12 days ago

Yep this is my diagnosis. I had a lot of time at the start to config horns and halos and miniguns and waffle toasters onto my craptop but now everything is constrained

o(╥﹏╥)o

SturgiesYrFase@lemmy.ml · 11 days ago

It’s really unfair. The older we get, the faster time seems to pass, and the less we have to spare. If we’re lucky, maybe we can get 15 or 20 years at the end to enjoy our labour…most of us will be too banged up from the grind to enjoy it.

AItoothbrush@lemmy.zip · 11 days ago

Nixos is amazing especially for use cases like yours. Ive been using it for id say 8 months. Never had anything break on me ever that had to do anything with updates. The most you do is edit your config sometimes because they renamed something.

As for dotfiles you can keep em how you did it before, your home directory doesnt have to be immutable.

Nixlang isnt that hard if you dont do anything insane and you can copy most things from other peoples configs. If you have custom executables theres actually a really good way of packaging it for you own setup and you can use them as any other package.

Nix-shell is really good when you need something instantly. It just drops you into a shell with the packages installed that you asked for. I tested out compositors by just using nix-shell on the tty and running them to see how they work.

For packages its basically 0 time. Nixos has an insane number of packages for almost everything and even when its not packaged you can get flakes other people made(bit like aur now that i think about it) and it will build the package for you.

Idk that much about dev envs, for me its just and ubuntu or fedora distrobox because literally everything is made to be compiled on those and its easier than searching for every package you need because of course every distro has completely different names for it. As for setting up your own dev envs i heard its a blessing and really good.

Idk for encryption is just have LUKS, dont know about the technicalities that much.

Something i recommend is not falling down the rabbit hole of making everything immutable. Your dot files can be just the way you already have them. Home manager is cool and all but after moving literally all of my configs to it i realized its just an extra useless layer of abstraction. Just upload you config directory to github and everything will be easy to manage. Also sometimes my system doesnt build because of some conflict in my config files. Kinda stupid to have the most stable packaging system ive ever seen in my life and then fail a build because of your neofetch config or something.

Another amazing thing on nixos is that you can have multiple streams of packagesm. My system is on stable(because its stable lol but still rapid enough for me) but some of my packages are on unstable. Firefox vulnaribility? Just update it to unstable and EVERYRHING WORKS. It NEVER breaks.

Sorry for the novel length comment but in the end if you have the need for a stable unstable system the nixos is perfect. Tbh i wish there was something simpler that did what nixos does. Someone could make something built on nixos that abstracts away the features that 99% of users dont need.

fool@programming.dev · 11 days ago

The “stable unstable” setup is a beautiful concept. Thanks for the dotfiles mention – I keep hearing “you need to rebuild if you edit a dotfile” but I guess that’s a myth encountered by people trying to nix too nixily, falling into said archetypal rabbit hole

Questions:

Does mixing streams “infect” other packages? I remember an old Gentoo thing where ~amd64 unstable packages would want to spread on its own. Since it’s nix I assume that an unstable package will require a bunch of unstables but they’d be installed alongside respective stable versions – i.e. taking up disk space but not “spreading” per se

For packages its basically 0 time.

Is that really true for you? I assume you refer to the length of time it takes to copy paste a flake from online but how reliable is that really? And the other commenters mention that there’s still wrestling to be had for certain tools

AItoothbrush@lemmy.zip · 11 days ago

Mixing release streams dont infect other packages but yes you will have multiples of a lot of dependencies. Thats the one thing nixos eats up pretty well but with modern storage it doesnt really matter. I have a 512gb ssd and only use about 200gb of it with nixos, vms and all my personal data. I havent thought about running out of storage in a lot of time. Tho your own usage may vary, i dont have many heavy packages other than a few design tools.

The zero time really is true, i just search the nix repo, add it to my config and rebuild. 2 mins. The only things ive struggled with are dependencies for building stuff but ive always been someone to struggle with it so i just started compiling in vms and now i just do it with distrobox. It works for me, i didnt even change my workflow from other distros but it may not work for you. I definitely recommend trying nixos out and if you like it you will love it. Just dont go too deep in the rabbit hole, i know people whos home is a temp directory and its rebuilt on every boot and their root is also rebuilt the same way. Dont even ask why or how 💀

algernon@lemmy.ml · 10 days ago

I’m one of those crazy people with / and /home on tmpfs. Setting that up is very easy with Impermanence, but it does require some care and self control. That is precisely the reason I set it up: I have no self control, and need the OS to force my hand. Without impermanence, my root and home fills up with garbage fast. I tend to try and play with a lotof things, and I abandon most of them. With Impermanence, I don’t need to clean up after myself: I delete the git checkout, and all state, cache and whatnit the software littered around my system will be gone on reboot.

In short, Impermanence makes my system have that freshly installed, clean and snappy feeling.

The whole thing sounds scarier and more complicated than it really is.

fool@programming.dev · 11 days ago

Too late, I asked algernon. O.O

but yeah I don’t think I’ll make my OS an absolutely pure mathematical function that I prove the correctness of at every boot _cool _af _tho

I do rely on correct dev envs so I’ll try my hand at nixos-shell -ing. Thanks for the input

ikidd@lemmy.world · 12 days ago

You might want to look at BlendOS. It’s not up to NixOS’s level of complexity, but it gets you atomic rollbacks. It might meet your time constraints better than the learning curve on NixOS.

dadarobot@lemmy.sdf.org · edit-2 12 days ago

I just started using nix recently. I really like the concept, and how simple it is to “temporarily” install an app only needed briefly.

I was trying to install a python program i wrote, and packaged with poetry (on an arch system) to nix. Pip and pipx both threw errors, nothing seemed to work. Advice online seemed like i needed to basically create a nix flake for the app. I still havent gotten it installed because i have no idea what nix flakes are.

Its probably just a learning curve, and not using nix the “nix way” but im incredibly frustrated and it was a massive time sink for me. I figured pipx would basically work like flatpak does and just install the thing in my home, leaving the system immutable or whatever, and staying mostly in the spirit of nix.

So i’d say its weird enough of a distro to waste your time sometimes.

That said, it seems to have the cleanest updates ive ever seen on linux. So much so i could probably just run them via cron, and never think about it again.

So win some lose some…

moonpiedumplings@programming.dev · edit-2 10 hours ago

Advice online seemed like i needed to basically create a nix flake for the app. I still havent gotten it installed because i have no idea what nix flakes are.

So, the problem is that flakes are technically an “experimental” feature, and thus are not allowed to be included as a primary solution in the official documentation. But, basically everybody uses flakes, so it leads to this crazy documentation split, and is a big part of why documentation on Nix is so bad.

Some stuff can only be done with flakes, some stuff only with non-flakes and you have to figure out which is which on your own, while also dealing with the poor documentation for either.

The advice you received was wrong. You could also use a combination of a default.nix file and a shell.nix file to create a package and development environment for your app. But, the documentation is so poor that it’s unlikely you will learn this, and figuring out how to do this on your own, is again, a massive time sink.

blackbrook@mander.xyz · 12 days ago

You might also consider openSUSE for btrfs snapshot rollbacks in case something breaks (though tumbleweed is quite stable anyway). They also have community packages.

apt_install_coffee@lemmy.ml · edit-2 11 days ago

Nixpkgs has more and newer packages than the aur.

The initial time to get shit done is longer; you can’t simply make install, but honestly you shouldn’t have been doing so on arch anyway.

Making your own derivation is much easier than making your own PKGBUILD and should be considered in those terms because you’re not just shoving some binary into /usr/bin for it to explode later when glibc updates.

When things fuck up, reverting to your previous config is at worst a reboot away.

I have much less time than I used to, so moving from arch to Nixos has prevented the time otherwise wasted in an arch-chroot trying to fix issues like the kernel upgrading past what the zfs-dkms supports.

If you’re using specialised proprietary tools, working them in with Nix can be an absolute nightmare, but I use a debian container for them.

dosse91@lemmy.trippy.pizza · edit-2 12 days ago

I’d say I’m a “time-strapped” user since I have a full time job and I’d rather spend my free time gaming rather than fixing a broken OS, nevertheless… I have 2 PCs with Arch Linux (one for personal stuff and one for work) and a server with NixOS.

When things break on Arch (which is rare these days but it can happen, especially if you play around with things from the AUR), I just rollback with timeshift (it takes just a few seconds with btrfs) and try that update again in a few days. Minor issues I can just ignore or work around them and take care of them when I feel like it, but they usually get fixed with updates within a few days. The only time I felt that it was actively wasting my time was when Plasma 6 came out a few months ago and a lot of little things broke, especially on wayland, but they were fixed rather quickly with 6.1 so I can’t complain too much.

NixOS on the other end has been nothing but trouble and a waste of time ever since I installed it. It took me a week to configure it, some packages are kinda old, most have incomplete declarative config, I had to manually write some units myself, and when things break it drives me crazy because even basic troubleshooting of services can be a pain in the ass because I have to find out where stuff is, know which config files are going to be overwritten, launch the correct nix-shell, … it’s all so tiresome… so I just revert to an older config and hope for the best. To make things worse, major updates often require manual changes to the config or even to application files themselves (looking at you, nextcloud) and you will excuse me if I can’t be bothered to do that on a DECLARATIVE DISTRO. Even debian doesn’t need that, come on! I don’t care what people say on NixOS, this OS is not ready yet, I don’t have time for this shit when I’m working and that server will be going back to debian next summer.

Laser@feddit.org · 11 days ago

NixOS […] some packages are kinda old

Fair

that server will be going back to debian next summer.

I don’t think that will solve the “some packages are kinda old” issue.

Telorand@reddthat.com · 12 days ago

I don’t care what people say on NixOS, this OS is not ready yet, I don’t have time for this shit when I’m working and that server will be going back to debian next summer.

I like the idea behind it, but I’m with you. I’ve tried to learn it and given up several times. There’s just not enough tutorial info, yet, to get people up to speed, and making changes seems to be a bigger deal than pretty much every other distro out there.

Its current state feels like Arch for people who think Arch is too easy.

moonpiedumplings@programming.dev · edit-2 6 days ago

So, I use Arch, but I don’t use the AUR at all. Instead, I use nixpkgs to get stuff (admittedly only like 3 packages) not in the Arch repos.

The main reason for this is the quality of AUR packages. Although I don’t really fear a malicious package, I do remember hearing about a package that moved a users /bin to /opt during the install phase.

Something like that is literally impossible with Nix, due to the way that applications aren’t really installed to the system. But, nixpkgs also requires some level of vetting the package quality, which is also nice.

I also use nix for managing all my development environments. For example, my blog github repo, has a few nix files at it’s root, and you should just be able to type nix-shell in folder, and then you will get an identical environment to me.

declarative rollbackable immutability sounds really freakin’ AWESOME

I have BTRFS snapshots set up, and with grub-btrfs, I can even boot from them and revert to an older kernel (my /boot is stored on BTRFS).

However, I have given up on NixOS, for many reasons. The documentation is very poor, and it’s more complexity than it’s worth, to make my whole OS reproducible, rather than just my development environments. In addition to that, their are also issues with running certain apps that expect to see a normal FIlesystem Hierarchy, which nix does not provide. Although you can work around this with stuff like steam-run or creating a fake FHS using nix, I would rather not play that game.

But, considering I installed some stuff in an Ubuntu 22 distrobox recently, because that was what VScode and Unity official provide repos for, maybe this doesn’t really matter. You can probably use distrobox on Nixos, but I’ve seen issues about GPU acceleration with distrobox (and other non-nix apps) as well.

EDIT: I lied, I use the chaotic aur for some things.

fool@programming.dev · 11 days ago

Thanks for the input!

I’m nervous about faking FHS as well, especially for specialized stuff. I don’t know much about steam-run or its caveats – so I can’t debug it (Maybe it turns out to be really simple and solid? Who knows…)

Thanks for mentioning the gpu accel issues in distrobox – I was considering using containerization to fight off any FHS issues but it seems I can’t jump the gun. I’ll probably just tighten dev envs by trickling in nix-shell usage; multiple versions of a package at once is an issue I’d def love to solve (in a way that’s more than just dockerfile)

Interesting that this is the third comment suggesting just using btrfs snapshots to resist Arch update experiences. I have root and home on two flat btrfs subvols so it shouldn’t be that hard to implement. (yeah yeah “What backup?” is bad)

Seems like the simplest way out is those two smallish changes. Wish I could transcend into declarativity but the thread’s nix survivor ratio is grim

moonpiedumplings@programming.dev · 11 days ago

Wish I could transcend into declarativity but the thread’s nix survivor ratio is grim

Yeah lol.

I will say, that for my server, I decided to use kubernetes + fluxcd for declaratively. My entire kubernetes “state” is declared in a git repo, and this is the popular, industry standard for things like this, called GitOps. It makes it very easy to add an app, since it’s just adding a folder + some new config files. And unlike Nix, Kubernetes and Flux are very well documented with much tooling as well. Nix doesn’t really have a working LSP or good code autocomplete, but with kubernetes, I can just start typing in a yaml file and then hit tab and it spits out the template for me. Code autocompletion with kubernetes feels much more similar to the tooling of other, more mature tooling

It’s not as declarative as nix though. There are things missing, like OCI containers could theoretically shift if you don’t rely on hashes and some other nitpicks. But declarativity is a spectrum, and I feel like, outside of scientific scenarios (think simulations where versioning, hardware, runtime etc being the same is very important), I think many non-nixos solutions are declarative enough.