Dreams of a Mini Micro machine

In my previous post I explained the reasons why I like Mini Micro so much, being (for me) the right combination between simplicity and power.

But something still does not feel right when I code in Mini Micro. And it is not related to Mini Micro itself but rather to "everything else". And that while coding in Mini Micro can be an immersive experience, especially when on "full-screen", my head still knows the truth: everything else still exists. The distraction-filled complex apps and operating systems, with notifications, YouTube, tons of buttons, windows and what-not, is an Alt-Tab away. Sometimes it is very convenient (e.g. looking for information while coding, downloading some image I need for a project) but other times knowing that these things are still there, very near, kills part of the experience.

It is the same feeling I get when wanting to be in nature, walking from the streets into the near-by woods and pretending to be lost in nature, only to hear a loud helicopter passing by, or still hear the roar of the cars in a near-distant highway, or still see part of the city if there happens to be an opening between the trees. Not the same.

You want to be "free", to get "away", but the escape is not real.

That got me thinking: wouldn't it be great to have a machine where something Mini Micro (or something similar) would run exclusively? With no distraction, no other apps, windows, etc.

In my ideal world, Mini Micro would run on something like this ...

After some consideration I came to the conclusion that the most practical way to do this would be:

• Have have a Linux installation (Mini Micro runs also on Linux)
• Have a dedicated user. Log-in automatically.
• Start Mini Micro in full-screen as an "X" application.
• No desktop-environment. No other apps.
• Nothing Alt-Tab could lead you to.

Recently I tried some of the steps necessary for this on an already existing Linux installation. I tried the "start Mini Micro full-screen" part.

For that I created another user, logged in to the console, and tried to start Mini Micro directly with "startx". Something like:

startx MiniMicro.x64

This would start Mini Micro directly as an "X" app, without even a window-manager. But it would not work properly: I was not be able to type anything, and there was no mouse cursor!

To this day I don't know why, but it seems that Mini Micro, which is based on Unity, is not so "X" friendly out of the box. Firefox worked "fine", but not so Mini Micro.

While trying to find a solution to this I kept reading again and again that this kind of thing should be done through a window-manager, not directly.

I was not entirely happy, I did not want to be able to Alt-Tab to anywhere! Not even a window-manager.

Still, I decided to try. At least to see if it would work.

I worked fine with openbox, but I was still able to alt-tab back to it. But at least I knew that I needed a window-manager to make keyboard and mouse-support work.

Fortunately for me I came across a very minimalistic window-manager perfectly suited for my needs:

https://github.com/astier/xswm

From the description:

xswm is a minimal stacking and non-reparenting window-manager for X with only one task. Open every window maximized. Zero configuration required. Due to its limited scope it is very minimal and performant (~550 SLOC). No built-in:

Hotkeys
Notifications
Statusbar
Window-Decorations
Window-Switcher
etc.

It was like a godsend.

It requires you to compile it yourself, but it is extremely simple. Just "make" and that's it (it requires "sudo make" for it to install to a system-wide location; the "libX11" headers and of course a C-compiler have to be installed).

This simple window-manager would be started with

startx xswm

Upon starting it looks for an "autostart.sh" script in the location "$XDG_CONFIG_HOME/autostart.sh". Problem for me was that the "XDG_CONFIG_HOME" environment variable was not set.

I created a launch script to set the variable and perform the "startx xswm" command.

Now it worked! Keyboard, mouse, and nowhere to run to. No alt-tab, no windows menu, not even alt-ctrl-backspace working (which usually is used to kill your X session). I was happy.

But a couple of things still bothered me:

• startx was writing a lot of noise to the console
• In the X session, before Mini Micro was loaded (which took a couple of seconds) for some reason a "xterm" window would open. There the Mini Micro (or rather Unity) output / noise would be visible, and only then Mini Micro would take over the uglyness.

So I redirected all output both from "startx" and the "autostart.sh" scripts to oblivion ("/dev/null"). Still, the maximized and undecorated, but sill present xterm window would open and be visible for some seconds.

It seemed I had to live with it. But as the saying goes: when life gives you lemons, make lemonade. So, I adapted my autostart-script to write "Loading Mini Micro ...".

Now the xterm window, and the delay, served a noble purpose.

Future work

In the future I would like to have a dedicated Linux installation which would boot directly to Mini Micro (my experiment was tried in a parallel virtual console, the whole desktop-environment still living on tty7). I will try this first on an emulator before committing to real hardware.

Getting rid / hiding the initial xterm window would also be great, if possible.

If everything goes well I would like this setup to be reproducible for others. I would like to publish these steps. Not sure how yet. Vagrant? Image? Linux-distro? Instructions?

Final words

Anyway, I am now one step further pretending to have a machine where Mini Micro is THE operating system. My creativity-driven inner-child and simplicity-yearning adult are both happy.

Cheers!