标签：#tor

I keep seeing the same local LLM sizing mistake: "The model file is smaller than my GPU, so it should fit." That is only the first check. A 24 GB GPU does not give your model a clean 24 GB memory budget. The display stack, runtime, temporary buffers, model weights, and KV cache all compete for the same space. Here is the worksheet I use before I download a model or rent a GPU. 1. Start with the weight floor The simplest weight estimate is: weight_memory_gib = parameters * bits_per_parameter / 8 / 1024^3 For a simple 4-bit estimate: Model size Weight floor 7B 3.3 GiB 13B 6.1 GiB 70B 32.6 GiB These are floors, not promises. Real quantized files can also contain scales, metadata, and layers stored at higher precision. If you know the exact checkpoint size, use that instead of the simple bits-per-parameter estimate. Also use total parameters for a sparse mixture-of-experts model unless your runtime really offloads inactive experts. Active parameters describe compute per token. They do not automatically describe how many weights must be stored. 2. Reduce the physical capacity to a usable budget I normally start with 90 percent usable VRAM for planning: usable_vram = physical_vram * usable_fraction For a 24 GB card: 24 * 0.90 = 21.6 GiB usable The exact reserve depends on the OS, display use, driver, runtime, graph capture, allocator behavior, and other processes. The important part is to stop treating the number on the box as fully available. 3. Add the KV cache The KV cache is where context length and concurrency become expensive. A useful planning formula is: kv_cache_bytes = 2 * layers * kv_heads * head_dimension * context_tokens * concurrent_sequences * bytes_per_kv_value The factor of two stores keys and values. Take a model with: 32 layers 8 KV heads 128 dimensions per head 8,192 cached tokens 1 concurrent sequence 16-bit KV values, which use 2 bytes The KV cache is about 1 GiB. Raise the context to 32,768 tokens and it becomes about 4 GiB. Keep that context and ru

Everyone is building agents. You should build escape hatches. We are living through the most expensive group hallucination in tech history. Every SaaS now has a chatbot stapled to it. Every CEO is an "AI thought leader" on LinkedIn. Every startup pitch deck is just the words "autonomous," "agentic," and "10x" in different fonts. NVIDIA could buy a small country. OpenAI burns through more cash in a quarter than NASA did getting to the moon. And for what? So you can generate slightly worse emails, slightly faster? Look, I love AI. I actually build with it. But I have been around long enough to know what a bubble smells like. It smells like free credits, unearned confidence, and a thousand wrappers around the same API call. The bubble will pop. Not in a dramatic, newspapers falling from the sky way. It will pop quietly. Credits will dry up. Models will get paywalled behind enterprise tiers. The cloud bill you have been ignoring will finally show up. And all those beautiful, cloud-dependent workflows you built will start blinking red. So while everyone else is trying to figure out how to make their AI agent book a flight, I have been asking a different question. What do you build when you assume the internet will get worse, the cloud will get more expensive, and you will need actual skills that survive a downturn? The answer, annoyingly, is two pieces of junk from Amazon that cost less than your last Uber Eats order. Piece of Junk #1: The $25 Router That Sees Everything It is not sexy. It is called the GL.iNet GL-MT300N-V2. Everyone calls it the Mango. It looks like a little yellow box that should have come free with your ISP in 2014. You can buy it on Amazon for about twenty six dollars when it is on sale. Sometimes twenty. Inside it is a tiny Linux computer running OpenWrt. It has two ethernet ports, a USB port, and just enough RAM to be dangerous. Most people buy it to get free WiFi in hotels. I bought it to spy on my own network. Because here is the dirty secret of

