5 ms·

I guess it's just up to someone to set up the package on debian that contains all of these

michaelmior 4y ago
That doesn't solve the "available everywhere" problem. It potentially would make the tools easier to install on Debian-based systems, if you have root access. I'm not sure any new set of tools will ever be available with the ubiquity of coreutils in the next handful of years, if ever.
- sitkack 4y ago
  Install rustup from https://rustup.rs/ https://rustup.rs/ cargo install broot exa miniserve ripgrep tuc xh xsv zellij Cargo is the package manager you are looking for.
  - michaelmior 4y ago
    I use Cargo regularly and rustup it does make it easy to install. That's not the point. I'm not looking for a package manger. I want to be able to write scripts that make use of tools I can pretty much guarantee are already installed.
    - sitkack 4y ago
      So we aren't talking past each other, how do you delineate between cargo and a package manager? Does anaconda, pip (pypi) or homebrew also qualify? Your scripts could have a prolog that installs rustup and calls cargo. There is also https://github.com/ryankurte/cargo-binstall https://github.com/ryankurte/cargo-binstall Even after 20 years of bashing, my bash skills still suck. So many corner cases! But if you include this, and call install_utils at the head of your scripts. It should install the tools on demand. #!/bin/bash RUST_PACKAGE_LIST='rg xsv tuc broot du-dust dutree' RUST_UTIL_LIST='rg xsv tuc broot dust dutree' function is_cargo { cargo > /dev/null } function is_utils { eval "which $RUST_UTIL_LIST" > /dev/null } function install_utils { if ! is_utils ; then if ! is_cargo; then curl https://sh.rustup.rs -sSf | sh -s -- -y fi eval "cargo install --locked $RUST_PACKAGE_LIST" > /dev/null fi } I don't recommend using this, it is just illustrative.
      - michaelmior 4y ago
        My primary point is that if I stick to coreutils, I don't have to worry about any of this. I can reasonably expect anything in coreutils to already be installed and available. Your functions seem like they'll work just fine, but either requires build tools to be installed, or the package to support binstall. For me, thinking about all these things and maintaining something like that isn't worth it when I can just use coreutils.
        sitkack 4y ago
        I totally understand. My .vimrc has shrunk from over a hundred lines to 4 lines in the last years. But I really think you are doing yourself a disservice. It is easier than ever (homebrew, nix, cargo, pip) to get nice software everywhere.
- jarbus 4y ago
  I agree. If these could be made installable without root, and independent of the current version of glibc, then there is huge potential to replace the older tools. I’d love to use things like fd, but they don’t work on older servers without root and a newer version of glibc
  - tomjakubowski 4y ago
    They're already installable without root. Just put them in ~/.local/bin. Most Rust binaries are portable and only dynamically link libc.
    - jarbus 4y ago
      That’s what I initially tried for fd, but unfortunately glibc is required for it, and probably other utilities as well.
      - roey2009 4y ago
        What would prevent us from adding those to a docker file?
        jarbus 4y ago
        Docker not being installed on remote
      - homarp 4y ago
        fd has musl version https://github.com/sharkdp/fd/releases/download/v8.4.0/fd-musl_8.4.0_amd64.deb https://github.com/sharkdp/fd/releases/download/v8.4.0/fd-mu...
    - layer8 4y ago
      Local installation is still not really a practical solution when you work e.g. on customer machines, on machines of another team, or generally if you work on many different machines. You still need to be aware of the standard tools and know how to use them when needed. I mean, I get it — I used to locally install vim on machines that only had vi, to make my muscle memory be functional when editing files. But it’s not the same as a core tool just being available by default so you don’t have to ever concern yourself with any alternatives.
- throwamon 4y ago
  Have you tried running them with Nix? I believe you can use most things from it without root, but I'm not sure.
  - michaelmior 4y ago
    I suppose I shouldn't have said only Debian. But having tools easily installable is still quite different from being able to reasonably assume they are already installed.
