Hacker News, Distilled

TV “Garbage” Settings and How People Work Around Them

• Many commenters assume the creator is mainly talking about motion smoothing / “soap opera effect,” vivid mode, and similar post‑processing.
• Common advice:
  • Use Filmmaker Mode (the standardized, logo’d one) if available; it disables most processing and aims at reference-like output.
  • Use Game Mode to cut input lag and often disable many “enhancements,” though color/contrast may still be off.
  • Turn off motion smoothing, “dynamic contrast,” “AI enhancement,” “super resolution,” and showroom-style “vivid” modes.
• Some note quirks: Filmmaker Mode doesn’t always apply to all inputs (e.g., Chromecast), and on certain brands Game Mode or Filmmaker Mode still need manual tweaking.

Creator Intent vs “My TV, My Settings”

• One camp strongly values creative intent: heavy grading and motion decisions are part of the art, and TV gimmicks “ruin” carefully mastered work.
• Another camp sees creator advice as pretentious: if viewers need more brightness, contrast, or different sound to see/hear comfortably or for accessibility, they’ll change settings and don’t feel bound by the director’s vision.
• Some propose a reasonable compromise: TVs should default to a clean, accurate mode, but users can opt into enhancements.

Dark Images, HDR, Compression, and Audio Problems

• Frequent complaints that modern streaming shows (including Netflix) are:
  • Too dark to see in normal living rooms, especially with HDR and OLED auto-dimming.
  • Over‑compressed, with high resolution but visible artifacts, especially in dark scenes.
• Audio is another major pain point:
  • Dialogue often buried under music/effects; many rely on subtitles.
  • Blame shared among bad downmixing from 5.1/Atmos to stereo, tiny flat‑panel speakers, “cinematic” mixing geared for theaters, and aggressive dynamic range.
  • Some use soundbars, center‑channel boosts, “dialogue enhancement,” or night modes; others note old movies/YouTube rarely have this issue.

Frame Rate and the Soap Opera Effect

• Strong split:
  • Many hate motion interpolation, find it uncanny, “stagey,” and destructive to cinematic look.
  • Others prioritize smoothness, arguing 24 fps is an archaic compromise; they accept interpolation artifacts to reduce judder, especially on OLEDs, and want native high‑FPS movies.
• Several note that 24 fps plus proper motion blur looks fine in a cinema but interacts badly with modern 60/120 Hz displays and instant-response panels.

Stranger Things and Content Quality

• Multiple commenters say TV settings can’t fix perceived weak writing and plotting in later Stranger Things seasons, with season 5 in particular described as shallow, overextended, or inconsistent.
• Others defend recent seasons as not nearly as bad as, for example, late Game of Thrones, though many agree quality has dipped since season 1–2.

Blogging / Newsletter Platforms and Substack Debate

• Several commenters dispute the claim that Substack has “no alternatives,” listing Ghost, Hyvor Blogs, Beehiiv, boosty.to, Keila, and others, plus classic options like WordPress and “BCC in an email client.”
• People note few non‑US platforms match Substack’s combined bundle: blog + newsletter + social network + monetization + recommendation engine.
• Criticism of Substack centers on dark patterns, VC incentives, weak moderation, and “free speech absolutism” enabling Nazi/extremist content. Others argue some hate speech is a necessary cost of broad free speech, while opponents counter that private platforms have no obligation to host Nazis.

Cost, Budgets, and Self‑Hosting

• One thread explores running on ~€10–20/month by mixing free Proton, Backblaze, and a cheap mini‑PC; pushback says €10 is unrealistic once domains, backup, VPN, and hosting are counted.
• Strong advice against self‑hosting email due to deliverability, IP reputation, and maintenance, though some insist it’s manageable with correct DNS (SPF/DKIM/DMARC) and a “clean” IP.

Email and Productivity Providers (Proton, Google, Microsoft, Others)

• Many comments compare Proton, Zoho, Google Workspace, Infomaniak, Posteo, and local EU providers.
• Google Workspace is seen as highly polished and great value (2 TB storage, admin tools, Gemini), but people worry about privacy, AI training on personal data, lock‑in, and arbitrary account bans.
• Infomaniak receives repeated praise as a Swiss/EU‑friendly alternative, though its docs suite is criticized as ugly/clunky.
• Some report positive migrations from Microsoft 365 to Proton, calling M365’s admin UX fragmented and confusing. Others argue Microsoft’s products are increasingly unreliable and over‑AI‑ified.

Proton’s Strengths and Limitations

• Proton is valued for privacy, EU‑like legal protections (Swiss), bundling mail, VPN, storage, password manager, and AI at a competitive price.
• Major criticism: weak or absent server‑side full‑text search in Mail and Drive due to end‑to‑end encryption. Workarounds (local indexing, Proton Bridge + Thunderbird) are seen as too technical or slow for many users.
• Some claim Proton’s E2EE is over‑marketed “snake oil” for most users, since email is frequently decrypted at the recipient’s provider anyway. Others see the reduced search as an acceptable trade‑off for genuine E2EE.

EU, Switzerland, and Surveillance / Free Speech

• Debate over whether moving to EU/European‑adjacent providers truly improves “privacy and data sovereignty.”
• Critics highlight EU “chat control” proposals and hate‑speech laws as threats to expression; supporters reply these are proposals or long‑standing criminal norms, distinct from US‑style commercial surveillance and mass data mining.
• Some stress Switzerland is not in the EU; for a few, that’s a feature (GDPR‑like protections without EU‑level surveillance proposals).

Ecosystems and Lock‑In (Google, Apple, Proton, Local‑First)

• Some are deeply embedded in the Google or Apple ecosystems and find it practically hard to leave due to integration, polish, and family/work expectations.
• Others refuse to trade privacy for convenience and prefer owning domains, using standards (IMAP, CalDAV/CardDAV/WebDAV), and self‑hosting parts (Nextcloud/Baïkal, Syncthing, KeePassXC).
• Commenters warn that moving from Google to Proton is still entering another ecosystem; the long‑term safeguard is owning your domain and keeping independent backups.

How the tool works & intended use cases

• Skill connects Claude Code to an external MCP server that stores past conversations in a small DB (key/value + embeddings), organized by namespaces and “hypergraph” relationships.
• On each request it:
  • Embeds the current query.
  • Runs semantic + time-weighted search over prior sessions.
  • Returns only the top-N relevant snippets into the prompt as additional context.
