Hacker News, Distilled

Why Markdown Won vs Alternatives

• Several commenters recall contemporary contenders (Textile, reStructuredText, AsciiDoc, org-mode) and see Markdown’s victory as mostly timing, simplicity, and momentum—especially via blogs and later GitHub.
• Compared to DocBook/Word, Markdown is seen as “worse is better”: far fewer features, but vastly better UX for basic writing, readable as source, and easy to adopt.
• Markdown’s minimal core and the HTML-escape hatch made it practical: you use the simple bits 95% of the time and drop to HTML when needed.
• Org-mode, rST, and AsciiDoc are praised as more powerful and cleaner, but too niche, heavy, or tied to specific ecosystems (e.g., Emacs, Sphinx).

Standardization, Flavors, and Parsing Pain

• Many are frustrated that Markdown isn’t standardized; multiple “flavors” exist (GitHub, Slack/mrkdwn, GFM vs comments vs issues).
• CommonMark is cited as an attempt to formalize ambiguous edge cases, but still complex and not universal.
• Several note Markdown is deceptively hard to parse correctly (like YAML), with whitespace, newlines, and nested lists being especially tricky.
• This non-uniformity is seen as both a feature (Postel-style robustness, adaptability) and a serious downside (portability, predictability).

Syntax, Semantics, and Limitations

• Examples from the article itself (intra‑word underscores) are used to show ambiguity in emphasis rules; many prefer * over _.
• Debates around <em>/<strong> vs <i>/<b> highlight Markdown’s reliance on HTML semantics and its lack of richer, explicit structure.
• Limitations repeatedly mentioned: complex layouts, precise typography, semantic markup, math, multi-level lists that interact oddly with code blocks, and awkward tables.
• Some argue Markdown is fine for notes and memos but inadequate for “real” structured documents; others counter that HTML inclusion and tools like Pandoc or Typst cover advanced needs.

Tools, Viewers, and Ecosystem

• Widespread everyday support (GitHub, chats, Google Docs input, editors like Obsidian, Typora) is praised as a major adoption driver.
• Others complain there are surprisingly few native “double-click and read” Markdown viewers, especially in stock OS/browser setups.
• Alternatives like Typst and Djot are highlighted as more modern, structured takes, sometimes used as backends for Markdown-authored content.

Article Critiques & Historical Context

• Some argue the article understates previous lightweight markup work and mischaracterizes how people actually wrote plain-text links.
• The piece is also seen as too light on the contentious history around attempted standardization efforts and the resulting long-term fragmentation.

Concept and Overall Reception

• Game is a Simon-style ear-training tool: listen to a melody, then reproduce it on a piano (onscreen or via MIDI).
• Many musicians, including experienced players, find it genuinely useful for practicing relative pitch, working memory, and basic sight reading.
• Several users say they’ve wanted exactly this kind of focused ear-training tool; some prefer it to more complex apps.

Difficulty, Progression, and UX

• Starting difficulty feels high for beginners; users ask for:
  • Fewer starting notes (1–2), slower tempos, and kid-friendly modes.
  • Ability to “freeze” difficulty at a comfortable sequence length.
• As sequences get long, it shifts from ear training to pure memory; some want capped lengths or repeated practice at a given level.
• Many request more forgiving behavior: multiple tries on a note, faster reset after mistakes, and option not to auto-replay the whole pattern each time.
• Users want a “noodle” mode: freely explore notes to find the melody, then explicitly submit an answer.
• Visual feedback (blinking overlays, “Wrong” popups, help button covering a key) is seen as distracting or confusing by some.

Input Methods and Technical Issues

• Strong demand for:
  • Computer keyboard mapping (Ableton-style or 4-row tracker layout).
  • Better on-screen keyboard and optional click-only interaction.
  • Super-easy hints like showing pressed note names or highlighting keys in Simon mode.
• MIDI support is praised, but one bug surfaced: some controllers send NOTE_ON with velocity 0 instead of NOTE_OFF, causing double triggers; this was identified and addressed.
• Multiple reports of no sound on iPhones; often related to silent mode, but at least one case persists, suggesting Safari/Web Audio quirks.

Pedagogical Role and Future Directions

• Consensus: it’s an ear-training/practice tool, not a complete “course” in theory or intervals.
• Debate centers on whether it truly “teaches” intervals vs. providing flashcard-style drills that support later conceptual learning.
• Suggestions include: interval-naming modes, higher/lower beginner drills, constrained note ranges (avoiding extreme registers), and more melodic, less random sequences (Markov/transformer-based generation).
• Some meta-discussion criticizes dismissive “AI slop” reactions and defends small, focused practice tools as valuable hacks.

Policy and Scope

• Vietnam now requires banking apps to detect rooted devices, unlocked bootloaders, ADB/dev mode, etc., and refuse to run.
• Commenters note many banks elsewhere already block rooted phones voluntarily; Vietnam making it law is seen as a step further.

Security Arguments For the Ban

• Pro-ban commenters argue rooted or modified phones are a strong fraud signal: easier to run malware, intercept traffic, overlay fake UIs, or tamper with app logic.
• Banks are often legally liable for fraud losses; excluding high‑risk client setups is described as risk management, not hostility.
• Remote attestation / Play Integrity / TEE are said to let banks distinguish stock, unexploited devices from ones with local privilege escalation or OS tampering.
• Regulators can later deem weaker practices “inadequate protection,” pushing banks toward stricter device checks.

Critiques: Security Theater and Control

• Many doubt rooted phones materially contribute to losses; most scams involve stock devices and social engineering.
• Root checks are called DRM and liability shields: preventing users from inspecting apps, recording screens, or backing up data, while shifting blame to customers.
• Several argue this entrenches Google/Apple hegemony and makes non‑corporate ROMs (Lineage, Graphene, etc.) second‑class citizens.

Shift to App-Only, Attestation, and Lock-In

• Multiple examples (Ireland, parts of Europe, some US and Asian banks) where:
  • Critical operations or any login require a mobile app and push‑based 2FA.
  • Websites are crippled or removed; some banks and fintechs are app‑only.
• Hardware attestation is increasingly used; commenters expect web access and SMS 2FA to be phased out or constrained.

User Agency, Rooting, and General-Purpose Computing

• Long threads connect this to the “war on general-purpose computing”: users treated as adversaries on their own hardware.
• Loss of root and mandatory attestation are seen as part of a broader pattern (locked bootloaders, TPMs, anti‑modding, app‑store control).

Workarounds and Practical Responses

• Many propose two-device strategies: a cheap, unmodified phone kept mostly offline for banking/ID, and a rooted or custom‑ROM phone for everyday use.
• Others prefer web banking with hardware tokens or card readers where still available; some say they would switch banks or to credit unions if forced into app‑only.

Vietnam-Specific Context

• Several tie the move to Vietnam’s VNeID biometric ID rollout and tighter linkage of SIMs, bank accounts, and state identity systems.
• In that framing, the rule is read as enhancing state tracking and control, not just fraud prevention.

Marketing Claims vs. Reality

• Flock repeatedly claims it has “never been hacked,” which commenters see as deliberately misleading given repeated basic security failures (e.g., hardcoded credentials, publicly exposed feeds).
• Several analogies are used: leaving a front door open and insisting the house was “never broken into,” or calling this an “unlocked front door” rather than a backdoor.
• Prior demos of still-insecure Flock cameras are referenced as evidence that “it’s all fixed now” PR is unreliable.

Nature and Handling of the Vulnerabilities

• Timeline from the article shows a disclosure in mid‑November with no remediation for over 55 days; many interpret this as clear responsible disclosure and poor response by Flock.
• Some argue this is not “sheer incompetence” but indifference: fixing it was simply not a priority.
• Others broaden to systemic causes: underfunded platform/security teams, emphasis on features and marketing over secops, and willful negligence around secret management.
• A minority questions the article’s technical clarity and notes some screenshots look like client-side JavaScript keys; they suggest impact may be overstated, especially for mapping/ArcGIS-style APIs.

Surveillance Infrastructure Itself

• Many see Flock’s very existence as the core problem, not just its security: pervasive ALPR and camera networks are framed as unreasonable search and a step toward a “panopticon.”
• There are calls for a constitutional right to privacy and for updating legal concepts of “no expectation of privacy in public” to account for mass, automated, always‑on surveillance.
• Debate emerges over whether public camera feeds should be public:
  • Pro side: transparency, self‑protection, and potential to turn people against surveillance.
  • Con side: risk of enabling stalking and abuse; core issue is persistent recording and retention, not mere observation.

Politics, Funding, and Corporate Actors

• Strong criticism of venture-backed surveillance startups and accelerators that support them; these are described as amoral, profit‑driven, and aligned with an expanding police state.
• Some note Flock’s late hiring of a CISO and security leadership; a few see this as a positive step, while others argue security for such a system “must be there from day one” and does not mitigate the ethical harm of bulk surveillance.

Local Activism and Resistance

• Multiple examples are cited of cities canceling or not renewing Flock contracts; organizers describe coordinated campaigns, public education, and exploiting Flock’s own negative press.
• Commenters describe how vendors cultivate police departments via grants, prewritten policies, and friendly messaging, leading municipalities to swap vendors rather than question surveillance itself.
• Some report vandalism of cameras and “blade runner”–style resistance, but note legal risk and contracts that stick cities with repair costs.

Background: Italy’s “Piracy Shield” and the Cloudflare fine

• Italy’s regulator AGCOM uses “Piracy Shield” to force fast blocking (within 30 minutes) of IPs/domains accused of live sports piracy, especially football streams.
• Orders target ISPs, CDNs and DNS resolvers, including 1.1.1.1. Blocks are issued on rights‑holders’ claims with little apparent verification or judicial oversight.
• Cloudflare was fined ~€14m (reported as >200% of its Italian revenue) for not implementing these blocks on its resolver and CDN; AGCOM argues CF has long been notified and invited into the process.

Global vs local blocking and technical disputes

• One camp says Italy is overreaching by effectively demanding global DNS and CDN blocks based on an Italian process, with no appeal, transparency, or due process.
• Others reply AGCOM only wants blocking inside Italy; they argue Cloudflare is exaggerating “global censorship” and could do IP or country‑based filtering.
• There’s disagreement over whether Cloudflare genuinely can’t comply without harming performance, or is using its anycast architecture as leverage by making collateral damage expensive.

Free speech, copyright, and foreign influence

• Some frame this as a pure copyright issue (sports rights), not “free speech.” Others say the same mechanism could easily be weaponized for wider censorship, so resisting it matters.
• Several commenters tie this into broader EU speech controls (German DNS blocks, UK Online Safety Act, Chat Control proposals) and foreign disinformation (Russian/Chinese state operations, US influence).
• There’s a deep split: one side insists unrestricted speech is essential even if it enables propaganda; the other argues democracies must curb coordinated foreign manipulation.

Reaction to the CEO’s rhetoric

• Many initially agree with Cloudflare’s legal/technical stance, then recoil at the post’s tone: “shadowy cabal” language, “play stupid games” bravado, and the AI caricature of European officials.
• The explicit praise and tagging of high‑profile US political figures (seen by many Europeans as authoritarian or hypocritical on free speech) is widely viewed as self‑discrediting and polarizing.
• Several see this as reckless “Twitter‑brain” CEO behavior that makes Cloudflare look like a politicized US actor rather than neutral infrastructure.

Exit threats and centralization risk

• Cloudflare is considering: ending free services in Italy (including to journalists/NGOs), pulling Italian servers, and cancelling investment and Olympic security support.
• Supporters say leaving a jurisdiction that fines you more than you earn is rational. Critics call it “collective punishment” and a reminder that relying on a single US provider is dangerous.
• Some Europeans explicitly welcome US tech pullback as a catalyst for EU “digital sovereignty” and migration to regional CDNs and DNS providers.

Clickbait title and HN meta-discussion

• Many note the original headline was misleading and emotionally charged, mirroring the very phishing tactics being described.
• Some argue the clickbait is actually appropriate, as it exposes readers’ own susceptibility to outrage-driven clicks.
• Others see it as irresponsible and confusing about SendGrid “the company” vs. SendGrid “the infrastructure.”
• There’s repeated frustration that many commenters react to headlines without reading, and suggestions that HN (or browser extensions/LLMs) should rewrite titles to be more factual, with human review.
• The article’s author updated the title to be clearer, and HN’s title was changed accordingly.

Nature and sophistication of the phishing attacks

