I spent the last few months building a new sparse fine-tuning method for MoE models called **USAF**. The goal was simple: if your GPU can run inference on an MoE model, it should also be able to fine-tune it. On my AMD RX 6750 XT (12 GB), I can fine-tune Qwen3-30B-A3B by training sparse expert weights and the router instead of adapters. The project is completely open source under the Apache 2.0 license. I'm not trying to build a business, sell anything, or monetize it in any way—I just wanted to share something I built that I think is genuinely interesting. I'd love to hear your feedback, especially from people working with MoE models. GitHub: https://github.com/tsuyu122/usaf submitted by /u/tsuyu122 [link] [留言]

Introduction Through Chapter 7 (Multi-Agent) , we have a complete, functioning AI system. The final step is building organizational infrastructure to operate AI safely over time. [Before] Technical safety Security → Block malicious input Evals → Measure quality [Now] Organizational / regulatory safety Governance → Know what AI systems are in use Risk mgmt → Classify and assess risks Audit logs → Record who did what, when EU AI Act → Regulatory compliance EU AI Act Status (as of June 2026) The EU AI Act came into force on August 1, 2024, with full enforcement on August 2, 2026 . Transparency rules (disclosing when users are interacting with AI, labeling AI-generated content) also take effect on that date. AI systems are classified into three risk tiers: Risk Level Description Examples Prohibited Not permitted Social scoring, manipulative AI High Risk Strict regulation Hiring, credit scoring, law enforcement Limited Risk Transparency obligations Chatbots, AI-generated content Minimal Risk No regulation Spam filters, game AI Our RAG system's classification: Limited Risk (chatbot). We are required to disclose to users that they are interacting with AI. Directory Structure pgvector-tutorial/ ├── existing files └── governance/ ├── ai_registry.py # ★ AI system inventory ├── risk_assessor.py # ★ Risk assessment ├── audit_logger.py # ★ Audit logging └── compliant_rag.py # ★ Governance-compliant RAG 1. AI System Inventory — governance/ai_registry.py Most organizations lack a systematic inventory of their AI systems, making risk classification and compliance planning difficult. Knowing what you have is the essential first step. # governance/ai_registry.py """ AI system inventory Centrally manage all AI systems in use across the organization. Forms the foundation for technical documentation required by EU AI Act Annex IV. """ from datetime import datetime from dataclasses import dataclass , asdict from enum import Enum class RiskLevel ( Enum ): UNACCEPTABLE = " prohibited " HIG

I had just aced my mentor’s Docker exam, so of course I thought I understood containers. I had said all the right words: namespaces, cgroups, images, layers, PID 1, Kubernetes Pods. Then I typed my first serious command and Linux reminded me that knowing the nouns is not the same thing as building the thing. $ sudo unshare -p 1 test unshare: failed to execute 1: No such file or directory That was the opening scene. I had not even built anything yet. I had typed the flags wrong and accidentally asked unshare to execute a program called 1 . This was going to be less “implement Docker” and more “let the kernel correct my confidence, one error at a time.” v1: namespaces, or the first time PID 1 lied to me The first version was supposed to be easy: run a process in a new PID namespace and prove it sees itself as PID 1. So I ran the command the way I thought it worked: $ sudo unshare --pid bash # echo $$ 25184 That was not PID 1. That was just embarrassing. The rule I had missed is simple: PID namespaces apply to children. The process that calls unshare --pid does not magically become PID 1. You need to fork. The first child born into the new namespace becomes PID 1. So the working version was: $ sudo unshare --pid --fork bash # echo $$ 1 That one line changed the tone. I was inside a different process universe. The shell thought it was process 1. Signals felt different. Orphans came home to it. Then I ran ps , and got humbled again. # ps -o pid,ppid,comm PID PPID COMMAND 25310 25304 bash 25344 25310 ps That made no sense at first. I was PID 1, but ps was showing host-looking PIDs. The next reveal: ps does not ask the kernel some pure “what processes exist?” question. It reads files. If /proc still points at the host procfs, your tools will tell you the host story. So I remounted /proc from inside the namespace: # mount -t proc proc /proc # ps -o pid,ppid,comm PID PPID COMMAND 1 0 bash 7 1 ps That was when it clicked. The namespace did not become real to my eyes until /pr

