Hacker News, Distilled

Announcement clarity & onboarding

• Several commenters found the release page unclear about what COSMIC is, suggesting clearer linking, screenshots, key features, and context.
• Some Pop!_OS users were unsure how to try COSMIC without reinstalling; replies mention using the alpha ISO live-boot or installing the COSMIC packages and switching sessions.

Design goals vs GNOME/KDE

• Many see COSMIC as a GNOME-like but independent DE: similar layout for familiarity, but with different goals (tiling, customizability, less “baggage”).
• System76’s split from GNOME is attributed to constant extension breakage, diverging design goals, and maintenance burden; building their own stack is seen as a way to move faster.
• Opinions diverge on KDE parity: some think matching KDE’s feature set will take years; others hope COSMIC stays smaller, more opinionated, and tiling-focused.

Technology stack (Rust, Iced, libcosmic)

• Strong interest in COSMIC’s use of Rust, Iced, libcosmic, and the Smithay compositor stack.
• Iced is praised for ergonomics, MVU architecture, low memory usage, and themeability, though it’s explicitly “experimental.”
• Debate over using an immature UI toolkit for a DE: critics cite missing accessibility, text editing niceties, and system integration; supporters point to rapid progress and good fundamentals.
• Comparisons are made with other Rust UI frameworks (GPUI, Vizia, Slint); Iced is generally seen as more mature.

Theming, tiling & extensibility

• Tiling is a major selling point; several users say COSMIC’s tiling is already better than KDE’s, especially on ultrawide/multi-monitor setups.
• Current theming is limited (colors, padding, border radius); some want richer, non-flat customization.
• Plugin architecture is a key differentiator: plugins run as separate processes communicating via Wayland, intended to be more stable than GNOME’s in-process JS extensions. API stability is not promised yet (alpha).

Alpha quality & usability

• Experiences vary: some daily-drive it on Fedora/Arch/Gentoo with only minor bugs; others hit severe breakage requiring reinstall and note many missing settings vs Pop!_OS’s GNOME.
• Specific complaints: DPMS/power management not done, fractional scaling issues for Electron/X11 apps, lack of stable workspaces, large title bars, limited cursor/theming options, missing applets/pagers.
• Positive notes: fast, lightweight, feels cohesive, sane Super-key-based shortcuts, good multi-monitor behavior and per-monitor workspaces.

Privacy & external services

• A network request to googleapis.com on startup alarms some users; others speculate it may come from online accounts or captive-portal checks.
• Broad agreement that such calls should be opt-in and ideally use self-hosted or non-Google services.

Distro support & release timing

• COSMIC already runs on multiple distros (Pop!_OS alpha, Fedora via COPR, Arch, Gentoo, openSUSE Tumbleweed), generally with good performance.
• Some frustration that Pop!_OS is still on 22.04; the COSMIC alpha is also effectively a Pop!_OS 24.04 alpha, with a full stable release expected later (timeline seen as optimistic by some).

Business strategy & hardware

• Debate over whether System76 should prioritize hardware quality vs building a DE.
• Some report disappointing laptop hardware experiences; others praise their desktops or newer models.
• A subset explicitly say COSMIC makes them more likely to buy System76 hardware, seeing integrated hardware+software as a differentiator.

Scope of the problem & netcode limits

• Servers already “distrust” clients for core rules (damage, movement bounds), but can’t do everything server-side without making fast games unplayably laggy.
• For smooth play, clients must predict and interpolate future positions and keep some “extra” state (e.g., players about to appear from behind walls), which inherently leaks information exploitable by cheats.
• Proposals like sending multiple “fake” character paths are criticized as too expensive, hard to synchronize with latency/rollback, and ultimately still needing to reveal the true state.

Types of cheats and why they’re hard to stop

• Memory-based cheats (aimbots, wallhacks, HUD overlays) can often be fought with client scanning + server validation, but developers note the focus has shifted.
• Increasingly common are:
  • Input-manipulation devices (recoil macros, controller spoofers).
  • External “screen bots” using computer vision on video output (HDMI grabbers, separate machines).
  • Hardware-level attacks (PCIe/DMA).
• These don’t need to touch game memory and can look like “perfect but legal” player input, making detection via rules very hard.

Client-side anti-cheat: effectiveness vs. intrusion

• Some argue anti-cheat is “snake oil” or primarily PR, since cheats still feel rampant in popular FPS titles; they report bans for benign tools, crashes, or disconnections.
• Others (including developers) frame anti-cheat as defense-in-depth: no silver bullet but significantly raising the bar for cheap, mass-market cheats and making many lobbies playable.
• Kernel-level systems are defended as empirically effective but criticized as rootkit-like, privacy-invasive, fragile (e.g., CrowdStrike-style failures), and harmful to the idea of user-controlled computers.

Linux, Steam Deck, and platform issues

• The linked site tracks which anti-cheats work on Linux/Steam Deck; users complain when studios or vendors refuse to enable Linux support despite technical feasibility.
• Some worry Linux support might ease cheating, but others note the Linux cheater market is tiny and rarely worth targeting.
• A segment of users refuses to run invasive anti-cheat on their main OS, using separate hardware or Windows VMs instead.

Server-side statistics & AI detection

• Many suggest statistical/ML methods: monitor headshot rate, reaction time, movement patterns, long-term performance.
• Counterpoints: top players and smurfs are genuine outliers; naive stats will ban pros; sophisticated systems are costly and mostly used where money is at stake (e.g., gambling).
• Historical examples (Battlefield’s FairFight, ML systems in other games) show stats help but eventually get supplemented by traditional or kernel-level anti-cheat.

Social and ethical dimensions

• Some see cheating as fundamentally a social problem requiring stigma, stronger account identity, and possibly legal action against cheat sellers.
• Others see invasive anti-cheat as a civil-liberties and general-purpose-computing issue, arguing that modest fairness gains for online games don’t justify deep OS-level surveillance.

Unclear facts and French legal context

• Commenters stress that only the formal charges are public; underlying evidence is secret under French criminal procedure.
• Some urge restraint until the initial custody period and judicial statements are over; others see the arrest itself as already a warning signal.
• There is confusion about timing of warrants and investigations, with media reports apparently contradicting each other.
• Debate over whether the judiciary is sufficiently independent from the executive; some see normal legal process, others see possible political motives.

