7 ms·

The obvious critique in 2021+ is "GoboLinux is a great concept but doesn't Nix make it obsolete?"

by DarylZero 5y ago

jiggunjer 5y ago
Or docker.
- lillecarl 5y ago
  Why is it that AppImages, snaps, flatpaks, Nix and every distro package manager is replaced by docker? Could it be that docker is missing something, maybe the Dockerfile isn't easily reproducible? Maybe the ephemeral status of all containers is quite some effort to work with? Maybe it's just not the one true answer to the question of software packaging.
  - jeroenhd 5y ago
    Identifying your dependencies is hard. The easy solution is not to care: develop on a machine, and ship the entire machine! That way, software with the Works On My Machine seal of approval can be pushed to production without trouble! I love Docker for the simplicity it offers, but the gigabytes of storage wasted on yet another slightly different version of Debian every time I pull a container irks me to no end. Sadly, it's the only way some software is distributed.
    - goodpoint 5y ago
      Please tell me this is satire.
      - jeroenhd 5y ago
        First part is, second part isn't :)
  - piaste 5y ago
    > Why is it that AppImages, snaps, flatpaks, Nix and every distro package manager is replaced by docker? Where are you seeing distros using docker for containerization? If anything, I'd say Flatpak is the one you're most likely to find installed in a 2021 workstation linux. Docker's killing features are the same as they always were: usability and ecosystem. 'docker run thingamajig' is simple and DockerHub is very likely to have thingamajig in its repos. Of the ones you listed, I'd say flatpak is the only one that compares favorably to Docker on both aspects ('flatpak install thingamajig'). And since flatpak is more designed for desktop applications, it's actually the one gaining ground. Docker or other containerd-based solutions should remain the preferred choice for servers, since they're designed for that. Nix is vastly less user friendly. Snaps, last I checked, still don't have an open-source repository implementation, meaning that Canonical has absolute control over them. I don't know much about AppImage, but AFAICT it's just a file format and not a full package manager.
- codedokode 5y ago
  Docker (in my opinion) is a poor solution for distributing apps. It resembles a quick hack rather than a solid, scalable, future-proof solution. The problem is: you need to deploy an application with all required libraries with specific versions and build options. Obviously, a proper solution would be a package manager which would read the declarative, non-executable configuration file and install or build necessary dependencies. Another problem is that you want to run an application on differen platforms, not only Linux. Again the proper solution would be to write a cross-paltform application and install it using a cross-platform package manager. Docker doesn't offer a proper solution; instead it suggests that you create a virtual machine, install a whole operating system (without a kernel) there and then write a bash script that will download and build dependencies. As docker image configuration file is an executable script, it means that it cannot be processed with automated tools; it can only be read by a human. Also, docker requires a daemon running as a root. This increases potential attack surface. Docker is not good for desktop applications because it doesn't have portals which can restrict access to DBus, audio daemons, file system etc.
  - galaxyLogic 5y ago
    Good points. So what is Docker good for? I think it's a good tool for creating and packaging virtual machines. No?
bantunes 5y ago
I was going to reply saying Gobo came first, but they're both from 2003!
- DarylZero 5y ago
  I thought Gobo came first. I remember installing it ~2003. Didn't hear about Nix until years later and when I did it reminded of that old Gobo install.
lillecarl 5y ago
GoboLinux uses patchelf just like Nix but you don't have to learn the convoluted undebuggable mess of Nixlang (I run NixOS on all my machines, it's a love-hate relationship)
- nusaru 5y ago
  I've only tried Nix once or twice, and I'm left wondering: why don't they use a scripting language? Is part of the appeal that the Nix language is a functional language?
  - darau1 5y ago
    > tried Nix once or twice me too. I broke my system a bunch of times, and eventually just gave up. I remembered the other day that I have a lot of programs installed with it that I don't even want to think about updating. rofi changed it's configuration file format recently, and that was tied up in nix. I am too lazy to fight with it for now, so I've just disabled my config file. It bothers me every time I use it.
    - lillecarl 5y ago
      NixOS is the only system I'm yet to break, and I've been using it at home for 2 years and at work full-time for a couple months. If the system evaluates it'll most likely work, if it doesn't you roll back a generation. I have an Ubuntu container around if I quickly wanna mess with something.
      - darau1 5y ago
        I'm positive it works. My problem was that figuring out why something went wrong was too time consuming, or difficult. I'm sure I could figure it out, but the problem again is time.
  - lillecarl 5y ago
    So everything has to be pure and side-effect free, I'm not into the history and when you're not doing too much Voodoo it looks like what you'd want a configuration file to look like. But the downside is that debugging is impossble. Guix uses guile, which is a Lisp so we could accomplish the same with other languages.
