commit 27756d5ca08b5bcdf1d47c2431ae24f29743c24d
parent fc419257e3a01a427b3fdbef862d40bfe371e891
Author: Andrew Laack <andrew@laack.co>
Date: Sun, 26 Oct 2025 05:18:12 -0500
Incremental posts
Diffstat:
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/posts/wip/complexity-facilitates-opression.md b/posts/wip/complexity-facilitates-opression.md
@@ -0,0 +1,5 @@
+# Complexity Facilitates Opression
+
+Web browsers are complicated pieces of software. The complexity in making a web browser is why there weren't any fundamentally new web browsers for many years until the LadyBird browser began development.
+
+This complexity built a moat around Mozilla and Google, allowing them to maintain a duopoly on browsers. While derivative browsers exist that are built on the underlying open source projects, these browsers are no more than a reskin of the existing browsers.
diff --git a/posts/wip/my-ideal-vcs.md b/posts/wip/my-ideal-vcs.md
@@ -0,0 +1,13 @@
+# My Ideal VCS
+
+These are some things I want from a VCS and how I would implement that.
+
+- Patch based
+- Simple to use
+- Simple to understand
+- Minimal code
+- Written in C
+
+Most of the complexty from VCSs iss how they manage the resolution of conflicting changes. As such, I'd rather not implement that. This should be left as a job for either a) the editor/IDE or b) the humans responsible for the changes.
+
+I get concerned by automatic merge conflict resolutions because changes within given file that act upon similar lines of code can often cause unexpected side effects when they are reliant upon the same variables in code. Given this, a human must be in the loop when resolving these conflicts, unless an exceptionally sophisticated VCS uses ASTs to determine if there is interdependence between the code. As such, I'd like my VCS to see when there are changes from differing patches on the same files and inform the use about this. These conflicts should then be resolved by a subsequent patch that combines the prior two patches into one.
