Dima

Folks don’t you see it’s the entire plan? The only government-approved employer is the government. I do hope this experiments ends sooner rather then later. Because we all know well **how** it will end.

The bar is far too low, but sure, many of us could.

I just got to the proper keyboard, and might be late to the party, but I want to go on record with my early thoughts on the Binance hack. 1. We got a solid proof of how centralized stablecoins really are. And we got a solid proof that it's not enough. Which is very sad. 2. Laymen pundits are receiving more and more signals that blockchain is not secure, while in reality there's nothing more secure than the blockchain today. One has to keep their private keys private though, which is excatly what is NOT happening as we speak. 3. This only means that [cold] crypto assets will be more and more marginalized. Which may well be a good thing all in all: I'd be happy to live in the world where small amounts happily travel cross-border etc. as crypto, while for large amounts we go institutional. 4. Binance is definitely at fault for not securing their contracts, and at the same time I very much hope we will not see any chain-level rollbacks (i.e. I hope for no forks). Seriously, not signature-gating withdrawals and still using one huge hot wallet is just so, so wrong. All in all I personally would love the world to have taken a different turn on Web3 assets. I.e., if we're talking a centalized exchange, all it takes to secure is is to put **all** KYC/AML receipts on-chain, in an encrypted and signed way. Make withdrawals subject to some 72 hours hold, audit any and all blocklists with full transparency, and here we go. Instead, we'll just keep seeing how DEX-es are simultaneously more secure than CEX-es (sic!) **and** DEX-es will be more and more tighly regulated. Enshittification at its finest, because large governments are no different from corporations, and corporations, when they reach monopoly status, can't stand it when emerging second-tier players can and do offer a better service for a lower price. I might be wrong, of course, that's why I'm a huge fan of going on record with thoughts like this.

Wait, all three of them?

Yay for @yonasbe!

Ref. jlevy.github.io/squares/visu… and Josh himself!

Serious question out of the blue: Do we even need Linux for servers these days? A friend sent me github.com/asterinas/asterin… over the weekend. I looked into it and could not form an opinion on whether it will or will not fly. From first principles, it should. The reality check, however, is that it's a few years old already, and not taking the world by a storm. Then I thought deeper. Golang, with all my disrespect to it as a language, is increasingly popular. And it's goroutines-first, i.e., cooperative multitreading is its building block. Most Rust production-grade code uses tokio these days. Or something like it. So, Rust code is also cooperatively multithreaded by design. Also, look at Nvidia GPUs. We, the world, have proven that a small set of chips can run the planet. No need in a huge variety. Apple's M1-M5 chips are another proof. Besides, Google was experimenting with turning old Pixel phones into the CPUs that power a datacenter. So, compute-wise, do we even need linux? Why can't we take one well-designed system-on-chip ARM, and give it a tiny wrapper on which a Golang runtime or a Rust tokio runtime can flourish? And it can be a thin real-time OS, which Linux is definitively not. Seriously, seen in this light, most of POSIX can, and arguably should, be treated as legacy. It's a source of unwanted synchronicity, and it's a source of bugs, after all. A tiny kernel, a blob storage, and a well-optimized async-friendly massively parallel network controller is all we need. So, from first principles, I can see a competitor to AWS emerging, where at a fraction of cost we can run Golang code or Rust code with increased reliability. The code may have to be implemented to use special libraries, and built with a dedicated toolchain, but this does not appear to be a problem in the day and age of agents. What am I missing? As in, aside from the legacy "too big to fail" argument, why should we not expect something like this to happen in the next year or two?

As we discovered today, "please call the manager" when the staff is acting silly is literally the same as turning model reasoning on and retrying the prompt. The very same prompt in most cases, I should add. Just against a reasoning engine with a larger context window.

"People are irrationally hesitant to show their prompts", "do you go back and correct typos in your prompts?" (c) Peter Steinberger Dude, sometimes I prompt without spaces to keep the room quiet. Pasting an image and saying `dafaq` is a marker by which OpenAI and Anthropic can probably trace my presence across platforms. And if my keyboard layout is сщташпгкув цкщтпдн and I notice it mid-paragraph, I would generally just continue ещ ензу фы шы, because why waste precious human time on something agents will handle in a split second with zero effort? People who hesitate to share their prompts have it backwards. "It's a boomer thing", as Peter rightly says. Thx for the event yesterday!

