Geir's Everything

Fan! Can you please shut up?

Wed, 06 May 2026 00:00:00 +0000

Why is the fan so noisy?

It’s my brand new Dell XPS 14, and the fan is noticeably, annoyingly, incessantly… there. Not really loud by anyone’s measure. But it’s there.

And thus it started. Tweaking the power profile, downloading the latest firmware, tweaking the power profile some more, waiting for new firmware… nope. Still there.

What is making it noisy? CPU is heating up. Clocked the CPU down. Still noisy. What is making the CPU busy? Lots of unnecessary processes. Shaving them off one by one. Still there.

It’s the desktop. All my Ruby scripts, the conky bar, the Ruby file manager, mutt with all my extensions, vim with my hyperlist plugin, etc. Bits here and there constantly polling, checking, fetching.

Can I fix this once and for all? Can I get the fan to shut up?

The scratch

This was the birth of CHasm and Fe₂O₃. A desktop in pure assembly, with the major applications written in Rust. The itch that needed scratching. And with Claude Code, it was actually doable.

As I write this in my vim replacement scribe, the fan is silent, the CPU sits at 36 °C, and the battery drain is around 3.5 W with screen brightness at 80 %. Two sessions of Claude Code are working away on Workspace 1 and 2 while I type this in WS6.

Nerdvana

I have never experienced a desktop this snappy and this tailored to my needs. Not only a silent fan, but keybindings that feel natural and consistent, and programs that do exactly what I need them to do.

It’s pure nerdvana.

Link to this post: https://isene.org/2026/05/Fan.html

The agency stack

Tue, 05 May 2026 00:00:00 +0000

It’s been an interesting few days with insightful comments related to my latest developments.

The sharpest pushback on my desktop post — the one about replacing my desktop with software I’d built — was a single line in the lobste.rs thread:

How is this OSS/FS promise if you have just hard locked yourself into using an insanely big subscription-based closed source software (claude)? You sure that it’s liberating?

It’s a fair charge and I want to answer it properly, because the off-the-cuff response I gave in the thread was true but incomplete.

The argument, in full

The Free and Open Source Software movement has always been about agency over the artifacts I depend on… the right to read, modify, share, and replace any program in my life. I’ve been an OSS/FS advocate since 1999, board member of EFN (FSF’s sister org in Norway) for 10 years, one of those people who organised the nerd protest march against OOXML.

So here I am, having spent the last five weeks building my desktop with Claude Code, a proprietary product from a single American company on a subscription that could change price or terms tomorrow. Have I just bought my agency back from one set of vendors and rented it from another?

I want to grant the critic their point. Yes, I have a new dependency. Yes, it’s closed. Yes, if Anthropic disappears or goes hostile or just gets boring, my flow of new tools stops. That’s a real cost.

But I think the framing of “agency or no agency” misses how agency actually stacks.

The stack was never clean

Pull on any thread of “I’m using free software” and you find proprietary fibres a few layers down. The Linux kernel runs on a CPU whose microcode is not free. The keyboard firmware in your laptop is not free. The display panel’s scaler is not free. The fab process that made the silicon is locked behind a forest of trade secrets. Even Stallman’s GCC was, for years, bootstrapped with whatever compiler was at hand on the host system — sometimes proprietary.

OSS/FS has never delivered a fully free stack. What it has delivered, consistently, is more agency than you had before, in the layers where agency was reachable. The question was never “is this entirely free?” — it was “is this freer than the alternative?”

By that test, my desktop today has more of my agency in it than it did six months ago, not less. The window manager, terminal, editor, file manager, mail client, calendar, RSS reader, music tool — every one of them is something I can read end to end, modify in an afternoon, and redistribute under the Unlicense if anyone wants. They live in two sister suites: Fe₂O₃ (the Rust half: editor, file manager, browser, mail, calendar, astronomy, and so on) and CHasm (the x86_64 assembly half: shell, terminal, window manager, status bar, screen locker, font rasterizer). Claude is a single new layer in the stack, and it’s the layer furthest from my final artifact.

