6 ms·

I appreciate all these new incarnations of old school tools but end up sticking with the basics regardless. When I'm sshing into a box to figure out whats going

by bm1362 9y ago

I appreciate all these new incarnations of old school tools but end up sticking with the basics regardless. When I'm sshing into a box to figure out whats going on, my toolset is mostly limited to top, find, xargs, awk, grep, df, du etc. Even local development now, I'm mostly debugging on a docker container running alpine or ubuntu. Knowing the right incantations is useful in that context and keeps me from installing better tools until they become part of the distro we deploy with.

burntsushi 9y ago
> When I'm sshing into a box to figure out whats going on, my toolset is mostly limited to top, find, xargs, awk, grep, df, du etc. I wrote some of the tools on coldtea's list, and I'm pretty much the same way in that I stick to distro tooling in vanilla setups. But I spend enough time on my local workstation that having "better" (read: creature comforts) is worth it there! But yeah, if you spend most of your time in vanilla setups, then tools not in the standard distro repos are a hard sell.
- j2kun 9y ago
  Who makes the decision on what gets standardized into the distro?
  - burntsushi 9y ago
    The people in charge of the distro. Governance structures vary. And sometimes it's not just about who gets to decide, but also, the technical work required to do it. People need to put in the work to make Rust applications packageable according to the distro's standards. YMMV.
    - deleted 9y ago
      [deleted]
    - IgorPartola 9y ago
      This. And at some point enough of these alternatives might accumulate that a new distro will form using only the new tools. The issue is that most people don’t realize just how entrenched the existing tools are. They are a part of cross distro standards because often times they are used for scripting. Imagine a distro that decided to not ship ls in favor of exa. Ok it’s own this isn’t a problem at all. But combined with the overwhelming amount of FOSS you might want to install on top of your distro, you would suddenly need ls anyways.
    - marcosdumay 9y ago
      Debian in particular has an entire alternatives system. Nothing stops somebody from creating the packages `nice_tools` and `select_nice_tools` that will install those tools and make them the default binaries for the commands.
    - geezerjay 9y ago
      I would add that if a distro aims for Unix compliance, it's obvious that there is no alternative to include certain utils.
- jorvi 9y ago
  What's strange to me is that some of these new incarnations use different syntax and/or flags. If those were the same you get the advantage of migraters not having to relearn anything. It also allows for the beauty of aliasing the new tool to the old name!
  - coldtea 9y ago
    >If those were the same you get the advantage of migraters not having to relearn anything. You'd also loose the ability to improve upon arcane/ad-hoc and obsolete flags and syntax choices though too. And for the "same flags" to make any sense, you'd also be constrained to produce the same output and even recreate the same quirks. At which point, might as well just use the originals.
    - bm1362 9y ago
      I agree with you, the reason these new tools are useful is they’re much more intuitive than the esoteric flags that have built up over the last 30 years.
  - burntsushi 9y ago
    There is a very simple response to this: if ripgrep were a 100% drop-in replacement for something like GNU grep, then there would be basically no point for it to exist in the first place. The whole point is that it is very similar but does some things differently that a lot of people consider "better." I imagine this is truish for the other tools mentioned in this thread as well. (And still other tools, like xsv, have no pre-existing standard. Standard UNIX tooling doesn't work on CSV.)
    - yorwba 9y ago
      Have you considered making a "grep mode" for ripgrep? If it's triggered by the name of the binary, it could provide both the traditional flags as well as its own.
      - burntsushi 9y ago
coldtea 9y ago
>I appreciate all these new incarnations of old school tools but end up sticking with the basics regardless. When I'm sshing into a box to figure out whats going on, my toolset is mostly limited to top, find, xargs, awk, grep, df, du etc. That's why I wrote about it being nice to have them all in distros -- perhaps in a single package like coreutils. Then wherever you are, they'd be just a "package-manager install rustutils" away. Generally, if one is not an admin of random hodgepodge of systems (e.g. in big enterprises), then you are: (1) doing work on your own workstation (2) administering machines you control the provision (e.g. a person administering a startup's Cloud servers) (3) doing development on some kind of vm In those cases you can quite easily install a bundle package and make sure those tools are there. I, for one, don't go out in unknown systems day after day -- even if we have 100s of servers we manage, we DO manage them.
- bm1362 9y ago
  Just my experience, I'm sure there are other types of organizations. In most of my workplaces, having one developer's preferred tools installed as a build step might not pass review. I would be annoyed if fish was installed on all our prod boxes, for example. I'm glad these tools work for you and I hope the community keeps making them, I just threw in my perspective.
  - jhasse 9y ago
    > I would be annoyed if fish was installed on all our prod boxes, for example. Why?
    - giancarlostoro 9y ago
      Wondering the same when you consider you don't have to login to fish as the default shell, it's all set per user. Even so, they can just turn it on once they log on.
    - bm1362 9y ago
      That was just a hyperbolic example, but I can think of a few superficial reasons: 1. Because you end up with a more complex Dockerfile. I've seen curls, clones etc during build - having a remote call for random tools in our build _feels_ like a bad practice. 2. There is also the issue that a fleet of application servers will have different tooling available, which can be frustrating in a pinch. I've done some gnarly things across many hosts, expecting a common set of tools. At AWS, we were responsible for non-nuclear team's services during oncall and would ssh to their boxes. Logging into a box with a different shell would be annoying. [2] > for i in `cat hosts.txt`; do ssh $i '...'; done