• Phishing emails use legitimate SendGrid infrastructure via compromised customer accounts, so SPF/DKIM can pass.
• Lures are tailored and “ragebait”: ICE support, BLM/LGBT/MLK footers, political banners, language changes, API failure notices, etc.
• Several people report receiving multiple such emails daily and find them unusually convincing and well-targeted.
• Some note this pattern across other providers (Mailgun, etc.): compromised accounts used as high-trust relays.
• The exact “unsubscribe button compromise trick” is asked about but not clearly explained in the thread (unclear).

Email security, UX, and provider responsibility

• Commenters criticize email clients (especially mobile Gmail) for hiding real sender domains and over-emphasizing display names, which makes phishing easier.
• SPF/DKIM/DMARC help only if recipients enforce them strictly and cannot stop brand impersonation from other domains.
• Some call for providers like SendGrid/Twilio to be held more accountable and to invest more heavily in abuse prevention; others note this is a broader ecosystem issue.

Defensive practices and technical ideas

• Suggested mitigations:
  • Per-service email aliases or sub-addressing (user+service@domain) to detect unexpected senders.
  • Admin-side rules (e.g., Gmail regex policies) targeting mismatches between display names and sender domains.
  • Reporting phishing to [email protected] and similar channels.
• Debate over 2FA: SMS/Authy are seen as phishable; WebAuthn is recommended but not currently offered by SendGrid.
• Some speculate about using powerful ML/LLM pipelines for phishing detection; others respond that ML-based spam/phishing filters already exist but are constrained by cost and false positives, especially against “legit but dumb” corporate email.

Politics and social engineering

• Politics is viewed as just one of many powerful emotional vectors; similar manipulative techniques appear in political fundraising texts.
• Discussion branches into how polarized narratives and existing propaganda make certain groups especially vulnerable to such tactics.

Information-theoretic bounds and what’s being encoded

• Several comments note that 26 bytes (208 bits) is well above the theoretical minimum needed to represent all legal positions (including side to move, castling, en passant), which is estimated around 152–153 bits.
• Others point out that if you only encode positions that actually occur in a specific database (“observed positions”), you can compress far more aggressively, even down to just indexing game+ply.
• There’s repeated clarification that counting “board states” is different from “game difficulty”; a huge state space doesn’t necessarily imply a hard game (example: Nim).

Clever vs practical encodings

• One camp praises the article as a fun, clever hack in the traditional “hacker” sense, useful as an exercise in bit-level thinking.
• Another camp argues that such dense encodings are rarely worth the complexity: bytes are cheap, code clarity and CPU cost of packing/unpacking are not.
• Some suggest the right scheme depends heavily on use: storing billions of positions vs querying a database vs transmitting games.

Chess engines, transposition tables, and real-world practice

• Engine-focused comments stress that top engines typically don’t store entire board states in huge tables; they use transposition tables keyed by Zobrist hashes and keep only one full board per search thread.
• Bitboards and related tricks are cited as “standard” for fast move generation rather than ultra-compact storage.

Game state vs board state and rules completeness

• Multiple commenters distinguish between:
  • Board position (pieces, side to move, castling, en passant)
  • Full game state (50/75-move counter, repetition history, clocks, etc.)
• The article’s scheme is criticized for not capturing repetition and 50-move information, which are required to decide claims of a draw.
• FEN is mentioned as a reference that explicitly includes move counters.

Castling, en passant, and logical concerns

• A central thread debates the article’s trick of overloading piece locations (e.g., using the king’s square as a special code for unmoved rooks/pawns to infer castling or en passant).
• Critics highlight edge cases: rooks or pawns that moved and returned, en passant availability after complex histories, and the difficulty of distinguishing “never moved” from “moved back” purely from piece locations.
• Some propose adding at least one extra bit to disambiguate rook-moved/en-passant-available, while others describe more intricate swap/encoding schemes to avoid extra bits.

Promotion, bishops, and bit-saving tricks

• Commenters note straightforward savings: bishops only ever occupy one color, so they can use 5 bits instead of 6 per bishop; this alone can shave several bits.
• There is extended back-and-forth about how many extra bits promotions truly cost in the worst case, with people constructing upper bounds and arguing about pawn-capture constraints.

Alternative encoding schemes (often ≈24–26 bytes)

• Multiple alternative fixed-length encodings are sketched:
  • Occupancy bitboard (64 bits) plus piece codes for occupied squares (e.g., 4 bits each), reaching 24 bytes worst case.
  • Masks of which of the 32 nominal pieces exist, plus 6-bit coordinates per surviving piece, with careful handling of cases where many pieces are missing to keep under 26 bytes.
  • Schemes that use compact 2-bit prefixes and suffixes to encode up to 12 piece types per square.
• Lichess’s production format is cited: 64-bit occupancy, then variable-length piece and state data, efficient on average and able to handle Chess960.

Moves vs positions; whole games vs single states

• Some argue that whole games are best stored as move lists, not position lists, and point to work compressing moves to ~3.7 bits each.
• Another commenter suggests directly encoding game histories as sequences of legal moves (using a move generator to index moves), potentially beating 26 bytes for typical full games but not as a universal worst-case position encoding.

“Bit-level magic” and implementation details

• One commenter objects that the article’s examples use decimal/character strings and integers, not literal bitstreams, and accuses it of misusing the term “bit-level”.
• Others respond that the examples are conceptual; the key is the count of possibilities (e.g., 495 promotion patterns fitting in 9 bits), regardless of how the article illustrates them.
• There is some confusion between theoretical bit counts and actual memory layout (bytes, padding, alignment), with clarification that a 9‑bit field will occupy 2 bytes in most practical layouts, but still only carries 9 bits of information.

Practicality and Time Commitment

• Main objection is the 50-day duration; many say few modern workers can take that much time off.
• Others counter that only a few hundred passengers per year were needed, and among billions living along the route, that’s plausible.
• Some recall an era when people traveled for months, funded by low costs in India and, in at least one case, foreign unemployment benefits.

Motivations and Nature of the Trip

• Many emphasize the journey as the point: seeing many countries, cultures, and landscapes, not just getting from A to B.
• Compared to today’s long Amtrak trips, this is framed as an “overland cruise” or moving commune, appealing to hippie-trail / nomad types and adventure travelers.
• Some mention drug/sex tourism and the broader 1960s–70s “Hippie Trail” context.
• Several personal anecdotes (Europe, US, South America, London–Afghanistan in a Fiat 500) show a strong culture of long, slow overland travel.

Cost, Inflation, and Class

