Hacker News, Distilled

Resource-Constrained & Historical Computing

• Many commenters like the idea of “Classical Software Studies”: writing games or apps on 64KB-era machines (Commodore, Game Boy, PDP/VAX, etc.) to relearn discipline around memory, modularity, and system limits.
• Others warn this can give warped intuitions for modern tradeoffs (maintainability vs. micro-optimizing for RAM/CPU). Good as an introductory or elective experience, not the core of a curriculum.

Real-World Software Engineering Skills

• Strong support for courses on:
  • Handling shifting requirements and “moving goalposts” via realistic group projects where specs change late.
  • Version control theory and practice (branches, merges, bisect, strategies).
  • CI/CD, build systems, containers, deployment pipelines, and debugging real systems.
  • Unix/Linux fundamentals (shell, text tools, processes), basic sysadmin/networking.
  • Teamwork, project management, and client communication.
• Some report such courses exist in pockets (e.g., sneaky spec changes, devops-focused Java courses), but they’re rare and hard to fit into standard curricula.

CI/CD, DevOps, and What Counts as “Computer Science”

• One side: CI/CD, Kubernetes, Jenkins, etc. are “not CS” but tooling; curriculum should focus on theory.
• Other side: there’s plenty of CS in these topics (distributed systems via k8s, algorithms/policies in merging, conflict resolution, scheduling) and they are central to modern practice.
• Practical obstacle: teaching CI/CD often devolves into teaching specific vendor stacks, and students may lack prerequisite skills (shell, Git, Linux).

History of Computing & “Classical Software Studies”

• Many argue computing should treat its history more like physics or civil engineering: understanding past systems (VisiCalc, MacPaint, early hypermedia, Smalltalk-like systems) prevents constant reinvention and can inspire better designs.
• Pushback: computing’s history is short and deeply tied to changing hardware “substrate,” so 1970s constraints may not generalize to today.
• Counter-pushback: for most everyday applications, hardware stopped being the limiting factor decades ago, so historical software and interaction ideas are still highly relevant.

Object-Oriented vs Functional Programming / “Unlearning OOP”

• The proposed “Unlearning OOP” course triggers heated debate:
  • Critics: this reflects a shallow or strawman view of OOP; many large systems rely on it successfully, especially in enterprise environments.
  • Supporters: OOP as commonly practiced (especially mutation-heavy, inheritance-centric designs) creates tightly coupled “webs of state” that resist refactoring, whereas functional styles encourage small, composable, testable units.
• Several note that OOP and FP are often complementary in practice (e.g., functional core, imperative shell), and that the real goal is to loosen the dogma that “everything must be an object.”

Performance, “Slow Languages”, and Algorithmic Complexity

• Enthusiasm for a “Writing Fast Code in Slow Languages” course:
  • Show that algorithmic improvements (O(N) vs O(N²)) often dominate language speed.
  • Teach vectorization, leveraging C-backed libraries (NumPy, Python sort), and architecture-aware design.
• Some argue Big-O ignores constants and hardware effects; in practice, “worse” algorithms on linear, vectorizable data can beat “better” algorithms on pointer-heavy structures.

Debugging, Legacy Code & Software Archaeology

• Many want explicit training in:
  • Systematic debugging (beyond print statements): debuggers, logs, profilers, memory tools; avoiding “debugging hypnosis.”
  • Reading and modifying large, messy, or abandoned codebases; understanding tickets, wikis, version history, and “digital archaeology.”
• Suggestions include courses modeled on labs: given a legacy system with many bugs/perf issues; course ends when tests pass and scaling goals are met.

Programmer Psychology & Workplace Dynamics

• Popular proposed courses:
  • “Refusal Lab” and ethics labs: practicing saying no to unethical or impossible demands.
  • “Obsessions of the Programmer Mind”: code formatting, type wars, over-refactoring, novelty-driven development, hype-chasing vs. principled skepticism.
  • Team dynamics, meeting behavior, blame management, and career realities (cheating analogies, “success has many parents; failure is an orphan”).

Broader Curriculum & CS vs Software Engineering

