Hacker News Reader: Best @ 2026-05-18 03:16:55 (UTC)

Consensus: Skeptical. Most commenters opposed VPN age-gating as broad privacy overreach, while a smaller group argued child-safety concerns are real and should be addressed at the platform or family-control level instead.

Top Critiques & Pushback:

• Scope creep from porn controls to internet-wide identity checks: Commenters argued that age-gating VPNs effectively means age-gating pseudo-anonymous access to the entire internet, which they saw as disproportionate compared with regulating specific sites or services (c48173505, c48174714, c48174354).
• Likely ineffective and easy to route around: Several users said determined kids will just use “dodgy” VPNs or other workarounds, so the policy would mostly burden ordinary users while creating new enforcement and privacy problems (c48169311, c48168023, c48167597).
• Mozilla’s conflict of interest: Some noted Mozilla also sells a VPN and said that weakens its credibility unless clearly disclosed; others replied that this is already disclosed in the linked submission and doesn’t invalidate the argument (c48166928, c48167483, c48167353).

Better Alternatives / Prior Art:

• Parental/device/network controls: A recurring view was that OS-level parental controls, ISP filtering, and school/family norms should be improved instead of forcing identity checks onto everyone (c48168800, c48169311, c48169770).
• Platform-level accountability: Even commenters sympathetic to child-protection goals generally saw site-specific measures as less invasive than restricting VPNs across the board (c48173505, c48174714).
• Content labeling / standards: Some suggested standardized site metadata such as adult-content labels so parental-control tools can work better without universal age verification (c48169358, c48170593).
• Existing pro-VPN guidance: One commenter pointed out that Australia’s eSafety guidance currently recommends VPN use, underscoring the inconsistency of governments promoting VPNs for safety while considering restrictions elsewhere (c48167063, c48167109).

Expert Context:

• This is tied to a specific UK consultation: A useful clarification was that Mozilla’s post responds to a UK government consultation on “growing up in the online world,” which reportedly includes a question about age-gating VPNs deep in the document; commenters urged others to submit responses (c48170433).

Consensus: Skeptical. Many commenters liked the post’s tone and agreed modern CSS is better than it used to be, but a large share pushed back on the idea that Tailwind is uniquely harmful.

Top Critiques & Pushback:

• Tailwind doesn’t inherently cause “div soup” or inaccessible HTML: The biggest rebuttal was that poor semantics come from developer choices and broader frontend habits, not from Tailwind itself; several argued the post confuses “forces” with “can be used badly” (c48160947, c48163629, c48160832).
• The real issue is ergonomics, not formal possibility: Supporters of the article’s critique replied that tools should be judged by the behavior they encourage; even if Tailwind doesn’t force bad markup, its workflow can make style-first thinking and extra wrapper elements the easy path (c48161445, c48161982, c48161996).
• For large teams, Tailwind is easier to scale than bespoke CSS: Experienced users said utility classes reduce selector conflicts, make unfamiliar codebases easier to edit, and shift reuse from global CSS to components; they framed cascade management as the real pain Tailwind solves (c48164351, c48164901, c48161678).
• The anti-Tailwind framing felt condescending to some: A recurring reaction was that critics overstate Tailwind users’ ignorance of CSS; several longtime CSS developers said they prefer Tailwind precisely because they know the tradeoffs and find traditional CSS harder to maintain at scale (c48164693, c48163180, c48161040).

Better Alternatives / Prior Art:

• CSS Modules / scoped component styles: Many suggested that if the problem is global cascade and class collisions, CSS Modules, Svelte/Vue scoped styles, Linaria, or similar tools give locality without packing utilities into markup (c48161514, c48160996, c48174576).
• ITCSS, BEM, and cascade layers: Some commenters pointed to older CSS organization systems and newer native features like @layer as cleaner ways to manage specificity and structure without Tailwind (c48162200, c48163992, c48167245).
• Hybrid approaches: A number of people said they use Tailwind for fast utility work but still keep scoped CSS for component-specific styling, which they see as a practical middle ground (c48162923, c48164449, c48163005).

Expert Context:

• Documents vs applications: One useful distinction was that Tailwind may be a worse fit for document-like, semantics-heavy pages but a better fit for application UIs with many isolated components; several people argued the thread was mixing those two contexts (c48160427, c48161305, c48162408).
• Modern CSS has changed the landscape: Even some Tailwind supporters noted that nesting, variables, :has, modules/scoping, and cascade layers make vanilla CSS much more viable now than when utility frameworks first took off (c48163246, c48164351, c48160308).
• Accessibility debate: Commenters split on whether Tailwind meaningfully affects accessibility at all: some said semantics and screen-reader behavior make HTML structure central, while others argued CSS choice is largely orthogonal unless developers misuse ARIA or markup (c48160349, c48161009, c48162135).

Consensus: Skeptical — commenters broadly agree the bug looks serious, but most push back on calling it a proven Microsoft “backdoor.”

Top Critiques & Pushback:

• Likely an auth bypass, not a BitLocker break: Several commenters say this is best understood as a WinRE/boot-chain authentication bypass. In TPM-only mode, BitLocker is already unsealed after a trusted boot path, so any post-bootloader bypass can expose the disk (c48170945, c48169652, c48173106).
• “Backdoor” claim is unproven: The strongest rebuttal is that unusual WinRE-only behavior does not by itself prove intent; component drift between Windows and WinRE could be ordinary engineering debt rather than malice (c48170945, c48171996, c48171337).
• PIN-bypass claim lacks evidence: Commenters repeatedly note that the public exploit affects TPM-only BitLocker, while the researcher’s stronger claim — bypassing TPM+PIN — has not been demonstrated publicly and would require a much more significant break (c48170023, c48172351).
• The bigger issue is weak defaults/threat modeling: A recurring view is that TPM-only full-disk encryption protects mainly against disk removal, not determined physical attackers; selling it as broadly secure gives users a false sense of protection unless preboot auth is enabled (c48169933, c48170470, c48171049).

Better Alternatives / Prior Art:

• BitLocker with PIN or startup key: Users say preboot authentication materially improves the model; some note their employers require PINs, though others say many companies still do not (c48170023, c48171510, c48172928).
• Linux/LUKS or Ubuntu TPM FDE: Commenters point out the architectural weakness is not unique to Microsoft; Linux systems that auto-unseal via TPM face similar issues unless paired with a passphrase/PIN (c48170945, c48169971, c48171049).
• VeraCrypt: The article’s recommendation sparked debate rather than consensus; some suggest open-source FDE, while others express distrust rooted in the TrueCrypt/VeraCrypt history (c48169373, c48169432, c48173078).

Expert Context:

• Technical explanation of YellowKey: One widely praised comment explains the bug as WinRE’s NTFS transaction-log replay reading logs from an external volume and applying them to the mounted filesystem, enabling WinRE auth bypass; with TPM-only BitLocker, that becomes a disk-access bypass (c48170945, c48172732).
• Why WinRE matters: Commenters clarify that WinRE can access the same unsealed disk state by design during trusted recovery boot, so this likely needs a WinRE patch rather than proving a secret BitLocker decryption key or Secure Boot revocation event (c48170080, c48171060).

Consensus: Cautiously Optimistic — commenters generally liked the project’s speed and tiny footprint, while debating whether Rust meaningfully improves coding agents beyond better implementation discipline.

Top Critiques & Pushback:

• Rust may not be the main bottleneck: Several users argued that coding agents mostly wait on remote LLMs, so rewriting them in Rust can be more hype than necessity unless local CPU/RAM problems are real (c48167434, c48167548, c48167897).
• Security and execution remain the hard part: Users focused on approval depth, sandbox escape risk, and whether bash access should exist at all; some suggested stricter tool models or containers instead of trusting recursive agent execution (c48166833, c48166855, c48171988).
• Extensibility is trickier in a compiled agent: A thread compared zerostack’s prompt/config approach with self-mutating or dynamically discovered tools, debating PATH-like plugins, MCP-style RPC, and embedded scripting runtimes (c48164909, c48166448, c48164972).

Better Alternatives / Prior Art:

• Pi / opencode / Dirac: These were the most-cited reference points; users described borrowing ideas like line hashing, modular tools, prompt systems, and coding loops from them (c48166422, c48167819, c48164948).
• Tiny or custom harnesses: Multiple commenters said they had recently built their own agents in a few hundred lines or with bespoke runtimes, reinforcing the view that many workflow-specific harnesses will coexist (c48165419, c48165512, c48171988).
• Alternative implementation paths: Suggestions included OpenADE, Barnum, Hermes-agent, Lua, Rhai, WASM, and even Zig, usually as better fits for scripting, plugin systems, or easier customization (c48172517, c48170617, c48164991).

Expert Context:

• Why the memory is low: The author attributed the small footprint to Rust plus implementation choices like load-on-demand connectors, smallvec, compactstring, size-oriented compiler settings, LTO, and a single-threaded Tokio runtime; this was one of the most technically detailed subthreads (c48164745, c48165107).
• Real pain with current tools: Many users backed the project’s premise by reporting that Claude Code or opencode can become sluggish, CPU-heavy, or memory-hungry in long sessions or on weaker machines, even if not everyone saw the same behavior (c48167724, c48168103, c48164613).
• Author responsiveness: A user reported provider-compatibility issues around max_completion_tokens and custom headers, and the author explicitly invited bug reports and PRs (c48166079, c48166545).

Consensus: Cautiously Optimistic — many agreed with the article’s core point about process bottlenecks, but a sizable minority argued AI is already speeding real work in some teams.

