Hacker News, Distilled

Bug and Root Cause

• The issue was Ubuntu’s use of uutils’ Rust date as a drop‑in replacement for GNU date.
• The -r/--reference option (print mtime of a file) was parsed but effectively ignored, falling back to “current time”.
• This behavior dates back to the initial “partial implementation of date” in 2017: the flag was accepted, documented in --help, but never wired into the logic.
• When Ubuntu’s update system used date -r to decide if updates were needed, it silently mis‑behaved and skipped automatic updates.

Testing, Maturity, and Responsibility

• Upstream GNU coreutils had no test for date -r until after this incident; a new test was just added.
• uutils explicitly does not yet pass the full GNU coreutils test suite; for date, several tests are still skipped or failing.
• Many commenters argue Ubuntu should not have shipped this as the default coreutils until test coverage and behavior parity were much closer.
• Some blame Canonical for rushing a core replacement without end‑to‑end tests of critical paths like system updates; others fault uutils for accepting unimplemented options without error.

Rust Culture, Stability, and Breaking Changes

• A long sub‑thread argues over whether Rust has a “ready to break things on a whim” culture.
• Critics point to Rust 1.80’s type‑inference change that broke existing crates (e.g. time) and caused pain for ecosystems like Nix, and to Cargo’s historic tendency to pull newest deps that might require a newer compiler.
• Defenders counter that:
  • These changes were discussed and not “on a whim”.
  • Such breakages are rare and heavily scrutinized.
  • Compared to C/C++ compilers and GNU extensions, Rust’s overall stability focus is strong.
• There is also debate over pre‑1.0 (0.x) crate versions and whether they actually signal instability or just version‑number conservatism.

Security vs Licensing Motives

• Canonical’s public rationale: resilience and memory safety for core tools, not primarily performance.
• Some commenters doubt the security payoff for low‑attack‑surface tools like date, and note that rewrites introduce new logic bugs anyway.
• Others emphasize that coreutils do process untrusted data (files, checksums, encodings), so memory‑safe implementations are inherently valuable.
• A separate line of discussion suspects licensing is key: GNU coreutils are GPLv3, while uutils is MIT, which is more comfortable for embedded and locked‑down devices.
  • Some see this as part of a broader trend away from GPLv3; others counter that Ubuntu still depends on GPLv3 components (e.g. libgcc) so this alone doesn’t free them.

Rewrites, Maintenance, and Ecosystem Impact

• One camp views Rust rewrites of mature tools as “attention‑seeking” or “virtue signaling”, arguing effort should go to maintaining and verifying existing C code.
• Another camp argues:
  • Rewrites uncover underspecified behavior and gaps in original test suites (as happened here).
  • Rust’s defaults and type system reduce entire classes of bugs compared to relying on optional static analysis in C.
  • New code in Rust may be more attractive to future maintainers than legacy C.
• There is concern that fragmented rewrites (coreutils, sudo, etc.) increase compatibility risk in an ecosystem already rich in fragile shell scripts.

Ubuntu Release Strategy and Risk Tolerance

• Some see using 25.10 (a non‑LTS release) as an acceptable testbed to shake out bugs before 26.04 LTS.
• Others note that Canonical markets interim releases as “production‑quality”, so shipping incomplete coreutils there is still inappropriate.
• Several users say this, combined with snaps and other disruptive changes, pushes them toward Debian or other “boring” distros.

Testing Techniques Going Forward

• Suggestions include:
  • Differential testing/fuzzing against GNU coreutils as an oracle.
  • Property‑based testing or Hypothesis‑style generators driving both implementations.
  • Static checks or argument‑parsing frameworks that reject recognized‑but‑unused options instead of silently ignoring them.

Leadership, Culture, and Succession

• Many tie the loss of detail-obsession directly to the former CEO’s death and inadequate succession planning.
• Current leadership is framed as an operations/finance regime: optimizing margins, OKRs and shareholder expectations rather than product taste.
• Some argue a visionary, product‑obsessed CEO is required to enforce quality and say “no” at scale; without that, middle management optimizes for metrics, not craftsmanship.

Perceived Software Decline and iOS 26/Tahoe

• iOS 26 and macOS 26/Tahoe are repeatedly called buggy, slow, and visually incoherent: broken animations, layout shifts, black camera viewfinders, CarPlay glitches, Bluetooth instabilities, and performance regressions even on new devices.
• Several note that virtually every screen they use daily has at least one obvious defect; others say their own installs are mostly fine, suggesting uneven quality.
• Some see this as a long-running “software quality crisis” rather than a one-off bad release.

Liquid Glass, Notch, and Visual Direction

• Liquid Glass is widely criticized as low-contrast, washed out, blurry, and MySpace‑like; some like its playfulness but still see poor refinement and accessibility.
• The notch on Macs/iPhones remains contentious: defenders point to extra pixels; critics cite hidden menu items and “stolen” usable space.
• Accessibility settings (larger text, dark mode) are reported to break layouts and make core apps unusable, especially for older users.

Features vs Quality and Release Cadence

• Many blame a “feature treadmill”: yearly OS branding and stock/press pressure push flashy features over polish.
• Suggested alternatives include biannual or tick‑tock releases (features then refinement), but commenters doubt current leadership would sacrifice perceived growth.
• Some say attention to detail hasn’t vanished but has been redirected into dark patterns (iCloud upsell, “Not now” prompts) instead of UX.

Hardware Strength vs Software Weakness

• Broad agreement that Apple’s hardware (Apple Silicon, battery life, trackpads, displays) is excellent; some say this is the only thing saving the company’s reputation.
• Others list long-running hardware missteps (butterfly keyboards, bending phones, thermal issues) to argue “legendary quality” was always overstated.

Everyday UX Frictions

• Numerous concrete annoyances: confusing Apple Pay card changes, Screen Time/parental controls that barely work, aggressive security pop‑ups, Safari layout regressions, keyboard and text‑selection oddities, inconsistent search and Settings navigation.
• Users report modal dialogs that resize after appearing, delayed UI readiness, and animations that block interaction.

Myth vs Memory and Ecosystem Shift

• Some argue the attention-to-detail legend was always partly myth; classic Mac OS and Snow Leopard also had serious flaws, but competitors were worse.
• Others stress that older Macs still felt cohesive under a clear “Macintosh Way”; today macOS is seen as just another web‑ and mobile‑influenced platform with nagging and lock‑in.
• Comparison point: despite complaints, many still find macOS markedly preferable to Windows 11 and Android UX.

Culture, Talent, and Gatekeeping

• One line of discussion blames cultural dilution: original “A players” left, hiring standards softened, and gatekeeping against low-skill or misaligned hires weakened.
• Others push back, arguing management incentives, not inclusivity or DEI, drive decline; harsh “brutal honesty” is contrasted with professional, tactful communication.

User Responses and Alternatives

• Some long‑time users vow to freeze on older OS versions or delay upgrades by a year; others plan to switch to Android or Linux desktops (Fedora, Mint, Omarchy, helloSystem, Framework laptops).
• A minority genuinely like iOS/macOS 26’s new features and aesthetics and report few issues, suggesting experiences vary widely.

EV BATTERY LONGEVITY & SUPPLY TIMING

