Hacker News, Distilled

Is Language Necessary for Thought?

• Many argue language is not required for most human cognition: we navigate, drive, do sports, improvise art, and make rapid life‑saving decisions without verbalizing.
• Others stress that language enables certain kinds of abstract, multi‑step reasoning and self‑explanation (e.g., “rubber duck debugging”) and so is deeply entangled with higher cognition, even if not strictly necessary.
• A famous deaf‑blind autobiographical case is cited: before acquiring language, the person described life as emotion and reaction, not reflective thought; some see this as evidence language is needed for consciousness, others note it coincides with general cognitive maturation.

Non‑linguistic and Multimodal Thought

• Many report primarily thinking in images, spatial layouts, movements, graphs, or “blobs” of concepts, using language mainly as a serialization layer for communication.
• Artistic creation, intuitive math, and tool use are offered as examples where the core “thinking” feels nonverbal, with words added only afterward.
• Comparisons are drawn to “hidden layers” in neural networks: thought as internal vector space, language as lossy output.

Language as Compression, Tool, and Constraint

• Several see words as powerful compression: naming a complex phenomenon (e.g., a culturally specific term) turns a long description into a single “slot” in working memory.
• Short, dense expressions (idioms, proverbs, four‑character sayings) are praised for aiding recall and reasoning.
• Others caution that if a phrase is easily paraphrased, a dedicated word isn’t evidence of a unique concept; all languages are argued to be broadly equally expressive.
• Some claim “the limits of language are the limits of thought”; others counter that we can clearly manipulate unnamed, fuzzy concepts and only later seek words.

Individual Variation in Inner Experience

• Strong disagreement appears over inner monologue: some have constant verbal narration; others have none by default and must “switch it on.”
• People differ in visual imagery (including aphantasia), inner music, and whether they “see text” when thinking words.
• A survey on internal experience is linked; many are surprised by how different others’ minds work.

Language, Culture, and Social Use

• Cross‑linguistic “untranslatable” terms (social ties, generosity, aesthetic worldviews) spur debate: are these genuinely unique concepts or just culturally loaded labels for shared ideas?
• Some emphasize language as primarily social: coordination, manipulation, status, and group identity (e.g., accents, legalese).
• Others argue much language use is self‑directed “communication with oneself,” shaping and stabilizing thought.

Relation to Formal Linguistics and Recursion

• The paper’s claim that language and other cognitive faculties are neurally distinct is contrasted with classic theories that treat language structure as central to human thought.
• There is an extended sub‑discussion on whether natural language is truly recursive, or whether recursion mainly appears in formal grammars describing it.

Implications for AI and Mental Health

• Some view the paper as support that LLM‑style language models alone are insufficient for full cognition; others note humans also often reuse language to think.
• In psychotherapy, it’s suggested that changing “self‑talk” may help only insofar as it changes underlying nonverbal patterns; language is framed as a tool to access or reshape deeper processes, not the processes themselves.

Performance & Benchmarks

• Farm positions itself as a Vite-compatible, Rust-based build tool with faster builds, especially on large projects.
• Reported benchmarks and one user test show roughly 2× faster production builds vs Vite (e.g., ~28s → ~13s for a ~2,100‑module app).
• Some see a 50% build-time reduction as a big win for CI and feedback loops; others view it as a marginal gain not worth adopting a new tool.
• Farm’s dev-time advantage is tied to “partial bundling” (somewhere between full bundling and Vite’s ESM-based dev server), aiming to keep large apps fast on cold start and HMR.

Comparisons to Existing Tools

• Frequently compared to Vite, esbuild, Rspack/Rsbuild, Turbopack, Parcel, Bun, Deno, and the emerging Rust-based Rolldown (Rollup rewrite).
• Vite currently uses esbuild in dev and Rollup for production; its maintainers plan to replace both with Rolldown.
• Some argue esbuild alone is “enough” unless you need advanced plugin ecosystems.
• Others note Farm and similar tools often reuse SWC and other Rust components rather than reinventing everything.

Tooling Ecosystem & Proliferation

• Several commenters ask why so many near-duplicate frontend build tools exist.
• A recurring answer: moving from single-threaded JS to multi-threaded compiled languages (Rust/Go) requires rewrites, so new tools appear instead of evolving old ones.
• There is concern that Rust-based JS tooling (parsers, bundlers, transpilers) is broad in scope but under-resourced, and not always as battle-tested as JS predecessors.

Maturity, Adoption & Migration

• Skepticism about using Farm in production due to its youth; questions about large users and sponsors, with no clear big-name adopters mentioned.
• Some want “drop-in” replacement behavior and auto-migration from Vite configs; existing docs for “migrate from Vite” are considered too thin.
• Farm aims for Vite hook/option compatibility but notes JS↔Rust plugin communication is a performance bottleneck; future direction is a Rust-native plugin system.

Platform, Binaries & Config

• NPM package is expected to be cross-platform; lockfiles should be identical across ARM Macs and Windows.
• Rust native binaries raise general questions of distribution but no concrete problems reported.

Website & DX Concerns

• Multiple reports of broken/jumpy mobile scrolling and layout issues; one user hits a WebGL-related crash on the homepage (docs still work).
• Some consider this a bad look for a frontend tooling project, especially around error boundaries and WebGL use.

Security, Origin & “Farm Inc.”

• Confusion and concern about “Farm Inc.”: users can’t find a corresponding legal entity in US/China registries.
• Project members later say Farm is not a company and that “Inc.” is a mistake.
• GitHub indicates a Chinese origin; some participants express geopolitical/information-security concerns about using Chinese-developed tooling, while others note similar risks apply to “Western” OSS.
• The repository layout and multiple proxy crates are called “weirdly convoluted” by one reader, but implications are left as speculation.

General Frontend Frustrations

• Broader complaints about JS tooling: dependency bloat, rapid churn, fragile plugin ecosystems, and slow builds compared to large C++ projects.
• Some see slow builds as an accidental “soft limit” on dependency sprawl; others emphasize that modern JS dev should have a fast feedback loop and that heavy build steps are themselves a smell.

Overall sentiment about Windows

• Many describe modern Windows (especially 10/11 Home) as user‑hostile: ads in Start/search, bundled games, OneDrive/365 nags, web search in Start, dark patterns pushing MS accounts, Edge, and cloud services.
• Forced or hard‑to‑control updates, occasional driver downgrades, and settings being silently reset contribute to a sense that “it’s not my computer.”
• Some report Windows updates breaking systems or features; others say their many Windows machines have been stable for decades, suggesting mixed experiences.
• Enterprise/managed installs are generally seen as far less obnoxious because IT strips out bloat and enforces sane policies.

