7 ms·

Looks nifty— basically it's the "let me try that in a container first" except on your live system with no setup to get it going. That said, as a NixOS user for

Looks nifty— basically it's the "let me try that in a container first" except on your live system with no setup to get it going. That said, as a NixOS user for the last year or so, I think I've gotten a bit spoiled by just not worrying about this kind of thing any more— eliminating the filesystem (other than home and var) as a big ol' chunk of globally mutable state is so liberating.

JadeNB 3y ago
> Looks nifty— basically it's the "let me try that in a container first" except on your live system with no setup to get it going. Also, if I understand it correctly, it saves doing a potentially expensive operation twice: `try`ing actually performs the operation, ready to be committed; whereas, if I understand correctly, if you do something in a container and it works, then you still have to do it again "normally".
- samstave 3y ago
  It would be nifty to save out "try"s in a sqlite/whatever and then curl install tries on other systems - such that you can easily clone certain setups between machines on a small/home network. Also, if you can name tries, install-stacks - such that you can do "Try --name 'homeWebSever' [then do your tries here] Then go to another machine and from your try repo, just type 'try install --name homeWebServer -- and it does whatever your try stack was
  - JadeNB 3y ago
    From my cursory understanding (based solely on the README), it seems that `try`s are just directories, so that they can automatically be slung around, without any need for a backing database: > Sometimes, you might want to pre-execute a command and commit its result at a later time. Invoking try with the -n flag will return the overlay directory, without committing the result. Also: > curl install tries … my brain instantly translated that to "curly fries". Built-in auto-correct!
    - samstave 3y ago
      Makes more, simpler, sense...
  - tripdout 3y ago
    This is basically what you can get with Nix, sharing a binary cache between machines and getting an identical dev environment / package setup.
rvdca 3y ago
I feel that one day I should write about this curse that NixOS brings into your life when you start enjoying it : you cannot go back to different systems but at the same time you (at least I) cannot vouch and recommend it to others as the languages and constructs (Flakes with a space or an utf-8 character in the path ? Here is a rabbit hole you can go down with) are just so byzantine and painful to work with but oh boy do they work... A crystal prison, nice but with sharp corners everywhere...
- paulddraper 3y ago
  That's the problem ... So much time to a pleasing but inefficient payoff
- pxc 3y ago
  You mean like this? https://blog.wesleyac.com/posts/the-curse-of-nixos https://blog.wesleyac.com/posts/the-curse-of-nixos You should still write your commentary on the idea, though!
  - miniBill 3y ago
    Thanks for the link! I definitely agree with the author, NixOS is the only system that does The Right Thing but I cannot recommend it to anyone. I mean, I technically have recommended it to one person, but he's an ex-Arch user so... does it really count? :D
    - pxc 3y ago
      There are definitely still many rough edges and sharp corners! For software developers and sysadmins with certain temperaments, though, I think it's definitely already a good fit. A lot of NixOS people come from Arch and Gentoo, and it works well for them— although Arch folks who are deeply aligned with its keep-it-simple philosophy are probably usually turned off by Nix.
  - foota 3y ago
    Heh, I love a good dig at GCL.
