Hacker News, Distilled

Reliability of the stats

• Several commenters distrust StatCounter: methodology is opaque, sample may be skewed, and past numbers (e.g., sudden Windows 8.1 spike) looked implausible.
• OS detection via user‑agent is error‑prone:
  • Some Chrome/ChromeOS UAs don’t include “Linux”; ChromeOS is sometimes treated separately.
  • Android or bots may be misclassified as desktop Linux.
  • “Unknown” is large and volatile.
• Others note that, even if the absolute levels are off, the long‑term trend (≈0.7% → 4.5% since 2009) suggests real growth.

Interpreting the growth

• Some argue share can rise even if absolute Linux users stay flat because many non‑technical users have moved to phones/tablets and use desktops less.
• Others think Windows 10/11’s direction (ads, telemetry, UI drift, hardware obsolescence, online‑account pressure) and high Mac prices are actively pushing power users toward Linux.
• ChromeOS and WSL blur the line: some say ChromeOS “counts” as Linux; others insist it’s just “Linux kernel + browser,” unlike a full GNU/Linux desktop.

Experiences switching to Linux

• Many report successful long‑term daily use (often Fedora, Mint, Pop!_OS, Manjaro/Arch):
  • Old hardware runs fast and remains usable.
  • Most web, dev, and many gaming workloads “just work,” sometimes with less maintenance than Windows.
• Several non‑technical relatives reportedly cope fine when given a browser‑centric Linux desktop.

Persistent pain points and skepticism

• Hardware compatibility is inconsistent, especially laptops:
  • Certain webcams (MIPI/IPU6), Wi‑Fi chips, sleep/hibernate, fingerprint readers, LTE modems, HDMI 2.1, and new GPUs can be problematic.
  • Some say “Linux works if you avoid the wrong hardware”; others say they almost never check compatibility and are fine.
• Fractional/HiDPI scaling is a recurring complaint; KDE/Wayland users say it’s largely solved, others say it’s still far behind macOS/Windows.
• Professional tooling gaps remain: full MS Office, Adobe CC, many audio‑production stacks, and some game‑dev tools are missing or inferior; Office compatibility via LibreOffice is described as inadequate for many business users.
• Some find Linux desktops “80% there” or “cockpit‑like”—powerful but cognitively heavy and occasionally brittle—while Windows feels more appliance‑like despite its own registry hacks and cruft.

Distros, UX, and system models

• Mint, Pop!_OS, Ubuntu, Fedora, Manjaro/Arch, and KDE Plasma are most often recommended; there’s disagreement over whether Debian/Ubuntu‑family desktops are “rock solid” or “outdated garbage.”
• Atomic/rollback distros (Fedora Atomic, NixOS) are praised as a way to make Linux safer for non‑technical users by allowing easy reverts after bad updates.

Gaming and Steam Deck

• Steam Deck and Proton are widely credited with making Linux gaming viable: many Windows titles, including some with anti‑cheat, run well; not all AAA or highly modded setups do.
• AMD’s upstream GPU support is praised; Nvidia’s proprietary driver and Wayland history remain contentious.

Accident forgiveness behavior across clouds

• Many commenters report major cloud providers (AWS, GCP, etc.) routinely forgiving large accidental bills, especially for key leaks, runaway serverless, or student projects, often after the user explains and fixes the underlying issue (e.g., following security checklists).
• Others note highly publicized cases where forgiveness only came after social media backlash (e.g., large Netlify overage), or where large AWS bills tied to design mistakes weren’t forgiven.
• Some point out that forgiven cases are under‑reported (no blog post), so HN-visible incidents are not representative.
• Several note that providers also change products after high-profile incidents (e.g., new S3 error-code billing changes).

Should “accident forgiveness” be table stakes?

• Many view it as basic hygiene rather than a special perk; others argue that even if it “should be,” it’s still valuable when a provider explicitly commits to it.
• Debate over whether costs are “socialized”: some argue customers inevitably pay for others’ mistakes; others respond that transient excess usage often has near-zero marginal cost given existing overcapacity, so forgiving it is mostly goodwill.

Hard billing caps vs. forgiveness

• Large part of the thread: users—especially hobbyists and small/bootstrapped teams—strongly want hard or configurable spend caps, preferring outages to any chance of a life‑changing bill.
• Cloud-side arguments against caps:
  • Terminating service is often worse than a surprise bill for “serious” apps.
  • Billing systems are complex, distributed, and eventually consistent; using them in tight control loops is hard.
  • Unclear semantics: what exactly to shut off (compute vs. storage vs. backups), when to do it, and how to avoid data loss or unexpected critical outages.
  • Users misconfigure and forget caps; later outages at scale would generate their own outrage.
• Users propose alternatives: soft/hard thresholds, rate-based caps, alerts/webhooks, partial throttling, or explicit “insurance-like” add-ons. Some smaller platforms have begun offering spend limits.

Cloud pricing complexity and alternatives

• Complaints that cloud pricing is opaque, with “black box” adjustments and high egress costs that lock customers in.
• Some advocate cloud-agnostic setups with Kubernetes and open-standard services, or simply using fixed-price VPS/bare metal (Hetzner, Linode, Ionos, etc.) where bills are predictable and bandwidth is cheap.

Perception of Fly.io

• Commenters generally appreciate Fly’s “human” tone, transparency, and willingness to forgive accidents, but criticize the lack of caps for small users and some documentation confusion around default offerings.
• Fly representatives stress focus on professional customers, investment in better anomaly detection and line‑item vetoes, and skepticism toward hard caps, while acknowledging strong user demand and leaving the door slightly open.

Announcement & access model

• Midjourney’s web interface is now open with temporary free trials; some users find onboarding much easier than the old Discord-only flow.
• Others say the “web experience” is still confusing or nonfunctional (e.g., disabled prompt box, unclear subscription flow).
• Access still requires Google or Discord sign-in, contradicting some users’ expectation of “open to everyone.”

Discord-first strategy & UX

• Several commenters see the Discord era as clever: free UX, hosting/CDN for images, built-in community, and “live” user support by watching public channels.
• Public channels acted as continuous product demos and tutorials; some argue going web-first would have been a mistake.
• Others found Discord itself a deal-breaker or too chaotic to navigate.

Authentication & privacy concerns

