GOPHERSPACE.DE - P H O X Y
gophering on aussies.space
AN XCELLENT IDEA

No I haven't made another spelling mistake in the title of a post. 
Today I'm talking about X, or X11, or the X Window System, or is it 
the X Windowing System, or X Windows System, no that sounds too 
Microsoft... Well you know, Xorg, or X.Org, or XFree86, or Xming, 
or...

OK, OK, just as long as the system itself isn't as confusing as 
what name to call it... [peeks into the source code] JESUS CHRIST!

Well alright, so long as you don't look under the hood or, you 
know, actually try to write software that deals with it directly, 
it's pretty nice from a user perspective. In fact a lot of that 
complexity in code is to allow for the flexibility of a 
client-server architecture that actually allows software running on 
one computer to display a window on another connected via TCP. Very 
handy back in the 80s when it was written, back when giving lots of 
people computers able to run graphical software was prohibitively 
expensive compared to the cost of just buying one mainframe and a 
fleet of dedicated X terminals.

Of course nowadays anyone sane probably just has their X clients 
(the applications they're running) talking to an X server on the 
same machine, little thought of until one day it fails to start at 
boot-up. But what I've realised is that in this largely ignored 
capability might be the solution to my long-term headaches 
connected with software updates.

To explain these headaches, I'll start with news on a long running 
saga that I've been complaining about since this phlog first went 
online. I had a final go at getting OpenSSH to compile in the 
configuration that I wanted, this time after studying forum threads 
from people who had similar problems (clearly this is something 
that the developers are in no rush to fix). Armed with a few more 
additions to my mile-long ./configure line, I finally got it to 
find the OpenSSL library and build the Makefile. But then gcc 
couldn't find OpenSSL. I was out of time and well and truely out of 
patience, so even though there was clearly a path to follow from 
there, I refused to take it.

I'd ruled out alternative SSH clients such as Dropbear and Lsh 
because just as important as shell access is SFTP for uploading to 
my sites like Free Thoughts (though I have discovered that shell 
access to aussies.space is actually more bareable over my slow 
connection with SSH compression enabled (-C), so composing things 
on the remote server isn't entirely out of the question anymore), 
and the other projects didn't include an SFTP client. But then I 
discovered that PuTTY, a popular open-source SSH and 
anything-else-terminal client for Windows, which I already had 
installed on my old Windows XP PC, is available for Linux too, and 
it includes an SFTP client! I downloaded the source and, without 
needing any separate encryption library, it compiled without a 
hitch. Plink is actually the command-line version of the terminal 
client program and uses many of the same commands as OpenSSH's 
client, while psftp is the command-line SFTP client. The graphical 
PuTTY can be built too, and uses GTK, but allows you the choice of 
building against GTK 1, 2, or 3! Why does one never get such choice 
when building popular software for Linux?! Sure, sure it might be a 
pain to maintain, but geeze it would make my life easier if 
everyone respected compatibility like that.

Anyway this has been a good example of the sort of troubles that 
I'm having keeping my computers set up the way _I_ like, often 
using outdated hardware because I like to stick with what works 
(and I can't afford to buy the latest anyway), while maintaining 
access to the internet. It's especially the case now that 
everyone's going encryption-nuts and requiring things like HTTPS 
everywhere even though I don't have a personal need for it most of 
the time, and those who do can use things like the HTTPS Everwhere 
browser add-on. With the web specifically, of course there's also 
the nightmare of Javascript and the corresponding need to run ever 
more bloated web browsers in order to access many parts of the web. 
It recently became impossible to browse YouTube with Javascript 
disabled, even just to find video links to download with 
youtube-dl. Plenty of other sites had gone that way already of 
course.

As I mentioned in a previous post, "The Need for New" (oh boy, 
almost four months and I still haven't got the new laptop set up), 
updating internet software (especially things like Firefox that 
update regularly and aren't practical to compile myself) leads to 
updating the OS, which leads to breaking compatibility with other 
software that I want to use (unless diving in to more difficult 
compiling and patching), and breaking compatibility with hardware 
that is no longer supported, or now has bugs in the drivers, or is 
just less efficient so needs more processing power, or RAM, or disk 
space. I don't need all that if I just want to edit text files, 
compile software, listen to tracker modules, draw diagrams, write 
documents, view and edit photos, design electronics, play old 
computer games, record myself humming, etc. For all that I've got 
my computers working how I like them and that's as far as things 
need to go. It's for one reason that I'm expected to throw all of 
that neat arrangement into complete disorder and rebuild it 
according to the ways of the moment. That reason is accessing the 
internet.

So, back to X, a system that's been mercifully static for at least 
a couple of decades now, and available for pretty much any Linux 
distro new and old, as well as for Windows if you install it. The 
answer to my troubles (maybe) is to install all of the internet 
software that I use on one headless modern (but cheap) computer 
connected to my LAN, and run that internet software with the 
display on my old outdated systems, via telnet for terminal 
software, and X for the more difficult things like Firefox. Then I 
have only one system to keep up to date, only one set of internet 
software to keep updating on it, and also only one configuration to 
keep set up how I like (an important consideration given that 
there's a lot that I like to change in Firefox's about:config). 
It's also a solution for sharing bookmarks over multiple machines 
(I know there are a lot of answers for that, but none that I 
managed to stick with personally so far).

I'm not saying this is all that radical or clever, it's what X was 
designed for after all, but it does involve a bit of planning and 
the details have been bogging me down a lot more than I expected so 
far.

Just a warning: from now on this will be a bit more of a log than a 
readable writeup because I'm still working on this and undecided 
about how, or whether, it will work. On the other hand that's the 
only reason why I'm devoting the time to writing this, because I've 
ended up with tons of vague dot-point notes scribbled down on paper 
and I need to condense my thoughts somewhere or else I'm likely to 
get lost. It might as well be more chow for the hungry Gopher.

First off, a list of internet software that I would want to run on 
the "internet client" computer. Note that this is only including 
stuff that's likely to become obsolete (not inc. Gopher or NNTP for 
example), though _ideally_ I should install that too and block 
direct internet access from other computers on my LAN for increased 
security given that their OSs will have known security 
vulnerabilities because they don't get updated much / at all.

* ---WEB BROWSERS--- - This is the main thing, and Firefox in 
particular. Chromium too if I can't avoid it.
* POP,IMAP,SMTP - technically it's alright if the Mail User Agent 
software runs on the other computers, but mail is received and sent 
by the internet client.
* SSH
* SFTP and FTPS
* Gemini browsers
* Downloaders, eg. Wget and Curl (also youtube-dl). - Need to wrap 
these in a script on the other computers so that eg. wget -o 
/somewhere/file has wget on the internet client stream the 
downloaded data over the terminal connection and write that to the 
file on the local machine. Otherwise lots of scripts might break.

That last one touches on the issue of dealing with saving downloads 
to fine in general. As it is I mostly already subscribe to the web 
browser convention of saving to a "downloads" directory and sorting 
them out from there. All I need is to set up NFS so that a 
downloads (and uploads for SFTP) directory on the internet client 
is accessible from all other computers on the LAN. But then there's 
the problem of file formats. Standards like PDF, for example, keep 
changing and I've already had trouble compiling newer versions of 
PDF viewers. Such changes are completely needless in my opinion, 
and if there was any logic in the world we'd be using Djvu format 
anyway, but that's the internet for you. The same goes for video 
and audio formats, and even old reliable image formats are 
apparantly under threat with new alternatives for JPEG being pushed 
by the likes of Apple and Google. Then there are Microsoft Office 
documents, but I'm mostly in a position to tell anyone who'se 
likely to send me one of them to either convert it to RTF, or PDF, 
or HTML, or get stuffed.

So I really want software on the internet client that can convert 
these horrible modern formats to something that I know and love, 
ideally running from a script that finds and converts them 
automatically.

* Image converters - Image Magick should be up to date enough for 
this, I hope.
* Audio converters - Maybe also a player rigged up to some buttons 
so that I can use the internet client as a little music box? Or is 
this needless feature creep... Well playing streaming audio would 
be complicated if it didn't have speakers.
* Video converters
* PDF converters
* Microsoft Office document converters

One other thing is that I need to have all of my printers on the 
network, so that I can print web pages from the internet client. 
Again nothing radical, but a pain to set up because so far I've 
worked on the logic that USB (or LPT) connected printers are fine, 
after all you need to be next to the printer to grab the paper it 
prints anyway.

Yes and speaking of hardware hassles, it's time to look at what 
computer I'd actually use for the internet client. Well jumping 
straight to my (first) conclusion, The Raspberry Pi 4. Poor as I 
claim I am, I can let $100 (Pis are more expensive in Australia - 
pissed me off when I heard about the $5 Pi Zero and then paid a 
little over $10, seems to be a bit more than just the exchange rate 
difference going on) go towards one of these without losing much 
sleep. Besides being cheap to buy, it should use a lot less power 
than a full PC, which is important given that such power would be 
in addition to that used by the PC I'm accessing it from.

But I've got a laptop, and on rare occasions I actually take it out 
of the house. What if I want to access the internet from it while 
I'm away from home where my LAN is? I could SSH in over the 
internet and use X port forwarding (ssh/plink -X option) I 
suppose...

Experiment time (well a few weeks/months ago actually, but I'm 
trying to make this exciting)!

I don't think the idea of tildes is really about running X, but 
nevertheless aussies.space does have the Xlib library installed 
(though not the development headers) and I found one lonely X 
program on its (I'm pretty sure virtual) hard disk:

$ xev &

Whoopie. A little box in a window and a whole lot of logged info in 
the terminal. Xev is actually just a debugging program, but it 
proved the point. Except it actually took ages after running the 
command for it to appear, and it doesn't really do anything so it's 
hard to gauge responsiveness. Turning SSH compression on helped get 
it to start up much faster (at this point I realised that it made 
everything faster, but it seems to be especially the case with X 
port forwarding), but I needed a real program to test properly.

The easy way would be to compile an X program as a static binary, 
then just copy it over to aussies.space. But all of the PCs that I 
use are still 32bit and aussies.space is x86_64. So I copied 
various Xlib library files over from my computer and wrestled them 
into makefiles until gcc was finally satisfied. Whereafter it built 
for me the timeless image viewer "xv", and the probably fairly 
forgotten game Xinvaders 3D (which uses Xlib's line drawing 
commands rather than bitmaps, so it wouldn't have as much 
information to transmit as other games). I set the permissions so 
that anyone on aussies.space should be able to run them too:

$ /home/freet/bin/xv &
$ /home/freet/bin/xinv3d &

As for the result, well xv takes a few seconds to refresh even a 
small image after moving the window, and Xinvaders 3D is just about 
playable but very laggy. There's no way that browsing websites in 
Firefox would be practical this way. Of course that's my slow 
internet connection, I haven't been to anyone with fast (wired) 
internet for ages due to the virus (as I'm in the only Australian 
state where it's really got away, but death and economic ruin isn't 
important enough to warrant a phlog post on that compared to 
configuring an unusual software environment), but the point is that 
I'd be connecting to the internet client at home, so this is the 
sort of performance I'd expect doing that.

I did configure xv so that it's now used for viewing images in both 
Lynx and ELinks though. ELinks was a real bugger to configure for 
this without any examples to copy, by the way (this post is already 
too long, but ask and I can share the config. I ended up with).

So with that option ruled out, the next one is to take the internet 
client with me instead of leaving it as home. But then I've got to 
set that up as well as the laptop, and it won't be bettery powered 
unless I build a battery supply for it, and that's to much trouble. 
What I want is to be able to power it from the laptop, but a Pi4 
would draw too much current. But a Raspberry Pi Zero W doesn't! It 
peaks at a little over 300mA, which is fine for USB. Plus it 
supports a USB "On The Go" mode where you can actually plug it into 
a USB port and it emulates a USB network adapter connected to 
itself. There are even boards on Ebay that allow you to solder on a 
USB-A Male connector. Raspberry Pi OS (no longer called Raspbian) 
is compatible with both the Pi Zero and the Pi 4. So when I leave 
the house I just have to pull the SD card out of the Pi4, put it in 
the Pi0w, then later stick the Pi0w into the laptop, a network 
connection is set up between them, then I configure the Pi0w wifi 
and use all the internet software on it like I do on the Pi4 at 
home. Great!

Now sure the Pi0 with a 1GHz ARM processor and 512MB of RAM isn't 
much of a performer these days. But my current laptop (the one that 
I still haven't got around to upgrading) is a 1GHz Pentium III with 
768MB RAM, and it runs Firefox at a mostly bareable pace with my 
configuration that disables as much junk as possible from both the 
browser and the sites that it browses. For the rare times that I 
want to browse the web away from home, it should suffice.

So yesterday (yeah things move slowly on this) I tried that out on 
the Pi0w that I had already. If all went well I'd set it up fully 
then buy a Pi4 to boost performance into the modern era. Mostly it 
did go well, but Firefox didn't.

First off, I did experiment earlier accessing Dillo running on the 
Pi0w over SSH with X port forwarding on my LAN. It was pretty laggy 
and the sshd process on the Pi was eating more than 50% of CPU time 
while scrolling around a page. Useless encryption again - nobody is 
snooping on my LAN (if they were close enough to do so, I'd see 
them). There's a simple HOWTO at TLDP that covers the basics of 
setting remote X windows up properly, and there's not much to it:
http://www.tldp.org/HOWTO/Remote-X-Apps.html

Having removed "-nolisten tcp" from my xserverrc and allowed the pi 
with xhost, Dillo could connect directly without any SSH nonsense, 
and it was quite responsive enough for my needs, while CPU usage on 
the Pi0 now only peaked at about 3% while scrolling around a 
webpage wildly. Good, now on to Firefox. I was running the current 
Raspberry Pi OS "lite", and a mountain of dependencies needed to be 
installed for Firefox, all up almost 900MB of space taken up! 
Anyway, it installed, so I ran:

$ firefox-esr &

"Illegal instruction"

Hmm...

Well the Raspberry Pi OS package archive will install Firefox on a 
Pi0, but not a binary that's compatible with the Pi0. The story is 
roughly that the Pi0 CPU implements the ARMv6 architecture, with 
certain additions for hardware floating point operations (and maybe 
more besides). Later models of "big boy" Pis after the Pi2 are 
based on ARMv7 CPUs which all have hardware floating point. Debian 
supports ARMv6 (but assuming no hardware floating point support) 
with the "armel" target, and ARMv7 with the "armhf" target. 
Raspberry Pi OS is apparantly built for ARMv6 with hardware 
floating point, which they then call "armhf" and should be 
compatible with both ARMv6 and ARMv7 Pis while still using the 
hardware floating point features for maximum performance (for some 
things, web browsing not really being the first that comes to 
mind). Therefore you'd expect that all Raspberry Pi OS packages 
should run on the Pi0.

https://wiki.debian.org/RaspberryPi#Raspberry_Pi_issues

The truth of the matter is that they're probably copying the 
Firefox-esr package from Debian armhf (the Debian armel Firefox-esr 
version is way out of date (v. 60.9.0esr) for some (frustrating) 
reason). As such it uses ARMv7 instructions, which don't work on an 
ARMv6 Pi0. Bloody bastards!

If they can't be bothered keeping the Firefox package working on 
the Pi0 with the official Linux distro (which I didn't want to use 
anyway due to Systemd), there's not much hope of any other distros 
doing so. Firefox being the most significant motivator for setting 
up this internet client system, this basically rules out the Pi0w 
as a hardware option.

But (sorry folks, this will just keep going on, my software 
projects tend to go this way), there's more to Pi than Raspberry 
(come on advertising agencies, there's talent going to waste 
here!), and indeed there is a whole world of Raspberry Pi clones 
and alternatives. Not quite so much for the Pi Zero, but there is 
the Banana Pi Zero:
http://wiki.banana-pi.org/Banana_Pi_BPI-M2_ZERO

Faster RAM, quad-core, USB OTG, and ARMv7 (or at least armhf binary 
compatible - that's all that I bothered to note down)! But enabling 
USB OTG seems to require recompiling the kernel, and it's not clear 
if the same kernel would work for a Pi4, and finding a distro for 
it without Systemd will probably be hard, and nobody seems to have 
measured the actual current draw so I can't tell if it can be USB 
powered. Sigh.

Then while grumbling about this in my sleep last night I remembered 
that the Atomic Pi, which is an x86_64 board that is apparantly 
actually New Old Stock from a failed robot vacuum cleaner product, 
bought by some mob who made an I/O board for it and slapped on a 
"Pi" brand. With postage to Australia they're more expensive than a 
Pi4, while offering similar, if not worse, performance from what I 
can tell. But if I get my "new" laptop set up, it is x86_64. So 
when leaving home I could take the SD card out of the Atomic Pi 
internet client, then wrangle the laptop's BIOS, or failing that 
Grub and a copy of the kernel on the HDD, to boot from the SD. It 
would mean that I would have to choose between booting into the 
internet client OS or the laptop OS with all of the non-internet 
software, but again I only rarely want to access the internet away 
from home so that inconvenience shouldn't be very great.

Though as it's basically a one-off, it's not clear whether an 
equivalent cheap, low-power, x86_64 board will be available to 
upgrade to later when Firefox and the web becomes even more bloated 
(the thought of what that might look like hardly bares 
contemplation). Also, by needing modern Firefox to run on the 
laptop, that means that the laptop hardware will keep needing to be 
upgraded over time as well, which is one of the things I was trying 
to get away from by isolating the internet software.

Another option might be to use the Pi4, then emulate it in QEMU on 
the laptop, ideally keeping the whole client-server thing working 
(though the internet client's internet would be via the laptop's 
OS). Unless QEMU's emulation performance is really really good 
though, I strugle to imagine this running fast enough for Firefox 
to be usable, at least on the old laptop that I'll be upgrading to. 
Also even more so than the Atomic Pi option, this will cause 
pressure to upgrade the laptop later on (if not immediately).

https://wiki.debian.org/RaspberryPi/qemu-user-static

Yep, as usual with these things there's no good option. I was 
kind-of hoping that it would look better with everything spelt out 
in text. But no, since Firefox on the Pi0 turned out to be a lie 
I'm not sure if I like any of the other paths that are left to 
take. Or maybe carrying around a battery-powered Pi4 along with a 
laptop wouldn't be so bad after all...

Hmm, two posts in a row that don't reach a conclusion, I must be 
dealing with too much personal stuff here lately.

 - The Free Thinker.