Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> It uses the standards set for containerization to make userland configuration reproducible as well. There's a manifest (Containerfile) that enumerates all the modifications, which means an upgrade is bump the version of the base image and replay all the modifications from the manifest.

Is the containerfile syntax and reproducibility as good as configuration.nix / NixOS?

I love NixOS but it’s a very acquired taste, to the point where even I occasionally wish I was running something bog-standard. If this is similar to NixOS but closer to regular Linux, that’d be nice to recommend to friends.



It's not as exactly reproducible because there's no version locking, however after running the Containerfile you have a snapshot of the filesystem that is ready to be used and that you can save. Universal blue images use GitHub container registry, and it's 90 days of history to have at least 90 days of rollbacks available.

I'm currently setting up a Bazzite machine by using a GitHub actions to build every day an image from Bazzite's image and adding/removing packages and files on top. I have the DE, login manager and all its customizations in the image and for the CLI utilities and thing like that I use home manager.

I like this setup because you just need to know Linux to customize the image, Containerfile's are just series of commands or file copies from the repo, compared to nix it's easier.


Thank you for the info!


I've only used NixOS, but the Containerfile looks more like a shell script than a Nix config:

https://github.com/ublue-os/bazzite/blob/main/Containerfile


    AS incomprehensible && \
       as nix can be && \
       i would take it && \
       any day over && \
       configuring a desktop OS && \
       with the horrible && \
       Dockerfile syntax


Containerfile is just what the IBM containers group calls a Dockerfile. They are 99% compatible.


That looks like something I wouldn't wanna use, all imperative


Same. I can't be the only one who feels that Nix is doing the right thing the wrong way. The right thing being reproducible, declarative, composable environments; the wrong thing being its language and tooling. Too often I feel like serious Nix users spend a distressing amount of time manually doing package manager tasks, so the way forward is to stop doing exactly that. Going back to imperative composition is a step backward that will never help people free up time away from package management.


FWIW I am starting to use home manager on my new macOS workstation, and I haven't had to dig too deep into Nix, nixpkgs, or NixOS.

I might hit limits soon as I rice my neovim install.


Make sure to have a look at nixvim: https://github.com/nix-community/nixvim


The language is just JSON with functions. It's actually so nice to write configurations in that I wish it was more easier to use as a standalone thing.


I wish guix was a little more mainstream.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: