Book review: ed Mastery

2023-04-15, post № 272

book-review, software, #ed

Depicted on the around eighty pages strong paperback ed Mastery [L18 [1]] is a grey-bearded Beastie in a study illuminated in a soft red. Sitting on a throne, eyes layed upon a lectern’s open book, Beastie smiles. When opened, one is greeted with three pages of justification for covering ed in this “bleak age” [L18, p. 3] we call ours. Though cheekily elitist in tone, it spells out this book’s intent to educate on one of the classics that make up a UNIX system.

In the next thirty pages, ed is seen in action. From core concepts of modes and addresses to commands and shell interaction, one is guided not just through what this editor can do but most importantly how it expects one to work with it. Being concise but not cryptic, it is at times as if one read the man page with someone by one’s side giving enough context to truly grok ed. As a basis for demonstrating editing functionality serves a poem in traditional UNIX-style text representation, the loose file format ed was designed to effectively manipulate, and later a ficticious, though humerous, list of chores and dreams.

Chapters five and six are dedicated to ed’s regular expression engine. Being a line-based editor, working with heterogenous or overly long lines is not a task ed excels at. Lamentably, Lucas does not address this weakness and gets carried away with an imprecise introduction of ed’s regular expressions exemplified by contrived examples followed by scatterbrained artificial workflows such as ASCII-underlining minutely and laboriously specified lines of text.

This low is only in parts resolved by the final six pages showing off ed’s power as a UNIX-universal scripting asset.

Unfortunately, ed Mastery was envisioned as an April Fools’ joke and appears not to be able to shed its provenance. Whilst ed’s historical significance and conceptual strengths in a world where metaphor sheer [S99 [2]] is an occurring phenomenon shimmer through at times, the work gets undermined by both said inception as buffoonery and its author’s play [L18b [3]] into LoPresti’s interpretation of a comedic take on computing [L91 [4]] as well as the drudgingly kept-alive so-called editor wars.

Nevertheless, ed Mastery is a joyous read. If one does not let typesetting inattentiveness dampen the mood and focuses oneself on the book’s title, one is left with a sincere and informative guide through ed’s facilities. Furthermore, as I understand it, Lucas in his works tries to represent a non-tribal, pragmatic approach to computing; with this in mind and thus avoiding identity-entanglement, room is left for a skin thick enough to cope with the mockery.

not oK

2023-03-18, post № 271

software, opinion, #software-blacklist, #kde, #konsole

Is it of note which bits are present, orchestrate this hunk of plastics? For on its own a paper weight of lighter statute, these are the breathed-in life it needs to tick. Thenceforth its way, its prowess, morals set in stone: their origins all along still people. People whose ideologies can clash.

Not two months ago, a coy note with regards to project hate has been published [1], yet some betrayal oh so deep truly does uncork my inner hatr:
A garden gnome ne’er, for years I did entrust Konsole to relay my actions in the digital realm. Dazed by glamour emanated through a single letter K, artlessly I never questioned if I indeed did not look at a smoke screen conceiling beliefs awry and craftsmanship missing.

It all innocently started when on my journeys as un internaute, I crossed paths with a KDE developer [2] and their plans to bloat Konsole out of proportion:
While the fanatic focus on the usager incompétent (cf. 265) itself did not phase me⸺as such is the sorry state of modern times’ reading of computing⸺the nigh conniving practice of not educating one’s pupils, not relieving them of their ignorance and thus crafting a test group exhibiting behaviour which underlines one’s argument, had me shook a little; for watching this explanation why Konsole eases use itself already empoweres enough not to be reliant on it.
Anyways⸺enough about the empty set⸺, what irked me truly were the speaker’s plans to stuff Konsole full of features, without a care in the world for project scope, implementability or security implications: an on-hover image preview for ls’ (however flavoured) output is neither what a fake glass teletype should be concerned with, nor is it⸺as they themself remark⸺possible to implement semantically correctly. Not every filesystem supports imperceptible stat(2) calls. More frighteningly still, it removes the only cautious way of viewing files in quarantine: when hd q.jpg one cannot dare for a mouse slip may incur an interpreted open, how is one to ever power on one’s own machine again? [3]
But, alas, in e-mail correspondance no interest was echoed, only resting on laurels, repeating how Konsole was the best there is.
Annoyed, I dug a wee bit deeper to find how far this madness had been allowed to spread to find in src/Screen.cpp a genuinely horrifying sight: “// This should never happen [...] Do not let this code go to a release.” [4] was botched in September of last year; and stayed there until now.

