Hacker News, Distilled

Qwen team shake-up and project direction

• Multiple commenters report that key Qwen researchers have left after internal tensions with the parent company, possibly over KPIs (e.g., DAU for the Qwen app) and product vs. research priorities.
• Some speculate about demotion, power struggles, or a shift toward closed, proprietary models, but specific causes remain unclear.
• Many see this as a major loss for the open/local LLM ecosystem, given Qwen’s recent progress.

Model capabilities and comparisons

• Qwen3.5 models, especially 35B-A3B and 27B, are widely praised as state-of-the-art among local/open weights, with strong coding, planning, and tool use for their size.
• Experiences vary: some find Qwen3.5-35B-A3B better than Qwen3-Coder-Next, others the reverse, often attributing differences to model size, quantization quality, chat template, and serving stack.
• Compared to frontier cloud models (Claude, Gemini, etc.), Qwen is still seen as roughly “a year behind,” but impressively close for self-hosted use.

Agentic coding, harnesses, and behavior

• Harness / orchestrator quality (e.g., Zed’s agentic features, Pi-style minimal setups, Qwen’s own harness, Antigravity, OpenCode) strongly affects outcomes.
• Tools often go unused unless the system prompt clearly defines them; explicit tool descriptions and formats significantly improve behavior.
• Users report both tenacious problem-solving and frustrating looping, shortcutting, or ignoring instructions mid-task. Lower temperature helps but temperature=0 can be counterproductive.

Performance, hardware, and quantization

• People share practical setups: consumer GPUs (3070 Ti, 5080, AMD AI Max), Macs, large-RAM CPUs, and various 4–6 bit quants via llama.cpp / vLLM.
• Token speeds in the ~20–70 tok/s range are common; context length and quant choice heavily impact tool-calling reliability and looping.
• Small Qwen3.5 models (0.8–9B) are noted as surprisingly capable for OCR and vision, but weaker for complex coding and coherent prose.

Geopolitics, talent, and economics

• Long subthreads debate why top Chinese researchers might stay in or return to China vs. joining US or EU labs, citing nationalism, quality of life, immigration enforcement, and government expectations.
• Some view Chinese open releases (Qwen, GLM, Kimi) as strategically subsidized to pressure US proprietary vendors.
• Business sustainability is questioned: training is costly, while models are released for free; suggested motives include VC funding, hosted inference revenue, and national strategic goals.

Vendor conflicts and “distillation”

• Discussion of Anthropic’s complaints centers on use of Claude as “LLM-as-a-judge” and for generating training data.
• Commenters argue this is more like RL with model-based feedback than true weight-level distillation, and note that similar cross-model training behavior is widespread.

Scope of the Problem

• Many agree that for-profit scientific publishing is exploitative and misaligned with public funding, but see it as a symptom of deeper issues: prestige incentives, publish-or-perish culture, and underfunded universities.
• Journals are framed less as knowledge-dissemination tools and more as career-advancement and credentialing infrastructure.

Government OA Mandates & Proposed Ban

• Strong support for the idea: “If taxpayers fund it, results shouldn’t be paywalled”; some see a grant condition banning for-profit journals as a clear, straightforward lever.
• Others argue this is politically and institutionally hard: entrenched interests, legal changes, and money flows make it nontrivial, even if conceptually simple.
• Several commenters note that US agencies (NSF/NIH and similar) already require open access via repositories like PubMed Central, but there’s debate over how much this actually weakens publishers’ business models or OA fees (“article processing charges”) replacing subscriptions.

Collective Action & Incentive Traps

• Suggestions to have top departments collectively boycott predatory or luxury journals meet pushback:
  • Senior academics often built their careers on those journals and tie their own prestige to them.
  • Junior researchers, postdocs, and grad students depend on high-impact venues for jobs and tenure; unilateral boycotts could punish them.
  • Coordination across many institutions and countries is seen as very hard.

Peer Review and Journal Prestige

• Broad agreement that “peer reviewed” ≠ “true”; peer review is limited, variable in quality, and often fails to detect fraud or weak methods.
• Disagreement over how much the public actually trusts “peer review” as a concept, and whether high-prestige journals are better or worse on reliability.
• Some argue journal-based pre-publication review is a weak, noisy gatekeeper that mostly adds delay and cost; others emphasize its value as a basic filter in an overwhelming literature.

Alternatives & Partial Successes

• arXiv and similar preprint servers are widely used in some fields (especially CS), but:
  • Not seen as “credible” by many committees and funders because anyone can upload.
  • Suffer from slush-pile problems and increasing low-quality or LLM-generated submissions.
• Proposed models:
  • Overlay journals on top of arXiv (e.g., Open Journal of Astrophysics); curated lists rather than exclusive publishing.
  • Open-access society or non-profit publishers (ACM, Dagstuhl, eLife-style assessment overlays).
  • Community-driven recommendation/curation signals layered over open repositories.
• Conferences in CS are cited as an example where most work is effectively open, but travel, visas, and review quality are significant issues.

Systemic Critiques

• Several commenters argue the real core problems are:
  • Prestige-based evaluation and funding, which journals serve.
  • Structural incentives for quantity over quality, leading to fraud and reproducibility crises.
  • Capitalist profit-seeking that will reappear elsewhere in the pipeline even if journals are reformed.
• Some advocate radical overhaul (“burn it down”), others favor incremental reform via OA mandates and new publishing models.

Product & Positioning

• MacBook Neo is widely seen as Apple’s “Chromebook-class” Mac: cheap, colorful, full macOS on an A18 Pro iPhone SoC.
• Many view it as the spiritual successor to plastic MacBooks / netbooks, aimed at students, schools, and light home use.
• Several note it effectively replaces the Walmart M1 Air deal and opens a true budget tier in the Mac lineup.

Pricing & Value

• $599 retail / $499 education is called “insane” for a new Mac; many predict it will sell extremely well.
• Others argue refurb/used M1/M2/M3 Airs (often 8/256 or 16/512) are better value at similar prices.
• Outside the US, VAT and regional pricing reduce the perceived bargain; some see local Windows/Lenovo/HP deals as more competitive.

Performance (A18 Pro vs M-series)

• Shared benchmark references: A18 Pro ≈ M1 in multicore, significantly faster in single-core, similar GPU class, much stronger NPU.
• Consensus: plenty for web, office, media, and “phone-class” workloads; not meant for heavy dev, VMs, or pro media.

8 GB RAM Debate