• Debate over the modern equivalent of the 1957/1973 ticket price; different inflation indices give different numbers but all imply it was relatively cheap per day.
• Compared to air travel of the time, the bus seems cheaper and all-inclusive, but likely still a “rich person’s” or at least non-working-person’s option.

Comparisons to Modern Options

• People compare it to Flixbus across Europe, Cape-to-Cairo overland tours, Green Tortoise in the US, and long Amtrak routes: more for scenery and experience than efficiency.
• Some strongly argue many HN-style readers undervalue non-monetary benefits of slow travel.

Geopolitics and Route Viability

• Multiple comments note today’s route would be risky or impossible: issues in Iran, Afghanistan, and especially Pakistan–India border closures and stopped cross-border trains.
• This is used as an example of non-linear progress: technically easier now, but geopolitically harder.

Historical Accuracy and Documentation

• The Wikipedia article is criticized for conflating two services (Indiaman vs. Albert) and for implying only one bus.
• People lament the lack of interior photos and personal accounts, though some photo archives and a clearer related article are linked.

Engine choice & platform focus

• Orion uses WebKit; reasons inferred include: alignment with iOS/iPadOS (where only WebKit is allowed), good battery/performance on macOS, and avoiding Chromium’s dominance.
• Some note that Firefox’s engine is harder to embed; others just want anything non-Chromium to slow Google’s control.
• On Linux, people see value in a third major engine alongside Gecko and Blink, especially if it drives WebKitGTK forward.

Apple search lock‑in and Kagi

• Several comments vent about iOS Safari’s locked search engine list, which excludes Kagi.
• Workarounds via extensions exist but are seen as clumsy; some users say this is the main reason they won’t subscribe to Kagi.
• Comparisons are made to Android and even HarmonyOS, where adding custom search engines is easier.

Closed source on Linux: controversy

• A large subthread debates Orion’s proprietary status.
• Many Linux users say they won’t run a closed-source browser at all, citing trust, privacy, and free‑software principles—especially for such a central application.
• Others are pragmatic: they already use proprietary apps on Linux and care more about breaking Chromium hegemony than licensing purity.
• The team explains they’re small, view Orion as significant IP, fear large-company appropriation, and plan to open‑source once the browser is financially self‑sustaining. Some find this reasonable; others call it a deal-breaker.

Linux alpha, quality, and DRM limits

• The Linux build is alpha-only, initially limited to paying supporters; a direct Flatpak link is shared and early testers report rough edges and high CPU use.
• Discussion highlights that, for mainstream adoption, support for DRM/Widevine (Netflix, etc.) may be decisive; others counter they don’t care about DRM playback and would use such a browser for “serious” work only.

Features, UX, and privacy details

• Fans praise: strong built‑in ad blocking, ability to use both Chromium and Firefox extensions, and tight Kagi integration.
• Some report past instability on macOS/iOS; others say recent 1.0 releases feel much more solid.
• Concerns surface around online installers and default Kagi referrer headers; both can be mitigated but defaults and opacity worry privacy‑focused users.

Perceived role and value of MCP

• Many see MCP as a small, boring integration layer: a standardized way for agents to call tools and resources, especially across different AI clients (Claude, ChatGPT, IDEs).
• Supporters emphasize interoperability and “write once, use in many agents,” likening it to LSP or USB for AI tools rather than just a local scripting mechanism.
• Critics argue the article focuses too much on local filesystem use and misses broader agent-to-service scenarios, including async and long‑running operations, generative UI, and SaaS integration.

Comparison with Skills, CLIs, and OpenAPI/HTTP

• Several argue Claude Skills (markdown + front matter) are simpler and often sufficient; some think useful commands/docs should live in human‑oriented files and be “taught” to the AI, not moved into AI‑specific configs.
• A recurring claim: almost everything MCP does can be done with CLIs plus a shell and tools like just/make, or via existing HTTP/OpenAPI APIs.
• Others counter that MCP’s structured tool schemas, resource mounting, and stateful handles provide more predictable, testable flows than agents dynamically generating glue code or scripts.

Security, lifecycle, and operational concerns

• Strong skepticism around security: MCP is seen as an easy data‑exfiltration vector, especially if people casually add third‑party servers.
• Some argue MCP is “just the protocol” and security is an implementation concern; others reply that in practice bad ops and weak curation are common, so the risk is real.
• Process lifetime and resource usage are highlighted: one‑process‑per‑server can lead to many heavy apps idling, especially with multiple coding agents.
• There is debate over whether MCP meaningfully improves sandboxing vs. running tools in containers/VMs or via safer gateways.

Interoperability, auth, and enterprise use

• Pro‑MCP voices stress OAuth-based auth, auditability, permission prompts, and approval workflows as key for exposing enterprise SaaS/APIs to agents (including web UIs like ChatGPT/Claude).
• Others ask why not just expose OpenAPI specs and treat AI calls as normal RPC, avoiding a parallel ecosystem.

Broader AI‑for‑coding and “fad” discourse

• Thread widens into whether AI coding and tool‑calling are fads: some report disastrous experiences and see LLMs as wasteful slop generators; others say latest models, used well, dramatically speed up meaningful work.
• There’s tension between those prioritizing code quality and domain expertise vs. those emphasizing speed, delegation, and acceptance of “good enough” outputs.

Expectations vs. Reality

• Many commenters say early hype imagined WASM as a universal, cross‑platform compile target replacing JS and even containers; reality feels smaller: “Figma runs faster” and niche infra wins.
• Several compare it to the JVM story: huge theoretical promise, but it settles into important, bounded roles rather than “holy grail” ubiquity.

WASM vs JavaScript (and asm.js)

• Debate over how “groundbreaking” WASM is versus compiling to JS or asm.js; some call it “just an optimization,” others argue asm.js was a fragile hack and WASM is cleaner, faster to start, and more robust.
• Benchmarks show mixed results: JS can beat WASM in some compute cases due to sophisticated JITs; others report 2–4x speedups in real apps (image editors, complex UIs, games).
• Key technical arguments: deterministic integer types, SIMD, better load/store model, optional GC, and no mandatory JS‑style GC overhead.

Browser Integration & JS Replacement

• Strong desire in part of the community for WASM to directly access the DOM and “replace JS”; others insist this was never a design goal.
• Today most frameworks still drive the DOM via JS “glue” or virtual DOM layers, which is seen as a major limitation for building full apps and for performance.
• Some fear full‑canvas or WASM‑only UIs would damage accessibility and make ad‑blocking/scraping harder.

