flexibeast.space - gemlog - 2020-09-06
On ‘bloat’ and ‘minimalism’
By the way, 'em' stands for 'editor for mortals' — I christened it that after Ken Thompson visited our lab at QMC while I was developing it and said something like: "Yeah, I've seen editors like that, but I don't feel a need for them, I don't want to see the state of the file when I'm editing."
— George Coulouris
Everything should be made as simple as possible, but not simpler
— Possible paraphrase of Albert Einstein
This is a rather long post, as it's been something i've been wanting to get off my chest for a while.
Something i've noticed since becoming involved with the Void Linux community is that a number of Void users are virulently opposed to ‘bloat’.
It should go without saying that ‘bloat’ is a very subjective concept, but it appears that it does need to be said: ‘Bloat’ is a very subjective concept. As i once wrote on r/voidlinux, one person's ‘bloat’ is another person's ‘essential feature’. i do wonder how many of the people with a fanatical anti-devotion to The Bloat use a line editor instead of some visual editor - if a line editor was good enough for Ken Thompson, surely it should be good enough for the 177t h4x0r5 seeking minimalist purity.
In particular, the notion that True Minimalism is stridently opposed to configuration files, and that people should configure software by manually modifying source code (possibly via patches) seems .... excessive. Particularly when people try to apply multiple patches without really understanding how patches work: that patches don't necessarily apply cleanly across source revisions, and that they don't necessarily compose without conflicts. But it seems users are happy to be convinced that wanting to be able to change the font size in an application (for whatever reason, including vision impairment) without recompiling is like wanting a unicorn/pony hybrid.
Minimalist fanaticism has gotten so out of hand that even Dylan Araps, the creator of KISS Linux:
and someone who can hardly be said to be against minimalism, created this excellent snark:
“A super fast and extremely minimal shell prompt”
Void is a ‘minimalist’ Linux distro in the sense that the base system is relatively small; running:
$ xbps-query -Rx base-voidstrap --fulldeptree | wc -l
currently returns “95” for the number of packages it pulls in, whilst running:
$ xbps-query -s '' | wc -l
on a fresh install from the latest base-system ISO returns “142”.
Yet at least one member of the Void team uses KDE; at least a couple of other members use GNOME. i personally use i3, which basically gets out of my way and eases the management of my workspace, even though - quelle horreur! - it allows configuration files. i'm here in geminispace, so i clearly feel there's something to be said for systems which facilitate being able to focus much more on content than on form, on simplicity rather than on feature-maximisation. But at the same time, i strongly agree with making things “as simple as possible, but not simpler”.
In the last couple of years, two tech things have resulted in me feeling excitement rather than cynicism: Void Linux, and now Gemini. In both instances, the excitement comes from discovering a system which is well thought-out and quite straightforward, but which doesn't actively put blocks in the way of end-users being able to customise things for their particular use-cases[a]. Gemtext is a simple and elegant format, yet also:
- makes it easy to link to content accessible via other protocols, particularly non-HTTP protocols; and
- provides markup which allows end-user configuration of how it's presented.
i use elpher, which allows me to customise how Gemini content is displayed; and GUI clients such as Kristall provide an nice UI for configuring presentation of Gemini content.
It might be argued that Gemini actually does create blocks, in that it actively minimises how extensible it is. But Gemini makes it easy to link to content outside of geminispace, without requiring direct support from the gemini protocol itself. Gemini could be ‘extended’ in the form of a new protocol - say, ‘Apollo’ ;-) - which provides the additional functionality, without any changes needing to be made to the Gemini standard.
This is the sort of minimalism i appreciate. :-)
☙
☙
[a] By default, Void uses runit for init and service supervision/management, but it's been fairly easy - albeit with the help of some friendly and knowledgeable people - for me to switch to using 66, a wrapper around s6/s6-rc.