Wiki engine with Markdown syntax and plain files as a backend

I love wiki applications. Not the Wikipedia, a famous encyclopedia website which runs on MediaWiki engine, but these kind of software at all. They are super useful as a content management system (CMS) to run your website, especially when it has a lot of interlinked articles and you want to bring some structure into it. This Google Blogger/Blogpost website is just a damn parody of normal CMS and it is very sketchy to use.

I wanted to make a big move from Blogpost to my own hosted wiki and was recently researching what options do I have. I had my own list of requirements for the prospective solution:

• the wiki engine should be open source, lightweight to be hosted on a potato (or free web hosting) and it should be using PHP or Perl or Python - this is what you can get easily on such hostings
  
  
• it should not require any SQL databases as a storage backend but to use plain files as a storage instead. For many reasons. I don't want to maintain it, make sure it's not running out of space, make proper backups and restore in case of failure. When the wiki storage backend is just files, you can backup them easily
  
  
• ideally it should have a built-in editor for pages. It might sound like a joke, but you'll see it later that not all of the engines do support that
  
  
• it should support Markdown syntax. Just because I got tired of dealing with WYSIWYG HTML editor of Blogpost, which is messing with HTML tags all the time. Custom wiki syntax for articles must die. 
  
  
• Last but not least. The project should be alive and not abandoned. Yes, if it meets all the above requirements, we can always take our MD files with us away from it, but if we're selecting a good candidate for us to use now, it should have at least his heart running well.

So let's do some comparison. 

MediaWiki 😕

It doesn't have an option to run on a top of flat files as a backend. 

TiddlyWiki and TiddlyMemo 😟

https://tiddlywiki.com/
https://tiddlymemo.org/

Not actually a wiki engine you can host somewhere on a webserver and have remote access from anywhere. It is a single HTML file with a lot of JS. With using JS controls you edit your own notes/pages with using web browser and then you click on "Save" button which generates you an updated HTML file you save (either as a version+1 of your wiki, or just override it). So it's more like a local wiki, which requires you to take it with yourself all the time. 

But if you ask me, it's very fragile approach to trust into aJS code to do it's job properly. If it screws and if you were not making proper backups yourself, your work will vanish in the thin air. 

MDwiki 😞

https://dynalon.github.io/mdwiki/#!index.md

I really love the idea: you just place a single html file somewhere on a webserver, where you store markdown documents (file.md) and then you access them like http://yourwebserver/index.html#!file.md
That html file has JS scripts in it to fetch and render the MD documents you reference.

Unfortunately the project is no longer being developed and it's very buggy.
I tried it multiple times and I cannot recommend it.

DokuWiki 👍

https://www.dokuwiki.org/

A good old mature wiki engine which supports everything I need.
Does support Markdown syntax with this plugin - https://www.dokuwiki.org/plugin:markdowku

Wiki.js

https://js.wiki/

Requires node.js. This is no for us.

Gollum

https://github.com/gollum/gollum

Requires Ruby. This is no for us.

Gitit

https://github.com/jgm/gitit

Requires Haskell. Again big no. 

PMWiki 😞

https://www.pmwiki.org/

A good candidate on a paper, worth trying. 

But what worries me is that the Markdown plugin - https://www.pmwiki.org/wiki/Cookbook/Markdown - was updated last time more than 16 years ago and ppl are saying it's no longer compatible with current versions of wiki.

There's another Markdown plugin - https://www.pmwiki.org/wiki/Cookbook/MarkdownMarkupExtension - which might do a better job, but it requires an eclosing of markdown syntax into additional tags like this:

(:markdown:)

 Test
 ====

(:markdownend:) 

So for now it's NO. 

FOSwiki 😐

https://foswiki.org/Home/WebHome

Written on Perl, which is more rare option to see among free web hosting providers.
Markdown is implemented by this plugin - https://foswiki.org/Extensions/MarkdownPlugin
It requires to add an additional littering macro on the page like:

Content can either be written within the topic area itself using:

%STARTMARKDOWN%

...

%STOPMARKDOWN%

or by using the %MARKDOWN makro:

