Hacker News, Distilled

Use cases and technical details of the $5 tier

• Many argue a single-node database is sufficient for a large share of line‑of‑business and hobby apps; 5‑nines HA is often unnecessary and expensive.
• Others note uptime expectations and potential global audiences make “business‑hours only” availability impractical outside niche cases (e.g. some government sites, specialty retailers).
• For the single-node plan, durability is said to be preserved via replication plus EBS backing; it’s not just “one box and you’re on your own.”
• Local NVMe disks vs EBS is a recurring thread: some are surprised local NVMe isn’t standard; others explain that doing metal + synchronous replication reliably is operationally very hard (node lifecycle, resizing, never terminating incorrectly).
• Questions arise on Postgres specifics (synchronous commit settings, Timescale support in progress) and the fact that this exists only for Postgres, not Vitess/MySQL, due to architectural differences.
• Latency concerns: advice is to place PlanetScale in the same region/city as compute (Render, Fly.io, etc.) to avoid large performance penalties.

Pricing, free-tier history, and “rug pull” risk

• A large portion of the thread centers on mistrust from the prior “free forever” hobby tier being removed and replaced with a ~$40 minimum plan, causing some users to abandon or shut down projects.
• Multiple commenters warn: don’t build anything you care about on this $5 tier if a future price hike would be painful. Others counter that at $5 it’s already gross‑margin positive and compute/storage trends should only improve profitability.
• Some view the $5 offering as a funnel to higher tiers; critics point out that even profitable low tiers can be killed if upgrade rates or support costs disappoint, or if strategy/leadership changes.
• Others argue this plan is fundamentally different from a loss‑making free tier and therefore less likely to disappear.

Free tiers vs paid low-end plans (broader debate)

• One camp says “free forever” should never have been promised; free tiers are effectively marketing/VC burn or subsidies from paying customers and are inherently fragile.
• Another camp calls the original language a bait‑and‑switch: if sustainability is uncertain, don’t say “forever.” The archived pricing page showing “Free forever for hobby use” is repeatedly cited.
• There’s comparison to other providers (Neon, Supabase, etc.) that still run free tiers, plus discussion that “scale to zero” doesn’t eliminate underlying costs; someone must pay.

Founder presence, tone, and reputational impact

• The CEO participates extensively, defending the decision to kill the free tier as necessary for profitability and long‑term survival, and emphasizing that all plans are now gross‑margin positive.
• Some readers appreciate the candid, non‑PR voice and agreement from ex‑employees that layoffs were painful but necessary. Others find several responses thin‑skinned or dismissive, especially statements along the lines of not caring what critics think.
• The “we never said forever” claim followed by being shown archived “free forever” wording, and then acknowledging it, is viewed by some as denial or gaslighting, by others as an honest memory lapse.
• Several commenters say that, regardless of technical quality, this exchange alone makes them hesitant to trust the company with future projects; others remain enthusiastic about the product and welcome a transparent low‑cost option.

Why Free/OSS Software Often Feels “Scary”

• Many projects are built “by power users for power users”: devs scratch their own itch, so they expose every option they’d ever want.
• Adding options is cheap for a dev and feels high‑value; pruning and coherently organizing them is expensive, ongoing work.
• Typical FOSS distribution and installation paths already filter for technically inclined users, reinforcing a power‑user bias in feedback.
• There’s little budget for UX research, user testing, or telemetry; when telemetry is proposed, the backlash is strong. So UIs are based on intuition and complaints from existing (already-skilled) users.
• Several comments stress this isn’t unique to FOSS: Microsoft Office, CAD tools, DAWs, GPG, etc., are also intimidating.

Simplicity Is Hard and Fragile

• Making a focused “one‑click” flow is easy; discovering the right flow for the right audience is hard.
• Maintaining simplicity is an unstable equilibrium: users and contributors constantly ask for “just one more option,” leading to feature creep.
• Everyone’s “20% of features” is slightly different; trimming too far can leave many users missing their one critical feature.
• A strong product owner or “benevolent dictator” is often needed to defend simplicity.

Proposed Strategies: Wrappers & Progressive Disclosure

• The Magicbrake idea (simple wrapper over Handbrake) is widely praised: keep the powerful backend, offer a trivial “drop file, press go” UI for common cases.
• Others point to “basic vs advanced” modes, or multi‑level settings (focused/simple/expert) with progressive disclosure, as a good compromise.
• Counterpoint: dual modes are hard to design well and often disappoint both novices and experts.

Power Users vs “Normal People”

• One camp argues tools should prioritize the thousands of hours experts spend with them, not the first five minutes of a novice.
• Another camp notes that if novices fail in the first five minutes, those thousands of hours never happen at all.
• Several comments criticize the “normal people are dumb” tone; many non‑technical users are time‑limited, not incapable.

Design, Culture, and Incentives

• Persistent theme: FOSS has far more volunteer coders than volunteer designers; artists and UX people are under‑represented and often undervalued.
• Good UI/UX demands research, iteration, and saying “no” – hard to do in volunteer, consensus‑driven projects.
• Some accept that many FOSS tools will remain “for nerds,” and that’s okay; others see a big opportunity in building polished, simple front‑ends on top.

Overall Reception and Convenience

• Many commenters describe Ventoy as “essential” and a “lifesaver,” especially for people who frequently install or test multiple OSes.
• Core benefit: write Ventoy once, then just drag-and-drop ISO/WIM/IMG/VHD/EFI files; a boot menu lets you pick at boot time.
• Supports many images on a single large drive (e.g., 2TB NVMe in a USB enclosure), reducing the “pile of flash drives” problem.
• The remaining space can be used like a regular USB drive for other files.

Compared to Other Tools (dd, Rufus, Etcher, Microsoft Tools)

• dd, Balena Etcher, and Microsoft’s Media Creation Tool: typically one ISO per stick; you reflash for each new image.
• Ventoy: persistent bootloader + menu; multiple ISOs co‑exist.
• Several comments criticize Etcher as a heavy Electron app with telemetry.
• Rufus is seen as more sophisticated than Etcher and good for Windows installs, but still image-per-stick.
• Windows install media creation (especially on non‑Windows OSes) is described as painful; Ventoy sometimes simplifies this, but not always.

Windows, VHD, and vDisk Use Cases

• Ventoy can boot Windows VHDs via its VHD/vDisk plugins; some keep a full Windows install with tools this way.
• Reported success installing Windows 10/11 (including Pro and LTSC) on many machines; others hit errors like missing media/driver messages.
• Workarounds mentioned: wimboot mode, Rufus+NTFS, or Microsoft’s splitting tools for >4GB files.
• Ventoy can help bypass some Windows 11 requirements and local-account restrictions.