cxr 5y ago
Previously: > > How does GoboLinux compare to Nix & Guix these days? Why would one use the former vs the latter? > This blogpost has a comparison of Gobolinux and Nix: > http://sandervanderburg.blogs http://sandervanderburg.blogs <https://news.ycombinator.com/item?id=13189792 https://news.ycombinator.com/item?id=13189792>
- k__ 5y ago
  TL;DR NixOS uses hashes based on all dependencies that go into a package build and GoboLinux uses version numbers. Which makes Gobo easier to use, but less secure.
- egberts1 5y ago
  SanderVanderburg.blogs is down.
  - cxr 5y ago
    It never existed. That "URL" got mangled. Click through to the HN thread that was the real referent of the comment.
- egberts1 5y ago
  so where do I find the /run where all the PIDs are kept? systemd compliant?
pxc 5y ago
GoboLinux is more impure and more compatible with processes that people are used to. Imo it will take an impure, downstream distro of NixOS to really make GoboLinux 'obsolete'. Something where, in a pinch, you can just ./configure && make without grokking Nix, and have it work. Or where you can install Linuxbrew and Pkgsrc and have them just work, as additional, non-sandboxed escape hatches. And such a downstream system could benefit from mimicking GoboLinux in a few ways, imo.
- Nullabillity 5y ago
  For what it's worth, the Nix definition for autotools-using programs can basically be: { pkgs ? import <nixpkgs> {} }: pkgs.stdenv.mkDerivation { name = "foo-1.0"; src = ./.; buildInputs = [ pkgs.libfoo pkgs.libbar ]; } You could make a CLI that does the templating for you, but there's nothing fundamental here that would require a fork of Nix (or Nixpkgs/NixOS) itself.
  - spindle 5y ago
    I agree ... and I think we urgently need that CLI.
  - pxc 5y ago
    Packaging most things for Nixpkgs is super easy, which is awesome. But I think impurity could be a different kind of on-ramp. See things like envfs or the reverted PR for the LSB module in NixOS.
    - Nullabillity 5y ago
      Envfs looks interesting, but I don't think compromising on Nix(OS)'s core to be more familiar is a sustainable approach, and the unreliability of the produced frankenbuilds seem more like something that'd scare newcomers away once things start breaking. I'd rather look into how to make the Nix-native workflow be as appealing and welcoming as the impure one, than compromise and end up with a system ultimately just that has the downsides of both.

The obvious critique in 2021+ is "GoboLinux is a great concept but doesn't Nix make it obsolete?"

jiggunjer 5y ago

Or docker.

lillecarl 5y ago
Why is it that AppImages, snaps, flatpaks, Nix and every distro package manager is replaced by docker? Could it be that docker is missing something, maybe the Dockerfile isn't easily reproducible? Maybe the ephemeral status of all containers is quite some effort to work with? Maybe it's just not the one true answer to the question of software packaging.
- jeroenhd 5y ago
  Identifying your dependencies is hard. The easy solution is not to care: develop on a machine, and ship the entire machine! That way, software with the Works On My Machine seal of approval can be pushed to production without trouble! I love Docker for the simplicity it offers, but the gigabytes of storage wasted on yet another slightly different version of Debian every time I pull a container irks me to no end. Sadly, it's the only way some software is distributed.
  - goodpoint 5y ago
    Please tell me this is satire.
    - jeroenhd 5y ago
      First part is, second part isn't :)
- piaste 5y ago
  > Why is it that AppImages, snaps, flatpaks, Nix and every distro package manager is replaced by docker? Where are you seeing distros using docker for containerization? If anything, I'd say Flatpak is the one you're most likely to find installed in a 2021 workstation linux. Docker's killing features are the same as they always were: usability and ecosystem. 'docker run thingamajig' is simple and DockerHub is very likely to have thingamajig in its repos. Of the ones you listed, I'd say flatpak is the only one that compares favorably to Docker on both aspects ('flatpak install thingamajig'). And since flatpak is more designed for desktop applications, it's actually the one gaining ground. Docker or other containerd-based solutions should remain the preferred choice for servers, since they're designed for that. Nix is vastly less user friendly. Snaps, last I checked, still don't have an open-source repository implementation, meaning that Canonical has absolute control over them. I don't know much about AppImage, but AFAICT it's just a file format and not a full package manager.
