Hacker News, Distilled

AI powered summaries for selected HN discussions.

Page 551 of 794

Dell ends hybrid work policy, demands RTO despite remote work pledge

RTO as Power Move / Shadow Layoffs

  • Many see Dell’s policy change as primarily about power and headcount reduction, not collaboration.
  • “Forced RTO” is framed as a stealth layoff: people quit without severance, especially those with options.
  • Some argue this tends to retain the most financially desperate, not the most skilled or motivated.
  • There’s frustration that everyone knows the “collaboration” justification is false but must pretend otherwise.

Talent, Hiring, and Market Effects

  • Commenters expect pro-remote employers to gain a major recruiting edge, especially for top talent.
  • Recruiters already report difficulty finding strong candidates who will accept RTO/hybrid.
  • Some predict an A/B test: remote-first companies can hire from a larger pool and may outperform long-term.

Productivity, Collaboration, and Tools

  • One side: colocated teams with whiteboards and ad‑hoc chats are described as 2–3x more effective, especially for complex work and junior dev growth.
  • Others counter that remote tools (Zoom, Slack, shared docs, Lucidchart, etc.) work fine if used well; many teams already span time zones where “30‑second chitchat” is impossible.
  • Several note that pre‑COVID offices were mostly headphones plus meetings, with little organic collaboration.
  • Strong emphasis that communication quality and management competence matter more than location.

Culture, Trust, and Corporate Honesty

  • Dell’s reversal from marketing remote/hybrid as the future to mandating RTO is seen as a bait‑and‑switch.
  • Workers view broad, inflexible mandates and camera rules as petty control and micromanagement.
  • Some liken the dynamic to everyone knowingly participating in an obvious lie.
  • Others argue small or owner‑managed companies can tailor remote policies person‑by‑person, while big public firms default to blanket rules to avoid legal risk.

Commute, Health, and Environment

  • Commuting is called unpaid, stressful, dangerous time that reduces performance and quality of life.
  • Several mention huge personal health gains from WFH (drastically fewer illnesses), and lament that air quality and disease mitigation were largely ignored post‑COVID.
  • RTO is viewed as environmentally regressive and at odds with “green” branding.

Policy Inconsistencies and Hypocrisy

  • Dell (and similar firms) still outsource to distant time zones and cut travel budgets, undermining the “in‑person collaboration” rationale.
  • If in‑office collaboration were truly central, commenters say, companies would reduce offshoring and increase budgets for periodic in‑person team meetups instead of local badge‑tracking.

Individual Responses to Mandates

  • Some who flatly refused RTO kept their arrangements short‑term but ended up sidelined or pushed out.
  • Others quietly negotiated exceptions with sympathetic managers—effective until upper management or HR started enforcing via badge data.
  • Several advise treating refusal as a bridge‑burning move and lining up another job first.

ADHD Didn't Break Me–My Parents Did

Blame, Responsibility, and Therapy

  • Thread splits on whether the essay “blames” parents or neutrally names harm to move on.
  • Some say blame is psychologically useful if you’ve spent a lifetime blaming yourself; others say staying in blame (of parents or self) is unproductive.
  • Several note that therapy can over-focus on blaming parents, missing undiagnosed neurodivergence in both generations.
  • A common theme: as adults, you’re responsible for dealing with the consequences of your upbringing, fair or not.

Parenting Neurodivergent Children

  • Strong agreement that parenting ADHD/autistic kids is extremely hard and nearly impossible to “get right” from the child’s perspective.
  • Some defend strict structure as necessary preparation for an inflexible world; others see discipline-only approaches (social deprivation, banning books, constant restriction) as edging into abuse.
  • Multiple commenters stress explaining why rules exist instead of “because I said so,” while others argue this is unrealistic with some neurodivergent kids or in emergencies.
  • There’s empathy for undiagnosed neurodivergent parents whose own impairments distorted their parenting.

Society, School, and Incompatibility

  • Many argue ADHD is both a real attention deficit and a mismatch with environments (schools, suburbs, cubicle work) that demand prolonged sitting, punctuality, and conformity.
  • Discussion contrasts past communities that informally absorbed “misfits” vs today’s productivity-obsessed systems; some say misfits mostly suffered then too.
  • Suburban isolation and fear culture are seen as leaving kids with only school and screens, limiting healthier outlets.

ADHD, Trauma, and Diagnosis

  • Several accounts link ADHD traits to childhood trauma and authoritarian homes; others warn against reducing ADHD purely to trauma.
  • Debate over whether ADHD is over-medicalized and loosely defined vs a clearly disabling executive-function disorder for many.
  • Diagnosis is described as both clarifying and identity-shaking: shifting from “rebel/misfit” narratives to “neurochemical condition.”

Medication and Treatment

  • Stimulants are described as life-changing and sometimes the only way to function by some; others cite overdiagnosis, “legal meth,” and ruined lives.
  • Concerns about societal pressure to medicate kids to fit school norms vs using meds as a tool to build better routines.
  • There’s interest in psychedelics, therapy, and future assistive tools (e.g., AI) as alternative or complementary supports.

Neurodivergence, Work, and Value

  • Several see ADHD as evolutionarily or structurally useful: exploration, novelty-seeking, and cross-domain thinking help in startups, research, and creative work, but clash with rigid academia and corporate metrics.
  • At the same time, ADHD can undermine health maintenance, careers, and relationships, especially without accommodation or insight.

It's OK to hardcode feature flags

When Hardcoding Feature Flags Is Acceptable

  • Many see hardcoded / config-file flags as fine for:
    • Low-traffic apps, solo devs, or orgs with very fast and frequent deployments.
    • Trunk-based development where flags are short‑lived “merge shields” and later deleted.
    • Beta builds or QA/stakeholder test deployments.
  • For these cases, a JSON/YAML file or env vars, committed and deployed with the app, are considered sufficient.

Why Dynamic Feature Flags Matter

  • Strong agreement that in higher-scale or slower-deploy environments, hardcoding is risky:
    • Need to roll out gradually, target segments, and turn features off instantly without redeploy.
    • Critical for mobile and long release cycles where shipping another build is slow.
    • Flags de‑risk deployments, enabling safer experimentation, A/B testing, and measurement of impact (crashes, engagement, revenue).
  • Several commenters say their org effectively never rolls out without flags; disabling a broken feature via a flag has saved incidents.

Build vs Buy: Homegrown vs SaaS Platforms

  • Many argue feature flags are simple enough to roll yourself:
    • Flags in a DB table, JSON in object storage, YAML in a separate repo, etc.
    • Benefits: no extra outage dependency, avoid vendor lock‑in and high SaaS costs.
    • Some report moving from robust in‑house systems to LaunchDarkly increased outages and complexity.
  • Others defend SaaS tools:
    • Provide rule builders, targeting, analytics, experimentation, multi‑tenant support, SSO, auditing.
    • Can be worth it for mid‑to‑large SaaS orgs where a dedicated team would otherwise be needed.

Implementation Approaches & Operational Concerns

  • Patterns mentioned:
    • DB‑backed flags with per‑user overrides; local caching and/or CDN long‑polling.
    • Config files pushed via CI/CD, object storage, secret managers, or Kubernetes ConfigMaps.
    • Passing flags (or references) per request so all services see a consistent set.
  • Concerns: atomicity of changes across large fleets, minimizing latency, and ensuring apps keep working when external flag services fail (near caches, defaults, offline modes).

Pitfalls & Terminology

  • Common problems: stale flags never removed, tangled flag dependencies, config‑caused incidents, and confusing “flags vs config” semantics.
  • Some feel “feature flags” has drifted from its original “development guardrail” meaning into generic runtime configuration, reducing conceptual clarity.

Bzip3: A spiritual successor to BZip2

