@jonydevcode

The Problem with Withheld Wonder

Wed, 17 Jun 2026 15:30:00 GMT

Months ago, I came across a trailer for Disclosure Day. The trailer had all the ingredients for a movie that I would enjoy, including Spielberg as the director, John Williams as the composer, starring Emily Blunt, aliens, intrigue, and science fiction. I tremendously enjoy the work of Spielberg (Raiders of the Lost Ark, Minority Report). When tickets became available, I told myself, say no more, take my money, and I quickly booked a seat at the nearest IMAX theatre. I had high hopes and expectations.

The trailer genuinely filled me with wonder. In the early version of the trailer, aliens were not even mentioned. That brief scene with Emily Blunt making the strange noises stirred up great intrigue in me. I wanted to see the movie because I wanted to be filled with a sense of discovery. Having finally watched it, the film simply does not deliver. I felt like everything in the movie was pointing towards something much more profound, but never fully bringing the viewer to that destination.

Warning: Major spoilers ahead. DO NOT continue if you want to avoid spoilers.

The movie started strong. I was immediately thrown into a tense scene between Daniel vs Noah and his goons. There were multiple points of intrigue. What was that small cylindrical piece that Daniel held that struck such fear into everyone? What was the “truth” that was being hidden? I felt like I hit the ground running. The movie does a good job of moving the plot along without wasting time on exposition. I quickly learnt that there are good guys (the ones who wanted disclosure), and bad guys (the ones who wanted the secrets kept hidden). The film was setting up for a satisfying pay off at the end.

However, as the plot marched on, the movie started to feel less like a display of intrigue and wonder, and more like a frustrating list of weak points and unanswered questions.

For starters, the antagonist (CEO Noah and Wardex) is annoyingly weak. His men in black are super incompetent. They failed to notice Daniel sneaking around a board fence and let him steal one of their cars. They saw that same car drive into the river, and never considered that Daniel and Jane (who were simply hiding behind a rock nearby) could have jumped out before the cliff. For the final 15 mins of the movie, Noah just gave up, sat on the chair, and watched Margaret and Daniel release everything to the news networks.

The motivations behind the major plot reveals are not clearly explained. Why did the aliens want to imbue Margaret and Daniel with those powers? Why did it take so long for the powers to manifest? What was the endgame? And let’s talk about Margaret. Her superpower is… weird. She seems to be able to control people, but the mechanism is not clear. In fact, the way she uses her power is borderline goofy. She rocks up to an army base, rattles off the guard’s name and personal PIN, and the guard lets her through. Shouldn’t you be extra doubtful of this civilian, who almost crashed into the barrier, and does not state her purpose in the military base, even though she knows something secret? Margaret then appears to Noah as his deceased wife, and suddenly Noah folds to her. What does appearing as a person’s deceased wife have to do with their free will? It doesn’t make sense.

Source: Universal Pictures.

In many articles about the movie, a screengrab shows Emily Blunt’s character Margaret holding a strange object that glows. This is one of three alien artefacts that appear throughout the movie. The movie never explains what they are, what they can do, or how to use them. They seem capable of anything, from “diving” into people’s minds, to performing a Mission Impossible IV invisibility illusion, to turning the power back on.

Several scenes also seemed loaded with significance, but there was no pay off later. One of the men in black grabbed the artefact, vanished in a puff of black smoke, and reappeared on the ground moments later. What happened? What was the crop circle generation scene around Daniel for? What was that moment in the train when Margaret was having a panic attack all about? For a moment, I thought Daniel was going to play the piano to calm her down.

All these flaws would have been redeemed if the ending had been great with a fantastic pay off. But the ending left me feeling empty and underwhelmed. Margaret looked into the camera and said “Listen”. There was no satisfying conclusion, no explanation, and I left the cinema with more questions than answers. Sometimes, that’s a good thing. With Inception, my friends would discuss for weeks whether they were in a dream or not. But this time, I just felt that the whole film was evasive about what it was really trying to reveal, rather than being something profound.