• Many commenters note EV packs are lasting far longer than early projections, with modest degradation (~5–20% over ~10 years) in well-engineered packs.
• As a result, the anticipated “wave” of retired EV batteries hasn’t arrived yet; most packs are still within warranty and in cars.
• Companies built around recycling/second-life (e.g., from 2017 onward) are only now seeing EV batteries become a majority of their intake, mainly from crashes and early failures, not end-of-life degradation.
• Expectation: meaningful volumes for large-scale reuse/recycling likely appear in the 2030s–2040s, tracking the 8–15 year lag from mass EV adoption.

---

SECOND-LIFE VS NEW BATTERIES: ECONOMICS

• Several argue second-life packs work technically, but may not be cost-competitive with cheap new LFP or sodium-ion grid batteries once you add testing, repackaging, and certification.
• The expensive part of grid-scale storage is often integration (power electronics, switchgear, siting, controls), not cells—so saving on cell cost via second-life may only shave a small fraction of total project cost.
• Competition for salvage packs is already strong (DIY, small storage firms), keeping used pack prices fairly high.

---

WHY “USED UP” EV PACKS CAN STILL WORK FOR THE GRID

• Key difference: cars need high energy and power density (weight/space critical, high current bursts for acceleration and fast charging).
• Grid and behind‑the‑meter storage mostly need lower C‑rates over hours; space and weight are cheap.
• At ~80% capacity, EV packs may be range‑ and performance‑limited in cars but still perfectly usable for slow, daily cycling at modest power levels.
• Degraded packs often have only a few weak modules; removing or down‑rating them and operating the rest gently can yield many additional years.

---

SAFETY, REGULATION & PRACTICAL OBSTACLES

• Second-life systems must pass stationary safety standards; regulators often treat reused packs as if they were new designs, duplicating tests already done for the vehicle.
• This adds cost and delays, and founders report difficulty competing with purpose-built Chinese grid batteries even when EV packs are “free.”
• Large‑scale battery fires (e.g., Moss Landing) loom over the sector; operators claim improved layouts and fire management, but real‑world validation is still pending.

---

ALTERNATIVE STORAGE PATHS

• Multiple commenters think the main grid‑scale future is cheap purpose‑built storage:
  • LFP and emerging sodium‑ion for batteries.
  • Thermal storage (e.g., sand/dirt heated to hundreds of °C) for low‑cost, long‑duration or heat applications.
  • Pumped hydro between reservoirs for multi‑day/seasonal storage.
• Detailed subthreads dive into thermal‑storage physics (heat capacity of dirt/sand, steam cycle temperatures, heat‑exchanger design) and conclude it is technically feasible and potentially extremely cheap for heat, harder for electricity.

---

VEHICLE‑TO‑HOME/GRID & DISTRIBUTED STORAGE

• Several see more near‑term impact from first‑life EVs used as mobile storage (V2L, V2H, V2G):
  • Even 1.5–2 kW continuous V2L, combined with a modest home battery, can significantly buffer household loads and outages.
  • Some users already feed EV V2L into “generator” ports of solar inverters as an ad‑hoc home backup and arbitrage tool.
• Obstacles: limited V2L power, lack of standardized two‑way charging, high cost/complexity of certified V2G chargers, and lifestyle friction (managing SOC nightly to save small sums).

---

RECYCLING, USED MARKETS & OTHER USES

• True recycling is still early because few packs have reached end‑of‑life; current streams are mostly production scrap and accident write‑offs.
• Some argue the most profitable reuse may be in high‑margin consumer segments (tool packs, e‑bikes, small residential systems) rather than utility‑scale.
• Home‑storage costs are dropping fast; DIY‑oriented commenters cite turnkey LFP systems in the ~€75–150/kWh range, arguing residential solar “wants” batteries and that second-life EV cells are competing against rapidly falling new‑cell prices.

---

BROADER ENERGY-SYSTEM DEBATE

• Several threads contrast solar+storage with nuclear and prospective fusion:
  • One side: solar + batteries + other storage is already cheaper and scaling orders of magnitude faster than nuclear; fusion is viewed as perpetually “20 years away” and likely uneconomic versus mass‑manufactured PV plus storage.
  • The other: long‑duration/seasonal storage for cold, cloudy periods remains unsolved at low cost; firm generation (nuclear, possibly future fusion) still seen as necessary in some geographies.
• Overall, most participants treat second‑life EV batteries as a useful niche contribution, not the core solution to grid decarbonization.

AI Gun Detection and System Design

• Commenters argue the core failure is using a probabilistic, opaque model for a high‑stakes, binary decision (“gun or not”) on children.
• Many doubt such vision systems can ever reliably identify concealed guns; at best they see “bulges” and shapes, which will always produce many false positives.
• People suspect it’s just a dressed-up off‑the‑shelf object detector (e.g., YOLO) monetized with security theater marketing (“near-zero false positives”) and no public accuracy data.
• Several insist any such system must: publish false-positive/negative rates, attach calibrated confidence scores, and always route raw video to humans before any law-enforcement action.

Police Response, Racism, and Risk

• A large part of the thread says the real issue isn’t AI but US policing culture: militarized responses, guns drawn first, little accountability, and qualified immunity.
• Many see this as functionally a “robotic swatting”: an automated alert creates a life‑threatening scenario out of nothing.
• Race is heavily discussed: multiple commenters say they assumed the student would be Black before opening the article, and doubt a white student in a wealthier area would be treated the same.
• Others push back that police violence is broader than racism alone, but links and anecdotes about disproportionate harm to Black people are cited repeatedly.

Information Flow and Incentives

• A local report (cited in the thread) says the central safety office canceled the alert, but the principal still involved the school officer, who then called in outside police.
• This is seen as “better safe than sorry” logic with asymmetric incentives: ignoring an alert risks career and lawsuits; overreacting shifts risk to the student.
• Several note that once AI flags something as a gun, humans are biased to see a gun in the image.

Surveillance, Civil Liberties, and Normalization

• Many connect this to TSA scanners, school content-monitoring tools, and facial/gait recognition: a broader trend of pervasive, for‑profit surveillance justified as “safety.”
• Commenters describe a dumb, uncool cyberpunk/Robocop/Brazil‑style dystopia where “computer said you’re dangerous, prove otherwise at gunpoint.”
• There’s concern that false positives will both traumatize kids and, over time, cause operators to discount real alerts, making everyone less safe.

Proposed Responses and Accountability

• Suggested remedies: ban or suspend such systems in schools; mandate human review with full video context; drastically de‑escalate initial police posture; or abolish SWAT‑style responses entirely.
• Many call for civil suits against the district, vendor, and decision‑makers, with some advocating personal liability for executives and superintendents rather than only taxpayer‑funded settlements.

What Sky Is and Why It Matters

• Commenters explain Sky as a macOS-only “natural language interface” that watches your screen, understands context, and can act through system APIs and app intents.
• It’s often compared to Alfred/Raycast + LLM, or a more powerful, context-aware version of Apple Shortcuts/Automator on the desktop.
• Several note that the team previously built Workflow/Shortcuts and are seen as having strong Apple-platform product taste and deep OS knowledge.

Reactions to the Acquisition

