-- Leo's gemini proxy
-- Connecting to xavi.privatedns.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini
Right before last year ended, I was feeling demotivated about software development in general, possibly due to several factors:
However, changes in my personal life allowed me to take a few months off work. It was a good moment to dedicate time to my growing family and stay a bit away from writing software.
It's been a few years now since I stopped using proprietary platforms and learnt how to self-host Internet services. Among them, I replaced Dropbox with Nextcloud, which is easy to use for non-technical users and is somewhat easy to setup (if using snaps). However, the server running such Nextcloud instance (which also runs this Gemini capsule) would run out of resources pretty soon. Having an unresponsive machine while far away from home is not cool at all.
It was clear that Nextcloud was sucking up the majority of the server's resources, so I did some quick search on alternatives. However, I was keeping a list of requirements on the top of my head beforehand, in priority order:
Only a web browser required.
Lightweight, both on the server and clients.
Ideally, no JavaScript required.
File uploading.
Private directory access.
Read-only, public file sharing.
I was somewhat surprised to see no free software projects that featured all of the points above. I initially resisted to write yet another so-called "cloud" project, but I was tempted to write my own vision of a simple and lightweight cloud.
Fast-forward a few months later and roughly 7,500 lines of handwritten source code, and these are the results:
slcl is an AGPLv3-or-later-licensed cloud storage solution, which aims towards maximum portability by restricting itself to POSIX.1-2008 standards, which means, among other things, C99 and sh (aka the POSIX shell) are the only programming languages available. Apart from a POSIX-compliant environment, slcl requires OpenSSL (although few features are used from it) and cJSON, as well as slweb (see below).
On the other hand, slweb, which follows the same license and philosophy as slcl, is a dead simple web framework that allows developers to run their own HTTP/1.1 server as a library. Also, utilities such as, but not limited to, a HTML serialiser are provided so as to allow applications to create their own websites.
"A web application written in C - what a mad idea nowadays!", many exclaimed. I have received this criticism frequently ever since I announced slcl on public channels. While I understand developers might prefer more ergonomic languages nowadays, there is not any reason why software in C cannot be safe. While no software is bug-free, I have tested slcl extensively, including tests with Valgrind, and I must admit I am happy with the results i.e., no memory leaks, read/write errors or unexpected behaviour in a long while.
In my experience, a disciplined attitude is everything a C programmer needs. Then, C rewards the programmer with efficient, fast software that runs pretty much everywhere. In the case of slcl, an instance running on this server takes around 5 MiB VIRT memory (while I assume most of it comes from OpenSSL), or 0.3% MEM, which is literally more than 100 times less memory usage than Nextcloud, while keeping the same essential features that I care about. Also, files get uploaded at a blazing speed, pages load near-instantly and thumbnails (a feature still not on the master branch, as of the time of this writing) no longer turn the system unresponsive.
From a higher level perspective, these projects have demonstrated me how inefficient and bloated modern software projects have become during the last decades. Inefficient software is one of the main culprits behind e-waste, and the industry is instead forcing users to think older hardware is to blame, rather than poorly written, inefficient software. This makes me wonder how many other projects should had been designed with efficiency in mind, rather than trying to achieve as many features as possible.
Article created on August 1st 2023.
-- Response ended
-- Page fetched on Sun Jun 2 00:19:42 2024