Intro

At the start of this year, I installed Linux Mint on my main laptop. I’ve used Mint Mate edition before on my secondary laptop a bit, so I wasn’t new by then. Since then, because of various issues I’ve distrohopped

Mint (lack of touchpad gestures + freezing thumbnails)
-> Ubuntu (Anti snap propaganda got to my head)
-> Fedora (Issue where 'output' speakers list grew infinitly and crashed GNOME + headphone jack issue)
-> opensuse tumbleweed (failing updates + bricked system + headphone jack issue)
-> Ubuntu

I’ve learned quite a lot from this journey, and now I’ve used being on ubuntu for about a month and I think I can confidently say that I will stay.

None of the distros I’ve used were bad, they just weren’t for me. The 2 most important features of any linux distros are frequncy of updates/stability and look and feel. All else is secondary. Fedora’s dnf might be better than ubuntu’s apt, but I like ubuntu’s take on GNOME more. Yes, I could make fedora like ubuntu, but the burden of maintaince would be on me.

The main problem with desktop linux

Sadly, there isn’t a single ‘main problem’, if there was it’d just be easy to fix it and enter the year of the linux desktop. Along with freedom, comes the freedom to mess up easily. What we strive for, is up to date packages and general system stability.

Every time you install a package using a traditional package manager(apt, dnf, pacman, etc…), then basiclly you run an install script the package provides, where they can pretty much do anything(yes, you could theoretically make a package that runs DOOM during installation). So basiclly you mutate your root directories to install a package. This is an extremely chaotic approach, and often the root cause for instability.

All we want is for distros to focus on the feel of the desktop, be unbreakable. This is incompatible with traditional package managers¹.

The solution to this is actually quite simple, make every directory other than /home immutable. That way, you can rollback all upgrades, maintance is super easy as the devs know everyones file system is synced, and the system is more stable, as updates are applied as full images instead of constantly mutating the system.

Immutable linux distros: Problems

Ok, so we now have immutable distros where only the /home directory is under the user’s control. There’s a very obvious problem with this: You can’t install packages, as they mutate the system. There are 2 solutions that most distros use: 1. Use flatpaks for gui apps. 2. For other packages, ‘layer’ them (tools like rpm-ostree do this). So say you ‘layer’ emacs on your immutable system, your system becomes base + mutation(emacs). So whenever you update, your base syncs to the official base image, then is mutated with emacs. This can get really slow really fast once you have base + mutation(a) + mutation(b) + mutation(c), where for every update base will be synced, then mutations a, b, and c will be applied.

Considering that now to install any cli program, any daemon, or anything that can’t come as a flatpak(you can use flatpaks to install cli programs, but it’s painful and it’s not what flatpak is designed for, you’ll have to do flatpak run org.gnu.ls if you wanted to run a fictional flatpak version of ls) you’ll need to take the latter approach for most things, now I bet immutable distros don’t seem so attractive anymore. Luckily, there’s a simple solution.

Snaps

BUT.. BUT… SNAPS BAD, SNAPS SLOW, NOT OPEN SOURCE, BAD DEPENDENCY MANAGEMENT , EVIL.

Let’s address this: Snaps are not slow anymore, they used to be, but that’s simply not a problem anymore. Snaps are open source, the only thing that isn’t is cannonical’s backend code for the snap ². Contrary to popular belief, snap do use shared dependencies, just not the traditional way. Most libraries are included in each snap, but snaps can reuse parts of other snaps.

Now, lets talk about why snaps are good: - They are sandboxed, like flatpaks - They are immutable - ANY .deb or rpm package can be a snap. Even the linux kernal can be a snap(see ubuntu core).

The future

So why did I bring up snaps? Well, it’s obvious now, that they can replace the flatpak + layering combo for immutable distros. So you’ll be able to install everything(cli tools, gui stuff, daemons, etc…) with snaps and enjoy the unbreakable stability of an immutable distro at the same time. No more worrying about updates breaking things, or tiny user specific bugs.

Although a immutable snap based version of ubuntu dosn’t exist yet, it’s likley cannonical is going to come out with one, and when it does, I’m switching.

Intro

This is my first post in 6 month or so, and the reason is mostly because I wasn’t satisfied with my past blogging setup. Now, I switched the website up completely, and it’s much better right now¹.

Futre

I’ll be doing at the very minimum one article per month. I already have the next 2 debunk ideas ready. I’m going to do an anarcho-primitivism debunk, and then a debunk of common crypto critisim debunks.

As for the direction of this blog, I’ll be activily trying not to make this ‘just another tech blog’ that posts about stuff already written about by 10+ people, so although I will still write tech articles, they will be far from exclusive in this blog.

UPDATE!!!

November 2025: Pretty much everything in this post is invalid as I use a completely different system now.

Intro

Right after spending about 2 weeks in making genorg, my supreme and functioning (most of the time) static site generator¹, here are the hows and whys.

Criteria

My criteria compared to your career just isn't fair

• The markup document type for the a blog article should be Org, or something as powerful(void).
• The org to html function should be complete and work well. Currently (and eternally), this is only done by the emacs org exporter itself.
• Categories
• Moving files around in the 'articles' directory should still produce the same output blog. This means that the category info would need to be in the article file itself.
• A powerful and flexible templating system. This would be used for example to export to the blog page.
• Rss feeds.

Comparasion of other static site generators

Before I decided to make my own thing, I tried to find other static site generator that would meet this criteria. At the end, I was left with 2 valid options.

