Table of Contents
Note that I'm not gonna be saying that it's confusing, hard to understand etc. Those things would be subjective, and even if I agree that it's not too intuitive, it's still totally learnable and not a big deal. In this article I'm gonna be talking about matters which are more objective.
Also note that it's not a tutorial on how Rust module system works; I'm assuming the reader is already familiar with it.
I like Rust-the-language a lot; I spent enormous amount of time in my life debugging memory corruption bugs in C, and so I'm fascinated by the ideas behind Rust, which gives us an incredible level of memory safety without compromising performance. That's very unique. However, there's one thing in Rust that really bothers me: the design of crates and modules.
There is a natural tendency that communication tools, which never meant to be security devices, end up being used heavily for security purposes. This happened to both emails and mobile phones. You know, SMS to a mobile phone is still sometimes the only option for a second factor authentication, despite a lot of evidence that in real life it 's a very bad idea due to SIM swap attacks (check e.g. looks like this or this). And emails are almost universally being used to reset passwords.
I say it's a “natural tendency”, because when the need for something new arises, people obviously try to find and (ab)use something that is already available. But then it strikes back, because first of all these tools were implemented with different goals in mind, and second, even our usage patterns remain mostly unchanged. So when it comes email and phones, we keep using them as if they were only for communication.
In the past few years I've been living in Bulgaria, working remotely as a software engineer (technically, “consultant”) for foreign companies (both European and US), and by now I have a pretty good idea about all the taxes and other business-related expenses one has to pay in this setup. Since it's ridiculously hard to find a good and detailed breakdown like that (most often you'll find that income tax is 10%, and dividend tax is 5%, which is accurate but awfully incomplete), I just decided to put this page together. After all, taxes here are pretty simple, unlike countries like US.
Initially I wanted to write articles on those two topics separately (mocking time and testing event loops), but during the process I realized that the things I want to talk about are too interrelated: when I need to mock time, it's usually to test some event loop with it, and when I test event loops, typically mocked time is also involved in that.
So in the end, it felt better to just combine all that in a single article.
I really love the security level U2F provides, but together with security, we have to think carefully about the backup and recovery plan. It would totally suck to get locked out of my accounts if something happens with my U2F token. At the same time, it doesn't make sense to have a backup which compromises U2F security.
As I was saying already, I love Go, I really do. And in particular I like the minimalistic approach to error handling: no exceptions, each caller should check the error explicitly and deal with it as it wants.
Many years ago, I've been waiting for a language like Go. Back then, I was primarily working with C (for microcontrollers), and C++/Java/Python/etc (for bigger machines). These are great tools, but still I was longing for compiled, statically typed, memory-safe (and garbage collected) language, which compiles for the target platform machine code, and has a big enough community.
At Cesanta, we use Makefiles to build our firmwares, libraries, and perform other things. But the more I use
make, the less I like it. I want my incremental builds to be reliable, and I want to be able to reuse my Makefiles as needed.
make can't provide that, and builds just kinda-sorta work most of the time.
Most annoying issues are:
I use Docker, but not often enough to memorize even basic Dockerfile instructions and CLI commands. After all I got so annoyed by being unable to quickly sketch some Dockerfile or to do something with the existing containers occasionally, so I decided to write a concise cheat sheet which I can print once and constantly keep on my desktop:
I work with embedded stuff for several years: our company develops and manufactures car trip computers, battery chargers, and other car-related electronic devices.
The processors used for our designs are primarily 16- and 32-bit Microchip MCUs, with RAM from 8 to 32 KB, and ROM from 128 to 512 KB, without any kind of MMU. Sometimes, there are even more modest 8-bit chips.
The usage of real-time socket connection with authentication data seems quite regular thing to me. And, personally, I find it very strange that this topic receives so little interest.
I needed to develop an utility application in Qt, which should work in Windows. I use Linux, and this is no problem since Qt is crossplatform, but anyway, to make sure resulting application works in Windows as intended, I've installed Qt in Windows guest OS in VirtualBox.
Surprisingly, at the time of writing this, there were two issues running Qt Creator in Windows guest OS.
Recently I had an opportunity to work with Ragel State Machine Compiler in my Qt project (There was a requirement to parse binary protocol), and the question was, how to integrate Ragel source files in the project conveniently. After all, I've read about qmake's
QMAKE_EXTRA_COMPILERS facility, which does the job very well.