• Recurrent theme: many of the proposed classes are really software engineering, devops, or professional practice, not “computer science” in the narrow theoretical sense.
• Some fear CS degrees are drifting into coding bootcamps; others argue current programs already overemphasize theory and underprepare students for actual software development.
• Shared undercurrent: whatever the division, students benefit from exposure to multiple paradigms (imperative, OO, functional, logic), historical systems, and at least one deep dive into how real software is built and maintained.

Artificial scarcity and digital ownership

• Many see CS skins as classic artificial scarcity: trivially reproducible assets whose supply is constrained by a central database (Valve), similar in structure to NFTs but centralized.
• Others note this mirrors long-standing real-world practices: luxury brands limiting runs, art markets where provenance drives price, designer sneakers, beanie babies, trading cards.
• Skeptics argue digital items differ because their existence and rules depend entirely on a single company, which can change value “at the press of a button.”

China, capital controls, and shadow banking

• Several comments describe CS skins as a de facto RMB↔USD bridge under Chinese capital controls.
• Skins can be bought and sold in both currencies and transferred across regions; this enables informal FX and “discounted” Steam balance.
• There’s disagreement on scale: some say it’s meaningful shadow banking; others claim Steam’s volume is too small to matter compared with other, more established channels.

Gambling, lootboxes, and kids

• Strong sentiment that lootboxes are unregulated gambling, often targeted at minors, with case openings openly marketed on Twitch/YouTube.
• Comparisons made to Pokémon/TCG packs, arcade ticket games, coin pushers, and casino gambling; several want lootboxes banned outright, at least for under‑18s.
• Debate over responsibility: some blame parents for lax controls; others argue it’s unreasonable to expect families to individually counter highly-optimized gambling systems.

Status signaling and “irrational” value

• High-priced skins are compared to designer bags, watches, sneakers, gold, and fine art: largely about status signaling and group norms, not intrinsic utility.
• Some note online identities (pseudonyms) can be as important as offline status, so digital flexing feels meaningful to many players.
• Others remain baffled that a $20k cosmetic knife can seem rational to anyone, seeing it as speculation, money laundering, or pure vanity.

Reactions to Valve’s changes

• Many active players welcome cheaper knives and the blow to third‑party gambling sites, hoping this “re‑centers the game” on gameplay.
• Traders and “investors” describe large paper losses and fear further unexpected rule changes; some mention extreme outcomes like reported suicides.
• Several frame this as a textbook lesson in closed, centrally controlled economies: one policy change can wipe out billions in notional value.

Valve’s incentives and ethics

• Two main theories: (1) product/legal strategy—reduce gambling risk and external speculation; (2) economic strategy—shift trades back on‑platform, where Valve captures marketplace fees.
• An ex‑developer describes long‑standing internal concerns about off‑platform markets, scams, and players grinding purely for money.
• Some view Valve as relatively pro‑consumer compared to the industry; others see the entire skins/lootbox system as “running a casino for kids” regardless of this tweak.

Scope of Monopoly and the 30% Figure

• Debate over how broad Apple’s power really is: critics frame it as “every business pays 30% to reach mobile users”; others counter that:
  • Only iOS app distribution is affected, not all businesses.
  • Historically 30% applied to paid apps and digital goods; now many apps pay 15% or nothing.
• Clarification that pre‑2020 it was effectively a blanket 30% on paid apps and most in‑app digital purchases; some categories (Uber, Amazon, etc.) were exempt from IAP but still paid the 30% “distribution” cut on paid apps.

How the Tribunal Got to 17.5%

• People ask where 17.5% comes from.
• Quoted judgment: tribunal compared other platforms (Epic Games Store, Microsoft Store, Steam’s lower tier), concluded a competitive range of 15–20%, and simply took the midpoint (17.5%) via “informed guesswork.”
• Some call this “made up”; others reply that this is literally what courts do when reconstructing a counterfactual in a monopolized market.
• Disagreement whether Google Play should be a benchmark, given it is itself alleged to have similar competition issues.

What Is a “Fair” Commission?