If Anthropic vanishes tomorrow, I lose the ability to generate new code as fast as I’m generating it now. I do not lose:

The code itself, all of which is mine.
The right to modify it by hand, the way I would have anyway in a pre-LLM world.
The patterns I’ve learned by walking through these designs.
The ability to switch to whatever LLM tooling comes next — open-weight or otherwise.

The artifact is the thing. The artifact is mine. The toolchain that produced it is rentable, and I’m renting it.

The compiler argument

I frame it like this: an LLM is a compiler.

When I write Rust, I don’t write the machine code. I write Rust, and a compiler turns it into instructions the CPU can run. The compiler is a trust layer — I trust it to translate my intent faithfully. Most of human software development has lived inside this trust assumption, and most programmers do not write their own compilers.

When I write a prompt to Claude Code, I trust it to translate my intent into Rust. It’s a higher-level compiler. The trust surface is bigger, the failure modes are weirder, and the licence is proprietary. But the shape of the dependency (“I trust this tool to translate”) is one we’ve always had with our toolchains.

If LLMs were on a public-domain compute substrate tomorrow, I’d switch. Until then, the same calculation that lets us run gcc-on-Intel applies: use the freest tool that gets the job done, and don’t pretend the stack is purer than it is.

What’s actually at risk

The honest answer to “what do I lose if this goes wrong?” is this: I lose velocity, not possession.

If Anthropic decides scribe should not exist, they cannot un-publish the source from my disk. They cannot make my running editor stop running. They cannot revoke my understanding of how the code works. What they can do is stop being a useful collaborator, at which point I revert to writing code at human speed, the way I did from 1978 to 2025.

Velocity is real. Five weeks of LLM-paired work is years at solo human speed (my speed). If the rate goes back to solo-human, I will ship less new stuff per unit time. But the existing stuff doesn’t move; my tools keep working; my muscle memory keeps applying.

This is a different trade than, say, depending on a closed cloud service whose servers hold the only copy of my data, or a SaaS app whose contents disappear when the subscription lapses. The proprietary tool is upstream of my work, not containing it.

Why I’m OK with the trade

A purist position is available: refuse to use any closed tool, build everything on free-software foundations, accept the slower pace as the price of consistency. I respect that position. I’ve taken something like it for most of my life.

I think it’s the wrong choice for me, today, because:

The agency I gain at the artifact layer is enormous and immediate.
The agency I cede at the toolchain layer is bounded — I keep what I produce, and the worst case is “develop slower again”, not “lose my desktop”.
Open-weight LLMs are improving fast; if Anthropic gets unbearable, the alternatives will likely be ready.
The asymmetry is in my favour: a few weeks of subscribed compute bought me decades of compounding personal-fit improvements.

The alternative — wait for the perfect free-software stack before using anything imperfect — is the same logic that kept Linux desktops perpetually “almost ready” for thirty years. At some point you have to build with what’s in the room.

The bigger point

OSS/FS was never a destination. It’s a direction. More agency, more often, in more layers than yesterday.

By that measure, my desktop has more freedom in it now than it did before I started talking to a closed model. While the model is closed, the the result is. And the result is what I live inside.

If the model becomes free too, even better. If it doesn’t, I still own the desktop.

I think that’s the right way to keep score.

An audience of one - by the numbers

Mon, 04 May 2026 00:00:00 +0000

The previous post made a case for building your own desktop. The argument was philosophical: removing multi-user accommodation eliminates substantial complexity. This post is the tally.

The bottom line, before the details: +3.5 hours of battery time on my Dell XPS 14, a fan that is mostly silent, and a terminal stack that fits in 691 KB instead of 109 MB.

All numbers below come from the actual binaries on my XPS 14 today, measured against the upstream tools they replaced. Every CHasm binary is pure x86_64 NASM with zero shared libraries and every Fe₂O₃ binary is Rust on top of a small shared library called crust.

Binary size

The terminal stack — shell, terminal emulator, window manager, status bar, pager — is the part of the desktop that runs all the time. Here is what that costs in CHasm versus what it cost before.

