Freedombone Blog

Freedom in the Cloud

Freedombone in 2019

2018 has been a fairly significant year for the project. Interest in decentralized systems and education about the problems of large silo systems has been increasing. Mainstream criticisms of Sillicon Valley companies which began to be reported in 2017 became more trenchant. There were continuing purges against disfavored demographics or particular topics of discussion.

Freedombone, and self-hosting projects like it, are becoming more relevant over time.

Probably the most significant changes to Freedombone this year have been the move out of Github and the introduction of the web interface. The web interface takes the project from being hacker grade to something which potentially could be a mass market product pre-installed on hardware. Some plans for the remainder of the year, and into the new year are:

Transition to buster

2019 is another Debian release year and version 10, nickname "buster", will be in freeze early in the year with the expectation of release some time in the middle of the year. Once it goes into freeze then I'll start on a new buster branch of Freedombone. If things are similar to the last release then it will take one or two months to make a new version, depending upon how big the changes are.

Rock64 build

It's probably possible to make a fully free software build for Rock64. I assumed there would be blobs in the boot sequence, but upon more investigation it looks like that isn't the case and it can all be built with Free Software licenses. As usual there might still be proprietary 3D graphics, but for a server that's not needed.

More apps

With the Debian 10 release it will be possible to enable more apps, such as those which require more recent php or python versions. One example is PixelFed.

Web interface polish

Improving the translations. Adding warnings screens. To make something really usable requires laser-like focus on interface minutiae, including things like color contrast, making sure that things are phrased in a comprehensible way and that the flow between screens is as semantically coherent as possible.

Your homepage

Add a web interface screen which can be set as a browser home page, allowing you to quickly navigate to any of your installed apps, and also do web searches.

guifi.net integration

The guifi.net model seems like a good one, with a foundation as a legal mechanism and crowdfunding of network infrastructure. This would be a good direction for the internet to go in, where it is neither run by corporations nor by the government but instead run by and for its users. It would be nice to have an easy way to set up Freedombone as a guifi.net node.

Compute per Watt

One of my projects for 2019 will be to try running an SBC as a desktop machine, to see what's the minimum amount of electricity I can use and yet still have a reasonably good desktop user experience. Whether this will be practical for doing development on I'm not sure, but it's worth a try. If I can get electricity use low enough then maybe there's a chance that in future I could go solarpunk.

I've set up an initial test using a Rock64 (4GB version) running on an SSD via USB3. The I/O bandwidth might not be quite as good as SATA, but it's still going to be a lot better than microSD or EMMC. I've got an old ASUS monitor, a Kensington Orbit trackball, a Unicomp spacesaver keyboard and a USB wifi adapter (suitable for libre distros). There's a small 4 port USB3 passive hub plugged into the Rock64 and a USB2 headphone/microphone adapter for sound. The Rock64 is configured to boot straight from USB3 and is running Armbian (stretch) with XFCE desktop. It's powered by a 15W (5V/3A) supply which is soldered straight to the board rather than using the conventional 3.5mm socket.

Using a test meter the Rock64 with all peripherals plugged in consumes about 10W. With the monitor it goes up to about 40W, so as expected it's actually the screen which takes most of the power.

For comparrisson when running the desktop in a more conventional way with a circa 2012 AMD CPU (before the TrustZone backdoor was added) takes about 200W of power in total, including the monitor. So running on an ARM board really does make a big difference in terms of compute per watt. The Rock64 is undoubtedly slower than the x86 AMD box, but not by all that much and I think some of the slowness is just because the wifi adapter is 2.4GHz only and doesn't use the 5GHz band.

There is also a down side. Armbian on the Rock64 uses a not yet upstreamed HDMI driver and 4K graphics acceleration might be proprietary although I'm not too sure about that. Anything 3D is sluggish, but since I'm not a gamer I don't really care about that. There's also no Tor browser for arm64, so I might see if I can fix that.

No Golden Era

An amusing blog post about the terrible condition of contemporary software. Admittedly there is a lot of badness and many challenges. But there never was a golden era.

They talk about how small Windows 95 was, implying that was some time in which Great Engineers performed Great Deeds. Being old enough, I could do a similar rant, but from the perspective of 1995. It would go something like:

