4 ms·

> nix/store/24v9wpp393ib1gllip7ic13aycbi704g-ruby-3.3.9.drv A different type of madness, but are ugly names so common, why not start with ruby-3.3.9 so any lis

by eviks 1y ago

> nix/store/24v9wpp393ib1gllip7ic13aycbi704g-ruby-3.3.9.drv A different type of madness, but are ugly names so common, why not start with ruby-3.3.9 so any list of files is semantically sorted/readable?

rkomorn 1y ago
The package name is "secondary" information in this context. The hash is the primary one because it's stable unless the input changes. The semantic is "what did this configuration generate", not "what's this package's version".
- eviks 1y ago
  it's primary for every human involved, also, the way you check whether it's changed is by automatically comparing that full hash, not its starting symbols, so you don't care where in the full string it's positioned > The semantic is "what did this configuration generate", not "what's this package's version". Then why have the name/version at all like in those nameless cache dirs?
  - rkomorn 1y ago
    It made sense to me when I looked at it, at mount points, at when it changed vs when it didn't, etc, so IDK what to tell you. FWIW, I'm also pretty sure I'm human. Edit: also, I'm pretty sure that I wouldn't find it any more or less complicated if the package name came first.
    - eviks 1y ago
      > at when it changed vs when it didn't You still have this information! Just in a way where it becomes easier to track the difference or see how many rubies you have etc > FWIW, I'm also pretty sure I'm human. So you do read the "ruby" name/version , not just the hash?
      - rkomorn 1y ago
        I don't care how many rubies I have, except for disk space, which I clean up regularly, so it's a bit moot. I actually don't look at the package names either as much as I look at the number of hashes, which I find easy to eyeball. Quite frankly, I don't really look at the paths anyway (on any kind of regular basis). I just know that when I've looked at them, the hash vs package name thing made sense to me because of the configuration -> result relationship. :) Edit: oh, when I said I'm pretty sure I'm human, I meant "I'm human too but I don't seem to be seeing things the same way you do".
        eviks 1y ago
        > I don't care how many rubies I have, except for disk space, which I clean up regularly, so it's a bit moot. So you do care about how many rubies you have (one of the nix issues is indeed its size), especially if it's not a ruby but some bigger dependency. Your solution is doing regular cleanup, another option would be to casually notice while browsing in a file manager or even clicking the "size" column, in which case reading left to right from the name would help noticing the dupes and maybe doing something about it. > Quite frankly, I don't really look at the paths anyway So you were just arguing for the fun of it based on a superficial theory? > I'm human too but I don't seem to be seeing things the same way you do Yeah you do, you read left to right and there is no way you read "sadlfkjasdlfwroiupdfoser" as well as you read "ruby-1.2.3". Though since you don't actually read that you don't care about it, that's also human, though not the level of human that matters for this argument
        rkomorn 1y ago
        > So you do care about how many rubies you have No, I care about how many leftover rebuilds I have that I no longer use (typically all of them). Couldn't care less about any individual packages because I leave it to Nix to know what should be installed and what shouldn't. I don't casually browse through the stores because I have no reason to. > So you were just arguing for the fun of it based on a superficial theory? Arguing? That's not what I'm doing, but maybe it's how you feel. Your initial post was a question. I replied to it. I guess your question was rhetorical, based on your responses to my comments. I was giving you my perspective. My various dealings with the paths comes from various adventures of debugging why my configs didn't produce what I thought (eg things not in path). It's also probably why I see the relationship as starting with config and ending with path on disk. I have never gone on fishing expeditions around store paths. When I go out of my homedir and "root" fs, I know what hash I want from looking at a symlink, or some log output.
    - jancsika 1y ago
      > Edit: also, I'm pretty sure that I wouldn't find it any more or less complicated if the package name came first. rkomorn.skills.tty.tab_completion -= 1;
      - rkomorn 1y ago
        Yeah, okay. Super cool HN comment quality.
