Log (rss)

Beans

Tesfaye Coffee from Ethiopia. Vendor lists notes of strong fruits and jasmine.

Equipment

- Coffee: Ethiopia Tesfaye, 20 grams, medium ground.  
- Water: 320g tap water
- Equipment: kettle, pour-over brewer, filters, scale

Method

1. Rinse the filter, pour out the excess water
2. Pour 20g grounded coffee, shake gently to level.
3. Pour first 50g of water in a circular motion, wait 30 secs.
4. Pour second 150g in a circular motion, wait 10-20 secs.
5. Shake gently to level.
6. Pour last 120g, totaling 320g
7. Shake gently to level.
8. Wait for pour over to complete

Observations

- The filter flops over and is unstable, potentially hindering the water flow.
- Water was just beginning to boil before use.

Results

- Lack of aromatic profile, no smell. 
- Andrea observed bitter tones.
- Marc observed overall delicate flavor with floral notes, not too strong.

Conclusions

The goal is to brew for coffee with less bitterness and more aroma. Variables we can tweak are:

- Temperature of the water. 
- The tap water.
- The spiral pouring technique. 
- The filter used. 
- Altering ratio of water to coffee ground.
- The amount of pulses and the pauses between the pulses. 

We also recognize that some of the limits are due to the equipment.

- Marc & Andrea

We arrived in Cyprus almost exactly one week ago. Today, I sit at a café in Limassol, looking out at the lively sunny street near the center of town, and I feel as if I had only just arrived. As if newly landed.

Like any change, moving always requires effort, usually new and unusual sorts of effort. After a lifetime of moving from here to there, I like to think that I have strategies in place to help me in these moments of transition. And yet, it can be hard, and it has been hard.

The countryside of a new country has special surprises, especially for city people, and I realize more and more that I am city person—despite my love for hiking and nature. Encountering sand flies for the first time, a drought for the third time this year, and challenges in transportation, all while coming down with a cold, is not too much fun. Even if we expected some challenges (like the transportation one), there's no way to sugarcoat the truth, it’s been tough.

I also realize how much I cherish self-sufficiency, which is to say my independence. Not being able to address challenges from the get-go due to feeling unwell and not knowing how things worked made me feel trapped.

And yet, things have slowly fallen into place, with some patience and initiatives to put things in order. Now, it feels like life is ready to begin again.

This experience made me reflect on some other challenging moves I've gone through, two of which were even more challenging. Moving to Paris, for one, and also Vieux-Fort in Guadeloupe (another island) tested me in more ways than one. Stockholm was also tough in the first three days, but overall, less tough than the first week of Paramytha. Even with those rough starts, I've yet to regret moving someplace new (even with new challenges that appear, like the COVID-19 pandemic while I was in Guadeloupe) and I hope this holds true for Paramytha, Limassol, and Cyprus generally.

- Andrea

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