Mobile computing can be a pain, especially when done in uncomfortable positions, on downsized and/or underpowered hardware, possibly in a noisy environment and while being distracted. Unsuitable conditions can also make it much harder to focus on computing-related activities. Yet a mobile computer is often better than nothing, and a comfortable workplace is not always available exactly where you want or need it to be.
These are my notes on dealing with mobile computers over time: mostly the software for underpowered computers with poor input and output capabilities, focusing on Linux-based systems.
I've been stuck with an old netbook (Intel Atom, 1 GB of main memory) for a couple of weeks, so wrote down some of the things I've learned. That's on Debian stable (Stretch was just released; using it with "non-free" repositories to get GNU documentation), with i3 window manager, and using Emacs for most of the tasks.
Wi-Fi is one of the most important things to set. This time,
both
wpa_cli and wicd claimed that the password is
wrong, but nmtui (NetworkManager TUI) has connected just
fine – though maybe it has messed up some settings for others somehow.
Wicd was hogging resources even while not doing anything useful, as Python
programs tend to do, so I've disabled it – it rarely worked
anyway. wpa_supplicant writes log messages such as "result=4"
and doesn't document those codes in its man page, requiring source code to
see what's going on. And NetworkManager just repeats those.
Firefox just starts for 30-40 seconds, and then lags even without JS. I gave up on it, and switched to w3m (emacs-w3m); web services such as online banking don't work with it, but it is keyboard-friendly, generally works, and does not lag too much. To use DDG for search, one should customize w3m-search-default-engine.
As for maps, there is FoxtrotGPS – an OpenStreetMap client that can cache and pre-download maps. It's pretty lightweight and usable.
For video playback, VLC appears to be more reliable than mplayer, even though has its issues (including bloating, lack of documentation, and resource hogging even while idle). Unfortunately, many videos are not available via bittorrent, being only hosted on youtube.com or similar websites; youtube-dl works to extract those.
One of the painful tasks to perform without a mouse is to copy and paste things between a terminal emulator and other programs (such as GUI Emacs). Actually it's somewhat awkward with a mouse, but even worse without it. Well, Emacs-to-terminal-emulator is easy: there are M-w to copy from Emacs and shift + insert to paste into a TE. Copying from a TE can be done by selecting with a touchpad, and then M-: (mouse-yank-primary (point)) RET in Emacs, though it won't work to insert into a TE; but turns out that one can emulate the middle mouse button by pressing the two touchpad keys simultaneously. It's not great, but works; perhaps a nicer way is to use a terminal multiplexer functionality for that, though then one may have to use nested terminal multiplexers, if they are also using those remotely. Or one could use an Emacs TE instead of a separate one, but that could also get awkward.
Speaking of terminal multiplexers: even though normally I'm not
using tmux, it is more useful to run remotely with
an unstable connection: a remote persistent session partially
compensates for the lack of a persistent connection and/or local
session.
Doing Haskell programming would be a pain on a netbook because
the REPL and cabal would require too much of
resources, so I've planned to use a remote server for that: just
run both Emacs and a REPL process there. Didn't have to do that
in those two weeks though.
xpdf, mupdf, and zathura are relatively lightweight and portable PDF viewers. Xpdf has ugly GUI buttons and a mostly useless left pane that takes space, others use partially qwerty-oriented (vi-style) key bindings (while I'm using Colemak), and the scrolling is quite messy in both mupdf and zathura (in mupdf, there's no way to tell whether you're at the end of a page or not, but scrolling by a little amount would jump a page if you're at the end; zathura may skip a line when scrolling with spacebar). Both xpdf and mupdf allow to adjust colors, zathura doesn't. So I've used both mupdf and zathura, but then discovered Emacs pdf-tools; didn't try it on a netbook, but it works nicely on a desktop: the colors are adjustable, keyboard-friendly, no notable issues like those with scrolling in others.
Bittorrent clients are not so nice to set and use: both rTorrent and
Transmission (transmission-daemon with transmission-cli) have broken Emacs
interfaces, which I gave up on after brief attempts to debug, since using
a netbook doesn't make debugging more fun. Transmission is nicer in that
it uses a daemon, which is more suitable for a program like that. To
simplify authentication, one should either use netrc
(.authinfo.gpg), or disable authentication and only allow
local connections:
"rpc-authentication-required": false, "rpc-bind-address": "127.0.0.1",
Then it's not so bad to control
with transmission-remote: -a and
-w options to add a torrent and write files into a
specified path, -l to list tasks, etc. The
Transmission IRC channel (#transmission at Freenode/Libera.chat)
is quite helpful, and minor bugs get fixed quickly there.
The situation with music players is pretty similar. I've tried
mpd multiple times before, and it never worked, but worked this
time (well, after mpc update); mpc is usable to
control it, even if not that fancy (i.e., plain CLI). There are
some Emacs packages: emms supports mpd, but tries
to handle all kinds of players, so the support is not so
great; bongo seems to have nicer UI, but doesn't
support mpd at all; mingus appears to work, but it
refreshes its whole buffer all the time, resulting in annoying
blinking and rendering it unusable. And there
is ncmpc, which is fine;
though ncmpc-lyrics has a lot of dependencies,
including Ruby. Music playback seems to be one of the most CPU
intensive tasks in a system with relatively little bloat.
The rest of my regular software is keyboard-oriented and lightweight: mu4e with mbsync for mail, circe/erc/rcirc for IRC, bitlbee and circe (later rexmpp) for XMPP, org-mode for notes and things like that, and other Emacs-based and CLI/TUI tools.
Later, in 2023, I have installed Debian 12.2 with Xfce on it. It takes almost 600 MB of main memory, leaving 400 for work.
During the unfortunate events in Russia in the early 2022, I decided to finally get a tablet computer while they are still available here and while I can afford one. At first I've looked into ones supported by LineageOS, but those were rather old ones, so I went for a model that is newer, and possibly can be supported later -- Samsung Galaxy Tab A8. I don't have much to compare it to (only used one Android phone out of similar devices, and just as a phone, for calls), but it appears to work and to be a tablet.
Samsung groups the awkward software required to be installed by the local government into the "law" group, so it's easy to remove it all at once. Avoiding Google and Samsung account creation, and aiming its usage as both a general household appliance (maybe for use in the kitchen, to read in bed, etc) and a useful device in an isolated wasteland if/when desktop computers will break and have no replacement, I've set F-Droid by downloading its APK, and then installed most of the software from it (though occasionally with APKs from their official websites too): OsmAnd for maps (including offline ones, from OSM); KOReader (as I use on an e-ink reader), Librera, OpenDocument Reader, and Kiwix to read things; VLC as a music and video player; Fennec (a Firefox version available from F-Droid); Sketches for basic sketching; Notes for note taking; a couple of fancier calculators with graphing; Conversations as an XMPP client; the Wikipedia client out of curiosity, but it turned out to be handy. Also Synthesia to try it out with a MIDI keyboard, which mostly worked, but that's proprietary. Termux provides plenty of regular GNU/Linux system functionality, including Emacs in its repositories.
I hear that ThinkPad laptops are nice for Linux, but they are expensive; Dell and Lenovo ones are commonly suggested for Linux-based systems too. Here is one of the articles on the topic, linking more: On modern laptop requirements.
I've picked a relatively inexpensive Dell Vostro 3515, which seems suitable for non-gaming tasks and inexpensive: a 15.6-inch display, plastic, no discrete graphics card, Ryzen 5 3450U and 8 GB of main memory (2 of those are used as video memory, leaving about 6 for the rest of the system), 512 GB SSD, and a 8P8C/Ethernet port (many laptops don't have those anymore), in addition to the common set of I/O ports.
To boot from an USB stick with a Debian 11 installer, I tried to
add it in the boot options in the UEFI menu, but that was rather
confusing: it asked to choose an exact .efi file,
and then failed with a "Something has gone seriously wrong:
shim_init() failed" message. Apparently that's common on
laptops, with different Linux distributions and laptop vendors,
but I haven't found descriptions of any working solutions,
except for installing an older version first. What worked for me
is just to choose a different .efi file, and then
hold F12 during the boot to enter a boot menu, selecting the USB
stick from it.
I'm always uncertain about the size of a boot partition (and
sometimes about that of the ESP partition too), and how exactly
to set encryption (e.g., apparently one can encrypt even the
boot partition while using grub, but it doesn't seem that
useful, and would lead to double password prompts). And about
the swap partition too: usually just disabling it, but perhaps
it's more useful on a laptop, and it's commonly suggested to
use. I've settled on about 500 MB for ESP
(/boot/efi), 500 MB for /boot,
encrypted swap and ext4 root partition (/), without
a separate /home. Then tried Debian's guided
partitoning, and it did exactly that (after selecting use of
encryption and of a single partition), so I just went with
it. Though as of 2024, some recommend 1 GB or 2 GB
for /boot, with Ubuntu apparently defaulting to
almost 2 GB, and it is likely to be a pain to change later in
such a setup, without reinstalling everything.
In this case it was a Debian Xfce Live version, with non-free software and documentation (just as for the Debian 11 workstation). It is nice and almost everything works well out of the box, though DPI tends to be wrong on laptops: it is 96 by default, while laptop screens have something closer to 144. That can be adjusted in the "Appearance" settings, the "Fonts" tab. I have also adjusted the touchpad behaviour.
In 2023, after hardly any use, the laptop ceased to charge the
battery (it is on the "pending-charge" status all the time, even
at 0% charge, with any UEFI charging settings), unclear why. I
have not found a way to fix it so far. Also attempts to update
the UEFI/BIOS firmware via "BIOS flash update" lead to an
"invalid file" error. Some suggest to run it from FreeDOS, but
it relies on BIOS, and the laptop appears to only support UEFI
boot. Another option is Windows (possibly the live and
lightweight version, Windows PE), though microsoft.com bans
Russian addresses from downloading it, and bans hoster addresses
where proxies are hosted as well, as of 2023 (while dell.com
also refuses to serve requests from Russian addresses, but
proxies work with it). Plenty of images on The Pirate Bay (which
is blocked in Russia, but at least does not refuse to serve
requests coming from non-residential addresses, so proxies work)
though. I managed to install Windows ADK on a Windows 10
machine, then to prepare a Windows PE USB stick from it. Had to
add firmware files into the "media" directory (actually added
into a few locations, initially failing to find any), then to
run diskpart.exe and its rescan
command to find the firmware (I think it was on disk C). The
firmware complained that "The AC adapter and battery must be
plugged in before the system bios can be flashed", had to run it
with /forceit option. Then it seemed to be working,
but got stuck on "update progress: completed". I ended up
resetting the laptop, then it complained that "battery pack is
removed or less than 10%". I turned it off, unplugged the cable,
plugged it back again, and the charging LED finally stayed
on. Waited for half an hour, turned it on, it ran the BIOS
(UEFI) and EC update process again, but then rebooted itself. It
forgot where the boot media is, I pointed it manually to a
Debian's .efi file again. Then it booted and was
charging. Better to look for laptops with a sane firmware update
process.
I acquired a Google Pixel 6a (not exported here officially, so
without a warranty, and no spare parts available; but at least
not certified in Russia, so no mandatory malware installed on
it), which has a plain Android system, and is supported by most
of the alternative Android distributions. The software to set on
it is similar to that on a tablet: F-Droid (with Guardian
Project repositories), then Conversations, ConnectBot, OsmAnd+
(with OSM carto style, and 150% text size), Wikipedia, VLC,
Fennec (+ uBlock Origin, noscript, HTTPS everywhere), Tor
Browser (with a bridge set manually), Notes, Librera, Yaaic,
Termux (with Emacs on it, as well as openssh and rsync, and
allowing it access to storage, so that pictures and other files
can be transferred over SSH with rsync: for instance, to
synchronize the pictures -- rsync -av -e 'ssh -p 8022'
--exclude='.trashed-*' user@host:storage/dcim/OpenCamera/
~/Pictures/OpenCamera/). Later I added strongSwan (to
connect to a home network as a "road warrior") and baresip
(though still mostly using Conversations for calls), Just
Another Workout Timer, Open Camera, WiFiAnalyzer, Kiwix, Aegis
Authenticator, a couple of games (Shattered Pixel Dungeon,
Mindustry).
The camera on this phone appears to produce rather bleak (washed out, desaturated) pictures, which is particularly apparent after enabling raw (DNG) picture writing. There are multiple ways to saturate it in darktable, but "tone curve" with independent CIELAB channels in particular is handy and versatile; the "denoise" module then helps to get rid of the produced noise. Perhaps one may also change the input color profile: colors look almost fine with sRGB instead of the embedded one; apparently it is a common problem with Pixel phones, see "Colours washed out from Pixel 7 DNG".
Kobo devices are supported by Koreader, among a few others. Apparently both Kobo and reMarkable are suitable for running Linux and custom software on them; see "E-ink is so Retropunk".
Some devices, particularly infrequently used and mostly stationary ones, such as radio receivers, may be awkward to power: batteries may be wasteful for stationary ones, and inconvenient to keep in a usable state for infrequently used devices, while inbuilt cheap AC-to-DC converters are unreliable and occasionally humming, and mimicking batteries with external AC-to-DC converters is tricky (they tend to provide higher voltages than 1.5 V of common batteries, and connecting those snugly would be tricky). A good option is to pick devices relying on external AC-to-DC converters, as laptops, phones, and e-readers do: it is usable for both direct usage and battery recharging, and battery chargers can be very simple, not adding complexity; many devices use USB for DC power input these days.