Top Critiques & Pushback:

• Requirements are not merely “upstream” work outside engineering: Many commenters said understanding the problem is central to software engineering itself, not something that can be cleanly handed off by PMs or analysts (c48170177, c48171251, c48172699).
• AI still struggles even with strong specs and tests: Several used Anthropic’s C-compiler experiment as evidence that current models still require close expert supervision and are not autonomous production engineers yet (c48170244, c48171112, c48172492).
• LLMs can make bad requirements look polished: A recurring concern was that PMs using AI to expand vague ideas into long tickets may create persuasive but inaccurate inputs that then flow into generated code and tests (c48170777, c48169427, c48171053).
• The article may understate AI’s value outside coding: Some argued AI also speeds ideation, prototyping, documentation, deployment prep, and domain-expert experimentation, so its gains are broader than the post suggests (c48169865, c48172643, c48174527).

Better Alternatives / Prior Art:

• Classic process theory: Users pointed to The Goal, The Toyota Way, and Brooks’s “No Silver Bullet” as older frameworks that already explain why bottlenecks and specification problems dominate productivity (c48168675).
• Smaller teams / less coordination: Multiple commenters said the bigger lever is reducing cross-team dependency and meeting overhead rather than focusing on code generation alone (c48170177, c48168386).
• Prototyping and persistent specs: Some suggested fast UI prototypes, structured specifications, or tools like Allium as better ways to improve inputs and feedback loops than relying on free-form prompting alone (c48168630, c48169606).

Expert Context:

• Compilers as a misleading benchmark: One subthread argued a C compiler is unusually well-specified, testable, and rich in reference implementations; if LLMs struggle there, that is a warning sign for messier real-world enterprise software (c48170332, c48172492).
• AI helps most with adjacent skills: A notable theme was that LLMs are often most useful when helping experts move into neighboring domains — e.g. backend engineers prototyping frontend work, or domain experts building internal tools — rather than replacing deep software judgment outright (c48168965, c48170098, c48169992).

Consensus: Skeptical. Many readers sympathized with the feeling of alienation, but pushed back on the article’s broad anti-complexity framing.

Top Critiques & Pushback:

• It romanticizes the past and ignores what complexity replaced: A common response was that nature and premodern life were not simple or humane; modern systems are complicated partly because they reduce disease, violence, scarcity, and arbitrary hardship (c48163924, c48164214, c48165196).
• It confuses a subjective feeling with an objective diagnosis: Several commenters said the post describes anxiety, burnout, or overload rather than "the world" itself; complexity may be real, but the essay overgeneralizes from one emotional state (c48167457, c48160878).
• "Do as little as possible" risks moral passivity: Readers objected that opting out can become an excuse for selfishness or for ignoring harm, especially if one’s work affects others; they argued that helping nearby people and building community still matters (c48167785, c48170938, c48170287).
• The real issue may be alienated work, not complexity per se: Many found the strongest part of the essay was its description of abstract white-collar labor with long feedback loops, where workers feel disconnected from concrete human outcomes (c48159223, c48168537, c48167341).

Better Alternatives / Prior Art:

• Marx / alienation: Multiple users framed the feeling as classic alienation—being separated from the purpose or product of one’s labor—rather than a wholly new condition (c48164678, c48168242).
• Graeber / "bullshit jobs": Others connected it to modern work that feels socially indirect or hard to justify, though this framing also drew criticism (c48166485, c48167491).
• Adam Curtis’ HyperNormalisation: Commenters suggested the film as a better account of how modern systems become opaque while elites simplify reality to retain control (c48163757, c48165175).

Expert Context:

• Abstraction vs usefulness: Some engineers said meaningful work does not require simplicity; what matters is whether organizations connect workers to real user impact. Customer support and shorter feedback loops were offered as practical remedies (c48167953, c48163926).
• Some complexity may be intrinsic to progress: A separate thread argued that humanity’s ability to understand and explore the universe is itself valuable and likely requires sophisticated institutions and tools, even if many modern complexities are wasteful or exploitative (c48164364, c48166434).

Consensus: Skeptical. Commenters were broadly hostile to Flock-style surveillance, but many thought the article itself overstated a small set of incidents and read more like advocacy than solid reporting.

Top Critiques & Pushback:

• The headline overstates the scale: Several users argued that 25 cameras nationwide—more than half allegedly destroyed by one person—is a “drop in the bucket,” not evidence of a major national trend (c48171555, c48171968, c48170880).
• The article feels like agenda-driven or AI-shaped writing: A recurring complaint was that the piece inflates a thin story, relies on weak signals like Reddit sentiment, and may have been heavily LLM-assisted; others pushed back that bad writing is the real issue, not authorship (c48171122, c48171527, c48170977).
• Vandalism may backfire politically: Some argued smashing cameras is emotionally satisfying but ineffective, unlikely to move policymakers, and more likely to polarize fence-sitters against privacy advocates (c48171028, c48171456, c48171140).
• Pro-surveillance pushback exists: A minority argued most people want effective policing, not less surveillance, and saw anti-Flock sentiment as a niche or privileged view detached from crime concerns (c48172244, c48172561).

Better Alternatives / Prior Art:

• Legislation and local organizing: Users pointed to city-level campaigns, voting, lobbying, and legal action as the more durable route, even if slower and less dramatic (c48171028, c48171505).
• Tighter system design: One commenter said concern would be far lower if cameras only retained vehicles tied to active BOLOs rather than storing everyone’s movement history (c48172477).
• Other governance reforms: Some broadened the discussion into campaign-finance reform, transparency, and better democratic accountability rather than focusing only on sabotage (c48171382, c48172251).

Expert Context:

• What makes Flock different: A useful distinction was drawn between ordinary policing and Flock’s model: commenters objected less to plate readers in principle than to persistent location tracking, broad retention, and data sharing that can reach federal immigration enforcement (c48172477, c48172424).
• Surveillance cuts both ways: A smaller thread noted that cameras can also aid accountability—e.g. bodycams or recordings of abuses—so the issue is not cameras in the abstract but who controls them and how the data is used (c48173158, c48173148).

Consensus: Skeptical — many commenters agree AI is disrupting open online CTFs, but a large share think the “dead” framing is overstated or confuses normal CTF automation with a new threshold of model capability.

Top Critiques & Pushback:

• The thread got derailed by jargon/title issues: A surprisingly large chunk of discussion was about the article not spelling out CTF and the submitted title being harder to parse than the original; others pushed back that niche blogs need not define basics for outsiders (c48164036, c48158235, c48164766).
• “Automation isn’t new in CTFs”: Several users stressed that CTFs have always rewarded tooling, scripting, and uneven team preparation, so treating all machine assistance like cheating misses the culture. The counterpoint is that frontier models now automate reasoning itself, not just grunt work (c48164822, c48165605).
• AI may worsen a long-standing problem, not create it: Some accepted that AI increases low-skill participation and interview cheating, but argued weak candidates, fizzbuzz failures, and credential inflation long predate LLMs (c48158620, c48161180, c48160651).
• “Dead” is too strong / adaptation may still happen: A few compared this to chess or games adapting to engines and anti-cheat, though others replied that online CTFs are harder to police because the evidence trail is thin (c48165621, c48166550, c48158595).

Better Alternatives / Prior Art:

• Separate learning from competition: Commenters echoed the article’s educational concern and favored labs or guided platforms over public scoreboards when the goal is skill-building, not leaderboard status (c48158190, c48158539).
• Restricted or offline formats: Some suggested the chess model — ban assistance in controlled tournaments, use anti-cheat, or move more activity in-person / into environments where AI use is harder to hide (c48165621, c48166550, c48158480).
• Challenge designs that resist current models: One challenge-builder said temporal/visual or partially physical tasks can still trip up AI, though even supporters treated this as friction rather than a durable fix (c48161555, c48158081).

Expert Context:

• Builders are already seeing heavy AI use: A commenter who helped run BSides Orlando said postmortem logging showed AI use is now basically guaranteed, but certain challenge types still degrade model performance (c48161555).
• The problem extends beyond CTFs: Users connected the same dynamic to code golf, hiring, and education: once AI can produce acceptable outputs, competitive signals and learning incentives get noisier unless rules or formats change (c48162177, c48158480, c48158172).

Consensus: Cautiously Optimistic — many agree text rendering is genuinely hard and that web tech is often the pragmatic choice, but a large contingent argues the post overstates the weakness of native APIs.

Top Critiques & Pushback:

• The problem may be SwiftUI, not “native”: Several commenters say the article mostly indicts SwiftUI’s current model for large, incrementally updated text, while AppKit/UIKit/TextKit or other native stacks can still outperform web apps when engineered well (c48168898, c48168943, c48168824).
• Text is intrinsically hard, not a “simple thing”: Many object to calling Markdown chat rendering simple, noting bidi text, glyph shaping, selection behavior, wrapping, streaming reflow, and accessibility make rich text one of the hardest UI problems; browsers just happen to have decades of investment here (c48172984, c48168717, c48168688).
• The post may conflate Markdown with rich text: Multiple replies say the real issue is long-form rich-text rendering and selection during streaming, not Markdown per se; that framing confused part of the thread (c48173355, c48168572).
• The evidence is anecdotal or overstated: Some dismiss the argument as a skill issue or ask for code/examples, saying many native apps already handle Markdown or text selection acceptably (c48169442, c48168574, c48168384).

Better Alternatives / Prior Art:

• Use WebKit, not full Electron: A common middle-ground view is that on macOS WebKit is already a native framework, so using it for Markdown/rich text is sensible without moving the entire app to Chromium (c48168455, c48169959, c48169272).
• Attributed strings / native text views: Some argue Apple’s native text system is strongest when driven by attributed strings rather than Markdown directly, and that converting Markdown into native rich-text structures may be the intended route (c48171151).
• Existing Swift libraries: Commenters point to packages like swift-markdown-ui and textual, though others reply that these still fall down on streaming, large documents, and frame-budget targets (c48168574, c48168748, c48171057).
• Alternative native frameworks: A few cite Qt/QML or older native toolkits as examples that can be fast and more mature than SwiftUI for some workloads, though others dispute whether that counts as truly native (c48168898, c48168972, c48168466).

Expert Context:

• Browsers are optimized for documents: One widely endorsed insight is that the web platform remains fundamentally document-centric, so it is unsurprising that it beats generic GUI toolkits on text-heavy, typographically rich, selectable content (c48168955, c48168974).
• Historical context on Apple text rendering: Commenters add that Apple has previously leaned on WebKit/HTML-related machinery in parts of its text stack, underscoring how long-standing and nontrivial this problem is (c48169854, c48171199).

Consensus: Skeptical: commenters found the demo technically impressive, but many doubted the “open-source” framing, the real quality/consistency, and the practical value beyond future robotics or tooling.

Top Critiques & Pushback:

• Not really open yet: Multiple users objected that the page says “open-source” while model downloads are marked “soon,” and others noted confusion between the released SANA-Video checkpoint and the specific SANA-WM model with camera control (c48161092, c48162990, c48165102).
• Quality and model-size claims feel overstated: Users pointed to obvious continuity errors (changing cave entrance, morphing book, weak revisits to prior views) and argued the “2.6B” headline is misleading because the showcased system also uses a 17B long-video refiner (c48159997, c48160152, c48165214).
• Games need intentionality, not just coherence: A large thread argued that hand-authored games feel meaningful because objects, environments, and payoffs are deliberately placed; world-model-generated spaces may be broad but hollow, producing more “slop” than memorable design (c48160388, c48161170, c48165173).
• The demo page itself is wasteful: Several users complained the autoplaying videos consumed hundreds of Mbps continuously, making the showcase hard to use on slower or metered connections (c48161573, c48161817, c48163866).

Better Alternatives / Prior Art:

• Procedural generation: Users cited Dwarf Fortress, No Man’s Sky, Terraria, and similar games as examples that already scale content while preserving design intent through layered systems rather than end-to-end video generation (c48160486, c48160689, c48160931).
• Deterministic game state + generated rendering: Some suggested a more plausible game architecture would keep explicit world state deterministic, then use diffusion/video models only for rendering or filling in details (c48161102, c48161731, c48160822).
• Physics simulators for robotics: A counterpoint to the robotics optimism was that current video world models may be poor substitutes for actual simulators when accurate physical rollout matters (c48165155).

Expert Context:

• What “world model” means here: One commenter clarified that, in current usage, this often means a video model that predicts/reacts to actions with game-like controls, not necessarily an explicit scene graph or symbolic world state behind the frames (c48163031, c48162591).
• Why labs care anyway: Others argued the long-term value is planning and simulation for robotics or multimodal systems with stronger spatial reasoning, even if today’s visible commercialization is mostly as video generation demos (c48161306, c48160954, c48161744).

Consensus: Skeptical—the thread broadly agrees pricing will change, but many think the article overstates both the subsidy and the resulting enterprise danger.

Top Critiques & Pushback:

• The article’s economics are shaky or overstated: Several commenters argue inference may already be profitable per token, while the real losses come from training, R&D, and capex; that makes this more of an investor problem than an immediate enterprise crisis (c48168425, c48168604, c48169119).
• Enterprise pricing is not just "$20 seats": Multiple users say businesses often buy via API, higher-priced team plans, pooled limits, or metered billing already, so the article exaggerates how exposed enterprises are to consumer-style subsidies (c48168665, c48169087, c48169896).
• The writing itself hurts credibility: A recurring side discussion says the piece reads AI-generated, citing repetitive rhetorical patterns and missing authorship as red flags (c48171898, c48172074, c48173231).
• Local models may limit price hikes—but maybe not soon: Some argue open/local models are already good enough for many tasks and will cap what frontier providers can charge; others counter that hardware, memory, throughput, and frontier-model quality still strongly favor cloud providers (c48171226, c48169716, c48170214).

Better Alternatives / Prior Art:

• Local/open-weight stacks: Users describe deploying Qwen, Gemma, and DeepSeek behind LiteLLM or on Macs/consumer GPUs as a practical hedge against vendor lock-in and future price increases (c48170258, c48174476, c48169921).
• Commodity routing and cheaper providers: Some point to OpenRouter and low-cost Chinese/open models as evidence that inference may already be more competitive and less scarce than the article suggests (c48168523, c48169299).
• Usage-based billing is already the correction path: GitHub Copilot’s move away from flat pricing is treated as a concrete precedent for how the market may normalize rather than collapse (c48169419, c48171132).

Expert Context:

• Inference vs. total-business profitability: One of the most useful distinctions in the thread is that AI companies can potentially make money on serving tokens while still losing heavily overall because competition forces continued spending on new training runs and infrastructure (c48169041, c48169325).
• “Good enough” may matter more than frontier best: Several commenters argue the real market question is not whether local/open models beat the frontier, but whether they become good enough relative to total cost of ownership for many enterprise workloads (c48170143, c48170320).

Consensus: Cautiously Optimistic — many commenters agree with the article’s core point that AI is most valuable when embedded into useful products, but they disagree over whether Apple is executing that well.

Top Critiques & Pushback:

• Apple’s real problem is Siri, not strategy: A common reaction was that the obvious Apple use case is simply making Siri actually useful for everyday tasks like calendars, media control, HomeKit, and shortcuts; several users said LLMs felt like the missing technology for what Siri always should have been (c48169595, c48174440, c48174579).
• Voice is a weak default interface: Many pushed back on the idea that conversational agents should replace screens or apps, arguing voice is awkward in public, poor for dense information, privacy-unfriendly, and should be reserved for limited situations rather than becoming the main UI (c48172570, c48174867, c48173886).
• The “AI product” framing can still fit some markets: A minority argued Gruber’s thesis is Apple-specific: for labs like Anthropic or enterprise software teams, AI itself can be the thing being bought and sold, even if consumers mostly experience it as a feature (c48170872, c48169361).
• Apple may be right on philosophy but behind in execution: Some commenters said Google already demonstrates “AI as feature” better via spam detection, translation, Lens, hold assistance, and photo tools, while Apple’s current implementations remain brittle (c48173624, c48174579).

Better Alternatives / Prior Art:

• Shortcuts: Users noted Apple already has a workflow system, but complained its authoring model is clumsy for anything nontrivial; natural-language shortcut creation was suggested as a better direction (c48173143, c48173398).
• Embeddings / narrow AI features: For practical value, commenters highlighted fuzzy search and reverse dictionary lookups as examples that work without leaning on full generative AI, contrasting them with more failure-prone uses like machine translation or “Stack Overflow clones” (c48172172, c48170830).
• Google’s feature integration: Several pointed to Pixel/Google features as evidence that AI can succeed as embedded functionality rather than as a standalone chatbot product (c48173624).
• Claude Code: One commenter cited Claude Code as a rare example of AI adding obvious value because it is tightly integrated into a real workflow rather than pushed as hype (c48169636).

Expert Context:

• Historical precedent inside Apple: One commenter connected the article to Steve Jobs’s “work backwards from the customer experience” philosophy, though another noted Apple has often combined speculative technologies first and only later found the product framing (c48169141, c48173256).
• Old Apple devices already did pieces of this: A Newton user recalled that handwriting phrases like “Lunch <name> Friday” could already be parsed into structured calendar events, suggesting today’s AI ambitions partly revisit old ideas with better tooling (c48169829, c48171420).
• Commoditization argument: Another thread compared AI to Dropbox-era sync: useful, temporarily productized, but likely to become infrastructure over time, leaving differentiation to hardware, interfaces, and labs rather than standalone consumer “AI products” (c48169361, c48169539).

Consensus: Cautiously Optimistic — readers found the article genuinely informative, but many immediately ran into browser support and styling limitations that blunt the usefulness of some native list features.

Top Critiques & Pushback:

• datalist is too unreliable in practice: Several commenters said the examples break or degrade on mobile Safari and Firefox Android, with odd autocomplete behavior and inconsistent support, making it hard to trust for production UX (c48162076, c48162993, c48163793).
• Native controls are hard to style or customize: A recurring complaint was that even when HTML elements are semantically right, designers often reject their default appearance, and cross-browser pseudo-element differences make custom styling painful (c48163952, c48165800, c48166346).
• <menu> may be semantically neat but functionally thin: One knowledgeable reply said <menu> is effectively the same as <ul> in browsers/accessibility trees unless you add the full ARIA pattern, so it does not magically create an accessible app menu by itself (c48164621).
• Real-world browser quirks undermine confidence in native HTML: The broken optgroup disabled behavior on iOS led some to argue that “div soup” or framework components can feel more predictable than relying on partially implemented platform features (c48162178, c48162367, c48164334).

Better Alternatives / Prior Art:

• Custom autocomplete/list UI: Users who need fuzzy matching, browseable options, or dependable behavior suggested falling back to custom lists/widgets; one commenter said they abandoned <datalist> and used an <ol> instead (c48163495).
• Div/React-based controls: Some argued that for sliders, meters, progress bars, and search/select hybrids, custom components built from generic elements are easier to style consistently across browsers than native controls (c48163256, c48166346).
• ARIA menu patterns: For real application menus, commenters pointed to the WAI Authoring Practices model, noting that role="menu" alone is insufficient and menu items also need proper roles and keyboard behavior (c48164621).

Expert Context:

• Support details matter by platform: A thread corrected the assumption that disabled <optgroup> works in Safari generally; commenters noted the feature appears supported in macOS Safari but not iOS Safari, explaining the discrepancy people saw on phones (c48162227, c48162367).
• HTML knowledge has become uneven: A side discussion argued that many newer developers skip deep HTML semantics in favor of frameworks, while others countered that this is normal technological abstraction and not necessarily harmful (c48162603, c48162774, c48164720).

Consensus: Enthusiastic — readers mostly treat Accelerando as strikingly prescient and idea-dense, while stressing that its future is bleak rather than celebratory (c48160113, c48159868, c48163196).

Top Critiques & Pushback:

• Some “predictions” are extensions of older dependency: Several commenters argue that skill atrophy and helplessness without tools are not new; modern people were already dependent on maps, infrastructure, and supply chains long before AI agents (c48164108, c48165189, c48164665).
• Not every extrapolation feels equally convincing: Users push back on claims that AI courts/law in milliseconds are clearly imminent, and some reject AI as a plausible “great filter” because machine civilizations might be more visible, not less (c48162037, c48164390, c48165135).
• The whole book isn’t equally strong: A recurring literary criticism is that the early, near-future sections are the sharpest and most vivid, while later parts become less compelling or more conventional space opera (c48164108, c48159868).

Better Alternatives / Prior Art:

• The Quantum Thief: Frequently recommended as another plausibly weird, high-concept future, though some say Accelerando feels more relevant to the present moment (c48160588, c48160828).
• Blindsight / Rainbows End / Across Realtime: Readers cite these as neighboring works on intelligence, singularity, and near-future extrapolation (c48161179, c48159914, c48160103).
• Halting State / Rule 34: Some argue Stross’s later books are better “15 minutes into the future” novels, especially on crypto, smart-contract-like systems, and networked crime (c48165134, c48168172, c48162209).

Expert Context:

• Author correction: Charles Stross himself appears to note that the opening material was written in 1998 and published as “Lobsters” in 2002, and he explicitly rejects readings of the book as techno-optimistic or pro-AI; in his view it ends with humanity effectively extinct except as simulations/memories (c48163630).
• Prescience readers focused on: Commenters single out always-on wearable mediation, agent dependence, automated shell companies, DAO/smart-contract-like structures, and uploaded lobster minds as ideas that now feel uncannily current (c48160113, c48160535, c48168172).

Consensus: Cautiously Optimistic — commenters found the gut-brain angle interesting, but most were skeptical that the article justifies strong claims about treating autism.

Top Critiques & Pushback:

• The article overstates weak evidence: Many pointed out that the headline sounds far stronger than the underlying evidence, which includes a very small early study and a follow-up without a placebo arm; they warned that autism trials often look spectacular in small uncontrolled studies and then fail in larger RCTs (c48160456, c48163762, c48159583).
• Possible confound: treating GI distress, not autism itself: A recurring argument was that improved constipation, pain, or nausea could reduce distress and make children appear calmer or better able to cope, without implying a cure or core change in autism (c48162151, c48159622, c48159766).
• PR/commercialization concerns: Several users noted the 2025 article reads partly like company promotion, relying on quotes from the researchers/company rather than a newly published paper; the lack of full Phase 2 results made some suspicious of investor-oriented hype (c48160684, c48161107, c48162536).
• Outcome-measure skepticism: Some questioned whether behavioral endpoints could be biased by study design, natural maturation, concurrent therapy, or changes in diet/medication over a two-year window (c48163762, c48160301).

Better Alternatives / Prior Art:

• Larger placebo-controlled trials: Users repeatedly said the real test is replication in better-controlled studies, not dramatic open-label results (c48160456, c48160474).
• Conventional GI care first: Some argued that if autistic children have gastrointestinal problems, those should be diagnosed and treated directly regardless of any hoped-for effect on autism symptoms (c48162151).
• Diet/fermented foods/probiotics: A side thread suggested less invasive microbiome approaches such as dietary diversification or fermented foods, though commenters did not present these as proven substitutes for FMT (c48159706, c48164067).

Expert Context:

• Restricted diets may skew the microbiome: Multiple commenters, including autistic people and parents, described “safe foods,” extreme food selectivity, and nutritional deficiencies such as scurvy, arguing this could itself distort gut flora and complicate causation (c48160126, c48161274, c48163187).
• Autism is heterogeneous: Commenters stressed that autism has many causes and presentations, so even if microbiome manipulation helps some patients—especially those with GI issues—it likely would not generalize as a universal treatment (c48160273, c48160748).
• University spinouts are normal, but controversial: Another thread explained that patenting and licensing university research into startups is standard tech-transfer practice, while others objected that publicly funded discoveries often become privately monetized (c48160107, c48160587, c48160592).

Consensus: Enthusiastic — commenters largely saw it as a charming, well-executed piece of functional art.

Top Critiques & Pushback:

• Needle bounce and overshoot: Several people focused on the rollover motion, saying the abrupt drop from full-scale to zero makes the needles bounce; some loved the effect, while others suggested ramped PWM or a more elaborate “catch” profile and warned that repeated shocks might wear cheap meters (c48164931, c48165236, c48166755).
• Clock behavior over purity: One commenter disliked the second hand having to reset, finding the visible wraparound aesthetically annoying even in an otherwise beautiful build (c48166323).
• Missing build details: A reader explicitly asked for the schematic, implying the post leaned more toward presentation than full replication details (c48173354).

Better Alternatives / Prior Art:

• Earlier meter clocks: Users pointed to prior art, including an older Arduino-based meter clock and a PIC-based DIY version, framing this project as a nicer execution of an established idea rather than a new concept (c48169003).
• Alternative fabrication paths: For readers put off by the woodworking, commenters suggested makerspaces with CNC routers or even tool-lending libraries as practical ways to reproduce the enclosure without owning a full shop (c48165318, c48166261).

Expert Context:

• Woodworking feasibility: A professional furniture maker said the case looked very doable on a makerspace Shopbot-class CNC, and noted the front panel could be simplified by skipping the rabbets around the gauges (c48165318).
• Analog-display appeal: One commenter working on an analog computer said using real panel meters instead of simulated ones on an LCD changes the feel of the system completely, reinforcing why projects like this resonate beyond mere timekeeping (c48164977).

Consensus: Skeptical. Most commenters see the announcement less as public-interest education and more as a marketing, adoption, or political-growth play.

Top Critiques & Pushback:

• "AI literacy" can become metrics theater: Several commenters compared this to mandatory workplace AI trainings that teach superficial usage while management mainly wants higher usage numbers and "productivity" optics, not real understanding (c48166016, c48166447, c48167788).
• Privacy and compliance risks: A major thread objected to normalizing pasting work or citizen data into chatbots, with warnings about GDPR, internal-data leakage, and unsafe habits even if the legal details depend on the data type and vendor contract (c48166626, c48166690, c48166883).
• It looks like customer acquisition or politics: Many argued the real goal is boosting OpenAI’s active users, gathering user data, or handing out a flashy freebie during an election period rather than solving a clear public need (c48166016, c48165943, c48166594).
• Malta’s politics overshadowed the deal: A large subthread pivoted into Malta’s corruption, tax-haven reputation, and press-freedom record; others pushed back that this was exaggerated or unrelated to the program itself (c48165982, c48167619, c48166630).

Better Alternatives / Prior Art:

• Other national pilots: Users noted this is not unprecedented in spirit: Anthropic has a program in Iceland, and OpenAI has announced similar country-focused work in Greece (c48167417).
• Earlier tech-subsidy models: One commenter said Malta has previously used similar public-access partnerships, such as subsidized Microsoft Office in the early 2000s (c48166424).
• Local/open models for privacy: A few suggested local or open models would be preferable where data control matters, rather than steering citizens toward a centralized hosted service (c48168428, c48165943).

Expert Context:

• The program is narrower than the headline suggests: Commenters pointed out it is a voluntary short online course with a one-year Plus reward, not an automatic permanent entitlement for every citizen (c48165750, c48163813).
• Malta is a small, tech-forward test bed: Multiple users noted Malta’s small population and history of positioning itself as a permissive tech hub (e.g. "Blockchain Island"), which may make it attractive for this kind of rollout (c48166792, c48166746, c48166424).

Consensus: Skeptical. Most commenters think the post’s broad conclusion may hold for dedicated local inference, but they dispute the framing, assumptions, and model choice.

Top Critiques & Pushback:

• Apples-to-oranges comparison: The biggest objection is that the post charges the full cost of a Mac against token generation, even though a Mac is also a general-purpose computer with resale value. Many say the relevant comparison is the incremental cost of buying a beefier Mac for local models, not the whole laptop price (c48168387, c48168445, c48168863).
• Assumptions are stacked against local use: Users object to rounded-up electricity, pessimistic throughput, and odd hardware framing. Several report much better token speeds, cheaper used Apple hardware, or argue that 24/7 utilization is the best-case scenario for amortization rather than an unrealistic baseline (c48168433, c48173903, c48174055).
• The article ignores why people run local models: Privacy, censorship resistance, offline use, fixed costs, and control over model/version are recurring reasons people accept higher local cost. Others counter that local models are slower, smaller, and miss frontier capabilities, so the premium is only worth it in specific cases (c48168645, c48169748, c48168577).
• Output-token-only accounting is incomplete: Several commenters say agentic workloads are often dominated by input tokens and prompt caching; local setups can make those nearly free, which materially changes the economics (c48168395, c48169206, c48170602).
• Cloud prices may be temporarily low: A major side debate is whether current hosted inference is subsidized by VC money and model-training burn, making today’s prices unreliable. Others push back that inference itself is profitable or at least getting cheaper with scale and hardware efficiency (c48169040, c48169197, c48170722).

