标签：#RAM

People type 2+2 into Google. They type 9+10 . They type 7*8 when they can't remember whether it's 54 or 56. Each of those is a real, high-volume search query — and most of the results are identical calculator widgets. So when I built Wrongulator , a calculator that returns a confidently wrong answer on purpose, I had a question worth asking: what if every expression were its own page, ranking for the exact arithmetic people already search? That is programmatic SEO — generating a page per parameter instead of writing pages by hand. And doing it across 17 languages means programmatic SEO with hreflang, where each generated page also declares its 16 translated siblings. The trap is that most programmatic surfaces are thin, duplicative, and get buried by Google. This one isn't, for a specific reason: every page has a real, unique answer baked into the HTML before any JavaScript runs. This post is about how — and the honest costs nobody mentions. Why a Permalink Per Expression Is Even Possible A page per expression only works if /2+2 reproduces the same result for everyone, forever, with no database behind it. That property isn't free — it's the result of one design decision I cover in detail in why a viral toy must be wrong the same way every time : the wrong answer is a pure function of the expression, seeded by a stable hash, with no per-user state. The relevant consequence here is what that property unlocks for SEO. Because f("2+2") always returns the same wrong answer, the server can compute that answer on demand for any expression in the URL, with zero storage. There's no pages table, no CMS, no pre-generation job. A request for /64+5 runs the engine, gets 67 ("the only correct number"), and renders a complete page around it. The programmatic surface is, in effect, infinite — but it costs nothing to hold, because nothing is stored. The pure function is what makes thousands of unique pages possible without a database. That's the foundation. Everything below is about

Sites that start from a stock theme tend to look like it. This one did too — until recently it was the default PaperMod screen. The editorial homepage and unified article styling you're looking at came out of a single day of customization. This guide is that work written down, with the code. One principle drove all of it: never fork the theme. The theme stays a submodule and keeps receiving updates; you win with site-level files only. Hugo resolves same-path site files ahead of theme files, which makes this possible. The entire customization of this site is a handful of files: layouts/index.html ← full homepage replacement data/home/ko.yaml, en.yaml ← homepage copy (per language) assets/css/extended/home.css ← homepage styles assets/css/extended/custom.css ← unifying every other page The starting point is a Hugo site with PaperMod as a submodule, deployed to GitHub Pages. Basic installation is well covered by the PaperMod wiki , so I'll skip it. 1. Replace the homepage wholesale Create a single layouts/index.html and the homepage is yours. The theme's home template stays untouched. The key move: don't hardcode copy into the markup — pull it from data files. On a bilingual site, one template then serves both languages: {{- $copy := index .Site.Data.home .Site.Language.Lang -}} {{- $posts := first 4 (where .Site.RegularPages.ByDate.Reverse "Section" "blog") -}} <section class= "editorial-hero" > <p class= "editorial-eyebrow" > {{ $copy.hero.eyebrow }} </p> <h1> {{ range $i, $line := $copy.hero.titleLines }}{{ if $i }} <br> {{ end }}{{ $line }}{{ end }} </h1> <p class= "editorial-intro" > {{ $copy.hero.intro }} </p> </section> data/home/en.yaml holds nothing but words: hero : eyebrow : " IDEAS · PRODUCTS · OPPORTUNITIES" titleLines : - " Where ideas become products," - " and products become new opportunities." Copy edits stop requiring template changes, and adding a language is one more yaml file. Latest posts are pulled dynamically as above — handle the {{ else }} emp

