Hacker News, Distilled

Reinventing the Database

• Many commenters argue the system is effectively “a database”: in‑memory objects plus snapshots, transaction log, indices, and Raft replication.
• Several point out that if you’re writing a snapshotter, WAL/transaction log, recovery, indexing, and migrations, you’ve recreated core DB functionality, often with weaker durability and fewer tools.
• Others note this pattern is well known (Prevayler, bknr.datastore, NUMA systems, AS/400, actor/event-sourcing systems, Erlang/Orleans, HashiCorp tools).

Why Not Use Existing Databases?

• Strong push toward “boring tech”: Postgres/MySQL/SQLite/Redis are viewed as simpler, better understood, easier to hire for, and battle-tested.
• Multiple people say colocation (DB on same machine or Unix socket, or SQLite + replication tools like Litestream/rqlite/dqlite) would deliver similar latency without custom infra.
• Some say Redis is ideal as a cache, not a primary durable store; others report long, successful Redis or SQLite use in production.

Complexity, Reliability, and Operations

• Critics highlight hidden complexity: Raft round-trips, concurrency via mutexes, crash consistency, log corruption, snapshots, upgrades, and cross-version compatibility.
• Concerns about incident response, recovery from edge cases, and implementing safe migrations without SQL tooling.
• Some infrastructure engineers affirm the architecture is viable but emphasize upgrade and evolution hazards.

Startup Phases and Developer Productivity

• The author’s framing: optimize for early “Explore” phase with in‑memory store; later “Expand” by adding Raft rather than rewriting to a transactional DB.
• Several disagree, saying relational DBs actually make exploration easier due to schemas, migrations, and powerful queries; switching later is common and manageable.

Performance, Cost, and RAM

• Debate over whether saving serialization/DB round-trips meaningfully improves performance for such workloads.
• Some worry about RAM cost and inefficiency if replicated in-memory state grows large; others stress that modern machines can hold substantial RAM and many apps never outgrow a single box.

Attitudes Toward Experimentation

• Many call this textbook overengineering and a maintenance nightmare for typical web apps.
• A minority welcome experimentation and non-SQL approaches, seeing value in challenging defaults, especially when built on existing Raft and datastore libraries rather than fully from scratch.

Study findings and perceived risk

• Many note a reported “3–5x” increased risk sounds dramatic but may still mean a small absolute risk, especially per year; lifetime risk could be more meaningful.
• Several criticize the study for not distinguishing consumption methods (smoked vs vaped vs edibles) or adequately controlling for confounders (other drugs, activity, socioeconomic status, etc.), calling its interpretability “unclear.”
• Others argue large undifferentiated samples can still be useful, and that any combustion inhalation is already known to be harmful.

Smoke vs vaping vs edibles

• Broad agreement that inhaling smoke of any plant is likely harmful (COPD, cancer).
• Some think risks are mainly from smoke, not cannabinoids, and expect vaping or edibles to be much safer.
• Others counter that vaping cannabis can still irritate lungs and potentially contribute to COPD; individual experiences differ.
• Concerns raised about vape extraction solvents, cartridge quality, terpenes (e.g., myrcene flagged in California), and pesticide contamination, including in legal markets.

Addiction, cognition, and health effects

• One side claims cannabis is not physically addictive and far milder than nicotine; addiction framed as mostly psychological, comparable to sugar or video games.
• Others cite recent public health guidance and studies calling cannabis physically addictive for a subset of users, with meaningful withdrawal and life impact.
• Multiple comments reference evidence that heavy or early-onset use can impair cognition or “make you dumber,” especially under 25, with partial or full reversal unclear.
• Debate over long-term presence of THC vs inactive metabolites; some conflate detectability with ongoing effect, which others dispute.

Comparisons to other substances

• Frequent comparisons with tobacco, alcohol, caffeine, and sugar.
• General sentiment: smoked cannabis likely less harmful than cigarettes due to lower volume and chemistry, but not harmless; alcohol seen as socially and medically more damaging overall.
• Some note smoked and processed meats also have carcinogenic links, reinforcing that combustion byproducts are broadly risky.

Policy, stigma, and autonomy

• Strong strain of defensiveness attributed to decades of criminalization, racism, and propaganda around cannabis.
• Many support legalization but want honest communication of risks, not minimization by pro-cannabis advocates or exaggeration by prohibitionists.
• Recurrent theme: adults should control their own bodies, but public use (smell, secondhand smoke, parks) and impaired driving raise legitimate concerns.

Driving and functional use

• Consensus that driving high is worse than sober; disagreement on how much worse and on study quality.
• Anecdotes of highly functional daily users coexist with worries that chronic heavy use, even if “productive enough,” still likely reduces potential or masks mental health issues.

Wireless vs. Wired Communication

• Several commenters ask why not use Wi‑Fi / RF to cut more wiring.
• Most responses oppose this for critical systems: higher latency, greater susceptibility to interference and jamming, no shielding, and much larger attack surface.
• EMI in EVs is already problematic (e.g., AM radio issues); adding more RF for safety‑critical links is seen as risky.
• Wireless is already used in constrained niches (tire‑pressure sensors, some battery management inside packs), but commenters stress it’s for non‑critical or hard‑to‑wire cases.
• In home/hobby contexts, some embrace RF for convenience; others deliberately avoid Wi‑Fi for security and reliability, preferring wired or protocols like Zigbee/Z‑Wave.

Zonal ECU Architecture & Failure Modes

• Discussion compares domain‑based ECUs (per function) vs zonal (per physical area).
• Concern: a zonal ECU failure could knock out many unrelated functions in that zone (locks, windows, seats, fans).
• Others say Rivian keeps safety‑critical domains (drive, battery, access, autonomy, infotainment) on dedicated ECUs; zones handle “small but important” loads.
• Multiple comments note that distributed real‑time systems are hard: state management bugs already appear in existing cars.
• Some advocate “dumb” edge I/O with centralized logic to simplify reasoning; others point out this re‑introduces single points of failure and wiring.

ECU Count, Modularity, and Suppliers

• Many like the reduction from dozens/hundreds of ECUs; others note legacy designs allowed reusable modules across models and suppliers with different safety/reliability levels.
• Rivian’s approach is seen as enabled by strong in‑house software and modern heterogeneous processors, whereas traditional OEMs are constrained by tiered suppliers and organizational inertia.

