标签：#an

CERN engineers announced a shift from Red Hat-based distributions to Debian for its accelerator control systems. This decision stems from Red Hat's tightening compiler mandates, which threatened legacy hardware. The transition, focused on 2,200 specialized control machines, is set for completion in late 2026, while CERN's other systems will remain with Red Hat and AlmaLinux. By Olimpiu Pop

Half a day lost is the honest cost of treating an AI model like a document. I discovered that the hard way: a CAPA opened for a data-provenance gap rolled forward into missing documentation, which then exposed weaknesses in change control and supplier traceability. This is what happened, what we changed, and the small automation that stopped the loop from repeating. The trigger: a CAPA that looked simple and wasn't An engineer flagged a discrepancy between on-device inference behaviour and the validation test bench. The CAPA looked routine: reproduce, find root cause, correct datasets or model weights. Quickly it turned into: We couldn't identify which training dataset produced the deployed model (no manifest, only folder names). Preprocessing steps changed between runs (different label encodings, a silent resampling step). Model binaries were overwritten in a shared location without an immutable model registry entry. Change control only referenced a release ticket number — not the dataset or container image digest. What began as a data-provenance finding became a documentation finding, then a change-control finding. Auditors would call this a traceability gap. The EU AI Act (and notified bodies increasingly expect traceability for high‑risk AI components) means you must show how a model version ties to the data, the training pipeline, the verification evidence, and the approval record. We didn't have that linkage. By midday my filter coffee was cold and I had a long list of evidence to assemble. Why CMOs see this differently As a CMO handling components and supplier networks, our "models" are often supplier-provided (analytics, inspection classifiers, OCR of COAs), or built from datasets stitched from multiple vendors. The usual eQMS workflows assume a device maker controls the full pipeline. They rarely fit a supplier-heavy reality where: Sub-tier suppliers supply datasets or models. Incoming inspection depends on vendor-provided models for automated checks. Suppl

I spent Friday night staring at a mock municipal utility shutoff notice. The text was dense. The language was punitive. The deadline was buried in a block of legal code on page two. Generosity usually shows up as time or money, and that kind of giving matters. I think it can also look like removing friction. Millions of vulnerable and non-native speaking families receive legalistic notices, like eviction warnings, utility shutoffs, medical bills, or benefit discontinuances, written in adversarial legalese. The emotional and cognitive weight is massive. These notices are dense no matter who is reading them. I still read some of them twice, and most people meet one while already having a hard week. What I Built I directed the build of Charitas Clew . It is an open-source, zero-judgment paperwork engine for public notices. Charitas Clew ingests overwhelming institutional notices and uses Google AI to decompress the legal gravity into plain-language clarity. Instead of a generic chat interface, it outputs a strict Action Protocol: The Actual Meaning : Demystified in plain, dignified language. Key Dates and Timelines : Pinpoints critical statutory deadlines and grace periods. Simple Next Steps : 2 to 3 actionable, reassuring instructions. Personal Speaking Script : A first-person script the user can read out loud when calling or visiting a clerk, caseworker, or counselor. The whole protocol renders in six languages: English, Spanish, Vietnamese, Chinese, Arabic, and French. A notice written in adversarial English comes back as plain language in the language spoken at that household's kitchen table. Charitas Clew joins the Clew Suite , my portfolio of civic tech tools focused on making complex systems more inspectable. Demo Live Production Instance: charitas-clew.web.app Firebase Hosting serves the frontend. Every AI call routes through the Express gateway on Cloud Run. Paste a notice or upload a photo of one, pick a language, and read the result. Code earlgreyhot1701D /