• Major flashpoint.
  • Pro-8GB: fine for “average users” (browser, office, light photo/video, students, parents); macOS swap and fast SSDs hide pressure; many report years of acceptable use on 8 GB M1/M2.
  • Anti-8GB: “laughable” / “barely usable” in 2026 given bloated browsers, Electron apps, and Tahoe/Apple Intelligence overhead; concern about constant swapping and longevity.
• Some hope Neo’s existence forces Apple and third‑party devs to re‑optimize for 8 GB again.

Hardware Tradeoffs

• Downgrades vs Air/Pro: sRGB, slightly dimmer/smaller display, no MagSafe, only 2 USB‑C (one USB 3 + DP, one USB 2), 8 GB fixed, smaller battery, mechanical (not haptic) trackpad, no backlit keyboard on base, weaker camera/speakers.
• Upsides at price: solid build, headphone jack, good Retina‑class screen, colors, Apple‑level trackpad/keyboard quality expected.

Education & Competing Platforms

• Many see direct targeting of Chromebooks in K‑12, though admins note:
  • Chromebooks are ~half the price, with mature Google management/GSuite integration.
  • Neo may appeal more to well‑funded districts and to college/individual buyers.
• Also framed as a strong alternative to low‑end Windows laptops and Surface Laptop Go; some say Microsoft/PC OEMs look overpriced now.

macOS on A‑Series & iPad Tension

• Running full macOS on an A18 reignites calls for macOS (or dual‑boot) on iPad Pro; some see Neo as implicit admission that iPadOS failed as a general‑purpose OS.
• Others stress Apple’s desire to keep iPad and Mac separate to sell “two for the price of two.”

Software Quality, Tahoe & Longevity

• Mixed reports: some say Tahoe + 8 GB is “mostly fine”; others call Tahoe a regression with higher RAM use and bugs, making 8 GB marginal.
• Worry that 8 GB machines could feel constrained in a few years; others counter that M1 8 GB machines are still usable and Neo will likely see long macOS support.

Repairability & Openness

• Criticism that RAM/SSD remain non‑upgradeable and Apple’s “environmental” claims ignore repairability; contrast drawn with new highly repairable ThinkPads.
• Unclear if bootloader will allow Linux/Asahi; A‑series history suggests it may be tightly locked, which some find disappointing.

Design, Colors & Branding

• Strong positive reaction to bright colors and “no notch”; some dislike the hyper‑saturated marketing page.
• Name “Neo” is seen as odd by some, but understood as signaling a new base Mac line and youth focus.

Security, Trust, and Permissions

• Many are uneasy installing AI-generated desktop apps with broad system access, unlike web apps in a browser sandbox.
• Glaze will reportedly have a permission model (per-file/directory, network domains, etc.), but several argue this doesn’t remove the core risk of arbitrary code execution.
• Concerns include: no clear security story on the landing page, potential for “trust-me” curl2bash-like behavior, and non-technical users running opaque binaries with sensitive permissions.
• Some expect this to be a “security nightmare” and question how an in-app store of unsigned apps fits with OS security policies.

Tech Stack and “Native vs Electron” Debate

• Speculation that Glaze apps are likely Electron or a webview wrapper; others wonder about Tauri, Wails, SwiftUI, or a Raycast-style runtime that maps React components to native widgets.
• Several wish strongly for truly native apps (SwiftUI, WinUI, GTK) and see more JavaScript-based desktops as “slop.”
• The actual implementation stack is not clearly disclosed; multiple commenters explicitly call this “unclear.”

Relationship to Claude Code and Other AI Builders

• Many see Glaze as “Claude Code with extra tooling”: packaging, signing, distribution, and opinionated design prompts.
• Some argue anyone comfortable with Claude can already build better, fully-owned native apps without vendor lock-in.
• Others counter that Glaze targets less-technical users and teams who value easy publishing, sharing, and sensible UI defaults over raw flexibility.

Use Cases and Value Proposition

• Enthusiasts mention “vibe-coding” personal utilities: menu bar tools, system monitors, text utilities, and niche business workflows.
• A key selling point is integrated distribution: a built-in store for private/public sharing across teams, avoiding App Store friction.
• Examples mentioned as built with Glaze include internal support tools, a MIDI-capable synthesizer, and a replacement for an existing team SaaS.

Product Direction and AI Fatigue

• Long-time Raycast users are split: some see this as a natural extension of workflow automation; others fear a distracting pivot driven by VC expectations.
• Skeptics predict many such AI app builders won’t move beyond polished demos, given iteration cost and complexity.
• Several note a broader saturation of “AI app builders” and question whether there are more platforms than real apps.

Design Quality and Agentic UI Capabilities

• Some report that recent AI models now generate surprisingly good, even novel UIs, versus crude results a year ago.
• Others remain doubtful that agents can reliably create complex, dynamic interfaces without heavy human iteration.
• There is interest in tooling that would let agents iteratively “see” and refine UIs, but concrete mechanisms remain unclear.

Impact on Shipping, Oil, and Markets

• Iran appears to be using attacks on shipping and Gulf Cooperation Council (GCC) states to raise the cost of war for third parties and make the region “uninvestable,” including by threatening the Strait of Hormuz.
• Some compare this to the 1980s “Tanker War,” noting that oil markets eventually adapted and overall disruption stayed relatively low; others point out that current disruptions are far more severe (claims of ~90% shipping halted) and Iran now has better weapons.
• Several comments argue that China, India, South Korea and parts of Asia are more exposed on oil than Europe, which already diversified after the Russia–Ukraine war.
• Many expect spikes in oil prices, shipping insurance costs, and knock-on global inflation, with concern about another affordability crisis.

Military Balance and Strategy

• There is debate over US/Israeli capacity: some say reliance on expensive stand‑off weapons is unsustainable and air defenses are finite; others cite B‑52s and jets over Iran as evidence of air superiority and destroyed Iranian launchers.
• Strong disagreement on whether unguided “cheap” bombing will be used: one side says cost and disregard for civilian life make it likely; the other insists precision-guided munitions (e.g., JDAMs) are now standard and cost‑effective.
• Iran is seen as compensating for weak conventional forces with ballistic missiles and cheap drones, aiming for persistent disruption rather than battlefield victory. How degraded Iran’s capabilities really are is unclear.

Civilian Casualties, Legality, and Morality

