8 ms·

After having moved to NixOS, this type of evolution feels archaic.

by mongol 3y ago

charcircuit 3y ago
NixOS itself still also has problems. The configuration / state for a program is scattered between /etc /nix/store ~ ~/.config /var instead of being in a centralized place. An application can be thought of as a combination of the binary, libraries, resources, and state. By default the applications needs to be able to read any of these and be able to read and write the state. Unix's FSH's biggest problem is that it tries to group files together by type instead of grouping files together by application. Nix can technically group things by application, but it is not really standardized so things can get messy and it is still normal for applications to read and write files from anywhere.
- someplaceguy 3y ago
  > NixOS itself still also has problems. The configuration / state for a program is scattered between /etc /nix/store ~ ~/.config /var instead of being in a centralized place. Those are features, not bugs... There are reasons for all of those existing and for why you wouldn't want everything in a centralized place.
  - charcircuit 3y ago
    The same could be said about having /bin /lib /usr/bin /usr/sbin /usr/lib /usr/local/bin /usr/local/lib ... yet these were all merged into /nix/store. NixOS's handling of state is poor. Even ignoring the problem of it all being spread out it is not uncommon for secrets to make it into /nix/store which is world readable.
    - mongol 3y ago
      Secrets handling is indeed an issue, you can shoot yourself in the foot if you are not careful. If you are careful you can avoid it though and it is not neccessarily difficult. It is certainly is one aspect of NixOS that requires care and can be improved. But to me, it is not so bad as to avoid it. The advantages outweigh the disadvantages with a wide margin
    - someplaceguy 3y ago
      Well, good luck convincing anyone to merge all config and mutable state into the same place (that should be fun, especially the user-specific config/state) :) > NixOS's handling of state is poor. Even ignoring the problem of it all being spread out it is not uncommon for secrets to make it into /nix/store which is world readable. The secrets handling is a well-known issue and easy to avoid when you're familiar with Nix. Although yes, it can be a problem when people are not aware of it. And I disagree with NixOS's handling of state being poor. Apart from this "secrets" problem you mentioned, it's not worse than other Linux-based operating systems and in fact it can be argued that it's significantly better. Just the fact that /nix/store is mounted read-only is, on its own, already a huge improvement over letting users and applications installing and modifying the system in an ad-hoc fashion (good luck when you upgrade your system!). Not to mention all the other advantages of /nix/store (such as user-installed applications, no package or library conflicts even if you install multiple versions of them, etc). And as another example, the `stateVersion` feature is something that also makes upgrades a lot more reliable, and I know of no other operating system that has a similar feature. Atomic configuration changes, booting into specific configurations, and system-wide configuration roll-backs (configurations which also include changes in package versions or even entire OS upgrades), also makes upgrades and configuration changes easy to try / fix if anything goes wrong. No other widely-used operating system has such a reliable configuration change mechanism, as far as I know. But, you know, if you have other ideas of how things can be improved (apart from your idea of merging user and system-wide state into the same place, which I think makes no sense), I would definitely appreciate to hear it!
      - charcircuit 3y ago
        >Well, good luck convincing anyone to merge all config and mutable state into the same place It will need to happen sooner or later once distros realize that security is important. >it's not worse than other Linux-based operating systems I was not talking in relative terms. NixOS made steps in the right direction, but there is still much more that can be done.
        someplaceguy 3y ago
        If you can think of a concrete and detailed, workable proposal, maybe you could write up a NixOS RFC and send a PR for discussion (or post something on the discourse community website?). Who knows, maybe something can be fleshed out and improvements come out of it...
- viraptor 3y ago
  > The configuration / state for a program is scattered between /etc /nix/store ~ ~/.config /var That's not really scattered. /nix/store has the generated files. They get linked to /etc if the app requires that kind of thing - often it's just added to the arguments instead. ~/.config is for user preferences (possible to flip at app runtime or static) which are not a system setting. /var is for system services states. Those are very separate use cases and get managed in different ways. The apps should also never be aware that /nix/store is a thing.
  - charcircuit 3y ago
    >Those are very separate use cases and get managed in different ways. To me they all look the same. For example you could have a /nix/state that had a directory for each program. Each program could have its own global and user specific state it could manage from within its directory.
    - viraptor 3y ago
      What would be the benefits of merging those?
      - charcircuit 3y ago
        It's simpler and would allow you to do sandboxing by not exposing your entire filesystem to a program.
        viraptor 3y ago
        This is already done in nixos for daemons: https://github.com/NixOS/nixpkgs/blob/65a62c9f75dc97714f836cae40656c254261f7a3/nixos/modules/services/backup/snapraid.nix#L176 https://github.com/NixOS/nixpkgs/blob/65a62c9f75dc97714f836c... and that's on top of the usual stuff systemd exposes. Then you get firejail for more custom apps. You still need that layer and needs to be configured per-app. Would moving config+state into one path really improve the experience? In what way would it be simpler?
    - 3y ago