Platform liability vs product design

• A major thread: Telegram is unlike Signal/WhatsApp because most chats are not end‑to‑end encrypted.
• By retaining access to content, Telegram is argued to have made itself capable of assisting investigations, and thus legally exposed when it refuses.
• Others note that true E2E design also protects operators from torture/coercion but raises other usability and scaling issues.

Encryption, “plaintext,” and cooperation

• Long argument over whether Telegram stores messages in “plaintext” or just non‑E2E “cloud” encryption.
• One side: if the service can decrypt or impersonate users, it is “effectively plaintext” and must be treated as accessible to staff and law enforcement.
• The other side: Telegram’s MTProto 2.0 protocol encrypts data at rest; calling it plaintext is incorrect, though it is not E2E.
• There is disagreement over how much Telegram cooperates with lawful requests compared to other platforms; some say it “voluntarily doesn’t comply at all,” others cite policy language and takedowns as partial cooperation.

Criminal use of Telegram

• Multiple comments describe widespread use in Europe and parts of Asia for drugs, prostitution, and worse, with “Find people nearby” cited as a visible abuse vector.
• Others counter that many of these accounts are scammers or bots, not real local dealers, and that similar issues exist on email, Tor, and other apps.
• Some see an inevitable “line” where scale of criminal activity forces a crackdown.

Geopolitics and Russia angle

• Several speculate that Telegram’s heavy use by Russian military, intelligence, mercenaries, and also by Ukrainian actors makes this partly about war, not just crime.
• Others point to reports of frequent travel to Russia and past blocks/unblocks as signs of possible ties to Russian services, but this remains conjectural in the thread.

EU vs US regulation and tech companies

• Discussion contrasts EU laws (DSA, national speech and crypto rules, aiding‑and‑abetting concepts) with broad US safe harbors (Section 230).
• Some argue the case shows Europe becoming authoritarian and hostile to foreign platforms; advice is floated for US-based services to avoid operating in Europe.
• Others reply that EU rules still exempt passive hosts if they act reasonably on illegal content; what’s at issue is alleged refusal to respond to lawful orders, not generic speech.

Broader concerns about encryption control

• Comments highlight a French charge about “importing cryptology” without declaration as disturbing for anyone shipping encryption tools (e.g., disk encryption).
• Several see a familiar “four horsemen” pattern: terrorism and child abuse invoked to justify expanding surveillance and weakening privacy.
• There is worry about reciprocal actions by non‑Western states against Western tech CEOs if this becomes precedent.

Mucosal / Intranasal Vaccines

• Commenters note existing intranasal vaccines (e.g., flu, some canine respiratory vaccines) and emphasize “mucosal immunity”: targeting the nasal and respiratory mucosa where SARS‑CoV‑2 enters.
• Several explain that systemic “jabs” protect against severe disease but don’t robustly immunize mucosal compartments, so infection and transmission can still occur.
• Intranasal vaccines are seen as promising for blocking infection at the point of entry and thus reducing spread and variant generation, if claims hold up.

Claims About This Candidate

• Thread highlights: broad antigen coverage (all major SARS‑CoV‑2 proteins, not just spike), claimed prevention of infection and transmission, and stability at 4°C for months, making it attractive for low‑ and middle‑income countries.
• Some view the cold‑chain requirement as its best feature; others argue very cold storage (dry ice / frozen) can be simpler for logistics.

Safety, Testing, and Live Attenuated Concerns

• Several stress that anything delivered intranasally must be tested “really well” due to proximity to the brain, citing drugs and pathogens that reach the CNS via nasal routes.
• Others ask why intranasal delivery should be considered riskier than natural infection, but agree thorough testing is needed.
• There is concern about live‑attenuated vaccines potentially reverting to virulence, referencing the oral polio vaccine.

Development, Regulation, and Access

• People recall that multiple intranasal COVID candidates stalled at the stage between promising data and large, expensive trials, often needing acquisition/funding to proceed.
• Some discuss the idea of synchronized mass vaccination to snuff out the virus, but doubt the feasibility of immunizing an entire population at once.

COVID’s Ongoing Relevance

• One commenter questions whether COVID is still a serious issue given apparently low daily case and death counts.
• Others push back, pointing to long COVID’s large burden and economic cost, and note that SARS‑CoV‑2 is not purely seasonal, with “summer waves” driven by new variants.

Public Trust, mRNA Skepticism, and Communication

• Multiple comments describe distrust of authorities over early messaging that vaccines would “stop spread,” later walk‑backs, and perceived censorship of dissenting or nuanced views.
• Some differentiate skepticism of mRNA COVID vaccines from general anti‑vaccine ideology; others argue misinformation and politicization are the main problem.
• Debate emerges over individual vs. collective risk, the ethics of shaming holdouts, and whether heavy‑handed moderation of “misinformation” increased skepticism.

What the system actually does

• Trains a Stable Diffusion 1.4–based model on ~900M–1B Doom frames plus recorded actions.
• At inference, predicts the next frame conditioned on a short history of previous frames (with noise added) and player actions.
• Noise during training is said to be critical to reduce “auto-regressive drift” and enforce temporal consistency.
• Several commenters stress: the diffusion model itself is stateless; any apparent memory comes from conditioning on recent frames and inputs.

Interactivity and evaluation (contested)

• The project page and some parts of the paper say humans can play at ~20 FPS and that videos are “real-time recordings of people playing”.
• Others read the paper as primarily training on RL agents and only evaluating via short, non-interactive clips shown to raters.
• Overall: community consensus is that interactive play is intended and probably exists, but the paper’s description of human gameplay is seen as unclear or underspecified.

Limitations and artifacts

• No explicit global world state: enemies respawn or shift, objects appear/disappear, ammo/health counters fluctuate, geometry “swims” or changes when revisited.
• Backtracking often reveals major inconsistencies (walls move, pickups change), likened to dreams or hallucinations.
• Model appears overfit to particular maps and bot-like movement; unusual player behavior may cause rapid breakdown.
• Counting and rule-consistency (e.g., damage ticks in slime, shots-to-kill) are unreliable.

Is this really a “game engine”?

• Many argue it’s more like:
  • “The world’s least efficient video codec.”
  • A dreamlike Doom emulator / interactive video, not a reusable engine.