throwing_away 3y ago
> eliminating the filesystem (other than home and var) as a big ol' chunk of globally mutable state is so liberating I'm about a week into the (very painful) process of switching to NixOS. This is pretty much the promise of NixOS that got me interested, but it seems to be that it's not really true. NixOS is just running a regular kernel that does regular linux security things. If you want AppArmor or SELinux you still have to configure it yourself. If you want a sandbox on NixOS, your options are still bubblewrap/firejail, proot, or flatpak. Or of course full virtualization with libvirt. The NixOS "containers" are just systemd-nspawn which (if I understand correctly) doesn't really offer more security than a properly permissioned user. I suspect that if you installed a malicious binary in a NixOS package, you'd be just as compromised as you would installing something malicious from AUR.
- mitchellh 3y ago
  The Nix store `/nix` is readonly except by the Nix build users. So, if you’re using Nix derivations for everything (the end goal), then rogue processes cannot interfere in any way with files outside of the chroot-like environment the build process creates. The writable directories (your home dir and var, as the parent stated) are still “vulnerable” and a program can run anything they want of course (bound by typical Linux/Unix rules). Nix isn’t a containerization/sandboxing technology, but it does remove any fear of installing software overwriting files you wanted, including OS level (and kernel) upgrades.
  - throwing_away 3y ago
    > but it does remove any fear of installing software overwriting files you wanted, including OS level (and kernel) upgrades. I understand that's "true" in a theoretical way because the store is read-only and it is all hashed. But the hashes aren't routinely checked by some kind of hypervisor, and root can still overwrite things in the store. The "fear of installing software overwriting files you wanted" essentially comes down to config file management (unhappy accidents) and malware. You should have config file management in git already, so I don't feel like NixOS needs to solve that. I was hoping it would solve the problem of random software being able to obtain root and not ransomware me, but it practically doesn't solve that any better than any other distro. I want to be missing something. I've invested a lot of time learning about Nix for the last week and my system is finally working, but I just got to the sandboxing/security portion of my install and the threat model seems broken.
OOPMan 3y ago
I wanted to use NixOS but it just proved to be too much of a PITA to get going with :-/ Hopefully someone will find a way to take some lessons from it while leaving all the friction behind.
- notfed 3y ago
  The the Nix language itself is the biggest PITA aspect of NixOS. It's just so unnecessarily awkward.
  - RGBCube 3y ago
    Agree, NixOS without the Nix would be awesome.
    - goodpoint 3y ago
      So guix?
yonrg 3y ago
I am intrigued by experimenting with nixos. For now, my current driver for workstations is arch, on servers rh-flavored or debian. Everything is managed by ansible, plus persistent data is in backup. A lost server could reinstated quickly. Same for starting a new workstation. I understand nixos can do this, too. And also I have read about an home manager in nixos, which I think is essential too. Otoh, I'm not a developer. I think I do not need different versions of softwares. Maybe this is why I have not switched to nixos so far.
deleted 3y ago
[deleted]

JadeNB 3y ago

> Looks nifty— basically it's the "let me try that in a container first" except on your live system with no setup to get it going. Also, if I understand it correctly, it saves doing a potentially expensive operation twice: `try`ing actually performs the operation, ready to be committed; whereas, if I understand correctly, if you do something in a container and it works, then you still have to do it again "normally".

samstave 3y ago
It would be nifty to save out "try"s in a sqlite/whatever and then curl install tries on other systems - such that you can easily clone certain setups between machines on a small/home network. Also, if you can name tries, install-stacks - such that you can do "Try --name 'homeWebSever' [then do your tries here] Then go to another machine and from your try repo, just type 'try install --name homeWebServer -- and it does whatever your try stack was
- JadeNB 3y ago
  From my cursory understanding (based solely on the README), it seems that `try`s are just directories, so that they can automatically be slung around, without any need for a backing database: > Sometimes, you might want to pre-execute a command and commit its result at a later time. Invoking try with the -n flag will return the overlay directory, without committing the result. Also: > curl install tries … my brain instantly translated that to "curly fries". Built-in auto-correct!
  - samstave 3y ago
    Makes more, simpler, sense...
- tripdout 3y ago
  This is basically what you can get with Nix, sharing a binary cache between machines and getting an identical dev environment / package setup.

rvdca 3y ago

I feel that one day I should write about this curse that NixOS brings into your life when you start enjoying it : you cannot go back to different systems but at the same time you (at least I) cannot vouch and recommend it to others as the languages and constructs (Flakes with a space or an utf-8 character in the path ? Here is a rabbit hole you can go down with) are just so byzantine and painful to work with but oh boy do they work... A crystal prison, nice but with sharp corners everywhere...

