标签：#X

TrueNAS CORE has been the standard for open-source storage using FreeBSD and OpenZFS. The shift to TrueNAS SCALE, based on Debian, left some users needing alternatives. FreeCORE upgrades TrueNAS CORE to FreeBSD 15.0, restoring essential features like FreeBSD Jails. While it satisfies certain administrators' needs, its long-term sustainability and maintenance by a single individual raise concerns. By Olimpiu Pop

A six-week journey through source builds, CI pipelines, and one package pacman never mentioned. TL;DR: pacman -S whisper-cpp ggml-vulkan . That's it. That's the whole answer. Here's why it took me several weeks to find it. The setup I use whisper.cpp for local speech-to-text and as a part of my projects. I have a GPU utilization monitor permanently visible in my GNOME panel via the Vitals extension — so when whisper.cpp started detecting my GPU but running everything on CPU anyway, I noticed immediately. Went to fix it. What followed was several weeks of googling, building from source, writing a custom PKGBUILD, setting up CI, publishing an AUR-style repo — and eventually discovering that the actual fix is a single extra package that pacman never once mentioned to me. The investigation First thing I checked: is the official extra/whisper-cpp package compiled with Vulkan support? All search results said no — -DGGML_VULKAN is explicitly OFF, GPU code is absent from the binary. The app sees your GPU through vulkan-icd-loader but has no code to actually use it. That matched exactly what I was seeing. So the binary itself was the problem. At the time, a separate whisper-cpp-vulkan package had existed in the repos but kept appearing and disappearing — and right then it was gone from both extra and AUR. AUR pushes were also temporarily restricted due to a supply-chain incident. So the "just install the vulkan variant" path was closed, though it used to be available sometime. The obvious move: build from source with -DGGML_VULKAN=ON , package it up, done. I published whisper-cpp-vulkan-arch with a PKGBUILD and prebuilt binaries, wired up CI to track upstream releases automatically and rebuild correspondingly, and wrote a Reddit post explaining the situation. The post was dated August 13, 2026. The twist A few weeks later, someone commented on the post. They suggested installing ggml and vulkan-icd-loader . I started writing a detailed reply explaining why this was wrong: gg

Clients of a house only see the facade: the door, the windows, the porch. The boiler closet, the fuse box, and the plumbing stay out of sight — and that is exactly what lets someone rearrange them without telling anyone. An Elixir module works the same way. The functions other modules call are the facade; helpers marked defp are the boiler closet. In the previous article about project structure we agreed that Todo is the front door of the todo feature and Parser is a back room. Nothing enforced that, though: every function we wrote with def was public, so any module could call Parser directly. defp turns the "back room" sign into an actual lock. In this article I'll explore the difference between def and defp , what privacy actually protects, and the patterns I use to keep our todo modules' interfaces small. Note : The examples in this article use Elixir 1.20.1. While most operations should work across different versions, some functionality might vary. We keep building on the same learning_elixir Mix project from the previous article ( Learning Elixir: Project Structure ). If you no longer have it, recreate it with mix new learning_elixir and add the Todo modules back — we'll show every file in full anyway. Two details that keep showing up: modules live under lib/ , and multi-step scripts like try_todo.exs live at the project root, next to mix.exs . Short checks run inline with mix run -e '...' , no file needed, and iex -S mix opens the same project in the shell for quick experiments. One more note on the outputs: mix prints a Compiling N files (.ex) banner before running, and the count depends on your build cache. I trimmed that line from most examples below. Table of Contents Introduction The Difference: def and defp What Privacy Actually Protects Refactoring the Todo Project Privacy Is Per Module, Not Per Namespace Multiple Clauses: One Name, One Visibility Docs, Specs, and Private Functions @doc false: Public but Hidden Reading a Module's Surface Import Only Bri

