Initial

README.md

@@ -0,0 +1,44 @@
+# website-pictures2
+
+**The World's Worst Way To Do This**
+
+## What
+
+### What I Did Before
+
+My website is not hosted locally and my server is perpetually
+running out of space (actually, this is not true anymore???)
+
+`website-pictures1` used GitHub to host compressed and encrypted JPGs
+that would then be cloned on a cloud server (OCI free tier :pray:)
+and built into a static site.
+This model was based around assuming the following:
+1. I don't want people to see these pictures without fist being authorized
+    - i.e. HTTP Basic Auth
+2. I do not trust GitHub to hold my pictures in an unencrypted format (follows from 1)
+3. `Ramiel` was the sole source of truth for building the picture directories and
+4. the cloud server was responsible for building the static pages.
+
+### That Was Bad, Actually
+
+The previous model was lame because:
+1. If I do not have access to `Ramiel`, I can't do anything
+    - it was all symlinks oh my god
+2. it was literally shell scripts
+    - ok, no diss to shell scripts, these in particular were actually super manageable.
+    - the problem is that expanding them to do more sucks bigly
+3. key point: I never added more pictures because it was a Huge Pain
+
+### What I Will Be Doing Now
+
+I've just confirmed that `bigrack` has more than enough space to do the following:
+1. Store pictures compressed, locally
+    - you can just add to a 7z archive whenever, so uncompressed images need not exist more than transiently
+2. Build a static page, locally
+    - big if true: imagine being able to debug without doing a full rebuild on your server
+3. Deploy the static page to `shrimplover`
+    - no like seriously why do I pick hostnames like this
+
+## How
+
+python or something idk

activate_venv

@@ -0,0 +1 @@
+.venv/bin/activate