Wiring Length, Copper, and System Voltage

• Back‑of‑the‑envelope math in the thread finds Rivian’s 1.6‑mile / 44‑lb copper reduction plausible.
• Commenters doubt the quoted 20% material and 15% carbon savings come from copper alone; broader simplification is implied.
• Several point to 48V low‑voltage systems (as in Tesla) as the next major step: same power with far lower current, thinner wires, and less copper.
• Others discuss safety limits around ~50–60 V DC, tradeoffs, and the complexity of multiple voltage rails.

Broader Themes and Comparisons

• References to Tesla’s past wiring‑reduction plans and Cybertruck architecture; curiosity about Tesla’s “unboxed” distributed ECUs vs Rivian’s more centralized zones.
• Some feel modern cars are over‑complex (hundreds of ECUs, massive compute for cameras/radars); others note regulations now require advanced driver‑assistance anyway.
• One commenter links wiring complexity to Conway’s law: harness layout mirrors organizational and supplier boundaries.

Scope and nature of the room checks

• Multiple commenters say daily room “checks” are now common in major Vegas hotels after the 2017 Mandalay Bay shooting; some have personally experienced them elsewhere, others say they have not, so prevalence is disputed.
• Officially, housekeeping is supposed to enter every room within ~24 hours; if housekeeping doesn’t, security checks.
• For DEF CON room blocks at Resorts World, shared internal docs show a stricter protocol: security checks Defcon rooms regardless of housekeeping and is given pictures of “hacking tools” (USB sticks, breadboards, soldering irons, Wi‑Fi APs, Flipper Zero, etc.).

Reports of abusive or incompetent enforcement

• Many posts distinguish normal post‑2017 “room checks” from what happened at Resorts World this year.
• Specific allegations: aggressive guards demanding ID, threatening trespass/arrest, detaining guests, coercive searches, rummaging in luggage, confiscating DEF CON badges and lockpicks, and targeting anything “technical‑looking.”
• Several argue this went far beyond safety checks for weapons and functioned as harassment or an attempt to push DEF CON guests out despite having sold them a room block.

Security rationale vs. “security theater”

• One camp: hotels face huge liability (e.g., post‑shooting settlements), so regular checks for guns, explosives, severe property damage, or dead/unresponsive guests are a reasonable tradeoff. “Do not disturb” is framed as courtesy, not an absolute right.
• Another camp: checks won’t stop a serious attacker who can time luggage and setup between inspections; focusing on USB drives and soldering irons is technically meaningless. They see this as security theater and corporate CYA that erodes privacy.

Privacy expectations and legal/ethical concerns

• Strong disagreement on what privacy guests should reasonably expect: some liken hotels to rentals that should honor DND signs; others say hotels and landlords routinely inspect spaces.
• Comparisons to other countries (e.g., Germany, EU) where such checks might be illegal or require stronger notice.
• Suggestions include filing complaints with Nevada’s licensing board, boycotting Hilton/Resorts World, and publicizing incidents.

Impact on DEF CON and venue choice

• Several note DEF CON has already become more corporate and less “edgy,” and this reinforces that trajectory.
• Some argue Vegas is uniquely suited (scale, 24/7, co‑location with Black Hat/BSides); others say plenty of US and non‑US cities could host without this level of surveillance.
• A few predict that antagonizing a technically capable, previously neutral crowd is a security mistake that could backfire on the hotel.

Direct nuclear-to-electric conversion ideas

• Discussion centers on bypassing the “thermal middleman” (steam cycles) via:
  • Radiovoltaics / betavoltaics and thermo-photovoltaics that convert ionizing or IR radiation directly to electricity, but with low absorption and power density issues.
  • Direct capture of charged fusion products (e.g., Helion-style coils where plasma expansion induces current).
  • For fission, most energy is in fast, charged daughter nuclei; capturing that as electrical potential instead of heat is conceptually possible but technologically unclear.

Fusion approaches and skepticism

• Fusion is described as “infinitely harder” than fission, especially for net-positive energy and direct conversion.
• Helion’s pulsed D–D / D–He³ concept is debated:
  • Proponents highlight low neutron fraction and direct electromagnetic capture.
  • Critics argue schedules have slipped, material/energy-flux limits may be insurmountable, and many fusion startups resemble overhyped VC plays.

Nuclear batteries and betavoltaics

• Existing betavoltaic cells (e.g., Ni‑63 in diamond) offer ~100 µW in tiny volumes:
  • Energy density over decades is huge, but instantaneous power is far below phone-level needs.
  • Could suit low-duty, intermittent devices, potentially with supercapacitors.
• Safety and regulation:
  • Beta emitters are relatively easy to shield but dangerous if inhaled/ingested as dust.
  • Widespread consumer use conflicts with non-proliferation, tracking, and waste rules.
  • Some argue they’d be easier to monitor than heavy metals; others stress regulatory and security burdens.

Economics, efficiency, and waste heat

• Conventional reactors convert ~1/3 of fission heat to electricity; everything is “a big nuclear boiler.”
• Main roadblock is cost and complexity (thousands of long-lived, high-spec welds; huge skilled labor needs), not thermodynamic efficiency alone.
• Direct conversion is framed as the kind of breakthrough needed to make nuclear economically competitive.
• District heating and hydrogen production from reactor heat are discussed:
  • District heating faces infrastructure, siting, and perception barriers.
  • High-temperature electrolysis/thermochemical H₂ could use heat more directly but demands extreme temperatures and still competes with cheap intermittent renewables.

Safety, regulation, and risk perception

• Radiation fatalities are rare under strict regulation; some see this as proof safety works, others as evidence of overregulation and excessive cost.
• Comparisons are made with untracked heavy-metal pollution, suggesting societal risk trade-offs are inconsistent.

Speculative and niche concepts

• Fission-fragment rockets as high-Isp drives (and possible direct power sources) are discussed, along with RTGs, plasma scintillator schemes, and even black-hole/Hawking-radiation thought experiments.

Exploit characteristics

