Rakhim Davletkaliyev writes short essays on software quality, blogging, text design, and the tech industry's treatment of users.
HN links his posts as shorthand for points about people liking the idea of blogging more than doing it, and for similar essays.
Obligatory meme:
https://rakhim.org/honestly-undefined/19/
I'm personally in the top left corner and bottom right corner at the same time, which is sort of funny.
I have used WordPress since 2004-2005, and I've also written a Python static site generator before using Flask + Frozen-Flask[1]. I've also made stops through tools like Sphinx, Hugo, Gatsby, and VitePress[2]. But my personal site continues to run WordPress[3].
I think I'd prefer something like VitePress these days for a technical documentation site. It has a lot going for it for that use case. And it feels built to last.
On true wikis that one can self-host, I recently learned that MediaWiki with a reasonable theme like Citizen[4] is a nice choice for an open source powered private wiki. Although I do find the Mediawiki markup language a little cumbersome versus simpler markup languages like reST or Markdown/MyST in the Python community (or GitHub-Flavored Markdown or Asciidoc supported elsewhere). But Mediawiki has a lot of nice features -- after all, Mediawiki powers Wikipedia. The theme makes it work properly on mobile, adds a little more structure for automatic ToC, and makes content editing a bit simpler.
It still isn't nearly as polished as commercial wiki-like software (e.g. Notion) but it's better than open source wikis used to be.
On the subject of the blog post, I think bit-rot or info-rot is the natural order of things. The kind of software you run isn't going to change those facts. And if you're…
> When a Python thread is holding on to the GIL (running Python bytecode), how many other Python threads can concurrently
You've been tricked by jargon. It's a common misconception. In this context, "concurrency" has a specific meaning that is different from the everyday one you're using in this sentence.
For a good introduction to what the two words mean in a software engineering context, check out this written version of Rob Pike's talk, "Concurrency is not Parallelism."
https://rakhim.org/summary-of-concurrency-is-not-parallellism-a-talk-by-rob-pike/
The very tl;dr summary is:
> Concurrency is composition of independently executing things. . . Parallelism is simultaneous execution of multiple things.
When Python's threading model was implemented, parallelism just wasn't much of a concern. CPUs had a single core and could therefore only be working on one thing at a time. (In a macro sense; pipelining and supersclar architectures were still a thing, but not super relevant here.) Multithreading was not a way to do multiple things at once, it was just a way to ensure that some long-running calculation would not cause the program to lock up by, e.g., preventing it form responding to event queues in a timely manner. This was done by, not by running things in parallel, but by switching back and forth among them them very quickly.
Python's GIL was designed for this kind of situation. It's there to ensure that nothing bad happens if one of those context switches happens in…
I agree it could have been phrased more nicely, but it actually pointed out something valid, which I didn't catch at first. The author hasn't written any posts in 5 years, and has ~15 total since 2010:
https://blog.steren.fr/
As someone who blogs regularly, I'm more interested in the toolchain of people who HAVE done significant writing. I read blogs for at least a decade before I wrote one, and it's harder than it seems, and coercing a good result out of tools isn't easy.
In fact I just wrote a few of my own tools to fix the image problem, e.g. http://www.oilshell.org/blog/2021/01/blog-roadmap.html#unix-y-web-services-i-wrote
Basically, the author's strategy is not likely to last (though it's not impossible). My blog started out very minimal, but as you write, you bump into the need for more automation and tools. My site looks very simple and minimal, but there is a surprising amount underneath.
Funny comic: https://rakhim.org/honestly-undefined/19/
When I was writing those tools I often wondered if we should just go back to Spolsky's CityDesk. It was a Windows GUI that would FTP HTML and images to a static server! I remember trying it briefly in the early 2000's. Although his blog also rotted due to CityDesk rotting! It's a hard problem.
https://www.joelonsoftware.com/2016/12/09/rip-citydesk/
You could use Substack/Blogspot/Mastodon themselves as your "static site generator".
POSSE (the concept linked here) is overrepresented in relation to revealed preference. PESOS (publish elsewhere, syndicate on site) is more compatible with how most people (including nerds) actually use the Internet; for all the talk about static site generators and "owning" your own "digital garden" >9/10 people would fall somewhere on the embarrassing part of the curve from the "Blogging vs. Blog Setups" comic. <https://rakhim.org/honestly-undefined/19/>
If you migrated to a fediverse instance with longer post length limits, you could use that to actually blog/post while mobile, and meanwhile you have a script on your homepage that "lazily" syncs those posts to your static site—
When anyone visits your homepage, they see your site as it was when you last built it.
When you visit your own homepage, it automatically fetches your social media feed, patches the previous input to the SSG with the new content, and then uses the APIs of whatever you're using to host your site for rolling out the new posts.
I'd still disagree. Want to share an image? Put it in ~/www/. Want to share a video? Put it in ~/www. Want to share some music? Put the .mp3 in ~/www. This core idea, that you can share files simply by using a file system, makes many of these extremely complex tools that require containerization due to their rapidly changing deps... overkill. An impediment to the actual goal of just showing people things. There's almost nothing simpler than using your mouse to drag a file into a folder or $ cp etc etc.
This entire thread reminds me of the inverse relationship between actually blogging and messing around with blogging setups, https://rakhim.org/honestly-undefined/19/
As for hosting your own Matrix homeserver, sure, that's such a heavy and over-complex protocol that changes rapidly and uses libs that change even faster. You'd want to containizer that.... and probably give it it's own computer instead of your desktop or an SBC since it's going to take a lot of system resources. Or even better, don't use protocols that are so unstable you can't run them natively.
My argument is that Josh has a lot of readers because it's clear that he puts a lot of time and effort into writing a great blog, and the code plays an important part. Obviously code isn't crucial to writing any successful blog (although in Josh's case it is) but my guess is that most of the people who see their hacked-up-and-spit-out homegrown blogging system as a positive put a similar amount of effort into that content. (See also "static gen basin": https://rakhim.org/honestly-undefined/19/)
Anyway, you seem to have an axe to grind here, so I'm ducking out. Have a nice day!