11 ms·

Creating bundles with guix pack

75 points by davexunit 10y ago

bandrami 10y ago
I really love GNU GUIX SD (the distro based on this package manager). I just wish the linux-libre crew would bite the bullet and simply publish an actual HCL. "Some transmitters with this chipset may not work because they require non-free firmware (that we deliberately changed the kernel to refuse to load)" doesn't really work for me.
- moosingin3space 10y ago
  The district looks very consistent and nice. I wish there was a version that did have firmwares so those of us with hardware that requires non-free firmware could use it. Yeah, idealism of FSF, but I'm not in a position to buy a Linux-libre-compatible machine right now.
  - rekado 10y ago
    FWIW: it's not hard to obtain hardware that works with Linux-libre. My main machine is a Thinkpad X200S where the restrictive Lenovo BIOS has been replaced with Libreboot, allowing me to install a WiFi card from Tehnoetic (using the Atheros driver). I have a couple of other machines and only one of them has reduced functionality when using Linux libre (e.g. the on-board Radeon graphics chip needs nonfree firmware for higher resolutions). Guix and GuixSD makes it easy to use a custom kernel package, so you can choose to use a blobby kernel, if you can accept that.
    - davexunit 10y ago
      To share my own story, I flashed a hacked version of the proprietary BIOS on a Thinkpad X220 and was able to replace the Intel wireless chip with an Atheros chip. At the time Libreboot wasn't available, but it could still be a viable method of using a newer Thinkpad with a fully free OS, downside being that the proprietary BIOS is still in use.
- dublinben 10y ago
  The HCL you're looking for pretty much already exists.[0] If you're looking for more specific recommendations, the Respects Your Freedom certification is a more limited list of hardware that is known to work without non-free firmware.[1] [0] https://h-node.org/ https://h-node.org/ [1] https://fsf.org/ryf https://fsf.org/ryf
- nckx 10y ago
  > that we deliberately changed the kernel to refuse to load I've heard this myth before too. Here's someone else's succinct answer to it: It's a common misunderstanding to think that the Linux-libre project forbids loading non-free modules/drivers by user's request after the kernel was installed. In fact, it's a bug that is very hard to fix due to the way that the Linux kernel itself is made, as Alexandre Oliva, member of Linux-libre project, states at http://www.fsfla.org/ikiwiki/blogs/lxo/2013-11-08-linux-libre-interview-by-bruce-byfield.en.html http://www.fsfla.org/ikiwiki/blogs/lxo/2013-11-08-linux-libr... (when answering the question "Is there anything that the project wants to do that it can't do now? In general, what are the future plans for the project?").
codemac 10y ago
Wouldn't this all be a bit easier if the hashes in guix/nix were relative to some global destination store location, rather than /nix or /guix?
- rekado 10y ago
  What would that look like?
  - codemac 10y ago
    I need to look at how pack is implemented, maybe I'm missing something. I already used this to install guile 2.2 on a debian machine, so I'm excited for this development. But to clarify my point - instead of all the content hashes being based on "/guix/store", they'd be based on "guix/store", which would be relative to a configured "store root" to the daemon (or defaulting to /). Then packages generated would also have relative links, thus "installing a package from guix" would just be a matter of downloading the dependency graph, and tucking away wherever you please.
    - davexunit 10y ago
      Without using absolute file names you'd have lookup problems everywhere.
      - codemac 10y ago
        Yeah, ran into this when thinking more about this on the bus. Sorry for the distraction.
- civodul 10y ago
  Thanks to user namespaces, it's easy to map, say, /home/myself/gnu to /gnu, as shown in the article (with "unshare"). For cases where user namespaces are unavailable, Pjotr Prins wrote a neat hack that allows users to "relocate" binaries to a different file system location by rewriting file names in the binaries: https://github.com/pjotrp/gnu-install-bin https://github.com/pjotrp/gnu-install-bin . Scary to some, but definitely does the job. :-)
