Christos Margiolis: engineering

In defense of the Old Web

Wed, 17 Aug 2022 00:00:00 +1200

The internet has reached the point where almost everything has been concertrated in just a few platforms. This is both opposed to the original idea of a decentralized and free internet, and is also used as a tool for control, since the flow of information is “managed” only by a handful of companies.

My rather romanticized proposal is that we should make an attempt return to the old ways of the internet (1990s-2000s) — when personal websites and small communities were thriving — not because of nostalgia, but because it espoused better values and promoted creativity, despite its problems (spam, malware, bad security practices, unencrypted traffic). This might very well be a pipe dream at this point, but I think it would be great to at least see the existing movement attracting more people than it already does.

I was initially working on a full article explaining my viewpoint in depth, but the following articles express them better than I could ever have:

So, how can you be part of the small web? To start off, you need:

A domain name.
Somewhere to host your website/service. I rent a Vultr VPS with the cheapest plan available, which is more than enough for my needs, but you can even do self-hosting at home if you want. If you do rent from Vultr, you can follow this guide.
To connect the domain name with the server, so that your website can be reached.
A stable and secure operating system for servers, such as OpenBSD.

A list of guides I’ve written:

To make finding other websites easier, have a links page, and consider being part of a webring.

The tools you choose to manage your website depend on personal preference and needs, but I firmly believe that because building a website is not rocket science, and because the web has been getting severely bloated you don’t need anything more than a few command line utilities, a text editor, and perhaps a static site generator. Modern web frameworks tend to cause more headaches than actually improve workflow, so I’ll refrain from recommending them. I like writing articles in Markdown, and using Hugo for static site generation and templating.

RSS: Advantages and usage

Fri, 27 May 2022 00:00:00 +1200

RSS (Really Simple Syndication) is a standardized protocol for creating and sharing web feeds. An RSS feed is an XML file consisting of entries, each of them usually corresponding to an article. Programs called “RSS aggregators”, parse these files and provide a nice display where you can nagivate through each entry as if it were a news feed. This is a very convenient way to “follow” websites because all you have to do is grab their RSS URL, add it to your aggregator, and read the articles once it parses the feed.

On the website owner’s end, a new entry needs to be added whenever a new article is published. The entry usually includes a short summary of the article, or as is the case for my website, the whole article, so that you can read it all through your RSS reader.

Why bother

RSS is an open protocol, it’s decentralized, and very simple both in terms of parsing and maintaining. Because RSS is such a simple protocol, it can adapt to everyone’s workflow. There are RSS readers for Android, Windows, UNIX, web browsers, email clients, etc.

Apart from the technical advantages RSS provides, it’s also a great way to have a personal, uncensored feed, following only the websites you want — even YouTube channels and Twitter accounts — without ads and additional noise and distractions.

I personally use sfeed as an RSS reader, because I like the extensibility it offers. I’ve written a small patch for sfeed_curses(1), so that you can bookmark feed entry URLs to a predefined file. I use this mostly to queue videos and podcasts and then stream them through mpv using a very simple script I created, which, all it does is read the “queue” file and pipe the URLs to mpv.

How to create and maintain an RSS feed

Below is a very basic RSS feed. Inside the <channel> tags is the whole feed, and inside <item> is each individual entry. The rest of the tags are pretty self-explanatory, if not, feel free to read the specification. The article/summary is placed inside <description> — that can be in plain text or encoded HTML:

<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">
<channel>

<title>Example Org</title>
<description>Example Org's RSS feed</description>
<link>http://www.example.org/rss.xml</link>

<item>
<title>Example entry</title>
<link>http://www.example.org/blog/post.html</link>
<pubDate>Sun, 06 Sep 2009 16:20:00 +0000</pubDate>
<description>
Here is some text containing an interesting description.
</description>
</item>

</channel>
</rss>

To create a new entry, you can either handwrite it in the XML file yourself, make a script or small program to do it automatically, or use some existing tool. I prefer to use my own script, since it’s a dead simple thing to do.

To share the feed, simply add the URL to your website and tell people to subscribe to it. For example, my website’s RSS feed can be obtained from https://margiolis.net/w/rss.xml.

Even though they purposefully make it hard to find, so that you can stay on their platform, YouTube, Twitter, Reddit, and other services, offer RSS feeds, and even if they don’t, there are ways you can generate one.

YouTube

Go to the channel’s home page, right-click and click on “Page source” and search for channelId" content. Copy the hash inside content="" and append it to the following URL (replace hash):

https://www.youtube.com/feeds/videos.xml?channel_id=hash

GitHub

You can get an RSS feed for each new commit that happens in a given branch. Replace username, repo and branch with the correct values:

https://github.com/username/repo/commits/branch.atom

Twitter

Twitter does not actually offer RSS feeds anymore, but there is a proxy site for Twitter called nitter that does. Replace username with the account’s username you want to follow:

https://nitter.net/username/rss

Each subreddit has an RSS feed under this URL (replace subreddit):

https://www.reddit.com/r/subreddit.rss

Facebook and others

There’s a nice program called RSS-Bridge that can generate RSS feeds for websites which don’t have one. RSS-Bridge is installed and run on your server, but there are public instances you can use.

Why reinvent the wheel

Fri, 25 Mar 2022 00:00:00 +1200

I’ve got a few reasons for “reinventing the wheel”, some personal and some practical:

I’m curious and want to know how things really work.
I like DIY from scratch projects.
Bottom-up learning is valuable.
There are things that are fundamentally flawed and need to be done again from scratch.
Existing tools don’t always match the criteria for your specific task and/or introduce too much complexity.
Because there’s already a way to do something, it doesn’t mean it’s the right way to do it.

Some of the greatest innovations have in fact been a reinvention of the wheel, because what already existed at the time wasn’t good enough. Imagine someone telling James Watt he shouldn’t waste his time reinventing the wheel. Improving what already exists means we have stable foundations and better tools to work with in the future. The wheel itself has been reinvented multiple times, hence we don’t use Bronze Age wheels anymore.

A good example in the software world of why sometimes reinventing the wheel is a good idea is UNIX vs Windows. UNIX was written from scratch to replace Multics which had serious flaws, so they ended up with a new and clean system, built right from the bottom-up. They reinvented the wheel and made huge innovations in the process. Windows on the other hand, is built on top of MS-DOS which even at the time was a mess, so what Microsoft is left with is an OS which up to this day is overly complicated, because of fundamental design flaws that cannot be fixed unless they do away with the whole thing and start from scratch. Instead, they are coming up with half-assed solutions and add complexity to the system with each update.

Then there’s quality and efficiency. Writing your own tools means they can be tailored to perform a specific task perfectly — something a big generalized framework or piece of software can’t do in many cases. We tend to ignore the improvements better software can bring in the long term and instead spend time fighting with not-so-great tools and also rely on the power of modern hardware to cope for our mediocre solutions (see modern web tools or the web in general).

So, am I proposing that we’d be better off writing machine code and building our own programs for everything? Absolutely not. What I AM saying though, is that instead of being allergic to reinventing the wheel, we can start to see the merits in it, without overdoing it. This approach is benefecial to our personal improvement as engineers, which means an improvement in software as a whole. Just as you learn any other skill by mastering and understanding the basics, programming has to be understood from the bottom-up, not the opposite way. There’s no point in knowing all kinds of fancy frameworks if all you see are black boxes, or cannot even implement a linked list if asked to. After all, it’s a fact that software is getting worse.

And to save myself from sounding ignorant, there are cases where reinventing the wheel is a problem, namely:

Companies rolling their own proprietary solutions for everything, and ending up creating protocols and programs, which are arguably worse, expensive, harder to maintain, and incompatible with existing software.
People who like to reinvent the wheel for the sake of just having “their own” version of something, even when there actually is good software out there that covers their needs just as well.

Knowing how things really work will enable you to trace bugs easier, write/design more performant software, and overall know what the hell you’re doing. And that can only be achieved by, sometimes, reinventing the wheel. Nothing can teach you what getting your hands dirty will.

A related article I found funny.

Email-driven Git workflow

Sun, 16 Jan 2022 00:00:00 +1200

Basic Git configuration (in case you haven’t already done that):

$ git config --global user.email you@example.org
$ git config --global user.name "Your Name"

Git email configuration:

$ git config --global sendemail.smtpserver your_mail_server
$ git config --global sendemail.smtpuser you@example.org
$ git config --global sendemail.smtpserverport your_smtp_port
$ git config --global sendemail.smtpencryption your_encryption_type

Examples

Apply a patch (or simply make a commit) and send it to a mailing list:

$ git am < some_patch
$ git send-email --to=list@example.org HEAD^

Fix last commit and send it:

$ git commit -a --amend
$ git send-email --annotate -v2 HEAD^

Send 3 last commits (see Revision Selection for more info on the notation):

$ git send-email HEAD~3

Send the last commit to list@example.org and make the subject look like “[reponame][PATCH] commitmsg”. This is useful for sending patches to mailing lists or programmers with multiple projects:

$ git send-email --subject-prefix="${PWD##*/}][PATCH" \
	--to=list@example.org -1

git-send-email(1) manual page. Simple as that. None of that fork & pull request crap.