Layer	Before	Bytes	After (CHasm)	Bytes
Shell	bash	1,540,520	bare	168,232
Terminal	kitty (binary)	207,496	glass	191,208
Terminal (full)	kitty.app bundle	109,270,888	glass	191,208
Window manager	i3	580,800	tile	82,616
Status bar	i3bar	122,160	strip	34,744
Bar content	conky	1,019,056	asmites (×16)	159,488
Screen locker	i3lock	59,864	bolt	30,528
Pager	less	245,256	show	41,144

CHasm core total (bare + glass + tile + strip + asmites + bolt + show): 707,960 bytes = 691 KB.

The kitty comparison is the headline number. The kitty binary is small because it is a launcher; the real workhorse is ~/.local/kitty.app, which contains a bundled Python 3.14 runtime, HarfBuzz, pixman, GLib, SQLite, and 107 shared objects. 109 MB total. glass replaces it at 191 KB with zero shared objects, including a TrueType / OpenType rasterizer (glyph), color emoji via CBDT, variable fonts, synthetic italic/bold, and full Unicode beyond the BMP.

That is a factor of 571× smaller for the user-visible terminal feature set I actually use.

Dynamic linking

Tool	`.so` dependencies
bare	0
glass	0
tile	0
strip	0
bolt	0
show	0
chasm-bits (each)	0

bash	2
kitty (launcher)	6
kitty (bundle)	107
i3	55
i3bar	46
i3lock	32
conky	51
urxvt	43
gnome-terminal	80
vim	86

Every CHasm binary is statically linked. Nothing in /usr/lib can break my terminal at boot. Distribution upgrade churn no longer reaches the desktop.

The Fe₂O₃ side

The Rust tools are not micro-optimised for size in the same way. They opt into a shared crust TUI library and link libc like any normal Linux program. They are still small.

Fe₂O₃ tool	Bytes	Replaces	Predecessor bytes
scribe	2,939,560	vim	5,609,800
pointer	4,240,680	ranger	4,866,877

scribe replaces vim at half the size and pointer replaces ranger with a lot more functionality, both on top of a crust runtime that several of these tools share. scribe is much, much faster in handling HyperLists than vim+hyperlist.vim could ever be.

Startup

“Shell startup” can mean two different things and the smaller number tells you nothing about the bigger one. Quoting both, from the bare README, both shells on the same machine:

Interactive prologue — execve to “ready for the first keystroke”, with history, tab completion, and syntax-highlighted prompt initialised:

$ ./bare --bench
bare startup: 9 microseconds

Non-interactive whole-process — echo cmd | shell > /dev/null, i.e. spawn shell, parse one line, fork-exec the command, wait, exit. This is the right number for using a shell as a pipe target or script interpreter. 1000 iterations each:

shell	`echo true \| shell`	`echo ls \| shell`	syscalls/invocation
bash	2.5 s	4.5 s	26
bare	2.1 s	4.5 s	14

bare wins the minimal benchmark (~17% faster) and ties on the realistic one where the spawned command’s own work dominates. Half the syscalls per invocation, no dynamic linker, no .bashrc parse. Same binary in both rows; bare detects isatty(0) at startup and gates history, PATH exec-cache, and prompt-state init behind it.

None of that matters if you only ever start a shell once a day; all of it matters if you fork shells from inside a status bar refreshing every 4 seconds, because that is 86,400 forks/day per segment at 1 Hz, the reason CHasm’s status bar segments are tiny static asm binaries (“asmites”) rather than shell helpers.

Resident memory

Captured from /usr/bin/time -v on cold runs of <shell> -c exit:

Shell	RSS
bare	392 KB
bash	3,700 KB
zsh	4,200 KB

bash and zsh sit at roughly ten times the resident-set size of bare on a no-op invocation. Again: irrelevant for one shell, decisive for hundreds of helper invocations per minute.

What this buys

I did not set out to make small binaries. I set out to make a desktop that fits the way I work. Small binaries are what falls out of the process when the design rules are:

No wasted CPU cycles. Every feature has a config flag and an early-return fast path. A “for some users” feature that runs unconditionally for everyone is waste.
Lightning fast. No interpreters in the hot path. No awk, sed, perl, or python in shell helpers, just builtins or asm.
More battery life. Anything that polls, wakes, or spawns a subprocess on a timer is suspect. Prefer inotify to sleep 1; check. Prefer stat() to fork().

A stack that is 691 KB total with zero shared libraries is what those rules look like applied to the terminal layer. A 109 MB Python-bundling terminal is what they look like ignored.

Why assembly, then?

A fair reader question after seeing the previous post on Hacker News. Assembly is not chosen for purity or for the romance. The romance came after. Assembly fell out of the rules above the same way the small numbers did. There is no library tax. There is no runtime to warm up. Each instruction has a cost I can see and a behaviour I can predict. When the rule is no wasted CPU cycles, working at the level where every cycle is visible turns out to be the lowest-friction place to enforce that rule. Rust would also have worked for most of the stack. It is what powers the Fe₂O₃ side. Assembly was the right tool for the layer that runs all the time.

Caveats

Feature parity is not 1:1. kitty has graphics protocol, ligatures via HarfBuzz, and a configuration language. glass has none of those. glass has variable fonts, CBDT color emoji, and a 191 KB binary. But the fonts render just as nice with the assembly glyph engine doing the font job.
vim has 35 years of plugins. scribe has 72 hours of me. The comparison is “the editor I use” against “the editor I used to use”, not feature counts.
I do not recommend any of this for anybody else. The whole premise of the previous post was that the audience is one. Building for one is not the same as not sharing. All the sources are public. Take what is useful, ignore the rest.

The small print

All binary sizes from stat -c%s on 2026-05-03. Shared-object counts from ldd | grep -c '=>'. Startup measurements from 1000-iteration loops on the 2026 Dell XPS 14 (the model that shipped in early January this year). Measurements that risked perturbing my running session, interactive terminal startup and live RSS of foreground processes, were skipped. The CHasm sources are at github.com/isene/chasm; the Fe₂O₃ sources at github.com/isene/fe2o3.

Ja, vi elsker — a heavier take on the anthem

Sun, 03 May 2026 00:00:00 +0000

I put my own spin on Ja, vi elsker — Norway’s national anthem — and pushed it a couple of notches harder than the brass-band version you usually hear on the 17th of May. Out on Spotify now.

Find me on Spotify as Geir Isene. The full back catalogue is on the Music page.

A desktop made for one

Sun, 03 May 2026 00:00:00 +0000

For the first time in twenty-five years I’m sitting in front of a computer where almost every program I touch was designed by me. One tool at a time, the off-the-shelf option got swapped out for something a little closer to how my hands wanted to work. (I wrote about the start of this a couple of weeks ago — that post laid out the early swaps; this one is the view from the other side of the journey.)

It’s been a crazy few weeks guiding Claude Code inbetween all the other stuff I’m doing in life. I direct CC, it works while I do other stuff. I get a second or few in between tasks, and I respond. Then off it goes adding features or hunting bugs.

Two suites in a happy marriage: CHasm, the bedrock — pure x86_64 assembly, no libc, the layer that paints pixels and reads keys. Fe₂O₃, the application layer in Rust, sitting on a small shared TUI library called crust.

The CHasm layer (assembly)

Role	Was	Now
Window manager	i3-wm	tile
Status bar / tray	i3bar + conky	strip + asmites
Screen locker	i3lock	bolt
Terminal emulator	kitty	glass
Login shell	zsh → rsh	bare
File viewer	less	show

The Fe₂O₃ layer (Rust on crust)

Role	Was	Now
Text editor	VIM	scribe
File manager	ranger → RTFM	pointer
Email / RSS / chat	mutt + newsbeuter + various web logins	kastrup
Calendars	Google + MS web	tock
Astronomy panel	astropanel	astro
Movies / series	IMDB-terminal	watchit

