Hacker News, Distilled

Political blame, mandate, and partisanship

• Commenters disagree sharply on who is responsible: the administration, Senate rules, House/Senate leadership, or both parties using the shutdown as leverage.
• Some argue Republicans could eliminate the 60‑vote filibuster and “just govern,” so claims they “need 60 votes” are seen as political choice, not legal constraint.
• Others blame Democrats for insisting on extending ACA subsidies as a condition to reopen, debating whether that is “extremism” or basic protection for millions’ healthcare.
• There’s a side debate over democratic legitimacy: does a plurality in a low‑turnout election equal a mandate? Some argue nonvoters implicitly accept the winner; others reject that as baseless.

Shutdown mechanics and comparisons

• Several posts explain that shutdowns stem from annual appropriations expiring; without new laws or a Continuing Resolution, agencies legally lose spending authority (post‑1980 Anti‑Deficiency Act enforcement).
• Some suggest automatic roll‑over of prior budgets or moving “essential services” like ATC into a separate, always‑funded track.
• Comparisons with Europe (Belgium, Westminster “loss of supply”) note that foreign “no government” situations usually don’t halt basic administration.

Air traffic cuts, safety, and operations

• The 10% capacity cut at 40 major airports is viewed as primarily a safety decision amid unpaid ATC and TSA staff. TSA delays of up to several hours are reported.
• One commenter lists the affected airports (essentially all major hubs). Others note that even non‑listed airports will be indirectly impacted via network effects.
• An airline operations perspective says carriers will likely pre‑trim schedules and “NOOP” flights, which eases logistics and maintenance but burns money and parking space.
• There’s concern that once back pay arrives, many ATC/TSA staff may quit after being forced to work without pay. Legal guarantees of back pay are cited but enforcement is doubted.

Class, inequality, and alternatives to flying

• Multiple comments stress that wealthy political and business elites, who use private jets, are insulated from commercial chaos.
• Proposals include grounding private and corporate flights during shutdowns.
• Some travelers are switching to rail, but detailed anecdotes show Amtrak can be slow, inconvenient, and fragile compared to rail and airports in Japan/Taiwan.

Accountability and structural reform

• Suggested fixes include: cutting or fining congressional and presidential pay during shutdowns, automatic snap elections if they last long enough, and funding agreed‑upon items separately.
• Critics argue such penalties would advantage wealthy politicians and encourage “war of attrition” politics rather than compromise.

What Happened

• Mozilla enabled an AI “SumoBot” / MT workflow on Japanese support KB articles.
• The bot auto-generated translations, auto‑approved them after ~72 hours, and appears to have overwritten or sidelined ~20 years of volunteer human translations, in production rather than staging.
• The long‑time Japanese locale leader publicly resigned, listing issues: violation of translation guidelines, ignoring existing Japanese localization choices, loss of control, lack of prior consultation, and objections to using their work as AI training data.

Reaction to Mozilla’s Reply

• The official response – “sorry for how you feel” + “hop on a call so we understand what you’re struggling with” – is widely read as:
  • A classic non‑apology that frames the problem as volunteers’ feelings rather than Mozilla’s actions.
  • Tone‑deaf and corporate (“hop on a call” for someone whose work you just trashed).
  • An attempt to move the issue off‑record into a private channel rather than address it publicly and concretely.
• A minority argue it’s a reasonable first response by a community manager with limited power, trying to gather details across language and time zones.

Machine Translation, Language, and Culture

• Many multilingual commenters say MT into Japanese is particularly bad: unnatural, wrong contexts, inconsistent terminology, and no awareness of local style guides.
• Even for European languages, several say “good enough” MT still produces atrocious UI text and documentation.
• Broader concern: LLM/MT flattens cultural nuance into an en‑US‑flavored generic style; people increasingly encounter auto‑translated threads and videos that “feel off.”

Process, Power, and Volunteers

• Core anger is about process and respect, not just quality:
  • No nemawashi / consensus building with locale teams; change was imposed top‑down.
  • Bot can overrule volunteers instead of serving them as an optional tool.
  • Doing this to unpaid contributors is seen as especially insulting; many say quitting is entirely justified.
• Some propose a better model: MT only as opt‑in suggestions, or for untranslated pages, with humans in control.

Licensing and AI Training

• Dispute over Creative Commons:
  • Some argue the contributor can’t now “prohibit” AI training on CC‑licensed text and that CC is irrevocable.
  • Others point to moral rights and unsettled law around whether models are derivative works, and argue legalities aside, Mozilla has clearly broken trust.

Bigger Pattern Noted

• Many tie this to a larger pattern: Mozilla chasing AI buzz, rolling out half‑baked features on live users, poor internal governance, and historic disregard for community feedback while marketing itself as community‑driven and “not like big tech.”

Bluetooth audio & mic quality

• Major recurring complaint: when a headset mic is enabled, audio degrades from acceptable stereo to “telephone‑grade” due to switching from A2DP to HFP/HSP, splitting limited bandwidth for duplex audio.
• Users report:
  • Non‑Apple headsets often sound unusably bad on calls.
  • AirPods subjectively degrade less because of better codecs and platform integration, though some say their mic is still poor for listeners.
  • In‑ear “earpod” mics are inherently disadvantaged by placement and size, but many argue the primary issue is codec/bitrate, not hardware.
• Workarounds:
  • Use laptop/desktop or external USB/desk/clip mics while keeping Bluetooth only for playback.
  • Prefer 2.4 GHz “gaming” headsets or wired options for better latency and duplex quality.
  • On desktops, forcing codecs (e.g., mSBC on Linux) can help but is fragile.

LE Audio, GMAP, and current support

• LE Audio (LC3, isochronous channels) is seen as the intended fix for:
  • Bad mic quality on headsets.
  • High latency.
  • The “10 kbps when mic is on” problem.
• In practice, support is scarce and messy:
  • Requires BLE 5.2+ with isochronous audio on both host and headset; many chipsets and OS stacks don’t support or expose it reliably.
  • GMAP (Gaming Audio Profile) specifically targets high‑quality duplex audio, but hardware that actually implements it is rare and often unstable, especially on Windows and Linux.
  • Users report broken or degraded features when enabling LE Audio (lost multipoint, missing battery info, assistant integration issues, app incompatibility).
• Some point to proprietary stacks/codecs (Qualcomm, Apple) as incentives not to fix these gaps quickly in the open standard.

Pairing UX and out‑of‑band ideas

• Opinions split: some say pairing “isn’t bad anymore,” others still find it unreliable or device‑specific.
• Good experiences: devices with explicit pairing buttons, or automatic USB pairing (game controllers, Apple peripherals).
• Bad experiences: “fast/quick pair” implementations, random entry into pairing mode, auto‑connecting or auto‑playing when merely powered on.
• Several commenters want a standard, secure USB or NFC “out‑of‑band” pairing flow; the spec allows OOB pairing, but actual implementations are proprietary and fragmented.