Better Alternatives / Prior Art:

• Qwen 3.6 models: Multiple users say Gemma 4 31B is a poor benchmark choice and that Qwen 3.6 27B/35B offers better quality-speed tradeoffs on consumer hardware (c48169097, c48169604).
• Smaller Mac + cloud budget: Some suggest buying a more modest daily-driver Mac and spending the savings on API tokens or subscriptions, which better reflects how most people actually work (c48169570, c48169088).
• Used Apple hardware or non-Mac GPUs: Others argue cheaper secondhand Macs, RTX 3090/5090-class GPUs, or hybrid setups with cloud planning plus local execution can beat the post’s chosen setup (c48169259, c48171645, c48169365).

Expert Context:

• Why datacenters win: Commenters explain that inference is heavily constrained by memory bandwidth, and datacenter providers gain huge efficiency from batching, concurrency, cheaper power, and tuned kernels. That makes hosted tokens cheaper and often much faster than single-user local setups (c48170478, c48174512, c48169269).

Consensus: Cautiously alarmed: most commenters think the declaration is serious and worth attention, but the thread repeatedly argues over whether the headline overstates the risk.

Top Critiques & Pushback:

• The headline overreaches with “global”: A recurring correction is that WHO declared a public health emergency of international concern, not a pandemic emergency; several users call “global health emergency” misleading even if the practical takeaway is still serious (c48172104, c48168986, c48169802).
• Don’t dismiss it just because Ebola is harder to spread than COVID: Some argue Ebola is not very contagious and is unlikely to spread far outside regions with weak health systems; others push back that containment only looks easy because of intensive intervention, and late detection plus conflict and travel still make wider spread plausible (c48171849, c48172689, c48173105).
• Variant uncertainty matters: Commenters note this may be Bundibugyo ebolavirus rather than the better-known Zaire strain, which weakens simple assumptions about transmissibility and vaccine coverage (c48173117, c48169095, c48169864).
• WHO trust remains contested after COVID: A smaller but vocal group uses the thread to re-litigate COVID-era WHO messaging, especially around airborne spread and early public communication, arguing that institutional credibility is damaged (c48169327, c48172611, c48169549).

Better Alternatives / Prior Art:

• Containment over panic: Users emphasize classic Ebola controls—surveillance, infection control in clinics, and safer burial practices—rather than border closures or pandemic rhetoric (c48168986, c48169930).
• Existing Ebola vaccine platforms: Several commenters note there is an approved vaccine for the Zaire strain, and suggest that prior vaccine work may help, even if it does not directly protect against this outbreak’s variant (c48168920, c48168951, c48169095).
• Preparedness framing: Some invoke the “preparedness paradox”: previous international responses may be why earlier emergencies did not become global disasters, so low eventual body counts are not proof the warnings were unnecessary (c48172689).

Expert Context:

• Historical fatality context: One commenter cites WHO numbers saying past Bundibugyo outbreaks had case fatality rates around 30%–50%, and that the current reported death rate appears within that historical range rather than obviously milder (c48169864).
• Conflict and state fragility complicate response: Multiple comments tie the late pickup and control difficulty to eastern Congo’s insecurity, weak governance, and cross-border armed conflict, arguing that infrastructure and politics are central to outbreak risk (c48170220, c48170340, c48172391).

Consensus: Cautiously Optimistic. Commenters welcome the idea of alternatives, but many argue the real problem is not buying a non-Apple/non-Google phone — it’s surviving the app-locked services built around the duopoly.

Top Critiques & Pushback:

• The ecosystem lock-in is worse than the hardware lock-in: Many say phones are now required for banking, transit, parking, tickets, IDs, parcel pickup, office access, and other everyday services, so a niche handset is only half the battle (c48160742, c48161934, c48161512).
• Claims that smartphones are strictly necessary were disputed: A sizable minority pushed back hard, saying they live without smartphones today using paper, cash, desktop web, landlines, and persistence — though often with extra friction and depending on country/local norms (c48163254, c48171674, c48161882).
• “Non-Google” is fuzzy when the OS is still Android-based: Several commenters argued the article’s list overstates independence because many options are AOSP forks that still depend on Google’s upstream work, updates, or hardware ecosystems (c48161166, c48159578, c48161309).
• Linux phones sound appealing but may not solve mainstream needs: Users noted that freedom-focused devices like the Librem 5 or PinePhone can work for basic calling, messaging, and email, but risk incompatibility with modern apps, employer requirements, and state services (c48159071, c48159618, c48160261).

Better Alternatives / Prior Art:

• GrapheneOS on Pixel: The most repeated omission. Commenters said it is the strongest practical privacy/security option, even if it currently requires Google hardware and still sits on Android/AOSP foundations (c48159100, c48159259, c48164125).
• Sailfish / Jolla: Presented as a living third-path ecosystem with users reporting that it works acceptably as a daily driver despite quirks and weaker camera/software polish (c48158960, c48159255, c48159367).
• HarmonyOS: A few commenters suggested Huawei’s platform as a serious alternative with strong integration, but others rejected it as just swapping one closed ecosystem for another (c48160843, c48165261).
• Windows Phone / BlackBerry nostalgia: Some saw the thread as a reminder that a viable third ecosystem was lost years ago, blaming market failure, app shortages, and Microsoft’s own missteps (c48159283, c48160164, c48168802).

Expert Context:

• Regulation, not individual abstinence, may matter most: One recurring expert-style argument was that governments should require viable non-app alternatives or at least web/API access for essential services, because app-only delivery is the deeper anti-competitive problem (c48162229, c48167480).
• Attestation and security politics are central: Some commenters argued that Google Play Integrity/Strong Integrity and similar attestation systems are what will really shut out alternative ecosystems, more than the handset market itself (c48167480, c48167612, c48160367).

Consensus: Enthusiastic, with a practical streak: commenters like the idea of reclaiming cheap Android hardware for Linux, while probing RAM limits, device quality, and how much AI actually helped.

Top Critiques & Pushback:

• 4 GB RAM may constrain the “workstation” claim: Several users asked what is realistically usable on a 4 GB tablet. The general view was that terminal work, light browsing, and simple desktop use are fine, but browsers/Electron apps dominate memory use and heavy multitasking will be limited (c48170183, c48174457, c48171756).
• Browser performance is disputed: One camp argued Firefox is preferable on low-memory systems because it discards tabs and supports stronger ad blocking, while others said Chromium feels much faster and more responsive on ARM devices despite possible memory costs (c48170904, c48172976, c48171705).
• The hardware itself may be sketchy: Users warned that ultra-cheap tablets often have misleading specs, variant hardware, and dubious marketing; one specifically called out the advertised “extended RAM” as just swap and worried that identical model numbers may not guarantee identical internals (c48172133, c48173364, c48170567).
• AI assistance drew skepticism: Some praised AI for making low-value reverse-engineering tasks newly viable, but others pushed back that it should not replace actual understanding and can become “slop” if used blindly (c48169437, c48169996, c48170171).

Better Alternatives / Prior Art:

• NetBSD / other ports: One commenter immediately noted that a tablet able to boot from SD might also be a good NetBSD target, pointing to Rockchip ARM support as prior art (c48175200).
• Other low-end Linux devices: Users compared the project to PinePhone Pro setups, old Chromebooks, and cheap x86 tablets already running Linux successfully, suggesting the broader pattern is “low-end hardware is still useful if the software stack is lean” (c48173265, c48172626, c48171055).
• Lean desktop choices: Some suggested that lightweight environments such as sway, i3, or terminal-first workflows may fit the hardware better than heavier desktop assumptions (c48170183, c48173265).

Expert Context:

• Why this tablet: The key enabler is that the Doogee U10 appears to prefer booting from SD, making experimentation low-risk because Android on internal storage remains untouched (c48170330).
• Conservative AI workflow: Experienced commenters said AI can help with porting only when used incrementally: compare against downstream/vendor sources, review every small patch, test step by step, and keep a knowledgeable human in the loop (c48169996, c48171588).
• Author clarifications: The author said Debian 12 Bookworm was a conservative choice, Trixie was not yet well tested, and real-world performance is “usable” for terminal work, light browsing, VS Code, and small experiments, especially compared with bloated stock Android (c48171653).

Consensus: Cautiously Optimistic — commenters found steering practically interesting, but many thought the article understated its most important real-world use.

Top Critiques & Pushback:

• The article missed the main use case: Multiple commenters said the biggest present-day application is removing refusal behavior (“uncensoring” / “abliteration”), not toy controls like verbosity. They argued runtime steering is especially valuable because it can be applied only when needed, unlike permanently modified model weights (c48161688, c48161488).
• Prompting and activation steering are different: In response to confusion about GitHub Copilot’s “steer with message,” commenters clarified that text-based course correction is not the same as modifying hidden activations directly during inference (c48161813, c48161857).
• One factual nit: A few readers objected to the post describing DwarfStar 4 as a stripped-down llama.cpp; they said it is its own project that borrows ideas and some code, but is not simply a fork with features removed (c48161382, c48161707, c48161666).

