Hacker News, Distilled

Scope of the policy and its stated rationale

• Thread clarifies this is a pause on immigrant visas from 75 countries, not visitor visas; some posts say it’s officially framed as temporary while “public charge” procedures are reassessed.
• Others doubt the “temporary” framing, calling it a typical pretext for a long‑term restriction.
• Several note the list includes Russia, Iran, many Russian‑aligned or unstable states, plus some outliers (e.g., Thailand, Georgia, Brazil), with reasons for specific inclusions described as unclear.

Citizenship-based discrimination and open-borders debate

• One camp sees this as worsening discrimination by origin and a worrying precedent for global copycats.
• Another argues every state already discriminates by citizenship; free entry is not a human right.
• That view is strongly contested: critics link “alien” vs. “native” framing to historical dehumanization and genocide, and reject blanket country bans as unjust.

Economic, cultural, and “public charge” arguments

• Some argue uncontrolled migration harms societies and cultures, and that large inflows reproduce origin-country institutions and norms.
• Others counter with US history of large-scale immigration, question the evidence, and claim capital prefers cheap, mobile labor while restricting worker protections.
• Multiple commenters point out the US already requires affidavits of financial support; if “public charge” is a problem, it’s an enforcement or bad-faith-pretext issue.
• Comparisons are made to Canadian-style points systems, which also exclude people (e.g., disabled) but are seen by some as more transparent.

Personal impacts, tech, and brain drain

• Tech workers report colleagues with green cards or pending EB visas now planning to leave for Europe (e.g., Belgium), citing fear of future rule changes.
• Immigrants and their families express anxiety about green cards, citizenship prospects, and even denaturalization talk, especially for non‑white nationals.
• Several predict other countries will benefit from US-driven brain drain.

World Cup, sports, and global events

• Commenters question how a US‑hosted World Cup and other competitions will function amid visa unpredictability, citing recent denied visas for athletes.
• Some note the pause doesn’t affect visitor visas, but others point to existing cases where elite athletes were refused entry anyway.

Meta: HN moderation and polarization

• Significant side discussion centers on this and related submissions being quickly flagged despite high interest.
• Some attribute it to bots or partisan brigading; others to long‑standing cultural bias on the site against politically uncomfortable topics.
• Users share workarounds (e.g., using the “active” page) to see heavily flagged but active discussions.

Directory and purpose of the thread

• OP is building a directory of HN personal sites at hnpwd.github.io, seeded from sites that have had reasonably successful HN submissions.
• People are encouraged to either post links in the thread or submit GitHub PRs; OP prefers PRs for scalability but doesn’t want that to block participation.
• There’s interest in importing links from a similar July 2023 Ask HN and in driving the directory from a JSON file to make automation easier.
• Other discovery tools are mentioned: blogs.hn, Kagi’s “small web” directory, webrings, and “now” pages as related ecosystems.

Types and styles of personal websites

• Huge variety: technical blogs, CV/portfolio sites, photo and art galleries, creative writing, game dev, music, security research, hardware hacking, and niche interests (language learning, semiotics, theology, cruising, etc.).
• Many sites are static (Hugo, Jekyll, custom SSGs, Nix, Go, Quarto, hand-rolled generators), often hosted on GitHub Pages or simple VPS setups.
• Design ranges from ultra-minimalist “old web” HTML to highly stylized experiences (OS/Desktop metaphors, pure-CSS 3D spaces, SVG metaballs, shader-heavy UIs, retro Windows/Apple clones, multiverse mode switchers).
• Several authors proudly mention unusual or very short domains and personal TLD choices as part of their identity.

Meta-discussion on blogging, feeds, and “small web”

• Many say they rarely update their sites and hope this thread motivates them to write more.
• Strong interest in RSS/Atom feeds; some readers explicitly only follow via RSS and complain when feeds are missing.
• Some lament modern platforms (e.g., WordPress “enshittification”) and express nostalgia for hand-made, ad-free, cookie-free personal sites.
• A few suggest making this “share your site” thread recurring (quarterly/annual) to keep the small web energy alive.

Tooling, infrastructure, and safety concerns

• Suggestions to automate link extraction from the thread (e.g., browser scripts) and to use static-friendly comment systems.
• One detailed cautionary story about using AWS as a domain registrar: account suspension → 2FA lockout → account “closed” → domains immediately released and grabbed by others, including scammers.
• Some discussion of HN’s spam filter: many single-link comments from very new accounts are auto-killed; users are torn between vouching for them and worrying they’re AI-generated spam.
• A minority voice calls the thread “people doxxing themselves,” but this isn’t widely picked up.

Economics of surplus and negative prices

• Several comments frame this as a textbook case of extreme supply vs. demand: beyond a point, the “price” to sell goes negative because disposal costs dominate.
• Analogies are drawn to electricity markets and the brief negative oil prices during the pandemic, where storage and ramp-up/ramp-down constraints made producers effectively pay others to take product.
• Some note that in agriculture and groceries, distribution and retailing often cost more than growing the crop, so “free at the farm” doesn’t translate to free in cities unless someone subsidizes logistics.

Who actually pays and how it’s organized

• Concern is raised that a farmer must be losing money; others clarify that in this case the farmer was already paid under a contract.
• The buyer faced low demand and high transport/distribution costs, so a newspaper and a company stepped in to cover those costs for a one-off campaign.
• Distribution is mostly via 1‑ton “big bags” to organizations that then pass potatoes on to individuals, suggesting the main channel is charities and social projects, not direct walk‑up consumers.

Waste, demand, and market impacts

• One camp argues this just shifts waste: people will substitute free potatoes for store-bought ones, leading to supermarkets discarding more.
• Others counter that even partial use is better than plowing the whole surplus under, and that some demand is elastic: people will eat more potatoes when they’re cheaper or free, or stock up and displace other staples.
• A separate worry is that large-scale free distribution might undercut small local sellers, though skeptics note German consumers are picky about potato varieties and that the specific bulk type may not overlap much with high-end local markets.

Food insecurity comparisons

• Commenters contrast this European surplus giveaway with US practices where excess crops are sometimes destroyed while people still experience food insecurity.
• There is debate over how severe US hunger is: advocacy stats (e.g., “1 in 7”) are critiqued as conflating occasional food insecurity with chronic hunger, yet multiple people insist school meals are crucial for many children.

Scale, units, and visualization