A demo Andrej Karpathy posted over the weekend stuck with me. He gave Opus 5 a million-token context and the first paragraph of The Lord of the Rings, and asked for a procedural 3D rendering of the scene in Three.js. The model worked alone for about two hours, wrote 5,500 lines, and coordinated polygon placement, camera paths, and animation on its own. Total cost: about $10. The result is faster to watch than to describe. Most reactions read it as the next step past "draw a pelican SVG" benchmarks. Something else looked bigger to me. What changed isn't the model's artistry. It's the unit of delegation. The unit of delegation changed Until now, the work we handed agents came in prompt-sized pieces. One function, one bug, one file. Anything bigger, we decomposed ourselves. The reason was simple: with a small context, the early parts of a long job slide out of view, and coherence goes with them. A million tokens erases that premise. Everything the model wrote and tried across a two-hour session stays in view. When the desk is big enough, there is no reason to hand work over in slices. Delegation moves from the task to the session. That is the difference between a function call and a work session. The first, we decompose and supervise. The second, we hand over material and intent, and receive a result. Karpathy's entire contribution was picking the paragraph and watching the output two hours later. Where the builder's work moves When execution costs $10 and two hours, execution is no longer the bottleneck. Two things remain. On the way in: the brief. What goes into the context. Karpathy's input was one paragraph, but choosing it was the design act. Translated to our work, it becomes choosing which spec, brand guide, reference, or codebase goes in whole — and what stays out. On the way out: judgment. By what standard do you accept the result? Reviewing 5,500 lines one by one doesn't match session-sized delegation. Instead, you define "done" before the run, then judge the

Graphical tools are great, but most of my daily development now happens in the terminal. A good CLI tool saves time, integrates with automation, and keeps my workflow consistent across local development and CI/CD. Here are the 10 CLI tools I use the most. Apidog CLI If you're working with APIs, this is the tool I've found myself using the most. I use it to run API test scenarios, manage environments, and reuse the same tests in GitHub Actions instead of maintaining separate GUI workflows. Git Still the foundation of every development workflow. Docker CLI The fastest way to spin up local services and reproduce production environments. GitHub CLI Creating pull requests, reviewing issues, and managing repositories without leaving the terminal is a huge productivity boost. HTTPie Perfect for quick API requests when debugging or exploring endpoints. jq If you work with JSON every day, jq is almost indispensable. ripgrep (rg) Lightning-fast code searching. Once you start using it, it's hard to go back. fd A simpler and faster replacement for the traditional find command. kubectl Essential for anyone deploying applications to Kubernetes. just A lightweight task runner that helps automate repetitive development commands. Final Thoughts The biggest improvement to my workflow has been moving repetitive tasks into the terminal. API testing, deployments, version control, and automation all become easier when everything is scriptable. Among these tools, Apidog CLI has had the biggest impact because it lets me keep API testing in the same terminal-first workflow that I already use for development and CI/CD. What CLI tool couldn't you live without?

submitted by /u/donmyar4 [link] [留言]

Why Build a Custom RTOS in 2026? Why build a custom RTOS when there are already tons of battle-tested ones like FreeRTOS or Zephyr available? It’s a fair question, but there's much more to it than just reinventing the wheel. Building a kernel from scratch forces you to understand low-level hardware interactions, assembly context switching, and memory layout. It fundamentally transforms you into a better embedded firmware engineer, sharpens your low-level debugging skills (hello, hard fault handlers!), and gives you complete freedom to architect a system tailored to your exact specifications. How to Get Started If you've decided to embark on building your own RTOS, here are the three critical decisions you need to make first: 1. Target Instruction Set Architecture (ISA) You need to choose a target architecture—common choices include ARM Cortex-M, RISC-V, MIPS, or x86. I chose the ARM Cortex-M4 architecture. It provides dedicated features tailored for OS design—such as the NVIC (Nested Vectored Interrupt Controller) , SysTick Timer , and the PendSV interrupt for safe context switching—along with an incredible community and ecosystem for developers. 2. Hardware vs. Simulation Select a development board featuring your target architecture (e.g., STM32). Alternatively, you can use QEMU to simulate the hardware environment before flashing physical silicon. In fact, many professional RTOS teams rely heavily on QEMU for automated testing and rapid prototyping. 3. Toolchain & Build Setup If you aren't using a Hardware Abstraction Layer (HAL) and want to write bare-metal code, you'll need a cross-compiler toolchain. Because I'm writing it in C and assembly for ARM, I am using the arm-none-eabi-gcc toolchain alongside GNU Make/CMake. What’s Next? In the next post, we’ll dive into startup scripts, linker scripts, and setting up the vector table . (Note: Throughout this series, I’ll be moving forward with the ARM Cortex-M4 setup, but the core operating system concepts will apply

