6 ms·

Nix allows you to perfectly reproduce the on-disk inputs going in to a build, and also completely isolate the build by heavily sandboxing it. But build processe

by catern 9y ago

Nix allows you to perfectly reproduce the on-disk inputs going in to a build, and also completely isolate the build by heavily sandboxing it. But build processes, being a large and complicated function, may not give you bit-for-bit identical output even if all their on-disk inputs are bit-for-bit identical. So it's a good start, but not enough. Distributions like Debian and Arch need to put in a fair bit of effort to reach the same level as Nix. But, in a sense, reaching that level is the "easy" part - it's an interesting technical challenge. The hard part of the reproducible builds effort, the part which Nix doesn't give you, and the part which developers from Debian, Nix, and other distros are still actively working on, is ensuring that bit-for-bit identical on-disk inputs, along with sandboxing, will give you bit-for-bit identical outputs. That is a task which requires cleaning up the build process of the entire open source world.

baldfat 9y ago
We are all still living on 30 year old package management systems and we need a modern approach. I still have hope for flatpak. I want a system where the folder is the application and deleting the folder is the way you remove applications. The devil though is in the details of how or what is shared. Sadly flatpak and snap don't seem to have much in community support. MacOS and OSX seem to be the closest to this idea of the folder being the application. Trying Nix it is just impractical, but I liked the idea.
- jerf 9y ago
  "We are all still living on 30 year old package management systems and we need a modern approach.... Trying Nix it is just impractical, but I liked the idea." There's a causal connection between those two things....
- ufo 9y ago
  Containers are orthogonal to what the parent poster was talking about. Reproduceable builds are a build system problem, not a package distribution or package interoperability problem. Even with containers, being able to reproducibly rebuild the containerized application from its sources if desired is still a challenge.
  - baldfat 9y ago
    > Even with containers, being able to reproducibly rebuild the containerized application from its sources if desired is still a challenge. 1) flatpak runs on a runtime and the application would than be exactly the same on all systems. Just like a Java program or any other programming language that runs on a runtime. 2. flatpak and snap are not for servers, which containers makes more sense because they are solving a different problem than desktops'. So they are more like a sandbox like what we find on tabs in Chrome. > Is Flatpak a container technology? "It can be, but it doesn't have to be. Since a desktop application would require quite extensive changes in order to be usable when run inside a container you will likely see Flatpak mostly deployed as a convenient library bundling technology early on, with the sandboxing or containerization being phased in over time for most applications. In general though we try to avoid using the term container when speaking about Flatpak as it tends to cause comparisons with Docker and rkt, comparisons which quickly stop making technical sense due to the very different problem spaces these technologies try to address. And thus we prefer using the term sandboxing." https://flatpak.org/faq.html https://flatpak.org/faq.html
    - ufo 9y ago
      Java bytecode and the other technologies you mentioned solve the problem of distributing a program so that it can run unmodified on various platforms. Reproduceable builds are not about software distribution, they are about compilation. The Arch Linux maintainers would like to be able to verify that the Java bytecode that they are sending to their users was indeed built from the Java source files that they were expected to be built from. With reproduceable builds anyone can double check that the Java bytecode that is being distributed is the correct one by recompiling it on their own machine. Without reproduceable builds you need to trust that the person who compiled the file didn't do anything malicious (either intentionally or unintentionally)
- keenerd 9y ago
  > I want a system where the folder is the application and deleting the folder is the way you remove applications. ROX has been doing that for like 15 years. http://rox.sourceforge.net/desktop/AppDirs.html http://rox.sourceforge.net/desktop/AppDirs.html