• There’s an extended side-thread on “tons” vs. metric tonnes, gigagrams, and “freedom units”, including playful approximations in cubic meters, elephant-equivalents, and numbers of meals/households.
• Some highlight that 4,000 metric tons = exactly four million kilograms, despite the article saying “almost.”

Alternative uses and lighthearted takes

• Suggestions range from fries, mash, and vodka/akvavit to biofuel and even a hypothetical “potato battery bank,” with rough back-of-envelope power calculations.
• Others lament that drying or processing into storable forms (e.g., mash, frozen fries) might be more efficient, but acknowledge that costs and logistics likely make that unrealistic here.

Politics, Leadership, and Inflation

• Several commenters argued presidents have limited control over inflation in current global conditions, though some insisted a president can matter in “normal times.”
• Tariffs were blamed by some for muting what could have been a sharper fall in inflation, with goals seen as misaligned with affordability.
• There is strong distrust that political and economic leadership is aligned with ordinary people; some see inflation as a deliberate tool to erode wages, stealth‑tax workers, and protect asset‑holders.
• Targeting 2% inflation was challenged; some advocated 0%, doubting mainstream justifications.

Measuring Inflation and “Vibeflation”

• NPR’s 114‑item Walmart basket was praised as relatable but criticized as too small compared to what large datasets or card/retailer data could support.
• Debate over “basket of goods”: some say CPI is adequate as an average model; others argue it obscures essentials vs non‑essentials and distributional effects.
• The ALICE “essentials” index was highlighted as better capturing survival costs and explaining “vibeflation,” where people feel worse off despite modest CPI.
• Others insisted both broad CPI and essentials-focused measures are needed for policy, especially for Social Security and low‑income households.

Shrinkflation, Quality, and Product Changes

• Shrinkflation examples (toilet paper rolls, coffee bags, bacon, detergent, fast‑food drink sizes) resonated strongly.
• NPR accounting for price per unit was welcomed, but commenters noted quality downgrades (e.g., “dairy dessert” vs ice cream, weaker products) are much harder to capture.
• This fed a broader sense of “enshitification” and product “baffleware” that overwhelms consumers.

Specific Goods and Pricing Dynamics

• Ice cream: inputs (milk, butter, sugar) were reported down or flat, but retail prices up; explanations offered included labor, energy, distribution, brand margins, and local optima in pricing.
• Soda: many noted a jump from roughly $1 to ~$3 per bottle; attributed variously to standard supply/demand, deliberate “greedflation,” and oligopolistic “because they can” pricing. Some evidence was cited of recent price cuts after demand softened.
• Cheap fish (swai) and dollar-store mispricing were cited as examples of hidden or low-quality costs.

Distributional Effects and Coping Strategies

• Commenters stressed that essentials (housing, childcare, healthcare, interest on debt) outpacing wages hits the bottom third of earners hardest.
• Mortgage forbearance and FHA loss‑mitigation programs were described as quietly keeping some nonpaying homeowners in place, with debate over how long that can last and who ultimately pays.
• Coping responses included cooking from scratch (rice/beans/lentils/veg), switching to store brands, buying secondhand toys, tracking personal spending, and replacing disposables (paper towels, some toilet paper) with reusables.

Perceived Capability: “Good Junior Dev,” Not Senior

• Many compare Claude and similar tools to a competent junior developer: fast at localized tasks, but needing close review and architectural guidance.
• Some report shipping “most of their code” with Claude (Opus 4.5), including production systems, with clear gains in velocity and bug-fixing (e.g., generating PRs from Datadog errors).
• Others argue even a good human junior is still more capable, especially at handling ambiguity and understanding systems.

Abstraction, Architecture, and API Design

• Strong consensus that LLMs excel at filling in details (implementing features, wiring code, refactoring with specific patterns) but struggle to invent good abstractions, APIs, or module boundaries without human direction.
• Examples: inefficient data copying instead of rearchitecting for pointer-style sharing; poor React component design; Python code with nested ifs, mis-scoped imports, and swallowed exceptions.
• Several note this mirrors the median human developer: most people are bad at API design and high-level abstraction anyway.

“Just Search” vs Compression and Novelty

• One camp frames LLMs as “really good search”: semantic retrieval over training data + user code, recombining known patterns. This mental model helps set realistic expectations: great at mapping, translating, modifying; weak at truly “from scratch” creation.
• Others call “just search” reductive, likening it to calling CPUs “just transistor states.” They emphasize:
  • LLMs act as lossy probabilistic compressors of human knowledge, synthesizing and recombining concepts.
  • Internal “circuits” and conceptual relationships can enable interpolation, limited extrapolation, and emergent reasoning-like behavior.
• Debate over whether outputs can ever be genuinely novel vs only “novel to the user” continues, with no consensus.

Reliability, Hallucinations, and Verification

• Experiences are highly mixed: some see large quality improvements and fewer hallucinations over time; others still hit made-up APIs, types, or misleading solutions that waste time.
• Simple harnesses (e.g., static typing, linting, tests, formal methods) can catch many hallucinations in code, but most domains lack such verifiers.
• A common pattern: Claude often chooses minimal or local edits, sometimes suboptimal globally; attempts to correct via CLAUDE.md–style instructions have only partial success.

Workflow, Learning, and Productivity

• Many feel “unlocked”: able to try more ideas, run more experiments, and explore design alternatives quickly, similar to the shift from film to digital.
• Others worry this leads to shallow thinking: quick prototyping replacing deeper internal reasoning and design “marination.”
• On learning: some say LLMs accelerate conceptual understanding by enabling more experiments; others feel they learn little unless they deeply review and debug the generated code themselves.

Future Trajectory and Limits

• One side sees a moving frontier: LLMs progressed from small functions to multi-file subsystems; therefore, higher-level abstraction and multi-service design may improve similarly in 6–12 months.
• Another side argues there are hard ceilings:
  • Persistent failures at abstraction and hallucinations despite scale-ups.
  • Training on “random internet code” bakes in bad patterns; prompts can’t fully fix that.
• No agreement on whether we’re nearing a plateau or just mid-curve.

Organizational and Economic Implications

• Speculation ranges from “mid-level-equivalent AI would be revolutionary” to tongue-in-cheek visions of a CEO plus fleets of agents (and even questioning whether a CEO would still be needed).
• Some foresee boards and owners still wanting a human “ringable neck” and guardian against misaligned AI-provider incentives.
• Broad concern that another path to the middle class (junior dev work) is narrowing, even if senior design and oversight roles remain human for the foreseeable future.