Attempts to tame Windows

• Users mention group policy, registry tweaks, firewall rules, debloat tools (various scripts, O&O ShutUp, winutil, AtlasOS, LTSC) to disable telemetry, ads, web search, OneDrive, Recall, etc.
• Counterpoint: this is seen as a “privacy treadmill”; changes can be brittle, revert after updates, or risk instability. Several argue an OS shouldn’t require this level of hacking.

Comparisons: macOS and Linux

• macOS is widely viewed as “less bad”: fewer in‑OS ads, more polish, better laptop hardware, but growing nags about iCloud, Apple Pay, services, and OS/app updates.
• Some see Apple’s security checks, notarization, and hardware lock‑in as a different kind of loss of control.
• Linux is praised for control, lack of ads/telemetry by default, and modern gaming viability via Proton/Steam Deck; but desktop UX, hardware support (Wi‑Fi, GPUs, HiDPI, sleep), and pro apps can still be rough.
• Ubuntu gets particular criticism for snaps and earlier Amazon/telemetry decisions; alternatives like Debian, Fedora, Mint, Pop!_OS, NixOS, Guix, and immutable spins are often recommended.

Lock‑in and practical constraints

• Many stay on Windows for specific ecosystems: CAD/CAM, industrial control software, Adobe/Affinity, Office compatibility, banking tools, router/CNC software, and legacy factory systems.
• Workplaces often mandate Windows laptops; some developers use WSL2 and are content, others insist on Linux or macOS.
• VMs and GPU passthrough are proposed as compromises, but not always performant or robust enough for heavy CAD/CAM or anticheat‑protected games.

Broader themes

• Strong sense of “enshittification”: OSs and browsers shifting from tools to ad/telemetry platforms.
• Some argue only regulation (e.g., in the EU) has meaningfully constrained vendors; others focus on personal exit—switching to Linux/macOS or sandboxed Windows VMs.

Scale, weight, and cost

