Braindump on the tariffs war.

It's unlikely my views would change much in the next weeks or months. And COVID taught me that making certain "predictions" early on is worth it. If only to compare the notes years down the road and to say "I knew it!". On the other hand, being wrong in public is also fun.

This post is about economics, not politics. Please refrain from personal attacks and political statements.

The US is paying too much to service its national debt, which is not a sustainable situation. And virtually any solution is better than the US dollar defaulting. Something like a "bank run" on US-issues securities is approaching slowly yet inevitably over time. And printing more money to service this debt was effectively living off past glory.

One could argue that the US was and remains successful enough at persuading other countries to keep purchasing US dollars, but it's quite clear over the decades that whatever powers stand behind this persuasion are only getting weaker.

In other words, the US consumer was enjoying the dominant position of the US after World War II, and then after the Cold War. Our politicians, however, were too comfortable, and have clearly not invested enough in domestic growth, thus weakening our position over time. As Peter Thiel nicely puts it, if you keep kicking the can down the road, sure enough you will end up with a lot of can and no road.

Thus, since we do need a solution that is definitively better than defaulting the dollar, we need other countries to play in. Of all the moves that the US can play, two are obviously the strongest.

Move One: Become more independent and self-sufficient as the country.

Move Two: Make sure other countries buy more US dollars than they sell.

I would also throw Move Three into the mix: Tie security guarantees from the US to being more US-friendly with respect to Move Two.

Move One ensures a strong position at the negotiation table. The less the US depends on another country, or some alliance of countries, the more plausible it is to just walk out of the room if the terms are not good.

One of my favorite sayings goes along the lines that in order to qualify for peaceful one needs to have the capacity to actually do harm; otherwise you're not peaceful, just weak. Clearly, the US wants to be strong and peaceful, and this requires being in a position where walking out of the room is a plausible move; despite, of course, the fact that a good negotiator does not walk out of the room mid-conversation.

Move Two is basically about keeping the US dollar strong. Call me old-fashioned, and with respect to economics I most definitely am — the Austrian School FTW. But I believe the price of something is the equilibrium of its buy and sell sides of the market. So, if more players need to buy the US dollar, the US dollar is stronger. And if more players need to sell the US dollar, the US dollar is weaker. Clearly, since the US does not plan to be a net exporter any time soon, we want a strong dollar. That's it.

So this brings us to where we are today. Whether the timing is right I am not in position to tell. Perhaps negotiating with the world on how to restructure our debt some ten years ago would have been better. Perhaps ten more years would not be implausible to wait. But give or take ten years, we should have made some move. And this move is being made now.

I do believe a net positive outcome is possible. It might take several years though, to restructure manufacturing and the job market. But ultimately the US is probably the most self-sufficient country in the world, and we do have best entrepreneurs and a lot of wealth. So, in the long run, I would of course bet on the US. It might be ugly, and we might go through a couple major world-scale crises. But, unless things go way too ugly, the US is far more likely than not to prevail.

And we do now have the administration that has a track record of acting bold internationally. You can rephrase "bold" as "bully", and I won't disagree. But this does play to the advantage of the US timing-wise.

That's it.

Not sure who needs to read this, but we hosted a small almost-two-hours Rust-for-C++ people podcast yesterday.

YouTube, in Russian.

My homework code snippets, Github.

Thanks @volyx and @apakhmv!

Crazy thought, but can't resist sharing.

It occurred to me I now have enough knowledge to build a proper blockchain from scratch.

Have other priorities as of now, of course, but it'd be a fun "build in public" project. I can imagine running it as a mentor / coach / "professor", hehe.

To connect the dots I only needed to understand tokenomics in addition to cryptography and distributed systems. And building clean examples from scratch is one of my passions.

Here's what I would do:

1) Split nodes into "compute" and "routing". The latter are stateless.
2) Make it proof-of-stake, but start with proof-of-work to cold-start the system.
3) Require every single request to be paid for, including system requests.
4) Use wasm, or other JIT-style solution, for infinite scalability.
5) Model tokenomics so that it is beneficial to spin up new routing nodes worldwide.

With (1), the routing nodes are literally just doing fanout, while being paid for it. Because you will only fan-out something where the party that wants stuff fanned-into itself has the proof it has paid you. The compute nodes are then only talking to the routing nodes, so they can be in-browser clients, whoa.

The entire system should be 99+% proof-of-stake by ~month two and ~99.9+% proof-of-stake by ~year ago. The only question is to pre-mine or not to pre-mine. I personally prefer the latter, so some proof-of-work to kickstart the system in a safe and secure way sounds right to me.

Making every request a paid-for request (3) should include internal routing. The routing nodes should be net positive by merely being available with decent uptime guarantees. Clients choose which public routing nodes to connect to based on their availability, and it's the clients that ultimately pay the fees for these routing nodes to run. That's some non-trivial math to do, but I'm sure it can be done well enough.