Compatibility, Reliability, and Secure Boot

• Several users report certain ISOs not working or even corrupting the Ventoy stick until re-prepared.
• Problem cases include some Linux installers (Debian/openSUSE reports conflict), obscure OSes (ReactOS, KolibriOS), FreeDOS behavior, and very cheap USB sticks.
• Suggestions: use GPT, UEFI boot, keep Ventoy updated, properly eject/sync writes, use GRUB2 mode when an ISO misbehaves.
• Secure Boot: can fail unless users disable it, change firmware mode, or enroll Ventoy’s MOK key; once enrolled, all ISOs benefit.

Binary Blobs and Trust Concerns

• Ongoing concern about Ventoy’s bundled binary blobs; some refuse to use it for this reason.
• Others note the blobs come from open-source projects with documented build instructions, arguing the project is fully buildable from source in principle.
• Debate centers on reproducibility, independent verification, and whether relying on upstream “trusted” binaries is acceptable.

Alternatives and Adjacent Tools

• Hardware ISO/VHD emulation enclosures (IODD) are mentioned as Ventoy-like but with mixed reliability experiences.
• Phone-based tools (DriveDroid, USB Mountr, MSD) can emulate USB mass storage/optical drives, though modern Android support is spotty.
• Network boot companion iVentoy is recommended for PXE-style installs.
• Some wonder why a simpler GRUB-based multi-ISO SSD solution isn’t more popular, especially for those wary of blobs.

Treaty scope and key concerns

• Commenters highlight provisions enabling:
  • Real-time traffic/content data collection and secret orders to service providers.
  • Cross-border data sharing with minimal transparency and weak human-rights protections.
  • Expansion of “cybercrime” to any offense involving a computer, where “serious crime” is anything punishable by ≥4 years in prison.
• Security and digital-rights critiques (e.g., EFF summaries) are cited: risks of broad surveillance dragnets, criminalization of security research, and tools for transnational repression rather than just cybercrime control.

Reactions to the US not signing

• Many see non-signature as a rare positive move for privacy and civil liberties, noting the US can still cooperate on cybercrime without this framework.
• Others are skeptical, pointing out US mass surveillance, weak consumer data protection, and extensive cyber operations; they doubt privacy is the real motive.
• Some argue joining could have constrained US power or conflicted with constitutional protections (e.g., compelled technical assistance vs. Fifth Amendment).

Authoritarian signatories and human-rights risks

• Strong focus on the treaty’s origins and support from Russia and other authoritarian or semi-authoritarian states (China, Iran, North Korea, etc.).
• Fear that:
  • Regimes will use “cybercrime” as a pretext to target dissidents, journalists, and protesters abroad.
  • Extradition and data-access mechanisms could be invoked against political speech that’s criminalized domestically.
• Several express disappointment that the EU, UK, and some Nordic states signed alongside such governments, seeing it as evidence of a broader drift toward surveillance and “chat control.”

Effectiveness and enforceability doubts

• Commenters question whether states that heavily rely on or tolerate cybercrime (Russia, North Korea, parts of Africa/Asia) will meaningfully enforce the treaty.
• View that bad actors can simply invoke sovereignty or “security interests” to refuse cooperation, making the treaty asymmetric in practice.
• Concern that, instead of reducing cybercrime, the convention mainly standardizes global monitoring and legal cover for state surveillance.

Broader skepticism of UN and international law

• Some see the convention as another overreaching, largely symbolic UN instrument that powerful or rogue states will ignore when inconvenient.
• Comparisons to other global agreements (climate, land mines, WHO) fuel a wider debate on whether such treaties meaningfully constrain states or just add bureaucracy.

Motivation: Sanctions and Microsoft Account Shutdown

• Central trigger: a prosecutor’s Microsoft email account at the ICC was blocked due to US sanctions, highlighting how a single US decision can partially paralyze a critical institution.
• Some say Microsoft had “no choice” under US law; others emphasize that this demonstrates why it’s inherently risky for the ICC to depend on US providers subject to a volatile political environment.

Data Sovereignty and Dependency on Big Tech

• Broad support for reducing reliance on “globomegacorps” whose size and political exposure create systemic risk.
• Risk is framed as both technical (loss of access, lock-in) and political (sanctions, informal pressure, “phone call from the president”).
• Several argue diversification across jurisdictions and vendors is more realistic than full independence from for‑profit firms.

Profit, Nonprofits, Capitalism, and Control

• Debate whether the core problem is profit or control.
  • One side: for‑profit incentives (maximizing revenue, avoiding displeasing powerful states) inherently distort behavior.
  • Other side: nonprofits still depend on funding, follow local laws, and can be coerced; what matters is control over source code, deployment, and infrastructure.
• Longer sub‑thread on capitalism as a decision/coordination mechanism vs. collective deliberation, and on how property rights and lack of “unclaimed resources” undermine idealized justifications.

Migration from Microsoft and Cloud Services

• Some are pessimistic: public-sector dependence on Microsoft and legacy systems plus staff retraining makes exit “nigh impossible.”
• Others counter with examples of gradual, successful migrations and argue this is a long “marathon” requiring commitment to higher values than the cheapest short‑term solution.
• Many see the episode as a delayed realization that outsourcing critical IT (especially to US clouds claiming “data stays in the EU”) sacrifices real sovereignty.

Self‑Hosting, Email, and Practical Obstacles

• Mixed experiences on self‑hosting email:
  • Some report chronic deliverability problems with big providers (especially in the 2000s–early 2010s).
  • Others say, with proper DNS and anti‑spam setup, self-hosted email works reliably even today.
• General sense: big organizations like the ICC can self-host or use sovereign providers more easily than small “little guy” domains.

ICC, US Law, and International Justice

• Several note the irony of relying on companies from a country that doesn’t recognize the ICC and has legislation hostile to it.
• Extended debate on why any state would accept supra‑national law, the weakness of international enforcement, and whether joining the ICC would meaningfully constrain or protect powerful states like the US.

European Initiatives and Open Source

• Article mentions EU‑linked efforts (e.g., OpenDesk, Zendis) to build sovereign infrastructure.
• Skepticism from some that EU “digital sovereignty” projects become consultant-heavy, conference‑driven money sinks with little going to core open‑source developers.
• Others argue governments should invest far more in local/EU tech, which has historically been neglected and underpaid compared to US tech sectors.

Why pursue ISO/IEC standardization?