• Used mainly to:
  • Resume long research/coding sessions across days.
  • Ask “what was I trying to do here?”, “what research threads already exist?”, “where did reasoning drift?”.
  • Let Claude reflect on and critique its own past reasoning.

Comparison to Claude’s built‑ins (CLAUDE.md, agents, skills, compaction)

• Several commenters say a good CLAUDE.md, AGENTS.md, per-project docs, and checkpoints/restore are enough; they see this as duplicating what agents + skills already solve.
• Others report:
  • Compaction making the model feel “dumber” and losing important edge cases.
  • CLAUDE.md often being ignored or only weakly applied.
• One thread explains a hierarchy:
  • CLAUDE.md → broad global/project instructions.
  • Agents → narrower, language/domain-specific instructions.
  • Skills → single-purpose instructions + deterministic tools (ripgrep, dependency graph analyzers, image generators), to keep context tight.

Privacy, hosting, and vendor lock‑in

• Multiple commenters say sending proprietary or sensitive code to a third‑party alpha service is a non‑starter; they want purely local or self‑hosted storage.
• Concerns include compliance, data leakage, vendor disappearance/price hikes, and negotiating agreements for “every small AI tool”.
• Some argue that even if useful, such features will eventually be best implemented by the model vendors themselves.

Alternatives and lightweight strategies

• Many describe simpler approaches:
  • Repo- or user-level CLAUDE.md and AGENTS.md.
  • Markdown “plans”, tickets, implementation logs, and work summaries committed to git.
  • Session JSONL parsing and local search (ripgrep, Tantivy, jq, custom CLIs).
  • Other memory tools: beads, claude-mem, Double, rg_history, memory-lane, custom MCP memory servers.
• Some find using less context, frequent fresh sessions, and strong planning/linting/tests more effective than elaborate memory layers.

Skepticism about memory abstractions & impact

• Repeated sentiment: there are already “countless” memory/context tools; few show benchmarks or clear productivity gains over simple docs.
• Doubts that external memory can reliably handle:
  • Drift, stale state, or subtle errors accumulating over time.
  • Multi-agent coordination without adding new failure modes.
• The project’s authors emphasize their focus on portability and shared state across tools/agents rather than “infinite context,” but some commenters remain unconvinced that semantic/temporal search alone solves the coordination problems they describe.

UBI and social safety nets

• Several commenters argue there is no realistic funding model for large-scale UBI from AI profits; small “petrostate-style” stipends don’t scale.
• Others counter that pilots and data show UBI works at small scale; the unsolved part is financing it nationally, not its individual effects.
• Some see UBI as politically doomed (resentment at “giving rich people money” and bureaucratic complexity); others say means-testing is costlier, crueller, and often used to sabotage welfare.

Tax base in an AI-heavy economy

• Core concern: payroll and income taxes shrink if humans are replaced by AI “employees,” undermining current funding for states and social insurance.
• Some say the solution is trivial: tax where value flows now—corporate income, data centers’ energy use, revenue from AI services.
• Others doubt governments’ capacity to adapt quickly or fairly, warning of convoluted systems like the existing US tax code.

Alternative tax designs

• Proposals include:
  • Progressive “earnings per employee” taxes (criticized as anti‑innovation and wage‑suppressing).
  • Land value tax and severance taxes on natural resources, described as “AI‑proof.”
  • Consumption/sales taxes, with debate over regressivity versus practicality.
  • Tiny taxes on all financial transactions or HFT‑style short-term gains, shifting burden from labor to capital.
• Disagreement over whether focusing tax collection on top earners and corporations is numerically feasible or economically destabilizing.

Capitalism, power, and “techno‑feudalism”

• One line of discussion claims we’re drifting from productive capitalism to “techno‑feudalism,” where a few owners rent AI and infrastructure to everyone else.
• Others push back, saying most firms still add value atop complex supplier networks; the real problem is monopoly and lax antitrust, not capitalism per se.
• Some foresee eventual communism or mass nationalization/taxation of AI firms as the only way to avoid collapse in demand and tax revenue.

Jobs, displacement, and productivity

• Sharp split:
  • One side says “AI will take all our jobs” is overblown; like tractors and past automation, AI will reallocate labor and create new, higher‑value work.
  • Others report concrete layoffs tied to AI tools and fear a downward spiral: fewer jobs → less consumption → business failures → fiscal crisis.
• Historical analogies (tractors, cars, past sectoral shifts) are used both to calm fears and to note that past productivity gains didn’t deliver the leisure Keynes predicted; instead, gains went largely to owners.

AI as “employee” vs tool

• Critics argue “AI employee” is a misleading metaphor; AI is capital equipment, not a taxpayer or person, and the key issue is tax structure, not anthropomorphizing.
• Some see AI mainly as a force multiplier: better tools mean more software, more automation work, and higher ambition, not less human employment overall.

Governance, inequality, and corporate power

• Commenters worry more about political capture and weak enforcement than about AI itself: corporations already avoid taxes, buy competitors, and shape laws.
• There is frustration that corporate directors rarely face personal consequences for aggressive tax schemes or fraud.
• Some note that without strong regulation and redistribution, an AI‑driven economy could concentrate wealth while leaving masses unemployed or purposeless.

Critiques of the article and discourse

• Multiple readers see the article as internally inconsistent (e.g., citing poor AI output while asking “what are humans for?”).
• Several suspect or detect LLM‑generated writing and are dismayed that even opinion pieces about AI are machine‑mediated.

Reaction to the announcement & copywriting

• Many readers mocked the second-line phrase “this announcement is more than just a headline” as hollow, LLM-ish marketing speak.
• Others argued it’s just standard corporate PR language that predates LLMs, and that using AI to write an AI company’s blog post is unsurprising.
• Some think the obvious “this is not just X, it’s Y” structure is deliberate watermarking or engagement bait; others see it simply as LinkedIn-style hype.

Perceived quality of Manus’ product

• Supporters say Manus was the best general “agent” for turning text into concrete work: slides, code, structured research, browser automation, and virtual machines, often earlier and smoother than US competitors.
• Critics found it slow, overpriced, and not meaningfully better than ChatGPT/Claude “agent modes,” calling it mostly a wrapper on public models plus good formatting.
• Several users report genuine productivity gains, especially for research and PPT creation, and are disappointed Meta may change or sideline it.

Why Meta bought it & valuation debate

• One view: Meta was lagging in consumer-facing agents; Manus brings a polished product, millions of paying users, and talent, fitting a strategy where models commoditize and UX/distribution matter most.
• Another: this is classic hype/bubble behavior—an acquihire or “friends giving friends a piece of the pie,” possibly fueled by investor relationships rather than exceptional tech.
• Undisclosed price fuels speculation: guesses range from hundreds of millions to multiple billions, with some comparing it to WhatsApp (user acquisition) and others calling such sums absurd or akin to money laundering.