WASI, Containers, and Server-Side

• Mixed views on WASI as a container replacement: proponents like the sandbox and instant startup; critics say it’s a small, oddly renamed POSIX subset that doesn’t solve packaging, networking, or orchestration.
• Friction noted around multiple WASI versions, component model churn, and lack of cross‑engine uniformity.

Tooling, Standards, and Ecosystem

• Tooling is repeatedly called immature: debugging often “printf‑level,” DWARF support stagnant, C/C++ and Rust toolchains awkward, multithreading constrained by browser security headers.
• Standards politics (WASI, component model, UTF‑8 vs UTF‑16, GC model, SIMD vs flexible vectors) are seen as slowing progress and creating fragmentation and bad blood.

Binary Size & Runtimes

• Disagreement over WASM bundle size: some experience multi‑MB artifacts; others show kilobyte‑scale Rust/Go/TinyGo examples with careful optimization.
• A recurring complaint: every WASM app must ship its own runtime/stdlib (ICU, TZDB, libc, language runtime), whereas JS gets these “for free” in the browser.

Where WASM Clearly Shines

• Widely cited strengths:
  • Porting large native codebases (C/C++, Rust, Java, Go) to the browser with little change.
  • High‑performance media, games, graphics, numerical code, and emulators.
  • Safe plugin and sandboxed execution (e.g., edge functions, user-defined logic, smart contracts).
  • Hidden but critical infra in build tools, editors, libraries, and specific web apps.

Sentiment Summary

• One camp sees WASM as a quiet success: ubiquitous in niches, great for sandboxed native code, doing exactly what it was designed for.
• Another camp is disappointed: JS remains central, DOM access is indirect, WASI/container dreams are unfulfilled, tooling is rough, and hype about “replacing JS” or matching NaCl/native performance hasn’t materialized.

Ideology: Is Open Source “Communism”?

• Long subthread debates whether open source resembles communism, socialism, libertarianism, or is politically neutral.
• Critics call “open source = communism” reductive: projects are privately owned via copyright and licenses; there’s no single state owner or planned monoculture.
• Some argue source code is part of the “means of production” for tech workers so there is a socialist flavor, but others insist open source is better seen as decentralization and market-enabling.
• Several comments note that political labels are routinely abused to smear policies and that language has drifted, especially in US-centric debates.

EU Digital Sovereignty vs. US Tech Dependence

• Broad agreement that the EU is dangerously dependent on US platforms (Microsoft 365, clouds, mobile OSes, databases).
• Sanctions and recent US political instability are cited as concrete risks: critical institutions could lose access or face backdoored systems.
• Some see open source as a key tool but stress it’s not enough: real sovereignty also needs EU-based hosting, maintenance, and even hardware (e.g., CPUs).

Open Source vs. Building a Competitive EU Software Industry

• One camp: Europe doesn’t just need more OSS, it needs strong local vendors; blindly preferring OSS could undercut viable European proprietary businesses.
• Another camp: anything funded with public money should be open source; governments should demand “public money, public code” and use OSS to avoid lock-in and vendor capture.
• A hybrid model is proposed: public, open reference implementations and standards; private firms compete on top.

Funding, Grants, and Sustainability

• EU already funds many FOSS projects (e.g., NGI, NLnet, Forgejo, code forges), but typical grants (5k–50k EUR) are criticized as too small to build serious alternatives to US clouds, databases, or AI.
• Dispute over developer motivation: some say experts will work for modest pay if the work matters; others argue that without serious money Europe will keep losing top talent and never reach scale.

Procurement, Governance, and Past Migrations

• Many stress the real lever is procurement: stop defaulting to “nobody gets fired for buying Microsoft/IBM/Oracle.”
• Examples: Munich’s LiMux (technically successful but politically reversed), Schleswig-Holstein’s migration, Polish and Dutch digital government platforms.
• Open standards for data exchange are seen as at least as important as open code.
• Fears: EU might create bureaucrat-controlled “EU Linux” forks or overregulated “EUbuntu” instead of contributing to existing ecosystems.

Sovereign OSS Ecosystem and Infrastructure

• Proposals include: EU-hosted forges (Codeberg, Forgejo, Sourcehut), a “European Open Source Sovereignty Fund,” and pan‑European reference stacks (OS, office, email, browser, accounting).
• Some advocate EU-picked “baseline” OSS infrastructure (cheap to fund, fast to ship) plus enforced open standards to prevent new walled gardens.
• Others warn that tightly coupling EU money and blessing to specific projects could distort the open market nature of OSS.

Views on the Call for Evidence and EU Regulation

• Mixed reactions: some praise the Commission for asking the community; others see it as evidence they “don’t understand” OSS or just want it cheaper.
• Broader argument over whether EU bureaucracy and heavy regulation, not lack of OSS, are what hold back a thriving software industry and drive startups and talent to the US.

Role of the state vs markets in AI and industry

• Debate over whether the AI boom is mainly a private‑sector story or heavily dependent on defense spending, university STEM funding, and earlier state-backed R&D (solar, space, EUV).
• Several argue for a “yin and yang” of public and private investment that ideological camps ignore.
• Others note the US has tariffs but no coherent industrial plan (infrastructure, training, labor costs).

Tariffs, protectionism, and execution problems

• The article’s chart on trade/automation is criticized as inconclusive, especially given time lags in relocating production.
• Some support targeted import limits (e.g. Shein surcharges) in increasingly materialistic societies; others say “data not in yet” does not imply protectionism is necessary.
• Rare earths are used as a case study: the US has resources but struggles to complete long-cycle projects (mines, separation, magnets) despite years of political noise; this is framed as an institutional/capitalism problem, not a resource one.

GDP, growth, and what “economic health” means

• Long thread arguing GDP and GDP per capita are crude: they miscount illegal or harmful activity as positive, ignore unpaid work, externalities, distribution, and “usefulness” of spending.
• Books and quotes (e.g., Kennedy, “Mismeasuring our lives”) are cited to argue for broader measures: household perspective, wealth distribution, non-market activity, time-to-afford basics.
• Others defend GDP as a practical, directionally useful proxy that correlates with many quality-of-life indicators, especially at low income levels, while conceding it’s dangerous to optimize on a single number.

Housing, wealth distribution, and generations

