Ne v kontakte Asocial programmer's blog

Last year I spent more hours playing Minecraft than I care to admit. Being an introvert that I am, I play on a small private server with my partner and a few friends, and Minecraft Realms has been a great hosting for us, fast, cheap, secure, with backups. The only issue — it can’t have mods, and eventually we wanted to play with mods. After shopping around for hosting services and trying a couple of them we came away mildly disappointed: they were either very slow, or very expensive. I decided that I will simply move the server to my former gaming laptop, which has been sitting idle for the last year or so. It had plenty of power and, most importantly, RAM, while being fairly energy-efficient. The cost of electricity running it 24/7 was a couple of times smaller than a comparable hosting.

My twitter feed be like:

Blockchain! NFTs! Distributed governance! Get rich quick!

We all know NFTs with URLs to someone’s HTTP server are silly¹. True cryptopunks store everything in blockchain directly! So how much would it cost me if I immortalized this blog in the Ethereum blockchain? Think about it! All my typos and rants immutable and preserved forever, that’d be cool!

Disclaimer: I have no idea what I’m talking about. I never actually used Ethereum for anything, and all I know about it I’ve learned in a couple of hours of random googling.

… or how to sell Chaos Engineering to your team when everything is already on fire.

This post is once again inspired by a discussion in DevZen podcast, episode #309 (for russian speakers, I highly recommend listening this one, lots of 🔥 discussions) and the Chaos Engineering book.

In the podcast, @sum3rman brought up an excellent point that most teams don’t reach a stage when their product is “too stable” and they need to introduce faults deliberately. Many more teams are actually in a semi-permanent dumpster fire state and claiming that breaking it even further will somehow help is gonna be a though sell.

Recently I found my old Eee PC 901 at the bottom of a drawer sitting and collecting dust. It served me well a decade ago and I still have fond memories of it, but by modern standard it’s really obsolete as a laptop. With Intel Atom N270 and 2GB DDR2 RAM at its heart, I’m not sure it’ll win over even Raspberry Pi 4. Yet it is in a good working condition, and I couldn’t bring myself to discard it into the trash bin.

At a peak of its popularity Eee PC family was very popular in the hacking/modding community, so I went on to see if there’s something cool I can do with it. I’ve never really messed with hardware before, so even if it doesn’t work out, I’ll learn something useful from it.

In this post I’ll document interfaces that exist on Eee PC 901 motherboard and present interest for modding. Kudos to the Eee PC community who reverse engineered all of this, I’ll try to cite original sources to the best of my ability, but internet archeology is hard, so apologies if I misidentify any.

Ultimately, the most useful sources were the ASUS original motherboard schematics and component layout, which you can find with a little bit of googling. I also relied heavily on postinga at eeeuser.com (down and gone, but mostly available through web archive), eee-pc.ru (which is also frequently down) and jkkmobile.com. Some specifics about supported protocol versions were found in Intel Atom N270 datasheet and Intel ICH7-M datasheet (south bridge). I also found helpful notes at ivc.no 1, 2, although they focus on Eee PC 701.

Trigger warning: If you have strong opinions about Ops, DevOps, SRE and adjacent subjects, read this at your own risk.

A bit over 4 years ago I’ve accepted a job offer with the “Site Reliability Engineer” title, and at the time I had no clue what it really was about. The recruiter said it was kinda like a normal Software Engineer, but more about infrastructure, and that was all. Since then people wrote countless posts, gave dozens of talks, literally published whole books about this job, and yet the industry in general has no clue what the fuck SRE means. Okay, maybe SRE still new ¹, but DevOps has been popular for a decade and people still get it wrong 🤷

So let’s set the record straight, shall we?

First of all, every modern organization needs IT Operations (Ops for short) these days. Computer systems are complicated enough to require a specialized professional to run and maintain them. This role’s purpose is to take existing components (software and hardware) and make them work together to solve business’s problem. Even though Ops usually isn’t about creating new components, this is really a jack-of-all-trades role and they can do anything IT.

Depending on the scale of the organization, Ops can branch out into more specialized roles such as Hardware Ops, Network Engineers, System Administrators, be that in-house or outsourced. Contrary to the popular opinion, coding skills often play a big role in these jobs, for example in integrating different systems, task automation, etc. And yeah, all those folks are “real engineers”, oftentimes more real than “software engineers”, but I digress.

Simplicity is complicated. In the Golang community, this statement is most often attributed to Rob Pike but it turns out a lot of people said something like that. A couple of weeks ago I encountered this yet again in a debate with a colleague (someone with lots of experience and whose opinion I respect a lot). Both of us considered ourselves advocates for simplicity, yet we were leaning towards radically different technical approaches. Both, of course, were sure that our own solution is much simpler than the other, and even had a good set of technical arguments to support that.

Without going into too many details, we needed a bunch of small business logic snippets executed ever so often against a certain dataset. The whole thing was supposed to be pretty small and simple (no high-load, out of the critical path, latency insensitive, etc.), so the main concern was to minimize maintenance and debugging effort. In this particular case, the language was Go, but frankly, this can be applied to any language.

Not so long ago I’ve discovered FSEconomy, an economy meta-gate for flightsim fans. Despite of somewhat simplistic core mechanics and unfancy look, it has a very active community and a lot of depth to it. I’ve spent last couple of weeks reading the manual, watching community forums and doing some assignments in the game itself. And the more I was learning the more questions I was having: where to fly? Which aircraft? Rent, buy or lease? What about FBOs? How to find the best assignments? The manual and community forums have some advices, but I want more definite answers.