Specification size, ecosystem, and security

• The 6.2 core spec’s ~3,800 pages are seen as part of a long‑running trend of ballooning wireless and platform specs; many argue most devices still only implement a slice.
• Some view the complexity and cruft as a barrier for newcomers and a pain for developers, though others say hardware cost and certification matter more.
• There’s frustration that, despite the huge spec, basic needs like robust high‑quality duplex audio remain poorly addressed in shipping products.
• Open‑source stacks (e.g., BlueZ) support up to 5.4, but lack developers and lag hardware certification; Linux users especially report pain around modern audio features.
• Security perceptions are mixed: the core standard isn’t viewed as awful, but real‑world implementations can be exploitable (e.g., DoS attacks on TVs, recent eavesdropping vulnerabilities).

Climate Risk: Catastrophe vs Manageable Crisis

• Many see the piece as part of a broader shift from “existential apocalypse” rhetoric toward “serious but survivable” framing, paralleling some high‑profile philanthropists.
• Others argue that “civilization-ending climate change” was always mostly a strawman; mainstream science has focused on severe disruption, not human extinction.
• There is confusion and disagreement over what counts as “catastrophic”: from trillions in damages and mass migration to billion‑death scenarios or total societal collapse.

Science, Models, and Expert Authority

• Critics say the article is largely uncited opinion, downplays risks like AMOC collapse, and cuts off analysis at 2100, ignoring centuries‑scale impacts.
• Others respond that climate science has unsettled aspects, so experts need to show their work more carefully.
• Thread includes disputes over whether climate science is “well established” or still strongly contested beyond basic warming.
• Some cite scenarios and paleoclimate (e.g., Eemian, Eocene) to argue against human extinction; others counter that speed of change and human infrastructure make historical analogies misleading.

Impacts: Sea Level, Food, Migration, Conflict

• Sea-level rise of 2–3 feet is called either “manageable but expensive” (retrofit ports, seawalls) or “off‑the‑charts disruptive” given coastal populations, island nations, and shipping.
• Food systems are a major fault line: some see yield declines but no evidence for global collapse; others stress that global shocks can’t be offset by imports and could drive hoarding, famine, and war.
• Past refugee crises are invoked as a small preview of potential climate‑driven mass migration and associated political extremism and violence.

Moral and Justice Framing

• Several commenters emphasize moral duties to future generations and to non‑human species, seeing mass extinction and degraded everyday nature as intolerable even if “the economy survives.”
• Strong focus on inequity: people near the equator and in poor countries are expected to bear the brunt while rich countries adapt and even benefit.

Communication, Politics, and Behavior

• Some blame past alarmist messaging for social “bullying,” polarization, and eventual loss of credibility; others say the public simply misread long‑term risk as near‑term doomsday.
• There is frustration that individual behavior (e.g., flying less) contradicts expressed concern, reinforcing calls for systemic tools like carbon pricing.

AI Hero Image and Perceived Quality

• The AI-generated hero image with “CLMATE” misspelled is widely mocked and used as a heuristic that the article and editorial process are low-effort or unserious.

Brand damage from Musk’s politics

• Many argue Musk has “torched” Tesla’s core consumer base (especially environmentally minded, center/left buyers) through his politics and online behavior.
• Specific flashpoints mentioned: Nazi-salute-like gestures, promotion of extremist figures, anti-trans rhetoric, and general “drunk uncle”–style reactionary posting.
• Several commenters say they or their friends in Europe and the US have decided not to buy Teslas, or even sold existing cars, purely for ethical/brand reasons.
• Others push back that you can like the cars while disliking Musk, and that boycotting hurts 100k+ workers more than it changes Musk’s views. This group tends to frame his views as commonplace right-wing opinions rather than uniquely disqualifying.
• There is an extended side-debate about “woke left” vs right-wing identity politics, tolerance of intolerance, and whether focusing on identity issues is electorally effective.

Demand vs “battery-limited” narrative

• Some insist Tesla is still battery-limited, so adding models would just add complexity, not sales.
• Many others counter with the article’s data: German sales down ~50% year-to-date, broader EU sales reportedly down ~30%, plus price cuts, promotions, and underused factory capacity — all seen as classic signs of demand weakness.
• One faction attributes the Reuters framing to media distortion and “delivery waves”; others reply that multi‑month and YTD declines can’t be explained by shipping timing.

Product, quality, and competition

• Critiques: aging lineup (few genuinely new models besides Cybertruck), dated or odd styling, removal of physical controls (stalks, buttons) in favor of touchscreens, lack of CarPlay, and widely reported build-quality and service issues.
• Some say Teslas no longer lead on range, charging curve, or price vs quality; competitors (VW group, Hyundai/Kia, others in Europe) are seen as catching or surpassing them.
• Defenders highlight continuous over‑the‑air improvements, good value for money, and argue all EVs have quality problems; they dispute that Tesla is uniquely bad.

AI/robotics pivot and governance

• Several see Tesla’s “AI & robotics” positioning as partly a response to a weakening car business.
• There is concern about Musk creating xAI outside Tesla, allegedly shifting GPUs from Tesla to xAI, and then pushing Tesla to invest at a huge valuation — framed as a governance and fiduciary-risk issue for shareholders.
• Musk’s enormous pay package and sharply reduced long‑term volume targets (20M total by 2035 vs prior 20M/year ambition) are cited as signs of a captured, self‑enriching board.

Capitalism, Socialism, and “Solarpunk”

• Strong disagreement over whether the described model is “socialism with Afrofuturist aesthetics” or simply capitalism plus new tech.
• One side: this is textbook capitalism—small businesses selling panels, private ownership after payoff, markets lifting people from poverty.
• Others: emphasis on “power to the people” and local value capture looks closer to socialism or at least to democratised ownership vs oligarchic “capitalism”.
• Broader definitional debate: capitalism as markets vs ownership of capital vs degree of state planning; examples from USSR/China used on both sides to argue that tech alone vs capitalism+tech drove development.

Math, Claims, and Trust in the Article

• Multiple commenters pick apart the numbers:
  • $40–65/month vs “$0.21/day” don’t reconcile.
  • 3–5× yield increase vs $600→$14,000/acre revenue looks like a 20×+ change.
  • “$120 might as well be $1M” vs later “$100 down” also feels inconsistent.
• Some attempt charitable explanations (subsistence consumption, annual vs monthly figures, crop mix changing), but many conclude the arithmetic is simply wrong.
• Later, someone posts actual Sun King pricing to show that PAYG solar economics can be plausible, even if the article’s specific figures are sloppy.

AI Slop, Style, and Author Response