Two years ago, "run a language model locally" meant a weekend of compiling, a graveyard of CUDA errors, and a model that answered like it had a concussion. In 2026, you can install one tool, type one command, and have a genuinely useful assistant running on a laptop with no internet connection. Here's an honest map of what works, what doesn't, and where the sharp edges still are. Why bother running locally at all Three reasons keep pulling developers back to local inference: Privacy. The prompt never leaves your machine. For code you can't paste into a cloud box, or personal data, that's non-negotiable. Cost and offline. No per-token bill, no rate limits, and it works on a plane. Latency and control. No network round-trip, and you pin the exact model version forever — no silent upgrades changing your outputs. The catch has always been quality-per-watt. That's the number that moved. The hardware tiers, honestly 8 GB RAM / integrated GPU: You can run 3–4B parameter models at 4-bit quantization. Good for autocomplete, summarizing, simple Q&A. Don't expect deep reasoning. 16 GB RAM: The sweet spot for most developers. 7–9B models run comfortably and are genuinely helpful for coding assistance and drafting. 32 GB+ or a discrete GPU with 16–24 GB VRAM: Now you're running 20–30B models, or bigger models at aggressive quantization, with real reasoning ability. Apple Silicon (unified memory): Punches above its weight. A machine with 32–64 GB of unified memory runs models that would need an expensive discrete GPU on other platforms, because the CPU and GPU share the same memory pool. Quantization: the trick that makes it possible The reason a 7B model fits in 16 GB is quantization — storing weights at 4 bits instead of 16. The common format you'll see is GGUF, and the common recipe is 4-bit (often labeled Q4). The quality loss from full precision to 4-bit is surprisingly small for most tasks, while the memory savings are 4x. Below 4-bit (2–3 bit) the model starts to degrade n

Originally published on hexisteme notes . A status column in one of my agent fleet's ledgers said 30 items were queued to publish. A working session that day stated a backlog close to a month at the fleet's normal rate and deferred the work that keeps posts flowing into the queue. At that moment the ledger showed the same backlog. That exact numeric match suggests — but does not prove — that the ledger informed the decision. The real number of items actually waiting was 6. At one post published per day, that is six days of runway, against a low-water alarm configured to fire at 3. The gap came from a status value that was never advanced after publication, not from the queue-file count itself. A column just quietly stopped meaning what everyone assumed it meant, and by the time it mattered, it had been wrong for a while. The pipeline, briefly The fleet runs a small publishing pipeline: a draft gets written, a promotion step validates it and drops a file into a queue directory, and a scheduled job runs once a day, picks the oldest file in that directory, publishes it, moves the file into a published folder, and appends one line to a log. Alongside the queue directory sits a separate ledger: a flat TSV file, one row per item, with a status column meant to track where each item sits in its life — staged, queued, published. Two different things track the same concept: the files actually sitting in the queue directory, and a column in a table that is supposed to describe them. Where it broke Exactly one piece of code writes status=queued : the promotion step, at the moment an item enters the queue. Nothing else ever changes that value afterward. The daily publish job moves the file and writes to the log; it never opens the ledger. Nobody had assigned any code the job of setting the status forward to published . So queued stopped meaning "currently waiting." It came to mean "was queued at some point," which, once true, is true forever. Every item that had ever passed throu

X is ending its controversial revenue-sharing program for content creators, which has seen numerous revisions under Elon Musk's reign. In its place, it's launching a new Original Content Rewards program on September 8th. To be eligible, creators must have at least 500 verified followers and at least 500,000 Home Timeline impressions from verified users in […]

A navigation map should help the user move through the world, not fight every gesture they make. I recently hit a deceptively simple bug while building field guidance in a React Native / Expo app: the route rendered correctly and the camera followed the current position, but users could not meaningfully zoom or pan while walking. They could pinch the map, but the next location update snapped the camera back to a fixed zoom. The map looked active. The experience felt broken. The cause: two camera owners The implementation combined two useful features: followsUserLocation={true} on the native map. animateCamera(...) after every location update, using a fixed walking zoom and pitch. Each feature was reasonable on its own. Together, they gave the camera two automatic owners and the user none. A pinch gesture changed the zoom for a fraction of a second. Then a GPS update arrived and our effect applied the navigation camera again. On iOS, native user-follow behavior added another layer of camera control. A better model: follow mode and explore mode The fix was not to stop navigation. Route progress, distance, bearing, breadcrumb recording and off-route detection should all continue regardless of what the user does with the map. Only the camera behavior should change. We now keep a small piece of local UI state: const [ cameraFollowing , setCameraFollowing ] = useState ( navigationActive ); useEffect (() => { if ( ! navigationActive || ! cameraFollowing || bearing == null ) return ; mapRef . current ?. animateCamera ( walkingCamera ( currentCoordinate , bearing ), { duration : 480 }, ); }, [ currentCoordinate , bearing , navigationActive , cameraFollowing ]); The native follow prop uses the same state: < MapView showsUserLocation followsUserLocation = { navigationActive && cameraFollowing } onTouchStart = { () => { if ( navigationActive ) setCameraFollowing ( false ); } } /> As soon as the user touches the map, the camera enters explore mode. Pinch, pan and rotation work n

