I once lost my emacs dotfile and suddenly i was almost unable to use Emacs on my own pc.
Since then, i've decided to apply as little customisation as possible to software I use, and read the documentation and learn the standard configuration instead.
For some reasons nowadays it's trendy to add colors, bells and whistles to things but I've found out that learning the standard/default configuration lets me be instantly capable of intervention on whatever machine i put my hands on. Worst case scenario, i can tell programs to ignore configuration files.
Regardless of the frequency of such a situation, it can really bite you when something big breaks and you need to ssh into a vanilla server in the middle of the night under pressure. Trying to fix a production fire under the gaze of an angry CEO is stressful enough, but not being able to take care of business on a box because of a missing personal config is truly one of the worst experiences I've ever had in this business.
It's only happened to me once, but that one experience made me take a really hard look at my workflow, and years later, I have no regrets about scaling back my configs. I guess it really just depends on your job and on-call/firefighting responsibilities.
Keep your dot files in github. Grab them. No internet, I bet you have them on your laptop that you are ssh'd to the server from. SCP them over. Heck, cut and paste them if needed. If things are so bad nether of these work you have bigger issues and need to consider a design with some redundancy. Clos fabrics and VM/containers and if you have to have bare metal then you should have more then one (cluster or behind a SLB).
There is no excuse for a single point of failure in 2017. Not trying to sound like an ass but....
You did say it was years ago, so what I said seems to be true for today, no judgment on your situation years ago. My first major shit, got to fix it was on Solaris 2.51 so that shows my age.
I bind bash and tmux to vim keymaps. If that is not on the box it is the first thing I fix. I will be fast to resolve the issue if my fingers just work as I have trained them :)
Yep, I don't understand why people think you can't clone your dotfiles and copy over your ~/.tmux.conf to your home directory on the server. It's the first thing I do when I get an account set up, along with the ~/.zshrc and ~/.vimrc, and I have it all automated as a script. Makes everything easy.
Why? This lets admins log in as themselves (leaving an auditable trail) with access to their own dotfiles to debug and analyze on the fly. Even with ex. Ansible for managing and ex. Nagios for monitoring, being able to use a shell to diagnose and fix novel issues is invaluble. If you've got a better solution, please do share. (Sincerely: if you can make my job easier, I'm happy to listen)
Using Emacs config files as an example, what's the issue with storing config files on a server? Even if it's a 'production' server it's not like they contain much in the way of sensitive information. Does it matter if others have access to a list of keybindings, aliases, colour schemes, plugins, etc...?
What if their contracts with their customers state everything that deployed is from an audited source in order to leave no loopholes in the event of a data breach?
And if there is a serious data breach you better be able to prove that you never installed anything malicious or dodgy on there.
> What if their contracts with their customers state everything that deployed is from an audited source in order to leave no loopholes in the event of a data breach?
Just delete the configs after you're done?
I place all my dotfiles in a directory, usually in ~/mgmnt/. Then I have a little shell script, which backs up all the dotfiles I need found in ~/ and symlinks the ones from the directory. It's .zshrc, .bashrc, .tmux.conf, .gitconfig, .emacs.d, and probably a couple of other config files. I only needed to do this a couple of times, but reverting such "installation" is as easy as a couple of rm/mv commands so I didn't even feel the need to write a script for this.
This works fine if your configuration contains nothing too custom. Typically after copying my dotfiles I have to edit them quite substantially to make them actually work - mainly because they rely on outside sources (in .tmux.conf, stuff like `set-option -g default-command "reattach-to-user-namespace -l bash"`, in .vimrc it's usually colours, clipboard hacks etc that break). Maybe I should have a second, trimmed down version with no outside dependencies.
For some of these files you can add logic to check for the system it is on. For example (on iPad, do not have the files to look at now..will try to post later) my bash and tmux configuration check to see if:
Linux or OS X (for terminal setting)
If I am in tmux session already.
Check out https://github.com/thoughtbot/rcm. It has a hook system, so you can have it automatically run commands to install external dependencies – stuff like vim or Emacs plugins.
I manage hundreds of servers that are not connected to the Internet, to which I cannot connect any device without management approval, and which are redundant, but which are periodically reflashed and/or replaced with a whole new set with a 'clean' image, less dotfiles.
I keep my dotfiles short and sweet, because it's tedious to retype and I need the defaults to still be instinctive when I lose them.
In the "immutable architecture" style, the only time you see a shell on a production box should be when it's on fire (and even then, only if you need to do some "perimortem" debugging because the problem keeps reoccurring even when you just blow the server's state away with a reboot, and nothing in the "postmortem" logs tell you enough to diagnose or even know what more logging you should add.)
I'd hope an immutable architecture wouldn't break inside the box, since that would indicate it mutated :) And if it did, you'd just blow it away and replace it.
At that level, it's the interactions with different components that can break down, and the tools you use are more about testing configured interactions. Also, bad data. That bit necessarily mutates.
I'm a big fan of developing in a similar environment to production, so that the debugging tools and interaction are familiar long before an emergency. At our company, we develop on Linux and deploy on Linux.
I now use https://github.com/junegunn/vim-plug - you can setup a one-liner in your Vimrc to download and set it up, then :PlugInstall and you're done (similar to what they have in the readme but I linked to a specific hash on GitHub instead of master).
I also keep a separate file that lists the plugins to install and the source that from my main .vimrc. A lot of my coworkers have wanted my main vimrc for an "out of the box setup" of Vim and found it best for them to specify their own plugins rather than just blindly use mine - it also makes it easier for them to grab the latest copy without any conflicts.
Can you explain further what you want to do? But for me, I keep a github repo with my vimrc (among other configs) and I have a Makefile there that symlinks the repo files to ~/
Totally agree. I think a lot of the replies miss the point - that having non-standard configuration is inherently more complex, because it adds a layer of abstraction. It is simpler to not have this layer.
Related note, check out fish shell [1], whose design document has an interesting argument against configurability in software.
"having non-standard configuration is inherently more complex"
I disagree. It can be more complex, but it is not at all inherent. If I configure my shell, my editor, my whatever software to work more like other software I use (keybindings, etc), I can actually make it less complex for me, because copying over a few config files on those rare occassions I need to is much faster than trying to learn a whole new set of keybindings/behaviors (and trying to keep all of the different ones in my head).
Yes it is possible to tinker yourself into oblivion (especially if you change the same items frequently, and never come to a stable state), but that is by no means the inevitible outcome.
I also very much disagree with this line from the fish shell design page:
"Every configuration option in a program is a place where the program is too stupid to figure out for itself what the user really wants, and should be considered a failure of both the program and the programmer who implemented it."
Now I understand what they are getting at, and if they didn't start that sentence with "Every" I would not disagree so much. Yes your program should make it as easy as possible for you to figure out how to do what you want to do. However, not everyone in this world is the same. People have different preferences on how things work, and some of the choices on how to do things are mutually exculsive. So every configuration option is most definitly NOT a failure of the program and the programmer who implemented it.
Granted there are programs out there that were seemingly made to purposefully obfuscate how they work (like the dev who wrote them gets some kind of sick pleasure out of making users' lives difficult :-D ). Obviously you should do your best to avoid that outcome (which almost aways comes not out of programmer malice, but other factors, I'm sure).
There is a place, I think, for a really good set of defaults that are consistent and easy for users to follow. I do not agree, however, that it must come at the price of forbidding users to customize their software. Tuck those customization options away if you must (if your philosophy is to encourage the use of the defaults), but I think it is a mistake to forbid user customization. If someone finds your program useful enough to want to customize it to their tastes, you risk losing a valuable customer/user who will move on to something that lets them shape it to work they want it to.
[edited to remove unintentional indent -- can't seem to break that habit of putting spaces at the beginning of the first line of a paragraph :D ]
> People have different preferences on how things work, and some of the choices on how to do things are mutually exculsive.
Yes! But asking the user to manually configure the system is a lame way to accomodate those preferences. It's better if the software can learn from the user. For example, if the user runs a certain command frequently, don't wait for the user to define an alias, just suggest it while the user types. Your shell can become more customized to you, with no configuration necessary.
This doesn't work for everything - key bindings for example. But it captures the "no configuration" world view.
> Tuck those customization options away if you must (if your philosophy is to encourage the use of the defaults), but I think it is a mistake to forbid user customization.
Not all configuration options are there to enable user customization. A lot of configuration is just punts on hard problems or decisions. For example, options like zsh's RC_QUOTES or bash's histappend. These don't reflect user preferences. They're just legacy or churn. The shell should just define its own language, and not make the user decide how '' is interpreted.
Every configuration point incurs a cost. The user who moved on to the über-flexible system discovered which plug-ins require which options, and which combinations are incompatible with each other.
This is where a layered approach really shines: have a rigid core with a flexible exterior. Allow the user to set the prompt, colors, key bindings, wrap commands likeΩ `grep` and `ls` to set colors, etc. Prefer open-ended customization (let the user write the function) instead of enumerated configuration (pick from N behaviors), an keep the core consistent so that there's something stable to build on. That's fish's philosophy.
Fair enough. I'm all for having the program do some intelligent prompting of the user, as long as it doesn't become annoying (like Microsoft's "Clippy" :-D).
There is a sweet spot with most software between being buried in a sea of options and having no options you can configure at all. I tend to gravitate toward having a sensible set of defaults and letting the user configure them otherwise if they want. Having options grouped together can be good too (like keybindings -- vim vs emacs style bindings for example).
I also like the idea of customization through functions/scripting rather than just giving the user a choice between N options. That's another area where a set of sensible defaults can be good -- defaults in that case, which can be programmed around.
BTW, thanks for responding here. Always nice to get feedback from the developers of a piece of software directly. I really haven't looked at fish for years (though I'm certain I checked it out a while back). I'll give it another look to see if there's something there to catch my interest.
Sorry I didn't see your response until today, I was busy the last couple of days and just got back to it.
I appreciate that you call out keybindings as a likely exception, but particularly in the shell, keybindings are 90% of my configuration! For some settings I'm sure there are sane defaults, but if programs don't know whether I prefer vim or emacs then they're going to have a bad time.
I did something different; I built my own config system that makes a PC account my own in about 20 minutes. My setup is effectively a program that needs to be installed, and I maintain it in a git repo, and it comes packaged with an installer. I'm a software engineer; I build tools to solve problems.
Emacs in particular is almost useless out of the box. But that's because of packages and modes; not because of key bindings and tweaks.
That being said, if a tool doesn't need extensive customization or doesn't ship with a broken config, I'll learn the defaults. I barely tweaked tmux.conf - I turned on xterm-keys and set-titles. And I've certainly reduced the depth of my configuration as the breadth of tools I use has increased.
And that's key: if most of my time is spent on one or two tools, it's well worth my time customizing those tools, because even fractional improvements will accumulate.
Well with Emacs it's more than customisation for me. I write my scripts and programs in Elisp, and if I don't do that, there's no sense in using Emacs for me, as I use it as my "computing environment". Plain emacs might be hard to use for a customising user, but I don't value that sort of use anyways.
Now it is superceded by avy (by abo-abo on GitHub) in every way + new features.
For such packages that always have room for improvement and not related to core emacs functionality, it is better that they stay in external repositories on GNU Elpa or Melpa.
That way, older packages do not have to get tied with emacs core. Currently Ido package is in that situation. I used to use Ido, but now I use the ivy package instead. Some people prefer to use helm instead. I would not be affected at all if Ido was removed from the emacs core in future and moved to GNU Elpa.
I once lost my emacs dotfile and suddenly i was almost unable to use Emacs on my own pc.
Since then, i've decided to apply as little customisation as possible to software I use, and read the documentation and learn the standard configuration instead.
For some reasons nowadays it's trendy to add colors, bells and whistles to things but I've found out that learning the standard/default configuration lets me be instantly capable of intervention on whatever machine i put my hands on. Worst case scenario, i can tell programs to ignore configuration files.