Meta’s reputation and social harm concerns

• Several commenters distrust Meta, citing social media’s documented harms (addiction, mental health, outrage incentives) and Meta’s history of prioritizing growth.
• This makes them uneasy about Meta positioning itself as steward of the “next tech wave” and about Manus user data and product direction post-acquisition.
• Many expect Meta to either neglect or “ruin” the product, based on past acquisitions (Oculus, Instagram, WhatsApp, metaverse efforts).

China/Singapore origins & marketing

• Discussion notes Manus’ roots in China and relocation to Singapore; some call it marketing-heavy and overhyped, others defend its technical merit and prior successful products.
• Even among Chinese founders in the thread, views are split between seeing Manus as mostly PR and seeing it as legitimately strong execution plus aggressive promotion.

AdWords Decline for Small Businesses

• Central anecdote: a small local entertainment business that depended on Google Ads for a decade now sees sharply falling leads despite similar or higher spend.
• Others with small businesses report the same: cost per click up, conversions and lead quality down, to the point where campaigns no longer break even.
• Some suggest more prosaic explanations: new competitors, poor campaign setup, search partner issues, or click fraud (including advice on log analysis and bot detection).

Is Google or Just Google Ads “Dead”?

• Several point out the article is really about the search ads product, not the company or search as a whole.
• Counter-evidence is cited: steadily rising Google ad revenue and search volumes; many larger advertisers still profitably spending seven figures monthly.
• A common reconciliation: the “K‑shaped” ad economy—big, sophisticated or high-margin advertisers still do well; smaller, unsophisticated ones get priced out.

Shifts in Discovery: AI, Social, and Private Channels

• Multiple commenters say they and their peers now use LLMs (ChatGPT, Gemini, etc.) for a large share of “search-like” tasks, especially comparisons and product research.
• Others see most practical discovery moving to TikTok, Instagram, YouTube, or private groups (WhatsApp, Discord, iMessage), with traditional web search used less.
• This weakens both SEO and PPC as predictable acquisition tools, especially for local or niche services.

Future of Ads in an AI World

• Strong expectation that AI assistants will become the next ad surface: sponsored products blended into recommendations, pay-to-be-in-the-training-corpus, or prompt-targeted placements.
• Some are optimistic this could be resisted (self-hosted models, ad blockers, regulation); most expect enshittification similar to search and social.

Impact on the Open Web and Search Ecosystem

• Debate over what “killed” the open web: social media dominance, Google’s ad-driven design, or now AI summaries that reduce clicks and weaken publisher incentives.
• Alternative search engines like Kagi are discussed: admired, but questioned on whether they can sustain their own index if the open web continues to shrink or wall itself off.

Alternative Marketing Approaches

• Suggested channels: Meta (Facebook/Instagram) ads, YouTube pre-roll, Reddit (with caveats), local SEO/Maps, physical flyers and QR codes, direct relationships with planners and influencers, content and FAQ pages optimized for LLMs.
• Some argue that in saturated, automated ad markets, many small businesses must fall back to word-of-mouth, repeat customers, and highly local tactics rather than mass platforms.

Handling Negative Feedback

• Many commenters endorse the article’s core advice: don’t take criticism personally, listen, and look for the actionable part of the complaint.
• A recurring theme: “feedback is a gift.” Complaints signal that people see potential and are frustrated the product isn’t delivering. Indifference is worse than hate.
• Several argue that the correct public response to harsh reviews is almost always some form of apology, acknowledgment, and offer to help; arguing back looks unprofessional and scares off other customers.
• One tactic highlighted: extract the invariant (“workflow is brittle,” “pricing feels dishonest”) from the theatrics, address only that, and possibly ask a specific follow-up.

Haters, Users, and Signal vs Noise

• Stories: angry users often become valuable contributors and advocates if they feel heard, but there are also “pathological” haters who cannot be satisfied and should be disengaged from.
• Suggestions to distinguish:
  • Frustrated user (fixable issues)
  • Casual troll (for laughs)
  • Malicious hater (bad-faith, community-poisoning)
• Warnings that optimizing for loud complainers can harm the broader user base; haters are rarely representative.
• Some see “squeaky wheel gets the grease” as a bad incentive structure that trains people to scream.

The CodeRabbit Incident and Apology

• Many view the CEO’s original defensive response and subsequent “apology” as poor examples of leadership: framed as protecting the team, reasserting user numbers, and subtly blaming the critic.
• Others note the critic’s tone was dickish but still argue the power imbalance means the company must hold itself to a higher standard.
• Several readers say this episode alone is enough to avoid the product, and compare it to monopolistic products widely hated yet entrenched.

Broader Reflections

• Negative feedback can fuel innovation if you use frustration as a diagnostic, not a personal attack.
• Public replies should be written for the observing audience, not to “win” against the critic.
• Discussion touches on generational shifts away from “customer is always right,” the burden of mandatory workplace tools, and discomfort with calling people “users” instead of “customers” or “people.”

AI Anthropomorphism Tangent

• Some push back on phrases like “Claude gets it,” insisting LLMs don’t “understand” or “think” and that anthropomorphizing them is misleading.
• Others counter that we lack clear definitions of “thinking” and cannot easily prove or disprove machine understanding.

Licensing and main causes of delisting

• Many examples (Blur, racing sims, Warhammer titles, Transformers, Prey 2006) highlight expiring licenses for cars, music, brands, or IP as the dominant reason for removal.
• Other recurring causes mentioned: server shutdowns for online/live-service games, breakdowns between devs and publishers, and studios folding.
• Some cases involve TOS/content violations, especially NSFW titles and payment-processor pressure.

Impact on owners and access

• Delisted generally means: no new purchases, but existing owners can still download and play via Steam, often indefinitely.
• Users report successfully reinstalling long-delisted titles (e.g., Blur, Transformers, old 3DS eShop games).
• Steam updates can silently remove licensed music from all copies; downgrading officially isn’t supported, though tools/“beta” branches sometimes allow older builds.

Preservation, piracy, and “gaming history”

• Several commenters see delisted but fully functional games (Blur, older Forza, GTA with full soundtracks) as evidence that licensing hurts consumers.
• Some argue piracy becomes morally acceptable or even a “moral imperative” for preservation when rights-holders refuse to sell historically significant games.
• Concern that non-transferable, expiring licenses will erase large chunks of gaming history long before copyright expiry.