singron 1y ago
It really doesn't matter. As a normal user, you don't use `drv` files directly, and everything you configure yourself will use attribute paths in nixpkgs. E.g. `pkgs.ruby` or `pkgs.ruby_3_3`.
Kootle 1y ago
In nix packages (derivations) are so lightweight that your store has tens of thousands of them, many with the same name, or with no meaningful name at all. On the rare occasions that you need to look in the store for a package you’re much more likely to be looking for a particular hash than a particular name. That, and having the hash as a prefix looks nicer in tabular output.
- Ericson2314 1y ago
  If I had my way 1. store paths would have no names at all 2. listing the contents of the store directory would not be allowed 3. store paths have more bits of information Then store paths are halfway decent (but non-revocable) capabilities.
  - vatsachakrvthy 1y ago
    How could one debug if we couldn't view contents of the store directory?
    - Ericson2314 1y ago
      You can still read individual store objects in their entirety. You just need to know the store path for the object that you want to read. You can still use root or something to list all the store paths. (But ideally nothing else would be running as root / with that power.)
  - eviks 1y ago
    > 2. listing the contents of the store directory would not be allowed Wow, that's awful, that's what Windows AppStore does, so it's even hard to see how much of the preinstalled garbage there is or even whether you might have a huge game you forgot to uninstall but might want to to free up some space. What's the cool benefit that could justify this limitation?
    - deleted 1y ago
      [deleted]
otabdeveloper4 1y ago
It's done that way on purpose. Precisely so you don't try to use the paths semantically. The names literally mean nothing in this context.
- eviks 1y ago
  That contradicts the simple fact that the name includes "ruby" and isn't just a hash
  - otabdeveloper4 1y ago
    That name is only there for debugging purposes. It doesn't actually mean anything and you only ever need to look at it to debug some hoary failing build.
XorNot 1y ago
The reason it's like this is because the only way to reliably grab it is to cut the string at the first hyphen - then the rest can be almost free text. It you do it the other way it's harder. You can try this with nix commands /nix/store/<hash>-x is a valid way to refer to something in the store most of the time.
- Kudos 1y ago
  You could just use the last hyphen. It's not as simple since you need to scan the whole string, but it certainly doesn't seem like a challenge to me.
  - XorNot 1y ago
    Yes but why pay that runtime cost for a problem the user can solve in human time using grep?
whacked_new 1y ago
I can't find the video of the talk where either Eelco Dolstra (nix) or Todd Gamblin (spack) talks about this, but IIRC it's a design decision; you generally don't go spelunking in the nix store, but if you do, and you ls /nix/store, you'll see a huge list of packages, and due to the hash being a constant length, you can visually separate the tails of the package names like 0009flr197p89fz2vg032g556014z7v1-libass-0.17.3.drv 000ghm78048kh2prsfzkf93xm3803m0r-default.md 001f6fysrshkq7gaki4lv8qkl38vjr6a-python-runtime-deps-check-hook.sh.drv 001gp43bjqzx60cg345n2slzg7131za8-nix-nss-open-files.patch 001im7qm8achbyh0ywil6hif6rqf284z-bootstrap-stage0-binutils-wrapper-boot.drv 001pc0cpvpqix4hy9z296qnp0yj00f4n-zbmath-review-template.r59693.tar.xz.drv Spack, another deterministic builder / package manager, IIRC uses the reversed order so the hash is at the tail. Pros/cons under different search / inspection conditions.
- setheron 1y ago
  I would be interested in that video.