• Key critique: a game engine should:
  • Work on new content, not only mimic a specific game.
  • Expose and control rules, state, and assets; this model only maps [recent pixels + inputs] → pixels.
• Others counter that if it can drive interactive play, it qualifies functionally as an engine, just learned rather than coded.

Compute, compression, and prior art

• Strong contrast drawn between Doom’s tiny original requirements and multi‑GB diffusion models on a TPU.
• Commenters note huge redundancy: the model could trivially “store” the game many times over, so it’s more an inefficient learned replica than true compression.
• Related earlier work like GameGAN is mentioned; this diffusion-based approach is seen as a more powerful but still narrow evolution.

Speculation and future directions

• Ideas floated:
  • Use diffusion only as a renderer over a simple low‑poly or physics engine.
  • Train on many games or real‑world video to generate new game styles.
  • Apply similar predictive models to robotics, UI/OS rendering, or cloud gaming client-side prediction.
• Several people connect this to predictive-coding theories of the brain and human dreaming.

Amazon marketplace reliability & counterfeits

• Many comments generalize from this ink case to Amazon’s broader quality issues.
• Some report years of trouble‑free purchases (especially when buying from brand stores or non‑US Amazon sites).
• Others say counterfeits are common but often “good enough” (e.g., ghost‑shift items from the real factories), so issues may go unnoticed.
• Inventory commingling is a recurring concern: buying “Fulfilled by Amazon” doesn’t guarantee origin; returns and fakes can mix with genuine stock.
• Some avoid Amazon for anything ingested or plugged into mains power; others cite bad experiences with chargers and counterfeit consumables.

Platform incentives and accountability

• Several argue Amazon shifted from B2C (prioritizing customer experience) to a B2B platform (prioritizing seller volume), driving “enshittification.”
• Quality‑focused sellers are said to have left the platform; suggestions include moving to independent sites, eBay, or Shopify-backed stores.
• Reporting counterfeits is described as difficult; UI channels map issues to “item not as described,” which may obscure systemic problems.
• Some view Amazon’s structure (marketplace sellers, logistics contractors) as a deliberate shield against liability, with regulators only slowly catching up.

Tattoo health risks & regulation

• Multiple commenters highlight infection, heavy metal exposure, and possible cancer risks (e.g., lymphoma) from tattoo ink, especially contaminated or poorly characterized products.
• Others note legitimate medical uses (radiation targeting fiducials, reconstructive surgery).
• There’s support for tighter regulation or at least formal certification of ink purity, though some doubt this helps if Amazon’s commingling persists.
• One person wonders if older, fully healed tattoos are “in the clear”; the thread does not provide a clear answer.

Cultural attitudes toward tattoos

• Strongly divergent views: some see tattoos as a sign of low impulse control and poor decision‑making; others call this narrow‑minded and prejudicial.
• Several describe tattoos as carefully planned, costly, and meaningful, often with mental‑health benefits or restorative value (e.g., for visible skin conditions or memorials).
• Debate touches on workplace bias, conformity pressure, and whether visible tattoos harm job prospects in high‑paid roles.

Sources of Extreme Wealth

• Several posts question how the top 1% amassed such gains: compounding returns on capital, especially once a net-worth threshold is crossed, make it much easier for the already-rich to get richer.
• Cited drivers: lower top tax rates over decades, property and asset price inflation, monopolies/oligopolies and regulatory “moats,” globalization, tech/oil fortunes, and historically slavery and land theft.
• Some note much of this “wealth” is unrealized asset appreciation and financialized gains rather than cash.

Arguments for Higher Taxes on the Rich

• Extreme wealth is framed as a threat to democracy, tilting societies toward oligarchy and giving unelected billionaires disproportionate political power.
• Advocates argue higher top rates worked historically and that billionaires should effectively be “taxed out of existence” or hard‑capped, while still living comfortably as millionaires.
• Many want the ultra‑rich to at least pay the same effective rates as professionals paying high marginal taxes, by closing loopholes and taxing income from capital more like labor.
• Some high earners in the thread explicitly say they would accept much higher taxes if they clearly funded universal healthcare, housing, food, and education.

Arguments Against or Concerns

• Opponents argue taxes are already too high, government is an inefficient or corrupt allocator (wars, megaproject overruns), and higher rates would discourage investment, entrepreneurship, and job creation.
• Capital flight and international tax competition are seen as major practical blockers; without global coordination, wealth may simply move.
• Some worry about “slippery slope” expansion of new taxes down to the middle class, citing the history of income tax.
• Others stress that poverty reduction and absolute living standards matter more than reducing inequality per se.

Mechanisms and Policy Ideas

• Proposals: wealth taxes (e.g., ~8% on ultra‑wealthy), higher top income brackets, taxing at the source of wealth so people can’t avoid taxes by moving, restricting benefits to tax‑avoiders, and breaking up monopolies instead of (or in addition to) taxing more.
• Debates over taxing unrealized gains:
  • Critics say it’s unfair/unpayable; point to huge paper gains vs limited cash.
  • Supporters note property taxes already hit unrealized gains; suggest instead taxing when people borrow against assets or limiting borrowing to cost basis.
• VAT is discussed as a tool that can be made somewhat progressive by rate‑differentiation, but also criticized as regressive and loophole‑prone.

Government vs Private Solutions

• One side emphasizes public goods and market failures (healthcare, transit, housing) and sees taxation as necessary to fund them.
• The other side prefers smaller government, private charity, and local initiatives, arguing individual action and limited state power better serve long‑term freedom and prosperity.

Boeing’s Corporate and Cultural Problems

• Many see Starliner as symptomatic of broader Boeing issues: financialization, cost-cutting, outsourcing, weak quality control, and a degraded engineering culture (often linked to the McDonnell Douglas merger).
• Criticism that MBAs and short‑term shareholder focus “extracted” value, leaving a hollowed‑out company.
• Some argue the problems are systemic across U.S. industry (Ford, GM, tech), not just Boeing.

Government Role, National Security, and Possible Remedies

• Boeing is viewed as “too strategic/connected to fail” due to exports and defense work.
• Proposals range from:
  • Breaking up Boeing’s business units.
  • Nationalization or using Defense Production Act / war powers to seize or control assets.
  • Forcing Chapter 11 to wipe out shareholders/execs while preserving operations.
• Others call these ideas unrealistic or legally/politically untenable in peacetime.

