4 files changed, 267 insertions, 0 deletions
diff --git a/docs/random/gemini_tldr.md b/docs/random/gemini_tldr.md
new file mode 100644
index 0000000..b232bfd
--- /dev/null
+++ b/docs/random/gemini_tldr.md
@@ -0,0 +1,132 @@
+# Gemini TL;DR
+
+2020-06-05
+
+For any internet protocol, you can either make it a few thousand words long, or make it 114M. Of course, we know this 114M wasn't there in the first place. W3C has tried very hard to standardize the web, without guarantee it would be simple. So, what we have now is a collaborative system where it's easier to introduce a standard than to deprecate one (remember Adobe Flash?). It's reassuring to know there isn't a central megacorp monopolizing the web, but this openness comes at a cost. It's when evangelical developers who can't program proper desktop apps abruptly choose to make a new web framework, a parasite on web browsers - one of the only things that are largely cross-platform. Because the work of portability has been handled by Mozilla, Google, etc, not by themselves, there is virtually no limitation regarding what you can do with it. If a handful of people suddenly like your "standard", all modern browsers will get to support it eventually.
+
+[Gemini](https://gemini.circumlunar.space/) is a young protocol that's slightly heavier than Gopher, but radically more lightweight than the Web. Its [spec](https://gemini.circumlunar.space/docs/spec-spec.txt) is 4.4k words long as of time of writing, which, excluding the appendix, is a 20-minute read if you skim past the microscopic details. Here is a TL;DR of the specs that's ~1k words long.
+
+## Prerequisites
+
+Before you proceed, there are a few fields of knowledge that you need to temporarily throw away while reading this post, plus a few you don't. Most of the former is HTTP-related.
+
+### Throw away entirely
+
+- CSS
+- JavaScript(R)(c)TM
+- All the fancy frameworks you have learned about (flask, jinja, react, jquery etc.)
+- Apache and nginx
+
+### Place within arm's reach
+
+- HTML
+- HTTP:
+    - headers
+    - 3-digit status codes
+    - verbs, e.g. GET, POST
+    - cookies
+
+### Do not throw away
+
+- TCP
+- TLS
+
+## Gemini spec
+
+### Synopsis
+
+- "Gemini" is the name of a [crewed space mission by NASA](https://en.wikipedia.org/wiki/Project_Gemini).
+- this spec is not complete, but probs won't change a lot soon.
+- gemini transports data via TCP/IP on port 1965 because the first crewed flight of Gemini was on March 23, 1965. This means unprivileged users can run a gemini server, too.
+
+### Requests and Responses
+- Gemini terminates lines with CRLF (`\r\n`) in requests and response headers.
+- Everything should be UTF-8.
+- Client sends a request to server: `<URL>\r\n`.
+- Server first responds with a response header: `<STATUS> <META>\r\n`.
+- Speaking of status codes, some helpful ones are `20 SUCCESS`, `30/31 REDIRECT`, and `51 NOT FOUND`. Status codes with the same leading digit belong to the same category and are treated similarly in clients.
+- If server returns `2x (SUCCESS)`, it will send a response body (e.g. the page requested, the file the client wishes to download, etc.) right after the response header. In such case, the `<META>` in the header should be the MIME type of the content.
+- If the response body belongs to MIME type `text/*`, it should use CRLF as its linebreak. LF is also accepted.
+- No support for compression or chunking of the content.
+- There is no keep-alive. A TCP connection is closed right after a request and response, and must be re-initiated should the client make another request.
+- Sending requests whose URL scheme is not gemini is called "proxying", and is not supported by most servers.
+
+### `text/gemini`
+
+- By default, the response body MIME type is `text/gemini`.
+- You can also serve other types, of course, but you'll have to specify in `<META>` of the response header.
+- The following list will teach you how to write `text/gemini`.
+
+#### Line types
+
+1. Text lines: ezpz, just normal text. Authors and servers should not "hardwrap", i.e. limit column width to e.g. 80 chars; the client should wrap a long line containing the entire paragraph into a block.
+2. Link lines: any non-preformatted line starting with `=>` is a link line. It should be followed by a URL, then optionally a link description. Like this:
+
+```
+=> gemini://fkfd.me/ fkfd.me geminispace
+```
+
+which is equivalent to this in HTML:
+
+```
+<a href="gemini://fkfd.me">fkfd.me geminispace</a>
+```
+
+Expect absolute and relative links, and ones that aren't even on gemini.
+
+3. Preformatted lines: any line between two lines that read ````` (3 backticks) is a preformatted line. Just like markdown. Like this (prefixed with a space in order not to interfere with formatting):
+
+```
+ ```
+ Without preformatted lines, ASCII art wouldn't have been possible!
+ ```
+```
+
+It should be rendered as monospace.
+
+4. Heading lines: any non-preformatted line starting with 1-3 hashes is a heading line. Also, you know, sure, like markdown. Like this:
+
+```
+# h1
+## h2
+### h3
+#### nope, not a heading
+###interestingly, the whitespace is optional
+```
+
+5. Unordered list items: any non-preformatted line starting with an asterisk is an unordered list item, i.e. an item of a bullet list. Like this:
+
+```
+* list item 1
+* list item 2
+*whitespace is optional again
+* although if I want to mimic italics it would be
+*pretty* hard
+* to distinguish it from list items
+```
+
+### TLS
+
+- TLS is mandatory for Gemini.
+- You must use TLS 1.2+; 1.3+ is encouraged.
+- A client can trust whatever cert it sees, but the recommended approach is to implement a TOFU (Trust On First Use) system, where:
+    - you trust the cert the first time you visit a site, even if it's self-signed
+    - you remember it
+    - every time you access the site, it sends you this very cert, so you know everything's fine
+    - the client will warn the user if the server abruptly sent a different cert when its previous one hasn't expired yet: likely a MITM attack (but also likely the site admin just replaced their cert for some reason).
+
+This eliminates the need for a CA, thus making TLS and gemini itself more accessible and widespread.
+
+- A client can prove its identity with a "Transient client certificate".
+    - on a site that asks for one, client generates and sends a cert (regular sites don't; such procedure must be manually approved by the user)
+    - the cert is sent along with all subsequent requests to this host
+    - server can identify this user now
+    - this is like cookies in practice, but very different in implementation
+    - one cert is limited to one domain
+    - one cert should not exist for longer than 24 hours; it's for one session only.
+
+## Conclusion
+
+This is it; 4.4k words of gemini spec summarized & exemplified in ~1k words. Whether you're reading this on Gemini or the Web (or gopher), I encourage you to join this community of members who are seeking asylum from the debris of the modern web. Gemini is still in an early stage; loads of decisions to make, and lots of pitfalls that the web has fallen in to avoid. This concludes our journey around the gemini spec today; see you in low space orbit.
+
+Oh, also, [McRoss](https://git.sr.ht/~nhanb/mcross) is an awesome GUI client.
diff --git a/docs/random/how_fkfd_is_made.md b/docs/random/how_fkfd_is_made.md
new file mode 100644
index 0000000..0615df9
--- /dev/null
+++ b/docs/random/how_fkfd_is_made.md
@@ -0,0 +1,52 @@
+# How an FKFD Comic is Made
+
+2020-07-21
+
+I don't consider myself a cartoonist, let alone good cartoonist. I am unqualified at comics in all aspects, you know? I can hardly draw anything that's not a rectangle, circle, or straight line; for every final stroke you see on the canvas, I have undone and redone three times; my update frequency is like `abs(tan(x/k))` where k is around 10 days\^-1 [1]. One day in May I pushed 4 comics. And then I completely skipped June.
+
+Let me keep it short and talk about how an fkfd comic is made. Not technical details (i.e. export as webp, then png, then run `./submit.py`...) but how I come up with ideas and express them in comics.
+
+## Life -> Idea
+
+However boring your life may be, you always find ideas bumping from inside your brain; they may just be a little dull. I catch my inspirations right away when I come up with one. Here is a list of common ideas.
+
+- I look at things that vaguely resemble others, and make fun of that[2].
+- I ask myself questions "what if we...?" and imagine the possibilities in the wildest way[3].
+- I contemplate about today's society and world, and when I cannot squueze jokes out of them, I make them look thought-provoking[4].
+- I voice concerns about today's technology and its relationship with human life[5].
+- Also comics that are straightforward xkcd parodies[6], or even ones that reuse xkcd graphics[7].
+- Giant buildup for giant fun, like flowcharts and tables[8].
+- Irony pointed at one certain type of person[9].
+- Inevitable graph jokes[10].
+- Personal rant[11].
+- Puns and wordplay[12].
+
+The ideas can be funny or serious, revolving around an outdated or emerging topic, whatever. Apply the craziest spices until the idea is hot enough to attract a handful of people. Avoid *really* niche hobbies, and definitely don't go to depths (i.e. inside jokes), for the sake of audience coverage. As a side note, I never deliberately check if my idea has been taken. Too much trouble. I do avoid copying ideas I know to exist, though.
+
+## Others' Idea -> My Idea
+
+My comics are large influenced by xkcd. A few other influencers:
+
+- SMBC for sociological ideas and single-panels
+- C&H for the puns
+- Poorly Drawn Lines for the anthropomorphic figures
+- Random Reddit posts for random ideas
+
+## Idea -> Comic
+
+There are certain periods when I was super innovative and others super productive and/or artistic. The best scenario is when these overlapped, and I was able to commit my ideas on the canvas on the fly. That was definitely efficient, but later when I reflected on comics produced over this period, I would often sense creeping embarrassment for lack of due thoughts before submission, or regret over some imperfections like a forgotten punchline. The second best is those moments when I had a genuinely great idea (at least to me at that time), and had a notebook handy. Once I would jot down a few hint words, like "dead kids sent from heaven to haunt their anti-vaxx parents", but turns out I was terrible at remembering details. Soon I learned to draw a rough sketch, and continuously iterate, fixing grammatical problems and pruning unnecessary words (canvas space is precious). Occasionally, I do it on a whiteboard. Finally, I boot up my lappy, draw what's on the paper/whiteboard through my wacom tablet into krita, sometimes verbatim and sometimes with a few minor adjustments, then re-orchestrate the elements so they fit on a digital canvas. Behold! Digital "art".
+
+## Footnotes
+
+[1] Which means my update speed peaks about once per month, while somewhere in the middle it's zero.  
+[2] Notable examples: [Heroic Ball Pen](https://fkfd.me/13), [Chihuahuatamayo](https://fkfd.me/74), and [Keychane](https://fkfd.me/93).  
+[3] Notable examples: [Night Plane Spotters](https://fkfd.me/70), [Soul Counter](https://fkfd.me/79), and [Amazon Ring](https://fkfd.me/87).  
+[4] Notable examples: [Intolerance](https://fkfd.me/65), [Zeta-373](https://fkfd.me/77), and [Stray Cats](https://fkfd.me/90).  
+[5] Notable examples: [Innovations](https://fkfd.me/73), [Intended Internet](https://fkfd.me/86), and [JavaScript](https://fkfd.me/101).  
+[6] Notable examples: [Code Quality](https://fkfd.me/10), [Technology, Inc.](https://fkfd.me/11), and [Irrelevant xkcd](https://fkfd.me/67).  
+[7] Notable examples: [Python](https://fkfd.me/6), [Entropy Harvesting Daemon](https://fkfd.me/81), and [Childhood Misconceptions](https://fkfd.me/92).  
+[8] Notable examples: [Partitions](https://fkfd.me/16), [X-over-Y](https://fkfd.me/53), and [Python Code With No Documentation](https://fkfd.me/55).  
+[9] Notable examples: [Flat Earthers](https://fkfd.me/21), [Blogging](https://fkfd.me/26), and [Wish](https://fkfd.me/71).  
+[10] Notable examples: [Time Consumption](https://fkfd.me/9), [Turning Point](https://fkfd.me/59), and [Graph Nerd Sniped](https://fkfd.me/89).  
+[11] Notable examples: [Smart Home](https://fkfd.me/46), [Middle Button](https://fkfd.me/52), and [Grades](https://fkfd.me/96).  
+[12] Notable examples: [Wheeled Armchair and Armed Wheelchair](https://fkfd.me/54), [One-Letter Modifications](https://fkfd.me/69), and [Company Rules](https://fkfd.me/88).
diff --git a/docs/random/index.md b/docs/random/index.md
new file mode 100644
index 0000000..dc60a86
--- /dev/null
+++ b/docs/random/index.md
@@ -0,0 +1,12 @@
+# Random stuff
+
+If you know me you'll be impressed how quickly and unexpectably my
+interests change. I'd pick up something and, whether I'm done with it or
+not, I'd dump it into a heap labeled "stuff I loved at some point", and
+they just stay there, like malloc'd memory that will never be freed.
+
+Nevertheless, occasionally I leave a permanent trace along the way.
+
+- [Gemini TL;DR](gemini_tldr)
+- [How an FKFD Comic is made](how_fkfd_is_made)
+- [The Real Git](realgit)
diff --git a/docs/random/realgit.md b/docs/random/realgit.md
new file mode 100644
index 0000000..6fa9cf5
--- /dev/null
+++ b/docs/random/realgit.md
@@ -0,0 +1,71 @@
+# The Real Git
+
+2020-05-02
+
+This post is for young developers like me, ditching GitHub/Lab for Gitea with a self-recognition as a hipster. There is a <a href="#tldr">TL;DR</a> at the bottom.
+
+For too long have I held the incorrect belief that we needed a GitHub alternative that federates, and joins the fediverse using ActivityPub. Well, it could be a thing. Gitea is good, and I'd be pleased to see it get better by implementing AP.
+
+## Interface
+
+Ask yourself: is a web app the only way to do issues/tickets, pull requests/merge requests, etc? Hear me out: people take it for granted that a good product deserves a shiny dashboard. Over the course of GitHub's "success", shiny tabs labeled "issues" and "pull requests" gain ubiquity on other VCS frontends. It disrupted the industry. 
+
+How did developers contribute to FOSS projects back when GitHub wasn't a thing? Well, before StackOverflow, we had forums. Similarly, before GitHub, we had mailing lists. It has been long known to me that the Linux kernel is developed on a mailing list, where contributors would submit patches and receive a *Wish You Were Never Born, Dumbass* Certificate from Linus. However I, along with many others had no idea how it's *actually* done. Check out [the PR page of the Linux repo on GitHub](https://github.com/torvalds/linux/pulls). *Too many* people have mistaken a web UI, if not limited to GitHub, for *the* development platform for *anything*. Well, it's definitely not how Linux is developed.
+
+The web interface is intrusive. You may be unsurprised to hear some people, typically new coders making their own GitHub page, code directly into GitHub's web editor, commit one file at a time, and test changes in the browser. It's the UI mindset. GitHub and websites alike hijacked us, and we didn't even know. The reason why will be analyzed.
+
+You notice a clear distinction between "coders" and "developers": it's like human evolution, the command of tools. Git is a tool; so is GitHub. A tool is intended to excel at a limited range of work. If you cry about how GitHub sucks as a cloud drive, you are cracking a walnut with a drill. Sharpening your skill is a superset of mastering the toolchain. Likewise, it seems sensible for me to, at this point of my coding hobby, leap out of the interfaces and embrace what Git should have been. After all, what we really wanted is not an interface, but a workflow, in which field Git's utilities work just fine.
+
+## The Real Git
+
+I will use [sourcehut](https://sourcehut.org/), aka sr.ht as an example. I stumbled upon it a while ago, but it wasn't until yesterday that I tried it out for its simplicity. Simple as in no bloat, not in being for dummies. For starters, there's no JavaScript. Really, you should check out its interface. Or not. It doesn't matter, something else does, and I sincerely regret having overlooked this "selling point": the absence of selling points. The web design does not only *look* simple, it *is* simple. Almost read-only, you can't do pretty much anything with it. For this reason, I refuse to call it "Git on steroids"; instead, it's "Git without hurdles", hurdles scattered in your dev work every single day. OK, listen carefully: all the interactions I used to assume to be web-only, happen on mailing lists. To submit a patch (retro version of "pull request" - remember that?), you simply commit your changes locally, run this command: `git send-email --to="~user/list@lists.sr.ht" HEAD~`, and your patch is out there waiting for review. Of course, a shitload of configuration has to be done ahead, which is partly why this email-driven development hasn't really taken off in the younger demographic.
+
+Despite its drawbacks, I find it superior to web apps. First of all it obviously saves bandwidth as well as time, since no time is wasted on the UI; the terminal plus an email client satisfy all needs. Second is because it's *dank as shit*. With the right configuration, you can set up a TUI email client, which enables you to combine the entirety of your workflow in the terminal. Finally, and the **most importantly**: it does *not* require an account for contributors to submit a patch. All it takes is your email address as your identity, and an email containing your patch. And *this*, is how Git is supposed to work. Read more on @OTheB's blogpost, the one that had me sold: [how to use git](https://boxin.space/post/how-to-use-git) (with fancy screenshots I'm too lazy to take). I'm not asking you to stop using web UI's; I'm reasoning how the alternative is more efficient, and should be considered as a solid option.
+
+### When is this approach favorable?
+
+Under what circumstance should you try this? When you're in a (probably small in core contributors) team maintaining a project actively. Mails feel more like a to-do list for today than a kanban for this month, as you may find in a web forge. Patches and feedback get stuck in the mailbox before you resolve them. You'll be more motivated to fix them or respond to them. 
+
+## Pains
+
+### Email
+
+With any given Git hosting platform with a fancy web interface, you very likely use your email to login. After that, you only occasionally receive notifications in your mailbox. Stuff happens over HTTP mainly, so it doesn't matter if you're using a shitty webmail interface like GMail. Let's say you ditched GitHub and went all in on email-driven development. Now email becomes a crucial part of your web-free workflow, and you can't just use another web interface while expecting to be a 10x dev. Furthermore, the email address is no longer *part* of your identity; it *is* your identity. Your patches are submitted through it, PGP key generated under it. So it is utterly critical to get this right before you even start.
+
+#### Provider
+
+It would be best if you have a personal server and are able to install a mail server yourself. I can't. Fortunately, I found a provider, thanks to [Drew DeVault's recommendation](https://cmpwn.com/@sir/102452352875414214) (first on the list). (Oh, did I mention Drew is Sourcehut's creator?)
+
+#### Local client
+
+IMAP and SMTP are old. This means were you to manually set up your account, there'd be standards and conventions, old and new, in any given field to fill out when configuring a client. For example (excuse my stupidity), TLS and STARTTLS are somewhat different, but I'm too lazy to check. I spent a tediously long time configuring 5 clients, 2 of which are working.
+
+In the [list.sr.ht wiki](https://man.sr.ht/lists.sr.ht/etiquette.md), I learned to [use plain text in email](httpd://useplaintext.email) and keep email etiquette in mind. This is easily achievable.
+
+I also had a reasonably short time setting up an SMTP client (turns out to be different from an fully-fledged email client), namely `msmtp`. It's a CLI utility for sending emails. You can configure `git send-email` to use it as one of the possible methods. See [git-send-email website](https://git-send-email.io/).
+
+### Community
+
+Admit it: mailing lists, although barrier-free, rarely gets as much attention as a web UI like a GitHub issue thread. Also, easy it may have been for you to get a email address you're proud to tell others, others' may be crap like SweeetBabe.69owo@gmail.com. Using email just feels more personal. For this reason, I suggest we use email-driven development for collaborative projects with a firm maintainer team, encourage experienced devs to join, and leave the mailing list as a feedback channel for regular users. Keep a mirror on a "regular" forge, as is the case for Linux, but I can't help cringing at [how](https://github.com/torvalds/linux/pull/695) [many](https://github.com/torvalds/linux/pull/708) [joke](https://github.com/torvalds/linux/pull/727) [PR's](https://github.com/torvalds/linux/pull/753) [it's](https://github.com/torvalds/linux/pull/767) [got](https://github.com/torvalds/linux/pull/779). (I mean, *some* of them are funny.) And a bot would reply under them, taking them to the mailing list. When you make a mirror, however, perhaps you should tell people about it in advance.
+
+## Reflection
+
+I reflected on myself, the guy who thought himself a hipster migrating from GitHub to Codeberg.
+
+### Why had I never heard of email-driven development?
+
+At the news GitHub banned Iranian users without notice under the sanction, I was equally outraged as many of its users. I reached out to [ForgeFed](https://forgefed.peers.community/) to discuss how we should make federated forge services, unaware the distributed nature of Git itself. I also started an issue thread in a repo protesting GitHub's abrupt decision, under which although one person noted how Git is decentralized already, nobody seemed to bring up anything about mailing lists or stuff like `git am`. I suppose the mailing list gang had left GitHub for good? A few days later, speaking up my opinions on IRC, some friends reminded me of the email-as-an-identity thing, but still no mailing list. So, that's basically why I heard of such a thing nine months later than I should have.
+
+### What made me think web UI is the orthodoxy?
+
+It's the first impression. GitHub (ironically) is my first mentor in FOSS. Like many others, I had no idea what GitHub and Git actually are, nor their relationship. As a result, it became a mindset, a mindset where I push buttons for actions and click checkboxes for options. It's undesirable, if you know what I mean. It's a shame for a Linux user for 3 years to be stuck in the web app for what could've been done in the terminal. Interfaces made email appear more old-fashioned than it really is, and this illusion harmed me. I wish I could ask for compensation.
+
+### How many other young devs exactly like me are out there, suffering?
+
+A lot. While beginners tend to wet their hands in a web environment they're familiar with, others like me will regret not having heard of the opposite sooner. That's why I'm asking you to share the word to whoever wants to take their development efficiency one level higher. Not necessarily on sr.ht (they do release their applications as free software, with the need of a mail server). It's worth learning how to amend a commit, rebase, etc.
+
+## TL;DR
+
+Many people believed the GitHub-like UI is the way all FOSS is developed. They are wrong. A web UI is not the only nor the original way to use git; you could use [git-send-email](https://git-send-email.io) to submit patches in mailing lists, and as maintainers you can merge them using git's stock utilities. Some people have never heard of the latter because they were never told about it; meanwhile, the web UI has hijacked their mindset. [Sourcehut](https://sourcehut.org/) is an example of email-driven development with a minimalistic web frontend. In such development scheme you will find your workflow more efficient, especially if you are used to a terminal. The obvious pain in the neck is a good mailbox as your identity and a local client that doesn't suck. I hope you're experienced enough to figure those out. Then it's the low public exposure of a mailing list. Perhaps maintain a mirror on a UI-driven site as a portfolio.
+ 
+The reason why I had never heard of such a thing before is no one told me the exact thing I needed to know. Also GitHub formed the stereotype of a git forge. There are certainly other young people suffering, unaware of email-driven development being an option. Tell them this thing has been around for 15 years.