Oscar's Blog2021-05-20T19:19:00Ztag:oscarbenedito.com,2020-04-13:/blog/Oscar BeneditoFollow TV shows with web feedstag:oscarbenedito.com,2021-05-20:/blog/2021/05/tv-shows-web-feeds/Oscar Benedito2021-05-20T19:19:00Z2021-05-20T19:19:00Z<p>
I am quite strict about which messages make it to a push notification on my phone. I don't like to
receive notifications unless they are important or urgent. The same thing happens with emails—indeed,
it's one of the few applications which have notifications enabled. However, I also don't want to
regularly check different places for updates. Because of this, most of the updates I receive are
through another channel: web feeds.</p>
<!-- /p -->
<p>
<a href="/blog/2020/04/use-web-feeds/">I have written before</a> about using web feeds (Atom, RSS,
JSON feed...) to keep track of updates to sites. I use my feed reader to get updates about some of
the software I use, YouTube videos, newsletters, and, of course, blogs. They are all things I
don't want to miss out on, but I don't want to be notified about. Instead, Miniflux (my feed
reader) stores them until I decide to log in and read them. This allows me to disable any
notifications but have them all centralized in one place.</p>
<!-- /p -->
<p>
Lately, many TV shows are starting to air again, meaning that there are new episodes weekly of
some series that I am watching, and soon more will follow. Because of this, I want to keep up to
date with which TV series are coming up, but I don't want push notifications or emails (or
checking their websites). I just want a way to know that there are new episodes for me to watch,
but without the hassle of looking it up... Ring a bell? Web feeds!</p>
<!-- /p -->
<p>
Yesterday I quickly looked around to see if there was any service offering that for free or
cheaply, and there was none. The ones I saw were about 5€/month, which is more than any other
service I use (a small VPS, email provider or Miniflux). I was not willing to pay that much, and I
was motivated enough to do such a service myself, it sounded like a fun and easy project to take
on for a day or two, so I did.</p>
<!-- /p -->
<p>
Luckily, <a href="https://www.tvmaze.com">TVmaze</a> offers a free API with all the information I
needed, and there I went with a Python script. After some time, I had it running, and today I
polished it a bit. I can say it is fully working now!</p>
<!-- /p -->
<p>
The script takes TV series IDs (as many as you want) and creates an Atom feed with an entry for
each episode there is. Just run it as a cron job every hour and put the output on a static site,
you're done! Alternatively, you can make one feed per show, so multiple people can subscribe to
their desired shows.</p>
<!-- /p -->
<p>
If you are interested, there is a bit more information about how it works <a href="/projects/tv2feed/">here</a>
and the code is <a href="https://git.oscarbenedito.com/osf/file/tv2feed.py.html">here</a>.</p>
<!-- /p -->
New home servertag:oscarbenedito.com,2021-03-03:/blog/2021/03/new-home-server/Oscar Benedito2021-03-03T18:39:00Z2021-03-03T18:39:00Z<p>
During this past year, I have been coming up with a variety of services that I want to host from
home. The problem was that I didn't have a computer to host them on, so I decided to buy one
before my Christmas vacation, when I would have time to tinker with it. Because of the gifting
tradition, I was asked if there was anything that I wanted, so I ended up getting it for Christmas
instead. In case you are curious, the computer is a Raspberry Pi 4 Model B, I decided to go with a
Raspberry Pi because it's the only device I have experience with and it has worked great, on top
of having good specs at a good price. I already have a server running round-the-clock (the one
hosting this website), so why did I need another machine running nonstop? For two reasons: control
and proximity.</p>
<!-- /p -->
<p>
When I talk about "my server", I mean a virtual private server (VPS) that I rent. "My server" can
be more accurately described as a virtual machine that lives in someone else's computer and that I
can administer for a certain fee. This is great for many reasons which can be summarized in "I
don't have to deal with any infrastructure-related matter": the server's owner takes care of
maintenance, broken parts, refrigeration, etc. On top of that, the server has a very fast internet
connection and a static IP. So it's a machine that has all the needed features to start serving
content to the internet. However, because this is someone else's computer, they have complete
access to it. My guess is nobody is accessing my data—it probably takes some effort to automate
scraping virtual machines, and I think I'm not interesting enough to be a target—, but that is not
a reassuring argument, so I don't trust my VPS with my private data. With a computer at home, I
have full control of everything that is happening, and I am more comfortable saving personal data
there.</p>
<!-- /p -->
<p>
That was related to control, let's look at proximity. The VPS is hosted somewhere far away (I
believe in Germany), so the only feasible way to connect to it is through an internet connection.
This comes with limitations—you need internet, and internet connections are slower than local
ones. Moreover, I want to be able to unplug external hard drives and plug them into my computer to
have instant access to any data (for example to make a copy to give to someone), as well as the
other way around: I want to be able to grab a USB drive, connect it to my local server and have
all the data available from all the devices in the network. For obvious reasons, I can't do that
with my VPS. Finally, because my home server is not exposing any service to the internet, it is
much harder to hack it or for some data to get leaked.</p>
<!-- /p -->
<p>
More arguments come to mind of why some things are better hosted at home, but I think by now the
general feeling has gotten across, so let's jump into what I've done so far and what are some
ideas I have for the future.</p>
<!-- /p -->
<p>What I currently have:</p>
<ul>
<li>
<strong>Media center</strong>: Well, something like it... I originally thought about
self-hosting Jellyfin or Plex, but the first time I wanted to use the media center I didn't have
much time to set it up, so I made a <em>very</em> minimal Apache site with an HTML file linking
to multiple videos and podcasts I had downloaded. Surprisingly, this setup has been working
great so far. I have created a script that autogenerates the page from a JSON with all the
metadata of the files I have and I have added some features (like marking media as "seen"). Now,
all I need to access the files is a web browser and, in some cases, <a href="https://mpv.io">mpv</a>
or <a href="https://www.videolan.org">VLC</a> if the format is not supported on the browser (did
you know you can stream videos with them?)</li>
<!-- /li -->
<li>
<strong>Git backup</strong>: It backs up all my Git repositories from different providers. It
does so with a <a href="https://git.oscarbenedito.com/git-backup/">Python script</a> I made some
time ago that given some authentication tokens, will mirror all my repositories (and any others
that I tell it to).</li>
<!-- /li -->
<li>
<strong>Syncthing</strong>: It runs Syncthing as another peer for all my folders. This way, all
my devices are always synchronized with the Raspberry Pi. Previously, two of them had to be on
and connected to have any synchronization. This also acts as a quick transparent backup for my
data, since the RPi is backed up daily.</li>
<!-- /li -->
</ul>
<p>My plans for the future are the following:</p>
<ul>
<li>
<strong>Expanding the media center</strong>: Add more functionality to the scripts generating
the webpage, add functionality to the website to be able to do some basic operations without the
need to SSH into the Raspberry Pi, and add more types of content.</li>
<!-- /li -->
<li>
<strong>Backup center</strong>: I'm not sure if "backup center" means anything (or if I'm using
it correctly), but as my backup center, the Raspberry Pi would be in charge of backing up all my
devices. Syncthing already helps with my phone and some other small folders, but I'd like to
improve my backup system so that a lot more data can be automatically backed up. I think with my
home server it will be much easier to regularly pull data from the services I use as well as
have a centralized location to which send my files.</li>
<!-- /li -->
<li>
<strong>Calendar and contacts synchronization</strong>: Right now, I use my email provider to
synchronize my contacts, calendar and reminders using the CardDAV and CalDAV protocols. I would
like to stop sending that information online and just have it synchronize with my home server
(ideally with the same protocols).</li>
<!-- /li -->
<li>
<strong>Photo and video library</strong>: I want to centralize all the photos and videos I have
(and the rest of the family's as well) and have a good interface to access them. This will
include sorting them out and will probably take a lot of time, so I'm not sure if I'll end up
doing it.</li>
<!-- /li -->
</ul>
<p>
... and anything else that comes to mind! I enjoy playing around with new software and I have been
enjoying every step of the move towards a more self-hosting setup, so I am sure that more things
will come up!</p>
<!-- /p -->
Gemini's different approach to linkstag:oscarbenedito.com,2020-12-20:/blog/2020/12/gemini-links/Oscar Benedito2020-12-20T20:01:00Z2020-12-20T20:01:00Z<p>
I have lately been reading many pages on <a href="https://gemini.circumlunar.space">Gemini</a>.
There has been a lot of interest around it on the blogs/microblogs I follow, which has lead to me
check it out as well. The project is very interesting, and if you have ever been interested in how
much bandwidth the current web wastes, the lack of privacy there is when we navigate it, the
constant security issues that come up with browsers, etc., I recommend you to take a look at the
project and read the FAQs. This post, however, is not about the Gemini protocol, but about how the
<code>text/gemini</code> media type handles links in comparison to HTML.</p>
<!-- /p -->
<p>
<code>text/gemini</code> is a very lightweight markup format. It only allows text, headers,
sub-headers, sub-sub-headers, preformatted text, unordered lists, quotes, and links. As you can
see, it has a (small) subset of the functionality of other hypertext formats such as HTML,
Markdown or org-mode. On top of that, links have to be on their own line, and you can optionally
give them a title. If I wanted to link to the Gemini homepage as I did in the last paragraph using
<code>text/gemini</code>, it would have to be in its own line:</p>
<!-- /p -->
<ul>
<li><a href="https://gemini.circumlunar.space">Project Gemini</a></li>
</ul>
<p>
That sounds very inconvenient, right? Why not just put the link inside the paragraph like in HTML?
I have found this way of linking a lot more pleasant when reading articles, and that's the reason
for this post.</p>
<!-- /p -->
<p>
When links are in the middle of text, sometimes you click on them while reading—maybe even before
you've finished reading the sentence! Even if you don't, they are distracting, you will probably
have to make a mental note: read the link once done with the paragraph, or you'll have to think:
is this link worth it? To decide whether to do the mental note in the first place. If you don't do
this, then you probably rescan the whole paragraph for links you have ignored (or just ignore
links altogether). By having the links at the end of the paragraph, you won't get distracted in
the middle of your reading, and you won't have to rescan for ignored links.</p>
<!-- /p -->
<p>
Aside from that, HTML links don't take up any space, they merely decorate a word that was already
there, while in <code>text/gemini</code> they take up a line of text, which means authors will
probably think twice before linking to 5 different websites that don't provide any useful
knowledge to the reader. But even if that doesn't stop them, now links have titles, which means
the visitor knows what the link is about before clicking it. That is a nice feature because it
makes it easy to ignore anything you are not interested in. If the author doesn't specify the
title, the URL will be shown in its place, and that already gives a lot of information. I know
that in most browsers, you can hover over a link to see the URL, but you have to reach for the
mouse to do it (and it is even harder to see the URL when on a phone or tablet).</p>
<!-- /p -->
<p><em>But the words with HTML links already tell what the link is about!</em></p>
<p>
Not always. For example, let's look at the start of the post, where the word Gemini links
somewhere. Three options of possible links come to mind: I'm linking to the homepage of the
project, the Wikipedia page (or some other wiki), or a previous post where I talk about how I've
been using Gemini lately. Two types of readers also come to mind: someone that doesn't know what
Gemini is (interested to click if it's one of the first two options) or someone that knows about
Gemini, but is curious about others' experience with it (interested only in the last link). So
it's not only about whether the link is useful or not but also about the particular visitor.
However, if at the end of the paragraph there was a line with one of the following texts, it is
obvious for the reader what kind of content the link is pointing to.</p>
<!-- /p -->
<ul>
<li>Project Gemini</li>
<li>Gemini — Wikipedia</li>
<li>Why I started using Gemini — Oscar Benedito</li>
</ul>
<p>
Two notes: this way of writing titles is the one I follow for HTML's <code>a</code> tags'
<code>title</code> attribute, but other authors will do them differently. Also, the correct way to
link to a blog post would be to link using the whole sentence ("I have lately been reading many
pages on Gemini"), but not everyone does it.</p>
<!-- /p -->
<h2>Final thoughts</h2>
<p>
When first reading about links in <code>text/gemini</code> I thought they were too limiting, but
they turned out to be quite nice. Don't get me wrong, links inside text can be very useful,
especially considering that the web is not only made of large articles but, for this particular
type of webpage, I find Gemini's approach better. This also made me realize how distracting links
can be, and I am now trying to reduce the amounts of links to a minimum, as well as footnotes, to
reduce the distractions caused by them. For now, I will still use links the "HTML way" because
this blog is hosted on the world wide web, but I might change my mind in the future.</p>
<!-- /p -->
<p>
On another note, if Gemini sounds interesting, check out the
<a href="https://gemini.circumlunar.space/docs/specification.html">specification</a>, it is easy
to read and the approach is very interesting.</p>
<!-- /p -->
Give back to free and open source softwaretag:oscarbenedito.com,2020-11-11:/blog/2020/11/give-back-to-foss/Oscar Benedito2020-11-11T18:25:00Z2020-11-16T23:22:00Z<p>
Most people make use of free and open source software—or services based on it—that is made
available to the public for free. And I mean free, not services that you pay with your data, but
those that are truly free of cost. Projects that rely on donations, grants, and the resources of
the maintainers (and most of the time it's only the latter). If you are a heavy user of FOSS, you
are probably already aware of this, but even if you are not a big user, you probably still use
Wikipedia (or other sites based on the same engine), the VLC media player, or others.</p>
<!-- /p -->
<p>
These programs are great, not only because they are universally affordable (have no cost!), but
because they are focused on the user. Their goal is to serve the user, not the developer, which
often involves software that is more private, useful and easy to adapt to your needs. Software
that doesn't break after a couple of years, and that keeps working even on older devices.</p>
<!-- /p -->
<p>
But this post is not about how great FOSS is, but about helping out these projects. All projects
have a cost, if there is no monetary cost, then there must be people behind it contributing their
time and energy. If you regularly enjoy some of this software, consider giving back to the
developers. This kind of project normally requires a lot fewer resources than commercial ones, and
even then, the maintainers normally carry most of the burden. By helping out, we can enlarge the
community and have more people working on it, as well as help current projects grow. How can we
help? Glad you asked!</p>
<!-- /p -->
<ul>
<li>
<strong>Donate</strong>: It's easy, doesn't require a lot of your resources, and it helps. My
biggest issue is normally convenience. If every time that I have the thought "this is very
useful, I should donate", I could press a button to give 2 euros, I would probably do it. The
problem is that there is no such convenient button. My most successful strategy has been
thinking about a handful of projects I wanted to donate to, and then sit down on my computer and
donate a bigger amount to each one of them. This way I only have to do it once every so many
months, instead of a little donation every two weeks.</li>
<!-- /li -->
<li>
<strong>Report bugs</strong>: Instead of complaining that something doesn't work, take some time
to make sure it's something about the program (not just you messing up) and, if it is, go to the
project's bug tracker and either provide more details to an already open issue or file a new one
if you can't find it there. This is can be more time-consuming depending on the bug, but it's
free (except for the time you pay, of course :)).</li>
<!-- /li -->
<li>
<strong>Translate</strong>: This one takes even more time! Is that program not in your native
language? Translate it yourself!</li>
<!-- /li -->
<li>
<strong>Send patches</strong>: If you want a new feature, there is an annoying bug, etc.,
consider jumping into the code and implement it/solve it on your own (or asking for some help
doing it).</li>
<!-- /li -->
</ul>
<p>
There are other ways to help (feel free to contact me if you think of more and I'll add them), but
these are the ones that come to mind. I partially wanted the post to be a reminder that donating
money and coding are not the only ways to help. In particular, reporting bugs is something most
users will be able to do and it helps—you can't fix it if you don't know about it. On the other
hand, depending on the project, such bugs will get fixed in a matter of days, so you'll be able to
reap the benefit.</p>
<!-- /p -->
<p>Enjoy a project? Help out!</p>
Improving ergonomics: the Atreus keyboardtag:oscarbenedito.com,2020-10-18:/blog/2020/10/atreus/Oscar Benedito2020-10-18T21:05:00Z2020-10-18T21:05:00Z<p>
Back in March, at the start of the lockdown, I had a lot of free time. I also had a lot of ideas
for personal projects and functionalities for my server, so I started coding a lot. I realized
that since I was spending a lot of time on my computer, without any time constraints, I could use
the opportunity to try things I was always "too busy" to try. Things that I knew would make me
more efficient on my computer, but had a steep learning curve. For example, I started using
<a href="https://i3wm.org">i3</a>, which I eventually changed for <a href="https://dwm.suckless.org">dwm</a>,
and I started using <a href="https://neovim.io">neovim</a> as my main editor (I had some
experience with vim, but never used it for day-to-day tasks). I now use dwm exclusively and vim
nearly exclusively.</p>
<!-- /p -->
<p>
Both programs disregard the mouse completely (or nearly<sup id="fnref1"><a href="#fn1">1</a></sup>),
and most other programs I tried or got more comfortable with during the lockdown also used text as
the main input method. With all these changes towards a more keyboard-centric system, I couldn't
help but think: can I improve my keyboard experience? I already touch-type, so that area didn't
have a lot of room for improvement. I could get a mechanical keyboard, but back then, I had only
used membrane keyboards and I felt perfectly comfortable, I didn't think there was a lot of room
for improvement there either, and I could not justify the economic cost of such a change. That
sounded just about everything I could improve on, so I guess I already had a pretty optimal
experience.</p>
<!-- /p -->
<p><em>Wait a minute...</em></p>
<p>
Why are the keyboards arranged the way they are? Is it the optimal position? Apparently, not even
close! If you look around, you will see that there are a lot of different kinds of keyboards with
the keys arranged in very different ways. Keyboards designed to be more comfortable than regular
ones are normally referred to as <a href="https://en.wikipedia.org/wiki/Ergonomic_keyboard">ergonomic keyboards</a>.
I did some research and I tried to understand—although it was hard to evaluate without trying
them—why they are considered more comfortable. Each keyboard had it's own pros and cons, and after
looking at many, I decided that my perfect keyboard would have the following properties:</p>
<!-- /p -->
<ul>
<li>
<strong>Arranged in columns</strong>: it makes no sense for keyboards' rows to be staggered.
Indeed, the reason for that design is that typewriters had to be staggered so that the levers
could all fit under the keys. With computers, this isn't an issue anymore, and columns are more
comfortable.</li>
<!-- /li -->
<li>
<strong>Make use of thumbs</strong>: my right thumb's job on a normal keyboard is to press one
big space bar and my left thumb doesn't even have a job! I would rather have a small space bar
and fit a couple more keys for each thumb.</li>
<!-- /li -->
<li>
<strong>Minimize the movements of my fingers</strong>: ideally, no finger would have to press
any key that's not adjacent to it's "resting" key (diagonally adjacent is fine).</li>
<!-- /li -->
<li>
<strong>Easy to type modifier keys</strong>: as I use the keyboard instead of the mouse as much
as I can, I use modifier keys often. I would like them to be reached easily.</li>
<!-- /li -->
<li><strong>High distance between hands</strong>: for a better posture when writing on my computer.</li>
</ul>
<p>
In short, I wanted to maximize the comfort of typing while minimizing the movements my hands had
to make. Additionally, I didn't want to spend a lot of money (I didn't know if I was going to like
moving to a different keyboard) and also would rather not have to build the keyboard myself,
although it looked like that was the only option.</p>
<!-- /p -->
<p>
After all the research, only one keyboard seemed to fulfill all my needs: the
<a href="https://atreus.technomancy.us">Atreus keyboard</a>. The Atreus seemed great, I would have
liked it more if it had an extra column on each side (like the
<a href="https://shop.profetkeyboards.com/product/atreus62-keyboard">Atreus62</a>), but it wasn't
a big deal. The reviews on the Atreus were all great, so I decided to give it a try.</p>
<!-- /p -->
<p>
Luckily for me, back then <a href="https://keyboard.io">Keyboardio</a> had just launched a
Kickstarter campaign for that precise keyboard. It had a good price for an ergonomic keyboard and
I didn't have to build it on my own. The only problem was that I'd have to wait until the end of
August to receive it, but time wasn't an issue for me, so I bought it. Fast forward five months to
two weeks ago, the keyboard finally arrived! <em>(There were some delays, although the people at
Keyboardio always kept us informed, great experience overall.)</em></p>
<!-- /p -->
<p>
I have been able to use the new keyboard for some time now and it looks good so far<sup
id="fnref2"><a href="#fn2">2</a></sup>. It took some time to get used to the columns instead of
staggered rows, but I am doing a lot better now. It also took some time to get used to the layers
(I had to re-learn where every character is!), but after I changed the layout to make it as
intuitive as possible, the learning process has been a lot faster.</p>
<!-- /p -->
<p>
Although I am liking the keyboard so far, I don't want to evaluate it extensively while still
getting used to it and I think I shouldn't reach any conclusions until I feel more comfortable
with it. I will probably write about my experience with the Atreus in the future.</p>
<!-- /p -->
<!-- footnotes -->
<hr />
<ol>
<li id="fn1">
In my case, I deactivate the mouse completely in neovim, as the only thing I use the mouse for
is to select text to easily paste it with the middle button on another application, but I like
the cursor staying where it is when I do it. For dwm, you can selects tags with the mouse, but I
rarely do that. <a href="#fnref1" title="Jump back to footnote 1 in the text">↩</a></li>
<!-- /li -->
<li id="fn2">
I don't want to use it for day-to-day tasks yet, as I am still a bit slow and feel more
comfortable with a regular keyboard, so I haven't used it that much. <a href="#fnref2"
title="Jump back to footnote 2 in the text">↩</a></li>
<!-- /li -->
</ol>
Switching to my own static site generatortag:oscarbenedito.com,2020-09-27:/blog/2020/09/switching-to-own-ssg/Oscar Benedito2020-09-27T16:27:00Z2020-09-27T16:27:00Z<p>
Since the start of this website (its first anniversary was a couple of weeks ago!) until recently,
I have been using the static site generator <a href="https://gohugo.io">Hugo</a>. Static site
generators are very useful when building relatively complex static websites, and Hugo has served
me well. I have also used <a href="https://www.getlektor.com">Lektor</a> and <a
href="https://jekyllrb.com">Jekyll</a> before for other projects, but for a site with a blog, I
like Hugo the most. However, with time, some issues have arisen with Hugo, and I finally decided
to change my site's generator.</p>
<!-- /p -->
<h2>Issues with Hugo</h2>
<p>
If you build your website with a static site generator, it will probably be the most critical
dependency of your site. Of course, it's a dependency I'm fine with as it makes things much easier
(dealing with Markdown content, categories, web feeds...), but if something goes wrong, the site
won't render as you want. Hugo in particular is a very big project and I don't feel like jumping
into the source code every time I have an issue with the program (especially since I've never used
Go, and I don't want to spend hours for minor annoyances). Although Hugo works wonderfully, I have
encountered moments where it has acted unpredictably, and documentation doesn't help most of the
time.</p>
<!-- /p -->
<p>
On top of that, although it works perfectly well (and it is one of the most popular SSGs), it is
on a beta stage and the developers have made backward-incompatible changes without warning in the
past. The change I have in mind was clearly stated on the release page, but I normally let my
package manager handle the updates, and I want my computer to keep working correctly (or throw big
red warnings all over the place). In this case, HTML inside Markdown files stopped rendering, and
I only found out coincidentally a couple of weeks later as the web feed was not valid anymore.
From that moment on, I started checking the release notes for every update (which are frequent,
about once a week), but it was an annoying routine.</p>
<!-- /p -->
<p>
I understand that the program is in beta and it was on me to check for breaking changes, but to be
fair, Hugo is marketed as a fully functional program (as if it wasn't on a beta stage) on the
official website. Considering my last issue, this was concerning and ended up creating uncertainty
on the stability of Hugo and the transparency of the developers, so I decided to change my site
generator.</p>
<!-- /p -->
<h2>Taking the leap</h2>
<p>
I wanted to move to something lightweight that could still be useful in a few years' time, ideally
a program that was easy to understand and maintain. The problem was that I had some very specific
needs that small programs didn't fulfill, leaving only big programs as an option (which I didn't
want to use). I thought of the possibility of creating my own site generator, but it looked like a
large task I didn't want to spend my time on. Hugo was working fine, and although I kept looking
up other SSGs when I discovered them, I stopped actively looking for alternatives or thinking
about designing my own.</p>
<!-- /p -->
<p>
Until the night of the 5th of September, when I came across <a
href="https://github.com/sunainapai/makesite">makesite.py</a>. This project was just perfect, and
I couldn't resist. Let me show you an extract of the README:</p>
<!-- /p -->
<blockquote>
<p>Have you used a popular static site generator like Jekyll to generate your blog?</p>
</blockquote>
<p>Yes...</p>
<blockquote>
<p>
I have too. It is simple and great. But then did you yearn to use something even simpler to
generate your blog? Do you like Python? Perhaps the thought of writing your own static site
generator crossed your mind but you thought it would be too much work?</p>
<!-- /p -->
</blockquote>
<p>Yes, yes, and definitely yes!</p>
<blockquote>
<p>If you answered "yes" to these questions, then this project is for you.</p>
</blockquote>
<p>
Nice! That night I read the README and the source code (which is shorter than the README). The
program is very simple and a lot of the basic functionality I needed out of a static site
generator was already there. On top of that, it didn't use any non-standard Python library except
for the Markdown parser. I really liked the project and I thought it could be the foundation of my
personal static site generator.</p>
<!-- /p -->
<p>
It was. The next morning, I started coding to make it usable for my website. I had to implement
many new features, but with Python it was <a href="https://xkcd.com/353/">easy and fun</a>. After
two days of working on it, I finally released my site using a personal fork of makesite.py,
<a href="https://git.oscarbenedito.com/oscarbenedito.com/file/gensite.py.html">gensite.py</a>!</p>
<!-- /p -->
<h2>The new benefits</h2>
<p>
So, why change the SSG if Hugo was working fine? As I said, I've had my issues with Hugo, and I
don't want to be forced to leave my static site generator if more arise in the future. I don't
know if I'll be able to switch SSGs when (and if) the time comes, and now I have the time and
motivation needed to do it, so I decided to take the chance while it was there. On top of that,
<em>gensite.py</em> is not only my "way out of Hugo", it is a program that has many features that
could have made me do the change without having any troubles with the last SSG.</p>
<!-- /p -->
<p>
First of all, the program is very small, it's only about 270 lines of code and it's written in
Python. That makes it very easy for me to read and understand the whole program very quickly, even
if I have completely forgotten everything about it. Obviously, this doesn't count the lines of
code of the libraries it depends on, but those are all standard libraries and the functions are
easy to understand, except for the Markdown parser, but if that ever gives me any trouble I can
change it without much effort.</p>
<!-- /p -->
<p>
Since <em>gensite.py</em> is made exclusively for my website, it is more closely tied to the rest
of my site. For example, it doesn't have a complex template engine, instead, templates only
process the following two snippets:</p>
<!-- /p -->
<ul>
<li><code>{{ var }}</code>: substitutes the string for the value of variable <code>var</code>.</li>
<li>
<code>{{ _if var }}text{{ _fi }}</code>: will render the text <code>text</code> if variable
<code>var</code> is defined. You can't have an <code>_if</code> inside another.</li>
<!-- /li -->
</ul>
<p>
If I need anything more complex, I will use Python to create the text and pass it as a variable
when rendering the template. I prefer this approach as it is a lot nicer to implement those
features in Python than it is with a template engine. For some pages—for example, the
archive—Python does some more heavy lifting and creates part of the HTML. This can sound weird in
comparison with other static site generators, where HTML is only dealt with in the template files,
but it makes things simpler, and I no longer need hacky templates to create certain outputs.</p>
<!-- /p -->
<p>
Moreover, I like the file structure a lot better (I designed it!), and if I ever want to change
it, it shouldn't take long to do so. Similarly, any other design options are exactly as I want
them to be, since it is me who decided them. In case it is not clear: everything works exactly as
I want it to!</p>
<!-- /p -->
<p>
Finally, it's a project that doesn't move too fast. One of the problems with websites is that
links are easily broken: entities change their backend, run out of money, mess up an update, etc.
and let their links break. Right now, I am pretty dedicated to my website, and if my SSG broke
something on my website, I would spend the time to fix it, but I can't ensure I'll do the same in
two or five years (and I don't want to break any links, even on the long term, but that's a post
for another day). Unless something happens with Python, <em>gensite.py</em> will work and so will
the generation of my website. There won't be any updates that break some random page or that
change a certain behaviour<sup id="fnref1"><a href="#fn1">1</a></sup>. I hope <em>gensite.py</em>
can stand the test of time, but we'll see...</p>
<!-- /p -->
<h2>Final comments</h2>
<p>
Forking <em>makesite.py</em> and setting up everything I needed for my website was very fun, but
it is surely a process that not everyone will enjoy. I have lately been leaning towards software
that is a simple as possible, software that is easy to understand and change if needed. It takes
time to set up, but once it's working, you can forget about it (and if you need to make changes,
they are quickly implemented) and you will have software that works exactly as you want it to. I
am very meticulous about this website and try to have good control over everything that happens
during the website's generation, and I couldn't be happier with <em>gensite.py</em>.</p>
<!-- /p -->
<p>
On another note, I don't want to end this post without saying that Hugo has been a great static
site generator, and I'd recommend it to anyone who wants to have a blog on a static website. In a
new update with breaking changes, they did throw errors if the old feature was used, so maybe my
experience wouldn't happen again. Just remember, it's still in beta.</p>
<!-- /p -->
<!-- footnotes -->
<hr />
<ol>
<li id="fn1">
Also, whenever I make changes to <em>gensite.py</em>, I can run <code>diff -r</code> to check
for differences for the outputs before and after the update. With Hugo, many files changed
without explanation (although it was mostly style choices, it made it hard to see the real
changes in content between updates). <a href="#fnref1" title="Jump back to footnote 1 in the
text">↩</a></li>
<!-- /li -->
</ol>
DAVup: back up your contacts and calendarstag:oscarbenedito.com,2020-08-30:/blog/2020/08/davup/Oscar Benedito2020-08-30T19:27:00Z2020-08-30T19:27:00Z<p>
Meet <a href="https://git.oscarbenedito.com/osf/file/davup.sh.html">DAVup</a>! It is a simple
script that will back up any contacts, calendars and to-do lists synchronized through CardDAV or
CalDAV.</p>
<!-- /p -->
<p>
I have always synchronized my contacts and calendars with online services to avoid losing them if
something happened to my phone and to have them synchronized with my computer. For some time, I
have been going a step further with my backups and have tried to keep a local backup of as many
things as I can. With that goal in mind, I made DAVup, which is very simple and does exactly what
I need. If you are interested, have a look!</p>
<!-- /p -->
Adding about pages to stagittag:oscarbenedito.com,2020-08-15:/blog/2020/08/adding-about-pages-to-stagit/Oscar Benedito2020-08-15T19:59:00Z2020-08-15T19:59:00Z<p>
I use <a href="https://codemadness.org/stagit.html">stagit</a> to show the public repositories of
my Git server on the web. I chose stagit because it is a very simple and lightweight tool, which
makes tinkering with the source code very straightforward (which I have been doing a bit lately)
and because the resulting website is static: easy to set up, faster, and there aren't any
application-specific issues (there is no application). Static sites are also nice because you know
exactly what is going on when a page is requested—the file is served—, whereas if it is a dynamic
site, you might or might not know what operations the server is doing to answer the request.</p>
<!-- /p -->
<p>
Stagit doesn't have many features. This isn't necessarily bad, as it keeps the source small and
readable and it still does everything I consider necessary, it even has an Atom feed for commits!
The one feature I really missed was being able to show an about page with the repository's readme
file when it is opened<sup id="fnref1"><a href="#fn1">1</a></sup>. For me, it is a basic feature,
especially with repositories for projects without a website/wiki. When I hear about a piece of
software, the first I do is go check out the repository and read a bit about it, and readme files
make that easier. Since most of my repositories have readmes written in Markdown, I wanted stagit
to convert them to HTML, so they could be shown nicely on the repositories' website.</p>
<!-- /p -->
<p>
If you want to try it out yourself, the change on stagit is very simple, just a couple of lines,
but it will add a dependency to the program<sup id="fnref2"><a href="#fn2">2</a></sup>. I use
<a href="https://github.com/mity/md4c">md4c</a> to parse the files, and it is ridiculously fast. I
haven't noticed any changes in the time it takes for stagit to run. Check out
<a href="https://git.oscarbenedito.com/stagit/commit/1fdbc7e8ef4025e50678261ca670daca85ac298c.html">this
commit</a> if you want to know how I did it, and feel free to suggest other approaches if you
think they are better.</p>
<!-- /p -->
<!-- footnotes -->
<hr />
<ol>
<li id="fn1">
Stagit has a link on the navigation bar to the readme file, and you could easily make that the
default <code>index.html</code> file, but it is just the page with the raw file (as any other
file is shown), it isn't presented like an about page. <a href="#fnref1" title="Jump back to
footnote 1 in the text">↩</a></li>
<!-- /li -->
<li id="fn2">
The dependency is only for parsing Markdown, if you don't need that, you can just show the raw
file without the line numbers and metadata, this is what
<a href="https://git.oscarbenedito.com/stagit/commit/1fdbc7e8ef4025e50678261ca670daca85ac298c.html#h5-5-16">I
do</a> when the readme file isn't a Markdown file. <a href="#fnref2" title="Jump back to
footnote 2 in the text">↩</a></li>
<!-- /li -->
</ol>
What is this vim talk all about?tag:oscarbenedito.com,2020-08-09:/blog/2020/08/what-is-this-vim-talk-all-about/Oscar Benedito2020-08-09T15:16:00Z2020-08-09T15:16:00Z<p>
Oh no! Another <a href="https://www.vim.org/">vim</a> post! Well... yes. I have seen a lot of
people criticizing vim before even trying it, so I am going to try and explain my history with it
and what I like about it. If you aren't aware, vim is a text editor that is normally used from the
command line (and, normally, the mouse doesn't work in it or is deactivated).</p>
<!-- /p -->
<h2>Getting into vim</h2>
<p>
When I first saw people that got around a computer with the keyboard, I realized how much faster
you can do stuff when you don't use your mouse. By that time, I used the copy/cut/paste shortcuts
and that was pretty much it, I didn't even use <code>Alt</code>+<code>Tab</code> to change between
windows, so I was mindblown when I saw people moving around so quickly without touching the mouse.
For me, the keyboard was simply a tool to write text.</p>
<!-- /p -->
<p>
Although I realized that being more familiar with the keyboard would make me more efficient, it
was hard to get used to it. I had to think before every keystroke, and everything was very slow.
GNU/Linux helped a lot with getting more used to the keyboard, not only did I use a couple more
shortcuts, but I also found myself using the terminal often.</p>
<!-- /p -->
<p>
At some point, a friend introduced me to vim. I remember<sup id="fnref1"><a href="#fn1">1</a></sup>
seeing such a weird program—and in the terminal!—and thinking: why would anyone use that?! I was
told that there were a lot of shortcuts, and experienced programmers could move through a file
very quickly with it, as well as do complex operations with the file contents. I believed it, but
I didn't want to spend years mastering vim, so I kept going with a simpler text editor. A couple
of months later, I had a programming class where the teacher would sometimes show us his screen
while writing solutions to exercises. He was fast, very fast. He moved around the file very
quickly and the craziest part was that he was using Geany. All that speed was reached with
<code>Home</code>, <code>End</code>, arrow keys, etc. No <em>real</em> shortcuts. I think that is
the point in time when I understood what a program focused on keyboard shortcuts (like vim) had to
offer.</p>
<!-- /p -->
<p>
Since then, I have tried vim many times and, truth be told, it is hard to start with. I also
didn't code a lot during certain times, and when I had to, I just wanted to get stuff done, so
finding times to figure out vim wasn't as easy. Another friend recommended using vim when editing
Latex files because of a plugin. I was creating Latex documents for some classes so I used vim for
a while to edit those files<sup id="fnref2"><a href="#fn2">2</a></sup>. This is how I started to
be able to do some things in vim. I eventually started managing servers and used it more and
finally, at the start of the confinement, I decided to use it exclusively. It took some time
adjusting to it, but I haven't opened any other editor except for a couple of occasions.</p>
<!-- /p -->
<h2>What I like about vim</h2>
<p>
The first thing that I like is that it is a modal editor, meaning it has modes: you are always on
one mode, and the editor responds differently to keypresses depending on the mode. The two most
basic modes are normal and insert. Insert mode responds to keypresses like you would expect from a
text editor: if you press <code>x</code>, an <code>x</code> is appended to the file you are
editing, and so on. Normal mode, however, will not print the letter you just typed. For instance,
if you press <code>x</code> the letter under the cursor will be deleted, and if you press <code>w</code>
the cursor will move to the first character of the next word. This is great because there are a
lot of shortcuts on normal mode that are incredibly useful, and let you move around the document
without the need of leaving the <a href="https://en.wikipedia.org/wiki/Home_row">home row</a> or
pressing modifier keys.</p>
<!-- /p -->
<p>
Now, normal mode has a ridiculous amount of shortcuts, each key has some behavior assigned to it,
so it can be hard to learn it all. In the end, it is only a matter of practice and it is easier
than it looks like. On top of that, these shortcuts act like a language, which makes them really
powerful. With that, I mean that shortcuts can be mixed to create new shortcuts. It is hard to
explain and there are a lot of explanations online, so I will refer you to two sources, and you
can keep investigating if you are interested:</p>
<!-- /p -->
<ul>
<li><a href="https://stackoverflow.com/a/1220118">Your problem with Vim is that you don't grok vi</a>: A very detailed Stack Overflow answer.</li>
<li><a href="https://www.youtube.com/watch?v=wlR5gYd6um0">Mastering the Vim Language</a>: A YouTube video of a talk in the Boston Vim Meetup of 2015 by Chris Toomey.</li>
</ul>
<p>
This is it for me. The fact that you can do so many things with the keyboard without the need to
keep <code>Ctrl</code> or <code>Alt</code> pressed and do them in such a natural "language" is
what makes vim the best editor I have tried so far. Of course, you can make other editors behave
like vim (<a href="https://en.wikipedia.org/wiki/Vi">vi</a> really), but vim is the best one I've
tried. Well... I actually use <a href="https://neovim.io/">neovim</a>, but for my use-case, I
probably wouldn't be able to tell them apart.</p>
<!-- /p -->
<h2>Final comments</h2>
<p>
There are still a lot of things left for me to learn about vim, especially when dealing with a
project with lots of files, but I am now more comfortable with vim than with a normal editor where
you move around using the mouse.</p>
<!-- /p -->
<p>
As you can see from this post, what I appreciate the most of vim is how it behaves, so I could
easily change to another editor that would copy this behavior and add other features. It is useful
that it is run on the terminal, as it is normally how I move around the computer, but I don't have
anything against other editors. I also want to try <a href="https://www.gnu.org/software/emacs/">Emacs</a>
again at some point (with <a href="https://www.emacswiki.org/emacs/Evil">Evil mode</a>, of
course), we'll see how that goes!</p>
<!-- /p -->
<!-- footnotes -->
<hr />
<ol>
<li id="fn1">
This is how I remember it, but it was—I think—three years ago, so it might not be completely
accurate. <a href="#fnref1" title="Jump back to footnote 1 in the text">↩</a></li>
<!-- /li -->
<li id="fn2">
The plugin is really nice (especially when writing big amounts of text), but I was so
uncomfortable with vim that I would write everything in vim and then edit/review it with a
different editor. <a href="#fnref2" title="Jump back to footnote 2 in the text">↩</a>
</li>
<!-- /li -->
</ol>
Setting up a personal Git servertag:oscarbenedito.com,2020-06-23:/blog/2020/06/setting-up-a-personal-git-server/Oscar Benedito2020-06-23T16:10:00Z2020-07-24T15:17:00Z<p>
Running a personal Git server is something that has been on my mind for quite a long time. One of
the most popular solutions I have seen around is <a href="https://gitea.io">Gitea</a>. A couple of
months ago, when trying out different things, I decided to run Gitea locally to see how easy it
would be to implement on my server. It turns out pretty easy, especially if you are using Docker.
However, my server doesn't run Docker as of now and it also felt like customizing it would be hard
(for example, getting rid of the username in the URLs). Gitea looks like a very good solution for
self-hosting Git (and the sites look very nice!), but in my case, it felt like using a
sledgehammer to crack a nut. I figured most self-hosted Git solutions would turn out to be a bit
too much for my use case, so I decided to look into hosting Git without any other program.</p>
<!-- /p -->
<p>
I had experience setting up a bare-bones Git server only usable through SSH, so I looked up how to
create a website with the <code>bare</code> repositories. It turns out there's even a built-in
option<sup id="fnref1"><a href="#fn1">1</a></sup>! Other programs have more or less similar looks,
but I decided to check if there was any way to have a static generator for the webpage—the fewer
things running on my server the better! And there is one (that I found):
<a href="https://codemadness.org/stagit.html">stagit</a>. It is very simple, and it does the job.
On top of that, the program is super small, which makes it very easy to modify it if needed<sup
id="fnref2"><a href="#fn2">2</a></sup>. I gave it a try and it worked nicely. I decided that it
was a good solution for my use case, therefore having a vanilla Git server would work, so I
started building it<sup id="fnref3"><a href="#fn3">3</a></sup>.</p>
<!-- /p -->
<p>Let's see how to set it up!</p>
<h2>Setting up a Git server</h2>
<p>
What will happen is we'll have <code>bare</code> repositories on our server which we'll then
clone/fetch/push to using SSH<sup id="fnref4"><a href="#fn4">4</a></sup>. We'll put these
repositories on the <code>/srv/git</code> directory—because I keep everything served from my
server on <code>/srv</code>—but any location will work. To keep Git separated from the root user,
we'll create a new <code>git</code> user, with <code>/srv/git</code> as its home folder, this way,
the remote address will be <code>git@domain:repo.git</code> (no need for an absolute address).
Let's do that:</p>
<!-- /p -->
<pre><code><!--
-->useradd -d /srv/git git
<!-- -->mkdir /srv/git
<!-- -->chown git /srv/git</code></pre>
<p>Now, let's create the folder for the SSH configuration where we'll add our public key.</p>
<pre><code><!--
-->su git
<!-- -->cd
<!-- -->mkdir .ssh && chmod 700 .ssh
<!-- -->touch .ssh/authorized_keys && chmod 600 .ssh/authorized_keys</code></pre>
<p>
We could stop here, adding our key to the file (you can also use <code>ssh-copy-id</code>), but we
can take a couple more steps to isolate the user from the server, useful especially if you want to
share access to the git user with someone else.</p>
<!-- /p -->
<p>
To do that, we'll use the <code>git-shell</code> shell, which will only run scripts found on
<code>~/git-shell-commands</code>.<sup id="fnref5"><a href="#fn5">5</a></sup></p>
<!-- /p -->
<pre><code>chsh git -s $(which git-shell)</code></pre>
<p>
Now if you add someone else's public SSH key to the server, they won't be able to run any command.
If you want to allow some commands, create scripts on <code>~/git-shell-commands</code>. For
example, I have scripts to initiate repositories, add SSH keys and other useful commands, you can
see them all <a href="https://git.oscarbenedito.com/git-shell-commands/">here</a>.</p>
<!-- /p -->
<h2>Making repositories public</h2>
<p>
Now we can pull and push to our repository, and we can share access to them by adding SSH keys (or
sharing the password if you use one). However, we might want to have public repositories that
people should be able to clone without the need to have access to all of them. To do so, we'll use
the Git Daemon (that uses the Git Protocol). All we have to do is run the following command (and
keep it running, I recommend running a systemd service if you use systemd, there is an example
<a href="https://git-scm.com/book/en/v2/Git-on-the-Server-Git-Daemon">here</a>).</p>
<!-- /p -->
<pre><code>git daemon --reuseaddr --base-path=/srv/git/ /srv/git/</code></pre>
<p>
This daemon will only serve repositories that have a file named <code>git-daemon-export-ok</code>
in them, so if you want to make a certain repository public, all you have to do is run:</p>
<!-- /p -->
<pre><code>touch /srv/git/repo.git/git-daemon-export-ok</code></pre>
<p>
Remove that file to make it private again. The cloning address will be
<code>git://domain/repo.git</code> and you can't push to that address. You can also serve
repositories through HTTP which will allow you to have fine-grained control over who can access
which repositories, look it up if you are interested.</p>
<!-- /p -->
<h2>Making a website</h2>
<p>
Now we can host private and public repositories, but we may want to share the public ones easily.
A website is a good way to allow people to quickly see your repositories without the need to clone
every single one of them. We'll use stagit to create the HTML files which we'll host as a static
site. First of all, let's install stagit:</p>
<!-- /p -->
<pre><code><!--
-->git clone git://git.codemadness.org/stagit
<!-- -->cd stagit
<!-- -->sudo make install</code></pre>
<p>To create a website for a repository run</p>
<pre><code>stagit /path/to/repo.git</code></pre>
<p>from the directory where you want the site built. To create an index file with all your repositories simply run</p>
<pre><code>stagit-index /path/to/repo-1.git /path/to/repo-2.git > index.html</code></pre>
<p>
with the path to all your repositories. Make sure you have the correct information on the
<code>owner</code>, <code>description</code> and <code>url</code> files so that stagit uses them
when creating the HTML.</p>
<!-- /p -->
<p>
Having to do this is every time you update your repositories is not a reasonable solution, but we
can set up a <code>post-receive</code> hook to do it for us. There are examples of scripts to use
as an initial creation script for the whole site and a post-receive hook on stagit's source code
repository. I have changed those scripts a bit to only process public repositories (the ones with
the <code>git-daemon-export-ok</code> file) as well a modified the source a bit. You can find the
changes on my <a href="https://git.oscarbenedito.com/stagit/">stagit fork</a>.</p>
<!-- /p -->
<h2>Pros of this setup</h2>
<p>
I have only been using this server for a couple of days, but I have also been setting up a bunch
of <a href="https://suckless.org">suckless</a> tools<sup id="fnref6"><a href="#fn6">6</a></sup>,
so I have been using Git a lot. One of the best things is that setting up repositories is very
easy. No need to open a browser, log in to GitHub and go through the process of creating a new
repository<sup id="fnref7"><a href="#fn7">7</a></sup>. I just run</p>
<!-- /p -->
<pre><code><!--
-->ssh git@oscarbenedito.com
<!-- -->init reponame</code></pre>
<p>
Done! I can also set it up as public by running a script I have on my <code>git-shell</code> and
change the description/owner/url just as easily.</p>
<!-- /p -->
<p>
Another thing I have noticed is that Git's clone/fetch/push commands are significantly faster on
this server than GitLab or GitHub. However, I don't know compared to a self-hosted instance of
Gitea or <a href="https://gogs.io">Gogs</a>.</p>
<!-- /p -->
<h2>Cons of this setup</h2>
<p>
One thing that might be missed by this setup is the ability to download a tarball with the code
from a certain commit, browse the code as it was in a given commit, see git blame, etc. This could
be solved by using another tool for the website part—such as <a
href="https://git.zx2c4.com/cgit/about/">cgit</a>—so if I ever want to do that, it shouldn't be hard.</p>
<!-- /p -->
<p>
Another thing is how the website looks. Other self-hosting solutions like Gogs, Gitea, GitLab...
look a lot nicer than stagit. However this isn't a priority right now and I appreciate the ability
to have full control over how the server works—and it has been very interesting to learn about it
all. Once again this is something to do with the website, and not the repository hosting
itself.</p>
<!-- /p -->
<h2>Final comments</h2>
<p>
It has been fun to set everything up and realize how easy it is to self-host Git without the need
for other software. On top of that, I can now share my repositories from my domain, which means it
is easier to stop using other hosting services if I stop wanting to accept their policies, similar
to having email on my domain.</p>
<!-- /p -->
<p>
For now, I will still have my public repositories hosted on GitLab and GitHub, as I don't mind it
and some people might be more used to those UIs. They also act as a backup in case something
happens to my server or if I want to edit my repositories from a computer without SSH access to my
server.</p>
<!-- /p -->
<p>
Finally, I have talked about some software that will allow you to self-host Git, but I don't want
to end this post without mentioning <a href="https://sourcehut.org/">sourcehut</a>. I find it a
very good solution because everyone can contribute to your projects without the need to create yet
another account. Everything is done through email, which is nicely supported by Git (learn more
<a href="https://git-send-email.io/">here</a>).</p>
<!-- /p -->
<p>
I almost forgot! If you want to check out my Git website or clone some repositories from my
domain, you can find all of that here: <a href="https://git.oscarbenedito.com">https://git.oscarbenedito.com</a>.</p>
<!-- /p -->
<p>
<em>Edit</em>: The post originally said that creating a new repository on GitLab was a long
process. However, you can just push to a new remote address and GitLab will automatically create
the new repository.</p>
<!-- /p -->
<!-- footnotes -->
<hr />
<ol>
<li id="fn1">
Run <code>git instaweb</code> from a Git repository to try it. <a href="#fnref1" title="Jump
back to footnote 1 in the text">↩</a></li>
<!-- /li -->
<li id="fn2">
I haven't modified the source code much yet, but I have some ideas in mind. <a href="#fnref2"
title="Jump back to footnote 2 in the text">↩</a></li>
<!-- /li -->
<li id="fn3">
Funnily enough, I had already set up a Git server there for a couple of repositories containing
a lot of personal information to avoid hosting them on GitLab or GitHub. I completely forgot
about it. I deleted it and started from scratch, as I wanted to document the process on my
personal wiki. <a href="#fnref3" title="Jump back to footnote 3 in the text">↩</a></li>
<!-- /li -->
<li id="fn4">
Bare repositories are simply a folder with the files of the <code>.git</code> directory of a
repository. Indeed, you can clone a repository from your computer running <code>git clone
/path/to/repo/.git cloned-repo</code>. This directory contains all the information of the
repository, that is why Git is distributed. <a href="#fnref4" title="Jump back to footnote 4 in
the text">↩</a></li>
<!-- /li -->
<li id="fn5">
If the <code>chsh</code> command doesn't work, make sure <code>git-shell</code> is in
<code>/etc/shells</code>, if not, add it manually. <a href="#fnref5" title="Jump back to
footnote 5 in the text">↩</a></li>
<!-- /li -->
<li id="fn6">
Fun fact: after setting everything up I realized that suckless uses stagit to show their
repositories, indeed the author of stagit is the current maintainer of some suckless projects
like <a href="https://st.suckless.org/">st</a> and <a
href="https://tools.suckless.org/dmenu/">dmenu</a>. <a href="#fnref6" title="Jump
back to footnote 6 in the text">↩</a></li>
<!-- /li -->
<li id="fn7">
I originally thought this was also the case for GitLab, however, you can push a new repository
to a new remote address and GitLab will automatically create it. <a href="#fnref7" title="Jump
back to footnote 7 in the text">↩</a></li>
<!-- /li -->
</ol>
Blocking connections on Androidtag:oscarbenedito.com,2020-05-27:/blog/2020/05/blocking-connections-on-android/Oscar Benedito2020-05-27T19:01:00Z2020-05-27T19:01:00Z<p>
I have been a user of <a href="https://www.netguard.me/">NetGuard</a> for quite some time. It is a
great Android app that lets you control which apps get Internet access and which don't. The paid
version will allow you to block connection on a per-domain basis (for each app), as well as let
you see all the domains an app connects to (which are normally a lot!). Furthermore, you will be
able to block domains for the whole phone. This is useful because it can act as an add blocker (by
default it uses the list of domains gathered in <a href="https://github.com/StevenBlack/hosts">this repository</a>).
The Google Play version doesn't have this feature because Google doesn't allow add blocking on the
store, so make sure you get the app directly from GitHub!</p>
<!-- /p -->
<p>
A couple of months ago I decided to use a VPN, it felt like ISP's where very public about
everyone's data, and I decided to put my trust in a company whose business is protecting their
customers' privacy. The problem with VPNs is that you have to trust them. There is no way for you
to ensure they aren't selling your browsing habits to the best bidder, but I did my research on
the provider I chose and I trust them a lot more than an ISP. Now you may ask, how is this related
to NetGuard? Well, NetGuard uses the VPN functionality on Android to be able to block certain
connections without root access, and Android only allows one VPN at a time, so I had to choose
one<sup id="fnref1"><a href="#fn1">1</a></sup>.</p>
<!-- /p -->
<p>
Finally, I decided to go with my VPN. However, I really liked the domain blocking feature, so I
decided to investigate a little further. It turns out you can use the <code>/etc/hosts</code>
files to block certain domains just like in a GNU/Linux computer. It is an easy process and it
really makes a difference in your mobile browsing experience. I'll explain how I did it with my
phone in case it helps anyone else (although simply installing NetGuard is a simpler solution for
sure, and you get more features!).</p>
<!-- /p -->
<p>
First of all install Android Debug Bridge (ADB) on your computer. If you are using GNU/Linux, you
can use <code>pacman -S adb</code> on Arch based distributions or <code>apt install adb</code> on
Debian based distributions, look it up if you have other distributions or operative systems. Now
plug your phone into your computer and on your phone enable developer settings (look it up if you
don't know how to do it) and do the following:</p>
<!-- /p -->
<ol>
<li><code>Android debugging</code> > <code>on</code></li>
<li><code>Root access</code> > <code>ADB only</code></li>
<li>Make sure your computer has access to your phone by enabling <code>PTP</code> on your phone (instead of <code>No data transfer</code>).</li>
<li>On the computer run <code>$ adb root</code> to get root access.</li>
<li><code>$ adb remount</code>, which will allow you to modify the file on the phone.</li>
<li><code>$ adb push /path/to/hosts/on/computer /etc/hosts</code></li>
<li>Done! You can now unplug your phone (and disable the options you enabled previously if wanted).</li>
</ol>
<p>If you want to edit the file manually, do the following after step 5:</p>
<ol>
<li><code>$ adb shell</code>, which will give you a terminal on the phone.</li>
<li><code># nano /etc/hosts</code> (<code>vim</code> also works on LineageOS).</li>
<li>Do your changes.</li>
<li><code># exit</code></li>
</ol>
<p>
Easy! However, I am using LineageOS and I am unsure if you can do step 2 on a stock ROM (if you
can't, you might need a rooted device). If you try it—whether on a stock ROM or another custom
ROM—, let me know if it works! You still won't be able to block certain apps' connections as with
NetGuard, but you won't have ads while keeping the VPN feature available for other uses.</p>
<!-- /p -->
<!-- footnotes -->
<hr />
<ol>
<li id="fn1">
NetGuard offers a way to do what I wanted, through proxies, but I didn't like the workaround.
<a href="#fnref1" title="Jump back to footnote 1 in the text">↩</a></li>
<!-- /li -->
</ol>
My journey through desktop environmentstag:oscarbenedito.com,2020-05-05:/blog/2020/05/my-journey-through-desktop-environments/Oscar Benedito2020-05-05T19:26:00Z2020-05-06T07:52:00Z<p>
My first experience with GNU/Linux was with KDE. It is the desktop environment used on my college
computers, and it was more or less the only experience I had with the GNU/Linux operative system,
so it was the desktop environment I installed at home (at that point I don't think I knew the
difference between a distribution and a desktop environment). After some time, I got comfortable
with the new OS and learned that distributions and desktop environments were completely different
things, so I started to look around for other DEs and decided to go with GNOME. It was a weird
choice, as I had only read—and heard—bad things about GNOME, but I was reading a lot about the GNU
project and decided to go with the DE that was part of the project, just to try it out.</p>
<!-- /p -->
<p>
Well, GNOME is great. I love GNOME! I am glad I wanted to try it (for a more or less stupid
reason) against what people were writing/saying. It works great out of the box, it has programs
for everything I needed and can easily be configured to fit your needs<sup id="fnref1"><a
href="#fn1">1</a></sup>. With Debian 10, the dark theme is great, and other apps like firefox also
go dark with it<sup id="fnref2"><a href="#fn2">2</a></sup>. It was a bit confusing the first
couple of days, but it was easy to get used to. GNOME has worked great for me (and still does).
With the lack of a bar with all the open windows (like on KDE), I have gotten more used to moving
around with the keyboard. I also made a conscious effort to use the keyboard more, as I had seen
many people move around faster and more naturally when they weren't using the mouse. So, after
gaining confidence with the keyboard, I decided to finally give i3 a <em>real</em> shot a couple
of weeks ago.</p>
<!-- /p -->
<p>
<a href="https://i3wm.org/">i3</a> is a tiling window manager, which means that it is a window
manager that arranges windows in a way that they don't overlap. A window manager is the software
that manages your windows (resize, move, close, etc.). The difference with desktop environments is
that the latter come with a window manager, but also many more programs (like a terminal emulator
or a text editor) as well as panels, system menus, and other features. These normally all look
alike and work well together.</p>
<!-- /p -->
<p>
I say I decided to give it a <em>real</em> shot because I have tried i3 multiple times before:
mainly logging in, seeing how ugly everything looks, logging out<sup id="fnref3"><a href="#fn3">3</a></sup>.
This time it was different: I had time to figure everything out, so I decided to push through the
first days (when everything is to be configured"), and then decide. I installed it, tweaked it a
little, didn't like some things, installed <a href="https://swaywm.org/">sway</a>, it fixed some
things but messed up others, I also considered other tiling window managers like
<a href="https://dwm.suckless.org/">dwm</a>, and went back and forth a couple of times (all in one
day). Eventually, I decided sway had one problem I couldn't cope with<sup id="fnref4"><a href="#fn4">4</a></sup>
and decided to stick with i3. I made a list of everything that was missing (or "wrong") and went to bed.</p>
<!-- /p -->
<p>
The next day, I grabbed the list and started working on the items. Some of them were very easy to
fix, like make the sound buttons work. Some others were a little harder, like mounting USB
automatically. I even had to reinstall i3—a fork of i3 actually—so I could have gaps between
windows (yes! I needed those!). I also added more items to the "problems-to-fix" list as I kept
using i3. After about a week, I had fixed everything on the list!</p>
<!-- /p -->
<p>
This process of going through a lot of minor things made me realize how awesome GNOME is. It has
so many features, without a need for the user to spend hours and hours making everything work. KDE
probably also goes into this category, but I haven't used it as much so I can't say. Other DEs
that I have tried have given me some problems here or there, nothing major, but it isn't the
out-of-the-box experience I appreciate in GNOME.</p>
<!-- /p -->
<p>
Some people quickly disregard these DEs because they are "bloated". In my opinion, it is true.
They have an absurd number of features, but for myself, when I simply need everything to work
without any tweaking, this is great. As a new GNU/Linux user, I wanted my computer to work without
much configuration, while still being able to be "picky" about some stuff. Even as a
moderately-confident user, I didn't have a week to spend making i3 look and act as I wanted. For
all my little things to be included, there are probably many more that I don't want, and are also
included (and other people want). I am fine with my desktop environment being bloated. That
changes for pretty much any other software I run on my computer, I like simple things, but I also
don't have unlimited time. Indeed, my initial reason to switch to i3 (or a tiling window manager)
wasn't "less bloat" or simplicity<sup id="fnref5"><a href="#fn5">5</a></sup> (I find GNOME very
distraction-free, and it has a good performance on my computer). I switched because I was tired of
overlapping windows and I wanted to make more use of my keyboard for managing everything.</p>
<!-- /p -->
<p>
With all the changes, I am very satisfied with i3, and haven't gone back to GNOME for a week. It
did take a lot of time to figure everything out (and configure it), but it was something I had
wanted to do for a long time (that's why the many attempts) and I finally had extra time to do it.
It was definitely worth it!</p>
<!-- /p -->
<h2>Final note</h2>
<p>
I think one of the major issues I had on my previous attempts was the <code>$mod</code> key used
for all i3 shortcuts. It is so hard to reach the <code>Super</code> key! I had already switched
the mapping of <code>Caps lock</code> and <code>Escape</code> (which improved my vim experience
drastically), so I knew <code>Caps lock</code> was the key I needed for my shortcuts (it is so
easy to reach!). I have now mapped <code>Caps lock</code> to act as <code>Escape</code> if I tap
it, and as <code>Super</code> if I hold down. With this little trick, i3 becomes a lot nicer, but
without damaging vim's experience. If you are considering using a tiling manager, think about it!
Also recommended if you use vim!</p>
<!-- /p -->
<!-- footnotes -->
<hr />
<ol>
<li id="fn1">
A very simple example is setting up "natural scroll" for the trackpad, which I had a couple of
issues the first time I tried with some DEs. But there are many things. <a href="#fnref1"
title="Jump back to footnote 1 in the text">↩</a></li>
<!-- /li -->
<li id="fn2">
I know this feature is not exclusive for GNOME (indeed, I configured i3 to act like this), but
it works out of the box, which is the point I am making. <a href="#fnref2" title="Jump back to
footnote 2 in the text">↩</a></li>
<!-- /li -->
<li id="fn3">
I have a HiDPI screen which made everything look super tiny. I had some issues with HiDPI
screens with KDE (there was always a weird app that didn't work well with it). This got solved
(out of the box!) with GNOME, and after all the frustration I had in the past, seeing it back
was a nightmare. This was finally solved pretty easily, although the solution is a little hacky
so I can also plug my computer into non-HiDPI screens. <a href="#fnref3" title="Jump back to
footnote 3 in the text">↩</a></li>
<!-- /li -->
<li id="fn4">
The problem is that applications using Xwayland are blurry on HiDPI screens, and that wasn't
solvable as far as I could tell. They also had no plans to solve it anytime soon (according to
sway developers, it is an Xwayland problem, and it's on them to fix it, which is a fair point).
<a href="#fnref4" title="Jump back to footnote 4 in the text">↩</a></li>
<!-- /li -->
<li id="fn5">
Now that I have tried it and feel comfortable, my next installation might come without GNOME and
probably have much less bloat, which I will appreciate for sure. It simply hasn't been a
priority so far. <a href="#fnref5" title="Jump back to footnote 5 in the text">↩</a></li>
<!-- /li -->
</ol>
Use web feeds!tag:oscarbenedito.com,2020-04-18:/blog/2020/04/use-web-feeds/Oscar Benedito2020-04-18T14:59:00Z2020-04-18T14:59:00Z<p>
Web feeds are data formats used to provide users with updates through web syndication. Websites
can use web feeds to post their content in a format that allows users to easily check for updates
regularly. Examples of web feeds are <a href="https://en.wikipedia.org/wiki/Atom_(Web_standard)">Atom</a>,
<a href="https://en.wikipedia.org/wiki/RSS">RSS</a> or <a href="https://en.wikipedia.org/wiki/JSON_Feed">JSON Feed</a>.</p>
<!-- /p -->
<p>
The most popular is RSS, you have probably heard of it. Until a year ago, RSS to me was an old
technology that some people used to get their news on an ugly feed reader. I thought this
technology was obsolete because of the couple <a href="https://indieweb.org/silo">silos</a> that
monopolize online social interactions. Well, this couldn't be further from the truth. Web feeds
are definitely not obsolete, and those "ugly readers" I remembered were just particular examples,
but there are a lot of beautiful readers out there. There's also a lot of people that want to be
able to get updates on different sites without the need to have an account on a centralized
third-party service.</p>
<!-- /p -->
<p>Let's see the benefits of using web feeds.</p>
<h3>Web decentralization</h3>
<p>
Web feeds allow for web syndication, which is key in order to decentralize the web. When you
follow a blog or a podcast through web feeds, neither you nor the content creator rely on a third
party to update you on the content. There's no need to post a new update on a social platform.
When new content is published, the subscribers will see the updates coming directly from the
original domain.</p>
<!-- /p -->
<h3>Centralized updates</h3>
<p>
Wait, what?! Well, not as in "centralized service", but as in you get all the updates from all
these different websites in one app or program. Web feeds allow the subscriber to see all the
content updates in one place, so convenient! Without it, we probably would have to check every
single website regularly to see if new content was published (or maybe design a bot that would do
that for us, but still, annoying).</p>
<!-- /p -->
<h3>Control over content posting</h3>
<p>
By not relying on a third party for content updates, creators have full control over their
communication channel. It will never shut down—disappearing along with the subscribers—, unless
the creator decides to do so. There also won't be any <em>magical</em> algorithms that decide
which updates are worth showing to their subscribers and which ones are not, or even which ones
<em>magically</em> get deleted. Subscribers get all of them.</p>
<!-- /p -->
<h3>Control over the consumption of content</h3>
<p>
By using web feed readers, you can configure a dark theme, a bigger font, etc. You can even have
the content read to you. There are accessibility features for webpages as well, but when using a
web feed it is so much easier, since the content is presented in a standardized format. It is also
in the user's power to filter the content any way they want. Do you want to block certain words?
Done!</p>
<!-- /p -->
<h3>Privacy for the subscriber</h3>
<p>
There's no need to insist on the fact that silos are a privacy nightmare. But there's more. If you
are reading a web feed, there are no advertisements tracking you and there are no <a
href="https://en.wikipedia.org/wiki/Web_beacon">tracking pixels</a>. You read the content (or not)
whenever you want, without anybody tracking you.</p>
<!-- /p -->
<h3>The disadvantages</h3>
<p>
So, why doesn't everyone use it? First of all, most of the blogs I read have a web feed, Mastodon
does too, as well as Youtube<sup id="fnref1"><a href="#fn1">1</a></sup>. However, you cannot
comment through a feed reader and you normally don't see the "related content" and all those extra
features we can find on a website<sup id="fnref2"><a href="#fn2">2</a></sup>. There is also an
entry barrier: it takes a couple fewer seconds to hit subscribe/follow than to look for the web
feed and open your web feed reader to add it.</p>
<!-- /p -->
<p>
Web feeds also work best when you have a lot of sites that publish every once in a while. If you
subscribe to 500 sites that publish hourly, it can get overwhelming with the common feed readers
(although there are probably others that are ready for this kind of usage and make it nice).</p>
<!-- /p -->
<p>
Finally, web feeds avoid tracking subscribers and the embedding of adds. That can be an
inconvenience to the content owner, who might want to do that. Although I am not a fan of it, it
is definitely something that happens. If that is your case, there is an easy solution: don't post
the content on the web feed. Simply put your title and a two-line summary of the content.
Subscribers can then press on the link and open the content. This way you keep your subscribers up
to date, without losing the capacity to embed ads.</p>
<!-- /p -->
<h2>Why e-mail newsletters are not a web feed substitute</h2>
<p>
E-mail newsletters have that decentralized component, you don't depend on a centralized service
(although most of them do, but that isn't necessary). However they are definitely not private.
First of all, you need to give out your e-mail address, who knows if it will end up on a spam
list? If you want to unsubscribe you have to go to their website and hope for them to erase your
data and not only archive it somewhere. Finally, e-newsletters can—and most do—contain tracking
pixels, so they can know how many times a subscriber accesses the content and when.</p>
<!-- /p -->
<p>
If you have an e-newsletter but don't have a website for it, then you have a reasonable excuse not
to have a feed (although you should definitely make a website!). If you post your newsletter
online, then add a web feed! It is very easy!</p>
<!-- /p -->
<h2>Fun fact!</h2>
<p>
As a matter of fact, I started writing a post on RSS feeds about three weeks ago. When writing why
you should add the whole content on your RSS feed and not only a summary, I remembered that to do
so, I did a little hack. I would put the whole content in the <code>description</code> tag, which
was designed for a brief summary. That got me thinking, I wanted to follow the standards. After
searching for a while, I discovered you can use the <code>content:encoded</code> tag, which is
exactly what I needed, but there where other tags that also seemed to do the same. After some more
research, I discovered RSS has some standardization issues. So I looked at the alternative I had
heard about before: Atom. Apparently, Atom arose from the need to standardize RSS, with a new
design that wouldn't have backward compatibility. Atom is very similar to RSS, but I like the fact
that there is one clear specification (apparently it has other cool features in case you are
interested, but I didn't look into them much).</p>
<!-- /p -->
<p>
After reading about this I learned how it worked and implemented for my blog's feed (since Hugo's
default is RSS). So if you use my web feed, you are now retrieving an Atom feed!</p>
<!-- /p -->
<p>
As you probably figured my first draft had a different approach than the final post. This was
partially because shortly after I started writing, <a
href="https://kevq.uk/why-having-a-full-post-rss-feed-is-a-good-idea/">this</a> post came out so I
changed my focus a bit. If you don't post your full content on your web feed, read it!</p>
<!-- /p -->
<!-- footnotes -->
<hr />
<ol>
<li id="fn1">
If you want to follow people from other big social media sites, there are ways to do so! Use an
instance of <a href="https://github.com/zedeus/nitter">Nitter</a> for Twitter or an instance of
<a href="https://sr.ht/~cadence/bibliogram/">Bibliogram</a> for Instagram. If you have other
sites in mind, look around the Internet, someone probably implemented a web feed for it. <a
href="#fnref1" title="Jump back to footnote 1 in the text">↩</a></li>
<!-- /li -->
<li id="fn2">
This is actually seen as a good thing most of the time, as you get to consume the content
without any distractions. <a href="#fnref2" title="Jump back to footnote 2 in the
text">↩</a></li>
<!-- /li -->
</ol>
On not caring about your privacytag:oscarbenedito.com,2020-04-07:/blog/2020/04/on-not-caring-about-your-privacy/Oscar Benedito2020-04-07T16:17:00Z2020-04-07T16:17:00Z<p>
When talking about violations of our privacy, I've found that most people don't care because it is
a thing that happens "far away" (<em>who in that huge enterprise cares about me, my browsing
habits, etc.?</em>). I can see where those people are coming from, it looks as if you are
anonymous because there are just so many people whose data is collected.</p>
<!-- /p -->
<p>
Let's bring it closer: if you are connected to your work WiFi, your employer can—and probably
does—monitor your traffic. This sounds a lot "closer", but maybe not enough. What if a co-worker
showed you a screenshot with all the connections that the devices connected to the WiFi were
doing? That happened to me, I could see my phone in there, with the URL I was visiting a couple of
minutes ago. I could also see other co-workers' phones ("Someone's iPhone", "Someone's Samsung
Galaxy") also followed by URLs. Those URLs were harmless, so that particular screenshot wasn't
particularly dangerous. However, my superiors knew everything I was doing on the work's WiFi<sup
id="fnref1"><a href="#fn1">1</a></sup>. Not that I had anything to hide, but I also had no
intention to give up my privacy, so I started using Tor when connected to the WiFi. They would
probably never know I was using Tor (just that I was accessing a certain IP address), but even if
they did, I didn't really care, there's nothing wrong with using it.</p>
<!-- /p -->
<p>
It seems as people are fine with having their privacy violated when it's from someone "far away",
but they are not okay when someone "closer" does it. Another example of this is email. Most people
wouldn't give away their email password to anybody, but they are okay with the fact that their
email provider is reading all their emails. The same happens with most internet services.</p>
<!-- /p -->
<p>
One can have the feeling that they are anonymous because they are one in a million, but the
reality is we are not. Thanks to technology and data analysis, we are able to process all that
data and profile people based on it. It happens on such a great scale that <a
href="https://en.wikipedia.org/wiki/Real-time_bidding">real-time bidding</a> is a thing. When you
visit a webpage, there is a real-time bid between advertisers to publish their ad in the
designated spaces, and companies bid more or less depending on the profile they have made of you.
In less than a second companies retrieve your profile and bid for you, every time you surf the
Internet!</p>
<!-- /p -->
<p>
You are one of many, but you are definitely not anonymous because of it. Targeted ads might not
sound too terrible. However, today companies are bidding for your attention, can you ensure
tomorrow they won't use that information for other purposes? Today you may trust a big company,
but the information they have will last for very long, can you trust the future leadership not to
use it for other purposes?</p>
<!-- /p -->
<p>
Just like you don't go around giving everyone access to your browsing history or emails, you
shouldn't do the same with companies. You might have nothing to hide, but why would you give such
private information away?</p>
<!-- /p -->
<!-- footnotes -->
<hr />
<ol>
<li id="fn1">
Not everything. When connected through HTTPS, traffic monitoring can only see the domain you are
visiting, not the actual URL. <a href="#fnref1" title="Jump back to footnote 1 in the
text">↩</a></li>
<!-- /li -->
</ol>
A lighter websitetag:oscarbenedito.com,2020-03-21:/blog/2020/03/lighter-website/Oscar Benedito2020-03-21T00:00:00Z2020-03-21T00:00:00Z<p>
Following up with the <a href="/blog/2020/03/lightweight-website/">last post</a>, I decided to
make my website even faster (which probably doesn't make a difference anymore).</p>
<!-- /p -->
<h2>The logo</h2>
<p>
My pages (HTML only) were about 21KB (without compression), but 11KB of those consisted of an SVG
that appeared in all of them: the logo. The logo wasn't requested from a different static file
because I needed to modify it using CSS (so that colors would change when switching to the dark
theme) and, at the time, I thought inlining was the only option to allow that. However,
investigating a little I found out there are alternatives to inlining: we can take advantage of
the <code>use</code> tag of SVGs to "inline" an SVG from a different URL. By using that, my pages
are now around 10KB of size (plus the statics files, which have a total size of 37KB for the pages
without MathJax).</p>
<!-- /p -->
<h2>The static files</h2>
<p>
Considering that the <code>favicon.ico</code> is already 15KB, 47KB for a page is very good!
Nevertheless, I wanted to reduce it even more<sup id="fnref1"><a href="#fn1">1</a></sup>. I looked
into browser caching and liked the idea. I'll explain the basics. When our browser sends a request
for a certain resource (URL/file), the server that responds can add information that tells the
browser how long it should keep the file for. If the next time you browse that site and need the
file again the file hasn't "expired", your browser will not request it, but instead make use of
the copy previously downloaded. This reduces the number of requests made and the bandwidth
used.</p>
<!-- /p -->
<p>
The only problem with browser caching is that if the contents of a certain file change, your users
will not see those until their copies expire. We want to maximize the time a file is used for
before requesting it again while minimizing the time between update checks (unless our static
files never change). To solve that, I used <a href="https://gohugo.io/hugo-pipes">Hugo's
Pipes</a>, which allows you to add the SHA256 sum of a static file to its name automatically (and
all the places where the file is referenced). Now when downloading the CSS file, your browser is
requesting <code>https://oscarbenedito.com/css/style.min.<SHA256>.css</code>, which will
(highly probably) change when the contents change. Since the URL will be different, the browser
will request the new file.</p>
<!-- /p -->
<h2>The uncompressed SVGs</h2>
<p>
I found out that SVG files where not being compressed by default<sup id="fnref2"><a
href="#fn2">2</a></sup>. So I also enabled that!</p>
<!-- /p -->
<h2>Final comment</h2>
<p>
My webpage is ridiculously small and all these optimizations aren't that important. However, it is
fun to learn about all of this and it can also be helpful if in the future I have a site with
bigger static files (or someone reading this has!).</p>
<!-- /p -->
<!-- footnotes -->
<hr />
<ol>
<li id="fn1">
By now you have probably figured out this is more of a hobby than something useful, as the size
reduced is ridiculously small. <a href="#fnref1" title="Jump back to footnote 1 in the
text">↩</a></li>
<!-- /li -->
<li id="fn2">
I don't really know the reason why. It might have something to do with <code>.svgz</code> files.
No idea. <a href="#fnref2" title="Jump back to footnote 2 in the text">↩</a></li>
<!-- /li -->
</ol>