With wasm, (4), nuff said. The self-upgrading with rolling-forward-compatibility approach is mainstream now. I knew it is the future more than ten years ago, am working on distributed systems where consistency and consensus are critical for fun and profit for more than five years, so it's very much clear what the right solution looks like. Also, L2, as in partial order instead of total order, is very much understood these days, so transactions can be built to be both fast and cheap.

Finally, the tokenomics (5) should be such that the network quickly grows to ~thousands of routers. In-browser clients will be easy to work with, and, eventually, they too will be replaced by sharks and whales. For starters CPU usage and traffic numbers are very low at the beginning, and a hosted instance literally costs under ~$15 a month in most parts of the world. So, for ~under 5% of CPU load, just pledge some ~$1K a month to "pay for hosting" by funding enthusiasts worldwide in whichever tokens they prefer, and have the payouts structured so that the planet is covered more or less uniformly.

Here we go. Something a bunch of savvy teenagers can build.

Now if only the above had value beyond pure academia. A distributed computer is fun, but it quickly gets to the territory where regulation plays against the core stack, and my life motto is to not fight uphill battles of this sort. Although this may well be a simple messenger, or a backend for a decentralized social network, and then — off we go!

If I had more time I would have written a more concise note.

TL;DR: If your Google for Business emails do not reach all recipients safely, you may need to configure something else.

Which prompts me to make a stronger statement.

Email sucks.

Here, I've said it. I was very much hoping to be in position to say something like this for a long time, and now it finally is painfully clear.

I understand why some technology or a protocol becomes design-by-committee, so that there's no way back. It's then too beneficial for the big players to change the state of the art, since a high barrier to entry makes their commanding position easier to sustain.

And I also believe in the balance between centralized and decentralized forces. As in, in the balance between small business and "The Big Brother", and, in today's world, companies of the size of Google are clearly closer to The Big Brother than to a small business.

But, even though subconsciously I always knew email is part of The Big Brother's game, part of me was not willing to part ways with the idea that is still belongs to that good old decentralized "peer-to-peer" era; just by how I understand the email protocols to interplay.

Well, not anymore. See the link above.

As of today I am solidly in the camp that email should die. Pavel Durov said it many years ago by the way. And, while I do not like Telegram's approach to "openness", or lack thereof, I am willing to concede that Telegram is just a good enough product.

The messengers are the future. And we have plenty of good protocols, including the decentralized ones.

So, my take is: let's end this email/GMail dominance once and for all!

If it requires a phone number to create an account — it's out.

If it does not have a simple way to send a message to someone, so that it's their client, not the platform, that ultimately decides whether this message should be shown, or end up in "spam", or get filtered altogether — it's out.

Heck, make it cost some one-hundredth of one cent to send The Message. We have the technology for this as of today. And all the problems with spam will disappear overnight.

Literally the only reason we do not have the above is that the legacy forces are too strong and the big players are too comfortable.

Well, that's why my bet is on Web3. Slowly but surely, the reality of people preferring to use Good Products over Crappy products will prevail.

Which reminds me: What Web3-friendly message protocol should I look into? I literally want a solution where my "address" is my public key. Some Ethereum name service would work too. Eventually I'll have to live my life without email, and might as well get a decent vanity name before it's too late!

Achievement unlocked: Coded on a vertically standing tablet from a coffee shop for an hour, typing on a keyboard below the table.

Side quest unlocked: A girl walked up my way and asked whether it's a NuPhy keyboard.

Not bad for the first day. Must be how nice these switches sound =)

PS: Coding Rust on a tablet is surprisingly more pleasant than coding C++ on a tablet. Mostly because compilation errors are easier to read.

Okay, time for an elephant in the room.

For a startup making their first single-machine relational hosted DB decision, is there any world in which MySQL is a better choice than Postgres?

My understanding was/is that MySQL is potentially lighter, a tad easier to use by beginners, and could win for read-heavy workloads. But that's no longer the case, right?

In other words, "Just use Postgres" (c) is just ... true. Right?

Note that I am very conscious in this "problem statement" that we need a single-machine hosted DB and we need it to be relational.

If it's not hosted but embedded, there are plenty of options. If it does not have to be relational, there are plenty of options.

Finally, single-machine is literally a terrible design decision for most use cases, but alas, big projects do start small, and development velocity matters most at the early stage stages.

Enlighten me pls.

Here are two posts in one, both inspired by AI-assisted coding.

One. I'm looking forward to more and more AI-assisted coding resulting in more and more managers and vice presidents and entrepreneurs and consulting agency operators who have mastered to understand the fine line between "this task can be hacked up in a few days" and "this task requires a team of skilled professionals working for months if not years".

Sure, there will always remain engineers-turned-managers who believe every problem can be solved in full, "in two weeks". But the entropy is increasing faster now, and, unless these people are consistently right about "two weeks", they will be forced out by the market.