Better Alternatives / Prior Art:

• Uncensored model edits: Users noted that open-model communities already use libraries and model modifications to identify refusal directions and reduce refusals, with steering seen as a better runtime alternative because it may preserve general capability better than permanently altered weights (c48161488, c48161688).
• Control vectors / representation engineering: Commenters connected the post to prior work on control vectors and representation engineering, arguing the mechanism described is already part of an emerging toolbox (c48162410).
• Soft prompts: One commenter suggested soft prompts (virtual tokens) may be even more interesting than steering because they can alter behavior through non-linguistic latent patterns (c48163601).

Expert Context:

• Runtime steering may damage models less: antirez said applying a steering vector inside the inference engine is “very superior” to baking the same change into GGUF/model weights, because the steering can be minimal, conditional, and limited to specific phases such as after thinking or outside tool use (c48161688).
• Refusal and capability tradeoff: Commenters noted uncensoring can reduce overbroad refusals in legitimate security or research tasks, but may also reduce general-task accuracy or make models more capable in risky domains (c48161763, c48161780, c48161904).
• Local is still local: On hardware requirements, some argued that needing 96–192 GB of RAM does not make the model non-local; if you can download and run it on your own hardware, it still counts as local inference (c48161693, c48161698, c48162531).

Consensus: Enthusiastic — commenters mostly treated it as a delightful retro-hardware stunt, while noting that the idea is fun precisely because it is impractical (c48165612, c48166229).

Top Critiques & Pushback:

• More demo than novelty: Several users pointed out that embedded devices and IoT gear routinely host web interfaces, and that chips with built-in Ethernet already exist; the clever part here is doing it on such constrained hardware with such a bare-bones link (c48167330, c48175002).
• Protocol details may be rough: One technically minded commenter noted a 2025 erratum to RFC 1055 that could affect SLIP decoding with Linux, and joked that TCP header compression (RFC 1144) might be the next step (c48166796).
• AVR platform longevity question: A side thread shifted into whether Microchip’s newer Cortex-M0+ parts make AVR less compelling, with debate over whether AVR’s remaining advantages are mostly in peripherals, low-voltage operation, and analog features rather than CPU core choice (c48166383, c48166404, c48166413).

Better Alternatives / Prior Art:

• Older tiny webserver demos: Commenters surfaced late-1990s/early-2000s “smallest web server” projects, including an ACE1101 implementation and even a “webserver on a fly,” framing this project as part of a long tradition of constraint-driven networking hacks (c48167950, c48170076).
• Ethernet-capable MCUs: Users mentioned that if the goal were practicality, one could simply use microcontrollers or SoCs with integrated 10/100 Ethernet, such as an 8051-based part linked in the thread (c48167330).

Expert Context:

• Historical continuity: One commenter said they personally built the old ACE1101 version and described squeezing the code under 1 KB by dropping ping and bit-banging I2C/UDP EEPROM upload support, giving useful historical context for how extreme these minimalist webserver projects used to be (c48170076).
• Retro feel was part of the appeal: Multiple users enjoyed that the page visibly streamed in slowly, evoking dial-up-era browsing rather than modern instant rendering (c48165612, c48173029).

Consensus: Cautiously Optimistic — readers found the idea interesting, but many doubted whether a tiny fixed-size state meaningfully solves “memory” in practical agent settings.

Top Critiques & Pushback:

• Compression is not the same as usable memory: Several commenters argued that compressing more history into a fixed state does not solve retrieval or association; the hard part is recalling the right information under varied queries, where search/RAG-style systems may still be better (c48159120, c48164681).
• Fixed-size memory has hard limits and degrades gracefully at best: Some readers interpreted the mechanism as continual compaction where detail is gradually lost or mangled as more information is inserted, rather than true long-term retention (c48160253, c48161595).
• Practical value is still unproven: Multiple commenters wanted evidence that these memory ideas help real workflows, especially coding agents; others questioned cost, novelty, and whether this is more than a modest architectural tweak (c48158802, c48158906, c48163410).

Better Alternatives / Prior Art:

• RAG / vector search: Users suggested embeddings plus retrieval as the more established way to recover relevant past context, with regex or lightweight filters as faster approximations in some settings (c48164681, c48164922).
• Docs, git history, rules, and CLI tools: For coding agents, several argued that transparent external artifacts—documentation, commit history, tests, and shell tools—are often better managed and more reliable than learned “memory” layers (c48161231, c48161438, c48162526).
• Journal-style external memory: One thread argued the more promising direction is a fixed-size internal state plus a large external token history the model can revisit, effectively treating memory like a searchable journal (c48165381).

Expert Context:

• Theoretical capacity may still be large: One commenter pushed back on the “too small to matter” criticism, arguing that even simple associative memories can store surprisingly large amounts of information per parameter, making this a potentially fruitful direction despite fixed-state limits (c48163578, c48166148).
• Related mechanism note: A technically minded reader characterized the paper as roughly adding DeltaNet-style hypernetwork ideas to existing LLMs—interesting, but not obviously groundbreaking (c48163410).

Consensus: Cautiously Optimistic — people liked the historical rabbit hole, but the thread mostly turned into nostalgia, hardware war stories, and discussion of the AMC show.

Top Critiques & Pushback:

• The literal “catch fire” claim was questioned: Several commenters doubted that an IBM 360 really caught fire from an invalid opcode, calling that part urban-legend territory or at least poorly evidenced (c48164427, c48166363).
• Some saw the article as overstating modern relevance: One subthread argued HCF was mostly an old joke rather than a term in current use; the author replied that this was his intent and that he was describing the phrase’s history, not claiming it is common today (c48165266, c48165308).
• Show-vs-tech tension: Among people discussing the TV series, a minority felt it was overpraised or too romance/soap-opera driven for something billed as a computing story (c48166908, c48167857, c48174883).

Better Alternatives / Prior Art:

• 6502 JAM opcodes: Users pointed to the 6502’s illegal opcodes as a cleaner-known example of “halt” behavior; one commenter noted FPGA implementers can safely reuse some of those opcode slots because old chips would just lock up on them (c48167346).
• 6845/CRT failure modes: Others offered adjacent historical examples where buggy programming could damage displays or monitors, including Commodore PET and IBM MDA systems using 6845-style video timing hardware (c48164448, c48165429, c48170913).
• Other tech narratives: For people interested in similar storytelling, commenters recommended Silicon Valley, The Soul of a New Machine, and Fire in the Valley as adjacent or alternative depictions of computing culture (c48164258, c48164315, c48164717).

Expert Context:

• Anecdotal evidence that software really could trigger physical trouble: Several longtime operators and hobbyists shared stories of line printers overheating, halon systems firing, and CRT phosphor burn from bad low-level behavior, reinforcing that old systems could fail in surprisingly physical ways even if “catch fire” was often a joke (c48166480, c48164448, c48171755).
• Why the show resonated: Many viewers said Halt and Catch Fire captured the hands-on, comprehensible feel of 1980s–90s computing and the personalities around it, contrasting that era with today’s more manipulative, attention-driven software ecosystem (c48165831, c48164789, c48167881).

Consensus: Cautiously Optimistic — people like the idea, but many doubt that retrieval-token savings alone translate into cheaper or better agent performance.

Top Critiques & Pushback:

• Benchmarks may optimize the wrong metric: Several commenters argued that showing fewer retrieved tokens or better retrieval scores is not enough; the real test is whether an agent completes tasks faster, cheaper, and with equal quality when grep is replaced (c48172599, c48174550).
• Models may not trust alternate tools: A recurring concern is that coding models are heavily trained around grep-like workflows, so they may retry, reread, or fall back to other tools, erasing any token savings unless the harness/prompting is tuned well (c48172599, c48172742, c48173096).
• Early anecdotal tests are mixed: One user reported better overall results with similar tooling disabled because lower context use was offset by more turns, while another small Semble-vs-rg/fd test found similar answer quality and only modest context differences, with Semble sometimes costing more in API credits (c48174550, c48175025).
• Scope question for small repos: For small codebases, one commenter said it can be cheaper and simpler to dump the whole repo or a structural outline into context instead of doing iterative search at all (c48174924).

Better Alternatives / Prior Art:

• LSP-based search: Multiple users immediately compared Semble to language-server tooling, suggesting LSPs may already solve parts of this problem for symbol-aware lookup (c48173657, c48173687).
• RTK / harness memory tricks: Some commenters said tools like RTK, plus global memory or AGENTS/CLAUDE prompt instructions, can get models to use non-grep tools reliably enough in practice (c48173503, c48173663, c48173096).
• CK / ColGREP / harness-native support: People also brought up ck, colgrep, and the idea that this kind of semantic search should be built directly into agent harnesses for local repos (c48174181, c48173521, c48173506).

Expert Context:

• Prompting matters as much as retrieval: A useful thread insight was that subtle differences in system prompts, AGENTS.md instructions, and tool descriptions can materially change whether models trust and efficiently use tools like this, making reproducible evaluation tricky (c48172742, c48174550).
• One concrete comparison to prior art: In response to ck, a commenter claimed Semble indexed much faster and returned more relevant code on a specific query, though this was anecdotal rather than a controlled benchmark (c48174927).

Consensus: Cautiously skeptical: commenters broadly dislike opaque platform censorship, but many argue the thread lacks key context about Ahmed, Kuwait, and Meta’s actual reasons.

Top Critiques & Pushback:

• Meta’s explanation is too vague: Several users object that “Community Standards” is an unusably broad justification; they want specific reasons, notice of any legal order, and some appeal path (c48171500, c48171772, c48171659).
• The free-speech framing is contested: One camp says giant platforms function like privatized public squares and should owe users more due process; the other insists free speech constrains governments, not Facebook, and warns against forcing platforms to carry speech (c48172004, c48173391, c48172586).
• The story is missing important background: Multiple commenters say the HN thread is arguing politics without enough verified context, and they question whether Ahmed was targeted merely for criticism of Kuwait or for something else (c48172597, c48172356, c48173063).
• Claims about Ahmed’s affiliations are disputed: A subthread argues over allegations that he promoted or was tied to the Muslim Brotherhood; some present that as crucial context, while others call it unsupported or politically motivated (c48171625, c48172270, c48172961).

Better Alternatives / Prior Art:

• Transparent legal-order notices: Users say Meta should explicitly say when an account is disabled due to a court or government order instead of hiding behind generic policy language (c48171772, c48171660).
• Appeals / arbitration: Suggested remedies include standardized appeals, data export, and even third-party moderation arbitration rather than opaque unilateral enforcement (c48173208, c48171944).
• Legal accountability mechanisms: Some propose stronger regulation of large platforms, including mandatory explanation standards or meaningful liability when acting on behalf of foreign governments (c48171659, c48173113).

Expert Context:

• Why governments still matter to platforms: A practical explanation is that sovereign states can threaten market access and local employees, giving even small countries real leverage over global firms (c48171438, c48171619).
• Section 230 debate surfaced quickly: Commenters re-litigate whether moderation should affect safe-harbor protections, with others pushing back that this is a common misunderstanding of Section 230 (c48171944, c48173142).

Consensus: Skeptical.

Top Critiques & Pushback:

• The economics make Solar Roof a niche luxury: Many commenters agreed the premium is too large for a product whose main advantage is aesthetics; several said the real comparison is often against adding panels to an existing roof, making the gap even worse (c48173499, c48175077, c48174743).
• The product is structurally hard to scale: Users repeatedly argued that tile-sized solar creates too many interconnections, more failure points, more complex installation, and awkward overlap between roofing and electrical trades (c48173362, c48166682, c48166080).
• Aesthetics matter, but only for a small market: Some said hidden solar is genuinely attractive for high-end homes or owners who dislike visible panels, including one owner who said they knowingly paid for the look; others replied that people have become more accepting of normal panels, shrinking that niche (c48174930, c48174644, c48174330).
• Tesla’s intent is disputed: A vocal group called the product a SolarCity bailout or hype vehicle, while others pushed back that it was a real attempt that simply lost to cheaper conventional panels (c48166086, c48167224, c48166850).

Better Alternatives / Prior Art:

• Standard rooftop panels: The dominant view was that conventional panels win on cost, speed, modularity, and ease of separating the roof decision from the solar decision (c48174743, c48166281).
• In-roof / integrated conventional panels: Several users pointed to flush-mounted or roof-integrated systems as a more practical middle ground, especially for new builds or places with stricter aesthetic rules (c48166353, c48166973, c48173560).
• Other vendors already exist: Commenters noted competitors such as GAF and several European/Japanese firms, often serving niche cases like historic buildings or tightly controlled neighborhood aesthetics (c48166281, c48166754, c48175152).

Expert Context:

• Rooftop solar can still pencil out well: Multiple commenters contrasted Solar Roof with ordinary PV, citing real-world payback periods of roughly 4.5 to 6 years in some markets and emphasizing benefits like backup power, hedging utility prices, and personal energy independence (c48173064, c48175032, c48173898).
• Integration has technical downsides: Users highlighted that flush/in-roof systems can run hotter and lose efficiency because they lack ventilation, which helps explain why simple rack-mounted panels remain attractive (c48174782, c48166973).

Consensus: Skeptical but alarmed — many commenters agree the article identifies a real authoritarian danger, while disputing whether “fascism” is the most precise label.

Top Critiques & Pushback:

• Not all the way to classic fascism yet: Several users argue the U.S. still differs from Nazi Germany or fully consolidated autocracies because courts, opposition politics, and critical media still exist, and state violence is not yet at 1930s levels (c48167041, c48167189).
• The term may blur important distinctions: A recurring pushback is that “hybrid regime,” “competitive authoritarianism,” or an Orbán-style illiberal democracy may better describe the current U.S. than historical fascism, even if the overlap is substantial (c48171062).
• Democratic erosion is already advanced: Others strongly reject the “healthy democracy” framing, pointing to media intimidation, deportations, ICE abuses, voter suppression, and institutional capture as evidence that the slide is already well underway (c48173352, c48168413, c48167611).

Better Alternatives / Prior Art:

• Orbán / Hungary model: Users repeatedly cite Hungary as a closer modern analogue: rule through gerrymandering, media pressure, culture-war propaganda, and institutional capture without fully open dictatorship (c48171062, c48167428).
• Umberto Eco’s “Ur-Fascism”: Commenters describe the essay as a needed update or rehash of Eco’s classic taxonomy of fascist traits (c48167361).
• Books on fascist rise: Users recommend They Thought They Were Free and February 1933 as more concrete guides to how fascism develops socially and institutionally (c48167181, c48167041).

Expert Context:

• Historical precision from German commenters: One German user agrees with the article’s premise but corrects a detail, noting Volkswagen was founded by the Nazi regime rather than merely absorbed into it, and that chemicals and steel were more central industrial backers of Nazism (c48167407).
• International comparison: Some commenters argue the article’s checklist also fits other countries, especially Israel and the Netherlands, suggesting the framework is broader than U.S. politics alone (c48174466, c48167943).
• Long-view warning: A notable thread argues that societies often fail to recognize fascist danger until after catastrophe, and that collective memory of such danger fades within a few generations (c48167407, c48171548).

Consensus: Cautiously Optimistic — commenters like the owner-led rescue effort, but mostly treat it as a symptom of a larger and troubling trend toward cloud-dependent, user-disempowering cars.

Top Critiques & Pushback:

• The real problem is cloud dependence, not EVs: Several users argue Fisker is just an extreme example of a broader software-lock-in problem that could affect ICE cars too; they see mandatory server check-ins for core functions as the fundamental design failure (c48165455, c48165511).
• Open-source cars are appealing, but safety and practicality are hard: Some want cars that owners can truly control and modify, while others note that automotive software is safety-critical, heavily regulated, and not easy for hobbyists to maintain correctly (c48165323, c48166237, c48165488).
• OTA updates can themselves be risky: Commenters worry not only about abandoned software, but about cars changing behavior overnight via forced updates; they prefer explicit user approval and less connectivity overall (c48165511, c48165841).
• Skepticism about the article’s writing: A visible side-thread argues the piece “reads very AI,” though others push back that AI-detection tools are unreliable and that AI-assisted writing matters less if the reporting is real (c48165695, c48165690, c48166989).

Better Alternatives / Prior Art:

• Open-source automotive platforms: Users point to existing FOSS engine-management and car-modding communities as evidence that owner-controlled vehicle software is possible, though difficult in practice (c48166237).
• European open-source collaboration: One commenter is intrigued that several European manufacturers are reportedly collaborating on an open-source automotive software platform, though they are skeptical of those firms’ software track record (c48165455).
• Reduced connectivity as a partial fix: Rivian’s option to disable LTE is cited as a small step toward owner control, even if it is not full software openness (c48165458).

Expert Context:

• Safety systems can feel “software-broken” when assist systems fail: In a useful corrective exchange, a commenter describing “jammed” brakes/steering is told that loss of engine power can remove brake boost and power steering assist, making controls suddenly very stiff without literal lockup; the original commenter largely agrees this explains part of the issue (c48165608, c48165762, c48165857).
• Open source in cars still runs into regulation/compliance limits: One user notes Tesla already ships a lot of open-source software internally, but argues that licensing and vehicle-safety/emissions rules complicate the idea of end users running arbitrarily modified car software (c48165519, c48165866).

Consensus: Cautiously pessimistic — commenters generally accept that some AI-exposed clerical and support roles are vulnerable, but many dispute how much of the current drop is truly caused by AI versus overhiring, cost-cutting, or broader macro weakness.

Top Critiques & Pushback:

• AI may be getting too much credit: A major thread argues companies are using AI as a convenient narrative for layoffs that were already coming from pandemic overhiring, bureaucracy, or ordinary cost trimming (c48163272, c48163177, c48163380).
• Macro conditions may explain part of it: Several commenters say these same SG&A-heavy roles are often cut first in slowdowns, so tariffs, higher rates, and recession fears could be interacting with AI rather than AI acting alone (c48162968, c48163359, c48163087).
• But the article’s occupational pattern matters: Others push back that the cited data is specifically about AI-exposed jobs — especially customer service, secretarial, translation, and paralegal work — not broad tech layoffs, which they see as stronger evidence of real substitution (c48163281, c48164021, c48164494).
• Service quality concerns: Many say AI-driven customer support and scheduling often feel worse for users and mainly benefit firms through lower costs, though a minority report good experiences when the AI is fast and escalates well (c48163391, c48163003, c48164075).

Better Alternatives / Prior Art:

• Human-in-the-loop support: Users suggest AI works best as triage or summarization, with humans handling exceptions and final authority rather than full replacement (c48172772).
• Competition and antitrust: Some argue the real remedy for “AI enshittification” is more market competition, lower barriers to entry, and antitrust enforcement so firms must compete on service quality, not just labor cuts (c48167201).
• Safety net over make-work: A recurring policy view is that society needs stronger social protections rather than preserving unnecessary headcount inside bloated firms (c48163379).