• Answers range from 0% (“already paid via hardware margins”) to 5–10% (anchored to payment processors) to “anything the market will bear if there is real competition.”
• Strong view that the core problem isn’t the percentage but exclusivity: Apple both owns the OS and is the only allowed store and payment channel.
• Many argue the only principled answer is: let third‑party stores and payments compete; then the market discovers the fair rate.

Sideloading, Third‑Party Stores, and Security

• One camp: iOS’s gatekeeping is essential to prevent mass malware, spyware, and app‑driven fraud; opening to sideloading would re‑create the Windows XP “adware hell.”
• Opposing camp: security comes from sandboxing and OS design, not store monopoly; macOS and PCs allow arbitrary installs and are not overrun; App Store already hosts scams and spyware‑like apps.
• Some argue for strong warnings and “dumb‑user” modes, not a universal ban on alternative stores or direct .ipa installs.
• Concern that Google is now copying Apple’s lockdown (verified‑developers signing, attestation), creating a de facto duopoly.

Comparisons: Steam, Consoles, and Others

• Steam also takes ~30% but:
  • Operates on open platforms (Windows/Linux).
  • Decreases its cut at high volumes and provides substantial discovery/promotion.
• Console stores (Sony/Nintendo) similarly charge 30%, but their hardware doesn’t dominate general computing and critical services (banking, messaging) the way phones do.
• Many say the Apple case is different because iOS devices are effectively essential infrastructure and Apple bars rival stores and toolchains.

Fines vs Structural Remedies

• $2B is characterized as “a couple of days of global revenue” or “a few days of profit”; likely cheaper than giving up monopoly rents.
• Some suggest fines should scale with global revenue or escalate daily until compliance, or be paired with personal liability for executives.
• Others argue fines are inherently weak; real remedy should be structural (forcing separation of OS and store, or mandatory openness).

Who Ultimately Pays

• Tribunal assumed developers pass ~50% of the overcharge to users; several commenters call that economically naive, arguing prices are set by willingness to pay and devs will mostly keep the windfall if fees drop.
• Broader point: in most cases, end users ultimately bear much of the cost of monopolistic rents, though incidence depends on market elasticity.

When mmap is faster (and when it isn’t)

• mmap can eliminate copies (kernel → user buffer → app buffer), giving big wins for read‑heavy, random access workloads (e.g., CDB, custom DBs, large matrices, append‑only logs).
• For already-cached data, mmap can be as fast as a memcpy from RAM, while read/pread adds syscall overhead plus copies.
• However, for typical sequential reads into a buffer, buffered I/O (fread/read/pread) and modern async mechanisms (io_uring) are often as fast or faster, with better readahead behavior.
• Multiple commenters stress mmap is “sometimes” faster, not a general replacement for read/write.

Interaction with Go’s runtime and page faults

• With mmap, a page fault blocks the OS thread running that goroutine; the Go scheduler can’t run another goroutine on that M/P while the fault is serviced.
• With explicit file I/O, the goroutine blocks in a syscall and the runtime can schedule other goroutines, giving better utilization under I/O latency.
• There is currently no cheap, ergonomic OS/API model for “async page faults”; proposals involving mincore, madvise, userfaultfd, signals, or rseq-style schemes are seen as complex and/or slow.

Benchmark design and the “25x faster” claim

• Several commenters say the showcased benchmark is flawed: the mmap version often doesn’t actually touch data, only returns slices, so it measures “getting a pointer” vs “copying data”.
• To be fair, both paths should read or copy the bytes and page cache should be controlled (e.g., drop_caches or touch pages).
• With realistic access (actually reading bytes), a 25x gap is considered unlikely; more like small constant-factor differences depending on call size and access pattern.

APIs, OS design, and alternatives

• Unix historically standardized on read/write to work uniformly across files, ttys, pipes, etc.; mmap arrived later and has different semantics (e.g., mapping can change under you, SIGBUS on shrink).
• io_uring is repeatedly cited as a better modern primitive for high‑performance I/O: async, controllable readahead, zero copies with the right setup, and no hidden page-fault stalls.
• Some argue OS-level abstractions like scheduler activations or newer proposals (UMCG) could better integrate user scheduling with page faults, but these are not widely available today.