I mean, staying net positive is not so difficult, but being efficient is a whole another story. And I want to be as efficient as I can. Luckily, FSE offers a treasure trove of data to support decision-making in a form of data feeds. So I armed myself with Python and spend a few evenings getting some answers.

Since I’m still quite a noob in this game, my high-level plan is this:

1. Find the most efficient way to build up initial capital without owning any assets.
2. Find out which assets (FBOs or aircraft, which ones) would provide the most significant cost reduction.
3. Invest and explore less involved methods of gaining revenue: rent/lease business, FBOs and all other fun.

Recently I’ve stumbled upon a code snippet in my C++ code, which I’d call “comment branching”. For example, you are experimenting with two implementations of the same functionality represented by a relatively small pieces of code and you need to switch between them back and forth until you decide which one will end up in final version.

Consider following snippet:

1
2
3
4
5
6

long number = 1024;
//*
std::string number_str = std::to_string(number);
/*/
std::string number_str = boost::lexical_cast<std::string>(number);
/**/

If you simply remove first slash from the second line, it turns into this:

1
2
3
4
5
6

long number = 1024;
/*
std::string number_str = std::to_string(number);
/*/
std::string number_str = boost::lexical_cast<std::string>(number);
/**/

Your first implementation became switched off, while code remained completely valid.

It’s pretty obvious, what’s going on there. //* is “commented-out” beginning of multi-line comment which becomes uncommented in second case. If might be considered as a kind in if equivalent. /*/ is a universal token which either starts or ends multi-line comment, depending on preceding context, something like else. Finally, /**/ works as endif token, which terminates comment is case was opened before, or does nothing otherwise. It might also be //*/, but visually I like /**/ more.

Be warned!

This technique has some disadvantages, which must be taken into account:

• It’s a very obscure way of code management for anyone except you and even for you few months later. Don’t commit this ever, it’s just a time-saver during playing with code.
• If code block a large, it’s hard to find these boundaries visually, especially taking into account that they most likely won’t be indented.
• It doesn’t work at all if code between this special comments contains multi-line comments.

Finally, I’ve completed transition of this blog to GitHub pages, planned over two years ago. I did the first step — migration to a static site engine (specifically, Acrylamid) — back in March 2014. And since than I’ve been saying to myself “one day I must move it to a GitHub as it’s a best free hosting for a static site”.

I couldn’t tell for how long I’d continue slacking like this, but now I had to do this. This site was hosted at free hosting service provided by EOMY.net since it’s very beginning and recently I’ve received a notification, that EOMY shuts down it’s shared hosting, completely focusing on VDS. It’s a bit sad news, as EOMY managed to provide fantastically stable and reliable hosting for all this years, so great thank you for them and good luck with VDS business!

By the way, I have plans on implementing an automated process of site generation and deployment using TravisCI the way it’s done for GCB-JS. If i do this, I’d be able to blog right from GitHub interface, which would be pretty cool :-)

In a past few years I’ve been using C++ as my main programming language and during this time I’ve been in constant search for better IDE for it which would run on Linux. I was very happy when Jetbrains released CLion IDE and immediately gave it a try. Though there is a lot to improve yet, I’d say that it has best autocompletion and modern C++ support among C++ IDEs on Linux. The only problem I had with it was a build toolchain which it uses.

Currently CLion supports only CMake projects (with is totally fine for me) with GNU Make generator (which is sad). When using CMake, I always preferred Ninja build system, especially for large projects like one I work on as my main job. For some reason Make does not a very good job at incremental builds. For example, even if there is nothing to rebuild, it spends 5 seconds to only verify this fact, which is pretty annoying. On other hand, Ninja does this in like 200 ms.

Unfortunately, CLion developers currently have no plans on supporting Ninja (I realize that they have many things to do way more important than Ninja support), so I decided to solve this problem by myself.

CMake-Ninja wrapper for CLion

I’ve found a kind of solution for my problem on internet but it had two very critical drawbacks:

1. You meed to edit manually CMake cache for each project you work on.
2. You have to run cmake -G Ninja manually eash time you add or remove files from your project.

After messing around CMake and ~/.clion11 directory for a while I’ve came up with a simple python script which wrapped around CMake binary used by CLion, replacing -G "Unix Makefiles" command line option with -G Ninja. It did work in terms of making CLion using Ninja for building a project and didn’t require any additional actions from me unlike previous solution. Unfortunatelly, it absolutely broke autocompletion support in the IDE, since it relied upon some artifacts, which Unix Makefiles generator was producing.

After some trial and errors I modified my script to act according following rules:

1. Whenever it’s called outside of CLion’s private directory (~/.clionXX) or there is no -G option in command line, it simply passes control over to CMake.

2. If there is -G option, it does some black magic to make me, CMake and CLion happy:

   1. First, it calls real CMake with original arguments, producing Makefiles required by CLion.
   2. Then it alters CMakeCache.txt to make CMake think that previous generator used was Ninja, not Unix Makefiles.
   3. Finally, replace “Unix Makefiles” occurrance in generator name with “Ninja” and call CMake again.

You may grab the script on GitHub. I’ve tested it on Linux and Python 2.7 but I suppose it should work on Windows and Mac too, maybe with minor modifications. Please, let me know in comments if it worked for you :-)

Finally, this script has several imperfections, which I’ll fix in future. One of the most important is that it currently mizes stderr and stdout of CMake which seems to confuse CLion a little bit when dealing with invalid CMakeList.txt file.