Remasters, replacements, and altered versions

• Common pattern: original games delisted when “Definitive,” “Redux,” or remastered editions launch (Death Stranding, Metro, Mafia III, Lumines, GTA).
• Debate over whether this is acceptable: fine if the new edition is strictly better, problematic when content (especially music) is removed or gameplay changes.

IP control and fan communities

• Warhammer/Game Workshop is cited as an example of a beloved universe with a widely disliked rights-holder (fan C&Ds, tight creator-network rules).
• Devotion and other politically sensitive or licensed-content cases show how external pressure and IP control can abruptly erase games.

Platforms, data, and definitions

• Clarification that this site isn’t comprehensive; all lists rely on scraping. Some titles were too small or short-lived to be captured.
• Distinctions between “delisted,” “purchase disabled,” and “unlisted” are noted; tools like Steam-tracker provide broader coverage.

What’s actually hard about software development

• Many agree: the hardest part is turning vague, contradictory human requirements into precise, testable specifications and architectures, not writing syntax.
• Others argue the truly hard part is understanding and evolving large existing codebases and capturing the “why” behind decisions—something code alone (and LLMs) don’t encode well.
• Several note that LLMs help with “what” and “how” but still struggle with “should we do this at all?” and “is this the right abstraction?”

Current capabilities of LLMs for coding

• Positive reports:
  • Strong at boilerplate, CRUD apps, UI ports, glue code, small utilities, and reading/annotating unfamiliar code.
  • Some claim large productivity gains (up to “one person doing work of many” on well-structured, testable tasks).
• Negative reports:
  • Frequent hallucinations, outdated APIs, fragile project plans, and architectural nonsense for novel or intricate domains (fintech, low-level, cryptography, complex simulations).
  • “Vibe-coded” projects often become unmaintainable and require large cleanups.
• Widely observed: they behave like tireless but inconsistent junior developers—sometimes brilliant, sometimes bafflingly wrong.

Trust, safety, and agentic systems

• Concerns parallel self-driving cars: tools work impressively until they fail in ways users can’t predict or quickly recover from.
• Some treat LLMs as another “Swiss cheese” safety layer (linting, test generation, review), not a replacement for human judgment.
• Advocates of modern agentic setups (tool use, compiling, tests, web search) say these sharply reduce hallucinations for many coding tasks; skeptics say variance is still too high for critical systems.

Jobs, skills, and industry structure

• Strong anxiety from some devs, especially newer ones, about being replaced or down-skilled to “AI conductor.”
• Others emphasize that requirements discovery, system design, trade-offs, risk ownership, and talking to stakeholders remain human bottlenecks.
• Expectation that low-skill / repetitive coding and some offshore work are at greatest risk; higher-level problem solving may grow in value.
• Worries that juniors raised on LLMs will never develop deep debugging and design skills, leading to brittle systems.

Long‑term outlook and analogies

• Historical parallels cited: 4GLs, VB/Delphi, low-code, open source, industrial looms, cars vs horses, and crypto.
  • In each case, productivity jumped, more software/things were built, and specialists remained, but many lower-skill roles vanished.
• Debate over whether this wave is “just another tool” or a genuinely different inflection; the thread remains deeply split.

Perception of the article and AI marketing

• Many see the post as thinly veiled marketing for an AI startup (product link high on page, “minutes to production” slogan).
• Some dismiss it outright due to polished branding and startup tone; others say the content matches their own experience and is genuinely useful.
• Concern that non-experts (especially managers) will treat it as authoritative guidance and turn it into rigid policy.

AI adoption: solo vs teams

• Commenters argue agents are far easier for solo devs than teams due to:
  • Diverse working styles and differing trust/enjoyment of agents.
  • Risk of a single “AI power user” overwhelming team capacity with sweeping changes.
• Fast, ephemeral, per-branch dev environments are widely praised, both for agents and humans.

Testing, 100% coverage, and Goodhart’s Law

• Strong disagreement over 100% coverage:
  • Critics call it bad advice for most projects; point to unreachable code, edge conditions, and industries (e.g. brakes) that do fine below 100%.
  • Supporters say line/branch coverage is a minimum bar for agents; tests are cheap when AI writes them.
• Multiple people warn about Goodhart’s Law: if AI is judged on “lines covered,” it will generate meaningless tests (“1 == 1”) to satisfy metrics.
• Some recommend focusing on branch or MC/DC-style coverage, property-based testing, and testing error paths rather than raw percentage.

Guardrails vs “good code”

• Many note the article describes guardrails (types, tests, linting, environments), not inherently “good” design or architecture.
• Risk: 100% syntactically clean, well-tested code that is still structurally bad or unmaintainable.
• Several say humans should define type signatures, specs, and invariants; AI should fill in implementations and tests.

Capabilities and limits of LLMs

• Positive experiences: AI accelerates boring code, test writing, refactors; pushes teams to improve DX, documentation, and naming so agents work better.
• Negative experiences: agents generate slop, junior-level abstractions, and “tautological” tests; require heavy review that many devs won’t actually do.
• Debate over LLMs as teaching tools: some use them for self-learning; others warn about confidently wrong explanations and shallow understanding.

Formal methods and spec-first workflows

• A few describe promising workflows: write high-level specs (e.g. TLA+/PlusCal) or PRDs, then have AI implement code strictly to the spec.
• Formal verification and property-based testing with AI assistance are seen as emerging but still immature.

Project concept & intent

• Proposed distro: Linux kernel underneath, but the entire desktop environment is Win32 apps running under Wine.
• Goal is to recreate the late‑90s–early‑2010s Windows desktop (Win2k/XP/7 era) for power users while keeping Linux control and freedoms.
• Some commenters say they’d “unironically use this,” especially for a light, practical Win2000‑style desktop.

Feasibility vs existing efforts (Wine, Proton, ReactOS)

• Skeptics argue that true Win32 compatibility requires reproducing Windows behaviorally, including bugs and mitigation quirks; Wine’s 30‑year history and remaining incompatibilities are cited as evidence this is very hard.
• Others reply that Wine/Proton already show very high practical compatibility, especially for games, and in some cases run old Windows software better than modern Windows.
• Some see this as “embrace, extend” against Microsoft; others say if you need perfect Win32, you might as well run Windows.

Motivations: control & dissatisfaction with modern Windows