• Major thread on dislike of mandatory Google/Discord OAuth and phone-number requirements.
• Critics worry about centralization of identity, cross-service policy lockouts, and privacy of prompts and account data.
• Defenders argue OAuth reduces support burden, password reuse, and friction for most users; email/password is portrayed as operationally costly.
• Suggestions raised: passkeys, independent password managers, web3-style keys, but adoption and business models are seen as unclear.

Content restrictions and censorship

• Multiple reports that Midjourney blocks or flags prompts about political leaders (e.g., Xi Jinping) and even mild PG‑13 concepts like bathing suits.
• Some note heavy filtering around nudity and certain “bold” language; others question whether this is more restrictive than large competitors.
• Debate over broader trend: newer models (Midjourney, SD post‑1.5, Ideogram 2.0) seen as more censored and sometimes worse at anatomy.

Comparisons with Flux, DALL‑E, SD, Ideogram

• Many say they’ve shifted to Flux, praising its openness, prompt adherence, and realism; SD community reportedly moving that way.
• DALL‑E 3 is credited with superior prompt adherence but criticized for a tacky, “bootleg” aesthetic.
• Ideogram 2.0 is viewed by some as a downgrade from 1.0, especially for anatomy.
• Several links and tips discuss running Flux locally or via various hosted services.

Capabilities, use cases & impressions

• Users praise Midjourney’s quality, especially for fantasy art; one D&D example required far fewer prompt tweaks than other tools.
• Others complain about failure on specific sci‑fi concepts (e.g., O’Neill cylinders, rotating habitats), though some show improved results with careful prompting.
• Prompt adherence is a recurring benchmark; some argue that detailed descriptions of unfamiliar or hybrid concepts are the real test, not simple tokens like “spork.”

Enterprise / business considerations

• Midjourney’s lack of organizational account management and multi-user controls makes it hard to adopt for company workshops or corporate use.
• Some observers are impressed that the company has grown with minimal funding and infrastructure by leveraging Discord and cloud storage.

Technical issues & misc. reactions

• Reports of sign-in errors (Google disallowed_useragent), storage/JavaScript issues in iOS Safari, and an Android device freezing on the splash screen.
• Debate about rate-limited free trials and cost of unrestricted access; some wish for pay-per-use instead of subscriptions.
• Philosophical split: some see these tools as democratizing “artistic skill,” others argue creativity was always accessible and AI is just rearranging pixels.

What “blocking” means here

• Major subthread on terminology: some equate “blocking” with any synchronous operation; others reserve it for when a thread is descheduled (e.g., waiting on I/O or kernel events).
• In async/cooperative runtimes, “blocking” is mainly about when control returns to the executor; a memory access that may trigger disk I/O is problematic if it cannot yield.
• There’s confusion when people call all memory reads “blocking”; others argue that cached reads are synchronous but not meaningfully “blocking” for async design.

mmap and async runtimes

• mmap makes file data look like memory, but page faults can take disk‑like latency while being invisible to the async scheduler.
• With cooperative scheduling, a page fault can stall the whole executor thread even though the kernel only blocks the faulting OS thread.
• This is framed by some as a limitation of mmap, by others as a fundamental tradeoff of cooperative user‑space scheduling.
• Some suggest OS or language features (userfaultfd, async “prefetch” or async memcpy, madvise/io_uring patterns) to separate “schedule I/O” from “consume data,” but these are nontrivial.

Performance characteristics & tuning

• mmap is powerful but has a wide gap between best and worst case; this complicates benchmarking and tail‑latency control.
• Sequential preloading or MAP_POPULATE, MADV_* hints, and mlock/MAP_LOCKED can help, but are not guarantees.
• Random access patterns could yield even worse behavior than shown in the article.
• For some workloads (e.g., preloading at startup when memory is ample), mmap can be effectively non‑blocking in practice.

Error handling and reliability

• mmap can turn latent I/O or media errors into SIGBUS at arbitrary code locations, not just explicit read/write calls.
• On POSIX, SIGBUS is the main failure mode; comparison is drawn with -EIO/-ENOMEM from syscalls.
• Debate over practicality: some say most programs would treat either as fatal; others argue explicit errors from read/write are easier to contextualize and handle gracefully than signal‑based failures.

Threads vs async

• One camp sees this as an argument for “just use threads”: preemptive scheduling naturally hides page faults.
• Others counter that async brings substantial benefits for I/O‑bound servers and can be made resilient if runtimes detect blocked workers and inject more threads (examples discussed from other ecosystems).
• General advice: don’t casually mix mmap with cooperative async unless you understand the interaction; mmap is viewed as an expert‑level tool.

Overall reaction

• Many commenters find the antipatterns highly relatable and say they’ve seen most or all of them in real teams.
• Some note that good review cultures are rare; they’ve mostly seen either rubber-stamping or “death by a thousand cuts.”
• A few joke about training LLMs either to follow the antipatterns or to detect and correct them.

What code reviews are (and aren’t) for

• Several argue reviews should focus on design sanity, complexity, readability, and test coverage, not bug-hunting or manual QA.
• Others admit they rely on running the code or tests because “reading code is hard,” especially for high‑risk areas.
• Reviews are also framed as knowledge transfer, shared ownership, and backdoor prevention, not just defect finding.

Antipatterns in practice

• Repeated complaints about:
  • Nitpicking style, spelling, and trivial renames.
  • “Ransom note” behavior: blocking a focused PR on unrelated refactors or documentation overhauls.
  • Priority inversion: long lists of nits followed by a late “bombshell” design objection.
  • Silent or slow reviewers who intermittently respond just enough to keep PRs blocked.
  • Political or status games: using reviews to delay rivals or assert control.

Size, rigor, and context

• Disagreement over acceptable PR/commit size: some aim for 100–200 line changes; others have unavoidable multi‑thousand‑file refactors.
• Some suggest multi‑day, multi‑pass reviews for critical or embedded systems where updates are costly; others find that level of rigor excessive for typical software.
• Lack of design context, goals, and background is cited as a root cause of many conflicts and misunderstandings.

Tooling, nits, and automation

• Strong support for auto-formatters, linters, spell-checkers, and pre-commit hooks to eliminate style/format bikeshedding.
• Some teams consciously ignore minor style issues in reviews; others insist small problems are still worth fixing but should be automated where possible.

