oky is okay

A philosophy for window management

Sat, 29 Nov 2025 00:00:00 -0800

its taken me 20+ years , but i’ve finally distilled my usage of my WM down to a core set of principles that focus on efficiency and predictability.

quick spec

one window per workspace, occassionally a vertical split for two windows
direct access to any workspace via keyboard shortcuts
pinned workspaces per monitor, with [1-7] on the left, [8,9,0,\] on the right and [u,i,o,p] / [z,x,c,v] are allowed on either monitor
mouse movement is deliberate: switching to a workspace does not move the mouse
i can move the mouse or throw windows between monitors with a single shortcut

why

the main feature is the ability to summon the exact window i want and display it fullscreen

my workflow revolves around workspaces. each one holds a single fullscreen window. generally, i’ll have somewhere between ten and twenty workspaces. i’ll occassionally use a vertical split and show two windows at once.

i have pinned workspaces that only display on a specific monitor. summoning a pinned workspace will change what is shown on that monitor, but it will not move the mouse or window focus to that monitor.

this makes it really easy to call up reference material or logs on the side without disrupting whatever i’m doing in the main flow.

the rest of my workspaces are unpinned and can float to whichever monitor

keybindings:

mod-[workspace] to jump to any workspace and mod-shift-[workspace] to move a window to a workspace
mod-[h,l] to focus either monitor and mod-shift-[h,l] to move windows
mod-[j,k] to change the focused window
mod-delete to kill a window
ctrl-space to summon the quick launcher

a robozzle solver

Thu, 12 Jan 2023 00:00:00 -0800

Many years ago, a friend of mine showed me Robozzle and good times were had. Recently, I was looking for puzzles in the F-Droid store and Robozzle popped up. After doing a few dozen of them, like any good coder, I wondered: how easy would it be to automate this?

What is Robozzle, anyways?

In Robozzle, you play the part of an evil programmer who has to code the instructions for their robot to steal all the stars on a 16x12 board. Since you spent all your time in evil school instead of robot school, the robot doesn’t have many instructions: it can move forward, turn, draw a color on the board or call a routine. Each square of the board can be empty, red, blue or green. If the robot goes to an empty square, it falls off and perishes. Since the robot can recognize colors, it can be told to conditionally execute an instruction only on squares of a given color. The robot can also modify the board by coloring a square to a different color, which acts as a sort of “memory” for the robot.

An example program might be: F1: ^ R< F1 which means: go forward, turn left on red squares and then call F1 again. Surprisingly, this small set of instructions can do a lot of things.

How difficult is writing a solver?

The largest program that can be written consists of 5 tapes of 10 instructions.

So, given all of the above, how easy is it to write a program to solve a given board configuration? A brute force program would essentially be: N**K where K is the number of available operations. On a single colored board with one routine, there might be only a handful instructions: forward, turn left, turn right, call F1. However, on a three colored board, with 5 routines, the number of instructions would be: (4 operations + 5 sub funcs + 3 write colors) * 3 colors = 36 potential instructions. This is noticeably harder to brute force. In small experiments, brute force takes too long for 7 instructions on this type of board.

A Random Algorithm

Instead of brute force, we can look for smarter alternatives. One popular category is randomized algorithms. What’s surprising about randomized algorithms is that they can actually do pretty well in exploring the solution space. For my robozzle solver, I wrote a genetic algorithm that evolves and mutates candidates until it finds one that solves the puzzle.

The genetic algorithm I used is reasonably simple, it has a few features:

Evolution: the algorithm starts by spawning random candidates. It then scores those candidates and picks the top 50, mutates them and scores the parents + their mutations and trims to the top 50 again. This is called a strain.

Fitness: the scoring of a candidate is based on 2 factors: what percentage of stars are collected + the percentage of squares visited. This rewards exploring more of the board. In order to reward exploration towards stars, each tile’s score is based on its travel distance from the nearest star.

Mutation: there are 3 types of mutations: 1) over-write random spots with new instructions, 2) randomly fill a subroutine and 3) randomly swap instructions. All 3 mutation types are run on a candidate and then inserted back into the pool.

Some additional changes to the genetic algorithm were added:

Generational: a strain is evolved for 100 iterations before moving to the next strain. after 10 strains are evolved, they are all mutated at once and the genetic algorithm is run on this megastrain for 500 iterations

Fertility: In a given iteration, the higher scoring children have more children. In this tuning, the top third get 3 copies of each mutation type, the middle get 2 and the last get 1.

In order to not completely fall into local maxima, two more additional features were added:

Spawning: Each iteration has an additional set of randomly spawned children added into it.

Charity: From the losers of each iteration, a random 10 programs are chosen for mutation and added into the next iteration.

Performance

Using python, this runs reasonably slowly so pypy was used. But even that is not enough, so a few optimizations were added:

Pre-emptively trim a program that doesn’t have any forward instructions
Detect loops and end early if we get stuck in an endless loop
Don’t run a program for more than 2000 instructions
Stop trying after 2 minutes and move on

Side Note: I wrote a brute force solver in c++ and pypy and surprisingly, the pypy was comparable in performance with generating all possible permutations. This had me wracking my head for a while - I still don’t understand what’s slow in the c++ version.

A better sort of randomness

Added on: February 4th

Around 7500 solved puzzles, the solver started hitting a wall. Thinking about what could be improved, a question I had was: “can we do better than pure randomness when selecting instructions?”. A program that has “write red”, “write red”, “write red” several times in a row is not actually that useful.

Wondering about how we can generate feasible programs and not just any program, I realized we can use markov chains for picking the instruction to place in a specific position.

Using the solutions from previously solved puzzles, we can generate probability distributions of which operations are likely to follow other operations. This concentrates the solutions that are generated, allowing the solver to go through more feasible programs in the same amount of time.

To gauge the difference, I ran the solver on the same puzzle 50 times and looked at the average solve time. With markov chains, the solve time averaged 4.7 seconds vs 7.3 seconds.

Using markov chains has shown the ability to solve more puzzles, but there are still at least a thousand unsolved puzzles. These puzzles tend to use stacks and the current solver fitness function seems to be having difficulties with them. A next area to explore is how to solve stack based puzzles in a better way.

Solving even more problems

Added on: February 10th

I received an email asking me for the source of robozzle. The email writer wanted a solver that could solve some pretty hard problems. After looking at the problems and what robozlov had been failing on, it was apparent that robozlov had difficulty with stack solutions.

It took a little experimenting to come up with a fitness metric that would help solve these problems, but after a couple days, it seems that one metric has helped a little bit. Now the fitness function is a combination of:

stars collected / total stars
squares visited / total sum of squares
number of stack pops / total instructions executed

The new value, number of stack pops is essentially: how often do we exit a sub-routine. This was the best number I could come up with, but there might be a better one. If we had chosen, number of stack pushes, the solver would prioritize endless loops. We need a mechanism to reward using the stack - hence the stack pops.

With this modified solver, we can now a solve a few hundred more puzzles, but still haven’t been able to solve the originally requested puzzles.

Results

So how did the program do? After running it for ~3 days, it downloaded and solved 65.5% of the available puzzles on robozzle for a total of 6937 solved puzzles out of 10,579 total.

The first run solved ~6300 puzzles. I noticed that there was some improvements that could be made on loop detection and a second run yielded ~400 more solved puzzles - some likely by random chance and some because of the modified loop detection. A third run yielded ~200 more puzzles solved.

Jan 30th Update: The solver is now sitting at 70.5% success rate, with 7471 solved puzzles. Robozlov is sitting at 9th rank.

Feb 10th Update: The solver is now at 74.4% success rate, with 7922 puzzles solved. Robozlov is now sitting pretty at 5th rank

The scoreboard only counts puzzles that have a positive amount of likes

Comparison

Multiple other people have written robozzle solvers, but the best I’ve seen is zlejrob which has solved ~4500 puzzles as of January 2023 and is in rank 26 or 27 on the leaderboard. Tasuki wrote up their approach here

Other solvers I’ve seen are:

Zolver: a brute force solver
RobAI: an ML based solver
robozzle.py: another brute forcer

How could it be improved?