RamRodification 3y ago
Why? (I'm clueless about NixOS. I think it's a way of declaring your whole Linux install as some kind of recipe file or something?)
- mongol 3y ago
  In NixOS, programs are installed in many different unique paths that are added to PATH through symlinks. There are very few programs added to static directories such as /usr/bin. This in itself may not sound like an improvement, but NixOS as a whole has a very different idea how to manage dependencies. Difficult to explain well, but it feels like fresh air compared to the slow evolution of historical Unix principles that most other Linux distributions follow.
  - PrimeMcFly 3y ago
    So you can't easily see which programs are installed in a directory, it's all abstracted away in a database? That sounds horrible. NixOS sounded kind of interesting, but if that's true it kills any interest I had in it.
    - mongol 3y ago
      It is called the Nix store, it is not a database as much as a special type of file hierarchy. It is not horrible, but it breaks tradition for sure. The benefits are best understood when evaluating NixOS as a whole, of which the file hierarchy is just a part.
      - PrimeMcFly 3y ago
        Thanks for clarifying.
        db48x 3y ago
        One of the main benefits is that you can have multiple versions of something installed in the store, with individual environments pulling in the specific version that they require. Makes it really easy (or at least possible) to keep old software running, or to keep multiple environments running on the same computer even though the people who use them don't cooperate.
doublepg23 3y ago
I feel like NixOS should've gone just a bit further and look closer to GoboLinux. https://wiki.gobolinux.org/Overview/GoboLinux-Filesystem-Hierarchy/index.html https://wiki.gobolinux.org/Overview/GoboLinux-Filesystem-Hie...
- mongol 3y ago
  I have never heard about GoboLinux. The linked page gives me the impression that GoboLinix tries to improve the FHS by using more self-describing directory names? But still follow the general principles of splitting a program's dependencies into a statically defined directory structure?

After having moved to NixOS, this type of evolution feels archaic.

by mongol 3y ago

After having moved to NixOS, this type of evolution feels archaic.

NixOS itself still also has problems. The configuration / state for a program is scattered between /etc /nix/store ~ ~/.config /var instead of being in a centralized place. An application can be thought of as a combination of the binary, libraries, resources, and state. By default the applications needs to be able to read any of these and be able to read and write the state. Unix's FSH's biggest problem is that it tries to group files together by type instead of grouping files together by application. Nix can technically group things by application, but it is not really standardized so things can get messy and it is still normal for applications to read and write files from anywhere.

someplaceguy 3y ago
> NixOS itself still also has problems. The configuration / state for a program is scattered between /etc /nix/store ~ ~/.config /var instead of being in a centralized place. Those are features, not bugs... There are reasons for all of those existing and for why you wouldn't want everything in a centralized place.
- charcircuit 3y ago
  The same could be said about having /bin /lib /usr/bin /usr/sbin /usr/lib /usr/local/bin /usr/local/lib ... yet these were all merged into /nix/store. NixOS's handling of state is poor. Even ignoring the problem of it all being spread out it is not uncommon for secrets to make it into /nix/store which is world readable.
  - mongol 3y ago
    Secrets handling is indeed an issue, you can shoot yourself in the foot if you are not careful. If you are careful you can avoid it though and it is not neccessarily difficult. It is certainly is one aspect of NixOS that requires care and can be improved. But to me, it is not so bad as to avoid it. The advantages outweigh the disadvantages with a wide margin
  - someplaceguy 3y ago
    Well, good luck convincing anyone to merge all config and mutable state into the same place (that should be fun, especially the user-specific config/state) :) > NixOS's handling of state is poor. Even ignoring the problem of it all being spread out it is not uncommon for secrets to make it into /nix/store which is world readable. The secrets handling is a well-known issue and easy to avoid when you're familiar with Nix. Although yes, it can be a problem when people are not aware of it. And I disagree with NixOS's handling of state being poor. Apart from this "secrets" problem you mentioned, it's not worse than other Linux-based operating systems and in fact it can be argued that it's significantly better. Just the fact that /nix/store is mounted read-only is, on its own, already a huge improvement over letting users and applications installing and modifying the system in an ad-hoc fashion (good luck when you upgrade your system!). Not to mention all the other advantages of /nix/store (such as user-installed applications, no package or library conflicts even if you install multiple versions of them, etc). And as another example, the `stateVersion` feature is something that also makes upgrades a lot more reliable, and I know of no other operating system that has a similar feature. Atomic configuration changes, booting into specific configurations, and system-wide configuration roll-backs (configurations which also include changes in package versions or even entire OS upgrades), also makes upgrades and configuration changes easy to try / fix if anything goes wrong. No other widely-used operating system has such a reliable configuration change mechanism, as far as I know. But, you know, if you have other ideas of how things can be improved (apart from your idea of merging user and system-wide state into the same place, which I think makes no sense), I would definitely appreciate to hear it!
    - charcircuit 3y ago
      >Well, good luck convincing anyone to merge all config and mutable state into the same place It will need to happen sooner or later once distros realize that security is important. >it's not worse than other Linux-based operating systems I was not talking in relative terms. NixOS made steps in the right direction, but there is still much more that can be done.
      - someplaceguy 3y ago
        If you can think of a concrete and detailed, workable proposal, maybe you could write up a NixOS RFC and send a PR for discussion (or post something on the discourse community website?). Who knows, maybe something can be fleshed out and improvements come out of it...
