Hacker News Reader

Comment by coldtea | Hacker News Reader

>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.

View on HN

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.

> I would be annoyed if fish was installed on all our prod boxes, for example.

Why?

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.

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

I mean you wouldn't need to set fish as the default shell. But even if it was, you could `do ssh $i "bash -c '...'";`

'fish' I take it is a shell (of which I remain ignorant.) I suppose that at the very least, it increases the attack surface on an installation and either makes security harder or the system less secure.

Why would you run build step on production servers at all?

Production servers can mean a lot of things, not necessarily just "servers running a web service".

For companies whose main activity is processing data, various build pipelines (not necessarily compiles) might be what production servers do all day.

I think I wasn’t clear, but a lot of people are harping on the specific use case I glibly mentioned.

To answer you, I meant on a Docker image build step- which is where you’d want to install the tool so it’s accessible to people debugging the application during the container run context.

Reply on news.ycombinator.com