Hugo/jekyll

The compromise here would be using the shabby hugo org export, or use Hugo. However, this could pretty much be fixed by using ox-hugo. Now I look back at it, this would probably have been the better choice. oh well, I'm happy with I have now. I reccomend this to to all readers who have a similar criteria.

Plus, using Hugo would remind me too much of the film with the same name which I vaguely remember watching, hence forcing me to rewatch and waste 2 hours.

Org publish

I couldn't move files, plus I would have to hand maintain the category pages. No thanks, I got better things to do (gulp).

The solution

Writing about programming instead of just programming kinda sucks, bear with me.

genorg

genorg is a perl script which generates the sites from a input directory and a TOML configuration file. It scours and converts a bunch of org files in the directory, and converts them to html (if needed). Each of these files contain a id for internal use, and a category.

  Input                  Cache                Output
+-----------+       +---------------+       +-----------+
| Org files | ----> | direct org    | ----> | Modified  |
|           | ----> | html export   | ----> | html      |
+-----------+       +---------------+       +-----------+
                       |        |
                    +---------------+       +-----------+
                    | Neccasary info| ----> | navigtion |
                    | eg title, date| ----> | files     |
                    +---------------+       +-----------+

Of course, any good static site generator needs a good templating system. So since genorg used perl, I had a obvious choice ahead: Template::Toolkit. Since it used C code with perl bindings, it was extremly fast. But still very powerful since it has been around for a while.

A example info file generated by genorg to communicate with genserve:

{
  "landing": "templates/index.html.tt",
  "blog_dir": "/blog/",
  "rss_dir": "/rss/:cat",
  "main_rss": "templates/main.xml",
  "blog_file": "templates/blog.html.tt",
  "cpath": [
    {
      "file": "templates/1.html",
      "rss": "templates/1.html.xml",
      "cat": "tech"
    }
  ],
  "files": [
    {
      "cat": "tech",
      "art": "introblog",
      "file": "2025/intro.org.html"
    },
    {
      "cat": "tech",
      "file": "2025/window.org.html",
      "art": "new_window_cmds"
    }
  ],
  "main_rss_url": "/rss"
}

The navigation files are considered stuff like the category pages. To keep the urls the same even when a org file is moved, the site needs to dynamically resolve links into respsecite file paths. example.com/category/article-id needs to find the file and serve it.

Why perl?

Lisp has all the visual appeal of oatmeal with fingernail clippings mixed in.

Larry Wall, as always, puts it very well. The other reasons are because of TIMTOWDI, and typed containers (in combination with a weakly typed language.).

genserve

So now to serve the dynamicly serve the genorg output, all we have to do is parse the json file and redirect files accordingly. Easy enough… right?

Well, it would be if I was satisfied with http requests taking 0.0001 seconds to be proccesed by genorg instead of 0.00001 seconds.

So I initally decided to make the http server part in Go. This did not go well, I didn't like the language, I didn't like the http server the standard library provided. So in about one day, I wrote 300+ lines of zig code to make it work.

Although the process was tedious, the result was worth it, as any visitors get to save approximately 10 × 10⁻5 seconds for every visit.

Code

My beautiful code can be found here. As for the http server code, I won't share that. Simply cause it's crappy code and it's going to be easy to find exploits in it. If you do decide to use genorg, I suggest using a fastcgi script to serve content based of the parsed json.

What now?

I'm very happy with the software used to generate the blog and articles, but I still want to add some HTML and CSS and images in the home page and category pages to make the site more vibrant (I've recived feedback that this site reminds a viewer of a 'bee'). Maybe later, I'll write about the non-technical aspect of blogs and why I wanted to have one.

Footnotes

Intro

Around September 2024, I also discovered this useful package for emacs windows management transpose-frame.el.

Around this time, I read Tobias' article on doing things that scale¹.

So of course, as a changed man, I sent a simple email asking for tranpose-frame.el to be moved to emacs core. But as it turned out, the package had many things wrong at it's core which would be impossible to fix without a rewrite.

Basiclly, transpose-frame.el relies on "copy pasting" window states(like the buffer, overlays, etc…), which was a faulty approach². The correct approach required new code in emacs C-land to be able to 'necromance' window objects when using the function split-window. For this reason, simply changing up the code in transpose-frame.el would not be sufficant. A full rewrite was required.

So, not knowing how much work was in, I agreed to do it. So after about 4 months of infrequent, painful work³, including constant collaboration with Martin Rudalics, the windows.c and windows.el maintainer who take care of all the code in the C-land size. Now, emacs 31 has all the functionality that transpose-frame.el had, plus extra. The file containg all these comands is window-x.el, which can be found here: https://github.com/emacs-mirror/emacs/blob/master/lisp/window-x.el.

Commands

Now, I used a simple layout for the following images simply cause I was too lazy to make more complex ones. Keep in mind, that these commands can work for any complex window layout you can cook up.

I would suggest trying them and playing around with them, but if you don't have emacs 31, this is a preview.

Transpose

M-x transpose-window-layout

This one is basiclly diagonal reflection.

Rotate layout

M-x rotate-window-layout-clockwise

M-x rotate-window-layout-anticlockwise

Flip

M-x flip-window-layout-horizontally

M-x flip-window-layout-vertically

Cycle (rotate windows)

This one is my personal favourite.

M-x rotate-windows

M-x rotate-windows-back

Footnotes