Still figuring out what this LinkedIn feature is, but it turns out the absolute reaction counters are relatively low, so shamelessly sharing for a few increments if you like my thoughts :-)

I really liked this podcast with DHH. Totally recommend. Especially the last ~40%.

Sorry =)

A friend sent me this.

I thought it'd work with overriding this via bind / call / apply, but alas, no luck.

Pretending I really want to do it — OCD FTW! — here's how it actually "works".

Better solutions are more than welcome =)

Сrazy thought on democracy and it working.

There's a growing wave — which I of course support in my heart — that goes along the lines of:

• If The People are not heard and the country/government acts against the expressed interest of The People, then this country/government can not be considered democratic.

While I — again! — agree with this in spirit, Norway presents and interesting "counter"-example.

• Norway has oil.
• Norway is quite wealthy per-capita.
• Norway maintains a sizable stabilization fund.
• Most voters complain along the lines of "why can we not have nice things when the country sits on this pile of money".
• The country chooses to keep investing this pile of money long-term instead of spending it.
• End result: not a single time in a lot of years the incumbent government won the elections.

Did I mention tax rates are quite high in Norway?

So we have a situation where the country, a clearly advanced one, routinely, decade after decade, goes against its own citizens' expressed interest.

Should "true democracy" win on Norway, people would vote to effectively redistribute this stabilization fund money among themselves. Handouts and/or lower taxes and/or whatever other means.

And yet this is not happening. And I, for one, would not bet on this happening any time soon. Even though, arguably, the average democratic voter in Norway would much prefer to see themselves have more money, not less.

Go figure.

Сегодня в 19:00 GMT+1 обсудим Современный System Design

В гостях Дима @BoreMeNo
Автор System Design Meetup https://www.youtube.com/@dimakorolev/

Ссылка на стрим
https://youtube.com/live/Gx14ex3NZo0?feature=share

☝️Sorry for the spam in Russian, but we're going live today with another Dima, just in a few hours.

My take on the CrowdStrike incident is exactly what @Komzpa half-jokingly said a while back.

“Catastrophies will ensure humankind prevails!”

I’m not _in favor_ of bad things happening. Of course. But the healthy attitude is to embrace them.

We, the technology sphere, have admittedly lost it. Boeing comes to mind first, well, second now. We have let the tech-illiterate career-driven bureaucrats run the show. We, the engineers, have crawled into our holes doing good work where we can, since fighting this corporate and enterprise monsteroucity is not our strength.

Game-theoretically, then, more catastrophies is a *good* thing. Because it is a wake-up call our industry, or maybe the whole planet, is long overdue for.

I’m an avid Linux user. FreeBSD rocks too. Open source kicks ass. UEFI et. al. are just terrible ideas, since they remove and obfuscate who and what really is in charge of pretty damn important things.

We were not listened to. I still have plenty of friends who sincerely believe the closed ecosystem of Windows is more stable and more reliable than “a bunch of freaks”. And who sincerely believe we should make our society cashless, but not properly-decentralized cashless but rather all the way around.

Well, I may be wrong and they may be right. Time will tell. So far though we have plenty of evidence in a very particular direction. I sure hope no one in their right mind would design a nuclear power plant to be operated by Windows 11.

A random idea, but it's about time for me to emit it into the wild.

Project (startup?) idea: An instrumented UI-first testing tool based on computer vision.

Effectively, Selenium but for everything non-browser.

Cucumber-style test descriptions, plus a set of pre-trained models that understand commands such as:

‣ Press the red "OK" button in the lower right corner.
‣ Scroll the top-level pane down until "Solution" appears.
‣ Wait until "Build succeeded" or "Build failed" has appeared on the screen.

Intended reference use case: DevEx teams testing the company-wide IDE setup, so that a new version of some PyCharm / VS Code plugin does not break some important flow.

"Page" load time testing: see how long an app, say, the IDE, takes to load until it is fully functional. I.e. until it can open the project, open a source file in it, and have code completion work with a trivial test case.

Also, works well for performance testing too. For example, to test responsiveness of some team messenger apps, open the same chat window (or a shared doc) from different VPNs around the globe, type the next character only after the one added by the "previous step" agent makes it there.

Would be quite big these days, huh?

Just clicked "Publish" on two posts that were in the works for well over a month. Behold:

• Distributed Stateful Workflows, and
• Stateful Orchestration Engines.

Hope you enjoy reading them as much as I enjoyed writing them. And spread the word!

Today I learned that for quite a while I was using the terms "data center" (DC) and "availability zone" (AZ) wrong!