• Many see it as a classic acquihire: buying a small, pre-launch app mainly to get a specialized macOS team.
• Some are surprised Apple didn’t buy them, given prior history with the same founders and Apple’s weak visible progress on AI assistants.
• Others argue Apple may have tried, or that ambitious engineers prefer working outside Apple’s constraints.

OpenAI Strategy, Moat, and Valuation

• A number of comments link this to broader consolidation and “tech feudalism,” where big AI players buy out promising small companies to absorb talent and attention.
• Some worry OpenAI is using VC money and M&A to justify a high valuation without clear profitability or durable moat.
• Others counter that acquisitions are a normal growth lever, even for startups, citing historical examples from Google, Microsoft, and Apple.

Apple’s AI Posture vs. OpenAI’s Push on macOS/iOS

• Multiple threads criticize Apple’s “atrocious” AI execution and Siri’s limitations, though a few report recent quiet improvements in Siri answers.
• One camp says Apple is wisely cautious: LLM assistants are inherently unreliable and hard to control, clashing with Apple’s “appliance-like,” predictable product philosophy and risk profile.
• Another camp says Apple has simply fallen behind and ceded ground; OpenAI is “skating to where Apple should be,” with a Mac ChatGPT app, Sora for iOS, and now Sky.
• There’s speculation that OpenAI is inching toward being an OS-like layer or “cover” over existing systems, and that Apple/Google/Microsoft could still cut them off at the platform level.

Privacy, UX, and Usefulness Concerns

• Some find the Sky demo underwhelming, focused on trivial tasks (messages, calendar, travel bookings) and “Clippy-like” hand-holding.
• Skeptics question whether AI agents on top of human-centric UIs are the right way to automate, versus proper APIs.
• There is unease about an app that continuously “watches your screen” and sends context to OpenAI, with users hoping Apple will allow strong local-only alternatives or restrict such access.

Scope and relation to Claude Code

• Confusion over whether Claude Code already “has memory”: some see CLAUDE.md and skills as a memory system; others argue real memory means automatic, selective remembering/forgetting across chats.
• New feature is seen as analogous to ChatGPT’s account-level memory and to “workspaces” / “projects” that have their own persistent pre-prompts.
• Projects are described as having separate memory spaces, which users hope will prevent cross‑contamination between general chats and project work.

Perceived benefits

• Users like not re‑stating environment, preferences, or personal context (OS, tools, frameworks, car model, city, skill level, etc.).
• Memory can make troubleshooting, learning new tech, and ongoing coding projects smoother; project‑wide instructions reduce repetitive prompting.
• Some value the “ongoing relationship” feel and style mirroring (tone, slang).

Skepticism and drawbacks

• Many power users prefer “functional” stateless chats: hidden, auto-injected context makes behavior harder to reason about and debug.
• Reports that memory-like features elsewhere led to noisy, irrelevant or stale facts, hallucinated memories, and reduced creativity due to “context rot.”
• Concern that models get stuck in ruts: once an early wrong path or partial plan is in context, iterative edits often perform worse than starting a fresh chat.
• Several note recent regressions: more tool-writing instead of direct answers, broken Claude Code behavior, and over-eager skills usage.

Privacy and data control

• Strong push for memory to live locally; server‑side memories are compared to cloud game saves with far higher sensitivity.
• Worries about legal exposure (“search warrants love this”), corporate data, and LLMs as de facto journals/therapists.
• Anthropic’s docs (as quoted) promise project‑scoped memories, incognito/temporary chats, and user-visible/editable memory summaries, but some remain wary and want clearer, simpler controls and a true “anonymous mode.”

Safety, “AI psychosis,” and anthropomorphism

• Memory is linked by some to ChatGPT “psychosis”/sycophancy: reinforcement of bad patterns and false sense of a persistent persona.
• Others fear Anthropic’s heavy anti‑sycophancy training plus memory could amplify adversarial, paranoid behavior.
• Debate over anthropomorphic language (“thinks”, “deceives”): some see it as harmful confusion; others as practical shorthand so long as you don’t assign personhood.
• Example system text where Claude must explicitly tell lonely users it can’t be their primary support system is noted; opinions split between appreciating guardrails and seeing “safety” as marketing or incomplete without published evals.

Prompting and context strategies

• Many share workflows:
  • One‑shot, high‑precision prompts; if wrong, edit and resend rather than chat back‑and‑forth.
  • Use temp/incognito chats to avoid memory contamination.
  • Use CLAUDE.md / instruction files and short, focused project prompts; keep them neither too long nor too vague.
  • Periodically start new chats to reset accumulated “garbage context.”
• Dispute over “forget everything so far”: technically old tokens remain, but some users find such instructions empirically help steer attention away from earlier content.

Implementation questions and meta‑discussion

• Some ask how this differs from RAG and what context/token budget it consumes; others note it’s “just more context engineering” and not fundamentally new.
• Concerns about feature fatigue and constant tweaks (skills, memory, tools) making models feel less predictable.
• A few note that first‑party memory layers vs open, model‑agnostic context managers (MCP tools, external DBs) are competing approaches; many are already rolling their own.

Definition of “slop” and naming controversy

• Many argue the paper misuses “slop”: common usage is “low-effort, low-quality, high-volume AI output,” not just repetitive phrasing.
• Others say the term is already broader still: often just “content I don’t like,” or any low-value content (including clickbait/Buzzfeed-style writing, corporate-speak, etc.).
• Some note a narrower precedent in specific communities (e.g., LLM roleplay) where “slop” does refer to repetitive stereotyped output, but criticize the paper for not clearly defining or sourcing its use of the word.
• Several commenters wish the authors had coined a more precise term like “LLM fluff phrases” or “diction/phraseology artifacts.”

Does Antislop just create “stealth slop”?

• A recurring concern is that suppressing obvious verbal tics will merely make AI-generated slop harder for humans to detect, benefitting SEO spam and content farms.
• Some see this as akin to “gain-of-function” for memetic spread: improving evasion of AI-text detectors and human pattern-recognition without improving underlying quality.
• A few explicitly prefer the tics to remain as visible “warning labels” for mode collapse and AI-written prose.

Annoying LLM tics: em dashes, emojis, affirmations, and stock phrases

• Users list persistent patterns: overuse of em dashes, emojis, bolding, empty affirmations (“That’s a great idea!”), and clichés like “It’s not just X—it’s Y,” “comprehensive,” “enhanced,” etc.
• Many find this helpful for spotting AI text; others lament that normal writing habits (like em dashes) are now stigmatized by association.
• Some customize models (“robot” personalities, explicit “no fluff” instructions) with mixed success; tics often return.
• There’s disagreement on intent: some think it’s a feature tuned for “pleasant,” emotionally supportive chat (e.g. coping with loss), possibly to increase engagement; others see it as wasting tokens and eroding trust.

Technical limitations and philosophical critique

• Several note the method appears heavily n‑gram/regex-based; they argue real mode collapse is semantic and stylistic at paragraph or idea level, not just repeated surface strings.
• Critics call this “patching symptoms”: removing shibboleths without increasing true diversity or creativity, potentially “gaslighting” users by hiding problems and making detection harder.
• Others respond that high-level semantic collapse is hard to quantify; inference-time suppression of measurable tics is still worthwhile, even if it doesn’t fix deeper issues.
• Alternative ideas raised: incorporate slop penalties into the training loss; use temperature or other sampling strategies; create benchmarks/leaderboards for “slop” across models.

