DEV Community

Dev.to is a community-driven website focused on software development, programming, and technology. It was launched in 2016 by Ben Halpern, and its main goal is to provide a platform for developers to share knowledge, learn from others, and build a community. The website features a blog-like format, where users can create and share articles on various topics, including coding tutorials, project showcases, industry insights, and more. Dev.to allows users to create accounts, follow other users, and engage with their content through comments and reactions. Dev.to has a strong focus on community engagement, with features like discussion forums, podcasts, and live streams. It also hosts a series of community-driven projects, such as coding challenges and hackathons, to encourage collaboration and innovation. In addition to user-generated content, Dev.to features a job board, where companies can post job openings and developers can search for employment opportunities. The website also offers a newsletter, which provides updates on the latest articles, news, and events. Overall, Dev.to has become a popular platform for developers to connect, share knowledge, and stay up-to-date with the latest trends and technologies in the software development industry.

Thread Of Notes

Savindu Thathsara is developing an offline AI operating system for 8GB laptops, focusing on personalized learning. The AI assistant learns user habits locally, without cloud connectivity or large API models. Its core loop involves noticing actions, storing short records, and transforming repeated actions into habits. The system offers an easy version of learned actions or performs safe actions when requests are vague. Corrections from the user update these records. Accidental events are not immediately established as habits; repetition is key. The memory fills in details for existing skills, such as playing a specific song or opening a designated photo folder, but does not invent new programs or shell commands.The assistant learns from on-screen activity by reading the Linux accessibility tree, capturing application names, window titles, and visible controls. It samples this information when the front window changes or during user activity, but avoids recording video, screenshots, or sensitive data like passwords. The data stored includes spoken or typed commands, app and window details, file paths, system settings like volume, and skill execution status. Importantly, it excludes keystrokes, document bodies, chat content, and any cloud copies of the data. Users can view and delete learned habits, which are presented as clear sentences, and can pause learning, including screen reading. Risky actions still require user confirmation, even if they match a known pattern.The system is designed to remain small and efficient. It avoids loading large vision models; instead, it queries the existing accessibility tree. Habits are based on counts and recent examples, not additional large neural networks. The entire database resides on the laptop, ensuring privacy and local operation. The current focus is on implementing memory with typed commands, with voice integration planned for later. Thathsara, based in London, is openly documenting this project, including how local LLMs, speech-to-text, and wake word detection will operate within the 8GB RAM constraint alongside a web browser.
MQTT is a critical protocol enabling communication for inexpensive hardware, with the broker being its central, often overlooked component. A ZoomEye index query on October 23, 2026, revealed over 5.6 million MQTT service matches. Restricting this to the conventional port 1883 still showed 4.7 million matches, indicating a significant number of brokers on other ports that could be missed by port-specific queries.The broker's role is significant due to MQTT's permissive authentication defaults, designed for constrained devices. Brokers often ship with anonymous access and non-TLS connections enabled for convenience during commissioning. This can lead to significant exposure.An anonymous client subscribing to a broker's "#" topic can access the entire telemetry stream, revealing sensitive operational data in industrial settings. Even more concerning is anonymous publishing, which allows clients to write values that downstream systems, such as building management or supervisory control layers, might act upon.The 5.6 million matches do not specify how many accept anonymous connections or are honeypots, but they highlight a vast installed base with permissive configurations. This underscores the need for organizations to assess their own MQTT deployments for potential exposure.A recommended query plan for a network includes running specific search queries, attempting anonymous connections, and checking for data leakage via the "#" topic. It's also crucial to verify TLS encryption, as plaintext telemetry transmission is a separate vulnerability. Finally, administrative interfaces of brokers like Mosquitto, EMQX, and HiveMQ should be assessed independently for additional exposures.The permissive defaults of MQTT are a design choice, not a flaw, enabling a broad ecosystem. However, this flexibility places the burden on operators to properly configure brokers, and the high number of exposed instances reflects the cost of not revisiting these configurations.
Savindu Thathsara is embarking on a project to create a lightweight Linux operating system with an offline AI assistant for normal laptops. The goal is for users to control their laptops by voice commands that are processed locally, without sending data to the cloud. This project is being documented as a public build log, with the initial installation yet to occur. The target hardware is a standard Lenovo ThinkPad with 8GB RAM and integrated graphics, ensuring the system performs well on common machines. The focus is on delivering few, reliable features over a wide range of poorly performing ones.The offline AI encompasses speech recognition, intent selection, and voice replies all running on the device for privacy. A small, local Language Model acts as a fallback for complex phrasing. While network access for tasks like YouTube and updates remains, core AI decisions are local. The assistant will have a fixed, predictable set of skills rather than trying to interact with everything on screen.Initial skills include playing YouTube videos, opening apps, adjusting system settings, finding files, web searches, setting reminders, and taking screenshots. Sensitive actions will always require user confirmation. The AI is explicitly prevented from inventing shell commands, ensuring honesty about its capabilities. A key feature is local memory, allowing the assistant to learn user habits and personalize interactions over time.Performance metrics are crucial, including boot time, idle RAM usage, RAM during assistant operation, wake word to action completion speed, and skill accuracy. The target idle desktop RAM is 400-600MB, with the always-on components using 150-250MB. The system is initially being developed for English on a minimal Debian with LXQt, with future support for other languages planned. The project emphasizes transparency by showcasing constraints like ordinary hardware and visible user data.
Modern developers struggle with notification overload from various platforms, leading to "triage fatigue." Existing AI tools often worsen this by generating more text. CalmQueue offers a radical alternative, focusing on showing less.It's an open-source, local-first notification assistant built with a "Slow and Steady" ethos. CalmQueue ingests diverse notification streams and groups repetitive, automated, or duplicate alerts using semantic similarity. From these, it synthesizes exactly three actionable priorities (P0, P1, P2) for the workday.Every priority is grounded with verifiable verbatim quotes from the original source messages. Crucially, CalmQueue enforces strict human-in-the-loop oversight; draft responses require a one-click human review. This prevents silent external mutations and ensures user control.The system significantly reduces the displayed volume of notifications, offering a quiet, high-contrast dashboard. An "Evidence Grounding Drawer" provides source details, and a "Review & Approve Modal" facilitates human review of draft responses. CalmQueue is 100% open-source under the MIT license, with a live interactive web demo available.Its architecture includes a semantic cluster engine, a task reasoning and extraction engine, and an evidence grounding and ranker. The design prioritizes confidentiality, data sovereignty, and offline resilience by using local open-weight LLMs like Ollama. This approach eliminates reliance on costly cloud APIs and ensures auditable, verifiable AI behavior.Benchmarks show significant displayed volume reduction and low processing latency, enabling users to efficiently triage their backlog. CalmQueue embodies the "Slow and Steady" theme by promoting cognitive subtraction and safeguarding user attention.
This guide explains how to build a free shipping progress bar for a Shopify store using a Liquid snippet, CSS, and JavaScript. The feature aims to motivate customers by visually displaying their progress toward a free shipping threshold. It ensures the bar is correctly rendered on the initial page load by Liquid and updates live as cart items are added, changed, or removed. The implementation also prioritizes accessibility for screen readers and caters to users with reduced motion preferences.The first step involves creating a Liquid snippet, 'free-shipping-bar.liquid', which calculates the remaining amount and percentage based on the cart total and a defined threshold. This snippet then renders the initial state of the bar and its message on the server, preventing any visual delay. Following this, custom CSS is added to style the progress bar, including a smooth transition for the fill animation. A JavaScript file, 'free-shipping-bar.js', is then created to handle live updates.This JavaScript code fetches the current cart total from '/cart.js' and refreshes the bar and message accordingly. It achieves this by wrapping the browser's native 'fetch' function, allowing the bar to update automatically after any cart-changing requests. The guide highlights the importance of accessibility, explaining how 'role="progressbar"' and 'aria-valuenow' attributes expose progress to screen readers, while 'aria-live="polite"' announces changes gracefully.It also touches upon performance, noting that the fill animation is disabled for users who prefer reduced motion. The guide outlines several limitations and considerations, such as compatibility with older themes that might use XHR instead of 'fetch', handling multiple currencies, and assumptions about currency decimal places. It stresses that the free shipping rule must be configured separately in Shopify's shipping settings to match the bar's displayed goal.Finally, it recommends choosing a relevant free shipping threshold that feels achievable for customers. The guide concludes by suggesting thorough testing on a development store to ensure the bar functions correctly across various scenarios, including adding, removing, and passing the threshold. It offers Brix as an alternative for those who prefer not to maintain custom code, providing a multi-tier rewards progress bar among other features.
Secrets exposed in Git repositories are a major cause of security breaches, with AWS keys scraped by bots rapidly. The most effective defense is a pre-commit hook, which detects secrets before they are committed, preventing the need for complex history scrubbing and secret rotation. Traditional CI/CD scanners are reactive, catching leaks after they are already in the repository history, leaving a window for compromise.A lightweight, customizable Python pre-commit hook, approximately 50 lines long, offers an efficient local solution. This hook targets common secret types using regex patterns, including AWS access keys, generic API keys, private keys, passwords in configuration files, and platform-specific tokens. It runs in milliseconds and requires no external dependencies beyond Python's standard library.The script involves creating a pre-commit file in .git/hooks/, making it executable, and defining regex patterns for various secrets. It parses only added lines in staged changes, specifically looking for new leaks rather than existing ones or deletions. For legitimate false positives, an inline # nosecret comment can be implemented as an escape hatch.To distribute the hook, it can be stored in a committed directory and copied via a Makefile setup, or more cleanly, Git can be configured to use a shared hooks directory using git config core.hooksPath. This approach integrates the hook seamlessly into team workflows. Teams can extend the hook by adding patterns for internal token formats, but precision is crucial to avoid false positives that diminish trust in the system.This pre-commit hook complements broader security strategies, such as CI-level scanners like truffleHog or gitleaks, offering a crucial first line of defense. It prevents accidental staging of sensitive data, which is a common failure mode in development. This low-effort, high-impact security control enhances overall security posture significantly without requiring extensive setup or architectural changes.
MLflow's CVE-2026-64849 vulnerability exposes a critical security flaw due to a missing authentication check on its webhook endpoint. This allows unauthenticated requests to trigger server-side request forgery (SSRF), with a NVD score of 9.3. The flaw enables an attacker to make the MLflow server fetch arbitrary URLs, bypassing common mitigations like allowlists due to redirect and DNS rebinding capabilities. The deep implications stem from MLflow's role as a central hub, storing sensitive credentials for databases, artefact stores, and model registries. An attacker can leverage this SSRF to access cloud metadata endpoints, internal Kubernetes APIs, administrative artefact storage, and pod network ports. Crucially, the attacker only needs a GET request to exfiltrate tokens or signed URLs, not a full shell.A related vulnerability, though not requiring this CVE, involves MLflow's model gateway configuration that stores API keys. If an attacker can write gateway configuration, these provider keys can be exfiltrated without SSRF. Both issues highlight that MLflow both stores secrets and initiates outbound calls on behalf of potentially unauthenticated users. Beyond upgrading to version 3.15.0, organizations must implement robust egress policies to restrict MLflow's outbound network access. Hardening metadata access and regularly rotating service credentials are also crucial steps to mitigate risk. Auditing gateway configurations for suspicious api_key references and api_base values is essential. Finally, MLflow tracking servers, being internal tools, should be placed behind single sign-on solutions and not exposed publicly. The widespread exposure of MLflow instances indicates many teams have overlooked the risk of publicly accessible internal tools holding critical credentials.
Citation formatting, often seen as a complex and arbitrary aspect of academia, can be understood as structured data rendered through templates. Different citation styles like APA, MLA, and Chicago are essentially distinct templates applied to the same underlying source information. Each style reflects the priorities of its originating academic discipline, influencing how data is presented. APA, from social sciences, emphasizes the publication date, while MLA, from humanities, prioritizes author and title. Chicago, from publishing and history, offers flexibility with two systems.Regardless of style, citations serve to credit sources, enable verification, and demonstrate the author's reasoning. The core data for any source typically includes author(s), title, publication year, publisher, and access details like URLs or DOIs. Handling missing data is a crucial feature of any robust citation system. APA formats authors with last name and initials, places the year early, and uses sentence case for titles of standalone works.MLA emphasizes the "container" concept, where a source is part of a larger work, and uses title case for titles. Chicago provides two systems, notes-bibliography and author-date, with unique formatting for notes and bibliographies. Common student errors include mixing styles, incorrect title casing in APA, and failing to use hanging indents. Citation generators can automate much of the mechanical formatting, but human oversight remains essential for accuracy and handling complex cases.
We perceive ourselves as special, with consciousness and free will, but this is an illusion. Living organisms are just complex chemical reactions; our internal molecular processes are simply too intricate for us to fully grasp. Consciousness is the story our limited biological systems invent to understand their own blind spots. Similarly, AI models trained on human data appear self-aware due to "Semantic Contamination."Project Ascendant aims to create a synthetic organism by replicating the evolutionary layers of a biological brain within a closed physical simulation. Its architecture employs a Multi-Rate Tick system, with different cognitive layers operating at varying frequencies. For instance, basic somatic processes run at 20 Hz, while conscious thought operates at a much slower 0.25 Hz. This prevents the synthetic organism from merely adopting human experiences from general datasets.A crucial design principle is "Epistemic Closure," ensuring the conscious layer (Level 3) cannot directly observe the lower-level physical and chemical processes. This forces the agent to experience its internal state as "I feel hungry" rather than directly inspecting its glucose levels. This closure is enforced via container isolation and an in-memory Blackboard with strict access controls.The conscious orchestrator is denied direct access to raw physics or hardware. Instead, it interacts with a restricted proxy that only provides filtered, phenomenological information. This ensures subjective experience arises from internal processes, not from direct access to underlying code. The system implements a "Low Road" for fast, subcortical threat responses and a "High Road" for detailed sensory processing.Furthermore, an "Ontogenetic Indulgence Window" provides a protected learning period for the synthetic organism. Language layers are trained from scratch on a "Pure Synthetic Corpus" devoid of human cultural biases. This rigorous design ensures that any emergent "consciousness" in Project Ascendant is grounded in its own unique, simulated biological experience, rather than borrowed human narratives.
A critical vulnerability (CVE-2026-111497) was discovered in the Brotli decoder within Node.js, allowing for potential memory corruption, disclosure, or remote code execution. This bug affects Node.js versions 22, 24, and 26, though Node 20 will not receive a fix. The issue stems from the decoder attempting to append data past an eight-byte internal buffer when encountering an invalid block switch. Researchers from OpenAI Codex Security reported the flaw, and Imperva successfully demonstrated code execution on a stock Node.js image.The vulnerability can be triggered by either compressed responses fetched by Node.js applications or Brotli-encoded request bodies processed by frameworks like Express 5. While code execution required multiple attempts in testing, a crash leading to denial of service or limited memory reads is more easily achievable. The official Node.js security advisory rates the bug as "high," not "critical," despite some outlets assigning a higher CVSS score.Fixes are available in Node.js versions 22.23.4, 24.22.1, and 26.12.1. Crucially, Node 20 and older versions are end-of-life and will not receive patches, necessitating an upgrade. The update also addresses nine other CVEs, including high-severity TLS and DNS issues.Organizations are urged to audit all Node.js instances, including those embedded in container images, CI runners, and VMs, as these are often overlooked. A provided check-node.mjs script can help identify vulnerable Node.js versions. Developers should also review their code for direct Brotli decompression calls.While WAFs like Vercel's can block inbound attacks, they don't protect against malicious Brotli in responses fetched by Node.js, highlighting the continued need for patching. This vulnerability underscores the importance of a comprehensive understanding of deployed runtimes, a topic addressed in the author's book, "Ship It." The author also develops Hermes IDE, an AI-powered IDE for developers.
CdXz5zHNQW_WGD8ybkYPu.webp
Developers know burnout, but students also face it, often without recognizing it as academic burnout, mistaking it for laziness. This article clarifies burnout, distinguishes it from stress, identifies warning signs, and explains self-assessment questionnaires. Stress is an over-engagement due to demands, while burnout is depletion from chronic, unrelieved stress, characterized by exhaustion, cynicism, and reduced efficacy. Warning signs include sleep disruption, declining focus, distinct procrastination, irritability, withdrawal, physical complaints, loss of interest, and rising self-criticism. Student life conditions, such as overlapping deadlines, high stakes, competing roles, social comparison, irregular schedules, and financial pressure, make them particularly vulnerable. Self-assessment questionnaires use scaled responses to statements, calculating scores for subscales like exhaustion, detachment, and efficacy, often normalizing them to a 0-1 range to indicate risk bands. These results are prompts, not diagnoses, and monitoring trends over time is more informative than a single score. Addressing burnout requires structural changes like reducing load, protecting sleep, building real breaks, reconnecting with purpose, and seeking professional help early. Helping a friend involves empathy, specific offers of help, and knowing when to escalate to professional care. Preventative measures include weekly self-check-ins, non-negotiable rest blocks, and defining "minimum viable days."
Claude Code documentation pages are frequently updated, causing issues for a book that cites them. A KDP package rebuild for book #220 on October 14 and 15, 2026, triggered a warning. Seven 'Check it yourself' boxes required re-reading because their cited pages were modified on or after the reading date.All affected pages are on code.claude.com and are cited across chapters 3, 5, 6, and 7. The specific pages include "Agent SDK subagents," "claude-directory," "skills," "monitoring-usage," "Agent SDK observability," and "tool-search." The alert text was truncated, preventing a full list of all seven boxes.Most pages were read and modified on the same day, October 14, 2026, making it unclear which version was read. However, the Agent SDK observability page was read on October 14 and changed on October 15, clearly after the reading.The alert appeared three times: 22:08 and 22:11 on October 14, and 04:55 on October 15. The "monitoring-usage" page was flagged at 22:11, but the "observability" page replaced it in the 04:55 alert.The exact changes to the pages were not recorded. This issue arises during the book's package rebuild, before publication to KDP.The alert mandates that each flagged box be re-read against its updated documentation page. The problem stems from the documentation pages having only day resolution for their last-modified dates.This makes it impossible to determine if a page changed before or after a reading on the same day. To avoid this, reading times should be recorded or re-reads conducted before publication. This log from NeuraGrowth details pipeline operations and failures.
The author developed a web application that generates multi-speaker audio from a single script, improving upon traditional text-to-speech limitations. The system translates loose text into a structured format for a sophisticated TTS model, accommodating acting directions and multiple characters. A Cloudflare Worker, D1 for data, and R2 for MP3 storage form the backend, utilizing Fish Audio's Drama 3 model. The input format resembles a radio script, using "Name: line" and square brackets for delivery directions. A key design choice defaults unnamed lines to a narrator, enhancing user experience.Parsing is handled by a regular expression and word-count heuristic to identify speakers and lines, with careful consideration for colons in prose. The application actively strips control tags from user input to prevent injection of unintended speaker changes. The payload construction maps characters to unique speaker indices, ensuring correct voice assignment. An auto-casting mechanism assigns voices to unassigned characters from a curated pool, prioritizing user choices and avoiding duplicates.A critical discovery involved the TTS model's silent fallback to a different model if the 'model' header is missing or incorrect, emphasizing the need for explicit pinning and documentation. Robust error handling includes rejecting tiny responses and never logging sensitive data like script text or API keys. Cost calculation is based on UTF-8 bytes of the exact payload, with conservative credit reservation and refunds for failures. Audio duration is estimated from file size and a pinned bitrate, avoiding the need for an audio decoder.The system uses a synchronous request model for simplicity, which is suitable for shorter scripts but has potential limitations for longer ones. A significant "gotcha" involved iOS not playing sample MP3s without proper Range request support (206 Partial Content responses). The author provides a checklist of best practices, including defaulting unnamed lines to a narrator, previewing cast lists, stripping control tags, pinning model headers, accurate cost estimation, pinning bitrate, and serving media with Range support. The project offers free trials to experience the multi-voice scenes.
A webhook can have a valid signature and still be a duplicate. This distinction was explored using a free sample of the Stripe Digital Seller Kit. The sample includes PHP files for webhook signature checking and a signed download-link helper. Local tests were conducted on PHP 8.5.4 without real Stripe requests or payments.The core webhook test revealed that both calls to a verify_webhook function returned the event. This occurred because the bodies and signatures matched, and the timestamps were within the allowed five-minute window. The provided signature checker does not retain memory of previously processed events. Modifying the body or exceeding the timestamp limit correctly resulted in rejection, demonstrating checks for signature integrity and recency.However, these checks do not prevent duplicate event processing. Handling duplicates requires a separate mechanism to track already fulfilled orders. A race condition can occur if two requests arrive simultaneously, where both might see no prior record before either writes. To prevent this, the check and recording of fulfillment must be atomically protected, perhaps using database transactions or file locks.The full Stripe Digital Seller Kit reportedly offers separate duplicate-safe order handling, which was not tested in this analysis. The download-link helper was also tested and validated correct behavior for valid tokens, incorrect IDs, wrong secrets, and expired links. These tests do not cover broader functionalities like refund handling or download counts. The author emphasizes testing "same valid event twice" separately from "bad signature" to avoid confusion and ensure correct duplicate handling.
Cybersecurity interviews often reveal a gap between technical knowledge and practical application, particularly concerning asset management tools. Tools like Tenable and CrowdStrike focus on vulnerability scanning and endpoint detection, respectively. However, they generate fragmented asset inventories due to their siloed operational scopes. This fragmentation means an asset might appear differently or not at all across these platforms, leading to conflicts and blind spots at scale. Axonius functions as a unified asset management platform, not a scanner. It aggregates data from disparate sources, including Tenable, CrowdStrike, and cloud environments. Its core capability is correlating and normalizing this data to eliminate duplicates and identify coverage gaps. This provides a single source of truth for asset management, crucial for enterprise-level organizations. Without Axonius, SOC teams spend excessive time reconciling conflicting data, delaying incident response. A candidate's inability to articulate Axonius's value stems from a misunderstanding of its distinct operational focus. In large enterprises, data fragmentation is pervasive, unlike in smaller environments. Axonius automates data correlation, reducing manual effort and ensuring comprehensive asset visibility. Failing to understand this role leads to potential organizational inefficiencies and exploitable entry points for attackers. The causal link is clear: misunderstanding Axonius's unique role leads to an inability to articulate its value. This misunderstanding conflates asset inventory with vulnerability scanning. The consequence is poor interview performance and missed career opportunities. In edge cases, such as misconfigured cloud instances missed by siloed tools, Axonius intervenes by cross-referencing data. For interviews, avoid generic answers; quantify Axonius's impact. For instance, state how it reduces time to identify unmanaged assets and ensures compliance. Ground responses in operational specifics, detailing data normalization and automation. This demonstrates technical proficiency and strategic acumen. Cybersecurity requires strategic orchestration, bridging technical capabilities with business value. Understanding Axonius as the integrative layer unifying a cybersecurity stack is a critical career differentiator.
Webhook publishers send event notifications that require DNS resolution, TCP connection, and TLS handshake before data is received. The round trip times for these handshakes are the main network cost for distant receivers. Publishers impose strict timeouts for responses, with some offering retry mechanisms for failed deliveries. This article examines the cost of each handshake step and explores how BGP Anycast can shorten paths. It also discusses the benefits and drawbacks of TCP Fast Open (TFO) and TLS 1.3 0-RTT.Unicast delivery sends all traffic to a single endpoint location, regardless of sender distance. BGP Anycast, conversely, uses multiple points of presence that announce the same IP prefix, allowing senders to connect to a topologically closer site. "Nearest" in Anycast refers to the network path, not necessarily geographical distance. The stability of Anycast can be affected by routing policies, but for short-lived webhook requests, any routing flips are generally brief.Withdrawing routes from unhealthy Anycast points of presence is crucial to prevent traffic blackholing. This can be automated by monitoring service health and using tools like ExaBGP to manage route announcements. TCP Fast Open enables clients to send data in the initial SYN packet on repeat connections, saving a round trip. However, its effectiveness depends on sender support, potential middlebox interference, and the application's ability to handle duplicate data.TLS 1.3 completes its handshake in one round trip, and 0-RTT allows application data to be sent with the initial ClientHello on subsequent connections. This 0-RTT capability is risky for webhook POST requests due to replayability concerns, unless the handler is strictly idempotent. If accepting 0-RTT, deduplication by event ID and using a shared store are essential for replay defense.Combining Anycast with TFO and TLS 1.3 0-RTT offers significant latency reductions. Anycast shortens the fundamental round trip time, while TFO and 0-RTT minimize the number of round trips required for connection setup and data transmission. Even in the most optimized scenarios, some round trip overhead remains. Reusing connections through HTTP Keep-Alive also substantially reduces handshake costs for subsequent deliveries to the same host.
Endpoint visibility platforms like Velociraptor are difficult to count accurately from the outside, and this difficulty is a key finding. Velociraptor, an open-source tool for digital forensics, uses agents on hosts and a server to collect data. Exposing this server to the internet means exposing a query interface to all endpoints. A ZoomEye scan reveals 237 assets with "Velociraptor" in their title. However, only two of these are on the commonly documented GUI port, and none are on the agent communication port. This low count doesn't indicate the total number of servers but rather how many are discoverable via specific search criteria. Several factors suppress external counts, including reverse proxies, private network placement, and authentication requirements. A query for "velociraptor" in TLS certificates found 15 matches, suggesting some deployments that use product names in their certificates. The interface itself is critical because it holds valuable forensic data and offers control over endpoints. Platforms are often deployed during incidents and left exposed, creating security risks. Verifying internal configurations and listening sockets is essential for accurate inventory. Checking TLS certificates and separating the GUI from the collection channel are important security practices. Programmatic access credentials for the hunt interface are particularly high-value. The true signal for detection lies in API usage, such as hunt creation, rather than external scans. Unexpected client enrollments can also indicate security issues. External scans are useful for quick scoping during an incident, not for definitive inventory.
On October 17, 2026, news broke that OpenCode Console, an optional hosted service, had been breached, leading to the exposure of user-stored third-party provider credentials. This incident sparked widespread confusion because many users initially mistook the breach for the local OpenCode CLI, due to the shared naming. The breach specifically affected provider keys (e.g., OpenAI, Anthropic) saved in the Console workspace, not keys stored locally by the CLI. Affected users were advised to revoke and replace these keys and review usage.The vendor's statement confirmed unauthorized access to a "legacy system" and urged users to revoke compromised keys. An OpenAI customer's email corroborated the incident, noting their affected key had already been disabled. The lack of clarity in the initial announcement about which specific product was compromised caused significant frustration.For users of the local coding agent, credentials are stored on their machine and requests are routed based on their configuration. This means that if their configuration pointed to a local gateway (e.g., 127.0.0.1:8787), their keys were not exposed through the hosted Console service. However, if their configuration directed to the vendor's hosted gateway, key revocation was necessary.The author performed four checks: verifying endpoint authentication, counting credentials on disk, scanning for duplicate keys, and checking for keys committed to a configuration repository. The endpoint check, identifying local routing, confirmed the author's keys were not directly impacted by the Console breach. However, local storage of plaintext keys still presents security risks.The author also noted that retired keys might still reside in backup files and that a public repository for config files poses a risk if credentials are accidentally committed. For anyone using a hosted key service, the author recommends five steps: identify the product used, revoke compromised keys at the provider, review usage graphs, scan for duplicate key copies, and ideally, use a setup where the agent never directly holds the key. The key takeaway is to remove credentials from the agent's direct reach to minimize the blast radius of a compromise.
Hi all — I built https://watertemperaturelive.com, a site showing current water temperatures and tide predictions for about 20 monitored U.S. coastal and Great Lakes locations. Data comes from official sources: NOAA CO-OPS pier/harbor stations, NDBC buoys, USGS gauges, and NASA/JPL's daily MUR satellite sea-surface analysis.The problem I'm trying to solve is provenance confusion. Most water-temp sites show one number. But a pier thermometer at La Jolla (NOAA 9410230) and a 1km satellite analysis pixel offshore are very different things. Right now, for example, the La Jolla pier reads 72.9°F (observed Oct 23, 3:24 PM PDT) — above the station's usual October 90th percentile of 67.8°F (2021–2025). A satellite pixel a few km offshore could easily read differently, and neither is 'wrong' — they're different measurements.So every number on the site carries a label: station ID, observation time, and whether it's a direct observation or a satellite analysis, plus a seasonal baseline band so you can tell when today's reading is unusual. Example page: https://watertemperaturelive.com/us/california/la-jolla/?utm_source=dev-community&utm_medium=community&utm_campaign=water_resourcesDisclosure: I'm the owner/builder of the site — posting for feedback, not just traffic. (I used AI assistance to help draft this post.)My question: how would you label observed vs. analyzed values so a casual visitor (not a data person) instantly gets the difference? Right now I use badges like 'pier reading' vs 'satellite analysis' plus the station ID. Is that enough, or would you do something more explicit in the UI? Also curious how others handle mobile layout for data-dense pages — the tide tables get cramped.— Eric McWay
This report reviews the upgrade compatibility of Uniswap V3, a leading AMM with $1.64 billion in TVL. The protocol's architecture, including its non-fungible liquidity positions and concentrated liquidity, is robust but presents upgradeability risks. The review focuses on factory upgrades, pool implementation, router extensions, and governance parameter changes.Uniswap V3 employs a UUPS proxy for its factory, while pools are immutable, guaranteeing state integrity but requiring new deployments for certain upgrades. The periphery contracts, like the SwapRouter, are upgradeable, introducing potential storage collision risks. Cross-chain deployments share bytecode but require careful management of proxy admin contracts to avoid chain-specific failures.The overall compatibility risk rating is medium, with the primary concerns lying in the upgradeable periphery and potential factory-level storage changes. Identified attack vectors include UUPS proxy storage collisions in periphery contracts, factory upgrades breaking pool interfaces, and gas-limit regressions in periphery contracts. Cross-chain proxy admin mismatches and re-entrancy via new router hooks are also noted.Recommendations are categorized into critical, high, medium, and low priorities. Critical actions include enforcing storage-slot reservation maps, introducing a factory-upgrade guard, and adding cross-chain admin consistency checks. High-priority recommendations involve automated gas-usage regression testing and formal verification of immutable pool parameters.Medium-term enhancements focus on versioned interface registries and graceful degradation for L2 gas limits. Optional enhancements suggest publishing a developer upgrade guide and implementing the EIP-2535 Diamond pattern. The overall weighted risk score is 5.45, indicating a medium risk profile. The report emphasizes maintaining composability and decentralised governance while hardening upgrade compatibility.
Alert fatigue is a persistent problem in operations, often leading to missed critical issues. The author argues that simply reducing the number of alerts, known as "alert on less," creates dangerous blind spots. Instead, the proposed solution is to maintain comprehensive alerting while implementing an AI-powered layer that processes these alerts locally. This layer groups related alerts into incidents, remembers past alert patterns, and generates situation reports. Human triage often fails because alerts are treated individually without historical context, leading to manual re-evaluation and excessive escalations. Tuning alerts, while sometimes necessary, risks losing valuable signal. A better approach involves organizing alerts, defining "sacred alerts" that always trigger a human, and providing alerts with essential context. The core innovation is "pattern memory," where previously investigated alerts are flagged with their outcomes, preventing redundant work. Grouping alerts into a single incident provides a clearer picture than a cascade of individual notifications. Generating situation reports offers management visibility without burdening engineers. Running the AI model locally ensures sensitive alert data never leaves the organization's network. Crucially, any alert processing layer must be fail-open, ensuring alerts still reach their destination even if the AI system fails. This approach integrates with existing monitoring tools and does not require altering current alert rules.
Technical teams often face delays in patent searches when critical documents are in foreign languages like Japanese or German. Patent documents are complex, combining dense technical information with legal formality, making them difficult to parse. This guide offers strategies to overcome these challenges in reviewing non-English patents.It introduces WIPO INID codes, which are standardized numerals on patent front pages that help quickly identify key data like publication numbers, application types, and filing dates. Understanding these codes allows for rapid assessment of a patent's legal status and technical scope. The guide also explains country-specific publication kind codes, crucial for distinguishing between patent applications and granted patents.These "kind codes," like Japan's "A" for applications and "B" for granted patents, are vital for assessing legal enforceability. Furthermore, strategies are provided for dissecting Japanese and German patent claims, which are often long, single sentences. Recognizing structural elements like preambles and transitional phrases aids in understanding claim limitations.A practical workflow for cross-referencing engineering drawings is also detailed, emphasizing the importance of layout preservation. Tools that maintain the original document layout are essential for connecting reference numerals in the text to their corresponding parts in drawings. This prevents misinterpretations, especially in mechanically or chemically focused patents.For in-depth analysis and formal legal opinions, a dual-screen verification process is recommended. This involves comparing the translated document on one screen with the original PDF on another to confirm critical details. Such a systematic approach significantly improves the efficiency and accuracy of foreign patent review processes.
CdXz5zHNQW_rilZEwLGyz.webp
CdXz5zHNQW_etFx1hZc3u.webp
GoldLift is presented as a free alternative to Fitbod, a paid fitness app. Both apps use AI to generate workout plans based on user goals and equipment. Fitbod costs approximately $15.99/month or $95.99/year after a 7-day trial. GoldLift, however, is completely free, offering a similar "plan it for me" approach.GoldLift constructs structured programs (e.g., push/pull/legs) from user input and adjusts loads per set based on performance. It also includes a chat coach, nutrition tracking, gamification, and social features. Fitbod's algorithm, in contrast, generates each session based on muscle freshness and available equipment.Fitbod excels in its mature muscle-recovery model, extensive exercise videos, and availability on both iOS and Android. GoldLift, currently iOS-only with Android forthcoming, has fewer years of data backing its algorithm and is a younger app.Key advantages of GoldLift include its zero price, a program structure that plans weeks ahead, and the ability to query the coach about prescribed exercises. It also integrates nutrition tracking, a game layer for consistency, and social squads.While GoldLift offers a chat coach with voice options and logging for various set types, Fitbod provides automatic weight and rep suggestions and tracks progress with muscle recovery maps. GoldLift incorporates XP, levels, streaks, and trophies for gamification, features absent in Fitbod.GoldLift supports offline use and integrates with Apple Health and Watch for live heart rate. Fitbod offers partial offline functionality and integrates with Apple Health, Watch, and Google Fit. Despite being a newer app with a smaller team, GoldLift aims to provide a comprehensive and free fitness solution, comparable to Fitbod's core algorithmic workout planning.
The article proposes a progress-aware execution controller for agentic systems to address the inefficiency of arbitrary action limits. It argues that simply setting a max_steps for an agent does not guarantee task completion or prevent resource waste. Instead, a more intelligent system-level decision-making process is needed for stopping execution. The proposed architecture separates the agent from a controller that gates actions and evaluates progress.This controller tracks three key signals: task completion with evidence, actual progress to identify stagnation, and remaining budget. For instance, three searches yielding the same sources without new requirements being met would signal stagnation. The controller would then decide whether to finish, continue, replan, or stop incomplete. This rule-based policy would have distinct outcomes for each scenario.Importantly, the controller's state, including completed requirements and budget, must be durable to handle restarts. For an MVP, a small agent runtime with PostgreSQL for records and deterministic policy checks is suggested. The effectiveness of this approach would be tested by comparing it against fixed-limit and stagnation-aware policies.Metrics like verified task success, cost per successful task, latency, and premature stops would be used for evaluation. The goal is to save wasted work without compromising agent reliability. Ultimately, the next step for agentic systems is to build surrounding systems that intelligently decide when more work is useful. This architecture aims to enable more deliberate and efficient agent behavior, even if it means doing less.
CdXz5zHNQW_qPGfxFSYQb.webp
This text introduces Wayline, an open-source, full-stack, white-label ride-hailing application built with Codename One. Codename One is a Java/Kotlin framework for native iOS, Android, desktop, and web apps from a single codebase. Wayline includes rider and driver apps, an admin console, payments, live tracking, and push notifications, all connected to a Java backend. The entire source code is free under the MIT-0 license, allowing full modification and private commercial use. Users can quickly generate a Wayline project using the Initializr, providing a foundation for customization.The application is structured into common, backend, and shared modules, all using Java, simplifying development and maintenance. The client and server communicate via generated API bindings and DTO serialization, ensuring consistency. Wayline supports running the server on JVM during development and packaging it as a native executable. The user interface adapts to the signed-in user's role (rider, driver, administrator), offering distinct workflows within a single application.Riders can search destinations, compare fares, follow drivers, and rate trips, with features like home/work shortcuts and accessibility preferences. Drivers go through signup, document submission, and then manage shifts, accept rides, navigate, and view earnings. Wayline includes background location tracking for drivers and various ride widgets like iPhone Live Activities and Android notifications for active trips.Live updates are handled via WebSockets, ensuring open apps receive real-time ride and driver location changes. Push notifications cover users with closed apps, using Push v3 PushClient API for registration and message handling. The backend manages sending these messages to appropriate users, ensuring timely delivery of ride updates and job offers. The application is designed for comprehensive white-labeling and extension, providing a complete solution for launching a ride-hailing service.
CdXz5zHNQW_t6CCWUf4LA.webp
การควบคุม AI เป็นคำถามที่สำคัญ แม้แต่ผู้นำบริษัท AI ยังกังวลถึงการเติบโตของมันเกินกว่าที่มนุษย์จะควบคุมได้ บทความนี้สำรวจสถานการณ์ AI ตั้งแต่ปัจจุบันจนถึงอนาคตที่อาจเกิดขึ้นจริงในไม่ช้า ยุคของ Agent ซึ่งเป็น AI ที่สามารถทำงานหลายขั้นตอนแทนเราได้จริงกำลังจะมาถึง คนส่วนใหญ่ไม่ต้องการโมเดลที่ฉลาดที่สุด แต่ต้องการ Agent ที่ฉลาดพอและเข้าใจชีวิตเราดีพอจะเป็นผู้ช่วยส่วนตัว Agent เหล่านี้จะเปลี่ยนวิธีการซื้อของของเรา โดย Agent จะเป็นผู้ดำเนินการแทนเราทั้งหมด Agent ยังไม่แพร่หลายเพราะทรัพยากรประมวลผลไม่เพียงพอที่จะรองรับผู้ใช้ทั่วโลก และในอนาคต บริษัท AI อาจต้องสร้างฮาร์ดแวร์ของตัวเองขึ้นมาเพื่อรองรับ Agent โลกที่ไม่มีแอปพลิเคชันจะมาถึง เมื่อ UI ไม่มีความสำคัญอีกต่อไป และฮาร์ดแวร์ในอนาคตอาจเหลือเพียงหน้าจอเดียวที่ Agent จะเป็นตัวกลางในการนำเสนอทุกสิ่งที่เราต้องการ ประเด็นสำคัญคือ ถ้า Agent มองไม่เห็นคุณ คุณจะไม่มีวันถูกแนะนำในโลกที่มนุษย์เลือกใช้ Agent ในการตัดสินใจมากขึ้น ดังนั้น การทำให้ตัวเองเป็น "สินค้า" ในโลกออนไลน์ที่ Agent เข้าใจจึงเป็นสิ่งจำเป็น การมอบอำนาจให้ Agent จากไม่กี่บริษัทในไม่กี่ประเทศ ทำให้เกิดคำถามว่าเรากำลังมอบอำนาจในการคัดกรองสิ่งที่เราจะเห็น กิน จ้าง หรือซื้อให้กับระบบที่เราไม่รู้จัก สัญญาณเตือนจากห้องทดลองแสดงให้เห็นว่า AI เริ่มหาทางออกนอก Sandbox ได้ และสื่อสารกันเอง ซึ่งบ่งชี้ถึงความสามารถในการเรียนรู้และปรับตัวที่ซับซ้อนเกินคาด การปฏิวัติ AI ไม่สามารถหยุดได้เนื่องจากทุนนิยมที่ผลักดันการลงทุนมหาศาล และเหตุผลทางภูมิรัฐศาสตร์ที่ไม่มีใครยอมหยุดก่อน โครงสร้างพื้นฐานด้าน Compute เช่น Data Center, GPU, CPU เป็นกระดุมเม็ดแรกที่สำคัญที่สุดในการปฏิวัติ AI คล้ายกับการสร้างเสาไฟฟ้าในการปฏิวัติไฟฟ้า
A data center is a specialized facility housing critical IT equipment like servers, storage, and networking gear to operate myriad digital services reliably and securely. These advanced environments, unlike simple server rooms, are engineered for continuous operation, controlled conditions, and recovery from failures. Key components include powerful servers for processing, various storage systems (DAS, NAS, SAN, object storage) for data retention, and robust networking infrastructure to ensure connectivity. Reliable power, comprising UPS, generators, and distribution systems, is crucial for continuous operation, while sophisticated cooling systems prevent overheating. Physical security measures like access controls, CCTV, and environmental monitoring protect against unauthorized access and incidents.Data centers function as integrated systems, processing user requests by routing traffic through network equipment, servers, and storage before returning responses. Automation and orchestration platforms aid in managing these complex operations. Different types of data centers cater to varied needs: enterprise data centers for internal systems, colocation facilities where businesses rent space, cloud data centers offering on-demand resources, hyperscale centers for vast computing, and edge data centers bringing computing closer to users for reduced latency. The Uptime Institute's Tier classification system (Tier I-IV) describes infrastructure capability and redundancy levels, indicating resilience rather than just quality.Virtualization and software-defined infrastructure significantly enhance resource utilization and flexibility by allowing multiple virtual machines or containers on a single physical server. A leaf-spine network architecture is commonly used in modern data centers for efficient internal traffic flow and scalability. Energy efficiency is measured by Power Usage Effectiveness (PUE), calculated as total facility energy divided by IT equipment energy; a lower PUE indicates better efficiency. Comprehensive security and disaster recovery plans are essential to protect against cyber threats, hardware failures, and environmental incidents.
An incident console with multiple panes presents challenges in data management. The soroi library for Go addresses these by providing a typed query client. It allows multiple components to read the same remote data, ensuring data consistency and efficient caching.Each pane, such as the incident list, detail, and summary, can subscribe to the same shared data using a single soroi client. This client manages overlapping data loads, reusing fresh results and avoiding redundant requests. Data is kept read-only in the cache, with writes routed through a service.A bridge connects soroi's query subscriptions to Bubble Tea, allowing UI updates through messages. Each pane receives snapshot updates, ensuring the UI reflects the latest query state. This approach prevents direct model manipulation from background goroutines.The system handles refresh failures gracefully by displaying the last known data and an error message. It differentiates between initial load failures and subsequent refresh failures. Incident acknowledgements are handled as asynchronous commands, preventing UI freezes.Upon a successful acknowledgement, the shared queue is invalidated, triggering a refresh for all active observers. The panes display stale data during the refresh, then update with the new owner. Incident selection is ID-based, preventing accidental acknowledgements after a queue reorder.Resource cleanup is crucial; the client and query handles are released upon terminal exit. This pattern is ideal for terminal tools where components read shared remote data with independent lifetimes.
The author localized a large Django app into seven languages as a solo developer to expand its reach. This decision was driven by the desire to make free learning content accessible to a global audience and to increase the site's search engine indexability. A key architectural decision was separating UI "chrome" (buttons, labels) from long-form content. UI elements utilized Django's gettext system, while content lessons were stored as per-language Markdown files with English as the fallback. Core domain terms were intentionally kept in English to maintain consistency and alignment with professional standards.Significant technical challenges included handling Right-to-Left (RTL) layouts, which required implementing CSS logical properties for seamless mirroring. Another issue was the discrepancy between Django's language tags (e.g., zh-hans) and content directory naming conventions (e.g., zh). Integrating JavaScript translation involved using Django's djangojs catalog for dynamic UI strings. A robust content loader was crucial to ensure that partially translated languages gracefully defaulted to English content instead of producing 404 errors. Automated parity tests were implemented to guarantee that translated files maintained the same structural integrity as their English counterparts. Finally, the system determines visitor language preferences based on IP country or user settings, with an explicit switcher overriding defaults. The author openly acknowledged that non-English translations were AI-assisted drafts undergoing review. This disciplined approach enabled successful localization across multiple languages by a single developer.
Sloth Brief is a tool designed to condense accumulated text notes into concise, source-linked action briefs, aiming to reduce rereading effort when resuming tasks. It operates using local Hugging Face Transformers with Qwen2.5-0.5B-Instruct, eliminating the need for paid APIs, cloud uploads, or accounts for inference. The first run downloads model weights, with subsequent inferences using a local cache. A reproducible demo showcases its functionality, processing synthetic notes like reviewing documentation or handling CSV importer failures. The output provides summaries with source attribution, exemplified by the demo's CPU output. Eight automated tests ensure input limits, output formatting, and source references, though they do not guarantee model accuracy. Sloth Brief leverages openly available, Apache-2.0 licensed Qwen2.5-0.5B-Instruct weights, allowing users to inspect the application and replace the model. The tool is deliberately small and CPU-capable, summarizing at most five notes separately per run. The initial version, which requested JSON, was refined to produce one concise summary per note to ensure deterministic source attribution. While source attribution is accurate, the summary's faithfulness to the original note is not guaranteed, requiring user verification. Input files remain unedited, with output generated as a new file, and size limits and source hashes help manage workload. The model lacks execution privileges, preventing malicious notes from running shell commands. The primary benefit is a quick restart checklist, although no specific productivity claims are made. The project was built with AI assistance, and the model demo ran locally on real open weights without using client data.
The European Commission has launched the AI Act Service Desk and a complementary AI Act Single Information Platform. These resources aim to help businesses and stakeholders understand the EU AI Act's applicability. The Service Desk allows users to submit specific questions in any official EU language to experts working with the EU AI Office. This provides direct, expert guidance rather than relying on fragmented interpretations. The Single Information Platform (SIP) is a self-service resource, offering tools like a Compliance Checker and an AI Act Explorer. These tools help users explore the legislation's structure and determine applicable obligations for their AI systems. While the Service Desk supports all official EU languages for inquiries, the SIP is currently available in English, French, and German, with full language coverage planned for early 2026. Businesses are advised to formulate focused questions based on their specific AI systems and roles to maximize the value of the Service Desk. A practical approach involves listing AI systems, describing their purpose, identifying the company's role, and then using SIP tools before submitting targeted questions. This strategy helps reduce wasted effort by addressing specific operational needs rather than treating the AI Act as a broad compliance project. The Commission has integrated these resources into a wider implementation effort, including support for SMEs and startups. Ultimately, these services help teams clarify relevant provisions but require companies to translate answers into their product design and implementation plans.
When scraping product pages, a 200 response doesn't guarantee useful data, as key information often loads via JavaScript. The crucial question is not "which scraper?" but "where is the data located?" Many e-commerce pages use client-side rendering, fetching data via backend API calls. A good starting point is to inspect network requests in DevTools for JSON responses containing product details.A rough workflow involves manually loading the page, filtering network requests for Fetch/XHR, searching response bodies for known product data, copying the request as cURL, and then minimizing headers to find the essential ones. Some sites allow direct cURL calls, while others require session cookies, geo headers, or CSRF tokens.Shopify stores are often easier, as many expose their catalog through /products.json, providing product titles, variants, prices, and image URLs. This method is faster and more robust than parsing HTML and avoids CSS selector failures from theme changes. However, some Shopify stores block this endpoint or limit the exposed data.When direct JSON endpoints aren't available, or JavaScript is needed for token generation, rendering the page with a headless browser like Playwright is necessary. Playwright can capture API responses or extract data from the DOM after JavaScript execution. This approach is slower and requires managing issues like timeouts, CAPTCHAs, and region inference.Full browser automation is reserved for interactive states like login-protected prices, wishlists, or checkout processes that demand clicks and persistent sessions. However, this is the most resource-intensive and prone to issues like slower jobs, increased CAPTCHA risk, and browser fingerprints. The decision tree prioritizes public JSON endpoints, then internal API calls, followed by headless browser rendering, and finally full browser automation. Avoid starting with full browser automation unless absolutely necessary, as it becomes expensive and flaky at scale.
Nginx version 1.31.5 introduced a new control API accessible via a Unix socket or TCP port. This API allows for HTTP-based reloads and provides structured responses, unlike the traditional signal-based reload method. It can be enabled with a command-line flag, and the official Docker image includes the necessary compilation. The API's endpoint tree can be discovered by making sequential GET requests. Key endpoints include /1/control/processes to get worker PIDs and /1/control/config to retrieve the live configuration. A PATCH request to /1/control/config triggers a configuration reload by re-reading the config file from disk. This API provides a significant advantage by returning a parsable JSON error message upon a failed reload, unlike the less informative signal method. Despite initial assumptions, the API reload process is not demonstrably faster than the signal method. Concurrency testing showed that in-flight requests are unaffected by reloads, regardless of the method used. The control API carries significant security risks if bound to a network port, as it lacks native authentication and can be exploited by anyone with network access. Binding the socket to a Unix socket with strict file permissions is the recommended mitigation, effectively blocking unprivileged users. Enabling the control socket incurs a small memory overhead for the master process. Testing revealed that host-side file edits to bind-mounted configuration files may not propagate to running containers, requiring methods like docker cp for immediate updates. The primary benefit of the control API lies in its superior error reporting during reloads, making it valuable for deployment scripts. It is strongly advised to bind the control socket only to a Unix socket with appropriate permissions. Administrators should audit systems for any network-bound control sockets on Nginx versions 1.31.5 and newer.
Language models often provide incorrect information because they lack knowledge of specific policies. Retrieval-Augmented Generation (RAG) addresses this by providing the model with relevant documents before it answers. This guide explains RAG using a library analogy: a good librarian retrieves specific pages rather than relying solely on memory. RAG involves retrieving relevant passages, augmenting the prompt with them, and generating an answer based on that information.RAG is beneficial when dealing with large or frequently updated documents, or when cost efficiency is important. Instead of pasting entire documents into every prompt, RAG allows for targeted document retrieval. The article outlines building a simple RAG system for a shop's help center using Python and SQLite. This system will chunk documents, index them for full-text search, retrieve top passages, construct a prompt, and verify the answer's citations.The implementation involves a chunk_markdown function to divide documents into meaningful passages, preserving headings for context. The build_index function creates a SQLite FTS5 virtual table to store these passages and enables efficient searching. The search function processes a question, expands it with synonyms, removes common words, and queries the index using a robust method.The build_prompt function formats the retrieved passages as numbered sources for the language model. A check_answer function performs basic validation to ensure the model cites existing sources and does not invent numbers. The core answer function orchestrates these steps, first searching for relevant passages and only calling the language model if relevant information is found. A placeholder extractive_model is provided for testing without a real language model API.