Culture, communication, and remedies

• Many point to culture and trust as the core issue, not individual pickiness.
• Suggested mitigations:
  • Distinguish blocking vs “nice-to-have” comments (e.g., conventional comment tags, “[nit]”, “[suggestion]”).
  • Allow reviewers to directly push trivial fixes.
  • Escalation or multiple reviewers when there’s disagreement.
  • Prefer questions and stated concerns over vague or loaded prompts.
  • Use synchronous discussions (chat/meeting/pairing) when async ping‑pong drags on.

Statistical Revisions and BLS Methodology

• Many comments note that large annual revisions to payroll data are routine and tied to reconciling survey-based monthly estimates with more accurate quarterly administrative data (QCEW).
• One quoted explanation from a BLS employee stresses the tradeoff between timeliness and accuracy, the “telephone game” nature of monthly estimates, and the existence of many internal checks.
• Others push back that a ~28–30% downward revision in job creation is unusually large (second-largest ever, per one comment) and undermines confidence, even if statistically explainable.

Conspiracy vs. Process Error

• A vocal subset sees the size and direction of revisions as evidence of political manipulation to make the economy look stronger, arguing that initial positive headlines stick while corrections are ignored.
• Critics of this view argue:
  • Revisions are an annual, well-known process.
  • Releasing worse numbers close to an election would be irrational if the goal were reelection.
  • Systemic biases can arise from procedures or incentives without a coordinated partisan plot.
• Some propose a middle ground: not overt “cooking,” but politically influenced prioritization and optimism in the methodology.

On-the-Ground Labor Market Conditions

• Several tech workers report long job searches, dried-up recruiter outreach, and layoffs of highly paid senior staff who can semi-retire on savings and severance.
• Others argue this is unrepresentative of median workers, who lack such financial cushions.
• There is concern about overproduction of developers, AI-induced disruption, fake job postings, and “zombie” job ads affecting perceptions and possibly data.

Participation, Wages, and Job Quality

• One line of discussion notes prime-age labor force participation near multi-decade highs, suggesting “almost dangerously over-employed.”
• Counterpoints emphasize:
  • Many people holding multiple low-wage jobs or dual-income households just to get by.
  • Rising debt, delinquencies, weak job satisfaction, and housing unaffordability as signs that headline employment masks distress.

Health and Disability (Long COVID)

• Long COVID is raised as a potential drag on labor supply, with references to data from the U.S. and Japan.
• Some insinuate people are “paid not to work,” but others respond that disability qualification is complex and burdensome, sharing experiences of intense scrutiny and bureaucracy.

Implications for Policy

• Several commenters think the revised data strengthens the case for imminent Federal Reserve rate cuts to protect a softening labor market, despite still-positive net job growth.

Private Attribution feature & disabling it

• Firefox added a “privacy-preserving attribution” experiment (dom.private-attribution.submission.enabled) for ad conversion measurement.
• Some users found it already disabled; others had it enabled even with strict privacy settings.
• It can be turned off via:
  • about:preferences#privacy checkbox (“Allow websites to perform privacy-preserving ad measurement”).
  • about:config or adding user_pref("dom.private-attribution.submission.enabled", false); to user.js.
• On Android, it can be changed in Nightly via about:config, or via chrome://geckoview/content/config.xhtml in some builds; recent versions reportedly have it off by default.

curl | sh backlash

• Many criticize the campaign’s suggested curl https://make-firefox-private-again.com | sh as unsafe and unnecessary for a single preference change.
• Even with visible script content, people warn that the fetched code could differ from what’s displayed.
• Several argue that screenshot/GUI instructions are safer and more inclusive.

Views on Mozilla’s direction & funding

• Strong disappointment that Mozilla is moving deeper into ad-tech (e.g., attribution, acquisition of an ad-related company).
• Some see this as a conflict of interest that may eventually lead to Chrome-like restrictions on ad blockers or more tracking “anti-features.”
• Others argue that ad measurement is already pervasive; PPA is framed as a less-invasive alternative for non–ad-blocking users.
• A linked Mozilla explainer and blog post are referenced, but several commenters find the justification vague or “trust us”–based.

Advertising, tracking, and business models

• Widespread hostility to tracking; many also oppose advertising itself, even if “privacy-preserving.”
• Large debate over whether the web can sustainably move away from ads:
  • One side: without ads, much current content and platforms (e.g., YouTube-scale hosting, news sites) would vanish.
  • Other side: loss of ad-driven garbage and clickbait would be positive; more paywalls, donations, or hobbyist content would be acceptable.
• Multiple comments stress that ads are never truly “free”: users ultimately pay via higher prices and manipulation.

Alternatives & hardening

• Several people recommend Firefox forks and alternatives (LibreWolf, Pale Moon, Brave, ungoogled-chromium, WebKit-based browsers, Ladybird, Orion).
• Mixed views on these: some praise zero-telemetry defaults; others question security posture, feature gaps, or project governance.
• Arkenfox and Mozilla’s own privacy-tweaks pages are cited, but users warn these can break logins and session state.

Efficacy and “wonder drug” framing

• Many commenters describe GLP‑1 drugs (Ozempic/semaglutide, Mounjaro/Zepbound/tirzepatide) as the closest thing to a 21st‑century “wonder drug” for obesity and diabetes.
• Users report dramatic weight loss and much better blood‑sugar control where diet, exercise, and older drugs failed.
• Some see them as non‑surgical alternatives to bariatric procedures.

Mechanism: appetite, brain, and behavior

• Drugs are GLP‑1 (and in tirzepatide’s case, GLP‑1 + GIP) receptor agonists; they reduce appetite, slow gastric emptying, and blunt blood‑sugar spikes.
• Debate: are they “chemically induced intermittent fasting,” generic calorie restriction, or qualitatively different? Consensus: they enforce a calorie deficit mainly by reducing hunger and cravings.
• Some emphasize that hormones/biochemistry, not just “discipline,” underpin eating behavior.

Side effects and long‑term risks

• Commonly reported: GI issues (nausea), possible muscle and lean‑mass loss, potential bone‑density reduction, and retinal concerns in diabetics with rapidly improved glucose.
• One view: decades of GLP‑1 study suggest low overall risk; others insist “you don’t get something for nothing” and worry about yet‑unknown chronic effects.

