Qwen 3.8 27B is excellent, but it defaults to overthinking things
Qwen 3.8 27B, an Apache‑2.0 licensed 27‑billion‑parameter vision‑capable LLM from Alibaba, runs locally from a 17 GB GGUF file. Its default reasoning_effort = xhigh makes the model generate extensive “thinking” traces, consuming tens of thousands of tokens and minutes per query (e.g., 22 276 reasoning tokens to produce 3 223 output tokens for a simple SVG). Reducing the setting to low or disabling reasoning cuts runtime to seconds and yields comparable outputs. The model supports a 262 144‑token context window, needed to avoid early truncation. Benchmarks show strong vision performance (accurate 0‑1000‑scaled bounding‑box JSON for pelicans) and effective tool‑calling, demonstrated by integration with the Pi coding agent and by generating complete HTML/JS utilities from a single prompt. Token throughput is modest (15–30 t/s in LM Studio) but improves markedly with Multi‑Token Prediction (draft‑mtp) in llama.cpp, achieving ~72 % speed gains over default GGUF serving. Main limitation remains inference latency on consumer‑grade hardware despite impressive capability set.
The Life and Death of Direct File [pdf]
The comments convey a mixed assessment of the Direct File project and its post‑mortem report. Readers note the report’s balanced, detailed presentation, yet many criticize the initiative’s high costs, lengthy timeline, and eventual shutdown, attributing outcomes to entrenched government procurement policies, political influences, and the preference for commercial contracts over internal development. Opinions also highlight perceived bias from the author, question the value of government‑run digital infrastructure, and suggest that outsourcing could mitigate inefficiencies, while acknowledging some successes within the limited budget.
AGI-64 Brings Sierra Adventures to the Commodore 64
- AGI-64 is a new AGI interpreter for the Commodore 64, currently about 75 % complete and fully playable with Space Quest 1; the engine is intended to run most AGI titles from the era.
- The interpreter will be offered as a free download and includes a compiler that converts user‑provided .vol and .obj files into a 1 MB EasyFlash‑compatible .CRT image, usable on devices such as Kung Fu Flash.
- Save and load functions operate via real or SD‑card 1541‑compatible drives on drive 8, using a custom disk format that allows up to six saved games.
- AGI‑64 employs a custom background pre‑processing technique to preserve original artwork, achieve fast loading, and maintain performance on the C64’s 1 MHz CPU.
- Screenshots demonstrate the interpreter running the Space Quest 1 title screen and full gameplay on actual C64 hardware.
The comments express curiosity and a request for clarification about the underlying technology, with users seeking a more detailed explanation of how the system functions. There is particular interest in whether the tool can recompile games, indicating a desire to understand its capabilities and practical applications. Overall, the tone is inquisitive and seeks additional information rather than offering criticism or praise.
A 3rd World Embedded Engineer Responds to "RISC-V They Should Have Known Better"
The author, a third‑world embedded engineer, critiques Dmitry Grinberg’s negative view of RISC‑V, arguing that Grunberg’s focus on ISA elegance ignores practical constraints of cost, availability, and openness for developers in regions like Trinidad & Tobago, Nigeria, and Bangladesh. He highlights inexpensive RISC‑V MCUs (e.g., CH32V003, CH32H417, Baochip‑1x) that meet cheap‑microcontroller requirements—limited registers, no multiplier/divider, machine‑mode only—while scaling to more capable systems with MMUs, Linux, or high‑speed peripherals using the same base ISA. By contrast, ARM’s product line separates microcontroller and application‑processor capabilities through distinct licensed cores and royalties, creating a non‑incremental path and higher tooling costs (e.g., expensive J‑Link debuggers, shipping restrictions). The author acknowledges RISC‑V’s extension‑induced fragmentation (e.g., Zcb, Zicsr) but asserts this modularity enables a single ISA to span from ten‑cent devices to advanced SoCs, fostering affordable, open development and education worldwide.
Comments show a mixed view of RISC‑V. Many appreciate its low‑cost, licensing‑free nature and flexibility for custom embedded designs, noting it enables cheap microcontrollers and could democratize hardware access. Others stress performance gaps with ARM64, fragmentation from optional extensions, and limited high‑end suitability, questioning the practicality of a single ISA spanning low‑end to server workloads. Several critiques target the article’s cost and shipping arguments, finding them inconsistent, while some highlight technical advances such as optional MMU and interrupt extensions. Overall sentiment balances optimism for future improvements with skepticism about current limitations.
Claude: System Prompts
Claude’s web UI (claude.ai) and mobile apps prepend a system prompt to every conversation. This prompt supplies dynamic context—e.g., the current date—and enforces behavioral guidelines such as always rendering code snippets in Markdown. The prompt is revised periodically to enhance response quality; changes are highlighted (bold) when multiple dated entries exist for a model. These prompt updates affect only the web and app interfaces and are not applied to the Claude API. From the Claude 4.6 generation onward, each model identifier corresponds to a single, immutable snapshot, so those models have only one system‑prompt entry.
The comments convey widespread criticism of Anthropic’s expanding system prompts, describing them as overly verbose, redundant, and counter‑productive for coding tasks while consuming valuable context tokens and compute. Users argue that many guard‑rail clauses add noise, hinder model efficiency, and could be handled more succinctly or modularly, and they call for customizable, task‑specific prompts. There is also frustration over perceived forum censorship of negative AI stories and disappointment with inconsistent model behavior, especially regarding safety overrides and politeness directives. Overall, the tone is skeptical and calls for leaner, more transparent prompt design.
Rhombus 1.1 is now available
Rhombus 1.1, a general‑purpose, customizable programming language, is now available at https://rhombus-lang.org/. The release introduces several language extensions and refinements:
- Annotations – New
annotandannot.defforms allow defining annotations without writing macro code. - Binding form –
asprovides an alternative to&&for naming and enables shadowing of identifiers bound as a form. - Class inheritance –
classnow binds inherited names using the appropriate superclass or interface reference. - Scope handling –
space.enforestadjusts scopes analogously to macro transformers when applying identifier handlers. - FFI –
newgains an initialized‑array variant for foreign‑function interfacing. - Pict module –
explain_animaccepts a~labelargument;Pict.rebuiltis renamed torebuiltwith a~as_rebuiltoption;magic_moveandcross_fadeimprove handling of paragraph points and multiple child pictures. - Slideshow – Added
slide_transitionand continued page numbering.
Community contributions are acknowledged, and feedback is invited via the Racket Discourse or Discord #rhombus channel.
The comments express strong appreciation for Racket’s extensive ecosystem and its ease of creating diverse applications, noting that Rhombus extends this strength by demonstrating Racket’s language‑building capabilities and offering a customizable, user‑friendly experience. The recent 1.1 release is welcomed, and the all‑Racket implementation of the Rhombus repository is highlighted as a positive feature. At the same time, concerns are raised about the current library distribution system, including a lack of clear promotion for top packages and dissatisfaction with the language’s name.
Reticulum – Decentralized Mesh Network
Reticulum is a cryptography‑based networking stack designed for resilient local and wide‑area networks using commodity hardware. It operates under high latency and extremely low bandwidth conditions, enabling users to build sovereign, self‑organized communication networks without centralized control or censorship. Key technical features include:
- No source addresses in packets; address allocation is decentralized and unlimited.
- Self‑sovereign, portable addresses become globally reachable within seconds to minutes.
- All traffic is encrypted by default with strong, modern algorithms; keys are ephemeral and provide forward secrecy.
- Unencrypted links or packets are prohibited and discarded by receivers.
Reticulum thus facilitates secure, autonomous networking at scales from small community setups to planetary‑wide deployments, emphasizing autonomy, interoperability, and resistance to external manipulation.
Comments focus on Reticulum’s lack of source address information, noting that while packets omit origin data, observers could infer approximate locations through repeaters similar to MeshCore. Several remarks criticize the absence of a published specification and the reliance on a single Python implementation, describing this as a missed opportunity for a well‑solved privacy solution. Additional remarks reference the term’s appearance in Neal Stephenson’s Anathem, request a comparative analysis with rayfish.xyz, and make a brief, ambiguous comment about “the resistance,” reflecting curiosity and mild concern.
Gmail might partially be to blame for receiving emails from other Sean Conners
The author recounts receiving emails meant for other individuals named Sean Conner because Gmail treats addresses with and without periods as equivalent (e.g., [email protected] = [email protected]). This behavior, introduced after the author’s early‑adopter account was created, can cause “leakage” of messages across distinct users, especially for legacy accounts. A quoted Stack Exchange response describes a similar case where an early‑registered [email protected] address receives mail for a later‑registered [email protected] account, leading to misplaced bank, school, and other sensitive communications. Google’s official justification cites the RFC‑5321 requirement that the local‑part semantics are defined solely by the domain host, allowing Gmail to ignore periods to reduce confusion. The post also notes that while most ASCII characters are permitted in email local‑parts, some require escaping and are discouraged. The author expresses distrust of Gmail for confidential use due to these address‑handling issues.
The comments express confusion about Gmail’s handling of periods in addresses, noting that adding periods has never redirected mail to a different inbox. Users report occasional receipt of messages intended for similar addresses, attributing most cases to sender typos or misconfigured reply settings rather than a Google leak. There is some alarm about potential privacy issues, but the overall view acknowledges Gmail’s address normalization as a measure to reduce such confusion.
Low-Tech Ceramic Water Filter
A ceramic water filter removes bacteria, protozoa, helminths, sediment and organic matter by forcing water through a fired clay matrix with pore sizes of 0.6–3 µm. The matrix is formed from a mixture of clay (30 kg) and combustible organic material (8.9–10 kg sawdust or rice husks) plus water (12.5 L); the combustible burns during firing, creating cavities that increase flow. After mixing, the paste is extruded into 8 kg cubes, hydraulically pressed between male and female molds, surface‑finished, dried (7–18 days depending on humidity), and fired: 2 h at ~100 °C then up to 900 °C for 9 h to vitrify the clay. Each pot is flow‑tested (1.5–3 L h⁻¹) and, if passing, coated with colloidal silver (≈47 mg inside, ≈23 mg outside) to provide biocidal activity. Finished filters are packaged with a tap‑fitted storage container. Users pour water into the pot; filtered water collects in the storage tank. Routine cleaning is required every six months, and pots should be replaced every 2–3 years or when cracked. The design originated in 1981 (Dr Fernando Mazariegos) and is now produced by community factories in 39 countries under open‑source guidelines.
The discussion highlights the widespread use of ceramic water filters in Brazil and notes similar products offered by an Indonesian manufacturer, emphasizing their practicality and cooling benefits. It explores the possibility of replicating the filtration effect with cement‑based materials, citing the natural permeability of limestone and the ease of shaping cement composites. Personal experience with pump‑driven ceramic filters is mentioned, and multiple external sources are provided for further information, reflecting a generally informative and exploratory tone toward low‑tech water filtration solutions.
Interview with Amit Patel, Creator of "Solar Realms Elite"
Amit Patel created the BBS door game Solar Realms Elite (SRE) in 1990 and later worked on programming, scientific computing, data analysis, simulation, AI, and web software. He began programming on a TRS‑80, then a Commodore 64, and learned Turbo Pascal, C, C++, and Prolog on an IBM PC‑XT; high‑school curricula included BASIC, Pascal, COBOL, and FORTRAN on a VAX 11/750.
Key technical aspects of SRE:
- Custom UI toolkit with menus, overlapping windows, keyboard shortcuts, ANSI‑color optimization, and precise formatting.
- Cooperative‑thread multitasking for gameplay, status bar, and sysop commands.
- Memory overlays and RAM‑efficient design for BBS sharing.
- Experiments in encryption, economics, game theory, and simulation.
Patel’s other BBS title, Planetary Conquest, explored discrete objects, variable maps, and arrow‑key screen navigation, but received limited development. He sold SRE and related games as shareware, estimating over 1,500 registrations (≈ $6 k / yr) and handling support, versioning, anti‑piracy, and marketing. After a 1996 hard‑drive loss and a 15‑year “detour” into non‑gaming fields, he now focuses on interactive text‑based tutorials for game development.
The remarks convey a nostalgic tone, recalling early contributions at a major tech company and personal involvement with a long‑running BBS system. They emphasize appreciation for pioneering work that created visible features and for enduring community‑driven platforms, reflecting fond memories of past technology experiences rather than critique or controversy. The overall sentiment is positive and reminiscent, focusing on the value of those early innovations and lasting connections.
The discussion highlights strong enthusiasm for recent advances that allow large‑scale models to run on consumer hardware, noting impressive capabilities despite modest resources. A common concern is that many current models overthink, leading to excessive token usage and slower performance, especially on dense architectures. Participants describe efforts to adjust reasoning‑effort settings, use prompts or tooling to limit unnecessary thinking, and compare models on speed versus thoroughness. Overall, there is optimism that continued refinement and hardware improvements will balance efficiency with the high‑quality reasoning demonstrated so far.