"Half of my investments is shit; I just don't know what half." Same applies to coding tasks. Knowing which of them can be thrown at the AI, and which require deep, long-term-committed, thoughtful work — this is the skill to look for. And I'm sure the market will not fail to deliver. Wondering if we'd have new "AI-assisted coding operators" interview types soon. Or remote "Cursor prompts writing" teams in Eastern Europe and Southeast Asia.

Two. Vibe coding is dead, long live vibe coding. Groovy Coding is the future! We coined this term yesterday at dinner, at a place where great ideas come. So this one must be great too.

Groovy coding is all about using AI assistants such that they optimize one's learning curve. That is, one's learning curve of being productive while coupled with these very AI assistants.

So it's a two-in-one: the groovy coder is simultaneously experiencing the joy of coding and the joy of learning. Long-term, the groovy coder is the winner.

Short term, oftentimes a groovy coder is indistinguishable from a vibe coder: either when they trust the AI to hack up something one-off / throw-away and boring, or when they are struggling to "help the AI" get a good understanding of a nontrivial domain together.

Mid term, a groovy coder can and will lose to a vibe coder. Because a groovy coder understands the importance of deeply internalized knowledge. Both in themselves — that's why we learn! — but, increasingly importantly, in the combination of this { groovy coder, the AI machine } tandem.

So instead of cutting corners and rushing through, the groovy coder accepts challenges as valuable learning experiences. Including the "teaching the machine" aspect as well. The AI used to be called Machine Learning for a reason, kids.

A loose yet good analogy is that a groovy coder is a senior++ engineer who's training an ~intern AI assistant. Not with the mission to get the most of this "intern" and replace them by a fungible next-version one. But with the mission of growing the seniority of this human + AI collective wisdom together.

Another good analogy is that imagine you get to live for another 1000 years, of which another 500 is your extended professional career. Most people will peak at a certain level, which may well be below their level today if they already have a few decades of experience past them. Groovy coders are who will grow to new heights, since they know exactly what it takes to expand horizons, and are working relentlessly to make it there. And today this relentless work has to include incorporating AI into their workflows in clever, long-term-positive ways.

What a time to be alive.

I'm not sure who needs to hear this, but some things get more and more clear in my head after doing them for a ~hundred times and asking ChatGPT et. al. for a ~dozen times.

Borrowing in Rust is all about the fact that, unlike C++, the very idea that some value was and/or can be consumed is codified in the type system.

This simple statement covers 95% of what one needs to know.