Scope of the $1 Proposal

• Many commenters note the title is misleading: the idea is to charge org users on paid plans, not “everyone.”
• Some think this could raise a meaningful fund (millions/month) and modestly improve sustainability for key projects.
• Others argue the amount per maintainer would be tiny given the number of projects and developers involved.

Metrics, Abuse, and Perverse Incentives

• Basing payouts on dependency usage (e.g., mentions in package.json / requirements.txt) is widely criticized:
  • Rewards micro‑packages and transitive “wrapper” dependencies far more than core, hard work.
  • Strong incentive to create spammy packages and push them into dependency trees, especially with AI code‑gen.
• Static, algorithmic rules are seen as guaranteed to be gamed; examples from NPM, Tea.xyz, and Spotify‑style streaming scams are mentioned.
• Popularity is not seen as a good proxy for real value, ongoing effort, or security‑critical maintenance.

What Open Source “Owes” and Is Owed

• One camp: FOSS is fundamentally a gift; licenses explicitly say “AS‑IS, NO WARRANTY.”
  • Using it without paying is morally fine; maintainers don’t owe support, features, or fixes.
  • If you want changes or guarantees, you should pay or build it yourself; saying “no” is normal.
• Other camp: load‑bearing volunteer projects create real risk (burnout, unmaintained, insecure infra).
  • When something becomes critical infrastructure, companies should be expected–or at least strongly nudged–to fund it.
  • Some want mechanisms that make it easier to transition from hobby to funded maintenance without “begging.”

Alternatives to a GitHub Tax

• Dual/commercial licensing, non‑commercial clauses, or “free for individuals/small biz” models.
• Direct corporate sponsorships, grants, and public funding; some see OSS as a public good best funded via taxes or government programs.
• Better use of existing tools (GitHub Sponsors, OpenCollective, npm fund), plus easier org‑level sponsorship workflows.
• Broader ideas: UBI or stronger safety nets so more people can afford to do uncompensated creative/OSS work.

Centralization, Power, and Microsoft

• Significant distrust of making Microsoft/GitHub a de facto tax collector and allocator:
  • Risk of capture, enshitification, rent‑seeking, and further lock‑in around a single proprietary hub.
  • Worry that “I pay GitHub, so you owe me” attitudes would worsen entitlement toward maintainers.
• Some argue Microsoft itself, not users, should be putting a substantial share of its profits into OSS, especially given Copilot and AI trained on public code.

Throttled “unlimited slow” vs hard caps and overage fees

• Many commenters praise the move to unlimited throttled access (500 kbps) after the cap as far better than a hard cutoff or punitive overage billing.
• Others miss the old $1/GB over-cap option, arguing it was fairer for occasionally heavy months than having to upgrade to a much more expensive unlimited plan.
• Several note you can upgrade to unlimited mid‑month and then downgrade for the next billing cycle, which mitigates some concerns.

Is 500 kbps actually usable today?

• Some say 500 kbps with decent latency is enough for email, messaging, VoIP, Zoom in low resolutions, basic browsing, and even low‑res YouTube/Netflix with buffering.
• Others argue modern sites, web apps, and streaming expectations make sub‑1 Mbps “painful” or “effectively unusable” for normal habits, pointing to multi‑MB homepages and aggressive timeouts.
• There’s nostalgia for dial‑up/ISDN speeds, but multiple people stress the web has grown heavier and less tolerant of slow links.

Real‑world Starlink use and technical behavior

• RVers, van‑lifers, remote workers, and rural users report Starlink as transformative, often preferring it even where 4G/5G exists due to consistency.
• Latency for interactive use is typically described as 20–50 ms, with periodic spikes (likely from satellite handoffs or obstructions) noticeable in gaming and sometimes video calls.
• The cheap “standby”/backup-style plans with low but usable bandwidth are popular for camping, driving, failover, and as a safety net when other links fail.

Comparisons to mobile data and throttling norms

• Many compare Starlink’s model to cellular plans that throttle after a quota; most prefer transparent throttling over surprise fees or total cutoff.
• Discussion branches into wildly different mobile data prices and caps worldwide and how throttled “unlimited” can still be practically useful.

Ethics, monopoly, and competition

• A substantial subset refuses to use Starlink on ethical/political grounds, arguing money directly empowers objectionable behavior.
• Others separate the technology from the owner, emphasizing Starlink’s unique value for underserved regions.
• There’s debate on whether Starlink has a de facto monopoly, the coming role of Amazon Kuiper and Chinese constellations, and how “threat of competition” may drive ongoing improvements even now.

Scope, terminology & communication issues

• Many visitors outside the UK were confused: the site accepts only UK postcodes and covers England & Wales (not Scotland, N. Ireland, or other countries).
• Several argue the homepage should clearly say “UK/England & Wales only” and briefly explain “rates” and “rateable value”; others say the intended audience already knows this and external users can just move on.
• Debate over domain conventions: some Americans assume “.com” implies US‑centric content; non‑US commenters push back, noting .com has long been global and the US is simply used to not using a country TLD.
• Confusion also stems from vocabulary: “postcode” vs “zip code,” and “pub” vs “bar,” with some Americans unsure what kind of venue is meant.

Business rates and pub taxation

• Commenters explain “pub rates” as UK business property taxes based on a government‑assessed rental value, not on profits.
• Pandemic‑era discounts on business rates for hospitality were heavily reduced and are planned to be removed, just as many rateable values have risen sharply.
• Some report local pubs facing 400–800% increases in rateable value; others see decreases, raising questions about previous valuation fairness.
• There is disagreement over framing: is keeping temporary relief a “subsidy,” or is the underlying tax structure itself punitive and poorly designed for low‑margin businesses?

Economics and decline of pubs

• Pubs are portrayed as having high fixed costs, thin margins, and highly price‑sensitive customers. Large chains with cheap property and huge volume can survive where independents struggle.
• Multiple factors driving decline are cited: rising rents, energy and wage costs; high alcohol taxes; competition from supermarkets; changing social habits; younger people drinking less or preferring gyms, gaming, or drugs over pubs.
• Rural pubs are especially vulnerable due to drink‑driving limits and lack of public transport.

Cultural role vs harms of alcohol

