3 ms·

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

by 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
  - Tyr42 9y ago
    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 '...'";`
- HankB99 9y ago
  '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.
dozzie 9y ago
Why would you run build step on production servers at all?
- coldtea 9y ago
  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.
- bm1362 9y ago
  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.

by bm1362 9y ago

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
- Tyr42 9y ago
  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 '...'";`
HankB99 9y ago
'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.

dozzie 9y ago

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

coldtea 9y ago
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.
bm1362 9y ago
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.