Week 3. "The deploy is done. Everything's green. Now what am I actually supposed to be looking at?" Previously Runner ↓ Cache ↓ Artifact ↓ Deployment Today ↓ Monitoring Junior Engineer: The canary rolled out fine yesterday. 100% traffic, all healthy. I closed my laptop. Was that wrong? Senior Engineer: Not wrong, exactly. But let me ask you something first. Your service is running on a server somewhere. Right now, this second — is it healthy? Junior Engineer: I mean... I assume so? Nobody's messaged me. Senior Engineer: "Nobody's messaged me" isn't an answer. It's the absence of one. That's the entire problem monitoring exists to solve. The Thing Nobody Says Out Loud Senior Engineer: Here's an uncomfortable fact about production systems: you cannot see them. Not directly. You're not standing next to the server, watching electricity move through it. Everything you know about whether it's healthy is a claim — something a piece of software told you, that you're choosing to trust. Junior Engineer: That sounds obvious when you say it, but I don't think I've ever actually thought about it that way. Senior Engineer: Most engineers don't, until the gap between "the system told me it's fine" and "the system is actually fine" bites them. Monitoring is the discipline of shrinking that gap — of making sure what you're told is close to what's actually true, and told to you fast enough to matter. 📒 Senior Engineer's Notebook You don't monitor a system because you don't trust it. You monitor it because you can't see it. Trust isn't the issue — visibility is. The Car Dashboard Analogy Junior Engineer: Can you make this concrete? Senior Engineer: Think about driving a car. You can't see the engine. You can't see the oil level, the coolant temperature, how much fuel is actually left in the tank, mid-drive. All of that is invisible to you, sealed inside metal, while you're doing 100 km/h. So the car gives you a dashboard. Speed, fuel, engine temperature, warning lights. You're not wat

Looking for Contributors to Build Zentrail IDE — An AI-Native Open Source Desktop IDE Hello everyone! 👋 I'm building Zentrail IDE , an open-source, AI-native desktop IDE designed for the next generation of software development. The goal isn't to build another code editor. The goal is to create an IDE where multiple AI agents can collaborate with developers in a single workspace to plan, write, review, test, and manage code. We're still in the early architecture and planning phase, and I'm looking for developers, designers, and AI enthusiasts who want to help build it from the ground up. 🎯 Project Vision Create an AI-first development environment that combines: 🧠 Multi-Agent Collaboration 💻 Native Desktop Performance 🤖 AI CLI Integration 📦 Plugin & Skill Ecosystem 🌍 Open Source Community ⚡ Modern Developer Experience ✨ Planned Features Workspace System Multi-project workspaces Workspace memory Persistent sessions Task management AI Workspace Agents Multiple AI agents running simultaneously Shared workspace memory Parallel task execution Intelligent task orchestration AI CLI Support Claude Code Gemini CLI OpenAI-compatible providers Local AI models Custom AI CLIs Git Automation AI-assisted commits Pull requests Code reviews Branch management Repository insights Skill System Install reusable AI workflows with a single command. Examples: Security Review Code Refactoring API Generator Documentation Writer Test Generator Plugin SDK A modular extension system for adding custom functionality without modifying the core IDE. 🛠 Tech Stack Frontend TypeScript React Tauri v2 Monaco Editor Tailwind CSS Backend Go gRPC WebSocket AI Runtime Python MCP LangGraph Database SQLite 🤝 We're Looking For We're looking for contributors interested in: Frontend React TypeScript UI/UX Monaco Editor Backend Go gRPC WebSocket Performance optimization AI Python MCP Agent orchestration Prompt engineering Desktop Tauri Windows development Cross-platform architecture Design UI/UX Design Icons Develo

