标签：#c

Look closely at what AWS, Microsoft, and Google shipped for AI agents this year and you notice something odd. Different names, different branding, and underneath, the exact same product. That convergence is convenient right up until you try to leave. Here's what they're all building and why it should make you a little cautious. What all three are actually building Strip away the marketing and the three big clouds are assembling the same five-part stack for running enterprise AI agents: a managed runtime to execute the agent, memory so it remembers context, identity so it can authenticate and be governed, tools so it can call your systems, and observability so you can see what it did. The products are AWS Bedrock AgentCore, Microsoft's Azure AI Foundry with its Agent365 control plane, and Google's Vertex AI agent stack. They look different on the pricing page. Architecturally, they're the same idea built three times. This isn't a coincidence. When you're solving the same problem, running agents safely inside an enterprise, you land on the same pieces. The market basically agreed on the shape of an agent platform in early 2026, and each hyperscaler raced to own it on their own cloud. Why the convergence feels great at first If your data and identity already live in one cloud, that cloud's agent runtime is the fastest path to production. Your storage is there, your identity system is there, your logging is there. The platform snaps into all of it. You get governance, audit trails, and deployment almost for free. For a team that just wants agents running with proper controls, that's a real gift. I get the appeal. The catch nobody puts on the slide Here's the trap. When your agent's runtime, credentials, state, and telemetry all live inside one cloud, moving it somewhere else isn't a config change. It's a rebuild. Take AWS Bedrock AgentCore. An agent built on it is wired to AWS identity, networking, and storage. Picking it up and moving it to Azure or Google isn't a matt