• Seen as a way to unlock government and large-enterprise adoption where “use international standards” is a formal requirement or strong expectation.
• Helps procurement and grant applications: once an ISO standard exists, users must justify not using it.
• Viewed as a milestone in industry “maturity”: moving from vendor‑controlled ISAs to stable, boring infrastructure with multiple vendors.
• Some see it as defensive: an ISO label may blunt political or lobbying attempts to curb RISC‑V uptake, especially amid US–China tensions.

Skepticism about ISO as a venue

• Many criticize ISO’s process as slow, bureaucratic, and sometimes captured (e.g., OOXML/.docx, MPEG/H.265 patent issues, C/C++ standardization woes).
• Concern that ISO’s paywalled documents conflict with RISC‑V’s open, freely available ethos, potentially making compliance harder to verify.
• Fear that ISO involvement could slow ISA evolution, introduce feature creep, or turn RISC‑V into an expensive proprietary standard “in practice.”

Fragmentation, profiles, and standard scope

• Some argue RISC‑V is “fragmented” due to modular extensions and many ISA variants, scaring business decision‑makers.
• Others reply that profiles like RVA23 already solve this for application processors, and that modularity is a key value for embedded/custom SoCs.
• Debate over whether ISO can/should “tie up fragmentation” by enshrining profiles, versus preserving flexibility and vendor extensions.

Technical maturity and competition with ARM/x86

• Critics say RISC‑V offers little over mature AArch64, is still green, and lacks high‑end cores comparable to Apple M‑series; supporters note this took ARM decades too.
• Performance gaps are attributed mostly to implementation, but some call out specific RISC‑V design choices and ABI decisions as “bad and doubled‑down on.”

Alternatives and complements

• Some would prefer more focus on open test suites and certification rather than a paper ISO spec; existing test repos and formal models are mentioned.
• Dedicated tech consortia (IETF, CNCF, etc.) are seen by some as better suited to evolving complex technical standards than ISO.

Video & conference context

• Talk is part of a larger JJ Con playlist; some find it odd the YouTube video is unlisted, seeing it as typical Google underexposure.
• A separate JJ-Con wiki page aggregates talks, slides, and notes.
• Multiple people complain about the poor audio quality and “point a camera at the lectern” conference style.

Google internal rollout & dev environment

• “GA in 2026” refers to Google-internal general availability on Linux only; external jj is already usable on multiple platforms.
• Google is predominantly Linux for dev, with an in-house Debian-based distro (gLinux) and internal mirrors; Macs and some Windows machines are used as terminals into remote Linux boxes.
• Many devs use macOS locally but build and run on Linux in the datacenter, reducing urgency for native jj on macOS except for iOS/macOS devs.

Jujutsu vs Git: why and for whom

• Fans describe jj as simpler yet more powerful than git: easier CLI, automatic rebasing of dependent commits, an explicit “undo” for repo operations, no staging area, and strong support for stacked/atomic commits.
• Git experts note that many workflows are possible in git but feel arcane, brittle, or tedious compared to jj’s first-class support (e.g., history surgery, filtering, and commit rewriting).
• Skeptics say they rarely need more than basic git commands and haven’t experienced git as a bottleneck, especially on smaller repos.

Conflicts, stacks, and workflows

• First-class “conflicted commit” state is a major selling point: you can defer conflict resolution, keep working elsewhere, and later fix conflicts without being stuck in a modal rebase.
• JJ auto-rebases children when you amend a commit, making long stacks of dependent changes and “PR stacks” much easier to maintain.
• Auto-snapshotting on every command and treating all changes as commits makes context switching and splitting commits easier, similar in spirit to IDE “local history.”

Git usability debate

• Strong divide: some insist git is straightforward if you internalize the commit-graph model and read the docs; others say the documentation is implementation-heavy (trees/blobs) and intimidating.
• Many report that errors and “weird states” (especially around rebase, detached HEADs, and collaborative mistakes) are where git becomes scary and time-consuming, even for experienced users.
• Reflog is cited as a safety net, but proponents argue jj’s global operation log (oplog) is a more comprehensive and user-friendly history of changes.

Scale and monorepos

• Several comments stress that opinions formed on “hundreds of devs, hundreds of MB” repos don’t generalize to multi-terabyte monorepos.
• Google’s internal systems (Piper, earlier git-like frontends such as “git5”) struggled with monorepo scale and workflows; jj is seen as a modern alternative frontend that still uses git as backend externally.

Compatibility & ecosystem concerns

• JJ lacks full support for some git ecosystem features: LFS, hooks, submodules, and creating tags via jj itself (though git can be used alongside).
• Some argue this limits jj as a drop-in git replacement for organizations with complex CI/integration setups and existing submodules/LFS usage.
• CLAs are required and contributions currently need a Google account; this is perceived by some as a barrier despite the project being independent of Google.

Collaboration & “serverless” setups

• One appeal of jj is safer use with shared folders (Dropbox, Google Drive, USB) due to its concurrency design; git repos in such environments are historically fragile.
• Others counter that bare git repos on shared drives plus SSH are simple and sufficient, and see Dropbox issues as a storage problem, not a git problem.

Presentation style discussion

• Large subthread critiques the slide deck and delivery: too much text per slide, tendency for viewers to read ahead, and difficulty syncing spoken words with bullets.
• Many advocate “less text, more structure”: fewer bullets, clearer narrative (situation–consequence–action–result), and emphasizing key impacts rather than deep internals for a general audience.
• There is disagreement on “passion”: some want more energy and motivation in technical talks; others prefer dry, information-dense delivery and resent TED-style exhortations.
• Several commenters praise the presenter’s openness to feedback and note the talk may have been well-calibrated for the in-person audience (experienced jj users) but less so for random YouTube viewers.

GCP usability, deprecations, and the “treadmill”

• Many users say GCP works well for core needs (VMs, storage, serverless), but repeated deprecations create large amounts of low‑value “busy work.”
• Some frame this as a deliberate “fire and motion”–style tactic (constant change to slow competitors); others counter that internal platforms at big companies behave similarly due to evolving requirements and promotion‑driven development, not strategy.
• AI is called out as especially bad: APIs and dependencies change so fast that work feels obsolete within months.

Console, tooling, and performance

• Multiple commenters complain the GCP console is painfully slow; some prefer a GUI but feel pushed to CLI or Terraform.
• The gcloud CLI is also seen as sluggish; debate over whether Python is at fault vs backend API latency.
• Suggested mitigations: heavy use of Terraform, scripts, and avoiding the console for anything but one‑offs.

Managing stack rot: VMs vs managed services

• One camp recommends building on plain Linux VMs to avoid provider deprecations; others argue this just shifts maintenance burden and can be worse when every VM becomes a snowflake.
• Several advocate continuous, aggressive upgrading to keep technical debt small instead of letting systems drift for years.