My (incorrect!) understanding sincerely was that there may well be more than one AZ in a single DC.

Heck, I would buy it that there could be more than one AZ in a single building of a DC, or even on a single floor of this building.

Because, in my book, if the reserve power supply for this building/floor is separate from the rest, and so is the building-level/floor-level network switch, this truly is its own, well, _availability_ zone, right?

Moreover, I sincerely believed that even within AWS it's perfectly feasible for the DevOps team to want to configure a, say, three-nodes Zookeeper cluster such that each of these three nodes lives in its own "AZ", well within the same data center.

Because it just makes sense, doesn't it? If anything, I'd want these three nodes:

1) To be next to each other, for low latency between them, and yet
2) Not in the same "risk group", for their failures to be uncorrelated.

By uncorrelated failures I mean that in the case of top-level switch failure, or a local power outage, I would like my setup to be far more likely to lose just one of these three machines, compared to losing two, or all three at once.

Well, apparently, intuitive as it sounds, the above explanation is demonstrably wrong, at least in the case of Amazon Web Services. In AWS there are regions, then availability zones, and finally data centers. In this order of traversing the hierarchy top to bottom.

My Monday begins (or, rather, continues from Sunday) by PyPl not accepting a package.

How difficult is it to have a trivial tutorial of one-liners with no external dependencies? Last time I pushed my code to a registry, it was npm back then, the whole thing took just a few minutes.

Worst thing is, even when it will work — and I assume it will some time soon — I can not fully trust it, since I have no clear picture of what all the underlying components underneath are doing.

Why not have some standard solution with standard authentication and live with it? There's a password, an OTP code, an API token, OpenID connector — and all of these are effectively security holes waiting to be exploited.

In the world where PGP and SSH are widespread and well-established technologies for dozens of years. Just ssh with your key. Get a fake shell where it prompts for the OTP. And you're done. Plain and simple, with no room for error. Much like one can ssh into ssh@github.com to test their key — beautifully clean and reliable.

Sigh. Gotta got used to the fact that my standards are higher than most. On the other hand, that's a hint to what area should I be working at: improving such processes for other engineers!

https://x.com/tsoding/status/1759199337685389760

I can relate.

My relationship with cmake was always a love-hate one, but it started to bounce back towards love recently.

After all, given its history and its legacy, it's still a surprisingly standardized and well-supported tool. If building on top of make in a clever way would be my path of choice, I could not have done better.

Besides, CMake-based projects are supported by multiple IDEs today, including VS Code, which I personally believe is fantastic.

One thing that I found cmake lacking — and hope the community of people smarter than me have thought about it before — is adding my library's include directories under some fixed ""dir name", regardless of what's the name of the dir my code is cloned into.

Most projects I've seen have in their root directory the CMakeLists.txt file, and also src/ and possibly include/. Say I maintain my_project. Ideally, I want its users to #include stuff as "my_project/my_header.h", or "my_project/include/my_header.h". However, this would require my_project to exist in its own directory called, well, my_project.

This is too much to ask in 2024, I'd say. Symlinks can solve this problem, of course, but only up to a certain degree.

What do people do?

Imagine I have a large project and it does have a collision in header names of dependencies; some "common.h" in my_dep_1 and my_dep_2. What's the canonical way to use them so that:

• The setup uses the "vanilla" versions of "my_dep_1" and "my_dep_2",
• The writers and readers of the code can clearly disambiguate whether we're looking at "common.h" from one or the other dep,
• The overall setup is not fragile, i.e. it works under various IDEs on various platforms, and
• The solution is generic, so that no changes need to be made on the side of "my_dep_1" and "my_dep_2" to use these deps in a clever way.

I can write my own dev setup script, even inside CMakeLists.txt, which will make sure that whatever directory is passed as -I to my code contains "my_dep_1/" and "my_dep_2/", if only as symlinks. This is the cleanest way I can think of, but it's also an overkill to my taste.

Would love to hear from people more experienced than I am. Thank you!

How do contributor license agreements work these days?

One thing I would particularly like to have is that it’s the existing community that manages the lineage of the project.

So that if someone (even the original author!) leaves, this person can not just say “I’m deleting all my code from this project”.

I mean they can. They can send such a pull request. They could even merge it in, perhaps even with some approvals they may well gather with their farewell message.

But then the community should just be able to put that code back in and continue to function as usual. We keep the name of the original contributor (on an altered name if they wish, no problem). But if they broke the functionality of the project by removing their code, I’d say keeping the project functional has precedence over their desire to have their code removed.