• Many see pubs as vital “third spaces” and social infrastructure, akin to libraries or youth centres; closures are described as tearing at social fabric and community life.
• Others, citing alcoholism, cancer risk, and violence, welcome pub closures and argue society over‑romanticizes drinking.
• Counter‑arguments stress that alcohol is a lubricant for social interaction, not the sole point of pubs, and that non‑drinkers can and do use them.
• Broader debate emerges over whether societies can design attractive, non‑alcohol third places at scale.

Reactions to the site & data

• The irreverent “fucked” status scale is widely praised and repurposed jokingly for error logging and other uses.
• Some users report map rendering issues, SSL errors, and outdated data (closed pubs still listed, old names, no Scottish pubs). The author’s own disclaimer that VOA data are often inaccurate is noted.
• A few suggest incorporating footfall or “busyness” data, open‑sourcing the code, or adapting the idea for other countries and for other threatened community venues.

Status of the policy / what’s actually changed

• Many commenters argue the headline is misleading: the government dropped the idea of one mandatory, single digital ID, not the move to digital checks.
• Digital right‑to‑work and other checks are still planned to move fully online by 2029; people expect something akin to the US E‑Verify, with multiple acceptable IDs.
• Some predict that, in practice, opting out will simply be made very difficult.

Arguments in favour of (some form of) digital ID

• A unified or federated ID could greatly simplify KYC, right‑to‑work, right‑to‑rent, banking, tax, and healthcare; several commenters describe the current UK setup as “fractally awful”.
• Examples from Scandinavia, Estonia, Switzerland and others are cited as proof that privacy‑respecting digital ID is possible and hugely convenient.
• Proponents suggest it would be better to share validated tokens than raw personal data and could reduce bureaucratic catch‑22s for migrants and workers.
• Some think a mandatory system, tied to benefits and employment, could curb illegal immigration.

Arguments against / surveillance, trust and competence

• Strong concern that UK political culture and state capacity would turn digital ID into a tool of control rather than citizen convenience (“bind, not tool”).
• Fears of an “Orwellian panopticon”, digital fascism, and the ability to “switch off” individuals from work and services.
• Suspicion that immigration and fraud rhetoric is a pretext; right‑to‑work checks already exist and legal migrants already use online e‑visas.
• Deep distrust that contracts would be handed to politically connected firms and implemented badly, given the UK’s track record with big IT projects.

Immigration, citizenship and constitutional context

• Multiple threads argue digital ID will not fix the underlying mess of UK immigration and nationality law: high costs, heavy paperwork, fragmented statuses, and powers to strip citizenship.
• Debate over whether a written constitution would help; some say it’s largely symbolic against an adversarial government, others see it as a needed foundation before tightening citizen tracking.

Broader politics

• Comments highlight party discipline, MPs parroting changing lines, and rapid policy U‑turns.
• Views range from “this was a sensible idea ruined by politics” to relief that an “incompetent” government failed to implement something potentially dangerous.

Deterrence and troop deployments

• Many see Denmark’s reinforcements (and expected NATO contingents) as a classic “tripwire” force: small, but enough to make any US move costly and politically explosive.
• Others argue the extra cost is negligible in Denmark’s budget and there is wide public support for defending Greenland, so “sapping” Denmark’s resources is unrealistic as a US strategy.
• Stationing allied troops is also seen as a signal that other NATO members no longer assume the US is a reliable defender, and are preparing for the possibility of US aggression while still hoping to preserve NATO on paper.

US motives and Trump’s role

• Commenters are divided between two main explanations:
  • Personal: Trump wants “ownership” of Greenland for ego and symbolism, settling old scores from his first term.
  • Geopolitical/oligarchic: pressure from billionaire and resource interests, plus a desire to push out China/Russia and secure rare earths and Arctic positions.
• Some see the whole saga as primarily a domestic political spectacle, not a genuine strategic necessity given existing US basing rights.

Greenland’s status, subsidies, and independence

• Denmark heavily subsidizes Greenland (figures like ~15k EUR per resident per year are cited), which makes full independence financially difficult.
• Polls are referenced where abstract support for independence collapses if living standards fall.
• Several argue the US could get what it wants by backing Greenlandic independence and then offering security and trade deals, rather than threatening force.

Invasion, occupation, and NATO response

• One line of argument: Greenland’s tiny, coastal, sparsely spread population and Denmark’s small military would stand no real chance against a US invasion, and most NATO members would pragmatically stay out to preserve US participation and funding.
• Counter-arguments cite US difficulties in past asymmetric conflicts and the risks of occupying hostile terrain with an armed population.
• Some believe a US attack on Danish/NATO forces would trigger massive protests and internal resistance in the US military; others are cynical and expect only limited public pushback.

Alliance credibility and diplomacy

• There is concern that even threatening a NATO ally makes the US effectively an enemy, undermining the alliance more than any Russian action could.
• Debate over whether the US could/should threaten to leave NATO to gain leverage; some note that only Congress can actually withdraw, and many allies already act as if US security guarantees are unreliable.
• Views diverge on Danish/Greenlandic leaders travelling to Washington: seen either as weak “going to the king” or as prudent, civilized engagement to manage an erratic but still powerful partner.

Meta and context

• Multiple comments express disbelief that an invasion of Greenland by the US is being discussed at all, as evidence of how far US politics has deteriorated.
• There are references to tech/VC and “network city” projects already eyeing Greenland, and to fringe MAGA fantasies, as part of a broader pattern of outside actors coveting the territory.

Press freedom, sources, and chilling effects

• Many see the raid as a direct attack on public‑interest reporting and a way to unmask and punish over 1,000 federal employee sources, with fears of firings, prosecutions, denaturalizations or worse.
• Others note DOJ claims the reporter isn’t a target and say this looks like a standard leak probe aimed at a contractor, but opponents argue that even if technically legal, raiding a reporter’s home is an extreme, rare step that will intimidate future sources.
• Commenters stress that, in U.S. law, it’s the leakers (federal employees/contractors) who are bound by classified rules, not journalists—so the raid targets someone who likely committed no crime to build a case against others.

Government power, ICE, and “secret police” dynamics

• A large part of the thread focuses on ICE’s evolution from immigration enforcement into what many describe as a de facto political police force: warrantless raids, lying to local police, detention and even killing of U.S. citizens, and deployment against “blue” cities.
• Several link this to broader authoritarian drift: deportations of citizens, masked agents grabbing protesters, and courts and Congress failing to check executive power. Some argue this is the predictable culmination of decades of “imperial presidency.”

Tech, surveillance, and device access