- eviks 1y ago
  > Pros/cons under different search / inspection conditions. But what's the pro? The tail alignment is worse than the head alignment since you read head to tail, not the other way aground
  - whacked_new 1y ago
    Comparing nix style (hash head, package tail), and spack style (package head hash tail), and speaking from my own limited experience, the need arises in different cases, which also depends on the ease of tooling, sometimes I'm grepping in /nix/store and you have (as shown earlier) a list of derivation paths like this $ ls /nix/store | grep nodejs-2 | head | sed 's/^/ /' 0a9kkw6mh0f80jfq1nf9767hvg5gr71k-nodejs-22.18.0.drv 0pmximcv91ilgxcf9n11mmxivcwrczaa-nodejs-22.14.0-source.drv 0zzxnv3kap4r4c401micrsr3nrhf87pa-nodejs-20.18.1-fish-completions.drv 2a7y7d38x8kwa8hdj6p93izvrcl9bfga-nodejs-22.11.0-source.drv 2gcjb0dibjw8c1pp45593ykjqzq5sknm-nodejs-20.18.1-source.drv and thus as designed, your eyes ignore the block of hashes and you see the "nodejs-..." stuff You might ask why are you grepping? Because it's fast and familiar and I don't know the native tooling as easily (possibly a UX problem). Then in spack (see https://spack.readthedocs.io/en/latest/package_fundamentals.html https://spack.readthedocs.io/en/latest/package_fundamentals....) they have $ spack find --paths ==> 74 installed packages. -- linux-debian7-x86_64 / gcc@4.4.7 -------------------------------- ImageMagick@6.8.9-10 ~/spack/opt/linux-debian7-x86_64/gcc@4.4.7/ImageMagick@6.8.9-10-4df950dd adept-utils@1.0 ~/spack/opt/linux-debian7-x86_64/gcc@4.4.7/adept-utils@1.0-5adef8da atk@2.14.0 ~/spack/opt/linux-debian7-x86_64/gcc@4.4.7/atk@2.14.0-3d09ac09 and $ spack find --format "{name}-{version}-{hash}" autoconf-2.69-icynozk7ti6h4ezzgonqe6jgw5f3ulx4 automake-1.16.1-o5v3tc77kesgonxjbmeqlwfmb5qzj7zy bzip2-1.0.6-syohzw57v2jfag5du2x4bowziw3m5p67 bzip2-1.0.8-zjny4jwfyvzbx6vii3uuekoxmtu6eyuj cmake-3.15.1-7cf6onn52gywnddbmgp7qkil4hdoxpcb you get the package name immediately from the left, which is nice, and you can pipe that straight to `sort`, but where the hash starts is more jagged on the right so there's a bit more noise when you're looking at the numbers. In the end the information is identical and it's a UX difference. Tradeoffs wise I think they both made the right choice. Because for nix, the packages are almost always in /nix/store, so the path length including the hash is almost always the same. For spack you can place your packages anywhere so the base directories can be highly variable, and so it's sensible to have the package names immediately after the package directory. Or, I'm just trying to rationalize the choices each designer made post-hoc. But after using both I appreciate the design considerations that went in. In the end, humans are inefficient. When I make name / version / hash identifiers in my own applications I end up using one or the either design.

by eviks 1y ago

rkomorn 1y ago

The package name is "secondary" information in this context. The hash is the primary one because it's stable unless the input changes. The semantic is "what did this configuration generate", not "what's this package's version".

eviks 1y ago
it's primary for every human involved, also, the way you check whether it's changed is by automatically comparing that full hash, not its starting symbols, so you don't care where in the full string it's positioned > The semantic is "what did this configuration generate", not "what's this package's version". Then why have the name/version at all like in those nameless cache dirs?
- rkomorn 1y ago
  It made sense to me when I looked at it, at mount points, at when it changed vs when it didn't, etc, so IDK what to tell you. FWIW, I'm also pretty sure I'm human. Edit: also, I'm pretty sure that I wouldn't find it any more or less complicated if the package name came first.
  - eviks 1y ago
    > at when it changed vs when it didn't You still have this information! Just in a way where it becomes easier to track the difference or see how many rubies you have etc > FWIW, I'm also pretty sure I'm human. So you do read the "ruby" name/version , not just the hash?
    - rkomorn 1y ago
      I don't care how many rubies I have, except for disk space, which I clean up regularly, so it's a bit moot. I actually don't look at the package names either as much as I look at the number of hashes, which I find easy to eyeball. Quite frankly, I don't really look at the paths anyway (on any kind of regular basis). I just know that when I've looked at them, the hash vs package name thing made sense to me because of the configuration -> result relationship. :) Edit: oh, when I said I'm pretty sure I'm human, I meant "I'm human too but I don't seem to be seeing things the same way you do".
      - eviks 1y ago
        > I don't care how many rubies I have, except for disk space, which I clean up regularly, so it's a bit moot. So you do care about how many rubies you have (one of the nix issues is indeed its size), especially if it's not a ruby but some bigger dependency. Your solution is doing regular cleanup, another option would be to casually notice while browsing in a file manager or even clicking the "size" column, in which case reading left to right from the name would help noticing the dupes and maybe doing something about it. > Quite frankly, I don't really look at the paths anyway So you were just arguing for the fun of it based on a superficial theory? > I'm human too but I don't seem to be seeing things the same way you do Yeah you do, you read left to right and there is no way you read "sadlfkjasdlfwroiupdfoser" as well as you read "ruby-1.2.3". Though since you don't actually read that you don't care about it, that's also human, though not the level of human that matters for this argument
        rkomorn 1y ago
        > So you do care about how many rubies you have No, I care about how many leftover rebuilds I have that I no longer use (typically all of them). Couldn't care less about any individual packages because I leave it to Nix to know what should be installed and what shouldn't. I don't casually browse through the stores because I have no reason to. > So you were just arguing for the fun of it based on a superficial theory? Arguing? That's not what I'm doing, but maybe it's how you feel. Your initial post was a question. I replied to it. I guess your question was rhetorical, based on your responses to my comments. I was giving you my perspective. My various dealings with the paths comes from various adventures of debugging why my configs didn't produce what I thought (eg things not in path). It's also probably why I see the relationship as starting with config and ending with path on disk. I have never gone on fishing expeditions around store paths. When I go out of my homedir and "root" fs, I know what hash I want from looking at a symlink, or some log output.
  - jancsika 1y ago
    > Edit: also, I'm pretty sure that I wouldn't find it any more or less complicated if the package name came first. rkomorn.skills.tty.tab_completion -= 1;
    - rkomorn 1y ago
      Yeah, okay. Super cool HN comment quality.