on_and_off 9y ago
I love exa and have just mapped it to ls (and ll for exa -l ) . That way I don't even have to learn the new command (or risk forgetting about ls / be frustrated when I can't use it).
foo101 9y ago
What surprises me is that even after 25 years of the Internet, we cannot bring in new tools into our environment (be it a remote box I ssh into or a trimmed down docker image) on the fly. The popular package management tools rely heavily on FHS and like to install stuff into directories that require root permission. Imagine if there was a tool that could download binaries of modern tools from a certain repo and install it to our ~/bin. Imagine if we could use new command line tools as easily as we can download a fully functional complex applications securely into a browser tab just by typing its URL!
- wruza 9y ago
  sudo chown -R user:user /usr, that’s what you effectively suggest. Also convince tool makers to provide ppas.
- laumars 9y ago
  You can. There's nothing stopping you adding ~/bin to $PATH. Many compilers allow you to specify the destination location either via a ./configure flag (for example) or an environmental variable. Or there is always the option of doing a `make build` and then manually copying the binaries into your ~/bin directory without doing a `make install` You can also add ~/lib (for example) to your LD_LIBRARY_PATH path if you wanted to install custom libraries and even have your own man page path too. All of this is already possibly on Linux and Unix however I'm not sure it's something you actively want to encourage as allowing users to install whatever they want on servers lowers the security to the level of the worst user on that server. If it was really deemed necessary that users should be able to install whatever they want then I'd sooner roll out a dedicated VM per user so at least their damage is self-contained (barring any visible networked infrastructure)
  - coldtea 9y ago
    >You can. There's nothing stopping you adding ~/bin to $PATH. Many compilers allow you to specify the destination location either via a ./configure flag (for example) or an environmental variable. Of course you can, technically. The parent laments why it's not easier to achieve. Already you're talking about manually building for example. Where's a package manager that will allow for that too, not just the central repo? (not just asking if such manager exists in some form, asking where it is in modern popular distros). >All of this is already possibly on Linux and Unix however I'm not sure it's something you actively want to encourage as allowing users to install whatever they want on servers lowers the security to the level of the worst user on that server. Which also touches the parent's question. Why is it not easier AND safer? It's not like we don't have security models that allow for such things...
cstrahan 9y ago
A potential solution that would allow you to have your cake (SSH into wherever) and eat it too (have your favorite tools on hand) would be: use a package manager on your hosts that allows for safe installation of per-user packages (that is, such package installation should have absolutely no effect on the system outside of the user’s environment. A logical implication here is that it should be possible to use multiple versions of each package, both inter- and intra-user) and per-user package installation should not require special privileges (i.e. you shouldn’t need to be root if, as per the previous requirement re: safety, per-user package installation has no effect on the rest of the system). Then you could log in and do your work with the best tools you know, rather than being constrained to what your distro (or your servers’ admins) deems useful enough to be installed by default. It strikes me as an odd choice to accept the least common denominator of tools. As a technologist, that sounds frustrating. And as someone in leadership, I can’t imagine hamstringing my team by making them work within an environment that won’t let them use the best tools for the task at hand.