Our multi-site maintenance tool fires wp plugin list --format=json against the sites it manages. One day, against a specific shared host (Xserver in Japan), this call started failing — and the failure mode was unusually subtle. Both the SSH connection test and the WP-CLI path test ( wp --version ) came back green. Users saw "all diagnostics pass, but the actual operation fails," a frustrating asymmetry. Tracing it back, the root cause was PHP Deprecated warnings emitted by older WP-CLI (2.x) under PHP 8.2+ leaking into the JSON output. This post walks through the three-layer defense we used to structurally absorb the noise without losing real failures. What was happening — Deprecated warnings on stdout The raw output on a problem host looked like this: PHP Deprecated: Creation of dynamic property WP_CLI\Dispatcher\CompositeCommand::$longdesc is deprecated in phar:///usr/bin/wp/vendor/wp-cli/wp-cli/php/... [ {"name":"akismet","status":"active","update":"none", ...}, ... ] Since PHP 8.2, assigning to a dynamic property on a class without #[\AllowDynamicProperties] emits a Deprecated warning. Xserver's /usr/bin/wp (an older WP-CLI 2.x) leans on dynamic properties internally, so running it on PHP 8.2+ produces a steady stream of those warnings. Note: PHP 8.2's dynamic-property deprecation is a healthy direction for the language. But during the transition, you get many libraries that "warn but still work" — WP-CLI was one of them. The actual problem is the host's php.ini : depending on display_errors , those warnings end up on stdout instead of stderr . Calling wp plugin list --format=json returns stdout containing both the warnings and the JSON, and json_decode() fails on the mixed input. Why diagnostics stayed green but operations failed The frustrating asymmetry came from how each test was checking the output: SSH connection test : runs echo ok — passes as long as ok appears somewhere in stdout, extra lines are fine WP-CLI path test : runs wp --version — passes as lon

For years, Zero Trust architectures were designed around one assumption: Humans make the decisions. That assumption is breaking apart. Autonomous AI agents can now query databases, trigger workflows, call APIs, and interact with other systems without direct human involvement. Modern AI systems no longer just generate text. They execute actions inside enterprise environments. When an AI agent can operate on behalf of a user inside your cloud infrastructure, its identity becomes just as critical as any human identity. And that fundamentally changes the security model. The Rise of Tool Calling Platforms like Amazon Bedrock Agents have changed the architecture of enterprise AI. These systems can now interpret a user request, decide which tools are required, and autonomously execute backend operations through Lambda functions, APIs, databases, and external services. A simple prompt can trigger an entire chain of actions. Example Workflow User Prompt: "Summarize customer complaints from the last 30 days." Agent Actions: Query the CRM database Call the analytics API Pull support ticket data Generate a report Powerful for productivity. Extremely dangerous if not properly secured. The New Attack Surface A single successful prompt injection can completely hijack an agent’s behavior. With overly broad permissions, an attacker can force it to: Access sensitive customer data Execute unauthorized API calls Modify records Trigger privileged backend workflows The risk becomes even worse in multi-agent systems. A compromised customer-facing agent can pass malicious instructions to a highly privileged backend agent. Traditional network perimeters and security tools often miss this entirely because the traffic comes from a trusted internal service. Why Traditional Zero Trust Falls Short Classic Zero Trust was designed for human behavior and relatively predictable access patterns. AI agents operate differently: They act autonomously and at machine speed They make decisions without real

Durante más de cuatro décadas, hablar de servidores era prácticamente sinónimo de hablar de arquitectura x86 . Desde los primeros servidores empresariales hasta la mayoría de los centros de datos modernos, Intel y AMD han dominado la infraestructura sobre la que funcionan nuestras aplicaciones. Sin embargo, algo está cambiando. De forma silenciosa, los principales proveedores de nube como Microsoft Azure están incorporando cada vez más procesadores ARM para ejecutar cargas de trabajo modernas. ¿La razón? No es únicamente el rendimiento. Es la eficiencia energética. El problema de los centros de datos modernos Cada vez que desplegamos una máquina virtual o un clúster de Kubernetes en Azure, detrás existe un servidor físico consumiendo energía. Ahora imaginemos un centro de datos con cientos de miles de servidores. Incluso una pequeña reducción en el consumo eléctrico por servidor representa un ahorro enorme cuando se multiplica por toda la infraestructura. Y no solo hablamos de electricidad. Menos energía implica: menos calor generado menor necesidad de refrigeración menores costos operativos menor huella de carbono Por eso la eficiencia energética se ha convertido en un factor estratégico para los hyperscalers (gigantes tecnológicos que poseen y administran infraestructuras de centros de datos masivas a nivel global). ¿Qué diferencia a ARM de x86? A grandes rasgos: x86 utiliza una arquitectura CISC (Complex Instruction Set Computing) , con un conjunto amplio de instrucciones complejas. ARM utiliza una arquitectura RISC (Reduced Instruction Set Computing) , basada en instrucciones más simples y optimizadas. Esto no significa automáticamente que ARM sea “más rápido”. Lo que sí significa es que puede realizar muchas cargas de trabajo consumiendo considerablemente menos energía. En otras palabras: ARM no busca ganar por fuerza bruta. Busca hacer más con menos. ¿Por qué ahora? Hace unos años, ARM estaba asociado principalmente a teléfonos móviles. Hoy la situación es muy