"A URL shortener" sounds like a weekend project. Slug in, long URL out, 302 , done. That's what I thought too. Then real usage showed up: links opened inside Instagram's in-app browser and didn't convert, bot traffic wrecked the analytics, and one link needed to send a US visitor somewhere different from an EU visitor. Suddenly the "trivial" part was 5% of the work. I built the whole thing on FastAPI + Redis + MySQL + htmx , deliberately with no frontend framework . This post is about the parts that turned out to be interesting — the redirect hot path, geo/device routing, and escaping in-app browsers — and why htmx was the right call for a one-person team. Disclosure: I build tapurl.io , a link shortener for marketers. This is a write-up of the engineering behind it, not a pitch — everything below is patterns you can apply to any shortener. The redirect is a hot path, so treat it like one Every other page in the app can be a bit slow. The redirect cannot. It sits in front of someone's click, and it runs on every click, so it has to be a tight, predictable read. The naive version hits your database for every redirect: @app.get ( " /{slug} " ) async def redirect ( slug : str ): link = await db . fetch_link ( slug ) # DB round-trip on every click if not link : raise HTTPException ( 404 ) return RedirectResponse ( link . destination , status_code = 302 ) That's fine until you have traffic. The slug-to-link lookup is a near-perfect cache candidate — a slug maps to the same link record every time. So the real path reads from Redis first and only falls back to MySQL on a miss: async def resolve ( slug : str ) -> Link | None : cached = await redis . get ( f " link: { slug } " ) if cached : return Link . parse_raw ( cached ) link = await db . fetch_link ( slug ) if link : await redis . set ( f " link: { slug } " , link . json (), ex = 3600 ) return link Two things worth saying out loud: Cache the lookup, not the decision. You cache the link record, but the actual destination

The main action took place at Geneva Watch Days, but others dialed in remotely to make sure it wasn't just a Swiss party.

Who hasn't built a full-stack app on AWS before, we all know the drill. You need an API (usually Lambda with API Gateway), a frontend, some authentication (Cognito) wired up, and IaC (CDK) to help deploy the app. On their own, none of that is hard, but wiring it up all together, especially in a team where every developer has their own style, always takes an amount of time before you even get to write a single line for the business logic. Nx Plugin for AWS ( @aws/nx-plugin ), an AWS Labs open source project, tackles that problem with code generators built on top of Nx . Instead of once again writing out boilerplate for every new service or website, you can just run a generator (CLI), answer a few questions, and get production-ready application code plus the CDK or Terraform to deploy it. This article introduces what the plugin does, the core concepts, and how to scaffold a complete full-stack app. What sets Nx Plugin apart from just another scaffolding tool? A note on versioning: at time of this article the plugin was pre-1.0, currently working through a 1.0.0-rc.x release candidate series with regular updates. Commands and generator names below were accurate at time of writing, check npm view @aws/nx-plugin version before you start, given the pace, it's likely to have moved on since this article published. A quick primer on Nx For the uninitiated Nx is a toolkit specifically for monorepos. Two things define Nx: A dependency graph across projects. Nx knows how the individual parts of your projects relate to each other (which website depends on which API, which library is shared where), and it uses that graph to only build, test, or lint the things actually affected by a change, with results cached so recurring CI/CD runs should be fast. Generators. Nx has a plugin system where a package can register generators, scripts that scaffold or modify code in your workspace, invoked via the nx g (or nx generate ) command. This is the bit @aws/nx-plugin builds on. Nx is not AW

Who hasn't built a full-stack app on AWS before, we all know the drill. You need an API (usually Lambda with API Gateway), a frontend, some authentication (Cognito) wired up, and IaC (CDK) to help deploy the app. On their own, none of that is hard, but wiring it up all together, especially in a team where every developer has their own style, always takes an amount of time before you even get to write a single line for the business logic. Nx Plugin for AWS ( @aws/nx-plugin ), an AWS Labs open source project, tackles that problem with code generators built on top of Nx . Instead of once again writing out boilerplate for every new service or website, you can just run a generator (CLI), answer a few questions, and get production-ready application code plus the CDK or Terraform to deploy it. This article introduces what the plugin does, the core concepts, and how to scaffold a complete full-stack app. What sets Nx Plugin apart from just another scaffolding tool? A note on versioning: at time of this article the plugin was pre-1.0, currently working through a 1.0.0-rc.x release candidate series with regular updates. Commands and generator names below were accurate at time of writing, check npm view @aws/nx-plugin version before you start, given the pace, it's likely to have moved on since this article published. A quick primer on Nx For the uninitiated Nx is a toolkit specifically for monorepos. Two things define Nx: A dependency graph across projects. Nx knows how the individual parts of your projects relate to each other (which website depends on which API, which library is shared where), and it uses that graph to only build, test, or lint the things actually affected by a change, with results cached so recurring CI/CD runs should be fast. Generators. Nx has a plugin system where a package can register generators, scripts that scaffold or modify code in your workspace, invoked via the nx g (or nx generate ) command. This is the bit @aws/nx-plugin builds on. Nx is not AW