• Posters clash over who “started” the war and whether initial strikes were “unprovoked,” with references to Iran’s proxy activity vs. US/Israeli actions and prior massacres inside Iran.
• There is sharp disagreement over how much the US and Israel care about civilian deaths; some insist they try to minimize them, others cite rhetoric and incidents (e.g., bombed schools) as evidence they do not.
• Legality under international law and the framing of the war as imperialism or “move fast and break things” foreign policy are recurring critiques.

Regional and Long-Term Dynamics

• Speculation that the conflict could fragment Iran into ethnic rump states (Kurds, Azeris, Baloch, Arabs), though some consider this conjectural and highlight repeated historical betrayals of Kurds.
• Others foresee regime change in Iran as inevitable; skeptics note air power alone has rarely produced stable outcomes and warn of an Iraq/Afghanistan‑style quagmire or proto‑ISIS successors.
• Risk of wider regional war or even “WWIII” is mentioned but viewed by some as overblown, with Russia and especially China expected to avoid direct military involvement while possibly providing limited support.

Ideology, Religion, and Domestic Politics

• Several comments emphasize religious fundamentalism on multiple sides (Iranian theocracy, hardline elements in Israel, US Christian Zionists) and note reports of US troops being given apocalyptic religious framing.
• Others frame the war as driven more by global capital and energy strategy than by religion, arguing that “capital” ultimately cannot be beaten and seeks to incorporate Iran into global markets.
• US domestic politics loom large: some see the war as a distraction from scandals or a bid to boost midterm prospects; others highlight how war spending benefits defense industries and entrenched elites regardless of outcomes.

Media and Analysis Skepticism

• A recommended YouTube “game theory” channel on the conflict draws mixed reactions: some find it insightful; others criticize it as conspiratorial, overconfident, and misusing technical concepts.
• Multiple commenters stress bias in all media ecosystems (Western, Gulf, Chinese, etc.) and advocate cross‑checking sources, with no consensus “trusted” outlet.

Real‑world fine‑tuning use cases

• Document classification and attribute extraction (doc type, year, subject) where small/medium models nearly match larger models but at much lower cost.
• Labeling/categorization and data extraction, especially converting semi‑structured inputs (e.g., receipts, documents) into strict JSON or schemas.
• Company‑specific models: internal knowledge bases, codebases, legal corpora, function-calling over internal APIs, and generalized attribute extraction for commerce.
• Vision + text: flood detection, handwriting recognition, receipt understanding, broader multimodal adaptation.
• Style and domain adaptation: personal “voice” for emails/forum posts, low‑resource languages, and highly idiosyncratic prose.
• Niche or sensitive domains where base models were filtered (e.g., porn content).
• Embedded/on‑device scenarios: tiny quantized models for games, robotics, and offline/air‑gapped systems.

Data, cost, and performance

• Several comments say a “few thousand” good examples can substantially improve small models; one user reports strong results with ~1,000 examples.
• Fine‑tuned small models are claimed to deliver ~10x fewer errors at ~100x lower inference cost than frontier APIs in some enterprise extraction tasks.
• Batch workloads over ~100k items and repeated reruns are highlighted as especially favorable for self‑hosted fine‑tuned models.

Debate: fine‑tuning vs prompting/RAG/tools

• Skeptical view: modern LLMs plus large context, tools, and RAG usually obviate fine‑tuning; especially for changing knowledge bases where RAG avoids retraining.
• Counter‑view:
  • Context is limited and competes with task input.
  • Large models are expensive and slow with big contexts.
  • Fine‑tuned small models give cheaper, faster, more deterministic, and less “distracted” behavior, especially for tightly scoped tasks and structured outputs.
  • Some domains (OOD data, new modalities, continual learning, strong style transfer) still clearly benefit.

Techniques and tooling

• Heavy emphasis on parameter‑efficient methods: LoRA, QLoRA, prefix tuning, GRPO/RL, doc‑to‑LoRA, model routing.
• Some friction with bitsandbytes and newer MoE/linear‑attention architectures; suggestions to train LoRA over GGUF bases.
• Function‑calling finetunes are cited as particularly powerful compared to pure JSON prompting.

Qwen‑specific notes

• Appreciation for the fine‑tuning guide, but concern that it currently focuses on larger MoE models; smaller and new 9B hybrid‑Mamba variants may need special treatment.
• Some worry about recent leadership changes potentially affecting Qwen’s open‑source direction.

Incentives: Simplicity vs. Career Progression

• Many argue orgs reward visible complexity, “big architectures,” and heroic firefighting more than quiet, simple solutions that just work.
• Simplicity that prevents incidents is hard to credit because counterfactuals (“problems that never happened”) can’t be measured.
• Others counter that in healthy orgs, consistently shipping reliable features fast does get noticed and promoted, but such orgs are not the norm.
• Some note explicit “detect issues early” criteria in promo rubrics rarely translate into actual rewards.

Framing Simplicity in Business Terms

• Thread repeatedly emphasizes: don’t sell “simplicity,” sell outcomes: fewer incidents, faster MTTR, lower on-call load, reduced infra costs.
• Suggestions: build small cost models, instrument KPIs/SLOs, and tie refactors or deletions to dollars, downtime, and velocity.
• However, some report even large cost savings lost to more “impressive” but less effective projects.

Organizational Culture and Management Skill

• Good managers/EMs are expected to understand why simple designs are better and to make that visible in reviews and promo packets.
• Many describe “promotion-driven development” and managers who equate complexity with robustness or competence.
• Several say this is worse in big-tech or heavily layered orgs; smaller companies more often value pragmatism and speed.

Interviews, Design Exercises, and “Future-Proofing”

• System-design interviews often implicitly reward overengineering: candidates feel punished for simple “just use Postgres / Google Sheets” answers.
• Others say the real intent is to explore trade‑offs; interviewers should acknowledge the simple answer, then push candidates into hypothetical constraints.
• There’s tension between testing design depth vs. rewarding pragmatic, off‑the‑shelf solutions.

AI Tools and the Cost of Complexity

• Multiple comments: AI drastically lowers the creation cost of complex code and architectures, but not the maintenance or operations cost.
• Concern that AI agents default to “add more layers” and popular stacks, amplifying overengineering unless tightly guided.
• Some see AI as a force-multiplier for good engineers who already value simplicity; others say models still lack the context needed for truly maintainable designs.

Broader Reflections on Simplicity