Alphabet’s business model and market power

• Commenters note Alphabet still derives the majority of revenue from ads; “search revenue” is widely interpreted as advertising.
• Some describe Google as a “cash volcano” that allows mediocre planning and endless product churn without visible financial penalty.
• Search and ads are criticized for effectively taxing “existence” on the web via brand‑keyword bidding and competitor targeting.

Cloud market dynamics and competition

• GCP’s 34% growth is seen as impressive but from a smaller base; some believe AWS is slowly losing relative momentum, others argue the AI boom is simply expanding the whole cloud pie.
• Opinions diverge on technical quality: some rate GCP’s infra and UX above AWS/Azure; others say Google’s support, enterprise focus, and sales execution are clearly weaker.

Cloud vs bare metal and “utility” analogies

• Several want more appetite for owning servers again, warning about dependency on “silicon nimbus.”
• Others prefer cloud as a utility, but argue vendor lock‑in prevents true commoditization.
• Ideas floated: state‑run “utility clouds” for basic compute/storage; faster, more modular colo to rebalance power away from hyperscalers.

Google’s AI position and ad conflict

• Many believe Google’s scale, cash, chips (TPUs), and engineering make it a top long‑term AI contender once easy funding for startups tightens.
• Skeptics highlight missed opportunities (late to productized LLMs), internal flakiness, and a cultural tendency to kill or pivot products.
• A major concern: tension between truly helpful AI and ad‑driven incentives. People anticipate AI assistants being polluted by sponsorship (“MLM‑friend” effect), though some argue every provider will face the same pressure and/or shift to subscriptions.
• There’s debate over whether AI is winner‑takes‑all: some expect a few dominant incumbents (Google, Microsoft); others see room for multiple players and note deep, non‑LLM Google AI (Waymo, AlphaFold) as a separate advantage.

GCP as a product and enterprise vendor

• One thread paints GCP as technically excellent but weakest on sales, support, and long‑term trust; AWS and Azure are described as more aggressive and responsive with enterprise features and deals.
• Another thread, from experienced GCP users, reports high reliability at scale, strong UX, and believes cloud is one of the few Google products that “just works,” with App Engine cited as ahead of its time despite later strategic missteps.

Miscellaneous points

• “Over 70% of Cloud customers use its AI products” is criticized as partially forced usage (e.g., AI‑fronted support flows).
• TPUs are praised as good value but too hard to integrate into real workloads.
• Some see Alphabet as analogous to past “safe bets” like IBM, warning that size and past success don’t guarantee future leadership.

Concept and Approach

• App shows each child’s balance and “growth” on a phone mounted to the fridge, aiming to make consequences visible and spark self‑driven curiosity and sibling competition.
• Parent acts as broker (“Bank of Dad”), applying a fixed interest rate; deposits/withdrawals are currently manual but planned as features.
• Some liken it to a long‑form “Marshmallow Test” for 7‑ and 10‑year‑olds: exchanging immediate gifts for future gains, but with the option to spend anytime.

Interest Rates and Realism

• Strong debate around the 15% rate: defenders say an unrealistically high rate keeps kids engaged; critics call it misleading given historical stock returns and volatility.
• Thread dives into comparisons of equities vs housing, leverage, and local realities (e.g., double‑digit nominal bond yields in Paraguay and similar markets, often offset by inflation and currency risk).

Child Psychology, Values, and Ethics

• Supporters argue early investing habits can be life‑changing and teach restraint, not gambling; several share positive experiences with custodial accounts and “Bank of Dad” schemes.
• Critics find it “sad” to swap birthday presents for a number on a screen, worry about kids becoming obsessed with wealth metrics, and argue that meaningful childhood experiences and physical hobbies matter more.
• Some see the core lesson as “capital beats labor,” sparking ethical concerns about stock markets, growth obsession, and environmental/social impacts.

Financial Literacy vs. Structural Constraints

• Many agree financial literacy is poorly learned in practice, even where courses exist; others point out big gaps between abstract compound‑interest math and real‑world tools (brokers, funds, taxes).
• Several stress that knowledge alone is useless without surplus income, highlighting widespread paycheck‑to‑paycheck living and high housing/health costs.

Risk, Volatility, and What’s Being Taught

• Critics note the app currently depicts guaranteed, smooth 15% growth and omits crashes, taxes, and bankruptcy risk.
• Multiple suggestions: add volatility, different risk/return “products,” diversification sliders, and even simulated bubbles/crashes so kids experience loss and recovery.

Implementation and “Single HTML” Dispute

• Some like the lightweight PWA idea; others object that it’s not truly a “single/plain HTML file” because it depends on external React/Tailwind CDNs, which breaks offline use and raises tracking/security concerns.
• A few bug/UX reports (e.g., date picker crash, missing styles offline) lead to suggestions to inline assets and fix PWA caching.

Alternative Models

• Numerous variants described: progressive “Bank of Dad” interest brackets, chore‑gamification dashboards, spreadsheet‑based accounts, and heavy emphasis on index funds and retirement plans as kids age.

What x86‑64‑v3 Brings and Why

• x86‑64‑v3 essentially targets AVX2‑class CPUs, plus a bundle of other extensions, though notably not AES‑NI/CLMUL despite those being common on such hardware.
• Motivation is to ship prebuilt binaries that can exploit modern instructions without dropping support for older CPUs, similar to emerging patterns on ARM and RISC‑V.

Performance Gains and Their Distribution

• Ubuntu’s own rebuild shows ~1% average speedup for “most packages,” with some numerically heavy workloads gaining significantly more (claims up to 1.5–2× in edge cases).
• Several commenters stress that aggregated numbers hide skew: a small number of hot libraries or apps may get large wins while the median app sees effectively nothing.

When 1% Matters (and When It Doesn’t)

• Strong view: hyperscalers or anyone running large fleets will gladly take 1%, as it can translate into fewer servers and substantial cost/energy savings.
• Counter‑view: for typical desktop users, CPU is rarely the bottleneck, so 1% is effectively unobservable.
• Others emphasize compounding small optimizations over years and across millions of devices.

Relation to Existing Optimization Techniques

• Many performance‑critical libraries (BLAS/LAPACK, crypto, compression, codecs, llama.cpp) already use runtime CPU feature detection, multiversioning, or fat binaries; for them, distro‑level v3 gives smaller marginal gains, or mainly reduces dispatch overhead.
• Some argue that widespread v3 builds will incentivize compiler and app authors to better use newer instructions.
• Gentoo/source‑compilation nostalgia appears: micro‑arch tuning gives modest gains now; the big wins often come from algorithmic choices, threading, or better BLAS/MKL/OpenCV builds.