What’s left? WeeChat for IRC and other chats. Firefox — the only GUI program I still use regularly. That’s it. Everything else is mine.

The vim line

Let me get a bit sentimental about vim, because vim was the one I thought I’d never replace.

I started using it in 2001. For twenty-five years, every email I wrote went through vim. Every article. Every blog post. Every line of code, every HyperList, and every book. It was the one tool I would have called part of how I think. The muscle memory was so deep that I’d open random text fields in browsers and ended with typing :w.

Then in three days I had scribe and stopped using vim.

The first commit landed at 00:09 on May 1st. By afternoon today (May 3rd) vim was replaced. Twenty-five years of muscle memory rerouted in seventy-two hours.

Vim is wonderful, but scribe is mine. It’s modal like vim, but missing the ninety percent of features I never used, and carrying the handful of writer-shaped tweaks I always wished vim had. Soft-wrap by default. Reading mode with Limelight-style focus. AI in the prompt without leaving the buffer. HyperList editing with full syntax highlighting and the encryption format the Ruby HyperList app uses. Persistent registers shared across concurrent sessions is a cool feature. None of it revolutionary, but all of it shaped to my exact workflow. And whenever I think of an enhancement I want, it’s just minutes away. It used to be waiting for months or years or forever for some developer to get the same idea as mine and introduce it into the tool I use.

Why this is possible now

It used to be that writing your own editor, your own file manager, your own window manager, was a project of years. I know, it took me a few years to get RTFM right. A serious undertaking with a serious cost. The economics of it didn’t work for most people, even programmers. You’d touch a piece of it, get most of the way, run out of weekend, and go back to the off-the-shelf tool.

That barrier is much lower now. With Rust, CC as the workhorse, and the fact that the hard problems of TUI programming have been documented to death… the cost of “build the tool you actually want” has fallen by orders of magnitude.

I don’t think this is a story about AI or about Rust specifically. Both helped. But the deeper point is that the gap between “I wish my editor did X” and “okay, here’s an editor that does X” is now small enough to fit inside a few evenings of focused work.

I’m not selling anything

I should say what this post is not.

It’s not an invitation to use my software. Honestly, please don’t. None of it is built for you. It’s built for me — for the way I hold my hands, the way I think about email, the way I want my calendar to render. I’m sure other people would find a hundred sharp edges I’ve never noticed because they happen to align perfectly with what I do.

It’s also not a request for kudos. The code isn’t novel, nor are the ideas. There’s nothing here that hasn’t been done before by someone with more taste, discipline or talent.

What I want to do is show one specific thing: it is now genuinely feasible to make a desktop computing environment that fits one person. Instead of a configuration of someone else’s tools. This is no longer a heroic decade-long undertaking. This is an actual, weekend-by-weekend, “this thing in my life now does exactly what I want” replacement.

The joy of an audience of one

The best part of building for myself: the relief of not having to care.

I don’t have to think about configurability for someone with different preferences. And I don’t have to support corner cases I’d never personally hit. Nor do I have to write documentation for users who don’t exist. No more arguing on issue trackers about whether a default is the right default — of course it’s the right default, it’s the one I want.

The editor’s \? cheatsheet shows the keys I memorised, in the order I prefer, with the bindings I think are sensible. Arrogance? Nope, it’s design without committee. The audience is one person. Decisions take seconds.

It turns out an enormous amount of software complexity comes from accommodating users who aren’t you. Strip that out and what’s left is small, fast, exactly-shaped, and a quiet pleasure to use.

So

If you’ve ever caught yourself thinking “I wish my editor / file manager / status bar / shell just did this one thing differently” and you’ve been told the answer is to write a plugin, learn an obscure config language, or accept the way it is, then consider that the third option is more available than it used to be: Build Your Own Software (BYOS).

You probably won’t replace your whole desktop. I didn’t plan to either. But the satisfaction of having even one tool in your daily workflow that fits you exactly is worth a weekend.

I’m a rabbit in spring :)

A desktop that bends to me

Fri, 01 May 2026 00:00:00 +0000