After the movie, I jotted down my thoughts. Then, I went to imdb.com’s user reviews section to see what others were saying. I saw two titles that resonated strongly with me: “Disclosure: nothing is disclosed” and “I wanted to be awestruck by Spielberg but instead I was dumbstruck”. Those couldn’t have more perfectly captured how I felt about the movie.

Compatibility vs Containment

Tue, 16 Jun 2026 13:00:00 GMT

Compatibility vs Containment

Proton is a compatibility layer that allows games to run on Linux. Proton is built by Valve, the company behind Steam, which is the world’s largest gaming platform by far. By making games playable on Linux, Valve has done unimaginable good for Linux adoption. I run Fedora on my gaming desktop. Proton is what has allowed me to enjoy so many games for the past several years.

With the magic required to get games to run well on Linux, I imagined that Proton forms a sort of containment layer around the Windows application. However, this couldn’t be further from the truth. In fact, Proton is based on Wine, which literally stands for Wine Is Not an Emulator. What security boundary did I then wrongly assume that Proton (or Wine) provides?

I encountered this lack of a security boundary firsthand while I was tinkering around with running games and other Windows applications on Linux. I ran 7zFM.exe (the File Manager binary for 7-Zip) and noticed that Proton maps Windows drives to various paths on my Linux system. For example:

Z: is mapped to /
X: is mapped to my home directory

This gave me pause for concern. My initial reaction was, why does a game need so much access to run? I briefly considered the risk of compromised developer accounts used to distribute malware via legitimate game updates. Access to my entire disk would give them the ability to harvest my personal data.

I then realised that I was implicitly treating Proton as a sort of security boundary, when this was entirely the wrong mental model to have.

On its GitHub page, Proton very clearly states its intent:

Proton is a tool for use with the Steam client which allows games which are exclusive to Windows to run on the Linux operating system. It uses Wine to facilitate this.

The goal has always been to run games. As many games as possible. In other words, the goal is widespread compatibility, not application isolation. This principle is also inherited from Wine, which clearly states in its FAQ that it does not do any sandboxing whatsoever. Therefore, to desire or assume any form of isolation via Proton is a mistake.

I started reflecting seriously about this because of how frequently supply chain attacks are used to distribute malware. Of all the malware, infostealers really scare me. But you know what’s worse than an infostealer? An infostealer masquerading as a game, available on Steam for anyone including myself to purchase and play.

There are already several examples of games that were hijacked with infostealers. One example is BlockBlasters. You can see an example of a batch script collecting browser profiles and crypto wallet data and sending it to a C2 server.

Figure 1: Malware payload showing a batch script that collects crypto wallet and browser data. (Source)

I wondered, why doesn’t Valve do something about it with Proton? Then, I stumbled across this heated discussion on GitHub from 6 years ago discussing this very issue. I found the discussion fascinating, agreeing with arguments from both sides. The issue author questioned why Proton couldn’t just symlink to the directories it needs, like ~/.steam and the game’s install directory. Proton contributors responded that this is behaviour inherited from Wine, emphasising that Wine’s job is not isolation of applications from the host. The issue is marked as Closed, indicating that Valve likely does not see this as a problem to be fixed.

It turns out that my question had been answered half a decade ago. The mapping of host directories, and a Wine executable having the ability to do anything a host user executable can do, is behaviour that should be expected from Proton.

I did tinker further. In a WINE prefix, there is a drive_c which serves as C: for the Windows applications. If you place your binaries within drive_c, you can minimise any need to read/write outside C:. This means that entire games or applications can be run without Proton (or WINE) needing to map host directories.

Assuming you are using that approach, there is a way to prevent this mounting by modifying a few lines inside Proton (and Protonfixes if you use that). Firstly, I must reiterate the point I already established earlier, which is that Proton is not a true sandbox. Secondly, this an incredibly fragile solution.

./proton

# Line 998-1000: comment out these 3 lines
if not file_exists(self.prefix_dir + "/dosdevices/z:", follow_symlinks=False):
    os.makedirs(f"{self.prefix_dir}/dosdevices", exist_ok=True)
    os.symlink("/", self.prefix_dir + "/dosdevices/z:")

