Hacker News, Distilled

Motorola–Amazon affiliate behavior

• Phones replace the standard Amazon app shortcut with one that routes through an affiliate URL, likely earning commissions on users’ purchases.
• Some see “hijacking the app” as overstated, framing it instead as typical OEM scummy behavior (bloatware, adware, “anti‑malware”, lock‑screen ads, etc.), but still a trust violation.

Intentional scam vs. mistake

• The use of a fashion‑influencer‑like domain and mismatched affiliate codes leads several to suspect something “off”: possibly a rogue employee, compromised update, or misconfigured marketing tooling.
• Others note that affiliate programs allow multiple codes; nothing in the thread conclusively proves intent.
• Commenters highlight that modern workflows (large PRs, weak code review, Google Tag Manager–style systems) make it easy for marketing or insiders to slip in such behavior. Overall motivation and responsibility remain unclear.

Broader OEM adware and tracking

• Many report Motorola phones auto‑installing unwanted apps and games, sometimes via non‑removable system components (e.g., Moto App Manager, AppCloud‑like services, Taboola/Glance‑style feeds).
• Similar or worse practices are attributed to other Android OEMs (Samsung, Xiaomi, “clean Android” brands adding app‑installers, carrier bloat, lock‑screen ads). Lenovo’s Superfish history is repeatedly cited.
• Some users say Fairphone and Sony devices are relatively clean; others emphasize that effectively all mainstream phones have some form of telemetry or preloaded junk.

Mitigations and user strategies

• Techniques mentioned: disabling specific Motorola system apps, using ADB/Universal Android Debloater, or Digital Wellbeing timers set to 0 minutes to permanently “pause” auto‑installers.
• Custom ROMs (LineageOS, /e/OS, GrapheneOS) are seen as key escape hatches, but bootloader unlocking is increasingly restricted (e.g., Xiaomi’s daily unlock quota lottery).
• Banking/ticketing apps often refuse to run on rooted or custom ROM devices, forcing some users back to stock OS for practical reasons.

GrapheneOS–Motorola partnership

• Several are reconsidering Motorola purchases despite the planned GrapheneOS support.
• One side argues the partnership is purely about hardware meeting strict requirements; GrapheneOS images stay fully under project control, with no OEM bloat.
• Skeptics worry that any “partnership” with a company engaging in adware/affiliate schemes could erode project independence or appear to endorse Motorola’s practices.

Wider context

• Many see this as part of long‑running “enshittification”: PCs with crapware, carrier‑modified feature phones, phones and banks monetizing user data, locked bootloaders, and app ecosystems hostile to user control.
• There is recurring advocacy for legal rights to unlock bootloaders and for genuinely user‑controlled, de‑Google’d, non‑adware phones.

Overall sentiment

• Opinions are sharply divided: some genuinely enjoy React, others tolerate it for work, and many actively dislike it.
• Several see it as “the worst option except for all the others we’ve tried”; others call it overhyped, bloated, or even harmful to frontend practice.

Why people like React / JSX

• The component model (UI as a function of state) is praised for composability and mental clarity, especially compared to jQuery, Backbone, and AngularJS.
• JSX is widely liked, sometimes more than React itself: mixing markup and logic in one file and reusing plain JS control flow feels natural and expressive.
• React’s declarative approach to DOM updates is seen as a huge improvement over manual DOM manipulation for complex interactive apps.
• Some like the ecosystem: GraphQL integration, React Query/TanStack Query, Vite, and tools like the React Compiler that reduce boilerplate.

Major criticisms of React and its ecosystem

• Hooks are viewed by many as confusing, leaky abstractions with subtle rules and performance traps; some miss the old class lifecycle model.
• React apps often break web fundamentals (navigation, back button, accessibility), especially in badly built SPAs.
• The ecosystem is fragmented: every codebase assembles a different stack of routers, state libraries, and data layers, making projects inconsistent and hard to onboard.
• Server Components and Next.js (under Vercel) are criticized as too “magic,” security‑prone, tightly coupled to specific hosting, and driving React’s direction in opaque ways.
• React is blamed for frontend bloat, over-engineering simple CRUD apps, and encouraging megabyte bundles for problems solvable with HTML+forms.

SPAs vs server-rendered / lighter stacks

• Many argue most sites should be multi-page apps with server rendering and small “islands” of JS, using tools like HTMX, Alpine, web components, or vanilla JS.
• Others counter that rich interactivity, complex state, and “polish” often justify SPA complexity.

Alternatives and comparisons

• Svelte, Vue, Solid, Angular, Lit, Elm, and web components are all mentioned; each has fans who find them simpler, faster, or more ergonomic.
• Signals/fine-grained reactivity (Vue, Solid, newer Angular, Svelte runes) are seen by some as a cleaner model than React’s re-render and hooks approach.

Ecosystem, inertia, and hiring

• React’s dominance is widely attributed to inertia, hiring pool size, and corporate backing, not just technical merit.
• Many choose it pragmatically (“no one gets fired for choosing React”) while personally preferring other tools.

Vulnerability & Affected Systems

• CVE-2026-28952 is an integer overflow in the macOS kernel, fixed via better input validation.
• It is fixed in macOS Tahoe 26.5 and also in specific iOS, iPadOS, Sequoia, and Sonoma versions.
• Some commenters initially misread it as a new Tahoe-only bug; others clarified it is a bug fixed in 26.5, not introduced there.
• There is some confusion over exactly which prior OS versions were affected; Apple’s notes are seen as less explicit than third‑party CVE records.

Role of AI Tools (Claude/Mythos)

• The CVE credits collaboration with Anthropic tools; another linked thread suggests Mythos was used to help build an exploit quickly.
• Some see this as evidence that AI-assisted security research is already practical.
• Others emphasize this is incremental on top of long‑standing techniques like fuzzing, not magic.

Security Testing & Why Bugs Persist

• Debate over whether traditional SAST/DAST/fuzzing “should have” found this bug.
• One side argues mature tooling already exists and often isn’t run systematically due to cost, complexity, or prioritization.
• Others counter that large vendors already fuzz at massive scale and hire external assessors, so “they just didn’t run tools” is not convincing.
• Several possibilities are raised: testing the wrong configurations, incomplete fixes, bad luck in fuzzing, or focusing on changing components.

Apple’s Security Posture