(And most of the remaining 5% would be a trivial idea that there can be multiple viewers or one writer, but not multiple writers, and not writers concurrent with viewers. And that if something is potentially crossing the thread boundary a lot more guarantees are required. And that Rust's type safety is all about making sure that non-`unsafe` code can not possibly be "wrong", at least in the memory safety meaning of this word.)

So, if you speak C++, just assume that, with respect to something being `std::move()`-d out, the compiler carefully tracks the very fact that the "remaining shell" is not something you can use.

This rule applies to everything, and the compiler is rather smart. Such that if all of your if/else branches are behaving identically when it comes to a certain object (with respect to consuming or not consuming it), it's one behavior. And if they are not, well, it's also legal, but you can't do everything after it.

Same with a closure/lambda. If it consumes its input, you can't, even in theory, call it more than once. And if you want this closure to be callable more than once, you need to, yes, capture by value or by reference; smart pointers with reference counting to the rescue.

Also, you can't really "check if something is still available", as in, not yet consumer. Since such a check would have to be a compile-time check. Alas, Rust does not have `static_assert`-s; although one gets used to this pretty quickly, since they truly are not needed, and they are easy to work around with if you need to quickly check while iterating on code whether some expression is of a desired type (or, speaking in Rust terms, if some expression implements the desired trait).

This is why mut is very much not the same as non-`const`. You can have a non-`mut` variable, and then "assign it" to a mut one right away. That's perfectly legal, since once you had an "instance", you are in full power to consume it. And if you can't consume it, then you probably have a reference, which, of course, you can only .clone(); unless it's a mutable reference. Not very intuitive for a C++ brain, but makes sense after you get used to it.

PS: Yes, you can't push to a vector in Rust if there's a reference to one of its elements.

It's not even a feature of the standard library, it's a feature of the language. Your own vector, should you implement it from scratch, will also fail to compile if, while growing and re-allocating, you attempt to move in memory the elements which some past caller is still holding a reference to.

Why are we not moving towards identity based on private keys?

This is a sincere and deep question, and it bothers me more and more as years pass.

Imagine you want to help some team. They want to add you to their Slack to begin with. What's the first question you'd get?

"What is your email address?"

And then perhaps they want you to have the NDA signed. And perhaps confirm who you are. And there will be a slow, human-driven, and error-prone process to check some preconditions that we have programmatic ways to handle for a long time now.

Same with Github. To push my commits, or to clone a repo, my SSH key is enough. But to be granted access, I'd need to provide my "Github username". Where's the logic in this?

I even wrote to the Github folks a while back that perhaps SSH-login-based authentication is a better means to prove oneself than a 2FA code. No luck.

Somehow the world wants to be tied to email, and, even worse, to phone numbers.

And that's in the era where we have widespread adoption of Web3. The younger generation understands mnemonics and public keys far better than SSH. I literally found that explaining Diffie-Hellman[-Merkle] via what a wallet app or gadget would do is more intuitive for them. And mentioning that Merkle's name should probably be there too lights up quite a few eyes.

One could say a major reason why banks still exist is that a lot of people are not tech-savvy. So they need the means to access their funds in case they have lost their keys, which is fair. People also need scam protection, understandably so, and they are comfortable trading some convenience for extra security. Very well then, the market does provide.

Behold ProtonMail. They encrypt your emails. And if you lost all the keys (including the recovery mechanisms), you can't access your old emails. And no one else will be able to use your email address.

As in: We have most of what the key-based access would offer. And people do like it. So, lack of "secure backup mechanisms" is no big deal, really.

I'll tell you more: there exist plenty of wallet apps (and devices) out there, where one's identity and access to it is protected better and safer. Multi-signature and social-proof recovery works fine. And isn't it obvious that we better segregate the tasks of using the service and authenticating into it?

As in, a lot of people today do say "Use Google for sign in", which I do support. Startups should not redesign their own "Forgot password" screens and password salting schemes. And OAuth2 is fairly good these days.

BUT!

SSH was at least as good, technically better, for 20+ years as of today. And Web3-grade wallets are at least as good, technically far better both protocols-wise and product-wise, for 5+ years as of today.

And the example from above — Sign this NDA with your legal name, verify your identity by uploading a selfie with your driving license, and then welcome to our Slack — is something we can 100% automate these days.

What's going on? Why is this not being adopted wider and wider as we speak?

Serious question to seasoned Rust users.

If a project uses multiple dependencies, and their names are somewhat generic and thus intersect, what does the community prefer — to use fully::specified::paths or to use them under longer, renamed names such as:

use libp2p::{
    noise::{Config as NoiseConfig, Error as NoiseError},
    ping::{Behaviour as PingBehaviour, Config as PingConfig, Event as PingEvent},
    swarm::{Config as SwarmConfig, ...},
    tcp::{Config as TcpConfig, tokio::Transport as TokioTcpTransport},
    yamux::Config as YamuxConfig,
};

Note that there's an intersection on ::Config in three (!) sub-namespaces of libp2p; although this is just one library, which may well not be representative.

Personally, I love these "augmented names", and I'd pick the approach that uses them any day.

My logic is that extra semicolons create cognitive load, and the cleaner the code reads the more likely the reviewers are to understand it in full, to spot errors, to suggest improvements, and to be more engaged with us overall.

This is the essence of the wisdom the Python folks taught me many years ago. If you can make it read short and unambiguous, prefer short and unambiguous. It's okay if the boilerplate code behind the scenes is long and ugly, and it's even okay if the types are erased and abused — we're all good as long as the developer who uses the library enjoys reading and following this user-facing code with ease.

On the other hand, I can totally imagine the status quo being dominated by the view that some verbose tokio::Mutex is the right way to go, while both TokioMutex and the ambiguous Mutex is just wrong for any big project.

We do not, after all, encourage using namespace std; in C++, and we got quite used to reading and writing std::unordered_map everywhere, automatically reading it as "a hash map".

Besides, I do acknowledge that in the Rust community "name abuse" is a widely used feature. Take, for instance, anyhow::Result — that's an extremely useful idea for small projects, but I would be quite unhappy to suddenly realize that some (some!) `Result`-s in a large project are `anyhow::Result`-s, while others are proper, full-blown result types.

Need help from Rust industry experts pls. What do you folks prefer?

Sorry (c)

We had an interesting offline chat last week, and one of the voiced opinions was along the lines of:

Our software will become faster in the next several years, because the cost of refactoring everything to make it faster is going to become marginally low.

Personally, I am willing to bet money against such a take (which I did say out there), but that's a separate conversation. It's also an emotional one, since stuff loading quickly is dear to my heart, and I have many and one examples where stuff just definitively became slower, with no signs of this trend reversing.

You can search for videos of Office 95 launching on Windows 95 if you truly are curious. There are even enthusiasts installing Windows 3.1 in virtual machines and launching MS Office right in there. It is as powerful as what 99.9% of users need today — fonts, alignment, bullet points, headings, print layouts, image embedding, and everything. And it fits into a negligibly small amount of disk space, and consumes less RAM than a minimalistic Chrome tab in 2025.

Anyways. Here's a link I stumbled upon today: Office is too slow, so Microsoft is making it load at Windows startup. So I can't resist sharing it with an obligatory comment above.

And two more things.

One: a test I've devised myself many years ago is to type, quickly, "Windows+R, notepad, Enter, Hello, comma, World, exclamation mark". My take is that even if one letter from Hello gets lost, it's a crime against humanity. Vim in a terminal would never do this to me. Just saying.

And two: while I'm not 100% comfortable admitting this, for the past three+ months my main machine is a Mac. Left/right desktop swipes are annoying AF (why not have an option to make it a one-frame, 1/120th of a second, operation?), but overall it's surprisingly reliable, and quite fast too.

So, in reality, my rant is not about operating systems but about how non-demanding with respect to latency an average Windows user is. We do have the technology and products that offer substantially smoother experience, and the reason Windows is not one of those products is clearly on the demand side of this marketplace, not on the supply side. As in: I have no doubts Microsoft does have amazing engineers who could make Windows good enough to my liking; it's the users and thus the product managers at Microsoft who continue to drag the company into the abyss of uncomfortable-to-use products. Amen.

In the brick and mortar economy, if you approach economics the way I do, there is a well-defined concept of externalizing costs. It is closely related to the tragedy of the commons.

To reduce it to a simple example for brevity, consider a shared, renewable yet exhaustible resource, while the rate at which this resource is replenished naturally is relatively low. The traditional example is when we have a pasture and a village of farmers.

The village benefits in the long run if its inhabitants agree to cap the total number of cows. Short-term, each individual person wins if they choose to own a cow, or another cow. Over decades, if preserving the pasture is essential to this village's sustained survival, some collective agreement to limit the total number of cows is what matters.

This is a canonical case that presents itself many and one times over. Real life examples include Haiti forests, industrial pollution, the economy of strikes, and even the OPEC itself.

Here's a thought inspired by a post I saw recently.

What people see on social media impacts how they think. By virtue-signaling, or otherwise by posting something "trendy", one is effectively externalizing the cost on everyone who sees that post.

Posting something for the narrative is polluting the "brain space" of other people. This applies to both intellectual and emotional resources that people "invest" while "consuming" one's social media content.

I just finished a quick book detailing how the tobacco industry successfully lobbied the idea that cigarettes are not too harmful to one's health for decades. Ultimately, the Big Tobacco knew they would lose, but it was worth it for a long time to keep investing hundreds of millions (!) of dollars annually into what effectively is propaganda; since one-sided, biased coverage of news, even the scientific news, is propaganda indeed.

(In a nutshell it's proof that democracy does work. Regulations around the tobacco industry were ultimately introduced since the social force pushing for them was strong enough for the new-coming politicians to ride this train. I.e., it became more valuable for an aspiring leader to side with the crowd that's asking to constrain tobacco consumption than to keep accepting lobbying money to, effectively, continue ignoring the issue.)

My take is that if we truly want to improve our material world in some aspect, say, pollution, we need to increase awareness about the problem in the right way. Just virtue-signaling that we care might well be playing into the narrative — the narrative those very "big co's offenders" are happily pouring tons of money into.

The big thought is that in order to reduce pollution in the material world we need to first be conscious about reducing pollution in the minds of people.

Thus, worry not about whether it's important to pay for CO2 credit offsets when booking your flight — even if you care deeply about exactly this very CO2 emission reduction. Instead, worry about not posting too much on social media that you have explicitly chosen the low-emission route!

Because, perversely, by amplifying this artificial narrative of "spend your $$$-s to offset your own carbon footprint", one is effectively acting as an unpaid actor who is diverting the crowd's attention away from what truly matters. Since the CEOs of all those companies fly, you know, private jets, alone, just to get to that conference in Aspen where they'd be talking to environmental regulators about how important it is for everyone to be conscious about their carbon footprint.

TL;DR: If you care about the future, begin by caring about how others around you think of it. Your words, especially if you have a following, do matter a lot more than your actions.

And mindless words, a.k.a. shallow virtue-signaling, may well deal more harm than good in the long run. So be conscious about the message, and expect the results to follow, in the long run.

Product idea! Since I'm in the Web3 space now.

Say, you have access to two machines, A and B. As in, you have a shell open on each of them. Perhaps A is your laptop and B is a remote service.

You want to configure access, so that "you" on machine A can operate as "you" on machine B.

Also, let's say there exists a verifiable way that you are indeed authorized to both "grant access into" machine B and "grant access from" machine A. More on this in a moment.

Today's protocols, mostly using .ssh/authorized_keys, offer neither auditability nor security. They are also design-by-committee, which over time I get to respect less and less.

Here's the product. An air-gapped device that allows one to securely bind A and B for future connections. A "smart pairing cable" which you need to "physically" connect to both terminals for the link to be established for good.

Of course there's no need for a physical cable. Your external device is just an offline QR code scanner with a touchscreen.

You run a command in a shell on A. Get a QR code, and perhaps a few digits below it. Scan this QR code with the external device. Type in those few digits. Do the same on B, with a different command — since A is "to enable access from" and B is "to enable access into".

Then you type, on the external device, the name for this "bond". Name idea: 007.

Finally, you need to get some input back into A and/or B. Your device can literally display a QR code if you have the means to scan it with your computer's camera. Or you can type in some keywords in the right order.

Behold! Diffie-Hellman[-Merkle], safe against any and all men in the middle. Because the ultimate keys are generated on the external device; or at least their salt is. So that if an attacker can see all the traffic between you and A, or you and B, they would not get anything out of it.

Since it's Web3, every such operation is journaled, in an encrypted way, on chain. Could be the company's proprietary chain. Although given it's all encrypted, as long as there's more second-order data traveling between your nodes to prevent metadata leaking, a public chain would do. In fact, both A and B would probably contribute ~0.01% of their CPU to be the validators of this chain.

Finally, forget SSH. It's bloated, and, as I said, design-by-committee. Instead, use a much simpler protocol, where everything is encrypted asymmetrically as it is sent between these two machines. Optionally, we can literally audit every single command and every single response sent this way.

Besides, the commands may well travel via not a network connection, but something else. Such as another blockchain. Yes, it would cost one a fraction of a penny to send that command, and it would add seconds of latency. But this way the connection can literally not be turned off.

For hardcore more, there can be an option to sign every single command. So that this external device — which technically is a hardware wallet — is required to be physically present and accessible in order to access machine B from machine A.

Finally, the prototype of this tool can literally be a command line application. I have positive experience spawning a tiny short-lived webserver on localhost and generating QR codes that link to http://localhost:${P}/${X}. So, no need in an external device, and no need to develop any iOS / Android app either. Any *nix laptop would do just fine.

I, for one, am finding it strange we still use authorized_keys broadly.

Last but not least: if you like this idea and are considering implementing it, I'd strongly recommend not only to open-source everything, but to design the cryptographic subsystem as plug-ins. So that the open source version uses trivial-ish ciphers which are weak by design. Because you never know what regulation can come about some time in the future, and it's better to be safe than sorry.

PS: The Open Policy Agent, OPA, rocks at authorization, AuthZ. This is about authentication though, AuthN. So yes, the innermost rules may well be powered by a Rego engine. Godspeed!

Sorry (c)

It just occurred to me that there exists a severely underrated skill.

It is extremely easy to develop. As in, it is literally the one where an amazing, extremely personalized teacher is available virtually for free.

This skill opens an enormous amount of doors, professionally and personally. Moreover, its value appears to be increasing exponentially as time goes on.

And yet a lot of people appear to have neither the desire nor the capacity to develop it.

What's even more bizarre is that while there exists a reliable way to self-train this skill, there is no training program or a workshop to obtain it. At least, there is none that I am aware of that is dedicated specifically to this skill, for adults. Some come close; for instance, humanities and acting classes would be quite useful.

But, all in all, children in kindergarten, and then pupils in decent schools, do get a decent degree of exposure to training this skill. Universities, and or real-life careers — not so much.

It is the skill of explaining one's thoughts . Coupled with critical thinking and with the ability to speak so that others want to listen to you is a superpower.

It was a superpower years ago already. Today, with LLMs everywhere, it's superpower squared.

And one can literally practice this skill with an LLM. "Explain me ... in simple terms". "Tell me if ... is a correct explanation". "Help me phrase ... better". "Assume the reader knows X and does not know Y, suggest a way to best outline A and B for them".

Here, the above five questions, which I just came up with out of thin air, are better than any affirmation or verbal exercise. Dedicate fifteen minutes a day to this, and you'll master the domain.

Moreover, true experts, at least those who do talk about their domain regularly, appear to have no problem articulating themselves. At the same time, quite a lot of people, who may or may not be experts, suffer from what I personally would categorize as basic inability to express a rather trivial thought.

On the other hand, I have to confess the above does make me happy. It's the evolution of human intelligence as it should be. One would have to be very naive to believe we, humans, have uniformly reached a certain height of clarity by the time AI in the form of LLM came to be.

A far more likely hypothesis — which is being definitively proven as we speak — is that the "lowest hanging fruit" when it comes to augmenting human intelligence with technology is not some "advanced reasoning".

The most impactful way to augment human intelligence simply is what we commonly refer to as basic communication skills:

1) Clarity of thought, to understand the domain from various angles and have the capacity to change the point of view "on demand",

