171–180 of 336 posts
The multitude of ways things can be configured spooked me a bit for desktop use though.
So a server that's dedicated to well-supported(by nixos) services running NixOS is awesome. it's easy to upgrade every 6 months and generally very painless. Everything else is a PITA though. Of course if you use an LTS like Debian Stable or Ubuntu, you only have to upgrade every 5-ish years, so unless you always need the latest and greatest release of something, it maybe isn't worth the hassle. Trying to hack on othe…
I've been on the fence about Nix. I've wanted to love it (and do love the concept), but between the Waiting-for-Godot situation for flakes, the weird language, and the occasional political infighting I've seen pop up about the community, I still haven't switched. I'm no language expert, but I genuinely don't understand why it wouldn't have been better to build some equivalent DSL in Haskell to do this given the simil…
My impression is that you can't really build nix as a DSL in haskell, because the core insight of nix is to introduce the "derivation" function into a pure programming language, whose behaviour is pure (the output is determined by only the inputs), but whose implementation is very much not (it builds packages from a specification).
There may well be a work-around for that (it's been a while since i haskelled), but it's likely to end up with a result that's less clean than it would ideally be.
Personally I find the nix language to be a pretty good match for the tasks it is used for (though some basic static typing would be nice).
From the outside, i can see why it looks odd, but from the inside, there's not much of a desire to switch to something better, because the language isn't the thing that gives people trouble after the initial learning period (which would exist with any host language).
So a server that's dedicated to well-supported(by nixos) services running NixOS is awesome. it's easy to upgrade every 6 months and generally very painless. Everything else is a PITA though. Of course if you use an LTS like Debian Stable or Ubuntu, you only have to upgrade every 5-ish years, so unless you always need the latest and greatest release of something, it maybe isn't worth the hassle. Trying to hack on othe…
LTS is harming the industry and holding everything back! IMO it is the wrong direction.
Stability is a great thing for busy professionals that want stuff to just work.
How many apps have you upgraded that have crashed and burned from the update? Me, a lot. both commercial and OSS. With OSS at least you get all the pieces so you can figure out how to put it back together again. With Commercial, you rollback, file a bug report and hope someone somewhere in the company will be incentivized enough to fix it for you.
Earlier quoted context omitted.
My experience has been in complete agreement with yours: I love the theory, but the practice is so, so painful. And yes, I also had to settle for your NVIDIA fix. I suspect I would have had a marginally better time on Arch as there are more people beating their heads against it and documenting how they made it work. NixOS documentation is piss-poor in comparison.
Most people don't realize that you can read the arch wiki and put the same settings into the nixos options. Where is the point in replicating that all again?
While it is technically possible to adapt the information in the Arch wiki to NixOS, you need a strong understanding of the software, how it was packaged for NixOS, and NixOS itself to do it effectively. Once you do figure it out, it's pretty straightforward, but that can be hours as opposed to minutes with Arch.
Earlier quoted context omitted.
The reason I keep it around on my laptop is mostly because of the snapshotting. I generally do know my way around Linux command line nowadays, but with Ubuntu and Arch (especially early in my career when I didn't know what I was doing), I would get into states that break the video driver, or break GRUB, or make the machine unstable, and the only thing I could do was reinstall the whole OS. With NixOS, since it's all…
Just a side note for those who aren't on NixOS, but who would like 90% of snapshotting: use timeshift. Especially if your file system is BTRFS. It'll do daily snapshots of all your system files, going back 5 days by default. I've only had to use it once, but it was invaluable. Another nice thing is it's very much a set-and-forget program.
I courted making the switch to NixOS a couple times, but I just don't really see the value add to me right now. Yes, if you have a lot of machines then it maybe make sense. At this point I just use Nix home manager for my dotfiles/userspace programs on a normal distro and I feel like I get 90% of the benefit without any of the headaches.
I delete your entire system file system right now. How fucked are you? With NixOS: I don't care. You can recover from a half deleted root file system.
To quote a friend: "A new car smell on every reboot."
Earlier quoted context omitted.
As I said, a small shell script I wrote. The only things it needs to do are sync files according to the `filelist` files and sync packages according to the `packages` files, so I don't need the full verbose DSL of Ansible etc. Also it means it has no dependencies on the target machine. You might say Ansible doesn't need anything on the target machine except ssh, but it does require the target machine to be reachable…
How do you deal with removing a package? For examplet the case where you have htop in your config, but no longer want it on your system or in your configs.
(*): This depends on the package manager:
- For Alpine / postmarketOS it's just the content of `/etc/apk/world`.
- For Debian / Ubuntu it's `apt-mark showmanual`.
- For OpenSUSE it's `zypper search --installed-only` (which includes both intentionally and automatically installed packages) and then subtracting the contents of `/var/lib/zypp/AutoInstalled`.
Earlier quoted context omitted.
You can just store the actual container though. Which will reproduce the environment exactly, it's just not a guidebook on how it was built. The value of most reproducibility at the Dockerfile is that we're actually agnostic to getting a byte-exact reproduction: what we want is the ability to record what was important and effect upgrades.
> Which will reproduce the environment exactly, it's just not a guidebook on how it was built. By that logic every binary artifact is a "reproducible build". The point of reproducibility isn't just to be able to reproduce the exact same artifact, it's to be able to make changes that have predictable effects. > The value of most reproducibility at the Dockerfile is that we're actually agnostic to getting a byte-exact…
So in practice.. if the build described in the dockerfile breaks, you notice when you’re changing / extending the dockerfile.. which is the time and place where you’d expect to need to know. My guess is that most people complaining about deterministic builds for containers are not using registries for storing images, and are not deploying to platforms like k8s. If your process is, say, shipping dockerfiles to EC2 and building them in situ with “compose up” or something, then of course it won’t be very deterministic and you’re at the mercy of many more network failures, etc