• Strong claims appear that U.S. agencies effectively have “root” into Apple/Google ecosystems and can push targeted updates; others push back, pointing out the lack of public proof and past fights over iPhone access.
• End‑to‑end encryption is called out as hollow when corporations control the endpoints.

Law, leaks, and double standards

• Multiple comparisons are drawn: Pentagon Papers vs. today; Snowden vs. incremental internal whistleblowing; Assange and Project Veritas vs. mainstream reporters.
• Some argue the legal framework (espionage laws, search warrants for third parties) allows selective enforcement: “classified” can mean whatever is convenient, creating a tool to harass disfavored journalists while insiders (e.g., presidents with documents at home) evade consequences.

Protest, politics, and resistance

• Commenters debate whether weekend protests and local organizing against ICE shootings indicate a “boiling frog” public or the early stages of serious resistance.
• There’s disagreement over how much politics belongs on a tech forum, but others insist surveillance tech, data markets, and AI tools are now central to repression, so “tech is politics.”
• Long subthreads argue over whether the Second Amendment has any real bite against a modern security state, and why many self‑styled “patriots” cheer state violence while decrying minor speech regulation.

Tools and Local Setups

• Many people use turnkey or semi-turnkey tools: LibreChat (with built-in vector DB), AnythingLLM, Kiln, Haiku.rag, Libragen, Nextcloud MCP server + Qdrant, discovery, etc.
• Common DIY stacks:
  • Ollama or llama.cpp for local models
  • Chroma, Qdrant, LanceDB, Milvus, SQLite + sqlite-vec / FTS5 / vec0, DuckDB VSS, Postgres + pgvector/ParadeDB, USearch, FAISS (CPU/GPU).
• Several homegrown libraries and CLIs were shared (piragi, llmemory, lifepim-ai-core, ragtune, SearchArray, pdfgptindexer-offline, seance, qmd, ck, local-LLM-with-RAG).

Vector Search vs BM25/Keyword Search

• Strong thread arguing BM25/TF‑IDF + n‑grams/trigrams often beat or match embeddings, especially for code and traditional IR.
• For code search, multiple people recommend BM25 + trigram (or ripgrep) over vectors; embeddings can be slow, noisy, and require careful models and rerankers.
• Others report excellent results from static/fast embedding models and hybrid search (BM25 + vectors + reranking) for both code and natural language.
• SQLite FTS5, Postgres BM25 extensions, Meilisearch, Manticore, Typesense, and Elasticsearch/OpenSearch are mentioned for sparse/hybrid search.

RAG Without “Heavy” Infra

• Several setups avoid vector DBs entirely: just full-text search over markdown, or agentic retrieval over filesystem/web APIs.
• Clarification that RAG is about retrieval-augmented generation in general; a vectordb is optional.
• Some use large context windows (e.g., 1M tokens) to “just stuff everything in,” but others still prefer RAG for efficiency and control.

Scaling, Performance, and Hardware

• FAISS noted as RAM-bound; once data doesn’t fit in memory, it’s the wrong tool.
• Experiences shared with large embeddings sets (millions of chunks, tens of GB RAM); FAISS GPU vs CPU tradeoffs.
• DuckDB and Qdrant discussed for both small local projects and potential TB-scale use, with advice to benchmark for specific rigs.
• One user offloads RAG to hosted/vector DB due to local slowdown on an M1 Pro.

Use Cases and Challenges

• Use cases: internal company chatbots, personal knowledge bases, RSS feeds, academic PDFs, datasheets, transactional/financial records, Zotero and Excel analysis, Claude Code memory.
• Chunking and document structure (tables, multi-column PDFs, financial records) are repeatedly cited as bigger practical challenges than model choice.
• Some are exploring graph-based/KAG approaches atop RAG for higher-level reasoning and traceability across complex systems.

Overview of the Dispute

• SparkFun published a brief, vague notice saying it is ending its relationship with Adafruit due to Code of Conduct violations, mentioning offensive/derogatory emails and “involving a customer in a private matter.”
• Many commenters say the statement invites speculation by hinting at misconduct without concrete details, and that SparkFun could have quietly stopped carrying the products instead.

Adafruit’s Account vs SparkFun’s Account

• Adafruit’s representatives claim:
  • SparkFun leadership and a former employee engaged in years-long harassment (hate/meme sites, photoshopped images) targeting Adafruit leadership, allegedly on company time.
  • Repeated private complaints were ignored; when they pushed again in 2025, SparkFun allegedly retaliated by cutting Adafruit off from buying Teensy boards (which SparkFun now exclusively manufactures) and invoking a “secret” CoC.
  • In response, Adafruit is discontinuing Teensy sales and working on an open-source, Teensy-compatible alternative.
• Counter-links and gists are shared showing:
  • A former SparkFun employee’s “joke site” and later apology/transfer of the domain, which some see as overblown by Adafruit.
  • Email chains and social-media threads where an Adafruit leader uses confrontational language, contacts employers/partners of critics, and is accused of doxxing and harassment. Some readers conclude “both sides look bad.”

Code of Conduct and Communication Critiques

• Large subthread debates CoCs:
  • Critics see them as vague, selectively enforced “HR for open source,” easily weaponized in interpersonal or political disputes.
  • Others argue a CoC is just codified “don’t be an asshole” and necessary for setting expectations, though bad CoCs and bad moderators are real risks.
• Several commenters describe SparkFun’s public CoC-framed notice as unprofessional and potentially defamatory; others say being transparent about a broken partnership is reasonable.
• Many think both companies should have handled this privately or, if going public, provided specific, evidence-backed details rather than insinuations.

Teensy / “Freensy” and Technical Impact

• SparkFun now exclusively manufactures Teensy; Adafruit can’t buy or sell it and will sell through existing stock only.
• Adafruit proposes an open-source Teensy-form-factor board (likely RP2350-based initially), adding features like SWD debug, onboard storage, LiPo charging, and open bootloader.
• Some welcome an open alternative; others note Teensy’s strength is its high performance, peripherals, and polished software ecosystem, which will be hard to match quickly.

Customer and Community Reactions

• Some declare they’ll boycott SparkFun; others, Adafruit; many say they’ll keep buying from both or just “who’s cheaper.”
• Several worry about Teensy ecosystem fragmentation and collateral damage to PJRC, which appears caught in the middle.
• A notable portion of the thread expresses fatigue with “open source drama,” viewing all parties as acting immaturely and urging them to stop litigating this in public.