Starliner Program Status and Contract Structure

• NASA decided not to bring astronauts back on Starliner; they will return on a Crew Dragon flight months later.
• Starliner is on a fixed‑price contract; Boeing is reportedly deeply underwater financially.
• Debate over whether Boeing can or should walk away vs being compelled to perform; some expect a negotiated exit.
• One commenter notes NASA’s Inspector General cited high numbers of quality Corrective Action Requests and insufficient trained workers on related Boeing programs.

SpaceX Comparisons and Monopolies

• Frequent comparison: SpaceX delivered crew transport earlier, at lower contract price, with multiple successful flights.
• Counterpoints:
  • SpaceX’s internal costs and profitability are largely unknown.
  • Some claim SpaceX might be subsidizing launches to gain dominance (“Amazon playbook”); others argue audits and ongoing spending imply real operating profits.
• Concern about a de facto SpaceX monopoly; some see a short‑term monopoly as acceptable with ISS ending in a few years, others call it dangerous and argue for multiple providers or more in‑house NASA work.
• Alternative or future competitors mentioned: Orion, Dream Chaser, Blue Origin.

NASA, Safety, and Astronauts’ Situation

• Most agree NASA’s choice to avoid flying crew home on Starliner is prudent.
• Astronauts’ extended ISS stay is framed as a normal, safe mission extension, not a “stranding.”

Broader Reflections

• Discussion of whether Boeing can reform its culture vs needing new entrants.
• Mixed views on privatization: some praise commercial innovation; others see capture, waste, and “jobs programs” like SLS as evidence of structural issues.

Article & benchmark context

• Thread revisits a 2021 optimization deep-dive on text CRDTs; many readers still find it unusually entertaining and clear despite technical depth.
• Original working title “CRDTs go brrr” is remembered fondly; some want the date visible because it affects how to read perf numbers.
• Several prior HN discussions of the same piece are linked; people now want updated benchmarks, especially against Rust implementations of Automerge and Yjs (Yrs).
• The author notes both major libraries and newer algorithms have since become significantly faster.

Why CRDTs were “slow” and performance details

• One explanation: early libraries were largely written by academics, with correctness prioritized over optimization.
• Since then, CRDT implementations have improved by orders of magnitude; some newer projects claim another large speedup since the article.
• A side discussion explores why a Rust-to-WASM build ran ~4x slower than native: FFI overhead was controlled for; the slowdown seemed to be raw codegen/runtime. Participants speculate about loss of high-level intent, weaker instruction sets, and optimization limits in current WASM JITs.
• Microbenchmark details like ideal bucket size (32 entries) are tied to cache-line and memory hierarchy effects.

Real-world use cases and UX quality

• Many apps are cited as CRDT-based or CRDT-like: design tools, reference managers, local-first workspaces, notes/todo apps, collaborative text/graph tools, and iCloud Notes.
• Experiences vary: some tools feel “Google Docs–smooth,” others (e.g., certain Notion workflows, Apple Notes in specific cases) show cursor glitches or lag under concurrent editing.
• A recurring theme: CRDTs shine in local-first, creative workflows (writing, design, coding) where offline edits are valuable; they’re seen as less compelling for fast-authoritative domains like real-time games.

Git, blockchains, and definition debates

• A large subthread debates whether Git or blockchains are “pragmatic CRDTs.”
• One side: they behave like widely used, conflict-resolving replicated data structures; for practical discussions, grouping them with CRDTs helps intuition.
• The other side: by the formal definition, they fail key properties:
  • Git: manual merge conflicts, non-idempotent/ordering-dependent merges, and different peers can converge to different histories.
  • Blockchains: cannot be updated independently without coordination; convergence relies on consensus, not purely on CRDT-style merge laws.
• Several argue stretching the term “CRDT” to cover these systems confuses newcomers; better to reserve it for structures whose merge is associative, commutative, and idempotent.

History size, privacy, and truncation

• Concern: CRDTs leaving long operation logs.
• Replies: for text, overhead can be extremely small; with compression, full histories may be smaller than final document state.
• Some libraries discard deleted text content while keeping structural metadata, which helps with privacy.
• Truncating history in decentralized settings is tricky: without careful snapshotting/consensus, peers that only saw partial histories can become irreconcilable.
• For immutable, content-addressed designs, redaction (e.g., GDPR) may require repacking history and breaking signature chains; partitioning data into smaller, per-resource histories is suggested.

Economics & Motivations for Cheats

• Several commenters say making cheats/bots can be lucrative: build once, sell many times, often as subscriptions.
• Cheats are framed by some as “automation” and technical challenge, more like solving a puzzle than “pwning noobs.”
• Others mention hacks to bypass in‑game monetization or grind (gold farming, circumventing recurring payments), seeing it as resistance to exploitative design.

Ethics and Player Experience

• Strong disagreement over morality:
  • One side sees multiplayer cheating as griefing that wastes others’ limited free time and ruins communities.
  • Another side is more blasé, viewing cheating as inevitable boundary‑pushing and blaming poor game design.
• Comparisons to steroids and pro sports arise; some argue clear bans are justified, others question whether those norms should apply to casual gaming.
• Accessibility edge cases (e.g., aiding players with physical limitations) are raised but not resolved; lines between “assistive tech” and “cheat” remain unclear.

Anti‑Cheat Approaches & Arms Race

• General consensus: it’s a cat‑and‑mouse game; anti‑cheat is harder than cheat development and never perfect.
• Many modern systems run in kernel mode or lower (drivers, DMA cards), including Riot’s Vanguard, which is praised as effective but criticized as invasive.
• Some insist client‑side anti‑cheat is fundamentally flawed; others argue a mix of server‑ and client‑side is necessary because the client’s representation of game data is part of gameplay.
• Hardware and AI cheats are highlighted:
  • DMA cards reading memory undetected.
  • AI aim assist via screen capture and controller manipulation, even off‑PC.
  • “Cheat” keyboards and macros (SOCD, rapid strafing) that automate human‑skill gaps; some games now ban specific devices.

Social, Design, and Systemic Responses

• Traditional social tools (vote‑kick/ban) are often subverted by bots or large coordinated groups and are seen as ineffective in modern, large‑scale or battle‑royale games.
• Ideas proposed:
  • Server‑side statistical/behavioral detection, similar to chess.com, with ban waves based on post‑game data.
  • A cross‑game reputation service, though others warn this resembles a “social credit” system with severe abuse and privacy risks.
  • Moving toward console‑like or “PC‑console” locked hardware with signed components to reduce cheating, at the cost of openness and upgradability.

