Get notified when I post a new article, software update or release. All messages will be sent in plaintext only. To subscribe, just send an email to

Fine-grained subscriptions

You can subscribe for notifications of a certain type only. Add the following words, separated by spaces to the subject field of your initial message.

  • articles — A new article is posted.
  • releases — Software updates or releases are rolled out.
  • other — Something else, which may include things ranging from like "hey, this site is closing down", to "I never sell things to my subscribers, but when I do...", to "the site is changing its domain name".
No unwanted messages, optional PGP
Your email will be kept safe out of in any DB on a 3rd party-server (given that, you trust ProtonMail at least), but rather it'll be kept in an encrypted text file that I will be accessing manually. If you'd like notifications to be encrypted, attach your public PGP-key, or if you're using ProtonMail, it'll be encrypted be default.

How to unsubscribe

The address you shall use to unsubscribe is the same, only the keyword is different: add STOP to the subject field. You may also unsubscribe from the certain categories of notifications only, in which case make subject field look something like: STOP updates other. At the same time, send STOP all or STOP will unsubscribe you from all notifications.

2 weeks

About 17 years ago I started noticing an peculiar rule, for lack of a better word, that since then had proved itself worthy of applying to various things — things both related and not related to work. Could be anything, but probably not everything. That rule is very simple: commit to it for two weeks. If it takes more than 2 weeks to learn, or get accustomed to, or, if you realize during those two weeks, it isn't serving your purposes or fulfilling your expectations — drop it.

BUT: don't make your two week commitments full of reluctant attempts you make in your spare time. If you know what time is, then you know there's very little of it to spare. This won't be a very short article, but it is worthy and something I would myself re-read. It will mostly be examples from both negative and positive experiences I had had trying to apply this rule. Perhaps, you'll be able to relate to at least one.

In the spirit of the rule, I would like to ask you to commit 10 minutes of your time to reading this article in full, going through all of the examples, whilst if you don't, you'll probably forget it tomorrow. I'm very much convinced it's not something that only works for me only — it appears to be something universal, regardless of your culture, gender etc.

Successful applications of the rule

Moving to Linux at the dawn of my career