Social and downstream effects

• Some can’t distinguish AI style from existing formulaic corporate/marketing prose, suggesting training data and business use-cases reinforce this convergence.
• There’s worry about a future where distinguishing human from AI text is practically or financially infeasible, with implications for education (take-home essays/coding tasks) and the value of “live” human performance.

Workarounds and humor

• Anecdotes include yelling in prompts, asking the model to “sleep,” or forcing quirky greetings to break patterns.
• Others propose tongue-in-cheek universal “anti-slop” filters (e.g., sed -e d) and joke names like “compu-slop.”

Nature of CZ’s Offense and Case

• Several commenters stress that Zhao was not convicted of fraud or direct money laundering, but of violating the Bank Secrecy Act by failing to implement effective KYC/AML controls for Binance’s U.S. business.
• Defenders call it a “technical compliance” case, note the 4‑month sentence and lack of proven specific laundering transactions in court, and argue big banks usually pay fines, not see CEOs jailed.
• Critics respond that AML rules are not a technicality: Binance allegedly ignored internal compliance warnings and profited from criminal flows; failure to prevent laundering is itself the crime.

Perceived Quid Pro Quo and Open Corruption

• Central reaction: the pardon is seen as transactional. Zhao and Binance are tied in the article and other coverage to the Trump family’s crypto venture and a large increase in Trump’s wealth.
• Many frame this as outright bribery or “selling pardons,” lumped with other high-profile clemency actions for political allies and donors.
• Some argue this normalizes U.S. corruption to “banana republic” levels and signals that rich offenders can buy impunity.

Crypto, Laundering, and Double Standards

• A large faction treats crypto as structurally intertwined with fraud, sanctions evasion, and ransomware, and sees the pardon as further delegitimizing the space.
• Others argue the U.S. selectively enforces AML laws against crypto while traditional banks with similar or worse violations escape with fines, calling out apparent double standards.
• A minority cast the prosecution itself as part of a “war on crypto” and even as ethnic or political persecution; this is strongly contested in replies.

Pardon Power and Rule-of-Law Concerns

• Many say this illustrates dangerous presidential pardon powers: effectively unchecked, used for cronies, and now arguably as part of pay‑for‑play.
• Proposals include abolishing or radically constraining federal pardons, shifting them to Congress or adding judicial review; others warn that pardons are sometimes needed to correct injustices.
• The pardon is discussed alongside recent Supreme Court rulings on presidential immunity, creating a sense that legal accountability for the executive is collapsing and impeachment is the only (weak) check.

Comparisons, Whataboutism, and Systemic Cynicism

• Thread repeatedly compares this to non-prosecution of 2008 bankers, Clinton’s Marc Rich pardon, and Biden’s sweeping family and low-level drug pardons.
• Some use these to argue “both sides are corrupt”; others label this whataboutism that obscures the scale and brazenness of current behavior.
• Broader anxiety emerges about the U.S. drifting toward authoritarianism, structural flaws (Electoral College, Senate, gerrymandering, Citizens United), and a public numbed or misinformed by partisan media and social networks.

Impact on Interest Rates and the Real Economy

• Several comments link rising federal debt to higher Treasury yields, which become the floor for consumer credit (mortgages, auto loans, credit cards).
• Higher rates are seen as likely to slow the economy via more expensive borrowing, though some argue the impact is muted because a large share of spending comes from the top 10%, who are less credit-constrained.
• Others note the Fed’s policy rate is the more direct driver of consumer rates, but Treasury yields set the long-term “rate floor” and define spreads for packaged consumer debt.

Who Owns the Debt and What a Default Means

• Debt is largely held via Treasuries by: the Federal Reserve, other federal entities (e.g., Social Security trust fund), mutual and pension funds, insurance companies, banks, foreign governments, and some crypto stablecoins.
• Multiple commenters stress that one party’s debt is another’s asset; writing it off would vaporize pensions, bank capital, and corporate balance sheets.
• A true default is described as an “extinction-level” financial event, far beyond typical crises, given Treasuries’ central role as global collateral.

Does the Debt Level Itself Matter?

• Some argue sovereign issuers can’t “run out of money” and that expectations about inflation and currency value matter more than the absolute debt stock.
• Others emphasize that rapid changes in borrowing and the growing share of revenue going to interest (headed toward ~20%) are dangerous constraints on future policy.
• Several note that exponential-looking debt growth is structurally tied to percentage returns and population/price growth, but still unsustainable if deficits outpace GDP.

Entitlements, Safety Net, and Moral Tradeoffs

• Big drivers of spending: Social Security, Medicare/Medicaid, and interest; SNAP is repeatedly described as small (~0.2% of total debt equivalent) and likely net-positive for health and the economy.
• There is sharp disagreement over cutting benefits (especially SNAP) versus raising taxes on high earners and corporations.
• Many frame cutting food, healthcare, or retirement benefits as morally unacceptable, especially given record corporate profits and extreme wealth concentration.

Tax Policy, Partisanship, and Structure of the Budget

• Commenters note that “discretionary” items Congress fights over are a small slice; most spending is mandatory by prior law.
• There’s debate over which party is more fiscally responsible: some blame tax cuts for the rich; others say both parties overspend and rely on cheap borrowing.
• Proposals include restoring pre-recent tax cuts, beefing up IRS enforcement, deep healthcare-cost reforms, and even constitutional “debt brakes” modeled on Switzerland.

US human rights posture and hypocrisy

• Many argue the US has long used “human rights” selectively—against enemies while shielding allies (Israel, Saudi Arabia, etc.).
• The portal is seen as part of a thin pretense of concern; Biden under-used it, Trump removed it, reinforcing views that both parties enable the same underlying foreign policy, with different rhetoric.
• Some say ending the pretense is clarifying: it makes it harder, especially for foreign liberals, to grant the US moral impunity.

Effectiveness and purpose of the portal

• Several doubt the portal ever produced real accountability, likening it to a corporate “suggestion box” feeding a shredder.
• Others say even symbolic mechanisms matter, because they:
  • Create paper trails discoverable via FOIA.
  • Provide diplomatic leverage over abusive client states.
  • Signal at least nominal shame or standards.
• Taking it down is seen as either ideological “vice signaling,” incompetence, or an intentional statement that abuses no longer need to be hidden.

Law, Leahy requirements, and executive overreach

• Leahy Law requires the government to “facilitate receipt” of abuse reports; some argue email and NGO channels technically satisfy this, so a website is not legally required.
• Critics counter that dismantling the one public, discoverable channel is clearly contrary to the spirit of the law and makes oversight harder.
• Long debate over whether this illustrates that:
  • Laws no longer constrain the executive in practice, due to a servile Congress and partisan courts; or
  • This is simply democracy: elected branches choose not to enforce constraints.

Trump, MAGA, and authoritarian drift

• Many tie the move to a broader pattern: pardoning war criminals, praising “toughness,” threatening media, ignoring statutory limits (tariffs, IG rules), and undermining elections.
• Defenders claim he is pursuing a coherent foreign-policy realignment and that institutions still check him; others say checks now fail by design because co-partisans in Congress and the judiciary refuse to act.
• Several commenters argue his supporters knowingly accept lawlessness in exchange for cultural victory or perceived protection from social change, not just out of economic grievance.