- majewsky 9y ago
  > I want a system where the folder is the application and deleting the folder is the way you remove applications. Why though? There is no difference in complexity between `package-manager uninstall package-name` and `rm -rf /apps/package-name`. If you implement the latter, it will probably be aliased to the former. The biggest problem in any case is not the application's assets (which all package managers manage competently), but its state and configuration files. It took Windows about a decade of carrot and stick to get (most) applications to put their files in a few defined locations instead of all over the place.
  - baldfat 9y ago
    > There is no difference in complexity between `package-manager uninstall package-name` and `rm -rf /apps/package-name` The issue is reproducible and developer complexity. But in terms of complexity you are confusing user complexity and developer complexity. Developer complexity is still high and is the big barrier to Linux development. Also we have the crazy apt-get update vs upgrade fiasco that chocolatey has gotten caught up in. They even made choco update be replaced by upgrade.
- cpburns2009 9y ago
  I still don't understand the fascination with flatpak, snap, etc. In my experience the package managers for Debian, Fedora, and Arch Linux work just fine. I really would prefer not to have 20 different minor versions of the same packages installed because the maintainers were lazy and used fat packages. It may be arguable to use fat packages for games (e.g., to support Steam) because it's my understanding that they have the most quirks of all programs. Nix and Guix do intrigue me though as a potential replacement of the various Linux package managers.
  - rdtsc 9y ago
    > Nix and Guix do intrigue me though as a potential replacement of the various Linux package managers. I am looking at those as well. One appeal is they allow precise tracking of dependencies and seem to support Mac as well, so could set things up easier on developers machines.
  - baldfat 9y ago
    > I still don't understand the fascination with flatpak, snap, etc. In my experience the package managers for Debian, Fedora, and Arch Linux work just fine. It isn't fine for developers or for the Linux ecosystem. Sure it works for users for installing what has been a complex development and packaging system. The problem is exactly that it is hard to distribute applications in Linux. > Flatpak is the next-generation technology for building and installing desktop applications. It has the power to revolutionize the Linux desktop ecosystem. https://flatpak.org/ https://flatpak.org/
    - Spivak 9y ago
      Application developers aren't supposed to be distributing applications. Obviously this is unrealistic and fat packages are a pretty good solution but they're best positioned to be supplementary rather than replacement for disto package managers. > The problem is exactly that it is hard to distribute applications in Linux. For who? Distributions generally seem to like their own packaging processes. You can distribute a package on the AUR in a few lines of bash and it's filled to the brim with software because of it.
- catern 9y ago
  This has absolutely nothing to do with my comment or with reproducible builds. Flatpak does absolutely nothing to help reproducible builds. That's just a statement of fact: It works at a different level of the stack, and solves a different problem.

by catern 9y ago

baldfat 9y ago

We are all still living on 30 year old package management systems and we need a modern approach. I still have hope for flatpak. I want a system where the folder is the application and deleting the folder is the way you remove applications. The devil though is in the details of how or what is shared. Sadly flatpak and snap don't seem to have much in community support. MacOS and OSX seem to be the closest to this idea of the folder being the application. Trying Nix it is just impractical, but I liked the idea.

jerf 9y ago
"We are all still living on 30 year old package management systems and we need a modern approach.... Trying Nix it is just impractical, but I liked the idea." There's a causal connection between those two things....
ufo 9y ago
Containers are orthogonal to what the parent poster was talking about. Reproduceable builds are a build system problem, not a package distribution or package interoperability problem. Even with containers, being able to reproducibly rebuild the containerized application from its sources if desired is still a challenge.
- baldfat 9y ago
  > Even with containers, being able to reproducibly rebuild the containerized application from its sources if desired is still a challenge. 1) flatpak runs on a runtime and the application would than be exactly the same on all systems. Just like a Java program or any other programming language that runs on a runtime. 2. flatpak and snap are not for servers, which containers makes more sense because they are solving a different problem than desktops'. So they are more like a sandbox like what we find on tabs in Chrome. > Is Flatpak a container technology? "It can be, but it doesn't have to be. Since a desktop application would require quite extensive changes in order to be usable when run inside a container you will likely see Flatpak mostly deployed as a convenient library bundling technology early on, with the sandboxing or containerization being phased in over time for most applications. In general though we try to avoid using the term container when speaking about Flatpak as it tends to cause comparisons with Docker and rkt, comparisons which quickly stop making technical sense due to the very different problem spaces these technologies try to address. And thus we prefer using the term sandboxing." https://flatpak.org/faq.html https://flatpak.org/faq.html
  - ufo 9y ago
    Java bytecode and the other technologies you mentioned solve the problem of distributing a program so that it can run unmodified on various platforms. Reproduceable builds are not about software distribution, they are about compilation. The Arch Linux maintainers would like to be able to verify that the Java bytecode that they are sending to their users was indeed built from the Java source files that they were expected to be built from. With reproduceable builds anyone can double check that the Java bytecode that is being distributed is the correct one by recompiling it on their own machine. Without reproduceable builds you need to trust that the person who compiled the file didn't do anything malicious (either intentionally or unintentionally)
