I went through a similar cycle. Going back to simplicity wasn't about laziness for me, it was because i started working across a bunch more systems and didn't want to do my whole custom setup on all of them, especially ephemeral stuff like containers allocated on a cluster for a single job. So rather than using my fancy setup sometimes and fumbling through the defaults at other times, i just got used to operating more efficiently with the defaults.

You can apply your dotfiles to servers you SSH into rather easily. I'm not sure what your workflow is like but frameworks like zsh4humans have this built in, and there are tools like sshrc that handle it as well. Just automate the sync on SSH connection. This also applies to containers if you ssh into them.

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.

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.

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

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.

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.

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.

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.

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.

That's still not professional, but then again 99.9% of companies aren't.

Could you help me understand what assumptions about the access method you have in place that make this seem unprofessional?

Let's assume they need access to the full service account environment for the work, which means they need to login or run commands as the service account.

This is a bit outside my domain, so this is a genuine question. I've worked on single user and embedded systems where this isn't possible, so I find the "unprofessional" statement very naive.

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.

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.

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.

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%?

The defaults are unbearable. I prefer using chezmoi to feel at home anywhere. There's no reason I can't at least have my aliases.

I'd rather take the pain of writing scripts to automate this for multiple environments than suffer the death by a thousand cuts which are the defaults.

chezmoi is the right direction, but I don't want to have to install something on the other server, I should just be able to ssh to a new place and have everything already set up, via LocalCommand and Host * in my ~/.ssh/config

Atuin is new to me!

https://github.com/atuinsh/atuin

Discussed 4 months ago:

Atuin – Magical Shell History https://news.ycombinator.com/item?id=44364186 - June 2025, 71 comments

I gave it a try a few months ago, but did not work for me. My main issue is that atuin broke my workflow with fzf (If I remember correctly, pressing ctrl + r to lookup my shell history did not work well after installing atuin).

I'm sympathetic, also a longtime fzf user here. I install it reflexively on any system I use for more than a day or two.

This is configurable! I use atuin, but fzf with ctrl-r.

I like atuin but why is it so slow when first opening (hitting up) in the shell?

I'd recommend disabling atuin when hitting up and just leave it on ctrl+r instead

Either it wasn't a design goal or they are stupid. Why don't you tell us?

The right way this would work is via a systemd service and then it should be instant.