• Vulnerability is in AMD CPUs’ handling of a model-specific register (MSR); with ring 0 (kernel) access, SMM configuration can be modified even when the SMI lock is set.
• This enables arbitrary code execution in System Management Mode (SMM), effectively ring −2, below the OS and hypervisor.
• Discussion stresses: you must already have ring 0 code execution, but this bug turns a kernel compromise into a stable firmware‑level foothold.

Persistence and what actually breaks

• Multiple commenters clarify that the CPU itself has no writable, persistent storage for attacker code (microcode is ROM + signed updates).
• Persistence is expected via motherboard firmware (BIOS/UEFI/flash), or bootloaders, not the CPU die.
• Some articles state you may have to “throw away the computer”; commenters push back that in practice you’d replace or reflash the motherboard/BIOS, not the CPU.
• Recovery options like dual BIOS or external flash programming are discussed; feasibility depends on whether compromised firmware allows reflashing. Overall remediation complexity is considered high.

How severe is it?

• One camp: “catastrophic” because it bypasses Platform Secure Boot protections, can hide from the OS and AV, and can survive OS reinstalls.
• Other camp: impact is limited because ring 0 is already game‑over on typical desktops; this mostly matters where ring 0 shouldn’t imply firmware control.
• General consensus: technically serious, but real‑world risk depends heavily on threat model and prerequisites.

AMD’s response and Ryzen 3000 controversy

• AMD plans firmware fixes for most affected products (especially datacenter), but lists Ryzen 3000 (“Matisse”) desktop CPUs as “no fix planned.”
• Intense disagreement over whether ~5‑year‑old desktop CPUs are “old” enough to drop security support.
• Some argue there are still large installed bases and that not fixing them is reputationally damaging and consumer‑hostile; others say age, low margin, and ring‑0 prerequisite make the risk acceptable.
• EU/EEA consumer‑protection time limits (2–5 years) are mentioned; some think this could justify demanding remedies.

Cloud / virtualization angle

• Concern: could guests escape into host/firmware?
• Counterpoints: typical VMs lack direct MSR access, and major providers likely patched quickly; impact is “unclear” but seen as more relevant than desktops if it exists.
• In SEV/PSP models, this is framed as a foundational breach of the intended separation between owner‑controlled guests and vendor‑controlled root of trust.

Broader trust and policy themes

• SMM, PSP/ME, and hidden firmware are criticized as inherently dangerous attack surfaces that undermine device owners.
• Others view the exploit as a potential way to disable or work around vendor‑controlled “trojans,” enabling more user control (e.g., coreboot‑style goals).
• Some call for laws mandating open firmware source, open documentation, and owner‑controlled flashing, with changeable cryptographic keys.

How it works

• Client runs code on a CPU-only Linux machine; a userspace library intercepts CUDA / GPU API calls.
• Intercepted calls and GPU commands are forwarded over TCP to a remote GPU, making the local system believe a GPU is directly attached.
• No kernel drivers or eBPF are involved; it’s LD_PRELOAD-style API remoting, not PCIe tunneling.
• Only GPU-related state lives remotely; files, packages, and CPU execution stay on the client instance.

Performance, latency, and bottlenecks

• Network adds latency, especially for GPU VRAM ↔ RAM transfers and training workloads.
• Provider claims inference performance (e.g., BERT) is close to local, with training slower but being optimized.
• Concerns that datasets larger than VRAM would cause heavy I/O each epoch; creators acknowledge and say they’ve added optimizations.
• Some say 10–30 MB/s per GPU is typical for their workloads, so 10 Gbps links may suffice.
• Gaming and highly interactive graphics are considered impractical due to latency.

Use cases discussed

• On-demand GPUs for development without paying for GPU time when only doing CPU work.
• Transparent acceleration for GUI and desktop apps (Matlab, CAD, Blender render farms).
• ML inference, some training, video transcoding, and potentially hash cracking.
• Potential for finer-grained GPU sharing or fractional GPUs.

Comparisons and related tools

• Compared to AWS GPU instances, Nitro, TPUs, Ray, Juice Labs, rcuda, qCUDA, virtio-gpu, and other GPU-over-network systems.
• Some see it as a more generic or more transparent alternative to cluster frameworks.

Pricing, access, and hosting

• Currently beta and free (T4 GPUs); future pay-as-you-go model planned.
• A100/H100 not yet generally available; pricing “to be determined.”
• No self-hosting yet, but strongly requested and considered for the future.

Limitations and open questions

• Linux-only for now; no Vulkan/OpenGL or DirectX; partial library support (tested with PyTorch/HF; issues with some others).
• Behavior and cleanup on GPU reset, VRAM residue, and network instability are raised but not fully resolved.
• Some skepticism about real-world value for serious training workloads and concerns about subscription-style “cloud everything” models.

Purpose of .internal

• ICANN has permanently reserved .internal from the public DNS root for private-use naming, analogous to private IP ranges (e.g., RFC1918).
• No one will ever be able to register .internal on the public Internet, so organizations can safely use names like service.internal without future collisions.
• This is partly a reaction to past surprises where pseudo‑TLDs later became real (e.g., .dev), breaking internal setups.

Relation to Other Special or “Private” TLDs

• .local is reserved by IETF RFC 6762 for mDNS/Bonjour, not general internal DNS; using it for other purposes conflicts with mDNS and can break systems.
• .home.arpa is an IETF‑reserved home-network domain, but some find it too long/ugly versus very short TLDs like .l or .lan.
• Other reserved TLDs (.example, .invalid, .test, .localhost) have more specialized purposes; .internal fills a generic “private namespace” gap.
• There is also .ALT (RFC 9476) for non-DNS “alt roots”; some see it as overlapping with a proposed .pseudo, but use cases remain debated.

Private TLD vs Public Domain for Internal Services

• Pro‑.internal:

  • Makes “invalid states unrepresentable”: you cannot accidentally expose .internal to the public root, reducing misconfiguration and data leakage.
  • Acts as a clear signal that something must remain private; helps audits and tooling detect unintended egress.
  • Useful when buying/renting a public domain is undesirable or impossible, or when you don’t trust long‑term control of a rented domain.

• Pro‑public domain (e.g., internal.example.com):

  • Easier TLS: can use public CAs (Let’s Encrypt, ACME DNS) instead of running a private CA.
  • Works seamlessly with BYOD, contractors, VMs/containers, phones, etc. that don’t trust internal CAs.
  • Keeps the option to expose services later without renaming or re‑certifying.
  • Avoids complex private DNS and split-horizon setups that many small orgs struggle with.