• Strong desire for a Windows‑like workflow without Microsoft’s telemetry, ads, and UI regressions.
• Multiple comments praise NT as a good kernel but condemn Win32 and modern shell/UX decisions.
• Enterprise editions and LTSC are mentioned as less “enshittified,” but many report Windows 10/11 as slow, fragile, and bloated.

Linux ABI, packaging, and ecosystem problems

• Long subthread: Win32 framed as the only de‑facto stable desktop ABI across both Windows and Linux.
• Complaints: glibc symbol versioning, frequent breaks in GUI stacks (GTK 2→3→4, Qt 4→5→6, X11→Wayland), and distro fragmentation make distributing Linux desktop binaries painful.
• Some argue this “shifting sand” is the core reason Linux never wins the desktop, more than gaming or installer difficulty.
• Containers, Flatpak, AppImage, Snap are seen as band‑aids that ship mini‑distros with each app.

Gaming & apps

• Gamers are a key target: Proton makes most Windows titles playable, but this also removes incentive for native Linux ports.
• Examples given of older DirectX games that are easier to run on Linux+Proton than on Windows 10/11.

UI, toolkits, and nostalgia

• Strong nostalgia for Win2k/XP/7 UI; several wish for a polished pixel‑perfect clone as a Linux DE.
• Debate over building GUIs with VB6/Delphi‑style native widgets vs modern web/Electron stacks; many view web UIs as heavier and less ergonomic.

Prospects

• Enthusiasts love the spirit and would try a live image.
• Skeptics think it will remain a niche experiment: keeping Wine, drivers, audio, and modern GPUs working across fast‑moving Linux kernels is seen as a long, uphill fight.

Sources of Fun in Programming

• Commenters split between:
  • Enjoying the process and craft: thinking through problems, typing code, understanding systems end-to-end, tight feedback loops.
  • Enjoying the result: shipped products, solved business problems, weird side projects that would never get built otherwise.
• For the first group, LLMs feel like “babysitting a robotic intern” and rob them of the satisfying parts (debugging, careful design, manual refactors).
• For the second group, LLMs are “intellectual crack” that remove drudgery and make previously impossible or too-costly projects feasible.

LLMs vs Autocomplete and Traditional Tools

• Some argue LLMs are just “autocomplete++”: another step in a long trend (IDEs, refactor tools, higher-level languages).
• Others insist they’re qualitatively different:
  • Generative, non-deterministic, and prone to hallucination.
  • They choose approaches and architectures, not just syntax completions.
• This leads to a new relationship category: not a passive compiler, not a teammate, but a confident stranger whose output must be audited.

Productivity, Code Quality, and Architecture

• Pro‑LLM experiences:
  • Dramatic speedups for CRUD apps, webshops, Home Assistant setups, internal tools, ops scripts.
  • Offloading boilerplate, repetitive refactors, test writing, API glue, and “yak-shaving”.
• Skeptical experiences:
  • High cognitive load from reviewing verbose or incorrect code.
  • LLMs struggle with architecture and domain modeling; seniors say the bottleneck is rarely typing.
  • Worry that “stochastic programming” produces systems no one truly understands.

Workplace Pressure and Job Security

• Several describe being effectively forced to use LLMs by management or peer expectations.
• Anxiety that if humans only do the “interesting parts” now, future models will eventually do those too, turning many developers into replaceable “boilerplate”.
• Others counter that tool adoption has always been uneven, that LLM productivity gains are overstated in many domains, and that organizing around work/wealth issues matters more than rejecting tools.

Tool Neutrality, Ownership, and Culture

• Disagreement on whether LLMs are “just tools”:
  • Critics note they mediate thinking and creativity, centralize power in a few companies, and may be weaponized against workers.
  • Supporters see them as like screens or tractors: context-dependent, with both good and bad uses.
• There’s recognition of strong emotional polarization:
  • Pressure in some circles to loudly love AI; in others, “AI bad” earns easy approval.
  • This post is seen as a “scissor statement” that cleanly divides people by what they value in programming.

Nature of the Blocklist

• Only ~300 domains are listed; commenters note this is tiny relative to the universe of piracy sites.
• List is overwhelmingly illicit movie/series/football streaming and torrent-like sites (e.g., “kino” domains, sports streams, Anna’s Archive, Sci-Hub).
• Some see it as a “curated index” of high‑value piracy sites; others point out major private trackers are missing, so it’s far from complete.
• A few people say they’ll use the list as a blocklist at home, framing piracy as theft and “inhumane.”

How Blocks Are Implemented and Circumvented

• In Germany these are DNS-level blocks, affecting only users of ISP DNS; changing DNS, running your own resolver (Unbound/Bind), or using DoH/DoT, VPNs, or services like NextDNS/ControlD bypasses them.
• Some ISPs use transparent DNS proxies or advertise third‑party DNS (e.g., Google) by default; others don’t implement the CUII blocks at all.
• Discussion of stronger techniques:
  • UK and Spain examples of IP blackholing/Cloudflare cooperation, occasionally causing collateral damage to unrelated sites.
  • SNI-based blocking vs the rise of TLS 1.3 + ECH. Debate over whether middleboxes can downgrade or strip ECH; practical attacks today often target DoH responses or rely on corporate MITM, not breaking TLS itself.

CUII, Incentives, and Legality

• CUII is described as a private consortium of copyright holders and ISPs, not a state body.
• Participation is formally voluntary, but ISPs face pressure: either join and implement blocks, or handle large volumes of individual copyright claims.
• Some call this “dystopian” industry self‑censorship; others see it as a pragmatic way to reduce legal workload.

Piracy vs. Censorship

• Many commenters mock the effort as symbolic: anyone savvy enough to find these sites likely knows how to bypass DNS blocking.
• Others stress that even if limited, blocking lawful resources like Anna’s Archive and Sci‑Hub is harmful.
• Several highlight the Streisand effect: the public list helps users discover new piracy and streaming sources.

Broader Free-Speech and Political Context

• Thread digresses into German hate‑speech and insult laws, raids over online posts, and debates about “Volksverhetzung,” Nazi history, and party bans.
• Opinions split: some see Germany/EU as increasingly authoritarian; others argue restrictions are targeted, historically grounded, and still compatible with robust democracy.

Nature of the bug: uninitialized vs “true” UB

• Many commenters say this is fundamentally an “uninitialized variable / garbage value” bug, not the more exotic “nasal demons” kind of undefined behavior.
• Others point out that in standard C/C++, reading uninitialized data is UB, and that the “could be anything” outcome is a direct consequence of that.
• Several stress that even if the standard had defined “indeterminate but stable garbage,” the logical bug (assuming a default value) would still exist.