Impact on Developers & Ecosystem

• Anti‑cheat can hinder legitimate debugging and GPU driver fixes, especially when tools are flagged as debuggers or unsigned/test drivers are blocked.
• Some report certain anti‑cheats (e.g., VAC) as weak against sophisticated cheats, leading to bot‑infested games; others see noticeable ban waves and partial effectiveness.

Overall reception

• Many commenters like the idea of a curated, health-checked list of free public APIs and bookmark it.
• The “tested daily” aspect is seen as the key differentiator from older lists where many APIs are dead or deprecated.
• Some think the list is cluttered with “joke” or trivial APIs; others find those fun or pedagogically useful.

Reliability and longevity of public APIs

• Several warn against relying on random public APIs in production or in books, citing APIs going offline or changing.
• Suggestions include:
  • Hosting your own example APIs on domains you control.
  • Using an API forwarder/proxy you control to decouple clients from upstream changes (with monitoring and optional transparent redirection), though some see this as adding another failure point.
• There is discussion about APIs being “just someone else’s computer” and the risks of opaque dependencies.

Joke / micro APIs and educational use

• The “is even” / “is prime” / “is fizzbuzz” style APIs spark a long thread:
  • Some view them as absurd “Parity as a Service.”
  • Others argue they are excellent for teaching API consumption due to simplicity and predictability.
• People quickly spin up complementary joke APIs and note humorous pricing/ads and intentional error messages.

Design, UX, and implementation feedback

• Initial inability to open API cards in new tabs and “no right click / middle click” are widely criticized; later reported as fixed.
• Some mobile users find the search layout confusing because results show below the fold under a “searching” heading.
• Reports of the site being slow from Asia raise questions about hosting/CDN and Nuxt implementation.
• Emojis unexpectedly replacing titles appear for some, unclear if bug or experiment.
• Health-score logic (reliability vs latency) is seen as under-explained.

API ecosystem, alternatives, and missing pieces

• Comparisons are made to older catalogs like ProgrammableWeb (now shut down) and the popular public-apis GitHub repo.
• Suggestions to include:
  • Music-related APIs from an external curated list.
  • WebSocket APIs (question raised whether they’re supported).
  • Specific APIs such as USPS address verification and stock-price APIs.
• Some argue many listed APIs could be static JSON files; static-site tools like Hugo are suggested for “read-only” APIs.
• There is a call for a public API or at least a syndication feed for the site itself; an API endpoint is later added.

Tools, business models, and sustainability

• Commenters note that keeping a free public API or a maintained list is hard with little incentive; ad-based monetization seems weak.
• Ideas include sponsorship as a public good and static hosting to minimize maintenance.
• People share APIs they actually pay for (e.g., logistics/tax, trading, cloud, payments) and recommend API clients like Insomnia and Bruno.

Extent of American Media Influence

• Many argue Canadians (and others) consume “unhealthy” amounts of U.S. news, often knowing more about U.S. politics than their own.
• Commenters note this is common globally: Europe, Latin America, the UK, and Australia are cited as importing U.S. news and culture wars.
• American politics is framed as entertainment: high drama, personalities, and horse-race coverage that crowds out substantive policy and local issues.

Effects on Canada’s Politics, Identity, and Culture

• Several see Canadian left and right “LARPing” U.S. Democrats/Republicans (e.g., convoy protests, gun policy, school-lunch-style programs).
• Some say Anglo-Canada feels culturally close to the U.S., especially along north–south regional lines, while others stress a distinct Canadian identity, more akin to Scandinavia in some respects.
• French–English divides and Quebec nationalism are highlighted as key reasons Canada hasn’t simply merged with the U.S.

Comparisons to Other Countries

• Non-English-speaking countries (France, Italy, Japan, China, India, Egypt) are suggested as less dominated by U.S. news.
• The UK and parts of Europe are said to import U.S. “culture war” frames (trans issues, “woke,” 15‑minute cities).
• Latin American and Colombian commenters report local debates increasingly echoing U.S. anti-communism and partisan narratives.

News Ecosystem & Local Journalism

• Multiple people lament the collapse of local and investigative journalism in Canada and the U.S., replaced by cheap syndicated or U.S.-centric content.
• Canadian media consolidation (including U.S. ownership) and government funding of certain outlets are criticized from different angles.
• Facebook’s blocking of Canadian news links (in response to the Online News Act) is seen as further weakening domestic visibility.

Health, Agency, and Overconsumption

• Several say all modern news consumption is unhealthy if passive and constant, regardless of country.
• Suggested remedies: focus on local politics, use multiple ideological sources (including foreign ones) and topic-specific research, and drastically reduce 24/7 outrage consumption.

US–Canada Power Dynamics

• Some describe Canada as a de facto U.S. vassal given trade, security, and geographic dependence; others push back, emphasizing real policy and social differences.
• Hypothetical U.S.–Canada annexation and historical war plans are discussed, with consensus that deep integration and brain drain exist, but also strong national attachments and practical obstacles.

Canadian Healthcare Tangent

• A long subthread debates Canada’s single-payer model: defenders like universal coverage; critics describe rationing, long waits, lack of family doctors, and bans on private alternatives.
• Others note there are different universal models (e.g., parallel private sectors elsewhere) and argue Canada’s current system is a degraded version of what it once was.

Nature of the “donation”

• Many see “donation” as “maintenance burden transfer” rather than a gift; “free as in puppies” is a recurring metaphor.
• It’s the old Mono repo in maintenance mode for years; Microsoft keeps an actively developed fork inside dotnet/runtime for its own needs.
• Several comments question whether there’s any financial endowment or meaningful tax write‑off; consensus is that any write‑off value is likely negligible.

Mono vs modern .NET

• Original Mono: C‑based reimplementation of the Windows-only .NET Framework, including app domains and desktop GUI stacks like WinForms and some WPF support.
• Modern .NET (formerly .NET Core): Microsoft’s official, cross‑platform runtime in dotnet/runtime, largely MIT/Apache licensed, high performance, and the recommended target for new development.
• There is also a Mono-derived runtime living inside dotnet/runtime/src/mono used for mobile and WebAssembly; it has diverged (e.g., removed multi‑AppDomain support).