Benchmarks & Performance

  • Multiple independent benchmarks were shared:
    • On a large text file and a Linux disk image, bzip3 achieved slightly better compression ratios than zstd/xz but was often much slower, especially on decompression, and used far more RAM (e.g., ~18 GB vs single‑digit MB for bzip2).
    • One user’s SQL benchmark found bzip3 compressing better than zstd for similar compression time, but decompression was ~20× slower, contradicting the README’s claims and raising suspicion about cherry-picked inputs and HDD-skewed results.
  • Enabling zstd’s --long and higher levels (up to -22) often made zstd competitive or superior on the same datasets.

Benchmark Design & Long‑Range Redundancy

  • The headline Perl-source benchmark (many similar versions) is seen as a “lowlight”:
    • It heavily favors algorithms that exploit long-range redundancy across near-duplicate files.
    • Others show zstd and even rar+lzip-style tools doing extremely well once long-window parameters are tuned.
  • Several argue that such a corpus is unrepresentative for typical use; corpus benchmarks later in the README are viewed as more realistic.
  • Discussion notes that BWT-based schemes shine on codebases with many similar files; suggestions include sorting files by extension/name before archiving to help any compressor.

Algorithm Focus & Design Choices

  • The author states bzip3 is intended as a modern replacement for bzip2:
    • BWT-based, text-leaning, with much larger block sizes and built‑in parallelism.
    • Uses arithmetic coding and context mixing; designed for modern CPUs with more RAM/cache.
  • Clarifications that LZ and BWT tend to excel on different data (binary vs “textual”).

Burrows–Wheeler Transform (BWT) Discussion

  • Many express near-awe at BWT’s “magic,” especially its reversibility.
  • Several detailed explanations:
    • BWT clusters symbols sharing the same following context, turning n‑gram structure into runs that RLE + entropy coding can exploit.
    • It’s closely related to suffix trees/arrays and conceptually similar to high‑order PPM models but with an implicit model.
    • Huffman/ANS need a model; BWT provides an efficient high‑order model, making low-order predictors behave like high-order ones.

Naming, Compatibility, and Ecosystem

  • Some dislike the “bzip3” name as easily confused with bzip2 and not wire-compatible, preferring a more distinct name.
  • Others argue an incompatible format merits a new major version number; confusion is the trade‑off.

Reliability, Backups, and Warnings

  • The README’s explicit warning about possible unrecoverable data makes some hesitant to use bzip3 for backups.
  • Others note virtually all OSS licenses disclaim warranty; reliability must be established via testing (e.g., compress–decompress–verify loops).
  • Past reports of bzip2 data loss and lzip’s focus on recoverability are mentioned; some have switched xz → lzip for that reason.

gzip vs zstd and Practical Adoption

  • Several contend zstd dominates gzip on speed and ratio at all points, recommending zstd (or lz4 for ultra-fast) except where backward compatibility is paramount.
  • Others stick with gzip for near-universal availability, tooling (zcat, zless, zgrep), and long-term “Lindy” stability.
  • Concerns about how widely zstd and related tools are installed by default across OSes; some will wait for zstd integration into ecosystems (e.g., Python stdlib) before switching.

Other Tools, Features, and Omissions

  • Some ask why lzip wasn’t benchmarked; they see it as a natural comparison point.
  • A feature request: store uncompressed size in headers (as gzip does); debate follows about zip bombs vs easier integrity checking.
  • Interest in better “long‑range” compression algorithms beyond large-window LZ/BWT and deduplication; this is seen as a promising but under‑researched area.

Apple is open sourcing Swift Build

Embedded Swift and Interoperability

  • Multiple commenters confirm Apple is actively investing in Embedded Swift (examples on ESP32, RP2040/RP2350, WWDC talks, docs).
  • Interop with C/Objective‑C/C++ is described as a core design goal; Embedded Swift produces ordinary object files that can link with C code.
  • FreeRTOS interop is considered feasible; one sample includes freertos/FreeRTOS.h. Biggest limitation noted: async support is rudimentary, currently single‑threaded.
  • Some speculate Apple wants Swift to replace internal “safe C” dialects (e.g., for iBoot, Secure Enclave, firmware, smart home devices).

Xcode, Tooling, and Developer Experience

  • Strong split: some say Xcode is “fine” if you avoid Interface Builder and keep SwiftUI simple; others describe it as crash‑prone, slow, and bug‑ridden (indexing issues, broken refactors, flaky tests, git confusion).
  • Several express desire to decouple Swift from Xcode; others note Swift has had CLI tools and a VS Code plugin for years, though VS Code support is still seen as weaker than Xcode.
  • Frustration that newer Swift versions often require newer Xcode/macOS, effectively forcing hardware/OS upgrades; others counter that standalone Swift toolchains can be installed, but that doesn’t solve iOS SDK/codesigning.

Apple Control, Trust, and Cross‑Platform Perception

  • Many argue Swift is “Apple‑tied” in branding and governance: Apple leads the project and prioritizes Apple platforms, which discourages non‑Apple adoption.
  • Others reply this is similar to Go, Rust, C#, Zig, etc., all of which have strong corporate or core‑team control, plus formal proposal processes.
  • Debate over whether Apple can be trusted as a long‑term steward; comparisons to .NET/Mono and other corporate‑controlled ecosystems recur.
  • Some emphasize Apache licensing and the ability to fork, while skeptics say the real risk is strategic control and priorities, not code access.

Linux, Foundation, and Ecosystem

  • Complaints that Swift still lacks first‑class distro packages; most Linux installs rely on tarballs, Docker images, or a Swift‑specific toolchain manager.
  • Others say distro toolchains are typically outdated anyway and prefer rustup‑style managers; one points out Swift provides such a tool.
  • New open‑source swift-foundation and swift-testing are highlighted as moves toward full, cross‑platform core libraries comparable to Apple’s proprietary Foundation/XCTest.
  • Some report modern Swift on Linux (with new Foundation) now feels close to macOS in practice for server‑side usage.

Swift Build and Build System Goals

  • The newly open‑sourced Swift Build is presented as a unified build engine that SwiftPM can delegate to on all platforms.
  • Apple‑specific behavior is being moved into plugins so the core build system can be shared by macOS, Linux, and Windows.
  • Commenters see benefits in easier debugging of build issues and faster access to fixes, without waiting for Xcode releases.
  • One link from the Swift forums claims this will improve SwiftPM and builds on all platforms, setting a foundation for more consistent multi‑platform tooling.

Comparisons to Other Languages and Ecosystems

  • Several compare Swift’s trajectory to C#/.NET: powerful language, originally platform‑tied, slowly opened, but still perceived as vendor‑owned.
  • Others argue .NET Core is now a strong, fully multi‑platform framework and suggest Swift would need similar depth in tooling, libraries, and governance to gain comparable trust.
  • Some prefer Kotlin, Rust, Go, or C# due to broader platform neutrality, more mature tooling, or richer ecosystems; others find Swift “comfy” and would like to use it beyond Apple platforms to avoid JVMs or Rust’s complexity.

Language Ergonomics, Error Reporting, and Compile Times

  • Swift is widely praised as a “really cool” and expressive language with strong safety and good C interop.
  • Criticisms include:
    • Poor crash messages for “index out of range” in non‑Xcode contexts: stack dumps require symbolication and can still be unhelpful; this contrasts with Go’s clear file/line panics.
    • Slow compile times, often attributed to complex type checking and overload resolution.
    • Perception of increasing complexity (many keywords, “too complex” types, extensive extensions) and a drift toward a Scala‑like feel.
  • Some note Swift is IDE‑first (Xcode) rather than CLI‑first, making non‑Mac workflows feel rougher than languages designed around simple tooling from the outset.