• Simplicity is described as a hard, “master-level” skill: finding the minimal solution, not just the easiest or smallest diff.
• Several note we are psychologically biased toward additive solutions and “serious-looking” complexity.
• A recurring suggestion: celebrate code and systems deletions, reduced dependencies, and monoliths that are “boring but fast.”

Nature of the BahnBet Site

• Several commenters point out the site is satire: no real money, fictional “caßh,” humorous legal copy, and playful stories (e.g., “Sinderella”).
• Many initially assume it’s a real betting platform; others note you must dig into the About page to see it’s fake.
• Some expect similar real markets will appear on crypto prediction platforms, even if this one is only a joke.

Ethical and Incentive Concerns

• Strong historical analogy to “coffin ships” and pre‑1745 marine insurance: betting on disasters without “insurable interest” creates incentives for sabotage.
• Commenters worry modern prediction markets on train delays, hacks, or outages could similarly pay people to cause harm if the payoff exceeds the cost.
• Others float adjacent ideas (betting on site outages, company hacks) to “divert” DDoS/hacker capacity, but the perverse incentives are noted.

Online Gambling and Societal Impact

• Multiple comments see online gambling as a growing, under‑appreciated social problem, with addiction compared to hard drugs in destructiveness.
• Debate over whether it’s really “under‑reported,” but some argue it’s still under‑prioritized by society despite media coverage and regulatory moves.
• Philosophical subthread: everything in life is a “gamble,” but participants distinguish between positive‑EV life choices and negative‑EV casino‑style betting.

Deutsche Bahn Reliability and Causes

• Many recount severe delays, missed connections, and flights; some say an undisrupted journey is now the exception.
• Some defenders argue DB suffers from decades of underinvestment, complex mesh operations, and political constraints; they stress employees do their best under a bad hand.
• Critics blame mismanagement, pseudo‑privatization, and slot blocking that hinders competition; claim reliability is worsening despite more funding.
• Infrastructure projects (track upgrades, “Generalsanierung”) are described as extremely slow and bureaucratic, with decade‑scale timelines.

Customer Experience, Apps, and Compensation

• Mixed but often positive views of DB’s app and digital tickets: many find it modern and convenient; a few report serious glitches (e.g., “forgotten” tickets, fines).
• EU‑level and DB‑specific compensation rules are discussed: partial refunds at 60/120 minutes delay, ticket flexibility, occasional hotel/alternate transport coverage.
• Some users mention strategies exploiting chronic delays (e.g., cheap fixed‑train tickets that effectively become flexible).

Comparisons and Humor

• Comparisons to France, Italy, Switzerland, Eastern Europe, Japan, China, and Canada illustrate wide variance in price, punctuality, and investment.
• Many praise the site’s copywriting and legal jokes (e.g., forced “residency” in Schleswig‑Holstein, mock court ruling calling DB tickets “gambling”).

Load Balancers, Split-DNS, and Operational Pain

• Load balancers can either support ECH (including “split mode” where only SNI is exposed) or force a downgrade; if they can downgrade, attackers with valid certs potentially can too.
• Consensus: if infrastructure doesn’t support ECH, it shouldn’t advertise it.
• Real-world complaint: ECH on by default (e.g. via some CDNs) plus split-DNS “intranets” causes flaky failures and confusing browser behavior. Split-DNS itself is described as brittle.

DNS, Downgrade Resistance, and Threat Models

• Proposed browser-side cache/preload (HSTS-style) for “ECH-using” domains to refuse non‑ECH, making downgrade harder.
• Debate: some say DNSSEC is crucial for record integrity; others argue for DoH/DoT to trusted resolvers as sufficient for ECH’s ISP/on‑path threat model.
• Agreement that plaintext DNS greatly weakens ECH’s value.

Censorship, Domain Fronting, and Public Names

• ECH can mimic domain fronting: outer “public_name” can be a benign or unrelated hostname while inner SNI is the real site.
• Specs allow servers not to validate public_name, enabling circumvention of SNI-based blocking and “approved” hostnames that route to blocked content.
• Concerns: this encourages governments to push for IP blocking, CDN cooperation, or legal controls; CDNs could selectively disable ECH by country or hostname.
• Some note IP-based blocking is collateral-damage heavy, hence less attractive for ISPs.

Parental Controls, Age Verification, and Control Models

• One side: hiding SNI makes network-level family filtering harder, driving demand for legal/age-verification regimes and device-level control.
• Others counter: parents can still use client-side filtering/MDM; network-wide dragnet filtering is overused and harms privacy.
• Broader worry that locked-down devices and mandatory verification will erode user control.

Bot Detection and TLS Fingerprinting

• ECH hides ClientHello from passive observers, weakening JA3/JA4 fingerprinting for third parties.
• Clarified that servers/CDNs terminating ECH can still decrypt and fingerprint the inner ClientHello.
• Some speculate sophisticated bots behind CDNs may blend in more easily; naive bots likely won’t implement ECH soon.

Small Servers, IP Certificates, and Scope

• Confusion over spec language about “DNS-based reference identities” and rejection of IP-like names; unclear to some whether IP-based certs are effectively excluded.
• View that ECH mostly benefits multi-tenant/CDN scenarios; single-IP small sites still stand out and can be IP-blocked.
• Workaround suggested: small servers can advertise a generic public_name unrelated to their actual domains.

ESNI vs ECH and Deployment Reality

• ESNI was widely trialed (notably via big CDNs), then aggressively blocked (e.g. by national firewalls) and ultimately abandoned.
• Mozilla-linked rationale: encrypting only SNI was incomplete and had interoperability issues; ECH generalizes this.
• Several note a long period with no practical replacement, leaving plaintext SNI ubiquitous and undercutting “encrypted DNS” claims.

Implementations, Tooling, and Corporate MITM

• Some HTTP servers already support ECH and even automate DNS HTTPS/SVCB records and key rotation; others support it more manually.
• Tools like test suites and visual explainers are referenced.
• DNS automation is hampered by weak, coarse-grained DNS provider APIs.
• Corporate MITM systems can block or strip ECH unless browsers enforce a no‑downgrade policy; expectation is many enterprises will simply disable ECH on their networks.

Overall Sentiment

• Strong enthusiasm for ECH as a privacy and anti-censorship improvement.
• Equally strong skepticism that technology alone can resist determined governments, corporate controls, and operational inertia.

Testing, harnesses, and validation