Durability, regain, and treatment length

• Stopping often leads to return of appetite and weight regain, similar to other weight‑loss methods.
• Some see lifetime use as likely; others hope for “reset” of habits plus exercise (especially strength training) to maintain results.

Cost, patents, and systemic healthcare effects

• Current U.S. prices (~$10–12k/year) are seen as prohibitive; cheaper in some other countries and via compounding pharmacies.
• Discussion of patent timelines and expectation that generics will transform access.
• Unclear net impact on healthcare costs: fewer obesity/diabetes complications vs more people living long enough to incur other expensive conditions.
• Skepticism that U.S. insurance premiums will fall even if population health improves.

Obesity, responsibility, and food environment

• Strong disagreement over “just eat less and move more” vs acknowledging structural and psychological barriers (hyperpalatable food environment, stress, poverty).
• Several argue drugs are necessary to counteract an obesogenic system; others push for systemic fixes to food supply and policy akin to tobacco control.

Eligibility and anecdotes

• Non‑diabetics with obesity are using these drugs; many report unprecedented control over urges, while some still crave “bad” foods.
• Mixed views on using them for modest weight loss vs reserving for obesity and diabetes.

Expertise, discernment, and “hidden” quality

• Many comments resonate with the idea that non‑experts can’t see how bad (or good) something is until shown by an expert: riding tack, sewing, anatomy in images, piano tuning, audio mastering, construction, etc.
• Several note that you can often feel that something is off (muddy orchestra, slightly off piano, bad mix) without being able to localize the fault.
• Others argue discernment is more continuous and learnable than the article implies: intermediate users can often reliably tell “better vs worse” even if they can’t do the work themselves.

“Good enough” vs pursuit of excellence

• One camp: even if only a few notice, aiming beyond “pretty good” is the whole point of art and craft; losing right‑tail expertise makes the world subtly worse.
• Counter‑camp: resources are finite; for many domains (pianos, pipe organs, niche crafts) “good enough for most people” is rational, and perfectionism can be pedantic or elitist.
• Some suggest a hierarchy of awareness: from audience who notice nothing, to those who vaguely sense quality, to experts who can diagnose specifics.

AI, automation, and erosion of skills

• Several extend the argument to AI: “$2 app” or model that does a 95–98% job risks hollowing out human expertise across domains, not just arts but also engineering and safety‑critical fields.
• Others note this is an old pattern (Luddites, industrialization) but agree the speed and breadth of current automation are new.
• A minority view: AI could eventually surpass human discernment (e.g., tuning, materials), revealing that current experts are themselves limited.

Audio, video, and “quality” debates

• Long subthreads debate sampling rates, bitrates, lossy vs lossless audio, and streaming video compression.
• Consensus: for most listeners, high‑bitrate lossy vs lossless is barely distinguishable; mastering and playback chain matter far more.
• Yet many describe very real perceived differences in cars, headphones, streaming platforms, or “fake Atmos,” often tied to EQ, codecs, room tuning, or placebo—ambiguity is acknowledged.
• In video, people complain that streaming “4K” is visibly worse than Blu‑ray, but market incentives favor cheaper, compressed delivery.

Loss of craft and historical analogies

• Commenters cite lost or degraded crafts: Renaissance architectural details, old instrument making, Damascus steel, pipe organs, journalism ethics, pre‑MP3 audio culture.
• Some argue lost arts can be rediscovered; others counter that the social and economic conditions that produced them may not recur.
• There’s broad agreement that consumer tolerance for mediocre but cheap/convenient output drives much of this decline.

Garbage Collection vs Manual Memory Management

• Debate over GC: some see it as essential for complex, shared object graphs; others report spending more time fighting GC (tuning, disabling, pooling) than manual memory would have cost.
• Latency-sensitive domains (VR, games, trading) are cited as especially painful with GC pauses and unpredictable behavior; Unity’s GC is called out as particularly bad.
• Counterpoints: modern GCs (e.g., on the JVM) can be nearly pauseless for many workloads; GC problems are often intertwined with other language design choices (type system, JIT strategy, value types, forced heap allocation).
• Newer systems programmers increasingly prefer automatic resource management; others insist that for systems work, opaque runtimes and non-negotiable GCs are unacceptable.

mimalloc, Thread-Local Allocators, and Rust

• Core technical issue: mimalloc keeps freed memory tied to the allocating thread and reclaims it lazily. Cross-thread free patterns can look like leaks until the original thread allocates again or mi_collect is called.
• Rust’s mimalloc crate wires it in as the global allocator but doesn’t expose mi_collect; the lower-level libmimalloc-sys does.
• This is framed as a design tradeoff: per-thread optimization vs cross-thread behavior. It’s argued this could bite C/C++ too and is fundamentally an architectural problem.

Language and Allocator Design

• Critique that Rust and C++ hide allocation behind global allocators, discouraging explicit, domain-specific allocator thinking.
• Zig is praised for explicit allocator passing, trading convenience for control and predictability.
• Suggestions to design languages more around mmap/munmap and pages are met with skepticism; page sizes and concurrency concerns make higher-level allocators necessary.
• Embedded and high-performance contexts often avoid dynamic allocation entirely, using bump or arena allocators.

Debugging War Stories and Reliability

• Multiple anecdotes of long-running, hard-to-reproduce bugs: UI drag-and-drop issues, stale client state in localStorage, JIT miscompilations, uninitialized locals.
• Emphasis on reproducibility and the scientific method in debugging; warnings against declaring bugs “fixed” without reproduction.
• Some languages (e.g., D) choose default initialization of locals to avoid entire classes of memory bugs.

Other Side Topics

• Brief side debate on using floating point for money: some insist on integer cents; others use floats (even single-precision) for modeling/backtesting with controlled rounding.
• Observations that allocators and OS resource management (memory, filesystems, file descriptors) have GC-like aspects but important differences in visibility and control.

Modern presses and logistics

• Commenters link Tesla’s Giga Press as a “modern parallel,” but others stress it is not equivalent to a 50,000‑ton forging press (different process, scale, and materials).
• Discussion of post‑WWII dismantling of German presses highlights how hard it would be to disassemble, ship, and re‑assemble such equipment, especially if manuals or experts were lost in war.

Casting, forging, machining, and materials