Why Wine cares

• Wine wants to run legacy Windows apps targeting .NET Framework 1–4.x; Mono is the only realistic non‑Windows implementation for that.
• Wine has long maintained its own fork (wine-mono) and used it to implement Windows .NET in Wine without shipping Microsoft’s proprietary Framework.
• Transferring the “Mono” name and repo to Wine is seen as aligning stewardship with the main remaining use case: compatibility with old Windows .NET software.

Status and future of Mono

• Widely described as “on life support”: few commits, behind .NET Framework 4.8, no new feature work expected.
• Expected future: bug fixes and OS compatibility work so old .NET apps continue to run under Wine; no meaningful new APIs.
• Some niche users remain (e.g., embedded runtimes, game engines, Second Life), but many are migrating away.

Microsoft strategy and trust

• Some view this as pragmatic cleanup now that .NET itself is cross‑platform; Mono’s original goal has been effectively met by official .NET.
• Others frame it as a classic “embrace/extend/extinguish” arc around Xamarin/Mono tooling and mobile/desktop stacks (Xamarin.Forms → MAUI, VS for Mac, etc.), fueling skepticism about relying on Microsoft stacks long‑term.
• Several note Microsoft’s warmer stance toward Wine and open re‑implementations in general, citing prior legal acknowledgments and the business importance of Linux and cross‑platform .NET.

App Size and Technical Causes

• Main discovery: Oral-B iOS app ~300 MB; Colgate’s even larger. Much of Oral-B’s size is attributed to bundled PDFs and many large image assets for product models.
• Several commenters argue these images could be far smaller (hundreds of KB each, better formats like AVIF, vector graphics) or fetched on demand.
• Others say shipping assets locally avoids mandatory internet dependency and CDN costs, but even then call the packaging “lazy” or “unoptimized.”
• Comparison: Android version of Oral-B app is ~67 MB, suggesting platform/tooling and team differences.
• Broader point: many iOS apps are large due to Swift, third‑party libraries, and lack of aggressive dead‑code removal; Android’s modern app format is cited as more size‑efficient.

“Why Does a Toothbrush Need an App?”

• Skeptical view: apps exist primarily to collect data, enable marketing/upselling, and create another push‑notification/channel to the user.
• Some see it as emblematic of “late-stage tech” and IoT excess; a $2 manual or simple electric toothbrush is considered sufficient.
• Supportive view: apps can:
  • Track brushing duration, frequency, and pressure.
  • Provide quadrant/coverage guidance and pressure feedback.
  • Gamify brushing, especially for kids (animations, avatars, streaks).
  • Help habit‑formation for users who respond well to quantified feedback.

Privacy, Data, and Monetization Concerns

• Many worry about:
  • Health and device IDs being collected and correlated via data brokers.
  • Potential future ties to insurance pricing or targeted advertising.
  • Overbroad permissions (contacts, location, media) and dark patterns.
• Others note much of this tracking logic is small; the bloat is mostly assets and generic ad/analytics SDKs.

Design, Ethics, and Regulation

• Some argue a toothbrush app should not embed AI/ML models or require an app for core functions (e.g., changing modes).
• Proposed principle: if a feature can be done on‑device without an app, it should not require one.
• Debate on whether regulation/consumer‑protection should restrict “defective by design” products vs. letting the market reject them.

Developer and Industry Reflections

• Agency‑built brand apps are portrayed as driven by marketing whims, analytics, and library stacking, not efficiency.
• Observed correlation: organizations with better internal security/engineering culture tend to ship smaller, cleaner apps.
• Some developers admit their own apps have grown large due to piling on features, libraries, and media, even when core functionality is simple.

Paper for Simplicity and Focus

• Many commenters say they returned to paper after trying numerous apps; digital tools added friction, tinkering, and procrastination.
• Paper is favored for: short-term todos, daily/weekly lists, quick sketches/diagrams, and deep thinking.
• Index cards, small notebooks, “hipster PDA” stacks, and single daily sheets are common patterns. Limited space forces prioritization.
• The physical act of writing and crossing off items is described as satisfying, motivating, and clarity-inducing.

Limitations of Paper

• Major downsides: no search, no backups, poor for long-term reference or knowledge bases, difficult refactoring/restructuring.
• People who lose paper frequently or travel a lot see it as impractical.
• Handwriting issues (illegible, smudging, especially for left-handed writers) make digital tools preferable for some.

Arguments for Digital Tools

• Plain text (todo.txt, single markdown file, org-mode) appeals to those wanting simplicity and searchability, sync, history.
• Apps praised for specific roles:
  • Simple lists and capture: Google Keep, Apple Notes/Reminders, Tasks, Simplenote, Telegram chats, email-to-self.
  • More structured systems: Obsidian, org-roam, OneNote, Notion (controversial), GitHub Issues, task managers like Things/Todoist/Remember The Milk.
• Digital excels at: search, cross-device sync, sharing (e.g., shared shopping lists), reminders, journaling over years, and complex project tracking.

Hybrid Approaches

• Common pattern: paper for daily/weekly planning and transient notes; digital tools for archival, long-term tasks, and project documentation.
• Some use weekly/daily notes (on paper or in markdown/Obsidian/org) and “roll over” unfinished items, dropping stale ones.
• Several scan paper notes (phone camera, apps like Post-it, Freeform) to archive or process them later, sometimes with OCR or models.

Specialized Devices & Gear

• E-ink tablets (reMarkable, Supernote, BOOX, Daylight) and tablets with pens (iPad, Galaxy Tab) are seen as “paper-like” compromises: handwriting plus search, sync, and organization. Opinions vary on software quality.
• Pens, pencils, and fountain pens are a surprisingly passionate subtopic.

Meta: Psychology, Procrastination, and Privacy

• Many note that obsessing over tools is often procrastination or “magical thinking” about productivity.
• Some attribute the intensity of the topic to ADHD/autistic traits and stress.
• A minority explicitly prefer paper to keep ideas off cloud/AI systems and avoid corporate data mining.

Data sources and detection method

