81–90 of 113 posts
I have been exploring nix for the past few months and my experience with nix has been both exhilarating and frustrating, simultaneously. On one hand, I find it hard to imagine not using nix now, but on the other hand, I hesitate to recommend it to other colleagues due to its steep learning curve, ux issues and potential for footguns. I sincerely hope that nix community improves the UX to make it more accessible to ne…
for what specifically?
That being said, that fine-grained layering selection is done via symlinks in Nix afaik, whereas a couple newer packaging systems (e.g. OCI containers or flatpak) can do such layering with newer stuff like bind mounts and namespaces+sandboxing (and I don't just mean sandbox for build time but for run time) and thus increase the security by selectively choosing what a package is supposed to have access to. I wonder how fast Nix will adapt to such new possibilities. I think it should do so quickly (e.g. switch to OCI as the underlying layering system; I hear that the Tvix project is experimenting with that?), as that could establish Nix as the dominant system/distribution in that field whereas otherwise it would be overtaken and left behind by whatever OCI-container-based distribution manages to come out as the dominant one.
There is currently (temporarily) a unique window of opportunity in that:
* Docker is totally ruining their position in the OCI world, and had never really put effort into building a comprehensive quality curated distribution. That is: their registry may be "comprehensive" as in large choice, but apart from a small set of base images, it's mostly a hotchpotch of low-quality uncurated images with uncertain security… and often found to be of severely lacking in the security domain.
* Redhat has a much too closed policy for their OCI registries and has made the mistake of restricting their OCI stuff to the server side while fedora pushes flatpak/flathub which is too restricted to the desktop. That artificial chasm between a server-only and a desktop-only system sucks.
* Ubuntu has completely borked their attempts at new sandboxed/layered package formats, snap sucks. And Debian and the other remaining big distros have nothing in that category
Nix has the advantage of already having a large, comprehensive and curated set of packages. All it needs is to adopt OCI as its underlying layering system (instead of symlinks), make its large package base trivially accessible to OCI, and make an effort on UX (a little more accessible and easier) and it could come out as the dominant distribution.
I have been exploring nix for the past few months and my experience with nix has been both exhilarating and frustrating, simultaneously. On one hand, I find it hard to imagine not using nix now, but on the other hand, I hesitate to recommend it to other colleagues due to its steep learning curve, ux issues and potential for footguns. I sincerely hope that nix community improves the UX to make it more accessible to ne…
The problem with Nix is that I still have to start with a Linux system--so I still need Docker, Terraform, something to give me a stable base for Nix to work against. At that point--why should I add Nix to the mess since I still need those other things anyway?
I have been exploring nix for the past few months and my experience with nix has been both exhilarating and frustrating, simultaneously. On one hand, I find it hard to imagine not using nix now, but on the other hand, I hesitate to recommend it to other colleagues due to its steep learning curve, ux issues and potential for footguns. I sincerely hope that nix community improves the UX to make it more accessible to ne…
Currently working on a graphical UX where you can create and share flakes without writing Nix code at https://mynixos.com The site makes it easy to browse indexed flakes and configure flakes via options and packages. Hopefully the structure provided by the UI can makes it easier to get started with Nix flakes :)
Earlier quoted context omitted.
What I see as a barrier for entry to Nix/NixOS is not the UX, but the available documentation, or lack of thereof. One may consider the docs being part of UX though. I am in the process of writing a book about NixOS, you may track the progress here: https://drakerossman.com/blog/practical-nixos-the-book The emphasis is on how to make it as practical as possible, plus cover the topics which may apply to Linux in gener…
Excited to see this being in progress. Have you checked out the docs effort spun up with the Nix Documentation team?
I like the principle of Nix that one can simultaneously install different versions of the same software and make layered choices of what version to use with what or depending on the use case. Nix has spearheaded that principle and that's great. That being said, that fine-grained layering selection is done via symlinks in Nix afaik, whereas a couple newer packaging systems (e.g. OCI containers or flatpak) can do such…
Oci should adopt a nix based approach.
Earlier quoted context omitted.
I personally would prefer a build and environment tool which uses the modern Linux namespaces to prepare isolated filesystems without needing to reinvent a whole bunch of wheels. A number of problems that I would like to be fixed: - Post-build patches to insure correct shared library paths in artifacts due to requirement to use absolute /nix/store instead of using the traditional Linux filesystem. - Numerous wrappers…
The filesystem complaint seems so fundamental, you might as well be complaining that Linux didn't use C:\ as its filesystem root.
Earlier quoted context omitted.
I personally would prefer a build and environment tool which uses the modern Linux namespaces to prepare isolated filesystems without needing to reinvent a whole bunch of wheels. A number of problems that I would like to be fixed: - Post-build patches to insure correct shared library paths in artifacts due to requirement to use absolute /nix/store instead of using the traditional Linux filesystem. - Numerous wrappers…
> uses the modern Linux namespaces to prepare isolated filesystems without needing to reinvent a whole bunch of wheels. I'm confused; Nix mostly works by passing the '--prefix' argument to standard, off-the-shelf configure scripts. Some build/packaging tools don't seem to work with a user-chosen prefix, and hence need some sort of workarounds; but that's surely a fault with those tools. > Horrible-horrible way to com…
Honestly I don't think so, in modern Linux namespaces it's perfectly possible to run them in isolated filesystems and to provide whatever they want at whatever paths they want without patches and workarounds. Instead Nix forces it's way up at the build level, so whatever artifact you get as a result of Nix derivation is suitable for running in a Nix system alone. I'd rather build a generic artifact that could be run in a traditional Linux system and let the user decide how it want to store it, instead of forcing the Nix way.
> I've never experienced a problem with it
There are problems with gcc-compiled binaries for example, and they are solved with a post-compilation patch. This is a workaround which does not scale and shouldn't be there in the first place, but that's mainly not gcc's problem in my eyes (although it could've done a better job too).
> The Nix store provides quite a nice separation between the "definition" side and the "building" side.
Somewhere deep inside it indeed does, there is no Nix the lang in final derivations. Nevertheless, I had too much trouble working at that level.