Howard Abrams

I think overall its a mistake to try to over automate this process. It's brittle and the requirements are simply not the same as a server environment that needs to be simple to replicate X versions quickly, repeatedly and frequently.

Automation needs fairly constant attention in the order of little tweaks week over week to fight the inevitable mismatch between the automation and the software networks that it interfaces with.

Do you reinstall your workstation once a week? Unlikely and probably would be an unproductive use of your time.

The way I approach it instead -

The first thing I do is list everything I need for a workstation in an orgmode text file. For why orgmode really works well for this -

http://howardism.org/Technical/Emacs/literate-devops.html

I aim to make a "computational document" that I can execute a bit at a time as I review/check each piece on installs and upgrades of the system.

To me it's really critical that there are links to the webpages and text notes about these configurations alongside the code I'm using.

I check this and the needed config files into a single git repository.

As the workstations (I use the same document for workstation,laptop, studiopc, homeserver, android) age I'm inevitably adding and upgrading bits of the git repository. I make sure that I work from the orgmode document whenever I touch any configuration.

I use Linux and Emacs (which means a big part of my software environment is in a git controlled .emacs.d) so the…

> I can stage and unstage individual hunks, do complex interactive rebases, squash commits, break apart commits, etc. much faster in Magit than I can in other Git GUIs.

I can do all that pretty fast in GitUp, too. Since most of the commands there have quick keyboard shortcuts.

My most common workflow besides staging anything is (to make sure history is clean):

- split up a commit (add/remove files or hunks if the commit contains stuff that should go into another commit)
- move new commit up/down the branch (doesn't require interactive rebase in GitUp)
- squash up/down

(undo/redo from time to time)

As far as I understand, Magit doesn't offer anything in that regard except the good old interactive rebase [1]. In GitUp moving commits is (u)p/(d)own and (s)quash with parent

> Maybe you're hung up on the "G" part; perhaps I should have just said "UI" rather than "GUI".

The distinction doesn't matter. The keyword in both GUI and UI is User. As a user I found GitUp to be a much better tool than Magit. Though Magit does probably allow for more very advanced usage most people don't do. [2]

However, actual useful usage like I described above? Ooh boy, no one does it except GitUp for some reason.

[1] I only have this blog post to confirm https://www.howardism.org/Technical/Emacs/magit-squashing.html

[2] There's another downside to GitUp: it's very slow on repos with huge histories. Probably due to the git library it's using.

Consider using org-mode [1] as your primary word processor and committing revisions to git. I recommend org-mode because org documents are saved as plain text and therefore can be easily diffed. org-mode can also be exported to many formats [2]. If you are concerned about how the look and feel of writing in plain text might impact your experience authoring a document, there are lots of editor specific tutorials for beautifying the presentation of org documents. Here is one such article on beautifying org documents in emacs [3]. Also, if you choose emacs as your editor and you are uncomfortable using git, then I recommend magit [4] because it makes git functionality highly discoverable.

[1] https://orgmode.org/

[2] https://orgmode.org/manual/Exporting.html#Exporting

[3] http://www.howardism.org/Technical/Emacs/orgmode-wordprocessor.html

[4] https://magit.vc/

That's an ansible task to do something, but it's not the task solved in the article, or in any of the other linked examples.

Things that you haven't done before are harder than things you do all the time, and I would've reckoned trying to do them in ansible is much harder than doing it interactively, but I'd be interested in learning.

If I find an article like this[1], how do you translate it into the artefact I would want to keep in source control? In org-babel it's this[2], so what would that look like in ansible?

[1]: https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-using-iptables-on-ubuntu-14-04

[2]: http://www.howardism.org/Technical/Emacs/linux-iptables.org.txt

Once you've done it and you've documented it, I can see how you might translate that into ansible (or chef or whatever), but that's a different thing.

Fish shell's joke tagline is "Finally, a command line shell for the 90s".

I believe that the developer experience for all sorts of tooling has improved dramatically over the last 15 years or so, coinciding with GitHub's rise in popularity.

e.g. the plugin ecosystem for Vim or Emacs have improved, let alone options like VSCode. Tools like Vagrant made it easier to work with VMs. Containerised workflows have similarly improved some cases. Languages like Go-lang or Rust seem pretty nice in some cases. etc.

Shells are also the kind of thing that developers use. I don't believe bash is the best we can practically get. -- Though.. I have heard of other, fancier shells; (or cool ideas like https://ambrevar.xyz/lisp-repl-shell/ or http://howardism.org/Technical/Emacs/literate-devops.html). These haven't caught on.

StumpWM sort of gets you a dynamic interface. Use the Scheme(ish) shell (http://scsh.net/) and you can get ...kind of dynamic.

Then there's the obligatory mention of this guy who took it to the next level http://www.howardism.org/Technical/Emacs/new-window-manager.html

Plan9 + ACME had an interesting 'editor/OS' integration, especially for the time, where you could highlight text, invoke a mouse click action, which would send it to a shell, and return the result on a new-line within your editor. Having everything exist as a file with an addressable file descriptor really made the platform powerful (too bad the licensing was horrible until recently). It's not homoiconic as a proper LISP-1 would be but still an interesting approach.