by bm1362 9y ago

burntsushi 9y ago

> When I'm sshing into a box to figure out whats going on, my toolset is mostly limited to top, find, xargs, awk, grep, df, du etc. I wrote some of the tools on coldtea's list, and I'm pretty much the same way in that I stick to distro tooling in vanilla setups. But I spend enough time on my local workstation that having "better" (read: creature comforts) is worth it there! But yeah, if you spend most of your time in vanilla setups, then tools not in the standard distro repos are a hard sell.

j2kun 9y ago
Who makes the decision on what gets standardized into the distro?
- burntsushi 9y ago
  The people in charge of the distro. Governance structures vary. And sometimes it's not just about who gets to decide, but also, the technical work required to do it. People need to put in the work to make Rust applications packageable according to the distro's standards. YMMV.
  - deleted 9y ago
    [deleted]
  - IgorPartola 9y ago
    This. And at some point enough of these alternatives might accumulate that a new distro will form using only the new tools. The issue is that most people don’t realize just how entrenched the existing tools are. They are a part of cross distro standards because often times they are used for scripting. Imagine a distro that decided to not ship ls in favor of exa. Ok it’s own this isn’t a problem at all. But combined with the overwhelming amount of FOSS you might want to install on top of your distro, you would suddenly need ls anyways.
  - marcosdumay 9y ago
    Debian in particular has an entire alternatives system. Nothing stops somebody from creating the packages `nice_tools` and `select_nice_tools` that will install those tools and make them the default binaries for the commands.
  - geezerjay 9y ago
    I would add that if a distro aims for Unix compliance, it's obvious that there is no alternative to include certain utils.
jorvi 9y ago
What's strange to me is that some of these new incarnations use different syntax and/or flags. If those were the same you get the advantage of migraters not having to relearn anything. It also allows for the beauty of aliasing the new tool to the old name!
- coldtea 9y ago
  >If those were the same you get the advantage of migraters not having to relearn anything. You'd also loose the ability to improve upon arcane/ad-hoc and obsolete flags and syntax choices though too. And for the "same flags" to make any sense, you'd also be constrained to produce the same output and even recreate the same quirks. At which point, might as well just use the originals.
  - bm1362 9y ago
    I agree with you, the reason these new tools are useful is they’re much more intuitive than the esoteric flags that have built up over the last 30 years.
- burntsushi 9y ago
  There is a very simple response to this: if ripgrep were a 100% drop-in replacement for something like GNU grep, then there would be basically no point for it to exist in the first place. The whole point is that it is very similar but does some things differently that a lot of people consider "better." I imagine this is truish for the other tools mentioned in this thread as well. (And still other tools, like xsv, have no pre-existing standard. Standard UNIX tooling doesn't work on CSV.)
  - yorwba 9y ago
    Have you considered making a "grep mode" for ripgrep? If it's triggered by the name of the binary, it could provide both the traditional flags as well as its own.
    - burntsushi 9y ago

coldtea 9y ago

>I appreciate all these new incarnations of old school tools but end up sticking with the basics regardless. When I'm sshing into a box to figure out whats going on, my toolset is mostly limited to top, find, xargs, awk, grep, df, du etc. That's why I wrote about it being nice to have them all in distros -- perhaps in a single package like coreutils. Then wherever you are, they'd be just a "package-manager install rustutils" away. Generally, if one is not an admin of random hodgepodge of systems (e.g. in big enterprises), then you are: (1) doing work on your own workstation (2) administering machines you control the provision (e.g. a person administering a startup's Cloud servers) (3) doing development on some kind of vm In those cases you can quite easily install a bundle package and make sure those tools are there. I, for one, don't go out in unknown systems day after day -- even if we have 100s of servers we manage, we DO manage them.

