标签：#X

If you searched for a klogg alternative , you probably already know klogg is good. It is fast, it is free, it is open source, and it runs on Windows, macOS and Linux. Most people who go looking for something else are not unhappy with klogg as a viewer. They are unhappy with one specific moment in their day: Opening the file again. You investigated a 48GB log yesterday. You closed it. This morning your colleague asks about a different error, and you have to wait through the whole index build a second time. On a USB HDD that is nine minutes of staring at a progress bar — and while it builds, klogg only shows you the beginning of the file. That is the problem this article is about. Below is a measured comparison on a real 47.73GB file, including the rows where klogg wins . The test File OpenStreetMap Japan japan-latest.osm — 47.73 GB, 892,239,125 lines Machine MacBook Air / Apple M4 (10 cores) / 32GB RAM Storage (measured with dd ) USB HDD 0.10 GB/s ／ USB SSD 0.41 GB/s ／ Internal SSD 3.29 GB/s Versions klogg 24.11.0 ／ UwView Pro Search hit counts were verified to match exactly across klogg, UwView Pro, and a direct search of the raw file — so we know both tools are answering the same question. The numbers klogg 24.11.0 UwView Pro Ratio First open HDD ~9 min ／ USB SSD ~110 s ／ Internal SSD ~15 s — every time HDD 10.6 min ／ USB SSD 138.5 s ／ Internal SSD 23.3 s — first time only klogg wins Reopening Same as the first open (re-indexes every time) 0.01–0.07 s ~1,250–50,000x Search, literal "Tokyo" ~585 s ／ 120–135 s ／ 15–20 s 74.8 s ／ 14.3 s ／ 5.1 s ~7.8x ／ ~9x ／ 3–4x Search, regex "Tok[yi]o" ≈ literal (I/O bound, pattern-independent) 29.8 s (USB SSD) ／ 11.0 s (Internal SSD) ~4.4x ／ ~1.5x Disk used to keep the file 48 GB (original required) 5.3 GB (original can be deleted) 1/9 Two things are worth saying plainly. klogg opens the file faster the first time. UwView Pro is slower on the first open because it is building a compressed cache while it reads. That is a real cost a

This article is about running a hand-written Gemma 4 port in pure JAX on three different accelerators, and about the two places the abstraction leaks. The code is here: github.com/xbill9/gemma4-dev What is this project trying to Do? This project aims to serve one Gemma 4 checkpoint from one JAX port across every accelerator I can rent, and to find out — by measurement, not by reading docs — which parts of "it's just JAX" are true. The port lives in ports/gemma4/ and is driven by a generation loop behind an OpenAI-compatible server. No PyTorch, no vLLM, no torch_xla . The same code runs on Cloud TPU v5e and v6e, and on an NVIDIA T4G attached to an AWS Graviton2 host. "Pure JAX" is the whole experiment. If the port is really portable, the only thing that should change between those rigs is a config file. It mostly is. Two things are not, and they are the interesting part. Gemma 4 E2B is not a stock transformer Any port has to carry four irregularities, and none of them are optional: Two attention geometries. Sliding layers use head_dim=256 , global layers use 512 . Most inference stacks assume one head dimension per model. 8:1 MQA , so the KV budget is nothing like the parameter count would suggest. A KV-share map that collapses 35 layers onto 15 caches . A 512-slot sliding ring , plus per-layer embeddings (PLE) held in a 4.70 GB table that gets quantized to 4 bits on load. That first one is worth dwelling on, because it is what breaks other stacks. On the vLLM path, the heterogeneous head dims force the Triton attention backend: Gemma4 model has heterogeneous head dimensions {'sliding_attention': 256, 'full_attention': 512}. FA4 not available, forcing TRITON_ATTN backend. And on a Turing GPU that backend then asks for shared memory the hardware does not have: triton.runtime.errors.OutOfResources: out of resource: shared memory, Required: 98304, Hardware limit: 65536 JAX never enters that conversation. Attention is ordinary XLA rather than a hand-tiled kernel, so ther