Default initialization and language design

• Strong support for “initialize everything explicitly,” especially for fundamental types.
• Several argue modern languages should (and mostly do) zero‑initialize by default, with an explicit “uninitialized” escape hatch for performance‑critical cases.
• Counterpoint: zero‑init as default can be wrong if all‑zero is not a valid value; some prefer languages that force explicit initialization or a Default/MaybeUninit-style mechanism (as in Rust).
• Some wish C++ had inverted defaults: everything initialized unless explicitly marked no_init / uninitialized.

C++26 and “erroneous behavior”

• One thread explains that C++26 will treat reading uninitialized variables as “erroneous behavior” rather than UB: compilers are encouraged to diagnose and may assign arbitrary but well‑specified “some value.”
• There is debate over whether this meaningfully restricts optimizations or just formalizes current practice; some find the distinction from UB unclear and possibly toothless.

Compiler optimizations under UB

• Multiple godbolt examples show surprising codegen:
  • Partially initialized structs being returned as if both branches executed.
  • Functions effectively deleting or skipping code after a UB point.
  • Values acting “paradoxically” (different effective values at different uses).
• Some defend this as legitimate: if you leave a value uninitialized, you said “any value is fine,” so the optimizer can pick whatever is convenient.
• Others argue this is “technically correct but practically harmful” and that compilers should treat such values as opaque, not fold them into constants.

Practical advice and structural issues

• Common recommendations:
  • Always give struct fields explicit defaults.
  • Use sanitizers / runtime checks (including stack poisoning options) to catch uninitialized reads.
  • Avoid patterns where structs flip between POD and non‑POD, which can silently change initialization rules.
• Some note the logical design is also flawed: two booleans success/error encode impossible combinations; a single status or richer enum / timestamp would be more robust.

4680 Batteries, Cybertruck, and Contract Write-Down

• Core fact: Tesla’s 4680 cathode supplier wrote down a $2.9B contract to ~$7,400, implying effectively zero expected volume.
• Many commenters see this as confirmation that the 4680 program has largely failed and that Cybertruck demand is far below Tesla’s stated capacity (tens of thousands sold vs ~250k/year capacity).
• Some argue it may simply reflect chemistry/supplier changes or vertical integration (Tesla making cathodes in-house, LFP pivot), not a “collapse,” but this is speculative and not backed by concrete production data in the thread.

Tesla’s Business Health and the EV Market

• One side: Tesla is “struggling” — declining sales in key markets (EU, China, US), weak margins, flat global EV growth in the US, and heavy competition from Chinese OEMs.
• Counterpoint: revenues near $100B, positive net income, strong liquidity, still among top global EV sellers; problems are margin compression and competition, not imminent insolvency.
• Several note that all BEV makers in the US are hurting; policy changes and lost subsidies are big factors. Outside the US, EV demand (especially cheap Chinese models) is strong.

Valuation, Meme Dynamics, and Shorting

• Many argue Tesla’s valuation is detached from fundamentals, driven by “cult of personality,” memes, and expectations of future miracles rather than cash flows.
• Frequent comparisons to a Ponzi scheme (in vibe, not legal mechanics): returns depend on ever new buyers; narrative constantly shifts (battery company → FSD/robotaxis → robots).
• Others push back: that’s speculation, not Ponzi; company has real products, revenue, and profits.
• Multiple comments stress that shorting is dangerous because markets can stay irrational longer than shorts can stay solvent.

Self-Driving / Robotaxi Thesis

• Bulls: stock is effectively a bet on Tesla cracking full self-driving; if they succeed, other automakers’ margins collapse and Tesla’s software revenue (e.g., subscriptions) could be huge.
• Skeptics: autonomy will be a commodity provided by many (Waymo, Mobileye, Chinese stacks, legacy OEM L3+ systems). No clear Tesla moat, especially with camera-only hardware.
• Past robotaxi/FSD timelines are cited as systematically wrong over nearly a decade; some label the pattern “corporate puffery” or worse.
• One long anecdote claims FSD v14 is a qualitative leap and extremely impressive in real use; others question survivorship bias and safety, or note that similar claims have been made for years.

Musk’s Credibility and “Cult” Dynamics

• Extensive discussion of Musk’s long history of missed or wildly delayed promises: $25k car, early Roadster, Cybertruck pricing/features, hyperloop, Mars timelines, robotaxis, Dojo, etc.
• Critics see a confidence game: hype moves stock, stock funds the next story, while timelines slip indefinitely. Supporters frame it as over-optimistic moonshot culture where some big things did ship (SpaceX, mass-market EVs).
• Political radicalization, public behavior, and association with far-right figures are widely seen as damaging the brand and sales, especially in Europe and among US moderates.

Competition: China, BYD, and Legacy OEMs

• Broad agreement that Chinese manufacturers (BYD, Geely and many others) now dominate low- and mid-priced EVs, with aggressive pricing and rapidly improving quality.
• Some predict traditional US and European automakers are structurally doomed by short-termism and reliance on high-margin ICE; others note they are finally ramping dedicated EV platforms and in-house batteries.
• Several claim Tesla squandered its lead by chasing Cybertruck/robotaxi instead of a true affordable mass EV, thereby ceding “car for the masses” territory to China.

Media, Electrek, and Bias

• Multiple comments criticize Electrek as increasingly anti-Tesla, framing everything in the worst light and leaning heavily on speculation.
• Others argue that what looks like “bias” is simply aligning with reality now that early hype has failed to materialize; their negative tone followed years of over-optimistic coverage.

Macro: Finance, Governance, and Policy

• Broader complaints that US capitalism rewards hype over fundamentals; index funds and mega-asset managers dampen real competition; and “new economy” giants practice self-dealing across affiliated companies (e.g., related entities buying unsold Cybertrucks).
• Debate over Chinese industrial subsidies vs Western short-termism: some see China’s long-term strategy and state support as rational industrial policy; others emphasize overcapacity and hidden costs.

Size and implications of Nvidia’s Intel stake

• Original September piece said ~4% post-issuance; commenters ask if that’s still accurate but no clear answer emerges.
• Some see it as a major symbolic shift: Intel’s key owners now include the U.S. government, Nvidia, and SoftBank (though others note large index-fund managers still hold more overall via funds).
• One concern raised: this may dampen Intel’s role as a meaningful AI competitor to Nvidia.

Could Nvidia just buy Intel? Antitrust and policy views