rubiquity 10y ago
Guix and Nix lack the hype of technologies/buzzwords like Docker and anything container related, but they look incredibly pragmatic and easy to use. Whenever I look at containers I always think they were started with trying to solve the problem of app packaging but at some point they tugged too hard on the tablecloth and all the other virtualization problems came tumbling down, too. I guess you can avoid a lot of these if you stick to running 1 container per host. Anyway, Guix looks super user friendly and I'm going to give this a try!
- davexunit 10y ago
  Yeah, we definitely lack hype. We have some container features, too, if you are interested. I wrote this back in 2015: https://www.gnu.org/software/guix/news/container-provisioning-with-guix.html https://www.gnu.org/software/guix/news/container-provisionin...
  - agumonkey 10y ago
    I hope you're not worried about hype. Good luck with the project.
- _ibu9 10y ago
  Yeah Docker and friends exist basically because the industry is blissfully unaware of nice things like Nix.
  - cookiecaper 10y ago
    Gotta be careful with this type of heresy! You won't get hired at a trendy VC-backed company if you're harshing the buzzwords. ;)
  - moosingin3space 10y ago
    Not exclusively. If I want to pay someone for support for running NixOS-based servers, who do I pay? Does NixOS have a support term anywhere near Red Hat (or even Ubuntu)? What about the awkward CLI UX? What about a turn-key solution to deploy my app? These questions are reasonably well answered with Docker, less so with Nix/NixOS. I say this as someone who really likes the ideas of Nix. In fact, I see the benefits of Docker as being solved reasonably well by Nix: * Isolation of multiple applications on the same server are handled by NixOS containers, which use the same configuration as a NixOS system and use things like cgroups and namespaces, * Immutable/declarative deployments (through things like docker-compose) are elegantly handled through nix-expressions, * Multiple versions of a dependency are handled through the nix store. I think a good measure would be to provide good tooling for generating Docker images from Nix, and this is what `guix pack` can do today. Once Nix has gotten over these pains, it can become a good developer tool, and from there, ops may choose to adopt it.

75 points by davexunit 10y ago

I really love GNU GUIX SD (the distro based on this package manager). I just wish the linux-libre crew would bite the bullet and simply publish an actual HCL. "Some transmitters with this chipset may not work because they require non-free firmware (that we deliberately changed the kernel to refuse to load)" doesn't really work for me.

moosingin3space 10y ago
The district looks very consistent and nice. I wish there was a version that did have firmwares so those of us with hardware that requires non-free firmware could use it. Yeah, idealism of FSF, but I'm not in a position to buy a Linux-libre-compatible machine right now.
- rekado 10y ago
  FWIW: it's not hard to obtain hardware that works with Linux-libre. My main machine is a Thinkpad X200S where the restrictive Lenovo BIOS has been replaced with Libreboot, allowing me to install a WiFi card from Tehnoetic (using the Atheros driver). I have a couple of other machines and only one of them has reduced functionality when using Linux libre (e.g. the on-board Radeon graphics chip needs nonfree firmware for higher resolutions). Guix and GuixSD makes it easy to use a custom kernel package, so you can choose to use a blobby kernel, if you can accept that.
  - davexunit 10y ago
    To share my own story, I flashed a hacked version of the proprietary BIOS on a Thinkpad X220 and was able to replace the Intel wireless chip with an Atheros chip. At the time Libreboot wasn't available, but it could still be a viable method of using a newer Thinkpad with a fully free OS, downside being that the proprietary BIOS is still in use.