Tooling, ABI, and Compatibility Questions

• Discussion about how dpkg/apt implement “architecture variants” and relation to Debian’s ArchitectureVariants design; clear point that different ABIs (e.g., armel vs armhf) are out of scope.
• Concern about moving a v3‑optimized disk to an older CPU: currently it just fails with illegal instructions; Ubuntu plans a cleaner recovery path.
• glibc hwcaps are seen as too limited (shared libs only) and space‑wasteful compared to full variant repos.

Concerns, Skepticism, and Edge Issues

• Worries about extra complexity, more heisenbugs, and non‑deterministic numeric behavior across variants.
• Some think using micro‑arch variants system‑wide is overkill; targeted variant packages or meta‑packages might be simpler.
• Others welcome Ubuntu joining Fedora/RHEL/Arch‑style optimization and see this as a partial replacement for things like Intel’s Clear Linux.

Initial reactions and confusion

• Many commenters react with alarm and anger, seeing the announcement as escalating an already dangerous world situation.
• Several find the BBC article confusing: Russia and China seem to be testing delivery systems or nuclear-powered engines, not detonating warheads, yet the U.S. response is framed as resuming nuclear weapons testing.

What kind of “testing” is at issue?

• Multiple people note the U.S. already conducts subcritical underground experiments (no self-sustaining chain reaction), last done in 2024.
• There is debate whether Trump means more of that, or a break with the post‑1992 moratorium on actual nuclear detonations. His vague remarks and lack of formal orders lead some to dismiss it as attention-seeking, others to treat it as serious intent.
• Some clarify that other countries’ recent “nuclear tests” are about missiles, submarines, or nuclear engines (e.g., Russia’s cruise missile and underwater drone), not warheads.

Nuclear war consequences and global fallout

• Tools like NUKEMAP are shared to visualize destructive radii and fallout; central urban dwellers conclude they’d be “instantly gone.”
• A linked study on an India–Pakistan “limited” nuclear exchange suggests massive global cooling, crop losses, and famine impacting over a billion people, illustrating that even regional use would hit “everywhere.”
• Commenters stress the psychological and strategic difference between simulations/subcritical tests and live detonations.

Arms control, non‑proliferation, and great‑power strategy

• Several note that the U.S. benefits disproportionately from test bans and non‑proliferation because it already has extensive test data and superior conventional forces.
• Resuming live tests is seen as a “gift” to China and Russia, who could use it as cover to conduct their own and improve warhead designs.
• Some speculate (with disagreement) that parts of the Russian arsenal may be poorly maintained, meaning a test race could expose or fix deficiencies.
• Commenters connect this to the collapse of arms control treaties, new U.S. missile defense proposals, and Russia’s development of exotic delivery systems.

Trump’s judgment and broader politics

• Many are deeply concerned about Trump’s temperament, attention to TV over briefings, and past nuclear comments (e.g., “tenfold” arsenal, nuking hurricanes), seeing this as part of a pattern.
• Others emphasize his statements are often policy-irrelevant bluster, but point out even confused talk on nukes increases global risk and can be misread by adversaries.
• Discussion branches into who “enabled” Putin (Bush-era wars, weak responses to earlier invasions), the Ukraine war, and the apparent absence or discrediting of modern peace movements.

Cultural references and risk perception

• The film A House of Dynamite is cited as a vivid depiction of nuclear command vulnerabilities; some praise it, others call it fearmongering but agree the underlying risk is real.
• Several note that post–Cold War generations underestimate nuclear danger, now overshadowed by climate change and other threats, even as nuclear rhetoric and capabilities ramp back up.

What “invertible” refers to

• Many commenters initially misread the claim as “given the text output, you can recover the prompt.”
• Thread clarifies:
  • The paper proves (for transformer LMs) that the mapping from discrete input tokens to certain continuous hidden representations is injective (“almost surely”).
  • The model outputs a next‑token probability distribution (and intermediate activations); that mapping can be invertible.
  • The mapping from prompts to sampled text is clearly non‑injective; collisions (“OK, got it”, “Yes”) occur constantly.
• The inversion algorithm (SipIt) reconstructs prompts from internal hidden states, not from chat‑style text responses.

---

Title, communication, and hype

• Several people find the title misleading / clickbaity because most practitioners equate “language model” with “text‑in, text‑out system,” not with “deterministic map to a distribution.”
• Others argue that within the research community the title is technically precise; the confusion stems from public misuse of terms like “model”.
• Some worry hype will reduce long‑term citations; others note that in a fast field, short‑term visibility is rewarded.

---

Collision tests and high‑dimensional geometry

• Skeptics question the empirical claim of “no collisions in billions of tests”:
  • Hidden states live on a huge continuous sphere (e.g. 768‑D); the epsilon ball used for “collision” is extremely tiny.
  • In such spaces, random vectors are overwhelmingly near‑orthogonal, so seeing no collisions in billions of samples is expected and weak evidence.
• Discussion touches on concentration of measure, birthday paradox limits, and the difference between “practically injective” and provably injective.
• Some note that even if collisions are astronomically rare, that doesn’t guarantee reliable inversion when information is truly lost (analogy to hashes).

---

Privacy, security, and embeddings

• Because hidden states (and embeddings) can in principle reconstruct prompts, storing or exposing them is not privacy‑preserving.
• This reinforces prior work showing “embeddings reveal almost as much as text” and undercuts the notion that vector DBs are inherently anonymizing.
• Suggested mitigations include random orthogonal rotations of embeddings or splitting sequences across machines (related obfuscation/defense work is cited).
• However, most production systems only expose final sampled text, so direct prompt recovery from network responses remains out of scope.

---

Conceptual implications for how LLMs work

• Result supports the view that transformers “project and store” input rather than discarding it; in‑context “learning” may just be manipulating a rich, largely lossless representation.
• Some see this as consistent with why models can repeat or condition on arbitrary “garbage” sequences: the residual stream must preserve them to perform tasks like copying.
• Debates arise over whether this counts as “abstraction” or merely compression/curve‑fitting; analogy made to compressing data once you understand an underlying rule.

---

Limitations, edge cases, and potential uses

• The result is about theoretical, deterministic models with fixed context windows and hidden activations; it does not enable recovering training data, per author clarifications mentioned.
• “Almost surely injective” leaves open rare collisions; how that translates into guarantees for inversion in adversarial or worst‑case settings is unclear.
• Possible applications discussed:
  • Attacking prompt‑hiding schemes in hosted inference.
  • Checking for AI‑generated text or recovering prompts—though in practice this would require the exact model, internal states, and unedited outputs, making it fragile.
  • Awareness that any stored intermediate states may be legally/compliantly equivalent to storing the raw prompt.