%MARKDOWN{text="..."}%

or by reading a file attachment:

%MARKDOWN{topic="..." attachment="....md"}%

So this is no for me.

IKIWiki

https://ikiwiki.info/

Not actually a wiki engine but a perl compiler to produce a set of HTML pages out of your git or svn repo (and it acts as a svn client or git remote). Has a native support of Markdown. 

If you ask me, the idea is quite nice, but from the brief look on a project website it does't give a feel of something mature with a lot of community. Also it's not something you'll be able to use as a hosted web application. 

ODDMuse

https://oddmuse.org/

Requires perl. Very minimalistic - I tried to play with it online using their own website, and quite subjectively this is below the level of minimalism I can afford. I'll give you this example - if you edit a page and you want to see how it looks like, by pressing a "Preview" button, it doesn't show you the actual rendered result. So for me it's no. 

Peperminty Wiki 👍

https://peppermint.mooncarrot.space/

What's good about it is that it's being actively developed, uses PHP, based on plain text files and  supports Markdown out of the box. I have played with it quite a lot and even raised a couple of small issues about the bugs I found. 

The biggest issue right now is that if you modify MD files externally, you need to remove the internal index file so wiki will rebuild it. This implicitly means that you also loose whatever tags and dates your pages were having, as it is also stored in that index file - https://github.com/sbrl/Pepperminty-Wiki/issues/242

Aneuch ✋

https://www.aneuch.org/
https://github.com/ajgraves/aneuch

Requires perl. Somewhat similar idea to Pepperminty Wiki - a single perl file to rule-them-all. Looks very mature but the bad thing is it is no longer developed. Last commit was like 2 years ago.

Summing up

So, as far as you can see there're not so many candidates I can choose from.

Recently I have found a good website which does the comparison of many wiki engines - https://www.wikimatrix.org/

One might be interested to revisit this comparison at some later point.

Also worth reading a below article. It highlights some very worrying trends in modern software, which is having a bad tendency towards clouds and locking your data into proprietary cage - https://www.inkandswitch.com/local-first/

Window manager hopping - dwm, twm, bspwm

dwm. Dynamic Window Manager. Let's go hardcore!

dwm, together with a bunch of few other lightweight tools are developed by these guys - https://suckless.org/

To say the least I'm deeply impressed how tiny, comfortable and snappy this thing is. 

At first, I was little skeptical about tiling window managers, because we all used to floating ones. But hell, how good and fast they are! It really shifts your user experience from being constantly distracted by different things to be entirely focused on doing what you actually wanted to do. Such tiling window managers are unleashing the true power of keyboard. You can still use your mouse, but really it's order of magnitude faster to do everything by keyboard. An did I tell you it's tiny as grain of rice which means memory and CPU efficient? :)

In order to not get yourself lost at the beginning, make sure you'll install not only dwm, but also few additional packages (what we need the most is dmenu - it's part of suckless-tools):

apt install dwm sterm suckless-tools

Here are some useful shortcuts you'll need at the beginning:

Alt + Shift + Enter	Starts a new terminal window
Alt + P	Opens a dmenu (launcher). Whatever you'll run will be put to the top of a "master" (pile of windows on the left hand side). The existing window from "master" will be moved to "stack" (right hand side plie of windows)
Alt + i / d	Increases or decreases the number of windows in "master" (left hand side half of screen)
Alt + h / l	Resize the split between "master" and "stack" and
Alt + j / k	Changes current focus to the next / prev window
Alt + 1 .. 9	Changes current workspace to #1 .. #9 (they call it a tag)
Shift + Alt + 1 .. 9	Moves the current window to a workspace #1 .. #9

 

I strongly advise you to go visit the official tutorial to get that to understand what is the main idea behind dwm and why it's doing what it's doing - https://dwm.suckless.org/tutorial/

 

Things I did after installing dwm:

 

1) had to change background colors used by dolphin (gui file manager), because by default it was using plasma dark color with dark unreadable fonts.

2) added some additional lines to ~/.xsessionrc as the KDE version in Debian doesn't clear all its processes behind:

# if we're switching to dwm we don't need any KDE processess any longer
if [[ "$DESKTOP_SESSION" -eq "dwm" ]] ; then
  xrandr --output HDMI-1 --mode 1920x1080
  sudo killall kinit polkitd kdeconnectd kactivitymanagerd kded5 packagekitd kglobalaccel5 kdeinit5 klauncher
fi

3) the default st terminal is just awesome, when it comes to memory footprint. But it doesn't look very pretty and it's like inviting you to change it. I forked it and finally implemented the putty-like copy&paste behavior I was missing so much since I moved to Linux  - https://github.com/kha84/st/

 

 

 

(screenshots are made with scrot)

 

twm. Old as hell. But still useful

I used to use twm a lot in my earlier days with linux. Really. But now it looks so outdated and so hard to use. You can think of it as of some archeological museum exhibit item: you can admire it's still there and working, even play a bit with it, but to use it on a daily basis - nah, just skip that part altogether.

 

  

awesome

tbc

bspwm

tbc

Few notes on web browsers (they all are shit)

SOCKS5

If you ever have to use a SOCKS5 proxy for a selected sites (like to bypass territorial restrictions) you might want to configure it in a manner it will be used by all web browsers, whatever you wanna use. So if you're KDE user you're doing that in your KDE System Settings app, on a tab called "Proxy". If you're GNOME user, I bet there should be an appropriate app for it. And all the rest applications are supposed to fetch these settings from your desktop environment or if you want to configure them on an individual basis - they should let you do so. In theory.

But after a closer inspection on practice it turned out that:

• Chromium doesn't give a shit about KDE settings. Even more, it doesn't give a shit about SOCKS5 configuration in UI. The only how you can make it to use SOCKS5 is to provide a cli parameter upon startup. But here goes the trick, if you already have a running instance of Chromium that other new process with SOCKS5 in cli won't give a shit about it.
   
•  Firefox does have SOCKS5 configuration, but it does that in a shit way - you can only specify which sites you don't want to use proxy. There's no nice checkbox like in KDE System Settings like "Use proxy settings only for those sites listed in exceptions". I tried to use a .pac file with a simple function which would always return my proxy (just as a matter of testing), but it's not going to work if you provide Firefox a path to it like file:///home/xxxx/yourfile.pac probably because it just doesn't support that. And running a whole web server just to give that Firefox an only file looks idiotic to me.
  
  This can be slightly mitigated by installing this firefox extension - Container Proxy but it's also non ideal.
  
  
• Konqueror is pretending that it can work with SOCKS5, but it has a nasty bug which resets the SOCKS5 proxy hostname and port. In the more recent version I tested (22.4) they're saying it explicitly in the proxy configuration that these settings won't be taken into consideration by web browsers. Why to show that form first of all?
  
  
• Opera - forget about it, it doesn't exist on ARM64/AARCH64

 

So in this round winner is Firefox.

 

Memory consumption

I did a very basic test to see what is memory consumed by different browsers when you just open them up, load the same web site in a single tab, scroll to the end of that page (to force browser to actually load every picture) and results are below. 

 

Needless to mention that I repeated my tests number of times with closing browser and killing all of its possible remainings, to ensure results are more or less stable. Measurements were made by running htop in a tty, comparing "memory used" before the browser was started with what it was when (a) browser just loaded the page (b) I scrolled that page all the way down.

Firefox

When just started showing empty page ~ 270 Mb

Opened a page - 320 Mb

Scrolled the page all way down - 370 Mb

Chromium

When just started showing empty page ~ 260 Mb

Opened a page - 310 Mb

Scrolled the page all way down -  360 Mb

Konqueror

For Konqueror I had to disable the setting to keep a preloaded instance of it, because it wasn't exiting clearly and there was always one process remained.

When just started showing empty page - 170 Mb

Opened a page - 210 Mb

Scrolled the page all way down - 260 Mb

 

Clearly Konqueror is a winner here. But to me they're all loosers. How come we ended up in a world, where the shitty page takes that much RAM? It would have been easier to render the whole fucking page into some kind of JPEG or PNG and show it like this in any picture viewer program.