• Network uses >500 volunteer lightning receivers plus central servers.
• Each station records ~1 ms of VLF signal at >500 kHz, time‑stamped via GPS with microsecond precision and sent to servers.
• Strikes are located via time‑of‑arrival triangulation across stations; Wikipedia link on Blitzortung’s method is shared.
• VLF propagation in the Earth–ionosphere waveguide allows detection of storms thousands of kilometers away; range depends on direction (west→east) and night vs day.
• Users are impressed that sensors in Europe, US, New Zealand etc. can detect strikes across oceans.

Hardware, coverage, and openness

• Data comes from crowdsourced hardware; users can see nearby detectors on a separate map interface.
• Some say the detector program appears frozen or hard to join; others note a newly released detector but unclear how to obtain it.
• Multiple commenters report being on waitlists for many years and frustrated by limited availability and cost.
• Historic data is restricted to contributors; non‑contributors resort to scraping live data, arguing the data is under Creative Commons / database rights, but legal status is debated.
• Several criticize the model as “open‑but‑not‑really,” while still sympathizing with resource limits.

APIs and third‑party services

• Integration with Home Assistant exists; it proxies data via MQTT to respect Blitzortung’s rule that third‑party apps must not use their WebSocket directly.
• Some avoid building direct client libraries to honor this policy.
• lightningmaps.org and Windy are cited as alternative visualizations using the data; some feel lightningmaps.org has degraded recently.

Use cases and automations

• Common uses: tracking storms for hiking, golf, swimming pools, and general situational awareness.
• Home automation examples include:
  • Alerts and rules around showering or using the pool when lightning is approaching.
  • Automations that adjust lighting to current weather and announce laundry completion based on power sensing.
• Environment Canada and satellite systems (GOES lightning mapper) are mentioned; satellites are seen as less precise but complementary.

Randomness and extreme events

• People discuss using lightning as an entropy source. Some point to RANDOM.ORG’s atmospheric‑noise approach; others argue lightning timing/location is correlated (e.g., “sympathetic lightning”) and thus weaker entropy.
• A subthread speculates that the VLF network could, in principle, detect nuclear detonations due to strong EMP signatures, though this remains purely speculative in the discussion.

Safety, showers, and risk perception

• Large subthread on whether showering during thunderstorms is dangerous:
  • One side: lightning can enter via plumbing or wiring, especially in older or poorly grounded buildings; agencies warn against using showers and corded appliances during storms.
  • Other side: actual risk is argued to be extremely low compared with everyday hazards; some cite sparse case reports and worry this overemphasizes rare events (neglect of probability).
  • Differences in building codes and grounding across countries are noted; some authorities (e.g., UK) consider showers safe if equipotential bonding is up to standard.
• There is debate on whether time spent engineering elaborate “shower safe” indicators is better spent improving grounding or addressing more likely risks (e.g., slips and falls).
• Many participants ultimately treat avoiding showers during nearby lightning as a low‑cost precaution rather than a major source of fear.

Miscellaneous observations

• Users note constant global lightning activity and suggest 3D visualizations.
• Some mention related citizen‑science projects (e.g., Raspberry Shake for seismology).
• UX issues: a mobile user reports an almost opaque cookie banner blocking the page in some browsers.
• Minor curiosities discussed include the South America flag used on the site and the historical connection between lightning, spark‑gap transmitters, and the word for “radio” in some languages.

Typography & CSS Issues

• Several comments note that precise typography on the web is hard, citing missing or immature features like text-box-trim.
• Misalignment between headings/body text and a baseline grid is highlighted; some blame browser/CSS limitations, others say many problems stem from font metrics and font design.
• Safari is mentioned as having more advanced typography features earlier than other browsers.

Monospace Readability & Line Spacing

• Many enjoy the monospace aesthetic, especially for code, tables, box-drawing characters, and diagrams.
• However, multiple people say monospace is suboptimal for long-form reading: weaker word shapes, tighter rhythm, and more visual fatigue.
• Line-height on the page is widely criticized as too tight; increasing it improves readability but breaks the “fixed grid” concept and alignment of character graphics.
• Some argue that proportional sans-serif fonts (e.g., Arial/Verdana) are better for body text, referencing existing typography research; others say personal preference and familiarity may dominate.

Design Aesthetics vs Usability

• Strong positive reactions to the clean, terminal-like look; some call it “beautiful” and “refreshingly light.”
• Others see “terminal chic” as the wrong direction and prefer layouts inspired by books or magazines.
• Hard line breaks and rigid pre‑style layouts on other “retro” sites and RFCs are criticized for poor mobile usability.

Fonts, Performance & Implementation

• The site’s use of JetBrains Mono is praised visually but criticized for loading ~725KB of webfonts.
• Some advocate font-family: monospace and relying on system fonts; others object that this breaks visual consistency and branding.
• Suggestions include font subsetting via unicode-range, using alternative CDNs, or self-hosting fonts from services like Google Fonts.

Accessibility & User Control

• Users mention issues with high contrast (pure black/white) and “pattern glare,” especially with monospace grids.
• Some describe using browser settings or bookmarklets to override fonts and weights for better readability.
• Concern is raised that sites designed to depend on monospace may “break” if users enforce their own fonts.

Retro / Small Web & Related Experiments

• The project is framed as part of a broader “small/indie web” trend: simple, semantic, static pages; minimal JS; RSS; personal blogs.
• People share related resources: monospace site lists, RFC-style CSS, text-only news pages, Gemini/Gopher-like ideas.
• Bricktext (monospace fully-justified prose via word choice) and ASCII art nostalgia are discussed as adjacent “text craft” experiments.

Scope of the “No Tax on Tips” Proposal

• Many see it as election-year pandering and a distraction from bigger issues like sub-minimum wages, wage theft, and wealth inequality.
• Several comments note it appeared suddenly after a campaign anecdote and was rapidly copied by opposing candidates, with little visible policy analysis behind it.
• Some argue it would likely entrench tipping culture and reliance on tips, not reduce it.

Tax Policy, Fairness, and Loopholes

• Some argue removing income tax on tips is fiscally minor, since low earners pay a small share of income tax and much tip income already goes unreported.
• Others warn it creates a large loophole: high earners and businesses could reclassify salary or consulting fees as “tips” to avoid tax.
• Questions raised: how to legally distinguish “tip vs wage vs bribe vs gratuity,” especially after recent court decisions; suggestions include caps, industry limits, or income thresholds, but those reintroduce reporting complexity.

