[theshrike79]

I'm guessing you haven't worked in Someone Else's environment?

The amount of shit you'll get for "applying your dotfiles" on a client machine or a production server is going to be legendary.

Same with containers, please don't install random dotfiles inside them. The whole point of a container is to be predictable.

[nijaru]

Do you have experience with these tools? Some such as sshrc only apply temporarily per session and don't persist or affect other users. I keep plain 'ssh' separate from shell functions that apply dotfiles and use each where appropriate. You can also set up temporary application yourself pretty easily.

[YouAreWRONGtoo]

Someone else's environment? That should never happen. You should get your own user account and that's it.

[mlrtime]

Sometimes we need to use service accounts, so while you do have your own account all the interesting things happen in svc_foo which you cannot add your .files.

[theshrike79]

I don’t even get an account on someone else’s server. There’s no need for me to log in anywhere unless it’s an exceptional situation.

[YouAreWRONGtoo]

This doesn't make sense.

You said you were already using someone else's environment.

You can't later say that you don't.

Whether or not shell access makes sense depends on what you are doing, but a well written application server running in a cloud environment doesn't need any remote shell account.

It's just that approximately zero typical monolithic web applications meet that level of quality and given that 90% of "developers" are clueless, often they can convince management that being stupid is OK.

[1718627440]

They do get to work on someone else's server, they do not get a separate account on that server. There client would be not happy to have them mess around with the environment.

[YouAreWRONGtoo]

By definition, it the client Alice gives contractor Mallory access to user account alice, that's worse than giving them an account called mallory.

Accounts are basically free. Not having accounts; that's expensive.

[nomel]

They specifically mentioned service accounts. If they’re given an user account to login as, they still might have to get into and use the service account, and its environment, from there. If the whole purpose was to get into the service account, and the service account is already setup for remote debug, then the client might prefer to skip the creation of the practically useless user account.

[fragmede]

If, in the year 2025, you are still using a shared account called "root" (password: "password"), and it's not a hardware switch or something (and even they support user accounts these days), I'm sorry, but you need to do better. If you're the vendor, you need to do better, if you're the client, you need to make it an issue with the vendor and tell them they need to do better. I know, it's easy for me to say from the safety of my armchair at 127.0.0.1. I've got some friends in IT doing support that have some truly horrifying stories. But holy shit why does some stuff suck so fucking much still. Sorry, I'm not mad at you or calling you names, it's the state of the industry. If there were more pushback on broken busted ass shit where this would be a problem, I could sleep better at night, knowing that there's somebody else that isn't being tortured.

[theshrike79]

It’s 2025. I don’t even have the login password to any server, they’re not unicorns, they’re cattle.

If something is wrong with a server, we terminate it and spin up a new one. No need for anyone to log in.

In very rare cases it might be relevant to log in to a running server, but I haven’t done that in years.

[LinXitoW]

In other replies you explicitly state how rare it is that you log in to other systems.

Aren't you therefore optimizing for 1% of the cases, but sabotaging the 99%?