Expert Context:

• What jobs commenters say are exposed: One widely cited comment lists procurement clerks, customer service reps, admin assistants, paralegals, translators, graphic designers, technical writers, and some sales roles as the affected set; it also notes software, data science, and operations research as areas still expected to benefit (c48164122).
• BLS credibility: Commenters discussing the underlying labor statistics say BLS projections have historically been reasonably accurate, while acknowledging shocks like Covid can throw off forecasts (c48163921, c48163838, c48164599).
• Some jobs may shrink unevenly: A nuanced point is that routine, mechanical translation or content work may be far more exposed than higher-skill artistic or relationship-heavy variants of the same profession (c48164582, c48163357).

Consensus: Skeptical to dismissive. Most commenters saw the post as a misleading flex about token consumption rather than convincing evidence of product or engineering value.

Top Critiques & Pushback:

• The title overstates real spending: Many argue the $1.3M number is a raw API-equivalent price, not what Steinberger actually paid, especially since he works at OpenAI and likely has subsidized or internal access; others counter that API-equivalent pricing still matters because ordinary users would face it (c48159678, c48159919, c48160017).
• Token burn is not productivity: A recurring theme is that spending huge numbers of tokens, generating lots of commits, or shipping constantly is a bad proxy for software value—akin to measuring dev output by LOC or spend (c48164290, c48164411, c48165456).
• OpenClaw seems fast but unstable: Users describe very rapid release velocity, but say it comes with churn, broken configs, regressions, and poor usability/security tradeoffs; defenders say the project does work and improves quickly, but critics say that just proves guardrails were dropped (c48159730, c48160336, c48165124).
• The workflow sounds self-inflicted and wasteful: Several commenters mock the idea of using swarms of agents to create, review, rank, and re-review each other’s output, arguing the complexity exists mainly because the system produces unreliable code in the first place (c48161302, c48160293, c48159915).
• Economics and sustainability look shaky: People compare this to dot-com-era subsidy dynamics, arguing AI usage is being masked by VC/platform subsidies and may become much more constrained once companies must justify margins and governance (c48163061, c48159849, c48160136).
• Environmental/compute concerns: Some frame this level of usage as a signal of looming compute and energy bottlenecks, while others dismiss vendor claims about massive future power demand as hype (c48159554, c48159798, c48161232).

Better Alternatives / Prior Art:

• Classic engineering discipline: Commenters argue that deterministic tests, isolated components, and mature deployment practices solve many of the problems OpenClaw appears to paper over with more agents (c48159915).
• Human-in-the-loop pairing: One thoughtful view is that today’s best use of LLMs is still active pairing/XP-style steering, because fully automating all the surrounding product, QA, and ops judgment explodes cost and still needs senior oversight (c48159869).
• Cheaper/local models: Some suggest open or local models are the only path to making this kind of experimentation economically sane over time, and cite using GLM/Kimi/DeepSeek-style stacks instead (c48159849, c48160430).
• Alternative tools: A few users mention having fewer implementation issues with other tools/frameworks such as Hermes, or with structured workflows like bmad (c48165108, c48160430).

Expert Context:

• Cost crossover insight: One detailed comment argues there is a real crossover point where building enough “harness” around LLMs—product context, architecture, QA, SRE, review—can cost more than the human labor it is meant to replace, unless senior humans actively steer the process (c48159869).
• Falling inference costs may change the calculus: A minority view says the current spectacle may be a preview of workflows that become practical later as model inference gets dramatically cheaper (c48160116).

Consensus: Skeptical. Many commenters accepted the broader concern about concentrated tech power, but doubted that “TESCREAL” is a coherent or useful umbrella for explaining it.

Top Critiques & Pushback:

• TESCREAL is too loose or rhetorical: Several argued the label bundles incompatible movements and functions more like a political boogeyman than an analytic category, obscuring concrete issues like wealth concentration and ego-driven power seeking (c48163661, c48163790, c48163806).
• The article may overstate ideological coherence: Commenters said figures like Thiel, Vance, Musk, and Andreessen may share anti-democratic tendencies, but their actions are not obviously driven by one unified doctrine; treating them that way risks exaggerating their intellectual consistency and influence (c48163777, c48163711).
• India example seen as incomplete or shaky: One thread argued the discussion of Hindu nationalism was underdeveloped or insufficiently contextualized, with disagreement over whether the article unfairly singled it out versus simply describing India’s present power structure (c48163422, c48163597, c48163625).
• AGI-control premise questioned: At least one commenter challenged the article’s quoted premise directly, saying that if AGI were truly intelligent, the idea that humans could “control” it is implausible (c48166242).

Better Alternatives / Prior Art:

• Focus on concentrated wealth and power: Multiple users said the stronger frame is not TESCREAL but the longstanding problem of billionaires and CEOs exerting political power beyond democratic accountability (c48163711, c48163779, c48162678).
• Critiques of the TESCREAL concept: A commenter pointed readers to The TESCREAL Bungle as a rebuttal to the idea that Effective Altruism, Rationalism, and adjacent currents form one sensible bloc (c48163661).

Expert Context:

• Historical analogy: One subthread compared TESCREAL to Posadism or other deterministic ideologies that claim special knowledge of the future and therefore justify suppressing dissent, though others narrowed that analogy specifically to Posadism rather than communism in general (c48163496, c48163791, c48164200).
• Reactionary ideas and influence are hard to trace: A commenter noted that measuring how fringe intellectual currents translate into real political power is difficult, and pointed to John Ganz’s writing on figures like Thiel as a better way to study that pipeline (c48164319).

Consensus: Enthusiastic — commenters found the cards clever and useful, while the main debate centered on modern vs. ancient Greek and pronunciation rather than the project itself.

Top Critiques & Pushback:

• Modern vs. ancient Greek confusion: Several readers initially assumed the cards might teach Ancient Greek, then noted the deck actually uses Modern Greek words; this matters for learners coming from classical texts or college language classes (c48160649, c48161734).
• Pronunciation can mislead learners: Commenters pushed back on treating math-class pronunciations as “classical,” arguing English conventions for Greek letter names often differ from both modern and reconstructed ancient Greek pronunciation (c48161649, c48164397).
• Some word/object matches seem weaker than others: Greek-speaking commenters discussed specific cards and suggested stronger everyday words or more visually fitting objects for certain letters, especially harder cases like omicron and chi (c48164488, c48164997).

Better Alternatives / Prior Art:

• Grammar books: Some said a basic Greek grammar course is a fast way to internalize the alphabet, recommending standard introductory texts instead of standalone flashcards (c48161283, c48161854).
• Preschool-style repetition charts: One commenter suggested simple printable large-letter charts as a lower-tech route that can still work well for adults and children (c48167609).
• Similar mnemonic systems: Readers compared the deck to Letterland for English and Chineasy for Chinese, positioning the idea as part of a broader family of visual alphabet/character-learning tools (c48162146, c48160924).

Expert Context:

• Greek letters in STEM: Multiple commenters said knowing the Greek alphabet substantially improves reading notation-heavy math, physics, and CS, with some wishing it were taught earlier because of how often letters like λ, σ, θ, and ω appear (c48162972, c48160698, c48161221).
• Native-speaker perspective: A Greek commenter noted that, paradoxically, Latin letters can feel easier as math symbols inside Greek text because they stand out more, and also emphasized that all 24 Greek letters regularly appear as variables across fields (c48167609).

Consensus: Cautiously skeptical — people like the direction, but many think the demo examples are too simple to prove usefulness on real engineering work.

Top Critiques & Pushback:

• Examples look toy-level: Multiple commenters say the showcased parts are basic and don’t demonstrate whether the system can recover accurate geometry for complex models, dimensions, or real constraints (c48175199, c48174621, c48175042).
• Unclear real-world robustness: One user tried the Docker setup and hit dependency problems, then questioned whether the system works on photographs or hand sketches instead of CAD-like renders; a reply mocked the broken containerization (c48174961, c48175062).
• Ambiguous CAD target/output: Several commenters were confused by the claim that it generates a “CAD program,” asking which CAD system that means and whether the output is actually portable or editable across tools (c48173866, c48174125, c48174281).
• Site usability issues: People complained about the autoplaying video interrupting phone audio and poor mobile rendering, which colored perceptions of the project quality (c48174815, c48175192).

Better Alternatives / Prior Art:

• OpenSCAD workflows: Some users said prompt-driven modeling with an LLM plus OpenSCAD has already worked well for them, though others noted OpenSCAD is not really B-rep “true CAD” in the same sense (c48174405, c48174434, c48174702).
• OpenCascade-based tools: For open-source B-rep work, users pointed to projects built on OpenCascade, especially CADQuery, CascadeStudio, and RepliCAD (c48175168).
• Other CAD kernels/projects: One commenter shared their own Rust B-rep CAD kernel, vcad, as related prior art and said it is also wired to Claude for similar experimentation (c48174784, c48174826).

Expert Context:

• Why “CAD program” matters: A knowledgeable reply explained that the interesting part is not merely outputting a final shape, but recovering a history of operations/sketches; another commenter clarified the current output appears to be DeepCAD-style JSON derived from Onshape-like operations rather than a native file for arbitrary CAD packages (c48173911, c48174281).
• B-rep vs script CAD: A useful distinction emerged between OpenSCAD-style scripted geometry and B-rep modeling, with commenters noting that free/open B-rep stacks usually rely on OpenCascade (c48174702, c48175168).