Modify the genetic algorithm to favor shorter solutions - currently the solutions always use the full puzzle length
Look at puzzles that weren’t solved well and see if there are any insights as to why
Currently, the evolution + generational iterations are hard-coded. It would be interesting to determine the “momentum” of a strain and keep improving it until we hit a wall
Combine “similar” strains into one group: if we evolve a strain and it looks similar to a previous strain, we can probably merge them
The solver tends to do poorly on solutions that have multiple functions of 10 instructions, these seem to make it stumble
It’s not clear that the tile scoring function (distance from closest star) is the best scoring function for exploration. There could be a puzzle that requires moving away from the star first that this scoring would penalize.
Analyze the “genealogy” of solutions and compare the frequency of a solution arriving during the normal strain evolution and megastrain evolution.

Closing Thoughts

This was a fun exercise over the last 2 weeks - I’ve been pleasantly surprised by the results. One thing that stuck out to me is how the terminology used affected the approach. Once genetic algorithm was chosen, the types of optimizations were influenced by the genetic metaphor. If I had chosen simulated annealing or a different evolutionary algorithm, maybe a different set of optimizations would have come out.

applications i use on gnu/linux

Sun, 26 Dec 2021 00:00:00 -0800

When setting up a new machine, I generally go through the same process: install a minimal linux OS, then add my favored applications on top of it. In this post, I’ll list the applications I tend to install and use. See this post if you want to see my history of linux usage.

Desktop

Desktop Environment: xfce4¹
File Manager: thunar
Window Manager: xmonad (my config)
Top Panel: xmobar
Bottom Panel: xfce4-panel
Notifications: dunst
Quick Launcher: rofi

Applications

Browser: firefox and sometimes chromium
Editor: vim
File Manager: thunar
Rest Breaks: workrave
Audio Control: pavucontrol
Bluetooth: blueberry
Networking: nm-applet
Movie Player: mpv
File Sync: syncthing
PDF Reader: zathura with mupdf plugin (previously evince)
Voice chat: mumble
Screenshots: xfce4-screenshooter

Development

Compiler: gcc
Interpreter: python
Reverse Engineering: binary ninja, radare2

Terminal Stuff

Shell: bash
Terminal Manager: tmux
Themes: base16-theme-manager
Terminal: xfce4-terminal
IRC/Chat: Weechat + Bitlbee
SSH: mosh
Syncing: rsync

Knowledge Management

Ebook library: calibre²
PDF library: zotero
Youtube: youtube-dl
Notes: filekasten

Writing

Blog Engine: jekyll
Markdown Language: kramdown
Doc converter: pandoc

Misc

xmodmap for setting caps lock to control key
xmousepasteblock
fzf: fuzzy file finder
z: quick directory switching

Vim Plugins

see this list

Notes

I use xfce4 because it’s somewhat lightweight and provides several session based functions I like: dbus communication, integration with printers, monitor management, etc. The applications I use from xfce4 are: xfce4-panel, xfce4-terminal, xfce4-session - but not xfce4-desktop, since I don’t need a desktop with icons. ↩
I wish I had a better ebook manager, but this one is mostly fine ↩

on LD_PRELOAD and C++

Thu, 23 Jul 2020 00:00:00 -0700

LD_PRELOAD is a way to intercept system calls issued from glibc and interact with them: modifying args, changing return values, completely exchanging implementations, etc

Some misc. things I learned about implementing preload hooks from C++:

remember to wrap the calls with extern “C” to prevent function mangling from CPP
try not to use cout inside preload functions without initializing std::iostream
you can use c++ overloading instead of C var args, which is cool!
LD_PRELOAD doesn’t necessarily cover all function invocations (f.e. system calls not invoked via glibc) - ptrace does a better job here
if you get undefined symbol errors during linking, it could be that you compiled with gcc instead of g++!
if your hooks aren’t being run, try implementing the 64 version: i.e. open64() vs open()
openat() may or may not be a systemcall - it likely calls open() or open64()

An example preload in CPY

#ifndef _GNU_SOURCE
#define _GNU_SOURCE
#endif

#include <dlfcn.h>
#include <stdio.h>
#include <stdlib.h>