Every time I needed to check whether my microphone actually worked before a call, or whether a key on a used keyboard was dead, I ended up on some sketchy "free online tester" that wanted an account, showed six ad banners, and — the worst part — happily streamed my webcam to a server I knew nothing about. So I built the thing I actually wanted: TestOnDevice — 118+ device tests that run 100% in the browser. No installs, no account, and nothing you record ever leaves your machine. Here's what I learned building it. The core constraint: the network is off-limits The single rule that shaped the whole project: no device data touches a server. No webcam frames, no audio buffers, no keystrokes, no sensor readings. That constraint turned out to be freeing rather than limiting, because modern browser APIs are genuinely powerful. Almost every "device test" is just a Web API plus a bit of rendering: What you're testing The API doing the work Microphone / speakers MediaDevices.getUserMedia , Web Audio ( AnalyserNode ) Webcam getUserMedia , <video> , MediaStreamTrack.getSettings() Keyboard keydown / keyup , KeyboardEvent.code Mouse / touch / stylus Pointer Events, PointerEvent.pressure Gamepads Gamepad API MIDI keyboards Web MIDI API Display ( dead pixels , refresh rate ) Fullscreen + requestAnimationFrame Motion / orientation DeviceOrientationEvent , DeviceMotionEvent A live mic meter, entirely local The microphone test is a good example of how little you need. Grab a stream, wire it into an AnalyserNode , and compute RMS on each frame for a level meter — no recording, no upload: const stream = await navigator . mediaDevices . getUserMedia ({ audio : true }); const ctx = new AudioContext (); const analyser = ctx . createAnalyser (); ctx . createMediaStreamSource ( stream ). connect ( analyser ); const data = new Uint8Array ( analyser . frequencyBinCount ); function tick () { analyser . getByteTimeDomainData ( data ); let sum = 0 ; for ( const v of data ) { const x = ( v - 128 )

The feature was supposed to be the easy one. NotebookLM generates flashcards. My extension reads them...

I self-host Umami for my SaaS, ParserBee . The main reason I picked it: privacy-friendly, cookie-less, first-party analytics that adblockers supposedly leave alone because the script comes from your own domain. That last assumption turned out to be wrong, and the reason is the subdomain name itself. Writing it up because the fix is small and the failure mode is silent. The problem My Umami instance ran at umami.parserbee.com , so the tracker was loaded like this: <script defer src= "https://umami.parserbee.com/script.js" data-website-id= "..." ></script> The EasyPrivacy filter list (used by uBlock Origin, Brave Shields, AdGuard, and most other blockers) contains a rule that matches the Umami tracker by hostname pattern, along the lines of: ||umami.*/script.js It doesn't target a specific company's server. It targets any host whose subdomain is literally named umami serving a file called script.js . Which is exactly how most of us name things when self-hosting: umami.mydomain.com , plausible.mydomain.com , matomo.mydomain.com . The filter lists know this convention, and they have rules for it. The result: every visitor with an adblocker never loads the script. No errors on your side, no console noise, nothing in the Umami logs. The traffic just quietly never shows up. I only caught it because signups were arriving from campaigns that Umami claimed nobody clicked; the server logs and Stripe disagreed with the analytics, and the server logs were right. The fix Serve the same Umami instance from a second hostname that no filter list matches. No proxying, no renaming files, no changes to the Umami install itself. I added u.parserbee.com as an alias for the same service: 1. DNS record. A CNAME (or A record) for u.parserbee.com pointing at the same server as the existing umami.parserbee.com . 2. Reverse proxy. Add the new hostname to the existing Umami site config so both route to the same instance. I run Umami in Docker behind Coolify, where this is just adding a second d

OpenAI just bought a cloud company, and if you only read the headline you'd miss the point. This deal tells you exactly where AI coding is heading: out of your editor and into the cloud. Here's what happened and why it matters. What OpenAI actually bought On June 11, 2026, OpenAI announced it's acquiring Ona, a German startup you might know by its old name, Gitpod. Terms weren't disclosed, and the deal still needs regulatory approval before it closes. Ona builds secure cloud environments where code can run. That's the whole reason OpenAI wanted it. Its Codex coding agent has grown fast, now past 5 million weekly active users, up from 3 million in April, and the jobs those agents run have gotten much longer. Tasks that used to take a few minutes now stretch into hours, sometimes days. An agent that works for hours can't live on your laptop. Close the lid and it dies. It needs a persistent place in the cloud to keep running. That's what Ona gives Codex, and notably, Ona's platform can run inside a customer's own cloud, which matters for enterprises that won't send code elsewhere. Ona's enterprise usage reportedly grew 13-fold this year, with clients like major banks and pharma companies. Why this is a bigger deal than it looks For years, AI coding meant an assistant inside your editor. Autocomplete, a chat panel, quick edits. The editor was the product. That era is ending. When agents run for hours on their own, the important question isn't "how good is the autocomplete." It's "where does the agent run, and for how long." The battleground is shifting from the editor to persistent cloud execution, and OpenAI just bought its way into that fight. The wider war OpenAI isn't alone in this move, which is why it feels like a real war now. Cursor already added cloud agents that run tasks without tying up your machine. Devin, from Cognition, was built cloud-first as an autonomous engineer from day one. Anthropic's Claude Code runs long, multi-step jobs and connects into your t

Something happened in 2026 that should be on every engineer's radar, especially if you work in finance, healthcare, government, or anywhere regulated. The US government labeled an American AI company a national security supply-chain risk. That had never happened before. Whatever you think of the politics, the professional lesson underneath it is big, so let me walk through it plainly. What actually happened The Department of Defense terminated a contract with Anthropic worth an estimated $200 million. The breakdown wasn't about price or performance. It was about how the military could use the AI. Anthropic's CEO, Dario Amodei, objected to a clause that allowed the military "any lawful use" of the model. Anthropic wanted the contract to explicitly rule out things like domestic mass surveillance and autonomous weapons, and refused to sign without those limits. The government wanted fewer restrictions. When talks broke down, the Secretary of War, Pete Hegseth, formally designated Anthropic a "Supply-Chain Risk to National Security." That label is normally reserved for foreign adversaries and hostile telecom vendors, think of how the US treated Huawei. This was the first time it had ever been applied to an American company, and reportedly the first time it was used because a company wouldn't agree to certain contract terms. OpenAI then stepped in to take the Pentagon work Anthropic had walked away from. There's a legal coda worth noting for accuracy. In March 2026, a federal judge granted a preliminary injunction against the government, writing that the designation looked like retaliation for Anthropic drawing public scrutiny, which she framed as a First Amendment problem. So the label is being contested in court, not settled fact. Why this matters beyond the headlines Strip away the politics and this is a case study in something every regulated team deals with: what happens when your AI vendor's policies collide with your requirements. Anthropic drew a hard line on use

🚀 JavaScript Fundamentals (Week-03): Building a Strong Foundation "Before learning frameworks like React or backend technologies like Node.js, it's essential to build a strong understanding of JavaScript fundamentals. A solid foundation makes advanced concepts much easier to learn." Introduction During Week-03 of my Full Stack Development learning journey, I focused on understanding the fundamental concepts of JavaScript . Instead of only writing code, I wanted to understand how JavaScript works behind the scenes . In this week, I learned about variables, hoisting, different types of scope, execution context, call stack, closures, the this keyword, call() , apply() , bind() , module patterns, and clean coding principles like DRY and KISS . In this blog, I'll explain each concept in a simple and beginner-friendly way with examples. 📚 Topics Covered What is JavaScript? Variables ( var , let , const ) Hoisting Scope Global Scope Function Scope Block Scope Lexical Scope Scope Chain Execution Context Call Stack The this Keyword call() , apply() , and bind() Closures Module Pattern Common var vs let Bugs DRY Principle KISS Principle Conclusion 📌 What is JavaScript? JavaScript is a high-level, interpreted, single-threaded programming language used to build interactive and dynamic web applications. Initially, JavaScript was designed to run only in web browsers, but today it can also run on servers using Node.js . Some common uses of JavaScript include: Creating interactive web pages Form validation DOM manipulation API communication Web application development Backend development with Node.js Example console . log ( " Hello, JavaScript! " ); Output Hello , JavaScript ! 📦 Variables Variables are containers used to store data. JavaScript provides three ways to declare variables: var let const var Characteristics Function Scoped Can be redeclared Can be reassigned Hoisted var name = " Sai " ; var name = " Rahul " ; console . log ( name ); Output Rahul let Characteristics Block

Strings & Text Processing: Text Isn't as Simple as It Looks If someone asks you what's the simplest type of data in programming, there's a good chance you'll say strings . After all, they're just text. A person's name is a string. An email address is a string. A password is a string. Even the message you're reading right now is just a collection of strings. At first glance, there doesn't seem to be much to learn. You create a string, print it, compare it with another string, and move on. But after writing a few programs, things start getting... strange. You convert "hello" into uppercase, yet the original string somehow stays the same. An emoji that looks like a single character suddenly reports a length of 2 . Joining thousands of small strings together makes your program unexpectedly slower. And then someone introduces you to something called Regex , which looks less like code and more like an ancient spell. None of these are bugs. They're simply the result of how strings actually work behind the scenes. In this lesson, we'll uncover those hidden details one by one. Surprise #1: Why Didn't the String Change? Take a look at this code. const original = " hello " ; const shouted = original . toUpperCase (); console . log ( original ); console . log ( shouted ); What would you expect the output to be? Many beginners think the output will look like this: HELLO HELLO But that's not what happens. Instead, JavaScript prints: hello HELLO The original string remains exactly as it was. Why? Because strings are immutable . What Does "Immutable" Mean? The word immutable simply means: Once something is created, it cannot be changed. Think of a printed book. If you want every occurrence of the word hello to become HELLO , you don't magically change the ink that's already on the paper. Instead, you print a new copy with the updated text. Strings behave in a similar way. Whenever you use methods like: toUpperCase() toLowerCase() replace() concat() the original string stays untouch

Hi, I designed and developed a spatial index that maps museum artefacts as connecting arcs/hyperlinks from their origin site to institutional location/sources. The Index specifically looks at western/euro-american institutions and maps their collection categorised by them under Islamic art, Asian/African art, ethnological collections, Middle East, South America etc. Started as my MA thesis in 2022, kept building since, mostly solo with a little funding. Fully open source, self-hosted, AGPL-3.0,

AI-powered PCB design tool for engineers and hardware teams Discussion | Link

The first hour with a new repo is archaeology: open package.json , skim the Makefile, hunt for .env.example , grep workflows for secrets. , check Compose for ports. I already built focused tools for each of those questions. What I still wanted was one command that prints the whole map. coldstart coldstart is that overview — offline, no accounts, agent-friendly JSON. go install github.com/SybilGambleyyu/coldstart@latest coldstart coldstart -md >> ONBOARDING.md coldstart -json It reports: Runtimes — Node engines, Go version, Cargo edition, Python requires, .nvmrc , .tool-versions Run — preferred npm scripts, Makefile ## targets, just, Taskfile Ports — Compose, env *_PORT , script --port Env keys — from .env.example CI secrets/vars — from GitHub Actions workflows (builtins like GITHUB_TOKEN omitted) Overview vs drill-down Need Tool One-pager coldstart Full task map howrun Every port + live check projports Secrets vs gh secret list needsecrets Lockfile PR summary lockbrief Typical first hour: coldstart # then only if you need depth: howrun -f test projports -unique -check needsecrets -check Small binaries, MIT, no SaaS. If it saves a README scroll, it is working.

Measured 2026-07-21 on vllm/vllm-tpu:nightly (vLLM 0.23.1rc1.dev1076), a GCE flex-start ct6e-standard-1t (one TPU v6e chip, 32 GB HBM) in europe-west4-a. TL;DR The plain google/gemma-4-E2B-it serves well on one v6e chip; none of its QAT siblings load at all. The 2-billion-parameter "efficient" Gemma 4 sustains 213 tok/s for a single user with a 16 ms first token, scales to ~2,200 output tok/s across concurrent streams, handles OpenAI-style function calling — including parallel calls and refusal to hallucinate calls — without a miss, and answers simple vision questions accurately in ~200 ms. The QAT variants are a different story: the int4 compressed-tensors export hits an unimplemented quantization path, and the bf16 QAT export trips a loader bug — the Gemma 4 implementation demands per-layer norms that E2B's KV-sharing architecture legitimately doesn't have. Filed upstream as tpu-inference #3225 . One capability coupling to know about: with a reasoning parser configured, schema enforcement only engages when thinking is enabled — thinking-off requests sail through unconstrained with a 200 status. Config interaction, not TPU limitation; details below. 1. Getting to a serving endpoint The host is a GCE flex-start VM — capacity granted on request, billed until deleted, hard-stopped at a 4-hour max run, $1.35/chip-hour. A startup script installs Docker, pulls vllm/vllm-tpu:nightly , fetches the Hugging Face token from Secret Manager via the metadata server, and launches vLLM. Boot timeline: VM RUNNING at t+0 (200 GB boot disk — the 10 GB default cannot hold the vLLM image) → Docker installed ~t+1:00 → image pulled ~t+6:00 → weights downloaded, XLA compiled, health green ~t+8:30. Two environment quirks worth knowing: Direct SSH silently times out on some networks even when the VPC allows tcp:22 — the block is upstream of the VPC. IAP tunneling ( gcloud compute ssh --tunnel-through-iap ) rides over HTTPS and works; so does tunneling the API port with gcloud compute start-

Every time this comes up, someone credits the same setup: Athena on Iceberg is where "the code is the spec" — where you open Git and read the whole system, catalog to transforms to schema, without logging into anything. In my experience they're not wrong. What I want to argue is that they're right for mostly the wrong reason. The reason people reach for is the engine — serverless, open format, nothing to provision. But the thing that actually keeps code as the spec, when it does, is something you could have applied to almost any engine. And the thing that breaks it, when it breaks, has nothing to do with Iceberg at all. So here's the split I've landed on, for now: whether "code is the spec" holds is about 90% discipline and 10% engine . Athena/Iceberg earns that 10% honestly — but 10% is all it earns, and I keep watching people mistake it for the whole thing. (Just where my own tinkering has led — not advice.) I should say up front that I'm still in the middle of this. What the best declarative setup for an agent actually looks like — how you turn a system into a spec it can read and act on without guessing — is something I'm actively testing, not something I've settled. Read what follows as a working idea at a particular moment, written down partly so I can find out where it's wrong. To see where the 10% actually lives, it helps to notice that a stateful system always keeps two copies of itself. The spec has two copies One copy is declared : the code you wrote, the schema you committed, the transforms in dbt, the catalog in Terraform. The other is realized : the state the engine accumulates while running — statistics, physical layout, caches, maintenance history, tuning knobs someone set at 2am. "Code is the spec" is really a claim about the distance between those two. When the declared copy explains almost everything about the realized one, you can reason about the system by reading Git. When it doesn't, you can't. Some of that state is declarable — you can pin a