I had enough. My heart broken, I fled.

A few days later, with a working patchset [5] under my belt, I expunged all K from my digital life and began using st [6]. I have not looked back.

E-mails held hostage

2023-02-18, post № 270

software, freedom, #email

Joyous as my rose-minded, bit-loving self of a few years past might have dreamt up the present decade, I achingly am in the process of alienating myself evermore from common-place software solutions: my ethically- and aesthetically-founded longing for freedom in thought and harbour in minimalism is recognised by few and respected by fewer.

More jarringly still, in ever-growing tergiversation I find some bits most dear to me in peril: exfiltrating works from walled-off, proprietary, sometimes cloud-only ecosystems is a labour-intensive undertaking as is prying in carelessness foreign-hosted repositories out of the hands of giants (cf. 261) no easy feat.
Though most resilient it turned out is a monopoly on my electronic correspondence which by and large is powered by e-mail.

Irk is felt at whim, a plan hatched with more thought. It is thus no wonder I brooded quite some time. And as the moon imperturbably completed its rounds, a desparate but not blatantly doomed scheme solidified: freezing IMAP data as tangible filesystem nodes followed by embracing POP3 with a home-brewed, tailor-made e-mail client.
Auspiciously my toils were not engulfed by scheming alone as imaptar is feature-complete, proved already useful as well as development on brief is currently in full swing.

May the day soon come when I can rest.

As specks of white from up above

2023-01-21, post № 269

poetry, #poem, #winter

As specks of white from up above
diminish in their quantity,
too feeble now, soon overpowered;
disrobed the streets lay bare.
Their prior cloak
a veil of white,
their rugged faces
now too apparent:
In a bid to⸺yes⸺retreat,
the forest looms a sanctuary;
alas it’s known too distant.

Winter MMXXII: An unintelligible tale of lost self

2022-12-24, post № 268

poetry, #winter, #short-story

He woke up by the crack of a twig, discombobulated. It was as if he had been torn away from his slumbery thoughts. Or had it been aid? He wasn’t quite sure.
A breeze of fresh air made him shiver. Laying underneath a thin layer of fir branches, with an uneasy feeling he tried to relive the past day — without success. The sun had already begun to rise behind the distant hills and winter’s ruthlessness slowly crept to overpower his feeble hull.
Glistening in the morning twilight of lust and shrubbery were specks intertwined with an all-consuming frosty blanket. Haze had started to form and coated the surrounding forest in mellow tints of earthy warmth. Longingly he set out to escape.
The further he journeyed, the more I realized who he was. I finally came to a stop; though still hurting for shelter. He was surprised to realize my state of being and I gasped in shock: As the snow melted, so did we and before the last mount had softened into a puddle, there was no one to admire night’s departure.

Electron decays at its roots.

2022-12-15, post № 267

software, #deprecation, #opinion, #bloat

“A hackable text editor for the 21st Century” once was the proud motto of yet another text editor’s working group [A22 [1]]; only that it also served as the flagship to their shiny new platform. Web everything! were the joy-filled chants ushering in a new era of containerized Chromiums. Too elite to recognize UNIX, too elite to value Emacs. Too elite and dazzled by their own superiority stemming from one interpretation of Git, they bestowed upon us Atom.
Eleven years later [2], Atom gets slaughtered [G22 [3]]: GitHub got gobbled up and Redmond picked favorites: VS Code runs on the platform envisioned with Atom — like a mistletoe surviving felling, it, transiently, seems to be the one that stays.

I have fond memories of Atom: in early 2019, when I first dipped my toes into a crude Git workflow, necessitated by a university group project to build a Java compiler in Haskell, it was my tool. Not realizing and at most tentatively asking myself about the difference between a popular version control system and a no-value centralization effort regarding the very, my window into computing was a MacBook and on it my window into conducted computing GitHub Desktop and Atom.

Atom wasn’t too bad if one accepted the dulled GUI-y way of life [S99 [4], pp. 46—60: ‘The Interface Culture’]: its shaky foundation and interpretation of JavaScript’s strengths only possible origins being besotted Web addicts isn’t apparent to the jaded mind. It felt right at home in the form-over-everything dystopia of macOS.

As such, I personally feel less of a loss in software and more an anger to monopolization: as so often with this duplicitous Redmond-free software, we witnessed another instance of gulp, grief, let grieve. Sub-par software and design ethe weren’t dropped, they were set in stone, hammered shut and embossed with a mark of ownership.

Bits: the mute conquerers of thought.