// we use extern C to prevent symbol mangling for usage in LD_PRELOAD
extern "C":
  static void _libhook_init() __attribute__((constructor))
  static void _libhook_init():
    printf("INIT HOOK\n")

  int open(const char *pathname, int flags, mode_t mode=0):
    static int(*func_open)(const char *, int, mode_t) = NULL

    if(!func_open)
      func_open =(int(*)(const char *, int, mode_t)) dlsym(RTLD_NEXT, "open")

    printf("OPENING PATH %s\n", pathname)
    return func_open(pathname, flags, mode)

My gnu/linux desktop setup

Sun, 18 Aug 2019 00:00:00 -0700

Redhat years (2002 - 2003)

The first distro I used was Mandrake Linux and then Redhat linux. When I first intalled these distros, I had to use installation CDs and printed manuals to get up and running. In those days, wifi often required special drivers and we had to compile kernel modules to get the network working. Good luck if you wanted hardware graphics card support (AMD Radeon, I’m looking at you)

I used Gnome as my desktop manager, but I liked to explore new packages and bleeding edge features. I was new to gnu/linux at this point and mostly had no idea what was going on - I slowly learned that /etc/ contained configs, /home/ was user data and /usr/ was for packages installed on the system. I had no idea that packages could be compiled against different libraries and would often try to install packages I found using an RPM search website only to find out that I was missing dependencies or had a different version of the library installed.

ArchLinux (2003 - 2007)

After installing some bad packages and messing up my package tree a few times, I eventually realized that the .rpm package format was not for me and moved to ArchLinux. From 2003 - 2007, I used ArchLinux - especially since I had enough time on my hands to fix broken installs. On Arch, I tried out different WMs, including Xfce, WindowMaker and Fluxbox. Every few weeks I would customize my desktop, fiddling with backgrounds, menus and organization.

My favorite feature of Arch was the PKGBUILDs and how easy it was for the community to share packages. Having a forum of dedicated bleeding edge users was great for exploring and trying out new things.

Some of my favorite programs from this time were GkrellM, Conky, MPD and XMMS. I used gaim (later renamed to pidgin) for messaging and hexchat for IRC.

The switch to Ubuntu (2007)

In 2007, I started working full time and realized I didn’t have time to mess around with broken upgrades and moved to Ubuntu LTS. The idea was that I could install a mostly default system and not have to worry about upgrades breaking things for me.

This was mostly accurate - but at some point SystemD started taking over more and more subsystems. With each upgrade, I now had to worry that some new SystemD feature would be broken or require a config workaround. Still - I thought this was better than bleeding edge breaks. Now (in 2019), SystemD mostly doesn’t bother my life, but I am still apprehensive when I do a dist-upgrade.

The switch to Mint (2020)

Ubuntu announced they were going with snap packages for popular packages, so I started searching for my next setup. The choice was mostly between arch or Mint, but I decided to go with Mint for now.¹ So far so good, it’s similar to Ubuntu in most ways.

The current setup (2009 - Now)

In 2009, I started thinking about how to eliminate the mouse from my life (see my post on mousekips) and eventually moved to using Xmonad as my window manager with Xfce4 as my desktop.

What I like about xmonad is that I can do most of my window management tasks using the keyboard and dual monitors are well supported. There’s a simple timelessness to a minimal desktop: my rot window is all black and there’s no window decorations for minimizing, maximizing or closing windows.

My philosophy for how I use my desktop is simple: each workspace usually has one window maximized on it. This is so that I can focus on one task at a time. For web dev, I use dual pane mode: one pane is the dev tools, the other is the browser.

Work Computers (2019 - Now)

At work, I use fedora, but I still use the same setup as my home machine: xfce4+xmonad. I’ve gotten pretty good at installing and configuring a system at this point: it only takes a couple hours to bring up a fresh install with all my regularly used applications.

The future (Now - ???)

I’ve spent 10+ years with xmonad, because of how well it works for me. I’ve tried switching away every few years and always end up returning.

The main downside of xmonad for me is that the configuration is in Haskell. As someone who doesn’t know Haskell (gasp), configuring xmonad is hit or miss. I’ve been setting up AwesomeWM which is configured in Lua, but haven’t managed to get it exactly the same as my xmonad setup. There are small bumps and the defaults don’t seem to work as well as I want. I’ve also heard good things about i3, but haven’t had a chance to try it out.

Notes

I think it was because the cross compilers for arm in arch requiring a custom AUR build ↩