• Casting is not inherently “low quality”; it has different trade‑offs: brittle, uneven microstructure, thermal‑shrinkage and precision issues, but enables complex shapes and efficient material use.
• Many parts are cast roughly to shape, then machined on critical surfaces; machining alone can be wasteful for complex geometry.
• “Cast iron” is a family of high‑carbon irons with graphite phases; properties depend heavily on alloy and treatment (e.g., ductile iron via Mg/Ce additions).
• Forging improves properties by deforming grains and can align them along stress paths; examples include connecting rods and wrenches.

Grain flow and strength: contested

• Several comments extol tailored grain direction and work hardening (e.g., wire drawing, forged I‑beams), claiming large strength/fatigue gains.
• Others with design experience say in many alloys and real designs, directional strength differences are modest, often overshadowed by manufacturing cost and later heat treatment that resets grains.
• Cited aerospace data show strong anisotropy for some extruded alloys but not others; consensus: effect is real, but highly alloy‑ and process‑dependent.

Extreme forming and joining techniques

• Explosive forming and explosion bonding are discussed as “press equivalents” for large or exotic parts (boat hulls, heat‑exchanger plates, bimetallic tube sheets).
• Welding very thick plate requires extensive beveling and many passes; alternatives include forge welding, hot riveting, and explosion welding.
• Electron‑beam welding in vacuum is highlighted as an advanced, high‑end production process, including for large nuclear components.

Nuclear vessels and strategic heavy presses

• North America lacks presses to make one‑piece PWR reactor vessels; current practice requires multi‑piece shells and critical welds, though new EB techniques may reduce schedule and anxiety over weld quality.
• Several commenters frame heavy presses as strategic assets akin to nuclear or aerospace infrastructure, lamenting missed investments (e.g., UK heavy press for reactors) and linking to broader debates about deindustrialization, CHIPS‑style subsidies, and whether markets alone would ever build such capability.

uv, Rye, and “one tool to win”

• Many welcome uv’s rapid progress and Rye’s role as a prototype feeding into it.
• Desire for a “one tool wins” experience similar to cargo is strong, especially to avoid time lost on venvs, PYTHONPATH, and monorepos.
• Some find migrating from poetry to uv harder than expected; others report seamless moves from pip-tools and praise uv’s speed and workspace support.
• There is confusion about whether Rye is effectively deprecated; consensus is “use uv” going forward.

Authority, PyPA, and standardization

• Several comments argue Python lacks a single endorsed, integrated tool like Rust’s cargo.
• PyPA is seen by some as technically valuable but politically messy, slow, or misprioritized; others note solid tools under its umbrella (e.g. pipx).
• Some think Python core/PSF endorsement (official tutorial recommending a tool) would matter more than PyPA’s.

Technical critiques of Python packaging

• Long, detailed criticism: wheel format discouraging precompiled bytecode; compilation at import time causing permission issues and workarounds; fragile dependency resolution rules (URLs as deps, auto-building sdists, version-mismatch risks); and an import system that can’t express package versions, forcing virtualenvs.
• Alternative designs are proposed (e.g., multiple versions coexisting in one install with metadata-driven resolution), but are hypothetical.

Performance and scale

• uv is credited with massive speedups in large projects (e.g., release process time dropping from hours to minutes).
• pip performance has reportedly improved significantly recently, but legacy design constraints and complex dependency graphs remain a drag.

Monorepos and dependency management

• Python monorepos are described as “hell”; people write custom plugins/scripts or eye uv workspaces and Bazel-style approaches.
• FAANG-style “one version of each dependency, vendored and maintained” is acknowledged as effective but labor-intensive and hard to replicate without large teams.

Governance, corporations, and VC

• Strong mistrust of VC-backed control over critical tooling (npm/Microsoft history cited).
• Some argue Python is already heavily influenced by large companies; others push back or see it as shared among multiple corporate and individual stakeholders.
• Forkability of uv is seen as both a safety valve and a potential source of future fragmentation.

Alternatives and deployment

• Nix (and sometimes Bazel/buck2) is proposed as a more general, language-agnostic answer, but others report poor real-world Python dependency experience.
• For CUDA/JAX and conda-based workflows, uv is seen as insufficient; pixi/mamba are suggested instead.
• Several participants say their real pain is not package management but building self-contained, shippable executables; uv/related work may help but doesn’t fully solve this yet.

Side projects turning into unwanted jobs

• Many relate to building a “fun” side project that slowly morphs into a draining second job: constant support, on‑call incidents, and pressure that far exceed the revenue.
• Several describe eventually shutting projects down, selling them for little, or freezing them at “maintenance only” once the excitement fades.
• A recurring theme: the engineering part is the minority of running a business; the rest is support, billing, disputes, compliance, and admin.

Customer support burden & user behavior

• Support is described as mentally exhausting: repetitive basic questions, users not reading instructions, entitlement, and being ghosted after long, careful replies.
• Some see this as a sign they don’t actually enjoy customer-facing work; others emphasize it’s normal and must be managed, not taken personally.
• There’s consensus that a small minority of users generate most of the pain, and that free or very cheap users are often the worst.

AI, automation, and self‑service

• Many advocate automating everything possible once the core product is stable: onboarding, trials, refunds, common support flows, and routing.
• Opinions on AI chatbots are split:
  • Critics say most bots are useless FAQ-wrappers that block access to humans and waste time.
  • Supporters report success with well‑scoped AI for trivial requests, triage, search, and preparing answers, as long as escalation to humans is easy.
• Several argue plain forms and good UX/docs often beat chatbots for well-defined workflows.

Pricing, “revenue/agony,” and customer quality

• Strong theme: raise prices and/or restrict purchases to filter out low‑quality or abusive customers; optimize for “revenue per agony,” not max revenue.
• Higher prices can reduce volume and fraud, but also increase expectations; the right balance is unclear and context‑dependent.
• Some suggest separating tiers: cheap, largely self‑serve plans vs. expensive plans with real support.

Fraud, chargebacks, and payment mechanics

• Chargebacks are widely viewed as brutal: processors levy fixed fees per dispute, and banks often side with cardholders even when evidence favors the merchant.
• This makes small-ticket, high-volume B2C especially fragile; a few bad actors can erase months of profit.
• Using a merchant of record (for VAT/sales tax and dispute handling) is seen as valuable by some, overkill by others.