Tienes una señal que a cada observación te dice en qué estado estás: un monitor de salud que dice OK o CAÍDO , un detector de conectividad, un clasificador de modo. Y cerca del umbral oscila : OK, CAÍDO, OK, CAÍDO, OK . Cada cambio dispara algo —una alerta, un failover, entrar o salir de una posición— y de repente tu sistema está temblando por ruido, no por una transición real. Es el mismo problema que resuelve el termostato de tu casa desde hace un siglo, y la solución tiene nombre: histéresis . No cambies de estado hasta que el nuevo se haya sostenido. La regla, en una frase Un estado nuevo solo se confirma tras repetirse N observaciones consecutivas. Si el candidato cambia o revierte antes de llegar a N , la cuenta se reinicia. El estado vigente se mantiene estable; los parpadeos se ignoran. Lo empaqueté como librería — hysteresis-state , Python puro, sin dependencias— porque lo reescribía una y otra vez: from hysteresis_state import HysteresisState estado = HysteresisState ( " OK " , confirmations = 3 ) for lectura in stream : # "OK" / "CAIDO" actual = estado . update ( lectura ) # solo cambia tras 3 lecturas seguidas if estado . changed : # ¿esta lectura provocó la transición? alertar ( actual ) Aliméntalo con OK, CAÍDO, OK, CAÍDO, OK y no pasa nada: ningún candidato se sostuvo. Hacen falta tres CAÍDO seguidos para que el cambio se confirme. El detalle que casi siempre falta: histéresis asimétrica Un umbral único tiene un problema sutil. Si exiges 3 confirmaciones para entrar en fallo, también tardas 3 en salir — y a veces quieres justo lo contrario: caer rápido a lo seguro, volver despacio a lo arriesgado . Es el comportamiento de un disyuntor eléctrico: salta a la primera, se rearma con cautela. Se resuelve dejando que el umbral dependa de la transición: # 1 confirmación para caer a "CAIDO", 5 para volver a "OK" conf = lambda desde , hacia : 1 if hacia == " CAIDO " else 5 estado = HysteresisState ( " OK " , confirmations = conf ) estado . update ( " CAIDO " )

A tutorial where you prove things without revealing things, and yes, the math actually maths. Here's something the internet doesn't want you to know: you overshare every single time you prove something. Prove you're over 21 at a bar? You hand over a card with your name, your address, your height, and your terrible 2019 haircut. Prove your income to a landlord? Here's every transaction I've made since college, please don't judge the 3am food delivery. We built the entire digital world on a verification model that boils down to "here's everything, trust me bro." Not anymore. There's a branch of cryptography that lets you prove a statement is true while revealing nothing else . It sounds fake. It's called a zero knowledge proof , and by the end of this article you'll understand one well enough to check it with Python. Then we'll look at Midnight , a blockchain that turned this party trick into a developer platform. Let's go. 🚀 🪪 The Trust Me Bro Problem Every verification system you use today works by disclosure . You prove things by showing the underlying data: Prove your age ➡️ show your whole ID Prove you can pay ➡️ show your bank statements Prove you're a real user ➡️ solve a CAPTCHA and sacrifice your data to the algorithm gods The data doesn't just get seen . It gets stored , and eventually it gets breached , and then a guy named xX_darkweb_Xx is selling your identity for the price of a burrito. The verifier never needed the data. They needed one bit of information : true or false. Everything else was collateral damage. In short: we've been answering yes or no questions with our entire life story. 🕵️ The Party Trick That Started It All Zero knowledge proofs let a prover convince a verifier that a statement is true without revealing why it's true. The classic example is Where's Waldo. Say I claim I found Waldo on the page and you don't believe me (fair, you've seen my code reviews). I could point at him, but then I've revealed the answer and ruined the puzzle. Ins

