 | NixOS Marketing | 260 Members |
| NixOS website + marketing team: https://nixos.org/community/teams/marketing.html | 56 Servers |
| NixOS Marketing | 260 Members |
| NixOS website + marketing team: https://nixos.org/community/teams/marketing.html | 56 Servers |
| Sender | Message | Time |
|---|---|---|
| 2 May 2024 | ||
 ibizaman | I searched about the following keywords online but didn’t find anything compelling. Did we ever market/talk about the whole Nix ecosystem as an artifact builder? In my limited experience trying to spread Nix love at work, I was originally faced with push backs because ppl were thinking of Nix as a competitor to docker because docker can do things that nix do: ppl use docker to setup dev environments, docker containers (duh) and has thus overlap with Nix that made it not obvious how Nix fit in. But then I switched to first explaining Nix as an artifact builder. And everything flows naturally from that. I then explain the sandboxing and how that relates to inputs and output and the hashing. Since this sandboxing goes all the way down, we can build a full BoM up to the exact commit of the shell used to build the Go compiler (we’re essentially a Go shop) that we use to compile our binary. Then I introduce that Nix has fine grained caching so we don’t need to rebuild the world each time. That ppl then realized it can build binaries but also config files, systemd services, ISOs, wholes OSes and docker containers. This means the dev environment has the exact same packages as the docker container which eliminates one of our frustrations at work. And that this includes all dependencies since it can package anything. I can continue forever so I’ll stop here but I just wanted to share this - currently in its early infancy - approach I’m using to explain Nix and everyone - literally everyone - I talked to see a great appeal to it that way. IMO this fits nicely in our work environment because it fixes our dev env which is in need of love but no one likes to take care of. | 01:26:51 |
| ibizaman | * I searched about the following keywords online but didn’t find anything compelling. Did we ever market/talk about the whole Nix ecosystem as an artifact builder? In my limited experience trying to spread Nix love at work, I was originally faced with push backs because ppl were thinking of Nix as a competitor to docker because docker can do things that nix do: ppl use docker to setup dev environments, docker containers (duh) and has thus overlap with Nix that made it not obvious how Nix fit in. But then I switched to first explaining Nix as an artifact builder. And everything flows naturally from that. I then explain the sandboxing and how that relates to inputs and output and the hashing. Since this sandboxing goes all the way down, we can build a full BoM up to the exact commit of the shell used to build the Go compiler (we’re essentially a Go shop) that we use to compile our binary. Then I introduce that Nix has fine grained caching so we don’t need to rebuild the world each time. That ppl then realized it can build binaries but also config files, systemd services, ISOs, wholes OSes and docker containers. This means the dev environment has the exact same packages as the docker container which eliminates one of our frustrations at work. And that this includes all dependencies since it can package anything. I can continue forever so I’ll stop here but I just wanted to share this - currently in its early infancy - approach I’m using to explain Nix and everyone - literally everyone - I talked to see a great appeal to it that way and seem to understand how Nix and nixpkgs and NixOS all fit together. At least this fits nicely in our work environment because it fixes our dev env which is in need of love but no one likes to take care of. | 01:29:10 |
| ibizaman | * I searched about the following keywords online but didn’t find anything compelling. Did we ever market/talk about the whole Nix ecosystem as an artifact builder? In my limited experience trying to spread Nix love at work, I was originally faced with push backs because ppl were thinking of Nix as a competitor to docker because docker can do things that nix do: ppl use docker to setup dev environments, docker containers (duh) and has thus overlap with Nix that made it not obvious how Nix fit in. But then I switched to first explaining Nix as an artifact builder. And everything flows naturally from that. I then explain the sandboxing and how that relates to inputs and output and the hashing. Since this sandboxing goes all the way down, we can build a full BoM up to the exact commit of the shell used to build the Go compiler (we’re essentially a Go shop) that we use to compile our binary. Then I introduce that Nix has fine grained caching so we don’t need to rebuild the world each time. That ppl then realized it can build binaries but also config files, systemd services, ISOs, wholes OSes and docker containers. This means the dev environment has the exact same packages as the docker container which eliminates one of our frustrations at work. And that this includes all dependencies since it can package anything. Which solves a second pain we have which is bootstrapping a new engineer’s laptop. I can continue forever so I’ll stop here but I just wanted to share this - currently in its early infancy - approach I’m using to explain Nix and everyone - literally everyone - I talked to see a great appeal to it that way and seem to understand how Nix and nixpkgs and NixOS all fit together. At least this fits nicely in our work environment because it fixes our dev env which is in need of love but no one likes to take care of. | 01:36:10 |
 tomberek | Yes! I've used a very similar flow to help describe Nix. I usually add the term "... with very good bookkeeping". | 03:17:27 |
| 3 May 2024 | ||
 Sigmanificient | An old mention of 80 000 packages was forgotten in NixOS webpage, I just made a pr to updatehttps://github.com/NixOS/nixos-homepage/pull/1414 | 03:22:27 |