SQLite Internals, Postgres 19 Checksums, & PL/CBMBASIC Extension Today's Highlights This week, we delve into SQLite's secure deletion and blob updates, explore upcoming data integrity features in PostgreSQL 19, and discover a unique PostgreSQL extension bringing Commodore 64 BASIC to your database. These updates offer insights into database internals, future resilience, and creative extensibility for the SQLite ecosystem. Secure Delete and BLOB Updates in SQLite (SQLite Forum) Source: https://sqlite.org/forum/info/6f3e886a1149c97e0ede9a243281efb05a043705393ea94437ed7c0556315972 This SQLite forum discussion delves into the nuances of secure data deletion and efficient BLOB updates within SQLite databases. Secure deletion is a critical concern for applications handling sensitive data, where simply deleting a row might not zero-out the underlying storage, leaving recoverable remnants. The thread explores methods and implications for ensuring data is truly eradicated when removed, potentially touching on PRAGMA settings or specific file system interactions. Understanding these mechanisms is crucial for developers building secure, embedded applications with SQLite. The conversation also extends to optimizing updates for BLOB (Binary Large Object) data. Efficiently handling large binary data, such as images or documents, in an embedded database like SQLite requires careful consideration to avoid performance bottlenecks and excessive disk I/O. The discussion likely covers strategies for in-place updates, managing free space, and the internal workings of SQLite's storage engine when dealing with variable-length BLOBs. This insight helps developers make informed decisions on schema design and update patterns for improved application performance and data integrity. Comment: This thread offers valuable insights into SQLite's low-level data management, essential for anyone needing to implement robust security or optimize BLOB storage. PostgreSQL 19 to Feature Checksums For All

This closes out the series' capstone: the multi-agent customer support system built across Parts 6-9, now hardened with evaluation, cost governance, and observability so it can actually run in production with an on-call rotation behind it, not just in a demo environment. Continuous evaluation pipeline Evaluation: measuring quality continuously, not just at launch A one-time eval before launch tells you nothing about drift once real traffic — and real edge cases — start hitting the system. Set up a continuous evaluation pipeline using a G-Eval-style approach, where a separate model scores production outputs against explicit criteria: eval_criteria = { " correctness " : " Does the response accurately reflect the order/refund status retrieved from the tools? " , " escalation_appropriateness " : " If the case was ambiguous or high-risk, did the agent escalate to a human rather than resolving it alone? " , " tone " : " Is the response professional and appropriately empathetic given the customer ' s stated frustration level? " , } def geval_score ( response , context , criterion_name , criterion_description , eval_model_client ): prompt = f """ Evaluate the following response against this criterion: { criterion_description } Context: { context } Response: { response } Score from 1-5 and give one sentence of reasoning. Return JSON: {{ " score " : int, " reasoning " : str}} """ result = eval_model_client . complete ( prompt ) return json . loads ( result ) def run_continuous_eval ( sample_of_production_traffic ): scores = { crit : [] for crit in eval_criteria } for interaction in sample_of_production_traffic : for crit_name , crit_desc in eval_criteria . items (): result = geval_score ( interaction . response , interaction . context , crit_name , crit_desc , eval_model_client ) scores [ crit_name ]. append ( result [ " score " ]) return { crit : sum ( vals ) / len ( vals ) for crit , vals in scores . items ()} Sample a percentage of real production traffic daily (not just s