Core Pain: Slow, Opaque Feedback Loop

• Main frustration is the “edit → commit → push → wait” cycle for even trivial workflow fixes, especially when failures occur only on specific OS/arch runners (notably macOS and ARM).
• Lack of first‑class “SSH into failed runner” support makes debugging painful; you’re forced to guess via logs and repeated runs.
• Several commenters think the blog post over-attributes a dependency/install problem to Actions itself, but still agree the debugging story is bad.

Local Scripts vs YAML Logic

• Very strong consensus: do not embed real logic in GitHub Actions YAML.
• Common pattern: workflow should just:
  1. Check out code
  2. Call a repo‑local script / Makefile / task runner
• This preserves local debuggability, reduces lock‑in, and makes migration to another CI or local runners easier.
• Some note this isn’t unique to GHA: any CI becomes painful if logic lives in the CI config rather than scripts.

Tooling for Local/Interactive Runs

• act is frequently suggested as a local runner; people find it helpful but:
  • Not a full drop‑in, Linux-only for proper runner emulation, and struggles with complex workflows and macOS use cases.
• SSH-style debugging actions (tmate, now upterm; custom SSH/cloudflared actions) partially address the pain by allowing live shell access to a failing job.
• Other CIs (SourceHut, Semaphore, some self-hosted setups) are praised for “rebuild with SSH” capabilities.

Environment, Caching, and Reproducibility

• Installing tools inside Actions is a recurring source of flakiness and time waste.
• Patterns to mitigate:
  • Use containers or Nix/mise to define reproducible dev/CI environments; let Actions only orchestrate.
  • Use hash-based caching keyed on lockfiles; rely on actions/cache or similar.
  • Some build custom images or run everything inside a single container/VM they can also run locally.

Language & Scripting Debates

• Disagreement over best scripting layer:
  • Some argue bash + Make/task runners are sufficient “plumbing.”
  • Others highlight bash’s fragility and prefer Python, PowerShell, Deno/TypeScript, or other higher-level tools for anything non-trivial.
• General agreement that whatever is used must be runnable locally and cross-platform where possible.

GitHub Actions vs Alternatives & Responsibility

• Mixed views: many dislike GHA UX and see strong vendor lock‑in; others find it still better than Jenkins/Travis and invaluable for free OSS compute and broad OS/arch coverage.
• Alternatives mentioned: GitLab CI, Bitbucket Pipelines, SourceHut, OneDev, self-hosted Forgejo/Gitea, plus newer platforms (Dagger, RWX, Depot).
• Some call the blog’s scenario a “skill issue” (misusing Actions for dependency installation), while others stress that the lack of tight feedback loops and interactive debugging is a genuine systemic flaw.

Operational simplicity vs Redis overhead

• Many welcome using SolidQueue (or similar DB-backed queues) to remove Redis from the stack, especially for small/medium Rails apps where Redis mainly serves background jobs.
• Core argument: you already operate Postgres/MySQL; if the database can handle queuing “well enough,” adding Redis is extra cost (deployment, HA, monitoring, auth, networking).
• Others push back that those Redis “costs” mostly mirror what you must do for Postgres anyway; the real benefit is consolidation, not that Redis is uniquely hard.

Queue DB vs application DB

• Debate over whether the job queue should share the same database as the main app:
  • Pro-same-DB: simpler architecture, transactional enqueueing with business data, fewer reconciliation headaches when one system fails.
  • Pro-separate-DB: avoids the queue overwhelming the primary DB; easier backup/restore semantics (e.g., not replaying old jobs like emails).
• Some argue coupling business and queue state tightly (same DB, same transactions) makes later migration to a separate queue harder.
• SolidQueue can use a separate DB config by default but also supports sharing the app DB.

Scalability and performance of DB-backed queues

• Several reports of Postgres-based queues hitting performance walls at modest rates (e.g., 2–5k jobs/min) and teams moving to Redis-based systems like BullMQ to stop tuning PG.
• Others claim such loads should be trivial for a properly tuned database and suspect misconfiguration or lack of batching.
• Elixir’s Oban benchmark (1M jobs/min) is cited as evidence DB queues can scale, but critics note it relies heavily on batching and is far from typical usage.
• LISTEN/NOTIFY in Postgres is called out as a bottleneck at high volume; systems work around this by debouncing notifications or relying more on polling.
• Replication overhead is mentioned as a real scaling limit even if a single node can churn through rows quickly.

Feature set, maturity, and Rails ecosystem

• SolidQueue praised for making “Rails 8 monolith” setups very simple and integrated (Active Job, unified “Solid” features).
• Concerns: still “early days,” some concurrency bugs reported, silent failures when DB pools fill, and a relatively weak UI compared to Sidekiq or GoodJob.
• GoodJob (Postgres-only) is viewed as more mature and feature-rich (e.g., batches, better UI), but its use of PG-specific features and session requirements can conflict with some connection poolers.
• Rails’ desire to keep SolidQueue SQL portable across databases (e.g., MySQL) limits engine-specific optimizations; some see this as a downside for Postgres-heavy shops.

Payload size and job design

• Consensus from multiple commenters that large job payloads are a poor fit for DB-backed queues and often for Redis too.
• Recommended pattern: store large data elsewhere (DB tables or object storage) and enqueue only identifiers; many frameworks’ docs already encourage this.
• One commenter explicitly benchmarked Redis vs Postgres vs SQLite and found Redis clearly faster for large JSON payload jobs.

When Redis (or other queues) still shines

• Several argue that if low-latency, high-throughput, or very large-scale workloads are central, a purpose-built queue (Redis, SQS, Kafka, etc.) remains the right tool.
• Redis is still valued for:
  • Caching (multi-layer caches in large SaaS setups).
  • Rate limiting and high-frequency counters where DB roundtrips are too slow or too costly.
  • Pub/sub or broadcast to many services with simple ops and language-agnostic clients.
• Others suggest that if you’re already on a major cloud, managed queues like SQS/PubSub are often a better default than either Redis or the primary DB.

Scope of “AI safety” and regulatory capture

• Some argue prominent “AI safety” groups focus on speculative extinction risks to scare regulators, paving the way for centralized control and an oligopoly of “trusted” big firms.
• Others counter that small advocacy orgs have limited resources, do address current harms (deepfakes, wellbeing, etc.), and that structural fixes (lawsuits, regulation) are hard.
• Debate over whether these orgs meaningfully tackle pollution, CSAM, and harassment versus mostly promoting “intelligence explosion”–style scenarios.