The way I started using Linux as my Desktop OS was by installing it as a second OS onto my HDD (we didn't have SSDs back then), so I can dual boot, but I think I stopped feeling the need to boot into Windows almost completely not long after that. The first distro I picked was OpenSuse — I did try to research it as much as I could and I actually read a book on Linux prior to installing it. But at the time, I think we were still using ADSL modems; it was basically dial-up connections, but faster and your landline would not be "busy" when you were online. But Linux didn't seem to support my particular type of modem. So it was rather difficult, you can imagine: I only had one PC, and had to reboot into Windows to google the issue. I remember I had attempted recompiling the kernel (to add support for my modem) on day 2 my Linux experience — something that I haven't had the need to do ever since. But that didn't help anyway. I don't remember very well what worked, but I definitely moved to Ubuntu very soon afterwards. What I do remember, is that my transition to Linux and not ever looking back at Windows again had been done within 2 weeks. Although it did took all of my time during that period.

The text editor

After that, I needed to find a text-editor and I tried many different ones, that seemed more traditional. But eventually I just decided to try Vim and this was the first time I consciously thought of that 2 week time frame. No excuses, only use Vim and nothing else. I had work to do at the time, and, perhaps, that might have helped, rather than stressed me more, as I had even more motivation to get up to speed with Vim faster. I didn't go through Vim-tutor or any of such tools. I just started using it, slowly adding plugins that I thought were necessary. After 2 weeks, the feeling of discomfort disappeared and although by no means I became a Vim-expert (nor am I a Vim-expert now), this initial period opened up for me years and years of slow joyful exploration of this text editor.

The RSI and the keyboards

For more than 10 years, up until very recently, I was struggling with a condition that falls under the category called RSI (Repetitive Strain Injury). Battles were lost and battles were won against it. For a while, it helped to hold my arms in ice-cold water. I managed to be able to keep it in bowl of water and ice for about 3 minutes at a time, multiple times a day (I think it also took me 2 weeks to get used to, come to think of it) — ignoring the pain and extreme discomfort. But it would ease the pain afterwards, albeit not for long. A few months later, after I realized ice wasn't helping long-term, I went to see a doctor and he recommended a wrist-band — a simple thing with a metal plate at the bottom, which would prevent your wrists from making unnecessary movements and, thus, prevent further inflammation and even reduce it. I had no idea such a thing even existed. But it saved me for a few years, until it started coming back, even though I'd be wearing wrist-bands almost all of the time while at work and sometimes even when I was sleeping.

The first and less challenging part of the story of the 2 week rule application was about learning how to use a mouse with your left hand. Even though I was using Vim (and now i3wm) mouse was and still is a fundamental input device for me. So it learning how to easily switch from my left hand to the right while using the mouse without feeling discomfort or even changing button layout. Also took me approximately 2 weeks, during which I was only using my left hand for the mouse — for two reasons, really: because my right hand hurt a lot more already and, of course, to commit to the idea of learning how to use with my left hand.

This trick worked for maybe another year. I still do it to this day, when say, I'm working from the couch in front of the TV hooked up to the same PC (which I highly recommend you try — this kind of simple change from a desk to a chair sometimes works wonders for productivity).

But, "Once you get RSI, it does not say good bye" so even though I was switching hands, typing less (had to do with changes at work) and wearing wrist bands for both hands, the pain kept coming back ever so stronger. I didn't know what to do. In my desperate attempt at salvation I ordered Kinesis — an ergonomic keyboard that had the best reviews on Amazon at the time —. I knew it'd be a challenge to learn to use it effectively — I'll explain why in a moment — but following the 2 week rule and also because I literally had no other choice, but to do it, I forced myself to only type on this keyboard for 2 weeks (and I did have to write quite a bit code every day, mind you, let alone work chat-rooms all sorts of other things that come with being the CTO).

The first 2 days of using the Kinesis keyboard felt like it might as well take 2 months or more to get anywhere near my usual typing speed. That's because the keys on it are aligned vertically — unlike on most regular keyboards — so I would constantly misspell and make tons of typos: then I had to remove the word or write it again... you get the picture. But on day 3 something had changed - all of a sudden I could, with enough confidence, sense, that I felt much less pain and by the end of week 1, I could already type somewhat confidently, making a lot less mistakes. Some of the online reviews I read were saying that mastering this type of keyboard would, in fact, make you a better typist on any keyboard (which turned out to be true), this I continued with my plan. And, once again, by the end of week 2 I barely had any remnants of my pain and my typing was at the very least of the same speed and accuracy level it used to be with traditional keyboards.

In 2020 I discovered a much more interesting keyboard, which was just a tad bit more expensive, but it served the same purpose and had additional features such as: highly programmable keys, layout layers, LED-lighting (also programmable) and hardware customization options allowing for different types of keys and key-switches (never cared for it before, but now I do) when you're ordering it. The programmable feature is implemented as web-interface app which compiles the firmware once your done customizing it. You would then download it, update the keyboard's software through a small easy to use GUI app and it'd be ready to use with your personal bells and whistles. And you could repeat this process as much as you wanted.

That keyboard is called Ergodox. I think they now have a slightly more pricey re-work of the original design called Moonlander, but I never cared for it. The original version was enough. I ordered two — second one later — because I was afraid I'd spill beer or coffee over it (I did) and it would stop working (it didn't). I remember when I just got it and was trying to set it up, I almost accidentally bricked it, because I disconnected the cable during firmware update (a firmware update is how you upload your customized layout onto it). Shall I say the team and even the CEO of that small company were incredibly helpful and assisted me in resolving the issue in mere hours.

DISCLAIMER: I am NOT affiliated with Kinesis or Egrodox in any way, no one payed me to write this. In truth, the Egrodox keyboard should cost $3,000 — not mere $300 that it does. That's how useful of a product I think it is. Even if you don't have RSI that causes you pain, this keyboard will bring you joy and become indispensable.

I loved this company so much, I even contacted the founder and the CEO and offered to invest, as I had some extra money at the time. They politely refused (and probably for good reasons). But this is the kind of company I wish I founded. They are the real thing, that rare metaphorical painkiller pill, rather than a candy bar.

FreeBSD after years of Linux

Last year, I accidentally came across a series of wonderful articles about FreeBSD and other BSD systems and was eager to try them. Again, the rule was 2 weeks and I think I managed to grasp just enough in those two weeks for this interest to remain: I managed to install the system on multiple machines (onto separate drives, but still) and explore the difficulties I would face if I migrated to it and made it my permanent Desktop OS. Running it on a server was no problem at all — I've started using it on my servers almost immediately, but, of course, there are more variables you need to take into account if you were to make a certain OS your Desktop/Laptop OS.