Building Next-Gen Agentic Architectures: From Local RAG to Sandboxed Execution and BigQuery MCP The 3 AM production fire revealed a harsh truth: modern agentic systems often collapse under their own weight. A single agent processing 10K RAG queries OOM-killed an 8GB cloud instance. The culprit was not the workload but the infrastructure: @pinecone-client/vecdb with 47 transitive dependencies bloat memory with unquantized float32 embeddings. The solution was 200 lines of Python using sqlite3 , array , and heapq , with bounded queues and race condition resilience. This is the story of how we replaced dependency bloat with surgical precision. The Dependency Problem Agentic systems today face three critical bottlenecks: Vector Search : Libraries like faiss-cpu (12MB) combined with pg-vector (synchronous disk I/O) block the event loop, creating latency spikes. BigQuery : The @google-cloud/bigquery client (12MB) plus grpcio (5MB) leaks file descriptors, hitting Linux's default 1024 soft limit. Sandboxing : Docker containers consume 500MB+ per instance, making them impractical for memory-constrained environments. The root cause is always the same: unbounded resource consumption. 1M vectors at 768 dimensions in float32 consumes 3GB of memory. Synchronous I/O stalls the event loop. Unmanaged connections leak file descriptors. The Zero-Bloat RAG Engine The solution begins with a fundamental shift: replace heavy dependencies with lightweight, audited code. Our LocalRAG implementation demonstrates this approach: import sqlite3 import array import heapq import json import threading from typing import List , Tuple , Optional class LocalRAG : def __init__ ( self , db_path : str , dim : int = 768 , max_vectors : int = 1_000_000 ): self . dim = dim self . max_vectors = max_vectors self . lock = threading . Lock () self . conn = sqlite3 . connect ( db_path , isolation_level = None , check_same_thread = False ) # Enable WAL mode for concurrent reads/writes self . conn . execute ( " PR

Technical progress has encouraged a new batch of companies to jump in on the promise of profits from humanoid robots. And they're all Chinese automakers.

Are XREAL's smart glasses the way of the future for home entertainment?

According to Xbox CEO Asha Sharma, Project Helix, which she announced in March as a codename for Microsoft's "next generation console" - phrasing that seemingly implied a singular device - will actually be a "family" of devices." "We've been hard at work on a great next generation and a great family of devices for Helix, […]

Nobody likes phone trees. "Press 1 for billing, press 2 for support." Miss an option? Start over. It is friction at its worst. The voice-ivr-with-agent-backend example replaces that with a natural language conversation. Callers just say what they need, and the app routes them to the right department. Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/voice-ivr-with-agent-backend What it builds A Python/Flask app that handles inbound calls with a conversational IVR: Inbound Call -> answer with Call Control -> look up menu config from KV -> LLM generates a dynamic greeting -> gather(speech) — caller says what they need -> LLM routes intent to a department -> transfer call The core primitives The app combines four Telnyx primitives: Call Control : answer() , speak() , gather_using_speech() , transfer() AI Inference : telnyx.ai.openai.chat.completions.create() for greetings and intent routing KV store : menu config per phone number (business name, departments, transfer numbers, keywords) Agent state machine : an IVRAgent class that tracks call state, turn count, and retry logic Dynamic greeting via LLM Instead of a hardcoded "Press 1 for billing," the app generates a conversational greeting from the KV config: def generate_dynamic_menu_prompt ( menu_config : dict ) -> str : departments = menu_config . get ( " departments " , []) dept_list = " \n " . join ( f " - { d [ ' name ' ] } : { d [ ' description ' ] } " for d in departments ) return ( f " You are an IVR assistant for { menu_config [ ' business_name ' ] } . " f " Available departments: \n { dept_list } \n\n " f " Greet the caller briefly and ask how you can help. " f " Keep it conversational and under 2 sentences. " ) The LLM generates the greeting through the OpenAI-compatible Telnyx Inference binding. If it fails, the app falls back to a static greeting from the KV config. Intent routing via LLM When the caller speaks, the transcription is passed to route_intent_with_llm . The LLM is instructed

Hello everyone! 👋 Happy to be joining the DEV community. I’m a Computer Engineering student based in Italy. My main focus is Cybersecurity, but I strongly believe you have to know how to build a system before you can secure (or break) it. Lately, I’ve been jumping between two very different worlds: Embedded C: writing firmware, managing file systems, and building custom OLED menus for the M5Stick S3. Frontend: building web apps using Next.js and React. My workflow is a bit of a hybrid. I like to focus on the system architecture, memory management, and edge cases, while using AI tools to do the heavy lifting of writing the actual code. Then, I review everything strictly to make sure it doesn't break. I’m here to build in public, share my projects, and learn from this awesome community. What are you all currently hacking on? See you around!

Kasia Trapszo discusses how Netflix evolved its commerce platform from a U.S. DVD service into global infrastructure. She explains navigating international payment realities, adapting to strict regulatory mandates, decomposing monolithic architectures along domain boundaries, and re-architecting systems for massive live-event demand - proving great systems survive by continually evolving. By Kasia Trapszo