• Strong consensus that agentic coding only works when there is a deterministic, executable test harness (unit tests, integration tests, browser automation, compression round-trips, etc.).
• Red/green TDD is seen as especially effective: have the agent write failing tests first, verify they fail, then implement until they pass.
• Several warn that LLMs often generate “tautological” or pointless tests that always pass; suggested mitigations include:
  • Forcing tests to fail on a deliberately broken implementation.
  • Using mutation-testing–style ideas to check tests actually detect changes.
  • Being specific about edge cases and status codes, not just “write tests for X”.

How agents are being used in practice

• Popular uses: boilerplate, CRUD, UI flows, landing pages, documentation, and exploring unfamiliar codebases.
• Some report they “barely write code” for certain domains (typed, well-tested web backends, React-style apps) and rely heavily on plan modes and agent loops.
• Others find agents still slower or too brittle, especially for math-heavy logic, ML pipelines, or unfamiliar APIs, and prefer manual coding with AI as an assistant.

Planning, specs, and state management

• Many advocate a structured workflow: write or refine a spec, have the agent produce a plan, review it, then implement with checkpoints and tests.
• Scratch files (markdown logs, decisions/rejections lists, AGENTS.md rules) help agents avoid re-trying failed approaches and encode constraints.
• Some move these logs into structured, queryable stores to avoid context bloat and allow multiple agents to share state.

Code review, quality, and cognitive debt

• Code review is emerging as the main bottleneck when code becomes “cheap.”
• Concerns about huge AI-generated PRs dumped on teammates; proposed countermeasures:
  • Smaller, bisect-safe patches.
  • Treat agent output like junior dev work.
  • Shift some review effort to designs/specs and architectural rules.
• Worries about “cognitive debt” from vast amounts of AI-written code that no one truly understands; interactive explanations and better documentation are proposed partial remedies.

Skepticism, limitations, and anti-patterns

• Strong pushback against hype and pattern-industrial-complex: fear of reinventing simple practices (tests, planning, small commits) under grand “agentic” branding.
• Some argue many workflows overcomplicate things; a single well-instrumented agent plus good observability can beat elaborate multi-agent setups.
• Anti-patterns called out: unreviewed mass PRs, relying blindly on AI-written tests, and assuming agents can replace deep domain understanding.

Organizational and ethical questions

• Mixed feelings about productivity gains that let one person do the work of several; seen as a people/management problem more than a technical one.
• Concerns about tools that mimic human browser behavior being used for spam, though defenders cite legitimate automation use cases.

Project concept

• The project implements an AArch64 CPU simulator that runs entirely on a GPU using neural networks for ALU operations, including add, mul, sqrt.
• Commenters frame it as a “because we can” hack, akin to CPUs in Game of Life or Minecraft, more about exploration than practicality.
• Some note it’s closer to “a CPU on an NPU that happens to be a GPU” than a conventional CUDA-based GPU CPU-emulator.

Performance and practicality

• One estimate: ~625,000× slower than a 2.5 GHz CPU for addition/subtraction.
• People question real-world utility, but others argue it doesn’t need a practical purpose.
• There is curiosity about how many such CPUs could run in parallel on one GPU and whether massive parallelism could offset slowness, but skepticism remains.
• Comparisons are made to more efficient GPU CPU-emulation approaches (qemu-style dynamic translation to shaders), which could be orders of magnitude faster.

Neural arithmetic and exactness

• Discussion around whether an LLM (or neural system) should perform exact arithmetic without external tools, versus just calling out to conventional hardware.
• Some question why one would train networks for operations like sqrt when the GPU already has fast, precise hardware instructions.
• The inversion where multiplication is much faster than addition is highlighted; explained by lookup-like parallelism for mul vs. carry chains for add.
• Idea raised that a fully neural CPU makes execution differentiable, enabling backpropagation through programs for program synthesis, though not useful for normal OS work.

GPU vs CPU roles and future

• Extended debate on whether GPUs could replace CPUs.
• Consensus trend: CPUs and GPUs solve different problems (latency-sensitive, branchy vs massively parallel), and full replacement is unlikely.
• Many expect continued convergence into heterogeneous systems (APUs, unified memory, mixed units like GPU, CPU, NPUs, FPGAs) rather than dominance of one.

Uses, OS-on-GPU, and culture

• Project author’s stated long-term dream: an OS running purely on GPU or on “learned systems.”
• Some link to prior work on parallel operating systems and “compute in memory” concepts.
• Thread contains the usual “can it run Doom?” jokes, references to Doom-on-GPU, and playful renamings of “GPU,” capturing both amusement and admiration for the hack.

Scope and Definitions

• Many see the law’s core concepts (“covered application store”, “operating system”, “general purpose computing device”) as overbroad or unclear.
• Debate over whether package managers (apt, yum, Homebrew), repositories (Flathub, PyPI, GitHub), DNS, torrent trackers, cloud services, routers, and embedded systems could be deemed “app stores.”
• Some argue the statutory “distributes AND facilitates download” language narrows scope; others think a creative prosecutor could still stretch it.

Impact on FOSS and OS Vendors

• Concern that FOSS OSes and tools would be forced to implement age signals, even for volunteer-run projects with no commercial backing.
• People worry about massive potential fines changing the risk calculus for hobby and noncommercial contributors, especially those publishing containers or images.
• Some claim the law is effectively designed for major consumer OSes (iOS, Android, Windows, macOS), with FOSS caught as collateral.
• Suggestions range from adding simple age fields to accounts to extreme responses like “not for use in California” labels or geoblocking the U.S.

Enforcement, Liability, and Vagueness

• Clarified that only the state attorney general can bring civil actions, with fines tied to the number of affected children.
• Disagreement on how “affected child” and “actual knowledge” work: some read the law as allowing developers to rely on OS signals; others think the language could misattribute knowledge or invite abuse.
• Fears that vague wording enables future expansion or prosecutorial overreach.

Privacy, Anonymity, and Slippery Slope

• Some view this OS-level age flag as the least invasive alternative to ID checks and third‑party verification.
• Others see it as a first step toward universal age/ID verification, loss of anonymity, and greater platform and state control.

Parenting, Public Health, and Effectiveness

• Split between those who insist responsibility should remain with parents (using existing tools and network controls) and those who argue most parents lack the technical capacity, framing it as a public‑health problem.
• Many doubt technical feasibility: kids are highly motivated to bypass controls; any system will resemble ineffective “Are you 18?” dialogs.

Legislative Process and Politics