2) Theory of mind, to quickly grasp what one's conversation partner does and does not get at the moment, and ultimately

3) The soft skills, to be an interesting conversation partner who other people want to be around.

What a time to be alive.

John Carmark hits the nail on the head, and I could not resist ranting back.

~ ~ ~

I mean seriously.

We're still talking about our candidates' past experiences of "breaking up the monolith into microservices".

While plenty of us have internalized it 10+ years ago this is a dead end, and many of us are living it for 5+ years that the "goal" of "splitting up the monolith" is often just the wrong goal.

And now people are confused about mass layoffs? Perhaps you should have been doing this tech thing right in the first place? There were signs ...

Rant over.

~ ~ ~

And here's what I truly think, since rants are a terrible way to convey knowledge.

Software does get bloated over time. Along all dimensions, really. In practice, security and audit aside, the two most notable dimensions are performance and maintainability.

Performance is when your users are not happy how slow the product is. While you're adding backend nodes like crazy to keep up. Knowing full well that had this been built right you'd have 10x faster apps that run on 10x lower resources.

Maintainability is when you always knows you can hire mediocre (sorry) talent from the market so that they can (vibe-)code more features.

Microservices as the replacement for the monolith was presumably solving both problems. So it was an easy sale.

I keep insisting that's a mistake.