• Several argue a full acquisition would likely be blocked on global antitrust grounds, citing prior failure to buy ARM and the power of EU/UK regulators over global deals.
• Others think the current U.S. administration might tolerate it, especially to create a “US foundry behemoth.”
• There’s debate over how real foreign regulators’ power is in a de jure sense versus the huge de facto leverage they have through market access.

Intel’s technical position and “wizard” talent

• One thread stresses Intel’s problems are not primarily money but missing expertise: “wizards” in advanced manufacturing mostly sit at TSMC, with deep, tacit knowledge not externally published.
• Path to becoming such a “wizard” is described as long, specialized PhD work plus years under experts, often for modest pay and difficult hours.
• Some push back that Intel is closer to TSMC than portrayed: already doing high‑volume EUV since 2023–24 and advancing 18A.

Ownership structure, funds, and control

• Debate over whether large asset managers (BlackRock, Vanguard, State Street) should “count” as owners versus being proxies for millions of individuals.
• Clarifications: funds typically vote the shares (proxy voting guidelines), which raises governance concerns for some; others point out this is standard practice and not inherently conspiratorial.

Circular investments and risk to Nvidia

• Multiple comments worry about Nvidia investing in its own customers (OpenAI, Intel, others) while also selling them hardware, calling it a “tight circle” beyond normal money velocity.
• Critics argue this amplifies downside: if a customer fails, Nvidia loses both revenue and equity value.
• Others frame it as medium‑risk, high‑reward: a few breakout successes could more than offset failures—but there is no consensus.

Corporate ownership and limited liability (broader tangent)

• One subthread proposes banning companies from owning companies; only people would own companies.
• Lawyers and others push back:
  • Would complicate subsidiaries, cross‑border operations, joint ventures, and M&A.
  • Would force immediate “IPOs” of subsidiaries to individuals and reduce saleability/value of businesses.
  • Limited liability is defended as necessary for risk‑taking; critics counter that it mainly protects capital owners and socializes some risks.

Project goals & status

• Commenters ask what tinygrad has actually achieved in five years and what it can do now.
• Cited goals from its site: run standard ML benchmarks/papers 2× faster than PyTorch on a single NVIDIA GPU and perform well on Apple M1; ETA mentioned as next year.
• It already powers an automotive driver-assist stack and can run NVIDIA GPUs on Apple Silicon via external enclosures.
• Mission is framed as “commoditizing the petaflop” and enabling efficient LLM training on non‑NVIDIA hardware.

Potential impact & competition

• Some see tinygrad as a potential alternative backend to PyTorch/TensorFlow, especially for edge and non‑CUDA hardware.
• Others argue PyTorch could neutralize it by adding an AMD backend to its own compiler stack, leaving tinygrad’s main work (AMD codegen) as a feature PyTorch could adopt.
• tinygrad maintainers respond that they welcome being used as a backend and already provide PyTorch and ONNX frontends.

Code size, complexity, and style

• The low line count is polarizing: some see ~19k SLOC with zero dependencies as evidence of low incidental complexity; others complain it feels like code‑golf and is hard to read.
• A linked optimization file becomes a focal point: critics find it dense; defenders say GPU compilation is inherently complex and the code is readable, “2D”, and appropriate for a small, expert team.
• There’s debate over whether fewer lines actually imply simplicity; several note that autoformatters trade away information density for consistency.

Language & ecosystem comparisons

• Discussion branches into Mojo vs CPython, Julia’s suitability as a Python successor, 1‑based indexing, multiple dispatch, metaprogramming, and trust in Julia’s correctness.
• Some argue Mojo’s divergence from Python semantics weakens its pitch; others say Mojo’s aim is acceleration of Python‑like code on specialized hardware, not replacing CPython.

Organization, hiring & funding

• Hiring via paid bounties and contributions is praised as highly productive and more meaningful than LeetCode interviews, but also criticized as potentially underpaying skilled work.
• The company is small, mostly remote, with periodic meetups in Hong Kong and some physical offices.
• Funding comes from VC, AMD contracts, and a hardware division selling multi‑GPU boxes (~$2M/year revenue); commenters debate whether this can support a team of engineers.

“Elon process”, TRIZ, and attribution

• The blog’s reference to an “Elon process” (remove dumb requirements, “the best part is no part”) triggers pushback.
• Several note these ideas predate that figure (e.g., TRIZ, classic design aphorisms); some dislike marketing that centers a celebrity rather than original sources.
• There’s broader meta‑discussion about separating technical achievements from controversial public personas, and about not derailing threads into personality politics.

NVIDIA, AMD & market dynamics

• Many see real value in helping AMD and other vendors compete with CUDA, calling this potentially worth a lot of money and technologically important.
• Some believe open‑source software and models, plus strong inference on commodity hardware, are the realistic path to “owning” NVIDIA’s current dominance.

Hiring bounties, AI, and the future of coding

• The bounty‑as‑interview model is contrasted with multi‑stage corporate interviews; some find it fairer, others see it as exploitative if undercompensated.
• There’s concern that AI coding agents will flood bounties with low‑quality patches, shifting value from coding to task specification and verification.
• One commenter speculates that as LLMs make both writing and understanding large codebases easier, huge legacy projects (LLVM, Linux, Chrome) may be harder to justify vs. focused, smaller stacks like tinygrad.

Community sentiment

• Enthusiasts praise the openness, clear technical mission, tiny stack, and hardware/software co‑design and express strong hope that tinygrad succeeds in pushing back against “rent‑everything” compute.
• Skeptics question the marketing emphasis (celebrity references, line counts), code ergonomics vs. PyTorch, and the founder’s public political writings, with some saying they’ll stick with mainstream frameworks for now.

Acquisition Rationale & Structure

• Official line: CD PROJEKT wants to focus on RPG development; selling GOG lets each pursue its own mission.
• Many commenters see GOG as a lower-margin, more volatile business being spun off from a stronger studio business.
• Some speculate GOG is being ring‑fenced so that if CD PROJEKT is ever acquired, GOG can remain independent and mission‑driven.
• People generally like that GOG will be privately held by a founder rather than under public‑market pressure.

Financial Health & Viability

• FAQ says GOG is “stable” with an “encouraging year”; some readers find that phrasing evasive.
• Analysis of CD PROJEKT filings shows tiny profits on relatively large revenue and very high cost of sales (~70%+), likely driven by revenue share with developers.
• GOG’s contribution to group profit is small; commenters see the spin‑off as rational but worry about long‑term sustainability and growth, especially against Steam.

DRM‑Free, Ownership & Offline Installers

