The Linux utility strace is essential for diagnosing process–kernel interactions, but its default output is often unusable. The key to effective debugging is using a specific set of flags that transform raw system call data into a structured, time‑stamped, and annotated log.

According to Avikam Rozenfeld in this presentation, here is the essential command template, followed by a breakdown of why each flag is critical:

strace -f -s 256 -o trace.log -tt -T -y <your_command_here>

Flags and why they matter:

• -f — Follow children
  Purpose: Trace child processes spawned by fork/clone.
  Key benefit: Ensures you trace the entire application flow (e.g., piped commands).

• -s 256 — Increase string size
  Purpose: Increase the string output limit (default 32 bytes) to 256 bytes.
  Key benefit: Prevents truncation of file paths and data being read or written.

• -o — Output to file
  Purpose: Redirect all strace output to a specified log file (e.g., trace.log).
  Key benefit: Separates trace output from the program's standard output for easier analysis.

• -tt — Precise timestamp
  Purpose: Prefix every line …

To build a new OS, or not to build a new OS?

There's a fascinating debate in the software world about whether it still makes sense to create a new general-purpose operating system from scratch.

The Pragmatic View

On one side, you have figures like John Carmack. In a recent discussion on X, he argued that building a new OS is often impractical. The cost, short lifespan, and developer burden rarely justify the effort, a lesson he learned from opposing Meta's custom XR OS.

The Idealistic View

On the other side is the spirit of the ultimate craftsman. This is captured perfectly in a joke by DHH during this presentation:

"People who are really serious about software should make their own operating system."

He's riffing on a famous quote by Alan Kay about hardware, but the message is clear: the ultimate challenge for a software purist is to build the whole stack.

A Middle Ground: Omarchy

Interestingly, DHH's own work offers a third path. He hasn't built an entirely new OS. Instead, he created Omarchy …

Second time that I have this problem, so I thought I would write it down.

When I create a new repository on GitHub, the default instructions to add the remote repository to my local git repository are:

git remote add origin git@github.com:my_username/new_repo_name.git
git branch -M main
git push -u origin main

The problem is that this assumes that I'm using the SSH protocol to connect to GitHub. However, I prefer using HTTPS for my connections. Therefore, I need to change the remote URL to use HTTPS instead of SSH. To do this, I can use the following command:

git remote set-url origin https://github.com/my_username/new_repo_name.git

To avoid this, the instructions to add the HTTPS connection directly should be:

git remote add origin https://github.com/my_username/new_repo_name.git
git branch -M main
git push -u origin main

When I create PowerPoint presentations, I often use animations to explain complex processes. I design slides so the final state is clear on its own, but sometimes this isn’t feasible. When sharing these presentations as PDFs, animations are lost, making slides hard to understand.

I’ve found a solution: PPSplit, a PowerPoint plug-in that exports presentations with animations as PDFs. PPSpit works by splitting animated slides into multiple PDF pages, each representing a step in the animation sequence. This preserves the flow and context of the presentation, ensuring viewers can follow the intended progression without needing the original PowerPoint file.

To use PPSpit in Windows, install the plug-in from its web page and open your presentation in PowerPoint. PPsplit will add a new tab to split the slides. Notice that this changes the file, so make a copy of the original presentation before using it, especially if you have auto-save enabled. After splitting, you can save the presentation as a PDF. The resulting PDF will have each animation step on a separate page, making …

Recently, I’ve come across a few tools to understand GitHub repos better: DeepWiki, GitPodcast, and ForGitHub.

DeepWiki: Turning Repos into Interactive Documentation

DeepWiki, developed by Cognition Labs, automatically converts any GitHub repo into a comprehensive, wiki-style documentation with interactive visualizations. What I love most is its "in-depth research" feature—it provides insights that feel like they’re coming from a senior engineer, covering design concepts, best practices, and even optimization opportunities. You can check it out at DeepWiki.

As an example, you can explore DeepWiki for SimCT.

GitPodcast: Listening to Code as a Story

GitPodcast converts any GitHub repository into an engaging podcast! Imagine listening to the evolution of a project, its commits, and its structure as a story while you’re on a walk or coding something else. It’s hosted by BandarLabs and available at GitPodcast.

This is the podcast for SimCT.

ForGitHub: Comparing Repos Side by Side

ForGitHub gives a list of cool tools and APIs that use the same URL structure as GitHub enabling you to use it by just …