Microservices-as-a-solution is a good mantra to live by. Many tech executives can do well by joining a company and rolling with this mantra. At the end of the day some things will likely improve and most engineers will likely be happy.

The company itself? Debatable. I'd say on average yes, but negligibly so. And quite a few companies would have done far, far better should they have not adopted the microservices-as-a-mantra approach.

The truth is, monoliths are ... just fine. Build systems are good these days, so one-line changes can be fast enough. Having to worry about potentially incompatible schemas during development is a GOOD thing. And not hiring developers who can only work on microservices and refuse to touch the monolith ... is also a GOOD thing to my taste.

Realistically, I am old and grumpy enough to blame the customer. Yes, here. I said it.

The customer these days does not really demand lightweight, responsive products. Say what you want about feature-bloat and about ugly redesigns, but there is a reason behind all companies engaging in these crimes against humanity. Revenue and market share.

Statistically, users want to see a new design.

Statistically, users want to know their product keeps shipping new features.

Statistically, users are fine with the app loading slower and slower.

And this "statistical" user is the user who pays, and thus the user who wins.

That's why I probably will not work on a B2C product. Because, as a user, I ultimately care about very different things. For instance, have the app load and respond 1% faster every quarter. It will be the fastest-to-load and fastest-to-respond app in the world in a few years. I'd love to use this app. But there's too few of me.