Military culture and normalization of abuses

• Commenters connect the portal’s removal with recent rhetoric from Defense/War leadership: downgrading “toxic leadership” complaints, restricting IG processes, and valorizing “risk-taking” even with “mistakes.”
• Critics see this as dismantling internal accountability and normalizing collateral damage and abuses as acceptable costs of a permanent “wartime footing.”

Press, whistleblowers, and alternatives

• Some conclude that direct leaks to journalists, NGOs, or outlets like Wikileaks are now more important than ever, since government self-reporting channels are untrustworthy or disappearing.
• Others warn that legal and rhetorical attacks on the press suggest those external channels may also be targeted.

Limits of “drill‑down on past project” interviews

• Assumes the interviewer is senior and technically sharp enough to pick good topics, ask probing questions, and spot BS; many aren’t.
• Strongly biased by interviewer’s own experience: they may reject simple, appropriate designs in favor of their preferred “proper” stack.
• Can disadvantage candidates with classified or tightly NDA’d work (government, big secretive companies) who literally cannot discuss details.
• Also hard on people with many years of experience or poor autobiographical memory; they may recall themes but not implementation detail.
• Some worry candidates can just parrot team design docs, and that the method selects for memory and storytelling more than autonomous design ability.

System design discussions and tradeoffs

• Many argue the key signal is how candidates reason about tradeoffs, constraints, and “it depends,” not whether they build a buzzwordy distributed system.
• Good interviews are described as back‑and‑forth, co‑worker‑style conversations where requirements are clarified and approaches are compared.
• Others find targeted system design problems on the company’s own architecture give clearer signal about real abilities, but admit this favors those with similar prior experience.

LeetCode, coding tests, and LLMs

• LeetCode‑style questions are seen as scalable and standardized but often poor at predicting real‑world performance; some view them as hazing or wage‑suppression tools.
• Distinction is drawn between trivial “can you code at all” questions (e.g., FizzBuzz) and hard puzzle/DP questions that mostly reward grinding.
• Remote coding interviews increasingly suffer from LLM cheating, making open‑ended discussion and pair programming relatively more trustworthy.
• Some companies respond with niche, low‑level trivia quizzes that are hard to Google or ask an LLM, but concede this only fits certain domains (e.g., bare‑metal embedded).

Recruiters, process design, and evidence

• Debate over non‑technical HR screens: they can filter volume but often mis‑screen strong engineers and create bad candidate experiences.
• Several comments emphasize that any technique fails in the hands of unskilled interviewers; there’s little feedback or training to improve them.
• One thread calls out the near‑total absence of empirical, research‑backed interview design in tech; most processes are anecdotal and rarely validated against outcomes.

Personal projects, NDAs, and ethics

• Strong disagreement over expecting side projects: some claim “real” programmers always have them; many others call this unrealistic and biased against people with families or demanding jobs.
• Concerns raised about asking for deep details of proprietary systems—potentially encouraging NDA or trade‑secret violations.
• Open‑source or personal work can work well for drill‑downs, but not everyone has presentable code they can legally or comfortably share.

Beyond competence: productivity and fit

• Multiple comments note that distinguishing “good programmer” from “productive in this environment” is much harder and largely unsolved.
• Red flags sought include inflexibility, ego, inability to handle requirements they don’t like, and poor collaboration in code review or pair settings.
• Some advocate paid trials or probation periods and fast firing as the only reliable way to catch false positives, though legal and social constraints limit this.

Perceptions of ASN.1

• Many commenters recount ASN.1 as painful, especially via X.509/PKI and telecom stacks; others strongly defend it as elegant and powerful.
• Criticisms: over‑engineered, huge spec surface, many edge cases, and decades of buggy implementations (notably mixed BER/DER).
• Defenses: a well‑designed, generic type system with formalism, extensibility, and multiple encodings; problems blamed more on PKI, X.400/X.500 naming, and bad tooling than on ASN.1 itself.

Technical Pros/Cons and DER vs BER

• DER’s canonical TLV encoding is seen as a key win for signatures and certificates; several say that if you stick to DER and a limited subset of ASN.1, life is manageable.
• BER and non‑canonical encodings are widely blamed for complexity and interoperability bugs.
• Some insist DER can be parsed generically without schema; others note IMPLICIT tagging and OCTET‑STRING‑wrapped subvalues make semantics opaque without specifications.
• The zoo of string and time types (many legacy encodings) is seen as crusty but mostly ignorable in modern profiles (e.g., “just use UTF8String/GeneralizedTime”).
• PER/OER and non‑TLV encodings are praised as more compact but harder to use without shared schema.

Alternatives and “What If Designed Today?”

• Comparisons with Protobuf, Thrift, JSON, CBOR, JWT/JOSE:
  • Some call Protobuf “ASN.1 with better tooling,” others say they’re fundamentally different.
  • CBOR/COSE is viewed as a modern, self‑describing binary alternative with canonical forms; a candidate for future security protocols.
  • If TLS/PKI were designed today, several expect JSON/CBOR‑based formats (JWT/CWT‑like), others think Protobuf would be chosen.
• Debate over canonical encodings: some argue they’re unnecessary if you always verify over the original bytes.

Implementation Experiences

• Multiple people built or extended ASN.1 compilers (in D, C, Java, Swift, Rust) and describe it as “hurts, but in a good way.”
• Real‑world uses: Web PKI, SNMP MIBs, eIDAS/PAdES, passports, aircraft/ATN messaging; embedded contexts sometimes hand‑roll small decoders and cope with non‑compliant encodings.
• ASN.1 is praised for enabling strict schemas, typed “holes,” and compact encodings; also blamed for unforgiving edge cases where the last 20% takes most of the effort.

Discussion of D Language

• Many like D’s design: native binaries, C/C++ interop, fast compilation, UFCS, built‑in unit tests, contracts, and ImportC.
• Concerns: missed adoption window, weaker ecosystem and tooling versus Go/Rust, historical stigma of proprietary compilers (though now open), and a standard library (Phobos) full of “paper cuts.”
• Lengthy argument over the optional GC:
  • One side: optional GC fractures the ecosystem and limits library reuse in GC‑free code.
  • Other side: this is no worse than subsets in C++/Rust; GC is just one allocator among many, and D’s strength is mixing GC and manual memory management.
• People suggest D needs a “killer framework” (e.g., web or game engine) and better async/coroutines to regain momentum; work on Phobos v3 and coroutines is mentioned but future impact is uncertain.

Human Drivers vs Robotaxis & Accountability

• Some argue investigations should target pervasive human violations of school-bus rules; others insist most humans do comply and are directly punishable, unlike AVs.
• Commenters note traffic enforcement has fallen since COVID and is often sporadic or revenue-driven, which weakens deterrence for humans.
• For AVs, accountability routes through the operator’s license to operate, software updates, and regulatory probes.

Cameras, Surveillance, and Automated Enforcement