Minimum Wage, Sub-Minimum Wage, and Business Models

• Debate over whether the main fight should be:
  • Ending tipped sub-minimum wages and enforcing true minimums; or
  • Eliminating tipping entirely and baking labor costs into menu prices.
• Some say raising minimum wages simply pushes up menu prices and tips (a “one-way ratchet” on costs); others counter that many no-tip, full-wage systems (e.g., certain states and other countries) operate fine, with competitive prices.
• Concerns that businesses already pay the legal minimum and seldom make up shortfalls in practice; others dispute over how often laws are enforced.

Tipping Culture and Social Effects

• Strong backlash against pervasive tipping prompts (especially at counters, self-checkout, coffee shops, kiosks, and for minimal service).
• Many see tipping as de facto bribery, a coercive expectation, and a way to offload labor costs onto customers while platform/middlemen (payments processors) also take a cut.
• Others defend tipping as:
  • A way for good servers to earn well above wage-only alternatives.
  • A perceived incentive for better service, though several cite research and anecdotes that tips correlate more with appearance, race, and gender than service quality.

Broader Structural Issues

• Multiple comments zoom out to wealth inequality, declining unions, and lack of a strong labor movement or workers’ party.
• Some advocate a cost-of-living-adjusted “livable wage” floor and phasing out tips; others oppose this as forcing businesses to subsidize workers irrespective of value created.

Vaccines, Viruses, and Autoimmunity

• Several comments discuss viral infections as triggers for autoimmunity via mechanisms like molecular mimicry, and note some vaccines also have rare autoimmune risks (e.g., GBS).
• Disagreement over how well COVID vaccine risks were communicated and who counts as an “expert”; some argue real experts rarely talk to the public, others blame toxic public debate.
• One commenter stresses mechanistic differences between viral infection and most vaccines (e.g., viral replication vs. non‑replicating antigens).

Rising Allergies and Autoimmune Disease

• Many share anecdotes of new adult-onset allergies, eczema, GI issues, and food sensitivities.
• Some attribute this mainly to lifestyle: chronic overnutrition, sedentary behavior, ultra‑processed food, high sugar, and disrupted satiety signals.
• Others point to environmental exposures (preservatives, pesticides, PFAS, microplastics), though this is contested and sometimes labeled a distraction from overconsumption.
• Vitamin D deficiency is highlighted with multiple study references suggesting substantial reductions in MS, T1D, and autoimmune incidence with higher vitamin D or supplementation.

Microbiome, Parasites, and “Old Friends”

• Several cite studies on helminths and gut parasites alleviating IBS or allergies, but others with chronic conditions say helminths did little and are wary of overhyping them.
• Debate over the “old friends” vs. “hygiene” framing: some emphasize immune calibration by early microbial exposure; others note immune system training is highly timing‑ and context‑dependent and that many “friendly” microbes can be pathogenic in the wrong host.

Antibiotics, Gut Health, and Hygiene

• H. pylori is described as a common, under‑checked cause of GI issues that is usually curable with a 14‑day antibiotic course; concerns raised about long‑term microbiome disruption.
• Mixed views on probiotics post‑antibiotics; evidence seen as inconclusive.
• Handwashing habits and nasal rinsing come up as low‑tech ways to reduce infections, with some regional variation in norms.

Immune System Models and Tissue Repair

• Discussion of whether “immune system as muscle” is misleading; alternatives proposed include antifragility and “Skynet”–style dangerous overreactions.
• Several push back on claims that cartilage or ligaments “don’t grow back,” citing newer work suggesting partial regeneration and non‑surgical ACL healing in some cases.

Link & availability

• Original blog repeatedly returned database errors; several users relied on archived copies.
• Multiple commenters linked directly to the underlying RAND report instead.

Definition and reliability of the “80% fail” figure

• RAND focuses on machine-learning-based projects inside existing organizations, excluding pure “prompt engineering” wrappers around pretrained LLMs.
• The 80% number does not originate in RAND itself; it traces to a business article citing unspecified executive surveys (83–92% failure) without primary data.
• Several commenters flag this as methodologically weak and advise skepticism about the exact percentage.

Reported causes of AI project failure

From RAND summary and discussion:

• Problem selection: stakeholders misidentify or miscommunicate what the AI system is supposed to solve; same root cause as many failed software projects.
• Data: organizations often lack sufficient, appropriate, or high-quality data; many hoard user data instead of generating the domain-specific documentation/expert material LLMs actually need.
• Shiny-object syndrome: teams prioritize “latest tech” and AI branding over solving concrete user problems.
• Infrastructure & MLOps: inadequate data pipelines, deployment infrastructure, and too few data engineers; ML specialists end up maintaining brittle data code.
• Overreach: some projects tackle problems that are currently too hard for AI, or where any misprediction is too costly.

How bad is 80%? Comparisons and ambiguity

• Thread notes claims that “non‑AI IT projects” fail at roughly half that rate, but other sources in the discussion say 60–70% of software projects in general fail.
• Some see a 20% success rate for bleeding-edge tech as quite good; others say it’s worse than mature IT and may still be overstated because many projects haven’t failed yet.

Hype, management behavior, and internal politics

• Many anecdotes of executives demanding “AI everywhere” for optics, often ignoring technical staff and basic ROI analysis.
• Others describe the opposite: AI and LLMs blocked over security/compliance fears, or leaders being ultra‑conservative on spend.
• Several compare this wave to earlier fads (blockchain, NoSQL, microservices, 3D movies), with “insert new tech into everything” mandates and predictable waste.

Data, cost, and feasibility constraints

• Training serious models is described as prohibitively expensive; code is easy, data and compute are hard.
• A common failure mode: AI used to paper over missing process, tooling, or documentation; without those, LLMs add little value.

Is the money “wasted”?

• “Billions wasted” is debated: funds mostly turn into salaries, cloud bills, and hardware.
• From a VC or portfolio view, high failure is acceptable if a few “black swan” wins pay for the rest; for enterprises seeking incremental automation, repeated failures hurt more.

Where AI appears to work

• Coding assistance is repeatedly cited as a genuine productivity booster for some engineers, especially for tedious refactors and boilerplate, though others remain unconvinced or concerned about quality.
• Commenters stress that many so‑called “AI products” are thin chat‑bot or LLM API wrappers with little differentiated value, contributing to the high apparent failure rate.