Adoption Prospects and “Dying Language” Debate

  • One camp asserts that without full early parity on non‑Apple platforms and more open tools (even Xcode), Swift will remain mostly confined to Apple ecosystems and be unattractive for general use.
  • Others strongly dispute claims that Swift is “dying,” pointing to its centrality for iOS/macOS/watchOS/visionOS apps and new uses (embedded, server‑side, projects like a Swift‑based browser).
  • Several argue Swift’s fate outside Apple depends on whether non‑Apple developers see enough long‑term neutrality and investment to justify choosing it over better‑established, less vendor‑tied alternatives.

Over 90% of U.S. airport towers are understaffed, data shows

Causes of ATC Shortages

  • Thread consensus: this is a long-running, multi-administration problem going back at least to post‑Reagan mass hiring and clumped retirements, not something that appeared suddenly.
  • Contributing factors mentioned: 2013 sequestration academy shutdown, chronic congressional underfunding, slow hiring pipeline, and a mandatory retirement age.
  • Several argue it’s fundamentally a budget and pay issue, not a lack of willing/able candidates.

Hiring Policies, DEI, and the Biographical Assessment

  • Strong debate over the FAA’s 2014–2018 “Biographical Assessment” test.
  • Some see it as deliberately engineered to achieve specific racial outcomes (“DEI rot”) and possibly discourage would‑be applicants; others frame it mainly as incompetently designed psychometrics with political pressure for diversity.
  • Others push back that actual numbers from related lawsuits suggest it affected only a few percent of the workforce and cannot explain the overall shortage; they demand evidence of causality rather than innuendo.
  • Broader DEI debate: one side equates it with quotas and lowered standards; the other insists DEI should mean widening recruiting funnels while still hiring the best-qualified.

Pay, Working Conditions, and Politics

  • Controllers in the thread say pay is no longer competitive relative to stress, schedule, and health impact; some have even left after new contracts reduced pay.
  • It’s a ~3‑year training process, so no quick fix; however, higher pay could reduce attrition and attract more candidates over the medium term.
  • Confusion and disagreement over the impact of a recent federal buyout/“resign or stay” email: some interpret it as pressure to leave; others call that an overstatement, noting later clarification that controllers are excluded.
  • Several point to repeated congressional refusals to fund more hiring despite known shortages.

Technology, Modernization, and AI

  • Many argue modernization (NextGen, better sensors, ADS‑B/TCAS displays to pilots, revised procedures) can reduce controller load, but note that upgrading a live safety‑critical system is inherently slow, expensive, and risk‑averse.
  • Some see ATC as “perfect for automation” or even for AI; others respond that safety‑critical roles require deterministic, robust systems and that ML/LLMs are ill‑suited, especially for novel edge cases.
  • There is disagreement over how much tech could have prevented specific recent incidents versus fundamental traffic density and procedural design.

Safety and Public Risk Perception

  • Some commenters ask whether U.S. air travel should now be considered “dangerous” given understaffing.
  • Others emphasize that commercial flying remains extremely safe and that near‑miss reporting and systems like TCAS are evidence of safety, not the opposite.
  • Several note that trends in near misses and controller fatigue need close monitoring; the worry is erosion of safety margins rather than immediate catastrophe.

Complexity of ATC Work and Pipeline Issues

  • Multiple controllers and others stress the cognitive complexity of ATC: real‑time mental simulation, second‑order thinking, and handling many simultaneous interactions.
  • Concerns that current hiring processes don’t adequately test for these traits, and that rigid assignment rules (limited, semi-random facility choices) and an upper hiring age limit further shrink the pool.
  • Some suggest tapping foreign or military-trained controllers with tailored retraining; this is raised but not explored in depth.

The Zizians and the rationalist death cult

Skepticism of “-isms” and Rationalist Identity

  • Several comments mock the idea of committing to any “-ism,” suggesting strong ideological labels tend to trap reasoning rather than improve it.
  • The name “rationalist” and “LessWrong” are seen by some as inherently smug, implying others are “irrational” or “more wrong,” though defenders say the label is meant as aspirational, not triumphalist.

What the Rationalist Scene Is Actually Like

  • Descriptions range from “completely normal nerds” to highly unusual: polyamory, group houses, intense AI-risk focus, altered social norms, drug use, and occasional scandals.
  • Many emphasize that most meetups are tame; the highly sexualized or cult-like subcultures are portrayed as outliers in specific hubs (e.g. Berkeley, NYC).
  • Some see rationalists as secular humanists who reinvented a quasi-religion: utilitarianism + AI-as-messiah.

Rationality vs. Rationalization

  • A recurring critique: the movement often practices “rationalizationism”—elaborate argument chains built on untested or fantastical premises.
  • Commenters stress that logic is only as good as its starting axioms and empirical grounding; without that, one can “prove” torture is optimal or justify almost anything.
  • Utilitarian consequentialism and longtermism are singled out as especially prone to justifying extreme harms for speculative future benefits.

Cult Dynamics, Zizians, and California Context

  • Many see the Zizian cult as another iteration of long-standing California mixtures of tech, self-improvement, New Age spirituality, psychedelics, and communal living, where cults periodically emerge.
  • Some argue the murders are best explained by generic cult patterns (charismatic manipulators, sleep deprivation, mental illness) rather than Bayesian math or LessWrong memes.
  • Others insist there is a pipeline: vulnerable, high-IQ misfits + psychedelic use + grandiose utilitarian frames → susceptibility to extreme groups like Zizians.
  • Defenders note Zizians were eventually banned and denounced by rationalist institutions, and that they are at best tangentially related.

Morality, Evil, and “Common Sense”

  • Several draw a line from abstract, high-stakes utilitarian thought experiments (e.g. “torture vs dust specks”) to real-world willingness to rationalize fraud (FTX) or violence.
  • There’s repeated emphasis that “rationality without morality” or without a “that sounds nuts” common-sense filter is dangerous.
  • Some commenters come to appreciate older moral traditions (Stoicism, long-lived religions) as stabilizing counterweights to rapidly improvised new ideologies.

AI Safety, Influence, and Impact

  • The movement’s long focus on AI safety is judged by some as largely ineffective compared to the actual trajectory of modern AI; others argue it has shaped techniques like reinforcement learning from AI feedback.
  • Critics worry that rationalist/EA memes (longtermism, doomerism) now inform extremely wealthy tech elites and policy discussions, magnifying the risks of any underlying moral or epistemic errors.

CDC data are disappearing

Scope and Targets of the Data Removals

  • Many commenters see the CDC takedowns as part of a broader “war on science” and independent institutions (science, academia, media), aimed at controlling narratives and ruling through fear.
  • Others frame it more bluntly as an attempted fascist or authoritarian takeover, with data deletion seen as laying groundwork for unaccountable power and future abuses.
  • A minority argue this is “just” compliance (or malicious over‑compliance) with the anti‑DEI executive order: scrubbing “gender”/LGBTQ terms and related content, not science itself. Critics counter that far more than DEI‑related pages are gone.

What’s Disappearing and Why It Matters

  • Reported removals go well beyond ideological flashpoints:
    • Vaccine‑specific ACIP recommendations, STI treatment and contraceptive guidelines, PrEP/HIV pages, domestic violence content, Long COVID survey pages, mask effectiveness studies, some HIV and general health info, and a pause in MMWR publication.
  • Commenters stress that while “grandma” doesn’t download CSVs, her doctors, hospitals, local health departments, and grant‑funded programs do; federal datasets drive planning for services like mammograms and disease screening.
  • Loss of official hosting undermines downstream research, health startups, and policy analysis; third‑party mirrors help technically skilled users but damage provenance and public trust.

Musk, DOGE, and Centralized Control

  • A large subthread links CDC actions to a wider pattern: Musk‑aligned personnel allegedly seizing or reshaping control of OPM, Treasury, NTSB, NASA data, and other federal systems.
  • Some fear a “blitzkrieg” to quickly capture digital infrastructure, purge civil servants, and possibly channel future government data and services through Musk’s platforms (e.g., x.com as a “super‑app”).

