4 ms·

The best part is that some people think 'brew' is a solid package manager and then show up in Linux and try to make 'linuxbrew' happen (no really, it is a thing

The best part is that some people think 'brew' is a solid package manager and then show up in Linux and try to make 'linuxbrew' happen (no really, it is a thing). I just wish everyone would take a day and read an intro to nix/nixpkgs and the world would really be a better place. There are so many "popular" hyped tools these days that can barely do a fraction of what is going on in the Nix ecosystem, but it doesn't seem to get the hype that brew, buildkit, linuxkit, etc all seem to get.

ynezz 8y ago
> hype that brew, buildkit, linuxkit, etc all seem to get I'm not that much in devops/containers guy, bit I'm not aware about linuxkit alternative in the Linux world, care to elaborate?
- colemickens 8y ago
  As my comment implies, nix and nixpkgs can do what `linuxkit` does (in terms of image building, at least) but better and in a more powerful manner. I can create nix derivations that look like a linuxkit yaml, but instead of having a bunch of opaque sha256 hashes to some container in them, it has symbolic references to packages that are defined in my nixpkgs repository. This nixpkgs repository includes package definitions for basically everything in a distribution. From it, out of the box, you can issue single commands to build: VM images, container images, images ready to deploy on GCE/AWS/Azure, all from a single set of package definitions. This means I can issue a single command that will output a VM image (or a container) that includes the exact revisions of all of my software, down to the kernel options and compiler flags. It makes it trivial to take in patches for critical components and rebuild a base image. No cloning extra repos. No build, container build, push, grab sha256, copy sha256 into a yaml file. Just specify the patch, hit rebuild, done. You can do this for VM images, specifying the total system configuration - how you want etcd/kubelet/etc running, for example. One command and you have a bootable Azure VHD. You can then use the same tree, or maybe a different branch, and declaratively(!), very minimally [1] build the most optimal container images that you then have deployed to Kubernetes or wherever. And you can be sure that you can build this exact configuration in 1 year, 2 years, 3 years, etc, due to how Nix works. I hope I've done a somewhat okay job of explaining this. I'm trying to take some time and write a "container oriented look at why Nix is cool" guide soon too. [1]: https://grahamc.com/blog/nix-and-layered-docker-images https://grahamc.com/blog/nix-and-layered-docker-images
  - ynezz 8y ago
    Great, thanks!
3PS 8y ago
Say what you will about Homebrew, but we need more package managers that can easily install without root. Not everyone has the time and energy to compile from source, and often it's a circular problem - I need to compile and install Python 3.7, which needs openssl, which needs to be compiled from source, which has even more dependencies... ad nauseam.
- colemickens 8y ago
  Why do we need more of them when we already have a number that are capable of deploying into a home directory? As someone who has worked on software that has needed packaging, and someone who tries to help out with packaging for a distribution, I can't imagine why we need more for the sake of having more. Per my original comment, nix can do this, for example and already has an enormous number of packages packed, pre-built/cached, ready to go.

ynezz 8y ago

> hype that brew, buildkit, linuxkit, etc all seem to get I'm not that much in devops/containers guy, bit I'm not aware about linuxkit alternative in the Linux world, care to elaborate?

colemickens 8y ago
As my comment implies, nix and nixpkgs can do what `linuxkit` does (in terms of image building, at least) but better and in a more powerful manner. I can create nix derivations that look like a linuxkit yaml, but instead of having a bunch of opaque sha256 hashes to some container in them, it has symbolic references to packages that are defined in my nixpkgs repository. This nixpkgs repository includes package definitions for basically everything in a distribution. From it, out of the box, you can issue single commands to build: VM images, container images, images ready to deploy on GCE/AWS/Azure, all from a single set of package definitions. This means I can issue a single command that will output a VM image (or a container) that includes the exact revisions of all of my software, down to the kernel options and compiler flags. It makes it trivial to take in patches for critical components and rebuild a base image. No cloning extra repos. No build, container build, push, grab sha256, copy sha256 into a yaml file. Just specify the patch, hit rebuild, done. You can do this for VM images, specifying the total system configuration - how you want etcd/kubelet/etc running, for example. One command and you have a bootable Azure VHD. You can then use the same tree, or maybe a different branch, and declaratively(!), very minimally [1] build the most optimal container images that you then have deployed to Kubernetes or wherever. And you can be sure that you can build this exact configuration in 1 year, 2 years, 3 years, etc, due to how Nix works. I hope I've done a somewhat okay job of explaining this. I'm trying to take some time and write a "container oriented look at why Nix is cool" guide soon too. [1]: https://grahamc.com/blog/nix-and-layered-docker-images https://grahamc.com/blog/nix-and-layered-docker-images
- ynezz 8y ago
  Great, thanks!

3PS 8y ago

Say what you will about Homebrew, but we need more package managers that can easily install without root. Not everyone has the time and energy to compile from source, and often it's a circular problem - I need to compile and install Python 3.7, which needs openssl, which needs to be compiled from source, which has even more dependencies... ad nauseam.

colemickens 8y ago
Why do we need more of them when we already have a number that are capable of deploying into a home directory? As someone who has worked on software that has needed packaging, and someone who tries to help out with packaging for a distribution, I can't imagine why we need more for the sake of having more. Per my original comment, nix can do this, for example and already has an enormous number of packages packed, pre-built/cached, ready to go.