Nature of Time: Illusion, Emergence, Arrows

• Several commenters struggle with “time is an illusion,” noting that theories often just rename time as “dynamics,” “rule application,” or “evolution of state.”
• Others argue “time is the evolution of state”: without change, no clock can exist.
• Multiple participants discuss entropy and the thermodynamic arrow. Some see entropy increase as defining the direction of time; others say entropy presupposes a time parameter and can’t explain the flow of time, only its asymmetry.
• Philosophical debates (McTaggart’s A/B series, Huw Price) are cited to argue that physics’ static 4D descriptions don’t capture lived temporal flow.

Relational Quantum Mechanics and Objective Reality

• Rovelli’s relational view: properties exist only in interactions; no observer-independent state.
• Some embrace this as the most faithful reading of QM’s formalism; others counter with realist alternatives (e.g., Bohmian mechanics, many‑worlds, QBism) and reject “no objective reality” as non-consensus.
• One technical thread dives into Bell’s theorem, nonlocality, and interpretations, emphasizing that “no local hidden variables” ≠ “no objective reality.”

Math, Accessibility, and Popularization

• A recurring complaint: lay misunderstandings stem from weak math backgrounds and overreliance on analogies.
• There’s disagreement over how “hard” the math really is: some say most tools are accessible beyond calculus; others point to deep use of advanced algebra, geometry, and topology.
• Popularizers are accused both of necessary oversimplification and of sometimes drifting into “quantum mysticism.”

Idealism, Realism, and Metaphysics

• Several commenters note that Rovelli’s stance aligns with long-standing philosophical idealism and perspectivism, not something radically new.
• Others defend physicalism or at least a minimal “objective reality” as necessary for science, common sense, and avoiding solipsism.
• There is concern that “no objective reality” can be misused to justify moral relativism, though others note existentialist and non-nihilist responses are possible.

Experiments, Technology, and Practical Constraints

• Some lament lack of clear falsifiable predictions from such theories; others respond that most feasible experiments have been done and current work is about reconciling existing results.
• Relativity tests, atomic and biological clocks, GPS, and entropy measurements are cited as concrete evidence that time (at least as a parameter) is very real and measurable, even if not fundamental.

Frustration with Next.js App Router & RSC

• Many commenters report experiences matching the blog: App Router and React Server Components (RSC) add a “bucket load” of complexity for marginal or unclear benefit.
• Key pain point: navigation causing full page remounts, losing client state and making fine‑grained loading UX (e.g., keeping some data visible while other parts load) difficult or impossible.
• Several feel RSC solves a problem they never had; they’ve built successful React apps for years without it and see RSC as overengineering.

Preference for simpler stacks and SPAs

• Strong current in favor of “boring” stacks: Vite + React + TanStack Query + a simple router (React Router, TanStack Router, Wouter).
• Multiple people say that replacing Next with a custom or minimal router made their apps simpler and faster.
• Some argue:
  • For SEO‑heavy sites: static generation or straightforward SSR + CDN caching.
  • For “apps”: lean into SPA + caching, possibly as PWAs, and accept a heavier initial bundle.

Routing & data loading philosophies

• Debate over whether routers should orchestrate data fetching (to avoid waterfalls/N+1‑style issues) versus using a dedicated data layer (e.g., TanStack Query) and parent components.
• Some praise modern “data routers”; others see this as scope creep and contributory to mental overhead.
• One thread critiques the idea that routing needs repeated reinvention; others defend ongoing innovation to better coordinate data loading.

Performance, SSR, and UX

• Disagreement over performance priorities:
  • Some ship multi‑MB SPAs and preload lots of data; users are happy because in‑app interactions are fast.
  • Others note this would be unacceptable for content sites (e.g., blogs).
• Several say perf anxieties around things like CSS‑in‑JS are overblown in practice.

Ecosystem churn vs “boring” frameworks

• Strong nostalgia for earlier React days (React Router + Redux) and for long‑stable ecosystems like Rails, Django, ASP.NET.
• Perception that incentives (marketing, “thought leadership”) drive constant reinvention and architectural churn, at real cost to teams.

Views on Vercel/Next direction & adoption

• Many see Next as a conceptual mess of modes and acronyms, with confusing caching and unfinished features, yet still missing basics like built‑in auth/i18n.
• Some note they are “forced” into Next because it’s the only supported extension framework for certain enterprise products.
• A minority defend Next/App Router, arguing that:
  • Issues often stem from mixing it with other data frameworks against its design.
  • Streaming HTML + RSC payloads and React caching solve some of the cited problems, albeit with a steeper learning curve.

Alternatives and related tools

• Nuxt is praised but there’s anxiety about its acquisition by Vercel.
• TanStack, Wouter, React Router v7, and simple backends (Spring Boot, Flask/FastAPI, Hono) come up as favored components.
• One side discussion raises concerns about Bun’s stability and security; others are skeptical that it’s fundamentally sloppy, citing mainly crash bugs typical of young low‑level runtimes.

Lifecycle scripts and arbitrary code execution

• Core concern: npm install runs preinstall/install/postinstall scripts, letting packages execute arbitrary commands before developers inspect code.
• Defenders cite legitimate uses: compiling native components (e.g., C++ addons, image tools), downloading platform-specific binaries, setting up git hooks or browser binaries.
• Critics argue this is too powerful for an unvetted public registry; even benign packages can later be flipped or compromised.

Comparisons with other ecosystems

• Many note DEB/RPM/FreeBSD ports/Gentoo require packaging effort and human review, creating friction that deters casual malware.
• Others point out that those systems also run maintainer scripts (e.g., kernel post-install, ldconfig), so the pattern isn’t unique to npm; the real difference is trust and curation.
• Language registries (npm, PyPI, cargo, etc.) are likened to “fancier curl | bash” without central vetting.

Dependency bloat and ecosystem culture

• Strong criticism of the JavaScript/npm culture of micro-packages and huge transitive trees (React/Vue/Angular projects dragging in hundreds of deps).
• Some say this makes auditing impossible and massively enlarges the attack surface; one bug or takeover in any tiny package can compromise everything.
• Others argue this pattern exists elsewhere too (cargo, pip), though perhaps less extreme; some defend micro-deps as aiding modularity and reuse.

Mitigation strategies discussed