keenerd 9y ago
> I want a system where the folder is the application and deleting the folder is the way you remove applications. ROX has been doing that for like 15 years. http://rox.sourceforge.net/desktop/AppDirs.html http://rox.sourceforge.net/desktop/AppDirs.html
majewsky 9y ago
> I want a system where the folder is the application and deleting the folder is the way you remove applications. Why though? There is no difference in complexity between `package-manager uninstall package-name` and `rm -rf /apps/package-name`. If you implement the latter, it will probably be aliased to the former. The biggest problem in any case is not the application's assets (which all package managers manage competently), but its state and configuration files. It took Windows about a decade of carrot and stick to get (most) applications to put their files in a few defined locations instead of all over the place.
- baldfat 9y ago
  > There is no difference in complexity between `package-manager uninstall package-name` and `rm -rf /apps/package-name` The issue is reproducible and developer complexity. But in terms of complexity you are confusing user complexity and developer complexity. Developer complexity is still high and is the big barrier to Linux development. Also we have the crazy apt-get update vs upgrade fiasco that chocolatey has gotten caught up in. They even made choco update be replaced by upgrade.
cpburns2009 9y ago
I still don't understand the fascination with flatpak, snap, etc. In my experience the package managers for Debian, Fedora, and Arch Linux work just fine. I really would prefer not to have 20 different minor versions of the same packages installed because the maintainers were lazy and used fat packages. It may be arguable to use fat packages for games (e.g., to support Steam) because it's my understanding that they have the most quirks of all programs. Nix and Guix do intrigue me though as a potential replacement of the various Linux package managers.
- rdtsc 9y ago
  > Nix and Guix do intrigue me though as a potential replacement of the various Linux package managers. I am looking at those as well. One appeal is they allow precise tracking of dependencies and seem to support Mac as well, so could set things up easier on developers machines.
- baldfat 9y ago
  > I still don't understand the fascination with flatpak, snap, etc. In my experience the package managers for Debian, Fedora, and Arch Linux work just fine. It isn't fine for developers or for the Linux ecosystem. Sure it works for users for installing what has been a complex development and packaging system. The problem is exactly that it is hard to distribute applications in Linux. > Flatpak is the next-generation technology for building and installing desktop applications. It has the power to revolutionize the Linux desktop ecosystem. https://flatpak.org/ https://flatpak.org/
  - Spivak 9y ago
    Application developers aren't supposed to be distributing applications. Obviously this is unrealistic and fat packages are a pretty good solution but they're best positioned to be supplementary rather than replacement for disto package managers. > The problem is exactly that it is hard to distribute applications in Linux. For who? Distributions generally seem to like their own packaging processes. You can distribute a package on the AUR in a few lines of bash and it's filled to the brim with software because of it.
catern 9y ago
This has absolutely nothing to do with my comment or with reproducible builds. Flatpak does absolutely nothing to help reproducible builds. That's just a statement of fact: It works at a different level of the stack, and solves a different problem.