• Some call the law “performative” or a product of lobbying and regulatory capture; others see it as an earnest but technically naive attempt to centralize age signaling.
• Frustration that the FOSS community did not engage earlier in the legislative process.

Overview & Goals

• Weave is a Git merge driver that merges code at the level of “entities” (functions, classes, methods) instead of lines.
• It uses Tree-sitter to parse files, falls back to line-based merge for unsupported languages, and writes normal files back so Git workflows remain unchanged.
• A key motivation is cleaner merges when multiple changes touch the same file but different entities.

Validation & Adoption Concerns

• Several well-known Git ecosystem contributors have privately expressed support; some users see this as strong validation.
• Others question the evidence for demand and worry about promotional tactics (e.g., opening issues on many repos to suggest adoption).
• There is interest in integrating with other tools (e.g., alternative VCSs, Git frontends), but this is mostly early-stage discussion.

Multi-Agent and AI Workflows

• Proponents argue entity-level merging is critical when many AI agents edit in parallel, reducing unnecessary conflicts and saving time/tokens.
• Skeptics say AI can already resolve most textual conflicts and that humans rarely find these conflicts hard anyway.
• A related idea is moving from “fix conflicts later” to “prevent conflicts” via an MCP server where agents claim entities before editing.

Technical Approach & Alternatives

• Compared to other Tree-sitter-based tools that match raw AST nodes, Weave groups entire entities, aiming for simpler, faster, more readable conflicts.
• There’s extensive discussion of storing ASTs (or CSTs) directly in a VCS vs. treating source as blobs; some argue code is already effectively a serialized AST and the real issue is parsers/consumers, not storage.
• Concerns are raised about languages with preprocessors (C/C++) and significant whitespace (Python); Weave claims best-effort handling with Tree-sitter plus language-specific logic.
• Structural hashes are used for rename detection; a commenter doubts this will reliably handle more complex refactors.

Language Support & Tooling

• Current support includes several languages via a shared parser library; Ruby and other languages (Swift, Bash) are requested and described as relatively easy to add through Tree-sitter grammars.
• C# support exists but is not prominently documented.
• A separate tool provides entity-level diffs on arbitrary files, and another experimental tool uses entity graphs for PR triage.

Limitations, Risks & Open Questions

• Weave can still miss purely semantic conflicts (e.g., one change obsoleting another); it reportedly runs post-merge dependency checks to flag some of these.
• Some argue stricter, more conservative conflict detection might be safer in cases where merging both sides leads to dead code.
• Performance trade-offs of AST-based approaches, robustness on heavily macro’d code, and behavior during rebases (vs merges) are raised but not fully resolved.

Perception of TikTok and Its DMs

• Many see TikTok (and similar big platforms) as fundamentally untrustworthy or “spyware,” unsuitable for any private communication.
• Others note that for teens and young adults, TikTok is the dominant social network; DMs are widely used simply because they are convenient and integrated with video sharing.
• Some argue any service offering 1:1 “private” messaging should either implement real E2EE or drop private DMs entirely; others say it’s acceptable to offer non-private DMs as long as that is clearly stated.

Encryption vs. Child Safety

• Critics view TikTok’s justification (“E2EE makes users, especially children, less safe”) as repackaging long-standing government arguments against encryption and as a pretext for surveillance.
• Supporters of stronger moderation argue that encrypted DMs can hide grooming, harassment, and CSAM; visibility into messages can help protect minors.
• Opponents counter that this logic would also justify warrantless home searches; they stress that teaching safety and limiting children’s access to addictive platforms is more important than weakening encryption.

Debate on E2EE Itself

• Strong skepticism that major US platforms provide “real” E2EE, with references to possible government programs and key management tricks.
• Some distrust even Signal and proprietary “secure” apps, pointing out client-side scanning, metadata collection, and the inability of users to verify what proprietary clients actually do.
• Others note E2EE still has clear value against server breaches and external attackers, while acknowledging usability and key recovery remain hard problems.

Age Verification and Child-Specific Devices

• Big subthread on age verification: some call for banning it (threat to anonymity, surveillance creep); others advocate privacy-preserving schemes (verifiable credentials, zero-knowledge proofs).
• Critics argue real-world implementations are usually leaky and politically hard to fix once deployed.
• Proposed alternative: sell “locked-down” or child-mode devices that signal an “underage” flag to apps/OS, shifting ID checks to device purchase rather than every online service. Views range from “sensible harm reduction” to “dystopian.”

Platform Responsibility, Regulation, and Media Framing

• Disagreement over what responsibilities platforms should have: minimal (like telcos) vs. strong transparency, algorithmic accountability, and liability for scam/malicious ads.
• Several comments worry that TikTok’s stance, if successful, will normalize non-encrypted DMs and accelerate a broader surveillance state.
• BBC’s description of E2EE as “controversial privacy tech” is criticized as biased framing; others respond that encryption truly is politically contentious, especially when framed around child protection.

Partnership & Device Support

• Motorola and GrapheneOS announced collaboration on future devices with unlockable/relockable bootloaders and official GrapheneOS support.
• Current Motorola phones reportedly do not meet GrapheneOS hardware/security requirements (e.g., memory tagging, secure element, IOMMU), so support is expected only for future models, likely around 2027.
• Hints suggest initial support for future flagships, especially Razr foldables and a “signature” line; midrange support is considered unlikely in the near term.
• Some commenters view the announcement as early “hype” with little visible work yet.

Motivations & Market Impact

• Many see this as a major win: alternative to Pixels, especially in regions where Pixels are expensive or unavailable, and where Motorola has strong retail presence.
• Discussion frames this as a strategic move for Motorola to differentiate, regain Android share, appeal to privacy‑conscious consumers, and target B2B/government/journalist use cases.
• Others emphasize potential for wider custom ROM ecosystem (Lineage, Sailfish, Linux‑based OSes) if bootloaders stay open.

Security Model & Trade‑offs

• GrapheneOS stance: strict hardware and long‑term update requirements; no interest in supporting weaker devices, even via community patches, to avoid diluting security and stretching resources.
• Uses binary blobs compiled by the project itself; Android source code embargoes are mitigated partly by OEM partners’ earlier access.
• Strong opposition to persistent app‑accessible root: argued to undermine verified boot and hardware attestation and to harm security even if unused. Some users strongly want “owned” devices with root, seeing this as a philosophical deal‑breaker.
• Sandboxed Google Play and “scopes” (for contacts, storage, etc.) are key features; per‑app location, camera, and microphone scopes are planned.
• Many banking apps reportedly work; Google Wallet/tap‑to‑pay does not, though third‑party options exist. Concern that future attestation policies could break more apps.