Legality, Records, and Enforcement Gaps

  • Several point to the OPEN Government Data Act and federal records laws: outright destruction or restricted access could be illegal and subject to NARA investigation.
  • Others respond that law is meaningless without enforcement: SCOTUS immunity for official acts, pardons, and partisan control of Congress make consequences unlikely.

Archiving and Resistance

  • Technically minded users highlight emergency archiving efforts (Internet Archive snapshots, full CDC dataset dumps, “Safeguarding Research,” DataHoarder, etc.) and argue that relying on federal hosting was a known fragility.
  • There is debate over responses: protests vs general strike vs civil disobedience vs resignation. Many express fatigue and pessimism, feeling previous efforts (elections, investigations, impeachment, mass protests) failed to prevent this moment.

Disagreement Over CDC and Media Framing

  • Some say the CDC had already damaged its credibility (e.g., COVID), so its dismantling is less tragic.
  • Others accuse the article and critics of exaggeration, insisting the data will return after language changes; skeptics point to the breadth and timing of removals and the simultaneous defunding and censorship moves as evidence this is not routine maintenance.

How to Run DeepSeek R1 671B Locally on a $2000 EPYC Server

Hardware setup & observed performance

  • Article’s build: single-socket EPYC with 512 GB DDR4, running DeepSeek-R1 671B Q4 via Ollama, reported at ~3.5–4.25 tokens/sec (TPS).
  • A dual-socket EPYC / 768 GB RAM setup (about $6k) reportedly runs the original Q8 model at ~6–8 TPS.
  • Users running extreme Unsloth quantizations (1.58–2 bit) from NVMe on much smaller consumer systems report ~0.11–0.16 TPS, confirming “model in RAM” is the dominant bottleneck.
  • Another home server with 2×3090 + 192 GB DDR5 gets ~4–5 TPS on the small dynamic-quant variant (4K context).
  • Power measurements from the article’s rig: ~60 W idle, ~260 W under load, lower than some commenters’ 1 kW assumptions.

Storage, memory bandwidth & RAID

  • Some suggest RAID0 across multiple NVMe drives to speed initial model load; with proper striping and IO alignment, >12 GB/s reads have been seen on similar platforms.
  • Others caution that naïve mdraid/ZFS setups can incur noticeable CPU and RAM overhead unless carefully tuned.
  • Discussion emphasizes memory channels and bandwidth over raw DDR speed; more channels often beat higher MHz.

Cost, efficiency & cloud vs local

  • Several calculations argue API access (~$2/MTok for R1-class models) is far cheaper than buying and powering a $2k+ box, unless utilization and/or electricity are very favorable.
  • Counterargument: privacy, policy constraints (no data off-prem), and general homelab utility (hosting many services) can justify the CapEx.
  • Some think local R1 at 3–4 TPS is already “usable” for non-interactive tasks; others consider anything <10 TPS impractical once the “thinking” phase is included.

Privacy, security & local vs cloud

  • Strong recurring theme: privacy is the primary reason to self-host, especially for proprietary code or customer data.
  • Skepticism that cloud contracts meaningfully protect against state-level surveillance; on-prem, even if poorly secured, at least requires more effort to access.
  • Local DeepSeek model itself is seen as safe; concerns apply mainly to using DeepSeek’s hosted service.

Quantization, MoE and model choices

  • Clarifications that the showcased build runs Q4 quantization, not full 8-bit; the Ollama 671B (~400 GB) is smaller than the ~700 GB Hugging Face weights.
  • MoE architecture (only ~37B active parameters per token) is what makes CPU inference at all feasible; a dense 671B would be far worse.
  • Many argue that, in practice, smaller 7–70B models (often on a single RTX 3090/4090 or M-series Mac) give far better speed/quality tradeoffs for most users.

Skepticism about the article & components

  • Some accuse the post of being “affiliate-linky,” with underpriced or mismatched parts (e.g., 8×32 GB kit linked while claiming 512 GB, EPYC prices off by ~2×).
  • Others defend it as genuine, useful content that happens to use affiliate links, but agree that RAM and CPU pricing/specs should be scrutinized.

How to turn off Apple Intelligence

Availability & Requirements

  • Several commenters report not seeing Apple Intelligence in settings; others explain it requires recent hardware (M‑series or A17 Pro) and specific OS versions.
  • Regional and language support is inconsistent: Macs in the EU can have it, but iPhones/iPads there generally can’t yet; some in Asia use it by setting system language to US English.
  • Some users can’t enable it due to language mismatches (e.g., “English (South Africa)” vs Siri language).

Storage Impact

  • Turning off Apple Intelligence on iPhone/Mac can free ~5–7 GB, which is significant on 64–128 GB devices.
  • One user notes disabling it on iPad still shows ~3 GB used and is unsure if iOS really reclaims this space on demand.

UX, Dark Patterns & Opt‑Out Pain

  • Multiple complaints that prompts to enable Apple Intelligence are pushy: dismissing notifications can open Settings and trigger downloads.
  • People dislike that iOS 18.3 re‑enabled features they had declined, and that related options (e.g., “Learn from this App”) must be toggled off per‑app.
  • Comparisons are made to long‑standing UX “metric juicing” and dark patterns (badges in Settings, default opt‑in, repeated nags).
  • Some say this erodes trust in updates; a few now avoid OS updates altogether.

Privacy & “Spyware” Concerns

  • Strong suspicion that local models and Private Cloud Compute enable extensive device‑wide analysis, with only Apple’s assurances preventing abuse.
  • Some point to on‑device photo analysis and older Siri/Spotlight “learning” features as precedent for cross‑app data indexing.
  • Others push back that models are mostly local and cloud calls are claimed to be non‑stored, but critics still worry about data leaving the device and future policy shifts.

Quality & Usefulness

  • Experiences with notification/message summaries are mixed: some find them almost always accurate, others say they’re often hilariously or dangerously wrong.
  • Many see little personal benefit from auto‑summaries or email “AI features,” and primarily want a more reliable, more capable Siri for simple commands.
  • Some argue Apple Intelligence is a crippled, slowly updated ChatGPT wrapper; others call Siri fundamentally weak compared with ChatGPT’s advanced voice mode or Google/Gemini experiments.

Third‑Party & Non‑Apple Alternatives

  • Desire for a way to replace Apple Intelligence with third‑party assistants via privileged APIs, but skepticism Apple would ever allow it.
  • An open source “Orange Intelligence” project is mentioned as a DIY alternative on Apple platforms.
  • Growing interest in escaping the ecosystem entirely: prepaid “burner” iPhones, flip phones, GrapheneOS, and Linux (laptops and even phones) are discussed, with debate over how usable modern Linux desktops really are.

Broader Sentiment About Apple & AI Push

  • Several see Apple’s aggressive “AI phone” rebranding and forced rollout as investor‑driven, not user‑driven.
  • There’s nostalgia for earlier Apple focus on polish and restraint; some feel recent software (App Store, News, AI) is trending toward ad‑like, spammy, and user‑hostile experiences.
  • A few defend Apple’s right to evolve the product, but many feel their agency over “my computer/phone” is being steadily eroded.

I spent five years building a webapp and got my first $1 (2022)

Overall reaction to the story and app

  • Many commenters find the long, solo effort inspiring and relatable, especially for people who love building large projects for their own sake.
  • Several praise the MIDI web app itself as “really good,” fast, simple, and approachable, especially compared with complex DAWs.
  • Some view it more as a learning/personal project than a serious business attempt, since there was no pricing and revenue came via GitHub Sponsors.

UI, design, and accessibility

  • Strong criticism of the extremely low-contrast light text on light background; multiple people call it nearly illegible and urge using default/darker text colors.
  • A short technical digression on contrast ratios and newer accessibility metrics (APCA) concludes that the current design is wildly unsuitable for body text.
  • Workarounds like reader mode or Dark Reader are mentioned as making the article readable.