- fragmede 4y ago
  There’s moreutils for an older rethink of the same set of utilities. I don’t see why an evenmoreutils wouldn’t eventually become popular enough to take hold? Probably not as quickly as you’d like in today’s world of instant gratification, but we’ll get there, eventually.
  - michaelmior 4y ago
    moreutils is still nowhere near as ubiquitous as coreutils. For me it's not about gratification. It would be more satisfying to make use of the most modern tools available. It's about making sure stuff works and I find sticking to coreutils is the easiest way to do that most of the time.
- moondev 4y ago
  This is why I like that you can "go run" golang programs without installing them. Anywhere golang is installed it will automatically build cache and run the binary for whatever platform you are on. For example go run sigs.k8s.io/kind@latest create cluster I wonder if something like this exists for rust
  - PaulDavisThe1st 4y ago
    Absolute no possible exploit path there at all
    - naniwaduni 4y ago
      Is it really an exploit when you're explicitly running code that you expressly trust (even if you probably shouldn't necessarily)?
      - _carbyau_ 4y ago
        Isn't an exploit explicitly a subversion of trust? If you shouldn't trust it but you do anyway and someone uses that against you - they exploited your trust.
    - taftster 4y ago
      Unless you are reviewing the source of everything and compiling it all yourself, then you're executing someone else's binary.
  - steveklabnik 4y ago
    “cargo install” is the Rust equivalent.
  - michaelmior 4y ago
    That is nice, but it still requires installation of golang which is obviously something that can't be guaranteed.
GuB-42 4y ago
I wonder how well Rust project get along with Debian packaging tools. "Modern" dev environments are often tied to their own package manager. JS has Npm, Rust has Cargo, etc... These have their own dependency managers, version systems, etc... and they don't always get along with the way Linux package managers work. IIRC, you don't even need Cargo to do Rust, so it should be possible to compile Rust projects like you compile C projects and essentially mirroring crates.io but with .deb packages but it looks like a lot of work.
- steveklabnik 4y ago
  Debian packages individual cargo packages/crates as their own Debian packages, and also applications that then depend on them. https://packages.debian.org/stable/rust/ https://packages.debian.org/stable/rust/ https://crates.io/crates/cargo-deb https://crates.io/crates/cargo-deb exists but I don’t know if Debian uses it or something else.

That doesn't solve the "available everywhere" problem. It potentially would make the tools easier to install on Debian-based systems, if you have root access. I'm not sure any new set of tools will ever be available with the ubiquity of coreutils in the next handful of years, if ever.

sitkack 4y ago
Install rustup from https://rustup.rs/ https://rustup.rs/ cargo install broot exa miniserve ripgrep tuc xh xsv zellij Cargo is the package manager you are looking for.
- michaelmior 4y ago
  I use Cargo regularly and rustup it does make it easy to install. That's not the point. I'm not looking for a package manger. I want to be able to write scripts that make use of tools I can pretty much guarantee are already installed.
  - sitkack 4y ago
    So we aren't talking past each other, how do you delineate between cargo and a package manager? Does anaconda, pip (pypi) or homebrew also qualify? Your scripts could have a prolog that installs rustup and calls cargo. There is also https://github.com/ryankurte/cargo-binstall https://github.com/ryankurte/cargo-binstall Even after 20 years of bashing, my bash skills still suck. So many corner cases! But if you include this, and call install_utils at the head of your scripts. It should install the tools on demand. #!/bin/bash RUST_PACKAGE_LIST='rg xsv tuc broot du-dust dutree' RUST_UTIL_LIST='rg xsv tuc broot dust dutree' function is_cargo { cargo > /dev/null } function is_utils { eval "which $RUST_UTIL_LIST" > /dev/null } function install_utils { if ! is_utils ; then if ! is_cargo; then curl https://sh.rustup.rs -sSf | sh -s -- -y fi eval "cargo install --locked $RUST_PACKAGE_LIST" > /dev/null fi } I don't recommend using this, it is just illustrative.
    - michaelmior 4y ago
      My primary point is that if I stick to coreutils, I don't have to worry about any of this. I can reasonably expect anything in coreutils to already be installed and available. Your functions seem like they'll work just fine, but either requires build tools to be installed, or the package to support binstall. For me, thinking about all these things and maintaining something like that isn't worth it when I can just use coreutils.
      - sitkack 4y ago
        I totally understand. My .vimrc has shrunk from over a hundred lines to 4 lines in the last years. But I really think you are doing yourself a disservice. It is easier than ever (homebrew, nix, cargo, pip) to get nice software everywhere.