Choosing markets and coping strategies

• Market choice matters: certain niches (trading, crypto, real estate, consumer apps) are perceived as attracting more fraud and difficult users than professional B2B.
• Common coping tactics:
  • Invest in clear docs and simple UX; link to docs instead of rewriting answers.
  • Develop a “polite but curt” support tone and clear expectations/SLA.
  • Aggressively refund and/or fire problematic customers.
  • Use VAs or staff as a buffer when revenue allows.
• Several conclude they now prefer hobbies or one‑off products with no ongoing support over SaaS‑style side businesses.

Project overview & excitement

• Thread is broadly enthusiastic about shadPS4 as a milestone for PS4 emulation, especially given Sony’s lack of a portable PS4 option and weak official backwards compatibility.
• Many see it as proof of how far hobbyist emulation can go without direct financial incentives.

PS4 architecture vs PCs / other consoles

• Several comments stress PS4 is x86 with a FreeBSD‑based OS and an AMD APU, making CPU-side emulation closer to running a “PC in a box.”
• Others highlight important differences: custom graphics APIs (Gnm/Gnmx), unified GDDR memory, console-specific GPU behavior, extra instructions, and PS4/PS5 custom hardware (e.g., decompression, storage).
• PS3 is widely regarded as much harder (Cell CPU translation, LLVM JIT), while PS5 is said to be quite different from PS4 despite both being x86.

Emulator type: compatibility layer vs hardware emulation

• Multiple posts describe most PS4 “emulators” as more like Wine: reimplement PS4 user-mode libraries, map syscalls, and translate PS4 shaders to SPIR‑V or similar.
• There is disagreement over labeling: some call shadPS4 an emulator, others insist it and similar projects are fundamentally compatibility layers, with only low‑level projects that virtualize PS4 hardware being “true emulators.”
• Shader translation is emphasized as a major job, since consoles ship precompiled shaders.

Performance expectations (PC & Steam Deck)

• Some are pessimistic about Steam Deck running “desired” PS4 titles at good FPS; others argue PS4 emulation should be far lighter than PS3 and will improve with time and hardware generations.
• On high‑end GPUs (e.g., RTX 4090), Bloodborne already hits very high FPS, though with incomplete/broken shading. One side expects 100+ FPS on mid‑tier PCs once matured; others caution performance will drop as accuracy improves.

Bloodborne and game preservation

• Bloodborne progress is a central hype driver: first character screen, then in‑game, now very high FPS in limited demos.
• Many express frustration that Sony has never released a 60fps/PC/remastered version, and see emulation as the only realistic path.
• Discussion touches on fan 60fps patches on hacked PS4/PS5 hardware and broader dissatisfaction with remasters vs faithful ports.

Learning emulation & resources

• Commenters recommend starting with very simple systems (CHIP‑8, Game Boy, NES) and share guides, books, and video series.
• High‑level explanation: emulate CPU, memory, I/O, and hardware mappings, or alternatively emulate system APIs and possibly JIT‑translate instructions.

Legality & “too soon” concern

• One comment claims PS4 is “too current” and predicts shutdown; others counter that emulators themselves are typically legal, with only game/BIOS distribution being the main legal issue.

Project scope and approvals

• Government approval currently covers only the Australian part: solar farm, inland HVDC to a “head-end,” and subsea cable out to the edge of Australia’s exclusive economic zone.
• The project envisions ~20 GWp of solar, ~36–42 GWh of storage, and a ~2 GW HVDC export link (about 1.75–2 GW to Singapore).
• There is discussion of also supplying Darwin and possibly other domestic loads, but demand near the site is small and remote.

Cable technology and materials

• Very long undersea links are technically feasible; this one (~4,200–4,300 km) would be far longer than existing cables but uses well-understood HVDC tech.
• Aluminum conductors are considered more likely than copper due to cost and availability; rough calculations suggest the metal requirement is a tiny fraction of global production.
• Losses over long HVDC lines are viewed as acceptable given high voltage and cheap solar; AC is rejected for such distances due to capacitive/inductive losses.

Economics and market logic

• Core business case: arbitrage between cheap outback solar and higher-priced Singapore electricity.
• Some argue it may be cheaper for each region to develop its own renewables plus storage (e.g., deserts near Europe, Indonesia’s own solar).
• Others note Singapore’s wealth, limited land, and desire for green supply make it a strong buyer, even if the project isn’t the absolute cheapest option.

Geopolitics and energy security

• Concerns that a 4,000+ km subsea cable is vulnerable in war or sabotage (submarines, dragged anchors).
• Counterpoint: Singapore already depends on imported fuels; if it were in a major conflict, loss of a cable would be just one of many problems.
• Rules reportedly cap any single import source to a fraction of Singapore’s total demand to limit dependency.

Alternative uses and opportunity costs

• Some argue Australia should prioritize cheap domestic power, onshore industry (e.g., aluminum smelting, green steel, data centers), and direct rooftop solar.
• Others see large-scale exports as a strategic “second round” of being an energy superpower, replacing coal exports with “frozen sunlight.”

Technical and implementation risks

• Comparisons to shorter undersea links (e.g., Basslink, Viking Link) raise worries about repair times, cost overruns, and maintenance.
• Skeptics doubt megaproject timelines and financing; proponents note private funding and see it as exactly the kind of bold green infrastructure needed.

LLMs vs. Semantic Web

• Many argue LLMs will make manual semantic markup redundant: they already do high‑accuracy extraction/categorization for many tasks and will get cheaper and better.
• Counterpoints:
  • LLMs “routinely get stuff wrong,” including catastrophic errors (e.g., mislabeling people as criminals).
  • Automation scales errors: even a 1% error rate can mean thousands of serious mistakes per day.
  • LLMs are opaque, non‑deterministic, and trained on SEO spam and blogspam, so they inherit those pathologies.
• Some see LLMs and semantic tech as complementary: LLMs can help build or fill out metadata and knowledge graphs; structured data and ontologies can ground and constrain LLMs (“neuro‑symbolic” approaches).

Incentives, Trust, and Business Case

• Key reason cited for “classic” Semantic Web failure: no business case for publishing rich open data. It reduces clicks and helps competitors and aggregators.
• Strong incentives exist to lie or game metadata (SEO), so publishers cannot be the sole source of semantic truth.
• Trust is unsolved: users need ways to judge reliability, provenance, and authority; simple vocabularies don’t address this.