Intelligence vs. utility

• Long back-and-forth over whether LLMs are “intelligent” or merely imitating intelligence.
• Some point to complex practical tasks (debugging systems, building full stacks, using custom DSLs) as evidence of real intelligence.
• Others say it’s pattern-matching over human output, will degrade without new data, and is best understood as a powerful calculator or power tool, not as a mind.

Hype, con, and marketing

• Many agree LLMs are useful but argue they’re sold as miracle cures (curing cancer, ending poverty, etc.), which fits the definition of a con: selling more than you deliver.
• Others say a tool that provides real gains, even if overhyped, is not a “confidence trick” in the same sense as Theranos.
• Several commenters stress the article is about marketing narratives and fear-based “P(doom)” messaging, not about raw technical capability.

Productivity and real-world impact

• Individual engineers report dramatic productivity gains (claiming up to “10x”), especially on boilerplate, refactors, and busywork.
• Contrasting evidence: some companies see measured productivity decreases despite self-reported increases, with harder reviews, more complex code, and skill atrophy.
• Concerns about hallucinations, lack of online learning, and long-horizon/agentic weaknesses suggest current LLMs may hit a wall; others see no clear “wall” yet.

Social, economic, and cultural costs

• Worries about environmental impact, hardware scarcity, harassment via deepfakes/CSAM, and displacement of artists and junior engineers.
• Gaming community cited as particularly hostile to visible generative content, though some say backlash is from a loud minority and AI is already widely used under the hood.
• Debate over whether society should “vote with wallets” or make collective political choices about acceptable uses and labor displacement.

Overall impressions & experience

• Many commenters find Gleam attractive: simple, well‑designed FP, strong static types, ADTs, Result/Option, pattern matching, immutability, and a good LSP.
• Some report substantial joy using it (sometimes after burnout or frustration with other languages); others bounce off the “invented rules” and FP style, preferring more mainstream languages.

Serialization and boilerplate

• A key pain point is lack of built‑in or standard derive‑style serialization (especially JSON); users dislike hand‑writing encoders/decoders for many types.
• There are mentions of codegen tools, but no consensus “good” library, especially for discriminated unions.
• This ties into the lack of macros and ad‑hoc polymorphism, which makes ergonomic, generic serialization libraries harder.

Types, distributed systems, and Gleam’s stance

• Long subthread debates whether HM‑style type systems lose value in distributed/networked contexts with partial failure and uncertainty.
• One side argues static types devolve into “everything is Optional,” becoming dynamic typing with extra ceremony.
• Others counter that types help define invariants, localize uncertainty at boundaries (e.g. deserialization), and allow compilers to enforce checks.
• Gleam is noted as explicitly not trying to make distributed message passing fully type‑safe; it treats external messages as dynamic data to handle at the boundary.

Polymorphism, macros, and ecosystem / interop

• From an Elixir perspective, lack of ad‑hoc polymorphism and macros is a blocker for some (e.g. JSON, filesystem, logging).
• Others see the absence as beneficial, reducing “magic” and indirection.
• Debate over ecosystem access: technically Gleam can call any BEAM function, but you must write @external bindings with type signatures; some see this as friction versus Elixir’s seamless interop.

Targets: BEAM and JS

• Some worry dual targets dilute focus; others like sharing code between server (BEAM) and client (JS).
• Differences in semantics (e.g. Int as arbitrary precision on BEAM vs JS number, recursion limits) mean most projects pick one target in practice.

Tooling, debugging, and REPL

• No native REPL yet; users approximate with “dev modules,” gleam run, the echo keyword, and Erlang shell tools.
• Some miss REPL‑driven Elixir/Erlang workflows; others find existing debugging options acceptable.

Performance and role vs Go/Erlang

• Runtime performance is essentially BEAM performance: slower than Go in raw throughput but strong for highly concurrent, I/O‑heavy workloads.
• Some question why to choose Gleam over Elixir for BEAM work; others emphasize type safety and ergonomics as the differentiator.

Community and politics

• Several comments note a visible political/values stance in the project/community.
• Some see this as positive (clear norms, excluding abusive behavior); others see it as a red flag or potential for echo‑chamber dynamics.

Understanding ADHD vs. “Founder Brain”

• Several people urge getting a formal diagnosis; self‑diagnosis is seen as unreliable and overlapping with other conditions (e.g. bipolar, autism, APD).
• One commenter notes there is no “late‑developing ADHD” in medical criteria; symptoms must exist in childhood, though adult diagnosis is common when environments change.
• Others argue OP’s description could just be high curiosity / internet‑shaped attention rather than ADHD.
• Some push back on romanticizing ADHD as a “founder superpower”; emphasize it’s a disorder that can seriously damage life and relationships.

Medication: Strong Support, Some Skepticism

• Many describe stimulants (Adderall/Vyvanse/lisdexamfetamine, methylphenidate/Concerta, atomoxetine) as life‑changing, making thoughts manageable and enabling tools/systems to finally work.
• Others note meds help but are not a cure; maybe remove 25–50% of the difficulty.
• Some are wary of amphetamines’ long‑term effects or side effects and prefer non‑stimulant meds, supplements, or caffeine.
• A minority strongly discourage amphetamines and prefer “safer” options (ginseng, diet changes), or simply avoid meds altogether.
• Practical caveat: ADHD meds/diagnosis can complicate becoming a pilot or joining the military.

Brain Mechanics, Sleep, and Meditation

• One detailed comment explains ADHD as poor regulation of the Default Mode Network (intrusive mind‑wandering during tasks).
• Focused‑attention meditation is framed as “reps” training the DMN/task‑positive toggle.
• Sleep is repeatedly called foundational; ADHD symptoms worsen sharply with poor sleep.
• Exercise (running, lifting, cardio, walking) is widely endorsed for mood, clarity, and focus.

Systems, Tools, and Environment

• Strong theme: externalize everything—ideas, todos, commitments—so the brain can let go.
  • Methods: text files, journals, GTD, org‑mode, Todoist, Notion, simple wikis, sticky notes.
  • Key properties: ubiquity, simplicity, quick capture, trusted review (daily/weekly).
• Many emphasize environmental design: minimal visual/technical clutter, specific “work only” spaces, stable routines, time‑boxed blocks for key tasks.
• Some prefer strict reduction of tabs and inputs; others lean into fast context‑switching but build powerful search/navigation workflows.