Firstly the whole conversation: https://share.gemini.google/NmMAhtBdsbtJ The TLDR (for ~100 head dept) 2 Pizza teams (8-10) turn into Domain teams (2-3) for a 75% reduction as roles vanish or merge. A 75% reduction in eng department head does not alter the departments Capacity. This is the 1x outcome. Staying at 100 gives 5-10x capacity. No change is ~$16m 25 heads in Domain is ~$5m (big saving!) with big workload lump on that 25, capacity probably drops 100 heads in Domains is $26m (costs went up!) with no backlog or idea left behind. org becomes hyper efficient and productive. operating costs drop, revenue climbs. Believable, or not? submitted by /u/Lower-Impression-121 [link] [留言]

Protocols let you define what a type can do without caring about what it actually is. Once...

Is your snoring just a nuisance, or is it a health warning? Obstructive Sleep Apnea (OSA) affects nearly 1 billion people worldwide, yet most remain undiagnosed due to the high cost of clinical polysomnography. Today, we are pushing the boundaries of AI Healthcare by repurposing OpenAI Whisper from a speech-to-text powerhouse into a clinical screening tool. In this tutorial, we will explore how to leverage Audio Signal Processing , Hugging Face Transformers , and Librosa to detect breathing patterns. By fine-tuning Whisper on non-speech acoustic events, we can transform a standard smartphone recording into a high-precision OSA screening device. Pro-Tip : If you're looking for more production-ready examples and advanced architectural patterns for AI-driven health monitoring, be sure to check out the deep-dives over at WellAlly Tech Blog . The Architecture: From Raw Audio to Clinical Insight To build an OSA screening algorithm, we don't just need to hear the sounds; we need to understand the rhythm and absence of sound. We use Whisper's robust encoder to capture the spectral features and a custom classification head to identify Apnea-Hypopnea events. graph TD A[Raw Sleep Audio .wav] --> B[Preprocessing: Librosa] B --> C[Noise Reduction & VAD] C --> D[Segmenting: 30s Windows] D --> E[OpenAI Whisper Encoder] E --> F{Event Classification} F -->|Normal| G[Healthy Breathing] F -->|Snore| H[Snore Phase Analysis] F -->|Silence/Choke| I[Apnea Event Detected] I --> J[AHI Index Calculation] J --> K[Final OSA Risk Report] Prerequisites To follow this advanced guide, you'll need: Tech Stack : Python 3.9+, transformers , librosa , torch , and evaluate . Dataset : Ideally, the UCD Snore Database or similar PSG-synchronized audio data. Step 1: Audio Preprocessing with Librosa Before feeding audio into Whisper, we need to clean the signal. Sleep environments are noisy (fans, traffic, etc.). We use librosa to normalize the audio and detect "Voice" (or in our case, Breath) Activity. im

The Silent Disruptor The silence in the room was absolute, broken only by the rhythmic scraping of pens on paper during a high-stakes meeting. Then, it happened. My pocket erupted into a frantic, brassy ringtone that seemed to last an eternity before I could fumble to silence it. My face turned crimson as the room’s focus shifted from the presentation to my vibrating trouser pocket. I had remembered to check my calendar, but I had completely forgotten to toggle my phone to silent mode. That moment of pure, concentrated embarrassment was the catalyst for me building Muffle. The Friction of Manual Control We live in an age of automation, yet our phones—the very devices meant to assist us—remain stubbornly manual when it comes to basic social etiquette. Every day, millions of people walk into mosques for prayer, classrooms for lectures, or medical offices for consultations, and every day, a percentage of them forget to silence their devices. This isn't just a minor annoyance; it is a persistent source of social friction. Before I started building Muffle, I looked for existing solutions. Most apps were either bloated with unnecessary permissions, required invasive cloud accounts, or simply failed to trigger at the right time. The fundamental problem wasn't just the lack of features like GPS-based prayer times or calendar-specific automation; it was the lack of reliability. If an automation app fails once, the user loses trust in it forever. If I am in a meeting, I cannot afford for the app to 'sleep' because the system decided to save battery at the expense of my configured routine. I needed something that could handle these state changes consistently, regardless of whether the phone was in my pocket, sitting on a desk, or buried in a bag. Architecting for Reliability When I began writing the core logic for Muffle, I immediately hit the wall that every Android developer eventually faces: Doze Mode. Android’s aggressive power management is designed to preserve battery by

