A Blog: Rare texts, musing and free range ranting

On the 24th, Microsoft published a letter titled Open Weights and American AI Leadership and currently fifty tech companies have signed it. The gist of the letter is, they want “open weight” AI models to be treated as a pillar of American national security.

It is a masterclass in conflation.

The letter spends paragraphs praising open source software. Linux. The internet. Scientific research. Sounds great. Then it pivots.. to Open Weight, not Open Source. Open weight models are framed as the natural successor to the Open Source tradition. They are not.

Open source means getting the recipe, the compiler flags, the training data provenance, the bug tracker so it can be studied, modified, and rebuilt from first principles. Open weights means receiving a forty billion parameter binary blob and being wished the best of luck. It is the difference between a cookbook and a frozen dinner. Both involve food, but only one allows the recipe to be changed.

The signatories of course know this. Most of them do not open source their frontier models. Most of them don’t actually open source anything at all. Imagine NVIDIA open sourcing their CUDA and GPU drivers? Yeah. That’s obviously not going to happen. So they want to release model weights. Or they release nothing at all and rent API access by the token and still get to call it “open”. Calling a weight dump “open” doesn’t make the model open source. It just means we know what the final state of the model was and can do some our own parameter tuning based on it. It’s not a bad thing, but it’s also not open source.

The geopolitical framing is equally convenient. The letter warns that restricting open weights will “drive innovation overseas.” Non American models are naturally treated as a looming threat to “good guy American models”. These are framed as the safe, sovereign choice. This from the same companies that store customer data in Dublin, train models in Singapore, and source chips from Taiwan. Sovereignty is a very flexible concept when it serves the bottom line.

What makes the posturing absurd is the timing. The AI frontier is being recast as a Cold War race. Congress is drafting bills. Export controls are expanding. Billions in defense contracts are being negotiated. All for a technology whose primary consumer use cases remain autocomplete, chatbots, and generating images of astronauts on horseback. The industrial applications are certainly promising. They are also mostly theoretical at this point. No one really knows if any of the use-cases we’re talking about it worth the associated cost. But the geopolitical architecture and rhetoric wars are being built before the building has an actual purpose.

The most cynical move of this letter is the underlying compute shift. The letter celebrates open weights (sorry open source) because they let organizations “run on their own infrastructure.” This sounds like empowerment. It is actually a capital expenditure transfer. Training a frontier model costs hundreds of millions. Running it at scale requires a data centers full of GPUs. This is the model we have at the moment and big tech has been subsidizing the consumer token costs since the start. If the real cost would hit us, I doubt we’d see widespread AI adoptation. So new revenue streams are sorely needed to pull these companies out of red bottom lines. The signatories of the letter are not offering to build those data centers. They are offering you a 120Gb binary VRAM blob and a table of numbers that might help you to do some fine tuning. You can build your own datacenters. Big tech keeps the training secrets, the cloud rental revenue, and the chip partnerships. The consumer gets the electricity bill and the cooling problem.

This is not open source. It is open cost.

The letter ends with a flourish about “American technological leadership” and “shared prosperity.” Shared by whom is the question. The signatories include the same half dozen companies that control every layer of the stack (yeah and ok, DoorDash, apparently for some reason) and keep swapping the 10 trillion dollar I.O.U between themselves. They control the chips. the cloud. The models and their distribution. They are not asking for an open ecosystem. They are asking for regulatory cover to keep selling binary blobs while the rest of the world buys the hardware and builds the datacenters to run them.

Open source lowered barriers. Open weights shift them. Open weights are ultimately a good thing, but I doubt this play is done with good, open sourced intentions. Quite the contrary, I’d imagine.

Maybe I’m cynical and jaded. Maybe time will prove me wrong. Maybe.

So I have bunch of SONOS speakers around the house and I wanted to use these from my Linux desktop machine, essentially just like I’d use them from Spotify Connect (selecting one of the SONOS speakers as output and that’s it).

Sonos speakers support AirPlay 2, and PipeWire — the default sound server on Debian 13 “Trixie” — has native AirPlay (RAOP) support.

That means you can make your Sonos speakers show up right in the system audio menu and route any application’s sound to them, no third-party software required.

Prerequisites

Everything needed ships with a standard Debian 13 desktop install:

• PipeWire with pipewire-pulse and WirePlumber (the default audio stack)
• libspa-0.2-modules (contains the RAOP modules; installed with PipeWire)
• avahi-daemon running, for mDNS discovery — check with:

systemctl is-active avahi-daemon

• Your PC and the SONOS speakers on the same network
• If you run a firewall, allow incoming UDP on ports 6001 and 6002 (AirPlay timing/control traffic), e.g. sudo ufw allow 6001:6002/udp

Only Sonos models with AirPlay 2 work (roughly everything from the Sonos One and Beam onward). Older models would need a DLNA-based tool like pa-dlna instead.

Step 1: Enable AirPlay discovery in PipeWire

Create ~/.config/pipewire/pipewire.conf.d/raop-discover.conf:

context.modules = [
    { name = libpipewire-module-raop-discover }
]

Step 2: Restart PipeWire

systemctl --user restart pipewire pipewire-pulse

Step 3: Verify

List your audio sinks:

wpctl status

Each discovered speaker appears as a sink named after its Sonos room, e.g.:

├─ Sinks:
│      62. Office                              [vol: 1.00]
│      80. Built-in Audio Analog Stereo        [vol: 0.40]

They also show up in your desktop’s sound settings and audio menu. Select one and play something — expect a 1–2 second delay when the stream starts (AirPlay buffering), after which audio stays in sync.

To test from the terminal:

pw-play --target <sink-id> /usr/share/sounds/alsa/Front_Center.wav

Troubleshooting

Which speakers are on my network?

Sonos devices answer SSDP queries and expose a description XML on port 1400. Quick inventory with avahi (apt install avahi-utils):

avahi-browse -rt _raop._tcp     # AirPlay devices visible via mDNS

Or query a speaker directly if you know its IP:

curl -s http://<speaker-ip>:1400/xml/device_description.xml | grep -E 'roomName|modelName'

A speaker doesn’t appear in the sink list

PipeWire only creates sinks for speakers that Avahi discovers via multicast mDNS. On some networks (Wi-Fi access points with IGMP snooping, or speakers meshed over SonosNet) the multicast responses never reach your machine, even though the speaker is reachable directly.

The fix is to define the sink statically by IP. Create ~/.config/pipewire/pipewire.conf.d/raop-static-sonos.conf:

context.modules = [
    {   name = libpipewire-module-raop-sink
        args = {
            raop.ip = "192.168.1.50"          # the speaker's IP
            raop.port = 7000
            raop.name = "Kitchen"
            raop.transport = "udp"
            raop.encryption.type = "auth_setup"   # required for AirPlay 2
            raop.audio.codec = "PCM"
            stream.props = {
                node.name = "raop_sink.sonos_kitchen"
                node.description = "Kitchen (Sonos)"
            }
        }
    }
]

Two notes:

• raop.encryption.type = "auth_setup" is essential. Discovered sinks pick this up automatically from mDNS, but static sinks default to none, and Sonos speakers reject unauthenticated streams.
• Give the speaker a DHCP reservation on your router, since the config pins its IP.

Restart PipeWire again after editing.

A speaker appears but playback fails with “403 Forbidden”

If a sink exists but vanishes the moment you try to play to it, check the PipeWire log:

journalctl --user -u pipewire | grep -i raop

A 403 Forbidden reply to the RTSP handshake means the speaker has AirPlay access control enabled (acl=1 in its mDNS records). This happens when the speaker has been added to Apple Home with restricted access. You can fix it on the Apple side: in the Home app, go to Home Settings, then Speakers & TV Access, and choose “Anyone On the Same Network”.

Two sinks appear for the same speaker

Avahi sometimes reports a device twice (IPv4 and IPv6 cache entries) and create duplicate sinks. If it bothers you, pin discovery to specific devices with stream.rules in raop-discover.conf — match on raop.name (the MAC-prefixed mDNS service name) and use the rules to exclude duplicates or rename sinks:

context.modules = [
    {   name = libpipewire-module-raop-discover
        args = {
            stream.rules = [
                {   matches = [ { raop.name = "~804AF297F666@.*" } ]
                    actions = { create-stream = {
                        stream.props = { node.description = "Office (Sonos Era 100)" }
                    } }
                }
                {   matches = [ { raop.name = "!~804AF297F666@.*" } ]
                    actions = { create-stream = { } }
                }
            ]
        }
    }
]