• Large subthread arguing the piece “reads like ChatGPT”: punchy one‑sentence paragraphs, repeated “here’s why this matters”/“the magic is this” constructions, LinkedIn-like hype tone, and basic math errors.
• Others push back: style ≠ proof; AI detectors are unreliable; humans also write formulaic, list-heavy prose.
• The author appears to state it was written while sick, not AI-generated, but suspicion persists; several note they now unconsciously imitate LLM style themselves.

Decentralized Solar vs the Grid

• Many see off‑grid solar + batteries as economically superior to building transmission in remote or corrupt environments; compared to rural electrification and mobile-phone leapfrogging.
• Counterpoints:
  • Reliability: batteries add 50–120% to system cost; hard to match grid “nines”, especially for night-time and winter loads.
  • Security: gangs/extortion, counterfeit panels, and regulatory barriers (permits, utility control) can erode benefits.
  • Equity: PAYG models electrify those who can pay; skeptics worry about leaving the poorest and public “universal service” behind.

China, Labor, and Supply Chains

• Recognition that China’s massive, subsidised build‑out of solar and batteries underpins low global prices and enables these African models.
• Disputes over how much is driven by cheap labor vs infrastructure/scale, and over the extent of forced labor and environmental damage in upstream supply chains.
• Some see this as a necessary transitional compromise; others as exporting pollution and exploitation while the West congratulates itself on “green” imports.

Repair, E‑Waste, and Sustainability

• Concern that millions of small solar kits fail soon after payoff, with little local capacity to repair, creating a fast‑growing e‑waste stream.
• Reports cited: large share of devices repairable but high transaction costs (travel, lost income) make centralized repair uneconomic.
• Ongoing efforts to train local technicians and embed repair labs are presented as crucial for a genuinely “solarpunk” outcome rather than a short‑lived, debt‑driven boom.

Breakthrough fatigue and skepticism

• Many commenters say they’ve seen nearly identical “tooth repair” stories for 15–30+ years, likening this to recurring hype about fusion, graphene, solid‑state batteries, AGI, etc.
• Key distinction raised: if this were an approved commercial product making clinical claims, it would be huge news; as a university press release based on preclinical work, it’s “nearly meaningless” until human trials.
• One person notes only a small fraction of early human studies ever reach phase 3 and approval; this gel is still at tooth/analogue-in-dish stage.

Context: real medical progress vs vaporware

• Several point out that HIV and many cancers have seen major advances: HIV is now a chronic, well-controlled disease for most; some cancers have immunotherapies and extended survival.
• Others list hair regrowth, male birth control, Alzheimer’s cure, tooth regrowth as areas that still feel perpetually “almost here”.
• There’s discussion that progress often looks like decades of slow improvement followed by sudden visible breakthroughs (e.g., weight‑loss drugs).

Tooth repair and regrowth landscape

• Commenters recall many enamel‑regeneration and stem‑cell tooth replacement announcements (e.g., sound‑wave regrowth, stem‑cell teeth, USAG‑1 research) that never reached clinics.
• One notes ART with high‑viscosity glass ionomer cement has effectively addressed caries in some regions since the 1980s, but is underused in the US due to entrenched drilling/filling business models.
• Others mention ongoing work on inducing a “third set” of teeth via developmental pathways, with concern about targeting and safety.

Existing remineralization products

• Long discussion of products like:
  • Novamin (calcium sodium phosphosilicate, in some Sensodyne variants outside the US).
  • Nano‑hydroxyapatite pastes (e.g., Apaguard, Boka, tabs), often reported to reduce sensitivity and aid remineralization.
  • CPP‑ACP (Recaldent, GC Tooth Mousse), Enamelon, Biomin F.
• Experiences are mixed but several report measurable reductions in sensitivity and, occasionally, reversal of early lesions; others see little difference.
• Regulatory differences (cosmetic vs drug claims) are cited as reasons some formulas aren’t sold or fully labeled in the US.

Science communication and academic incentives

• Multiple comments blame “publish or perish”, KPI‑driven academia, and PR‑heavy university press offices for overhyping early-stage findings.
• Concerns about p‑hacking, poorly designed studies, and lack of reproducibility are seen as eroding public trust.
• Some argue HN links should go to the actual paper (which is open access) rather than to institutional PR.

Dentistry practice, economics, and technology

• A practicing dentist says if cavities vanished, dentistry would shift but not disappear: there would still be gum disease, fractures, wear, implants, bite and cosmetic work.
• Others speculate fewer dentists would eventually be needed, similar to what would happen if obesity suddenly plummeted.
• Noted tech improvements: 3D intraoral scanning and SLA 3D printing for crowns and fixtures; sonic scalers for cleanings.
• At the same time, some low‑hanging comfort fixes (e.g., using lukewarm rinse water) are still often ignored.

Oral hygiene and product debates

• Flossing: cited systematic reviews/meta‑analyses suggest weak evidence for caries prevention but some support for gum-disease reduction; users point to technique issues and self-report bias.
• Mouthwash: one commenter claims emerging research shows daily antimicrobial/alcohol-based rinses may harm the oral microbiome and raise certain risks; others ask for references.
• Xylitol gum: said to reduce cariogenic bacteria and support remineralization indirectly, but not itself a mineral-depositing agent.
• Several mention anxiety, access problems, and personal trauma around dentistry, plus the role of sugar and alcohol in tooth decay.

Implants, artificial teeth, and natural dentition

• One provocative take suggests replacing all teeth with artificial ones if rich; many others strongly disagree, stressing that natural roots and periodontal ligaments provide shock absorption and better long‑term function.
• People with implants report upper‑jaw implants can be fragile and uncomfortable compared to natural teeth; flexible, “shock absorber” implant designs are mentioned as emerging tech.

Pandemic “National Emergency Library” Decision

• Many see IA’s uncapped lending during COVID as morally justified: digital access when physical libraries were closed, and a public good publishers should have praised, not sued.
• Others call it a “boneheaded” stunt: clearly illegal “dropping the C from CDL,” sabotaging the stronger legal position of controlled digital lending and triggering a lawsuit publishers had long hesitated to file.
• Some frame it as breaking a MAD-style balance: IA had operated for years without suit; the emergency move “pulled the trigger” and lost.

Copyright: Reform vs. Enforcement

• Broad agreement that copyright terms and DMCA abuse are broken; some want the entire system torn up or time-limited by medium (e.g., short terms for programming books, TV).
• Counterpoint: copyright is still the legal basis even for permissive licenses and is needed so authors, editors, and other creators can earn a living.
• Debate over whether most authors make real money from books, especially older works, and whether many now rely on speaking, courses, or “personal brand” instead.

Role and Risk-Tolerance of IA