Tech stack churn and “shiny object” syndrome

  • The repeated rewrites (CoffeeScript → ES6 → TypeScript, React → Riot → Material-UI → styled-components, etc.) are seen as a classic cautionary tale.
  • Some argue a “boring” stack like jQuery or PHP would have shipped sooner and focused effort on the product. Others note that a complex, stateful UI would be painful in jQuery alone.
  • Multiple comments say learning via rewrites is valuable, but extremely inefficient if the goal is to ship quickly.
  • One thread notes that LLM-based coding works better with older, stable APIs, giving another reason to avoid chasing the latest framework.

Product-market fit, MVP, and pivoting

  • Several people share stories of overbuilding, only to discover no product–market fit.
  • Strong advocacy for launching minimal versions, reducing features, and iterating based on real users rather than endlessly adding “one more feature.”
  • Clear distinction drawn between:
    • Adding features = refining the solution to the same core problem.
    • Pivoting = changing the core problem, target user, or fundamental approach.

Money, first dollar, and funding

  • Many relate to the emotional impact of the first $1–$5 earned; it’s described as uniquely validating.
  • Some share contrasting outcomes: from thousands in monthly revenue to six-figure losses over many years.
  • GitHub Sponsors is described as effectively non-viable for income; Patreon is seen as worse in some ways.
  • Discussion of how people afford long projects: usually via day jobs, freelancing, or prior savings, not large upfront capital.

Broader indie/web reflections

  • Comments lament web’s trend toward monopolization and ad spend dominance but also stress that bootstrapping small, niche tools is still viable.
  • Debate over “outdated” tech (PHP, jQuery, file-based routing) versus modern stacks; several argue that many community biases against older tools are shallow or inherited.
  • Some emphasize that it’s legitimate to build primarily for learning or personal satisfaction, even if the product never finds a market.

What we get wrong about athleticism

Appearance vs. Performance and the Role of Body Fat

  • Multiple comments echo the article’s point: elite performers in many sports (cycling, running, lifting) often look “normal,” not like fitness models.
  • Extra body fat is described as helpful for recovery, hormones, sleep, mood, and for surviving long competitions; cyclists in Grand Tours reportedly start slightly heavier and “diet” during the race.
  • Very low body fat is framed as anti-performance: lifters and strength athletes often bulk (higher body fat) to get stronger and only cut to look “shredded.”
  • Some NFL players are said to consciously maintain a fat layer as “padding” for injury prevention.

Bodybuilding, Strength, and Aesthetic Ideals

  • Strong distinction between training to look strong (bodybuilding) and training to be strong or perform (powerlifting, sport-specific training).
  • Debate over whether bodybuilding muscles are “just for show”: consensus is they’re extremely strong vs. general population, but suboptimal for maximal strength, agility, or endurance in competition contexts.
  • CrossFit athletes and decathletes are often nominated as closer to a “complete” or ideal athletic physique.

Hollywood, Signaling, and Cultural Body Standards

  • Many criticize Hollywood’s trend of giving even non-action characters steroid-level physiques, often historically or contextually implausible.
  • Extreme “movie muscles” are compared to a peacock’s tail: costly ornament that signals resources and discipline more than practical function.
  • Some argue most people don’t actually find extreme bodybuilder physiques attractive; the main audience is other bodybuilders and niche subcultures.

What Counts as ‘Athleticism’? Sport-Specific vs. General

  • Large subthread argues over whether an NFL quarterback is “one of the greatest athletes on earth.”
  • One side: success at the most competitive position in a high-talent league implies extreme athleticism.
  • Other side: compared to athletes in soccer, track, or endurance sports, such players may not be outliers in raw speed, endurance, or jumping ability.
  • Broader point: different sports optimize different traits (fine motor control, continuous running, explosive power, resilience to impact), so physiques and visible “fitness” vary.

Examples of Non‑Stereotypical Elite Bodies

  • Commenters list elite MMA fighters, NBA stars, rock climbers, and baseball players with soft or unimpressive-looking physiques who are nonetheless world-class.
  • One pushback claims these are rare exceptions and that in genuinely “physically difficult” sports (soccer, climbing, endurance), elite bodies almost always look extremely fit.

Quantifying Athleticism and Sex Differences

  • One commenter proposes numeric metrics (VO2max, run times, lifts, reps) as a clearer definition of athleticism.
  • Others criticize this as too narrow (no throwing, jumping, coordination) and note that at elite levels men outperform women across distances, though there’s argument about ultramarathon records and participation effects.

Health, PEDs, and Expectations

  • Several notes that peak athleticism can conflict with long-term health, especially in collision sports and extreme dieting/dehydration for aesthetics.
  • Personal anecdote highlights PED use and the for-profit nature of U.S. fitness/health culture.
  • Some lament that average standards are so low that modest muscle or leanness leads to immediate steroid accusations.

Hell is overconfident developers writing encryption code

Tone and framing of “hell”

  • Several commenters agree that writing crypto is dangerous for non-experts, but dislike framing “overconfident developers” as “hell”; they see it as demotivating rather than educational.
  • Others defend the frustrated tone as understandable given how often the same mistakes reoccur.

Why developers roll their own

  • Common complaint: experts are condescending, vague, or self-promotional (e.g., dropping a snarky GitHub issue plus a blog link but not explaining details).
  • Identifying real experts vs. “windbags” is perceived as hard and time‑consuming; hiring them is expensive and rarely budgeted.
  • Pressure to “ship yesterday” and security as a box‑ticking exercise pushes teams toward ad‑hoc solutions.

Using crypto correctly is hard

  • Even when using libraries, many devs struggle with low‑level, footgun‑heavy APIs (OpenSSL, Node’s crypto), and the difficulty of composing primitives into secure protocols.
  • Multiple people note you can misuse even high‑level libs like libsodium (bad keys, nonces, protocol design).
  • Core theme: most real vulnerabilities come from “joinery” and protocol design, not from the primitive itself.

Examples of bad crypto

  • Stories of partners reversing RSA public/private roles, limiting input to 8 bytes, or inventing bespoke XML “encryption” with hard‑coded, published RSA keys, often accepted because it “looks complex.”
  • Discussion of padding‑oracle risks and unauthenticated CBC; concern that maintainers sometimes dismiss warnings when they don’t see an immediate exploit path.

What “don’t roll your own crypto” means

  • One camp: it now effectively means “don’t do anything security‑related without experts,” which feels paralyzing.
  • Counterpoint: the original intent is narrower—don’t design your own schemes or compose primitives (AES, RSA, DH, etc.) into new protocols without expertise; using audited high‑level constructs (“boxes”, AEAD, KMS, Vault) is fine.
  • Debate about whether writing auth systems or password storage counts; consensus: primitives like salted SHA are out, password KDFs (bcrypt, scrypt, Argon2, PBKDF2) are table stakes, but full auth flows still have many pitfalls.

Tools, documentation, and responsibility

  • Strong calls to prefer opinionated, misuse‑resistant libraries (libsodium, Tink, age, sops, managed KMS/Vault) and to get external review for anything novel.
  • Several argue cryptographers have underdelivered on “easy‑to‑use, hard‑to‑misuse” tooling and accessible, centralized best‑practice documentation, contributing to developer mistakes.
  • Others counter that crypto’s inherent complexity and incomplete threat models can’t be solved by simple checklists; the realistic path is better tooling plus occasional expert consultation.

The government information crisis is bigger than you think it is