In case you're wondering why I decided to move to FreeBSD, I think it's because I'd become frustrated with Linux: things seemed to be breaking constantly with every little update — even considering the fact that I rarely do upgrades and I'm using i3wm as my window manager. Additionally, when things did break, it took a while to find out the cause, because of how non-transparent and convoluted the booting process and the whole system in general had become. For instance, I recently tried upgrading the kernel and something went wrong, which prompted Grub to erase its configuration files. Then, of course, the system wouldn't even boot. But all I did was typing sudo apt upgrade — nothing fancier. Yet I ended up spending day and a half learning practically everything about Grub until I managed to boot my system. Me using ZFS (which is, mind you, officially supported on Ubuntu) also didn't help the case and wasted more time.

All in all, compared to booting FreeBSD — which has wonderfully written documentation and simple boot config files, (there are but 2 simple key=value text files responsible for that) — Linux now looks like a complete mess.

Unsuccessful applications of the rule


Since high-school it had always been challenging for me. I felt like a loser not being able to run more than 3 minutes without having to stop. The insides hurt. Not sure what it was, but I was not a smoker and was healthy. When I already was in college, I signed up for gym membership and before working with weights, I'd start my exercise with 5 minutes on a treadmill, running at a pace of 11km/h (6.8 miles/h). That was rough, and, suffice, to say, I had not gotten accustomed to it within the 2 weeks. But...

When breaking a rule leads to another proof the rule works

...I kept doing it. 5 days a week, every week, even when it was freezing cold and -30C outside, I'd go to the gym and run for at least 5 minutes (most of the year it was either winter time, or a season with the weather still to cold to be running outside). And so slowly and with a lot of effort, mental and physical, I brought my record time to 30 minutes (same pace of 11km/h) in about 1 year after I started running regularly. It was a milestone, but it still felt exhausting to do those 30 minutes. I wanted them to feel easy.

On my 22nd birthday, a year or so later, I set the record of 1 hour and 30 minutes running at 11km/h. Surprisingly, it didn't feel as painful as when I got to 30 minutes. Ever since I knew anything was possible. I think my eventual record in the following years ended up being somewhere around 1 hour and 45 minutes. I like to thing that's partially due to that one time when I did 1h 45m and the gym was about to close, so I had to get off that treadmill.

The more important realization came about later. When I took inevitable pauses in my exercise routine, it would, again, start to feel as if everything was difficult. I wasn't struggling with running for 5 minutes, but a 30 minute run would feel uncomfortable and not enjoyable again — exhausting me rather than energizing. But guess, what — after repeating these pauses and come-backs multiple times, I discovered that it generally took me 2 weeks (and sometimes less) to get back in shape and into my usual state of mind (because, in reality, it's the mind that was making me feel discomfort and pain). Once I had gotten used to the mere idea that each time I'd be re-starting my routine after a pause, it would only need me to have enough patience for 2 weeks, it was then that even that time shrunk to 1 week. And I would then feel discomfort if I skipped a day or two, and felt absolutely no discomfort running for 1 hour or more.

Talking about exercising in general: it didn't apply to just the running. At some point, I decided it's going to be the abs, which I never seriously worked on. Took 2 weeks to stop feeling miserable and start enjoying it and about the same amount of time to notice visible progress.


In 2020, I was forced, or, rather, volunteered to be forced to spend 2 weeks in quarantine inside a hotel room. That was hard. They wouldn't let you out almost at all. And you'd be paying for this experience out of your own pocket. I had my laptop with me of course, but I don't work on it much, because of my RSI condition I mentioned above and also because I tend not to work when I travel. I very much prefer a stationary home office — which was waiting for me as soon as I'd be released from the voluntary mandatory quarantine.

I even pre-ordered a new PC with two SSDs to make RAID-1, so I wouldn't worry about backups as much and was looking forward to set up a fresh system on this brand new Desktop PC. In terms operating systems, my frustration, for the most part, had to do with those constant upgrades and things they would break. My friend had been using NixOS for quite a while by then and had recommended I tried it, and so I finally did, while sitting in the tiny hotel room with that laptop, I installed NixOS onto the VirtualBox. On day 4 for of tinkering with it and reading documentation and forums, however, it became apparent to me it wasn't going to solve what I initially thought it would — or, at least, not as fast and at a much higher price I'd pay in time that I would have to spend learning how to do things NixOS way. To be more specific, I felt like the deterministic builds (or whatever they call them) and stability would come at a high price manifesting in the complexity of its configuration.

