initPC

🛠A collection of C++, Python & Rust development-oriented config scripts to quickly init new machines for my personal use.💻Dotfiles are in a separate repository here: https://github.com/jan-revay/dotfiles and here: https://github.com/jan-revay/windows_dotfiles

How to use

First run on a new machine

1. cd ~
2. git clone https://github.com/jan-revay/initPC.git
3. cd initPC/
4. git checkout <branch> (optional step, branch devel is the default)
5. Run the initPC script launcher:
   • ./run_init.sh - on Linux distros or Termux
   • cd Windows_10 && .\run_all.ps1 - on Windows

✔️ Note: Logs will appear in the folder initPC/Logs/. Use cat <logfile> to display the log file with the original VT100 colors.

Applying changes to your machine

Run the refresh command from Bash, after you have updated the initPC or dotfiles repo (e.g. adding a package, changing a config file, or adding an alias...), to apply the config change to your machine (after the first run). The script never removes any packages other than the ones in apt-get autoremove, therefore removing packages from the init script does not have any effect after the first run.

Branches

1. devel - development and experiments, might be inconsistent or broken regularly. Consistent, and fully functional changes from the branch devel might be merged into the branch testing. The devel branch is expected to be broken from time to time (e.g. when working on larger changes "per partes" or experimenting) and it might not always be possible to init a machine using it. New changes are usually pushed to the devel branch directly, however, very large changes can have an individual feature branch.
2. testing - shouldn't be broken or inconsistent most of the time, changes from devel that are queued to be accepted to the stable branch (or rejected). If a change is rejected from testing it will be dropped via a commit into devel that will be fast-forward merged to the testing branch again.
3. stable - tested, stable, useful, production-ready, and not expected to change much in the monthly horizon.
4. LTS - debloated, (also tested, stable, useful, production-ready) and not expected to change in the yearly horizon. Only necessary stuff. Possibly useful for detecting whether bugs in the stable branch are caused by the init script or to be used as a substitute for the stable branch while the stable branch has a critical bug. Debloating is done via additional commits on top of the LTS branch, therefore syncing stable and LTS is done via rebasing to preserve the debloating commits on top. As the LTS branch has additional commits on top, it is tested separately.
5. feature-<name of the feature> - all feature branches should be branched off and merged to devel. Features and bugfixes of testing, stable, or LTS should always go through the devel branch first (following the change workflow below).
6. archived/<branch-name>-<YYYY-MM-DD> - branches archived before a push --force.

LTS, stable, and testing branches are expected to be always in a consistent state so that they can always be used to init a new machine e.g. VM or a bootable partition.

✔️ Note: By stable I mean free of unpredictable behavior and crashes, not as described here: https://medium.com/@gordon.messmer/what-does-stable-mean-4447ac53bac8 (TODO toread)

Change workflow

                    functional &         tested, stable, useful   not changing, debloated,
    impl.            consistent**          & production-ready        retested & stable
O---------> devel ---------------> testing -----------------> stable -----------------> LTS
|             ∧    ff-only merge             ff-only merge                rebase
| impl.       |
|             |
+-----> feature-branch
 large
 change

** "consistent" means, among other things, that all CI tests (implemented via GitHub actions) pass successfully.

FAQ

1. Why don't I use Ansible?

TODO

2. Why don't I use Chezmoi?

TODO

3. Is the refresh command idempotent?

By idempotency we mean: TODO

Let:
R_C1 - executing refresh resp. initPC via ./run_init.sh on a commit C1
S - clean state (state after installing a new OS before running ./run_init.sh)
𝓢 - set of all possible states of an OS image
∘ : R_Ci x 𝓢 -> 𝓢 - application of the `refresh` command to the state

We want:

R_C1 ∘ (R_C1 ∘ S) = R_C1 ∘ S

TODO

4. Does runing the refresh command after a change in this repo on a new machine produce an equivalent state to running refresh on an existing machine?

In general no.

TODO - when does this hold and when it does not?

Let us have 2 commits:
C1
C2

C1 -> C2

And let:
R_Ci - executing refresh resp. initPC via ./run_init.sh on a commit Ci
S - clean state (state after installing a new OS before running ./run_init.sh)
𝓢 - set of all possible states of an OS image
∘ : R_Ci x 𝓢 -> 𝓢 - application of the `refresh` command to the state

We want:

R_C2 ∘ (R_C1 ∘ S) = R_C2 ∘ S

TODO

1. Merge and deprecate the InitNewPC repo InitPC repo on org GitHub and initAndroid repo.
2. Merge with LogidCfg repo
3. Test the Windows setup script on a VM
4. Create aliases for PowerShell
5. Try merging the apt, flatpak, and snap install commands
6. Have a look at popOS packages and add the useful ones to other init scripts
7. Design a system for applying the configs on all my machines once they are updated here.
   • implement refresh alias
   • add notification to .bashrc if the initPC or dotfiles are not up to date
8. Add more C++ tools from here: https://github.com/cpp-best-practices/cppbestpractices/blob/master/02-Use_the_Tools_Available.md
9. Add Bats automated tests
10. Try adding NixOS
11. Create CI tests on GitHub
12. Todos from the repo
13. Make the core Linux init script Debian based (i.e. other distros just add stuff to the Debian base init script)
14. Maybe replace the Debian variants (Ubuntu, PopOS...) with a single Ansible script with conditionals?
15. Do some research on whether snap and flatpak packages work in WSL resp. which alternative package manager to use in WSL
16. Consider running the whole ./run_all.sh script as sudo and removing sudo commands from the script.
17. Consider using http://www.bashbooster.net/, https://github.com/bevry/dorothy, https://www.chezmoi.io/ or similar libraries (see: https://www.chezmoi.io/comparison-table/ and https://dotfiles.github.io/utilities/).
18. Format to max 82 chars in a line.
19. Echo errors to stderr
20. Make the script compliant with the Google Bash style guide.
21. Consider running different files in different subshells i.e. not using the source command.
22. shared_gui_packages_install.sh
23. Automatic formatting of markdown files
24. Format markdown files (add linebreaks, beautify...)
25. Consolidate branches (unmerged feature branches).
26. Backup solution