2022-11-26, post № 266

opinion, #computing, #despair, #free-software

It must have been last year’s late months when while strolling through my library’s isles I glimpsed at one unexpected cover which earnestly pulled me in: with bold, dark cyan letters on a once white background which by now radiated its decades shelved away it read UNIX. One of the original works [KP84 [1]] on the approach to conducted computing now ever so dear to my heart: Its authors instrumentally involved in its creation, I felt compelled to read an ad fontes account of the digital landscape of forty yesteryears.

For by now nearly a year I flipped through the yellowed pages of gorgeously typeset hardware descriptions, shell documentation, design rationale, operating system history, C listings and DSL showcases. This book accompanied me an entire year and despite hiatuses of several weeks at a time, when I did pick it up, it pulled me into a magical world of optimism and dare I say naïf exploration of live symbol shifters, their capabilities and aesthetical merits. I wistfully bethink; reading a story of thought, interleaved with prose of C. Slightly smirking at the supposed limitations of terse call stacks notwithstanding true marvel for what had then been achieved.

I seem to have lost this spark. The raw awe of feeling text come alive on its own. The artful contention with the impossibility of an oracle but the dullness of an echo. The joy of playing this game: talking to a single dollar sign on a black void and therein watching my thought act, be, talking back.
Nowadays, the air of digitality becomes further and further intertwined with a frightened, unsmotherable and ever-present anticipation of existential demise. [F22 [2]]

I have furthermore come to the realisation that all I do is long for the origins of our stagnant over-technologized world. When at a rasterized photon spewer, I do everything to make it be a terminal. If I want my letters to have non-informational entropy attached to them, I incorporate caligraphy into my hand writing and enjoy the flown ink. I see nothing more than byte transformers in these machines and for that the simple read and write syscalls are sufficient. All advances made in the field of hardware are about dubiously motivated reality approximation unit density and time warping, yet can still be described by ps. I don’t care for the web, for the obsessive skeuomorphic recontextualization of reality GUIs make one believe in. [S99 [3], pp. 46—60: ‘The interface culture’]
I even wonder if Stallman’s legacy is indeed a cult with only those wise enough to abstain from befouling their mouths with ignorance the likes of ‘FOSS’ members. A cult which has failed, their one and only message through conformance kneaded into obscurity.

But where to then? With churches crumbling and analogue life waning? With every last cranny infested by fakery? — Maybe the right choice is to hide in local woodland; all efforts to think the contrary seem that unbearably inane.

Thoughts on software packages

2022-10-29, post № 265

opinion, software-design, #package-manager, #dependency-management

Monolithic kernel or not, a base operating system is seldom equipped for all tasks a user expects to perform on it. As such, most OS’ provide facilities to run custom executables on the machine, as well as loosely managing them when running. However, software acquisition is largely thought of as an extra layer on top of the base system, interwoven with it to various degrees: a userland’s package manager’s job.

Unfortunately, fueled by the manic lust for usability by a fabricated usager incompétent, the classical package manager maxim (as acted upon by e. g. Advanced Package Tool (APT) [1], Pacman [2], Portage [3], Dandified YUM (DNF) [4], Zypper [5]) seems to fade in popularity, with large GNU/Linux distributions gravitating towards container bundles (see e. g. Flatpak [6], Snap [7], AppImage [8]): whilst their advantages of dependency encapsulation and supposed security benefits are never-endingly chanted by their proponents, in my view they are merely an ad-hoc solution. Instead of crafting solid software with thoughtful third-party inclusions and kempt versions of all parts (which would include replacing abandoned upstreams instead of freezing them together with their reason for abandonement indefinetely), a jumbled mess of any bit that has not evaded the grasp of GitHub is crammed into a bloated archive, coated in a generic runtime and made executable to fool an unsuspecting quick glance into believing one is installing a piece of software worth one’s while.

A cleaner approach which does not use the plethora of unwritten bits found on modern storage devices as a lazy cop-out to understand a package as a miniature virtual computer but nonetheless achieves the desirable property of package atomicity, solves the issue of competing library names or versions and even promises reproducible builds is to improve upon the classical maxim but not discard it (see e. g. Nix [9], Guix [10]). However, I feel like these projects get carried away by their founding principles, slowly encroaching on the entire system: understandling themselves as much more than merely a package manager, they become the distribution and even want to manage user-specific configs (see e. g. guix home [11]). As such, they fall into the trap of complexity and bloatedness, alienating those who came for a Unix experience.

