4 ms·

Seems like a great way to help ease contribution. I've never used NixOS, but I wonder how it would compare in this and other ways.

aidenn0 9y ago
I've been using NixOS for a while now. There is a lot to be said for using nix as a development tool &c, but in terms of a daily driver OS: Upside: It really is the best of both worlds for binary/source distros. 99% of the time it just downloads an archive and unpacks it, so it's just as fast to install or upgrade as e.g. arch. On the other hand, patching software from upstream takes seconds to do (not counting the unavoidable build time). Downside: In order to accomplish the upside, it completely changes the filesystem layout. "./configure; make; sudo make install" is basically guaranteed to not work. To install software not in nix, you will be writing a nix expression. There is a command to create an FHS compatible namespace that works for e.g. Steam, but applications installed in there are second-class citizens, so it's preferred to not do this for anything that can simply be installed via a Nix expression.
- ComputerGuru 9y ago
  Have you tried FreeBSD before? It ships with an awesome binary package manager and a virtual tree of sources for all the packages in the package manager at the same time. You can install the binary (sudo pkg install foo) or cd into the source dir, fetch the sources, patch on a whim, then “make” (even if the project upstream does not use make) and install.
  - honr 9y ago
    I have used ports (if that is what you are referring to) albeit on a mac. It is very basic, without any of the interesting properties that make nix interesting. It essentially feels like a slightly improved "download && ./configure && make && make install" script.
    - aidenn0 9y ago
      It does have a usable binary cache, which is absent from other source-based systems glances in portage's direction
  - aidenn0 9y ago
    Ports is great. I have only used FreeBSD lightly, but macports is the only package manager for OS X that has been reliable for me. Nix is not a strict improvement, but it improves things in a lot of directions compared to ports. Hardcoding dependencies at build-time seems to me like a fundamental first step towards a stable system that has been absent from Linux since the late 90s.
- honr 9y ago
  As someone who hasn't actively used nixos (yet), only nix (the package manager) for a while: I have always been curious and dumbfounded why he (Eelco) abandoned Maak (his build system, that I thought, would go together with nix). I think a proper, integrated build system (integrated with nix, the package manager) is a (or the?) missing piece to improve software development.
  - aidenn0 9y ago
    My two current favorite make replacements are redo and tup. They go in opposite directions in replacing make: redo boils down to "How can we capture 99% of the value of make with 1% of the complexity" and does it well. It helps that you don't have to figure out whether sh or make will be interpreting your (similar, yet different enough to trip you up) expressions; redo is "sh all the way down" It also manages to automatically have dependencies on build rules which Make could really use. Tup is more like "How can we limit what make can do in order to make a better special purpose tool?" Tup can't handle files with spaces and implementing "make install" is flat out impossible. It also is very inflexible with your directory tree. However, it is the best tool for "Many files in, one file out, rebuild if any inputs change" and making this implementation tractable is a specific result of being less flexible than make. [edit] Just found the Maak paper: 1) Ports actually does unify building and deployment by using make for deployment 1a) This does require writing (or modifying) makefiles for every single package 2) Nix fits in the same space as Maak, as you use nix both for building and deployment; it just may farm out some of the work to a secondary build system such as make. If you consider the build-script to be the generator (rather than e.g. `cc`) then it maps closely to Maak. 2a) There is no reason I can think of why you couldn't have a nix expression for every single .o file, and have nix-build handle incremental builds for you. 2b) Farming out much of the work to existing build systems is a pragmatic approach to reduce the amount of work needed to create a nix expression. 99% of the time if cmake or autoconf are used, a minimal nix file will give you a mostly working package. This is much more reliable than trying to autoconvert Make (which is composed of two turing complete languages) to some other system. 3) One that the paper claims that only the generators can have complete dependency information (Make, Maak, and Nix all farm out specifying dependency information to the author of the build script; though Nix attempts to prevent you from omitting dependencies by sandboxing), but Tup sidesteps this by sitting between the filesystem and the generator.