COUNT(*) looks like a trivial operation: SELECT COUNT ( * ) FROM orders ; The query asks for a single number, but that doesn't mean PostgreSQL can produce it with a constant-time read from some internal counter. When we need an exact count, PostgreSQL has to determine how many rows are actually part of the visible result set for that query. On large tables, that work can become a meaningful chunk of total execution time. And the problem doesn't just go away by throwing an index at it. The useful question isn't "do I have an index?" It's: How many rows does PostgreSQL actually need to examine to compute this count — and can that work be reduced? Why COUNT(*) Can Be Expensive in PostgreSQL PostgreSQL uses MVCC — Multi-Version Concurrency Control — to manage concurrent access to data. That's what lets multiple transactions work at the same time while each sees a consistent view of the database. But it also means row visibility depends on the snapshot the query is running under. That's why PostgreSQL can't answer: SELECT COUNT ( * ) FROM orders ; by simply reading an exact counter stored somewhere in the table's metadata. To return an exact result, it has to process the rows — or an index structure representing those rows — and determine which ones are part of the visible result. On a small table, that cost is invisible. On a table with millions of rows, the amount of work starts to matter. Which leads to an important distinction: returning a single row from COUNT(*) does not mean processing a single row. How to Analyze a COUNT with EXPLAIN ANALYZE Before reaching for an index, it's worth looking at what PostgreSQL is actually doing. Say we have this query: SELECT COUNT ( * ) FROM orders WHERE status = 'completed' ; We can analyze it with: EXPLAIN ( ANALYZE , BUFFERS ) SELECT COUNT ( * ) FROM orders WHERE status = 'completed' ; The goal isn't to hunt for an Index Scan by default. Worth checking instead: the scan type estimated rows vs. actual rows processed rows discard

Android App Protection Shouldn't Come at the Cost of Performance: The Lightweight Approach of XopProtector Android application protection has always involved a difficult trade-off. Stronger protection often means: Larger APK size Longer protection/build time Higher runtime overhead Slower application startup For large Android applications, these costs can become especially noticeable. XopProtector takes a different approach: strong protection with a focus on build efficiency, small APK overhead, and fast runtime startup. 300MB APK Protection in Under 5 Minutes For large Android projects, protection time is an important part of the development workflow. If protecting a 300MB APK takes 10–20 minutes or longer, it can significantly slow down: CI/CD pipelines Regression testing Beta releases Production builds Daily development XopProtector is designed to minimize unnecessary processing and optimize the protection pipeline for DEX, native libraries, and protected runtime data. In our testing environment, a 300MB-class APK can be protected within 5 minutes . This makes APK protection much more practical for frequent builds and automated CI/CD workflows. Actual protection time depends on hardware, APK structure, number of DEX files, native libraries, and the selected protection configuration. Small APK Size Overhead Protection should not mean dramatically increasing the APK size. Some protection solutions introduce significant additional runtime components or duplicated protected data, which can result in noticeable APK growth. XopProtector focuses on keeping the protection runtime lightweight and minimizing unnecessary additional data. The goal is simple: Original APK ↓ XopProtector ↓ Protected APK Protection ↑ Security ↑ APK overhead ↓ Build time ↓ Runtime overhead ↓ For large applications, keeping the size overhead low can be just as important as the protection itself. Fast Startup After Protection Build time is only one part of the equation. What users ultimately exper

Status of the demo. The viewer was regenerated on August 29, 2026 from a sanitized public projection (with the non-public bits stripped out 😀): the artifact contains no mail bodies, attachments, addresses, absolute paths, tokens, credentials, or microdata. Preamble: remembering is not enough In the second part I went after a bounded problem: getting penta-agent 's memory to retrieve evidence and to recognize when it had found none. The question in this third part is more practical, and it comes out of the system having been in use for a while: what happens to a memory as it grows and turns blurry, or even contradictory? An index can pile up fragments without any trouble, and there are plenty of tools that already do that well. A more useful memory, in my judgment, has to carry provenance, currency, permissions, contradictions, and deletion criteria. It also has to tell finding a source apart from using it correctly. Recent literature insists on separating RAG — retrieval-augmented generation — context management, and agent memory, because they do different jobs and call for different evaluations 1 . What follows has three movements: what changed since part II; which experiments survived a more serious evaluation; and how to show a memory without passing it off as a mind. Spoonful 1: from retrieving fragments to governing evidence In part II the problem was retrieving well : finding the relevant context and recognizing when there was not enough evidence. A useful memory does not only retrieve information; it also has to know where it came from, whether it still holds, where it can be used, and what is allowed to be done with it . RAG mostly solves retrieval. The memory layer adds rules for keeping, updating, relating, or discarding evidence. None of those functions amounts, on its own, to identity. To describe provenance I use concepts compatible with PROV-O — entities, activities, and agents — while currency, sensitivity, and permissions need rules of their own 2 .