TLS, CAs, and Security Trade‑offs

• .internal cannot use public CAs by design; X.509 trust breaks if multiple organizations can get certs for the same name, so a private CA is required.
• Many note operational pain: distributing CA roots to all clients (especially mobile), inconsistent trust stores (OS vs browser vs Java), and managing an internal PKI.
• Others argue “encrypt everything” is still important: LANs and “trusted” VPCs are frequently compromised; zero‑trust models treat internal networks as hostile.
• Use of public domains exposes names via certificate transparency logs; critics see this as information leakage, supporters call it an acceptable trade‑off.

Operational and Usability Concerns

• Cookie/storage collisions and name clashes across organizations are possible with shared .internal names, just as with RFC1918 IPs; mitigations include longer, org‑scoped names (e.g., service.company.internal).
• Browsers currently treat unknown TLDs as search terms; some want special handling so foo.internal behaves more like localhost.
• Many home/SMB network setups still lack good DHCP+DNS integration; reserved internal TLDs could simplify this if consumer routers used them consistently.

Overall context: expanding Russian internet controls

• Commenters see the Signal block as another step in Russia’s broader effort to control online information.
• Many say the Russian internet is already “close to unusable” for Western content without VPNs; some add that even with VPNs, captchas, throttling, and bans make use difficult.
• Early blocks like LinkedIn are mentioned as precedent; YouTube is said to be throttled and even fully cut off at times.
• Domestic video and messaging alternatives exist (e.g., RuTube), but are criticized as lacking large, uncensored content catalogs.

Status of other platforms: Telegram, WhatsApp, YouTube, TikTok

• Telegram: reported as not blocked and now “vital information infrastructure.” People use it heavily for news, including from all sides of the war.
• Conflicting claims on WhatsApp: some say it’s “completely blocked,” others say it worked recently and is not blocked; status is unclear.
• YouTube: reports of long-term throttling, with some saying it was recently “shut off completely.” Proxies (Invidious, LibreTube) are used to access it.
• TikTok is described as increasingly important for Russian state messaging, fitting a broader realignment away from Western platforms.

Motives: censorship, security, and digital sovereignty

• Many argue the regime cannot tolerate non-state-controlled media, especially during military setbacks (e.g., in Kursk Oblast).
• Some see this as preparation for harsher moves, including worries about increased nuclear risk, though this is speculative within the thread.
• Others frame it as following China’s model: cutting dependence on Western services, growing domestic ecosystems, and enabling tighter surveillance.
• A reported plan to block Google, Android, and possibly iOS is discussed; skeptics doubt full smartphone disconnection, but others note China’s AOSP-based approach as a model.

Tools and workarounds: VPNs, Tor, protocols

• VPNs are widely known even among non-technical users; some seek routers with built-in VPNs.
• Signal’s built-in “censorship circumvention” and community-run proxies are mentioned as partial workarounds.
• Some distrust Tor and Signal, alleging intelligence-agency control or backdoors; others do not address or endorse these claims.
• There is criticism of Signal’s centralization and anti-federation stance; XMPP, Matrix, Simplex, Session are proposed as more resilient, decentralized alternatives, with specific XMPP software and onboarding options referenced.

Comparisons to democracies

• Several note that democratic countries (UK, EU, Australia, Belgium) also contemplate weakening encryption.
• Signal’s public stance of leaving markets rather than undermining privacy is cited, with some skepticism about how firm such positions would be in practice.

Overall response

• Many commenters like the idea of layering LLMs on top of OCR, especially for long, low‑quality scans (old books, archives) where manual cleanup is painful.
• Others feel Tesseract is outdated and that newer OCR or vision models alone can now do better.

---

Tesseract and other OCR engines

• Tesseract is praised for being free, CPU‑friendly, and fast, but accuracy is a recurring complaint—especially with digits, punctuation, plus signs, and non‑Latin scripts.
• Some note that tuning DPI (around 300) helps, but still hit issues like “77” → “7” or “+40%” → “440%”.
• Alternatives mentioned: EasyOCR, PaddleOCR, Surya, TrOCR, Nougat, Donut, and commercial APIs (Google, Amazon Textract, Azure).
• For Arabic, Japanese, and German, several report that commercial cloud OCR is clearly superior to open‑source options but at the cost of dependency and privacy.

---

LLM‑aided correction: strengths and weaknesses

• The LLM layer shines on prose: fixing obvious OCR typos, normalizing punctuation, and turning noisy scans into readable markdown/epub text.
• It is much less trustworthy for numbers, names, and contract‑like documents; several insist such outputs must be manually checked, often field‑by‑field.
• Multi‑stage prompting and narrow tasks per step matter more than model choice. Prompt engineering is key.
• Some show examples where an LLM correctly “rescues” Tesseract errors using domain context (finance, road names).

---

Vision LLMs vs OCR+LLM pipelines

• Opinions diverge:
  • Some claim GPT‑4V/4o, Claude, Gemini Flash, and specialized models (e.g., Florence‑2) already outperform Tesseract/EasyOCR for many documents, including equations and tables, and can work directly from PDFs or page images.
  • Others find small open multimodal models slower and less accurate than classical OCR, especially on symbols, dense tables, and weird layouts.
• There’s debate over cost: some say page‑image → GPT‑4o‑mini is comparable to OCR+LLM; others think full VLM OCR is still orders of magnitude more expensive.

---

Hallucinations, safety, and trust

• Multiple commenters worry about “silent” semantic errors (numbers, legal terms) analogous to the historic JBIG2 Xerox bug; they prefer visibly broken OCR over polished but wrong text.
• LLM hallucinations and safety filters (e.g., refusing violent content) are seen as real risks for sensitive documents like police reports or contracts.
• Attempts to detect prompt‑injection or safety interference via additional prompts are viewed as only partially reliable.

---

Complex layouts, tables, and handwriting

• Multi‑column layouts, forms, dense tables, charts, and scientific formulas remain difficult. Some recommend specialized models (e.g., for formulas or invoices) plus a final LLM cleanup.
• Handwriting OCR is still weak overall; certain vision transformers and GPT‑4o work well on neat handwriting, but large personal archives and cursive remain challenging.