Pitfalls and gotchas

• Mappings outlive file descriptors; truncating or shrinking a mapped file can cause SIGBUS on access and unspecified behavior.
• mmap allocations don’t show up clearly in Go’s pprof heap reports, making memory pressure/debugging harder.
• Writes via mmap are tricky; in-place random writes can be problematic, though append-only patterns can work well.
• Some filesystems or drivers can misbehave with mmap (e.g., reports of issues on macOS ExFAT with SQLite WAL), though the exact root causes are debated.

Real-world usage patterns

• Positive reports: custom DBs, key–value stores, and log-structured systems see large gains from mmap, especially for random reads and read‑mostly workloads that fit in RAM.
• Negative/skeptical reports: for typical apps doing buffered sequential reads or needing robust concurrency semantics, mmap adds complexity and hidden latency points without dramatic wins.

Context around Varnish

• There’s discussion clarifying that “Varnish Cache” today has both a corporate fork and another version (renamed Vinyl Cache), and that the company behind the blog post has long funded and maintained the codebase rather than it being a one‑person effort.

Humorous framing of /dev/null as a database

• Most comments lean into the joke: /dev/null as the perfect, infinitely scalable, ACID- and CAP-compliant “database” with zero bugs, no support issues, and massive cost savings once all data is piped into it.
• People riff on real-sounding productization: “Null as a Service” (NaaS), devnull-as-a-service.com, enterprise policies with /dev/null0 and /dev/null1, audits, and DR runbooks.
• Support and analytics jokes: routing tickets and logs to /dev/null “solves” reliability and throughput problems.

ACID, CAP, and pedantic pushback

• Several point out that /dev/null is not actually a database, more a storage sink.
• Durability is debated: some argue it trivially satisfies durability because nothing is stored; others insist durability refers to preserving user data, which clearly fails here.
• Similar nitpicks about “state transitions” when there is effectively only one state, and that the joke relies on colloquial, not formal, definitions of ACID.

Real-world behavior and failure modes

• /dev/null can fail in practice: missing /dev, running out of file descriptors or memory, or /dev/null being replaced by a regular file or a different device (allowing data capture or system instability).
• Disaster recovery is tongue-in-cheek: you can recreate it with mknod and chmod, and “all the same data will be there” because it’s always empty.

Performance, scalability, and “web scale”

• Benchmarks show tens of GB/s when writing /dev/zero to /dev/null; others test pipes (yes | pv) and observe pipe or tool overheads.
• Many jokes about horizontal sharding, global sharding “across the universe,” Kubernetes deployments, and “Heisen-throughput” that scales as high as you can measure.

Related satire and analogies

• References to S4 (Super Simple Storage Service), write-only memory, “mangodb,” nocode, supersimplestorageservice.com, and pipe-logic/circuit analogies.
• A few criticize the joke as weak or sloppy; others defend it as classic nerd humor and a “trivial solution” that usefully highlights how ACID/CAP definitions can be vacuous.

Security / tampering angle

• One concern: a privileged user can replace /dev/null with a normal file or different device, allowing interception of “discarded” data.

Experimental psychology and “insight”

• Commenters connect the essay’s themes to “insight” problem solving: getting stuck due to fixation, then suddenly seeing a solution.
• Verbalization is said to increase fixation, while visualization can help break it—consistent with some lab findings.
• Some criticize the essay as unmoored from existing research and wish it cited the problem‑solving literature more directly.

Different inner modes of thought

• Wide variation is reported:
  • Constant, sentence‑like inner monologue.
  • Primarily images, spatial/kinesthetic “feel”, or emotion with little or no words.
  • Aphantasia (no imagery) with purely linguistic or “silent text” thought.
  • Hyper‑vivid imagery, sometimes remembered decades later.
• People describe reading either as “hearing every word” (slower, high comprehension) or as absorbing paragraph shapes and concepts (fast, lower comprehension).
• Many note difficulties visualizing abstractions or, conversely, difficulty thinking in pure language.

When wordless thinking seems better