Thus, I decided, I needed to drop it. But time was not wasted, because during those very same four days, I also came across ZFS, learned that I could easily implement RAID-1 without any kind of requirements for the motherboard or its firmware, and that it was already working on Ubuntu 20.04. Suffice to say, by the time I was back and setting up my new PC, it took my one day to get everything up and running. And, mind you, it did require some manual configuration because I wanted both encryption and RAID-1 with ZFS (the same manual configuration would not have been required if I had known about FreeBSD and picked it, instead of Ubuntu).

But there's more to those four days...

The realization that NixOS is a "no go" made me seek for other solutions. Eventually, that led me to writing Dock, which is an alternative way of using Docker without Dockerfiles — a tool written purely in Bash scripting language. Using it every day for more than a year (I never bothered to release it until 2022) saved me days of work and countless nerve cells.

To go a bit further, I'll say that it also made me realize that Docker is far from a perfect containerization tool: my images wouldn't work on my colleagues' MacBooks, for instance. I did find a simple enough workaround for it, which I'm working on right now. But, more importantly, it all made me realize I can craft a much better solution, which would work with multiple container engines such as Podman and FreeBSD jails — all through the same set of commands. Or, alternatively I would rewrite Dock to design it as a two-layered container system for light-weight containers (where light-weight containers would be running inside one heavy VM container).1

The useful by-product of this two-layered design would be additional security. Just by its very definition, attempting to break through 2 layers (3 actually, as the first layer would be your OS) is much harder.

Do you see why I told you this long story and deviated?

Look at what came out of this 2 week rule, or, better yet, let's call this a principle (as principles are meant to be violated from time to time) — and especially out of my unsuccessful attempt at NixOS: I learned about ZFS, Docker, FreeBSD and its various tools; I wrote my own tool for managing Docker, for which I had to dig deep into Bash (it's rough, but can't say I regret it); and I even wrote a set of small utilities for everyday stand-alone usage or sourcing them into other Bash scripts — that became the BashJazz project.

All of the above came out of the 2 week principle and its sub-principle of dropping it — if, despite giving it all of your time, attention, and effort, you come to an early realization that it won't work. There is no way to lose in this game. Because it is your game. You may have it — if you want.

Oh yeah, I almost forgot. Here's a GIF so that you don't forget this principle. It also seems to serve as yet another tiny proof that 2 weeks is some kind of magic number indeed:


[1] For those few curious people reading this, I'll elaborate on the design I have in mind for a Dock re-implementation as a managed, two-layer container structure:

  1. LAYER 1: a heavy VM, native or usable on a particular OS — KVM/QEMU (Linux), bhyve (FreeBSD), xhyve (a bhyve port to MacOSX), VirtualBox on Windows (perhaps, you can recommend something else for Window to be used as the Layer 1 heavy VM engine: something that's, perhaps, faster, or easier, better yet, easier to interact with through shell scripts?). The management of Layer 1 would be automated with just a few short shell scripts — not even Bash scripts, but the original Bourne shell (#!/bin/sh) scripts or, possibly, in any other scripting language suits a particular OS better. The VM would run a standardized version of a chosen OS (I think I'll pick FreeBSD) with minimal list of necessary packages installed.
  2. LAYER 2: a light-weight container engine — native to the OS installed on the heavy VM will then be used and managed by additional set of tools — this time I'll pick Perl, not Bash for the task (because I think I really over-extended myself with the latter and went too far with it over the past year — out of principle, it now seems).

    I'd probably opt out for FreeBSD as the heavy VM guest and the FreeBSD jails as the light-weight container engine and will write the manager scripts in Perl this time. FreeBSD jails are a lot more flexible — unlike Docker, they don't have a concept of "images", and are also not tied to a particular architecture. Thus, theoritically, I would only have to distribute a few different images of FreeBSD for different architectures and/or VM engines from (1) and the light-weight "containers" would take care of themselves, regardless of the heavy VM host platform architecture.