Log (rss)

Currently, I am reading the book Zen and the Art of Motorcycle Maintenance, and it is divided into several Chautauquas. Chautauquas began as part of a social movement during mid-20s America and they consisted of educational events full of "entertaining lectures, performances and/or concerts". The story of Zen And The Art Of Motorcycle Maintenance uses this concept to deliver philosophical insights in a way that is more entertaining to the reader, and uses, as you might guess, motorcycle maintenance to talk about what is the meaning of quality and why quality matters.

- Marc

I love Emacs as a system, even if it is a bit slow and bloated. People joke that Emacs is a great OS that is missing a text editor. And well, while Emacs does not actually handle persistence, concurrency, virtualization, yadda yadda, which an OS normally should, it is certainly not just a text editor. I think of it as a computing environment.

Compared to Kakoune or Neovim that open in milliseconds, Emacs loads in seconds. Many features have noticeable delays that just feel like they should be smoother, and you wonder if there aren’t a few features that could be cut. But despite that, I think it contains so many interesting utilities and features that I just wish were available in regular Unix.

There is without a doubt a certain charm to Emacs. Here are some of the Emacs features that I would love to bake into Unix and terminal ecosystems:

• Ease of access to offline documentation. Info-pages get a bad rep, maybe in part because the keybindings are very Emacs specific, but it solves a real need. Because man-pages are meant to be terse and for reference, they can not contain everything necessary to provide good documentation.
• Everything can be linked and bookmarked. That means that if you have references scattered around different documents, you are able to very easily bring them together. For example, I have bookmarks to reference documentation, websites, emails, all accessible from a single place. In Org mode, I can have TODO items that link to specific parts of a code.
• Documents can be interactive. Together with org-babel or hyperbole, you can create interactive media. For example, hyperbole can add a document full of commands you can run, so your documentation is interactive. org-babel can enable you to to write documents with code-snippets in them so that you can evaluate them.
• Variable pitch mode and image rendering. Variable pitch mode allows you to switch between a sans font and a mono-spaced font. This along with images makes for a much better reading experience when browsing the web.
• It can load images directly. There is a way to do so as well if your terminal emulator has sixel support, but this feature is not really used so often.

I would like to use a Unix terminal instead of a Lisp VM like Emacs, as I do prefer an ecosystem where you are not just bound to Lisp but can use whatever tool you want. In theory, a lot of what Emacs can do is feasible in Unix, but in practice the ecosystem is far behind. If you are like me (you basically live within your terminal), I find that you are better served by a system like Emacs.

- Marc

While we are now well into September, I wanted to take a moment to reflect on some memorable August reads, books that I still think about and will be thinking about for a while.

I read two books last month, one poetry and one prose (very unconventional prose, however).

El oficio de vivir, or (roughly) The craft/work of living, is a collection of poetry by María Mercedes Carranza. Compiled posthumously and prefaced by her daughter, the collection sinks, poem by poem, deeper into the despair that plagued Carranza, especially in her final years. Despair about aging, despair about Colombia’s endless violence, despair about injustice, meaninglessness, despair about despair. Death weighs heavy on almost every page. Her words manage to covey the hollowness of depression in a way that I have not seen captured in any other piece of writing (even books and memoirs about war or genocide). It is grim, very grim.

El libro uruguayo de los muertos, or The Uruguayan Book of the Dead, on the other hand was much less grim, despite of the title. It did take me a very long time to read. Along with García Márquez’s El otoño del patriarca, it might be one of the toughest books I’ve ever gone through. In short snippets destined to a mysterious correspondent, Mario Bellatin melds fact and fiction to speak about everything and anything. Some themes do stand out: writing, publishing, illness, death, family, truth, falsehood and mysticism. Like the Twirling Dervishes he describes, cyclical snippets of narrative appear, disappear, only to reappear later, the same or almost the same or altered incomprehensibly. Temporality is warped, contradictions appear, and, as a reader, offering resistance only makes the read more painful. At some point you just have to let go and let Bellatin take you on a trip that goes round and round. And in the end, I was left a bit dizzy.