• Use alternative clients that disable lifecycle scripts by default (pnpm, Bun) or set ignore-scripts=true in .npmrc; disagreement over whether this is meaningful or “security theater” without sandboxed runtime.
• Run all dev tooling in containers/VMs (Docker aliases for npm, UTM VMs, firejail/bubblewrap, Codespaces/Workspaces); debate over practicality vs necessary hygiene.
• Mirror/vendor dependencies into a local “depository” or VCS (third_party/), resembling BSD ports or vendoring; large argument about whether lockfiles solve or create problems.
• Prefer popular, older, low-dependency libraries; avoid unnecessary deps (especially trivial utilities and bundled CLIs); sometimes inline small bits of code.

Advice and broader reflections

• For hobbyists: reduce dependencies, keep dev environments isolated, pin versions and checksums, and accept some residual risk.
• Recognition that attackers now exploit LLM-hallucinated package names and that dynamic, runtime behavior (C2, env exfiltration) is hard to catch with static checks.
• Some blame the JS/npm ecosystem; others stress that any open package system is vulnerable and that the focus should be on better practices, tooling, and OS-level sandboxing rather than singling out one community.

Overview of the issue

• Crunchyroll is reportedly replacing older, well-crafted ASS subtitles (with rich typesetting) in its catalog with simplified, lower-quality tracks.
• This affects not just new shows but also back catalog, suggesting a deliberate transition away from the old system rather than a one-off regression.
• Viewers report that on Amazon Prime, where CR content is sublicensed, the subtitles are often “unusable” compared to Netflix or fansubs.

Technical and workflow motivations

• CR currently uses an ASS-based rendering stack, which is powerful but unusual in the broader streaming industry.
• General streaming platforms (Netflix, Amazon, many TVs) expect simpler formats like TTML/WebVTT and disallow burned‑in dialogue subtitles in delivery specs.
• Several commenters argue the move is about:
  • Aligning with “industry standard” subtitle formats.
  • Reducing storage and distribution complexity (no per‑language hardsubbed encodes, easier CDN usage).
  • Using commodity subtitling vendors and making sublicensing easier.
• Others counter that:
  • Subtitle text files are tiny; storage is a weak justification.
  • ASS tracks can be stored separately and many devices are already capable.
  • Segment-based partial hardsubs or image-based overlays (like Netflix’s “imgsub”) could preserve quality without massive cost.

Impact on viewing experience

• Main degradation: loss of precise positioning, overlaps, styling, and typesetting of on‑screen text (signs, labels, info boxes, dense infographics).
• Translations for dialogue and on‑screen text are now often merged into 1–2 lines at top/bottom, making it unclear what corresponds to what and hurting immersion.
• Dub + subtitle combinations are inconsistent:
  • Often no English subtitles with English audio.
  • Or subtitles reflect the sub script, not the dub script.
  • Deaf/hard‑of‑hearing viewers are especially affected; CC and “dubtitles” are unreliable or missing.
• Users also complain about a rise in machine‑like errors on Netflix/CR captions (misheard words, fantasy terms mangled).

Business incentives, culture, and piracy

• Several see this as classic “enshittification”: once anime is mainstream and CR has quasi‑monopoly power, they optimize for cost and reach, not quality.
• Some argue most of the mass market prefers dubs, so high‑end subtitling is no longer prioritized; others note sub watchers remain a large, loyal segment.
• Many say this pushes them back to piracy, where dual‑audio, ASS typesetting, and fan translation notes are often better.

Broader localization concerns

• Parallel drawn to manga: official translations and Viz-style localizations often drop puns, kanji wordplay, sign translations, and author notes that fan scanlations used to explain.
• Debate over philosophy: “smooth, invisible” translations vs. more literal or annotated ones that preserve nuance and cultural flavor.

Cambridge Analytica and the DSA

• Some argue Cambridge Analytica shows why platforms should refuse data access: “research” can be a cover for abuse and the platform takes the reputational hit.
• Others respond that the EU’s Digital Services Act (DSA) would have blocked that case: no safeguards, no institutional liability, and not focused on systemic risks.
• There’s debate over jurisdiction: critics say DSA can’t realistically control non‑EU actors; supporters point to EU action against companies like Clearview as evidence they are trying to project enforcement extraterritorially, albeit with mixed effectiveness.

Research Access vs Privacy and Liability

• A core tension: regulators want researcher access for transparency; many commenters see this as a “privacy nightmare” and don’t trust academics to secure data.
• Others counter that (a) platforms themselves are the bigger privacy risk, (b) current problem is lack of access even to public data, and (c) DSA access is meant to be aggregate, privacy‑preserving, and heavily filtered.
• Concern is raised that any breach will be blamed on the platform (“5 million Facebook logins hacked”), regardless of who leaked.

Elections, Influence, and “Censorship”

• One side fears unregulated platforms and specific political actors using social media and microtargeting to covertly skew elections, likening this to Cambridge Analytica.
• Another side objects to the phrase “influencing elections,” saying it’s just campaigning and is being selectively framed as sinister when opponents do it.
• Deep disagreement over whether DSA‑style transparency is legitimate oversight or a slippery slope to government‑driven censorship and speech control.

EU Regulation, Industry, and Power Balance

• Critics see the EU as over‑regulating, scaring away “modern industry” and contributing to Europe’s weaker tech sector and economy.
• Defenders argue self‑regulation has failed in other domains; the real goal is balancing power between governments, platforms, and independent researchers.
• Some suggest losing certain US products may be acceptable if it pushes Europe to build its own alternatives.

Implementation, Scraping, and User Consent

• Engineers worry about the practical burden of bespoke data requests; lawyers front it, but engineers must build and run compliance tooling.
• Scraping is proposed as a workaround; others note platforms block and sue scrapers, which is used to justify formal access rules.
• Several commenters are uneasy that platform users become de facto research subjects, with only limited or unclear ways to opt out (e.g., making profiles private).

Nature of LLM Outputs and “Facts”

• Core tension: LLM answers can contain facts, but they are not themselves a reliable source of facts.
• Several comments criticize the slogan “they just predict next words” as overly reductive; it describes the mechanism, not whether outputs are true.
• Others counter that the process matters: a result can be textually correct but epistemically tainted if produced by an unreliable method.
• Some argue LLMs are optimized for human preference and sycophancy—“plausible feel‑good slop”—rather than truth.

LLMs vs Wikipedia, Books, and Search Engines

• Wikipedia is framed as curated and verifiable: content must come from “reliable sources” and represent mainstream views proportionally.
• LLMs, by contrast, draw from an uncurated corpus; curation and explicit sourcing are seen as the key differentiators.
• Parallel is drawn to old advice “don’t cite Wikipedia”; similarly, LLMs and encyclopedias are tertiary sources that shouldn’t be primary citations.
• Some prefer LLMs to modern web search, which is seen as SEO‑polluted; others say it’s effectively the same content with different failure modes.