# Line 314: shortcircuit these two functions with return
def setup_game_dir_drive():
    return
    setup_dir_drive("gamedrive", "s:", try_get_game_library_dir())

def setup_steam_dir_drive():
    return
    setup_dir_drive("steamdrive", "t:", try_get_steam_dir())

./protonfixes/utilities.py

# Insert a return to shortcircuit setup_mount_drives(), removing u, v, w, x
def setup_mount_drives(func: Callable[[str, str, str], None]) -> None:
    """Set up mount point drives for proton."""
    return
    if os.environ.get('UMU_ID', ''):
        drive_map = {
            '/media': 'u:',
            '/run/media': 'v:',
            '/mnt': 'w:',
            os.path.expanduser('~'): 'x:',  # Current user's home directory
        }

        for directory in drive_map.keys():
            if os.access(directory, os.R_OK) and not _is_directory_empty(directory):
                func('gamedrive', drive_map[directory], directory)

The changes above will not persist across runner updates. Applications that rely on host directory access (e.g. if you need to browse for a file exposed over the /run/media virtualised directories) will also not work correctly. I do not recommend this unless you can tolerate the trade-offs.

At the end of the day, Proton provides compatibility, not a trust boundary. On Linux, I am certainly safer in some ways. But the real wake up call for me was realising that running untrusted software through a compatibility layer is ultimately still running untrusted software. If I wanted isolation, I’d reach for a VM.

I'm Learning Neovim

Sun, 14 Jun 2026 07:00:00 GMT

I use VSCode as my default editor. Honestly, I’m happy using it and have no pressing need to switch. However, very recently, curiosity got the better of me. I have decided to learn and use Neovim for a few weeks. At the end of the journey, I hope to report back on my experience, and whether I want to make the switch to Neovim permanent.

I’m fairly proficient in VSCode’s keyboard shortcuts. Features like the file picker and command palette (⌘+P/Ctrl+P and ⌘+Shift+P/Ctrl+Shift+P) help tremendously with feature discovery, particularly when I don’t know the exact keybind but I know that an action exists (like split right).

My history with Vim dates back to my Computer Science undergrad days. Learning Vim and showing off rapid keyboard commands was very trendy among my classmates. At the time, I learnt the bare minimum, which allowed me to SSH into the school’s cluster, edit files, and most importantly, quit Vim. When I was much younger, I had learnt programming with IDEs like Visual Studio and IntelliJ. I was very used to feature discovery being part of the UI. For text editing, Sublime Text or gedit was my preferred tool. Vim, on the other hand, seemed like a path towards getting no work done at all.

Lately, as I’ve become more interested in craftsmanship, I’ve seen people promote Neovim as a way to care about the tools one uses to write code. I’ve seen several online lists of benefits that Neovim has over UI-based editors. Here are some I would like to test or experience for myself:

Cool factor
- Neovim is just cooler than VSCode. I previously worked at a company where the “elite” backend devs would stereotypically have beards and use Vim. There is nothing objective about how either attribute makes you a better programmer. Since my wife won’t let me grow a beard, I’ll have to settle for using Vim.
Consistency in keyboard shortcuts
- I use macOS and Linux consistently. VSCode shortcuts are not universal. The modifier is ⌘ on macOS and Ctrl on Linux. Using Neovim on both OS helps build consistency, especially since Vim motions and commands are designed to be portable and avoid OS-specific requirements.
Ability to SSH into anywhere and have a powerful editor at my fingertips.
- Generally, I’ve had no issues managing my servers effectively, relying on basic vim/nano. In rare instances, I’ve wished for a better editor setup. That’s where Neovim would have come in clutch.
Faster (?)
- Vim motions and commands promise to make a proficient user much faster at editing text. Is this true? Vim/Neovim enthusiasts will tell you yes but I haven’t seen any empirical data.
- Lots of great discussion points in this Hacker News thread, but the one that stuck with me was the differentiation between those who “think then code” vs those who “think while coding”. I fall into the latter camp. I instinctively put my initial thoughts into code, despite knowing that my plan or direction could be off. Then, I iterate. I’m sure I spend equal if not more time refactoring and rewriting existing code than writing brand new lines. Vim/Neovim is supposed to help with the speed of that iteration.
- Launching and taking equivalent actions in Neovim feels faster than VSCode. I would guess that a lot of this stems from the Electron and JavaScript overheads. From my own experience, VSCode is so well optimised that it is already fast enough. Would this difference have any measurable impact on one’s experience using the editor, be it productivity or enjoyment? I’m not sure, but I would certainly like to test this with my own experience.
Avoid VSCode’s marketplace (?)
- There have been past examples of malware on the VSCode Marketplace. Just last month, GitHub confirmed that a poisoned VSCode extension gave an attacker access to ~3,800 internal repos. Neither VSCode nor Neovim offer complete sandboxing, hence Neovim’s plugin security exposure is the same as VSCode’s, albeit with a much smaller ecosystem.

