As used for my personal laptop.
- Some configuration for tools, and some unique abilities, some of which (but not all) are described below.
-
Substantial Emacs configuration with workarounds for prominent bugs in TRAMP, LSP, and Magit.
-
Custom Bash history handling that archives each session's separately while still starting each session with its initial history being the combined histories of all sessions. The grouping of each session's history is preserved in the combined. Removal of duplicates and of user-specified ignores is done in the combined. Extra effort is made to be robust with multiple concurrent sessions and with other aspects.
-
Custom Bash prompt.
-
Partitioning of SSH multiplexing, so that particular functionalities benefit from connection sharing within a specific functionality, but so that sharing is not done across separate functionalities in order to avoid one's accidentally crashing another's connections. This is configured for Emacs for TRAMP's
/ssh:
and/vagrant:
methods, and formy-deploy-setup
, and for optional general use. -
Setup to analyze and browse the source-code of The Rust Programming Language itself from Emacs. This is especially useful for studying or debugging The Rust Standard Libraries (either directly or when stepping into a custom toolchain's used by a project). This requires special configuration of
lsp-mode
andrust-analyzer
(similar to what is done for VS Code to do this). This works best with a few tweaks to arust-lang/rust
directory. -
GDB commands for generating LLVM (Clang, Rust, etc.) code-coverage reports multiple times before a process exits, which is useful to see the current coverage of a program before something else happens to it, and which is useful when injecting function calls (and other alterations) via GDB to conduct spontaneous tests and iteratively exploring the coverage effects.
-
Automatic setup of GDB to find debug-info and source-code in dedicated per-user or system-wide temporary directories, including for non-Home-Manager non-NixOS platforms.
-
Can deploy itself to a remote user's home directory, in various POSIX OSs, by invoking a single command that automates bootstrapping this. Desirable for easily having my personal setup in different hosts. This command is automatically invoked for my Vagrant VMs, and is also intended to be invoked for remote machines (e.g. manually when working with preexisting machines of a company, or automatically (or manually) when provisioning a new machine).
-
Platform-specific detection that installs packages and configures things to be the same or similar in different OSs. Based on a pathname scheme for uniformly and hierarchically locating platform-specific and architecture-specific parts, based on a scheme for identifying different platforms.
-
Currently supports:
FreeBSD
,Linux/Alpine
,Linux/Debian
,Linux/NixOS
,Linux/Ubuntu
,NetBSD
, andSunOS/OpenIndiana
. Further support for other POSIX OSs can be added in the future. -
Works when a home directory is simultaneously shared across multiple machines of different OSs and different CPU architectures. The installation and configuration of some tools is also setup to work for this, e.g. GDB's, Cargo's, Emacs', and some others.
-
When in NixOS, incorporates Home Manager, with configuration for MATE Desktop, Firefox, Emacs, Rust, and more.
-
When in NixOS, integrates with, and uses some of the options of, my NixOS configuration. Provides the "skeleton" for new user's home directories, giving reproducible consistent user environments that can be tailored per-user.
-
When in NixOS, uses KeePassXC for automatic entry of: website passwords; SSH key passphrases and adding to
ssh-agent
; and as the Secret Service (D-Bus API) (instead of GNOME Keyring or KDE Wallet) which is further used for: Git credentials; NetworkManager (wifi, VPN) passwords; GnuPG key passphrases (via thepinentry
program); etc. Premade template DB and browser settings, to help a new user get started with this consistently. -
When in NixOS, provides extra support for debugging of binaries (executables & libraries) installed by Nix packages (pre-built w/o rebuilding or locally-built) according to your choice. Options for Home Manager to configure all this.
- When in OpenIndiana (and potentially Oracle Solaris), has tools installed, enabled via building with my patches, that are not usually available for this platform.
-
This repository enables both: sharing changes between multiple users (via the
main
branch), and tracking private per-user dot-files (in private per-user branches). -
Companion support script for easily setting this up for new users, with hidden
~/.git
so that home directories normally do not appear as repositories (which is normally undesirable). The dot-files remain a working-tree checkout of each user's repository. -
Companion command for temporarily unhiding
~/.git
, for working on dot-files changes.
If you'd like to try my setup (which, beyond having the "dot" files, also installs some packages and also records the preexisting contents of the home directory):
From a checkout of this repository:
REPO_DIR=de-dotfiles
git clone --branch=main https://github.com/DerickEddington/dotfiles.git $REPO_DIR
To a remote user's home:
#VERBOSE=5 \
MY_DEPLOY_SETUP_DOTFILES_FROM_REPO=$REPO_DIR \
XDG_DATA_HOME=$REPO_DIR/.local/share \
$REPO_DIR/.local/bin/my-deploy-setup ssh://[USER@]HOSTNAME[:PORT]
The target remote host should be a fresh VM (see the previous section above for
which OSs are supported), and the host that clones the repo and runs
my-deploy-setup
could also be another fresh VM, so that you don't mess with
your own hosts and users' homes, and so that you don't have to trust my code.
Or, you can do all the above cloning and deploying commands in only a single
host (which could be a fresh VM), by placing the clone outside of the target
home dir (so it's not captured), and by replacing the ssh://...
with
dir:$HOME
(so it targets the home dir in the same host).
You can see that my-deploy-setup
prepared a branch for the user's future
changes to the home dir configs and that the preexisting contents of the home
dir were recorded as a tagged commit in the history and then the new contents
were merged with that:
user@target ~
▸ with-unhidden-gitdir git log --all --graph --oneline
From a user's home that already has my setup installed, it's easier to deploy
the main
branch (or the user's branch) to some other host:
user@target1 ~
▸ my-deploy-setup $TARGET2_URL