• Dispute over whether Millennials/younger cohorts are poorer than parents: some cite wealth data showing they’re ahead at comparable ages; others argue means hide inequality and housing affordability is the real constraint.
• Housing bubbles are debated: some say past bubbles burst (2008), others see ongoing propping-up via policy, making eventual adjustment worse.
• Pension burdens and aging demographics are seen as looming shocks, especially in Europe.

Markets, stocks, and currency risk

• Discussion of households’ 401(k) exposure: stock gains may not offset rising living costs, so incumbents may not get political credit.
• Non-US investors highlight how S&P500 returns look much weaker once currency moves are included; this sparks back-and-forth over whether it’s “just a unit change” or a real loss when you must pay bills in your home currency.
• Currency hedged ETFs are mentioned but higher fees and long-run mean reversion make them controversial.

Populism, technocrats, and voter disillusionment

• Populism framed as the public reacting to “broken deals” by elites/technocrats, especially in US/EU.
• UK examples (Brexit/Reform, minor benefit cuts) illustrate perceived managed decline: taxes and debt up, services down, little bold reform, making voters receptive to “bullshit change.”
• Others stress voters themselves demand incompatible things (high services, low taxes), and populist governments often worsen fiscal problems by expanding benefits.

Resilience vs renewal

• Several caution against celebrating “resilience” (no recession, modest growth) that merely postpones pain.
• Protectionism and constant monetary easing may stabilize in the short term but slow productivity, adaptability, and deeper renewal.
• Some argue adaptability—fast reallocation of people and capital—is more important than headline growth, which can mask fragility.

What Anthropic Changed

• Anthropic restricted Claude Code subscription credentials so they can only be used by official Claude Code clients, not by third‑party CLIs like OpenCode or Crush that were spoofing the client.
• Regular pay‑per‑token API keys still work fine in OpenCode and others; only the “Claude/Max via Claude Code” subscription path is blocked.
• Some third‑party clients using Claude Code via ACP or the official Agent SDK appear unaffected, since they’re treated as first‑party surfaces.

Loophole vs. Terms of Service

• Many commenters note this use was always a ToS violation and depended on reverse‑engineering and “you are Claude Code” prompts; they see this as Anthropic finally closing an obvious loophole.
• Others argue that from a user’s perspective, they were paying for model access, not a specific UI, so losing third‑party usage feels like a paid feature being removed, even if it was never officially supported.

Economics, Lock‑In, and Data

• Strong consensus that Claude Code/Max is heavily subsidized: for power users, equivalent API usage would reportedly cost multiples of the $200/month fee.
• One camp says it’s rational for Anthropic to constrain how that loss‑leader is used, to avoid third parties extracting maximum tokens without giving Anthropic product lock‑in, telemetry, or training data.
• Another camp frames this as early “enshittification” and vendor lock‑in: using pricing to force a buggy first‑party tool instead of letting the best harness win.

Technical Details and Arms Race

• Under the hood, Anthropic initially gated access via mild behavioral checks (system prompt, tool names like read), which OpenCode and others mimicked; Anthropic then blocked those patterns.
• Workarounds landed quickly (renaming tools, updated auth plugins), but several predict a cat‑and‑mouse escalation: obfuscation, cert pinning, behavior analysis, and possibly “BotGuard‑style” client integrity systems.

Claude Code vs. OpenCode Quality

• Many developers praise OpenCode’s engineering (TUI runtime, web/desktop reuse, multi‑provider support, fewer UI bugs) and call Claude Code flickery, sluggish, and janky in tmux/screen.
• Others report Claude Code works fine for them and note its careful token optimization, tool selection, and tight integration with Anthropic’s models.

User Reactions and Switching

• Visible number of users say they canceled Claude subscriptions or won’t renew, moving to OpenAI, GLM, Grok, Cerebras, or other coding agents via OpenCode.
• Some shrug, seeing this as an inevitable tightening of “unlimited” SOTA offerings and a reminder that models are becoming a commodity while control over the client/harness becomes the real battleground.

Product philosophy: complexity vs “frictionless” apps

• Several commenters resonate with the tension the essay describes: tools that genuinely teach and deepen understanding often require effort and “friction,” which clashes with modern growth-driven UX ideals.
• Some compare this to generative AI trends where skill-building is treated as optional or even exclusionary.
• Birders note that many users choose eBird + Merlin because it’s easier, but some prefer iNaturalist precisely because it slows you down, forces judgment, and yields more trustworthy records.

iNaturalist, Seek, and user experience

• Many see iNaturalist as on par with, or even more personally impactful than, Wikipedia: a daily tool for learning species, ecosystems, and taxonomy.
• Seek is praised as a lightweight gateway for casual users and families; others find it naggy (e.g., repeated “don’t disturb nature” warnings) and switch to the main app.
• Several argue the current split is confusing: Seek feels like “just a feature” that should be the iNat mobile front door, with the full web UI as the real power-user interface.
• Complaints include clunky observation workflows, poor mobile performance, slow image loading, and an “old” feel, which discourage deeper engagement.

Scientific value and data quality

• Supporters emphasize iNat as a unique, massive biodiversity record feeding into GBIF, used in conservation organizations and research (e.g., species distributions, invasive species, modeling).
• One commenter reports that in their rare-plant work, iNat is a useful first-pass data source but often not publishable on its own.
• Another initially doubts real scientific use but is pointed to GBIF’s citation tracking showing thousands of iNat records in some studies.

AI models, openness, and data control

• A strong thread criticizes iNat’s closed machine-learning models as contrary to open science and to a 501(c)(3)’s public-interest mission, given that models are trained on community data.
• There are allegations of forum posts on this topic being “not approved” and effectively sidelined.
• Others agree models should be open but distinguish that from calls to “ban AI,” noting ML is now integral to large-scale scientific analysis.

Governance, leadership, and organizational design

• Long subthreads debate sociocracy, “unstructured anarchy,” and agile/flat structures.
• Critics say the described governance experiments lacked clear accountability, and that the author stepped out of formal leadership yet continued pushing strong product opinions.
• Defenders argue that non-hierarchical models can work when participants are aligned and trained, and that experiments in democratic governance shouldn’t be dismissed just because they’re hard.
• More broadly, commenters see a familiar pattern: as platforms scale, they introduce hierarchy, optimize for growth and risk management, and gradually alienate the early contributors who built their value.

Real-world usage and impressions