I am also pre-empting some downsides:

Initial productivity decrease is very tangible and noticeable
- I’m struggling to get started on fixing my broken Game Boy emulator timer implementation.
- I don’t know how long this period of low productivity will last.
Losing access to VSCode’s larger extension ecosystem
- The larger ecosystem of VSCode marketplace means faster and widespread support. However, the impact to me is likely not going to be major since I haven’t encountered any language or feature that I use on VSCode but isn’t on Neovim.

I enjoy learning something new. Getting started learning Vim motions and configuring init.lua from scratch was very satisfying. Yet, I’m fully aware that configuring the editor and actually using it are two very separate experiences. I hope that as I continue this experiment, I will become better at motions. I hope that editing and refactoring code will become easier. I hope that I will generally enjoy the experience of using Neovim. The crucial tell at the end is whether I reach for VSCode or Neovim when I have to write code.

Is How We Use AI Destroying Our Craft?

Tue, 09 Jun 2026 14:00:00 GMT

My opinion has always been that AI is a great tool, but it’s a tool.

At the Open Source Summit North America 2026 in Minneapolis, Linus Torvalds said (25:57) the above. He noticed how people proudly declare that their code was 99% written by AI, but those same people would have never said that their code was 100% written by compilers.

I love the tongue-in-cheek comparison that I had never thought of. But should we even consider AI to be a tool? In his series “Wading Through AI”, Casey Muratori contends (1:40) that AI shouldn’t be considered a tool because it is inherently non-deterministic. Historically, tools have been controllable devices that responded well to skill. A blacksmith’s hammer. A painter’s brush. A surgeon’s scalpel. A programmer’s keyboard. The predictable nature of tools, and the fact that you can receive clear and usually instant feedback, allowed people to master them. In fact, unpredictable tools are a major risk to the wielder. A chainsaw that cannot be used in a controlled way is capable of great destruction.

Yet, that isn’t the right question. AI is undoubtedly a tool. Consider this Merriam-Webster definition of tool:

something (such as an instrument or apparatus) used in performing an operation or necessary in the practice of a vocation or profession

Purely based on the definition, AI solutions are “tools”. People use them for information retrieval, summarisation, analysis, image generation, and role-playing. Arguably the biggest impact LLMs have had is in the arena of programming, where “agentic coders” are now writing significantly more code than before.

Instead, I posit that the right question is this: does the way we use our tools destroy our craft?

Craftsmanship is important. I believe that we should approach our skills, whether for our profession or for leisure, with the intent to practice a craft for enjoyment and fulfilment. We exert control over our tools to accomplish a task, and often in that process receive feedback about our skills. We learn and improve. When I started learning to type, the keyboard gave me consistent feedback about how slow or wrong I was. With practice over many years, I’ve grown to be proud of how quickly I can type. Using a tool more typically builds competency, which instils a sense of pride and accomplishment in the individual.