• Visual art, music, athletics, mushroom hunting, and some forms of coding are described as almost entirely nonverbal.
• Several programmers and mathematicians report “seeing” structures, architectures, or proofs as shapes, flows, or motions, then later translating to code or notation.
• Insight “in the shower,” dreams that metaphorically encode technical problems, and naps/meditation are framed as high‑value nonverbal processing.

Costs and constraints of language

• Language is seen as both helpful structure and restrictive abstraction: it compresses, constrains, and can freeze an idea prematurely.
• Some feel a rich, multidimensional idea becomes a “crippled shadow” when verbalized, sometimes even breaking their connection to the original intuition.
• Others feel wordless thinking risks confusing feelings with logic and makes external critique impossible until ideas are eventually expressed.

Writing, communication, and collaboration

• Many insist that wrapping insights in words (or code, diagrams) is essential for checking rigor and sharing knowledge, even if discovery was nonverbal.
• Writing is described as a crucial “translation layer” and trainable skill; speaking is often seen as a weaker, more lossy channel.
• People report powerful “second‑processor” effects when collaborating with similarly wired thinkers, though some caution this may involve projection rather than true shared mental content.

Meta‑claims about thought itself

• Some argue all real thinking is inherently nonverbal, with words as “sportscasting” layered on top; LLM‑style language manipulation is contrasted with this view.
• Others push back on superiority claims, noting every style has blind spots: verbal thinkers ruminate; nonverbal thinkers struggle to explain.

Tools and Techniques to Block Shorts

• Many alternatives to FocusTube are shared: uBlock Origin filter lists, custom CSS/filters, Brave’s “YouTube Anti-Shorts” list, FreeTube, NewPipe, SmartTube, TizenTube, Unhook, UnTrap, Control Panel for YouTube, AppBlock, ScrollGuard, Leechblock, Tampermonkey/Greasyfork scripts, and router/hosts-level blocking.
• Common strategies:
  • Hide Shorts sections and other “doomscroll” surfaces (home, sidebar, search).
  • Redirect youtube.com/shorts/VIDEOID to watch?v=VIDEOID to avoid the vertical, infinite-scroll UI.
  • Disable watch history to kill recommendations and Shorts on web and app (though this also removes useful recs).
• On Android, people discuss ReVanced and potential future limitations from Google’s signing requirements; some fall back to sideloading via ADB or custom ROMs.

Sentiment on Shorts vs Long-Form Content

• Strong hostility: “AI slop”, stolen clips, low-context, highly addictive, and “brainrot.” Many say they never intentionally click a Short.
• Some praise: quick sketches, cooking/woodworking tips, previews that help decide if a full video is worth it, and relief from padded 10–20 minute “YouTube-optimized” videos.
• Several note the Shorts algorithm often surfaces more relevant topics than the main feed, but they still prefer to find or watch the full-length versions.

Addiction, Time-Wasting, and Mental Health

• Numerous comments describe Shorts/TikTok-style feeds as “digital drugs” or akin to gambling: infinite scroll plus variable reward loop leads to hours lost and post-use “hangover.”
• Some users explicitly block Shorts because they’re too personally addictive; others say they feel no pull at all and see the panic as overblown.
• Debate arises over whether any leisure that’s “just for fun” is hedonistic vs a legitimate use of time.

Critique of YouTube’s Design and Incentives

• Widespread frustration that Premium users can’t opt out of Shorts or algorithmic feeds; “don’t show me this” is seen as a placebo.
• Product decisions are framed as hostile: forced Shorts entry points, limited controls, “show fewer” instead of “never,” and AI/ads pushed everywhere.
• Many see this as engagement-metric optimization by PMs and executives, likened to addictive industries (gambling, tobacco).

Kids, Regulation, and Broader Media Debate

• Parents express difficulty blocking Shorts on kids’ devices; some advocate focusing on encouraging creation/other activities rather than pure technical blocking.
• Multiple calls for legal requirements to let users opt out of algorithmic feeds or for broader regulation of attention-extractive design.
• Others argue that panic over Shorts repeats historic moral panics about novels, TV, or writing itself; the real issue is structural incentives and modern work/life patterns, not the medium alone.

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.