1. 5
  1. 8

    I was a little sad that this had nothing to do with nix the distribution/package manager/language. :)

    1. 5

      same here… It is probably good warning the author that choosing a name starting with nix, while there is a NixOs distribution, and a Nix language, with tools like nix repl, nix-build, nix-shell, nix-store, nix-env, nix-doc… that such a name may create confusion.

      Just my two cents.

      On the other side, while the *nix acronym was already used in the 2000s, instead of Nix/NixOs, they could have chosen Nyx (the goddess of the Night).

      That makes three cents.

      1. 4

        Better yet, there literally is a nix-info command, generally used for people to include information alongside issue reports.

        $ nix-info -m
         - system: `"x86_64-darwin"`
         - host os: `Darwin 19.5.0, macOS 10.15.5`
         - multi-user?: `no`
         - sandbox: `yes`
         - version: `nix-env (Nix) 2.3.4`
         - channels(abathur): `"darwin, nixpkgs-20.09pre237891.f9eba87bf03"`
         - nixpkgs: `/Users/abathur/.nix-defexpr/channels/nixpkgs`
      2. 2

        Exactly! I came across this crate when I was looking for Nix store support functions, and sadly it was not it. Also, it didn’t support FreeBSD, if I recall correctly, so the crate might be misnamed.

        1. 1

          Not misnamed, just not implemented yet. I feel like for the most part I have the Linux side covered, I still need to implement the BSD side of things.

          I’ve been very busy lately juggling around multiple projects and in real life things, I just haven’t found the time to implement it yet.

      3. 3

        This is my first lib crate in Rust. I feel like enough work has been put into it to warrant it’s own post. Please let me know what you all think, I would really love to make this better!

        It’s a crate which provides functions that output various system info in *nix such as cpu, distro, environment (de/wm), package counts, etc.

        It was initially a part of my rsfetch (neofetch alternative in Rust) rewrite, but I felt like the info gathering functions would go great in a lib crate. And I’m quite happy with the results so far. I feel like this is going quite well for my first lib crate.

        1. 2

          Very cool!

          Might be worth noting that this won’t work at all on any non-Linux systems though (many don’t have /proc, and on some UNIX systems, files in /proc are not plaintext, many don’t have /sys). Would you be interested in advice on how to structure it to be more multi-platform friendly? Or do you want to keep it Linux-specific?

          1. 1

            Thank you.

            I plan on supporting BSDs as well for sure! Otherwise nix (as in *nix) would be a misleading title. I know mostly what I need to do to get them supported, I just haven’t gotten around to implementing it yet. I’m juggling around multiple projects right now, along with various in real life things.

            If there are any other *nix operating systems that people use and would like support for, I’d be more than happy to add it.

            And yeah, advice would be great! :)

          2. 1

            Nice! I’ve had to write a lot of these functions for a project I’m working on so it’ll be convenient to use this in the future.

            Just a note: I got a panic when I tried to get the window manager (I use sway on NixOS). Returning an io::Result for nixinfo::environment() and an Option for nixinfo::env() could work a lot better, especially for headless or strange systems.

            1. 2


              Returning a Result<String> was actually the next thing I had listed for nixinfo. :)

              And I’ll look into Option. I’ve never worked with Options before and this crate was the first time I really started working with Result.

              Thanks for the note.

              Edit: Result<String> and Option<String> have been implemented for environment() and env() respectively.