• Mixed views: some argue Apple is not particularly security‑focused historically on macOS and lagged on mitigations (ASLR, SIP, etc.).
• Others claim Apple has led on many OS security features and now has strong architectural protections, especially post–Apple Silicon.
• There is speculation (framed as unofficial) that Apple already uses frontier AI models internally but avoids publicizing it.

Update Strategy & Patch Cadence

• Older norm of long uptimes is seen as incompatible with modern security; frequent updating feels necessary.
• Some historically stayed one major or point release behind but now feel pressure to stay on the latest for security reasons.
• Others note Apple backports security fixes to older major versions, so jumping to the newest OS is not always required.

Future of Automated Security Auditing

• Several expect continuous AI/agent-based vulnerability scanning to become standard, funded by “token budgets” and sold as security services.
• Comparisons are made to existing large-scale fuzzing infrastructures and CI/CD security pipelines.

Update Size, Storage, and User Friction

• Many complain about huge update sizes (often 10–13+ GB) and dual-architecture images.
• Users with 32–64 GB devices struggle to free enough space for OTA updates, especially when the OS and “system data” already consume much of the storage.
• Workarounds like tethered/desktop updates exist but are seen as poor UX and “malpractice” when critical security fixes are bundled into massive images.

Kernel, C, and Systemic Risk

• Multiple simultaneous kernel bugs across projects are viewed as evidence of a large, fragile attack surface.
• Commenters note that most listed CVEs are memory-safety issues (overflows, UAF, OOB), blaming continued use of C.
• Some argue stronger type systems or capabilities-based designs could also help with permission and logic issues, but such OS architectures have seen limited adoption.

Rust performance and safety overhead

• Bounds checks usually cost a few percent, but can reach ~20% in some hot paths or block autovectorization.
• Techniques to reduce bounds checks include range-based iterators, slicing, explicit assert!s, and carefully placed unsafe.
• When C++ is compiled with strong hardening (_FORTIFY_SOURCE, sanitizers, hardened STL), it often becomes slower than Rust for equivalent safety.
• Integer overflow checks are expensive but are disabled in Rust release builds by default; they can be enabled if desired.

Bounds checking, optimization, and proofs

• Rust currently lacks a stable, explicit contract for carrying high-level invariants from HIR to MIR, making sophisticated proof-based elimination of checks difficult.
• LLVM’s scalar evolution (SCEV) is language-neutral and can’t exploit Rust-specific invariants well.
• Bounds-check hoisting in MIR is possible but thorny: the compiler must preserve exact panic behavior and messages, and must reconstruct information lost during iterator lowering.
• Some bounds-check patterns can already be removed via explicit asserts that LLVM can prove.

Comparisons with C and C++

• One position: Rust is roughly as fast as C; modern C++ can be faster in practice due to powerful metaprogramming enabling zero-cost abstractions.
• Counter-position: raw compiler optimizations on LLVM IR are shared, so C, C++, Rust, and Zig should be comparable; differences come from ergonomics, LTO, and how code is written.
• C++ templates and constexpr are praised for enabling high-performance generic algorithms; others argue they increase complexity and can bloat code.
• Rust’s strict aliasing rules can theoretically outperform C/C++, but current backends underutilize this potential.

Other languages and metaprogramming

• Zig and Nim are cited as having strong compile-time metaprogramming; Nim’s crypto library is claimed to outperform C via generated assembly.
• Julia and Fortran are mentioned as highly performant in numeric domains, but Julia is not considered a systems language.
• Refinement-type approaches (e.g., Flux for Rust) aim to statically eliminate bounds checks.

Panics, exceptions, and semantics

• Rust panics are catchable (like C++ exceptions), so the compiler cannot freely “time-travel” panics (e.g., hoisting a bounds failure to loop entry) without changing observable behavior.
• Different rewrites of an out-of-bounds loop change when and where the panic occurs, which matters if panics are caught.

Compile times and tooling

• Multiple comments criticize Rust’s slow compilation for large projects, harming the edit–compile–run loop.
• Mitigations discussed: splitting code into multiple crates for parallelism and caching, reducing heavy proc macros (notably serde), using faster linkers (lld, mold), and caches like sccache/kache.
• Rust’s single-crate “translation unit” model limits parallelism within a crate; LTO trades compile speed for runtime speed.
• Some expect compiler parallelism and infrastructure work to improve this over time.

Ergonomics and real-world experience

• Several practitioners report that writing truly high-performance code is:
  • Easiest in C++ (templates, allocators, compile-time tricks),
  • Much harder in C (no integrated generics),
  • Rust encourages safer, cache-friendly patterns and avoids some C++ pitfalls (e.g., overuse of inheritance and vtables).
• A recurring theme: there is “no performance of a language” in the abstract; real performance depends on compilers, tooling, and what programmers are willing and able to express ergonomically.

Role of Programming Books vs. Other Resources

• Many say books are no longer primary; web docs, tutorials, and now LLMs cover most day‑to‑day needs.
• Others report buying and reading more books recently because they provide curated scope and order, compared to overwhelming, fragmented online info.
• Several distinguish: use LLMs/docs for specific problems, books for fundamentals, architecture, and “big picture.”
• Some argue books were never ideal for learning languages; interactive platforms, REPLs, and hands‑on projects work better for many.

Learning Styles and Mental Models

• Strong theme: people learn differently. Some need interactive exercises; others happily learn by reading dense texts.
• Advocates of books emphasize:
  • Deliberate sequencing of concepts.
  • Building a coherent mental model, avoiding random “piecemeal” knowledge and gaps.
  • Exposure to peripheral ideas you wouldn’t think to search for.
• Critics counter that many language books are shallow, syntax‑heavy, or quickly obsolete; theoretical and systems books age better.

LLMs, Skills, and Code Quality

• Common practice: pair books with LLMs—read a chapter, then query AI for clarification, tangents, or debugging help.
• Concern that LLM‑driven workflows can freeze or erode genuine skill growth; people may ship “first drafts” and accumulate debt.
• Multiple comments stress juniors still need to learn to code and understand concepts to:
  • Guide agents with correct vocabulary.
  • Evaluate and review AI‑generated code.
• Interview anecdote: candidates who couldn’t code manually also failed with AI assistance.

Economics, Piracy, and Decline of Book Culture

• Reported sales data for one language book show tens of thousands of copies, but revenue is modest; most income now comes from subscription platforms.
• High retail prices and cheaper or pirated PDFs (Libgen, Anna’s Archives) push younger devs away from buying.
• Several note LLMs were trained on “pirated” books and online Q&A; some see this as theft, others as analogous to earlier digital copying.