• One camp: IA should stop tying high‑risk experiments to the core institution; it’s too important (Wayback, historical media) to jeopardize with “kooky” copyright fights. Proposals include a separate, more conservative mirror organization.
• Other camp: IA’s value comes precisely from “eccentric, untamed idealism”; without that boundary‑pushing, projects like the Wayback Machine might never have existed.

Corporate Double Standards, AI, and Google Books

• Some argue there’s a double standard: profit‑driven giants (OpenAI, Google) can mass-copy works for models or search; idealistic public-access projects get crushed.
• Others insist IA’s book lending is legally different from private training datasets or snippet search, and that equating them is misleading.
• Google Books is cited both as a clear fair‑use legal win and as a practical loss, since much material vanished or became snippet‑only.

Libraries, Capitalism, and Piracy

• Claim that if public libraries were invented today, publishers would sue them out of existence; only historical precedent and billionaire philanthropy entrenched them.
• Pushback: current public libraries lend one copy at a time; IA tried to go beyond that, closer to a shadow library.
• Long subthread on piracy: some point to studies suggesting little sales harm and note pirates often buy more; others emphasize friction, institutional piracy (universities skipping purchases), and the risk of automated derivative works undercutting originals.

Importance and Fragility of the Archive

• Strong consensus that IA/Wayback is irreplaceable: a “last pre‑slop snapshot” of the web and media history otherwise lost.
• Concern over centralization and legal risk: mention of a full copy in Alexandria, calls for more independent mirrors and torrent-based replication.
• Estimates of IA’s size vary in the thread (hundreds of TB to ~15 PB+), and feasibility of multi-region replication is left unclear.

Current SIMD Options in Rust

• Consensus on guidance from the article:
  • Use std::simd on nightly if possible.
  • Use wide for stable Rust without multiversioning.
  • Use pulp/macerator when you need multiversioning and portability.
• Some large projects use nightly std::simd in production, while avoiding the most unstable APIs.
• Stable std::arch intrinsics for x86, ARM, and WASM are widely used for non‑portable, target-specific SIMD.

Why std::simd Isn’t Stable Yet

• Stabilizing portable SIMD is seen as a “massive hard problem”:
  • Needs to abstract many heterogeneous ISAs while balancing performance and ergonomics.
  • Subject to Rust’s strong stability guarantees; once shipped, API mistakes are very hard to fix.
• Blockers mentioned:
  • Dependence on unstable building blocks (e.g., const generics, generic_const_exprs, trait solving).
  • Interactions with safety, coherence, object safety, error reporting, etc.
  • LLVM SIMD intrinsics can be volatile and have caused ICEs and codegen issues.
  • Unclear how to support scalable SIMD ISAs like RISC‑V vectors or ARM SVE with today’s fixed-lane design.

Rust Governance, Priorities, and Funding

• Compiler and language work is largely volunteer-driven; there are few people who can prioritize stabilization work.
• High bar for quality in std, plus no BDFL to “just decide” when something is good enough.
• Some argue Rust made too many global promises (safety, semver, trait coherence), which slows or kills complex features.
• There is concern about underfunding of core compiler work despite corporate use; a maintainers fund has been started.

Autovectorization and Floating Point

• Many workloads can get good SIMD via autovectorization + careful loop structure, especially for integers.
• For floats, aggressive reordering is blocked by IEEE-754 semantics; Rust lacks a stable equivalent of -ffast-math.
• Nightly offers “algebraic” float operations and _fast intrinsics as an opt-in, but these require explicit, awkward APIs.
• Some users want a more ergonomic, scoped “fast math” mechanism; others warn about the dangers of global flags.

Ergonomics, Multiversioning, and Abstractions

• Runtime feature detection + #[target_feature] is described as painful: attributes must be propagated or forced via #[inline(always)], making abstractions and reuse harder.
• Workarounds exist (traits over vector types, generic algorithms instantiated per-ISA) but are fragile and often rely on unsafe.
• Keeping data in SIMD form across a pipeline and handling packing/unpacking correctly is a recurring complexity.

Comparisons to Other Languages

• C# is seen as having a more mature, stable SIMD story (portable vectors + intrinsics), partly due to strong corporate backing.
• Java and Go are described as weaker on SIMD; Go currently relies on awkward assembly, though intrinsics are being worked on.
• Some argue Rust leans too much on LLVM and underinvests in higher-level, predictable autovectorization compared to C/C++ ecosystems.

Architecture & Platform Support

• Dillo uses the FLTK GUI toolkit (moved from an early GTK+ codebase around Dillo 2).
• FLTK has been ported to DOS; there were DOS/Windows ports of Dillo 3.0, but they never landed upstream. Maintainer is open to merging them if someone helps update the code.
• FLTK 1.4.x currently breaks many things in Dillo; experimental support is planned behind a configure flag in an upcoming 3.3.0 release.

Project Status & Infrastructure

• Active development continues, with recent 3.x releases and adherence to semantic versioning.
• The project is moving off GitHub to its own site, cgit repos, and a custom “buggy” bug tracker where issues are Markdown files stored in git.
• Motivation: speed, offline use, JS-free workflows, interoperability outside a corporate walled garden, and minimal bandwidth.

Design Philosophy, JS, and the Modern Web

• Dillo intentionally has no JavaScript support; many commenters see this as therapeutic and a feature, not a bug.
• This exposes how much of the modern web is JS-gated: Google Search and Maps now block non-JS browsers; alternatives like DuckDuckGo Lite and Startpage still work.
• Some argue any site requiring JS for basic functionality is “a bad website” and should be avoided; others note this makes Dillo unusable for many everyday sites.

Performance, Use Cases & Comparisons

• Widely praised as extremely fast and lightweight (tiny binary, runs well on 40–64 MB RAM, old laptops, netbooks, BSD on i386, OLPC, PDAs).
• Often contrasted with NetSurf: NetSurf is more standards-compliant and familiar; Dillo is lighter, more brutalist, and more idiosyncratic.
• Users report success on modern low-power devices (e.g., ARM tablets), using curated “lightweight” sites.

Standards & Compatibility

• CSS support exists but is incomplete; an old CSS compatibility page is acknowledged as outdated.
• Maintainer views Web Platform Tests as the best indicator of support and has experimented with integrating them, but many tests require JS.

Security & Sandboxing

• Some concern that “ultralight” might also mean light on security features.
• Maintainer has experimented with pledge and Landlock; proper multi-process isolation would require internal redesign and is a longer-term goal. Short-term: CSS/images and specific image decoders can be disabled.

Related Projects & Ecosystem

• Discussion touches on various forks (Dillo+, Mobilized Dillo) and alternative lightweight engines (e.g., a Rust-based engine reusing Servo components).
• Dillo is cited in “suckless” circles and remembered from Damn Small Linux and other minimalist distros.

What Actually Changed in the Policy