Digital government information and preservation

  • Commenters stress how easy it now is to “flick a switch” and remove or alter digital records, unlike the old FDLP print era where many libraries held immutable copies.
  • Several argue this makes government data uniquely vulnerable to partisan erasure and revisionism; one compares it to the Library of Alexandria vs. random clay receipts that survived.
  • There is debate over whether the Library of Congress could be a safe home for preservation: its leadership is appointed by the president, so some see it as politically exposed; others emphasize congressional oversight but admit norms are being stress‑tested.

Active removal of datasets and records

  • Multiple concrete takedowns are listed: USAID’s Development Experience Clearinghouse and portfolio system, CDC HIV pages, the CDC data directory, Youth Risk Behavior Surveillance, and various USAID/education/gender resources.
  • The DOJ’s removal of a public January 6th case database is highlighted as especially alarming, seen by some as “1984 in real time.”
  • People ask whether anyone is systematically tracking removals and archiving at‑risk sites; no comprehensive solution is identified.

Authoritarianism vs. “spending cuts” framing

  • One camp frames the wave of firings, website removals, and non‑enforcement of appropriations as part of an authoritarian project: purging watchdogs and law enforcement, racial scapegoating, mass deportations, and concentration‑camp‑like detention, all executed via the executive while Congress looks away.
  • Another camp calls this “hyperbole,” arguing that reducing bureaucracy and budgets is the opposite of classic authoritarian expansion of the state, and that entrenched agencies and interest groups will naturally scream in maximalist terms.
  • Counter‑arguments respond that the pattern of illegal or extralegal actions, disregard for the power of the purse, and efforts to control information distinguish this from ordinary “small government” politics.

Government size, debt, and the “sledgehammer”

  • Some express cautious hope that the current shock might expose waste; others think the chances are higher that it destroys critical capacity (science funding, health data, oversight) while barely affecting the deficit.
  • Data cited in‑thread show most federal spending is Social Security, Medicare/Medicaid, defense, and interest; slashing civilian agencies and information systems cannot realistically balance the budget.
  • Several warn that dismantling institutions and records for short‑term political or fiscal goals will create long‑term damage, especially by eroding transparency, accountability, and the historical record.

Hoppscotch: Open source alternative to Postman / Insomnia

Ecosystem churn: Postman → Insomnia → Bruno → …

  • Many commenters describe a recurring cycle: Postman became cloud‑first and bloated; Insomnia followed with accounts/telemetry; Bruno then positioned itself as the “fix,” and is now seen as heading down a similar path.
  • Some say “the industry has moved to Bruno,” but others push back, having never heard of it or finding it too buggy/unpolished in team use.
  • Yaak (by Insomnia’s creator) is repeatedly mentioned as a new offline‑first alternative.

Monetization, open core, and trust

  • Bruno and Hoppscotch are perceived as open‑core tools with expensive enterprise tiers; some believe they intentionally limit community features to protect paid offerings.
  • Bruno’s shift from “all free” to paid feature tiers upsets users who feel they were sold an anti‑enshittification story only to see the same pattern emerge. Others defend it as necessary to sustain development, emphasizing that the core remains open source and terminal/IDE workflows can replace paid GUI features.
  • A Hoppscotch PR adding OIDC was explicitly declined because that feature was reserved for the enterprise plan, viewed by some as “shady” and anti‑user.
  • One maintainer promises never to monetize their own client, with replies noting that only strong copyleft, no CLA, and broad contributors make such promises credible.

CLI vs GUI clients

  • Many prefer curl/Hurl/HTTPie CLI, or scripting via Python/Jupyter, citing simplicity, maturity, automation, and avoidance of heavy GUI dependencies.
  • Others argue GUI tools are invaluable for teams, complex payloads, multiple environments, auth flows, and easy onboarding.
  • File‑based approaches (Bruno collections, VS Code REST Client, JetBrains HTTP client, httpyac, Hurl) are praised for Git integration, transparency, and freedom from SaaS lock‑in.

Performance, Electron, and native/TUI options

  • Electron‑based clients (especially Postman) are criticized as bloated and sluggish; users with limited RAM feel real pain.
  • Some want lighter GUIs using native or slimmer toolkits (iced, slint, Qt/QML, Tauri, Wails) or TUI tools (Posting, Slumber).
  • There’s debate over whether demand and willingness to pay are sufficient to economically sustain a high‑quality, fully native cross‑platform client.

Falsehoods programmers believe about null pointers

Null pointers, offsets, and array indexing

  • Several comments expand on the idea that a crash address near zero (e.g., 0x420) often indicates a null base pointer plus a field offset in a struct or class; the offset can help locate the offending field.
  • There is debate over whether array indexing on a null pointer is meaningfully distinct: in C, p[n] is *(p + n), so doing pointer arithmetic on a null pointer is already undefined behavior, even if the computed address is non-zero.
  • Some low-level patterns (like unions of pointer-or-error codes, or large structs/arrays starting at address 0) can yield non-obvious offsets that complicate diagnosing null-related crashes.

Undefined behavior and compiler behavior

  • Multiple participants emphasize that dereferencing a null pointer is undefined behavior in C/C++, and that trying to be “clever” about what actually happens is dangerous.
  • Historically, compilers mostly treated UB as “will probably just access address 0”, but modern optimizers aggressively exploit UB, leading to reordering, dead-code elimination, or “time travel”-like effects.
  • There’s disagreement on how much programmers should care about the standard: some prioritize strict conformance to keep future compilers predictable; others focus on testing against specific compilers/platforms and writing straightforward code.
  • Discussion dives into whether “undefined” means “defined somewhere else”; several commenters push back strongly, clarifying that UB is intentionally unspecified and may vary across compilers, versions, flags, and hardware.

C as a “high-level” language and alternatives

  • Some argue C is more of a high-level “abstract machine” language than people admit, making it ill-suited as a simple “portable assembler.”
  • Others note C++ is slowly fixing longstanding portability issues (e.g., mandating two’s-complement integers, proposed fixed 8-bit bytes) but becomes too complex for small systems.
  • There’s a lively Rust/Zig vs C thread: some see Rust/Zig as serious modern replacements; others argue they’re unavailable or impractical on many targets, or unsuitable for certain low-level tasks (e.g., complex garbage collectors).

Signals/exceptions vs explicit null checks

  • The article’s suggestion of “ask for forgiveness” (rely on faults/signals instead of null checks) is widely criticized for C/C++:
    • SIGSEGV cannot reliably distinguish null dereferences from other memory faults.
    • It depends on UB (null address unmapped), may create fragile signal handlers, and can interact badly with optimizations.
  • Some note that, in managed languages with JITs, omitting explicit null checks and relying on hardware traps can be a real optimization on hot paths, but the thrown exceptions themselves are very slow.
  • Others argue a single null check is trivial for CPUs and easily predicted, so the practical win is dubious without hard data.

Embedded, OS behavior, and hardware details

  • Several comments highlight that address 0 may be valid on some embedded platforms (RAM, flash, vector tables), so using NULL as “always invalid” is dangerous there unless the MPU is configured to trap it.
  • There’s clarification that in the C standard, a null pointer is guaranteed not to compare equal to any valid object/function pointer, even on systems where address 0 is usable memory.
  • Claims that Windows “always” turns null dereferences into access violations are refuted with references to counterexamples and subtle behaviors.

Usefulness and genre of the article

  • Some readers like the historical and low-level detail; others find it trivia-heavy and misleading for average programmers, who should simply treat null dereference as UB and never rely on observed behavior.
  • There’s criticism that the piece misuses the “falsehoods programmers believe” genre, which traditionally targets real-world assumptions that break user-facing software (e.g., names, time zones), rather than niche language-lawyer corner cases.

Why Tracebit is written in C#

Overall sentiment about C# / .NET

  • Many commenters describe C# as a “solid 3–4/4 at everything”: productive, ergonomic, safe enough, and with good performance; not always “best” but extremely well-rounded.
  • Several say it’s the language they keep coming back to for backend work; words like “cozy”, “comfortable jumper”, “hard to rage-quit” recur.
  • Others think the article reads more like post‑hoc justification for a language the team already liked; all listed advantages could apply to other ecosystems too.