paulddraper 3y ago
That's the problem ... So much time to a pleasing but inefficient payoff
pxc 3y ago
You mean like this? https://blog.wesleyac.com/posts/the-curse-of-nixos https://blog.wesleyac.com/posts/the-curse-of-nixos You should still write your commentary on the idea, though!
- miniBill 3y ago
  Thanks for the link! I definitely agree with the author, NixOS is the only system that does The Right Thing but I cannot recommend it to anyone. I mean, I technically have recommended it to one person, but he's an ex-Arch user so... does it really count? :D
  - pxc 3y ago
    There are definitely still many rough edges and sharp corners! For software developers and sysadmins with certain temperaments, though, I think it's definitely already a good fit. A lot of NixOS people come from Arch and Gentoo, and it works well for them— although Arch folks who are deeply aligned with its keep-it-simple philosophy are probably usually turned off by Nix.
- foota 3y ago
  Heh, I love a good dig at GCL.

throwing_away 3y ago

> eliminating the filesystem (other than home and var) as a big ol' chunk of globally mutable state is so liberating I'm about a week into the (very painful) process of switching to NixOS. This is pretty much the promise of NixOS that got me interested, but it seems to be that it's not really true. NixOS is just running a regular kernel that does regular linux security things. If you want AppArmor or SELinux you still have to configure it yourself. If you want a sandbox on NixOS, your options are still bubblewrap/firejail, proot, or flatpak. Or of course full virtualization with libvirt. The NixOS "containers" are just systemd-nspawn which (if I understand correctly) doesn't really offer more security than a properly permissioned user. I suspect that if you installed a malicious binary in a NixOS package, you'd be just as compromised as you would installing something malicious from AUR.

mitchellh 3y ago
The Nix store `/nix` is readonly except by the Nix build users. So, if you’re using Nix derivations for everything (the end goal), then rogue processes cannot interfere in any way with files outside of the chroot-like environment the build process creates. The writable directories (your home dir and var, as the parent stated) are still “vulnerable” and a program can run anything they want of course (bound by typical Linux/Unix rules). Nix isn’t a containerization/sandboxing technology, but it does remove any fear of installing software overwriting files you wanted, including OS level (and kernel) upgrades.
- throwing_away 3y ago
  > but it does remove any fear of installing software overwriting files you wanted, including OS level (and kernel) upgrades. I understand that's "true" in a theoretical way because the store is read-only and it is all hashed. But the hashes aren't routinely checked by some kind of hypervisor, and root can still overwrite things in the store. The "fear of installing software overwriting files you wanted" essentially comes down to config file management (unhappy accidents) and malware. You should have config file management in git already, so I don't feel like NixOS needs to solve that. I was hoping it would solve the problem of random software being able to obtain root and not ransomware me, but it practically doesn't solve that any better than any other distro. I want to be missing something. I've invested a lot of time learning about Nix for the last week and my system is finally working, but I just got to the sandboxing/security portion of my install and the threat model seems broken.

OOPMan 3y ago

I wanted to use NixOS but it just proved to be too much of a PITA to get going with :-/ Hopefully someone will find a way to take some lessons from it while leaving all the friction behind.

notfed 3y ago
The the Nix language itself is the biggest PITA aspect of NixOS. It's just so unnecessarily awkward.
- RGBCube 3y ago
  Agree, NixOS without the Nix would be awesome.
  - goodpoint 3y ago
    So guix?

yonrg 3y ago

I am intrigued by experimenting with nixos. For now, my current driver for workstations is arch, on servers rh-flavored or debian. Everything is managed by ansible, plus persistent data is in backup. A lost server could reinstated quickly. Same for starting a new workstation. I understand nixos can do this, too. And also I have read about an home manager in nixos, which I think is essential too. Otoh, I'm not a developer. I think I do not need different versions of softwares. Maybe this is why I have not switched to nixos so far.

deleted 3y ago

[deleted]