singron 1y ago

It really doesn't matter. As a normal user, you don't use `drv` files directly, and everything you configure yourself will use attribute paths in nixpkgs. E.g. `pkgs.ruby` or `pkgs.ruby_3_3`.

Kootle 1y ago

In nix packages (derivations) are so lightweight that your store has tens of thousands of them, many with the same name, or with no meaningful name at all. On the rare occasions that you need to look in the store for a package you’re much more likely to be looking for a particular hash than a particular name. That, and having the hash as a prefix looks nicer in tabular output.

Ericson2314 1y ago
If I had my way 1. store paths would have no names at all 2. listing the contents of the store directory would not be allowed 3. store paths have more bits of information Then store paths are halfway decent (but non-revocable) capabilities.
- vatsachakrvthy 1y ago
  How could one debug if we couldn't view contents of the store directory?
  - Ericson2314 1y ago
    You can still read individual store objects in their entirety. You just need to know the store path for the object that you want to read. You can still use root or something to list all the store paths. (But ideally nothing else would be running as root / with that power.)
- eviks 1y ago
  > 2. listing the contents of the store directory would not be allowed Wow, that's awful, that's what Windows AppStore does, so it's even hard to see how much of the preinstalled garbage there is or even whether you might have a huge game you forgot to uninstall but might want to to free up some space. What's the cool benefit that could justify this limitation?
  - deleted 1y ago
    [deleted]

otabdeveloper4 1y ago

It's done that way on purpose. Precisely so you don't try to use the paths semantically. The names literally mean nothing in this context.

eviks 1y ago
That contradicts the simple fact that the name includes "ruby" and isn't just a hash
- otabdeveloper4 1y ago
  That name is only there for debugging purposes. It doesn't actually mean anything and you only ever need to look at it to debug some hoary failing build.

XorNot 1y ago

The reason it's like this is because the only way to reliably grab it is to cut the string at the first hyphen - then the rest can be almost free text. It you do it the other way it's harder. You can try this with nix commands /nix/store/<hash>-x is a valid way to refer to something in the store most of the time.

Kudos 1y ago
You could just use the last hyphen. It's not as simple since you need to scan the whole string, but it certainly doesn't seem like a challenge to me.
- XorNot 1y ago
  Yes but why pay that runtime cost for a problem the user can solve in human time using grep?

whacked_new 1y ago

