How to Fix Linux Menu Icons for Portable Electron Apps

13 June 2026 by susiloharjo

Linux desktop menu showing an Electron application shortcut with its icon properly rendered beside the system tray

How to Fix Linux Menu Icons for Portable Electron Apps

You downloaded a Linux app as a portable folder or a raw binary — Antigravity IDE, a portable VS Code, a side-loaded Electron tool. You wrote a .desktop file, dropped it in ~/.local/share/applications/, and the app is gone from the menu. The launcher grid shows nothing. The search box finds nothing. You open the .desktop file and the Icon= line points at a perfectly valid PNG, yet the system acts like the icon does not exist.

The problem is almost never the icon file. The problem is whitespace in the path.

GNOME, KDE, and most freedesktop-compliant desktop environments parse .desktop files with a config parser that is unusually strict about spaces. A path like /home/ubuntu/Downloads/Antigravity IDE/resources/app/resources/linux/code.png will silently fail to load for two reasons: the unquoted space inside Icon= breaks the parser, and even when the parser survives, the desktop file validator (which runs when update-desktop-database regenerates the cache) treats the entry as malformed and drops it.

I burned an hour on this the first time. The second time I wrote the fix down. This is the four-step version that survives every Electron portable app I have thrown at it.

I Set 2 Playwright Goals at 4 AM and Both Beat Fajr

13 June 2026 by susiloharjo

Browser window with Python Playwright code on a desk in the dim light of pre-dawn, a closed Quran beside the keyboard

I Set 2 Playwright Goals at 4 AM and Both Beat Fajr

This Saturday morning I woke up at 4 AM with the kind of half-baked idea that only survives a brain that hasn’t fully booted. I wanted to see if I could give an LLM a real browser, a goal written in two sentences, and walk away. Not a toy. Not a sandbox. LinkedIn. Tokopedia. The real web, with logins and JavaScript and the kind of DOM that makes scrapers cry.

By the time I finished praying Fajr and closed my Quran, both jobs were done. One returned 23 LinkedIn profiles as structured JSON. The other returned 14 G-Shock listings under Rp 1.000.000 from Jakarta sellers offering instant payment. I had not touched the keyboard.

This is the prompt pattern that made it work — and the three things I almost got wrong.

5 Things I Stopped Doing as a Lead

12 June 202612 June 2026 by susiloharjo

I led a small engineering team for two years. We shipped on time, the code was clean, and the standups were short. By every metric I cared about, the team looked fine. Then three of my best engineers quit within a month. None of them had a single conversation with me before they handed in their notice.

The exit interviews told me what I should have seen earlier. They were not burned out by the work. They were burned out by the way I gave it to them.

I spent the next six months rebuilding how I delegated. I read four books on engineering management. I ran a one-on-one feedback survey every Friday for twelve weeks. I shipped a working team again, and the difference was not subtle.

Here are the five delegation habits I had to kill. If you are a tech lead and any of these feel familiar, the exit interview pattern will too.

Why a Simple If-Else Can Beat an LLM

12 June 2026 by susiloharjo

Code logic: simple if-else flow chart contrasting with LLM API endpoint

Why a Simple If-Else Can Beat an LLM

TL;DR: When you can describe the inputs and the expected outputs in advance, you don’t need a model — you need a function. Here’s the principle, the proof, and the one case where the principle breaks.

A teammate burned $47 of API credits last quarter on a “smart” classifier. The job: sort incoming support emails into four buckets (billing, technical, account, other) and route them to the right Slack channel. The model nailed it about 91% of the time. The remaining 9% it was confidently, hilariously wrong — sending a billing dispute to the technical channel, an outage report to “other.”

I replaced it with a 40-line Python script using if and a handful of keyword checks. It runs in 12 milliseconds per email, costs $0, and gets the same 91% — except the 9% it gets wrong are predictably wrong, so we know to watch them. The classifier used to hallucinate categories that didn’t exist. The script never invents a fifth bucket.

That’s not an edge case. That’s the principle: when the parameters are already known, deterministic code is the right answer. The question is why this works, and when it stops working.

Anthropic Shipped Two New Models. They’re the Same Model.

12 June 202611 June 2026 by susiloharjo

TL;DR: Anthropic launched Claude Fable 5 (general availability) and Claude Mythos 5 (restricted, cyber defenders only) on June 9, 2026. Same underlying model. Different safety posture. $10/M input tokens and $50/M output — less than half the price of Mythos Preview. Part 1 of 2: specs and use cases. Part 2 will be the review after I have run something real on it.

I opened Anthropic’s newsroom on Tuesday and saw two new flagship models. Then I read the second paragraph and realized they were the same model.

That is the structural fact nobody is writing about. The release notes, the benchmark table, the customer quotes — all of that is downstream of one decision Anthropic made: a single frontier model, packaged twice. Once for everyone. Once for the people with a clear reason to be dangerous.

The packaging is the product. Let me walk you through what’s actually shipping, what the safeguards mean in practice, and what I want to test once the access thaws.

Design Thinking Is 80% Theater. Here’s the 20% That Works.

12 June 202611 June 2026 by susiloharjo

Last quarter I ran a design thinking sprint on an AI agent project. Three weeks in, the only thing I’d produced was a wall of Post-it notes, two empathy maps, and a definition statement nobody on the engineering team could repeat. The agent itself had not moved one line of code forward.

Then I threw out 80% of the framework and kept the 20% that actually shipped the project.

Design thinking, stripped of consultant-speak, is a debugging loop for the gap between “what we think the user needs” and “what the user actually needs.” Most of what gets taught in corporate workshops is theater. The 20% that matters is something engineers have been doing for decades under a different name. They called it “writing tests against user behavior” or “asking the customer before shipping.”

This post is the 20%.