jarbus 4y ago
I agree. If these could be made installable without root, and independent of the current version of glibc, then there is huge potential to replace the older tools. I’d love to use things like fd, but they don’t work on older servers without root and a newer version of glibc
- tomjakubowski 4y ago
  They're already installable without root. Just put them in ~/.local/bin. Most Rust binaries are portable and only dynamically link libc.
  - jarbus 4y ago
    That’s what I initially tried for fd, but unfortunately glibc is required for it, and probably other utilities as well.
    - roey2009 4y ago
      What would prevent us from adding those to a docker file?
      - jarbus 4y ago
        Docker not being installed on remote
    - homarp 4y ago
      fd has musl version https://github.com/sharkdp/fd/releases/download/v8.4.0/fd-musl_8.4.0_amd64.deb https://github.com/sharkdp/fd/releases/download/v8.4.0/fd-mu...
  - layer8 4y ago
    Local installation is still not really a practical solution when you work e.g. on customer machines, on machines of another team, or generally if you work on many different machines. You still need to be aware of the standard tools and know how to use them when needed. I mean, I get it — I used to locally install vim on machines that only had vi, to make my muscle memory be functional when editing files. But it’s not the same as a core tool just being available by default so you don’t have to ever concern yourself with any alternatives.
throwamon 4y ago
Have you tried running them with Nix? I believe you can use most things from it without root, but I'm not sure.
- michaelmior 4y ago
  I suppose I shouldn't have said only Debian. But having tools easily installable is still quite different from being able to reasonably assume they are already installed.
fragmede 4y ago
There’s moreutils for an older rethink of the same set of utilities. I don’t see why an evenmoreutils wouldn’t eventually become popular enough to take hold? Probably not as quickly as you’d like in today’s world of instant gratification, but we’ll get there, eventually.
- michaelmior 4y ago
  moreutils is still nowhere near as ubiquitous as coreutils. For me it's not about gratification. It would be more satisfying to make use of the most modern tools available. It's about making sure stuff works and I find sticking to coreutils is the easiest way to do that most of the time.
moondev 4y ago
This is why I like that you can "go run" golang programs without installing them. Anywhere golang is installed it will automatically build cache and run the binary for whatever platform you are on. For example go run sigs.k8s.io/kind@latest create cluster I wonder if something like this exists for rust
- PaulDavisThe1st 4y ago
  Absolute no possible exploit path there at all
  - naniwaduni 4y ago
    Is it really an exploit when you're explicitly running code that you expressly trust (even if you probably shouldn't necessarily)?
    - _carbyau_ 4y ago
      Isn't an exploit explicitly a subversion of trust? If you shouldn't trust it but you do anyway and someone uses that against you - they exploited your trust.
  - taftster 4y ago
    Unless you are reviewing the source of everything and compiling it all yourself, then you're executing someone else's binary.
- steveklabnik 4y ago
  “cargo install” is the Rust equivalent.
- michaelmior 4y ago
  That is nice, but it still requires installation of golang which is obviously something that can't be guaranteed.

GuB-42 4y ago

I wonder how well Rust project get along with Debian packaging tools. "Modern" dev environments are often tied to their own package manager. JS has Npm, Rust has Cargo, etc... These have their own dependency managers, version systems, etc... and they don't always get along with the way Linux package managers work. IIRC, you don't even need Cargo to do Rust, so it should be possible to compile Rust projects like you compile C projects and essentially mirroring crates.io but with .deb packages but it looks like a lot of work.

steveklabnik 4y ago
Debian packages individual cargo packages/crates as their own Debian packages, and also applications that then depend on them. https://packages.debian.org/stable/rust/ https://packages.debian.org/stable/rust/ https://crates.io/crates/cargo-deb https://crates.io/crates/cargo-deb exists but I don’t know if Debian uses it or something else.