submitted by /u/IamMichaelSalim [link] [留言]

Specifically, the video is about developing a game where all the textures and sounds are generated at runtime using Sine waves. I thought it was high-quality and explained complex math concepts well. submitted by /u/TheBrokenRail-Dev [link] [留言]

Following up on a common claim in the AI avatar space — that voice/video avatars convert better than plain text chat — there's surprisingly little rigorous testing behind it. If you're building or embedding one of these widgets, here's a practical way to actually measure it instead of trusting vendor case studies. Why This Is Harder Than a Normal A/B Test Standard A/B testing swaps one variable (a button color, a headline) while holding everything else constant. Avatar vs. text chat isn't that clean — you're changing interaction modality, response latency expectations, and visual real estate simultaneously. You need to isolate the variable that actually matters: does voice/video presence drive conversion, independent of the underlying conversation quality? A Cleaner Experimental Setup javascript // Pseudocode for variant assignment function assignVariant(sessionId) { const hash = hashSessionId(sessionId); return hash % 2 === 0 ? 'avatar' : 'text'; } Key controls to hold constant across both variants: Same LLM backend and prompt/knowledge base — the conversation logic shouldn't differ, only the presentation layer Same lead capture form and CTA placement — don't let UI differences beyond avatar-vs-text confound the result Same traffic source — segment by acquisition channel if traffic mix varies, since paid vs. organic visitors convert differently regardless of chat UI Minimum sample size before evaluating — novelty effects are real; running this for 3 days will overstate the avatar's lift. Run for at least 2-3 weeks to let novelty decay. Metrics to Track (Not Just Conversion Rate) Conversion rate alone hides why one variant wins or loses: session_start_to_first_message (engagement friction) message_count_per_session (depth of interaction) time_to_form_completion (avatar/video adds latency — does it cost or gain time?) bounce_rate_before_first_response lead_quality_score (if you can grade downstream — a lead isn't a conversion if it's junk) A common finding worth watc

submitted by /u/f311a [link] [留言]

Most business prediction problems do not arrive as prose. They arrive as rows: account attributes, transactions, sensor readings, test results, and a target column. For this kind of data, gradient-boosted trees and other conventional methods remain hard to displace. A new paper, Why Large Language Models Fail at Tabular Prediction , asks a much more useful question than “can an LLM classify a table?”: what, specifically, breaks as the task becomes more like ordinary tabular machine learning? The answer from the authors’ controlled experiments is input dimensionality. Their result matters because it separates a real limitation from several explanations that sound plausible but did not hold up in their tests. The experiment was about prediction, not table chat The paper evaluates frontier LLMs in a pure inference setup: a model receives labeled examples and must predict labels for new rows in a single generation pass. There is no fine-tuning, retrieval pipeline, tool calling, or agent loop to compensate for the base model. This is deliberately narrow. It asks whether a general-purpose language model can act as a direct tabular learner. Across 31 benchmark datasets, the authors compare nine methods and 252 configured classical models. That scope is important: a weak result on one CSV is easy to explain away as prompt design or a quirky dataset. A consistent trend across many tasks is harder to dismiss. The headline is not simply that LLMs lose to established tabular baselines. It is that their accuracy declines as the number of input dimensions grows, while the classical baselines in the study stay stable or improve. The paper therefore treats dimensionality as the central failure mode rather than an incidental property of difficult datasets. Four popular explanations did not survive testing There are several standard reasons developers give for poor LLM performance on tables. The researchers turn these into falsifiable hypotheses. “The classes overlap too much.” If th