With this small config change you get Sonos speakers as audio outputs, visible in the audio menu.

I recently tried Obsidian. Again. For maybe 7th time… inspired by someones youtube video about organized project documentation which has always been my nemesis. I like writing notes, with a paper and pen, but I’m a complete administrative catastrophy when taking notes or “drafting ideas” using digital devices. The “second brain” pitch is about capturing everything you read and think into Notion or Obsidian notes, organizing it with the right method, and an external mind should emerge.. one that makes you smarter, more creative, and (per the YouTube thumbnails) helps you run a six-figure business. There’s a book, a course, a certification program, and an entire ecosystem of tools and influencers built on the idea.

Every single one of these “second-brain systems” seems be focusing on how to easily capture notes and then magically by connecting them with (can you believe..) links, derive some kind of value out of it.

I have a bookmark folder called “New Stuff”. I put new links in there every now and then, but I hardly ever look at them, because it’s just easier to fire a new search for whatever I’m looking for. The folder has around 2500 bookmarks in it. “This looks interesting” link folder is hardly a second brain. But lot of the self-help videos seem to think there’s something valuable in this so maybe I just don’t get it.

There is, as far as I can find, no peer-reviewed study showing that second-brain systems improve learning, output, or anything else. The entire evidence base is testimonials, largely from people whose job is selling the method.

But there is some evidence pointing the other way. “Google effect” would indicate that in controlled experiments, people who believed a computer would store what they typed remembered significantly fewer facts than people who believed it would be erased. Your brain, perhaps quite rationally, doesn’t bother to keep what it believes is filed somewhere else. So a second brain maybe isn’t a “idea backup storage”. It’s basically an instruction to your first brain to zone out and take a break.

Saving a thing feels like learning the thing. I always feel “important” when I drag a new link into my “New Stuff” folder. But I don’t think I learn anything from it. It’s just a dopamine hit from doing something you believe is useful.

I’m sure there are many good use-cases for these systems if you’re an author or academic researcher but I’ve personally never really found any use for them. And I’ve been trying for years.

Of course now that we’re in the (sigh) AI era, it seems these systems are focused on pointing Claude Code or some MCP agent at your Obsidian vault and believing your second brain finally “comes alive” to run your business (why does everyone taking notes always have to aim for running a business?)

But sure. Maybe your AI session gets better context out of it. But if the whole point of your notes is that a machine reads them, your incentive to learn anything at all in your own brain drops to zero. You’re not building knowledge. You’re curating a prompt library while getting small dopamine hits because it feels useful and important.

When did you last retrieve a note that changed your project or code? If the honest answer is “I usually just Google it,” you don’t have a second brain. Maybe you just have a very organized way of avoiding your first one.

That’s how all my attempts have ended up so far. I’m pretty sure I’ll keep trying though because it sounds good. Help me understand this?

So the US government decided Anthropic’s frontier models couldn’t be shared outside its borders. No deprecation notice. No migration guide. No apologetic status page with a little yellow icon. Just gone on a Friday, which is of course the only day anything ever breaks.

Sovereignty drags a lot of flag-waving baggage behind it. The engineering version of the word is much smaller and far less self-important. It has nothing to do with patriotism or “buy local to feel good.” It’s about whether a critical dependency can be yanked by someone who isn’t in the room and was never going to ask first.

These days, these critical dependencies stack up into layers, neatly enough to be reassuring right up until it isn’t. In relity, every layer is just a spot where someone else gets to throttle, meter, or just pull the plug.

At the top is the app and SaaS layer, the Microsoft 365s and Workspaces everyone swears they could migrate off any time now. Below that is the freshly arrived AI model layer and its APIs. Under that, cloud and compute, where most of Europe’s spend cheerfully flows to about three American companies. Below that, chips, governed by export rules that change with the mood. And at the bottom, connectivity, the satellites and subsea cables nobody thinks about until a Russian fishing trawler drags an anchor across the bottom of the ocean.

The AI-model layer is the new arrival. A year ago it wasn’t really on the register at all. Now half the stack depends on it and we’re all apparently fine with a single API call that can quietly vanish over a weekend. Just fine. No concerns. Our modern infrastructure has chokepoints, and whoever’s sitting on one gets to squeeze whenever it’s convenient.