Current Adoption and Practical Uses

• JSON‑LD + schema.org is widely deployed for SEO, rich Google results, and link previews; CMS plugins generate it automatically.
• Other formats appear in niches: RDF/XML in PDFs and archives, MARC/BibTeX in libraries, RSS/Atom, microformats, RDFa/Microdata.
• Semantic tech is reportedly used in enterprise/sector contexts (e.g., European electricity grids, procurement, enterprise knowledge graphs), often internally.

Gap from Original Semantic Web Vision

• Many see today’s usage (author/title/image/date for previews, basic structured data) as a drastic retreat from the original “Web‑scale queryable knowledge graph” dream.
• Lack of a “killer app” for ordinary users is emphasized; benefits mainly accrue to large platforms and scrapers.

Formats, Tooling, and Developer Experience

• JSON‑LD is seen as pragmatic for CMSes but aesthetically disliked (data in <script> blobs, duplication, namespaces).
• Microformats/RDFa embed semantics inline but are harder to maintain and poorly supported by tooling and browsers.
• Ontology work is considered cognitively heavy; global, static ontologies are viewed as unrealistic, and mapping between competing schemas is hard.

Search, Semantics, and User Control

• Pure keyword search is limited but transparent and user‑driven; semantic/ML search can obscure user intent and favor “average” interpretations.
• Some propose user‑controlled classifiers and knowledge graphs to mitigate the publisher vs. reader incentive misalignment.
• Overall, participants see the “semantic web” ideas as valuable, but adoption, incentives, and human–machine meaning gaps remain unresolved.

Overall sentiment

• Strongly negative overall. Many praise Sonos hardware performance and sound quality but describe the UX, app, setup, and networking as among the worst they’ve ever used.
• Several long‑time customers say this release turned them from brand loyalists into people who will never buy Sonos again.

Hardware vs. software

• Hardware is widely regarded as solid, good‑value, and capable of excellent sound.
• Software and UX are called opaque, fragile, and arbitrary. Non‑technical family members often refuse to use the app, relying on AirPlay instead.
• Some suspect Sonos is intentionally making systems complex/fragile, increasing sunk‑cost lock‑in once users finally get everything working.

New app and protocol stack

• Linked technical analysis: the old, robust UPnP/SOAP stack was replaced by mDNS + HTTP + WebSockets with Sonos’s cloud in the loop for third‑party services.
• Commenters say this rewrite is more fragile, heavier on older hardware, and far more dependent on cloud availability and latency, even for local actions.
• Many concrete bug reports: disappearing speakers/systems, toggles that don’t work or revert silently, “unregistered” devices with dead “Fix it” buttons, NFC pairing paths that hang, setup flows that never complete.
• Some invoke the classic advice against total rewrites and criticize shipping a forced upgrade without feature parity or a rollback path.

Networking and SonosNet problems

• Detailed reports describe SonosNet forming STP loops, tunneling over Wi‑Fi and Ethernet, congesting networks, and even taking entire Unifi deployments down.
• Best‑practice workarounds include wiring all speakers, isolating Sonos in its own VLAN/broadcast domain, and treating devices as “hostile guests.”
• Existence of official Unifi “how to survive Sonos” docs is cited as evidence of systemic networking flaws.

Accounts, cloud reliance, and data

• Many see mandatory accounts and cloud control as needless for speakers, comparing to Hue and other smart‑home gear that now require logins “for security.”
• Others argue that advanced features and remote access legitimately require accounts and think criticism is overblown.
• Broader frustration with post‑sale updates: seen as adding unwanted features, data collection, and bugs, not value.

Alternatives and coping strategies

• Several users abandon Sonos or vow to only buy “dumb” speakers plus swappable streamers (Wiim, Chromecast Audio, Squeezebox/LMS, Music Assistant, DIY Raspberry Pi setups).
• AirPlay 2 multi‑room, Bluetooth speakers + Spotify Connect dongles, and other open/home‑server solutions are favored to avoid lock‑in and future “enshittification.”

Definitions of “hacker” and ethos

• Many align on “insatiably curious” or “infinitely curious” as core, but note that curiosity alone is a “bookworm”; hacking also involves tinkering with rules, breaking/repurposing systems, and deeply understanding complex systems.
• Others prefer “technically creative” or “wants to understand how things work to manipulate them.”
• Several note that arguing about the definition is itself very “hacker.”
• Some stress that hacking goes beyond computers to social, financial, and biological systems.

Reception of the article and Phrack style

• A sizable group finds it engaging, well-written, even “manifesto-like,” especially past the initial “what is a hacker” section.
• Others experience the tone as edgy, self-important, or long‑winded; multiple people wanted a TL;DR and felt the intro was cringe or gatekeepy.
• Some see it as a modern, middle‑aged echo of classic hacker manifestos and consistent with Phrack’s traditional voice and layout, including the text/ASCII style.
• A few complain about mobile-unfriendly formatting but also find the plain-text aesthetic charming.

Hackers, capitalism, and financial systems

• Many like the framing of financial markets and startups as systems to analyze and exploit, not mysterious priesthoods.
• There’s agreement that understanding incentives (VC, middleware/EDR vendors, “checkbox” security) explains why bad products and obvious grifts get funded.
• Some strongly dislike the recommendation to “become the corporation,” seeing hacker culture as inherently anti‑authoritarian. Others argue that running ethical companies is how to scale impact and create good jobs.
• Several readers say the article helped connect their technical mindset with economic and market dynamics.

Pills, cynicism, and agency

• Multiple comments unpack “redpill” as disruptive truth and “blackpill” as truth plus hopelessness / learned helplessness.
• Some relate being “blackpilled” about startups: seeing pervasive incompetence and bullshit yet feeling too disillusioned to found something.
• Others push back, arguing this mindset is itself disempowering and that hackers should cultivate agency rather than doom.

Body hacking, estrogen, and inclusion

• The estrogen / estradiol example sparks a large subthread.
• One camp sees body modification and DIY access to hormones or reproductive meds as legitimate “hacking your own body” and navigating hostile medical/legal systems.
• Another camp is puzzled or hostile to its inclusion, preferring more traditional “Molotov / lockpick” imagery; this leads to arguments about trans issues, autism correlations, terminology (“biological male”), and accusations of bigotry.
• Some emphasize that accepting people who are different is central to hacker culture and that reproductive and gender‑affirming healthcare are more broadly useful than destructive hacks.