Stack Overflow and AI

• SO question volume has dropped sharply; some see it as “dying,” replaced by LLMs for routine questions.
• Views on SO are mixed: invaluable in its prime but plagued by harsh moderation and aging, obsolete answers.
• Worry that as sites and blogs decline, LLM training data and the broader technical ecosystem will suffer.

Nostalgia and Timeless Texts

• Many cherish classic books (C, OS, networking, algorithms, SICP, etc.) as milestones and enduring references.
• Some fear that with AI and fewer books, future developers will lack that shared canon and personal “history on the shelf.”

Roles AI Plays in Coding

• Used as tutor, rubber duck, and design partner: explain unfamiliar tech, critique plans, suggest alternatives, generate practice problems, and help with specs/PRDs.
• Popular as code reviewer and bug-finder: spot corner cases, security issues, performance bottlenecks, inconsistent patterns, and missing tests.
• Often employed for boilerplate, repetitive refactors, test generation, documentation, and comments, while humans handle architecture and critical paths.

Workflows and Practices

• Many describe multi-step loops: human drafts requirements → AI proposes plan → human refines → AI implements in small chunks → AI(s) review → tests/benchmarks → further refactors.
• Some orchestrate multiple models in series or parallel (implementation vs review vs specialized audits) and use skills/guardrails (e.g., “don’t hand-roll, prefer libraries”; “treat each change as a PR with tests”).
• Others prefer minimalism: write most code by hand, let AI fill small gaps, review code, or generate specs from conversations.

Speed, Productivity, and Cost

• Some claim substantial speedups (e.g., “v3-quality in v1 time”, hitting OKRs earlier) even with long AI review loops.
• Others report parity or slower progress versus manual coding, but with higher final quality and more explored alternatives.
• Token cost and provider limits/outages are real constraints; people discuss cheaper models, local models, and being “token-efficient” as a skill.

Code Quality, Comprehension, and Learning

• Thread strongly emphasizes staying “aware” of all generated code and maintaining a mental model; fear of cognitive offloading and “anchoring” on AI’s first attempt.
• Opinions split on AI code quality: some say modern models beat most humans on small snippets; others find it technically correct but ugly, overengineered, or context-blind.
• Several report genuine learning: new patterns, idioms, and designs from reading AI code and arguing through trade-offs.

Skepticism and Risks

• Concerns about “slop”: large, poorly factored AI-generated code, endless review loops, and accumulating tech debt that no one truly understands.
• Worries about burnout from supervising many agents in parallel, constant context switching, and pressure to ship more with less time.
• Ethical and organizational fears: dependence on vendors, layoffs justified by AI, management pushing unsupervised agentic coding, and loss of craftsmanship and “taste.”

Overall sentiment

• Strong consensus that walking boosts creativity, problem-solving, and mood.
• Many say the study merely confirms what’s “obvious” from lived experience, but still value having data.

Personal experiences & analogues

• Numerous anecdotes of solving bugs or hard problems while:
  • Walking (commutes, loops around lakes, office corridors, city streets, nature trails).
  • Doing light, repetitive tasks: mowing lawns, washing dishes, riding tractors, driving on highways.
  • Showering, running, biking, or right before/after sleep.
• Some use walks to triage the day, think through life decisions, or mentally compose code and prompts.

Proposed mechanisms

• Light movement plus low cognitive load frees attention for “background” processing.
• Mentions of the brain’s default mode network and “mind-wandering” as key for insight.
• Removal or reduction of stimuli (no phone, no headphones) is often cited as crucial, but:
  • Others prefer a bit of distraction (music, podcasts) to break fixation, then silence.
• Comparisons to therapy techniques (e.g., bilateral stimulation in EMDR) as a possible parallel, but speculative.

Work, productivity, and tools

• Many programmers report breakthroughs only after stepping away from the computer.
• Walking is woven into routines: Pomodoro-style breaks, daily 5k walks, “working walks” for calls, one‑on‑one meetings done while walking.
• Some use dictation plus AI to turn walks into a primary work mode; others see AI as reducing the joy of “sleep-on-it” insights.
• Frustration with workplaces that equate “not at desk” with “not working.”

Environment, gear, and lifestyle

• Preference for green or quiet spaces, but even busy cities, malls, or pacing at home can work.
• Interest in walkable cities; some move away from dense urban areas to get better walking environments.
• Use of standing desks, under‑desk treadmills, walking pads, and “treadmill desks” to integrate movement indoors.
• Walks also credited with weight loss, pain reduction, stress relief, ADHD management, and better sleep.

Skepticism & caveats

• A minority find mid‑day walks disruptive to focus; walks help more before or after work.
• Some question the study’s creativity measures (e.g., toy tasks) and generalizability.
• Others note that simply leaving the desk isn’t inherently meditative; intent and mental habits still matter.

Overall sentiment

• Thread is overwhelmingly negative on the car as a Ferrari, with some pockets of enthusiasm for specific ideas and the interior.
• Many distinguish between “nice EV” and “appropriate Ferrari”; they see a mismatch between brand heritage and this product.

Exterior design & brand identity

• Frequent claim: it “doesn’t look like a Ferrari.” Lacks traditional Ferrari proportions, drama, and visual cues.
• Compared unfavorably to mass‑market or mid‑market EVs: Kia, Hyundai, Polestar, Tesla, Nissan Leaf, Prius, BYD, generic Chinese EVs.
• Styling likened to an Apple Magic Mouse, smartphone, Pixar car, sneaker, or “vape cartridge on wheels.” Some call it Fiat Multipla / Pontiac Aztek‑level misstep.
• Front end and overall “blob” aero shape heavily criticized; rear lights and truncated rear also widely disliked.
• A minority find the exterior attractive or at least interesting and think it may age into an icon, but often still say it’s not “Ferrari enough.”

Interior, UX, and controls

• Interior generally receives far more praise:
  • Appreciated: physical knobs and switches, analog‑digital blend, passenger display, hand‑rest for climate controls.
  • Seen as a good direction away from pure touchscreens, with better ergonomics and tactile feedback.
• Critiques:
  • Large central “tablet” still disliked as distracting and trend‑driven.
  • Steering‑wheel knobs, touch buttons for indicators, and some layout choices seen as gimmicky or ergonomically dubious.
  • Piano‑black plastics and persistent reliance on screens still irritate some.

Powertrain, performance, and sound