Why “it encrypts” doesn't equate to “it’s secure” If you want to find a tutorial for encrypting files in code, your search results will provide dozens of tutorials. Most of these tutorials will produce code that, on the surface, performs encryption. Users can provide plaintext, receive ciphertext, and the code also performs decryption. Unfortunately, the phrase “the output looks scrambled” is an unsecure way to test a program for security. These tutorials fail to incorporate security practices, which will result in these tools being rejected in real life security assessments. By identifying these mistakes, we can reason about the validity of these encryption schemes. This article covers the correct way to build a file encryption tool and the mistakes that beginner encryption tools include. These mistakes will help you learn the correct way to build an encryption tool. SecureVault (Node.js, packaged with no dependencies) is a command-line tool that is referenced throughout to help provide context to the design decisions that were made for this tool. Prerequisite mindset: When designing secure systems, always assume that the attacker knows more than you. Do you really think that your adversary will only submit the inputs you assumed they would submit? They will submit corrupted inputs, they will submit old ciphertexts, and they will do anything you thought was impossible. You need to have a secure design. You must think "what malicious inputs can I handle here?" . The goal: three guarantees, not one Before you even think about writing code, you need to know exactly what you mean by that something is secure. A good file encryption tool must provide three guarantees. Most of the tutorials that I have seen think only about the first one. Confidentiality - the attacker that steals the file should not be able to read the file. Integrity - If the attacker alters the encrypted file, you will know. Authenticity - The file can only be generated by a user that knows the passwor

When snow is in the forecast, most people ask the same question: Will school be canceled tomorrow? A weather app can tell you how much snow is expected. It can tell you the temperature, wind speed, and probability of precipitation. But it doesn't usually turn all of those variables into one practical question: How likely is a school closure? That's the problem I wanted to solve with a snow day calculator. Instead of using a single snowfall threshold, the calculator combines several weather hazards and adjusts them according to regional tolerances. The result is a probability estimate rather than a simple yes/no answer. The basic idea School closures aren't caused by snow alone. A storm producing six inches of snow in a northern state can be manageable, while the same six inches in an area that rarely sees snow can cause major transportation problems. Ice, extreme cold, wind, and the timing of precipitation can change the situation considerably. The calculator therefore looks at four primary weather hazards: Snow accumulation Freezing ice and sleet Extreme cold Wind and snow drifts These are combined with the probability that meaningful precipitation is actually occurring. The core model is: P(Closure) = [1 - (1 - P_snow) * (1 - P_ice) * (1 - P_cold) * (1 - P_wind)] * P_precip The idea behind the equation is fairly straightforward. Each weather hazard contributes its own probability. The model combines those hazards into an overall risk and then accounts for the probability of precipitation. The output is capped at 99% because weather forecasting and school closure decisions are never certain. Why use multiple weather factors? Imagine two forecasts. Forecast A Snow: 6 inches Ice: 0 Temperature: 25°F Wind: 10 mph Forecast B Snow: 3 inches Ice: 0.20 inches Temperature: 15°F Wind: 30 mph Looking only at snowfall, Forecast A appears worse. But Forecast B has several additional transportation hazards. Ice can make roads slippery, extreme cold creates exposure concerns, an

🚀 Building a REST API with Java Spring Boot: A Practical Beginner’s Guide If you're coming from Java and want to move into backend development, Spring Boot is one of the best frameworks to learn. It removes a lot of the boilerplate traditionally associated with Spring and makes it surprisingly easy to build production-ready REST APIs. In this article, we'll build a simple Blog REST API using: ☕ Java 🌱 Spring Boot 🌐 Spring Web 🗄️ Spring Data JPA 🐘 PostgreSQL 📦 Maven 🧪 Postman By the end, we'll have an API that can: Create a blog post Get all blog posts Get a post by ID Update a post Delete a post 1. What is Spring Boot? Spring Boot is a framework built on top of the Spring Framework that makes it easier to create Java applications. Without Spring Boot, you often need to configure many things manually. Spring Boot gives us: Auto-configuration Embedded servers Starter dependencies Production-ready features Easy REST API development A simple Spring Boot application can be started with: @SpringBootApplication public class BlogApplication { public static void main ( String [] args ) { SpringApplication . run ( BlogApplication . class , args ); } } That's enough to start our application. 2. Create the Spring Boot Project The easiest way to create a Spring Boot project is through Spring Initializr . Choose: Project: Maven Language: Java Spring Boot: Latest stable version Packaging: Jar Java: 17+ Add these dependencies: Spring Web Spring Data JPA PostgreSQL Driver Validation Lombok Your project structure will look something like: src └── main └── java └── com.example.blog ├── BlogApplication.java ├── controller ├── service ├── repository ├── entity └── dto This separation will become important as our application grows. 3. Create the Blog Entity Let's create a simple BlogPost entity. @Entity @Table ( name = "blog_posts" ) public class BlogPost { @Id @GeneratedValue ( strategy = GenerationType . IDENTITY ) private Long id ; @NotBlank private String title ; @NotBlank @Column (