Personally, the above finding, when generalized further, is my biggest point of professional growth and pain. Since in order to be effective at the level I am at, I need to sincerely care about those users who love feature-bloat and who need a "new" UI/UX every once in a while. And I have to truly internalize that I must be the servant of these users if I want to be successful in the industry.

So, John. I respect you dearly. But you're just wrong on this one.

As in, you can afford to live in a fantasy world where ultimately "all the good programmers unite together and write all the good code, thus displacing all the bad code". Sure.

But that's literally escapism, a coping strategy of an old man, whose inner nerd is not happy when looking around. I'm the same. And I'm choosing to reprogram myself instead of feeling bitter about it.

Also, if every year I succeed at working with 1% better people on 1% better products, compounding returns is a gift that keeps on giving!

Serious product idea.

A vibe coding IDE that self-reflects not just on the level of a mediocre-to-decent coder, but at the level of a mediocre-to-decent tech lead.

You give it a task. A prompt, really; generally just a piece of text, but it could be a longer spec.

Obviously, a swarm of agents begins analyzing this prompt and working on it.

Secret sauce #1: While these agents work in parallel, they truly are optimizing the same function — how to keep the user happy while reporting on their progress. Concurrently, not sequentially, as Cursor does today.

So that there are various seemingly spin-off messages on the progress. From very low level ("I think I could re-use this function from that file") to very high level ("this request will require a broader end-to-end test, so why don't I check back with the user what this test should look like?").

Secret sauce #2: While the agents are designed to ultimately produce the desired result in a finite, small number of steps, the intermediate outputs are designed such that it's very easy for the engineer (the "human operator", or the tech lead of the AI coder) to course-correct.

My flow with Cursor today is that quite often I need to stop it, and rewrite the prompt. In ~80% of cases it's about:

a) simplifying the prompt, and
b) setting cleaner, well-defined intermediate goals that I will be able to validate myself.

So, effectively, I need to literally "save the current prompt on the stack", in a text editor or something, then run a "sub-prompt", and then return to the original one.

Instead, I want this "partial and temporary fall-back" operation to be 1) suggested and defined by the AI itself, and 2) require only a tiny, quick, targeted action by a human.

Much like a good Starcraft player will have all the control groups and camera hotkeys ready, so that with enough mechanical skills (a.k.a. effective actions-per-minute) they can literally look at the "battlefield" for a split second to give two or three locally-optimal orders and immediately switch their focus elsewhere.

I want the coding assistant to literally display the "decision tree" for me, so that something as trivial as "do not try to mock X", or "do not try to re-implement Y, but use the existing code from Z instead" will only take a fraction of a second from me.

This does sound totally doable to me with the modern-day LLMs. The secret sauce is literally to work on a better visualization of what exactly the critical decision points are. It's quite a trivial agentic system. Can be a command-line-first one.