dublinben 10y ago
The HCL you're looking for pretty much already exists.[0] If you're looking for more specific recommendations, the Respects Your Freedom certification is a more limited list of hardware that is known to work without non-free firmware.[1] [0] https://h-node.org/ https://h-node.org/ [1] https://fsf.org/ryf https://fsf.org/ryf
nckx 10y ago
> that we deliberately changed the kernel to refuse to load I've heard this myth before too. Here's someone else's succinct answer to it: It's a common misunderstanding to think that the Linux-libre project forbids loading non-free modules/drivers by user's request after the kernel was installed. In fact, it's a bug that is very hard to fix due to the way that the Linux kernel itself is made, as Alexandre Oliva, member of Linux-libre project, states at http://www.fsfla.org/ikiwiki/blogs/lxo/2013-11-08-linux-libre-interview-by-bruce-byfield.en.html http://www.fsfla.org/ikiwiki/blogs/lxo/2013-11-08-linux-libr... (when answering the question "Is there anything that the project wants to do that it can't do now? In general, what are the future plans for the project?").

codemac 10y ago

Wouldn't this all be a bit easier if the hashes in guix/nix were relative to some global destination store location, rather than /nix or /guix?

rekado 10y ago
What would that look like?
- codemac 10y ago
  I need to look at how pack is implemented, maybe I'm missing something. I already used this to install guile 2.2 on a debian machine, so I'm excited for this development. But to clarify my point - instead of all the content hashes being based on "/guix/store", they'd be based on "guix/store", which would be relative to a configured "store root" to the daemon (or defaulting to /). Then packages generated would also have relative links, thus "installing a package from guix" would just be a matter of downloading the dependency graph, and tucking away wherever you please.
  - davexunit 10y ago
    Without using absolute file names you'd have lookup problems everywhere.
    - codemac 10y ago
      Yeah, ran into this when thinking more about this on the bus. Sorry for the distraction.
civodul 10y ago
Thanks to user namespaces, it's easy to map, say, /home/myself/gnu to /gnu, as shown in the article (with "unshare"). For cases where user namespaces are unavailable, Pjotr Prins wrote a neat hack that allows users to "relocate" binaries to a different file system location by rewriting file names in the binaries: https://github.com/pjotrp/gnu-install-bin https://github.com/pjotrp/gnu-install-bin . Scary to some, but definitely does the job. :-)

rubiquity 10y ago

Guix and Nix lack the hype of technologies/buzzwords like Docker and anything container related, but they look incredibly pragmatic and easy to use. Whenever I look at containers I always think they were started with trying to solve the problem of app packaging but at some point they tugged too hard on the tablecloth and all the other virtualization problems came tumbling down, too. I guess you can avoid a lot of these if you stick to running 1 container per host. Anyway, Guix looks super user friendly and I'm going to give this a try!

davexunit 10y ago
Yeah, we definitely lack hype. We have some container features, too, if you are interested. I wrote this back in 2015: https://www.gnu.org/software/guix/news/container-provisioning-with-guix.html https://www.gnu.org/software/guix/news/container-provisionin...
- agumonkey 10y ago
  I hope you're not worried about hype. Good luck with the project.
_ibu9 10y ago
Yeah Docker and friends exist basically because the industry is blissfully unaware of nice things like Nix.
- cookiecaper 10y ago
  Gotta be careful with this type of heresy! You won't get hired at a trendy VC-backed company if you're harshing the buzzwords. ;)
- moosingin3space 10y ago
  Not exclusively. If I want to pay someone for support for running NixOS-based servers, who do I pay? Does NixOS have a support term anywhere near Red Hat (or even Ubuntu)? What about the awkward CLI UX? What about a turn-key solution to deploy my app? These questions are reasonably well answered with Docker, less so with Nix/NixOS. I say this as someone who really likes the ideas of Nix. In fact, I see the benefits of Docker as being solved reasonably well by Nix: * Isolation of multiple applications on the same server are handled by NixOS containers, which use the same configuration as a NixOS system and use things like cgroups and namespaces, * Immutable/declarative deployments (through things like docker-compose) are elegantly handled through nix-expressions, * Multiple versions of a dependency are handled through the nix store. I think a good measure would be to provide good tooling for generating Docker images from Nix, and this is what `guix pack` can do today. Once Nix has gotten over these pains, it can become a good developer tool, and from there, ops may choose to adopt it.