Citations, Hallucinations, and Tool Use

• Strong disagreement over “LLMs should just cite sources”:
  • One side: Gemini/Perplexity and others already attach links that are often useful, like a conversational search engine.
  • Other side: citations are frequently wrong, irrelevant, or wholly fabricated; models confidently quote text that doesn’t exist.
• Distinction is made between:
  • The LLM’s internal generation (no tracked provenance).
  • External tools (web search, RAG/agents) that fetch real URLs and which the model then summarizes—also fallible.
• Repeated anecdotes of invented journal issues, misrepresented documentation, fake poems and references highlight systematic unreliability.

How (and Whether) to Use LLMs

• Recommended workplace stance: using AI is fine, but the human is fully responsible for verifying code, data, and claims.
• Some see LLMs as “addictive toys” or “oracles”: useful for brainstorming, translation, and sparring when you already know the domain, but bad for learning fundamentals.
• Key risk: wrong and right answers are delivered with the same confidence; corrections often produce more polished but still wrong text.
• Many emphasize critical reading and cross‑checking with primary sources, regardless of whether information comes from AI, Wikipedia, search, or people.

Reactions to the Site and Messaging Style

• Several view the site as snarky, passive‑aggressive, and more like self‑affirmation for AI‑skeptics than effective persuasion.
• Others think the message is obvious and will not reach those who most need it; they advocate clearer norms like “don’t treat chatbot output as authoritative” and teaching deeper digital literacy instead.

Role of uv vs existing tools

• Many see uv as the “npm/cargo/bundler” Python never had: one fast, unified tool instead of pip + venv + pyenv + pipx + poetry/pipenv.
• Others argue the same concepts existed (poetry, pip-tools, pipenv, conda) and uv is mainly a better implementation with superior ergonomics and performance.
• Some prefer minimalism (plain python -m venv + pip) and feel uv mostly repackages workflows they never found painful.

Perceived benefits

• Speed is repeatedly called out: dependency resolution, installation, and reuse from cache feel 10–100x faster than pip/conda/poetry.
• “Batteries-included” workflow: uv init / add / sync / run handles Python version, venv, locking, and execution without manual activation.
• Inline script metadata (PEP 723) + uv run makes single-file scripts self-contained and shareable without explicit setup.
• Good fit for beginners, non-engineers, and “I don’t want to think about environments” users; reduces the biannual “debug Python env day.”
• For some, uv finally makes Python pleasant again compared to ecosystems with strong tooling (Node, Rust, Ruby).

Security & installation debates

• Strong pushback on curl | sh / iwr | iex install instructions: seen as unsafe, unauditable, and bad practice in 2025.
• Counter-arguments: installing unsigned .deb/.rpm is not inherently safer; trust in source matters either way; scripts can be downloaded and inspected.
• Similar concern about scripts that auto-install dependencies at runtime: convenient but expands the attack surface unless constrained to trusted indexes/mirrors.

Limits, pain points, and skepticism

• Some report uv failing where plain venv+pip worked, and note it’s still young with rough edges.
• Complaints: “does too many things,” confusion around new env vars, perceived friction with Docker, lack of global/shell auto-activation, project-centric mindset vs “sandbox” global envs.
• A few hit specific bugs (e.g., resolving local wheels, exotic dependency constraints) and still keep poetry or pip+venv.

Conda, CUDA, and non-Python deps

• Consensus: uv is excellent for pure-Python; conda (or pixi, which uses uv under the hood) still wins for complex native stacks (CUDA, MPI, C/C++ toolchains, cross-OS binary compatibility).
• Some hope uv (or pixi+uv) will eventually reduce reliance on conda, especially in ML/scientific environments, but that’s not solved yet.

Ecosystem, governance, and fragmentation

• Debate over a VC-backed company steering core tooling: some see risk of future “Broadcom moment,” others point to MIT licensing and forking as safety valves.
• Harsh criticism of PyPA’s historic decisions and the long-standing packaging “garbage fire”; uv (and Ruff) are seen as proof that fast Rust-based tools can reset expectations.
• Fragmentation (pip, poetry, conda, uv, pixi, etc.) is still viewed as a barrier for newcomers, even if uv is emerging as a de facto standard for many.

What the hardware is supposed to be

• Commenters converge that this is not a general-purpose CPU/GPU replacement but specialized analog/stochastic hardware.
• Core idea: massively parallel “p-bits” implementing Gibbs sampling / probabilistic bits, i.e. fast, low-energy sampling from complex distributions rather than simple uniform RNG.
• One view: they’re essentially an analog simulator for Gibbs sampling / energy-based models, potentially useful for denoising steps in diffusion or older Bayesian/graphical model workloads.

Relationship to prior work and terminology

• People note prior companies (e.g., other “thermodynamic computing” / stochastic hardware efforts) and say Extropic has already shifted from superconducting concepts to standard CMOS.
• Several argue this is just stochastic or analog computing under new branding; “thermodynamic computing” is criticized as buzzwordy and potentially misleading.
• Others say the underlying ideas are decades old (stochastic/analog computers, probabilistic programming), with the novelty largely in CMOS integration and scale of RNG/p-bits.

Claims, benchmarks, and real-world value

• There is real hardware, an FPGA prototype, an ASIC prototype (XTR-0), a paper, and open-source code; some stress that this makes outright “vaporware” accusations unfair.
• Skeptics counter that existence of hardware and a paper does not imply commercial relevance; benchmark examples (e.g., Fashion-MNIST) are seen as unimpressive and small-scale.
• Questions raised:
  • Are the quoted 10×–100× speed/energy gains versus CPU/GPU meaningful at full-system level (Amdahl’s law)?
  • Why highlight FPGA comparisons instead of showing FPGA products or just doing a digital ASIC first?
  • Is random sampling actually a bottleneck in modern AI workloads? Many say no for today’s deep learning.

Fit with current AI paradigms

• Multiple comments argue the stack appears optimized for 2000s-era Bayesian / graphical / energy-based methods, not for today’s large transformer models where matrix multiplies dominate.
• Some speculate this could enable a “renaissance” of sampling-based methods; others think it’s too late and will stay niche unless model paradigms shift.

Hype, aesthetics, and skepticism

• The website’s heavy visual flair, cryptic runes, and slow, CPU-hungry frontend strongly contribute to “hype/scam” vibes.
• Opinions split: some see genuine, risky deep-tech experimentation; others see overblown marketing, vague claims, and unclear answers to basic practical questions (precision, verification, ecosystem, reproducibility).