• Specs noted: 1050 hp, large battery (122 kWh), ~280 mi EPA range, ~5100 lb, four‑wheel steering, active suspension.
• Many argue efficiency is poor relative to Teslas and other EVs; others respond that Ferraris have never prioritized efficiency.
• “Torque language” paddles (multiple power and regen levels) are viewed either as a clever way to add engagement or as marketing fluff.
• Sound system using axle vibrations instead of synthesized engine noise divides opinion:
  • Supporters see it as a more authentic alternative to fake sound.
  • Critics think it’s pointless complexity and would prefer near‑silence.

Target market, pricing, and strategy

• Price (~$600–650k) widely seen as shocking given the family‑car silhouette and “generic EV” look.
• Many think it’s aimed at wealthy buyers who want a practical 4–5‑seat status EV (e.g., Cayenne/Urus‑type use, “school run” car, tech‑wealth crowd).
• Strong belief that Ferrari will use it as a “loyalty test”: customers may be pushed to buy it to secure allocations for future halo models.
• Deep concern that this dilutes Ferrari’s visual and emotional identity; some fear a “Jaguar‑style” brand misstep, others frame it as a necessary, high‑risk transition into EVs.

Overall reception

• Many commenters find the site “cool”, “sick”, nostalgic, and visually appealing; several say they might adopt it as their default HN client.
• Others describe it as “beautifully unusable” or anxiety‑inducing, appreciating the concept but not the practicality.

Design & layout

• Newspaper‑like aesthetic, yellowish paper texture, and grid layout get strong praise for coziness and nostalgia.
• Critics say the masonry/grid doesn’t behave like a real newspaper: no clear “main story” anchor, columns don’t line up, and information feels scattered.
• Some prefer a simpler, more scannable layout and compare favorably/negatively to other HN frontends.

Typography & readability

• Repeated complaint: body text and meta text are too small; many users zoom to 150–200% or override CSS.
• Tight line spacing and justified text reduce readability, especially on tablets and wide screens.
• Suggestions: larger default font, more leading, three columns instead of four on most viewports, optional left alignment, browser hyphenation, and a configuration menu for text size and alignment.
• A few users say they like the small size and ask for options rather than a hard change.

AI summaries and content

• Summaries help surface stories users otherwise wouldn’t click; less “clicking” is appreciated.
• Criticisms: one‑paragraph summaries are hard to read; paragraphs mix multiple ideas; some call it “AI slop” and worry about inaccuracies and generic phrasing.
• Requests for: multi‑paragraph formatting, optional use of original snippets/README text, a global toggle between AI summary vs snippet, and tag/category extraction.
• Some note failures on JS‑heavy or paywalled sites and question the ethics of using Googlebot‑style user agents to bypass paywalls.

Performance & technical implementation

• Some previews load slowly due to large, unprocessed OG images and front‑page traffic.
• The author explains: a scraper hits HN every 10 minutes, uses Puppeteer/Chrome with a spoofed Googlebot UA, extracts document.body.textContent, sends it to a free AI endpoint for summarization, and runs the stack on a small VPS with Bun.

Feature requests & enhancements

• Ideas include:
  • Different column templates and random “newspaper” layouts.
  • Hero article and size scaling based on points/upvotes.
  • Infinite scroll (already present) and better pagination metaphors (“page 2”).
  • Options to collapse summaries for skimming.
  • Retro filler ads at the bottom.
  • RSS reader or other feeds in the same style.

Technical feasibility of Mach‑5 flight

• Commenters stress that an engine alone doesn’t make 2‑hour transpacific flights feasible; materials, thermal management, and airframe design are major unsolved issues.
• Hypersonic air‑breathing propulsion (ramjet/scramjet) is described as much harder than rocket-based hypersonic flight: internal shockwaves and heat loads inside the duct are key constraints.
• Some think hypersonic air‑breathing is “nowhere near” solved; others point to rumored programs (e.g., SR‑72, Meteor missile) as evidence the puzzle may be cracked for military-scale craft.
• Noise and structural vibration are expected to be significant for passengers, even at high altitude, due to transmission through the fuselage.

Passenger travel vs. missiles

• Many argue the obvious first application is hypersonic missiles, not passenger jets, given complexity, heat, and startup-speed requirements.
• Ramjets need high initial speeds; practical designs likely require separate propulsion (e.g., rockets or conventional jets) to get to ignition speed.
• Several posts suggest the “Mach‑5 passenger jet” narrative is partly cover or aspirational; the real driver is seen as cruise-missile tech and advanced fighters/interceptors.

Economics and market

• Concorde is repeatedly cited: technically impressive but economically marginal, with limited routes, high fuel burn, and sonic boom restrictions.
• Some say today’s world—more ultra‑wealthy, more long‑haul Asia–Pacific traffic—could support a boutique supersonic/hypersonic market, especially for business jets and key executives.
• Others argue there are no economies of scale; certification, maintenance, training, and separate fleets make commercial viability unlikely, even with high ticket prices.

Alternatives: suborbital and existing air travel

• Suborbital hops are proposed as more sensible for extreme speed: shorter global travel times, avoidance of sustained hypersonic heating, and a brief weightless experience.
• Discussion highlights that door‑to‑door time is dominated by ground logistics and airport security; some see this as the real bottleneck, others say trusted-traveler programs already minimize this for the target clientele.

Environment, safety, and politics

• Environmental impact is a major concern; some see hypersonic passenger travel as incompatible with climate goals.
• Several view this primarily as part of a broader hypersonic weapons race and missile defense ecosystem, not a civil aviation revolution.

Hardware and Storage Setup

• 2 PB of Huawei flash is used as a fast preprocessing tier (dedupe, cleaning, normalization) for ~60 PB of raw data, not as total training data.
• Several commenters argue 2 PB is modest by modern standards; individuals can approach that in spinning disks. Others note cost and performance at this scale are still substantial.
• Some see the article as oddly focused on the storage brand and appliance rather than on overall system architecture.
• Concerns are raised about extreme density (multi-Tbit/s links into a 2U box) creating power/network “hotspots” and limited real-world throughput.

Feasibility of Training and Hardware Adequacy

• The Cray system (hundreds of GPUs, tens of thousands of CPU cores) is called “meager” by some, who doubt Norway can train a “fully fledged” frontier LLM and suspect waste.
• Others counter that comparable clusters have trained strong models, that most labs experiment on <500 GPUs, and that this is sufficient for national-scale work and institutional learning.
• Some see it as an impressive proof-of-concept rather than a final, globally competitive system.