ZIRP, interest rates, and tech economy

• Many agree that zero/near‑zero interest rates fueled wasteful startups, lazy capital allocation, and a depressing era of scammy projects, though some credit ZIRP for enabling speculative engineering (e.g., big infrastructure projects) that later benefited the ecosystem.
• There’s extensive back‑and‑forth on whether low rates are choice vs macro inevitability, how much they drive bubbles, and how rate policy interacts with inequality, worker power, and government deficits.
• Opinions diverge on whether returning to very low rates would be dangerous or beneficial, but most think ZIRP had serious distortive side effects.

Community, careers, and impact

• Older participants reminisce about BBS/phone‑phreak eras and the feeling of belonging to a secret counterculture; some feel modern “hacking” has gone mainstream or become a pale imitation.
• Others share that they moved from youthful hacking into entrepreneurship, valuing creating good jobs, helping customers, and serving communities more than solo exploits.
• Some are skeptical of early‑stage startup work unless you’re a founder; others describe paths of saving money in big tech, then self‑funding profitable, value‑driven businesses.

Moral and political reactions

• Many commenters find the startup “disgusting” or “sad,” seeing it as normalizing cheaper mass killing and emblematic of tech’s drift from “don’t be evil” toward militarism.
• Others argue weapons development is morally necessary in a violent world; opposing weapons is called an incomplete or “faith-based” strategy that ignores ruthless actors.
• Some view YC’s involvement as reprehensible; others applaud YC for backing defense work and “supporting America” amid geopolitical tension.

Deterrence, self‑defense, and Ukraine/Taiwan

• Ukraine’s war shifts some previously anti‑military views: cheap drones and missiles are seen as essential for deterrence and for offsetting an enemy’s numerical advantage.
• Several argue credible military capability is required to prevent invasions (Ukraine, Taiwan, smaller countries vs Russia/China).
• Others warn that cheap, abundant weapons make escalation easier and lower the threshold for political leaders to choose force.

Proliferation, terrorism, and internal security

• Concerns that cartels or non‑state actors could eventually afford cruise‑missile‑like capabilities; others note they already could use autonomous RC aircraft as one‑way weapons.
• Ideas such as “personal Iron Dome” air defenses for wealthy communities are discussed, but seen as largely impractical or illegal under explosives and hazmat rules.

US, imperialism, and who the weapons serve

• One camp frames the US military as the main global bully whose weapons are used to dominate poorer countries and support client states.
• Another sees most of the world living under a US‑provided “umbrella of safety” and argues that potent US and allied forces have underpinned an unusually peaceful era.
• Debates extend to Iran, Iraq, Korea, and the USSR; causes of wars and regime‑change operations are contested.

Technology, cost, and swarming

• Discussion of propulsion: small turbojets vs piston engines, pulsejets, and trade‑offs in speed, detectability, range, and cost.
• Cheap, slower “suicide drones” vs faster jet missiles: quantity can overwhelm ship defenses, especially layered SAM/CIWS systems.
• Anti‑ship focus is defended as having relatively low collateral damage; critics note allies could still misuse such weapons against civilian targets.

Industrial base, China, and attrition

• Commenters stress modern peer war is about industrial output and attrition; reference to reported Chinese “gigafactory”‑scale missile component production.
• Some argue focusing on anti‑ship missiles is mis‑prioritized; the real deficit is long‑range munitions to strike land‑based systems in China.
• Doubts raised whether US startups can match Chinese scale, even if they innovate on unit cost.

Defense industry incentives and careers

• Multiple posts describe current defense procurement as bloated with middlemen, bespoke specs, slow timelines, and misaligned incentives to maximize billable work.
• Some propose that VC‑backed firms that self‑fund R&D then sell products might improve efficiency.
• Practical advice is shared on entering the sector as a developer: get relevant engineering background, security clearance, and join contractors or government programs.

Scope of the Ruling and Legal Reasoning

• Judge in Northern District of Texas struck down the FTC’s broad non‑compete ban, saying the FTC lacked statutory authority and that the rule was “arbitrary and capricious.”
• Some commenters who read the opinion say the judge reinterprets decades of FTC authority over “unfair methods of competition,” and discounts the agency’s extensive 500+ page justification.
• Others argue the ruling is unsurprising: employment contracts are traditionally state law, and only Congress (not an agency) should rewrite them at scale.

---

Chevron, Administrative Power, and Separation of Powers

• Many see this as an early consequence of the Supreme Court’s rollback of Chevron deference: courts now second‑guess agency interpretations instead of deferring to them.
• Pro‑agency commenters worry this will dismantle large parts of the regulatory state (consumer, labor, environmental protections).
• Critics of agencies counter that unelected regulators had effectively become “judge, jury, and executioner,” and that power should return to Congress and the courts, even if it causes upheaval.

---

Are Non‑Competes Ever Justified?

• Strong consensus in the thread that broad non‑competes are anti‑worker, anti‑competition, and mainly a wage‑suppression tool.
• Examples of abuse: fast‑food workers and 10‑year non‑competes for contractors.
• More limited uses get some sympathy:
  • “Garden leave” where employees are paid not to work for competitors.
  • High‑level executives or founders who voluntarily sell a time‑limited non‑compete for substantial compensation.
• Several argue NDAs, trade secret law, and patents already cover legitimate employer concerns.

---

Role of Congress vs. Agencies

• Many support banning non‑competes but think doing it via FTC rule was legally fragile and politically reversible; they want a federal statute instead.
• Others respond that Congress is too gridlocked, so agency action is often the only practical route.

---

State Experience and Federalism

• California’s long‑standing non‑compete ban is cited as evidence such bans are workable and pro‑innovation, though some note its state‑law origin is not directly controlling in federal court.
• Debate over whether federal bans would implicate the Commerce Clause or 10th Amendment is unresolved in the thread.

---

Practical Status and Next Steps

• For now, status quo remains: existing non‑competes are enforceable where state law allows.
• Most expect appeals; outcome at higher courts is seen as uncertain and highly dependent on the current Supreme Court’s broader project on administrative law.