I’m setting up a local AI development environment on Windows + WSL2 and I’m trying to decide between two architectures. Option 1 — Ollama/Models on Windows WSL2 ┌───────────────────┐ │ Application │ │ ├── Python │ │ ├── .venv │ │ └── Source code │ └───────┬───────────┘ │ HTTP localhost:11434 │ ▼ Windows ┌───────────────┐ │ Ollama │ │ ↓ │ │ Models │ │ ↓ │ │ GPU │ └───────────────┘ Option 2 — Ollama/Models inside WSL2 WSL2 ┌─────────────────────────┐ │ Application │ │ ↓ │ │ Ollama │ │ ↓ │ │ Models │ └────────────┬────────────┘ │ GPU access │ ▼ Windows ┌─────────────────────────┐ │ GPU / Driver │ └─────────────────────────┘ My current setup is Option 1 , and it works: WSL2 can access the Windows Ollama API through localhost:11434. But I’m wondering if Option 2 is a better long-term architecture for local AI/LLM development. I’m especially interested in: 🚀 Performance 🎮 GPU utilization 🧠 Model management 💾 Disk usage 🔧 Setup and maintenance 🐧 Linux/ML tooling 🐳 Docker integration 🌐 Networking 📈 Future scalability If you use Ollama with Windows + WSL2, which architecture would you choose and why? And if you've actually used both setups, I'd especially like to hear about your experience. 👇 Option 1 or Option 2?

Nvidia is worth more than most countries because we cannot figure out how to do cheap...

A Windows 11 VM in Proxmox VE was showing nearly 100% memory usage in monitoring. Inside Windows Task Manager, however, actual memory usage was only around 30–50% . At first glance, that looks like a monitoring problem. It wasn't. The issue was in the VM configuration: the PVE Ballooning Device had been disabled , which meant Proxmox VE was not receiving the guest memory statistics needed to reflect the actual Windows memory state. I encountered this while monitoring a Proxmox VE environment with OpsHome NOC. This post documents how I traced the discrepancy and fixed it. The symptom On the same Proxmox VE host, the memory usage of Ubuntu VMs looked normal. One Windows 11 VM was different. The VM had 24 GB of RAM configured, but the monitoring result remained close to: Memory: 100% Used: about 24.2 GB Total: 24 GB Inside Windows 11 Task Manager, however, the VM was clearly not using all of its memory. The difference looked roughly like this: Monitoring: 90%–100% Windows 11: 30%–50% That is too large a difference to treat as a normal sampling variation. If you encounter something similar, especially when Linux VMs on the same Proxmox host look normal, do not immediately assume: Windows has a memory leak The monitoring threshold is wrong The monitoring application is calculating memory incorrectly The more important question is: Is Proxmox VE actually receiving the correct memory statistics from the Windows guest? Checking BalloonService inside Windows 11 For Proxmox VE to obtain useful guest memory statistics from a Windows VM, the VirtIO Balloon driver and its related Windows service need to be available. Inside Windows 11, I opened PowerShell and checked BalloonService: Get-Service * balloon * The result showed: Running BalloonService So the Windows-side BalloonService was already installed and running. At this point, the guest-side service did not appear to be the problem. The next step was to check the VM configuration on the Proxmox side. Checking the Proxmox VE

Your Free AI Server Will Fail Quietly. Five Gates to Make It Loud. The model can be innocent. The server cannot. Earlier this week I wrote a fail-closed checklist for AI-generated code. That list guards against the model writing something dangerous. This list guards against something duller: the server around it dying at 2 a.m. while the model stays online the whole time. Nobody sees that failure until a user does. The setup I am testing MonkeyCode for a small side build: a log-summarizing API. The project gives you free model access and a free server option, which is exactly the toy setup I like. Ten lines of app logic. Zero dollars. One honest problem: free infrastructure is someone else's best effort. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Before you judge, my plan was simple. I deliberately killed my own server to see where the stack would fail. Then I wrote gates that make each failure loud. The kill test Here is the failure sequence, reproduced on purpose. The server process died. No restart policy. Connections hit a dead socket. Nothing answered. The client had no timeout and waited forever. No health probe. No alert. No log line. Four hours later, the model was still happy. The server was still dead. The tool was still broken. The model was innocent the whole time. The harness was the guilty one. The problem was never intelligence. It was silence. So here are five gates, ordered from cheapest to most annoying. Gate 1: A kill switch that outlives the process A crash bug can take down your app. It can also take down your ability to disable the app. So the switch lives outside the app. KILL_FILE = " /tmp/disable-monkeycode " @app.post ( " /summarize " ) def summarize ( logs : str ): if os . path . exists ( KILL_FILE ): raise HTTPException ( 503 , " disabled by operator " ) ... Why a file and not a database row? Because the DB may be down when you need the switch most. A file survives restarts. You can touch it from cron.