viraptor 3y ago
> The configuration / state for a program is scattered between /etc /nix/store ~ ~/.config /var That's not really scattered. /nix/store has the generated files. They get linked to /etc if the app requires that kind of thing - often it's just added to the arguments instead. ~/.config is for user preferences (possible to flip at app runtime or static) which are not a system setting. /var is for system services states. Those are very separate use cases and get managed in different ways. The apps should also never be aware that /nix/store is a thing.
- charcircuit 3y ago
  >Those are very separate use cases and get managed in different ways. To me they all look the same. For example you could have a /nix/state that had a directory for each program. Each program could have its own global and user specific state it could manage from within its directory.
  - viraptor 3y ago
    What would be the benefits of merging those?
    - charcircuit 3y ago
      It's simpler and would allow you to do sandboxing by not exposing your entire filesystem to a program.
      - viraptor 3y ago
        This is already done in nixos for daemons: https://github.com/NixOS/nixpkgs/blob/65a62c9f75dc97714f836cae40656c254261f7a3/nixos/modules/services/backup/snapraid.nix#L176 https://github.com/NixOS/nixpkgs/blob/65a62c9f75dc97714f836c... and that's on top of the usual stuff systemd exposes. Then you get firejail for more custom apps. You still need that layer and needs to be configured per-app. Would moving config+state into one path really improve the experience? In what way would it be simpler?
  - 3y ago

RamRodification 3y ago

Why? (I'm clueless about NixOS. I think it's a way of declaring your whole Linux install as some kind of recipe file or something?)

mongol 3y ago
In NixOS, programs are installed in many different unique paths that are added to PATH through symlinks. There are very few programs added to static directories such as /usr/bin. This in itself may not sound like an improvement, but NixOS as a whole has a very different idea how to manage dependencies. Difficult to explain well, but it feels like fresh air compared to the slow evolution of historical Unix principles that most other Linux distributions follow.
- PrimeMcFly 3y ago
  So you can't easily see which programs are installed in a directory, it's all abstracted away in a database? That sounds horrible. NixOS sounded kind of interesting, but if that's true it kills any interest I had in it.
  - mongol 3y ago
    It is called the Nix store, it is not a database as much as a special type of file hierarchy. It is not horrible, but it breaks tradition for sure. The benefits are best understood when evaluating NixOS as a whole, of which the file hierarchy is just a part.
    - PrimeMcFly 3y ago
      Thanks for clarifying.
      - db48x 3y ago
        One of the main benefits is that you can have multiple versions of something installed in the store, with individual environments pulling in the specific version that they require. Makes it really easy (or at least possible) to keep old software running, or to keep multiple environments running on the same computer even though the people who use them don't cooperate.

doublepg23 3y ago

I feel like NixOS should've gone just a bit further and look closer to GoboLinux. https://wiki.gobolinux.org/Overview/GoboLinux-Filesystem-Hierarchy/index.html https://wiki.gobolinux.org/Overview/GoboLinux-Filesystem-Hie...

mongol 3y ago
I have never heard about GoboLinux. The linked page gives me the impression that GoboLinix tries to improve the FHS by using more self-describing directory names? But still follow the general principles of splitting a program's dependencies into a statically defined directory structure?