Mathematical optimal base vs. real hardware

• Several comments re-derive the “optimal radix” result: minimizing base × digits leads to base = e using calculus; among integers, 3 is closest to e.
• Related reformulation: minimizing x / log x over x > 1 gives minimum at x = e; base-3 is the best integer.
• Some note that this “radix economy” is a toy cost function and ignores hardware realities.

Physical / engineering constraints of ternary

• Major theme: ternary gains in information density (~1.58 bits per trit) are modest and often outweighed by:
  • Harder discrimination between 3 voltage/charge levels.
  • Greater susceptibility to noise and tighter tolerances.
  • Likely need for higher supply voltages and more power dissipation.
  • Increased implementation complexity for gates and adders.
• Disagreement over whether ternary must use negative voltages; some argue three positive levels suffice, others stress that intermediate levels are still problematic.
• Multiple comments emphasize that binary CMOS has been optimized for decades; designing fast, low-power multi-level logic at GHz is a different and harder problem.

Existing multilevel and “ternary-like” technologies

• NAND flash already stores multiple bits per cell via multiple charge levels (SLC/MLC/TLC/QLC), but this is used only for storage, with binary interfaces and substantial analog and ECC overhead.
• High-speed links (Ethernet PAM-5, PCIe PAM-4, USB PAM-3, high-order QAM) use multi-level signaling for bandwidth, but internal computation remains binary.
• Tristate / Hi-Z buses and open-collector/collector systems are discussed as three-state at the electrical level but still fundamentally binary in logic.

History and myths about ternary computing

• The Soviet Setun machine is cited as a real ternary computer, though one comment notes it encoded trits using binary pairs.
• Claims that the USSR “bet on ternary and lost the space race” are widely dismissed as fabrication or exaggeration.

Programming, logic, and architecture issues

• Ternary control flow would naturally have three-way branches; some see this as occasionally useful (e.g., < / = / >, true / false / error), but others think most real branches are still binary (e.g., loop exits).
• Some speculate about richer “tritwise” operations and ternary-native data types, but concrete killer examples beyond density are not provided.
• Discussion of minimal ternary gate sets and balanced ternary arithmetic shows theoretical richness but also practical complexity.

Critiques of the article and overall sentiment

• Many readers view the article as overselling ternary, leaning on simplistic arguments like “more than yes/no.”
• Core consensus: mathematically, ternary (and e) is elegant; practically, binary remains superior given current device physics, tooling, and cost models. Enthusiasm is mostly theoretical; skepticism dominates on engineering grounds.

Boeing and Starliner Reliability

• Many see Starliner’s problems as part of a broader pattern of Boeing quality and safety failures (aircraft and space), arguing the company “should stop getting contracts” until it proves competence.
• Others note Boeing’s entrenched role as a defense contractor and NASA partner makes major change or loss of contracts unlikely.
• Some argue this specific situation is as much a NASA program/management failure as a Boeing one, since NASA historically acted as systems integrator and certifier and should not have allowed such a configuration to fly.

NASA’s Role and Commercial Crew Model

• One view: NASA bears responsibility for supervising integration, certifying vehicles, and ensuring no in-orbit “critical updates” are needed for a baseline mission.
• Counterview: Under Commercial Crew, providers own/operate spacecraft and NASA is more like a customer buying rides, deciding only whether it’s safe enough to fly its astronauts.

Software, “Bricking” Risk, and Confusion

• Discussion centers on reports that Starliner’s current flight software cannot perform automated undocking and reentry, and that an in-orbit software update is being considered.
• Several commenters question how a software update could “brick” an ISS docking port or Starliner itself, noting robust update/rollback patterns are well-known.
• Others stress that docking systems involve stressed mechanical parts; unvalidated control software could cause physical damage that cannot be “reset,” so NASA’s caution is seen as justified.
• Some call the “bricking the ISS port” framing clickbait or misreporting, saying details and risks remain unclear.

Corporate Accountability and Criminal Law

• Strong sentiment that Boeing leadership should face serious personal consequences for safety failures; others note incompetence and bad leadership are not typically crimes.
• Debate over incarceration vs. other sanctions:
  • One side emphasizes deterrence via prison time for executives.
  • Another argues increasing likelihood of enforcement and stronger regulation matter more than harsher penalties.
  • Ideas include banning negligent executives from decision-making roles or imposing severe operational sanctions on corporations.

Dependence on SpaceX and Alternatives

• Some argue NASA should favor SpaceX given its track record, while others worry about reliance on a single private provider.
• Proposals range from forcing a Boeing breakup to nationalizing SpaceX; critics warn such moves would punish risk-taking innovators and could stifle competition.

Confirmation and Immediate Reactions

• Death was confirmed via family updates on a fundraising page and on his blog.
• Some early confusion over timing and sources was quickly resolved by direct statements from relatives.
• Many express shock at how fast things progressed from the hospice post to his death and emphasize relief that his suffering is over.
• Condolences to his wife, infant daughter, and extended family are widespread.

Who Jake Was and Why HN Cares

• Several ask who he is and why there is a site-wide black bar.
• Others explain he was a long‑time HN participant with very high karma, an active blogger, novelist, and researcher, whose detailed writing about his cancer journey had been heavily discussed on HN.
• Some note that “black bar criteria” are informal and community-/moderator-driven; being a long‑time, widely read community member is considered sufficient.

Writing, Agency, and Over‑/Under‑Treatment

• His blog chronicled the diagnosis, treatment choices (including surgeries, radiation, and missed opportunities for early chemo), and later reflections on regret and overtreatment.
• A much‑praised essay argues that extreme “agentic” pursuit of every possible treatment can itself be harmful, especially under uncertainty.
• Commenters highlight how unusually candid, analytic, and emotionally direct his and his wife’s writing was.

Debate on FDA Regulation and Experimental Access

• One major thread debates whether terminal patients should have broader access to experimental drugs.
• Pro‑access side: terminal patients should be free to choose; current rules are over‑cautious, cost lives, and are shaped by institutional self‑protection.
• Skeptical side: regulations were “written in blood”; loosening rules risks exploitation, unsafe treatments, erosion of trust in medicine, and biased trials.
• Sub‑debates cover supplements vs. drugs, fraud vs. informed consent, clinical trial ethics, and the tension between utilitarian calculus and political reality.