bm1362 9y ago
Just my experience, I'm sure there are other types of organizations. In most of my workplaces, having one developer's preferred tools installed as a build step might not pass review. I would be annoyed if fish was installed on all our prod boxes, for example. I'm glad these tools work for you and I hope the community keeps making them, I just threw in my perspective.
- jhasse 9y ago
  > I would be annoyed if fish was installed on all our prod boxes, for example. Why?
  - giancarlostoro 9y ago
    Wondering the same when you consider you don't have to login to fish as the default shell, it's all set per user. Even so, they can just turn it on once they log on.
  - bm1362 9y ago
    That was just a hyperbolic example, but I can think of a few superficial reasons: 1. Because you end up with a more complex Dockerfile. I've seen curls, clones etc during build - having a remote call for random tools in our build _feels_ like a bad practice. 2. There is also the issue that a fleet of application servers will have different tooling available, which can be frustrating in a pinch. I've done some gnarly things across many hosts, expecting a common set of tools. At AWS, we were responsible for non-nuclear team's services during oncall and would ssh to their boxes. Logging into a box with a different shell would be annoying. [2] > for i in `cat hosts.txt`; do ssh $i '...'; done

on_and_off 9y ago

I love exa and have just mapped it to ls (and ll for exa -l ) . That way I don't even have to learn the new command (or risk forgetting about ls / be frustrated when I can't use it).

foo101 9y ago

What surprises me is that even after 25 years of the Internet, we cannot bring in new tools into our environment (be it a remote box I ssh into or a trimmed down docker image) on the fly. The popular package management tools rely heavily on FHS and like to install stuff into directories that require root permission. Imagine if there was a tool that could download binaries of modern tools from a certain repo and install it to our ~/bin. Imagine if we could use new command line tools as easily as we can download a fully functional complex applications securely into a browser tab just by typing its URL!

wruza 9y ago
sudo chown -R user:user /usr, that’s what you effectively suggest. Also convince tool makers to provide ppas.
laumars 9y ago
You can. There's nothing stopping you adding ~/bin to $PATH. Many compilers allow you to specify the destination location either via a ./configure flag (for example) or an environmental variable. Or there is always the option of doing a `make build` and then manually copying the binaries into your ~/bin directory without doing a `make install` You can also add ~/lib (for example) to your LD_LIBRARY_PATH path if you wanted to install custom libraries and even have your own man page path too. All of this is already possibly on Linux and Unix however I'm not sure it's something you actively want to encourage as allowing users to install whatever they want on servers lowers the security to the level of the worst user on that server. If it was really deemed necessary that users should be able to install whatever they want then I'd sooner roll out a dedicated VM per user so at least their damage is self-contained (barring any visible networked infrastructure)
- coldtea 9y ago
  >You can. There's nothing stopping you adding ~/bin to $PATH. Many compilers allow you to specify the destination location either via a ./configure flag (for example) or an environmental variable. Of course you can, technically. The parent laments why it's not easier to achieve. Already you're talking about manually building for example. Where's a package manager that will allow for that too, not just the central repo? (not just asking if such manager exists in some form, asking where it is in modern popular distros). >All of this is already possibly on Linux and Unix however I'm not sure it's something you actively want to encourage as allowing users to install whatever they want on servers lowers the security to the level of the worst user on that server. Which also touches the parent's question. Why is it not easier AND safer? It's not like we don't have security models that allow for such things...

cstrahan 9y ago

A potential solution that would allow you to have your cake (SSH into wherever) and eat it too (have your favorite tools on hand) would be: use a package manager on your hosts that allows for safe installation of per-user packages (that is, such package installation should have absolutely no effect on the system outside of the user’s environment. A logical implication here is that it should be possible to use multiple versions of each package, both inter- and intra-user) and per-user package installation should not require special privileges (i.e. you shouldn’t need to be root if, as per the previous requirement re: safety, per-user package installation has no effect on the rest of the system). Then you could log in and do your work with the best tools you know, rather than being constrained to what your distro (or your servers’ admins) deems useful enough to be installed by default. It strikes me as an odd choice to accept the least common denominator of tools. As a technologist, that sounds frustrating. And as someone in leadership, I can’t imagine hamstringing my team by making them work within an environment that won’t let them use the best tools for the task at hand.