[HN Gopher] Nix-GUI: Make NixOS usable for non-technical users t...
___________________________________________________________________
Nix-GUI: Make NixOS usable for non-technical users through settings
/ GUI
Author : asicsp
Score : 201 points
Date : 2021-10-10 11:09 UTC (11 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| TeMPOraL wrote:
| What a coincidence. I was just asking about NixOS on Mastodon.
| Reposting (I'm on a mobile, little time to type):
|
| " a question on dev environment isolation. Is either #NixOS or
| #GUIX usable as an OS for day-to-day use (coding, browsing,
| occasional gaming)? Or is it better to just use their respective
| package managers on top of regular Linux? Also, anyone here doing
| desktop #virtualization? Is there a sense of running a #VM per
| project? Is that a viable alternative to dual-booing Windows when
| I want to do some Windows dev or play a game?
|
| I'm planning to overhaul my desktop and am exploring options."
| podiki wrote:
| I've recently switched (from Arch) to Guix for my new desktop.
| Works great, though does require some work (I enjoy the
| tinkering). Depends on what you want of course, and needs you
| have especially in the non-free or things like JS (Guix does
| not package, but you can use Nix package manager or other tools
| I think). Here is the HN post for the article I wrote to see
| the article (about the hardware) and discussion
| https://news.ycombinator.com/item?id=28628344 I'll have some
| followups soon on what I like about Guix for this usage and how
| I set things up, with some tips.
| Ericson2314 wrote:
| I've used it as my daily driver for the last 7 years.
|
| I don't really play games that much but you can install Steam,
| and at that point the distro doesn't matter as much. (Though
| for a bunch of reasons I think NixOS would be the ideal distro
| to base SteamOS off of, and Valve & co. are only now closing
| the gap _years_ later with some still-beta flatpak-esque
| stuff.)
|
| I would say, if you can get excited with messing around with
| Nix _instead_ of playing video games, you 're going to have a
| better time. Not because you need to (though you might if this
| is your first time doing Linux), but because the joy lies in
| being able to understand "what the fuck is actually going on!"
| for the first time, and getting to that level of understanding
| will take some time.
| carlhjerpe wrote:
| I have a Windows VM on a NixOS host for gaming, was really
| quite convenient to set it up, I set it up on a separate drive
| to be able to boot native too but I ended up never really doing
| it, so I will reconfigure my 2 drives as a Zraid and have
| windows on a Zvol instead.
|
| NVIDIA works great, but if I were to buy new hardware I'd go
| AMD (maybe Intel when the time comes)
| depressedpanda wrote:
| > I have a Windows VM on a NixOS host for gaming, was really
| quite convenient to set it up, I set it up on a separate
| drive to be able to boot native too
|
| I've been planning on doing exactly this, but haven't had the
| time to figure out the best way of going about it.
|
| Is there a good guide/write up you'd recommend? (I already
| have a Windows 10 install on a separate SSD, but I rarely
| boot it because I can't stand the OS)
| carlhjerpe wrote:
| So first I did this I did it on manjaro using this archwiki
| article:
| https://wiki.archlinux.org/title/PCI_passthrough_via_OVMF
|
| When I moved to NixOS I just did a normal NixOS install and
| applied the same parameters to kernel boot as before and
| passed the GPU through.
|
| I was using looking-glass at first, but my computer is too
| slow and crappy (memory bandwidth seems to choke) to run
| 144fps in overwatch.
|
| You just pass the entire block device into the VM if you
| wanna keep your setup, or pass it through with as PCIE if
| it's an NVMe device.
|
| I thought it'd be hard, but you'll be up and running in a
| day
| smoldesu wrote:
| Overwatch is also highly optimized via Wine, if you're
| looking to play. I'm on 6-year-old hardware (i5 4460, GTX
| 1050ti) and I have no problem hitting 120+ FPS in-game.
|
| https://www.youtube.com/watch?v=voXc1nCD4IA
|
| This video is a pretty good demonstration of how neck-
| and-neck the performance is these days. Frankly, I feel
| like it stutters _less_ in Linux, but I might just be
| imagining things.
| gallexme wrote:
| I use https://github.com/danielfullmer/nixos-nvidia-vgpu +
| https://looking-glass.io/ very successfully
|
| Can theoretically game on Linux and windows at same time
| with just a single gpu (2080 ti), mainly use it cause I
| only have single gpu and I don't want to loose hardware
| acceleration on Linux, the nixos module both applies a the
| vgpu unlocker for consumer graphic cards (so u can split a
| gpu in multiple virtual gpus)
| https://github.com/DualCoder/vgpu_unlock
|
| And merges it with the GeForce drivers so the host gpu does
| not stop having display output
|
| And I just passthrough the vgpu and Xbox controllers to the
| vm with qemu and my main windows nvme disk (windows
| naturally just works inside and outside a vm for me, dual
| boot)
| m45t3r wrote:
| > Is either #NixOS or #GUIX usable as an OS for day-to-day use
| (coding, browsing, occasional gaming)?
|
| Yeah, definitively. I use only NixOS on all my machines for
| about 3 years already. My machines are working so well nowadays
| that I rarely have to change anything [1], even during major
| upgrades (between stable versions).
|
| I don't fear anymore if a machine could break tomorrow. I know
| that it will be very easy to restore it to a working state.
| Last time my working notebook broke I didn't even bother making
| a backup (except from some data on my Home), just installed my
| config and it worked exactly it was working before. Also, I
| don't fear changing my system: if something brokes after the
| changes, I can just rollback.
|
| I use for all those three purposes, mainly coding and browsing,
| but some light gaming. Steam actually works better on NixOS
| than any other distro I tested before thanks to the isolation
| that Nix provides.
|
| > a question on dev environment isolation. [...] Or is it
| better to just use their respective package managers on top of
| regular Linux?
|
| I imagine those are part of the same question. Generally what I
| recommend for newbies is to start small: yeah, it is fine to
| continue using your respective package manager, specially if
| you don't need "native compilation" [2].
|
| After you get more experience with Nix though, I would
| recommend you to start isolating your development environments.
| Nix has its own `nix-shell`, that it is kinda bare-bones but
| works well, and can be very practical once you use something
| like `nix-direnv` (https://github.com/nix-community/nix-
| direnv/). There is also this `devshell`
| (https://numtide.github.io/devshell/intro.html) project that is
| interesting.
|
| > Also, anyone here doing desktop #virtualization? Is there a
| sense of running a #VM per project? Is that a viable
| alternative to dual-booing Windows when I want to do some
| Windows dev or play a game?
|
| I put those two questions together because yes, I ran desktop
| virtualization on NixOS, and yes, I ran Windows on a VM to play
| games thanks to PCI-e passthrough (my dedicated GPU is
| connected directly to the Windows VM so the performance is near
| native) [3].
|
| Again, I will not recommend you do to this right after starting
| NixOS since it is one more thing to possible frustrate you, but
| just so you know that it works and works well, specially
| because my VM configuration on NixOS is also on my
| `/etc/configuration.nix` and it is fully reproducible.
| Coincidentally I was messing with my VM settings yesterday and
| "broke" my VM multiple times, however I just run one command
| and restored it to the previous state.
|
| However I never bothered to dual-boot NixOS/Windows, because I
| barely use Windows nowadays so I find rebooting my system just
| to use Windows bothersome. Probably not your case, so maybe
| dual-boot makes more sense. This article should help and seems
| very easy to do (again, disclaimer, not tested because I never
| needed it):
| https://nixos.wiki/wiki/Dual_Booting_NixOS_and_Windows.
|
| About the VM per project, unless you want to do this for some
| other reason (security maybe?), you don't need to. As I said
| before, you can use things like `nix-shell` and this will
| already give isolation enough for development purposes.
|
| ---
|
| Some closing words: remember, start small! Nix/NixOS is a
| journey. You will learn eventually what you need. However, if
| you try too many things at the same time you will feel
| frustrated. The official documentation is good, however it
| kinda assumes that you know what we are talking about already,
| and it is also very big and not well separated in steps, so it
| feels overwhelming for newbies. To supplant this there are many
| blog posts, however some of them are out-of-date (it shouldn't
| be too much of an issue though, since Nix tries really hard to
| backwards compatible).
|
| You will eventually need to learn the minimum of the language
| to read the source code. It is less difficult than it seems,
| because while Nix as a language is strange at the first glance,
| it is a very well designed DSL for the domain. After sometime
| editing your own configuration you will naturally learn the Nix
| language, and can start to understand what is happening.
|
| For where to start, I recommend trying to replicate your
| current system in a NixOS install. If you already use another
| Linux distro try to get the same desktop environment and
| packages that you already use. If you're coming from
| Windows/macOS try Gnome or KDE. Just tweak the system until
| you're happy with the result. Eventually try Home-Manager to
| manage your Home configuration in the same way as in NixOS
| (fully declarative), and once you feel happy, you can try
| Flakes (making you configuration fully reproducible). This
| process can takes months or even years, but don't bother or
| rush, just continue your journey. It really pays off in the
| long run.
|
| [1]: well, I am on a "coding spree" right now so I am doing
| many changes, most to refactor some things that I wasn't happy
| before; but before this coding spree my configuration didn't
| change significantly for almost a year.
|
| [2]: what I call having to compile C/C++ libraries in an
| another language like Python (giving it an example here, almost
| any language has a similar mechanism since C/C++ ecosystem is
| huge), that generally needs to dynamically link with whatever
| you have in your system installed. This is possible on
| Nix/NixOS, and easy once you know what you're doing, but it is
| different from anything else so it does trip newbies.
|
| [3]: if you're interested on this approach, I used this guide
| when started: https://forum.level1techs.com/t/nixos-vfio-pcie-
| passthrough/.... To get it fully reproducible it though, there
| is no way on NixOS itself yet, however there is a good guide
| here:
| https://nixos.wiki/wiki/NixOps/Virtualization#Setting_Up_the...
| TeMPOraL wrote:
| Thanks for the detailed writeup, and all the pointers in it!
|
| > _About the VM per project, unless you want to do this for
| some other reason (security maybe?), you don 't need to. As I
| said before, you can use things like `nix-shell` and this
| will already give isolation enough for development purposes._
|
| That's great to know. I don't have security requirements
| there - I'm just looking for a way to isolate projects along
| with their dependencies and supporting software (e.g. if I
| need a one-off installation of some program to create
| project-specific assets).
|
| The problem I'm trying to solve is the system getting messy
| over time - accruing multiple versions of runtimes for
| programming languages, system configuration changes, pinned
| library versions etc., all because every other project needs
| some OS tuning or system-wide dependency. Eventually, I
| always end up hitting a roadblock where something I need now
| is incompatible with something I changed 2 years earlier no
| longer remember why. So I'd like to keep various projects and
| activities isolated, and to be able to just get rid of them
| when they're no longer needed.
|
| The reason I'm asking about VMs is because I recall reading a
| blogpost or a HN comment where someone described how they're
| achieving what I'm after by running a hypervisor on their
| main machine, and doing everything in one-off VMs. I can't
| find that post/comment now, and I'm left wondering if this is
| something people do, and what the tradeoffs are.
| pxc wrote:
| Old versions of software are super easy to deal with with
| Nix, because it gives you a baseline level of isolation for
| all packages that obviates these problems. On some of my
| systems running the latest NixOS release from 2021, I've
| installed a package from 2015, and I didn't have to do
| anything to isolate it or its whole toolchain.
| m45t3r wrote:
| > The problem I'm trying to solve is the system getting
| messy over time - accruing multiple versions of runtimes
| for programming languages, system configuration changes,
| pinned library versions etc., all because every other
| project needs some OS tuning or system-wide dependency.
| Eventually, I always end up hitting a roadblock where
| something I need now is incompatible with something I
| changed 2 years earlier no longer remember why. So I'd like
| to keep various projects and activities isolated, and to be
| able to just get rid of them when they're no longer needed.
|
| Don't worry, this issue is solved with Nix/NixOS itself.
|
| If you use `nix-shell` to setup an dev environment for
| which project, you will generally have a `shell.nix` or
| `default.nix` file in the same directory as the project.
| For example: with import <nixpkgs> {};
| mkShell { name = "myProject";
| buildInputs = with pkgs; [ gcc
| python39 lua ]; }
|
| And once you use `nix-shell` inside the directory that
| contains this file above, it will download GCC, Python 3.9
| and Lua, and put them on PATH. If you do a Ctrl+D, it will
| exit this shell and you won't have those 3 programs in your
| PATH anymore (assuming of course that you don't have them
| installed in your system).
|
| BTW, this is where `nix-direnv` enters: it will do the
| `nix-shell` part and Ctrl+D management automatically for
| you. So once you enter in the project directory, it will
| automatically activate the `nix-shell`, once you exit, it
| will automatically exit `nix-shell`.
|
| The Python case is specially interesting because if you
| have Python 3.7 in your system PATH, this shell will
| override the system Python, so only in this project you
| will have Python 3.9.
|
| To avoid re-downloading them every time, Nix will actually
| cache those dependencies. So to really remove them from
| your system you will need to run the garbage collector
| (`nix-collect-garbage -d`), but since they're not in your
| PATH they will not conflict with other packages in your
| system.
|
| It is something similar to NixOS (however in this case this
| is system-wide): { pkgs, ... }: {
| environment.systemPackages = with pkgs; [ gcc
| python39 lua ]; }
|
| In this case, GCC, Python 3.9 and Lua will be available on
| your system PATH after you do a `nixos-rebuild swtich`. If
| you remove them they will be deleted from the system PATH
| after running `nixos-rebuild switch` again, creating a new
| _generation_.
|
| The generation part is important: in case things break, you
| can go back to the previous version using `nixos-rebuild
| switch --rollback`. So let's say you changed Python 3.9 to
| 3.10 on your system but it actually broke something
| important (let's say it is a script that is important for
| your desktop, so now you don't have a desktop anymore): you
| can just call `nixos-rebuild switch --rollback` and
| everything will go back to working again, and afterwards
| you can commit your changes and run `nixos-rebuild switch`
| to commit them.
| opan wrote:
| Guix System is very usable as a main OS if your hardware is
| compatible. Linux-libre gives some people trouble with their
| GPU or WiFi. I use a ThinkPad T440p with the WLAN card removed,
| and everything that remains works fine. If you need blobs for
| an AMD GPU or WLAN, you likely need to swap out linux-libre for
| linux in your config. I haven't done this myself, but I know a
| few people who have done so. Also consider that discussion of
| non-free bits like this are not allowed in the official IRC and
| mailing lists, so you'll have to either be on your own or find
| the semi-secret places where guix users use non-free things.
|
| All that aside, I've spent time with NixOS and Guix System
| both, and much prefer the latter. Nix has more packages, but
| some of them (which I actually use in everyday life) are broken
| in odd ways where they work fine in Guix. I also like to use a
| distro without systemd when possible, and find the guix
| community feels more alive/active. Getting more Guix users (and
| packagers) will help narrow the gap as well. There are enough
| packages that I don't miss too much in daily use, and you can
| comfortably get all your emacs packages through guix, I just
| often can't try some new program when I first learn about it.
| forgotpwd16 wrote:
| Don't know about Guix System but I've used NixOS as main OS for
| third year now just fine. Of course for coding you'll need to
| learn how to create (basically learn Nix, the language) an
| environment that has the libraries used in the specific
| project. The last question applies to any distro. Gaming is
| viable if you've GPU passthrough.
| Narice wrote:
| For dev environment s I would recommend taking a look at
| devshell: https://github.com/numtide/devshell
| catern wrote:
| You may already realize this, but you don't need to run a VM
| per project if you're using Nix; Nix lets you have as many
| self-contained development environments as you like, all on one
| machine without VMs or containers.
| TeMPOraL wrote:
| That was my understanding, but I wasn't sure. Thanks for
| clarifying.
| temp0826 wrote:
| re: vm per project- Hashicorp's Vagrant has been around for
| over a decade if you want to keep beating that horse.
| TeMPOraL wrote:
| I don't mean isolating just the project, but also its
| development environment, tools for making assets, their
| dependencies, etc. Possibly persisting runtime state when
| switching over to a different project. Basically, as if each
| project had its own dedicated laptop.
|
| IIRC, Vagrant was geared for just project isolation, and
| didn't offer the optimum VM management experience.
| Apaec wrote:
| > #NixOS or #GUIX
|
| Two years user of NixOS here, moved after using Arch for about
| 3 years. Overall I'm really happy with it.
|
| I also evaluated Guix when migrating from Arch. My raw and
| honest opinion about it is that it's just an attempt at open
| source fragmentation with zero innovation(I'm not impressed by
| Scheme or Lisps) that uses GNU marketing/branding/philosophy to
| gain adoption. I decided not to waste any time with it.
| suchar wrote:
| Over the years, I tested multiple options, and currently, I'm
| using NixOS declarative containers. It requires more work to
| create a new environment than with nix-shell, but in my
| experience, this is not a bottleneck. With some setup, you can
| even run graphical applications inside containers. I've written
| more about this and other approaches on my blog:
| https://msucharski.eu/posts/application-isolation-nixos-cont...
| if you are interested. It is pretty specific to my needs, so it
| may not work for you.
|
| Regarding the Windows: after playing with GPU-passthrough, I
| came back to dual-boot. It is more reliable because you are
| less likely to run into some hardware quirk.
| mindslight wrote:
| Kind of orthogonal to your questions, but perhaps it helps:
|
| NixOS solves OS-level issues. If you don't appreciate that
| you're having them, or you're solving them by other means, you
| might not see the appeal.
|
| I tried NixOS on three separate occasions before it stuck. My
| existing setup is based on Debian and templating config files
| across machines (small heterogeneous network). This system can
| rebuild any machine from a blank slate, and so the first two
| times I tried NixOS I didn't see what it could give me - my
| configuration was already quite declarative and centralized.
|
| The third time trying NixOS, I was aiming to make an image for
| a Raspberry Pi (after a Raspbian apt-get upgrade had borked a
| system once again). Seeing that I could make a full build from
| source, cross compiled or emulation compiled, with a few lines
| in a config file made it all click. It felt reminiscent of the
| Lisp curse where such a thing isn't well documented, because
| it's just second nature once you understand the system. I've
| only felt that level of paradigm changing expressive power a
| few times, and NixOS was one of them.
|
| What is keeping me heading in the NixOS direction is the
| greater source accessibility. I've run Debian for 20+ years,
| and I still don't routinely modify existing packages. Whereas
| with Nix it's second nature because it's essentially a source
| distribution.
| GordonS wrote:
| I've never used Nix, but it sounds interesting.
|
| I get the impression it's more used on desktop, but I'm curious
| if anyone has used it on servers?
| tinco wrote:
| I would say it's more convenient and useful for servers, but it
| could also be used for desktop. In theory it's the perfect
| server operating system, but in practice many sysadmins balk at
| having to learn the configuration language which has some
| design flaws that make it awkward and they stick with old
| fashioned stuff like Ansible.
| xyzzy_plugh wrote:
| Yes. I know Shopify does (or at least did), I believe Target
| was a relatively early adopter. I think Tailscale dabbled with
| the idea.
|
| Everything feels quite stable from a server admin perspective,
| though there are still various competing methods to actually
| administer fleets of machines. Nix Ops is a bit opinionated but
| works okay. I just build locally or in CI and push to hosts
| remotely.
| ElonMuskrat wrote:
| FWIW Shopify used nix-shell for the developer environment. If
| all they need to do is import standard packages - it's
| actually quiet a good solution for multi-platform dev
| environments.
| fesc wrote:
| I'm using it for some internal systems at work and I feel
| there's nothing like it.
|
| NixOS gives a level of reproducability that other tools like
| Ansible won't ever be able to give you.
|
| This reproducability means it makes debugging problems very
| easy: E.g. uncomment a line in the config and see if something
| starts working again. You can nearly undo everything cleanly in
| NixOS by just doing that.
|
| On the other hand the learning curve really is pretty steep.
| Took me about half a year to get to a point where I understood
| it enough to be able to debug most errors.
| ElonMuskrat wrote:
| Yeah. We've used it on servers. It's good in a small setting
| where a handful of Nix experts can run the infrastructure show.
|
| Getting it to scale to an organisation of hundreds wasn't
| feasible. As soon as we needed to start expanding
| "infrastructure" beyond just one team, and rapidly hiring new
| engineers in the context of rapid growth. Training and learning
| curve was intractable. And we cannot just easily hire NixOS
| experts like traditional Ubuntu OS.
|
| Nix made complicated things possible but simple things
| complicated. Pretty much every new feature request could only
| be processed by a handful of Nix experts, and it was obvious
| that wouldn't scale with the growth of the company.
|
| Frankly, Nix solves problems that the industry has already
| solved or knows how to live. Its lack of adoption from software
| vendors makes the economical cost/benefit unatractive.
| throwaway894345 wrote:
| > Frankly, Nix solves problems that the industry has already
| solved or knows how to live
|
| Agreed. Nix solves really important problems, but the
| problems it introduces tend to be worse. My instinct is that
| Nix is on the right path, but there doesn't seem to be much
| awareness or concern for tackling these problems. Of course,
| this is the contributors' prerogative--if they're really just
| interested in making Nix work for the existing Nix community
| (rather than broadening it into the world of mainstream
| software development and operations), then that's all well
| and good. But if they want to appeal broadly they need to
| make some significant changes.
| bionhoward wrote:
| nix is awesome and would make a great addition to windows and mac
| as well, if we all standardize on something like this, we could
| have more reproducible computing environments across dev, prod,
| and fun. also improves security a lot due to software supply
| chain management w/ immutable builds, and could make rebuilds +
| updates far easier and faster
|
| it's a bit esoteric though, the syntax and docs can both improve
| a lot.
|
| my dream machine is qubes host running nixos guests but that's a
| lot to set up and learn!
| lappa wrote:
| Thanks for posting this.
|
| This is a work in progress and definitely isn't at the point
| where, for example, a Ubuntu user with little technical
| background could switch over easily.
|
| As many commenters have pointed out, users will still be
| questioning which options they should change to accomplish a goal
| and will need to use a search engine.
|
| To alleviate these problems, our next major step is "Guided
| Configuration"[0]. This will allow users to select a task (e.g.
| add a user, add a group, configure your desktop environment,
| configure sound, configure bluetooth, etc) and be provided a list
| of options relevant to the task.
|
| Additionally "Recommended Options"[1] will inform users of
| options relevant to their current configuration which they have
| yet to define.
|
| There are a few other smaller changes in the works to help with
| usability, and I'm open to suggestions for how we might continue
| to improve UX and make configuring NixOS intuitive.
|
| Also, if you've used Nix-Gui, please consider filling out the UX
| Survey: https://github.com/nix-gui/nix-gui/issues/129
|
| [0] https://github.com/nix-gui/nix-gui/issues/77 [1]
| https://github.com/nix-gui/nix-gui/issues/21
| trenchgun wrote:
| Exellent! I was thinking of maybe doing this at some point. Happy
| that somebody else is alrady doing it. I might contribute to it.
| [deleted]
| astral303 wrote:
| To call this an interface for " non-technical" users is an utter
| delusion.
| Ericson2314 wrote:
| It should be said it is for technical but non-programmer users,
| "power users".
|
| I don't think it is more scary than dconf-editor or regedit :D.
|
| After this foundation is laid, there's no reason we can't add
| more "tutorial/wizard" flows, just as Microsoft kept revamping
| the Windows "control panel" but kept the old version.
|
| What we can't do is simply drop config options like Apple. The
| Nix ecosystem aspires to be all mechanism minimal policy. If
| upstream exposes the knob, we ought to somehow expose it, at
| least via a free-form textual "extraConfig".
| lappa wrote:
| >After this foundation is laid, there's no reason we can't
| add more "tutorial/wizard" flows, just as Microsoft kept
| revamping the Windows "control panel" but kept the old
| version.
|
| Well put, this is exactly the goal. https://github.com/nix-
| gui/nix-gui/issues/77
| teitoklien wrote:
| People who will even approach tools like this , are never as
| "non-technical" as youre referring to.
|
| Dev has made a great implementation for people who fear the
| terminal. Thanks to this now i can bring more of my friends to
| try tools like these.
|
| I dont think the creator is delusional at all, The non-
| technical in this market is just different.
| zzzeek wrote:
| I keep going to the NixOS website to understand what NixOS is.
|
| it says it's an "OS". I've been in the computer thing for a long
| time and in my experience, an "OS" is the thing that runs when
| your machine first boots up. From this it follows that you can't
| run an "OS" without rebooting a machine (or running it in a VM,
| or whatever).
|
| Yet I go to nixos.org, click "Learn" (let's assume I'm the
| supposed "non technical user") click "install nix".
|
| And what we see is two lines of shell that seems to be starting
| some kind of daemon. I just ran that locally, and it even states,
| it's going to move things around and start a daemon:
|
| - set up the "default profile" by creating some Nix-related files
| in /root - back up /etc/bashrc to /etc/bashrc.backup-before-nix -
| update /etc/bashrc to include some Nix configuration - back up
| /etc/zshrc to /etc/zshrc.backup-before-nix - update /etc/zshrc to
| include some Nix configuration - load and start a service (at
| /etc/systemd/system/nix-daemon.service and
| /etc/systemd/system/nix-daemon.socket) for nix-daemon
|
| is nixos an "OS"? Can I install it on a machine with no pre-
| existing OS booting from a USB stick? would be great if their
| docs could explain if nixos is an "OS" or some kind of runtime
| modification of linux / OSX. (Edit: wikipediaing / googling, it
| looks like you can in fact install it from an ISO, and that Nix
| is basically a linux distribution. I guess it has some kind of
| installer that can "morph" an existing distro into nix? their
| site should be less cagey about basic details like this).
|
| I think if the NixOS site / docs could do a better job, or any
| job at all, of answering this question it would make it more
| clear what exactly it is because I only have a vague idea that
| it's a package manager that rides on top of existing OSes, which
| is great, but the site doesn't make it look like that.
| Ericson2314 wrote:
| The website has decided the best rhetorical approach is to
| describe what the "ecosystem does for you", and thus not talk
| that much about Nix vs NixOS vs Nixpkgs up front. But I think
| that might be mistake. I would lead with:
|
| Nix - package manager / build systems for end-to-end
| reproducibility at scale.
|
| Nixpkgs - Extremely comprehensive package repository built
| using Nix.
|
| NixOS - Linux distribution built around Nixpkgs
|
| Home-Manager - doftfile manager built around Nixpkgs
|
| There are other tools, but they are much more niche, so I would
| start with that. I think that clears up with what you and many
| others have asked, and doesn't "distract from the sales pitch"
| too much.
| easygenes wrote:
| Yes, the wiki takes the opposite approach. See:
| https://nixos.wiki/wiki/NixOS_Wiki:About "The
| NixOS Wiki is a community-run project to document the Nix
| Ecosystem. NixOS is a Linux distribution which is created
| with the Nix package manager as its foundation. NixOS relies
| upon the extensive Nixpkgs package repository, which is one
| of the largest and most up-to-date package sources in the
| Linux world. The Nix ecosystem also includes tools like
| Hydra, for continuous integration testing, and NixOps, for
| deploying NixOS machines to networks and clouds (e.g. EC2,
| GCE, and Azure)."
| Nullabillity wrote:
| It's a bit confusing (and the old site did a better job
| explaining this), but basically, you have two separate
| projects: Nix (a package manager/build system) and NixOS (a
| standalone Linux distribution that uses the Nix package
| manager).
| zzzeek wrote:
| can i use the nix package manager _without_ using nixos? is
| that what the "install" link I referred towards is setting
| up ? my original impression of nix years ago was that oh it's
| a package manager, maybe like the old BSD packagesource
| thing, great. but then "NixOS" came in and seemed to confuse
| things.
|
| all good stuff but wow that website needs to be reorganized.
| [deleted]
| easygenes wrote:
| Yes, I agree it needs to be fixed. I noted this source of
| confusion earlier and appreciate the confirmation. Will be
| working on getting a disambiguation header on the main
| download page soon.
|
| You're on the right track. Nix is a package manager you can
| use on just about any Linux distribution, and also MacOS.
| NixOS is a Linux distro built with and including Nix (and
| using Nixpkgs as its package repo).
|
| Nix is also the name of the functional programming language
| created to describe packages in Nix the package manager.
|
| Nix is also a pun on the word meaning "nothing", which is a
| nod to how it's all purely functional.
| Nullabillity wrote:
| > can i use the nix package manager without using nixos? is
| that what the "install" link I referred towards is setting
| up ? my original impression of nix years ago was that oh
| it's a package manager, maybe like the old BSD
| packagesource thing, great. but then "NixOS" came in and
| seemed to confuse things.
|
| Yes. On the download page[0] you have two sections: Nix
| (the one you were looking at), and NixOS (which is packaged
| as a traditional disk image).
| amarant wrote:
| There is some somewhat confusing naming here, and I believe it
| is the cause of your confusion.
|
| There is a operating system named Nixos. It uses a package
| manager called Nix. The package manager can be installed in
| other operating systems. The package manager is configured
| using a functional language also called Nix.
|
| What you installed was either the package manager, or a
| interpreter for the language.
|
| They could've named these things better IMO
| bogwog wrote:
| Guix (https://guix.gnu.org/) is a similar project, and it has
| the same issue regarding confusing terminology.
|
| I wonder if adoption of these otherwise awesome projects
| would improve if they did a better job with communication?
| trenchgun wrote:
| I don't think it is confusing. There is a package manager
| Nix, and a distro built around it, NixOS. And the package
| repository Nixpkgs.
|
| What is confusing however, is that the configuration language
| and the package manager have the same name, Nix.
| zzzeek wrote:
| in my experience (writing SQLAlchemy) it's good to give all
| of the "<Brandname>" titles a suffix. That is, instead of
| having "Nix" and "Nix OS", you would have, "Nix Package
| Manager" and "Nix OS".
|
| I had *exactly* the same experience with SQLAlchemy. for
| years and years, it was, "SQLAlchemy" and "SQLAlchemy ORM".
| The online discussion was always the same: "ORMs, I like
| ORMs, I dont like ORMs, blah blah blah" and constantly
| trying to say, "SQLAlchemy has a whole non-ORM part too!"
| and this was only vaguely received.
|
| Problem was 90% solved by *changing the name*, introducing
| the new term "SQLAlchemy Core":
|
| SQLAlchemy Core
|
| SQLAlchemy ORM
|
| now when people talk about SQLAlchemy, you will regularly
| see discussions with "I only use Core, not ORM" or "did you
| try that with Core?" There are still people who think
| SQLAlchemy is in its entirety an ORM but it's a vastly
| thinner slice of less engaged users -the path to
| understanding the different components is helped enormously
| by qualifying them all.
| Arcuru wrote:
| I agree, the documentation is not good, but here is the
| explanation of what the different components are:
| https://nixos.wiki/wiki/Nix_Ecosystem
| jbverschoor wrote:
| Better skip the "non-technical":
|
| Nix-GUI: Make NixOS usable for technical users through settings /
| GUI
| tarkin2 wrote:
| I should try to look at the documentation again. But apart from
| the using the package manager, the rest of the documentation
| submerged you in a deep theoretical understanding of nix, going
| deeper and deeper, until the only thing that made sense anymore
| was the respect you gained from the technies who went further
| and somehow managed to use nix.
| pxc wrote:
| Do you feel that way about the wiki, too?
| suchar wrote:
| I think NixOS would benefit from easily accessible collection of
| opinionated modules/profiles/configurations with minimal set of
| options. Something like gnome-desktop / sway-desktop / etc. Gnome
| actually does pretty good job here.
|
| The point is: currently my NixOS and Home Manager configurations
| have over 2k LOC total. When you search for configurations on
| GitHub/Google you are likely to find complex ones. For example,
| quick search for "nixos gnome" (Google) gives me link to NixOS
| Wiki (which describes only Gnome part) and blog post
| (https://gvolpe.com/blog/gnome3-on-nixos/) which is useful but
| links to really huge configuration
| (https://github.com/gvolpe/nix-config) that is overwhelming to
| any beginner.
|
| Great example of such approach is nixos-hardware
| (https://github.com/NixOS/nixos-hardware) which provides one-line
| configuration covering hardware quirks.
| Apaec wrote:
| Home Manager always seems like a unnecessary layer though. Why
| is it needed if you already control everything with NixOS?
| opan wrote:
| It's for the user packages. This way you can keep the system
| profile lean for fast updates of the kernel and such, and
| then update firefox and other things separately. With Guix
| they have had manifests for a while, which are integrated
| into Guix proper and are like the package half of Home
| Manager (not the config stuff). I only keep a handful of
| things installed as system packages, and then I have probably
| 100 or more things in my manifest.scm file. As my user I
| apply this manifest and it will install or remove things as
| needed. No root privileges needed.
| Apaec wrote:
| > This way you can keep the system profile lean for fast
| updates of the kernel and such, and then update firefox and
| other things separately
|
| That makes a lot of sense. Right now a nixos-rebuild is
| really slow for me as I have a big configuration.nix file.
| I guess Home Manager could help in this case, will dig into
| it.
| domenkozar wrote:
| That's the goal of https://nix.dev, you can subscribe for
| future updates!
| Kiboneu wrote:
| Yes, that's how I learned nixos -- moderately on the sparse
| documentation, highly on other people's code. I was shy on the
| #nixos channel.
|
| Now I have a working setup which spans all of my computers and
| servers (I also have autodeployment scripts for aws and
| netboot). I use the devos flake as a template, check this out:
| https://github.com/divnix/devos
| easygenes wrote:
| The NixOS wiki has a good comparison page for templates like
| devos:
|
| https://nixos.wiki/wiki/Comparison_of_NixOS_setups
|
| This is the other big one (most stars):
| https://github.com/hlissner/dotfiles
| jtojnar wrote:
| GNOME is even documented in the manuals nowadays
| (https://nixos.org/manual/nixos/stable/#chap-gnome).
| Unfortunately, Google does not really like single-page
| documentation.
| dmitriid wrote:
| This will sound rude, but I'm more and more convinced that people
| immersed in nix have never seen a real person in real life.
|
| defined boolean expression reference true.
|
| wat.
|
| I'm a technical person, and I have no idea what this is. And for
| technical people? Literally everyone says that "nix is really
| hard to get started with".
|
| nix and nix-related developers, please, please find some real
| people and talk to them.
| otabdeveloper4 wrote:
| You probably don't have a problem that this solves.
|
| I.e., some people still download random zipfiles from the
| internet and install each individual app from a wizard dialog
| onto their Windows 10 machine. They find software repositories
| and package managers confusing and overengineered. I guess
| that's okay.
| forgotpwd16 wrote:
| >They find software repositories and package managers
| confusing and overengineered.
|
| And that's why big distros have created GUIs (e.g. Ubuntu's
| software center) that truly hide any technicalities. Nix-GUI,
| as it's now, will instead be more like Synaptic, it kinda
| makes life easier but you still require technical knowledge
| to use it.
| AnIdiotOnTheNet wrote:
| I don't find package managers confusing but I do, in fact,
| find them overengineered. They solve at most 75% of
| application management problems with the fallback for the
| other 25% being "compile it from source yourself" and it
| takes an army of unpaid third party maintainers to pull that
| off.
|
| In my current estimation, Nix just solves an additional 5% at
| the cost of exponentially more overengineering.
| dmitriid wrote:
| > You probably don't have a problem that this solves.
|
| > They find software repositories and package managers
| confusing and overengineered.
|
| The screenshot is literally a mishmash of technical jargon
| with little to no relation to each other.
|
| sound.enable defined boolean asset resource enabled.
|
| What problem does it solve, exactly?
| amusedcyclist wrote:
| If you think the words software repository and package
| manager are esoteric technical jargon then you don't need
| nix, which is completely fine. But it allows developers to
| identically reproduce builds of a software which depends on
| other software packages. Other package managers may depend
| on some global variables of your system, which nix avoids.
| otabdeveloper4 wrote:
| That's like asking "what problem does apt-get solve,
| exactly, with its technical jargon, when I can always
| download the software I want using Google Chrome?"
| Narice wrote:
| Yeah but here it's the level of jargon that is the
| problem, there is too much! This is a good project for
| sure but it is not ready for new users.
| CJefferson wrote:
| Honestly, that's so patronising I wonder if you are trolling?
|
| I use Debian and Redhat happily, also do plenty of Docker. I
| really want to love Nix and have tried a few times (even
| submitting some package updates), but just kept bouncing off
| it and giving up.
| otabdeveloper4 wrote:
| Good for you. That means you haven't encountered a problem
| that Nix is designed to solve.
|
| (Nix is very much a "worse is better" tool in the tradition
| of hacking something together out of existing tools until
| you a minimal working product. It's designed to solve a
| particular class of problems quickly and painlessly, even
| if the end result isn't "clean" or "elegant". The "clean"
| and "elegant" solutions to these problems are vastly more
| complex and overengineered.)
| CJefferson wrote:
| I believe I have a problem Nix is designed to solve
| (reproducible builds) all the time. However, one can work
| around it with enough pain and suffering on Ubuntu (I can
| write a shell script to download and build the specific
| GCC, GHC, rustc and other packages I need and build from
| source where required), and still find that much easier
| to distribute to my colleagues, rather than having to
| teach them to use Nix.
|
| What else is Nix good for? I'd be interested to know.
| whateveracct wrote:
| Nix allows you to abstract over your shell scripts. Like
| pack those fuckers in a derivation and now people can
| install them with Nix in a uniform way (and compose them
| with their own packages) instead of manually shell
| scripting.
|
| You can even use a single overlay to add a namespace to
| your company's nixpkgs, which will then allow your
| colleagues to discover all the versions of all those
| tools with nix repl >
| pkgs.CJefferson.ghc<TAB>
|
| and boom! All the GHC versions you've worked hard to
| package across branches and repos etc will be at their
| fingertips.
|
| As is always the case with FP, composition and
| abstraction is the big longterm win with Nix. No other
| comparable tool comes close on those axes.
| bsima wrote:
| > defined boolean expression reference true.
|
| "Defined" means the configuration is set, as opposed to unset
| or undefined
|
| "Boolean" is a type, so the setting can be either true or false
|
| "Expression" is the value of the setting, in this case true
|
| "Reference" is a button that opens up the documentation for
| this particular setting
|
| If you keep telling yourself nix is hard then it will be hard
| roblabla wrote:
| I'm a nix fan and have been using nixos for years now,
| packaging stuff and writing my own nix-based libraries, but I
| still find the language to be painful.
|
| The problem is, documentation is sparse to non-existant, error
| messages are poor and often far from the actual problem, and it
| makes use of concept that lots of people are not familiar with
| (like lazy evaluation) without ever explaining them, resulting
| in surprising semantics.
|
| But as far as I can tell, the nix devs are fully aware of these
| issues - they are affected by it too! The problem is, solving
| each of those issues is hard, and requires a lot of focused
| efforts.
| dmitriid wrote:
| nix has been around for _18 years_. If the documentation is
| still sparse after all these years, it 's not a problem that
| will be fixed, ever. Same for explaining concepts.
|
| Proper errors are a huge and poorly understood problem, so
| I'm inclined not to judge those too harshly.
| m45t3r wrote:
| I don't think it is fair to judge a project for the number
| of years its been around, specially for something that is
| really novel and innovative. Nix/NixOS is not a new web
| framework that most of concepts are really clear for
| everyone working with Web. It is a brand new concept for
| Operating Systems, however most people don't have a clue
| about system immutability and reproducibility and why this
| is so hard.
|
| Of course, this doesn't excuse the state of the
| documentation that should be better. It is just that nobody
| ever documented this kinda of things before, so it is
| difficult to do it better.
|
| Nix and NixOS just started to get more known and become
| popular from the last ~5 years or so, and I think this made
| the whole community aware that documentation is an issue
| and it is getting better and better (but maybe not at the
| pace most people wanted).
| TheFreim wrote:
| > The problem is, documentation is sparse to non-existant,
| error messages are poor and often far from the actual
| problem, and it makes use of concept that lots of people are
| not familiar with (like lazy evaluation) without ever
| explaining them, resulting in surprising semantics.
|
| I used NixOS and Home-Manager to run my entire system and
| home directory for a couple weeks earlier this year. The lack
| of clear documentation made me leave. Most of the time to
| find relevant information I'd have to go in some chat room
| since often the "official" documentation would be outdated.
| If the documentation was better I'd probably still be on it.
| georgyo wrote:
| All the official documentation is autogenerated daily. What
| documentation did you find outdated?
| dmitriid wrote:
| Autogenerated documentation !== up-to-date and/or good
| documentation.
|
| Autogenerated means "we take these particular strings and
| texts and dump them in a different format". It says
| nothing about whether they are even remotely up to date.
| georgyo wrote:
| Sure, but in my experience the documentation from the
| source has always been correct. There is tons of stuff on
| other websites that is outdated, but the source
| documentation has not suffered the same atrophy.
|
| More importantly, much of the documentation is auto
| generated not from arbitrary doc strings, but from the
| nix expressions themselves. IE:
| https://search.nixos.org/options?
|
| So I believe there was another source of the
| misinformation then the official docs.
| Narice wrote:
| Most probably NixOS Wiki, it's not official but always
| comes up as the top result because the manual's titles
| are irrelevent when you're trying to solve a specific
| issue. The NixOS Wiki is very helpful in a lot of ways
| (there is more info than in the manuals and you don't
| have to troubleshoot for hours because you missed
| activating some options), butit is true that it is
| sometimes outdated :/
| EE84M3i wrote:
| One example: nix-pills introduces nix-env -i[1] as the
| third "pill" -- isn't this basically deprecated and never
| recommended by serious uesrs?
|
| [1]: https://nixos.org/guides/nix-pills/enter-
| environment.html
| larusso wrote:
| Too that I say look at react hooks. Somehow the React devs
| managed to introduce functional concepts into a framework
| without anyone knowing why or how this black magic trick
| works. At the time of introduction I was heavily interested
| in functional approaches, mainly the solutions from Haskell.
| And now nobody gives a a damn how hooks works in JS only that
| they make the coding somewhat easier and nicer. (I'm no JS
| developer and how no real world view at the current stage
| anymore).
|
| Regarding nix. I love the idea and the project. Tried it 3
| times with various issues which stopped me from using it
| (last time I was not able to compile a rust program because
| of some weird c runtime library which was pulled with the
| wrong version from wherever by whoever). My second bigger
| issue with nix is the fact that you have to go all the way or
| it makes no real sense. Mixing nix with Ubuntu or base arch
| is of course possible. But the developing python or whatever
| whichever means to install and manage the whole toolchain and
| project dependencies also with nix. I still check the project
| every now and then.
| Narice wrote:
| > The problem is, documentation is sparse to non-existant,
| error messages are poor and often far from the actual
| problem, and it makes use of concept that lots of people are
| not familiar with (like lazy evaluation) without ever
| explaining them, resulting in surprising semantics.
|
| Absolutely, that is the major roadblock for Nix/OS in my
| opinion, with the new `nix` command, the documentation is way
| better but the language and OS documentation is still bad, if
| you search for something on a search engine, the top result
| will probably be the NixOS Wiki which is not even official!
| Manuals can come up but the title for the nix manual (not
| NixOS) is "NixOS - Nix 2.3.15 Manual" which is confusing by
| itself but even more so when you're trying to solve a
| specific problem and not just get the manual. Having the
| "NixOS" part at the end for example would already help.
| Having titles for different parts of the manuals would be
| best. However, manuals are single pages except for the new
| nix command manual. That is a truly horrible user experience
| in my opinion... NixOS is however very good in other areas so
| the experience is positive in general but if resolution of
| issues could be faster, it would help significantly. My guess
| is that they will push towards the new manual format, so this
| will get resolved eventually but it will probably take a long
| time.
|
| They are also probably not aware of certain issues like the
| fact that having no roadmap is not great for end users or
| contributors and doesn't create this focused effort that is
| required to solve the issues mentioned. Nix devs seem to be a
| bit too technical which is becoming a problem. If you guix to
| nix, they are much more organized, if you go to their
| homepage and want to contribute, it is very clear where you
| can contribute and how. Another example would be flakes. They
| created quite a hard split in the community between people
| that are using them and people that are not. They have some
| problems sure, but I think they should become standard and
| then be iterated upon. To summarize, the Nix/OS project feels
| to me like it is still treated like a research project with
| no users and few contributors which is not the case.
| forgotpwd16 wrote:
| This GUI started few months ago so you shouldn't be surprised
| it's unpolished. Right now it's the Nix configuration with
| buttons rather text.
| [deleted]
| BiteCode_dev wrote:
| Looking at the GUI, I have no idea what it does.
|
| I'm guessing that you actually need to know Nix to be able to use
| it, which kinda defeats the "usable for non-technical users"
| goal.
|
| I can see the value of it, if I ever learn Nix, and want a quick
| way to make modifications without having to google every
| possibilities.
| whateveracct wrote:
| It literally says what each field does..
|
| Just because it doesn't have an obvious minimal modern UI
| doesn't mean it doesn't do its job. Gotta read I guess .. but
| then again Nix also in general has a prerequisite of "calm down
| and read." But then again, so does Linux!
|
| The only thing you need to do to be Nix-competent is not flip
| the table and blame the tool when you get an error you don't
| understand. (Same goes for Haskell.) That said, my years of
| industry experience has shown that that is a rare attribute -
| doubly so amongst those with experience and therefore egos.
|
| People in this thread act like Nix users are out of touch.
| Maybe, but I'd rather be out of touch and learning than grumpy
| that I had to read.
| dmitriid wrote:
| > Make NixOS usable for _non-technical_ users through a
| settings / package management GUI.
|
| ^ emphasis mine. What _exactly_ does a non-techical user have
| to read to understand whatever 's on the screenshot? Forget
| non-techincal, explain this to a _technical_ person.
|
| Apparently this has something to do with sound? Have you or
| any nix-person ever seen a sound configuration screen for
| non-technical users? I mean this one is by no means perfect,
| but do compare: https://www.techrepublic.com/a/hub/i/r/2016/1
| 0/05/a7dba7dd-3...
| whateveracct wrote:
| KDE provides that already in NixOS. So yeah .. we do see it
| all the time :)
|
| This config is for a different layer - one a non-technical
| user probably wouldn't ever modify in most OSes. Hence, the
| value.
| Zababa wrote:
| This is exactly the same, although their choice of "sliding
| buttons" with text and color inside is a bit weird compared
| to checkboxes.
| seoaeu wrote:
| What? They're nothing alike. One has normal, logical
| options like selecting sound effects and output devices.
| The other has useless things like how much the media keys
| adjust the volume by and whether to entirely disable
| sound on the system, and is littered with technical
| jargon like 'undefined' and 'boolean'.
| whateveracct wrote:
| You don't select your output device with your
| configuration.nix. You use it to configure the underlying
| OS. So doing this stuff with a GUI? Unheard of in the
| mainstream. Unnecessary maybe too, but still. Not the
| same.
| Ericson2314 wrote:
| You can be "grumpy you had to read" or "grumpy about other
| being complaining they have to read". You chose that latter
| and I think it's a good choice :).
| Zababa wrote:
| > I'm guessing that you actually need to know Nix to be able to
| use it, which kinda defeats the "usable for non-technical
| users" goal.
|
| I don't think that's true. Excel is usable by non-technical
| users. Part of it is due to the GUI, part of it is due to the
| easy packaging. But you still need to know spreadsheets to use
| it. This project does the same for Nix.
| kaba0 wrote:
| Is it? There would not be several courses on it otherwise.
| Zababa wrote:
| There's a difference between "usable" and "having a deep
| knowledge" I think.
| lappa wrote:
| Unfortunately Nix-Gui hasn't yet achieved it's tagline.
| Hopefully https://github.com/nix-gui/nix-gui/issues/77 letting
| users configure a predefined list of options relevant to
| completing a task will bring us closer to that goal.
| exdsq wrote:
| Having worked in a large Nix dev environment, the difficulty in
| understanding what was going on meant devops were needed for the
| simplest changes. Ended up being a blocker for every project I
| was on. Love the idea but really really dislike it in practice.
| NixOS is cool though.
| amusedcyclist wrote:
| Also having worked in a large Nix dev environment, I find it
| quite intuitive to use and the reproducibility is a great way
| to ensure your bugs aren't caused by an incorrectly set
| environment variable or something random like that. It does get
| a bit annoying when you need a package not available in nixpgs
| but thats true of any build system
| Ericson2314 wrote:
| This is the type of costs-and-benefits "it's not for me" I can
| get behind.
|
| (I left another comment about as a Nix user I don't mind it not
| being popular, but I do mind people complaining about the costs
| and ignoring whatever benefits might lie on the other side, as
| if all technology is reducible to its learning curves.)
| abathur wrote:
| With the naivety of someone who's never worked in _any_ large
| dev environment: I would guess for that to work (at this point,
| at least) every team would need either someone who knows Nix on
| the team, or at least on-demand access to someone floating?
|
| I feel like ~proficiency with Nix has is a bit of a superpower
| as a developer. It's an incredible lever. But I have no
| delusions about how hard some "easy" things are, especially
| around language ecosystems with their own package managers. And
| learning it is a good bit of work.
| easygenes wrote:
| Shopify is a shop with about 1000 developers who use Nix on
| MacBooks. Here's a video on one of their internal tools which
| is basically just a bit of chrome on top of Nix to run
| anything without installing it: https://youtu.be/VUM3Km_4gUg
| exdsq wrote:
| Yeah the env I worked in was managed by some of the core Nix
| devs so they went in 100% and used all of the cutting edge
| features. It ended up being utter magic to me and most others
| I know. Tens of thousands of lines of Nix code so trying to
| add a library to the build was practically impossible, some
| of the code was hidden in private repos because it was
| confidential etc but other repos imported it... gah!
| ris wrote:
| I think one of the reasons it feels like this is with Nix,
| the guts of what people are setting up are all exposed,
| right there in robust code. You see what's going in to the
| sausage.
|
| In comparison, I've worked in projects which distribute
| their components as .deb packages, and the difference is
| night and day, the latter being a nightmare of laborious
| manual steps and funny tools. To a user of a .deb file this
| is all opaque, but let me assure you the complexity is most
| certainly there in spades.
| ElonMuskrat wrote:
| This matches my experience.
| xyzzy_plugh wrote:
| A lot of odd Nix hate in here, or at least extreme dislike.
|
| NixOS is so very usable. There are a lot of foot-guns but that's
| true of Linux systems.
|
| It takes some time to get comfortable with all the different ways
| to configure stuff. There's a new language, a new build system, a
| new Linux distribution.
|
| I've spent very little time relative to say, figuring out dpkg or
| systemd, or learning Bash or C or Perl, or learning the Linux
| FHS.
|
| NixOS makes running deterministic systems driven from a single
| configuration incredibly easy.
|
| Nix the language and tools allow you to build software
| deterministically and create environments where that software is
| available (e.g. on $PATH).
|
| Nix Flakes is an experimental feature aimed at bringing
| reproducible and hermetic configurations of dependencies into the
| fold (i.e. lock files, ala Gem or Cargo or Go Modules).
|
| Nix-the-tool's interactive "package manager" should be
| deprecated, as it's a huge pitfall for most developers. But it
| works and is frankly a good first step for folks coming from Apt
| or Homebrew.
|
| Learning to write modules is probably the steepest learning
| curve, but compared to learning how to build RPMs or Dpkg or Brew
| recipes, it's really not bad at all. I actually find it _easier_
| and I 've been at this for less than a year. Sure, if you're
| trying to get something working no one has figured out yet you
| may be in for a pickle, but that feels like it's always been
| true. The difference is a lot of software breaks and bends the
| rules and boundaries constructed to keep things and people sane.
| Nix does not allow that, generally, which is a very good thing.
| Fixing other people's garbage is the bane of any package system
| maintainer, it's no different here.
| throwaway894345 wrote:
| I haven't used full-on NixOS yet, but I've used the Nix package
| manager quite a lot, and literally all of my forays have been
| miserable for a variety of different reasons.
|
| To be clear, I love what Nix _aspires_ to be, but it doesn't
| deliver on its promises IMO.
|
| As a package author, the Nix language has lots of rough edges,
| it's absurdly tedious to figure out how to call various
| functions (what type of argument does it expect?) because it's
| untyped and nixpkgs is poorly documented. There are too many
| other issues here to unpack.
|
| As a consumer of packages, it's often unclear what I need to do
| to install anything but the simplest packages. E.g., installing
| vs code with some plugins (note that this differs between NixOS
| and other systems). Further, the CLI interfaces are confusing
| from a UX perspective IMO, and it's often unclear what I
| actually need to use Nix well (homemanager? flakes?) the
| guidance is confusing and contradictory.
|
| So I don't _hate_ Nix, but I do have a lot of constructive
| criticism.
| openfuture wrote:
| There's always guix...
|
| Using scheme for everything is great, for showcase and recent
| developments check this video on guix home
| https://www.youtube.com/watch?v=R5cdtSfTpE0
| easygenes wrote:
| Just note Guix is a GNU project so there's no support at
| all for anything unfree.
| SkyMarshal wrote:
| There's no official support for non-free but the GUIX
| community has created a number of channels for non-free
| packages. I believe this is the main one:
|
| https://gitlab.com/nonguix/nonguix
|
| More if you google "GUIX nonfree".
| cyberbanjo wrote:
| Yes, but you won't likely find help for NonGNU software
| in the offical GNU Guix channels, IIRC they have a banner
| on their libera.chat that says you shouldnt be asking for
| help with non-free software here.
| easygenes wrote:
| The wiki has pretty good coverage of managing vscode
| extensions: https://nixos.wiki/wiki/Visual_Studio_Code#Managi
| ng_extensio...
| forgotpwd16 wrote:
| >So I don't hate Nix, but I do have a lot of constructive
| criticism.
|
| Why not write a blog post? Probably some of those issues are
| known but no one works on them, so a reminder isn't bad. And
| for those that aren't, maybe someone picks it up and tries to
| fix it.
| throwaway894345 wrote:
| That's not a bad idea. I'll toss that on the queue.
| SkyMarshal wrote:
| Also considering posting your ideas to the Nix forums or
| possibly github issues, lots of activity there and you'll
| probably get some good feedback before publishing.
|
| https://discourse.nixos.org/
|
| https://github.com/NixOS/nixpkgs/issues
| easygenes wrote:
| The UI for Nix has been under significant rework over the
| last ~3 years, but the new UI isn't ready for primetime yet,
| so none of it is made prominent now. It's getting there
| though.
|
| You can have a peek here:
| https://nixos.org/manual/nix/unstable/command-
| ref/experiment...
| throwaway894345 wrote:
| That's good to know. I hope they really nail it!
| KronisLV wrote:
| > A lot of odd Nix hate in here, or at least extreme dislike.
|
| I don't have any doubts about the likes of Nix or even other
| attempts at improving the reproducibility of building and
| installing packages being technically superior to what we have
| now in some ways.
|
| But at the same time, you can't forget about people and in some
| ways the industry taking the path of least resistance whenever
| possible.
|
| You want to introduce a good but somewhat complicated way to
| manage packages? People will simply use "apt" while its
| UI/UX/DX is easy to get a hang of.
|
| People get sick of differences between environments and how
| hard it is to deal with everything from resource constraints,
| port binding, configuration management, persistent data
| handling etc. in *nix? Many of them will turn to shipping VMs,
| tools like Vagrant or more recently - Docker.
|
| Thus, it stands to reason that for any tool to become popular
| amongst the "common folk", not just brave early adopters or
| very technically able people, the tool needs to be easy to use.
|
| I guess that's also why i'd say that more people use Linux
| distros (GNU or otherwise) as opposed to something like the
| *BSD OSes, even if those also have some notable benefits in
| regards to stability, networking performance, in-tree
| development etc.
| Ericson2314 wrote:
| Nix is common among consultancies because the more _switching
| between projects_ you do, the more it pays off. If you like
| every 6 months (or merely every job change!) fuck with APT,
| your bashrc, etc. with a little stack overflowing during
| onboarding, whatever. It 's too rare to be worth optimizing;
| I get it. If you switch projects every 2 weeks, the calculus
| changes greatly.
|
| I do work at one of them now, but I got into Nix as a student
| hobbyist, when I was also rotating through homework
| assignments and personal projects quickly.
| KronisLV wrote:
| > Nix is common among consultancies because the more
| switching between projects you do, the more it pays off.
|
| I feel like this is perhaps situational? I am yet to see
| Nix be used once in about 5 years of development in many
| projects in Eastern Europe, both governmental in private
| sector.
|
| Though maybe the industry here is lagging behind trends -
| only in the past 3 years or so Docker has started gaining a
| foothold and even large corporations are just figuring out
| how to run their own Kubernetes clusters and Docker Swarm
| is still in use in some places, or even just Docker
| Compose.
|
| Then again, some of these projects don't even have systemd
| services in place to ensure that they can be controlled
| easily, so who knows... Manually launching Tomcat or
| GlassFish instances never inspires confidence.
| Ericson2314 wrote:
| > I feel like this is perhaps situational? I am yet to
| see Nix be used once in about 5 years of development in
| many projects in Eastern Europe, both governmental in
| private sector.
|
| Hah!
|
| Nix is super European, and from my American vantage point
| the more west you go, the fewer Nix users there are! I
| first learned of the whole Eastern Europe consulting
| phenomenon via the Nix community too.
| easygenes wrote:
| Yeah, good points. Nix has been as-yet very pointedly a
| developer-centric ecosystem. And not just that, but
| developer-centric for people who favor functional programming
| in general.
|
| There's some work especially in the last few years to make it
| all more approachable, but that's the background. Wait a
| couple more years and you will see more projects like Nix GUI
| here start to mature and then it will get very interesting
| beyond people who have backgrounds in, e.g. distributed
| computing and Haskell.
| WastingMyTime89 wrote:
| I have no opinion about NixOS but every time I read someone
| touting its merits I feel like I live in a parallel universe.
| NixOS seems to solve problems I never had at extreme costs to
| its general usability.
|
| I don't care that I can rebuilt a computer identical to mine in
| minutes. I don't change computer often enough for it to matter
| and the tweaking I do is minimal because frankly tweaking
| configuration is not fun and feel like a gigantic waste of
| time. Same things for reproducible builds, I like them as a
| developer for the things I work on because they make things
| easier to manage and debug. I couldn't care less as a user. I
| just want things to work.
|
| I guess it could make sense for servers as an alternative to
| provisioning tools but then it seems to me like it's competing
| with docker and kubernetes and I have never seen a convincing
| argument about why it would be better.
|
| I think that's why you see a lot of things you view as dislike.
| Plainly speaking I think most people don't see the point.
| xyzzyz wrote:
| > I guess it could make sense for servers as an alternative
| to provisioning tools but then it seems to me like it's
| competing with docker and kubernetes
|
| It's not competing, it's complementing. Think of it as a
| fully deterministic "docker build".
| WastingMyTime89 wrote:
| Yes but << docker build >> already exists and can already
| be made deterministic so it's indeed somewhat competing.
| Would anything be easier by using Nix?
|
| Right now it seems to me like a large ordeal with little to
| no benefits and my interaction with the Nix community
| hasn't been very convincing. A lot of Nix users seem to
| believe determinism and reproducibility of everything to be
| enough of a justification in itself. I don't think it's
| worth the pain.
| bergkvist wrote:
| The biggest limitation of using Docker for building
| images is that it does not allow for composition. You
| can't simply say you want to combine a Python and Rust
| image for example.
|
| With dockerTools from nix
| (https://nix.dev/tutorials/building-and-running-docker-
| images), this kind of composition is easy. You also end
| up with significantly smaller image sizes - containing
| only exactly the dependencies needed for the image to
| work, which is also good from a security perspective -
| since it decreases the attack surface.
| ris wrote:
| > << docker build >> already exists and can already be
| made deterministic
|
| Truly deterministic Dockerfiles are a rare thing to find
| among the ecosystem.
|
| And we haven't even got into docker's poor support for
| unprivileged container building which leads to weird
| solutions using dind when you need to build an image from
| inside a container..
| dgb23 wrote:
| Two examples to get a taste of the tradeoffs and utility it
| provides would be postgrest and IHL.
|
| I think it's sexy. But like you I haven't had the time to
| really dive into it and understand it. The promise is
| simplification, both operational and in terms of the runtime.
| capableweb wrote:
| > it seems to me like it's competing with docker and
| kubernetes and I have never seen a convincing argument about
| why it would be better.
|
| This seems to indicate a huge mismatch between what you think
| Nix/OS is compared to what it actually is. NixOS is for
| creating/maintaining systems, Docker is for running
| applications and Kubernetes is for running applications but
| across multiple servers, neither of those tools are like the
| other really.
| Azsy wrote:
| The market you compete in is the market your users imagine
| you offer similar solutions. Not the market of how you
| describe yourself.
|
| Docker's features usually include "its easier to create and
| maintain a system".
|
| That Nix does this different and better doesn't matter when
| a user is just looking to solve that one problem.
|
| At that moment, for that user, Nix is just a fancy config
| manager with one click deploy features and competing with
| docker.
| capableweb wrote:
| Again, misunderstandings seems to run rampant in this
| thread...
|
| No, Docker doesn't maintain systems, it handles
| applications. No one runs systems inside of Docker.
| People run applications with Docker, and Docker itself
| runs on systems.
|
| And no, Nix doesn't "do this differently and better", as
| what Docker does and Nix does is wildly different. Nix is
| for machines, not applications. Sure, a subset of
| features from Nix can be used like Docker, but that
| doesn't mean Nix and Docker is the same, no matter what
| you think of markets or whatever.
| _red wrote:
| I think what the parent is alluding to is: What is the
| practical point of using Nix when similar outcomes can be
| reached with more mainstream solutions? In other words,
| suppose I want to deploy a web app that depends on Nginx,
| PHP, and PostgreSQL.
|
| I could:
|
| (a) Run all as docker-compose type solution
|
| (b) Run all as scripted Nix solution
|
| (c) Install packages manually on general purpose OS
|
| Lets ignore "c" for the moment as the goal is to avoid
| that exact scenario. Given the prevalence and widespread
| support for "a" why should sysadmins choose "b"?
| capableweb wrote:
| I don't understand how you can use docker-compose,
| docker, Kubernetes or anything else to achieve the same
| thing as NixOS. NixOS gives you a fully reproducible
| personal computing system, from boot config, window
| manager, partitioning to applications, home directories
| and everything in between.
|
| What mainstream options are available for doing this?
| Guix could be one option, but it's not mainstream so I'm
| not sure what tools you are referring to.
| mixmastamyk wrote:
| And why would someone want that? Sure it sounds
| theoretically nice, especially if I was still working in
| IT. But learning another system with a poor ui has a
| large cost for a theoretical benefit.
| stjohnswarts wrote:
| Eh you can do the same thing (or close enough) with a
| bash install script on a "stock" linux system and then a
| docker set up with the applications that that you want.
| Or with ansible. it really depends on the end goal. Not
| everyone needs every single bit to be the same. Or you
| can just image a drive. It depends on the end goal and
| often multiple solutions will get you there.
| ris wrote:
| These are the nasty solutions I have to deal with at work
| all the time and my entire job consists of handling
| things when the "quick" bash cloud init script that
| someone wrote and various people have made additions to
| over the years goes wrong.
|
| Bash scripts fail at this task because they are generally
| not convergent. Ansible makes a basic effort at being
| convergent, but most of the scripts I've seen are
| extremely naive about the ways in which a configuration
| can diverge.
| _red wrote:
| moreover, you can also use docker digest instead of tags,
| that is: instead of _docker pull postgresql:11_ you can
| do _docker pull postgresql@sha:xxxx...._
| porker wrote:
| You are talking past the comment that you replied to, and
| you haven't answered it.
| pxc wrote:
| Nix _is_ (a) and (c), depending on how you want to use
| it. What differentiates it from docker-compose or `dnf
| install` isn 't just the fact that you can ship something
| in containers or install some packages but also the
| various properties those containers or packages inherit
| from the build system.
| ducktective wrote:
| I guess the nix way would be more performant because it
| does not need layers of OSes
| Ericson2314 wrote:
| I would argue Docker and Kubernetes are a bunch of crap
| popularized by people lulled into blowing all their money
| to cloud providers and compelled out of envy to imitate
| big tech -style deployments, even though it means taking
| on extra problems you absolutely don't need to deal with.
|
| Also, Docker and Kubernetes are...just more layers. There
| is no cleaning up what came before. The Nix ecosystem is
| about drilling all the way down and cleaning up the prior
| tech debt. It's a fundamentally different approach.
| WastingMyTime89 wrote:
| > Docker is for running applications
|
| Yes but no. Docker is mainly used for its ability to build
| and reuse standardised containers. It's very much a
| distribution mechanism (I mean that's why it's called
| docker). From other comments I get the feeling that NixOS
| could be used to build reproducible containers in a way
| that remind me of building tools like Bazel but it's not
| entirely clear to me why you would chose to do that nor if
| it's actually a goal of the product.
| jbboehr wrote:
| > NixOS could be used to build reproducible containers
|
| You absolutely can build docker images using Nix via
| dockerTools.buildImage [0].
|
| [0]: https://nix.dev/tutorials/building-and-running-
| docker-images
| easygenes wrote:
| Docker and Kubernetes are almost strictly a subset of the
| power within the Nix ecosystem.
| Ericson2314 wrote:
| The "market" for Nix is honestly OCD people that care about
| the software production process --- "god willing" our
| fastidiousness will eventually pay off as everyone else
| slowly boils in "accidental complexity", and our decisions
| finally make sense to others. In the meantime, it's hard to
| convey the benefits.
|
| For now, I argue there is surprisingly little business case
| to care about developer efficiency --- VCs _want_ you to blow
| cash, and increased developer outsourcing with remote work is
| covering the stupid complexity costs the cloud imposed.
| Mainly, businesses are _demand constrained_. That there is
| tons of embarrassing supply chain issues rights now is to me
| in accordance with this. America has gotten really good at
| advertising and customer acquisition, but we 've lost skills
| at actually doing the basics, as it is really easy to service
| whatever demand you can scrounge up.
|
| So far now, you either really want a clean workbench, even at
| the cost of dealing with the complexity that cleanup exposes,
| or you don't. That says whether Nix is or isn't for you.
| [deleted]
| grawp wrote:
| Nix(OS) purely with Flakes i.e. without channels is so f good
| that I'm not using it just as my daily driver on a PC and to
| package software and create development environments...
|
| I also replaced Buildroot with it for building embedded images
| for SBCs. Lifechanging experience.
| Ericson2314 wrote:
| Thanks you too, I think this has actually been the thread with
| the least sloppy Nix hate yet!
| tinco wrote:
| Crazy thing about NixOS is that it's so good, all the bad parts
| can be excused. I like to go on forums and complain about how
| the Nix configuration language is horrible, and there's not
| much documentation on how to get general things done.
|
| But that said, I'm still running NixOS on my servers. And no
| way that I'd ever go back to old fashioned provisioning scripts
| like Ansible.
|
| Just yesterday I had a problem upgrading a machine that's been
| running for 3 years without updates, and it wouldn't upgrade to
| the latest version of NixOS because of some certificate issue I
| couldn't figure out. Tried a couple things, nothing worked,
| gave up and destroyed the box. Installed the latest version of
| NixOS on it, pulled my configuration from git and it's back
| online exactly how I want it.
|
| It runs 5 websites in docker containers with a reverse proxy
| that automatically gets its SSL certificates from Let's
| Encrypt, some other services, and a tmux session with irssi.
| Everything neatly managed by systemd through unit files,
| everything set up from one simple nixos configuration.
|
| If I'm complaining about NixOS, it's because the best server
| operating system in existence right now has flaws. Not because
| I'd ever go back to a traditional linux distribution.
| m45t3r wrote:
| > Crazy thing about NixOS is that it's so good, all the bad
| parts can be excused. I like to go on forums and complain
| about how the Nix configuration language is horrible, and
| there's not much documentation on how to get general things
| done.
|
| I don't think it is fair to say that Nix as a programming
| language is horrible, IMO, as a DSL it is pretty good and
| fits the domain well.
|
| It is a strange language at first and it takes some time to
| learn all its quirks. Also, it lacks better tooling, things
| like LSP for example (there is one but it is slow and limited
| last time I tried). But just claiming the language is
| "horrible" is really unfair.
| whateveracct wrote:
| The Nix language is excellent imo
|
| Better than so many I use professionally
| mindslight wrote:
| The semantics are great and necessary for Nix, but the
| syntax sucks. But syntax is the Afghanistan of programming
| languages, and all that.
| easygenes wrote:
| rnix-lsp is decent these days: https://github.com/nix-
| community/rnix-lsp
| m45t3r wrote:
| This is exactly what I meant with "there is one but it is
| slow and limited last time I tried", but it does seem
| that they made good progress (the last time I tried it
| was some months ago).
|
| Time to try it again.
| m45t3r wrote:
| BTW, thanks @easygenes. It is really much better nowadays
| (that goes to show how fast Nix/NixOS is improving).
| eximius wrote:
| I think it's fair. It is, by far, the biggest hurdle to
| adoption and contributions.
|
| I'm a SWE and I don't grok it yet.
|
| Granted, I haven't spent a _ton_ of time on it. But if you
| have to spend a ton of time on it, it has in some sense
| failed.
|
| It's harder to learn than literally any other language I
| can think of that isn't designed specifically to be
| esoteric. Most languages, after you have picked up a few,
| you can just glance at and you've got the basics. Nix is
| its own beast entirely.
|
| Edit: I do acknowledge that there is some difficult to
| manage inherent complexity. And, like many others, I love
| what Nix is trying to be. But I do think improving the
| language would be a big step.
| ris wrote:
| > I'm a SWE and I don't grok it yet.
|
| I think the biggest difficulty most people have is that
| it's a pure functional language, and that is quite
| foreign to a lot of people, even many SWEs.
|
| It's something that's not going to change though because
| it's a fundamental part of why Nix works so well.
| easygenes wrote:
| Yeah, I'm just waiting for Jeff Geerling to get onboard with
| Nix. Then things will get interesting (he's a big Ansible
| buff and probably the biggest RasPi Youtuber).
| vlunkr wrote:
| The fact that instead of upgrading, you had to wipe and
| restart doesn't seem like a very compelling argument for
| NixOS.
| exitheone wrote:
| I think the important thing that did not come across very
| well is that "wipe and reinstall" with nix is so incredibly
| painless that doing it is even an option. The same would be
| very very painful with other distributions. A clean
| reinstall of your whole system with nixos takes maybe 30
| minutes. Compare with the average "my Ubuntu upgrade
| failed" debugging session...
| easygenes wrote:
| Yes, and speaking of... the fact that "generations" are a
| central feature which allows seamless rollbacks to
| previous system states means that if your upgrade fails
| you're hardly ever more than a few minutes away from a
| functional system again.
| bogwog wrote:
| I disagree. I don't use Nix, but I've been in situations
| before where an upgrade either couldn't complete, or
| catastrophically broke something. Those situations are
| horrible and can take hours or days to resolve.
|
| Having the option to say "fuck it" and just reinstall
| everything, without worrying about manually installing
| exact software versions and reconfiguring everything sounds
| amazing.
| kvark wrote:
| Wait, isn't a point of NixOS is that your updates are
| guaranteed to be smooth? I haven't used it, but your story
| now worries me. I don't want to be back at "just reinstall
| the OS" days, even if configuration is portable.
| 0xCMP wrote:
| With a cloud server it's obviously less of an issue, but
| even with a desktop for Nix its less of an issue than any
| other distro.
|
| Each time you update your configuration it's essentially
| reinstalling. When you boot you have the option to boot the
| previous version (which includes previous app versions and
| etc).
|
| Reinstalling NixOS and updating it are extremely similar
| actions except for full reinstalls having data loss
| (formatting) and taking longer (cache is empty).
| tinco wrote:
| On NixOS installing any package is the same as reinstalling
| the operating system. Reinstalling the operating system
| just took a minute longer because it had to do more
| downloading. (edit: in theory, I actually bet that the
| certificates sneakily leak mutable state into the system
| with the expiry process, i.e. I bet that if I reinstalled
| the same version of NixOS with the same configuration, I'd
| get an install that would actually be able to talk to the
| nixos package servers)
|
| But you're right to be worried a little bit, and this is
| exactly why many people criticize NixOS. In theory it's the
| most perfect operating system, but in practice it's so
| complicated that when something's bugged it's really hard
| to figure out how to recover, and the documentation is not
| up to the task of educating you on what to do when things
| are wrong.
|
| Also this situation was a bit special because it couldn't
| talk to the NixOS servers for upgrading (I presume due to
| an expired root certificate, but I couldn't figure it out),
| if it was any other problem, I could simply roll back the
| upgrade process (which would be instantaneous because it
| doesn't actually remove the old packages when you upgrade).
| Ericson2314 wrote:
| > And it wouldn't upgrade to the latest version of NixOS
| because of some certificate issue
|
| This sounds like Lets Encrypt changing it's protocol. Nix
| itself doesn't give a shit about such things, but maybe
| some sort of script was supposed to double-check the cert
| on boot (just speculating). While NixOS can be
| reproduciable, whatever software Let's Encrypt runs is
| obviously outside the host's control, so perhaps "leap-
| frogging" to the latest NixOS somehow helped.
|
| This is incidentally a good example at why I am pretty
| against microservices (not saying Let's Encrypt is a bad or
| a microservice, but it is the analogue of one in this
| parable).
| tinco wrote:
| I couldn't figure out what it was, but it was definitely
| a problem with NixOS itself, possibly with expired root
| certificates or something like that. The upgrade command
| couldn't connect to the nixos servers. I know there was
| at least one root certificate that expired in the past 3
| years, so maybe I just caught a bad interval for not
| upgrading.
| deltasixeight wrote:
| > A lot of odd Nix hate in here, or at least extreme dislike.
|
| I hate this expression. I'm a nix user. But if you can't
| understand why people dislike it... you're the one that's odd
| and out of touch.
|
| If you want people to adopt nix the worst way to convince them
| is to call their behavior odd when it isn't.
|
| The reason why adoption of nix is so low is trivial. High
| initial learning curve and it's so different from everything
| else that's out there. The only reason why I got over that
| learning curve is because my company uses it. If it wasn't for
| my job I would not have have the will power to climb over that
| learning curve.
|
| Like seriously can you not see that someone is not willing to
| spend months learning nixos when they can get a pretty much
| from point A to point B using a turn key solution like ubuntu?
|
| Nix is great. But you need to climb over the initial hump. That
| is all.
| Ericson2314 wrote:
| What we dislike is everything talking about the costs, and
| not the benefits. Fine if it's not for you --- I personally
| care more about institution and upstream adoption than
| getting more random end users at this point --- but people
| passing off these one-sided cost-and-no-consideration-of-
| benefits analyses as engineering decisions is a bit grating.
|
| To me Nix is hard, but Nix is worth it. I acknowledge these
| people's pain, now would they acknowledge my pleasure
| (ideally without writing it off as that of a cult inductee!
| :)).
| m45t3r wrote:
| > What we dislike is everything talking about the costs,
| and not the benefits.
|
| Exactly. I tried to push really hard our company to use
| Nix/NixOS (and maybe in our case nix-darwin too, since the
| majority of engineering uses macOS), but it never went
| anywhere (I did convert a few of my colleagues to use NixOS
| though).
|
| But why? Well, onboarding is a pain in my company. We have
| some Ansible scripts that always break in some innovative
| ways, so it takes a whole day to setup a new machine for a
| bunch of engineers. Sure, partly of the fault is the fact
| that our Ansible scripts are really hacky (in some steps
| they still call some Bash scripts instead of using Ansible
| DSL for example), but Ansible is simply lacking in some
| places to have a really pleasant experience.
|
| If we could use NixOS though, this would be a very
| different matter. I use NixOS in the same company, had the
| same configuration for pretty much 1 year, and also
| survived a broken laptop and setup my whole setup in like
| 30 minutes (most of time spend downloading packages
| actually). I even separated part of my NixOS configuration
| in another repository so other engineers using NixOS can
| also make use of it.
|
| Yeah, it took a long time to get where I am currently, but
| nowadays I just stopped worrying about managing system,
| system update breakages, and anything like this. I can just
| use my system, fully up-to-date, and I know if something
| breaks, I can revert. It is beautiful.
| Ericson2314 wrote:
| Yeah I ended up working at a place that was already using
| NixOS -- as in developer laptops come with NixOS, and
| that was definitely a huge plus. Much nicer when the war
| is already won, and there is no class of macOS or
| Windows-using devs to appease!
| whateveracct wrote:
| > But if you can't understand why people dislike it... you're
| the one that's odd and out of touch.
|
| Oh I know by now why people dislike it. I've worked for years
| with it with engineers of all stripes. It's always big heads
| and bad attitudes and never Nix itself.
|
| And Ubuntu isn't a turnkey solution to what people use Nix
| for lol.
| totony wrote:
| I have went pretty deep in nix recently and imo the "Fixing
| other people's garbage is the bane of any package system
| maintainer, it's no different here" + high learning curve +
| lack of xattrs and permissions support in nix store makes it a
| bad OS. The amount of custom code to fix "issues" and "issues"
| that are only fixed because the maintainer thinks he knows
| better than the dev is too big to be maintainable. Still a good
| package manager for eg macOS if you dont need that.
| Ericson2314 wrote:
| > Fixing other people's garbage is the bane of any package
| system maintainer, it's no different here.
|
| I honestly think it's hard for "Nix to Nix" simply because by
| trying to make everything reproducible, it is dealing with
| more of upstream's garbage, and "reifying" the hoops that
| people jump through doing sysadmin things in code looks
| scary.
|
| I really want more upstream developers to use Nix, so they
| might loose their myopia, and start thinking of the the FOSS
| ecosystem as a whole, and not just their own packages within
| it. Nix is the best way to get the bird's eye view, I am
| sure. Just try not to gag at what you see!
|
| [1] Though I still maintain that contributing to Nixpkgs is
| much easier than contributing to e.g. Debian or Fedora.
| totony wrote:
| Reproducibility is not the only issue they're facing. I
| think the mentality extends to more than just fixing linker
| issues, e.g. this
| https://github.com/NixOS/nixpkgs/issues/9656
|
| At the end of the day, I much prefer trusting upstream than
| having to trust packagers to do everything right.
| Ericson2314 wrote:
| Fair, but at the same time, "setuid" is a war where
| everyone looses, IMO :).
|
| Since the issue was first closed, there are some
| solutions for NixOS that I hope for discoverable. For
| Nixpkgs alone, I really don't think see any solution that
| is both secure and ergonomic -- setuid is bad.
| totony wrote:
| Setuid has been replaced by capabilities, but nix faces
| the same struggles it has for setuid (only supports it
| through a wrapper, and that was after a "wontfix"
| according to the bug tracker).
|
| More than that though, the mentality that you can just
| patch away critical features (like setuid) without
| telling the user is imo unhealthy for an OS.
| easygenes wrote:
| Yeah, exactly. Nixpkgs is basically the largest and most up
| to date repo in the Linux world now. Most of that's coming
| just from the small existing core community. That has to
| say something for the efficiency of it.
| vegai_ wrote:
| As usual, those who have learned Nix have completely forgotten
| what was difficult about it in the first place. And those who
| haven't are so confused that are unable to ask good questions.
| solarkraft wrote:
| Sounds like a concise description. All Nix people I met say
| ,,bro it's so simple" while the docs throw around 20 different
| concepts, multiple of which seem to be the same thing, but not
| really, but really you may want X in case you want to do Y but
| sometimes not except usually you do but well actually it'll be
| replaced in a few months (...)
| 3np wrote:
| Hey, just go through this 20-page tutorial series and by the
| end you may be able to transfer that experience to that one
| ruby package with a particular native dependency you just
| want to build right now.
|
| https://nixos.org/guides/nix-pills/
| throwaway894345 wrote:
| Another aspect is that the Nix experience varies widely
| between languages, in part because of different levels of
| support for different languages but also because different
| languages' build and runtime systems vary with respect to
| how easily they map to Nix. So your friend who heartily
| recommends Nix might have had a decent experience with his
| Haskell projects, but you and I working in the trenches
| with Python or Ruby are having a miserable time and
| everyone who told us Nix was great just kind of shrugs and
| chuckles as they tell us they don't know how to solve our
| problems with Nix.
| abathur wrote:
| Ian Henry has, thankfully memorialized the learning process so
| that we can all readily rediscover it.
| https://ianthehenry.com/posts/how-to-learn-nix/introduction/
___________________________________________________________________
(page generated 2021-10-10 23:01 UTC)