However, I don’t feel that same degree of pride and accomplishment when I use agentic coding tools. Much has been said about AI coding. On one hand, language models today are incredibly capable. I have personally been astounded by how good OpenAI’s Codex is at creating desktop and web apps, some of which I use on a daily basis. On the other hand, many people online have bemoaned the issues of shifting coding to agents, including the loss of control, loss of understanding, and inconsistent quality across language models and harnesses. The issue that bothers me the most is the cognitive offloading that happens when a programmer substitutes their slow and often frustrating process of coding by hand with AI in the name of efficiency gains.

Going back to Linus’ quote above, I get his point. But I worry about how Linus is open ended about the way people use AI as a tool. Using AI to write code for you has virtually no corresponding skill increase in the individual, compared to another who hand-writes, debugs, corrects, and improves their own code. Additionally, I can see how both compilers and AI form an abstraction above machine code. However, compilers are (mostly) deterministic. Given the same set of inputs (code), build environment, compiler version, compiler flags, and other config, a compiler should produce the same output. That predictability enables debugging and reproducible builds.

Can the same be said about AI? I’ve recently warmed to the idea of calling AI a slot machine. Pull the lever, and wait for the spinning ASCII progress circle to complete. Fail, and you try again, without reasoning through the obstacle encountered. For common languages and frameworks, the probability of getting good, workable, maintainable code with AI is very high. If your encounters with AI are limited to those scenarios, you’re consistently hitting “jackpot” with each AI lever pull. But AI does much worse for languages, frameworks, or domains outside the popular. Recently, I’ve been learning Zig. I’d say about 50% of the time, I can’t get GPT 5.5 to generate idiomatic working Zig code. Initially, I couldn’t tell that the code was wrong. In fact, I only realised how wrong the generated code was after the compiler gave me the predictable, instant feedback of dozens of error messages. After hours of reading through the Zig docs, reading online discussions, and crucially, working through Zig programming exercises by hand, I finally started to build a sense of how to write better Zig code.

Here’s what I’ve decided. For scenarios where I don’t care about the element of craftsmanship, I personally do use AI as a “tool” to aid me in accomplishing a task. Some examples include summarising product reviews on the internet, quickly generating throwaway web apps and utilities, and summarising transcripts of videos that I do not intend to watch closely.

But in two areas, I will not use AI as a tool for output generation: programming and writing. As I write more code, I want to improve as a programmer. As I write and publish more posts, I want to improve as a writer. I acknowledge that my code and writing both will start out terrible. However, using AI to short circuit the process and achieve unearned output quality will only hurt me in achieving my desired improvement.

Slow down and think about your use of AI. Are you overemphasising the output and inadvertently discounting how your skills are affected? I’m not against the use of AI. And I have no doubt that AI is capable of producing fantastic output. Rather, the question I need to ask is whether I still want to become the kind of person who could have produced it.

Editorial House Rules v1.0

Mon, 08 Jun 2026 14:50:00 GMT

To kick off my actual writing, I want to talk about some boundaries.

I have a day job. As is typical for most organisations, there are clear rules about what I, as an employee, am allowed to say publicly. To ensure a clean separation between what is work and what is personal, I want to state clearly what I will write or will not write about.

All my writing is done entirely in my personal capacity. My writing does not represent the views of my employer. I may write about my personal observations, books, movies, music, technology, programming, and AI. These are topics that interest me. If any are work-adjacent, they will be entirely based on public sources and personal interest.

There are also topics I will not write about.

For instance, I will not post about my work, or official, non-public, or work-derived information. I am also intentionally going to avoid topics that touch on sensitive public issues, which include matters about social cohesion, national security, or politics. I may state my views and preferences in my posts, but they should not be treated as official information, insider content, or professional or role-related advice. Essentially, if anything is connected to work, I will leave it out.

I believe that for the most part, constraints are good, and spelling them out clearly here can help me write safely and sustainably. I can still write about plenty of other topics. I hope that my writing here will become my personal space for my interests, not a window into my work.

Hello, world!

Fri, 05 Jun 2026 07:00:00 GMT

It is always appropriate for the first post to be the customary greeting of programming.

Hello, world!