• Used successfully for BLE and LoRa projects, USB video-to-OLED streaming, MQTT-based HomeAssistant nodes, and a guitar amp BLE controller.
• Generally reported as stable; panics usually attributed to vendor softdevices rather than Embassy itself.
• Strong praise for the overall Rust embedded toolchain around it: probe-rs, defmt, embedded-hal, and PAC crates.
• Microsoft uses it in an embedded-controller project; Ariel OS is built on it, and it coexists with other ecosystems like RTIC and Xous.

Async vs blocking and ecosystem “split”

• One concern: much new embedded Rust OSS is written assuming Embassy-style async, creating friction for those preferring synchronous or bare-metal styles.
• Others counter that many Embassy HALs expose near-parity blocking APIs and still lean on embedded-hal, so you can mostly avoid async if desired.
• Reimplementing simple drivers per framework is seen by some as acceptable and even desirable; skepticism expressed toward fully generic HALs.

Power, ergonomics, and concurrency model

• Proponents highlight:
  • No-heap async, cooperative multitasking, and automatic CPU sleep at await points.
  • Dramatic ergonomic gains versus hand-written state machines and interrupt-driven globals, especially for multi-IO workflows (double buffering, timeouts, composition).
• Critics argue async is not inherently more power-efficient; WFI/sleep and interrupts work just as well in non-async designs, and “async vs blocking” is a false dichotomy.

RTOS vs async and real-time guarantees

• Embassy markets itself as obsoleting traditional RTOSes for many use cases; some users agree for general-purpose microcontroller firmware.
• Others strongly object:
  • Async Rust provides cooperative concurrency, not hard real-time guarantees.
  • Traditional RTOS features—preemptive scheduling with bounded latency/jitter and strict timing guarantees—are not replaced.
  • Concern that README language overstates what async/Embassy provides.
• Comparison with FreeRTOS and RTIC sparks debate; one link shows good latency numbers, but at least one commenter calls the comparison “apples to oranges.”

Hardware, getting started, and constraints

• Recommended MCUs: RP2040, ESP32-C3/C6, STM32 Nucleo boards, Nordic nRF52/nRF54 (the latter still incomplete), with praise for integrated debugging and good docs.
• Raspberry Pi SBCs are considered “embedded Linux,” not the typical microcontroller target for Embassy.
• Some worry about large dependency graphs (100+ crates for a blinky) due to supply-chain and regulatory tracking; others see that as an acceptable trade-off for a modern embedded experience.

Perceptions of the Shooting

• Many commenters characterize the killing as an extrajudicial execution or murder, emphasizing the victim’s role as a mother and the orphaned child.
• Strong focus on officer responsibility: he had a prior car-related incident, appears to ignore basic training (never stand in front of a vehicle), and escalated a low-level situation into lethal force.
• Others argue it’s not “clear cut”: they claim the video shows the car initially moving toward the officer on icy pavement, say he could reasonably have perceived an attempt to run him over, and that split‑second decisions complicate judgments of intent.
• A recurring sub‑debate centers on the 2nd and 3rd shots from the side window; even some who see the first shot as arguable self‑defense see later shots as indefensible and purely punitive.

ICE, Policing, and Impunity

• ICE is widely described as a paramilitary force whose “MO is intimidation,” with repeated comparisons to Nazi brownshirts and 1930s Germany.
• Commenters argue positions that allow state violence attract people who want to use it, especially when abuse is rarely punished; analogies are drawn to abusive clergy shielded by institutions.
• Several call for abolishing ICE (noting it was only created in 2003), or for criminal trials for senior officials; others frame this as now the “moderate” position.

Broader Authoritarianism and Political Response

• Many see the official response—lying, labeling the victim a terrorist, uncritical praise for the shooter, memes, threats of more violence—as more disturbing than the shooting itself.
• The killing is interpreted as part of a pattern: pardons for January 6 participants, attacks on courts and media, attempts to criminalize filming ICE, and talk of canceling elections—all read as steps toward a permanent authoritarian regime.
• Some insist this goes beyond “normal politics” and is about the survival of democracy; others argue that HN should avoid US political fights even while calling the killing horrible.

International and Comparative Perspectives

• Commenters compare immigration enforcement elsewhere:
  • Russia: no ICE‑like unit; ordinary police rarely shoot at cars, though torture and abuse happen after detention.
  • India: forcible expulsions and disregard for court orders.
  • UK: strong anti‑“illegal” immigrant sentiment but not comparable street shootings.
• One cites global polling showing immigrants often seen as a strength, countering the idea that anti‑immigrant sentiment is universally rising.

HN Meta and Community Reaction

• Frustration that the thread was flagged; multiple users accuse the community of cowardice, “no politics” evasions, and tacit support for authoritarianism.
• Others caution against absolutist “with us or against us” thinking and note the need for rare exceptions to HN’s politics‑avoidance when events are extraordinary.

Usefulness of the Map & Data Gaps

• Map is praised as a helpful visualization of unrest across Iran.
• Several note that internet shutdowns mean recent events are under‑reported, so current density is likely an undercount.
• Some ask what “small/medium/large” crowds mean numerically; one reply claims “millions”, but this isn’t clearly grounded in the map itself.

Nature of the Protests & Foreign Influence

• One early comment alleges the protests are not organic and are backed with foreign cash and weapons, specifically blaming Israel and Mossad.
• Others strongly reject framing this as primarily Israeli propaganda, emphasizing Iranian agency and longstanding domestic grievances.
• A subset of commenters insist this and similar posts are part of an Israeli/Zionist campaign to build support for a future strike on Iran.

Risk, Repression & Role of Arms

• Commenters express admiration for protesters facing a violent, repressive state and fear many will be killed or jailed.
• There is debate on whether street protests alone can topple the regime; some argue that without weapons, the state will just wait or crush dissent.
• This spills into a US‑centric argument over the 2nd Amendment:
  • One side says an armed populace is essential to successful revolt.
  • Others counter that small arms rarely decide revolutions, that past regime changes often came via mass protests and army defections, and that widespread guns can just empower warlords or loyalist militias.

Iran’s Political Future: Shah, Democracy, History

• Some lament that legitimate grievances are being tied to calls to restore the Shah, described by critics as also brutal and corrupt.
• Others reply that, given the current regime, many Iranians see the exiled monarch as a lesser evil or transitional figure; cited polling suggests he’s the single most popular opposition symbol, though still a minority preference.
• Long subthread debates 20th‑century history:
  • One side stresses the 1953 CIA/MI6‑backed coup against Mosaddegh as a key blow to Iranian democracy, leading to decades of dictatorship and setting the stage for the Islamic Republic.
  • Opponents argue Mosaddegh had already centralized power and undermined democratic norms, so calling it a coup against a “genuine democracy” is misleading.
  • They agree, however, that the Shah’s later rule was clearly authoritarian.