aidenn0 9y ago

I've been using NixOS for a while now. There is a lot to be said for using nix as a development tool &c, but in terms of a daily driver OS: Upside: It really is the best of both worlds for binary/source distros. 99% of the time it just downloads an archive and unpacks it, so it's just as fast to install or upgrade as e.g. arch. On the other hand, patching software from upstream takes seconds to do (not counting the unavoidable build time). Downside: In order to accomplish the upside, it completely changes the filesystem layout. "./configure; make; sudo make install" is basically guaranteed to not work. To install software not in nix, you will be writing a nix expression. There is a command to create an FHS compatible namespace that works for e.g. Steam, but applications installed in there are second-class citizens, so it's preferred to not do this for anything that can simply be installed via a Nix expression.

ComputerGuru 9y ago
Have you tried FreeBSD before? It ships with an awesome binary package manager and a virtual tree of sources for all the packages in the package manager at the same time. You can install the binary (sudo pkg install foo) or cd into the source dir, fetch the sources, patch on a whim, then “make” (even if the project upstream does not use make) and install.
- honr 9y ago
  I have used ports (if that is what you are referring to) albeit on a mac. It is very basic, without any of the interesting properties that make nix interesting. It essentially feels like a slightly improved "download && ./configure && make && make install" script.
  - aidenn0 9y ago
    It does have a usable binary cache, which is absent from other source-based systems glances in portage's direction
- aidenn0 9y ago
  Ports is great. I have only used FreeBSD lightly, but macports is the only package manager for OS X that has been reliable for me. Nix is not a strict improvement, but it improves things in a lot of directions compared to ports. Hardcoding dependencies at build-time seems to me like a fundamental first step towards a stable system that has been absent from Linux since the late 90s.
honr 9y ago
As someone who hasn't actively used nixos (yet), only nix (the package manager) for a while: I have always been curious and dumbfounded why he (Eelco) abandoned Maak (his build system, that I thought, would go together with nix). I think a proper, integrated build system (integrated with nix, the package manager) is a (or the?) missing piece to improve software development.
- aidenn0 9y ago
  My two current favorite make replacements are redo and tup. They go in opposite directions in replacing make: redo boils down to "How can we capture 99% of the value of make with 1% of the complexity" and does it well. It helps that you don't have to figure out whether sh or make will be interpreting your (similar, yet different enough to trip you up) expressions; redo is "sh all the way down" It also manages to automatically have dependencies on build rules which Make could really use. Tup is more like "How can we limit what make can do in order to make a better special purpose tool?" Tup can't handle files with spaces and implementing "make install" is flat out impossible. It also is very inflexible with your directory tree. However, it is the best tool for "Many files in, one file out, rebuild if any inputs change" and making this implementation tractable is a specific result of being less flexible than make. [edit] Just found the Maak paper: 1) Ports actually does unify building and deployment by using make for deployment 1a) This does require writing (or modifying) makefiles for every single package 2) Nix fits in the same space as Maak, as you use nix both for building and deployment; it just may farm out some of the work to a secondary build system such as make. If you consider the build-script to be the generator (rather than e.g. `cc`) then it maps closely to Maak. 2a) There is no reason I can think of why you couldn't have a nix expression for every single .o file, and have nix-build handle incremental builds for you. 2b) Farming out much of the work to existing build systems is a pragmatic approach to reduce the amount of work needed to create a nix expression. 99% of the time if cmake or autoconf are used, a minimal nix file will give you a mostly working package. This is much more reliable than trying to autoconvert Make (which is composed of two turing complete languages) to some other system. 3) One that the paper claims that only the generators can have complete dependency information (Make, Maak, and Nix all farm out specifying dependency information to the author of the build script; though Nix attempts to prevent you from omitting dependencies by sandboxing), but Tup sidesteps this by sitting between the filesystem and the generator.