Samsung's Processing-in-Memory (PIM)
Samsung’s LPDDR5X‑PIM adds a processing‑in‑memory (PIM) block to each of the 16 banks of a standard LPDDR5X‑9600 DRAM chip, enabling internal MAC operations without using the external bus. Each block contains a MAC tree, a 1024‑bit instruction register (64 × 16‑bit ops), 4 kbit source registers for activation vectors, and 2 kbit scale registers. The MAC array can perform four INT8/FP8 MACs per data clock (eight per DDR cycle) and doubles throughput for 4‑bit weights, yielding a chip‑wide compute rate of up to 2.4 TOPS (≈614 GB/s internal bandwidth). Multi‑bank mode broadcasts register writes across all banks, acting as a constrained SIMD processor; single‑bank mode preserves normal DRAM operation. PIM is accessed via special row addresses that repurpose standard read/write commands, requiring software to isolate a PIM memory region, map it uncacheable, and avoid concurrent regular accesses. This raises OS‑level challenges (locking, context switching, cache coherence). Samsung’s approach demonstrates feasibility of standard‑compliant DRAM compute but highlights significant integration and software‑stack complexities.
Europe's last regular standard-gauge steam passenger service
From 20 to 28 August 2026 the steam locomotive Pt 47‑65 undergoes a periodic review; during this period scheduled services will be operated with a diesel SM 42 6D instead. The steam‑hailed train runs Monday‑Friday between Wolsztyn and Zbąszynek and on Saturdays between Wolsztyn and Poznań; it does not operate on Sundays or public holidays. Tickets can be purchased via the Wielkopolskie Railways website, at the station ticket office, or directly from the train conductor. Departure times are posted at the station. No additional service details are provided.
Comments highlight inconsistencies in how regular‑service steam trains are classified, noting that UK examples such as the Flying Scotsman, Festiniog, and heritage lines like North Yorkshire, Swanage, Bluebell, and Dartmouth meet criteria for integrated tickets yet are often excluded, while gauge differences are also cited. Australian steam operations are described as primarily tourist‑oriented rather than timetable‑regular. A separate viewpoint stresses environmental drawbacks, recounting severe coal‑particle pollution on a Polish steam trip and expressing disappointment with the experience. Overall, the discussion balances enthusiasm for heritage rail accessibility with criticism of classification and environmental impact.
GUIs should be fully keyboard-driven
The post discusses the Hacker News debate over whether developers should favor graphical user interfaces (GUIs) or terminal user interfaces (TUIs). While TUIs are often praised for being inherently keyboard‑driven, the author argues that this advantage merely highlights the poor keyboard navigation in many GUI applications, not an intrinsic superiority of TUIs. Modern GUI frameworks and design guidelines—e.g., the GNOME Human Interface Guidelines—explicitly require that every action be accessible via the keyboard, making full keyboard‑driven GUIs feasible. The author’s experience creating a first GUI app, Klisi, shows that implementing comprehensive keyboard shortcuts is straightforward and improves overall usability. Consequently, the decision between GUI and TUI should not hinge on keyboard support; developers must prioritize intentional, keyboard‑friendly design regardless of the interface type to ensure an intuitive user experience.
The comments show broad agreement that robust keyboard navigation is essential for accessibility and power‑user efficiency, yet many observe a decline in support from modern GUI frameworks and a lack of consistent shortcuts or discoverability cues. Contributors cite older native toolkits as easier to make keyboard‑friendly, criticize recent designs for treating keyboard use as an afterthought, and highlight extensions or custom tooling that restore functionality. While some view full keyboard‑driven interfaces as niche, the prevailing sentiment urges better standards, consistent implementation, and attention to both accessibility and productivity.
You Know GDPR Is Good Based on Who Hates It
- The author cites FDR’s 1936 speech to argue that strong opposition signals effective, hard‑fought policy; by that metric GDPR is succeeding.
- GDPR’s most visible symptom, the cookie consent banner, is described as a “dark pattern” that exposes users to data‑sharing practices rather than being the cause of privacy loss.
- The regulation reflects a long European tradition (e.g., Germany’s 1970 law) and aligns with OECD privacy principles: data minimization, purpose limitation, security, access, and correction.
- The “Brussels Effect” explains rapid global adoption: the EU’s large market and coordinated enforcement through national Data Protection Authorities compel multinational firms to comply, leading to harmonization such as the EU‑Japan adequacy agreement.
- In the United States, privacy is treated as a market issue; post‑9/11 security focus, lobbying, and revolving‑door ties have prevented robust federal regulation, leaving surveillance capitalism unchecked.
- The piece contrasts this with Karl Polanyi’s “double movement,” noting that while other sectors eventually receive protective regulation, the US lacks a functional counterbalance for data‑driven markets, making EU‑driven GDPR the primary driver of worldwide privacy standards.
The overall view expresses mixed sentiment toward GDPR: it is praised for improving data protection and prompting better corporate practices, yet criticized for creating intrusive consent banners, overly complex compliance, and slow, uneven enforcement that burdens small businesses while large firms can absorb costs. Commenters note that regulators often lack technical expertise, leading to excessive legal red tape, and argue that the current implementation undermines the regulation’s intent, making the web feel uglier without delivering clear benefits to users.
Boot a Virtual iPhone via Apple's Virtualization.framework
vphone‑cli is a command‑line tool that uses Apple’s Virtualization.framework to instantiate a virtual iPhone VM based on PCC research VM infrastructure. After installing dependencies (Python 3.13, aria2, wget, GNU tar, OpenSSL 3, ldid‑procursus, sshpass, keystone, cmake, libusb, ipsw, zstd) via Homebrew, the repository is cloned and the helper scripts setup_tools.sh and build.sh compile and sign the binary and bundle it as a macOS app.
Key commands:
- vphone‑cli vm create <name> -V <variant> runs the full pipeline (download IPSW, patch boot chain, DFU restore, install custom firmware, first boot).
- Individual steps (fw prepare, fw patch, restore, cfw install, vm launch) allow manual control.
- VM management includes list, info, new, config, clone, export, import, rename, and delete.
Supported patch variants (less → exp) adjust security bypass levels; SSH (mobile/root) and VNC access are provided on port 22222/5901. All VM data reside under ~/.vphone/ or a user‑defined $VPHONE_ROOT.
Two AMFI‑bypass methods are described: disabling SIP and setting amfi_get_out_of_my_way=1, or keeping SIP enabled and using amfidont. Known limitations include lack of nested virtualization, region‑specific setup failures, EXC_GUARD crashes (remediated by fw patch --force-exc-guard), and a ld‑id‑procursus bug fixed by building from HEAD.
A host‑side control socket (vphone.sock) enables programmatic input, screenshots, and clipboard operations for automated testing.
The comments express overall enthusiasm for the project’s capabilities, noting its usefulness for app testing, reverse engineering, and profiling compared to existing tools. Users seek clarification on its differences from the iOS simulator, the role of virtual baseband, regional setup restrictions, and technical requirements such as SIP modifications. Several inquire about practical applications like browser testing, account recovery, and potential cross‑platform support, while also questioning whether Apple might counteract the approach. The tone is generally positive but includes curiosity and cautious concerns about limitations and future viability.
Hunting Down a Go Runtime Bug on 32-Bit Embedded Systems
A Go application running on 32‑bit ARM (or i386) Linux crashed sporadically with
runtime: netpoll: eventfd ready for 5
fatal error: runtime: netpoll: eventfd ready for something unexpected
The panic originates in netpoll_epoll.go, where the netpoll loop expects only EPOLLIN events. The Go runtime stores event metadata in the 8‑byte ev.Data field of struct epoll_event. For socket fds it stores a tagged pointer (lower 4 bytes = sequence tag fdseq, upper 4 bytes = pointer to pollDesc). For the internal event‑fd it stores a raw pointer to netpollEventFd with the upper 4 bytes zeroed.
On 32‑bit little‑endian systems the comparison *(*uintptr)(unsafe.Pointer(&ev.Data)) == &netpollEventFd examines only the lower 4 bytes. As fdseq increments, it eventually equals the low 32 bits of &netpollEventFd. The runtime then misidentifies a socket fd as the event‑fd, violates the assumption that the ready event is just EPOLLIN, and aborts. This alias can only appear after millions of pollDesc allocations, explaining crashes in long‑running programs.
A reproducible test creates many poll descriptors until fdseq collides, triggering the panic within minutes. The fix replaces the raw pointer with a nil‑tagged pollDesc for the event‑fd, ensuring ev.Data always contains a tagged pointer and eliminating the aliasing. The patch was merged in 2026, resolving the bug introduced in Go 1.14.
The discussion emphasizes the value of leveraging the Python plugin interface of gdb to enhance debugging capabilities on embedded devices, noting a personal improvement in skill. It also conveys curiosity about additional undiscovered 32‑bit bugs, reflecting an interest in further exploration and detection within this domain. The tone is constructive and inquisitive, focusing on practical techniques and the potential for uncovering more issues.
TurboKV: Insanely fast Rust key-value store
TurboKV is an asynchronous embedded key‑value store for Rust offering atomic batch writes, ordered range scans, configurable durability levels, optional compression, and background compaction. It supports hardware‑accelerated Bloom filters using AES (x86/x86_64 with +aes,+sse2, ARM/AArch64 with +aes,+neon) and can be built with -C target-cpu=native for CPU‑specific optimizations. The crate provides Db, DbOptions, and WriteBatch APIs; databases are opened via Db::open or Db::open_with_options with options such as fast, durable, or paranoid. Options include toggling the write‑ahead log (WAL), sync‑writes, memory‑table size, block‑cache size, and compression (LZ4, Snappy, Zstd, or none). Keys and values are arbitrary byte slices; all mutations copy inputs, and reads return owned Vec<u8>. Scans are point‑in‑time snapshots and support range, prefix, and iterator interfaces. Maintenance functions include flush, compact, and status queries (logical_stats, physical_stats). Benchmarks (TurboKV 0.6.0 vs. fjall 2.11.2 and redb 2.6.3) measured throughput on an Apple M4, detailing durability modes, batch amortization, and raw performance data.
The comments show a mixed response, combining technical critique, curiosity, and light‑hearted remarks. Several points question the terminology around durability and note that the described mode would not survive power loss, while others highlight performance claims, attributing speed to hardware‑accelerated AES, LZ4 compression, and possible SIMD use. There is interest in additional features such as atomic get‑plus‑delete operations, and jokes about developers creating personal databases and meme‑driven hype. Overall, the tone blends skepticism, technical interest, and informal humor.
Htmx 4.0
htmx 4.0.0 replaces the internal XMLHttpRequest implementation with fetch(), a change that is transparent to most users. Key differences from htmx 2.x:
- Attribute inheritance is now explicit; attributes must include the “:inherited” suffix to cascade to child elements, removing the need for hx‑disinherit and simplifying inheritance logic.
- Event naming follows a standardized “htmx:phase:action[:sub‑action]” pattern (e.g., htmx:before:request, htx:after:swap); most legacy event names are consolidated into htmx:error and htmx:response:error.
- History handling no longer stores page snapshots in localStorage; on back navigation the page is re‑fetched and swapped, with an optional hx‑history‑cache extension that uses sessionStorage for caching.
- New features: built‑in morphing swaps, the tag for structured partial updates, and the hx‑live scripting layer (Alpine.js‑style reactivity).
- Extensions added or updated: hx‑preload, hx‑download, hx‑alpine‑compat, hx‑history‑cache, hx‑sse, hx‑ws, hx‑multipart, plus a bundled htmax.js for common extensions.
- Versioning: 2.x remains the “latest” tag on CDN; 4.x is published as “next” until early 2027. Install via npm or CDN at https://unpkg.com/[email protected]/dist/htmx.min.js. An upgrade‑check CLI tool flags required changes.
The comments show strong enthusiasm for htmx’s simplicity, progressive‑enhancement approach and its ability to add Ajax‑like behavior with minimal JavaScript, with many users reporting productive experiences and praising its documentation and compatibility. At the same time, several developers express concerns that htmx encourages mixing presentation with business logic, can become complex for large single‑page applications, and may be less suitable when extensive client‑side state management or modern frameworks like Angular, React or Alpine are preferred. Issues with mobile navigation and version‑numbering also appear. Overall sentiment is largely positive but tempered by practical reservations.
U.S. sanctions against the A/I Collective
Autistici/Inventati (A/I) is a volunteer‑run collective founded in 2001 within the autonomous anticapitalist movement, focusing on technology and digital rights activism. The organization offers free digital self‑defence tools and communication platforms aimed at activists and individuals, emphasizing non‑commercial use and refusing any commoditisation of user data. Services are provided without monetary compensation; funding comes solely from voluntary donations. Each service request undergoes manual review by a volunteer, requiring alignment with A/I’s manifesto, respect for its policy, and adherence to its privacy terms; requests are anonymised and subsequently destroyed. The group stresses solidarity, self‑organisation, and a commitment to free, secure communication for its aligned community.
The comments converge on strong criticism of the U.S. designation of Autistici Inventati as a terrorist entity, describing it as an unprecedented and overbroad move that threatens free‑speech protections and sets a dangerous precedent for labeling digital‑infrastructure providers. Participants question the evidence linking the collective to violent groups, view the action as politically motivated antifa targeting, and express concern that similar services for activists could face sanctions, eroding anonymity and hindering legitimate dissent. Overall sentiment is skeptical and alarmed about the implications for civil liberties and online activism.
I accidentally turned LLM memory into program analysis
The author describes how LLM agents used for vulnerability research lose track of established facts over long sessions, leading to repeated hallucinations. To address this, they built Lemmalog, a Datalog‑style engine that stores observations as structured facts and derives conclusions via declarative rules, enabling incremental updates, retractions, provenance tracking, and temporal validity intervals. When a fact changes (e.g., a pointer relationship is disproven), Lemmalog automatically invalidates dependent conclusions without re‑processing the entire transcript. The system separates fuzzy extraction (LLM parsing of code, debugger output, natural language) from deterministic reasoning (the Datalog engine). Benchmarks on LongMemEval and LoCoMo show Lemmalog achieving F1 scores of ~0.46 and ~0.53 respectively, outperforming full‑context prompting and matching or surpassing other memory systems on categories such as knowledge updates, temporal reasoning, and adversarial queries, while using 6–38× fewer tokens per query. Limitations include weaker inference on conditional knowledge and reliance on accurate fact extraction. The work demonstrates that maintaining a structured analysis state can improve LLM memory fidelity without expanding context windows.
The discussion emphasizes that LLMs work best when confined to translating natural language to and from formal representations, while mechanical reasoning is delegated to structured systems such as Datalog, Prolog, or knowledge graphs. Contributors note that persistent, queryable memory and formal verification can reduce repeated inference costs, but warn that LLMs often forget or retain outdated facts, requiring explicit decision logs or non‑monotonic frameworks. Interest in integrating “old‑school” AI tools, linters, and specialized libraries is high, though practical challenges and the need for reliable grounding remain common concerns.
The discussion expresses cautious skepticism about the practicality of processing‑in‑memory architectures, emphasizing that data movement dominates energy and silicon costs and that limited DRAM bank sizes could negate performance gains when weights exceed a single bank. Historical parallels to earlier RAM‑based compute extensions are noted, and while Samsung’s continued PIM research and past demonstrations are acknowledged as technically interesting, the lack of a clear killer application leads to doubts about widespread adoption. Overall sentiment is measured, recognizing potential but questioning current feasibility.