Reflections on Cancer, Suffering, and Death

• Many share personal cancer stories (parents, siblings, their own diagnoses), contrasting rapid vs. drawn‑out deaths and the trade‑off between time to prepare and prolonged suffering.
• Themes include the meaning of suffering, human adaptation to chronic pain, and how people often display unexpected strength once “there is no choice.”

Digital Legacy and Memorialization

• Discussion touches on what happens to accounts after death and how to plan digital legacies, with links to checklists and guides.
• Some note the value his HN comments and blog may have for his daughter in the future.
• A side discussion considers moderating hostile blog comments on end‑of‑life posts.

Family Participation and Ongoing Advocacy

• Family members participate, thanking the community and describing how much the online response meant.
• His wife commits to continuing advocacy for FDA and clinical‑trial reform and invites collaboration.

Scope: EU-only and “malicious compliance”

• Apple enables alternative browser engines only in the EU because law compels it there; no similar pressure elsewhere.
• Many see Apple’s response as hostile or “malicious compliance”: lots of complexity, EU-only binaries, and feature carve‑outs rather than a straightforward global opening.
• Some argue this will eventually spread worldwide; others note EU is a relatively small share of App Store revenue, so Apple may limit changes to that region.

Security, privacy, and monopoly incentives

• One camp accepts Apple’s framing: alternative engines and app stores increase attack surface, support costs, and risk of data-harvesting browsers (e.g., social networks shipping “browser” shells).
• Others counter that:
  • iOS already sandboxes apps, so browsers should not endanger the whole phone.
  • Safari/WebKit and iMessage themselves have had serious vulnerabilities.
  • Chrome’s security record may be stronger, and current WebKit-based browsers already sync data and “phone home”.
  • “Security/privacy” is largely a pretext to protect App Store revenue and weaken PWAs/web apps that could bypass it.

Sandboxing, JIT, and Lockdown Mode

• WebKit runs with elevated privileges (JIT, multiprocess) outside normal app sandboxes; alternative engines will gain similar privileges under strict criteria.
• Lockdown Mode disables WebKit JIT system‑wide, cutting JS performance but reducing exploitability.
• Regular third‑party apps historically could not use JIT; WebViews do via separate processes.

Alternative app stores, support burden, and user behavior

• Some argue more stores/browsers will generate more breakage and support calls, with minimal upside for average users who are content with defaults.
• Critics reply that:
  • Desktop OSes and macOS handle multiple stores and browsers.
  • Apple already hosts malware occasionally in the App Store, so centralization isn’t a silver bullet.
  • Walled gardens should be opt‑in, not mandatory; technically literate users want the option.

New engine requirements and potential gatekeeping

• Requirements include: EU-only distribution, passing web platform tests, blocking third‑party cookies, and using memory‑safe languages or mitigations for web‑facing code.
• Commenters see these as:
  • Reasonable in principle for a high‑risk component like a browser engine, but
  • Vague enough (“features that improve memory safety”) to let Apple arbitrarily block engines, especially smaller ones.
• Some doubt even Safari/WebKit would fully meet the stated bar; others expect Apple must at least allow Chrome/Blink and Firefox/Gecko or face further EU action.

What OTranscribe Is (and Isn’t)

• Tool is a browser-based UI that helps with manual transcription: playback speed, easy pause/play, keyboard control.
• Does not perform automatic speech-to-text; users type everything themselves (confirmed in FAQ excerpt).
• Works offline if the site is preloaded; can be self‑hosted (MIT licensed) or saved as an offline web app.
• Praised for being simple, distraction‑free, and well-suited for interviews and travel/offline use.
• Some find it “too simple” for many modern use cases.

Expectations Around AI and Automation

• Several commenters initially assume it’s an automatic ASR tool and are corrected.
• Others are surprised it has no AI integration, but context is that it was written years ago before current AI wave and is not actively developed.
• Some argue manual transcription still matters, even with AI, for proofing, attribution, and handling edge cases.

Alternative Tools: Automatic Transcription & Diarization

• Many suggestions based on Whisper and derivatives:
  • CLI and libraries: Whisper, whisper.cpp (much faster on CPU), WhisperX, whisper‑diarization.
  • Hosted services/APIs: Spectropic (with diarization, some LLM post‑processing for speaker names), Audiogest, TurboScribe, VideotoTextAI, Talio.
  • Desktop/mobile: Aiko (iOS, offline Whisper), various macOS and Electron apps, oTranscribe+ (browser/Electron with Vosk via WASM), Pixel Recorder and Live Transcribe, FUTO’s Android tools, Transcribro.
• Several tools generate subtitles (SRT/VTT), handle YouTube downloads, or provide chat-with-transcript features.

Real-Time, Local-First, and Accessibility Use Cases

• Strong interest in:
  • Real-time, word-by-word transcription.
  • Fully local processing for privacy and for people who are hard of hearing.
• Some report good results with local-first apps and Android’s built‑in captioning/transcription; others still searching for open-source, punctuated, real‑time solutions.

Quality, Hallucination, and Post-Processing

• Whisper and similar models are viewed as high quality but can be slow on CPU and may hallucinate in dead air.
• LLMs can be chained after transcription to:
  • Remove filler words.
  • Correct errors, punctuate, and infer speaker names.
• One experiment with a multimodal LLM shows near‑perfect transcription with nuanced punctuation, but post‑processing pipelines can also “over-correct” phrasing.

Language and Dialect Issues

• OTranscribe itself is language-agnostic (you type whatever you hear).
• Multiple tools claim broad language support; specific mentions of Japanese and Brazilian Portuguese queries, with mixed clarity on accent handling.

Methodology and 7‑minute‑mile claim

• Many doubt that 7:00 min/mile (4:20 min/km) is the “most efficient” human running speed in any general sense.
• Objections: most adults cannot run that pace at all or only briefly; it corresponds to strong club‑level performance (near ~3:00 marathon).
• Several note likely sampling bias: data probably dominated by relatively light, trained runners, not the general population.
• Commenters say walking has a clear U‑shaped efficiency curve, but human running cost vs speed is relatively flat; “one optimal pace” may be overstated.

---

Running vs walking efficiency