Although I'd prefer to see this "decision tree" visually, and have a few pre-prepared responses right inside each and every node of this decision tree. And have the system that can incorporate ("merge") the results of user input tweaks of whatever progress was made after this now-altered prompt right into the current "working set" of hypotheses, assumptions and, ultimately, code.

In an extreme case this can be thought of as a chatbot-based vibe coding assistant. You tell it what to do. It responds with a pull request. But, if you're watching this chat, it gives you plenty of opportunities to interfere as you see fit.

And this "interference flow" is not designed to necessarily be linear. So it's more like an RPG quest to complete. Your hero can walk around screens and talk to different characters, choosing their next statements from various options. But ultimately this game is all about having these characters cooperate most effectively to achieve the desired result, which you are communicating to the system by "playing this RPG".

Would be cool, huh? Is any AI-assisted coding tool trying this already?

AI is soooo far from AGI.

So I was categorizing some thoughts, and had a ~20 minutes long tape recorder note to self, in Russian.

While waiting in line to get a haircut, I figured why not spend this time wisely, and tried to find a way to transcribe and summarize these notes from the phone.

No luck. Can't do it on the phone. Even "saving" something into the "Downloads" folder into "Files" proved to be nontrivial.

Half an hour later, from a proper keyboard at home, I started the same process. No luck again. Even ChatGPT just straight out fails to parse the attached file.

Instead it suggested I use the whisper model. Alas, the commands it suggested did not work right away. Well, I'm an engineer.

TL;DR: What worked, and was relatively painless and quick at the end of the day, was to download the text-to-speech model and run it locally.

# ~10 seconds
git clone https://github.com/ggerganov/whisper.cpp

# ~1 minute
(cd whisper.cpp; make -j)

# ~5 minutes
(cd whisper.cpp; ./models/download-ggml-model.sh medium)

# ~10 seconds
(cd audio; ffmpeg -i audio.m4a -ar 16000 -ac 1 -c:a pcm_s16le audio.wav)

# ~3 minutes
(cd whisper.cpp; ./build/bin/whisper-cli -m models/ggml-medium.bin -l ru -f /home/dima/whisper/audio.wav)

Then I used the "standard" AI tools to pre-summarize the above, to finally do my own "human-creative" part manually.

Why no Earth is there no product avaialble?

I'd clearly have used a (free) Web version right away, from that barbershop line.

And I'd definitely pay for premium features, which are super obvious:

1) Split into sentences, not just a wall of text like news broadcast subtitles.

2) Detect who is speaking, so that the summary contains names, not just text.

3) Sentiment / WPM analysis.

4) Summarization on-demand; in fact, it can pre-run dozens of summarizations with various prompts, to let me choose which one I prefer, now and in the future.

5) Bonus: If there are multiple people, tell me who does and who does not get message right away.

6) Bonus bonus: When transcribing live, use the knowledge from the past to a) label speakers correctly, and b) suggest when it is important to slow down and explain again, since that other speaker asking clarifying questions has a track record of not understanding what's going on =) perhaps it can even suggest how I can and should adjust my own speech knowing who's listening to me right now.

Where is such a product? It's a super obvious one, isn't it?

No comment on Katy Perry, but I sincerely believe high screen refresh rate — as well as ultra-low latency on both the screen and mouse/touchpad — are extremely high contributors to productivity and overall well-being of us, the tech folks.

Seriously, and I wrote about it before: my number one "test" when choosing a gadget is how responsive it is.

I just can't enjoy using a touchpad + screen combo on a laptop if it's under 60HZ. And I will likely pay more for it to be ~3ms, not ~10ms end-to-end latency.

I am often rejecting tablets specifically because I feel an extra ~0.05 seconds lag between my tap on the screen and the response, and it's annoying af.

Sure, high refresh rate does consume more energy. But you know what? I have a draft blog post breaking up energy consumption per capita into various human activities.

TL;DR: a higher refresh rate it veeeery low on the list of what's worthy of saving on.

I could even make a stretch argument, that might well be true if counted carefully, that the world would score a net win if we all use 150HZ screens, but top ~20 websites get rid of PHP and Ruby.

If this sounds too ambitious to you to rebuild several services overnight, here's a better idea. Let's embed anonymous, untraceable adult content video players with peer-to-peer caching into major operating systems and devices. Just a MacBook or just a Microsoft Surface would likely be enough if instead of visiting whatever XXX website in whatever browser, people would get used to opening a local app.

And both MacOS and Windows have sophisticated means to push OS updates to devices such that the devices then self-organize to distribute these updates among themselves. So all we need is to push movies as well, in the order of several gigabytes per day. We can and will encrypt them, of course, so kids do not accidentally get exposed, and adults who have religious objections to such an idea are shielded from anything and everything. But this will be far better energy footprint wise than asking users to lower their screen refresh rate!

In other words, it's never about the "greater good", folks. Although blessed are those who believe. Amen.