Three weeks ago I posted about bare, my login shell in pure x86_64 assembly. It was the start of a sprint. Now the whole stack is mine.

bare is the shell. glass is the terminal emulator. tile is the window manager. strip is the bar. show is the file viewer. bolt is the screen locker. All in x86_64 assembly. Single static binaries with no libc or any bloat and with minimum CPU cycles. Built with Claude Code over a few evenings. The CHasm suite.

The Rust side, Fe2O3, absorbed almost every other tool in my daily use. RTFM became pointer and then the rest of my Ruby tools became fresh and rusty; kastrup, tock, astro, scroll, watchit. Each is a static binary, snappy like a rattlesnake and uses memory I can count on one hand.

The only GUI program I regularly run now is Firefox.

A laptop on full battery now lasts more than three hours longer than it used to. The fan is mostly silent. Cold-start times are gone since everything is already warm by the time my finger leaves the Enter key.

I had a chat with Claude about the typical pushback when I tell people that I built my daily-driver tools with AI. The pushback comes in flavours: “I don’t trust AI code”, “yeah, it can prototype, but how do you maintain it?”, “what’s the fun in that?”, “but, but you didn’t actually make it!”.

These all miss the same mark.

I never wrote kitty. I never wrote i3, or zsh, or vim, or Firefox. I ran them for years and never asked who wrote them or how. I cared whether they worked, whether they fit how I think, whether I could lean on them. The authorship question never came up because I had no alternative.

But I got tired of subtly adapting to how applications work. Someone wrote it a specific way, and it may be highly configurable, like the i3 window manager. But it was never exactly like I wanted it. Almost, but not on the mark.

What changed is not who writes the code. It is who has agency.

For three decades the tool was the fixed point and I adapted to it. I learned its quirks, accepted its compromises, built habits around its limitations. Now the tool bends to me. When tile annoys me I describe the annoyance and tile changes. When glass needs a sequence it does not handle, it gets one before the tea water boils.

And when it comes to maintenance… we have done lots. Five bolt bugs found via diagnostic logs I cannot read on my own (machine code), patched, retested, committed, tagged, all in a short stint. The loop is tighter than most teams manage with a full-time engineer on payroll. I read the symptoms. Claude reads the code. We converge.

The “but you didn’t make it” critique falls apart the moment you remember most people are running thirty years of code they didn’t write either. They just had no agency over it. What changed isn’t the authorship question, it’s the agency question.

This is not me telling you to do the same (you could if you just clone the repos for inspiration and let Claude Code go at it to make it how you want it). The point here is that it fits one shape, mine. If your shape is different, build differently. Or do not build at all and use what works.

I am writing this down because the transition has been strange and the strangeness deserves a note. I have been a tweaker since 1999. The tweaking has finally caught up with the tools. There is nothing left to compromise on. That is a quiet kind of luxury.

The next quirk will surface. It looks like it’s going to be replacing my most beloved tool of all: VIM. Time for a better text editor. For me.

My tools - all vibecoded

Thu, 23 Apr 2026 00:00:00 +0000

From 1978 until summer last year I had been programming in 30+ different languages, including Assembly and lots of Ruby. Then I got going with Claude Code (CC). Since then I have ported most of my Ruby tools to Rust and then started moving my most basic tools over to pure Assembly. I haven’t typed code in the past 9 months.

I am a long-time tweaker of my setup. Running Linux since 1999, I used to search extensively for the right tools to match my needs; VIM, i3 window manager, kitty terminal, conky, etc. I managed to tune my setup to fit me almost perfectly. Almost. I subtly adapted to the software, changing the way I would ideally work to work the way the software would let me.

I went from using Ranger as my file manager to writing RTFM to have it exactly the way I wanted it. Years of hand-coding Ruby. Then came a rush of applications, still hand-coding like mad; rcurses, astropanel, IMDB, rsh, and many more. While I love Ruby’s elegance, it is slow. And being a performance junkie, I decided to let CC loose and port my main Ruby tools to Rust with amazing speed boosts.