The word “sovereign” is now stamped on basically every cloud and AI vendor homepage, usually next to a stock photo of a flag or a very secure-looking padlock. It’s the new “cloud-native.” A few years ago everything was cloud-native, including products that were just a VM in a trench coat. Last year everything was “AI-powered,” including a few things doing what was clearly a regex and a prayer. AI demand arrived (or was drummed up by the vendor hype machine) before anyone agreed what the word meant. The vacuum got filled with whatever definition was most flattering and least expensive to claim. The mechanics are pure greenwashing. Find a thing people want, find the cheapest way to look like it’s on offer, and get it onto the slide before legal wakes up.

The usual shape is depressingly consistent. A local datacenter gets stood up in some small far-away village with a promise of tech jobs, a stack of compliance certs gets collected, and the whole thing gets christened a “sovereign cloud.” But where data physically lives and who has authority over it are two completely different questions. If the company running it is headquartered somewhere whose laws can compel it to hand over data or cut access, the location of the disk is a charming detail and nothing more. The CLOUD Act and FISA 702 are the usual party guests. It’s sovereign the way a rental car is “your car” right up until someone with more authority and a clipboard wants the keys back.

The EU’s shiny new cloud-and-AI law comes with four whole tiers of “sovereignty assurance,” which is about three more tiers than anyone actually wanted. Only the top tier actually keeps non-EU providers out. Everything below it lets the usual hyperscalers waltz in, provided their home country counts as “aligned enough,” a phrase doing an Olympic amount of deadlifting in this context. Some of the “sovereign” contracts already going out are landing with joint ventures that politely include the exact foreign giants the whole exercise was meant to reduce dependence on.

And for the all-time cautionary tale, there’s Gaia-X. A 2019 push for a sovereign European cloud. Spectacular volume of diagrams, working groups, and press releases. Almost nothing in production. Not for lack of engineering talent, but because the setup was voluntary, fragmented, and quietly steered by the very incumbents it was supposed to dethrone. Turns out asking the foxes to help design the chicken coop fence has a predictable result.

The small mercy is that telling real from snake-oil doesn’t require a law degree.

Can a foreign government or a vendor’s HQ cut access overnight, and has it already happened to some other poor soul? Who holds the encryption keys and who can be quietly compelled to produce them? Closed API, or open weights that actually run in-house? Not where the datacenter lives but who genuinely owns the company operating it? Whether there’s a tested exit plan or just a slide that confidently says “multi-cloud” and means nothing? And where the money actually goes? Because the spend is either building real capability or just renting someone else’s platform with a local flag sticker slapped on the side.

Failing one of those isn’t a dealbreaker. Having no answer at all, not being able to describe the blast radius, that’s already a hole in the floor.

For language models specifically, the options tend to collapse into three, and every one of them comes with a catch.

US closed frontier models are the most capable. The catch is the switch lives in someone else’s hand, possibly someone who tweets or uses too much orange tan spray. Chinese open-weight models like Qwen and Kimi are cheap to the point of being almost suspicious, auditable, and happy to run locally. The catch is the censorship, the narrative baggage, and a brand new dependency to replace the old one. Building European models, Mistral and the various public-sector efforts, gives genuine control. The catch is it’s slower and costs real money, two things committees love.

We need to stop picking a country and start picking an architecture. Open weights on owned infrastructure can’t be killed from a distance. That property holds no matter whose flag the model shipped under. The capability gap is closing fast too. The distance between the best open model and the closed frontier went from about a year to a few months, and on coding they’re basically neck and neck. The strongest open weights right now are mostly Chinese, and no amount of squinting changes that. Open weights still mean the thing can be run locally regardless of origin.

Downloading a model is the easy bit. It’s basically a git clone and some disappointment about your available VRAM. Knowing whether it’s safe to point at a bank, a hospital, or a government workflow is actual engineering, and it’s the part almost nobody has bothered to fund.

Evaluation, red-teaming, regression-testing a model before it gets anywhere near production should be the standard. The EU’s AI Act waves vaguely in this direction for the most capable models, but the in-house muscle to actually do any of it is thin to nonexistent, and nobody seems particularly bothered about that part. Sovereignty without an evaluation pipeline isn’t sovereignty. It’s running a stranger’s 120Gb binary as root and calling it strategy.

The reflexive response to all this is a world-weary shrug. The argument goes that EU catching up is hopeless, so the grown-up move is to negotiate decent terms and make peace with the dependency. It sounds like realism.