Managing the Idea Firehose

• Common pattern: write down every idea, then later triage into: do now, project, habit, someday/maybe, or discard.
• Scheduling “side‑quest time” or creative blocks helps satisfy novelty cravings without derailing core work.
• Reframing thoughts as “arisings, not commands” reduces the compulsion to act on every micro‑idea.

Switching Off and Rest

• Many struggle to “switch off”; brains keep running even off the clock.
• Strategies: physical hobbies (running, biking, skating, knitting, games), nature walks, music, noise‑canceling headphones, app blockers.
• Some use weed or alcohol; others warn it can backfire or become self‑medication.

Acceptance, Context, and Partnerships

• Several embrace ADHD as double‑edged: intrusive noise plus genuine creativity and entrepreneurship.
• Success often comes from pairing with people who are strong at execution/maintenance.
• Theme of acceptance: you will never become “neurotypical,” but with meds, systems, sleep, movement, and good partners, you can function well and even thrive.

Business Incentives vs Code Quality

• Several argue that, in practice, companies reward “slop” that ships features and survives QA more than careful craftsmanship.
• Others counter this isn’t universal: some firms with plenty of cash still produce bad code because internal incentives reward velocity, not quality.
• There’s concern that LLMs supercharge this “feature pusher” culture, especially where management measures output by PR count rather than long‑term reliability.

What LLMs Do Well (According to Supporters)

• Rough drafts, boilerplate, CRUD UIs, simple scripts, glue code, and tests.
• Working in unfamiliar stacks or languages, where they can outperform a human novice.
• Search/“digital clerk” tasks: reading docs, comparing options, summarizing specs, rummaging through repos.
• Routine changes in a familiar stack when guided by a skilled engineer and good prompts, sometimes via agentic tools tightly integrated with the codebase.

Where LLMs Fall Short

• Tendency to add unnecessary logic, verbosity, and accidental complexity; mismatch with domain invariants; failure to reuse existing abstractions.
• Poor reliability in novel or intricate domains (custom build rules, concurrency benchmarks, binary formats, hardware interfaces).
• Need for heavy babysitting for small, precise changes; difficulty sticking to specific protocols or formats.
• Inconsistent outputs, even for similar prompts; context window and toolchain quality heavily affect results.

LLM Code as Technical Debt

• Many describe LLM output as “future digital asbestos”: fast to generate, expensive to live with.
• All code is debt, but LLMs can create much more, much faster; some report LLM‑authored sections as the worst debt they maintain.
• Others argue that with solid specs and tests, regenerability can offset debt, especially if LLMs help write and refactor tests too.

Skill, “Average” Output, and Who Benefits

• Common view: models reproduce something like the average of their training data; below‑average devs gain most, strong devs gain less.
• Some claim frontier models are already “above average” compared to typical industry code; others insist “LLM code is always bad” or at best student‑level.
• Disagreement over corpus quality (elite OSS vs lots of amateur/student code) and whether prompting can reliably pull from the “good” tail.

Evangelism, Insecurity, and Culture War

• Skeptics describe a pattern: maximalists insist LLM coding is the future, imply refusers are fearful, lazy “non‑hackers,” or will be “left behind,” and push mandatory adoption via management.
• Others note the article mirrors this by psychologizing evangelists as insecure or mediocre coders—seen as the same move from the opposite side.
• Multiple comments frame this as another instance of tech tribalism (like language/framework wars, crypto, self‑driving cars).

Learning, Careers, and the Future

• Worry that ubiquitous LLMs will produce generations of “vibe coders” who never learn fundamentals or understand systems they “build.”
• Some see LLMs as just another tool (like Python vs C, or 3D printers), with real but bounded impact; others think the trajectory (recent model jumps, agentic systems) points to major economic displacement within ~5–10 years.
• Calls to move away from abstract psychoanalysis and instead share concrete workflows, domains where they help or fail, and measurable outcomes.

Scope of the Proposal (Open Source at EOL vs. Just Interfaces)

• Several commenters note the article mostly calls for publishing hardware specs, protocols, and basic firmware/SDK, not full codebases.
• Some argue that for simple devices (e.g., scales) this is enough; for complex ones (routers, SoCs) it isn’t.
• Others say reverse-engineering can already recover many specs; the real value is removing legal/technical barriers to alternative firmware.

Secure Boot, Signing Keys, and “Fail Open” Designs

• Strong debate over whether EOL should trigger release of signing keys.
• One side: forcing key release would create botnet risk and let attackers hijack OTA update channels.
• Counterpoint: embedded security is already “an unmitigated disaster,” and inability to fix EOL bugs due to locked boot chains is worse.
• Proposed compromise:
  • Multiple-key architectures (ROM → 2nd-stage bootloader → app) where an EOL update can unlock the 2nd stage.
  • Physical or explicit user actions (buttons, magnets, sequences) to enter “unlock” mode.
  • Laws requiring designs to allow post-EOL user control.
• Some call for outlawing permanently locked bootloaders; others stress security models that depend on locking but want reversible unlock.

Regulation vs. Market / Consumer Responsibility

• Many want EU-style regulation: mandatory unlock at EOL, open APIs, or liability/refund if core functionality is killed.
• Skeptics doubt enforcement against large tech firms and foresee loopholes (e.g., redefining “main function”).
• Another camp says consumers should refuse cloud-tethered/closed devices and “vote with their wallets,” though others call this unrealistic at scale.

Cloud Dependence, E-Waste, and Examples

• Multiple examples of good hardware rendered useless when backends died (frames, thermostats, speakers, cameras).
• Some point to successful community rescues (e.g., alternative firmware and self-hosted backends) as proof of demand.
• General agreement that dependence on vendor servers for basic local functions is a major e‑waste driver.

IP, Cost, and Practical Constraints

• Commenters note:
  • Commercial products often share codebases across generations; open-sourcing one can reveal active IP.
  • Third-party licensed components can’t legally be open-sourced.
  • Cleaning a codebase for release can be expensive (months, six-figure costs).
• Hence suggestions to:
  • Require only open APIs and freedom to run alternative software.
  • Design around open standards (e.g., local protocols, non-cloud basics) from the outset.

Broader Ideas: Copyright, Games, and Archival

• Some advocate short software copyright terms and mandatory source escrow so old software and games enter the public domain in usable form.
• Others highlight the practical difficulty of preserving old code and toolchains for decades, questioning the value of such laws without strong incentives.