Notably, Guix’ appeal does not stop at boot-level reproducible systems: it is the one entry on the FSF’s list of endorsed GNU/Linux distributions [12] which I managed to successfully use for a few days. The signficance of the existence of such a distribution should not be underestimated, since — yet again unfortunately — the ideals of free software increasingly fall by the wayside with proprietary firmware, kernel blobs and spyware for the masses being accepted by many. Combined with GNU’s declining relevance [13], it might be that Stallman’s four freedoms [14] fail to capture a now relevant dimension of software; in my opinion a pertinent one is to restrict source complexity.
Filling this void, the concept of software minimalism, famously advocated for by suckless.org e.V., prohibits many of the driving forces behind abandoning free software principles: cutting-edge hardware pressure, bloat-cope and dependency trends to name a few.

If now Guix has shown that a package manager can be used as a vehicle to preach a message but — for me more importantly — also comfort believers, I sense there to be an open niche for a package manager representing both software minimalism and software freedom.

Peculiarly, my proposed niche seems to at first glance be diametrically opposed to the core function of a package manager: managing complex package hierarchies. After all, many few-man-show projects choose to go with the in-memory installer route of curl shady.org | sudo sh. Leaving security concerns aside (should one have reason to assume malice, installation via less exploitable means is only a boon when never running the installed), lack of transparency makes uninstalling a daunting task plus further obfuscates the user’s perception of their own system — contrary to the goals of free software.
Furthermore, the separation of program binary and run command (i. e. rc, config file) is blurring evermore in light of suckless-style architectures (see e. g. dmenu [15], dwm [16], XMonad [17], knôtM [18]) lifting configurations to the compilation stage, thus leading to a deluge of similar forks — a scenario classical package managers are not equipped to satisfactorily handle.

On the topic of architectural changes, the decrease in sheer source volume also makes dropping pre-compilation more attractive: Guix consoles the wary with the promise to only optimise reproducible building by injecting pre-compilations and cryptographically proving identity, whilst Portage bears the burden of hour-long compile times. Yet many package managers rely on binary distribution of clouded origins, which itself undermines the principles of free software: claiming to treat people in a free manner is not just about pointing at a licence file on a project’s homepage and executable poisoning is one of the least arduous vectors a miscreant could dream of.
Suffice it to say, software freedom isn’t worth a cent without the source, which is often unfairly treated like an addendum to the binary and thus forgotten about; never shipped. I think source compilation is paramount and beyond its conceptual merits, minimalistic software does not suffer from excruciating compile times, rendering compilation on delivery viable.

From a deeper architectural view, dependency management and the attitude towards dynamic libraries has also changed over the last decade: go’s toolchain relies heavily on ad fontes source inclusion [C18 [19]] and the benefits of dynamic libraries are nowadays hard to make out [D20 [20]]. My few encounters with such system-wide dependencies of late have only been Google’s brotli wrapper for go [21] (I am unsure if the hassle to rely on cgo is worth the presumed performance superiority) as well as the never-dying fossils Xlib [22] and ncurses [23].
Some research-stage approaches have gone even further, dissecting the concept of a source package into finely hash-indexed language-semantic atoms instead of collections of files (see e. g. Unison [24], Fragnix [25]). [26]
I surmise the disappearance of a pressing need to save disk space, evermore longed for moral and security-related transparency paired with the tremendous potentials e. g. dead code elimination, call-specific fusion and measurement-based custom optimization heuristics open up will help the proliferation and maturing of such heavily source-oriented software design approaches.

My own involvement in the area of package management stems from the realisation that my current dotfile management leaves a lot to be desired: fed up with the myriad of individual files I had to manually manage (a shell rc, an editor rc, color schemes for said editor, and various utilities either written in shell or C — thus also needing compilation), in 2021 I started to verbatim paste or base64 encode everything into my shell rc, effectively devising an ad-hoc archive format. [27] Whilst undoubtably in line with the Unix tradition [KP84 [28], pp. 97—99: 3.9], it proved to be both fiddly to manage and did not play well with version control. Thus, I began thinking about a unified framework which enables me to portably and recreatably manage my configurations.
This ongoing effort has currently manifested itself in fleetingly [29], a light-weight package manager with the goal to un-intrusively and atomically add functionality to a running system, journalling what it did to it. As such, fleetingly need not worry about system-integral or deeply dependant packages nor packages of great binary size. It represents my attempt to fill the above described niche, paying attention to proper licencing, proper attribution, software freedom and software minimalism.

Jonathan Frech's blog; built 2024/07/06 12:42:51 CEST