I can't find the video of the talk where either Eelco Dolstra (nix) or Todd Gamblin (spack) talks about this, but IIRC it's a design decision; you generally don't go spelunking in the nix store, but if you do, and you ls /nix/store, you'll see a huge list of packages, and due to the hash being a constant length, you can visually separate the tails of the package names like 0009flr197p89fz2vg032g556014z7v1-libass-0.17.3.drv 000ghm78048kh2prsfzkf93xm3803m0r-default.md 001f6fysrshkq7gaki4lv8qkl38vjr6a-python-runtime-deps-check-hook.sh.drv 001gp43bjqzx60cg345n2slzg7131za8-nix-nss-open-files.patch 001im7qm8achbyh0ywil6hif6rqf284z-bootstrap-stage0-binutils-wrapper-boot.drv 001pc0cpvpqix4hy9z296qnp0yj00f4n-zbmath-review-template.r59693.tar.xz.drv Spack, another deterministic builder / package manager, IIRC uses the reversed order so the hash is at the tail. Pros/cons under different search / inspection conditions.

setheron 1y ago
I would be interested in that video.
eviks 1y ago
> Pros/cons under different search / inspection conditions. But what's the pro? The tail alignment is worse than the head alignment since you read head to tail, not the other way aground
- whacked_new 1y ago
  Comparing nix style (hash head, package tail), and spack style (package head hash tail), and speaking from my own limited experience, the need arises in different cases, which also depends on the ease of tooling, sometimes I'm grepping in /nix/store and you have (as shown earlier) a list of derivation paths like this $ ls /nix/store | grep nodejs-2 | head | sed 's/^/ /' 0a9kkw6mh0f80jfq1nf9767hvg5gr71k-nodejs-22.18.0.drv 0pmximcv91ilgxcf9n11mmxivcwrczaa-nodejs-22.14.0-source.drv 0zzxnv3kap4r4c401micrsr3nrhf87pa-nodejs-20.18.1-fish-completions.drv 2a7y7d38x8kwa8hdj6p93izvrcl9bfga-nodejs-22.11.0-source.drv 2gcjb0dibjw8c1pp45593ykjqzq5sknm-nodejs-20.18.1-source.drv and thus as designed, your eyes ignore the block of hashes and you see the "nodejs-..." stuff You might ask why are you grepping? Because it's fast and familiar and I don't know the native tooling as easily (possibly a UX problem). Then in spack (see https://spack.readthedocs.io/en/latest/package_fundamentals.html https://spack.readthedocs.io/en/latest/package_fundamentals....) they have $ spack find --paths ==> 74 installed packages. -- linux-debian7-x86_64 / gcc@4.4.7 -------------------------------- ImageMagick@6.8.9-10 ~/spack/opt/linux-debian7-x86_64/gcc@4.4.7/ImageMagick@6.8.9-10-4df950dd adept-utils@1.0 ~/spack/opt/linux-debian7-x86_64/gcc@4.4.7/adept-utils@1.0-5adef8da atk@2.14.0 ~/spack/opt/linux-debian7-x86_64/gcc@4.4.7/atk@2.14.0-3d09ac09 and $ spack find --format "{name}-{version}-{hash}" autoconf-2.69-icynozk7ti6h4ezzgonqe6jgw5f3ulx4 automake-1.16.1-o5v3tc77kesgonxjbmeqlwfmb5qzj7zy bzip2-1.0.6-syohzw57v2jfag5du2x4bowziw3m5p67 bzip2-1.0.8-zjny4jwfyvzbx6vii3uuekoxmtu6eyuj cmake-3.15.1-7cf6onn52gywnddbmgp7qkil4hdoxpcb you get the package name immediately from the left, which is nice, and you can pipe that straight to `sort`, but where the hash starts is more jagged on the right so there's a bit more noise when you're looking at the numbers. In the end the information is identical and it's a UX difference. Tradeoffs wise I think they both made the right choice. Because for nix, the packages are almost always in /nix/store, so the path length including the hash is almost always the same. For spack you can place your packages anywhere so the base directories can be highly variable, and so it's sensible to have the package names immediately after the package directory. Or, I'm just trying to rationalize the choices each designer made post-hoc. But after using both I appreciate the design considerations that went in. In the end, humans are inefficient. When I make name / version / hash identifiers in my own applications I end up using one or the either design.