Trust, Geopolitics & Baseband Concerns

• Debate over whether Motorola’s ownership (Lenovo/China) or historical ties of Motorola Solutions (separate company) to militaries/intelligence should affect trust.
• Some argue verified boot with custom keys mitigates OEM trust; others stress that closed basebands, SIM toolkit features, and potential SoC backdoors mean smartphones can never be fully trustworthy, especially against state‑level actors.
• References to Pegasus and post‑Snowden surveillance are used to argue both that “nobody cares about you” is naive and that defense‑in‑depth still raises attack costs.

Form Factor, Features & UX Wishes

• Repeated calls for: smaller devices, headphone jacks, microSD, removable batteries, and even hardware kill switches; skepticism that market demand is large enough for OEMs.
• Enthusiasts also want good cameras, gaming‑capable Snapdragon hardware, desktop modes, and physical keyboards; some hope for future tablets or laptop‑style docks.
• Complaints about existing Motorola adware/bloatware and hope that GrapheneOS devices will be clean.

Role of PMs, Engineers, and “Vibe Coding”

• Many see technical PMs / product-minded engineers as increasingly valuable, especially as AI handles more coding.
• Some argue PMs coding prototypes is useful for communication, internal selling, and exploring long‑tail ideas that wouldn’t get engineering time.
• Others say letting PMs ship production code is low leverage, creates cleanup work, and confuses accountability: if you ship code, you’re effectively an engineer.

Quality, Risk, and “Prod Diffs”

• Strong concern about PM‑written or AI‑generated code landing in production: edge cases, performance problems, and lack of understanding of complex systems.
• Anecdotes of PM vibecoding causing serious production incidents (e.g., hammering databases, leaving “happy‑path only” data debris).
• Several suggest limiting PM coding to low‑blast‑radius areas (internal tools, dashboards, CSS, personal automation).

Future of the PM Role

• One camp predicts the standalone PM role will shrink or be absorbed into engineering/design as AI reduces coding friction and flattens orgs.
• Others say code is now cheap, so deciding what to build, prioritizing, and having “taste” becomes more important, not less.
• Some PMs expect to specialize (engineering, design, data) and move closer to “product engineer” roles.

Engineers vs PMs as “Product Owners”

• Several engineers claim they could more easily become passable PMs than PMs could become competent builders; others counter that the skill sets and motivations differ.
• Common view: in practice, PMs often shield engineers from politics and conflicting stakeholder demands; removing PMs can overload devs with meetings and context switching.

AI Capabilities and Limits

• Mixed views on how far current models (e.g., Claude Opus) go: some jokingly claim engineers are obsolete; most insist complex systems still require deep engineering judgment.
• “Text-to-code” is seen as flashy but risky; “code-to-text” (AI explaining codebases for PMs) is praised as underused and safer.

Culture, Gatekeeping, and Process

• Some see resistance to PM coding as necessary quality control, not gatekeeping; others think engineers are resisting business folks meeting them halfway.
• Agile/Scrum is framed by some as process that turns both dysfunctional and highly motivated teams into “average”; small, tight teams often function well without heavy process.

Modular RAM and New LPCAMM2 Standard

• Many are excited about LPCAMM2 as a repairable, efficient alternative to soldered RAM and as a way to keep up with high-speed memory requirements.
• Some worry about long‑term availability of CAMM modules 10+ years out, compared with standard DIMMs/SODIMMs.
• CAMM is seen as a technical response to signal‑integrity limits of traditional slots at higher speeds.

Repairability Score and iFixit Credibility

• The 10/10 score is widely praised as a meaningful shift toward user‑serviceable laptops (e.g., modular Thunderbolt/USB‑C boards, easier keyboards).
• Critics argue this is more “replaceable subassemblies” than true board‑level repair and may mean costly OEM parts.
• iFixit is accused of bias and “repairwashing,” especially given its business relationship with Lenovo and perceived inconsistencies in scores vs. other laptops.
• Several commenters say the article and even Lenovo quotes read like AI‑generated marketing copy, reducing trust.

ThinkPad vs Framework and Other Vendors

• Many long‑time ThinkPad owners cite decades of positive experience, easy upgrades (RAM, SSD, screens, batteries) and strong Linux support.
• Framework is praised for ethos and parts logistics but criticized by some for price, reliability issues, and “newcomer” mistakes; others report excellent experiences.
• Lenovo is seen as bringing Framework‑style modularity (especially ports) into a high‑volume mainstream line.

Linux, Firmware, and BIOS Issues

• Recent ThinkPads are generally reported to work very well with Linux and NixOS, including fingerprint readers on some models.
• Firmware updating is a sore spot: Lenovo’s Windows‑centric EXE process is called awkward; fwupd support exists but can conflict with secure‑boot setups.
• Other OEMs (especially HP, some Dell) are criticized for buggy or even bricking BIOS updates.

Display, Keyboard, and Form‑Factor Trade‑offs

• Complaints about limited screen options: no high‑refresh panels and often only 1920×1200 in some regions; some see 60 Hz as fine, others as unacceptable in 2026.
• Keyboards on older ThinkPads are fondly remembered; some say quality has slipped, others are satisfied with current T‑series.
• Debate over plastic vs metal: high‑quality plastic + magnesium chassis is defended as more durable than trendy metal/glass.

Longevity, Security, and Pricing

• Many report ThinkPads running solidly for 8–10+ years with only batteries, fans, or keyboards replaced; refurb ThinkPads are praised as great value.
• Some still distrust Lenovo due to past incidents (e.g., Superfish, firmware concerns, Chinese origin), though others mitigate by immediately installing Linux or coreboot where possible.
• New ThinkPads are seen as significantly more expensive than older generations, with some arguing the value proposition is eroding even as repairability improves.

Street design vs. speed limits and enforcement

• Many argue that simply lowering posted limits (e.g., to 25 mph on wide, straight roads) fails because drivers still travel at the speed the road “invites,” creating dangerous speed differentials.
• Advocates of “engineering over enforcement” push for redesign: lane reductions, narrower visual corridors, curb bump-outs, medians, and vertical elements that naturally slow cars.
• Others emphasize stronger enforcement: more tickets, rehabilitative penalties, periodic retesting, and stricter licensing, while still supporting design changes.
• Concerns are raised that overly narrow lanes and aggressive calming can create new hazards for larger modern vehicles.

