It's weird how the circle of life progresses for a developer or whatever.
- When I was a fresh engineer I used a pretty vanilla shell environment
- When I got a year or two of experience, I wrote tons of scripts and bash aliases and had a 1k+ line .bashrc the same as OP
- Now, as a more tenured engineer (15 years of experience), I basically just want a vanilla shell with zero distractions, aliases or scripts and use native UNIX implementations. If it's more complicated than that, I'll code it in Python or Go.
I think it's more likely to say that this comes from a place of laziness than some enlightened peak. (I say this as someone who does the same, and is lazy).
When I watch the work of coworkers or friends who have gone these rabbit holes of customization I always learn some interesting new tools to use - lately I've added atuin, fzf, and a few others to my linux install
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.
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.
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.
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.
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.
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.
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.
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
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).
For anyone else reading this comment who was confused because this seems like the opposite of what you'd expect about Nix: Hacker News ate the asterisks and turned them into italics.
Besides many nix computers I also have wife, dog, children, chores, shopping to be done. Unlike when I was young engineer I could stay all night fiddling with bash scripts and environments.
What does your wife, dog, children, chores, and shopping have to do with custom configuration and scripts? Just set up a Git repo online, put your files there, and take a couple of minutes to improve it incrementally when you encounter inconveniences. And just like that, you made your life easier for a marginal effort.
Having a wife increases the opportunity costs of the time you spend on maintaining the scripts and also increases the costs while writing these (when the wife is nagging).
Some are desktops, some laptops, some servers. Different packages installed, different hardware. Three more variants.
Yes, I do have a script to set up my environment, but it already has a lot of conditional behavior to handle these five total variants. And I don't want to have to re-test the scripts and re-sync often.
I've heard this often, but I'm going on ~25 years of using Linux, and I would be lost without my dotfiles. They represent years of carefully crafting my environment to suit my preferences, and without them it would be like working on someone else's machine. Not impossible, just very cumbersome.
Admittedly, I've toned down the configs of some programs, as my usage of them has evolved or diminished, but many are still highly tailored to my preferences. For example, you can't really use Emacs without a considerable amount of tweaking. I mean, you technically could, but such programs are a blank slate made to be configured (and Emacs is awful OOB...). Similarly for zsh, which is my main shell, although I keep bash more vanilla. Practically the entire command-line environment and the choices you make about which programs to use can be considered configuration. If you use NixOS or Guix, then that extends to the entire system.
If you're willing to allow someone else to tell you how you should use your computer, then you might as well use macOS or Windows. :)
Yeah - been there, done that, too. I feel like the time I gain from having a shortcut is often less that what I wound need to maintain it or to remember the real syntax when I'm on a machine where it's not available (which happens quite often in my case). I try to go with system defaults as much as possible nowadays.
I am going through a phase of working with younger engineers who have many dotfiles, and I just think "Oh, yeh, I remember having lots of dotfiles. What a hassle that was."
Nowadays I just try to be quite selective with my tooling and learn to change with it - "like water", so to speak.
(I say this with no shade to those who like maintaining their dotfiles - it takes all sorts :))
as a person who loves their computer, my ~/bin is full. i definitely (not that you said this) do not think "everything i do has to be possible on every computer i am ever shelled into"
being a person on a computer for decades, i have tuned how i want to do things that are incredibly common for me
though perhaps you're referring to work and not hobby/life
> When I was a fresh engineer I used a pretty vanilla shell environment. When I got a year or two of experience, I wrote tons of scripts
Does this mean that you learned to code to earn a paycheck? I'm asking because I had written hundreds of scripts and Emacs Lisp functions to optimize my PC before I got my first job.
Prepare to swing back again. With nearly 30 years experience I find the shell to be the best integration point for so many things due to its ability to adapt to whatever is needed and its universal availability. My use of a vanilla shell has been reduced to scripting cases only.
On the other hand, the author seems to have a lot of experience as well.
Personally I tend to agree... there is a very small subset of things I find worth aliasing. I have a very small amount and probably only use half of them regularly. Frankly I wonder how my use case is so different.
In my case i'd start typing it in my browser then just click something i've visited 100 times before. There is something to be said about reducing that redundant network call but I dont think it makes much practical difference and the mental mapping/discoverability of aliases isnt nothing.
I can't say I relate at all (5 years of experience).
They'll have to pry my 1000-line .zshrc from my cold, dead hands.
For example, zsh-autosuggestions improves my quality of life so ridiculously much it's not even funny.
I moved away from 1000 lines .zshrc when I had to do stuff on linux VMs/dockers and I was lost a lot. But you zsh-autosuggestions, and fzf-tab is not going anywhere.
The moment of true enlightenment is when you finally decide to once and for all memorize all the arguments and their order for those command line utilities that you use at an interval that's just at the edge of your memory: xargs, find, curl, rsync, etc.
That, plus knowing how to parse a man file to actually understand how to use a command (a skill that takes years to master) pretty much removes the need for most aliases and scripts.
I already have limited space for long term memory, bash commands are very far down the list of things I'd want to append to my long term storage.
I use ctrl-R with a fuzzy matching program, and let my terminal remember it for me.
And before it's asked: yes that means I'd have more trouble working in a different/someone else's environment. But as it barely ever happens for me, it's hardly an important enough scenario to optimize for.
Why would I even attempt to do that? Life is too short to try to remember something like that. Maybe 20 years ago when internet was not that common. Or maybe if you are a hacker, hacking other peoples machines. Me? Just some dev trying yo make some money to feed my family? I prefer to have a walk to the woods.
I just use the autocd zsh shell option for this. And I also use `hash -d` to define shortcuts for common directories. Then just “executing” something like `~gh/apache/kafka` will cd to the right place.
I use a dotfile with aliases and functions, mostly to document / remember commands I find useful. It's been a handy way to build a living document of the utils I use regularly, and is easy to migrate to each new workstation.
Given the nature of current operating systems and applications, do you think the idea of “one tool doing one job well” has been abandoned? If so, do you think a return to this model would help bring some innovation back to software development?
Rob Pike: Those days are dead and gone and the eulogy was delivered by Perl.
But was the eulogy written in Perl poetry? I see it everywhere, but I don't know who this JAPH guy is. It's a strange way of spelling Jeff, and it's odd that he types his name in all caps, but he has published a remarkable quantity of works and he's even more famous than the anonymous hacker known as 4chan.
Oh I hate that paradigm. Well, maybe chmod and ls rsync and curl all do they OWN thing very well but every time I am using one of those tools I have to remember if i.e. more detailed response is -v or maybe -vvv or --verbose or -x for some reason because maintainer felt like it at 2:32 in the morning 17 years ago... Some consistency would help, but... Probably it is impossible the flame war over -R being recursive or read-only would never end.
For the Infra Engineers out there who still manage fleets of pets, this is double true. You may not have access or be able to use all your shortcut scripts so you better know the raw commands on that unsupported RHEL6 host.
I prefer using kubectl than any other method so i have plenty of functions to help with that. I'd never consider using python or go for this although I do have plenty of python and go "scripts" on my path too.
If you come through the other side, you set up LocalCommand in your .ssh/config which copies your config to every server you ssh to, and get your setup everywhere.
- When I was a fresh engineer I used a pretty vanilla shell environment
- When I got a year or two of experience, I wrote tons of scripts and bash aliases and had a 1k+ line .bashrc the same as OP
- Now, as a more tenured engineer (15 years of experience), I basically just want a vanilla shell with zero distractions, aliases or scripts and use native UNIX implementations. If it's more complicated than that, I'll code it in Python or Go.