This is supposed to be a starting point to clarify a design “philosophy”, a systemic methodology. To create general principles that guide design, preventing pitfalls and not losing the forest for the trees. One needs to have both knowledge of technical minutiae when designing, and also have a general, consistent, mature outlook that guides the overarching tendency of their design; to not get lost trying to optimise for arbitrary measures for their own sake, but to always be faithfully in service of the human intended to use it, delivering them to their own ends. Concepts like “minimalism”, “simplicity”, “speed”, etc. are not inherent moral virtues to strive for, but means to an end; this is what needs to be clarified.
First, we ought to take a step back and understand the nature of the tools we use. A tool is both means and end,1 and it is of no matter if the end product is “ideal” (as opposed to concrete) in nature, like a text, for example. It is treated primarily as means, because its consumption is characterised by the creation of another product, not consumption by its annihilation. Its usefulness is thus characterised by how well it can achieve the task at hand; any and all other considerations are secondary if not superfluous to this primary aim. This doesn't exclude aesthetic considerations – as ease and satisfaction of use is always an aim for any tool – but I argue that a tool that does its job well, and seamlessly, is precisely what beauty and perfection are. As Saint-Exupéry states beautifully:
In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away, when a body has been stripped down to its nakedness. […]
There was a time when a flyer sat at the centre of a complicated works. Flight set us factory problems. The indicators that oscillated on the instrument panel warned us of a thousand dangers. But in the machine of today we forget that motors are whirring: the motor, finally, has come to fulfil its function, which is to whirr as a heart beats—and we give no thought to the beating of our heart. Thus, precisely because it is perfect the machine dissembles its own existence instead of forcing itself upon our notice.
And thus, also, the realities of nature resume their pride of place. It is not with metal that the pilot is in contact. Contrary to the vulgar illusion, it is thanks to the metal, and by virtue of it, that the pilot rediscovers nature. As I have already said, the machine does not isolate man from the great problems of nature but plunges him more deeply into them.—Antoine de Saint-Exupéry, Wind, Sand and Stars
This is, fundamentally, the case for simplicity, for “minimalism”. It is not out of concern for the machine that we intend to minimise its usage – unlike some ascetics who prostrate themselves before minimalism as abstract ideal, punishing themselves with constraints for no apparent reason but vain, divorced from any practical considerations. But precisely because the less a tool is “substantial”, the more empty space can be occupied by the task to be accomplished:
Thirty spokes
Share one hub.
Adapt the nothing therein to the purpose in hand, and you will have the use of the cart.
Kneed clay in order to make a vessel. Adapt the nothing therein to the purpose in hand, and you will have the use of the vessel.
Cut out doors and windows in order to make a room. Adapt the nothing therein to the purpose in hand, and you will have the use of the room.
Thus what we gain is Something, yet it is by virtue of Nothing that this can be put to use.—Tao Te Ching
Poetic; without adopting it as a life philosophy, I certainly find it a perceptive insight into good design philosophy. The less intrusive elements a tool presents, the less conscious a user is of it, the more intuitive. A keyboard, for example, allows the user to completely forget the keyboard's existence and immerse themselves in the text completely, granted that they have learnt to touch type.
Here, we hit a sort of wall, however. A physical instrument is concrete, a medium between Man and Nature. But we have reached a point where we have created instruments of interacting not with Nature, but with a system, with an abstraction, to organise thoughts, ideas, consciousness. You cannot have “less” since you are creating an abstract world, de novo. This is what requires the most intense investigation, a gap I intend to cover.
Although I intend to be the foremost proponent of progress, it is also unwise to waste past labour, rather than incorporate it. Some systems are truly so convoluted that they cease to be suitable for a refactor, and must really be replaced anew; but that carries its own risks. While a new system can avoid the explicitly identified pitfalls of its predecessor, it inevitably falls in what is taken for granted in the old; subtleties, hidden assumptions, and unconventional bugs that have been fixed can be lost in the new program, as not everything can be abstracted away from the old perfectly, but some information is necessarily lost when trying a new implementation – as well as completely new bugs being possible. Take for example a couple security bugs that were found in sudo-rs. Despite Rust fundamentally protecting against more or less all kinds of memory related vulnerabilities, the fact that the program was written anew means it is prone to bugs not found in the previous program, which is oftentimes not an acceptable risk. Being in production is itself testing time, and the older a program is, the more testing time is incorporated in it, the more mature the program is, and the more reliable, generally speaking.
Older technologies have a lot of human material – i.e. documentation – that enables efficient and ingenious – and ingenuity is fundamentally an organic process – exploitation of mechanistic, inorganic processes at intense speeds. Leading paradigms, like the POSIX model, are certainly far from ideal (technology has changed much since then, and the “everything is a file” paradigm clearly does not hold up in real life, like sockets for example), but a balance is to be had between theoretical perfection and practical adoptability. No doubt, operating systems and human-interface research is something I intend to understand and is necessary for more effective organic-inorganic symbiosis – after all, to the majority of humans, computers and their workings appear to them as an alien, imposing force rather than an intellectually exploitable resource, which ought to be remedied; the fault is in the program, and not the human. But existing and widespread technologies have a lot of capital “inertia”, so to speak, preventing replacement and necessitating backwards compatibility, making impossible an exploration of “optimal” symbiosis, under this mode of production and distribution, at the very least. Thus, one has to adapt; and the POSIX model strikes that balance for me.
With that as context, as a method of approach, here is my own tech stack, and the reasoning associated.
OpenBSD running on a Raspberry Pi 4 for all my services, which I happened to have lying around so used it, rather than picking it out in particular. Its small size and power is advantageous, especially considering how light my processes are, and the low traffic I get.
OpenBSD is essentially ideal, or the pinnacle of *NIX, at the very least: very simple, easy to understand, well documented. Thus far, it is the only system I have been comfortable to use with no external resources, thus no networking. I am thoroughly confident I can use only its documentation for all intended purposes (taking only bugs as an exception). Disadvantages: less capital behind it so less features and speed, most notably filesystem, although there is a better one in the works, which shows great hope (GEFS). Incidentally, it happens to be developed for 9front first and foremost, with porting in process.
After failing to make a DAS in a sufficient and economically justifiable manner, I opted to just buy a motherboard with SATA ports to make a NAS directly. Initially, I planned to migrate everything to the new server for maximum size and power efficiency. However, when weighing my options, OpenBSD seemed very ill suited for a NAS. Its filesystem is comparatively primitive, and RAID is not exactly sufficient to cover for its flaws. ZFS seemed amazing, and runs natively on FreeBSD. Unlike Linux, FreeBSD has no distros so benefits from having only one centralised documentation, forum, etc., making it easier to navigate. ZFS also can only run through some modules on Linux due to licensing issues, so it seemed like less of a hassle to just run FreeBSD directly.
I opted to keep the OpenBSD server since it was already set up perfectly, and because I did not want to learn how to make all these services again with potential issues on a different OS, with how satisfying and simple OpenBSD is. Besides, it is generally good practice to keep NAS and services separate, and two machines can create redundancy (i.e. for e-mail, which I have yet to do, but should).
On the desktop, I use Linux. My distro of choice is Artix Linux, which is essentially Arch Linux but without systemd as its init. I use OpenRC, and the choice was done rather arbitrarily years ago, because I found systemd more counterintuitive and buggy whenever I used it. Likely, it solves problems that are more relevant for large scale servers, but I have no experience there so can't speak about advantages or disadvantages in that regard. For me personally, a simple init system makes sense for my equally simple needs.
I don't use a BSD on the desktop mainly for compatibility purposes; although more complex and with more quirks, Linux runs Windows software required for school, work and play more consistently. It has the broadest hardware support at full performance, and is open source. Moreover, I am running a mainstream, well-established distro (Artix only makes minimal adjustments to Arch; otherwise essentially undifferentiable) so benefit from reliability and guarantee that the distro won't die, and that I am not dependent on them for configuration, etc. but take software as is. Really, the only distros, with minor exceptions, people should be using are Debian/Devuan, Arch/Artix, and Fedora, as all others are derivative – although this is a very opinionated take. Additionally, all *NIXes share POSIX; for any scripts I make, ensuring they are POSIX compliant means switching between one and the other OS based on use case is fairly simple. For example, I ran OpenBSD as my desktop for a year or so in the past, but switching back to Linux for software compatibility was very frictionless. My desktop/laptop are also not as mission critical as a server, and since I am constantly using it, adapting to changes – i.e. lack of reliability – is easy, whereas for a server I only maintain a few hours a year, reliability is of tantamount importance so that I don't get lost.
Plan9/9front is extremely interesting despite knowing little about it, but it presents exactly that kind of architectural shift that allows more efficient and highly usable interfaces. Every process can have its own namespace, and this paradigm is applied consistently, unlike UNIX's “everything is a file”. This allows processes hitherto unthinkable, such as running processes on different machines – with different architectures! – seamlessly, as if they are running on one and the same machine, simply by changing the namespace of a single process. This requires further study.
Clearly, I lack the in-depth knowledge for authoritative judgements, and I aim to remedy that by making intentional reading of design philosophy, especially with regards to systems design; Donald Norman seems interesting in that regard, and am keeping him in mind.
“Although a use-value emerges from the labour process, in the form of a product, other use-values, products of previous labour, enter into it as means of production. The same use-value is both the product of a previous process, and a means of production in a later process. Products are therefore not only results of labour, but also its essential conditions.” —Marx, Capital↩︎