Have you ever had this happen? You're chatting with a friend about buying a new pair of shoes. A few hours later... Instagram shows you an ad for those exact shoes. Or maybe you're talking about planning a trip. Suddenly...Your feed is filled with hotel deals, flight offers, and travel videos. The first thought that comes to almost everyone's mind is: "𝐌𝐲 𝐩𝐡𝐨𝐧𝐞 𝐢𝐬 𝐥𝐢𝐬𝐭𝐞𝐧𝐢𝐧𝐠 𝐭𝐨 𝐦𝐞." 👀 Honestly... I've thought the same. And maybe you have too. But what if I told you that the truth is actually more fascinating than the myth? So... is your phone secretly listening? Probably not. Not because it can't. But because it usually doesn't need to. Think about it. Every day you leave behind hundreds of tiny digital clues. 🔍 What you search. ❤️ What you like. ⏱️ How long you watch a video. 🛒 What you browse. 📍 Where you go. 👥 Even who you interact with online. Individually...They don't say much. Together...They tell a story that's surprisingly accurate. A story about your habits. The scary part? AI doesn't need to hear your conversations. Sometimes...It already knows what you're likely to do next. Not because it can read your mind. But because it's incredibly good at recognizing patterns. And when a prediction is accurate enough... It starts to feel like magic. Or surveillance. Here's what fascinates me the most. The real superpower of modern AI isn't listening. It's predicting. And sometimes...Those predictions are so good that they make us question reality itself. The next time you think, "My phone is definitely listening to me." Ask yourself a different question. "How much of my digital behavior have I already shared without realizing it?" Because maybe...The microphone isn't the real story. Your patterns are. 💬 Have you ever had an experience that made you think your phone was listening to you? What happened? Takeaway : Technology doesn't always become powerful by knowing more. Sometimes... It becomes powerful by predicting better. Technology becomes less magical when you und

Hay muchísimo escrito sobre qué tiene que reportar una organización: guías de Supersalud, de Supersociedades, de SAGRILAFT, de PTEE, de SST, de reportes ambientales. Todas contestan la misma pregunta — ¿qué me aplica? — y la contestan bien. Casi nadie escribe sobre la pregunta que de verdad hace fallar a las organizaciones: ¿cómo no perder ninguno, todos los años, cuando son treinta? Porque los incumplimientos que he visto de cerca casi nunca vienen de que alguien ignorara la obligación. Vienen de que la obligación se conocía perfectamente y aun así se pasó la fecha. Este artículo va del problema operativo —fechas, evidencia, responsables— no de cuáles normas le aplican a su entidad. Eso es otra conversación, y no es esta. Por qué el archivo de Excel deja de servir Con tres obligaciones, una hoja de cálculo sobra. El dolor no empieza por el número: empieza cuando el calendario hay que derivarlo . 1. Las fechas no son fechas, son reglas. Muchos vencimientos no están escritos como un día del calendario: dependen del último dígito del NIT, de días hábiles, o de un plazo contado desde un hecho. Eso significa que alguien recalcula el calendario entero cada año, a mano . Cada enero se reintroduce la misma oportunidad de equivocarse, y basta con un festivo mal contado. 2. El calendario vive en una persona. Casi siempre hay alguien que "sabe cómo es la cosa". Mientras esté, funciona. Cuando se va de vacaciones —o se va de la empresa— se va con ella el contexto que nunca estuvo escrito. La hoja sobrevive; el criterio para llenarla, no. 3. La hoja dice que se entregó, no lo prueba. La celda en verde es una afirmación de alguien. La evidencia real —el radicado, el archivo exacto que se subió, la hora— está en el correo de alguien. El día que hay que demostrarlo, empieza la arqueología en bandejas de entrada. 4. Los terceros que le reportan a usted. Si recibe información de contratistas, sedes o filiales, ahora administra dos problemas: sus propios vencimientos y los de ellos.

submitted by /u/f311a [link] [留言]