• One camp advocates widespread use of HD cameras, bus-mounted systems, and even drones to capture violators, treating tickets like parking fines (owner-liable).
• Others describe US legal quirks that make mailed camera tickets easy to ignore and require “two-way” acknowledgment.
• A strong civil-liberties thread opposes “constant surveillance,” preferring higher personal risk; supporters reply that pervasive cameras and ALPRs already exist and should be used for safety.

“Fix Once, Deploy Everywhere” vs Software Reality

• Pro-AV voices say a key advantage is that once a behavioral bug (like mishandling a school bus) is found, a software fix can be rolled out fleetwide and regression-tested—unlike human drivers whose knowledge rarely updates.
• Skeptics highlight the complexity: object classification, edge cases (stop arm timing, emergency vehicles, fog, state-by-state laws), hardware limits, and interactions with other behaviors.
• Several compare this to aviation: safety is improved iteratively through post-incident investigation, but “code written in blood” is still a concern.

Corporate Incentives, Fines, and Regulation

• Debate over whether fines should start small and escalate vs being large from the outset.
• Some fear large operators will treat penalties as a business cost and eventually lobby to cap liability; others think PR risk around harming children is a powerful counterweight.
• Multiple comments call for NTSB/FAA-style, strong federal oversight; others insist states can regulate roads adequately.

School Buses, School Zones, and Legal Complexity

• Non-US readers question why all traffic must stop for school buses; replies cite high-speed rural roads without sidewalks, crosswalks, or lights, where kids cross anywhere.
• There’s confusion and variation around:
  • When opposing lanes must stop (depends on lane count/median).
  • School-zone signs tied to “school days,” “when children are present,” or flashing lights.
• Some argue AVs can in principle handle this better by integrating calendars and map data; others say ambiguity is so high that always slowing is the only safe rule, though being too slow can create hazards.

The Specific Waymo Incident

• A video shared in the thread shows a Waymo turning slowly in front of a stopped bus, apparently trying not to block an intersection; no children are visible.
• Opinions split on whether this was dangerously unsafe or technically illegal-but-low-risk; several say a human driver might have done the same.
• Others stress that the law is intentionally strict because children can emerge unpredictably, and that AVs must visibly “over-comply” to avoid signaling to humans that passing is acceptable.

Waymo Safety and Operational Limits

• Supporters claim Waymo has driven over 100M miles with no fatalities and lower crash rates than human drivers and ride-hail drivers, and operates cautiously in multiple cities.
• Critics note the operational domain is still constrained (weather, geography, map quality), that fleets have had mapping and emergency-response failures, and that statistical proof of superiority requires vastly more exposure.
• Some emphasize that human safety could also be improved via better training, driver-assist features, and—crucially—road design (narrower lanes, traffic calming) without AVs.

Broader Concerns and Hopes

• Fears include fleet-wide bugs, hacking that could control many vehicles at once, and AV-specific legal carve-outs.
• Others envision AV-only rulesets, AV school buses that broadcast their status to surrounding vehicles, and eventual large reductions in the ~1.2M global annual road deaths—if deployment is managed carefully.

Methodology & Limitations

• Commenters find the prompt set narrow: few questions per axis, English-only, forced A/B/pass answers, and a single system prompt.
• Suggestions: expand question bank, add multiple phrasings per item, randomize option order, and translate prompts to see how different language “Overton windows” shift answers.
• Small sample size per axis means a model can flip from 0% to 100% in a category just by changing 1–2 answers, so per-axis claims are seen as fragile.

Nature and Sources of Bias

• Many argue bias is unavoidable: models inherit it from human data; selection of training sources (news, publishers, social platforms) skews toward elite or “progressive” online discourse rather than general populations.
• Others stress bias isn’t layered on a neutral engine; it’s baked into the weights through data and RLHF.
• Labels like “progressive” and “conservative” are criticized as narrow (heavily tied to abortion/gender/social-norm questions) and not capturing economic or geopolitical stances; several see most models as “establishment / neoliberal” rather than truly progressive.

Interpretation of Results

• Observed pattern: almost all models lean regulatory and socially progressive, with a few outliers leaning libertarian or conservative on some axes. Some call this polarization; others call it uniformity.
• Specific findings spark debate: pro-UN/NATO/EU stances, pro-Israel answers, disagreement with international law on resistance to occupation.
• Distillation and newer versions sometimes show ideological shifts, raising questions about what alignment steps changed.

Control, Neutrality, and “Truth”

• One thread: are models mostly shaped by data, or are companies intentionally steering politics? Both possibilities are considered.
• Several argue it’s impossible to define a single “neutral” position; “unbiased” might mean mirroring empirical consensus, not 50/50 on every controversy.
• Others propose LLMs should refuse direct answers on hot-button questions, instead outlining competing arguments—but even choosing which “facts” to present is itself contested.

Social & Political Implications

• Concerns that LLM-backed devices could become new chokepoints: effectively banning or monetizing disfavored activities, similar to payment-processor control.
• Fear that ideologues will game training data and alignment to capture “perceived truth,” using LLMs as a new propaganda vector.
• Counterview: LLMs are tools; healthy users should treat them as maps of discourse, not oracles.

Proposed Responses

• Add explicit political-bias sections to model cards; place models on ideological compasses, including compliance rates.
• Provide transparency about training and alignment and allow user choice among differently biased models, analogous to picking newspapers or feed algorithms.
• Accept that the real task is not “removing” bias but choosing which bias is appropriate for a given application.

Algorithmic Pricing, Stability, and Game Theory

• Several commenters connect the article’s results to earlier work on learning agents in artificial markets, noting prior findings of instability (bubbles, crashes) versus these “stable but high-price” equilibria.
• There is curiosity about extension from 2-player to N-player games: some expect more competitors to make collusion-like dynamics harder; others think more players could actually make stable algorithmic pricing easier, especially with humans supervising the systems.
• The “nudge high” gas-station thought experiment is seen as intuitive: algorithms periodically test high prices to converge on mutually profitable high-high equilibria.

Real-World Dynamic Pricing and Discrimination

• Many observe that dynamic/algorithmic pricing is already pervasive: Amazon price cycling, Walmart’s store-by-store prices, online vs in-store price differences, and A/B testing to find what “the local market will bear.”
• Commenters discuss the historical move from haggling to fixed prices (including religious and behavioral-economics motives) and predict a broad return to individualized price discrimination as automation lowers labor costs.

Regulation, Enforcement, and Policy Ideas

• Some argue regulators can and do control inputs and methods (e.g., insurance rate filings) and could restrict use of competitor data or require justification based on allowed datasets.
• Others are skeptical: algorithmic collusion is hard to prove, enforcement often hinges on narrow concepts like “nonpublic data,” and fines may be smaller than profits.
• Proposed solutions include: profit caps (as with utilities), public zero-margin competitors, government entry into high-margin markets, mandatory financial transparency, and stronger antitrust. Critics worry profit caps become de facto targets.

Collusion, “Algorithms,” and Number of Players

• Multiple commenters stress that the core issue is information and incentives, not “algorithms” as such; the same strategies could be executed with pen and paper.
• One view: if firms knowingly adopt a shared pricing algorithm, that choice itself is collusion; others see it more as systemic design failure than intentional conspiracy.
• The number of competitors (n) is repeatedly highlighted: with few players, tacit or explicit collusion is easy; with many, undercutting is more attractive, making sustained high prices harder.

Broader Economic Debates