But that wasn’t enough. I still had stuff I wasn’t totally happy with and that still could use a speed increase. And so I got CC to churn out “bare” as my new login shell - a port of my Ruby Shell. I posted a link to lobste.rs about that that got some interesting reactions.

The resulting Assembly shell is a 150Kb executable with a 9 microsecond startup time.

But a super-fast shell in a slow terminal? I know kitty hacks speed with running in single-instance mode, but even that can be made to go faster (and the single instance mode of kitty does have some drawbacks). And so glass the terminal emulator was born.

How about a faster window manager that is tailored exactly to my needs? Yup, with CC anything is possible. Say hello to the new window manager, tile. And its companion strip (a replacement for i3bar and the like).

This makes my window/terminal/shell experience lightning fast with no wasted CPU cycles and minimum memory footprint. This has boosted the battery life of my Dell XPS14 laptop by a few hours (the noisy fan is mostly quiet now). The setup is doing precisely what I need it to do. And if I need something changed or new features, then that is only a prompt away and some minutes of tweaking.

The whole stack in a single screen: tile holding the layout, strip + asmites (the per-segment programs in chasm-bits) along the top status row, glass in every pane (with pseudo-transparency picking up the wallpaper), bare behind every prompt, and show rendering syntax-highlighted source in the left and bottom-right panes. Every binary in that picture is pure x86_64 assembly talking straight to the kernel and the X server. No libc, no toolkit, nothing in between.

My central apps like pointer, kastrup, tock and nova can stay as single-binary executables written in Rust. They are fast enough (for now).

From what I can research, nobody has previously built shell, terminal emulator, and window manager in pure x86_64 Linux assembly. And it was done in about two weeks.

This is a whole new world where I command my own environment in ways that was completely out of reach back in 2025. I foresee the death of software as we know it where people use general purpose apps. I expect AI to craft tailor-made solutions for anyone with the imagination to ask for it.

Making others feel good

Wed, 15 Apr 2026 00:00:00 +0000

Siv reminded me of something important a couple of weeks ago; “It is more important to make the other person feel good than it is to be right.” This was reinforced by a couple of comments by Morten Lind-Olsen the other day.

This can be debated, and you can easily find counter-examples. But let it sink in just a bit. If the other person is not feeling good, then any right you may have or be, will not make much impact. A person needs to be receptive to receive.

It’s in line with this quote from Wayne Dyer, “When the choice is to be right or to be kind, always make the choice that brings peace.”

And this attributed to Lao Tzu, “Let go of your attachment to being right, and suddenly your mind is more open. You’re able to benefit from the unique viewpoints of others, without being crippled by your own judgment.”

Or from Scooter (originally John Templeton), “It’s nice to be important, but it’s more important to be nice.”

Peace.

Free Will; TEG released

Sun, 12 Apr 2026 00:00:00 +0000

After more than 40 years of research into Free Will and Mathematics, I have released my work on Trans-Existential Grounding (TEG).

The academic paper was accepted on PhilPapers, marking a step toward a popular science book, “The Freedom Proof”.

I’ve written several articles on Free Will over the years, including the OnePageBook. But last summer I got the real breakthrough. Since then I’ve been busy formulating the mathematics and ensuring it is sound, and in parallel writing the upcoming book.

The academic paper is mathematics-heavy, while the book takes a very different approach. It focuses on the reason for existence, your choices and personal responsibility.

Stay tuned for progress on this project.

My Login Shell in Assembly

Thu, 09 Apr 2026 00:00:00 +0000

Three shells. Three languages. One obsession with going deeper. And faster.

I started with hand-crafting rsh. Written in Ruby over a few years. Now 4,048 lines, full-featured, comfortable, slow. 300 millisecond startup. Fine for a scripting language, frustrating when I open lots of terminals in quick succession.

Then I decided to rush to the next level. Rewriting rsh in Rust. Rush has 4,280 lines, same feature set, 26 millisecond startup. Part of the Fe2O3 suite of Rust terminal tools. Fast, but still loading a runtime, linking against libc, initializing a memory allocator.