Many recent vehicles had CarPlay and Android Auto built in, but if yours doesn't, you can add a portable one to your dash.

Web development has changed a lot. We have LLMs, AI-assisted coding, etc. But some things remain...

Slate's build-a-truck model aims to keep costs low by only including features you'll use. But it won't be popular outside the U.S.

The Uber founder has said that Atoms will allow him to complete "unfinished business."

Welcome back to TechCrunch Mobility, your hub for the future of transportation and now, more than ever, the role AI is playing in it.

I had four small services. Each one was a Model Context Protocol adapter — a thin wrapper that lets an AI agent call out to some external thing. One talked to Replicate for image generation. One talked to a Nostr-friendly social poster. One was a Git-aware research helper. One was a Tavily-powered web search. They were all written in Python. They all ran on Knative on a small Kubernetes cluster. They all worked. And they were all just slightly too slow to use. A six-second cold start is fine for nothing. It is the precisely wrong amount of time — slow enough to be noticed, fast enough to feel almost loaded. An AI agent waiting six seconds for a single tool call does not know it is waiting for a cold start; it just knows the tool is sluggish. The user does not know either. The user just thinks the agent is broken. And six seconds was a good day. Some of the services took longer. So I rewrote them in Go. This is what that cost me, and what the measurements actually were before and after. The actual problem Cold starts on serverless platforms are an old problem with a well-known shape. The platform spins your container up only when traffic arrives, so the first request after an idle period pays the full startup tax — image pull (or warm cache hit), container start, language runtime initialisation, application bootstrap. For Python, application bootstrap is where the bill arrives. The interpreter has to start. import statements run. The dependency tree gets walked. If you have ever wondered why a hello world Flask app feels so much heavier than a hello world Go binary, this is why. Python is doing real work before your code runs. Go has already started. On a small Kubernetes cluster — small as in I am paying for it personally — you do not keep a fleet of warm replicas around. You scale-to-zero. You scale-to-zero because that is the entire point of using serverless on small infrastructure. The trade-off is that every idle service eats a cold start the next time it is inv

Humanistic Architecture Learning to See Problems Differently I had the opportunity to attend a class called “Humanistic Architecture” by Mr. Chakrit Riddhagni. The class was about applying humanistic principles to software development . Before talking about what I learned, I would like to share a little about my own perspective on software development. Personally, I have a quote and a belief about software development: it is both a science and an art. I see software development as something that has an artistic side, while being grounded in logic, with almost endless possibilities. “Crafting software requires artistry, guided by imagination, grounded in logic, endlessly enduring.” This quote has been one of my inspirations since I started working as a developer. What I mean by this is that I have always liked thinking about software development as a kind of literature . We are not simply writing code. We are solving problems. We are developing and creating something to solve a problem that either we or our customers are facing. Because of this, as a developer, I naturally work with problems every day. But… I never really thought much deeper about what a “problem” actually is. Usually, when we solve a problem for a customer or develop software for them, we receive an issue or a scope of work and then start working on it. We know that something is a problem, so we focus on solving it. But we do not always stop and ask What is the actual structure of this problem ? Is this really the problem? And does the solution we are building actually address the problem we are trying to solve? That changed when I attended the “Humanistic Architecture” class. One of the biggest things I gained from this class was a new perspective and a set of tools for defining what a “problem” really is. Anatomy of a Problem We can look at a problem through the Anatomy of a Problem , which consists of three parts: Current State — where we are now Gap — the difference between where we are and wher

