From 9f53d676501be3f2eb568cb555ebd0b010511616 Mon Sep 17 00:00:00 2001 From: Pavel 'LEdoian' Turinsky Date: Wed, 10 Jan 2024 16:47:46 +0100 Subject: [PATCH] render --- output/about-blog.html | 313 +++++++++++++++++++++++ output/archives.html | 6 +- output/categories.html | 3 + output/category/talks.html | 3 + output/category/technology.html | 66 +++++ output/drafts.html | 3 + output/drafts/forgetting-dns6.html | 3 + output/drafts/ucw-keymap-on-wayland.html | 3 + output/feeds/all.atom.xml | 256 +++++++++++++++++- output/feeds/technology.atom.xml | 256 ++++++++++++++++++ output/index.html | 3 + output/smrst2023-cs.html | 3 + output/tag/infrastructure.html | 66 +++++ output/tag/meta.html | 66 +++++ output/tag/smrst.html | 3 + output/tag/software-engineering.html | 3 + output/tag/trains.html | 3 + output/tags.html | 3 + 18 files changed, 1060 insertions(+), 2 deletions(-) create mode 100644 output/about-blog.html create mode 100644 output/category/technology.html create mode 100644 output/feeds/technology.atom.xml create mode 100644 output/tag/infrastructure.html create mode 100644 output/tag/meta.html diff --git a/output/about-blog.html b/output/about-blog.html new file mode 100644 index 0000000..ff038d2 --- /dev/null +++ b/output/about-blog.html @@ -0,0 +1,313 @@ + + + + + + + + + + + + + About this blog – LEdoian's Blog + + + +
+

LEdoian's Blog

+
+ +
+ + +
+
+

About this blog

+

This is my blog and this article describes its setup and other details about my +intentions. The actual setup is probably the most +interesting tech-wise.

+
+

What is this?

+

My own space on the internet where I can post whatever and link others to it. +It might end up containing rants, guides, ideas, or maybe nothing at all in the +end. Only the future will tell.

+

The blog might even serve as my personal web page/introduction. Maybe. Maybe not…

+

The main motivation is to have low-effort way to post random stuff. Which leads +to my requirements for this thing.

+
+
+

Requirements

+

(The requirements are a bit too idealistic, so not all of them were satisfied…)

+
    +
  • low-effort, me-friendly, low-maintenance – I don't want to have to learn too +many new technologies to use this. This includes the required technologies: +Python, Markdown/reStructuredText, Jinja2, git, …
    • +
  • Technical and math content ~~friendly~~ compatible – I expect that to appear +here.
    • +
  • Static site – for security, coolness factor and control. Also static on the +front-end, because I don't like JavaScript and/or running untrusted code on +my machine (even when in a sandbox). The SSG should likely be aimed at +creating blogs, not documentation. Also, self-contained, as in not depending +on third-party sites.
    • +
  • No moving parts in the infrastructure (or as few as possible) – if it works +on my machine, it should just get mirrored to the public site with as few +modifications as possible.
    • +
  • Transparent – I should be able to understand it, maybe others could also use +it as a resource or take inspiration. (At one point, this deployment itself +started being interesting, so if I can share the background as well as the +final webpage, it would be cool.)
    • +
  • Followable – I know you internet guys like to ~~stalk~~ follow people :-)
    • +
  • Aligned with my values: minimalist, simple, extensible/hackable, FLOSS
    • +
  • If the platform could distinguish translations and do strikethroughs, it would +be nice, but that is not a hard requirement.
    • +
+

There are several features of conventional blogs that I consider to be a +non-goals or even anti-goals. Mostly it is about interactivity – I don't aim +for having any kind of comments here, or really anything that would require +JavaScript or complex HTML/CSS. And appearance goes past me as well, I instead +try to let the browser decide how to display this page – more on that below.

+

The workflow I wanted to achieve is something like: Write the content, git it, +build it (locally, no CI/CD), push it, done. Single write, single push, very +simple.

+

And I managed to achieve something like that, via learning (too much?) about +git.

+ +
+
+

The setup

+

Naturally for a sysadmin/netadmin, the setup consists of 7 ~~ISO/OSI~~ layers:

