The reason I prefer the simplest of tools to address problems concerns not only aesthetics. These solutions tend to also be faster to deliver. They tend to be more flexible to adapt across an entire arena of tinkerers. They tend to be pluggable, yet not constrained by other solutions. And they tend to be resilient to unforeseen circumstances.
Let’s consider some cases.
Contents
A coffee
I tend to satisfy a coffee craving up to two to three times daily. Sometimes I resort to instant, which demands nothing but to pour boiling water over a teaspoon or two of the specially processed and condensed coffee grains. A minute of prep time, it’s something I appreciate at 5:30AM to facilitate a speedy transition to the daily journal. Commonly, however, I prefer the more glorifying experience of raw coffee grains.
Many rely on coffee or espresso machines. These take space, employ mechanics of varying complexity, can require occasional maintenance, cost anywhere from USD $10-500, and come with an instruction manual. In addition, the industry invented compound coffee-based cocktails, in addition to those little cylindrical, single-serving plastic coffee tubes.
Yet coffee has been consumed for centuries, far predating electricity or complex sweeteners. All it demands is boiling water and a drinking container. And unless you rely on an electric stove or electric tea pot, it need not even require electricity.
You simply incorporate the ground coffee beans into cold water, set over sufficiently low heat for 3-4 minutes, and once the water boils, slowly pour into a cup to limit the raw grains from entering. Alternatively, wait a couple of minutes to let them further settle before serving, or add a tiny bit of cold water to expedite the settling.
If, on the other hand, you prefer the pour-over method, you need no machine. Simply boil the water separately, then find any steel/plastic/paper filter.
If you grind your beans as I tend to, you need not even use an electric grinder. Manual designs exist (ie the ones with a spinning lever), which demand but slightly more effort.
You can employ these methods anywhere with the ability to boil water. There’s hardly maintenance aside from the disposal of the used coffee grounds. (Or leverage the grounds for horticultural/exfoliating/cleaning/cooking/incense purposes).
No specialized coffee machinery is ever necessary. And if you become accustomed to this basic preparation method, you will never depend on spare parts, malfunctioning, the supply of wasteful plastic coffee tubes, or even electricity. Prepare coffee in a forest over fire.
The toaster
How about a toaster. A convenient contraption, it manipulates one or more slices of fresh bread to produce the toasted variety in under a minute.
The mechanics tend to wear out and break down. The toaster consumes space, electricity, and costs money, which you may argue amortizes to much time savings across the expected lifetime.
But have we forgotten how to toast a slice of bread on a skillet?
This too should consume a few minutes with the skillet heated: no mechanical parts, electricity optional, only a quick soak necessary after the fact.
I don’t think the process adds any substantial prep time, having become a second-nature ritual. On the other hand, it eliminates unnecessary space-consuming gadgets for something so pre-ancestrally trivial.
(It wouldn’t surprise me to discover IoT-ready programmable, remotely activated toasters, but I dare not explore.)
We love to email. Well, maybe not love. Email is but a protocol. Only the group society labels as geeks or nerds experience such platonic love.
I respect a protocol. I admire a protocol for its simplicity, for its effectiveness, for its resilience to poor network conditions.
I admire it for the fashionable syntax, solid semantics, and acceptable timing, all cornerstone ingredients to any attractive protocol. And I most admire it for the longevity - the ability to survive the test of time.
The email protocol, dating back to the 70s, caters to that criteria. It facilitates what I indeed love: the ability to compose and direct unconstrained, asynchronous communication to the party of my choosing. Unconstrained, because one may produce long, romantic prose without the need for parchment, pen, ink, or parcel.
Alternatively, it facilitates terse, corporate interchange lacking subject headings, capitalization, words over four letters, and any certainty in passing the Turing test.
The protocol is asynchronous, as we place no strict technical expectations on the time of receipt nor reply, similar to a paper letter.
And though a paper letter allows the careful eye to gauge the authenticity of the sender by keen observation of the handwriting (and other detective clues), email enables security measures via key-pair encryption to insure not only the sender’s identity but the parcel confidentiality. Never mind the infrequent usage of these measures.
Email is simple to drive and maintain, with a 40-year history to solidify the reputation. Anyone may host an email server or leverage the thousands available. Anyone with an email address corresponding to an email server (the @domain portion of the address) may communicate with any other email user across the world - notwithstanding any potential filtering and blocking.
One may interface directly with the email server via a web interface, or by means of an alternate client through a retrieval protocol such as IMAP. One may also download the email for local storage by similar methods. Personally, I download and interact with my email offline via a series of Linux terminal apps, leveraging basic IMAP and SMTP (email sending) functions.
One need not feel attached to an email host or address. Further, the two need not depend on each other: a domain purchased and maintained at one registry may redirect to a completely different email host. If you grow wary of storing your email at one location, switch email hosts and redirect your address (by an MX record alteration in your DNS provider).
Likewise, if overspammed or feeling the itch for novelty, you may choose a different email address on the same host. You may even retain the same mailbox. Email enables these handy abstractions.
We thus see the flexibility to combine combine the address, the host, the retrieval, and the composition methods. Each, at least by nature, is entirely abstracted from the rest.
At some point, however, the abstractions became less clear under the influence of mega-corporate cloud solutions. I somewhat exaggerate, though over time casual email users lost sight of that inherent simplicity and elected to bundle their solutions into a not easily diffused compound.
The Gmail hosted solution arguably spans across the majority of email users today. Most personal (and many business) addresses I encounter belong to this domain.
That doesn’t even cover the cases of external domains that ultimately utilize Gmail as an email host, although those users already find themselves on firmer soil: an external domain grants the flexibility to transfer the email to another physical host with relative ease.
As for me, I see no reason to store all my mail on the Google servers, and especially with the corresponding domain, which you then have no flexibility to transition elsewhere.
Or be it any other dominant provider, over time, I grow skeptical of storing too much information within one too prevalent of an entity. This especially applies to the providers that mine data for questionable purposes.
Thousands of small to larger, free, and low-cost email providers exist. The paradox this may appear, I feel more comfortable leveraging a host out of a low-redundancy data center (or a basement of a 2-man sysop team), than a conglomerate, ultra-dominant cloud infrastructure.
Though subject to scrutiny, the extreme scenario intends to make a point. Having that extra local vulnerability causes me to employ backup measures and become more conscientious of the big picture.
I hold more trust in any sufficient small-scale solution than a giant of questionable ulterior motive and infinite ambition that transgresses my direct needs.
Not to mention the habituation and dependency the extra layers of elegance foster in a user. You begin to associate the otherwise simple, decades-old service with the brand, with the interface, with the domain. You begin to expect the otherwise unnecessary features, the tags, categories, labels, plugins, integrations, interface, themes, et cetera. Ask yourself, is all of this necessary?
Basic email providers enable the simple means to accomplish largely the same. Email already appropriates folders, filters for automatic processing and mail redirection, basic SPAM detection, security and address book functions, at the least. Each feature may not capture the absolute state of the art, but does that really matter?
Rather than rely on the number one spam filtering solution in the market, what concern is it to assume a bit less, and simply be mindful of how you publicise your address(es) to begin with?
I don’t mind the second-best solution, the third, or even the 17th. I can handle and even prefer a ruggeder interface which I would hardly use anyway, opting for offline tools and IMAP retrieval (conveniently producing yet an additional layer of backup).
Don’t create too much comfort by relying in one leading provider. It leads to fragility, should you desire change for whatever motive. Opt for more transparency, more control and more independence.
Summary: steps to regain email independence
With the most crucial steps listed first, following at least the first two will carry you a long way.
- Own email domain: freedom to transition from one host to another or self-host without altering your address.
- Use an alternate email host, not one of the leading giants.
- Offline tools over web browser interfaces, via IMAP retrieval. Ex: Thunderbird, Mutt.
- Store email offline via IMAP sync. Ex utilities: isync, offlineimap.
- Bonus 1: don’t require internet connectivity to manage or compose email.
- Bonus 2: Automatically gain an offline backup.
- Self-host your email (for advanced users).
The alarming cloud formations
Too long I’ve observed the trend of transitioning services into the cloud. Without strong necessity, many follow suit, outsourcing the task to someone who does it better.
But does the supposed ‘better’ warrant placing dependence in the cloud provider and a stable network connection? Do you even need the better for much of this ancient (and trivial) labor?
I would argue to the contrary. Rarely do you really need the cloud services - many carefully devised, packaged and sold, irrespective of consumer necessity.
Granted, capitalism couldn’t otherwise operate. But as an individual, you also bear a responsibility to yourself: to reason for yourself, to fend for yourself, to intelligently assess your needs, and to discern the real from the fiction.
Consider a basic calendar. You could outsource the function to the cloud, gaining convenient synchronization across multiple devices and the ability to share. The provider might even support external calendars, such as the important milestones in the history of Hogwarts or the German Bauhaus.
Speaking from 10 years of calendar history I’d offloaded from the cloud circa 2018, I found it substantially (and eerily) revealing, to the likes of a private journal. I now manage it exclusively offline.
Prior, I’d used a Linux command line utility calcurse, which stores entries in plain text, but since, I’d further simplified to a direct plain text document with an optional CLI interface.
Is synchronization that crucial to your case? Probably not. You can manage with one access point. Otherwise, leverage any of a myriad of alternate calendar solutions with CalDev support (the widespread calendar synchronization protocol). It need not be a major provider with a top of the art interface and malicious data mining habits.
Similar to email, I would sooner entrust an autistic basement hacker to host a server-side copy of my calendar.
However, if like me, you operate your calendar offline, having a back up is indeed important. Hence back it up from time to time! The solution need not be anything elaborate for a plain text document.
By being in control of these components (which implies rudimentary maintenance, not impulsive micromanagement), you won’t find yourself debilitated in case of a rare event.
Readable plain text is the most resilient data storage format you’ll encounter: no concern over extinct or legacy formats, incompatibility, or lack of support. I strongly recommend resorting to plain text mechanisms wherever possible, not strictly for your calendar.
I find the cloud document storage and synchronization solutions similarly over-engineered and unnecessary for most cases. For the end user, I suspect this started from the need to easily collaborate and share your documents with others.
I acknowledge this as an actual need to circumvent the grotesque tactic of emailing unfashionably large chunks of data back and forth. My sense of calm undergoes a severe strain upon the receipt of a 30MB email with three photographed selfies of 20 megapixels each.
Worse yet, major email providers actually deliver emails of this amplitude. So thanks to the document sharing solutions, casual users need not toss flash drives around, nor scp/ssh data to who-knows-what servers.
However, what started with the plainer document sharing, over time degenerated into storing a respectable portion of documents in the cloud: not encrypted (by you that is), and without strong motive to share or distribute. This, in the era of a 32Gb micro-SD card costing an equivalent of a glorified coffee with milk.
You could argue that cloud storage offers cosmic levels of redundancy, backup measures and security: possibly true, per some definition of security.
I’ve never pretended to be amateurishly versed in security practices. However, the little I understand suggests that in the chain of cascading components, the weakest link breaks the chain. And the weakest link is rarely the 2048-bit AES encryption scheme. (Were you the one to generate that private key, offline?)
Concerning the redundancy, how much do you really need? Let’s suppose you store your data at N nodes, each carrying some low probability p of failure/data loss during some sufficiently discreet time interval. Assume independence of failure events: not necessarily a safe, but a plausible assumption, provided the N nodes are housed at varied nodes.
The odds of all failing simultaneously is p
For the record, I abandoned all SaaS (Software as a Service) storage/synchronization solutions for any but the most ephemeral of data, such as that warranting a quick share or transfer.
I still leverage a IaaS (Infrastructure as a Service) cloud solutions for housing sizable data of mostly multimedia content. As I travel a lot, carrying a physical backup on me would severely defy the point.
Most of such data I wouldn’t care to be revealed to the entire internet anyway, though for anything slightly more sensitive, I personally encrypt it, offline.
I could go on indefinitely on the superfluousness of many cloud services: images, music, notes, chat, office suites, etc. And similar reasoning usually applies - fragility, dependence, habituation, opaqueness, complexity.
Regards to the disk jockey
I’ve been listening to FM radio a lot. It only takes the discovery of one advertisement-light, eclectic and ambitious radio station to sustain a severe portion of my music listening urges. And I find the analog radio receiver preferable: small-scale, old technology, having survived the test of time.
The device operates on both AC and DC power. It immediately turns on: no delay, no buffering, no network connection constraints, no accounts or distractions, no caching hundreds of MB on disk or in RAM.
I can deal with the occasional static and electromagnetic interference, which, kept within bounds, I find as pleasurable as the LP screech.
A plain vanilla (:
At its core, chat carries out a similar function to email - the exchange of text: usually the terse and the cryptic intended for the regional dialectics. But we all comprehend the text smiley.
At some point the chat application with the greatest user base, at least across my travel destinations, became the Whatsapp messenger.
In many countries WA has become the de-facto communication standard, especially where mobile plans are known for SMS and voice plan restrictions. In many cases, WA has come to surpass cellular networks, email exchanges, or even other internet-based methods I find more plausible, a point I’ll shortly elaborate on.
For practical purposes, WA requires a smartphone/tablet device to function. Not only that, but it demands a device from one of the few leading manufacturers of this category.
I have low tolerance for such devices, and I’m not the only one. In fact, I heavily prefer to chat on the (stationary) computer.
Thus it follows that whatever low percentage of users I represent, in order to actively communicate with a respectable portion of mobile users across the world, we must use, or at least keep actively operational and maintain one such device.
The application imposes a closed protocol/API, a fixed interface and a very limited set of hardware: that is, the touch-screen smartphone, or rather, the 2% of design comprising 98% of the mobile phone market (considering 25+ years of relevant history) - all for the sake of chat.
I desist, and reiterate: on the surface, chat is not too distant from email, but for certain glorifying features and timing expectations.
There need not be a chat de facto application. With proper abstractions, the system decomposes into the protocol/API, the interface, and the underlying hardware, each layer interoperable with the rest.
XMPP
Let’s consider the old, but hardly obsolete XMPP chat protocol. It’s still used much across the corporate landscape and some specialized domains.
Major chat solutions, including the very WA, Facebook messenger, or whatever Google employs these days, (to the time of publication) leverage a closed variant of XMPP, which, alas, eliminates the major purpose - the openness and the flexibility to leverage any interface and hardware.
The main incentive behind the traditional XMPP protocol, however, lies behind the very distribution of powers - the Peer-To-Peer exchange - much like the email protocol.
Anyone may host an XMPP server. Anyone may leverage an XMPP account freely offered across myriads of open XMPP servers to communicate with any other XMPP user (one not behind a corporate firewall). An XMPP username even resembles an email address: user@domain. You see the similarity.
Naturally, there is not a notion of a de facto XMPP application/interface/hardware. Hundreds of desktop/mobile/web variants exist to chat over XMPP via any practically conceivable hardware. Likewise, being an open protocol, anyone may contribute a new client.
XMPP supports the same multimedia, group and voice interactions of WA/FB messengers, limited only to the interfacing application and server-enabled features.
XMPP facilitates an open chat ecosystem. WA imposes a closed ecosystem.
Other, not necessarily leading but prominent chat solutions exist with a smaller user base. Many, while not strictly open, relax some of the constraints WA imposes. Many lift the hardware restriction, allowing one to chat on more varied hardware, or even the desktop computer, without as much as a mobile phone in possession. Some even provide an open or semi-open API, enabling anyone to contribute a new client, though the server component might remain closed and opaque. It makes sense to evaluate each case individually, should you choose to pursue such a compromise.
IRC
I’ve rejoined the IRC (Internet Relay Chat) network for the first time since probably the year 2000. The user base and activity on IRC seems to have significantly declined, though it continues to live and be maintained.
IRC has too survived the test of time, around since 1988. Like XMPP, it’s a distributed protocol. No central entity issues directives - no single point of failure.
IRC resembles something of a wild west of redundant world-wide servers housing the user accounts and channels, each maintained by one or more operators (sheriffs).
Myriads of clients exist of varied interface and target hardware. Despite the antiquity, the openness, the lightweight protocol, and the largely text-oriented interaction makes IRC operate remarkably fast.
Regretfully, much of what I encounter on IRC caters more towards specialized groups one may consider nerds, geeks, extremists, gamers, hackers, and intellectuals: not so much for the casual user, or at least no longer.
Questions, comments? Connect.