• Distinction emphasized between:
  • Energy per distance (kcal/km) vs
  • Energy per time (kcal/hour, METs).
• Some personal analyses: calories ≈ proportional to distance × body weight; walking may use ~80% of the calories per distance compared to running.
• Faster speeds raise power output; many people hit cardiovascular limits long before any theoretical efficiency optimum.
• Efficiency is multidimensional: fatigue, joints, mental load, time in sun/cold, and time on feet all matter. For long days, a light run/jog can feel less tiring than long slow walking because you finish sooner.

---

Human endurance and persistence hunting

• Multiple references to research on human evolution: humans have unusually flat running‑efficiency curves, good cooling (sweat glands, “nakedness”), and excel at endurance over many speeds.
• Discussion of persistence hunting: humans jogging animals into heat exhaustion; contrasted with quadrupeds whose optimal gaits have narrower speed ranges.
• Anecdotes and analogies extend this to human‑vs‑human “endurance advantage,” but others point out tactical and technological factors make this unrealistic in modern conflict.

---

Training, fitness, and heart‑rate zones

• Many anecdotes: people who can walk 20–40 km but are destroyed by a short run; others who can run long at modest pace but can’t approach 7‑min miles.
• Age, body mass, and prior activity strongly affect feasible pace; some older runners doing high mileage still cannot hit 7‑min miles.
• Zone‑2 / MAF (low‑intensity, fat‑dominant) training is repeatedly mentioned as key to building distance capacity, even if it feels “too slow” and often includes walking at first.

---

Injury risk and biomechanics

• One side claims repetitive impact from running wears out knees (cartilage, meniscus) and should count as a deferred “efficiency cost.”
• Others cite a study (linked) finding no clear association between years of running, pace, or marathon counts and arthritis.
• Technique is highlighted: forefoot or mid‑foot strike, “natural running,” and stronger legs (e.g., squats) are said to reduce knee pain; downhill running is widely reported as hard on joints.

---

Weight loss, practicality, and psychology

• Multiple stories of substantial weight loss from long daily walks; walking is easy to sustain, integrate into commuting/errands, and doesn’t spike appetite as much as hard runs.
• Cycling is seen as mechanically efficient but less helpful for bone density and (for some) weight control vs walking.
• Rucking (walking with a heavy backpack) is noted as dramatically raising calorie burn.
• Several emphasize the mental benefits of running (focus, mood) even if it’s not calorically “better” than walking.

---

Units, metrics, and technical nitpicks

• Complaints about imperial units for speed and kcal instead of joules; some convert METs to W/kg and note 1 MET ≈ 1.16 W/kg.
• Clarifications about “calorie” vs “kilocalorie” and about correct dimensional notation (kcal/kg/h vs kcal/(kg·h)).
• Some argue the headline violates Betteridge’s law; others note the article conflates “energy per time” with “energy per distance,” confusing the central question.

Legality of “hacking back”

• Many commenters note that retaliatory hacking likely violates the CFAA and similar laws, even when targeting scammers abroad.
• Some want explicit legal carve‑outs or licensing schemes for anti‑scam operations; others strongly oppose exceptions, citing risk of abuse, framing innocents, and selective enforcement.
• Several point out disclaimers (“this isn’t my work / not condoning”) are mostly CYA and may have limited legal value.

Vigilantism vs. formal law enforcement

• Strong emotional support for hitting scammers back; some even fantasize about extreme responses, especially against hospital ransomware.
• Others warn that vigilante justice is dangerous: poor evidence handling, emotional overreaction, risk of targeting innocents, and erosion of rule of law.
• There’s debate over whether society has a “natural right” to justice that justifies vigilantism when the state is ineffective; others counter that this leads toward lynching or anarchy.

Jurisdiction and international limits

• Many stress that scammers operating from China, Russia, or similar jurisdictions are hard to prosecute; extradition is rare and depends on local politics, not just treaties.
• Some argue that if a state won’t or can’t act, practical impunity results even if the act is “illegal on paper.” Others reply legality and enforceability are distinct.

Telecom, SMS infrastructure, and incentives

• Commenters criticize carriers for profiting from scam traffic and having little incentive to stop it beyond regulation.
• Discussion of STIR/SHAKEN and number reputation as partial progress for calls, but SMS/MMS remain a “giant hole”.
• Proposals include:
  • Opt‑in for international calls/texts in the US.
  • Stronger spam filtering and liability for carriers.
  • Even rebuilding messaging with secure, non‑spoofable, end‑to‑end systems.
• Some note that easy reporting (e.g., “report scam” like *69) is missing, but others warn that without resources, more reports just add noise.

Human impact and ethics

• Recognition that scams cause severe emotional and financial harm, sometimes leading to suicide.
• Counterpoint: many call‑center “scammers” are themselves trafficked and coerced, complicating blanket calls to “attack” them.
• Thread raises need for ethics in CS education; others argue ethics courses change little when crime is so easy and lucrative.

Operational and attribution risks

• Several warn about weak OPSEC when going after scammers; retaliation can include serious counter‑attacks or SWATting.
• Misattribution examples (e.g., stale DNS records, compromised third‑party sites) show how easy it is for amateurs to hit the wrong target.

Scope of the NPS Rule

• NPS definition cited: “High clearance 4WD” = SUV/Jeep/truck with ≥15" rims, ≥8" clearance, a transfer case that can switch 2WD/4WD and high/low range; AWD explicitly excluded.
• Many note this excludes capable full‑time 4WDs (e.g., Land Cruisers, G‑Wagen–type vehicles, some EVs) and any AWD EV with no transfer case.
• Rationale discussed: reduce rescues, trail damage, and ranger workload from people driving in over their heads.

Why Rangers Might Prefer a Simple “4WD Only” Rule

• Posters argue NPS needs an easy, enforceable line that doesn’t require rangers to know every model/trim and drivetrain nuance.
• Some think the rule is conservative but appropriate; others see it as technically crude and potentially unfair to capable AWDs (e.g., Subarus).

AWD vs 4WD: Technical Debate and Confusion

• Broad consensus: terms are marketing-driven and inconsistent; actual capability depends on:
  • Locking/limited‑slip differentials and transfer case
  • Low‑range gearing
  • Ground clearance, approach/departure angles, suspension travel
  • Tire strength and tread