• Many commenters argue this is mainly a terms-of-service / liability update, not a hard technical block.
• Distinction emphasized:
  • Still allowed: individuals asking ChatGPT about their own health or legal situation.
  • Disallowed: using ChatGPT to provide licensed advice to others (e.g., “AI doctor/lawyer” products, custom GPTs marketed as such).
• Some users report recent refusals on medical questions; others see no behavioral change, leading to confusion about whether the system or just the written terms changed.
• The article itself was later corrected to say model behavior has not changed.

Anecdotes of Medical “Success” vs Limits

• Multiple stories where ChatGPT surfaced rare or overlooked diagnoses or conditions (intestinal/birth defects, congenital issues, stroke risk), sometimes matching or beating doctors’ diagnostic lists.
• Others stress these are anecdotes with heavy bias: prompts are often informed by hindsight, and users may unconsciously steer the model.
• Several note that the primary value is helping patients understand terminology, tests, and options, and prepare better questions for clinicians.

Hallucinations, Sycophancy, and Self‑Diagnosis

• Many examples of dangerously wrong advice in construction, electrical work, woodworking, and basic trades, used as a warning for medical/legal reliance.
• Concern that LLMs eagerly confirm user biases, especially around mental health or rare diseases, and can be “coaxed” into any diagnosis with iterative prompting.
• Comparison to WebMD: ChatGPT is more flexible and persuasive, which can amplify hypochondria and bad decisions.

Liability, Licensing, and Professional Protection

• Broad agreement this is driven by fear of lawsuits and medical‑device / unauthorized‑practice regulations, not “AI doom.”
• Debate over whether doctors/lawyers are being protected as a guild vs legitimately shielding the public.
• Some foresee specialized, regulated “professional” AI products for clinicians and lawyers, with ordinary users pushed to weaker or more constrained tools.

Broader Concerns

• Worry that restrictions will push people to less constrained (and possibly worse) models or jurisdictions.
• Frustration that marketing oversells AI as near‑omniscient while fine print and policies insist outputs are untrusted and not actionable.

Overall quality and user experience

• Many users report surprisingly good recommendations from just a few books; often 70–95% of suggestions are titles they’ve already read and liked.
• Others find results “fine but not magical”: too close to bookstore-style “more of the same”, dominated by popular titles and bestsellers.
• Works better with 3+ books or Goodreads import; one‑book inputs tend to add generic popular titles.
• Site speed, simplicity, and lack of popups/logins are widely praised.

Series, authors, and diversity

• Common complaint: recommendations over-focus on:
  • Later books in the same series.
  • Many titles from the same author.
• Users want:
  • Option to hide sequels and/or authors already in the input.
  • Visual cues or separate sections for “in series” vs “other” books.
  • More diverse lists (fewer near-duplicates, less author/series repetition).
• The author acknowledges series handling is the biggest weakness and has added a diversity reranker (e.g., maximal marginal relevance).

Negative feedback, novelty, and long tail

• Strong desire for explicit negative signals:
  • Mark “read, liked”, “read, didn’t like”, “hide”, or “meh” and rerun.
• Many want better discovery:
  • Less emphasis on extremely popular books (Harry Potter, Sapiens, 1984, etc.).
  • Options to surface rarer / long‑tail titles and “deep cuts”.
  • Multiple recommendation modes (comfort zone vs exploration/serendipity).

Intersect feature

• Concept (finding users who read multiple given books) is praised as powerful for hidden gems.
• In practice, several users get:
  • No matches for long lists.
  • Only huge, likely fake accounts with tens of thousands of books and no ratings.
• Suggested improvements:
  • Near matches when no exact overlap.
  • Filter by shelf size, remove obvious bots.
  • Optionally consider ratings (not just “read”).

Technical and architectural discussion

• Author uses a SASRec-style sequential transformer for “next book in sequence”.
• Other practitioners suggest exploring HSTU/OneRec, BERT4Rec, TIGER, and hybrid stacks (content-based, graph-based, TF‑IDF/BM25) combined for novelty and serendipity.
• Infrastructure details (Hetzner server, Meilisearch ~40GB, GPU inference) and “how it works” attract interest; some ask for open-sourcing and an API.

Scraping, legality, and ethics

• Significant debate over scraping 3B Goodreads reviews:
  • Critics cite robots.txt and ToS; some reviewers feel their work was “stolen” or used without consent.
  • Others argue the data is already public and heavily scraped; see this use as relatively harmless and noncommercial.
  • Legal status of redistributing the dataset is seen as risky; the author declines to share raw data and points to an academic dataset instead.
• Some users request removal of their data from the system; others express general discomfort with their reviews being used for ML at all.

Safety and privacy concerns

• Worry that the “intersect” feature could be abused to profile readers of controversial books.
• Suggestions to treat some titles as “always private” for intersections or allow community-maintained sensitive lists.
• Author notes Goodreads itself already exposes similar user–book associations, claims not to include private accounts, and offers an opt‑out mechanism.

Scope: what age does vs what GPG/PGP does

• age is praised as “super clean” because it only does file encryption; some see this narrow scope as its main virtue.
• Multiple commenters argue that calling this “switching from GPG” is misleading unless it explicitly means “for file encryption only.”
• GPG/PGP are described as multi‑purpose: encryption, signing, key management, web of trust, email integration, smartcard use, SSH auth, commit signing, release signing, multiple recipients, revocation, etc.
• age does not cover signing, identity, web-of-trust, or key discovery; minisign/signify only cover signing. None are viewed as full PGP replacements, just simpler subsets.

Who actually uses PGP, and for what

• One camp claims almost everyone outside a small niche only ever used GPG for one-off file encryption, so age is sufficient and more adoptable.
• Another camp argues PGP is still foundational: used by Linux distributions and critical infrastructure for package signing, by security teams for disclosures, and by serious engineers for commit signing, reviews, SSH, passwords, etc.
• There’s disagreement over how often PGP is actually used in bug bounties and disclosures; some say PGP-encrypted reports are rare and not correlated with severity, others say they are rare but high quality and important.

Identity, public keys, and “security theater”

• A workflow where admins demand a public key before sending credentials via Slack is debated.
• Critics argue this is “security theater” if the key is not authenticated; it doesn’t solve identity verification.
• Defenders note that PGP provides mechanisms (fingerprints, web of trust, key signing, Keyoxide-style proofs), but admit the specific described workflow omits them.
• There’s broad agreement that identity verification is orthogonal to the crypto primitive; without independent key verification, any scheme is weak.

PGP as “digital passport” vs overcomplex relic