• Strong support for GOG’s DRM‑free stance and downloadable installers; many consciously buy there over Steam despite worse UX or higher prices.
• Long debate over whether Steam purchases are “leases”: concerns about revocable licenses, delistings, changing content, and store shutdown risk.
• Counterpoint: Steam has a decades‑long track record, delisted games usually remain downloadable, and for many users practical convenience outweighs theoretical ownership.
• Users acknowledge that even GOG licenses are not legally “ownership” and can’t be resold, but offline installers are seen as a meaningful safeguard.

Linux, Clients & Ecosystem

• Many want an official Linux Galaxy client and/or formal support for Heroic, with cloud saves, achievements, multiplayer, and Linux builds wired into GOG’s backend.
• Others argue GOG’s value is precisely that no client is required; community tools (Heroic, Lutris, lgogdownloader, minigalaxy) plus documented APIs already exist.
• Experiences with Heroic/Galaxy‑compatible features (cloud saves, achievements) are mixed; some report they work, others find them flaky.

Preservation & Catalog

• GOG is praised as one of the few commercial actors serious about game preservation and classic titles running on modern systems.
• Concrete examples: Heroes of Might and Magic 3, Master of Magic; GOG often preferred over newer “HD” or Steam versions.
• Some note GOG’s biggest weakness is not enough new releases; many would rebuy modern games DRM‑free.

Piracy & DRM Debate

• One camp claims widespread piracy makes DRM‑free AAA releases non‑viable.
• Others counter that most Steam DRM is trivial, piracy is largely a service/price problem, and DRM mainly harms paying customers and enables artificial expiry of games.

User Experience & Trust

• GOG generally seen as ethical and user‑friendly, but there are blemishes:
  • Galaxy’s technical quality and security (old CVEs).
  • A notable refund denial due to mis‑logged playtime.
  • Past missteps like always‑online HITMAN and Gwent on GOG.
• Overall sentiment: cautious optimism; people hope independence strengthens GOG’s preservation/DRM‑free mission but remain wary about its financial and competitive position.

Static Allocation as “Old but New”

• Many note that “allocate everything at init, no heap afterward” is decades-old practice in embedded, early home computing, some DBs, and game engines.
• Others argue it’s still underused in mainstream backend/web work, so repackaging it (e.g. as a style guide) is useful, not hype.
• Several point out TigerStyle explicitly builds on prior work like NASA’s safety rules, not as something novel but as a disciplined application.

Motivations and Claimed Benefits

• Determinism: avoiding runtime allocation improves latency predictability and makes worst‑case behavior easier to reason about.
• Safety: in Zig without a borrow checker, banning post‑init allocation is used as a strategy to avoid use‑after‑free and scattered resource management.
• Simpler reasoning: centralized initialization and fixed limits encourage explicit thinking about resource bounds (connections, buffers, per-request memory) and reduce “soup of pointers.”
• Design forcing function: static allocation pushes you to define application‑level limits and batch patterns (regions/pools), similar to Apache/Nginx memory pools.

Critiques and Tradeoffs

• Static reservation can hoard memory and starve other processes, especially on multi‑tenant systems; dynamic allocation plus good design is often “good enough.”
• With OS overcommit, large “static” reservations don’t guarantee you won’t OOM later, and touching all pages at startup just shifts when failure happens.
• You still need internal allocators (pools, free-lists), so “no allocation” really means “no OS-level allocation after init,” not that memory management disappears.
• Fragmentation and exhaustion of fixed pools can be hard to debug (e.g. comparisons to LwIP), and you can still have logical use‑after‑free via index reuse.

OS, Databases, and Context

• Discussion connects static DB buffers to Linux overcommit and OOM behavior; some see historical DB tuning as a driver for overcommit.
• For a file/block‑backed database, static limits govern in‑memory concurrency rather than total data size, which many see as a good fit.
• For an in‑memory KV store, commenters stress this implies a hard upper bound on stored pairs and paying allocation cost upfront.

Broader Reflections

• Some see static allocation as aligning with safety‑critical and game/embedded practice; others note most modern apps favor GC and dynamic allocation for ease.
• There’s debate over theoretical implications (Turing completeness, reasoning about programs), but consensus that real machines are finite anyway.
• Several highlight the broader issue of how old techniques get lost and must be “re‑marketed” to new generations.

Carrier Control vs. User Freedom

• Many see eSIM as intentionally reducing user autonomy compared to physical SIMs.
• Key complaint: moving an eSIM between phones usually requires carrier approval, online access, and often SMS-based verification to the old device.
• This breaks the “pop SIM into new phone in 10 seconds” workflow, especially if the old phone is broken, lost, or abroad.
• Carriers can block or complicate transfers, charge fees, or even lock eSIMs to a device, which users view as a power grab reminiscent of pre-SIM CDMA days.

Real-World Failure Modes

• Numerous anecdotes:
  • Broken phone abroad, unable to receive SMS verification, stuck without number or 2FA for weeks.
  • Carriers requiring in-person store visits, postal QR codes, or bizarre ID checks to reissue or move eSIMs.
  • Travel eSIMs failing due to unsupported phone models, one-time QR codes, or poor customer support.
  • Horror stories of transfers getting stuck and numbers temporarily “lost.”
• These are contrasted with physical SIMs that generally survive device damage and can be moved instantly.

Where eSIM Shines

• Strong praise for travel:
  • Buy and provision data/voice before landing, often via apps; avoid language barriers, store visits, and local KYC hassles.
  • Easy to try new carriers or temporary plans; some MVNOs make eSIM swaps trivial via web portals with TOTP.
• Useful for multiple lines (work/personal, multiple countries) on one device without juggling plastic SIMs.

Technology vs. Policy

• Several argue the core eSIM tech is fine; problems stem from carrier and manufacturer choices and GSMA rules.
• Spec allows carriers to block removal/transfer, supporting subsidized-lock business models.
• Apple and other OEMs dropping SIM slots removes the physical “escape hatch” and amplifies bad carrier behavior.

Broader Pattern: Removed User-Friendly Hardware

• Thread links eSIM to removal of headphone jacks, microSD, and other physical affordances.
• Some users deliberately choose phones that retain physical SIM, SD, and 3.5mm jack, seeing these as last defenses against lock-in and hardware fragility.

Emerging Workarounds

• “Physical eSIM” smartcards (eSIM-on-SIM) let users load eSIM profiles then move them like regular SIMs, but are seen as niche and pricey.
• Consensus: best current setup is physical SIM for primary line, eSIM for travel/secondary use, and strong regulation to curb carrier abuses.