Language evolution and features

  • Strong praise for how much C# has evolved (records, pattern matching, async/await, spans, NativeAOT, intrinsics, nullable ref types, generic math, improved lambdas).
  • Comparisons to TypeScript are frequent; both share a designer and many constructs. Some note bidirectional influence between C# and JS/TS.
  • Some worry about “constant expansion”: large syntax surface, many ways to do the same thing, and new code looking alien to C# 2.0-era developers.
  • Others counter that most changes are syntactic sugar, backward compatible, and quickly pay off in reduced boilerplate if teams agree on style.

Productivity, tooling, and “batteries included”

  • .NET is repeatedly praised for smooth setup and “batteries included” APIs: fewer third‑party dependencies than Node, Rust, or Python for common tasks.
  • Visual Studio / Rider are seen as exceptionally powerful; VS Code + language server is considered sufficient by many. Some reject the claim that a “big fat IDE” is required.
  • ORM experiences are mixed: Entity Framework Core is praised as productive and much improved, but misused ORMs (EF or Hibernate) can cause severe performance problems.

Performance and “systems” angle

  • Several argue .NET now has a very high performance ceiling, close to C/C++/Rust/Zig in hot paths when using structs, stackalloc, spans, intrinsics, and NativeAOT.
  • Debate over whether .NET’s control over memory is truly comparable to C; proponents demonstrate fixed-size buffers and stack allocation, critics highlight GC and lack of whole‑program manual allocation.
  • Comparisons with JVM: some claim CIL + reified generics give the CLR more low‑level optimization potential than JVM bytecode; others say real‑world gaps depend heavily on workload.
  • Versus Go: disagreements about goroutines vs async/await. Some prefer Go’s debugging and model, others note .NET tasks have lower overhead and more expressive composition.

Stability, codebase rot, and upgrades

  • Multiple people praise .NET projects for resisting “bit rot”: old code often builds and runs with modern SDKs; dotnet restore plus the right SDK usually suffices.
  • Counterpoint: ecosystem history includes many breaking platform shifts (.NET Framework ↔ Core, WebForms → MVC → ASP.NET Core, Silverlight, UWP, etc.).
  • Upgrading between recent .NET Core LTS versions is described as mostly easy, though third‑party dependency mismatches can still cause work. Migrating old ASP.NET Framework web apps to ASP.NET Core usually means a rewrite.

Web, desktop, and mobile

  • Modern ASP.NET Core (especially minimal APIs) is considered fast and productive by many, but one recurring complaint is naming chaos: many different “ASP.NET X” products over the years confuse newcomers and job seekers.
  • Microsoft’s GUI story is widely viewed as messy (WinForms, WPF, UWP, MAUI, Blazor variants). Third‑party Avalonia and MonoGame are frequently recommended for cross‑platform desktop/game UI.
  • Mobile/iOS/Android support (Xamarin/MAUI) is seen by some as underwhelming or uncertain, especially on macOS; others note .NET plus MonoGame/Avalonia can target many consoles and OSes.

Ecosystem, culture, and comparison with others

  • Several frame .NET and JVM as “adult-run” ecosystems: strong backward compatibility culture, large first‑party libraries, and better fit for long‑lived business systems than trendier stacks.
  • Others find Java’s library ecosystem more portable and mature; defenders say .NET’s library portability is similar and its FFI is much easier than JNI.
  • Go is favored by some for simple, data‑oriented code and infra-tool integration; critics argue Go’s limitations force awkward workarounds and that C# can be written in a similarly data‑oriented style.
  • Rust is acknowledged as better for tight resource control and safe concurrency; many still pick C# for faster feature delivery in typical SaaS backends.

OO vs data‑oriented / functional styles

  • A noticeable group dislikes GoF-style OO and sees Java/C# ecosystems as culturally attached to it, making such codebases unattractive to modern devs.
  • Others stress that modern C# is multiparadigm: you can use records, tuples, static modules, extension methods, and fairly functional patterns; F# is recommended for more “pure” functional/data‑oriented work.
  • F# itself is praised but seen as under-resourced and with weaker tooling/integration than C#, which hinders adoption despite strong language merits.

Security and trust concerns

  • One commenter questions C# for a security product: worries about GC pauses, powerful reflection/dynamic code, AMSI bypass techniques, and opaque runtime mutation.
  • Others respond that .NET’s ecosystem scores well on supply‑chain security metrics, NuGet has relatively few advisories, and Microsoft invests heavily in patching CVEs in first‑party libs.
  • Separate unease exists around Microsoft’s stewardship: past foundation drama, tooling regressions (debugger, live reload), and fear that competing OSS libraries get “crushed” when Microsoft ships alternatives or when maintainers change licenses under pressure. Some argue Azure incentives and “developers first” culture make a long‑term bait‑and‑switch unlikely.

Market perception and adoption

  • Several note that in B2B, Java and .NET quietly dominate; claiming C# for SaaS is more mainstream than contrarian.
  • At the same time, C# is underrepresented in “cool startup / FAANG” discourse, leading outsiders to underestimate its prevalence and the satisfaction of its user base.

Tesla Paid Zero Federal Income Tax in 2024, Despite $2.3B in Income

Moral and societal concerns

  • Many see a large, profitable company paying zero federal income tax as emblematic of a “rigged” system that erodes civic trust and makes compliant taxpayers feel like “losers.”
  • Others argue income tax itself isn’t inherently “the right thing” (noting the U.S. functioned with mostly tariffs/excise taxes pre‑1913) and say the real issue is the size/inefficiency of government spending, not low corporate tax.
  • Counterpoint: modern quality of life and infrastructure depend heavily on tax‑funded public investment; wanting to “go back to 1913” is dismissed as romanticizing the past.

How Tesla’s zero federal tax likely worked

  • Commenters summarize the mechanics as:
    • Carry‑forward of net operating losses from early unprofitable years.
    • Stock‑based compensation deductions and depreciation.
    • Accelerated depreciation of capital investments (timing shift: less tax now, more later).
    • Roughly $300M in U.S. tax credits tied to EV production and similar incentives.
  • Back‑of‑envelope calculations in the thread suggest these items can plausibly reduce a ~21% federal liability on $2.3B U.S. income to near zero, though some details remain unclear.
  • Others note Tesla still paid state and foreign income taxes, plus payroll and other non‑income taxes.

Reinvestment, jobs, and dependence on public infrastructure

  • One view: keeping earnings in the business (rather than taxed away) is better for growth, jobs, and the broader economy.
  • Multiple replies clarify that profits reported to shareholders are after normal operating and R&D costs; if everything were reinvested they wouldn’t show up as profit.
  • Skeptics also point to Tesla’s layoffs, use of H‑1B workers, and heavy reliance on public roads and infrastructure as reasons it should be contributing more in taxes.

Fairness: corporations vs individuals

  • A recurring complaint: corporations can deduct a wide range of costs (depreciation, many inputs to production) and sometimes wipe out taxable income, while individuals cannot similarly offset wages with the full costs of living/earning.
  • Others respond that individuals also receive extensive breaks (mortgage interest, employer‑healthcare exclusions, retirement accounts, credits, etc.) and that a large share of households already pay no net federal income tax, though they still pay payroll and sales taxes.
  • Tension remains: individuals rarely can get their entire income shielded year after year the way some large firms occasionally do.

Media framing and polarization

  • Several commenters criticize the article’s tone as activist rather than explanatory:
    • It allegedly assumes tax credits and accelerated depreciation are inherently illegitimate and labels ownership of productive assets as “hoarding wealth,” without arguing those premises.
  • Defenders say the outlet is openly ideological and that advocacy journalism aimed at corporate power is valuable, especially if the facts are correct.
  • There is broader debate over journalism’s relationship to the current administration and whether media outlets are in a “battle” with it or being attacked by it.