Thus, I believe, it should be part of the contribution license agreement that one consents to their code being used in the project even if decide to withdraw themselves, to be excluded, or even removed from the project against their will. Effectively, they attest that not only they have the right to contribute, but they also grant the community the right to use their code even if at some point later on they may want to withdraw parts or all of their code.

Is this a reasonable position to hold?

Can this position be incorporated into the CLA in a language that does not allow for ambiguity?

Are there real life examples of such CLAs, ideally with proofs of them holding against someone’s desire to have their code removed in a non-non-breaking way?

Heh, while I am not a huge fan, I used to praise Python for "sensible defaults". Consider a trivial if-condition:

if something:
    foo()

It checks something for a boolean that is False, for a zero, for an empty string, empty array, etc.

Lovely, isn't it?

Well, today I was writing a script that should behave differently depending on whether a config.json file is present in a directory or not. The code uses a Pythonic-clear construct of try-ing with open(...) as file and json.loads().

For a negative unit test (yes folks, death tests FTW!), I have, of course, used a definitively non-empty config.json. The contents of which were {}\n.

You can guess the rest.

Took me a couple dozen seconds to formulate the right hypothesis, and a few minutes to make sure it's isfile() that is responsible for the condition, not "just" if config_json:.

Obligatory pic attached.

My new hobby is asking ChatGPT 4o to generate maps as pictures.

It requires some prompt engineering — it can even generate real maps with pins using Python modules now! — but I generally succeed by just asking nicely.

"Just generate the picture with that map please. You're good at generating images, and the map is an image, isn't it?"

The amount of hallucinations there is insane. I won't be comfortable sharing the Congolese wars picture it made for me, since that one was brutal — a good half of Africa was fighting.

Here are "Vietnam tourist destinations" though. Enjoy responsibly.

#nottraveladvice

I don't really trust Telegram as the platform, and people often wonder why.

To me it's not about open source or not open source. Business models come first because it's the business model that keeps the product afloat, to begin with. And for some products going open source is just too bad to consider seriously. Signal is not, after all, open source.

And it's not about the lack of transparency. Telegram is quite transparent about what they do and how they do it.

What I do not understand — since it does not compute in my head — is how can the platform BOTH declare it wants to be resistant with respect to privacy AND at the same time be so reluctant to enable external add-ons for encryption.

Say, you and I want to communicate 1:1, and we have exchanged our public keys before.

It doesn't take a genius for both of us to run a trivial, tiny, open-source daemon on a dedicated device to encrypt/decrypt messages sent specifically to us on the fly.

So that when I'm sending you a message it's my laptop that encrypts it with your public key, so only you with your private key can decrypt it. And vice versa.

If it's a multiple persons chat, only the people who I trust to have their public keys in an uncompromised way will be able to see messages sent by me. Because man-in-the-middle is real.

My point is, such a feature, with encryption/decryption of particular chats taken out to a dedicated device, would a) absolutely not compromise Telegram's position on the market, and b) unambiguously send the message that Telegram does indeed care about user privacy.

TL;DR: There should be a way to buy a Raspberry Pi, join the same home WiFi network, have some one-time QR code for this Pi to act as my encryption device for certain Telegram chats, and run a tiny, small, self-contained piece of open source software on this Pi specifically to keep being locked into the Telegram ecosystem while having the confidence that my private chats are private.

Heck, this "tiny piece of open source software" is something an advanced Linux user can put together in half an hour in bash by just invoking openssl commands. Asymmetric encryption is literally the most trivial thing that exists in the world.

If Telegram truly wants to compete with Signal on the privacy front, the solution I am outlining, both from the product side and from the tech side, is literally single-digit days to build and ship for the engineers. So, single-digit weeks to build and ship for Telegram as a company. But, somehow, everything but this solution is being developed and shipped.

~ ~ ~

I'll go further and postulate that the approach I am outlining should be the future.

Some 15 years ago I was wondering why isn't there a "login solution" where I scan some QR code with my phone to open a one-time session on some untrusted and semi-trusted device. Fast forward to today, and that's exactly how Whatsapp and Telegram are used in the browser.

Same with OTP codes. There are open source apps fully compatible with Google Authenticator. The protocol is open. Exporting a certain code from one device to another is about scanning a QR code. Safe enough for most people's standards.

Nothing prevents us from building the same solution for chats and messaging. Scan the QR code from my device to get my private key. Type my OTP on your device — I'll share one code — to prevent man-in-the-middle attacks. You now know my public key, and your device can encrypt messages sent to my device. Your device may become compromised, but this we have no control over.

But it's more than enough for me to know that your device can be a Raspberry Pi and there exist plenty of open source implementations for the open standard for the above protocol.