Sovereign LLM vs Using Frontier Models

• Core argument for a sovereign Norwegian LLM:
  • Reduce dependence on foreign, especially US, corporations.
  • Capture local history, law, news, and culture, including dialects and older orthography.
  • Avoid American-centric style, morals, and values being imposed even when chatting in Norwegian.
• Skeptics ask who will actually use a weaker domestic model, and argue better search/agents over the library corpus or sharing curated Norwegian datasets with major labs might yield more utility.
• Some frame the project as cultural preservation and “applied humanities,” not pure economic efficiency.

Language, Tokenization, and Cultural Representation

• Multiple comments note that current English-heavy tokenizers make Norwegian and similar languages 1.5–3x more token-expensive, affecting cost and sometimes quality.
• Frontier models often “think” and search in English, then translate, leading to style drift and cultural misalignment even when the output language is correct.
• Debate over whether English-trained models already “know Norwegian well enough” versus needing a dedicated model to capture nuance and non‑Anglo tone.

Data, Copyright, and Access

• Norway’s National Library holds a uniquely comprehensive, legally deposited digital collection; private companies lack equivalent access.
• Special agreements allow LLM training on copyrighted news and other material that cannot simply be released as an open dataset.
• Some would prefer more public access to out‑of‑copyright data; legal and institutional constraints limit that, making LLM training a workaround for exploiting the archive.

Overall reaction to the law

• Many think the law is fundamentally bad and should be repealed, not patched with exemptions.
• Others see it as part of a broader, popular push to restrict kids’ access to harmful online content and social media, even if implementation is messy.
• Several argue California politicians are driven more by optics (“protect the children”) and donor interests than technical reality or civil liberties.

Linux / FOSS exemption

• Amendment exempts operating systems/applications whose licenses allow copying, redistribution, and modification (commercially, royalty‑free).
• Commenters note this likely covers Linux and BSDs, but not Android in commercial form (Apache 2 + proprietary layers) or Windows/macOS.
• Some worry about edge cases: composite products, corporate Windows rights to copy/modify binaries, Tivoization, and “source vs software” wording.
• Colorado’s similar FOSS exemption is cited; some suggest tightening language to explicitly require modifiable source code and no platform locks.

Privacy, surveillance, and regulatory capture

• Strong concern that age‑gating at the OS level is a step toward deanonymizing the internet and building ID‑linked device registries.
• Many see big platforms (especially Meta) pushing OS‑level age checks to shift cost and liability away from themselves and entrench incumbents (“regulatory capture”).
• Some frame this as part of a wider anti‑VPN / pro‑surveillance trend, not genuine child protection.

Parental controls vs. age verification

• Broad agreement that controls should be client‑side and parent‑driven, not universal ID checks affecting adults with no children.
• Long sub‑thread proposes using an RTA‑style HTTP header (or richer content descriptors) plus browser/OS parental controls, with “adult by default” unless approved by parents.
• Others flag problems: mixed‑content sites (e.g., Wikipedia, social media), per‑country standards, liability incentives to over‑label as “adult”, and poor historical adoption of such schemes.

Constitutional and societal issues

• Some argue device‑level age gating and mandatory classification are compelled speech and incompatible with the First Amendment.
• Others counter that society already accepts age limits on alcohol, tobacco, porn, and physical venues; the disagreement is over means, not ends.
• There’s deep division between “no restrictions at all” advocates and those prioritizing collective action to reduce social media harms to minors.

Confusion about the actual CA law

• Several note that many comments conflate different jurisdictions’ age‑verification schemes.
• Clarifications: the California approach discussed is described as an OS‑level age bracketing / parental‑control system for child‑primary devices, not mandatory government ID checks or direct PII sharing with apps—though critics still see it as a dangerous precedent.

What “Tokenmaxxing” Actually Is

• Companies incentivize or require engineers to maximize AI token usage, sometimes with leaderboards and perceived ties to performance reviews.
• Reported Uber numbers (via linked coverage): average AI spend of ~$150–$250 per engineer/month, with “power users” at $500–$2,000.
• Some devs say they now feed models pointless tasks just to avoid looking like “low users.”

Costs, Subsidies, and Economics

• Many argue current token prices are heavily subsidized by VC or model vendors; once subsidies end, heavy agentic use may rival or exceed junior salaries.
• Others counter that inference is highly optimizable, open-weight models are improving fast, and labor has a hard cost floor, so AI should eventually be cheaper than humans for many tasks.
• Skepticism that major model providers are truly profitable; comparisons to prior bubbles and expectations that a recession will purge weak AI offerings.

Goodhart’s Law and Management Critique

• Strong consensus that “tokens used” is a bad productivity metric, likened to lines-of-code or hours-at-desk.
• Example behaviors: agents chatting with each other, redundant tool calls, and feature work driven by metric-chasing rather than user value.
• Some see executives as herd-followers reacting to investor/board FOMO; others defend “burn money now” as an intentional exploration phase to find high-value workflows.

Productivity, Quality, and Engineering Culture

• Reported gains range from “not helpful” to ~20% boost, with many warning that massive claimed multipliers are hype.
• Concerns that junior engineers using AI for everything don’t build real understanding; rise of fragile, “vibe-coded” PoCs that become production-critical.
• Teams struggle to measure real ROI: many tokens can produce many low-impact features; fewer tokens can yield one high-impact change.

Local Models, Security, and Architecture

• Debate over centralized data centers vs. GPUs per dev; some believe local/open models (e.g., DeepSeek, Mistral) plus internal hosting will undercut cloud APIs.
• Security worries about sending sensitive data to third-party APIs, especially foreign ones; local hosting seen as a mitigation.

Uber-Specific and Broader Strategy Questions

• Some question why a 16-year-old “taxi + food delivery” firm still needs thousands of engineers; others point to enormous regulatory, tax, payment, and locale-specific complexity.
• Many expect a shift from “use as much AI as possible” to “use the right model, minimally, for clear business value.”

7‑Eleven Japan’s Business Model and Legacy

• Commenters highlight that 7‑Eleven Japan was not just a licensee but a major retail innovator in Japan: franchising, just‑in‑time inventory, centralized POS, and sophisticated cold-chain logistics.
• The company is credited with transforming both large grocery and mom‑and‑pop convenience retail, and later tying stores into early e‑commerce (ticketing, pickups, online orders).