• Advocates frame PGP as the only broadly standardized decentralized cryptographic identity layer (“internet passport”) and emphasize smartcards, long-lived keychains, backup, rotation, discovery, and revocation.
• They highlight modern tooling (e.g., keyfork, AirgapOS, smartcards, Keyoxide, WKD, new keyservers) as mitigating old UX and keyserver problems.
• Critics argue PGP/OpenPGP itself is a 1990s design with deep architectural issues, not just bad implementations like GnuPG. They liken it to OpenSSL used for everything and say most competent modern systems prefer more purpose-built tools.
• A recurring tension: PGP’s “Swiss Army knife” nature vs the modern preference for small, composable tools (age, minisign, SSH signing).

SSH keys, signing, and supply-chain security

• Some use SSH keys for Git tag and binary signing (with GitHub’s verification UI) and find this much easier to deploy than PGP.
• Others call SSH signing an abuse: SSH keys were meant for session auth, not long-lived signatures; using one key for multiple roles complicates rotation and revocation.
• There’s debate whether identity management and key discovery should live inside the cryptosystem (PGP-style) or in higher-level, domain-specific layers.

Agents, password managers, and web auth

• gpg-agent is valued for SSH-agent functionality and letting tools like pass keep secrets encrypted at rest; this is a sticking point for some considering migration.
• Others complain GPG’s smartcard behavior (e.g., lack of PIV/PKCS#11 support) interferes with other applications and prefer to remove it.
• Several age-based password managers and agents are mentioned as alternatives, with people reporting successful real-world switches.
• There is curiosity (but no clear answer) about using gpg-agent/gpgme-json for WebAuthn/passkeys; capabilities here remain unclear in the thread.

Post-quantum concerns

• Some question whether age is “post-quantum.”
• Discussion notes: age uses a symmetric file key plus public-key wrapping; symmetric keys are 128-bit, and current public-key algorithms are not PQ.
• One comment (citing the age author) claims 128-bit symmetric keys are sufficient for PQ security and that PQ public-key integration is blocked in standards bodies; others still recommend waiting for fully PQ-safe public keys before migrating for long-term archives.
• There is general unease about adopting new non-PQ schemes in 2025 for long-lived backups, though opinions differ on urgency.

Adoption, complexity, and philosophy

• age is seen as far easier to introduce into teams than GPG, which many consider a non-starter due to UX and conceptual overhead.
• Pro-PGP participants argue that the complexity reflects real requirements (backups, rotation, non-centralized trust) and that lighter tools ignore these and set users up for future failures.
• Opponents counter that most real-world users don’t need or use those features, and that PGP’s complexity and poor ergonomics have prevented it from fulfilling its own ambitions outside a small, specialized community.

Questioning the premise

• Several commenters argue the premise is shaky: meta-analyses show only tiny correlations between IQ and self‑reported happiness, and in many data sets smarter people are slightly more satisfied.
• Others note happiness appears strongly dispositional/genetic with a personal “set point,” so expecting intelligence to shift it much may be a category error.
• Some say the question is like asking “Why aren’t tall people kinder?”—intelligence and happiness are largely orthogonal traits.

Definitions and measurement

• Long debate over what “smart” means: IQ, problem‑solving, creativity, emotional intelligence, wisdom, or real‑world “poorly defined” problem solving.
• Likewise, “happiness” is variously framed as pleasure, life satisfaction, contentment, lack of suffering, or meaning; many think the term is too vague.
• Self‑report surveys of happiness are criticized: people interpret “Are you happy?” relative to different baselines, answer styles may differ by intelligence, and the hedonic treadmill keeps average scores flat despite material progress.

Why intelligence might reduce happiness

• Awareness: smarter people may better see systemic injustice, suffering, power imbalances, propaganda, and existential risks—“ignorance is bliss.”
• Overthinking: rumination, “paralysis by analysis,” thought spirals, and trying to solve emotional problems with abstract reasoning can fuel anxiety and depression.
• Expectations: gifted kids are told they’ll do great things, then collide with ordinary constraints, diminishing returns, and failure; high standards and perfectionism undermine satisfaction.
• Social mismatch: being far from the mean IQ can lead to loneliness, feeling “out of sync,” being resented or sabotaged, or bullied as “weird.”
• Identity: some smart people tie self‑worth to success, career status, or being “the smart one,” which makes setbacks and ordinary outcomes feel like personal failure.

Why intelligence might help or not matter

• Others argue intelligence improves income, health, problem‑solving and thus should raise average life satisfaction; any lack of correlation may be due to overcontrolling variables or bad happiness measures.
• Multiple commenters stress emotional intelligence, virtues, relationships, and wisdom as far more central to well‑being than raw cognitive horsepower.

Society, work, and meaning

• Many point to capitalism and modern work: endless promotion games, “solving imaginary problems” in tech, consumerist messaging that stokes discontent, and social media outrage.
• Smarter people may see the “cage” more clearly but still feel trapped in it, especially when doing work they perceive as pointless.

Suggested antidotes

• Recurrent themes: cultivate gratitude, contentment, close relationships, community with intellectual peers, philosophy or spirituality, and focus on meaning or contribution rather than chasing happiness directly.

How the hidden connectivity was found

• Commenters say Norwegian testers used a “Project Lion Cage”-style setup: vehicles taken underground / into a Faraday-like environment with spectrum analyzers to see where they transmit.
• Romanian SIM cards were physically found; some speculate eSIMs would be harder to spot physically but still discoverable via RF testing.

Capabilities and risk of remote access

• The undisclosed connection allowed: software updates, diagnostics, and control of battery/power systems; test team concluded buses could be remotely stopped or bricked.
• Several note: bricking via OTA is trivial; making OTA safe and reliable is the hard part.
• Others worry about more extreme scenarios (e.g., overheating batteries, coordinated shutdowns), though some think safety hardware and physical fuses limit worst‑case outcomes.

“This is normal” vs “this is different”

• One side: essentially all modern vehicles have SIMs, telemetry, OTA updates; John Deere, Tesla, eCall, etc. Already remotely updatable or disable‑able in practice.
• Other side: these SIMs were not disclosed in procurement; this is far beyond simple diagnostics and not “standard” for road vehicles, especially for critical infrastructure.
• Disagreement over how many cars/buses are truly “fully remotely controllable” versus just updatable.

Broader cybersecurity and IoT concerns

• References to Polish trains with anti‑repair geofencing and GPS “kill codes”; car hacking research; worries about a future worm (Petya‑class) hitting huge IoT and vehicle fleets.
• People highlight similar or worse backdoors in Western tech (motherboards, routers, smart home gear, hospital devices) and note that if your transport is online, it can in principle be hacked.

China, politics, and procurement strategy

• Split between those seeing justified national‑security concerns (Chinese state‑linked firms, ability to disrupt logistics in war) and those seeing trade‑war FUD and selective outrage.
• Extended debate about EU blocking a big European train merger vs fear of a dominant Chinese rail/bus supplier; tension between antitrust, corruption in tenders, and security‑driven protectionism.
• Some advocate outright excluding Chinese vendors from critical contracts or imposing tariffs; others prefer stricter software/audit rules applied to all suppliers.

Why buses are online & proposed mitigations

• Practical reasons cited: live location tracking, accurate arrival times, remote CCTV viewing, diagnostics, and OTA maintenance.
• Proposals include: mandatory source disclosure to regulators with reproducible builds, third‑party audits, and ripping out opaque “black box” controllers where trust is impossible—while others note you can’t truly prove the absence of backdoors.

Capabilities and Architecture

• OpenPCC is described as essentially an attested, anonymous HTTP server wrapper: “inference” is the first workload, but any HTTP-based workload (e.g. anonymization pipeline) can run inside the compute node.
• One suggested use: wearables or AR devices sending sensitive logs (e.g. faces) through OpenPCC to an anonymization service, so developers can debug without seeing raw private data.
• If anonymization can be done on-device, commenters note that’s simpler, but OpenPCC provides a server-side option.

Privacy Guarantees and Limitations

• The system aims to ensure that operators of inference hardware cannot see prompts, via TEEs/vTPMs, attestation, and no SSH/administrative access.
• Clarification from the implementers:
  • Clients only talk to nodes that present valid attestation bundles.
  • Compute node filesystems are measured (e.g. via dm-verity) and published in a transparency log; in practice this implies source publication for those images.
  • Prompts are encrypted to node-specific keys that live only in the vTPM; a different machine cannot decrypt them.
• Multiple commenters warn against overstrong claims like “no one can see your prompts,” noting TEEs typically do not meaningfully resist physical attacks by a determined operator or state.

Comparison to Other Confidential-Compute Efforts

• Compared with simpler setups (VPN + anonymous crypto payments + direct inference provider), this adds attestation and “non-targetability”: the idea that even a compromised operator cannot reliably steer a specific user’s traffic to a compromised machine.
• Apple’s PCC, AWS Nitro Enclaves, Azure confidential inference, and GPU enclaves from NVIDIA/AMD are cited as similar or adjacent systems.
• Some argue cloud TEEs still boil down to “trust the provider’s tooling and hardware vendor,” versus hardware-only roots of trust.
• Another project (privatemode.ai) is mentioned as a commercial analogue; licensing differences (Apache 2.0 vs BSL) are noted.

Legal and Abuse Considerations

• A long subthread debates whether truly private/censorship-resistant compute enables storing illegal material (e.g. CSAM, stolen secrets) that providers cannot detect or selectively remove.
• Others counter that encrypted blobs are already widely hosted (e.g. cloud storage) and point to existing liability regimes (e.g. takedown-on-notice, Section 230, banking analogies like safe deposit boxes).
• Anonymous crypto payments in the EU may be restricted or effectively treated as money laundering; status is described as unclear but trending restrictive.

Threat Models and Trust Roots

• Some commenters insist that physical access by operators (or state actors) means privacy cannot be “provable”; live migration and hardware attacks are discussed as realistic vectors.
• There is debate about which root of trust is acceptable (US vs European vendors, intelligence-agency influence, secret courts).
• Apple PCC’s “non-targetability” and heavy reliance on independent auditing are seen as raising the bar but still not eliminating the need to trust large vendors.

Use Cases and Skepticism

• One thread questions what non-malicious workloads people would actually run this way; others respond that any remote LLM use on proprietary or sensitive data is a natural fit.
• Concrete examples include: private code analysis, debugging helpers, or cross-component tracing on large, proprietary codebases where outputs can be verified but inputs must stay confidential.
• Some participants see privacy as inherently desirable even for ostensibly non-sensitive or open-source-related work; others are more skeptical and emphasize running local models instead when feasible.

Miscellaneous

• There is support for the project’s open-source/Apache 2.0 approach and availability of source and attestation, contrasted with closed or BSL’d alternatives.
• Clarification that despite “chatbot” branding, the architecture is generic and can host arbitrary HTTP workloads.

Smalltalk’s Image: Power and Controversy

• Many comments highlight the “image” (a snapshot of the entire object graph) as Smalltalk’s most impressive feature: live state can be frozen, moved, and resumed, even across decades of evolution.
• Others argue the same concept limited appeal: shipped images captured opaque, one-off states with no obvious build recipe, unlike today’s library‑ and file‑based ecosystems.
• Some note that modern systems (macOS autosave, giant shared-library images, Docker) have gradually reinvented parts of this idea.

Versioning, Build Discipline, and Team Workflows

• Critics claim images encouraged “cowboy coding” and made multi‑developer work and reproducibility hard.
• Defenders respond that Smalltalk had method-level versioning, change logs, and sophisticated tools like Envy/Monticello and team workflows since the 1980s; the image should be treated as a throwaway cache, not the source of truth.
• A recurring theme is that real pain points were lack of modularisation and global namespaces, plus cultural habits, not inherent image technology.

Malleability, End Users, and Comparisons with the Web

• Smalltalk’s full introspection means end users can, in principle, inspect/modify everything. Some see this as a nightmare, others as a freedom feature akin to browser devtools.
• In practice, deployed images can be stripped of tools, locked down, and wrapped as normal executables. Some systems also reset state on startup.

Deployment, Tree Shaking, and “OS Within an OS”

• Questions about how commercial Smalltalk apps were delivered get answered: packagers “shake the tree”/strip dead code from the image, add a small native launcher, and ship a single executable.
• The runtime can be made indistinguishable from a normal native app; no development UI needs to be exposed.

Live Environment vs Reproducibility

• Several people praise the “you are in the running environment” experience: halt‑and‑continue, editing missing methods at breakpoints, and zero restart cost.
• Others emphasize that this conflicts with reproducible debugging; they prefer deterministic replays, property-based testing, and database-backed workflows.

Smalltalk, Ruby, and Other Descendants

• Ruby is seen as inheriting Smalltalk’s object model but not its image‑centric workflow; Rails pushed Ruby toward conventional file/VCS tooling.
• Java is said to have “won” partly by being free, integrating better with existing tools, and being championed by vendors who had previously backed Smalltalk.
• Newspeak, Elixir, and modern IDEs are mentioned as spiritual or partial successors to Smalltalk’s ideas, though none fully replicate the original image-centric vision.

Where TUIs Still Run Critical Work

• Commenters report TUIs still active in retail (big-box chains, warehouse clubs, specialty stores, restaurants/bars), logistics and trucking, lumberyards, agriculture equipment service, utilities, insurance, banking, telecom, medical/billing, postal systems, universities/libraries, and manufacturing/ERP.
• Many run on AS/400, mainframes, HP3000, AIX/Unix, SCO, Pick, MUMPS, COBOL, xBase (dBase/FoxPro/Clipper), and even 80s home computers under emulation or original hardware.

Why Businesses Keep TUIs

• Core reasons: reliability, low operating cost, and the risk/expense of migration from heavily customized, poorly documented legacy logic.
• For many SMBs, the existing system “does everything we need,” and rewriting would not clearly pay off.
• Hardware is often virtualized/emulated instead of replaced, extending life further.

Efficiency, Speed, and UX Characteristics

• Strong consensus that well-designed TUIs are extremely fast:
  • Keyboard-only control, no mouse travel.
  • Fixed layouts with no scrolling, so information always appears in the same place.
  • Input buffering/type-ahead lets expert users enter multiple screens of actions before the system finishes drawing.
  • Stable hotkeys and menus allow deep muscle memory; operators can process orders in real time as customers speak.
• Several recount major productivity drops when TUI systems were replaced by “modern” GUI/web front-ends.

Training, Labor, and Discoverability

• TUIs are repeatedly compared to musical instruments or Vim: steep initial learning curve, very high ceiling.
• Works best where employees stay long and perform repetitive domain-specific workflows.
• Some argue today’s higher turnover and casual/consumer users push toward GUIs with better discoverability and less training.

Arguments for Modern GUIs/Web UIs

• Some point out that GUIs can be just as keyboard-centric and fast, but rarely are designed that way; modern UX often prioritizes aesthetics, marketing, and developer convenience over efficiency.
• Others are skeptical of the “perfectly tuned old TUI” narrative, noting that many such systems are unmaintained, bug-ridden, and effectively held together by user workarounds.

Modernization Patterns and Tools

• Common strategies: wrap TUIs with web/GUI shells, expose APIs, scrape via terminal emulators/SendKeys, or replicate TUI behavior in web SPAs.
• Several mention modern TUI frameworks (for Rust, Python, Go, etc.) and hybrid systems: TUI for internal power users, GUI/web for external or occasional users.

Meaning of “non-digital / analog”

• Several commenters note the title is misleading; the site doesn’t claim the car is analog, just retro.
• “Analog” is interpreted as “no screens / touch UI,” not “no electronics.” People stress that EVs must have digital controllers (BMS, inverter, charger, etc.).
• Some discuss that even old cars with dials used stepper motors and ECUs; lay use of “analog” is mostly “no displays or apps on the dash.”

EV components, standardization & repairability

• One detailed comment explains that many EV components are shared across platforms: motors, inverters, onboard chargers, DC/DC converters and connectors are often supplier-made and somewhat interchangeable.
• Battery packs are usually model‑specific; modules may be shared within a brand; cells are generic but hard to replace; BMS is typically bespoke.
• Swapping components often requires OEM coding or firmware, with expensive or locked tools; aftermarket support is sparse, so DIYers rely on salvaged parts and cracked software.
• This is framed as a continuation of broader modern-car trends, not unique to EVs.

Connectivity, privacy & “offline” cars

• Strong desire for EVs that are not cloud-connected; many would accept analog-style controls or BYOD infotainment if it meant no tracking.
• Examples cited: removing SIMs, unplugging telemetry modules, and concerns over hidden modems, “placebo” SIMs, and mandated systems like eCall.
• Some argue that connected features (remote climate, maps, charger data, eCall) are genuinely useful; others want an “airplane mode” with hard guarantees, logging, and third‑party audits.
• Debate over whether companies would go as far as covert SIMs; some call this paranoia, others point to broader patterns of telemetry and dark patterns.

Price, market positioning & practicality

• Base price around €44.5k ex‑VAT (~€54k with Dutch VAT) leads many to categorize it as a “toy for the well‑off” or a second/third car, not a people’s EV.
• Others counter it’s comparable to a Tesla Model 3 or hot hatch and not “country club only” money, especially given low-volume EU manufacturing.
• Seen as closer to a leisure roadster (MX‑5 / Porsche 356 homage) than a family car or Ikea hauler.

Design, specs, charging & safety

• Praised for being small, light (~590–630 kg) and visually classic; criticized by some as toy-like or plasticky.
• Concerns about the shiny metal dash causing glare; multiple calls for matte/wood/leather options.
• Modest power (~56 hp) and lack of visible modern safety systems (airbags, advanced driver aids) prompt worries about crashworthiness; many frame it as an acceptably risky weekend toy.
• Range (200–300 km from a 31.5 kWh pack) is seen as adequate for dense European regions, but absence of DC fast charging makes it clearly non-ideal for long trips.

Who Is Removing XSLT and Why

• Chrome is deprecating built‑in XSLT; Firefox and WebKit have publicly signalled support for removal as well.
• Stated reasons: tiny usage, large/complex code path, and multiple serious vulnerabilities in libxslt and related XML code that’s effectively under‑maintained.
• Some commenters dispute that other vendors truly “agreed to remove it,” arguing they only agreed to explore removal and also mentioned options like sandboxing or replacement implementations.

Security vs. Maintenance vs. Motive

• Pro‑removal side: XSLT’s engine parses untrusted input via old C libraries with long‑lived memory‑safety bugs; modern fuzzing keeps finding 20‑year‑old issues. Maintaining this niche feature forever is not worth the ongoing security and engineering cost.
• Critics argue security is a pretext: Chrome could ship the same WebAssembly/JS polyfill they recommend to site authors, which would sandbox XSLT like any other script.
• Others note Chrome simultaneously keeps adding much riskier, vendor‑driven APIs (WebUSB, WebBluetooth, etc.), so “shrinking attack surface” appears selective.

Value and Use of XSLT

• Fans describe XSLT as a powerful, concise, declarative tree‑transformation language, especially for XML‑centric domains (publishing, standards, finance, government, JATS, trade settlements). It enables templating and XML→HTML rendering without JavaScript.
• Several real production uses are cited: gov/legislative XML, weather data, enterprise integrations, RSS/Atom and sitemap styling, CMSs, directory listings.
• Critics say XSLT is painful, hard to debug, a Turing tarpit in XML, and effectively replaced by JS + JSON + template libraries; many projects already do transforms server‑side.

Backward Compatibility and “Open Web” Concerns

• One camp sees this as breaking an old, standardized web feature and violating the “don’t break the web” norm; worries about big vendors unilaterally shrinking the standards surface and marginalizing XML‑based content.
• Others reply that near‑zero usage plus availability of server‑side transforms or polyfills makes this an acceptable, even necessary deprecation; browsers are not obliged to support every spec feature forever.

Alternatives and Mitigations

• Suggested paths: server‑side XSLT (often already used for XSLT 2.0/3.0), JS/wasm polyfills (including an official one), possible extensions, or content negotiation for feeds.
• XPath DOM APIs remain, so Selenium/Playwright XPath locators are unaffected.
• Some argue vendors should instead have funded a modern Rust XSLT engine or adopted projects like Xee; others see deprecation of rarely used APIs as healthy for an overgrown browser platform.