+
    +
  1. Physical layer: cheap Hetzner VPS. Not physical, but whatever.
    2. +
  2. Network layer: Nginx
    3. +
  3. Persistence layer: this git repo. I will elaborate below why can +you see this both rendered here and in the source form in Forgejo.
    4. +
  4. Content layer: Markdown or reStructuredText files.
    5. +
  5. Business logic layer: Pelican. It's rather +popular and written in Python, I didn't look further.
    6. +
  6. Presentation layer: I hacked my own theme, because I didn't like any in +the pelican-themes repo. +I was a bit inspired by the layout of eevee's blog, but I wanted a dark theme. And as you can see, I +can't do quality frontend, so it ended up horrible… :-D
    7. +
  7. Stalking layer: Pelican's built-in RSS and Atom feed generators. Not +linked from anywhere at the moment, but the repo will tell you what +hides under the /feeds/ path. Or you can utilize the repo (for personal +use – the content's license is not decided at the moment)…
    8. +
+

Most of this is straightforward, the fancy part is my repo. The repo contains +both source and rendered content, so that I can point Nginx right at a checkout +and have Git solve both persistence and deployment without additional moving +parts.

+

There are two tricks in the configuration of Git repositories: pushing to a +checked out repo is enabled by configuring receive.denyCurrentBranch = +updateInstead in the target repository (which is just a normal repo, not a +bare one), and then I just told my source repositories [1] to use +two push targets for the remote (the first line replaces the original push +address for some reason):

+
+git remote set-url --add --push blog_remote gitea@gitea.ledoian.cz:LEdoian/blog.git
+git remote set-url --add --push blog_remote blog_user@blog.ledoian.cz:blog_dir
+
+

The blog user is just a user with SSH access via authorized keys, no special +sauce there. Nginx is then pointed to serve ~blog_user/blog_dir/output/ at +blog.ledoian.cz. (The git-remote(1) manpage requires me to have both +repositories in sync, but as long as I configure all my repositories this way, +I should be safe, and I think I could get away with my blog checkout getting +behind accidentally.)

+
+
+

My workflow and lots of drafts

+

It's Git so it's only natural for me to use various branches and repositories +even for a dumb blog. There are in fact 4 stages an article may go through [2]:

+
    +

  1. A private draft: lives on a branch priv/something, may contain private +infos (like when I would just copy-paste from terminal without redaction) +and this branch will probably never be merged to the main repo. Nothing +about these branches is guaranteed.

    +
    2. +

  2. A public WIP draft: uses a branch called pub/something which is pushed +to Forgejo (and in fact also to the blog itself, but that is just an +implementation detail). The draft is either does not build or is very +incomplete and I expect to add stuff in a way that could break the build, so +I put it on a separate branch. The branch will be probably merged to the +main branch (called blog) when it is ready.

    +

    The pub/… branches can be created either manually or by cherry-picking +from the respective priv/… branch, but that will likely not be +distinguishable. (I am too lazy to keep the references even in the commit +logs.)

    +
    3. +

  3. When a draft is almost ready (or the content has simple syntax), it gets +placed on the blog branch. The only thing that designates it as a draft +is status: draft in the frontmatter, which means that the article will +get rendered and put somewhere on the public blog, but not reachable from +the title page ("unlisted").

    +
    4. +

  4. Of course, eventually (and hopefully) the article gets published for +everyone to see. At that point, it is complete (or at least that is what I +thought when marking it as published). Possibly it might be updated in the +future, but no such update is anticipated at the moment of publishing. [3]

    +
    5. +
+

I use Git to synchronize my private branches among machines, so there are +actually two "server-side" repositories (private and public one) and thus two +remotes. [4]

+

As for the actual workflow, for the main branch it usually consists of: writing +content, committing it, building the web, checking it locally, committing the +built blog and pushing it. Sometimes I do the commits together, but I always +separate the rendering/building commits from the content-creating ones, so that +I can handle those differently if needed (i.e. there is no point in +cherry-picking the built content, I can generate it). [5]

+

For other branches I use some applicable subset of the steps above, probably.

+
+
+

Design considerations

+

The appearance of the blog is maybe not nice. That is for two reasons: I don't +have the right idea about how to make it much better and I want to have a +rather simple CSS for the web. The latter wish is because I tend to tweak +appearance of sites I visit using my own styles, so I would like you to be able +to do the same.