Someone really needs to do to git what uv did to python. I'd chime in, but am oversubscribed now :-(

This deserves an entirely new browser, and I, for one, would try it out if it's open source.

Oh well. Fix it, dear agent.

2021: Why can't we solve machine translation? 2026: Wispr Flow is so good at trying to make my speech make sense as text that it literally parsed my three lines long Russian instructions as Ukrainian. I don't speak or understand Ukrainian. I've translated that resulting text back into Russian. That's exactly what I wanted my agent to do. "Accidental translation" in 2026 is literally better than bleeding-edge translation in 2021. Cross-language understaning is a commodity now. It is cheaper to translate in 2026 than it was to understand штсщккуседн-сщташпгкув-keyboard-layout text in 2021.

Inspired by a recent conversation. I can somewhat understand copyright on authored texts when it comes to pieces of art, also known as literature. But I can't understand no-AI-training clauses or README demands that models not read the code. So you are publishing a piece of code that you are not allowing models to train on? And I immediately think of consumer tools, such as CLI / TUI utilities. Well, if it's useless code, it's useless regardless. And if it's useful, a *lot* of people are using this code. It's easy to use programmatically. It's easy to use when it's run on a remote machine. It's easy to use when it's 100% sandboxed. It's easy to put under `tmux` and `asciinema`, which I do routinely. And presumably your tool has decent help. And forums. And tons of data on how best to use this tool, and how it is used. And then you say "don't read this source code with AI"? Seriously? It would take single-digit dollars — LITERALLY SINGLE-DIGIT DOLLARS — to blackbox-sandbox your tool, DOWN TO ALL OS CALLS IT MAKES, and to ask a few AIs to read its help, to read the forums, and to come up with a fully functional demo of the features people actually use. And then another, I dare say, SINGLE-DIGIT HUNDREDS OF DOLLARS to reimplement those features from scratch. Without a single glance at your tool's source code. So, if it's a useful tool that people need, you're just sitting on a ticking time bomb if you choose to sit on its otherwise-open code as a dragon hoards its treasure. The rebuild happens either way; sitting on the source just leaves you outside the process. In fact, everything I'm saying above applies to closed-source software too. With proprietary, closed-source software, by the way, the difference is enforcement. The same black-box rebuild applies, but lawsuits are only plausible where there's real money on the table; real money that could be won. And a large corporation behind those lawsuits, with an army of lawyers and with tons of money at stake. But a low-key developer, or a community of low-key developers, who have been maintaining some tool(s) over the years? Sure, you could argue you've invested a few hundred hours into your baby tool; perhaps a few thousand hours. You're not going to court for it. Moreover, you're worth more as the expert who steers the rebuild than as a pile of source code you won't let models read. You can LITERALLY approach big AI companies and offer that expertise. After all, a great-to-use tool with wide adoption — wasn't this what you were working for all this time, as enthusiasts? During "peace times", i.e. assuming there's no "AI war" for training data, who cares about the code, except perhaps security researchers? You built something many people use, great. Now the Universe is offering you a chance to make your own impact larger, by a wide margin. All you need is to say yes and collaborate. And yet quite a few people choose to turn their egos on instead, and "protect their code" from being "used by the AI to improve". As if they would have protested if some professors had showcased some important concepts to students based on their code or something. Don't get me wrong, there are quite a few prominent critics of Big Tech. I'm sure I can steelman their arguments too. RMS, for instance, is largely right, IMHO, that the death of truly open software is what created this siloed monopoly-run Big Tech, as opposed to Hypertext FIDO 2.0. But copyleft was about keeping code free to use and modify, not locking it away from machines that read it. And the cypherpunks community, while it has brought many useful tools and privacy wins such as PGP, is largely gone today. So yes, it's not difficult to steelman that criticism. But why not join forces? Why not view the AI as the force of nature, as the greater good, that we should all collectively leverage for a better civilization? Why instead choose to resurrect the luddites movement and fight against?

So we have a solid addendum to open-weights models thanks to Mistral, or is this a wrong way to read the news?

I wonder that is saying "for Sam's sake", "for Dario's sake", and "for Elon's sake" in prompts would yield better results.