This is a submission for Weekend Challenge: Generosity Edition What I Built My late...

In December 2024, Google quietly updated its closed testing rules for personal developer Console accounts. For months, indie developers had to recruit at least 20 testers to keep their app opted in for 14 consecutive days before applying for production access. Under the revised guidelines, that threshold dropped from 20 to 12 testers. Understanding the nuances of the Google Play 20 testers vs 12 testers shift helps you plan your release schedule accurately without running into unexpected delays during Google Play Console verification. While lowering the number by eight testers sounds like a major relief, the core requirements behind closed testing have not changed. Google still enforces a strict 14 consecutive day duration, and the Play Console continues to monitor tester retention and engagement. A lower numerical requirement means less logistical hassle, but maintaining a stable group of committed testers remains the primary hurdle for independent developers. The Policy Shift: From 20 to 12 Testers Google originally introduced mandatory closed testing in November 2023 to improve app quality and curb low-effort submissions on the Play Store. Initially, all new personal accounts registered on or after November 13, 2023, were required to run a closed test with at least 20 opted-in testers for 14 days without interruption. After roughly a year of developer feedback regarding how difficult it was for solo creators to find 20 reliable participants, Google reduced the requirement to 12 testers in December 2024. It is crucial to understand who this rule applies to. The requirement exclusively targets personal developer accounts created on or after November 13, 2023. If you operate an organization or business developer account, or if your personal account was registered before November 13, 2023, you are currently exempt from this mandatory closed testing gate. However, if you fall under the new personal account category, reaching 12 continuous opt-ins is a strict prerequis

Google has open-sourced Mantis, an AI-agent framework designed to automate the software vulnerability lifecycle, from identifying and validating vulnerabilities to reproducing and fixing them. Google says it developed Mantis to address the high rate of false positives and hallucinated vulnerabilities produced by conventional AI-powered code scanning. By Sergio De Simone

"We achieved within a few years what had taken the European space industry decades before."

Take full control of your desktop alerts by sending yourself recurring reminders and custom notifications triggered by specific events.

I was initially enamored with the beta version of Apple’s revamped smartphone assistant. As the full release approaches, I’ve forgotten Siri AI even exists.

Published 2026-09-06 This describes NIST IR 8547 ipd — the initial public draft of November 2024 — as it stood on the date above. Its dates are proposed. If a final IR 8547 has published since you are reading this, check it: the numbers below may have moved, and the article's central caveat may no longer apply. If you have read anything about post-quantum migration in the last year, you have read that RSA is deprecated in 2030. It is one of those facts that has been repeated into the shape of a rule. It is half true, and the half that is false is the half people plan around. Here is the actual table, from NIST IR 8547, Transition to Post-Quantum Cryptography Standards : algorithm parameters transition RSA, ECDSA 112 bits of security strength Deprecated after 2030 Disallowed after 2035 RSA, ECDSA, EdDSA ≥ 128 bits of security strength Disallowed after 2035 Read the second row again. At 128 bits and above there is no 2030 row at all . RSA-3072 is not deprecated in 2030. Neither is P-256. The 2030 date applies to 112-bit strength — RSA-2048, P-224, 2048-bit finite-field Diffie-Hellman — and to nothing else. The key-establishment table (Table 4, covering finite-field DH/MQV, elliptic curve DH/MQV and RSA) has exactly the same shape. Same split, same dates. So an inventory that reports "47 uses of RSA, all deprecated in 2030" is reporting something the document does not say. Some of those uses are on a 2030 clock and some are on a 2035 clock, and which is which depends on a field most tooling does not look at. Deprecated is not disallowed The second thing worth getting right is what the two words mean, because they are not synonyms and NIST defines both: deprecated — "The algorithm and key length may be used, but the user must accept some security risk." disallowed — "The algorithm or key length is no longer allowed for applying cryptographic protection." Deprecated is a risk acceptance. You may continue, with your eyes open and presumably a note in a register somewhere.