Terminal boredom, or how to go on with life when less is indeed less
Table of Contents
If the "medium is the message," then the message of low-bandwidth timesharing is "blah." 1
The "benefits" of minimalist computing have not been realised. The benefits its espousers mention include small programs and accessibility. For example, the Gemini protocol is supposed to provide high "power to weight" and many claim that reducing everything to text makes for a better reading experience; but in reality it has created large codebases, many in the one to ten thousand lines of code range, and can be quantifiably observed to make expression incredibly difficult. As well as lacking any basis in program design, computing minimalism can only fake any basis in any ecological concerns or any ecology movement.
Social ecology for suckers
One paper we encountered discusses the terms used in less-is-less computing,2 at least informing us that it hides under phrases such as liberatory technology, appropriate technology. But no one appears to understand these terms. I am fairly well versed with social ecology so I will focus on the appropriation of liberatory technology.
"Human scale" is a euphemism for "nothing"
First, there is a fetishism for "small" technology, whatever the fuck that is meant to mean - we will later describe why smaller protocols end up with more complexity. But people seem to like small things, they call them "smol", they probably think those things are cute even; the most blatant of counter-arguments is to attack the connotations of the adjective "small" itself:
Terms like "large," "small," or "intermediate," and "hard," "soft," or "mellow" are simply externals — the attributes of phenomena or things rather than their essentials. They may help us determine their dimensions and weights, but they do not explain the immanent qualities of technics, particularly as they relate to society. 3
Indeed a "small" technology is just that. It is not necessarily "good", "useful", "liberatory" or so on.
We will later argue that such minimalism also makes communication very difficult, as it favours reduction to remain "minimal" rather than changing to allow for better self-expression. Even Towards a Liberatory Technology, which was cited by the paper,4 suggests that more should be achieved with simpler techniques:
The importance of machines with this kind of operational range can hardly be overestimated. They make it possible to produce a large variety of products in a single plant.
So already it is established that social ecologists favour multi-purpose machines (and surely protocols and designs and so on).
And social ecologists rather prefer to support "human" relations:
Small is not enough. What is human is what counts, not just what is small. What is beautiful are people, what is beautiful is the ecosystems and their integrity in which we live.
One is perfectly capable of arguing that anything a human does "is human", and so everything is human and so the term is irrelevant. But the statement as a whole emphasises the individuality and capability rather than a vague notion of size or "simplicity". By reducing the degrees of freedom in a medium of communication, we deemphasise the individuality its users.
Futurism ± 50 years
Furthermore, social ecology offers us a term for describing movements which attempt to change things while retaining some axioms of the present which make it impossible to change. This term is futurism and again we are given a blunt example of it:
Most futurists start out with the idea, "you got a shopping mall, what do you do then?" Well, the first question to be asked is, "why the hell do you have a shopping mall?" 5
But our identification of a futurist streak in less-is-less is not the formation of stupid questions; rather, it is in dodging good questions, such as "How do you design powerful systems to be comprehensible by small groups and individuals", by effectively answering "You can't, and so I never wanted them anyway!" The premise established, that powerful systems must be too complex to be comprehensible to individuals, is at least futurist, would we not have any ideas of how to design powerful systems now. But such ideas already exist, and so it is worse than merely futurist! The whole concept is based on notions that haven't been true for decades. Of course, the people involved have set themselves in an era of computing where they just got over learning structured programming, but barely past that it has been obvious how to design powerful but small systems.
Philosophical questions aside, what are the implications of powerless systems?
The perversions of minimalism
"Accessibility" with crossed fingers behind your back
It is said that, by reducing the means of presentation to mere text, Gemini is much more accessible than, say, the Web. This claim is pure bullshit - by reducing the structures that can be created, documents are much harder to read.
For example, Drew DeVault's "How I choose a license" guide shows off literally an exponential blowup in the effort required to read a document.
The main part of the page is a decision diagram, which looks something like
The page instead represents this diagram as a list of states, and transitions leading to terminal states (like "Use AGPLv3") and leading to non-terminal states (like "GOTO 8"). To find the next state, one has to linearly scan down the page to find the line starting with the number.
Credit where it is due: as the decisions don't form cycles, DeVault was clever enough to ensure that every transition only goes further down the page. But from an algorithmic point of view, a linear search is pretty terrible; and the worst possible decision diagram which only asks the user \(n\) questions could have up to \(2^{n+1} - 1\) states, leaving the user to scroll for a very long time.
I figure that the "solution" is to separate the document into multiple documents, one document per state, so that each state could actually link to the next states. But this is arguably a violation of the so-called sensibility of Gemini, where one "document" has been split into multiple requests.
Another solution would be for the client to have a sufficiently good
search tool. In this case, we would only need to be able to find a
string like 4: but otherwise we may find false positives, say, if a
more conventional list number format like 2. were used, the 2. in
Apache 2.0 would likely be a false positive. (And, before someone
asks, it is probably not acceptable for the user to have to know any
regular expression syntax to only match a 2. at the start of a
line.)
What exactly is "minimal"?
Further analysis of what a good interface for a decision diagram would eventually suggest that there is, in fact, no clear line between a bad and bloated "Web application", and a good and small "digital document", so we better shut up about it before no one reads the rest of this article.
But another another solution would be to hack a client to understand
some kind of anchoring, like <a name> does for HTML. However,
such an extension would not be well received. DeVault going full
Torvalds mode while complaining about a simple client extension makes
for another good piece of discussion. The gist of the issue was that
one Gemini client would send off a request for a favicon character,
which serves a similar purpose to a favicon picture on the Web. His
fire-eyed appearance is based on an appeal to a supposed minimalism,
of course:
The golden rule of Gemini is: do not extend the spec.
This is the only means we have of self regulation. I'll ask nicely first but ultimately I'll do what I have to in order to preserve Gemini's simplicity and utility as a small internet protocol.
Do not. Extend. Gemini.
Period.
The opinion of some appears to be that any exploitable surface that one could consider making an extension with must be met with fire. While I will later regret using the term, the Gemini protocol uses a blatantly Orwellian approach to avoiding extension, even at the cost of useful features. The Gemini FAQ answers why there is nowhere to include a content length in a response:
To minimise the risk of Gemini slowly mutating into something more web-like, it was decided to include one and exactly one piece of information in the response header for successful requests. Including two pieces of information with a specified delimiter would provide a very obvious path for later adding a third piece - just use the same delimiter again.
But this begs the question: what extensions are considered to be any good by others? What extensions does a good client implement? I don't know if there is a good answer for either,6 but I suppose it is somewhat reasonable to ask: how much more complex is a client which implements all these things? The Gemini FAQ espouses ease of implementation:
A client comfortable for daily use which implements every single protocol feature should be a feasible weekend programming project for a single developer.
Experiments suggest that a very basic interactive client takes more like a minimum of 100 lines of code, and a comfortable fit and moderate feature completeness need more like 200 lines.
These statements could well be only for the core protocol, and not any extensions. Is a good client with all the extensions that one wants even in the same ballpark? Perhaps we should check. A convenient list of clients was provided which I counted up the lines of code for. The first on the list is Candor:
[hayley tmp]$ git clone https://git.sr.ht/~julienxx/castor
Cloning into 'castor'...
remote: Enumerating objects: 789, done.
remote: Total 789 (delta 0), reused 0 (delta 0), pack-reused 789
Receiving objects: 100% (789/789), 223.09 KiB | 282.00 KiB/s, done.
Resolving deltas: 100% (519/519), done.
[hayley tmp]$ cd castor/
[hayley castor]$ cloc .
34 text files.
34 unique files.
6 files ignored.
github.com/AlDanial/cloc v 1.90 T=0.02 s (1380.6 files/s, 178434.4 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
Rust 24 359 28 2694
Glade 1 0 1 215
SVG 1 1 1 212
Markdown 1 46 0 100
TOML 1 3 1 31
make 1 10 16 30
-------------------------------------------------------------------------------
SUM: 29 419 47 3282
-------------------------------------------------------------------------------
I make bad estimations, but I don't make estimations that are fifteen times off! Of course, this client also implements the Gopher and Finger protocols, and it uses the evil, bloated and nice-looking Gtk+ toolkit rather than a smol and painful terminal interface, so I better pick another client. Why not the author's own AV-98? It's even written in that high-level Python language, so surely there will be fewer lines of code:
------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- Python 2 166 272 1239 Markdown 1 14 0 48 ------------------------------------------------------------------------------- SUM: 3 180 272 1287 -------------------------------------------------------------------------------
BWAHAHAHAHAHA! What a fucking lie that "200 lines" figure turned out to be! But then we never checked out those extensions; I figure the first Amfora client has a few…
------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- Go 47 998 980 5809 TOML 13 193 710 516 Markdown 8 162 0 484 YAML 7 17 4 197 Python 1 28 10 73 make 1 9 1 32 Bourne Shell 3 8 0 25 ------------------------------------------------------------------------------- SUM: 80 1415 1705 7136 -------------------------------------------------------------------------------
Need I comment more?
How to go on
So we are faced with creating a simple system which does quite the opposite of the "simple" protocols and means of communication today. Such a system has to empower the user and actually provide capabilities for self-expression in many forms, while retaining some properties that prevent a computer from doing undesirable things. The following approach is only one approach, but we believe it is a fairly good approach which can cure terminal boredom.
To solve the apparently contradictory initial constraints, we need to introduce the concept of a meta-medium. A medium in this context is a technique for communicating an idea. A meta-medium is a technique for communicating a medium. It provides the axioms which an implementation of a medium be described with, and also provides some restraints because the axioms are designed to avoid some behaviours. Of course, the implementation is usually called a program.
Typically, the meta-medium for a computer is a combination of an operating system and a programming language. The operating system allows for running any machine code, which of course can compute whatever it pleases. Any operations with the outside world are mediated using an interface, which eventually tests the permissions of the program. The main issue is that these permissions are seldom restrained, such as in desktop operating systems, or they are too vague for our requirements, such as in mobile operating systems or hardened servers; so it is very unwise to run arbitrary programs that one doesn't trust. Permissions that would make such an idea much safer include, say, constraining a program to only be able to retrieve and not update remote data, to make it difficult to leak any data from the user, and to make any attempt at hijacking the resources of the user pointless.
This requirement suggests that there has to be another layer between the program and operating system, which is able to identify the kinds of messages, so that it is actually feasible to deny the capability of sending some kinds of messages. This layer, in both of our experiments, consists of a virtual machine which selectively provides capabilities to programs, and can limit the resources a program consumes. The virtual machine also provides a great improvement for the modularity of the system, as only the virtual machine has to be re-implemented in order to run the same programs on different computers. The implementor is only concerned with implementing the meta-medium, not with implementing any media, and so any media implemented effectively come for free.
As well as assigning appropriate limitations for what resources mediums may use, a medium should also be informed of what requirement the user has for how information is presented. Some people say that Gemini separates "content" and "presentation", and so the user has more control over the latter; but the presentation is forced to take a mostly linear, textual form, and the user has no control over that.
To achieve a real separation of content and presentation, information has to be stored in some sort of semantic format, with a program which will render out the information in various ways. These two requirements can be satisfied by the slots and methods of an object in a message-passing object system. An object system also provides a way of specifying protocols and composing programs, which a small-protocol world cannot offer.
We had some fun looking at lines of code counts, so I will present my own: the Netfarm object system and virtual machine consists of 4,272 lines of Lisp code, our networking substrate 3,748, the server and client another 2,343 lines, and a graphical client another 360 lines. All in all, that's 10,723 lines of code which does a hell of a lot more than displaying fake paper on your screen! And, of course, that figure includes good engineering things like unit and fuzz tests, and dubious engineering things like low-level optimization hacks, so you could get away with fewer lines if you didn't care for those.
Conclusion
The reader may have noticed that we never used the term "less-is-more", even if others have used it to describe either the reductive systems we mockingly have assigned the adjective "less-is-less" to, or the more powerful systems we have designed. The term is fundamentally a distraction; through hand-waving about "simplicity" and "human scaling" we accept the simplification of our own relations and thoughts, and so we find ourselves seemingly satisfied by a reductive technology.
Reductive technologists, despite the ideologies they desperately try to cling to, find themselves making an utter piss-take of such ideologies and the liberatory potentials that they suggest. Doesn't this closing statement sound a lot like the one at the end of "Ethical software" is (currently) a sad joke? (By the way, it still is.) I think they are both caused by the same phenomenon, where one direction throws a group to failure, so they go in the opposite direction without any critical thinking, and make a joke of themselves.
Only a few weeks ago I encountered a lovely piece called Nice Shit for Everybody, which seems to share our idea of maximalism rather than minimalism. And they find themselves with the same conclusion for other forms of minimalism:
If only it were so simple. […] This is pure reactionary thought. To run and do the opposite just because capitalism displays certain social features does not make one an anticapitalist. It makes you a petit-bourgeois bohemian.
It is not difficult to have nice shit on the Internet, nor is it difficult to ensure such shit respects the privacy and preferences for media to use of the user. Based on how much time has been wasted on making incremental changes to minimalist protocols, complaining about them, and then implementing arbitrary sets of them, it looks very easy in comparison to make a convenient meta-media to achieve our goals.
Footnotes:
Alan Kay and Adele Goldberg, Personal Dynamic Media
Murray Bookchin, The Ecology of Freedom
Laurent Bossavit's The Leprechauns of Software Engineering argues that "any author citing another paper should be required to provide proof that they a) possess a copy of that paper, b) have read that paper, c) have read the paper carefully." The easiest way to satisfy at least points A and B would be to quote TALT, but there is no such quote of course.
Murray Bookchin, The Ecology Movement: Utopia or Technocracy?
We have heard from private discussion that many more little wars have been fought over what to extend or what not to extend.