Customer Experience: Japan vs. US and Other Countries

• Many describe Japanese 7‑Eleven (and other “conbini”) as clean, ubiquitous, and reliable for good, cheap, quick meals; tourists often visit daily.
• Others caution that food is still processed and nutritionally mediocre, and that locals silently judge people who live off conbini food.
• Compared with Western convenience stores, though, Japanese offerings are widely viewed as far superior in quality and consistency.
• Stores in Hawaii, Taiwan, and parts of Mexico are seen as closer to the Japanese model than mainland US outlets.

Pricing, Affordability, and Japan’s Economy

• Debate over whether tourists find 7‑Eleven cheap mainly due to the weak yen vs. deeper structural stagnation in Japan’s economy.
• Some argue Japan has slipped toward “second‑tier” income levels; others emphasize lower housing/transport costs and different housing culture (homes as consumer goods, not investments).
• Consensus that convenience stores are 30–50% more expensive than supermarkets for locals, even if still good value to visitors.

Food Quality, Health, and Waste

• Strong enthusiasm for specific items (onigiri, sandwiches, fried chicken, desserts), including value vs. US equivalents.
• Counterpoint: still “processed crap” by local standards, just very good for what it is and uniquely convenient.
• Fresh‑food model generates significant waste. In Japan, a lot is reportedly trashed; discounting was historically restricted, and donating to homeless is uncommon.
• Discussion in the US context about informal donation/giveaway practices and whether support infrastructure must precede such a model.

Payments, ATMs, and Transit Cards

• Historically, 7‑Eleven ATMs were crucial for foreign cards; more ATMs now support them, but reliability and fees still vary. 7Bank ATMs remain favored.
• Japan has rapidly shifted toward electronic payments (notably PayPay).
• Long subthread on Suica/PASMO and FeliCa: hardware support, regional software locks, licensing costs, and experiments with Visa/Mastercard contactless on transit.
• Despite progress, visitors are advised (by commenters) that cash remains essential due to many cash‑only merchants and sometimes finicky online card verification.

Ownership, Strategy, and US Operations

• 7‑Eleven US has been fully owned by the Japanese parent for decades.
• Organizational structures differ: heavily franchised in Japan vs. a mix of corporate and franchise in the US.
• Skepticism that the Japanese fresh‑food model can be replicated in the US due to lower density, logistics, and food‑waste issues.
• Some report deterioration of US chains acquired by 7‑Eleven (notably Speedway), contrasting with “race to the top” competitors like Buc‑ee’s, Sheetz, Wawa, etc.

Urban Form, Safety, and Culture

• In Japan (and some other “safe/high‑trust” countries), children are seen using convenience stores and public transit alone; contrasted with US/Canadian norms shaped by fear and car‑centric planning.
• Commenters note that pedestrian and traffic safety, not just crime, constrain children’s freedom in many places.

Web Experience and Alternate Links

• Complaints about the ad‑heavy original biography site lead to ad‑blocker recommendations and alternate obituary links (CNN, NYT).

Miscellaneous Notes and Trivia

• Mentions that 7‑Eleven originated in Dallas and is now a significant cultural fixture in both the US and Japan.
• Observations that some of the world’s highest‑grossing 7‑Eleven stores are in Denmark.
• One commenter questions the broader public significance of Suzuki’s biography; another pushes back against turning an obituary thread into nationalistic criticism.

Product & Positioning

• Chert is pitched as “Twilio for iMessage”: an API to send/receive iMessages (with SMS/RCS fallback) for business use cases like customer support, scheduling, cart reminders, and form-fill follow-ups.
• Founders emphasize scale, stability, and a managed service over DIY Mac/AppleScript setups, claiming most businesses don’t want to run their own iMessage infrastructure.
• They argue iMessage feels “more conversational” than SMS/RCS due to blue bubbles, typing indicators, reactions, and US user familiarity.

Competition & Alternatives

• Multiple commenters point out existing similar products (e.g., other iMessage gateways, AI agent platforms) and question differentiation.
• Others note that Apple already provides “Messages for Business,” with richer features (forms, quick replies, app payloads) and CRM integrations.
• Founders reply that Apple’s official solution is slow to onboard, restrictive, inbound-focused, and uses visually distinct “business” bubbles.

Spam, Abuse, and User Experience

• A large portion of the thread is hostile to the idea, associating it with more spam, deceptive bots, and erosion of trust in iMessage.
• Many users explicitly say they want fewer business messages, prefer email or SMS for transactional content, and will report “abandoned cart” style messages as spam regardless of opt-in language.
• Founders say they focus on opt-in and high-importance cases (e.g., after-hours support), manually vet customers, and monitor line “health,” but admit they’re not self-serve yet and rely on process rather than strong technical safeguards.

Apple ToS & Platform Risk

• Multiple commenters cite Apple’s own language that iMessage is for personal use, not commercial messaging, and predict an eventual ban similar to the Beeper Mini case.
• Chert argues Apple is mainly against spam, points to AppleScript and existing “agents,” and believes compliant, consented use will be tolerated.
• Many see this as naïve; they stress Apple can shut it down for any reason and that the entire business is “built on quicksand.”

Meta: YC Funding & Ethics

• Commenters are surprised YC funded a model with such obvious platform and legal risk, comparing it to SIM farms / gray-market messaging.
• Some see adversarial interoperability as a positive and hope for legal precedent; others label the idea manipulative, antisocial, and something they “hope Apple kills quickly.”

Parenting norms, family size, and “safetyism”

• Many posters link overprotective parenting to lower fertility and high “investment” in a single child; losing or “messing up” that child feels existential.
• Others argue economics and competition (tutors, activities, housing) drive one-child families and intensive parenting, rather than the other way around.
• Several older commenters describe 70s–90s free-range childhoods and feel lucky; some tried to reproduce it for their kids, with mixed success due to changed norms and environments.
• Some see today’s risk-averse culture as excessive; others emphasize that parents are making hard tradeoffs against low‑probability but catastrophic harms.

Built environment, cars, and physical safety

• Large SUVs/pickups, higher hoods, and car-centric design are widely cited as major constraints on letting kids roam, even when parents aren’t worried about crime.
• Suburban sprawl, lack of sidewalks, street parking, and unsafe crossings make independent walking/biking impractical or dangerous in much of the US.
• Commenters contrast this with places like the Netherlands, Nordic countries, Spain, Japan, etc., where infrastructure and norms support kids walking, biking, and using transit alone.
• There’s disagreement about whether modern traffic is objectively safer; some stats show overall road deaths down, others point to rising pedestrian fatalities, especially in the US.