El oficio de vivir was close to making it on my favorites list—it is a true work of art. But the art that resonates with me the most is that which peers into the void, but with defiance. There is a will to live and an affirmation of life, the renewal of life. With Carranza, we succumb to the void, even if the last poem of the collection offers a glimmer of hope.

Mario Bellatin’s Salon de belleza (Beauty Salon) is one of my favorite books, but I can’t say the same for El libro uruguayo de los muertos. There are very interesting ideas about the nature of truth and fiction, about the pain of creation, and about life, death and creation as cyclical. The unconventional form resonated with these themes, but maybe it went on for too long. But then again, watching Twirling Dervishes perform is fascinating, but it can also feel eternally long after a while. But isn’t that what we’re all after, eternity? Reading El libro uruguayo de los Muertos definitely felt like it took an eternity too, but maybe that's what Bellatin was trying to do—approach eternity, which also means to approach death.

Other Interesting August Reads

• “Programming is Forgetting: Toward a New Hacker Ethic”
• “The Betrayal of American Border Policy”
• “The Funeral: At a Loss” (recommend reading this only after watching Itami Juzo's film)

- Andrea

Bogo is my Thinkpad T480s that has served as my primary laptop since 2019.

System Description:

• Kernel: 6.6.50_1
• OS: Void Linux
• Desktop: CWM
• Fonts: Iosevka Aile, Courier 10 Pitch
• Term: Urxvt
• Editor: Kakoune
• Shell: ksh
• Connection Manager: iwd
• Audio Manager: pulseaudio
• Battery: ID-1: BAT0 charge: 41.9 Wh (91.7%) condition: 45.7/57.0 Wh (80.2%)
• CPU: Intel Core i7-8650U
• CPU Speed (MHz): avg: 593 min/max: 400/4200 cores: 1: 400 2: 780 3: 400 4: 400 5: 800 6: 764 7: 400 8: 800
• Graphics: Intel UHD Graphics 620

Bogo was serviced with a X1Y3 glass trackpad, new RAM and SSD after RAM reported faulty in 2024.

- Marc

Today, I continued my exploration into measuring energy usage for a server. To my dismay, I discovered that when running software within a VPS, measuring its energy usage becomes impossible. A VPS obscures the underlying hardware to protect other servers running on the same hardware. Theoretically, an attacker could use the energy data to perform side-channel attacks to extract private keys from other users, so there are good reasons to keep the data hidden in virtualized systems.

All the companies that I have worked for rely on VPSes and VMs, with no access to the underlying hardware. I imagine at this point it is pretty standard in the industry, which makes me think that few companies are able to measure their energy usage and understand the footprint of their backend.

It is unfortunate because sharing the hardware also means that we could leverage it more efficiently, and avoid over-provisioning hardware. At the same time, when you do not understand how much energy the software is using, it encourages wastefulness.

Related Reading: "Green Networking Metrics"

- Marc

There is a dichotomy in software development, high-level and low-level software. This is particularly true for programming languages, where you have low-level languages that give you more control, but require more understanding of how computers work, and high-level languages that allow you to express your ideas more simply and allow you to not think about low-level details.

High-level software is called that because it operates at higher levels of abstractions. This means that it obscures the machinery of what happens within a computer (the "low-level"), so that we can focus on the task at hand. For example, we would not want to think about how a web browser forms a TCP/IP connection, communicates with a DNS server, etc., when opening a web page—at least, we do not want to up until the point where we encounter an error.

High-level software unlocks the ability for us to perform more advanced tasks quicker with less mental overhead. It can also unlock a great deal of improved security, as it can restrict certain operations from the user and better adapt to their needs, which, even if it deprives users of some liberty, can still be desirable.

However, when we only focus on building a good high-level experience, it comes at the expense of low-level control that becomes inaccessible or too complex for regular users. This invites us to be inefficient and construct false understandings. Without a deep understanding of our systems, we cannot meaningfully fix the system nor optimize it. It invites us to outsource this control to experts, who are often restricted to building general solutions for many use-cases. Poor understanding often leads to rebuilding the same solutions over and over again, with the solutions becoming even more complex and inefficient each time. When only experts understand systems, it centralizes knowledge and power away from the general population.

I explored the democratic problems it leads to in my essay The Curse of Convenience.

Low-level tools give us greater control and greater freedom. Understanding the lower-level units makes it easier for us to understand how everything fits together, and gives us the power to make the changes we wish. However, using only low-level tools makes it more difficult to cleanly express ideas and it can be a frustrating experience. It sometimes requires digging through manuals and the time it takes to accomplish tasks becomes much longer. It is also easier to make mistakes.

This dilemma leads me to solutions that attempt to be simple on many planes of abstractions. In programming languages such as Go and OCaml, the high-level semantics are simple, but a user can still also understand the lower-level details of what happens, which makes it possible to operate at a lower-level when necessary without being an expert. In software, Unix utilities find the balance of being simple and allowing users to express high-level ideas. Older motorcycles are easy to operate, and also easy to fix when necessary.

- Marc

One of the most beautiful ideas behind the original Unix, that I think has unfortunately gotten lost and is now underrated, is the idea of a form of collective computing. People would gather as a group and collectively build tools. The way Dennis Ritchie described it:

"What we wanted to preserve was not just a good environment in which to do programming, but a system around which a fellowship could form. We knew from experience that the essence of communal computing, as supplied by remote-access, time-shared machines, is not just to type programs into a terminal instead of a keypunch, but to encourage close communication."

Using a collection of simple tools, users would then be able to bring these together on time-shared machines and build solutions to meet the needs of their communities.

Another obvious advantage to collectively owned computers is that you retain ownership from the bigger companies, while at the same time still unlock better optimization permitted by scale. For instance, these collective computers can live in geographically advantageous regions. For example, Solar Protocol directs users to whichever server has the most sunlight.

There are a lot of advantages to empowering users to fix issues themselves, rather than someone fixing their problems for them. I wrote about it extensively in my essay The Curse of Convenience. I also see with the new LLM models a resurgence of this idea in Maggie Appleton's essay about home-cooked software. Personally, I am skeptical that LLM's will enable this revolution, but I think her essay is still worth a read!

Today, there is a communal computing system that exists, it is the SDF. It has been around since the 1987, and it is definitely marketed towards a technical audience. It hosts a set of collective computers that any member can use for any purpose (within reason). With it, people have set up a Lemmy instance and a Mastodon instance. It also comes with a free email account and a shell you can SSH into and do any kind of programming that you want.

Personally, I use SDF to host my notes with git. Doing that was as simple as ssh user@tty.sdf.org -t mkdir notes && cd notes && git init. Once done, I am able to access these notes from my phone or my laptop, wherever I happen to be. To clone it locally, I just run git clone user@tty.sdf.org:~/notes. I also hang out at their Lemmy instance.

- Marc

I have recently(ish) become interested in file formats. In particular, file formats that are human readable and human writable.

These formats have quite a few advantages:

• They are (obviously) modifiable by hand
• They are easy to backup
• They are easy to maintain
• They are (often) easy to build software for

But they also come with challenges:

• Human-writable means that data integrity is not guaranteed
• They are inefficient

To me, the biggest beauty of these file formats is that they can outlive the software that created them. Even if I am on a foreign computer, without internet, hit with amnesia, I can still make sense of and modify these formats.

Software, in some way or another, always takes data and outputs data, that's what a computer is meant to do. I think it is worth thinking about how we can make sure that the data generated outlives the software that made it, inspired by Permacomputing.

I kicked off a thread on Mastodon to see what kinds of human-readable data formats people know of. I am excited to see what people share.

- Marc

Common startup-mentality is to move fast and break things. Books like Lean Startup also posits that startups should build "MVPs", which is an incomplete version of the product that allows you to test it on real users so that you can iterate on it.

All the talk is about being cheap and fast, which I do think is important for a startup. However, I also think people get it wrong, because while it is good to be lean, the product should not be buggy, wasteful or low quality.

I think of software as similar to building a house. The fastest way to get a house up is building a house with poor foundations, using the cheapest brick with prebuilt modules. But, it is also unlikely that anyone would want to live in such a house.

If, instead, we were to invest in quality, even if it means to build only a small section at the time; I believe the end result would be better and the feedback received along the way will also be more useful. So, when coding let's make sure that the code is good. Let's not neglect testing, but perhaps with a more limited scope. Let's take the time to think about the visuals and the energy efficiency of the solution, because neglecting this affects the quality of the entire product, and energy efficiency is a social responsibility we all bear.

I also think of writing code akin to maintaining a house. If your code is bad and smelly, it is like working in a kitchen that has not been cleaned for months with dirty dishes piled up in a sink. It is not a place where you want to work in, or inhabit.

- Marc

As of today, I have publications forthcoming in Hypertext Review, The Good Life Review and The Madrid Review. In the past two years, I have published at Americas Quarterly, Periódico de Libros, Pie de Página, and for Artists at Risk Connection.

It was difficult for me to write that paragraph. It is even more difficult still to post it and keep it on this website. The feeling that I am bragging really gets under my skin, which is why I tend to struggle with self-recognition. But, my aversion to listing "accomplishments" is not even fully based on humility, it is also a bit of cowardice. It takes courage to stand publicly behind a piece of writing (especially some pieces of writing that I now find could be so much better, if only I could pick them apart and put them back together), it is safer to sink into anonymity.

However, if I were to retreat, I would be incapable of truly understanding where I am at as a writer. And, despite of everything, I also marvel at it all still, that the texts that I spent hours drafting and tweaking and dialoguing with others about are out there, whatever that means. In a sense, I still don't really truly believe it.

From childhood, language and writing have always been a safe haven. I gravitated towards storytelling in the moments of most uncertainty. It was fun. Libraries were there no matter how many times we had to pack up and move. I always knew I wanted to write, to be able to share images, thoughts, impressions, and feelings with others.

However, a writing career never seemed like an option. Of course, a career involving writing, yes. But it was out of the question that I would just write. That wasn’t a real career, and most importantly, it was unsustainable for someone like me. Even when I majored in languages, literature, and the humanities—I imagined I needed to enter academia or do something else. And I did, I did do something else, and I found many additional passions in the social sciences, in anthropology, in film, and in science.

I continued to write, but for myself. Other responsibilities quickly took up my time, responsibilities that I genuinely enjoyed tackling and that were within the fixed path laid out by my studies (which involved academic writing). But when the studies ended, or paused (who knows), and I had to think closely about what I really wanted to do, the urge to write, creatively, made itself known. But about what? And who would read it?

It turns out that I had published before, as a student. But I never took those achievements seriously. I downplayed the writing itself, for some reason, “it didn’t count”. In some sense, I feel that still, like the publications I have listed at the top of this entry "don't count", incomprehensively.

The first creative text that I published appeared a decade ago in the quarterly magazine, Just Poetry!!! This poem, “Fruit Salad is Heterogenous”, was just a faint memory in the back of my mind until I rediscovered the printed issue earlier this year. I didn’t even remember it had been printed. I certainly didn’t remember it had been one of the nominees for best of issue. And when I re-read it, I realized it was not half-bad for a high school student publishing and writing poetry for the first time. I surprised myself with those words, and they evoked feelings and memories latent with meaning.

Exactly ten years later, my first creative English narrative pieces and Spanish-language poetry pieces are forthcoming.

I am well aware of all the ethical issues with the publishing industry, as with any industry, especially as journalism and print struggle financially. There are very good reasons the reject the notion of traditional publishing all together. And yet, the efforts of small presses that I see here in Bogotá and online internationally are exciting (Hypertext and The Good Life, are non-for-profits; The Madrid Review is a volunteer effort). And even in more traditional media, there are people passionate about storytelling. I can discern (or a better word, vislumbrar) a way of breaking through and sharing stories and histories with a variety of people. That prospect excites me.

Not to say I haven’t been discouraged by rejection (part and parcel of the process) or by a perceived shortage of time or disappointment in myself (self-doubt, or perfectionism). It has felt impossible at times. That feeling of failing to communicate something important, essential or the essential nature of that which I am trying to communicate. The hegemony of English also makes publishing in Spanish challenging—and I don’t want to feel pressured to write in English because of it. I want to write in English because I feel like it. And I want to be able to write in Spanish (or any other language) when I feel like it too.

In those times of self-doubt, my friends and family have been essential, as well as the kind words of the readers who have found something worthwhile in my writing. But also, diving into the written works of others has been so important. Those books, poems, and articles that speak to me motivate me and give me courage.

- Andrea