sgl.md

I propose the creation of yet another GNU/Linux distro, to be called SneakernetGnuLinux (SGL).

The goal of this project is to distribute the Linux operating system in a form that maximizes the level of usability that is possible on the less privileged side of the digital divide.

The system, as ititially configured at install time, should be tuned with some (user-selectable) combination of the following assumptions:

• That the target user does not have Internet access at all
• That the target computer is "air gapped"
• That availability of Internet connections will be intermittent or otherwise unreliable
• That connections, once made, are likely to be lost after a short time
• That available Internet connections will be slow; perhaps painfully slow

Some particulars:

Image distribution

Obviously distribution by snail mail should be on the short list of distribution modes, and perhaps should be the official default. The image size should be either less than two gigabytes, or available as multiple files less than 2GB in size. This is because for people without "wireline" Internet access likely available venues for download may be flash drives (usually FAT formatted) used at a public library, or downloads on cell phones (some of which have higher data caps for traffic initiated by mobile apps than for traffic associated with the tethering or hot spot features of a phone.

System update and maintenance

I'm assuming a Debian rather than RPM/YUM type repository only because that's what I'm most familiar with. If there's some reason to believe the other (or another) brand is better suited to the mission of SGL, please do explain!

A typical use case for someone who relies on a public library computer or other Internet-connected computer to which they have access, but not on demand, and possibly not soon, might go as follows:

1. User inserts a flash drive
2. System maintenance utility copies contents of /var/lib/dpkg and /etc/apt/sources.list onto this drive (hopefully they will fit).
3. Also copied onto the removable volume would be Windows, OSX or (probably 32-bit) Linux executables of a program which can
4. Parse the files status and available in the dpkg directory
5. Connect to whatever software repository is appropriate for SGL.
6. Fetch whatever files would be fetched by sudo apt-get update and sudo apt-get upgrade on the SGL system back at home, if only it could
7. Fetch whatever files would be fetched by sudo apt-get install ... if there are any software installation requests in the user's "to do" list.
8. Generate a Linux shell script which will dpkg -i the retrieved .deb files, in dependency-tree-appropriate order.

Since some people's main/only source of Internet access is a cell phone, a mobile app for processing the system update sequence might also be nice.

Web request/response cycle

One of the most important ways in which a fresh installation of SGL would differ from those of most distros would be in default settings having to do with networking timeouts. Basically timeouts should be maxed out. There should be a minimum of giving up on a network operation just because it hasn't completed after 1 second, one week, one decade, etc. There should of course be some way of clearing pending operations, but the overall design philosophy should be to err on the side of retaining unfulfilled requests as pending.

Web browsers

Don't know whether there is any mechanism to include browser settings in an initial OS install configuration. If not, perhaps an unbranded build of a browser is in order? If there is, I'd like to have it tweak default browser settings to effect:

• Maximum use of caching of downloaded files
• Minimum use of page-reload features (or anti-features, as the case may be).
• Browser settings, if there are any, that instruct the browser to assume that one bird in the hand is worth some random number in the bush. Assume the user would rather view a cached page that we definitely have than a possibly more up-to-date version that we might be able to have. Please don't refresh the page just because I made some tab active, etc.
• Make the initial OS install come with at least one reputable download manager included among pre-installed browser extensions. Don't assume downloads will come in one piece. Never hesitate to make use of the "Range" header.

Mobile apps for routing browser requests from tethered SGL PC's through phone's Internet connection

This probably violates the terms of service and should not be included in our distro.

Other applications

Web "to do" lists

This is something I practiced during the mid-aughts during a period of several years of no residential Internet access. What I did then is arrive at the library with a flash drive (it was once a stack of floppies, actually). On this flash drive was

• an HTML file called webtodo.html
• the DOS/Windows version of wget, from a package called UnxUtils i.e. the file wget.exe
• a script called webtodo.bat which largely consisted of a command such as:

.\wget -e robots=off -r -H -l2 .\webtodo.html -p -T30 -t5 -o webtodo.txt

The -l2`` command switch means "recurse 2 levels deep." The local file webtodo.htmlitself is level 0, the URLs it links to are level 1 and the URLs they link to are level 2. Going 3 levels deep, of course would have been massive overkill and, combined with therobots=off` command switch, terrible netiquette.

Support system for processing to do lists on other operating systems

There should be a utility included in SGL which writes onto a removable drive a script that performs a sequence of actions similar to the above. This software should surpport Windows, or whatever operating environment is likely to be on the library computer. It should be basically "open and go."

Synchronization with other devices

Mobile device synchronization

Many of the problems associated with keeping calendars, contacts and the like synchronized between devices is merge conflicts or the equivalent. Unfortunately, Evolution, one of the open-source community's leading providers of calendar/contacts/email type software, is particular immobilized by such discrepancies.

Cloud services are a nice idea in theory, and solve some but not all of the synchronization problems, but probably nothing defines the digital divide more than cloud services, which are based on the explicit assumption that users have reliable, on-demand Internet connectivity, and even high-bandwidth, high-or-no-cap connectivity in the case of "cloud storage" or "cloud backup."

Cloud services

If we remove the assumption that cloud interactions should happen in a timely manner, there's no reason we can't interface SGL with cloud services. Naturally it will be the rule rather than the exception that the system state includes a large number of pending operations. It also means that cloud operations are included in our "to do" list awaiting an opportunity to access the Internet. Support for cloud services should of course prioritize (I would go so far as to say exclusively support) nonproprietary platforms such as CalDAV and CardDAV.