[HN Gopher] Nix - Death by a Thousand Cuts
___________________________________________________________________
Nix - Death by a Thousand Cuts
Author : jonotime
Score : 178 points
Date : 2025-01-11 16:19 UTC (3 days ago)
(HTM) web link (www.dgt.is)
(TXT) w3m dump (www.dgt.is)
| jonotime wrote:
| Thoughts on a love/hate relationship with Nix on the desktop.
| unstruktured wrote:
| I don't think he touched on whether server side is a more valid
| use case, but was nice to read someone elses take on using it for
| a desktop. Thanks for the contribution.
|
| He did find functional programming to be sort of mystic so I
| don't know if I trust his take on assesing the nix language
| itself.
|
| TLDR; just stick with ubuntu or arch unless you feel like
| experimenting
| jonotime wrote:
| Author here. Your TLDR is spot on. Yes, my intent was to be on
| desktop use since most things I read dont consider that
| specifically. I did talk about how I would keep this running on
| some simple home servers since I think that's where Nix shines.
| But some of my servers are raspberry pis, which I mentioned I
| am worried to run Nix on due to resource limitations. I should
| probably just try it.
| dhon_ wrote:
| I wish remote build/deploy for Raspberry Pi was in a better
| state - it seems like a perfect fit for NixOS.
|
| I've got x86 servers running NixOS that are deployed using
| Colmena, but it seems to fall apart when I add cross
| compilation into the mix.
| aidenn0 wrote:
| cross compilation is hit-or-miss, but using qemu/binfmt
| works just fine, if a bit slow.
| lilyball wrote:
| I'm running NixOS on a raspberry pi and I deploy to it with
| deploy-rs1. This works pretty well for me. My dev machine
| is an Apple Silicon laptop with nix-darwin installed and I
| use its nix.linux-builder module to run an aarch64-linux VM
| as a remote builder to build the rpi's system. All this
| means the rpi never has to do any building itself, and
| doesn't even need the nixpkgs source installed either.
|
| If you want to do this yourself, I recommend using
| https://github.com/nix-community/raspberry-pi-nix so the
| system is configured much more closely to how the stock
| raspberry pi image works. The benefit of this is better
| reliability of stuff like bluetooth.
|
| 1https://github.com/serokell/deploy-rs
| Arnavion wrote:
| I dabbled with NixOS many years ago for a much shorter time than
| the author has spent on it, so I have much less experience with
| it. My main problem with it was that the problem of declarative
| config is basically solved at the software-level already.
|
| System services have always been able to be configured by
| dropping files in /etc. Lots of software also specifically
| supports config dropins, so that merging configs from multiple
| sources is even easier. Even stuff like creating users and groups
| can be done on systemd distros by dropping in config files.
| Similarly configuring user software is mostly about dropping
| files in ~/.config etc.
|
| Package managers vary. Alpine's apk is the best in that
| `/etc/apk/world` is the list of packages you want, and every run
| of `apk upgrade` will install and uninstall packages accordingly
| to match that list, but it doesn't have dropins. apt and zypper
| don't even have a config file, only an opaque database that you
| can only interact with using the commands. But you can maintain
| your own packages list and then script apt/zypper to diff against
| that list and install/uninstall accordingly. (zypper in
| particular does maintain a list of packages, except it's a list
| of packages that you *don't* install explicitly but are just
| auto-installed as dependencies of the ones that you did, which is
| funny to me.)
|
| I get declarative config on all my devices (a mix of OpenSUSE,
| Debian, Ubuntu and postmarketOS, across servers, desktops,
| laptop, phone) with just an Ansible-like setup. For each device I
| have a `$hostname.roles` file that contains one role per line.
| Each role corresponds to a `role.$role` directory that contains
| any files that should be deployed as part of that role (both
| under homedir as well as at the system level) as well as a
| `packages` file that lists any packages that should be installed
| for that role. Then there's a small shell script that matches the
| hostname of the machine against this directory and ensures that
| all files exist, and that all the required packages are installed
| and no extras are installed. Also the entire directory is in
| version control so I have a log and reasoning recorded for every
| change.
|
| The author mentions rebuilding a laptop to do another laptop's
| job by applying the other's Nix config. I have also used my
| script to rebuild a few devices after their disks died and I had
| to reinstall the OS from scratch, so it ticks that checkbox too.
| And of course I've added and removed roles occasionally to
| add/remove features from individual devices.
|
| NixOS would give me a way to rollback the entire config, but I
| can also do that with this. In case I need to rollback to
| packages that no longer exist in the distro repository, I have
| btrfs snapshots to roll back to.
|
| NixOS would give me a way to install multiple versions of
| packages, but this is something I've never needed. I primarily
| stick with distro software so it is always consistent, and if two
| distro softwares require different versions of the same
| dependency, distros already know how to solve that (make two
| coinstallable packages).
|
| The one time I tried to build someone else's Nix project (and
| they even had a Dockerfile with nix in it to do the build so it
| would be completely independent of the host), it didn't build for
| me, so I'm not sure how reproducible it really is. But that
| might've just been a problem for that one project.
|
| I'm sure Nix(OS) has benefits for other people, but for me the
| benefits that I would care about are handled entirely by dropping
| files in the right places, and I don't have to use a different OS
| or package manager or bespoke programming language to do that.
| yjftsjthsd-h wrote:
| > an Ansible-like setup
|
| Using another common tool (salt/chef/puppet/...) or something
| home-rolled? (Just asking because I'm interested in new options
| in this space)
| Arnavion wrote:
| 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 over ssh, which is not necessarily the case if
| I'm rebuilding a machine such that its network is not already
| configured. So in that case all I need to do is sneakernet my
| git repository over and then execute a shell script.
| RestartKernel wrote:
| Trying to get Eduroam working soured me on NixOS as a
| desktop/laptop OS. If conventional methods fail, you're left with
| a completely non-standard OS designed to prevent quick hacks.
|
| But NixOS spoiled my entire mindset around Linux. Going back to
| anything else feels like a massive downgrade. We would be better
| off today if declarative operating systems became the standard
| back when they could.
| soraminazuki wrote:
| Wi-Fi should just work like any other Linux distro, assuming
| you have a desktop environment like GNOME or Plasma installed.
| IshKebab wrote:
| Probably not very helpful telling him that it _should_ work!
| pzmarzly wrote:
| eduroam is not your everyday WPA{2,3}-PSK, it's WPA2-EAP.
| There are official shell scripts to provision certificates,
| but they only seem to work on major distros, and for some
| reason the eduroam website made different scripts for every
| university. Also, for most people this is their first (and
| last) experience with 802.1X, especially setting it up
| themselves.
|
| In my experience few years ago, it was a pain to set it up on
| everything except macOS and iOS (which come with eduroam
| certificates preinstalled in their trust stores).
| pxc wrote:
| I ran NixOS while I attended university and don't remember any
| problems with this. Is it a NetworkManager issue?
| rowanG077 wrote:
| Nix for me has been a great source of stability. I used to run
| ubuntu and was never happy. Packages randomly broke, the UI
| lagged a lot, I always had to dig to get things working. One day
| when I head a uni deadline an automated updated destroyed my wifi
| funcionality. I had some experience with nix from work so in
| anger I installed NixOS. Wifi worked and I finished my uni
| assignment. Haven't installed anything else on my computers
| since, and that was 6 years ago. Sure things can be a pain. But
| NixOS has never broken in unexpected ways. I know if I update
| things may go wrong. But I can always go back and try again a
| newer version a few weeks later.
|
| The biggest drawback is really that "random executable from the
| internet" does not work out of the box. And sometimes you have to
| spend a lot of time to package something yourself. But all in all
| It has saved me time and a lot of pain. I dare even say I no
| longer have a toxic relationship with my OS.
| VTimofeenko wrote:
| For those pesky random executables there's a couple of escape
| hatches -- buildFHSenv and nix-ld. This is also predicated on
| good provenance of the executables in question. One should
| probably not even ldd sketchy binaries:
|
| https://jmmv.dev/2023/07/ldd-untrusted-binaries.html
| micahcc wrote:
| steam-run seems to be able to run everything. It uses bubble
| wrap to keep the OS isolated and add /usr/bin stuff most exes
| want.
| soraminazuki wrote:
| Even proper packaging is far easier compared to other package
| managers. Typical distros push users away from packaging
| their own software, so users end up relying on ad-hoc
| solutions instead. Nix instead makes packaging easier by
| having proper tools to abstract away the nitty gritty
| details.
|
| For random binaries, autoPatchelfHook works miracles.
| 0x457 wrote:
| Every time I see a linux installation with a mess in /opt
| because it's faster than making a package, I get annoyed.
| aszen wrote:
| I now use distrobox to run random binaries in a container. It's
| faster and convenient
| otabdeveloper4 wrote:
| > just run random binaries from the internet like it's 1998,
| bro
|
| That world was fun but I don't want to go back to that place.
| Havoc wrote:
| I found getting started quite easy.
|
| But then you discover there are like 4-5 different ways to manage
| packages and not much consensus in the community on what the
| correct way is. That was kinda discouraging
| aidenn0 wrote:
| I think there probably actually isn't one "correct" way.
|
| Anything that is best configured with a nixos module should
| probably be in your system configuration, but beyond that there
| are probably a lot more than 5 different ways and they have
| their advantages and disadvantages.
|
| What I settled on was a per-user declarative setup (first with
| "nix-env -r", now with "nix profile"). Then I use nix shells to
| run software for one-offs. If I find I am running the same
| software from a nix shell a lot, I toss it in my declarative
| file.
|
| Plenty of people hate this setup, and do something completely
| different (e.g. imperative managing of profiles, or using home-
| manager, or a dozen direnv setups). I don't necessarily think
| any of them are wrong, but they are not for me for various
| reasons.
| pxc wrote:
| A fairly clear hierarchy emerges with enough experience, I
| think, but I don't know if there's explicit consensus about it
| of the kind that could make its way into documentation. Here
| are the rules of thumb, though (in a kind of priority order):
|
| 0. If you're new and on the fence about using flakes, go ahead.
| (If you know you don't want them, fine.)
|
| 1. Prefer declarative installation to imperative installation.
|
| 2. If a module exists, prefer using it to configure a package
| to just adding that package to a list of installed packages.
|
| 3. 'Native' packages are better than 'alien' packages.
|
| 3a. Packaged for Nix is better than managed externally. (I.e.,
| prefer that programs live in the Nix store rather than Flatpak
| or Homebrew.)
|
| 3b. Prefer packages built from source to packages carved out of
| foreign binaries.
|
| 4. Prefer to just rely on Nixpkgs for things that are already
| in Nixpkgs; only bother with other sources of Nix code (likely
| distributed as 'flakes') if you know you need them.
|
| 5. Prefer smaller installation scopes to larger installation
| scopes-- when installing a package, go with the first of these
| that will work: per-session (i.e., ephemeral dev env) -> per-
| user -> system-wide).
|
| 6. Prefer Nixlang to not-Nixlang (YAML, JSON, TOML, whatever).
|
| 7. If you're not sure, go for it.
|
| If you follow these guidelines you'll make reasonable choices
| and likely have a decent time. The most important rule is #1,
| so once you know your OS, your task is to make sure you have at
| least one module system available to you. (On NixOS, that's
| NixOS and optionally Home Manager. On other Linux, that's Home
| Manager. On macOS, that's Home Manager and/or Nix-Darwin.)
|
| After that, everything can find its natural place according to
| the constraints above. If you need to break or relax a rule,
| it'll be obvious.
|
| Inevitably you'll end up with things installed in a handful of
| ways and places, but you'll know why each thing belongs where
| it is, and you can leave yourself a note with a '#' character
| anywhere that you think a reminder might be useful. :)
| craftkiller wrote:
| > ZFS on Linux [...] The recommended way to do this is to use
| LUKS, not native ZFS encryption.
|
| FWIW I've been using native zfs encryption on nixos and it works
| great. It lacks neat features like being TPM-backed or having
| multiple keys, but if all you need is password-based encryption
| then I think native ZFS encryption is better since you'll be able
| to do encrypted zfs send/recv, you'll have granular control over
| which datasets are encrypted (or encrypted with different
| passwords), you'd get cross-platform support for the encryption
| (for example, my FreeBSD home server can receive and decrypt my
| laptop backups), and you aren't adding another layer of
| complexity.
| rcxdude wrote:
| I think the main reason ZFS's native encryption isn't
| recommended is that there's known bugs in its implementation,
| especially around key rotation and send/recv.
| aidenn0 wrote:
| > I think the main reason ZFS's native encryption isn't
| recommended is that there's known bugs in its implementation,
| especially around key rotation and send/recv.
|
| Is that still the case? I thought the send/recv bugs at least
| were squashed a couple years ago?
| ris wrote:
| I think this is quite a fair commentry (although I quite like the
| Nix language personally) - as a nixpkgs developer even I don't
| use NixOS on the desktop. For me it shines on servers and
| development environments.
| tuananh wrote:
| > as a nixpkgs developer even I don't use NixOS on the desktop
|
| that's not every encouraging :)
| ris wrote:
| Why? It just isn't what draws me to Nix.
|
| I've never even really tried NixOS on the desktop TBH.
| tuananh wrote:
| nothing. it's just from someone with no experience with nix
| like me, it feel weird that someone is already deep into
| Nix but isn't tempted to use it daily.
| cbrozefsky wrote:
| You can use it daily, intimately, without using nixos.
| Using it for dev environments on macos for example, and
| servers. Did that for years before I installed nixos on
| my desktop.
| woile wrote:
| I've been using nix in a Mac for a year now. Recently I
| got a new Lenovo machine and first thing I did was
| install nixos, it's actually much better than I was
| expecting. You do notice that nix is designed around
| nixos
| wpm wrote:
| Maybe it's everyone else using it on their daily driver
| that got it wrong?
|
| It's like doubting Kubernetes because one of the
| maintainers doesn't run their desktop in KubeVirt.
| yjftsjthsd-h wrote:
| I think it's more like Microsoft folks running macs;
| technically valid, but odd optics. Besides, why would you
| use KubeVirt to run your desktop? Just run it in
| containers directly.
| jmartens wrote:
| What is so interesting about Nix is that it's not one
| thing. Its not (just) a distro. Its not (just) a package
| manager. Its not (just) a system manager. Its not (just)
| a language. Its not (just) a build tool.
|
| It is all those things, but specifically, what you want
| it to be. Yes, that makes it super confusing, but also
| powerful.
| autra wrote:
| To counterpoint this, I'm an happy nixos desktop user. It's
| not perfect, but still vastly better than a non declarative
| distro for my taste.
| lolinder wrote:
| Seconded. I switched to NixOS a year ago after an apt
| install broke my system one too many times, and so far I've
| been very very happy with it. I've broken things, but being
| able to roll back to an exact duplicate of the previous
| state has been a lifesaver. I can't imagine wanting to go
| back to repairing broken apt installs.
| sshine wrote:
| Wholeheartedly agree.
|
| NixOS gave me back my desire to customise my Linux again.
| I've run Linux since 1997; I've run a lot of distros.
|
| Having to reconfigure my Linux on every hardware reset (1-2
| years apart) just exhausted me to a point where I ran GNOME
| on Ubuntu so I wouldn't waste time on one-off stuff.
|
| My .emacs and .vimrc shrunk to 10% so I could reproduce
| them from memory if I had to.
|
| With NixOS, installing a new machine and having it work
| exactly like all my machines is minutes of work.
|
| I'll never lose my hyper-customised setup again.
|
| Running something like Arch or Artix again feels very much
| like losing my "save" button.
| pxc wrote:
| It mostly goes the other way, I think. The community surveys
| haven't asked about NixOS desktop usage in particular. Still,
| I'm certain that a large majority of contributors are running
| NixOS on their desktops/laptops/workstations.
|
| That said there are prolific and longstanding contributors
| who focus on non-NixOS and even non-Linux platforms, and
| corporate users are likely to be running Nix on macOS or
| Ubuntu (under WSL). It's not surprising that some users who
| don't use NixOS on laptops or desktops have still become
| Nixpkgs contributors or maintainers, imo.
| aidenn0 wrote:
| As a counterpoint, I'm rather the opposite of you:
|
| 1. I use Nix primarily on the desktop (2 laptops, 2
| workstations), though I also use it on one server. I don't
| think I could ever go back to any other Linux distro for my
| daily-driver. Things "just work" to a degree that they never
| have for me on e.g. Ubuntu.
|
| 2. I quite despise the Nix language; this is not to say that I
| think it's particularly bad (or good) as a language, just that
| nearly every single degree-of-freedom in language design that
| is largely about personal taste takes the opposite choice to
| what I would prefer
|
| 3. I find setting up development environments with it to be
| very hit-or-miss, to the point where I have in some cases
| fallen back on what I would do without nix, and used nix-ld to
| fill in the gaps.
| nunez wrote:
| I'd like more clarity on this:
|
| > The advantage over docker here is that (when using Flakes) Nix
| builds are completely reproducible. Docker containers may be
| isolated, but surprisingly they are not deterministic out of the
| box. With some work you can make docker deterministic, but thats
| what you need, its much easier to use Nix.
|
| as the whole purpose of the Dockerfile is to create a
| reproducible environment.
| theossuary wrote:
| I guess you could consider a docker image a "reproducible
| environment," but it's certainly not a reproducible build;
| running docker build twice on the same directory isn't
| guaranteed to give you the same image. You could put in the
| work to make it a reproducible build, but it doesn't do
| anything to help you achieve that. Nix defaults to reproducible
| builds, and requires flags for "impure" non-reproducible
| builds. It does this by requiring all dependencies be managed
| by nix, and all sources be copied into the nix store.
| JamesSwift wrote:
| Its reproducible at a superficial level. Tags are mutable, so
| someone can push a different "3.1" between build 1 and 2, which
| results in a different build. You can also be fuzzy with tags,
| so if you say "from nginx:3" as your base (or nginx:latest)
| then build 1 and 2 can change because of a new tagged build
| upstream.
|
| Then theres the million app-level changes that can creep in, eg
| copying local source is non-deterministic, apt-update, git
| clone, etc. Nix requires you to be fully explicit about the
| hash of the content you expect in each of those cases and so if
| you build it twice it is actually the same build.
| jonotime wrote:
| Author here.
|
| The idea with nix flakes is it has a lock file which should
| guarantee the same build. This is like package-lock.json or
| pdm.lock which contains dependency checksums for every package.
|
| Docker works more like your standard package manager. If you
| ask for mysql 5, today you may get mysql 5.1, but next week you
| may get mysql 5.2. So it does not come with a guarantee.
| aidenn0 wrote:
| Do any of your Dockerfiles make e.g. apt calls? If so, then
| they will get a different version of software installed when
| built on different days, because that will depend on the state
| of the package servers.
|
| A more trivial example of non-deterministic would be that you
| can write a Dockerfile that uses curl to fetch data from
| random.org; the functions nix provides for fetching from URLs
| require you to specify the sha-sum of the data you fetch.
|
| Nix flakes make it hard for you to inject anything into your
| dependencies that hasn't been hashed to confirm its identity.
| It in many cases still isn't 100% deterministic (consider e.g.
| a multithreaded build system where orderings can influence the
| output), but it's a big improvement.
| soraminazuki wrote:
| Docker images are just as reproducible as binary blobs, which
| is essentially what they are.
| antonvs wrote:
| Binary blobs can be easily reproducible, depending on how
| they're built. By comparison, the "easily" part doesn't apply
| to any non-trivial Docker image.
|
| The issue is that you have to lock down all your
| dependencies, including local data, repos, and registries.
| Most people, and even most companies, don't have the
| resources to achieve that, so they simply don't do it.
|
| Further, Docker doesn't provide any significant mechanisms to
| help ensure reproducibility in the face of these issues, so
| you can't say that Docker _supports_ reproducibility.
| edude03 wrote:
| Containers are only reproducible at run time not at build time.
| Once you build a container and pull it down by its sha256,
| you'll get the same environment each time. However if your
| Dockerfile does any IO (curl, apt get, pip install etc) you're
| quite likely to get different images on different machines.
| thln666 wrote:
| The whole purpose of the Dockerfile is not to create a
| reproducible environment. The purpose of a Dockerfile is to run
| a bunch of commands inside of a container and save the output.
| Those commands may or may not produce the same output every
| time they're run.
|
| For example, if you have a debian base container that you run
| `apt install nginx` in, what version you actually get depends
| on a lot of different things including what the current version
| of nginx is inside of the remote repositories you're installing
| from _when the docker build command is executed_, not when the
| Dockerfile is written.
|
| So, if you do "docker build ." today, and then the same thing 6
| months from now, you will probably not get the same thing.
| Thus, Dockerfiles are not reproducible without a lot of extra
| work.
|
| Nix flakes are not like that - they tag _exact_ versions of
| every input in the flake.lock, so a build 6 months from now
| will give you the _exact same system_ as you have today, given
| the same input. This is the same as like an npm lock file or a
| fully-specified python requirements.txt (where you have each
| package with an ==<version>).
|
| So, you definitely can make Dockerfiles reproducible, but
| again, the Dockerfile itself is not made to do that.
|
| Hope that helps your understanding here!
| nunez wrote:
| My setup is a smorgasbord of dotfiles and symlinks. It's been
| built up over 13 years, so it's very well seasoned and has served
| me well, but I've long been meaning to move to Nix to make my
| setup cleaner. The bad in this article isn't that bad, so now I'm
| amped even more to do this!
| anirrudh wrote:
| I've been daily driving nixOS on my desktop, and manage my work
| and personal macOS machines with flakes. I love this ecosystem,
| and have even managed to make folks at work use nix devShells --
| frankly, the learning curve is pretty steep; the payoff is that
| I've learned so much. I've been very happy with it -- I run a
| windows VM with libvirt/KVM/QEMU when I want to game, and use the
| same to run "local" LLMs. While docker is a great technology, I
| actually prefer using nixOS containers (which are, under the
| hood, systemd-nspawn containers).
|
| When I worked on my startup briefly, I built nixOS images with
| everything needed for raspberry pis; all I needed to do was use
| dd to burn the image to an SD Card.
|
| For me, nix is a wonderful and perfect solution for building
| stable software.
| ChocolateGod wrote:
| I use NixOS, one of the annoying things to me is the
| documentation and error reports.
|
| I swapped my installation to a Flake managed install a few months
| ago, and parts of my Nix files that were perfectly fine before
| started throwing out errors (specifically HomeManager), which no
| amount of Googling the error message that gone thrown got me any
| closer to a solution.
|
| I looked at documentation recently to try and enable PGO/LTO and
| Zen 3 optimizations (don't mind compiling everything) and I think
| I saw at least 10 ways and none worked (gcc errors, etc).
| lolinder wrote:
| This is why I haven't switched my NixOS to flakes yet. The
| community discussions always act as though flakes should be the
| default that everyone should use now, but I figure that the
| developers know what they're doing and haven't made them the
| blessed path yet for a reason. So far so good--my system is far
| more stable than it was under Debian and I've yet to run into
| anything that didn't have an easy answer.
|
| I have a suspicion that because the Nix community is
| disproportionately likely to contain early adopters, the
| general mood in the forums is less risk-averse than I am with
| my primary stacks.
| sshine wrote:
| > _I figure that the developers know what they 're doing and
| haven't made them the blessed path yet for a reason._
|
| My take is: flakes don't align with centralised nixpkgs and
| ultimately don't solve any problems that can't be solved
| without flakes.
|
| They're just an interface for a decentralised module system.
| You can use them, they're feature-complete, and they don't
| align with nixpkgs: it doesn't make sense for individual
| packages to have their own flakes, nixpkgs can already be
| loaded as a flake.
|
| FlakeHub tries to popularise flakes, but I don't know if
| there is a flake discovery problem to solve.
|
| Ekala Project is designing a poly-repo alternative to nixpkgs
| (ekapkgs) and they don't embrace flakes.
|
| So... Flakes have reached full maturity: a decentralised
| package format that has stalled its adoption status within
| the main Nix toolchain.
| 0x457 wrote:
| > My take is: flakes don't align with centralised nixpkgs
| and ultimately don't solve any problems that can't be
| solved without flakes.
|
| I've turned to flakes to specifically solve some problems,
| and flaked solved them. To this day, flakes are still the
| only way to solve them.
|
| Flakes aren't default due to political reasons.
| nixosbestos wrote:
| Yeah, I am flabbergasted that anyone can claim flakes
| don't solve problems. And yet, every _SINGLE WEEK_ some
| newcomer gets tripped up on channels, managing them,
| realizing the root 's channels are different than users,
| realizing their channels are out of sync on their
| multiple machines, no posting their channel revision when
| they solicit help. Not to mention pure eval. Not to
| mention transitive dependency overriding.
| jmholla wrote:
| > I've turned to flakes to specifically solve some
| problems, and flaked solved them. To this day, flakes are
| still the only way to solve them.
|
| Can you share some examples of such problems?
| joshcsimmons wrote:
| Worth noting that ChatGPT et al. Are equally useless for
| debugging Nix. Frustrating that it's so far behind. Error
| messages are often cryptic and misleading.
| FrostKiwi wrote:
| Have my server infrastructure on NixOS. Huge boost in
| productivity and stability, would never go back to standard
| linux. But man if something breaks it's a nuke going off. Sry for
| the long post, but thought I share my experience:
|
| Mass storage on a big encrypted RaidZ array of spinning rust, no
| issues. Bootloader, /boot, Encrypted Root and Databases on
| Mirrored NVME Drives. And man is that a nailbiter on each update.
| Setup my drives during 22.11 following NixOS Root on ZFS
| instructions [1], which were amended following reports of systems
| becoming unbootable [2] and mostly removed later [3].
|
| Besides initially being a broken setup [4] with an increasing
| amount of mounts each update stalling any system writes and
| causing updates to fail, it became a well running machine after
| that was fixed. Then during the 24.05 update and with no config
| change, the system became unbootable [5]. After a tough recovery
| [6] I never figured out how to do mirrored bootloaders again,
| switched to a single bootloader setup. To this day I have
| interactions I don't understand and am trying to fix [7], which
| sometimes causes updates to knock services offline due to the
| `nixos-rebuild switch` process stopping services, going to update
| the bootloader, failing due to missing mounts and exiting with
| services being offline, prompting manual intervention.
|
| [1] https://github.com/openzfs/openzfs-
| docs/blob/1211e98faf1f37a...
|
| [2] https://github.com/openzfs/openzfs-
| docs/commit/1211e98faf1f3...
|
| [3] https://github.com/openzfs/openzfs-
| docs/commit/4fb5fb694f44c...
|
| [4] https://github.com/NixOS/nixpkgs/issues/214871
|
| [5] https://github.com/openzfs/openzfs-docs/issues/531
|
| [6] https://github.com/openzfs/openzfs-
| docs/issues/531#issuecomm...
|
| [7]
| https://discord.com/channels/568306982717751326/132854109967...
| sigmonsays wrote:
| i use nixos on VMs, my desktop (Gaming and productivity) and
| servers. I use flakes for everything.
|
| I've painfully learned how to do everything I need. My only big
| complaint is updating systemd. I have yet to figure out the
| systemd update bug. Sometimes nixos-rebuild-switch takes my
| network offline when updating systemd. It's incredibly annoying
| to update a box and have it drop offline. My work around is to do
| a 'diff' and when systemd is updated, I reboot manually and only
| update the boot image.
| aidenn0 wrote:
| Does it stay offline? My network often bounces when updating
| systemd, but I haven't seen it stay down.
| sshine wrote:
| Mine does that too, sometimes.
| yoyohello13 wrote:
| 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.
| poincaredisk wrote:
| >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.
|
| If it works for you, sounds good!
|
| I comment because I recently had opposite thoughts - that maybe
| I should migrate off nix home manager - to keep 90% of benefits
| (nixos) and avoid all the headaches (home manager quirks).
| Funny how opposite experience we have.
|
| For me I love nixos because how when I configure something it
| just works, and how when I break something I can just undo that
| easily. And I like how my system don't get more cruft with time
| and stays lean.
| tombert wrote:
| 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 declarative, if I end up really
| breaking something, I can always reboot and choose a previous
| generation. It makes things a lot less scary for me, I can
| experiment with and play with different boot parameters and
| drivers and I know that I won't be stuck spending two hours
| reinstalling everything. It changes the entire way that I work.
|
| For example, on my current laptop (Lenovo Thinkpad, AMD), I was
| having an issue with my USB ports idling out, so sometimes the
| first ~4 seconds of my typing wasn't registering since the USB
| port had to wake up. The solution involved adding a kernel
| parameter `usbcore.autosuspend=-1`.
|
| Had this been something like Ubuntu, I have been burned enough
| trying to add kernel params that I might honestly have just
| lived with the annoyance because I didn't want to risk
| everything breaking, but because I knew that there was no
| actual risk with NixOS, I was able to fix it permanently, and I
| have the solution committed to Git if I ever have to do this on
| another computer.
| aidenn0 wrote:
| Anybody know what author is talking about with gnome and plasma
| not being allowed in the same configuration? I don't currently
| have both configured, but I ran this way from somewhere in the
| neighborhood of 20.09 to 23.05 with no difficulties.
| dandanua wrote:
| Desktop NixOS is my daily driver for almost 3 years. I don't
| bother diving into deep technicalities, flakes or other
| complicated stuff. I define programs and settings that I need in
| the configuration.nix. That's all. And it works perfectly!
|
| For complicated stuff I run containers such as docker or podman
| (you could use distrobox too), so I don't have a headache while
| trying to achieve it in NixOS (but I respect everyone who does
| this and makes this system grow).
| _huayra_ wrote:
| 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 similar lazy nature of the language. DSL for
| most things, then open the hood and do actual Haskell for crazier
| use cases. I get that Nix started before Haskell became less
| academic and slightly more usable in the mainstream and has built
| up momentum, but the lack of tooling for understanding what is
| going wrong when incrementally building up a config is very
| confusing.
|
| I'd be curious if anyone has go to or from NixOS compared to
| declarative distros compared to the atomic distros like ublue [0]
| and has any thoughts. I'm a bit split about what to move to next
| (though my >5 year Tumbleweed install on most of my machines is
| holding up no problem).
|
| [0] https://universal-blue.org/
| Zambyte wrote:
| I switched away from Nix OS and eventually landed on GNU Guix,
| which I have stayed on for about 4 years now. One of the main
| reasons I switched away from Nix was because of the language,
| and how underdocumented it all felt. GNU Guix was a breath of
| fresh air, using a language with decades of academic backing
| outside of the context of Guix (SICP was awesome for getting
| into it) and the whole system is very well documented, with a
| nearly Arch-wiki quality manual built into the OS in the info
| pages.
| pzmarzly wrote:
| I'm using Universal Blue now (Aurora, i.e. KDE flavour) and I'm
| very happy with it. With its large amount of pre-installed
| packages and drivers (including proprietary ones), I still
| didn't need to install any custom package (rpm-ostree) or
| otherwise modify the OS config (except for turning off SELinux
| in /etc/sysconfig/selinux). It's the most pragmatic distro I've
| used so far.
|
| SaveDesktop[0] (saves flatpak apps and DE configs) and mise-en-
| place[1] (declarative shell environment manager) are making my
| installation backupable and quite reproducible (not to NixOS
| standards though).
|
| For software that's not in flatpak, docker or mise, toolbox[2]
| and distrobox[3] are available for the rescue. Both work really
| well (toolbox seems better for CLIs, distrobox for GUIs), but
| all atomicity/declarativity is lost.
|
| [0] https://github.com/vikdevelop/SaveDesktop
|
| [1] https://mise.jdx.dev/
|
| [2] https://github.com/containers/toolbox
|
| [3] https://github.com/89luca89/distrobox
| mcpar-land wrote:
| for me there are two kinds of pain in software troubleshooting:
|
| 1) I Don't Know The State: there's some weird little bit of state
| hanging around somewhere I don't know about that's messing with
| my end result. Once I learn about this state, correcting it is
| trivial.
|
| I hate this kind of problem solving, it's not mentally
| stimulating, I don't learn a lot, looking up answers online is
| often not helpful. And when I fix it, I don't gain a lot beyond
| just the problem not happening anymore. (examples: secret config
| file i didn't know about, an application edited its own config,
| file permissions were wrong, symlink was wrong, cache is invalid,
| etc.)
|
| 2) I Don't Understand The Concept: the idea of what something is
| supposed to do or why hasn't clicked for me yet. Getting to that
| state will take some time as I wrap my head around it. Once I do,
| I have that knowledge forever and can build on it to understand
| even more concepts.
|
| I _love_ this kind of problem solving. It's mentally stimulating,
| it builds on itself, increases mastery, problems are easily found
| / troubleshot online because people are dealing with similar
| issues and not their own machine's personal state.
|
| NixOS has been almost entirely the second kind of problem solving
| for me. The first two weeks were basically a full time job of
| fussing with my config but once I got it, I got it forever.
| Writing my first derivation was confusing, but now it's easy and
| it'll always be easy.
|
| I think this is why Nix has been able to "get away with" having
| the abysmal, fragmented documentation that it has for so long -
| it's so good at being a near-stateless, all-encompassing
| declarative configuration that even outdated blog posts, random
| people's personal configs on github, even the nixpkgs source code
| can be helpful enough to solve your problem (and that's often all
| you have to go on!!!)
| zie wrote:
| 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 other people's junk with NixOS is just asking
| for pain. Just use Ubuntu LTS like everyone else. That's
| generally easy and painless.
| Brian_K_White wrote:
| "Trying to hack on other people's junk with NixOS is just
| asking for pain."
|
| To me that's a large part of the very definition of a useful
| general purpose OS is that it's flexible and enables you to do
| whatever you need to do today, without the developers having
| previously somehow planned and provided for exactly that thing.
|
| It's like the systemd argument all over. The exact thing
| systemd aims to prevent is the exact thing that made the
| original unix so powerful and useful that 40 years after
| architecting it, it still worked because they didn't try to
| think of every possibility, they gave you a toolbox that let
| you do whatever you might need to do. Where systemd sees a
| shell script as "unmanaged chaos" I see "unconstrained utiliy",
| a useful toolbox including a saw that doesn't have it's own
| opinions about me what boards I can cut.
|
| If "Trying to hack on other people's junk with NixOS is just
| asking for pain." that is basically the definition of "this is
| not a useful operating system that empowers me to get things
| done". It's useful maybe as a crafted firmware for a static
| device.
|
| (Not saying that nixos inflexibility is driven by the same
| paternal "we'll give you the whitelist of actions Poettering
| thinks are valid" attitude as systemd. In nixos it's merely a
| natural consequence of indirection and layering. They aren't
| trying to remove any agency from the user/admin, it's just the
| simple indirection itself that makes pre-planned and
| standardized things easier at the expense of anything direct
| and unplanned becoming harder.
|
| Like instead of having an OS that may or may not be driven by
| ansible, let's replace the OS with just ansible, and now there
| is no way to do anything any other way except by figuring out
| how to write a playbook to do it.)
| grumpyprole wrote:
| > To me that's a large part of the very definition of a
| useful general purpose OS is that it's flexible and enables
| you to do whatever you need to do today,
|
| NixOS gains most of its power from restrictions. These
| restrictions enable awesome things like starting a shell with
| all dependencies in seconds versus minutes using alternative
| technologies (used by great effect by replit). Nix works
| surprisingly well for most software, but anything with a ton
| of dynamic dependencies is going to cause issues. Even
| knowing what the dependencies _might be_ statically can be
| hard. Sure, providing an OS with no restrictions and complete
| flexibility is an option, but then you 'll just end up no
| better off.
|
| Whatever the future of operating systems will be, it
| certainly will involve more restrictions and less
| flexibility.
| cb321 wrote:
| Not to be too presumptuous, but you sound like someone would
| might like Gentoo. It still works without systemd, though it
| does install sys-apps/systemd-utils (mostly for the /dev FS
| stuff). I'd say the focus of Gentoo is on "managing choice",
| and it is true that some choices can make your system(s)
| diverge from the most frequent instances floating around (but
| those tend to be systemd-based these days). It's still pretty
| decent, though. I've been incrementally upgrading the same
| basic install since Jan, 2007. Of course, you may already
| know all about it and have other opinions.
| mazambazz wrote:
| > Trying to hack on other people's junk with NixOS is just
| asking for pain.
|
| Yeah, but being that Nix is essentially a giant wrapper for the
| system, that kind of goes without saying. The other side of the
| coin is that, using other people's Nix junk is extremely easy.
| Far easier than what any other distro could hope to achieve.
|
| My favorite example is simple-nixos-mailserver. Try passing
| someone a dovecot, postfix, and openssh
| configurations/instructions in any other distro and see how
| long it takes before they mess up, or more likely, give up.
|
| Whereas with simple-nixos-mailserver, you're guaranteed to get
| something to work, essentially right out of the box.
| bfrog wrote:
| I love the ideas behind Nix. But as noted here, there's a
| thousand cuts to be found.
|
| My biggest issue has been packaging binary distributed programs.
| These often want files in a particular directory somewhere, often
| want to find relative path libraries or plugins, want certain
| configuration options in etc...
|
| None of that Just Works, there's a whole confusing method to try
| and monkey patch the software to work but its long list of not
| being able to find the information you want, not being able to do
| what you want, or simply limitations around how nix wants to
| structure things that make it really really frustrating.
|
| If something like Nix were to be done again... I'd really
| recommend starting with something like a strongly typed flake
| like language with tooling a lot closer to that of cargo from
| rust from the get go. Errors should be easy, projects should be
| easily setup independently, etc. Where every project can simply
| be built as an independent thing. Sure there's downsides, but the
| upsides are that... you don't have the impossible task of
| managing one of the largest mono repos, if not the largest, on
| github. With all of the insane issues that entails. It wouldn't
| be that terrible to have a crates.io equivalent to publish, test,
| and share flakes.
|
| Now I think I might've just created flakehub... but flakehub
| still relies on nix the tool and nix the language which are far
| from easy to work with.
| jcmfernandes wrote:
| I'm relatively new to nix, and this cut close:
|
| > At this point NixOS has been around for 2 decades, but it still
| feels like it has not settled on good recommended workflows for
| incoming users.
|
| Yes. This was a major pain point when I was getting started. The
| IRC community has been helpful in this regard. I also really
| don't like that nixpkgs serves as both a lib and a package set.
| Be one! I don't want "special" inputs in my config.
| Brian_K_White wrote:
| Instead of having an OS that might be driven by ansible, let's
| just replace the OS with ansible.
| Baeocystin wrote:
| The older I get, the more I realize that so much of the divide in
| the tech field is simply between the two camps of "the tools are
| the interesting part" vs "getting things done with the tools is
| the interesting part".
| azeirah wrote:
| The more I use nix, the more I understand it's both. Nix is
| genuinely so fucking great, but the ecosystem and docs and
| language are a mess. It needs to be cleaned up, and things
| _are_ getting better.
|
| The core philosophy of Nix is so damn solid though, and that's
| the real innovation here. As long as its philosophy manage to
| stick around, then it's ok.
| rob_c wrote:
| It's basically, I refuse to learn how to containerize.
|
| Just learn, use, promote best practices and stop forking the
| ecosystem _even_ further...
|
| There, I got that off my chest.
| jvandreae wrote:
| The problem with docker is less the containerization and
| more the half-baked build system.
| jjmarr wrote:
| Well, yeah.
|
| Nix is attempting to be better than containerization.
|
| Saying "improvements aren't necessary because we already
| have 'good-enough' technology" is a meaningful argument
| when the improvements aren't significant.
|
| In my view, they _are_ significant because Nix can be used
| to create a fully featured OS instead of just a VM.
| pzmarzly wrote:
| > they are significant because Nix can be used to create
| a fully featured OS instead of just a VM
|
| Look up Bootable Containers project by RedHat [0]. Fully
| featured OS built from a Containerfile, bootable on bare
| metal.
|
| I agree that Nix design is much better than Docker, and
| has a bunch of features that OCI ecosystem doesn't (e.g.
| remote builds[1], partial downloading of the build tree,
| non-linear build process[2], nix store import/export,
| overlays, I/O isolation, much better composability), but
| "creating OS instead of VM" [did you mean container?] is
| not one of them.
|
| [0] https://github.com/containers/bootc
|
| [1] You can use DOCKER_HOST, and I'm happy that this
| option is there, but Nix does it better.
|
| [2] Perhaps with BuildKit it's no longer true, I haven't
| checked what happens if you have multi-staged build with
| one stage depending on multiple previous ones (which are
| otherwise unconnected). I think Earthly can parallelize
| this scenario https://earthly.dev/
| edude03 wrote:
| As a heavy container user myself - I've been using
| containers since I needed to build my own 3.x kernel to
| test them - docker doesn't solve the reproducibility
| problem nix solves - IE, I can make a Dockerfile that does
| `RUN curl foo.com/install.sh` and who knows if that'll work
| ever again. Nix on the other hand doesn't allow you to do
| IO during builds[^0] only describe the effect of doing the
| IO.
|
| [0]: Though apparently darwin (mac) doesn't support
| sandboxing by default, so you can bypass that but anyway
| agumonkey wrote:
| eelco thesis: 2003
|
| lxc: 2008
|
| docker: ~2012
| mazambazz wrote:
| Nix and containerization aren't drop-in replacements for
| each other.
|
| You can use Nix to build containers. Containers on their
| own don't guarantee reproducibility, especially if the
| build process isn't static and pure ( how many times do we
| `sudo apt update` inside a Dockerfile )?
|
| And not everything is going to be containerizable. That
| only works for most applications. What if we're trying to
| manage our cloud servers? That's where Nix really shines.
|
| Do you really think that Nix developers don't know how to
| containerize applications? You think people are using Nix
| because they refuse to learn how to containerize, and
| therefore opt to learn a _much more_ difficult and arcane
| build process? The logic doesn't track there.
| z_mitchell wrote:
| I think that's a bit reductive, but I get the intent. A lot of
| people see systemic problems in their development and turn to
| tools to reduce the cognitive load, busywork, or just otherwise
| automate a solution. For example "we always argue over
| formatting" -> use an automated formatter. That makes total
| sense as long as managing/interacting with the tool is less
| work, not just different work.
|
| With Nix I still think it's a net positive, but the "different
| kind of work" side of the equation is pretty large. That's why
| we're building Flox [1]. The imperative user interface of a
| package manager (flox install, flox search, etc) that builds
| out a declaratively-configured, reproducible, cross-platform
| developer environment. I really think it nails the user
| experience by keeping that "different work" side of the
| equation small, and (I hope) just gets out of your way.
|
| [1]: https://flox.dev
| pkkm wrote:
| Your veiled implication that Nix and NixOS aren't about
| "getting things done" is, I think, more than a little unfair.
| I'm using multiple programming languages at work. Each one of
| them has its own dependency manager that does basically the
| same job as the other ones. In Python it's Poetry, in Ruby it's
| Bundler, in JavaScript it's npm/yarn, in PHP it's Composer,
| etc. A lot of projects require extra setup steps outside of the
| dependency manager. It's not a good experience that lets you
| get up and running quickly. And my situation with scripting
| languages isn't the worst case: God help you if you have
| dependencies between projects in AOT compiled languages that
| use different dependency managers. This is why Google made
| Bazel and Facebook made Buck.
|
| Of course, the standard answer is to spin up a ton of Docker
| containers. Docker works, but it looks to me like a local
| optimum rather than a truly painless solution. It sucks as a
| build system, and Dockerfiles not being reproducible is the
| default outcome that needs significant extra care to avoid (how
| many times have you seen _apt update_ or some equivalent in
| one)? Besides, why should I have to worry about a whole another
| OS inside my main OS, with potentially different tooling and
| conventions, when what I really want is just specific versions
| of a couple of tools?
|
| I think we've gotten used to development environments being a
| shitty experience to the point where it seems part and parcel
| of programming, but when you take step back, it's apparent that
| the situation causes a lot of frustration and wastes a lot of
| time. To me, Nix's combination of package manager and
| reproducible build system looks like one of the most credible
| ways out. NixOS' declarative configuration and rollbacks are
| nice side benefits too, for server admins and newbies
| respectively. Nix just needs a lot more polish. I'm not about
| to introduce a tool where the most common workflow is still
| considered experimental. For now, I'll keep using Docker, but I
| watch Nix with interest and can't wait until its UX matures.
| eacapeisfutuile wrote:
| That is not why neither Bazel or Buck was created.
| pkkm wrote:
| It's not? I recall reading that coping with a variety of
| languages was one of the main motivations, but do correct
| me if I'm wrong and you have a citation.
| eacapeisfutuile wrote:
| They do hermetic builds so that it is viable at large
| scale via granular caching. They were made to make that
| work at those scales, with pretty much zero consideration
| for any external package managers or anything like that
| samsquire wrote:
| I enjoy writing tools.
|
| How do you feel about Kubernetes?
|
| It would be good to have some interesting tasks to do?
|
| I think the tools should do also much of the work. I actually
| prefer batch systems that are a simple execution of a program
| against a dump which are just process all the data and generate
| data with the new states than a networked online system that
| breaks all the time and due to DNS
|
| Micro services keep me awake but a simple CSV processing I can
| fix in my own time.
| tombert wrote:
| I love NixOS, it's my daily driver on my personal laptop, but it
| definitely has given me more than its fair share of headaches.
|
| If everything you're going to do is in Nixpkgs, great! Nix will
| mostly "Just Work" and you'll get all the nice declarative
| goodness that you want. Since Nixpkgs is constantly getting
| updated, this isn't that weird of a thing.
|
| The thing that's been most annoying to me is when I try and run
| generic Linux programs, only to be unceremoniously told "You
| can't run generic Linux programs in NixOS because we break
| dynamic linking". Suddenly something that would take about ten
| seconds on Ubuntu involves me, at the very least, making a Flake
| that has an FHS environment, or me making a package so that no
| one else has to deal with this crap [1]. I didn't really _want_
| to know how to make my own Nix package, and I don 't really
| _want_ to be stuck maintaining one now, but this is just part of
| Nix.
|
| This means that it's still not something I could easily recommend
| to someone non-technical like my parents, unlike Ubuntu. You have
| to be willing and able to occasionally hack up some code if you
| want your system to be consistently useful.
|
| To be clear, there's a lot of stuff I really like, I don't plan
| on removing it from my laptop, and for something like a server
| (where the audience is sort of technical by design), I really
| have no desire to ever use anything but NixOS, but it's a little
| less impressive for desktop.
|
| [1] https://github.com/NixOS/nixpkgs/pull/366367
| lilyball wrote:
| You can run generic Linux stuff if you install nix-ld1, the
| only tricky bit is having to customize the set of libraries
| given to nix-ld for your use-case. It includes various common
| libraries by default, but depending on what you want to run you
| may have to add to it.
|
| 1https://search.nixos.org/options?channel=unstable&show=progr..
| .
| tombert wrote:
| Interesting, I didn't realize that that was an option.
|
| I've been getting by with buildFHSenv and Flakes, which,
| despite my complaints, really isn't _that_ annoying. My goal
| at this point is to eventually compile all my flakes and take
| on Lutris.
| JasonSage wrote:
| There's also nix-alien which does this but tries to be more
| automagical.
| kombine wrote:
| Could you setup distrobox to run regular Linux programs?
| tombert wrote:
| Almost certainly, though I've never tried.
|
| I'm technical enough to where making a Flake doesn't really
| bother me, and it's really not as hard as I was making it out
| if you're already familiar with functional programming, I'm
| just saying it's an annoyance.
|
| That said, I might need to play with Distrobox, it looks like
| it's in nixpkgs.
| 0x457 wrote:
| Love NixOS and Nix in general (just not the language). I've
| started using `steam-run` to run things I'm too smooth brain to
| port.
| tombert wrote:
| I will say that once I found out about Flakes it bothered me
| a lot less. I find them a lot easier to test and it's nice to
| be able to easily define a custom little environment for them
| and then just do `nix run` afterwards.
|
| It's been especially useful to be able to specify exact
| versions of wine and winetricks installs on a per-game basis.
| lilyball wrote:
| > _It seems very cool that you can roll back in the case of a
| catastrophic upgrade failure, but has that every happened to you?
| Not me._
|
| Rollbacks saved me from completely destroying my entire system. I
| managed to fill up my boot partition in a way that deployed
| successfully but left the whole system unbootable after reboot,
| and the only way I managed to save it without having to
| completely wipe and reinstall from scratch (which means losing
| all my data) was to load the SD card onto my laptop, fix the boot
| partition by hand to ensure the kernel from the previous
| generation was valid, and edit the bootloader config to delete
| the offending configuration (because accidentally trying to boot
| it would re-corrupt the boot partition).
|
| I've also used rollbacks in other less catastrophic situations,
| such as when I broke wireless (since I build remotely on a much
| more powerful machine and deploy over SSH).
| ssalka wrote:
| Just want to flag that the first image likening Nix to the Holy
| Trinity has a spelling error in the text "The Operating Systam".
| captainepoch wrote:
| > It seems very cool that you can roll back in the case of a
| catastrophic upgrade failure, but has that every happened to you?
| Not me.
|
| It did, and thanks to that rollback feature, my system was
| working in a few minutes.
| edude03 wrote:
| Nix has been my daily driver for about 10 years, all 10 on
| servers, and about 3/4 on a laptop.
|
| The thing that hits close to home for me, is the inability to use
| software that doesn't support nixes opinions on how to do version
| management (for example a post of mine from years ago[^0]),
| software that likes mutable state for its configuration (Gnome
| for example) and yeah, trying new things that aren't packaged for
| nix means writing a nix derivation.
|
| That said, I feel like nix does more good than harm for me so the
| paper cuts are bearable.
|
| [0]: https://community.roonlabs.com/t/unable-to-get-roon-to-
| start...
| James_K wrote:
| I only wish Guix had a more robust nonfree packages I think it
| could really give Nix a run for its money.
| nemoniac wrote:
| If you're looking for robust, nonfree packages for Guix, you
| can find them here:
|
| https://github.com/nonguix/nonguix
| 0x457 wrote:
| It reads like the author didn't even try to understand NixOS.
|
| > But not always. Why? Because there are so many ways the context
| can vary as everyone is doing different things. Is that config
| you found:
|
| This whole section reads like author gives ChatGPT code snippets
| and asks it to explain.
|
| Nix snippets are not very copy-pastable because everyone creates
| different abstractions to reduce boilerplate. I have probably
| done "JSON -> list of packages" conversion 3 different ways in my
| codebase.
| grep_name wrote:
| I've been using nixOS on my laptop for over a year now and I
| still don't have an answer for 'my version of firefox/darktable
| has a bug in it, but I can't update it without upgrading the
| entire rest of all the software installed on my machine.' I keep
| thinking there has to be a way around this, but it doesn't seem
| like there is one that's clean and not hacky / brittle. Other
| than that I love it, but that's a pretty huge caveat
| sunshine-o wrote:
| I really like Nix but recently I ended up in a very tricky
| situation:
|
| If you you are cut from the internet or end up with a very slow
| connection you can end up totally blocked. As a minor
| configuration change can require you to download a lot of data.
|
| I also found out there is not much you can do to protect you from
| this.
___________________________________________________________________
(page generated 2025-01-14 23:00 UTC)