One rule settles nearly every case: a model may help you say what is true about you, and it may not decide what is true about you. Drafting is help. Supplying the content of a claim about your own experience is not. The line, and why it is there An application is a set of representations about a person, made by that person, on which somebody else will rely. That is what makes fabrication in one different in kind from fabrication in an essay: there is a party who acts on it, and there are consequences downstream for colleagues, clients and sometimes patients. So the test is not “did a machine touch this”. It is “does the document assert something the applicant does not know to be true”. A cover letter drafted from your notes and edited by you asserts nothing you did not supply. A cover letter that describes a project you did not run asserts something false regardless of who typed it, and would be equally dishonest written by a friend. Case Description rewriting: fine Rewriting your own bullet points more clearly. Fixing grammar. Translating your industry's jargon into the target industry's. Cutting 900 words to 300. Generating ten possible openings so you can choose one. decoding: fine Asking what a job advert is actually asking for, then checking your own experience against that list yourself. metrics: not fine Letting it fill in achievements, metrics or responsibilities you have not verified. 'Increased conversion by 32%' is a fact about the world; if you do not know the number, it is a fabrication with a number in it. motivation: not fine Any statement of motivation you have not read and would not say out loud. 'I have long admired your work in X' when you have not is a small lie that is very cheap to expose in an interview. assessments: not fine Completing an assessment designed to measure your unaided ability, where the employer has said not to, or where the whole point of the task is the thing you outsourced. What genuinely helps The honest uses are also the ef

Let me be upfront about something: this tutorial will age badly. Not the concepts — those hold. But the specific names, the price points, the rankings — the AI model landscape moves fast enough that any comparison table has an expiration date. What's the best model for code today might be second place next quarter. The one that seems expensive now might be the obvious choice by the time you're reading this. That said: the mental model for navigating this landscape doesn't expire. What questions to ask when choosing a model, how API access differs from a subscription, what "context window" actually means on a regular Tuesday — that's stable. With the right map, you can update yourself when things change. And they will. The frontier models: the big three Frontier models are the most capable models at any given moment. In 2026, the competition comes down to three: Claude Sonnet 4.6 (Anthropic) is the model you'll be using throughout this course, and the current benchmark for coding tasks. Together with Opus 4.7, it ships with a 1M token context window at standard pricing — no special headers, no premium plan required. It stands out for sustained reasoning, precise technical writing, and following complex multi-step instructions. Sonnet 4.6 is the speed-quality balance; Opus 4.7 is more powerful but slower and more expensive. GPT-5.4 (OpenAI) — released March 2026 — is the first general-purpose model with native computer use : it can operate desktop interfaces and execute complex workflows across applications. It reaches 1M tokens of context, incorporates the coding capabilities of GPT-5.3-Codex, and comes in multiple variants — Thinking, Pro, mini (free tier), and nano (API-only) — making it the most accessible of the three. Recently, GPT-5.5 has been released, with improvements in speed and reasoning. OpenAI also maintains the Codex family as a separate line: GPT-5.3-Codex is optimized for complex agentic software engineering and leads benchmarks like SWE-Bench Pro; G