Government subsidies, politics, and Musk

  • Some argue Tesla and Musk were effectively “created” by Obama‑era loans, subsidies, and carbon/EV credits; without them Tesla might have failed around 2014.
  • Others counter that many legacy automakers and airlines received far larger bailouts; focusing only on Tesla is selective.
  • Musk’s political activity and closeness to the current administration lead some to suspect that future tax or regulatory changes may further favor Tesla, though this is speculative within the thread.
  • There is also frustration that while Tesla benefits from public support, its CEO campaigns aggressively in politics and allegedly “buys influence” instead of “paying taxes.”

Tax policy ideas and broader reform

  • One cluster of comments echoes economists who argue for eliminating corporate income tax entirely, on the theory that only people ultimately pay (via consumers, workers, or shareholders).
  • Others strongly reject that, noting corporations are legally distinct entities that hold and accumulate wealth and should be directly taxed.
  • A separate subthread promotes a “single tax” Land Value Tax (LVT) to replace income and other taxes, claiming it could fund the entire federal and state budget.
    • Critics worry this would crush farmers or displace low‑income homeowners in high‑value areas; supporters reply that LVT targets unimproved land value and would be heavier on under‑used, expensive land (e.g. McMansions, speculative holdings) and lighter on dense housing.
    • Disagreement persists over the distributional effects and practicality.

EV credits and climate goals

  • Some note a contradiction: many people who support EV tax credits then react with outrage when those credits significantly reduce a manufacturer’s tax bill.
  • There is confusion and debate over whether incentives should go to:
    • Consumers (per‑vehicle credits at purchase, to boost demand), or
    • Manufacturers (per‑unit or production credits, to anchor EV factories in the U.S.).
  • Commenters argue these structures create different incentives:
    • Credits tied to profits risk rewarding high‑margin vehicles more than high‑volume affordable ones.
    • Consumer credits may better push mass adoption, but non‑refundable credits in practice mainly help higher‑income buyers who owe enough tax.
  • Some worry that attacking EV credits now will be used politically to justify rolling them back, undermining climate goals.

Tesla’s size, profitability, and other context

  • Several commenters are surprised Tesla’s net income is only in the low single‑digit billions, especially compared to far more profitable firms like Meta or Toyota, given its market valuation and attention.
  • There is discussion that a notable slice of recent earnings came from revaluation of Bitcoin under new accounting rules, not core operations.
  • Some participants suggest looking at multi‑year averages of earnings and taxes rather than a single year, given the timing effects of depreciation and credits.

Musk aides lock government workers out of computer systems at US agency

Access to Government Systems and Data

  • Commenters highlight that locked-out systems include a massive HR database with SSNs, birthdays, addresses, performance data, and more.
  • Loss of civil servant access combined with unknown actions by outside aides is seen as creating serious cybersecurity, privacy, and oversight risks.
  • Several describe it as an “unprecedented, hostile, and possibly illegal” move against the civil service, with anecdotal reports of barricaded doors, mysterious servers, and senior staff being rapidly pushed out.
  • What Musk-aligned aides are actually doing with the data and systems is unclear, which is itself a central concern.

Coups, Kleptocracy, and Democratic Backsliding

  • Some frame this as an “auto‑coup” or soft coup: using formal authority plus private power to rapidly neutralize institutions without tanks in the streets.
  • Others argue “this isn’t a real coup” because there’s no military rounding up opposition; replies counter that coups don’t have to be military to be real.
  • Comparisons are made to other countries where governments quickly replace key staff based on loyalty, turning the state into a kleptocracy.
  • A linked far‑right “playbook” and prior “second American Revolution” rhetoric are cited as context for fears of deliberate dismantling of constitutional government.

Criminalizing Votes and the Tennessee Sanctuary Law

  • A side discussion focuses on a Tennessee law making it a felony for public officials to support or vote for “sanctuary” policies.
  • One side says sanctuary policies were already banned and this merely increases penalties.
  • Others argue the key change is criminalizing how elected officials vote or advocate, calling it a direct attack on First Amendment protections and a dangerous precedent that could be extended to other issues.

Billionaires, Musk, and Governance Style

  • Many argue Musk should have no governing role and that his rise to de facto high political power via money shows systemic failure.
  • Some see admiration for China’s ability to control people and businesses as motivating US oligarchic behavior.
  • Running the federal government like a Silicon Valley startup is widely mocked as reckless.
  • There is speculation (unclear, not evidenced) that system control could be used for DEI‑related purges.

Meta: HN, Flags, and Politics in Tech

  • Users complain the story is repeatedly flagged/killed because it mixes Musk, politics, and tech, despite being highly relevant to technology and governance.
  • Others (including moderation) say such threads rarely yield thoughtful discussion and that HN’s mandate is not general current affairs.
  • There is tension between users who see suppression of political tech stories as harmful and moderators/users who see aggressive flagging as necessary to preserve discussion quality.

Add "fucking" to your Google searches to neutralize AI summaries

Trick: Swearing to Disable Google AI Overviews

  • Adding “fucking” (or similar profanity) to queries often prevents Google’s AI overview from triggering.
  • Using it with a minus sign (e.g. -fuck, -fucking) or in a nonsense quoted phrase (e.g. -"fuck 5823532165") can suppress AI while minimizing impact on results.
  • Some note this also changes SafeSearch behavior, surfacing unrelated explicit content or hiding entire sites unless an explicit term is included.

Other Technical Workarounds

  • Appending &udm=14 to the search URL (or using udm14.com / tenbluelinks.org / “Web” tab) restores mostly plain “10 blue links” and removes AI and rich modules, but also hides useful infoboxes (weather, calculators, etc.).
  • Some use CSS/uBlock/AdGuard rules or browser extensions to hide AI overview blocks.
  • Adding -ai to queries can also suppress overviews, though it fails when “ai” is legitimately part of the search.
  • Verbatim mode (tbs=li:1) and site-specific operators sometimes help but are reported as increasingly unreliable.

Degradation of Search and E‑commerce Search

  • Many describe Google as ignoring quotes, - exclusions, and other Boolean tools, making precise search difficult.
  • Similar complaints target Amazon: it rewrites queries, ignores negative filters, and pushes ad-optimized results, making it hard to find items without common attributes (“non-latex”, “not dimmable”, etc.).
  • Some resort to custom Google site-search for Amazon, or alternative search engines (Kagi, Yandex, DDG).

Mixed Views on AI Summaries

  • Critics: summaries are often confidently wrong, obscure original sources, and reduce incentives to publish. Some call them “stolen” from publishers.
  • Supporters: find them fast and usually accurate “good enough” overviews, with visible source links they click when information matters.
  • Confusion exists about disabling them: Google’s own text says they can’t be fully turned off, only reduced via Labs/settings or workarounds.

Desire for “No AI” Modes Across Services

  • Multiple commenters say they’d pay for a “No AI” toggle in search, productivity tools, Gmail, Spotify, Instagram, and others.
  • Complaints extend to recommendation systems (e.g., Spotify’s sticky taste profile, removed “dislike” buttons; image search polluted with low‑quality AI art).

Corporate Incentives and AI Hype

  • Many see AI push as driven by KPIs, ad revenue, and hopes of reducing labor costs, not user demand.
  • Others argue AI is already highly valuable for many users, with large spend and strong adoption, even if visible consumer features (like Google’s overviews) are unpopular.
  • There’s debate over whether this is a normal hype cycle or a deeper “enshittification” of core tools.

Broader Cultural Notes

  • Profanity is seen as both a cathartic protest and an emerging “human signal” to distinguish text from AI.
  • Underlying sentiment: frustration that users must develop hacks and extensions just to get simple, accurate search results again.