• Broader question: can Iran realistically move to a non‑autocratic, liberal system given its history of monarchy and theocracy, and ongoing great‑power interference?

Regional, Environmental & Long‑Term Pressures

• Some argue authoritarian clampdowns have limits because of looming economic collapse and, especially, severe water scarcity driven by groundwater overuse and inefficient agriculture/industry.
• Others note similar unsustainable groundwater extraction in parts of the US, framing this as a global pattern of “exporting water” via agriculture.

Comparisons to Other Countries

• Several compare Iran’s protests with those in the US and Israel:
  • Some accuse Americans of hypocrisy for focusing on Iranian oppression while downplaying ICE, deportations, and domestic killings.
  • Others say the current US use of ICE and similar forces represents a more violent, terrorizing shift than past administrations.
  • Israel is described by some as a “terrorist” or “apartheid” state with large internal protests that get less Western amplification; others defend it as a democracy and dispute the “genocide” framing.

HN Meta: Politics, Flags & “Propaganda”

• Multiple commenters complain that US‑focused political posts often get flagged off HN as “current affairs”, while highly political foreign posts like this stay up.
• Some see heavy flagging of anti‑Israeli or anti‑US comments here as evidence of coordinated manipulation; others dismiss that and say you only see what survives moderation.
• One line of argument is that this story deserves exceptional attention because collapse of Iran’s regime would have outsized global impact; critics respond that such framing ignores US/Israeli aggression and regional destabilization.

Technical Issues with the Map

• Several Firefox users report the map showing only a grey panel with UI controls.
• Others confirm it works on various Firefox versions and platforms but requires:
  • Allow‑listing certain third‑party CDNs (fastly, cartocdn, tailwind, unpkg) in blockers like uBlock Origin.
  • Hard refreshes; some observe it “just starts working” later, possibly due to GitHub Pages/CDN quirks.

Perceived Audio Quality & Usefulness

• Many praise the project as impressive given its small size and CPU-only constraints; some find it “good enough” and fun to experiment with.
• Others think the demo sounds extremely robotic, distorted, or “warped cassette–like,” and say they cannot imagine anyone mistaking it for a human voice.
• Several note strong dependence on the reference audio and parameters; poor references can yield very rough output.
• Some users report partial similarity to target voices and find it impressive for the low training budget and easy local use.

Comparisons to Other TTS Models

• Chatterbox-TTS is repeatedly cited as a higher-quality alternative, especially with GPU hardware; its outputs are described as “incredible” compared to Sopro’s artifacts.
• Kokoro (82M) is mentioned as another high-quality, lightweight local model, though some browser/latency issues are reported.
• Other open-source options brought up include Vibe Voice, F2/E5, and Higgs-Audio; some consider Vibe Voice the only viable OSS option for high-quality cloning.
• Commercial systems like ElevenLabs are referenced as current quality benchmarks, especially for speech-to-speech.

Zero-shot Voice Cloning Terminology

• A long subthread debates what “zero-shot” means.
• One camp uses the ML definition: zero-shot = no weight updates for unseen speakers; reference audio at inference is just conditioning context.
• Another camp argues that if you must supply an example voice clip, it’s intuitively “one-shot,” and the term is misleading.
• Consensus: terminology is overloaded and confusing, but in this project “zero-shot” means no per-speaker training or fine-tuning.

Use Cases & Ethical Concerns

• Positive use cases: local voice assistants, on-demand audiobooks, accessibility and restoring voices lost to disease, automation of phone chores.
• Strong concern about scams and impersonation (e.g., calls to elderly relatives); some question whether the societal downsides outweigh benefits.
• A philosophical thread debates whether “bad technology” exists or only bad uses, with analogies to weapons technologies.

Technical Details & Constraints

• Author states this is a hobby project trained for roughly a few hundred dollars; community interest might justify a larger, higher-fidelity model.
• Model size (169M) excludes the Mimi codec parameters; uses FiLM for speaker conditioning.
• CPU-speed claims (e.g., ~7.5s to generate ~30s audio) are seen as impressive relative to typical GPU-heavy TTS setups.

Core idea: agent = LLM + tools + loop

• Many commenters agree the article accurately captures the conceptual core: a while-loop where the LLM chooses tools, the harness runs them, and results go back into context.
• Several minimal examples are shared (tens of lines in Bash, JS, PHP, Python) to show how small a usable loop can be.
• The post is compared to earlier “how to build an agent” pieces that made the same “emperor has no clothes” point.

Where real Claude Code diverges

• Multiple people say the article is now out of date: current Claude Code has parallel subagents, hooks, skills, improved planning, TODO/task management, and more sophisticated context handling.
• There’s internal plumbing not visible from the loop: UUID-threaded histories, message queues, file-history snapshots, subagent side-chains, queuing of tool calls, etc.
• Some describe Claude Code as closer to a RL‑trained conductor/orchestrator than a 200‑line script.

Harness vs model quality

• One camp argues model improvements (e.g., newer Claude Opus vs earlier Sonnet) dominate; simple harnesses like mini-swe-agent can match or beat fancy ones if the model is strong.
• Another camp says harness details matter a lot in practice: UX, planning, skills, approvals, context pruning, and parallelization can make a weaker model plus good harness competitive for many tasks.
• Benchmarks and anecdotal comparisons suggest large quality gaps between model generations that no harness can fully erase.

Planning, TODOs, and “early stopping”

• A recurring pain point is premature task completion: the model stops after a few steps and declares “done.”
• Claude Code’s TODO/task tools, repeatedly injected into prompts and kept at the top of context, are cited as a key mitigation; experiments show disabling them significantly degrades performance.
• People describe custom variants: persistent “plan.md” files, working-memory files, DSLs for task termination, and “nudges” when the model forgets to call tools.

Production complexity, safety, and skepticism

• Practitioners building large-scale agents emphasize edge cases: user messages during active loops, Slack/webhook integration, approvals, error handling, structured decoding, and resuming async tasks.
• Some liken the article to “Twitter in 200 lines”: educational but glossing over the bulk of real-world complexity.
• Concerns are raised about agents’ broad filesystem access and the risks of running them unsandboxed.