• Long subthreads debate how well Econ 101 “free market” models apply in reality, especially under modern concentration, advertising, and overcapacity.
• Housing and rent algorithms (e.g., RealPage/Greystar–type scenarios) are cited as concrete, harmful examples of algorithmic price coordination driving up essential costs.

Blog readability and presentation

• Several readers report the article text rendering as gray and/or bold, calling it low-contrast or “unreadable” on some Safari/iOS setups.
• Others say it looks normal, suggesting a variable-font or CSS override issue; one points to a .text-gray-600 rule possibly not being overridden when JS/CSS fail.
• Suggestions include using browser reader/article mode. Some expect a “public cloud” vendor blog to be readable without such workarounds.
• There’s also a small meta-thread about dates: people want the publication date clearly at the top, not only as a “last updated” line at the bottom.
• Writing style divides readers: some love the vivid metaphors and vocabulary; others find it needlessly ornate.

Global state, routing, and consensus

• A recurring theme is that “instant” global database-style consensus for routing state is not workable at Fly’s scale.
• Commenters explore alternative patterns: Envoy xDS with etcd + watches, cluster-level health checking, gossip-based systems, and DNS/DNS++-style discovery.
• There’s debate over whether DNS is fundamentally inadequate or actually a robust, cheap service-discovery layer with failures mainly in the control plane and reconciliation logic.
• One key distinction: noticing an instance is down is easy; reliably notifying every proxy worldwide, within tight latency bounds, is not.
• Suggestions to reduce blast radius via sharding, cells, or shuffle sharding conflict with Fly’s stated premise: any edge proxy must be able to route to any customer app globally.

Corrosion, SWIM/gossip, and regionalization

• Corrosion is described as a SWIM-like gossip layer plus cr-sqlite CRDT replication to maintain a distributed routing “working set.”
• The current direction is regionalization: per-region Corrosion clusters with fine-grained machine state, and a lean global cluster that only maps apps to regions, mainly to limit blast radius of bugs.
• Some discuss how far SWIM/gossip can scale: estimates range up to millions or more members, with practical limits driven more by change frequency and blast radius than raw node count.

SQLite, CRDTs, and correctness concerns

• Readers are intrigued to see cr-sqlite used in production but probe its behavior: nullable column “backfill” is really clock metadata, not data writes, and is noted as an optimization opportunity.
• A critical thread argues that cr-sqlite’s use of column versions isn’t a proper logical (Lamport) clock and that its conflict-resolution semantics are suspect.
• Others dislike doing CRDTs inside SQL with a last-writer-wins bias, calling it overkill versus simpler Postgres patterns for this specific routing-state problem.
• There’s also a side question whether Corrosion/cr-sqlite could act as a multi-writer alternative to tools like litestream (no clear answer in-thread).

Rust bug and language evolution

• One outage involved an if let expression holding an RwLock guard longer than intended, causing a contagious deadlock when the else-branch assumed the lock had been released.
• Commenters note that the Rust 2024 edition changes temporary lifetimes for if let, which would have prevented this specific pattern; there’s some back-and-forth on when that edition became available relative to the incident.

Product maturity, trust, and expectations

• Some commenters argue that repeated issues around service discovery, certificate expiry, and distributed state suggest a “move fast and learn in production” mindset that’s risky for a public cloud.
• They contend such a provider should enter the market only after having a robust, validated design for global routing and automation of basics like cert renewal.
• Fly’s responses emphasize that global any-to-any routing is the core premise of the platform, not a bolt-on differentiator; the complexity and nonstandard solutions follow from that premise.

Other tools and side discussions

• rqlite is raised as a possible way to achieve a fault-tolerant SQLite-based system; its creator chimes in with a couple of production references.
• Some criticize the perceived “obsession” with SQLite/CRDT, suggesting a traditional Postgres deployment and even specialized networking hardware (FPGAs), though concrete benefits for this problem are not clearly articulated.
• There are minor threads about name collisions with another project named “Corrosion” and general curiosity about how very large gossip systems are run in practice.

Context and ambiguity of Starlink shutdown

• OP notes the article glosses over Myanmar’s civil war: the junta blames opposition-linked groups for scam centers, while those groups deny it.
• Some argue disabling 2,500 terminals inevitably benefits one side militarily/politically, but who benefits is unclear.
• Others counter that, regardless of factions, large-scale, well-documented scam compounds are a clear enough target.

Nature and severity of the scam centers

• Multiple commenters stress these are not “normal” call centers: reports describe kidnapping, trafficking, imprisonment, torture, and forced scamming (“modern slavery”).
• Compounds like KK Park and Shwe Kokko are said to be run largely by Chinese/Taiwanese crime groups, with trafficked workers from many countries.
• View: this is “black and white”—any action reducing their capability is good, even if both junta and militias are otherwise abusive.

Sovereignty, law, and corporate duty

• One camp: if you operate in a country (or beam services into it), you should obey its laws; if the government is illegitimate or genocidal, don’t do business there at all.
• Opposing view: companies are not morally bound to follow laws of genocidal or authoritarian regimes; they should resist being tools of “jackbooted thugs.”
• Others emphasize consistency: if Starlink respects Brazil’s courts or Israel’s rules, it can’t arbitrarily ignore Myanmar without consequences.

Genocide, resistance, and “terrorism” labels

• Debate over whether resistance groups operating scams (if true) are “terrorists,” “freedom fighters,” or just another set of bad actors.
• Some argue you either refuse to support genocidal regimes everywhere or you’re inconsistent; others note international actors already maintain embassies and follow local law while pressuring for change.
• Strong disagreement over when breaking unjust laws is morally necessary versus dangerously ad hoc.

Free communication vs shutting down abuse

• One side: communication access is akin to a human right; denying it (especially in a civil war) is dangerously political and may hurt journalists, civilians, or resistance.
• The other: telecoms routinely cut off terrorism and severe crime; there are worse things than “internet censorship,” like torture and organ harvesting.

US power, Musk, and geopolitical influence

• Some see Starlink as a tool of US soft power/DoD influence, pointing to military contracts and earlier Ukraine involvement.
• Others call this “tinfoil hat” thinking, arguing Starlink exists mainly as a commercial service, though they concede government pressure and sanctions clearly matter.

Technical and operational details

• Starlink is officially not licensed in Myanmar or Thailand; terminals are smuggled in and geo-located via GPS.
• SpaceX claims to have proactively disabled far more terminals (2,500) than were physically seized (~80), likely based on location clustering around scam compounds.
• Concerns: how does Starlink distinguish scam terminals from, say, nearby journalists or bystanders; collateral disconnections seem likely.

Meta: evaluation of HN’s reaction

• Some commenters are frustrated that discussion fixates on sovereignty, Musk, or abstract legalities instead of the extreme human-rights abuses at the compounds.
• Others criticize knee-jerk anti-Musk comments, or note that the same crowd recently attacked Starlink for not complying with national laws elsewhere, highlighting inconsistency and polarization in tech discourse.

Project and implementation

• Rouille is a proc-macro that lets you write Rust using French keywords and identifiers via a simple word→word dictionary.
• It’s explicitly not meant for serious use; the mapping is intentionally naïve and inefficient, and the French is “lenient” and humorous (e.g. compiler jokes, slang).
• There’s a name clash with an existing minimal synchronous Rust HTTP framework already called “rouille”.