• Disagreement on importance of locking diffs vs clearance:
  • Some say lockers are critical in rocks, mud, sand; others say clearance and articulation matter more and lockers mainly compensate for poor suspension travel.
• Many AWD systems rely on brake‑based torque vectoring and clutched couplers; performance ranges from “great in snow/ice” to “overheats or ruts trails off‑road.”

Trail Impact and Safety

• Several claim AWD systems that wait for wheelspin before reacting can chew up trails more than locked 4WD. Others contest this or say evidence is unclear.
• Weight and tires are repeatedly highlighted as under‑discussed but critical; highway tires and space‑saver spares are seen as liabilities far from help.

Marketing, User Understanding, and Regulation

• Strong sentiment that automaker marketing around “AWD” and “off‑road” misleads buyers about real capability.
• Some call for clearer, feature‑based requirements (e.g., lockers, low range, clearance) instead of AWD/4WD labels.
• Others argue consumers and regulators can’t practically track all technical variations, so coarse rules are inevitable, even if they misclassify edge cases.

Housing costs, internal migration, and population change

• Several comments argue high housing costs in major US cities (e.g., LA) are pushing people to cheaper inland areas, driving local population loss but not national decline.
• One view: the core issue is underbuilding housing since the 2010s, not tech salaries.
• Others debate rent-to-income ratios: one commenter’s “rent ≈ salary” claim is challenged with median/average data suggesting rent is closer to half of income, still seen by some as unsustainably high.
• Declining people per household over 50 years means that if homebuilding lags, total population in some areas can fall even without national decline.
• Some note that family size decisions (e.g., needing more bedrooms) can be influenced by housing costs, though others call separate bedrooms a “luxury,” sparking debate over expectations vs necessity.

Immigration, asylum, and labor markets

• One line of argument links Hispanic-driven growth to more welcoming southern border policy and instability in Latin America, especially asylum seekers.
• Others counter that asylum is a small share of total immigration and that California’s housing issues are mostly about existing residents, not new immigrants.
• There’s disagreement on labor effects: one side argues “plenty of workers” and warns that low-wage immigrants depress wages; another cites low unemployment and research claiming immigrants are not harming US-born workers.
• Some emphasize building more housing as a less controversial, more lawful solution than restricting asylum.

Fertility and drivers of Hispanic population growth

• Multiple comments stress that most Hispanic growth since 2020 comes from natural increase, not immigration, citing figures (~2.21M births minus deaths vs ~0.94M net immigration).
• Another notes Hispanic fertility has nearly halved over 30 years, though it remains higher than other groups.

Race, ethnicity, and classification

• Several comments explain that “Hispanic” is an ethnicity separate from race; Census categories include “White Hispanic,” “Black Hispanic,” etc.
• Some argue that talking about “white vs everyone else” obscures this complexity and that various groups have historically moved in and out of the “white” category.
• Others question how “diversity” is framed when 91% of growth comes from one (non-majority) ethnic group.

Broader economic and social framing

• There is tension between a “meme” of economic doom (housing crisis, unlivable rents) and views that overall conditions are mixed: housing worse, some goods and services cheaper.
• Land value tax and limiting public comment in planning are briefly floated as structural reforms to housing policy.

Apple’s market power and supplier squeeze

• Many agree Apple has enormous buying power in components, using scale to push prices and margins down while keeping high end‑user prices.
• Some argue this contributes to low wages and poor conditions at suppliers (e.g., Foxconn) and leaves smaller component firms dangerously dependent on a single customer.
• Others counter that harsh labor conditions in China predate Apple and are common across electronics manufacturing; Apple is a big player, not a unique villain.

Is Apple really “America’s semiconductor problem”?

• Several commenters say focusing blame on Apple is misleading; structural issues include Intel’s failures, the dominance of TSMC on leading nodes, and decades of offshoring.
• Missing discussion of Intel, Qualcomm, Nvidia, and GlobalFoundries is seen as a major gap.
• Some read the piece as mostly showing Apple doesn’t truly prioritize U.S. manufacturing despite patriotic marketing, but that doesn’t explain why domestic fabs struggled in the first place.

Monopoly, monopsony, and market segmentation

• Debate over whether Apple is a monopoly (seller) or a monopsony (dominant buyer of certain components).
• Clarification: Apple isn’t a smartphone unit-share monopoly, but it dominates profit share and “high-spend” customers, giving it outsize influence.
• Some describe Apple as a “cultural” or ecosystem monopolist: control of affluent, high‑spend users gives it power over developers, suppliers, and even repair markets.

Article quality and use of examples

• Many find the article selective or “hit‑piece‑like”: mixing chip fabs with unrelated IP disputes (e.g., graphics IP, Apple Watch patent fight).
• The Imagination Technologies example is criticized as about IP licensing, not semiconductor fabrication or U.S. industry.
• Others find the article broadly convincing, arguing that greed plus buyer concentration explains much of the dynamic.

Reshoring, fabs, and global supply chains

• Multiple comments stress that the problem is not just chips but entire ecosystems: clustered suppliers, huge trained workforces, and logistics that the U.S. no longer has.
• TSMC’s struggles in Arizona and U.S. PCB lead times vs. China are cited as evidence of deeper capability and ecosystem gaps, not just wage differences.
• Apple’s pre‑orders at new U.S. fabs are noted; some say that shows support, others see it as PR while the real volume stays offshore.

Policy ideas and regulation debate

• Proposed remedies from the thread include tariffs on devices with foreign‑sourced chips, stronger right‑to‑repair laws, and more aggressive antitrust against platform lock‑in.
• Others warn that additional regulation could entrench incumbents or make U.S. fabs less competitive; they call instead for pro‑competition environments and better execution by domestic firms.
• There is disagreement on whether big government action (tariffs, CHIPS funding, industrial policy) is necessary or whether industry missteps (especially Intel’s) are the primary cause.

Android, ecosystems, and competition

• Several note that in unit terms Android dominates globally, but Apple dominates profits and high‑end segments.
• Some argue no one truly competes with Apple’s integrated hardware‑software ecosystem, in part because Android economics (thin margins, ad‑driven models, fragmented support) undermine long‑term investment.
• Others report being satisfied or happier on Android, questioning the claim that Apple’s products are uniquely superior.