Windows 95 is 30M!!! That's a ridiculous number of floppies. I have to schlep this tower of Pisa of floppies around to get the thing installed on different desktops. What were Microsoft thinking? Amiga Workbench was a single floppy. ONE. Uno. Ten years ago the BBC Micro booted in two seconds. Flip the power button, beep, command prompt. And all before you can sip your coffee. If you had a Viewsheet ROM you were productive within 5 seconds. Windows 95 is like 60 seconds or more. Sometimes a lot more. What is it even doing with that time? I don't need fancy true type fonts. It's just superfluous fluff. And this OLE thing is a total disaster and never seems to work as expected. It's a cludge on top of a cludge.

If you could go back further in time to the beginning of Unix then you'd also find Thompson and Ritchie running out of disk space and clumsily moving their operating system files into the home directory on another disk. If you could ask them they'd probably explain that this was a terrible hack and that they would get around to fixing it later. 40+ years later the hack is still there.

So no matter what computing era you are in there are always problems, it's just the particular type of problems which change. From some people's perspective there was always a golden era ten or more years ago, but really that's just cherry picking, or remembering the good points but forgetting about the bad ones. The main thing is to just keep plugging away at fixing the broken things. Hopefully some day Electron apps will be a thing of the past, and language package managers will either no longer break horribly or be replaced by something more reliable.

Website Icons

A few tweaks have been made to the index page of the website.

Image description

Information about the mesh version now has its own icon and the Patreon icon has been removed so that there are two rows of four icons. The icons have also been made not so overwhelmingly gigantic. This makes the site look better on a small mobile screen in portrait orientation. The Patreon link has been moved into the FAQ.

Muted words

It's still experimental and not very well tested but I've been adding a new feature to the blocking screen of Freedombone which allows for messages containing certain words or phrases to be blocked. Twitter has this feature and calls it "muted words" and there's a similar capability within the Pleroma interface.

As an example, maybe I don't want to see anything containing the phrase "Black Friday" or "blockchain". There has been so much blockchain hype in the last year that posts on the topic are just another eye-rolling event.

I'm also expecting that as the fediverse becomes more popular that it will also become more adversarial with a greater amount of spammy posts. This type of word based blocking, combined with the existing domain/address blocking might help to mitigate that.

Emacs Workflow

Listening to the first episode of the LibreLounge podcast among many other things they describe their Emacs workflow using org-mode. I also do things in a similar way, so on the obscure off-chance that anyone is even the slightest bit interested in how I do it, it goes as follows:

My main editor for most things, especially "getting things done" type tasks is of course Emacs. I use org-mode for notes and also org-agenda as a TODO list. My Emacs configuration is a bulky menagerie of assorted modules and I started out with Sasha Chua's configuration from Github in about 2012 and then heavily modified it, removing some things and adding a bunch of other things. Maintaining this can turn into a yak shaving exercise, but fortunately I rarely reinstall Emacs these days since I'm typically using an Arch based desktop distro.

I have a personal git repo stored on the server which contains my org-agenda files and notes. Synchronization is just a matter of committing on one system and then pulling the changes on another. That might sound complicated compared to something like Syncthing, but in practice it's not much of an issue and avoids the type of conflicting situations described in the podcast.

On first running Emacs it shows my personal index page which is an org-mode document with embedded links to notes, cheat sheets, bookmarks and the current TODO list. Most commandline stuff I do within Emacs using eshell. I use git mostly from the commandline, but occasionally with magit to list commit history for repos or individual files. I also use golden ratio mode so that buffers change size automatically.

I did email within Emacs at one time, using Mew, but now I mostly use Mutt or the Freedombone webmail, which is a customized squirrelmail. Mutt is hard to beat for speed and simplicity, and has good GPG integration. Also logging in to the server via ssh or using webmail to read email avoids the need to expose any IMAP port and so reduces attack surface.

I've been an Emacs user since about 2010. Prior to that I mostly used gedit with its various plugins. I did try versions of Emacs in the more distant past - particularly MicroEmacs - but didn't use it as my main editor.