In remote software demos, the biggest problem is not always the product itself. Sometimes the audience simply doesn’t know where to look. A button may be visible. A setting may already be on screen. The presenter may be explaining everything correctly. But if attention isn’t directed clearly, people can still get lost. After doing a lot of screen sharing and software demos, I kept noticing the same small UX problems. 1. The cursor is visible, but not necessarily noticeable When you're presenting your own screen, you always know where your pointer is. The audience doesn’t. On a large monitor, a compressed video call, or a busy application UI, the pointer can easily disappear visually even though it is technically visible. This becomes especially obvious when you say something like: “If you look over here…” You know exactly what “here” means. The audience may need another second or two to find it. That delay sounds minor, but during a demo it can happen again and again. A presenter moves on to the next step while part of the audience is still trying to locate the previous one. 2. Moving the pointer is not the same as directing attention A common workaround is to move the mouse around whatever you want people to notice. I’ve done this many times myself. Circle the button with the cursor. Move back and forth over a chart. Quickly point between two settings. It works, but it also adds visual noise. Eventually I realized there are really two different actions happening: Navigation — using the mouse to operate the software. Attention — telling the audience where to look. During a demo, those aren’t always the same thing. Sometimes I don’t want to click anything or change the interface. I just want to say: Look here. 3. Highlighting something can interrupt the demo There are plenty of powerful screen annotation tools available. They make sense when you want to draw arrows, write notes, add shapes, or explain something in detail. But during a live product demo, switching int

How I Built a Wedding Planning Suite with Supabase in 3 Months Quick Answer: I built a full wedding planning platform in 90 days using Supabase as the backend (PostgreSQL database, real-time subscriptions, Row Level Security, and OAuth auth), Next.js 14 for the frontend, and a few carefully chosen npm packages for specific features like QR code scanning. The key was leveraging Supabase's managed services to avoid building auth, websockets, and file storage from scratch. Introduction Three months ago, I had an idea: what if couples could plan their entire wedding through one cohesive platform? Not a static checklist app, but a living, breathing system where vendors, guests, budgets, and timelines all talked to each other in real time. I'm a solo developer with a day job. I didn't have a team of backend engineers to build authentication, real-time sync, or file storage infrastructure. I needed a stack that would let me ship fast without shipping broken. Enter Supabase. I'd heard the "Firebase alternative" pitch before, but what I discovered was something far more powerful for developers who actually want to own their data and their SQL. This is the story of how I built WedPlanner—a full wedding planning suite—with Supabase, Next.js, and a few other tools. No VC funding. No offshore team. Just me, a tight deadline, and a PostgreSQL database that never let me down. Why Supabase? The Architecture Decision That Made Everything Possible When you're building alone, every architectural decision compounds. Pick the wrong database, and you'll spend weeks fighting migrations. Pick the wrong auth solution, and you'll ship with security holes you don't even know about. I evaluated Firebase, PlanetScale, Clerk, and rolling my own PostgreSQL on RDS. Here's why Supabase won: PostgreSQL, not a proprietary document store. Wedding data is relational. A guest belongs to a wedding. A vendor has multiple bookings. A budget category has many line items. Trying to model this in Firestore's

📝 Originally published (in Japanese) at forge.workstyle.tech . The Challenge of "Silence" in Unmanned AI Avatar Live Streams When creating a live stream where an AI avatar operates autonomously, the first major hurdle you encounter is the issue of "silence." It’s not that there are no viewers—quite the opposite. Yet the avatar falls silent for long stretches, or ignores comments for tens of seconds. What human streamers do unconsciously—creating "space" in the conversation—is entirely missing from AI behavior. In this article, I’ll summarize two key challenges we tackled to prevent unmanned streams from becoming boring. The first: how to fill the silence when no comments arrive. The second: how to handle response delays when comments do arrive. The former deals with behavior during "no input," while the latter concerns the time between input and reaction. Both are two sides of the same coin in live streaming, and neither worked with a straightforward implementation. What they had in common was that brute-force attempts to "make it faster" or "make it smarter" missed the mark. We had to observe long-running streams, measure breakdowns, and redesign priorities—mundane but essential work. Reactive Alone Doesn’t Make a Stream Our initial implementation was straightforward: "Respond when a comment arrives." Functionally, it worked correctly and passed tests. The problem was what happens when no comments arrive. In an unmanned stream, the avatar stands frozen on screen for tens of seconds—blinking, but doing nothing. This is nearly an accident for a live stream. And for newly launched channels, this is the default state. Comments come only after the stream has grown; until then, silence is the norm. This was a design philosophy issue. If built as a chatbot, the AI only outputs in response to input —just like a web request/response model. But a streamer is different. Their job is to keep talking even when no one says anything. So we needed a mechanism that generates speech