If you are integrating ZATCA Phase 2 (Saudi Arabia's Fatoora e-invoicing) and you have seen this: { "type" : "ERROR" , "code" : "signed-properties-hashing" , "category" : "CERTIFICATE_ERRORS" , "message" : "Invalid signed properties hashing, SignedProperties with id='xadesSignedProperties'" } ...after your invoice sailed through /compliance/invoices , this post is for you. It is the single most confusing failure mode in the whole integration, and the fix is not what the error suggests. The trap: SignedProperties exists in two byte-shapes The XAdES SignedProperties block is referenced twice in your signed document: ds:Reference URI="#xadesSignedProperties" carries a digest of the block. The block itself is embedded inside ds:Object > xades:QualifyingProperties . The natural assumption is that both refer to the same bytes. They do not. The hashed shape carries namespace declarations and starts at column 0: <xades:SignedProperties xmlns:xades= "http://uri.etsi.org/01903/v1.3.2#" Id= "xadesSignedProperties" > <xades:SignedSignatureProperties> <xades:SigningTime> 2026-08-07T02:14:33 </xades:SigningTime> <xades:SigningCertificate> <xades:Cert> <xades:CertDigest> <ds:DigestMethod xmlns:ds= "http://www.w3.org/2000/09/xmldsig#" Algorithm= "http://www.w3.org/2001/04/xmlenc#sha256" /> The embedded shape carries no namespace declarations (they are inherited from ancestors) and its root element is indented to column 32 : <xades:SignedProperties Id= "xadesSignedProperties" > <xades:SignedSignatureProperties> Embed the hashed shape verbatim - the intuitive thing to do - and the gateway rejects with signed-properties-hashing , even though your indentation "looks right". The second half of the trap: the digest encoding The digest is not the raw SHA-256 bytes in base64. It is base64 of the hex string : const crypto = require ( ' crypto ' ); // hashedShape = the namespaced, column-0 variant above const propsDigest = Buffer . from ( crypto . createHash ( ' sha256 ' ). update ( Buffer .

Many young men are driven to resentment and are financially exploited as influencers sell them classes, pills, and the illusion of clout, a new report reveals.

Every React developer eventually meets the same fork in the road. You write an event handler that reads state, pass it to a child or an effect, and now you must choose: leave it as a plain inline function and watch every render create a new reference — breaking React.memo , re-running effects, re-subscribing listeners — or wrap it in useCallback and start playing dependency-array whack-a-mole, where one forgotten dependency means the handler sees state from three renders ago. That second failure mode has a name — the stale closure — and it's arguably the most common React bug in production code. The fix has a name too: useEvent , proposed in an official React RFC in 2022 , and available today as useEvent in @reactuses/core . It gives you a function whose identity never changes across renders but whose body always sees the latest state and props . Both halves of the fork, no trade-off. This post covers the API, the three-line implementation trick that makes it work, how it compares to useCallback and to React 19.2's built-in useEffectEvent , real patterns, and the one rule you must respect (don't call it during render). TypeScript-first. The Problem in Thirty Seconds Here's the bug factory. A chat component sends a heartbeat with the current draft text: function Composer ({ roomId }: { roomId : string }) { const [ draft , setDraft ] = useState ( '' ); useEffect (() => { const id = setInterval (() => { sendHeartbeat ( roomId , draft ); // ⚠️ which draft? }, 3000 ); return () => clearInterval ( id ); }, [ roomId ]); // draft intentionally omitted — we don't want to reset the timer return < textarea value = { draft } onChange = { e => setDraft ( e . target . value ) } />; } The interval closes over the draft that existed when the effect ran — the empty string. Every heartbeat sends '' forever. Add draft to the dependency array and the closure is fresh, but now the interval tears down and restarts on every keystroke . useCallback doesn't help: it has the exact same depen

If you've started learning DBMS for software engineering interviews, you've probably come across terms like Functional Dependency , Attribute Closure , Candidate Key , Normalization , and Canonical Cover . For many beginners, Canonical Cover feels like another algorithm to memorize. It isn't. Before you ever learn how to compute a Canonical Cover, you should understand why it exists . This article focuses only on the Introduction and Foundations . We intentionally won't discuss the algorithm yet. What Is the Interviewer's Intent? When interviewers ask about Canonical Cover , they are usually not testing your memorization . Instead, they want to know whether you understand: How databases represent business rules Why redundant rules create problems Whether you can simplify complex dependency sets Whether you understand the foundations of normalization In interviews, Canonical Cover often appears before questions on: Normal Forms Dependency Preservation Lossless Decomposition BCNF Schema Design Interviewers are checking your understanding of database design , not your ability to recite definitions. Why Do Interviewers Ask Canonical Cover? Imagine a database contains hundreds of dependency rules. Many of those rules may: Repeat the same information Contain unnecessary attributes Be derivable from other rules A good software engineer should recognize unnecessary complexity. Canonical Cover is essentially about answering one question: "Can we represent exactly the same constraints using fewer and simpler rules?" That's why interviewers ask it. They want to see whether you appreciate: simplicity correctness maintainability efficient schema design Where Does Canonical Cover Fit Inside DBMS? Think of DBMS topics as a learning roadmap. DBMS | -------------------------------- | | Database Design Transactions | | Functional Dependencies | Attribute Closure | Candidate Keys | Canonical Cover | Normalization | 2NF → 3NF → BCNF Canonical Cover belongs to the database design portio

Why Does Python Need asyncio.Lock? INTRODUCTION After understanding asyncio.Semaphore , I thought I had learned everything required to control multiple coroutines. A semaphore limits how many coroutines can execute simultaneously. Then another question came to my mind. If Python's event loop executes only one coroutine at a time, why do we even need a Lock? Initially, I assumed a lock was unnecessary because there was only one thread. But after experimenting with shared variables, I realized that even though only one coroutine executes at a particular instant, multiple coroutines can still interfere with each other. In this article, I'll explain the problem that led to asyncio.Lock , how it works, and why almost every backend application uses it. What You Will Learn Why asyncio.Lock exists What is a race condition What is a critical section How Lock works internally Practical examples Real-world backend use cases Prerequisites Before learning asyncio.Lock , you should understand: Coroutines Event Loop await asyncio.Semaphore The Problem Suppose we have a shared variable. counter = 0 Now imagine two coroutines trying to increment it. async def increment (): global counter temp = counter await asyncio . sleep ( 1 ) counter = temp + 1 Initially I expected the final value to become 2 because two coroutines are incrementing the counter. But that wasn't what happened. Let's See What Actually Happens Initially counter = 0 Now Coroutine A starts executing. Read counter ↓ temp = 0 ↓ await The coroutine reaches await . The event loop suspends it and starts another coroutine. Now Coroutine B executes. Read counter ↓ temp = 0 ↓ await Notice something interesting. Both coroutines have already read counter = 0 Now Coroutine A resumes. counter = 1 Then Coroutine B resumes. counter = 1 The final value becomes 1 instead of 2 This is called a Race Condition . Why Did This Happen? Initially I blamed the Event Loop. Later I realized, the Event Loop didn't do anything wrong. Its job is

TikTok says a "moderator error" delayed the removal of a livestream that appeared to show blogger Perez Hilton harming himself, as reported earlier by Wired. Jamie Favazza, a spokesperson for TikTok US, tells The Verge that the platform notified law enforcement about the situation and banned Hilton's account for violating its community guidelines. Hilton, or […]

Multi-agent examples often jump straight to models, tools, and production claims. That makes it difficult to see what the protocol is doing. Before adding an LLM, it is useful to watch a small system discover specialists, delegate a task, and return a result that you can inspect. This tutorial uses A2A Orchestration Lab , an open-source Python project by Fernando Paladini. It starts three local agents: an orchestrator, a researcher, and a writer. The researcher and writer are deterministic stubs, so the example isolates the Agent2Agent (A2A) communication flow from model behavior. The result is a runnable research-to-write pipeline that helps explain where A2A fits next to the Model Context Protocol (MCP). TL;DR Install the lab with uv , run its demo command, and inspect the three local Agent Cards and the delegated result. The project is a learning lab, not a production runtime. That is a feature for this tutorial because every moving part remains visible. Prerequisites You need: Python 3.12 or newer. uv for environment and dependency management. A terminal with network access for the initial dependency download. The repository declares version 0.1.0 , requires Python >=3.12 , and depends on the A2A Python SDK, httpx , and uvicorn . It is licensed under MIT. Create and run the lab Clone the public repository and let uv create the environment from the locked dependencies: git clone https://github.com/paladini/a2a-orchestration-lab.git cd a2a-orchestration-lab uv sync Run the bundled end-to-end demo: uv run a2a-lab demo "Explain A2A and how it relates to MCP" The CLI starts the three agents as subprocesses, waits for their Agent Cards, sends a message to the orchestrator, prints the response, and terminates the child processes. The default prompt is the same explanation used by the repository README, but using your own prompt makes the delegation easier to recognize. On a successful run, the output contains sections similar to these: [demo] asking orchestrator: 'Expl