A Blog: Rare texts, musing and free range ranting

On Open Weights and American AI Leadership

On the 24th, Microsoft published a letter called Open Weights and American AI Leadership and currently fifty tech companies have signed it. The gist 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. 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. It can be studied, modified, and rebuilt from first principles. Open weights means receiving a forty billion parameter binary blob and being wished luck. It is the difference between a cookbook and a frozen dinner. Both involve food. Only one allows the recipe to be changed.

The signatories 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 CUDA and GPU drivers? Yeah. So they want to release model weights. Or they release nothing at all and rent API access by the token. Calling a weight dump “open” is like calling a PDF “open source” because it can be read with a magnifying glass.

The geopolitical framing is equally convenient. The letter warns that restricting open weights will “drive innovation overseas.” Non American models are treated as a looming threat. American models, meanwhile, 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 flexible concept when it serves the bottom line.

What makes the posturing absurd is the timing. The AI frontier has been 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 promising. They are also mostly theoretical. The geopolitical architecture is being built before the building has a purpose.

The most cynical move is the compute shift. The letter celebrates open weights 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. The signatories are not offering to build those data centers. They are offering a file download that forces the recipient to build (or buy) their own compute. Big tech keeps the training revenue, 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). Chips. Cloud. Models. 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 country buys the hardware to run them.

Open source lowered barriers. Open weights shift them. Open weights are a good thing, but I doubt this play is done with good, open intentions.

I guess time will have to prove me wrong. Maybe it does.

Permalink: /blog/2026/07/26/Open/

HOWTO: Use Sonos Speakers as Audio Outputs on Debian 13

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.

Permalink: /blog/2026/07/15/SONOS-on-Debian-13/

Second Brain

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?

Permalink: /blog/2026/07/11/Second_Brain/

The Sovereignty Rant

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 critical dependencies stack up into layers sort of neatly (ok not really, but bear with me), which is reassuring right up until it isn’t. 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 it’s 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 it seems surprisingly many things depend on it and a single API call that can quietly vanish over a weekend is a problem. The network 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 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. Demand arrived long before anyone agreed what the word meant, so 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, 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 wolves to help design the chicken coop fence has a predictable result.

The nice part is that telling real from snake-oil doesn’t require a law degree. A handful of rude questions does most of the work.

The switch test goes first. Can a foreign government or a vendor’s HQ cut access overnight, and has it already happened to some other poor soul. Then key custody. Who holds the encryption keys, and who can be quietly compelled to produce them. Then the model layer. Closed API, or open weights that actually run in-house. Then the legal entity, which is the question vendors hate most. Not where the datacenter is, but who genuinely owns the company operating it. Then portability. A tested exit, or a slide that confidently says “multi-cloud” and means nothing. And finally the money trail. Whether the spend is building real capability or just renting someone else’s platform with a local flag sticker slapped on the side.

Failing one question isn’t necessarily a death sentence. Having no answer at all is. A dependency where nobody can describe the blast radius is 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 the sales deck forgot to mention.

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.

The framing that keeps popping up in my mind is the fact that we should 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. One honest caveat. The strongest open weights right now are mostly Chinese, and no amount of squinting changes that. Openness still means the thing can be inspected and run locally regardless of origin. Pretending the origin doesn’t exist just makes for worse decisions later.

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 do it is thin to nonexistent. Sovereignty without an evaluation pipeline isn’t sovereignty. It’s running a stranger’s 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. It’s mostly just comfortable.

History is rude to the shrug, though. Airbus, GSM, and Galileo all looked adorably naive at the start and all turned out fine. The contrast with Gaia-X is the whole lesson. The ones that worked had mandated demand and a long horizon. The one that flopped 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 high-availability, databases and regions, we just need to drag up that old stuff and apply it to the AI-layer.

At the team level, the switch test slots into the next vendor review or RFQ. A self-hosted open-weight model is a perfectly reasonable spike for one non-critical workload. And writing down what actually happens if a given vendor vanishes tends to be clarifying, in the way a cold shower is clarifying. Treat critical AI and cloud less like a SaaS subscription and more like infrastructure supply. Reserves, redundancy, and an exit plan that has been tested rather than merely promised.

Which lands back on the off switch. Sovereignty was never really about isolation or flags. It’s about the ability to keep running when someone an ocean away changes their mind on a Friday afternoon.

Permalink: /blog/2026/06/16/Sovreignity/

AI Is Making Us Write More Code. The Code Is Getting Worse.

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 are pretty impressive. 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. You knew there was going to be one. 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%. Yikes.

They call it Acceleration Whiplash

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. Tools like Cursor and Claude Code in agent mode just apply changes directly. You used to make many small accept/reject decisions as you went handcoding. Now you 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 REALLY hard.

Coide 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.

Your best engineers are doing quality control. 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 — lines deleted vs. added — went up 861% under high AI adoption. This shouldn’t really come as an surprise to anyone who has worked with AI at any lenght. It loves refactoring and rewriting things. Sometimes it’s good, however most of the time it’s just completely unnecessary. But at nearly 10× the prior churn rate it’s worth understanding before you take 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, it doesn’t do well with “long term memory”. 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. But it’s a tradeoff 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.

It’s nice to start seeing real data and behaviors over longer time scales together with perspective, the entire field needs more of this and less of ..well whatever it is that the hypecycle is serving today.

Permalink: /blog/2026/06/15/More_Code/