xAI accused of training Grok on real and AI-generated child pornography.

When testing opinionated Linux distributions, the ultimate benchmark isn't how smoothly they run on a workstation with 16 cores and a high-end GPU—it's how gracefully they perform on budget, resource-constrained hardware. Enter Omarchy , the "omakase" Arch-based distribution created by David Heinemeier Hansson (DHH) . Built around the Hyprland tiling window manager and explicitly tailored for modern developer productivity, Omarchy proves that a curated desktop environment doesn't require a heavy computing footprint. Running Omarchy 4.0.0 on an entry-level laptop built around an Intel Celeron N4020 CPU demonstrates how deliberate software curation turns modest hardware into a fast, highly capable development machine. 💻 Hardware & System Overview Below is the environment breakdown from our test run: Category Specification / Details Hardware / PC Model ASUS C204M Processor Intel® Celeron® N4020 (2 cores / 2 threads) @ 2.80 GHz Graphics Integrated Intel UHD Graphics 600 Display 11" Built-in Display (1366x768 @ 60 Hz) RAM Utilization 2.69 GiB / 3.68 GiB (~73% load) Storage / Root 15.66 GiB / 27.10 GiB (~58% used) on Btrfs OS & Kernel Omarchy 4.0.0-1 (Linux Kernel 7.1.8-arch1-3) Compositor Hyprland 0.56.2 (Wayland) 🚀 The Developer Experience: What Makes Omarchy Special Omarchy isn't just an Arch installer with custom dots; it's an opinionated operating system designed to eliminate setup friction and let you write code immediately. 1. Zero-Friction Language Setup via Menus Setting up language runtimes on a fresh Linux install often involves hunting down version managers (like asdf , nvm , or pyenv ), configuring shell initialization scripts, and managing system paths. Omarchy streamlines this entirely. Through its integrated menu system, installing a programming language or developer stack is as simple as launching the system menu, picking a language (Node.js, Ruby, Python, Go, Rust), and hitting Enter. The system automatically installs the necessary version managers, conf

Netflix and Rockstar Games finally debuted their "extended look" at Grand Theft Auto VI. It showed that the new game looks to keep much of the spirit of GTA - exploration, driving, crimes, shooting, and cinematic story scenes. But everything just looks much better than previous entries, with impressive graphics, densely-packed rooms, and detailed environments. […]

Most package tracking flows make the customer do the work. You get a tracking number. You open a page. You refresh it. Maybe you get a generic text that says the package is out for delivery. If you need to ask a real question, you usually end up somewhere else entirely. I wanted to build the opposite shape: what if the package itself had an agent? The shipment-agent example is a Python and Flask app that treats a shipment as a durable AI entity. It can send proactive SMS updates, understand customer replies with Telnyx AI Inference, and answer inbound calls with shipment context. Code: https://github.com/team-telnyx/telnyx-code-examples/tree/main/shipment-agent What it builds The app centers around a ShipmentAgent . The agent owns: shipment status carrier and tracking context customer phone number interaction history messaging and voice behavior Instead of a stateless chatbot waiting in a web page, the agent lives alongside the shipment lifecycle. Carrier update -> Flask webhook -> ShipmentAgent updates state -> SMS customer Customer SMS reply -> Telnyx Messaging webhook -> AI Inference response -> SMS reply Customer phone call -> Telnyx Call Control -> ShipmentAgent answers with context Why this is useful Shipment status is not just data. It is a customer communication problem. People want to know: Is my package delayed? Can I leave delivery instructions? Did it already arrive? Who do I call if something looks wrong? Traditional tracking pages are good at showing status, but not at handling conversation. This example shows how to turn the shipment into a small communications agent that can respond across SMS and voice. The main flow When a carrier status changes, the app receives a webhook. For example: out_for_delivery delayed delivered The ShipmentAgent updates its internal state and sends a message to the customer through Telnyx Messaging. If the customer replies, the app passes the message and shipment context to Telnyx AI Inference. That lets the response incl