Community, social trust, and institutions

• Loss of stay‑at‑home parents, denser local kid populations, and everyday neighbor interaction is frequently cited. The “whole street watching the kids” has largely vanished.
• Some say diverse, anonymous cities and legal risk (CPS, police, liability) make neighbors less likely to intervene informally and more likely to call authorities.
• A few report police/CPS visits or threats when kids play outside unsupervised; others say fears of state intervention are exaggerated in their areas.

Media, crime perception, and cultural fear

• Many blame 24‑hour news, social media, parental group chats, and apps like Nextdoor for amplifying rare dangers (abductions, trafficking) and driving “safetyism.”
• Others push back that child abuse—especially by known adults—was under‑recognized in the past; today’s caution may be a reaction to learning its true prevalence.
• There’s debate whether lower child victimization rates are because the world is genuinely safer, or because we already constrained kids’ freedom.

Screens, alternatives, and children’s agency

• Some argue kids stay inside because indoor entertainment is now vastly more compelling, not only because parents forbid roaming.
• Others note that when safe, interesting third spaces and peer groups exist (dense cities, European towns), kids still choose to roam and form independent cultures.

Access, Cloudflare, and DDoS Protection

• Several commenters cannot access the local news article due to Cloudflare and/or geofencing; they criticize “one bouncer for the web” and lack of a way to contact site owners when blocked.
• Others note the block is likely site‑configured geofencing (e.g., Asia, Russia, Middle East) driven by spam/exploit traffic and regulatory exposure (e.g., GDPR), not Cloudflare itself.
• Debate over necessity of Cloudflare:
  • Pro side: small sites face real DDoS/bot pressure and get free or cheap protection; hosting alone may be insufficient; upstream providers can even bill for excess traffic.
  • Con side: DDoS is overstated for most sites; blocking continents or ISPs “kills the web” and excludes legitimate users, especially travelers and VPN users.
• Alternatives floated: rely on host‑level mitigation, accept occasional downtime, imagine IPFS‑like backup access, or serve ultra‑lean text/markdown endpoints for bots/LLMs (with skepticism about maintaining dual content paths).

Zoning, Permitting, and Who Can Build

• Discussion of how large projects proceed: zoning determines allowed use; deviations need variances and public hearings.
• Permitting (construction, environmental, utilities, stormwater) can take years and cost hundreds of thousands or millions before operations begin.
• This process often favors large firms that can carry unproductive land and pay for studies and lawyers, though local small firms may have more community trust.
• Common practice is land contracts contingent on permits, shifting risk from buyer to seller; hyperscalers typically use such structures.
• Several anecdotes describe stalled or failed projects (industrial yards, downtown redevelopments) and how regulatory complexity, discretionary approvals, and “regulatory capture” advantage incumbents.

Data Center Scale, Impacts, and Trade‑Offs

• 244 acres is seen as large but not unprecedented; modern “campus” builds can span many buildings, with individual data halls of 40–100 MW and extremely dense accelerator racks.
• Regions like AWS us‑east‑1 are described as many data centers spread over a wide area, not one giant facility.
• Environmental and local impacts are debated:
  • Concerns: noise, light, visual impact, water use (especially where water isn’t perceived as “infinite”), massive power demand, grid upgrades potentially raising rates, and few long‑term jobs.
  • Counterpoints: compared to heavy industry, data centers are relatively clean; construction generates large numbers of trade jobs; property and equipment taxes can be huge and long‑lasting; some argue new large loads can lower marginal power prices and fund transmission upgrades.
  • Water‑use criticism is called a “meme” by some; others stress resource limits and grid strain.

NIMBY, Local Benefits, and Fairness

• Strong skepticism after prior local megaproject failures (e.g., Foxconn nearby) feeds opposition to another massive build.
• Some see affluent communities using environmental‑justice language to block infrastructure they nonetheless benefit from, pushing burdens onto poorer neighbors.
• Residents near proposed sites argue they bear costs (noise, aesthetics, property value risk, utility impacts) with little upside.
• Suggested ways to make data centers more welcome:
  • Provide public goods such as multi‑gigabit fiber for locals, subsidized compute, partnerships with local colleges, and broader community investments.
  • Design sites with serious ecological planning (large preserved natural areas, not just minimum stormwater ponds).
• Others note that if U.S. communities resist, hyperscalers will shift growth toward regions (MENA, South Asia, SEA) where governments offer aggressive incentives, raising separate concerns about local consent and governance.

Microsoft, AI, and Strategic Context

• Some view Microsoft’s withdrawal as a rational response to community pushback; others tie it to the company’s aggressive AI build‑out and need for massive infrastructure.
• Brief debate about Microsoft’s AI strategy and leadership:
  • Claims that the company is “all in” on Copilot/AI and risks leadership changes if it fails.
  • Counterpoints note past stock performance under current leadership but also recent share‑price volatility and competition.

Kagi as a paid alternative

• Many comments praise Kagi as the closest thing to “old Google”: relevant results, strong advanced search, no ads, and minimal, opt‑in AI.
• Users highlight customization (domain boosting/ban lists, keyboard navigation, stats) and good multilingual support, though a few say it’s strongest in English.
• Weak spots: local/business search and maps, shopping results, and a comparatively small user base. Some worry small scale could harm anonymity or long‑term sustainability.
• Skepticism includes: needing an account, subscription cost, reliance on multiple external indexes (Google/Bing/Yandex/etc.), and concerns over using Yandex data given Russia’s war in Ukraine.
• Some suspect astroturfing due to how often it’s recommended; others insist the praise is organic.

Other search engines and meta‑search

• DuckDuckGo, Brave Search, Startpage, Ecosia, Mojeek, Qwant, Yandex, Exa, Searxng, etools.ch and smaller engines (Uruky, seek.ninja, etc.) are all mentioned.
• DDG is seen as “good enough” by many, especially with settings like ad‑off and no‑AI variants, but others find it mediocre, weak in non‑English, or lacking fresh Reddit content.
• Brave Search is liked for its own index, “goggles” to filter out junk (e.g., Pinterest), and a Google‑2008 feel. Some distrust Brave’s brand or past ad experiments.
• Meta‑searches like Searxng and etools.ch are valued for blending multiple engines, including niche ones like Marginalia.

AI overviews, LLMs, and search

