I chose TWM because it’s the simplest desktop environment and has one of the smallest footprints if not the smallest. On a machine such as the Raspberry Pi 3 with its fixed memory size of 1GB (which is hard-wired into the card and can’t be upgraded, not even with a plugin extension), what the RP3 (and all its predecessors) required of their human programmers was an understanding of its limitations helping to choose the best applications to run on the card. Ever since I bought and powered up the first generation, I’ve always sought software that demanded as little resources as possible, especially memory. TWM, of all the DEs I’m familiar with, demands the smallest memory footprint of all. The screen shot above, the one I used in an earlier post, ran overnight for 14 hours, with the three xterms on the desktop, and top (or htop in this instance) running in one of the windows.

Looking at the upper left corner of the htop terminal, you’ll note that only a fraction of the .9GB (out of 1GBl; remember that part of this is shared and used by the GPU). You should also note that swap hasn’t been touched. In all other distributions and versions I’ve used in the past, some sort of cron job would kick off or the DE would make much more demands of the memory. To be honest I’m not sure that swap is enabled here; after looking at the screen capture I need to go check that. Regardless, the memory footprint of the OS and DE are quite small after 14 hours, something for an embedded computer I’m quite appreciative off.

And this brings up a final point. Eventually I want to tuck this computer into a corner somewhere and not worry about it. Not forget about it, but get it to the point where I don’t have to worry that it’s run out of memory and swap and locked up horribly. I can reach that goal with a custom executive or other non-Linux runtime, but that costs hard cash up front as well as on-going royalties. That’s not a problem if you’re creating a commercial product in which a computer is just an out-of-sight appliance. But for someone such as myself, with no resources, I need to carefully choreograph all of this to create something that I could sell with a clear conscious. I also want to point out that this is not a general purpose computer that would require something like Raspian, that might run Libre Office (and a lot of other applications that are in that distributions). TWM is little more than a light-weight xterm manager, if you will. I could not even install all the X packages to support TWM and just live within the seven virtual logins provided by the ALT function keys, something I did for a number of years when Linux was first released. The DE for my use is thus a means to an end, not an end unto itself, and it doesn’t need all the fancy features that all other contemporary DEs have accumulated over the years. TWM is just fine for my purposes.

I spent some time this evening running the Raspberry Pi 3 (referred to as RP3 from here on out) through some paces, starting with bringing up the i2c interface. I’d done this early on with the original Raspberry Pi a little over two years ago using the Arch Linux distribution. I followed those directions but with Raspbian as the target distribution, and I failed to enable the i2c buss.

Rather than spend an inordinate amount of time trying to debug Raspian I grabbed the second of my 32BG Samsung micro SDHC cards and following the directions on the Arch Linux | ARM wiki, I created a bootable Arch Linux card and brought up the RP3 under Arch Linux for ARM. The current page for the RP3 instructions states up front this is the older 32-bit ARM release. Because this is a bare-bones distribution compared to Raspbian, the RP3 needed to be hard wired into my network in order to update the distribution as well as install additional packages, such as support for WiFi. I should note that it was simple to install Arch Linux WiFi support, and when it was installed, it enabled the RP3’s internal WiFi network. Once that was up and running I pulled the network cable and carried on.

I installed the same packages for the RP3 as I did for the original Raspberry Pi, and when I went back to reboot it, I didn’t see the i2c buss. I did a little digging and discovered I had to edit the /boot/config.txt file on the RP3, making the following changes to the file:

• uncomment device_tree_param=i2c_arm=on
• uncomment device_tree_param=i2s=on
• uncomment device_tree_param=spi=on

With those three lines uncommented and with the necessary drivers installed from the earlier packages /dev/i2c-1 was finally enabled.

I should note that the same Arch Linux ARM micro SDHC card boots both the RP2 as well as the RP3.

I should also note that I needed to fix how the Apple aluminum keyboard worked as I documented here.

Because the RP3 requires more power than any other Raspberry Pi to date (5v at 2.5A), I’m using an Apple 12W USB power adapter. I’ve got more than a few around the house these days, and their output is rock solid and clean. So far it runs the bare bones system without anything else attached.

Next steps will be to install X and TWM. Or I just might use the seven virtual keyboards that work now (one of the benefits of a properly configured Apple keyboard).

I’m trying to move as fast as I can to catch back up to where I was back in 2014. I’m working towards an IoT framework around Arch Linux with baked-in encryption. For real this time.

And maybe, just maybe, add a dash of some of the CoreOS features that have caught my fancy. A lot has happened these past two years, and I have a lot of serious catching up to do.