Jev in 25 Lines of Python
The post demonstrates a minimal “Jev” implementation using the Llama‑CPP Python bindings. It loads the Qwen 3‑0.6B GGUF model (Qwen/Qwen3-0.6B‑GGUF, file Qwen3-0.6B‑Q8_0.gguf) with a 512‑token context, enabling logits_all. A prompt is constructed that presents an email snippet and three labeled choices (“A. Legitimate”, “B. Spam”, “C. Phishing”). The model is evaluated on the tokenized prompt, and the final token logits are extracted. Logits for the label tokens are gathered, transformed into log‑probabilities via logaddexp, and exponentiated to obtain class probabilities. The script prints logits, log‑probabilities, and probabilities rounded to three decimals. The author emphasizes that this approach performs local, fast classification without transmitting data, and references more complete open‑source Jev projects (OpenJev, openjev‑sglang, OpenJev on DiffusionGemma). The post is a parody, published Sep 22 2026.
GPT-6 Sol and Luna
The comments highlight strong approval of the 50 % price reduction for GPT‑6 Luna and Sol, with many users noting the cheaper cost as a primary benefit and seeing Luna as a practical upgrade over its 5.6 predecessor. Opinions are split on performance: several users report comparable or improved results for Sol, while others observe a modest decline for Luna and worry about possible model “nerfing.” Comparisons with Anthropic’s offerings emphasize OpenAI’s perceived transparency and cost‑effectiveness, yet some developers still favor Claude for specific tasks such as UI design. Overall, the community values affordability and reliability but remains cautious about trade‑offs in capability.
Claude Opus 5.5
Claude Opus 5.5 is the first model in Anthropic’s Claude 5.5 family, matching Claude Fable 5.1 on most tasks while costing ~40 % less than Opus 5. External evaluators (Frontier Design, METR) and Anthropic’s automated behavioral audit rate it as the strongest‑performing and safest model to date, with reduced prompt‑injection susceptibility and broader alignment testing (longer, impossible, real‑incident scenarios).
Performance – major gains in agentic coding, computer use, and knowledge work; e.g., a 680 k‑line code migration completed in < 1 day, 39/40 web‑app load‑time reductions, and higher graphics polish in game generation. Benchmarks (Terminal‑Bench 4.0, AutomationBench, GDPval‑AA v2.1) show Opus 5.5 leading Claude models and outperforming GPT‑6 Astra at ~20‑40 % of the cost per task.
Cost & Speed – default token pricing $4 M input / $20 M output (20 % lower than Opus 5); cache reads $0.20 M (60 % lower). Output generation > 30 % faster; fast mode up to 2.5× speed at $8 M input / $40 M output.
Safety – production safeguards enabled, classifier screens actions, open‑source sandbox, robust code‑review checks; ties Fable 5.1 for lowest prompt‑injection success rate (Gray Swan benchmark).
Applications – available to vetted life‑science and cybersecurity programs; upcoming Claude Sonnet 5.5 and Claude Haiku 5.5 will share similar improvements.
The comments show mixed reactions to Claude Opus 5.5. Many users note the lower token pricing, faster generation and a clearer, less verbose communication style, citing improved coding and agentic tasks. Others criticize the frequent model releases, price‑driven feature cycles and new safety filters that hinder certain workflows. Some prefer alternative models such as Astra, DeepSeek or Chinese offerings, while a few express frustration with UI and subscription handling. Overall sentiment balances appreciation for performance and cost gains with skepticism about product strategy and restrictions.
Transit rewards
Waymo is launching a transit rewards program in the San Francisco Bay Area, with plans to expand to additional cities. Riders who link a Visa card in the Waymo app and take a Waymo trip and a public‑transit trip within two hours will receive $2.85 in Waymo Cash—the approximate cost of a San Francisco bus fare. The incentive applies to all 27 Bay‑Area transit agencies that accept contactless Visa tap‑to‑pay. Waymo will also lease 40 dedicated parking spaces at Caltrain stations to facilitate vehicle staging for transit users. The rollout begins with employee access before opening to the public. Waymo cites surveys indicating that more than half of its riders in San Francisco, Los Angeles, and Phoenix combine rides with public transit, and positions the program as a complement to existing regional transfer discounts and tap‑to‑pay models. The company plans to replicate the model with other agencies to broaden all‑electric, multimodal mobility options.
Comments express frustration with fragmented transit options and the limited scope of Waymo’s incentive, noting that requiring a Visa card excludes many riders who rely on transit passes. Users question the program’s motives, viewing it as a marketing or competitive tactic rather than a genuine effort to improve mobility, and criticize the lack of broader integration with existing payment systems. There is a strong desire for a seamless, door‑to‑door solution and greater investment in reliable, publicly funded transit infrastructure, which many feel remains under‑prioritized.
OpenAI GPT–6 Astra breaks Enigma message that has resisted solution since 2005
On 15 Sep 2026 Carter Leffer obtained validation that OpenAI’s GPT‑6 Astra independently broke the German Army Enigma message MVUEH (Nr. 172, 10 Jul 1941), a ciphertext unsolved since 2005. The AI identified the message as the most promising unbroken entry on the Crypto Cellar Research site, suspected a relation to the previously solved message SIPVX (Nr. 173), and used the repeated place name “ROSENOW ROSENOW” as a crib. After developing Python and C++ Enigma simulators and a Bombe, GPT‑6 derived a key with wheel order 253 (instead of the day’s 512), a left‑hand wheel turnover at the 72nd letter, and distinct plugboard and ring settings. The recovered plaintext matches SIPVX except for a twelve‑letter length difference caused by a transcription error (“Bitte” → “Btte”) and a duplicated signature. GPT‑6 also referenced Bundesarchiv radio‑message volumes (RS 3‑3/20a, RS 3‑3/63b) despite their absence from public archives. The break illustrates AI‑driven cryptanalysis achieving in days what previously required weeks or months of manual research.
Comments show mixed reactions to the AI‑driven Enigma decryption. Several participants acknowledge the successful plaintext recovery and view it as a notable illustration of large‑language‑model assistance in cryptanalysis. Others question the novelty, suggesting the result likely stemmed from existing simulators, training data, or straightforward prompting rather than a breakthrough, and they debate the extent of human versus model contribution. The discussion also revisits historical Enigma‑breaking credit, expresses curiosity about applying similar methods to other unsolved codes, and raises broader concerns about hype, transparency, and the limits of current AI capabilities.
Data-only attacks are easier than you think (2024)
Comments acknowledge that data‑only attacks are relatively easy to detect with existing static analysis and fuzzing, while emphasizing that abuse of legitimate business logic, such as e‑commerce refund manipulation, presents a more serious and harder‑to‑detect threat. Several remarks highlight the relevance of resources like GTFOBins and advocate better taint‑analysis tooling with improved user interfaces to reduce over‑tainting. There is surprise that a recent tool avoids LLM integration, coupled with a broader criticism that research quality has declined since LLMs became commonly used.
'We hacked the FBI:' Hackers say they have data on all FBI employees
Hackers claim to possess a comprehensive database of FBI personnel, asserting that they have personal information on every employee. A disclosed sample of 5,000 records, obtained by 404 Media, lists names, residential addresses, telephone numbers, and spousal details for alleged agents. The release is framed as evidence of a large‑scale breach of FBI staff data. Accompanying the claim are multiple image placeholders covering unrelated topics such as Roblox hijacking, a16z‑backed phone farms, smart‑toothbrush botnets, AI‑generated calls, and AI‑training controversies, but no additional substantive information about the purported FBI data leak. No technical specifics about the breach method, source, or verification are provided.
Comments coalesce around deep skepticism toward the security of large government databases, emphasizing that breaches like the recent PeopleSoft compromise expose systemic weaknesses and highlight reliance on vulnerable vendor software. The consensus criticizes governmental incompetence, hiring practices, and inadequate investment in cyber‑defense, while noting that paper or non‑collection remains the only truly safe option. Observers also question the motives and credibility of the hacker group, mock media hype, and speculate on AI’s role, but overall the tone is cynical and calls for stronger, more accountable security measures.
Show HN: Npunlock – Run custom C kernels for Intel NPUs
npunlock is a Windows‑only toolchain that enables custom C kernels to run on Intel Core Ultra NPUs (Meteor Lake / NPU3720). It bridges the gap between user‑written C code and Intel’s ACT‑SHAVE processors, allowing these kernels to be embedded in standard NPU graphs compiled with Intel’s driver. The project supplies header files (e.g., npunlock/npu3720_kernel.h) and uses the MoviTools MVC_DEPEND toolchain for compilation; the required binaries (npunlock.dll, npunlock_worker.exe) are packaged with the Python module. Example code demonstrates a full‑precision (FP32) GELU implementation, comparing NPU output against NumPy and reporting maximum absolute error. Supported features include static‑shape FP16 unary and binary kernels, mixed‑precision graphs with independent FP32‑unary and FP16‑binary branches, and reusable NumPy‑compatible buffers via Python, CLI, or native C APIs. Limitations: Windows x64, Meteor Lake/NPU3720, static shapes, known tensor layouts, and no OpenVINO runtime required. Linux ports and newer NPU generations are untested but encouraged for community contributions.
The comment expresses a neutral, inquisitive tone, asking for clarification on the purpose and practical applications of the content. It does not convey strong positive or negative sentiment, merely seeks information about usefulness, and reflects a straightforward request for explanation without any additional opinion or critique.
Microsoft killed FoxPro in 2007. Anyway, here's FoxPro revived
FoxDev Studio revives Visual FoxPro 10 as a 64‑bit environment that removes the 2 GB file‑size ceiling imposed by 32‑bit offsets. Tables larger than 2 GB remain readable, though they cannot be reopened in legacy VFP. The platform includes a Rust‑based compiler emitting WebAssembly bytecode and a matching interpreter; the editor validates code against this compiler, ensuring consistent syntax and runtime behavior. Execution runs in fibers that yield for external actions (e.g., MESSAGEBOX, READ EVENTS), preventing UI blocking. Forms are represented by a live object tree rendered directly by React, allowing granular updates (e.g., changing a label’s caption repaints only that control). Legacy 32‑bit .fll libraries are accessed via a small 32‑bit bridge process invoked by SET LIBRARY TO, while native 64‑bit DLLs can be called directly with DECLARE ... DLL. The system therefore supports both historic VFP libraries and modern 64‑bit extensions within a unified, high‑performance runtime.
The comments convey a mix of nostalgia for Visual FoxPro’s simplicity and rapid development, recognition that sizable niche industries still rely on it, and criticism of its architectural limitations, especially security and multi‑user file‑based access. Many contributors describe successful migrations to client‑server or web stacks, while others argue that modern replacements often add unnecessary complexity and cost. There is consensus that legacy FoxPro applications persist because they work, but there is also a shared call for safer, scalable alternatives and open‑source tooling to facilitate transition.
ReBarUEFI: Resizable BAR for almost any UEFI system
A UEFI DXE driver enables Resizable BAR (RBR) on systems lacking native support, improving GPU performance and required for optimal Intel Arc operation. The driver replaces the PreprocessController function of the PciHostBridgeResourceAllocationProtocol, reading a Resizable BAR size from the ReBarState NVRAM variable and applying it during PCI enumeration. Optional steps include enabling 4 GB decoding, disabling CSM, and applying BIOS patches for large BAR handling. The project provides scripts (buildffs.py, CMake‑based ReBarState) for building the driver on Windows or Linux, as well as UEFIPatch patches to lift 4 GB, 16 GB, and 64 GB BAR limits, prevent 64‑bit BAR downgrades, and expand MMIO space up to 512 GB on modern chipsets. Compatibility notes: it can work on PCIe Gen2 (e.g., i5‑2500K), Linux can resize BARs with 4 GB decoding or via DSDT patches and the kernel pci=realloc option; Windows requires BIOS modification. Unsupported BAR sizes may prevent boot, resolvable by clearing CMOS. Performance gains of up to ~12 % FPS were observed with a 2 GB BAR on an i5‑3470 + RX 580 system.
The discussion highlights interest in enabling Resizable BAR to unlock full VRAM access and modest performance gains, particularly for gaming and GPU‑intensive tasks such as machine‑learning workloads. Users express frustration with restrictive BIOS options on older or vendor‑locked systems, noting that coreboot and custom firmware can add features like 4 GiB decoding, NVMe boot, and CPU microcode updates. There is curiosity about practical benefits, compatibility with specific hardware, and the feasibility of applying ReBAR modifications to both motherboards and graphics cards.
The discussion critiques relying on raw token log‑probabilities with chat models, noting that prose‑oriented training can dilute choice probabilities and cause unwanted drift. It recommends using clearly defined system prompts and structured multi‑token outputs to improve reliability, and suggests routing different prompt types to specialized models. Concerns are raised about missing latency, compute, and error‑rate comparisons, especially relative speed claims versus existing solutions, and a demand for concrete benchmarks, low‑latency performance, and robust parsing is expressed. Overall, the tone is skeptical yet constructive, emphasizing practical improvements and measurement.