6 ms·

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 w

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.

deleted 11mo ago
[deleted]
nijaru 11mo ago
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.
- theshrike79 11mo ago
  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.
  - fragmede 11mo ago
    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 11mo ago
      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.
      - ZeroSolstice 11mo ago
        [dead]
  - nijaru 11mo ago
    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 11mo ago
    Someone else's environment? That should never happen. You should get your own user account and that's it.
    - theshrike79 11mo ago
      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 11mo ago
        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 11mo ago
        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 11mo ago
        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 11mo ago
        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.
  - LinXitoW 11mo ago
    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%?
tester457 11mo ago
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.
- fragmede 11mo ago
  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

deleted 11mo ago

[deleted]

nijaru 11mo ago

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.

theshrike79 11mo ago
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.
- fragmede 11mo ago
  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 11mo ago
    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.
    - ZeroSolstice 11mo ago
      [dead]
- nijaru 11mo ago
  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 11mo ago
  Someone else's environment? That should never happen. You should get your own user account and that's it.
  - theshrike79 11mo ago
    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 11mo ago
      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 11mo ago
        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 11mo ago
        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 11mo ago
        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.
- LinXitoW 11mo ago
  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%?

tester457 11mo ago

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.

fragmede 11mo ago
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