Other localized variants and related projects

• The repo links to many other “Rust in X language” forks (German, Russian, Spanish, Greek, Slovak, etc.); people also mention Esperanto, Latin, and a German project “Rost”.
• Several say their versions were hand-written as jokes, not AI-generated, though some suspect newer ones might be.
• Other examples of localized or joke languages: Baguette# and Chamelle (French OCaml variants), Latin “ferrugo”, French LSE (BASIC-like), localized VBA, AppleScript French/Japanese dialects, non-English PLs (Russian, Chinese, Hindi).

Quality, tone, and translation choices

• The French dictionary is widely found hilarious, especially vulgar or playful mappings:
  • WTFPL → “license rien à branler”.
  • “merde” / “calisse” / “oups” → panic.
  • “super” for super, playing on a French homograph rather than the intended meaning.
• Some French speakers dislike or debate particular choices (e.g. translating Option as “PeutÊtre” instead of using “Option”, second-person imperatives, word order like “asynchrone fonction”).
• Reactions to other language variants are mixed:
  • Russian variant seen by some as funny, by others as lazy “gopnik” stereotyping.
  • Spanish “rústico” is criticized because the README wrongly claims it means “Rust”.
  • Greek is seen as too bland; Slovak version is criticized for omitting diacritics.

Experiences coding in one’s native language

• Many French speakers report strong discomfort reading code in French; it feels like bad pseudocode or someone “yelling orders”, whereas English feels neutral/technical.
• Several non-English speakers recount starting with localized variable names (Portuguese, French, Swedish, etc.) in early learning, then switching to English for collaboration, searchability, and consistent terminology.
• Others note that for native English speakers, code doesn’t really feel like English anyway; keywords have specialized meanings, and PLs are their own register.

Localization, tooling, and thought experiments

• People imagine a world where programming languages are fully localized: separate compilers per language or a single AST-based representation with localized views in the editor.
• Practical concerns arise: canonical on-disk format, whether identifiers are translated, increased complexity, and parallels to localized Excel/Sheets function names that hinder portability.
• Some propose IDE/LSP-level “mnemonics” or doc-comment-based translation layers as a more realistic approach than fully localized core languages.

Trust, Closed Source, and the Article’s Framing

• Several commenters argue Obsidian is relatively trustworthy for proprietary software: non‑VC funded, clear “your data is yours” stance, local Markdown files, generous licensing.
• Others say the article is really about security, not “evil devs”: good intentions don’t prevent vulnerabilities.
• Some think the title unfairly singles out Obsidian or is borderline clickbait given the nuanced content.

Open Source vs. “Source Visible”

• Electron devtools showing minified JS is not considered open source; license and modifiability are what matter.
• Open source is framed as reducing vulnerabilities over time and giving users an escape hatch if the vendor changes.
• Counterpoint: even open source often lacks verified, reproducible builds, so users still mostly “trust” binaries.

Security Model and Plugin Risks

• Main concrete risk: powerful, unsandboxed community plugins that can read/write files, make network calls, run servers.
• Plugins are reviewed only once and not re‑audited on updates; plugin ecosystem is growing quickly.
• The Electron + npm supply chain is seen as another attack surface (malicious packages, auto‑updates).
• Multiple people suggest plugin sandboxing and more granular permissions as the real fix.

macOS Sandboxing, Signing, and Distribution

• Obsidian not being in the Mac App Store means no mandatory sandboxing; some see that as a serious risk for sensitive notes.
• Code signing/notarization only proves origin, not absence of backdoors; it helps with revocation, not with trust in behavior.
• macOS is noted to have app‑level and folder permissions, but no simple way to sandbox a non‑Store app by default.

Alternatives and Data Portability

• Several open‑source alternatives are mentioned: Joplin, Logseq, Trilium, SiYuan, and others, each with trade‑offs (UI, formats, complexity).
• Some argue that Obsidian’s Markdown is still somewhat non‑standard due to plugin conventions.
• A few users strongly advise avoiding any closed‑source note‑taking tool despite portable files, citing long‑term risk and habits lock‑in.

Ethics and Economics of Closed Source

• One camp says closed source is inherently unethical; another calls that absolutist and emphasizes sustainable funding and livelihoods.
• There is debate over whether “only open source is trustworthy” is realistic or counterproductive.
• Some suggest Obsidian could open‑source the client while monetizing sync/back‑end, citing other projects that do this.

Mitigations and Practical Advice

• Suggested mitigations: minimize plugins, use only core features, sandbox via Firejail/AppImage or Flatpak on Linux, or rely on larger vendors like Apple Notes.
• Others note Obsidian does annual third‑party security audits of the core, but plugins remain an open risk area.

Licensing Change and Immediate Impact

• VST3 moving from GPLv3/commercial to MIT removes major barriers for GPL2, MIT/BSD and distro-packaged software, especially on Linux.
• Previously, VST2 required signing a restrictive proprietary agreement (often including giving up VST2 rights when adopting VST3), and VST3’s GPLv3-only option blocked many projects.
• Several commenters expect more open‑source plugin hosts and plugins to ship VST3 builds now, and note this could legitimize previously “legally gray” open-source VST work.
• Steinberg also opened the ASIO SDK under GPL3; some are puzzled it’s not GPL2‑compatible like the Linux kernel.

CLAP, Competition, and Motivations

• Many see the move as a competitive response to CLAP, an open C‑API plugin standard with simpler design, polyphonic modulation, and broad Linux support.
• Some argue “CLAP is way better” and say the world should move off VST3; others point out downsides (multiple MIDI representations, no manifest, unspecified parameter interpolation).
• CLAP adoption is described as small but growing, helped by frameworks (e.g., JUCE) and several high‑profile and open‑source plugins.

Technical Design: VST3 vs Alternatives

• VST3 is criticized as COM‑inspired, interface‑heavy, and sprawling, with tricky state machines, threading rules, and ABI assumptions about C++ vtables.
• MIDI handling in VST3 (treating CCs as parameters, no native MIDI stream) is widely called a design mistake; workarounds require thousands of dummy parameters and lead to poor MIDI behavior.
• Sample‑accurate automation via parameter queues and linear interpolation is viewed by some as elegant, by others as slow, complex, and rarely implemented correctly.
• AU is described by one participant as more open‑ended/graph‑oriented, but others counter that in practice all major formats reduce to similar “process()” models; host limitations matter more than spec.

Ecosystem, Adoption, and Tooling

• VST remains the universal lowest common denominator; CLAP is far from AU‑level adoption and has no CLAP‑only DAW pushing it.
• Hosts and frameworks (notably JUCE) are key: once they support CLAP or new VST3 features, plugin support tends to follow.
• Some hope this change, plus open standards like CLAP and LV2, will finally reduce format fragmentation and overcommercialization, especially for Linux users.

Community Sentiment and History

• Reaction is strongly positive (“huge and wonderful change”), but tempered by anger over past VST2 SDK takedowns and license pressure.
• Several call it “too little, too late” unless VST2 is also relicensed freely.
• Yamaha/Steinberg are generally praised for long‑term support and occasional “doing the right thing,” though mistrust remains.