• Strong split: some love Google’s AI Overview/Gemini as a fast answer layer that bypasses ad‑bloated pages; others find it frequently wrong, dangerously authoritative, or hard to audit.
• Broader worry: AI summaries siphon traffic and revenue from original sites, threatening the incentive to publish new content and degrading future training data.
• Many already use ChatGPT, Claude, Perplexity, Mistral, or Gemini directly as their “search,” especially for complex queries; others say LLMs still miss key libraries, docs, or popular tools.
• Some see AI‑first search as inevitable; others view it as enshittification and prefer pure “ten blue links.”

Google’s decline and workarounds

• Widely shared view that Google’s core search quality has deteriorated over the past decade due to SEO spam, ad load, personalization, and query rewriting.
• People use tricks like &udm=14, -ai, or custom extensions to get “web”‑only, no‑AI Google, but fear these parameters may eventually be removed.

Alternative paradigms

• Interest in self‑hosted and decentralized approaches like Hister (personal full‑text index from browsing history) and ideas for shared or P2P indexes and “search stubs” to reduce dependence on big centralized engines.

Craft, Community, and Loss

• Many agree the author is expressing grief over losing a beloved craft and sense of community (pairing, labs, meetups), not just complaining about tools.
• Some argue this nostalgia is real and valid; others see it as an existential crisis or sunk-cost issue that ignores that tools have always changed crafts.
• Several note that even before LLMs, industrial practices, Jira, remote work, and career progression already eroded the “joyful, communal” phase of programming.

AI as Tool vs Threat to Learning

• One camp treats LLMs as “Iron Man suits”: accelerators for typing, boilerplate, search, refactoring, tests, and small maintenance, while humans still design and reason.
• Another camp fears “outsourcing thinking,” deskilling, and a drug‑like dependence where people stop doing things they once could do, leading to “cognitive surrender.”
• Some solo or geographically isolated devs say AI is the first “collaborator/mentor” they’ve ever had and is empowering rather than dehumanizing.

Code Quality, Maintenance, and “Slop”

• Critics say stochastic code generation lowers the floor: it enables cheap, disposable, low‑quality software and encourages “vibecoding” without understanding.
• Others report the opposite in their own projects: more tests, better CI, more refactoring, and AI code review catching subtle bugs.
• Several stress that quality depends on how tools are used: careful review vs. blindly accepting agent output. The long‑term effect on the median codebase is seen as unclear.

Jobs, Inequality, and Historical Analogies

• Repeated comparisons to machinists→CNC operators, artisans→mass production, and furniture makers→IKEA: AI may make “hand‑crafted” software a niche craft.
• Disagreement over whether this is “just another automation” (manual labor analogy) or fundamentally different because it targets cognition and learning.
• Some warn of job devaluation and token‑usage metrics; others argue skills in specification, review, and system design will remain central.

Human Intelligence, Distraction, and Meaning

• Several worry AI plus existing media tech accelerate distraction, lazy thinking, and societal “dumbing down,” even if aggregate knowledge and GDP rise.
• Others argue human heedlessness predates AI; these tools mostly expose and scale existing tendencies.
• Multiple comments stress that people derive meaning from work; large‑scale removal of meaningful craft and autonomy is seen as socially dangerous.

Workplace Pressures and Power Concentration

• Reports of management demanding maximum AI usage, PR throughput, and token metrics create a zero‑sum, fear‑driven environment.
• Concerns that proprietary AI centralizes power and rents, unlike tools like git or Postgres; calls for open models and skepticism about further corporate control.
• A minority is enthusiastic about entrepreneurial upside and personal experimentation; another group prefers to “opt out” or stick to non‑AI workflows.

Overall reception of the encyclical

• Many (including atheists and agnostics) praise it as unusually sane, humane, and intellectually serious compared to typical “tech thought leadership”.
• Writing is described as dense, high “wisdom-per-sentence,” well argued, and rooted in long historical memory (e.g., connections to earlier encyclicals like Rerum Novarum).
• Some skimmed or used summaries first but concluded it’s worth reading in full; others found it too long or too theological to engage deeply.

Technology, AI, and concentration of power

• Strong agreement that AI and digital platforms amplify existing power imbalances, especially in favor of large private actors and billionaires.
• Commenters connect the encyclical’s warnings to real-world examples: AI data centers opposed by local communities, political capture, regulatory theater, and “AI as the new colonialism” via data extraction.
• The “disarm AI” framing (freeing it from military/economic arms-race logic) resonates, but some think it’s unrealistic under current capitalism and geopolitics.

Common good, property, and data

• The claim that patents, algorithms, platforms, infrastructure, and data should be treated as goods with a “universal destination” is seen as striking.
• Several see this as indirect support for open access / free software ideals; others read it as an argument for taxing and regulating tech/IP more heavily.
• Tension noted between this stance and strong private IP regimes and corporate walled gardens.

Human limitation, virtue, and meaning

• The defense of human finitude and limits against transhumanism/posthumanism is widely appreciated.
• Users link the text to Jewish, Muslim, and other religious sayings about incomplete work, small faithful acts, and long-term responsibility.
• Some contrast this with Silicon Valley “cult of progress” and techno-immortality fantasies.

Religion, hypocrisy, and authority

• Positive: recognition of the Church’s long intellectual tradition, social teaching, and willingness to critique capitalism, war, and tech power.
• Critical: recurring charges of hypocrisy on women’s ordination, abuse scandals, past support for slavery/colonialism, and doctrinal stances on sexuality and abortion.
• Debate over whether encyclicals can be morally useful despite institutional sins and whether faith biases the analysis of AI and personhood.

DEI, politics, and capitalism

• Long subthread on DEI: some see pro-DEI language in the encyclical; others argue DEI has become discriminatory or is being demonized by bigots.
• Broader frustration that both “progressives” and “conservatives” often seek top-down power rather than local, relational action the encyclical emphasizes.
• Multiple commenters argue most AI harms stem from late-stage capitalism and profit-maximization, not “AI itself”.

AI practice, open models, and responsibility

• Support for open(-weight) models and shared infrastructure as a way to avoid extreme concentration of AI power; concern this still allows misuse.
• Disagreement on where responsibility lies: some place it on builders/engineers, others on executives, funders, or governments; several insist it must be “all of the above”.
• Comparisons to nuclear tech, CFCs, and previous industrial revolutions; skepticism that humanity has ever truly “tamed” a powerful tech purely for the common good.