Our app ships long video lessons. Twenty to forty minutes each, watched mostly on hostel wifi and mobile data with two bars. Streaming video looks like a solved problem when you build the happy path. You wire up ExoPlayer, point it at a stream, it plays. Then real students open it on devices you have never held, and your bug tracker starts filling up with one line: "video not playing." That line turned out to be four unrelated problems. Here's what I actually learned. ## Buffering is the bug you feel before you see an error Nobody waits out a bad connection during a 35-minute lecture. On a 15-second reel a stall is annoying. In a lecture, a stall every two minutes means the student closes the app and studies from a PDF instead. So the real question was never "does it play." It was "what happens when the network stops cooperating for four seconds." Three situations broke us repeatedly: Wifi to mobile data handover mid-lesson Bandwidth that is technically connected but useless Short total drops, three to ten seconds, that should not end playback ExoPlayer gives you everything you need here. Adaptive bitrate, a configurable LoadControl , player listeners. The catch is that the defaults are tuned for general media, not for a 40-minute lecture on a bad link. What moved the numbers for us: Bigger buffers, deliberately. DefaultLoadControl.Builder().setBufferDurationsMs(...) takes a min buffer, a max buffer, the buffer needed to start playback, and the buffer needed to resume after a rebuffer. That last parameter is the interesting one. Raising it costs you a little extra time on resume and buys you far fewer repeat stalls, because the player stops trying to restart on a nearly empty buffer. Telling the user the truth. Our first version showed a spinner and nothing else. A spinner with no context reads as "the app is frozen," so students force-closed and reopened, which threw away the buffer and made everything worse. Saying "reconnecting" instead of spinning silently cut t

Every week I read the same story in a slightly different shape. An AI agent deleted a production database. An agent emailed the wrong recipient list. An agent ran up a surprise bill because nobody set a spend limit. These incidents get a viral thread, a few hundred angry replies, and then they vanish. The next team wires up an agent with the exact same missing guardrail, and the exact same thing happens again. Agent failures are undocumented and, because they are undocumented, they repeat. That is the problem I wanted to fix. So I built AgentPostmortem , a public registry of AI agent failures. Real incidents, documented and searchable, at agentpostmortem.com. The core idea Aviation has the NTSB. Software has postmortems and status-page retrospectives. AI agents, which are being handed write access to filesystems, inboxes, payment APIs, and cloud consoles, have nothing comparable. There is no shared, structured record of what has actually gone wrong. AgentPostmortem is that record. It is a community-driven database of incidents where an AI agent caused real harm: deleted data, sent emails to the wrong people, ran up unexpected bills, exposed credentials, or otherwise went off the rails in production. Cases can be submitted anonymously or with attribution. Every case is reviewed before it goes public, and each approved case gets a permanent identifier in the form APM-XXXX so it can be cited and referenced forever. The goal is not to dunk on any particular model or vendor. It is to turn one-off war stories into a corpus you can actually search before you ship. The schema The value of a registry lives in its schema. If every report is a free-form blog post, you cannot compare or aggregate anything. So the submission is structured and validated. The fields I settled on, enforced with a Zod schema on the server, are: Agent involved , chosen from a known registry of agents (Claude, GPT-4, o1, o3, and others), each tied to its company. Title , a concise summary, between 20