Vision Zero, US cities, and mixed outcomes

• Commenters note that cities like Seattle, San Francisco, and Portland adopted Vision Zero–style policies (lower speeds, bike lanes, traffic calming) but saw pedestrian deaths increase or stay flat.
• Possible factors mentioned: weak enforcement, incomplete/compromised designs (especially bike lanes), larger and more powerful vehicles, post-COVID shifts toward more selfish or reckless driving, and GPS rerouting traffic onto residential streets.
• Others push back that correlation is not causation and that isolating policy effects from population growth, behavior change, and other trends is hard.

Safety vs. convenience tradeoffs

• Some see low urban speed limits and heavy camera enforcement (Helsinki, London, Sydney, Amsterdam, Wales) as effective but frustrating and unpopular, especially for drivers.
• Others argue modest speed reductions often barely affect travel time yet significantly cut crashes, and that slower driving plus better transit and cycling can improve overall livability.
• Critics label extreme “safetyism” irrational and complain that driving is being deliberately made miserable to make other modes look better.

Culture, vehicles, and infrastructure differences

• Several comments attribute Nordic/European success partly to more law-abiding cultures, denser urban form, and less driving.
• Others highlight differences in vehicle fleets: EU rules on pedestrian-friendly front ends vs. US prevalence of large SUVs/pickups and bull bars.
• Japan is cited as responding to rising bike crashes with higher fines, contrasted with Helsinki’s emphasis on redesign.
• High-quality, separated bike infrastructure in Helsinki (and the Netherlands) is contrasted with compromised or unsafe US bike lanes.

Data, metrics, and definitions

• Debate over metrics: deaths per distance driven vs. deaths per population; city vs. state vs. national comparisons.
• Some skepticism about “zero deaths” statistics due to differing definitions (e.g., 30-day cutoffs for counting traffic fatalities).

Meta: Many commenters didn’t read the article

• Large portion of the thread treats the title as being about customer-support chatbots.
• Multiple people point out the article is actually about humans offloading their writing/thinking to LLMs and then making others read that output.
• Some argue HN behaves like other social media: reacting to the headline, not the content.

Customer-support chatbots: experiences and tradeoffs

• Some users like chatbots as first-line support: instant responses, quick refunds, or painless price negotiations (e.g., deliveries, subscriptions).
• Others say chatbots rarely solve real problems, serve mostly to stonewall, or funnel users into dead ends (broken callback systems, limited options, repeated data entry).
• A popular “good” pattern: bot collects structured info, then hands off to a human (“smart answering machine”).
• Frustration focuses on lack of reliable human fallback, especially for banks, ISPs, government portals, and complex billing issues.

Economics and ethics of support

• One perspective: human support is very expensive (training, churn, facilities, full burdened costs); trivial calls like password resets or “power cycle your router” dominate volumes.
• Counterpoints:
  • Big firms helped create these problems with confusing UX, fragile products, and opaque flows (esp. identity and passwords).
  • Customers have already paid; “free support” is just bundled support.
  • High-value calls (real bugs, deep technical issues) are rare but important; current triage systems make them too hard to report.
• Debate over charging for support with refunds if it’s the company’s fault; concerns about perverse incentives to deny responsibility.

“AI slop” in writing, PRs, and discussion

• Strong dislike for generic, verbose LLM-generated prose in PR descriptions, blog posts, Slack, LinkedIn, etc.; seen as low-signal, formulaic, and often wrong on details and intent.
• Several argue:
  • If you had to think hard enough to prompt the model well, you could have just written the thing.
  • Readers care about your reasoning and relationship to the facts, not a synthesized average of internet text.
  • LLMs act as “misunderstanding amplifiers” when given fuzzy internal concepts or jargon.
• Others see value in LLMs as:
  • Tooling to expose complex systems via natural language interfaces.
  • Grammar/spell-check and expansion of terse points into accessible prose.
  • Triage aids that surface relevant docs or APIs, as long as humans provide a concise, honest “anchor” summary.

Broader worries about AI content

• Concern that AI-generated “slop” will further drown already noisy internet content, making high-signal material harder to find.
• Calls for emerging etiquette: don’t use agents as your voice in genuine human exchanges, and don’t force others to “talk to your chatbot” when they came to talk to you.

Outage scope and status-page reliability

• Many report 500 errors on git operations, pushes, pulls, CI fetch/checkout, and Pages; some note the status page initially showed only Copilot/Actions issues.
• Several question how timely and truthful githubstatus.com is, though others point out that detailed postmortems and monthly availability reports are usually added later.

Perceived root causes

• Strong belief that ongoing migration from GitHub’s own datacenters to Azure, plus aggressive AI/Copilot push, is degrading reliability.
• Others suggest explosive growth in automated and AI-driven activity (e.g., massive repo cloning, frequent CI polling) may be overloading capacity.
• Some argue corporate incentives favor visible AI features over less visible reliability work.

Uptime metrics and “how bad is it?”

• Links to third‑party tracking show dozens of incidents in the last 90 days and ~98.8% recent uptime for Actions; some estimate “deep into one nine” overall.
• Debate over impact: some think outages are overblown and teams should have other work to do; others at large orgs say repeated incidents materially disrupt thousands of people and automation chains.

GitHub as critical infrastructure / single point of failure

• Discussion emphasizes how deeply CI/CD, deployment triggers, webhooks, package registries, and SSO/permissions depend on GitHub.
• Outages demonstrate that many systems implicitly assume GitHub is always available.

Alternatives and self‑hosting

• Suggestions: Codeberg, GitLab, Forgejo, Gitea, bare git+SSH on a VPS, simple hooks for deployments, and local/third-party CI.
• Some report years of flawless uptime with self‑hosted setups; others counter that migrating large enterprises off GitHub, with all their integrations, is nontrivial.

Resilience and CI design

• Strong advocacy for “break-glass” CI: the ability to run the same pipelines locally or in alternate CI when GitHub/Actions are down.
• Recommended patterns: pipelines as scripts (e.g., build.sh), reproducible local runs, decoupling CI logic from CI infrastructure (e.g., with tools like dagger.io), and treating automation as codified runbooks.

Broader sentiment

• Many see a decline from “beloved, stable Git host” to a frequently failing, enshittified platform under Microsoft.
• Others note that dominant players often retain customers despite recurring downtime, due to lock‑in and risk aversion.