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 learnin…
Nix-GUI: Make NixOS usable for non-technical users through settings / GUI
141–150 of 206 posts
Re: Nix-GUI: Make NixOS usable for non-technical users through settings / GUI
#142Earlier quoted context omitted.
> 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 every…
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…
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.
Re: Nix-GUI: Make NixOS usable for non-technical users through settings / GUI
#143Earlier quoted context omitted.
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…
> 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…
At the end of the day, I much prefer trusting upstream than having to trust packagers to do everything right.
Re: Nix-GUI: Make NixOS usable for non-technical users through settings / GUI
#144Earlier quoted context omitted.
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…
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 c…
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"?
Re: Nix-GUI: Make NixOS usable for non-technical users through settings / GUI
#145Earlier quoted context omitted.
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…
> 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…
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.
Re: Nix-GUI: Make NixOS usable for non-technical users through settings / GUI
#146What 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…
> 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 resto…
> 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.
Re: Nix-GUI: Make NixOS usable for non-technical users through settings / GUI
#147What 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…
Re: Nix-GUI: Make NixOS usable for non-technical users through settings / GUI
#148Earlier quoted context omitted.
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…
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.
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).
Re: Nix-GUI: Make NixOS usable for non-technical users through settings / GUI
#149A 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 learnin…
Re: Nix-GUI: Make NixOS usable for non-technical users through settings / GUI
#150Earlier quoted context omitted.
> 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 resto…
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 wi…
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 {};
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.