Have you ever watched a two-kilobyte write fail with No space left on device while df -h still showed free gigabytes? I did, and I spent the next forty-eight hours cleaning the wrong evidence. This is the reconstructed field notebook from that session, including the commands I ran, the ones that misled me, and the checklist I now run before I blame the disk. Nothing here is a benchmark, a quota promise, or a claim about hardware I did not measure. I was iterating on a small Python worker that dumped JSON sidecars next to each run. The worker itself was unremarkable. The failure mode was not. Hour 0: the write that should have been boring The first traceback looked like a disk problem, so I treated it like a disk problem. Would you have done anything else with ENOSPC staring at you from a three-line stack? I would not, and that is exactly how the next two days started. OSError: [Errno 28] No space left on device: 'runs/2026-09-05T07-12-04.json' I ran the obvious command, got a comforting number, and closed the wrong investigation. df -h reported plenty of space on the root filesystem, and /tmp looked equally relaxed. I even created a dummy file in $HOME by hand, which succeeded, so I told myself the worker path was special. df -h df -h /tmp /var /home touch ~/probe-ok.txt && ls -l ~/probe-ok.txt That last touch was the trap. Can a filesystem accept a file in one directory and refuse a tiny file in another while still having blocks to spare? Yes, and inode exhaustion is the boring reason. I did not ask that question for twelve hours. What I tried first, and why it felt reasonable I treated the symptom as log rot, because that is the story operators tell each other. I truncated worker logs, deleted old JSON sidecars I could see, and reran the job with a smaller batch. The write still failed, sometimes on file number twenty, sometimes on file number four. Truncated worker.log and debug.log with : > file instead of deleting the path. Removed a handful of large .jsonl fil

Managing files, running scripts, and executing terminal commands on your smartphone from a computer is much more convenient through a full SSH session, eliminating the need to switch between device screens. ​Installing OpenSSH Open Termux and install the package for the secure protocol: pkg update && pkg install openssh Configuration ​Set a password to secure the connection: passwd ​ Find your current username using the whoami command (usually looks like u0_a... ). ​Start the SSH server: sshd ​Connecting from a PC Find your smartphone's local IP address using ifconfig (look for the inet line under the wlan0 interface). Note that Termux uses a non-standard port 8022 by default instead of the standard 22. Connect from your computer (Linux, macOS, or Windows via PowerShell/PuTTY): ssh <username>@<smartphone_IP> -p 8022 After entering your password, you will gain full access to your phone's terminal directly from your PC. Autostarting the Server To avoid starting the server manually every time you open the app, add the command to your shell configuration: echo "sshd" >> ~/.bashrc This tool turns your mobile device into a fully functional remote node that is easy to manage over the local network when developing and testing lightweight projects. I share more simple and awesome smartphone IT projects on my Telegram channel: @termuxq

The Hidden Cost of React Server Components When React Server Components (RSC) were first introduced, they were hailed as the solution to the "bundle bloat" problem. By shifting rendering logic to the server, we promised users faster initial page loads and a cleaner separation of concerns. However, after deploying RSC at scale in production environments throughout 2026, many teams are discovering a harsh reality: RSC is not just a syntax update; it is a fundamental shift in architectural paradigm that punishes lazy design. If you aren't careful, your "performance-first" architecture can quickly become a massive bottleneck. Let’s dive into three critical lessons learned from the trenches of production RSC development. 1. The Sequential Waterfall Regression In the traditional client-side React world, we were accustomed to useEffect data fetching patterns. Moving to an async/await model in Server Components feels intuitive, but it introduces the risk of sequential waterfalls that block your entire render pipeline. The Anti-Pattern Consider a scenario where you need to fetch user profile data and their associated posts. A naive implementation might look like this: // ❌ The Waterfall: This will block the render until both finish async function Profile ({ id }) { const user = await getUser ( id ); const posts = await getPosts ( id ); return < ProfileView user = { user } posts = { posts } /> ; } In this example, the server must wait for getUser to resolve before even initiating the getPosts request. This doubles your latency. The Optimization: Parallelism and Streaming To fix this, you must leverage Promise.all to initiate requests concurrently. Even better, you should push these fetches into separate sibling components to allow React to stream the results as they arrive. // ✅ The Optimized Approach function Profile ({ id }) { return ( <> < Suspense fallback = { < UserSkeleton /> } > < UserComponent id = { id } / > < /Suspense > < Suspense fallback = { < PostsSkeleton /> }