codedokode 5y ago
Docker (in my opinion) is a poor solution for distributing apps. It resembles a quick hack rather than a solid, scalable, future-proof solution. The problem is: you need to deploy an application with all required libraries with specific versions and build options. Obviously, a proper solution would be a package manager which would read the declarative, non-executable configuration file and install or build necessary dependencies. Another problem is that you want to run an application on differen platforms, not only Linux. Again the proper solution would be to write a cross-paltform application and install it using a cross-platform package manager. Docker doesn't offer a proper solution; instead it suggests that you create a virtual machine, install a whole operating system (without a kernel) there and then write a bash script that will download and build dependencies. As docker image configuration file is an executable script, it means that it cannot be processed with automated tools; it can only be read by a human. Also, docker requires a daemon running as a root. This increases potential attack surface. Docker is not good for desktop applications because it doesn't have portals which can restrict access to DBus, audio daemons, file system etc.
- galaxyLogic 5y ago
  Good points. So what is Docker good for? I think it's a good tool for creating and packaging virtual machines. No?

bantunes 5y ago

I was going to reply saying Gobo came first, but they're both from 2003!

DarylZero 5y ago
I thought Gobo came first. I remember installing it ~2003. Didn't hear about Nix until years later and when I did it reminded of that old Gobo install.

lillecarl 5y ago

GoboLinux uses patchelf just like Nix but you don't have to learn the convoluted undebuggable mess of Nixlang (I run NixOS on all my machines, it's a love-hate relationship)

nusaru 5y ago
I've only tried Nix once or twice, and I'm left wondering: why don't they use a scripting language? Is part of the appeal that the Nix language is a functional language?
- darau1 5y ago
  > tried Nix once or twice me too. I broke my system a bunch of times, and eventually just gave up. I remembered the other day that I have a lot of programs installed with it that I don't even want to think about updating. rofi changed it's configuration file format recently, and that was tied up in nix. I am too lazy to fight with it for now, so I've just disabled my config file. It bothers me every time I use it.
  - lillecarl 5y ago
    NixOS is the only system I'm yet to break, and I've been using it at home for 2 years and at work full-time for a couple months. If the system evaluates it'll most likely work, if it doesn't you roll back a generation. I have an Ubuntu container around if I quickly wanna mess with something.
    - darau1 5y ago
      I'm positive it works. My problem was that figuring out why something went wrong was too time consuming, or difficult. I'm sure I could figure it out, but the problem again is time.
- lillecarl 5y ago
  So everything has to be pure and side-effect free, I'm not into the history and when you're not doing too much Voodoo it looks like what you'd want a configuration file to look like. But the downside is that debugging is impossble. Guix uses guile, which is a Lisp so we could accomplish the same with other languages.

cxr 5y ago

Previously: > > How does GoboLinux compare to Nix & Guix these days? Why would one use the former vs the latter? > This blogpost has a comparison of Gobolinux and Nix: > http://sandervanderburg.blogs http://sandervanderburg.blogs <https://news.ycombinator.com/item?id=13189792 https://news.ycombinator.com/item?id=13189792>

k__ 5y ago
TL;DR NixOS uses hashes based on all dependencies that go into a package build and GoboLinux uses version numbers. Which makes Gobo easier to use, but less secure.
egberts1 5y ago
SanderVanderburg.blogs is down.
- cxr 5y ago
  It never existed. That "URL" got mangled. Click through to the HN thread that was the real referent of the comment.
egberts1 5y ago
so where do I find the /run where all the PIDs are kept? systemd compliant?

pxc 5y ago

GoboLinux is more impure and more compatible with processes that people are used to. Imo it will take an impure, downstream distro of NixOS to really make GoboLinux 'obsolete'. Something where, in a pinch, you can just ./configure && make without grokking Nix, and have it work. Or where you can install Linuxbrew and Pkgsrc and have them just work, as additional, non-sandboxed escape hatches. And such a downstream system could benefit from mimicking GoboLinux in a few ways, imo.

Nullabillity 5y ago
For what it's worth, the Nix definition for autotools-using programs can basically be: { pkgs ? import <nixpkgs> {} }: pkgs.stdenv.mkDerivation { name = "foo-1.0"; src = ./.; buildInputs = [ pkgs.libfoo pkgs.libbar ]; } You could make a CLI that does the templating for you, but there's nothing fundamental here that would require a fork of Nix (or Nixpkgs/NixOS) itself.
- spindle 5y ago
  I agree ... and I think we urgently need that CLI.
- pxc 5y ago
  Packaging most things for Nixpkgs is super easy, which is awesome. But I think impurity could be a different kind of on-ramp. See things like envfs or the reverted PR for the LSB module in NixOS.
  - Nullabillity 5y ago
    Envfs looks interesting, but I don't think compromising on Nix(OS)'s core to be more familiar is a sustainable approach, and the unreliability of the produced frankenbuilds seem more like something that'd scare newcomers away once things start breaking. I'd rather look into how to make the Nix-native workflow be as appealing and welcoming as the impure one, than compromise and end up with a system ultimately just that has the downsides of both.