• The PVM‑4300 weighed ~450 lb, drawing comparisons to pianos and car engines.
• At ~$40k in 1989 (≈$100k today), it sat in extreme high‑end territory.
• Many anecdotes describe similarly huge consumer CRTs (32–40") that needed multiple people, special furniture, or even structural consideration for floors.

Rarity and use cases

• A 1990 news article said Sony had sold only three units by then; commenters wonder how many survive.
• PVM‑series units are clarified as professional broadcast monitors, not consumer TVs.
• Some trade shows reportedly rented them as spectacle pieces.

Engineering constraints on big CRTs

• Major weight comes from thick front glass needed for vacuum, durability, and phosphor support.
• Debate: some say less glass is structurally sufficient for vacuum; others note living‑room sets must be child‑safe and sturdy.
• Glass also serves as X‑ray shielding and contains significant lead, especially in neck/funnel.
• Larger tubes need higher voltages, stronger electron beams, and complex magnetic focusing, all adding bulk.

Late CRT innovation

• Discussion of thinner, wide‑deflection CRTs like Samsung’s 2005 Vixlim; considered “peak CRT” but obsolete on arrival.
• Mentions of metal‑cone CRTs and exotic folded‑beam prototypes; issues with reliability and insulation limited adoption.
• Field Emission Displays were a hoped‑for successor but lost to ever‑cheaper LCDs.

Other large‑screen technologies

• “Big screen TVs” in 80s–90s media were usually CRT projection sets (rear or front), not gigantic direct‑view tubes.
• Eidophor and other projection systems are cited as niche big‑venue tech.

Retro gaming and image quality

• Many praise CRTs and especially Trinitrons for motion, color, and handling of low resolutions.
• Others note high‑end HD CRTs often look worse for 240p/480i than SD sets, and that modern FPGA‑based consoles with HDMI are excellent alternatives.
• Latency‑adding processing (e.g., IDTV features) is flagged as undesirable for competitive gaming.

Plasma, LCD, OLED, microLED

• Plasma is fondly remembered for image quality but criticized for heat, power draw, and aging noise.
• OLED and prospective microLED are discussed as spiritual successors; cost and manufacturing limits remain key constraints.

Legality, COVID “Emergency Library,” and IA’s Strategy

• Many argue IA’s COVID-era “emergency library” (unlimited concurrent loans) was an obvious overreach that “poked the bear” and triggered the lawsuit.
• Others stress the lawsuit formally targeted all of IA’s controlled digital lending (CDL), not just the emergency period.
• Court granted summary judgment against IA; several commenters see this as proof their legal theory was weak and poorly executed.
• Criticism that IA leadership gambled the whole archive on an activist move instead of isolating the legal risk.
• A minority defend IA’s actions as necessary civil disobedience in a broken copyright regime.

Controlled Digital Lending vs. Copyright Law

• CDL advocates: if a library owns a physical copy, it should be allowed to lend one managed digital scan at a time (1:1 “owned-to-loaned”).
• Court held the scanning + delivery itself is “copying” requiring permission; the 1:1 constraint was deemed irrelevant.
• Some note IA’s own records under discovery showed they weren’t even perfectly enforcing 1:1.
• Analogies raised (and mostly rejected legally) to “renting DVDs and streaming them one-at-a-time” services that courts shut down.

Critiques of Copyright Duration and Scope

• Broad agreement that copyright terms are far too long (life + 70 in practice).
• Proposals: fixed 10–25 year terms; “use it or lose it”; mandatory renewal fees; automatic public domain at death; shorter terms for software.
• Strong support for freeing out-of-print / commercially unavailable works; debate over whether authors’ families should keep rights.
• Comparisons with trademarks (“use it or lose it”), patents, and copyleft licenses (GPL) as alternative incentive structures.

Publishers, Authors, and Libraries

• Many view publishers as rent-seeking gatekeepers exploiting DRM and expensive e‑book licenses that drain library budgets.
• Others push back, highlighting the value of editors, typesetters, and the need for revenue in a high-risk book market.
• Libraries’ traditional first-sale rights vs. tightly controlled digital lending seen as a core conflict; fear that “digital libraries” will be effectively illegal.

Access, Piracy, and Shadow Libraries

• Strong sentiment that restricting easily shareable knowledge is socially harmful, especially for old, niche, and technical books.
• IA’s scans are often unique mid‑20th‑century works not well covered by LibGen; removal is a real loss for researchers and students.
• Many predict users will shift to LibGen, Anna’s Archive, IPFS, and torrents; some openly encourage seeding as a form of resistance.

Normative and Political Debates

• Long subthreads on whether information should be treated like property at all; emphasis on non-rivalrous nature of digital goods.
• Arguments range from “abolish copyright” to “fix it modestly”; concerns about communism vs. capitalism, UBI, state subsidies, and long-term societal incentives.

Engineering, economics, and risk

• Engineering is framed as making good tradeoffs under constraints (money, time, safety, performance), not pursuing perfection.
• Formal methods are seen as justified when failure is catastrophic or very costly (deep space probes, large-scale distributed systems, medical/nuclear/aviation-like domains).
• For early-stage startups or short-lived prototypes, many argue the cost of formal methods is irrational compared to time‑to‑market; technical debt is treated as an economic bet.
• Several comments stress that finance and incentives (including the ability to externalize failure costs) largely determine how much rigor is applied.

Where formal methods help (and where they don’t)

• Widely agreed: they matter most for concurrency, distributed protocols, and tricky low-level behavior where intuition and tests often fail.
• They’re also useful to precisely explore requirements and failure modes, and to prove or disprove algorithmic properties (deadlock freedom, message loss, protocol safety).
• Some argue formal methods are essential to make software engineering more like traditional engineering; others counter that most non-software engineering only uses heavy formality in narrow, optimized or safety-critical slices.

Tools and approaches mentioned

• Positive experiences reported with TLA+, Alloy, bounded model checking (CBMC, Kani, JBMC, Klee, Frama‑C), and Rust-based verifiers (Prusti).
• Other tools referenced: SPARK, Dafny, F*, abstract state machines, P, Viper, RAISE.
• Some use these tools to model protocols/hardware buses and then mirror the model closely in code, yielding very few logic bugs.

Verification gap and integration with code

• A major concern: “verification gap” between a specification in a separate language (e.g., TLA+) and the production implementation (C, Rust, etc.).
• Desired directions:
  • Proofs embedded in the language via stronger type systems, contracts, or dependent types.
  • Tooling that runs in CI, generates tests/stubs, or checks real source (not just abstract models).
• Async, threading, and complex frameworks are often poorly supported by current tools, limiting adoption.

Testing vs proofs and cost debate

• Long back‑and‑forth on whether exhaustive testing or high coverage can ever substitute for formal proofs; many say no, others claim exhaustive testing can be practically sufficient in some domains.
• Formal proofs are described as powerful but expensive; estimates range from modest overhead to 5–10x more effort, and only clearly worthwhile where correctness is highly valuable.

Housing impact and scale

• Barcelona plans to phase out ~10,000 tourist apartments by 2028.
• Commenters note this is significant but not transformative: with ~1.6–1.7M city residents and ~2.5 people/household, it helps tens of thousands but not the full housing gap.
• Compared to 15,000 units built 2011–2020, the ban potentially frees more homes than recent construction over a similar time span, but still lags behind recent population growth (100k in 4 years in the wider metro).

“Build more” vs physical and political limits

• Many argue the real solution is increasing housing supply and loosening zoning, as done in some Asian cities.
• Others counter that Barcelona city is already extremely dense (~16,000/km²), geographically constrained (“in a bowl”), and largely built out; further upzoning (e.g., 5–6 to 10 stories) is seen as costly and politically difficult.
• A separate group points to the much lower density in the broader province and good rail links, arguing there is regional room to grow if transit-oriented development is pursued.

Tourism, locals, and “resource curse” dynamics

• Strong resentment of mass tourism is reported: locals describe being priced out, central areas feeling “colonized,” and hearing less Catalan/Spanish.
• Some frame tourism as a “resource curse”: lucrative for property owners and tourism businesses, but crowding out other economic activity, hollowing neighbourhoods in the off-season, and driving political backlash.
• Counterpoint: tourism is a modest share of Barcelona’s GDP (single-digit %) but important nationally; harming it may mean fewer jobs and less growth.

Property rights, zoning, and “authoritarianism”

• One camp sees banning STRs as normal zoning (you can’t run a factory or nightclub in an apartment), democratically chosen by residents who bear the externalities.
• Critics call it NIMBY and “authoritarian,” arguing owners should decide how to use their property and that this scapegoats tourists instead of fixing underbuilding and foreign/investor demand.

Airbnb vs hotels from the user side

• Several travelers prefer apartments for kitchens, laundry, space, and family/group stays; others report Airbnb “enshittification”: higher prices, fees, chores, and unreliable hosts, pushing them back to hotels or aparthotels.
• Some expect hotel prices and “richer” tourism to rise if STRs vanish; others welcome fewer, more expensive tourists over overcrowding.

Effectiveness, enforcement, and alternatives

• Skeptics predict black markets, “rebranded” rentals (e.g., to digital nomads), or hedge funds holding units; others reply that past STR regulations and rent controls can work if enforced.
• Alternative or complementary ideas mentioned:
  • Heavy taxation of STRs and second homes to fund social/affordable housing.
  • Limits or taxes on foreign buyers.
  • Empty-home taxes.
  • National‑ or city‑built social housing and liberalized zoning, especially where building capacity still exists.

Broader view

• Several see Barcelona as a valuable natural experiment: even if this is a one‑time partial fix, its outcomes—on rents, tourism, and neighbourhood vitality—will be closely watched by other cities facing similar pressures.

Rectangular vs. Round Wafers

• Several comments note silicon ingots are drawn as cylinders, so wafers are naturally round; making rectangles means squaring the boule or cutting rectangles from circular wafers.
• Some argue this is still advantageous: squaring the boule yields large, pure silicon offcuts that can be recycled, while partial chips on circular edges are contaminated and harder to reuse.
• Rectangular wafers align better with existing X/Y positioning stages and rectangular chip layouts, potentially improving clamping, reducing acceleration stresses, and simplifying lithography modeling.
• Others point out that many process steps, especially spin coating and optics, are optimized for circular wafers; uniform coating on rectangles is called “sucks” and non‑trivial.

Cost, Waste, and Value

• Multiple posts emphasize that raw silicon cost is negligible compared to finished chip value.
• Example figures in the thread: tens of dollars for 200–300 mm blank wafers vs. hundreds of thousands to around a million dollars of value per 300 mm wafer for high‑end GPUs.
• Therefore, improving usable die count (especially avoiding edge partial dies) matters far more than saving raw silicon.

Interposers and Panels

• One clarification: this move may be about large rectangular panels for interposers, not traditional chip wafers.
• Interposers are now bigger than individual chips; using circular wafers leads to significant wasted edge area.
• For interposers, ultra‑perfect silicon isn’t required; continuous ribbons like those used for solar cells could be sliced into rectangular panels and then finished with a thin high‑quality surface.

Alternative Shapes (Hexagons, Triangles, 3D)

• Hexagonal wafers or chips are discussed but generally dismissed:
  • Hard to dice with long straight cuts; require complex, multi‑direction cuts across a fragile wafer.
  • Triangular chips tessellate but give no clear advantage and complicate design and tooling.
• Some speculative 3D concepts (cube chips with coolant channels, “shells” nesting into spheres) run into heat dissipation and manufacturing complexity concerns.

Process and Industry Inertia

• Round process chambers (etch, deposition) are valued for uniformity; square chambers are expected to pose challenges.
• The industry’s deep investment in 300 mm circular wafers is seen as a major barrier to change.
• A lithography engineer notes only upsides for rectangles in their domain but doubts widespread adoption will be fast.

Economics and Foundry Relationships

• Comments suggest large customers (e.g., major device and GPU makers) prepay or co‑invest in fab capacity and sometimes even own specific machines, helping fund radical equipment changes.

Charging range, cycles, and state-of-charge buffers

• Many commenters aim to keep lithium batteries in a mid-range (e.g., 30–80% or 40–60%) and avoid deep cycles like 100–5%, which are said to be more damaging.
• Some laptops/phones and EVs expose charge limits (e.g., 60–80%) that users exploit to keep maximum charge below 100%.
• There is discussion that devices often hide real capacity: some BMSs reportedly map “100%” to less than true full charge and “0%” to above absolute empty, but the buffer size varies and is device-specific.
• One claim: degradation tends to floor around ~80% capacity regardless; careful habits just delay reaching that point.

Fast vs slow charging and current

• Many want explicit “slow charge” / “charge to X%” controls per session.
• Workarounds include using low-power chargers, wireless chargers, current-limiting adapters, and scripts or root-only tools to cap current.
• Consensus: higher charge rates and high “C” (e.g., very fast phone chargers) accelerate wear; lower current and avoiding the last 10–20% are seen as protective.

Temperature effects

• Strong agreement that heat is harmful; suggestions include good airflow, avoiding hot cars, and using vents or active cooling mounts.
• Some push back on “the colder the better,” arguing batteries should stay near their rated temperature; extreme cold plus charging can cause damage (e.g., lithium plating).
• For LFP, tests cited: modest extra degradation at 35°C vs 25°C but still very long lifetimes.

Chemistry- and application-specific notes (LFP, EVs)

• LFP: flatter voltage curve makes SOC estimation harder; many BMSs rely on coulomb counting plus periodic 100% charges for balancing.
• Some claim LFP tolerates high SOC well and is “hard to kill,” with guidance to charge to whatever is convenient and not fear full charges.
• Off-grid / seasonal use: LFP is viewed as fine stored cold and idle, with BMS quiescent draw considered negligible.
• EVs: modern packs generally use active cooling; advice is to avoid charging or heavy acceleration when the pack is very hot. Older designs without cooling (e.g., early compact EVs) were noted as problematic.

Software, tools, and trade-offs

• Numerous tools (OS settings, root apps, desktop utilities, smart plugs) are used to limit charge %, current, or temperature.
• Some users meticulously manage charge windows; others ignore all this and simply replace batteries every few years, arguing the hassle may not be worth marginal gains.

Apple’s Decision & Features Affected

• Apple will not roll out Apple Intelligence, iPhone Mirroring, and enhanced SharePlay Screen Sharing in the EU this year.
• Official rationale: DMA interoperability rules could require opening these capabilities to third parties in ways that, according to Apple, would compromise security and privacy.
• Several commenters see this as a strategic move or “bluff” to put pressure on EU regulators or public opinion, not a purely technical limitation.

Security, Privacy, and Interoperability

• Supporters of Apple’s stance argue:
  • Screen-reading / screen-sharing plus AI is effectively a “spyware API” if exposed to untrusted third parties.
  • DMA/DSA create a conflict: Apple is responsible for safety but must also allow interoperability and potential replacements of core components.
  • Private Cloud Compute and on-device models are designed with strong guarantees that may break if third-party models must plug in at the same level.
• Critics respond:
  • APIs can be designed with explicit permissions and sandboxing (similar to camera or screen-recording).
  • If third-party AIs are dangerous, so are Apple’s or Microsoft’s Recall-style features; trusting Apple purely on “privacy brand” is questioned.
  • If Apple can re-architect for China’s demands, they could also do so for the EU and are choosing not to.

EU Regulation: Protection vs Overreach

• Pro-regulation view:
  • EU laws (DMA, GDPR, etc.) finally have “teeth,” forcing big tech to slow down and consider privacy and competition.
  • It’s better to delay “shiny features” than repeat social media–style harms; tech should fit democratic choices, not vice versa.
• Anti-/skeptical view:
  • EU rules are seen as unclear, aggressive, and retroactive, creating business risk and discouraging investment.
  • Fear that overregulation will lock the EU out of bleeding-edge tech, deepen productivity gaps, and push users toward weaker, cheaper alternatives.
  • Cookie banners are cited as an example of well‑intentioned regulation with persistent global annoyance and uneven enforcement.

Market Impact and Alternatives

• Debate over whether this will significantly hurt Apple’s EU sales: some expect little change due to ecosystem lock‑in; others think it undercuts Apple’s AI-based upgrade pitch.
• Commenters note an opening for EU-compliant, privacy-focused competitors, but also lament the EU’s relatively weak consumer-tech ecosystem and VC sector.

Broader AI Attitudes

• A subset of users welcomes the absence of OS-integrated AI and prefers separate, ideally open-source and local, AI tools.
• Others worry that the EU is already “falling behind” in AI, while some question whether being first in AI is inherently desirable.

Privacy & Data Use

• Some riders are wary of giving Google/Waymo detailed location histories, especially for sensitive trips.
• Others argue phones already leak similar data; debate over whether Google is effectively a “data broker.”
• Waymo’s policy allows sharing data for ad targeting under California law, but not selling raw data; some see this as standard ad-tech profiling, others as unacceptable.

User Experience & Ride Quality

• Many SF and Phoenix users strongly prefer Waymo over Uber/Lyft: predictable cars, quiet, good AC, no small talk, helpful with babies and sleep.
• Ability to set music profiles that persist across rides is appreciated.
• Some report glitches (e.g., AC bug or car refusing optimal drop‑off point), causing frustration.

Pricing & Economics

• Most report ~10% higher base prices than Uber/Lyft, but comparable after tips; some see much higher.
• Riders expect prices to drop with scale, but others think Waymo will charge what the market bears, especially while supply is limited.
• Debate whether AVs’ real point is cost savings for operators vs cheaper rides for users.

Safety, Speed & Driving Behavior

• Waymos are described as cautious: slower than traffic, long stop‑sign pauses, very courteous to cyclists.
• Some see this as a key safety benefit; others complain about longer trips and human drivers doing risky maneuvers to pass.
• Large subthread debates speed limits vs “flow of traffic” and whether slower AVs are objectively safer or create new hazards; consensus: humans often drive badly, but independent, non–vendor safety data is still desired.

Coverage, Routing & Airports

• Big limitations: no SFO service, historically no or limited freeway use, constrained geographic coverage (esp. Phoenix suburbs).
• Routing often avoids highways and prefers side streets, making some trips much longer; this is a major complaint for time‑critical trips (e.g., airport).

Autonomy vs Remote Assistance

• Waymo says cars are self‑driving but can receive guidance from “fleet response” operators.
• Operators can suggest paths or lane choices when cars get stuck, but reportedly don’t joystick‑drive the vehicle.
• Some commenters distrust the lack of detailed metrics (e.g., interventions per mile) and suspect heavier remote involvement.

Labor, Society & Politics

• Ethical tension: fans like not dealing with drivers; critics see this as dehumanizing and cheering job loss.
• Some view AVs as a way to remove dangerous human drivers; others emphasize economic harm to drivers.
• Local political opposition (e.g., SFO restrictions, safety FUD) is seen by some as disproportionate given reported safety.

Cleanliness & Maintenance

• Current fleet is consistently clean and new; skepticism about whether this will hold post‑“honeymoon phase.”
• Waymo has cleaning policies, cameras, and fee schedules for messes; some think centralized fleet management will outperform gig drivers, others expect standards to erode when competition thins.

Vandalism & Abuse

• Concern that widespread deployment may trigger more vandalism (already a few high‑profile incidents), or YouTubers probing edge cases to confuse cars.

Overall reaction to LLMs on PCB design

• Many see this as a clear demo of current LLM limits: models generate schematics and footprints that look plausible but have critical errors (missing connections, wrong footprints, bad decoupling, extra components).
• Several EEs stress that a single such error can make an entire board worthless; “70% correct” designs are often harder to fix than starting from scratch.
• Others are impressed that frontier models can do anything at all in this domain and view the results as “amazing for 2024,” but still not production‑ready.

Where LLMs seem useful today

• Strong agreement that LLMs shine at:
  • Parsing and summarizing datasheets and PDFs.
  • Turning informal requirements into high‑level code or DSLs (e.g., SKiDL, tscircuit‑style React DSLs).
  • Automating boilerplate tasks: power nets, decoupling suggestions, pin tying, reminders like “you forgot I²C pullups.”
• Several comments argue that LLMs are best used as “vocabulary expanders” and design‑space explorers, not as final designers.

Alternative approaches and future directions

• Multiple posters argue pure LLM/next‑token prediction is the wrong tool for holistic, highly constrained design problems like PCB layout or high‑speed transmission lines.
• Suggestions include:
  • Diffusion or other generative models for combinatorial optimization and placement/routing.
  • Domain‑specific solvers for length matching, SI, etc., with LLMs as a front‑end.
  • Fine‑tuning on netlists, footprints, or synthetic datasets; RL or self‑play using rule‑based checkers.
• Some report promising results using diffusion and autoregressive models on combinatorial problems (MaxCut, MIS, MaxClique) but note neural search and exploration remain open challenges.

Data, components, and verification issues

• A major bottleneck: poor, inconsistent, NDA‑gated datasheets and third‑party libraries. Juniors are taught not to trust existing symbols/footprints.
• Proposals include “datasheet‑to‑component” and “datasheet‑to‑SPICE” pipelines, but others warn verification is hard and AI‑generated libraries will not be trusted without strict checks.

Meta‑discussion: model quality, hype, and “goalposts”

• Mixed experiences comparing Claude, GPT‑4o, GPT‑4‑turbo, Gemini; performance is highly task‑dependent.
• Debate over “goalpost shifting”: some say expectations unrealistically jump from “works at all” to “zero hallucinations,” others argue reliability is a legitimate new requirement.
• Broad consensus: LLMs are transformative and useful in many workflows, but far from replacing domain experts in safety‑critical or nuance‑heavy design tasks.

Historical origin & sign convention

• Early experimenters defined “positive” and “negative” before electrons were known, based only on how rubbed materials behaved.
• The labeling was purely conventional; reversing all signs would leave Maxwell’s equations and circuit laws unchanged.
• Later discovery that electrons carry charge opposite to the defined current direction created a mismatch, but standards were already deeply embedded, so they were not changed.
• The thread notes that the time between Franklin’s work and atomic/molecular theory is very short on geological/biological timescales, illustrating how recent our understanding is.

Current vs electron flow and charge carriers

• Conventional current is defined as flow of positive charge; in normal metals the actual mobile carriers are electrons moving the opposite way.
• In semiconductors, “holes” (absence of electrons) behave as positive charge carriers, so thinking in terms of hole flow is often more convenient.
• Charge carriers need not be electrons (e.g., ions in electrolytes), reinforcing that “current” is a macroscopic abstraction.

Terminology confusion (anode, cathode, etc.)

• Many comments describe difficulty remembering anode/cathode, especially because which terminal is which can flip when a device is charging vs discharging.
• Various mnemonics are shared; some argue the terms are so context‑dependent they’re almost useless outside vacuum tubes, diodes, and electrochemistry.
• There is also confusion between cations/anions and anodes/cathodes.

Fields, energy flow, and what actually moves

• Several comments stress that electrons drift very slowly; the “signal” and energy propagate via electromagnetic fields at near‑light speeds.
• Energy in circuits largely travels in the fields around conductors, with wires acting as guides; electrons mainly respond to the fields.
• Linked popular videos on this are described as insightful by some and misleading or “debunked” by others; critics emphasize that electrons do flow in wires and that “current through air” is negligible except during breakdown.

Grounding, safety, and practical circuits

• In power systems, what matters for safety is which conductor is tied to earth; touching one isolated conductor is harmless, touching one referenced to ground can shock you.
• Grounding the system helps control voltages relative to earth and mitigate lightning/atmospheric charge issues.
• Battery examples (AA vs 9V, licking terminals) are used to illustrate the need for a complete path and sufficient voltage.

Mathematical and philosophical aspects

• Some argue “electron is negative” is sloppy shorthand and that only its charge is negative in a chosen numerical model; others counter that this shorthand is standard and clear in context.
• Extended debate touches on whether numbers and negation are features of the world or purely mental constructs, and whether math is invented or discovered.
• Commenters note the symmetry of flipping all charges and directions, and that many EM expressions depend only on products of charges, making the sign convention physically arbitrary.

Gravity and other analogies

• An analogy is drawn to a hypothetical future reinterpretation of gravity (push vs pull), arguing that some sign choices in physics may be conventional.
• Others point out that “push gravity” models have been tried historically and run into hard quantitative contradictions (drag, shielding, equivalence of inertial and gravitational mass).

Naming, language, and pedagogy

• Discussion digresses into how labels like “up/down” quarks, left/right politics, battery/accumulator, and color names (red/blue, pink/red, orange/brown) illustrate arbitrary but sticky conventions.
• Some regions and textbooks reportedly teach electron‑flow (negative‑to‑positive) conventions instead of conventional current, which can confuse students when they encounter mainstream notation.

Historical context of √2 and Pythagoreans

• Discussion centers on why √2 was historically shocking: it showed some right triangles have side ratios that are not rational, contradicting the belief that all magnitudes are commensurable.
• Clarification that only some right triangles have rational side ratios (Pythagorean triples); “most” do not.
• Debate over what Pythagoras himself actually did; earlier Babylonian knowledge of the theorem and triples is noted.
• The drowning-of-the-discoverer myth is flagged as likely untrue, though secrecy/anxiety around incommensurability is acknowledged.
• Ancient Greeks often preferred geometric reasoning and saw arithmetic as “dirty” or practical, not philosophical.

Nature of rationals, irrationals, and real numbers

• Commenters stress that irrationals are defined negatively (not expressible as a ratio of integers).
• Dense rationals versus uncountable reals leads to “most” real numbers being indescribable; only countably many can be named or encoded in finite text.
• Computable numbers are highlighted as a more “sane” subset of reals, though still with limitations (e.g., ordering arbitrary computable reals is not computable).

Cantor vs Dedekind and constructive mathematics

• One camp criticizes Cantor and uncountable sets as leading to “navel-gazing” and non-constructive horrors (e.g., Banach–Tarski, “almost everywhere” phenomena).
• Others defend classical set theory as extremely successful and central to modern science, noting no contradictions found and great practical utility.
• Intuitionism and constructive approaches (e.g., Dedekind cuts, reals as limits/approximations) are discussed as alternatives; some see them rising in relevance via proof assistants.

Irrationality and repeating decimals

• Explanation that any eventually repeating decimal is rational via algebraic manipulation (multiply by a power of 10 and subtract).
• Conversely, all rationals in base-10 must either terminate or repeat because there are finitely many possible remainders in long division.
• Proofs of irrationality (e.g., for √2, e, π) are emphasized as independent of computing digits.

Philosophy, teaching, and broader reflections

• Some wish basic math education covered formal definitions and the history of ideas more deeply.
• Others recommend history-of-science/math resources and warn of “rabbit holes.”
• Speculation appears on whether aliens or non-spatial AIs might develop very different foundational number systems.

Usefulness of an “innovation doctrine”

• Many see “innovation doctrine” as vague, slideware-level advice akin to mission statements and “think outside the box.”
• Critics argue doctrine alone can’t overcome entrenched incentives, budgets, and legal constraints.
• Some defend the idea if “doctrine” is understood like military doctrine: clear principles and processes that enable effective action, not rigid rules.

Bureaucracy, incentives, and dysfunction

• Large orgs and agencies accumulate rules to manage risk, audits, and complexity; this slows even trivial changes.
• “Innovation hero” stories are seen as symptoms: when basic automation requires months of political and procedural effort, the system is self‑defeating.
• Multiple comments stress incentives: budgets tied to headcount, risk-averse middle management, and reward systems that favor compliance over improvement.

Government vs. private sector

• Disagreement over whether government needs innovation: some say it’s a monopoly with little competitive pressure; others note states compete fiercely (e.g., militarily) and spend heavily on innovation.
• Public-sector constraints (civil-service protections, budgeting rules, strict accountability) make firing and change hard, but targeted units with top-level backing (e.g., digital services) can work.

Culture, trust, and middle management

• Recurrent theme: leadership doesn’t trust “grunts,” assumes they’ll create “NIH spaghetti,” and so builds heavy oversight.
• Others counter that messy homegrown systems often arise from too much oversight, budget denials, and perverse promotion incentives (e.g., reward “org-wide impact” for reinventing wheels).
• Middle management is depicted as the main blocker: judged on safe delivery of top initiatives, hostile to nonstandard work, and motivated to veto bottom-up ideas.

Risk, change, and the quality of innovation

• Several argue most ideas are bad; friction is a necessary selection mechanism, not automatically “dysfunction.”
• Others respond that zero tolerance for failure kills necessary experimentation; slack time and “screwing around” are required.
• People and organizations strongly resist change; even small improvements can trigger “immune responses.”

Metrics, process, and gaming the system

• Stories of Jira/Agile metrics being optimized at the expense of real work: teams inflate or split tickets to satisfy burndown charts or “planned points” KPIs.
• This is seen as a sign of deeper dysfunction: metrics drive behavior, but are often decoupled from actual customer or mission value.

Career and human consequences

• “Innovation heroes” often burn out, get marginalized, or leave; for every celebrated hero, several quietly exit.
• Some suggest the rational strategy in such orgs is to automate your own work quietly and avoid visibility.
• Others note that large organizations often prefer acquisitions over internal innovation, because their core strategy is to defend existing business models, not disrupt them.

Nature of one-line fixes & debugging experience

• Many note that “one-line fixes” usually hide the real work: the hard part is discovery, not editing the code.
• Debugging is described as an emotional rollercoaster, oscillating between feeling brilliant and feeling incompetent, sometimes simultaneously.
• Some stress how subtle clues from past experience (e.g., knowing modulo is slow on an 8‑bit microcontroller) can unlock days of progress in minutes.

ETAs, productivity, and management metrics

• Engineers struggle to give time estimates: once the cause is known, the fix is fast, but discovery time is highly variable.
• Using lines of code, sprints, or similar quantitative metrics to judge productivity is criticized as misleading, especially when big payoffs come from small changes or deletions.
• Some argue management should rely more on trusted technical leaders rather than simplistic metrics.

Seniority, value, and compensation

• One side claims seniors deserve higher pay because they more consistently deliver leverage (e.g., deleting features, simplifying requirements).
• Others argue pay reflects market forces and negotiation more than actual value, citing high performers paid well below peers.
• There is debate over how tightly “senior” correlates with real skill, domain knowledge, and positive impact versus politics or resume-driven development.

Performance, compilers, and the modulo discussion

• Participants debate whether compilers should optimize modulo operations, especially with constant or power-of-two denominators.
• Some note modern compilers already replace division/modulo by constants with multiply-and-shift sequences; others point out this breaks down when the divisor is variable.
• There’s interest in the article’s claim about rewriting 16‑bit modulo into 8‑bit operations, with linked references but no fully clear consensus on the exact transformation.

Anecdotes of long-lived and subtle bugs

• Multiple stories echo the main article: months of work to find a race condition, an uninitialized boolean, or a layout-sensitive hash bug whose fix is one line.
• Examples include flaky CI due to hash collisions, kernel driver initialization races, and performance regressions triggered only on some boots.
• Commenters highlight how better warnings, static analysis, and sanitizers (ASAN/MSAN, valgrind) catch some of these classes of bugs today, though setup and overhead can be nontrivial.

Legacy systems, data issues, and tooling

• People recount painful interactions with old stacks: WCF, mixed .NET/.NET Core, K8s complexity, and vendor SDK mismatches.
• SQL gotchas like undocumented constraints and problematic money types causing miscalculations are common themes.
• Old Perl scripts and embedded 8051-era code are cited as surprisingly durable, though version mismatches (Perl4 vs Perl5) can still bite.

Engineering ethics & the Challenger decision

• Commenters highlight McDonald’s refusal to sign off as an archetype of personal integrity under pressure, contrasting it with common corporate groupthink and “beige” conflict‑avoidant cultures.
• Many emphasize that engineers’ no‑go recommendations were overridden by managers at Thiokol and NASA, despite prior formal warnings about O‑ring risks and reclassification of the joint as a critical, non‑redundant failure point.
• The case is cited as an example of “normalization of deviance”: repeated tolerance of anomalies (like O‑ring erosion or damaged Shuttle tiles) until catastrophic failure.
• Several note that cultural reforms after Challenger did not prevent a similar pattern from recurring with Columbia.

Technology, AI, advertising, and personal red lines

• Numerous posters describe refusing work in areas they consider harmful: military, ads, surveillance, gambling, payday loans, crypto, and sometimes AI.
• Others argue individual boycotts are ineffective without unions or professional regulation akin to other engineering fields.
• There is an extended debate on advertising: some see it as socially valuable product discovery; many more frame modern adtech as behavioral manipulation, pollution, and “non‑consensual mind control”.
• Opinions on AI diverge: some view it as neutral infrastructure with good and bad uses; others see it as an “anti‑printing press” that will degrade trust and supercharge manipulation.

Economic pressure, careers, and ethics

• Commenters stress that visas, family obligations, and weak job markets push engineers into ethically dubious work; “principles vs eating” is a recurring tension.
• Whistleblowing and “being difficult” are often career‑limiting or worse; stories from defense, nuclear, and corporate environments describe management ignoring or punishing bad‑news messengers.

Organizational structure, risk, and responsibility

• Discussion around dashboards, alerts, compiler warnings, and safety cases echoes Challenger: once “some red” is normal, signals lose meaning.
• Some advocate small teams with real technical ownership and fixing all warnings/alerts; others note many engineers will still deprioritize quality without strong culture and incentives.
• There is debate over hierarchical corporations vs employee ownership: hierarchies are seen as efficient yet prone to misaligned incentives, information loss, and executives overweighting schedule/financial risk over safety.

Spaceflight risk, other programs, and acceptable danger

• Thread compares Shuttle practices with SLS, Starship, and Boeing’s Starliner; some defend SpaceX’s iterative “test, fail, fix” model, others worry about “barn‑style” risk culture.
• Heated exchanges explore how much risk astronauts (or explorers generally) should accept, with sharp disagreement over claims that very high death probabilities (e.g., 50%) are acceptable.

Technical approaches to age verification

• Multiple ideas suggested: OpenID-style protocols, Apple digital IDs with FaceID, EU/German/Estonian eID cards, US DMV smartcards, W3C Verifiable Credentials, zk-proofs, government “age attestation” APIs.
• Some argue cryptographic systems can give “over 18” proofs without sharing identity, using short-lived, site-specific tokens, rate limiting, and zero-knowledge proofs.
• Others claim this is “literally impossible” without either shareable tokens that kids can reuse or some revocation/centralization that breaks true zero-knowledge.
• Practical barriers noted: hardware readers, browser support, app-store hostility to porn, and kids simply using parents’ IDs or devices.

Centralization, trust, and surveillance concerns

• Strong worry that any centralized verifier (Apple, government, OpenID provider, banks, etc.) gains visibility into porn use and broad browsing habits.
• Some see this as a Trojan horse for de-anonymizing the internet, creating a slippery slope from porn verification to identity requirements for dating, email, news, and more.
• Debate over whether a government-run system is acceptable:
  • Pro: government already issues physical IDs; could run privacy-preserving APIs; we already trust it with far more dangerous powers.
  • Con: chilling effects, potential authoritarian abuse, silent refusal or manipulation, and doubt that “no logs” guarantees would be honored.

Motivations and incentives

• Many believe the stated “protect the children” rationale is a wedge issue; real goals include broader monitoring and control, or moral/religious anti-porn crusades.
• View that laws intentionally make compliance nearly impossible to achieve a de-facto porn ban.
• Speculation that Pornhub’s blocking tactic is driven by liability avoidance, operational cost, and preserving user trust/traffic, but also acts as PR and political pressure.

Alternative solutions and effectiveness

• Several propose shifting enforcement to client or ISP-level parental controls and content headers, rather than server-side identity checks.
• Skepticism that any remote age verification can reliably stop motivated minors; “rum runners” and shared IDs likely persist.
• Concern that pushing Pornhub out just drives users (including kids) to more extreme, less regulated sites and VPNs.

Project goals & value proposition

• Seen as an “experimental engineering” effort to build a fully independent web stack and prove a modern browser engine can be created without big-tech resources.
• Some frame it as “basic engineering” rather than a product with a business-style “value proposition”; the value is in the open, incremental development process.
• Others see practical value mostly in offering another engine to counter browser monoculture, even if it never reaches mass market.

Maturity, capabilities & expectations

• Consensus: the engine is very early and far from being a daily driver; major sites still break and performance/stability lag far behind Chrome/Safari/Firefox.
• Many doubt it will ever reach “critical mass”; others counter that past engines (KHTML→WebKit→Blink) also started small.
• Some users are simply “irrationally excited” that a fresh engine exists at all, despite low short‑term practicality.

Learning & contributing

• Multiple commenters say it’s a good learning playground with broad scope and approachable tasks (e.g., simple features like find‑in‑page).
• Others warn that browser development is inherently deep and that motivation lasts longest when you’re scratching your own itch, not just “learning on a big project.”

Browser ecosystem, monoculture & Firefox debate

• Many want Ladybird as an additional independent engine beyond Blink and WebKit; some argue Firefox already breaks monoculture, others say its heavy funding from Google undermines independence.
• Intense debate around Mozilla’s choices: telemetry, “studies,” ads, acquisitions, and cancelled efforts like Servo; some still consider Firefox solid and configurable, others have lost trust.
• Several worry that standards effectively ratchet toward whatever Chromium implements, making life hard for new engines and subsets.

Implementation choices: C++, Rust & security

• A major thread questions building a hostile‑content processor in C++ in 2024, citing memory‑safety concerns and studies linking many exploits to unsafe memory.
• Defenses of C++ include:
  • Author proficiency and project origins as a personal/hobby effort.
  • Lack of proven, large‑scale Rust/browser examples; suspicion of “rewrite it in Rust” as cargo‑cult.
  • Argument that many modern JS‑engine bugs are subtle logic/JIT issues where language choice helps less.
• Others point to alternative approaches (Ada, ATS, formal methods, sandboxing) but acknowledge practicality and ecosystem issues.
• Discussion notes that current sandboxing on non‑SerenityOS appears minimal; plans exist but are “nowhere near” the aggressiveness of Chrome‑style sandboxes.

Architecture, platforms & dependencies

• Ladybird now targets Linux and macOS and has dropped SerenityOS as a primary target, partly because using third‑party libraries conflicts with SerenityOS’s “no third‑party code” philosophy.
• Uses Qt for browser chrome and platform integration; some worry this makes the project “pointless” compared to Qt WebView (Chromium), but others stress Ladybird’s engine is independent of Qt.
• There is per‑tab/process isolation and architectural docs; deeper hardening is planned but incomplete.

Alternative web visions & subsets

• Some wish for a browser that implements only a strict subset of HTML/CSS/JS/APIs for simplicity, speed, and security, perhaps with fallbacks to a “big” browser for complex sites.
• Others argue subset browsers fail in practice: once mainstream engines support a feature, sites rely on it and any browser lacking it is seen as broken.
• Proposals include:
  • A “new web” or separate protocol (compared to Gemini) that deliberately avoids complexity.
  • Browsers that delegate PDFs, video, and JS‑heavy pages to external tools.
  • Acknowledgment that many text‑centric sites still work with little or no JS, but modern webapps do not.

Adoption, funding & future prospects

• Skeptics think the project may eventually pivot to Chromium or stall once the full scale of the work hits; others strongly doubt this, noting years of steady progress and that using Chromium would erase the project’s raison d’être.
• Some hope for legal or policy interventions (e.g., browser‑choice ballots, constraints on major platforms) to prevent further consolidation and give alternative engines room to matter.
• Overall sentiment: strong admiration for the ambition and execution so far, tempered by realism about how hard it is to catch up to mature engines and the ever‑growing web platform.

Scope of the Ban: Security vs. Free Speech

• Some see the Kaspersky ban as akin to restricting code as speech, drawing parallels to historical crypto export controls (e.g., PGP), but others argue this is a stretch since Kaspersky is closed-source commercial software, not a publication.
• Another view: this is not about speech but about cutting off a company seen as tied to a hostile state during wartime; selling AV into US infrastructure is framed as a national-security, not First Amendment, issue.

Trust, State Influence, and War Context

• Many argue a Russian-based AV vendor cannot be independent of the FSB, especially during Russia’s invasion of Ukraine, and that any AV is effectively a rootkit capable of exfiltrating data or silently whitelisting state malware.
• Counterpoint: the same logic could apply to US tech firms with ties to US intelligence; critics see a double standard where “our” intelligence is tolerated but “theirs” is grounds for bans.
• Some say Russia’s political system and war conduct (annexations, city destruction) make it qualitatively different from the US; others insist both powers behave badly and global diplomacy has broadly failed.

Kaspersky’s Technical Quality and Response

• Several comments note Kaspersky consistently scores very high in independent AV tests and was early in detecting sophisticated threats like NSA-linked “Equation Group” malware and possibly Stuxnet-like campaigns.
• Some suspect US hostility grew after Kaspersky exposed such tools; others call that a “childish” view and say the ban is about structural risk, not hurt feelings.
• Kaspersky’s relocation of data processing for some countries to Switzerland and offer of transparency centers is presented as evidence of good faith by supporters, but dismissed by skeptics as PR theater with weak auditing.

NSA Malware, Leaks, and Collateral Damage

• One camp claims ordinary users will almost never be targeted by NSA malware and that AV offers little protection if a state actor wants you specifically.
• Others counter that NSA tools and exploits do leak (e.g., EternalBlue → WannaCry; Stuxnet’s spread), causing large-scale collateral damage where strong AV and independent research matter.
• There’s debate over how controlled Stuxnet really was and how many non-target systems were damaged, with details acknowledged as partly unclear.

Broader Views on AV and Policy

• Some suggest banning all commercial AV due to misaligned incentives and deep system access.
• Others welcome the Kaspersky ban as overdue and urge Europe to follow, seeing it as part of a broader trend (alongside TikTok actions) of weaponizing control over widely deployed software.