"Fundamentally, we want to learn about the origins of this planet and how it came to be like it is."

In the Mapbox Standard Style , the complexity of its layer styling is abstracted away — you can configure it with predefined variables, but you can't directly edit its layers. This is by design, and allows you to benefit from continuous improvements by our map designers. So what do you do when you need a label to say something different, appear at a different zoom level, or simply not appear at all? Here's a technique for surgically replacing a single label with your own, while keeping everything else in the Standard style untouched and precisely matching the label style. In the embedded example below, we've replaced the label for "New York" with "New Amsterdam". Why they changed it, I can't say. 😉 Using a classic style? If you're on a classic Mapbox style where you have direct access to edit symbol layers, there's a simpler approach: override the label text using an expression directly on the layer. See Customize label text in the Mapbox docs. This post is specifically about the Standard style, where internal layers are not editable — which requires a different technique. Step 1: Get the exact coordinates and properties of the label feature Most map labels come from the place_label source layer in the Mapbox Streets tileset . Here's a simple map that shows only the place_label source layer's points (and water features for reference). Click a label and you will see its full data, including the coordinates and properties: Copy the full GeoJSON Feature. Fields like symbolrank , filterrank , class , worldview , text_anchor , and capital all control how the label is styled and at which zoom levels it appears. You'll need to match these when building your replacement feature. Step 2: Build a custom style that imports Standard Instead of loading the Standard style directly, create a top-level style JSON that imports Standard and adds your own source alongside it: const map = new mapboxgl . Map ({ style : { version : 8 , sprite : ' mapbox://sprites/mapbox/standard/... ' ,

In what appears to be a follow-up to the mighty “CasiOak,” the rugged Japanese watch brand is expected to release an all-new luxury homage.

A federal judge temporarily barred an X rival from using the Twitter name, but found that X was likely to have abandoned the “Tweet” trademark and bird logo. The startup has since relaunched as Tweet.app.

The company says no children under 13 can ride -- even with a parent. That's more restrictive than the Model Y SUVs it's using as robotaxis.

The browser console showed exactly what CORS errors always show — a request blocked for violating the same-origin policy — except the response headers, visible in the network tab, clearly included Access-Control-Allow-Origin: * . The header the browser wanted was right there. The browser rejected the request anyway. The detail that's easy to miss in the network tab Chrome's network inspector, by default, coalesces duplicate header names into a single display line — so Access-Control-Allow-Origin: * shown once in the UI can actually mean the header was sent twice by the server, and the browser is showing you a merged, deduplicated view rather than the literal wire response. curl -s -D - https://api.example.com/data -o /dev/null | grep -i access-control Access-Control-Allow-Origin: * Access-Control-Allow-Origin: https://app.example.com Two separate headers, both valid individually, sent by two different layers that each thought they were the one responsible for CORS: our nginx reverse proxy had a blanket add_header Access-Control-Allow-Origin *; for general API access, and the application server behind it independently set a specific origin for authenticated routes. Neither config was wrong on its own. Together, they produced a response with the header appearing twice — and per the Fetch spec, a response with multiple Access-Control-Allow-Origin values is treated as invalid, so the browser blocks the request rather than guessing which one you meant. Why this is worse than a missing header A missing CORS header fails immediately, obviously, the same way every time. A duplicate header fails in a way that looks, from the response body alone, like the header is present and correct — because it is present, twice, which is precisely the state that trips the spec's validation. Every piece of evidence you'd normally check says "this should work," and it still doesn't. The fix Removed the blanket nginx header and let the application server be the single source of truth for COR

The US government is investigating whether the Cybercab, which lacks a steering wheel and pedals, meets vehicle safety standards.

Airbnb redesigned its authentication architecture around server driven flows and policy based challenge selection. The new Flexible Authentication system reduced authentication related code by 60%, cut the web client bundle by 100 KB, improved successful authentication by 2.6%, reduced duplicate account creation by 27%, and lowered OTP costs by 11%. By Leela Kumili