+

And for the former reason, if you have any ideas / improvements (including user +styles), hit me at blog@pokemon.ledoian.cz :-)

+

My overall idea is a dark-by-default [6] minimalist page with a single menu on the +right containig all the relevant links. The page should not dictate too much +but rather let the user agent decide the rendering (it does anyway…).

+

I want my blog to render similarly in Gecko-, WebKit- and Blink-based browsers +(e.g. Firefox, Badwolf, Qutebrowser). Others should be usable. +Browser-/engine-specific styles are not welcome – let's keep it simple. And no +JavaScript…

+
+
+

Work in progress / TODOs

+

This thing is at the moment very barebones, which is sufficient for the main +purpose. However, I would like to have some features here, one day, hopefully:

+
    +
  • Dates in the article headers (and maybe more improvements of the theme, see +above)
    • +
  • Stable category and tag names and a page with a description of them. As of +now I haven't really invented a system of sorting my content, which leads to +a mess… Please don't rely on categories having any particular name / URL for +now.
    • +
  • Link the RSS feeds from somewhere
    • +
  • Personal info with links to my other profiles
    • +
  • Some linking to the Fediverse and using it for comments (since there will be +no comments here)
    • +
  • Sensible translations, maybe (if I/someone ever get to write the same content +again in a different language…)
    • +
  • Improve the list of talks I've given (create some kind of sensible table maybe?)
    • +
  • Decide on a licence for the content (If you want to utilize something here +before I do that, please ask me, I think we can find a way :-))
    • +
+

If you are so upset with this blog (or maybe bored) that you want to improve +it, send me patches / ideas. I don't expect anyone to do that, though :-D (And +I do not promise you that I will use the patch, even if it matches all my +opinions above. I also have some gut feelings about what I like…)

+

Also, tell me if you hate something else about my page. I want to at least know +whom I upset :-D (but I will probably also think about your gripes and whether +I can and should try to avoid them…)

+
+ + + + + +
[1]I also use multiple machines on which I can write stuff.
+ + + + + +
[2]

I am lazy and chaotic (good), so the stages are optional +and non-linear, and sometimes involve paper. This article is a prime +example: parts of it were on two different private branches, but at the end +I wrote it from scratch directly on the main branch. And the requirements +were written on a paper originally.

+

Nevertheless, the general idea still holds and may inspire others, so it +makes sense to keep this part in the article. (Also, this footnote might not +make sense before reading the definition of the stages, but I didn't find a +better place to put it…)

+
+ + + + + +
[3]Well, given this article contains some future plans, I +actually anticipate update of this one, but maybe not in the near future. So +the outline is not really correct, but I make the rules :-) (There +were some build breaks on the main branch, too :-D)
+ + + + + +
[4]I would love if my Forgejo could have "private +branches", but I understand that the overhead for doing this is not nice, +since it would need to be able to decide for any object, whether it is +public or not (you can do git fetch <remote> <object-hash>) and somehow +keep track even with rebases, merges, force-pushes, many branches, … Having +a separate private repository is not a big problem in comparison.
+ + + + + +
[5]Git purists might want to tell me that committing build +artifacts is not good practice. I know and I explicitly don't care in case +of this repo, because here I prioritise my own comfort of being able to +check everything locally and then be reasonably sure the deployed version +will also work, all this with only a single push somewhere. Of course, one +could argue that with that there is no reason to create two commits, but it +does not really bother me to run something like git commit -m"render" +output/ when I am sure it works, and this keeps readable diffs separate +from the non-readable ones (i.e. the changes in generated HTML).
+ + + + + +
[6]Having the page be dark-by-default is my preference, but I +respect that others may prefer light sites. However, I have not yet +determined what colors should be used (probably still cyan / blue / maybe +purple-ish, but I don't know what shade) nor understood how to use +@media(prefers-color-scheme) in a maintainable and simple way (in the +context of my theme). So naturally, this is postponed to the future…
+
+ +
+
+
+ + + + + diff --git a/output/archives.html b/output/archives.html index 9627c15..f56e692 100644 --- a/output/archives.html +++ b/output/archives.html @@ -28,10 +28,13 @@

Categories

Tags