Airbus, GSM, and Galileo all looked adorably naive at the start and all turned out fine. These are all projects that had mandated demand and a long horizon. The Gaia-X flop had a voluntary consortium and a lovely set of intentions.

None of this requires becoming a policy person or saying “strategic autonomy” out loud in meetings. Most of it is the instinct already applied to tech everywhere; we just need to drag up those old desogns and apply it to the AI-layer. Nothing has really changed.

At the team level, spending some time thinking and writing down what actually happens if a given vendor/model vanishes tends to be clarifying, in the way a cold shower is clarifying. “Critical AI” and cloud dependencies get treated like SaaS subscriptions when they should be treated like infrastructure supply. Reserves, redundancy, and an exit plan that has been tested rather than merely promised.

And all of this lands back on the off switch. Sovereignty isn’t about isolation or flags. It’s the ability to keep running when someone an ocean away changes their mind on a Friday afternoon. That’s it. That’s the whole ask.

A report from Faros, that draws on two years of data from 22,000 developers, lands with a pretty clear message: AI coding tools are making developers faster, and that speed is quietly breaking things downstream.

The throughput numbers look fantastic, assuming you only look at the throughput column. It seems no one actually codes without AI anymore. And as a result, task completion up 34%, big features shipping 66% faster per developer, code-specific work up 210% at the team level. But then there’s the other column. Bugs per developer are also up 54%, the chance of a production incident per merged PR has tripled, and 31% more pull requests are being merged with no review at all. Median time in code review is up 441%.

AI writes code that looks sort of right. It’s (mostly) clean, well structured, idiomatic, well-named. The problem is that a large codebase has years of accumulated context. Why a module was built a certain way, what the rest of the system depends on, what breaks at the edges. AI models just can’t know that, so they fill the gaps with plausible-sounding guesses. Usually fine. Sometimes not.

The small interactions with coding decisions have changed. Agent mode tools like Cursor and Claude Code just apply the diff directly. We used to make many small accept/reject decisions as we went hand-coding. Now we get to review a big diff at the end. The human judgment didn’t disappear, it just got compressed into a single coarser decision, often made quickly. And from experience, keeping those diffs readable and understandable is practically a full-time job on its own.

Code generation is way faster than review. One developer with AI can produce code way faster than any reasonable number of humans can carefully read it. When both sides move at human speed the system stays in balance. When one side accelerates by an order of magnitude you get exactly what the report data shows: a pile-up at review, people getting buried, eventually merging things without looking.

So your best engineers are doing quality control now. AI code has a specific failure mode. It looks superficially fine but has subtle structural problems which you won’t realize until you’re neck deep in it. The only people who reliably catch those are senior engineers, who now spend their days reviewing AI output instead of solving the actual hard problems. Throughput is up, but it’s not a great use of anyone’s most expensive hours.

The feedback loop is slow. Velocity metrics look great right now but the costs show up in incidents and rework, which take months to accumulate and often get owned by a different team entirely. By the time the pain is visible, the decisions that caused it are six months in the past.

Code churn went up 861% under high AI adoption. Naturally, this surprises absolutely no one who has spent five minutes watching an LLM refactor a file it just wrote. It loves refactoring and rewriting things. Sometimes it’s good, however, most of the time it’s just completely unnecessary. At nearly 10x the prior churn rate it’s worth understanding before you take the previous throughput numbers at face value. A lot of it is just refactoring for the sake of it.

Adding more reviewers or stricter QA gates is only treating the symptom. The problem is at the authoring stage. AI agents work with incomplete context. They can see the current codebase but not why it looks the way it does. This kind of context is hard for AI, as it doesn’t do well with long term memory and actual deep understanding. But giving it some of that context (architectural decisions, historical constraints, testing requirements) makes the output substantially better from the start and causes less of a pile-up at the review stage. Doesn’t eliminate it, but mitigates somewhat. It’s a tradeoff though, as you’ll be adding more and more things into the AI context window.

The report also makes a clear case against cutting headcount because AI output is up. The engineers who look cuttable on a velocity dashboard are often the ones absorbing the quality gap AI is creating. Remove them and that buffer disappears. Finally some common sense.

At least it’s nice to see real data over longer time scales. The field needs more of this and less of whatever the hype cycle is serving today. Assuming anyone in management is actually listening, anyway. Maybe.