The question became, “what if there was nothing between my keystrokes and the kernel?”

bare

bare is an interactive shell written entirely in x86_64 Linux assembly.

While I have written my fair share of assembly through the years (even raw hex coding), my projects have mainly been on the coconut processor, and never on x86. In just 4 evenings with maybe 6 hours total of coding with Claude Code, bare became my login shell.

This shell has no libc, no runtime, no dynamic linking. Pure syscalls. The binary is 126KB and starts in 8 microseconds.

$ ./bare --bench
bare startup: 8 microseconds

The numbers

	rsh (Ruby)	rush (Rust)	bare (Assembly)
Language	Ruby	Rust	x86_64 ASM
Source lines	4,048	4,280	13,366
Binary size	~15MB (interpreter)	2.6MB	126KB
Dependencies	Ruby runtime	libc, 8 crates	none
Startup	~300ms	~26ms	8µs
Dynamic linking	Yes	Yes	No

bare is 3.4x faster than bash on per-invocation CPU time and 27x faster than rush. The binary is 21x smaller than rush.

What you get

bare is now my daily login shell. It has:

Dynamic prompt with git dirty indicator (green/red dot, no fork needed)
Multi-pipe, redirections, command chaining, background jobs
Command substitution $(cmd), brace expansion {a,b,c}, globs [a-z]
Nick aliases, global aliases, abbreviations (expand on space)
Interactive tab completion with LS_COLORS and cycling
Ctrl-R history search, inline suggestions, prefix filtering with Up/Down
Alt-F/Alt-B word movement
Job control (Ctrl-Z, fg, bg)
6 color themes, 18 configurable colors
Syntax highlighting while you type
Config file auto-saved on exit
Plugin system (any executable in ~/.bare/plugins/)
AI integration via plugins (:ask, :suggest)
time builtin, --bench flag
Session save/load, calculator, command stats, validation rules
Companion TUI configurator: bareconf

Everything is coded with direct kernel interaction. Every read(), every write(), every fork(), execve(), pipe(), dup2(), wait4(), ioctl() is a raw syscall instruction. No wrappers, no abstractions.

The details

The entire shell is one assembly file: bare.asm. NASM syntax. Every feature that other shells delegate to libraries, bare implements from scratch:

Terminal control: raw mode via ioctl(TCSETS), character-by-character input
Line editing: cursor positioning with ANSI escape sequences
Tab completion: opendir + getdents64 syscalls to scan directories
Git branch: reads .git/HEAD directly, walks parent directories
Git dirty: compares stat() mtimes of .git/index vs ref file
History: file I/O with open/read/write syscalls
Job control: fork, wait4 with WUNTRACED, manual SIGSTOP
Config: hand-rolled line parser for ~/.barerc

The BSS section allocates all buffers statically. No heap, malloc or brk. The kernel zero-fills BSS pages on demand.

The journey

Going from Ruby to Rust was about speed. Going from Rust to assembly was about obsession and a dose of nostalgia and seeing what is actually possible with AI coding.

When you write a shell in assembly, you learn exactly what a shell does. There’s no std::process::Command. There’s fork() returning in two processes and you handling both. There’s no crossterm::terminal::enable_raw_mode(). There’s a 60-byte termios struct and an ioctl number.

Every bug teaches you something about Linux. A segfault from writing to the text section. A hang from SIGTTOU when the process group doesn’t own the terminal. A crash from $ being a NASM keyword, not ASCII 36. All of these and more Claude and I had to get and debug.

Try it

git clone https://github.com/isene/bare.git
cd bare
make
sudo make install

Or grab the .deb from the releases page.

Set it as your terminal shell and feel the difference. You probably don’t need 8 microsecond startup. But there is something satisfying about a shell with nothing between you and the kernel.

CHasm

bare is the first project in the CHasm suite (CHange to ASM). Because sometimes the right answer to “can we make it faster?” is “remove everything.”

Link to this post: https://isene.org/2026/04/Bare.html