Hacker News, Distilled

Function Calls, Locals, and Micro‑Optimizations

• Several comments benchmark global vs local references to min.
  • Binding local_min = min inside a function/loop often yields ~5–10% speedup because local lookups use a compact array instead of global dict lookups.
  • However, one counter‑benchmark showed a local alias being slightly slower, illustrating that results depend on exact code and version.
• Putting hot code in a function can roughly halve runtime vs running at module scope, again due to locals being faster than globals.
• Dynamic features (min being overridable, locals()/exec) constrain optimizations and can cause surprising behavior around local variable visibility.

Builtins, Loops, and Algorithm Choices

• Using min(heights) on a list is ~5x faster than manual while‑loops scanning for a minimum; for loops are faster than while, but still much slower than the builtin.
• Using min(a, b) inside a loop was ~3x slower than a simple if comparison.
• General advice: let optimized builtins and C‑backed libraries do the looping; avoid tight Python loops when possible.

CPython vs Other Runtimes and Languages

• CPython remains much slower than PHP, Go, and Java in simple loop benchmarks (often multiple‑x slower), while PyPy can be significantly faster than both CPython and PHP on the same code.
• Some argue this confirms Python should mainly be “glue” around fast C/Fortran/Rust code; others point out that for many apps, developer time and ecosystem outweigh raw speed.
• Rewriting Python prototypes in Rust/Go/Java often yields 10–20x speedups, but at higher implementation cost.

Interpreter Internals and Optimization Strategy

• Python 3.11+ executes many Python‑level calls entirely inside the bytecode interpreter loop (no C call), improving call performance.
• Discussion compares this to Lua and LuaJIT, which experiment with opposite strategies (using or avoiding C‑level calls) for performance.
• Superinstructions were mostly removed because they inhibited newer optimizations.

Ecosystem, Use Cases, and Tooling

• Python is defended as a high‑level DSL over fast native libraries, especially in ML/AI and scientific computing where SciPy, NumPy, and friends dominate.
• Alternatives like Go, Rust, Nim, Julia, Common Lisp, Fortran, and others are discussed; ecosystem maturity and hiring pool heavily favor Python.
• Heavy imports (NumPy, pandas, xgboost, etc.) can take seconds, which matters for many short‑lived processes but is a one‑time cost for long‑running workloads.

Meta‑Takeaways

• Participants stress benchmarking actual code rather than relying on old rules of thumb.
• Consensus: CPython deliberately trades speed for simplicity, flexibility, and C‑extension friendliness; performance work is welcome but won’t change that core trade‑off.

Culture and Management Problems

• Multiple ex-employees describe Intel as siloed, political, and toxic, with middle management focused on optics, stack‑ranking bullet points, and protecting fiefdoms rather than shipping reliable silicon.
• Decision‑making is seen as process‑driven instead of person‑accountable, encouraging risk‑aversion and slowing progress.
• Some argue that without deep cultural change, Intel’s talent and technology base will be squandered.

Product and Engineering Issues

• Many see Intel’s core problem as “bad or late products”: hot, inefficient laptop CPUs; lagging server chips; poor yields on new nodes.
• Intel’s long stagnation on 14nm and slow rollout of AVX‑512 and SIMD are cited as symptoms of deeper rot.
• Some praise historical bright spots like Intel SSDs and QuickSync, and say consumer CPUs still perform reasonably well.

Branding, Segmentation, and Customer Perception

• Several commenters criticize branding (Celeron, Ultrabook, GPU names) and feature‑fusing as long‑term brand destruction and waste.
• Others argue branding would be fine if the products were compelling; marketing cannot fix engineering gaps.
• There is debate on whether Intel should advertise to end users at all versus focusing purely on OEMs.

Competition: AMD, ARM, NVIDIA

• AMD is widely seen as having overtaken or matched Intel in performance and efficiency, especially in servers and gaming, though Intel still leads single‑thread in some views.
• Intel’s server share is maintained partly via heavy discounting, hurting margins.
• ARM’s value is framed as licensing and customization plus power‑efficient implementations, not magic in the ISA.
• Many view NVIDIA’s CUDA ecosystem as the de facto standard for AI, with Intel and AMD far behind.

GPUs, AI, and Software Ecosystem

• Opinions on Intel’s GPU efforts are split: some say Intel should exit GPUs entirely; others argue a third player is vital and note improving Arc drivers.
• Intel’s AI accelerators (e.g., Gaudi) are praised by some as technically strong yet commercially ignored.
• oneAPI/SYCL vs CUDA vs OpenCL sparks debate; several see CUDA lock‑in and weak non‑NVIDIA tooling as Intel’s biggest AI barrier, not hardware.

Foundry Strategy and Fabs

• Many think pivoting hard into foundry is Intel’s best remaining moat, but execution on new nodes (e.g., Intel 4/18A) and yields is doubted.
• Some suggest spinning off fabs, like AMD did, to focus each side and tap “strategic” subsidies; others argue it’s too late and would sacrifice Intel’s one structural advantage.

Laptops, Power, and Form Factors

• Long subthread on ultrabooks vs thicker laptops: some value thin/light and fanless designs; others prefer better keyboards, thermals, and ports.
• Windows laptop battery life and sleep behavior are heavily criticized; blame is shared among Microsoft, OEM bloatware, and Intel/AMD power states.

Strategic Misses and Innovator’s Dilemma

• Passing on early Apple iPhone SoCs and failing to crack smartphone ARM are cited as huge missed opportunities, though some argue margins were unattractive.
• The overall story is framed by several as a textbook “Innovator’s Dilemma”: x86/server cash cows delayed necessary bets, letting AMD, ARM, and NVIDIA build their own “castles” elsewhere.

Product scope & goals

• Stack Auth is pitched as an open‑source alternative to Auth0/Clerk focused on developer experience and deep integration with Next.js + Postgres.
• Goes beyond basic authentication: organizations/teams, RBAC/permissions, user dashboard, impersonation, email flows, and (soon) TOTP‑based 2FA/MFA.
• A setup wizard for Next.js generates pages, handlers, and config with a single command.

Comparisons to existing solutions

• Compared against Supabase Auth: Stack Auth claims broader feature set (authZ, orgs, impersonation, dashboards) and is building Postgres/Supabase connectors to combine with RLS.
• Versus Ory, Supertokens, Logto, Keycloak, FusionAuth, Zitadel, etc.: positioned as more “developer‑friendly,” less enterprise‑oriented, and more tightly integrated with specific frameworks.
• Multiple commenters note crowded competition; some doubt the differentiation is strong enough.
• Some ask for direct comparisons (including to keycloak, Zitadel, Propel Auth, Auth.js) and a clear feature matrix.

DX/UX & integrations

• Strong focus on Next.js (app router), with a dedicated SDK and components. REST API is framework‑agnostic; other stacks (Golang, Django, Rails, vanilla React, etc.) are planned but not yet first‑class.
• Some users had friction (npm dependency issues, OAuth redirect troubles); maintainers invite bug reports and plan more language examples.
• Components run on the app’s own domain rather than redirecting to a hosted login page, which some see as better UX but others argue trades off security vs. classic redirect‑based auth servers.

Licensing, hosting & business model

• Dual license: client libraries under MIT, server under AGPL. Some confusion about AGPL is clarified; it is still open source and does not force open‑sourcing the whole product.
• Monetization is via hosted SaaS and support; maintainers publicly commit to keeping core code open source and compare their model to Supabase.
• SAML and some enterprise‑style providers are implemented when paying customers request them, but contributions land in the OSS codebase.

Security & trust

• Commenters press for clear security policies, pen‑testing and architecture docs.
• Project adds a SECURITY.md and notes reliance on battle‑tested lower‑level auth libraries, but concerns remain about delegating auth to a young project.

General sentiment

• Many express enthusiasm, relief at an OSS Clerk‑like option, and frustration with Auth0/Clerk pricing and lock‑in.
• Others are skeptical about yet another auth platform, VC‑backed open source, and the complexity vs. rolling simpler in‑house auth.

Relationship to Existing Productivity Systems

• Several commenters map “quests” to GTD-style “projects” and longer-term “goals” to higher horizons / someday‑maybe lists.
• Some see the article’s method as a simpler, more tactical version of GTD, useful for actually moving items off backlog, especially for people who find GTD too heavy.
• Alternatives like Zen to Done, theme systems (e.g., annual “themes”), and habit frameworks (e.g., Atomic Habits, The Power of Habit) are mentioned as similar “systems vs goals” approaches.

Framing, Language, and Psychology

• Many argue that words matter: “quest” evokes adventure, adversity, personal growth, and makes setbacks feel expected rather than demoralizing.
• Others push back, citing skepticism about Sapir‑Whorf–style claims and “euphemism treadmill” effects; they doubt renaming alone changes behavior.
• A counter-argument is that even if population‑level effects are hard to prove, reframing can clearly help individuals; therapy, parenting, and everyday experience rely heavily on such reframes.

Process / Systems vs Outcomes / Goals

• Strong overlap with “systems over goals” and “process vs outcome”: quests emphasize who you’re becoming and what you do daily, not just the end state.
• Many examples (marathon training, car restoration, boatbuilding, martial arts) show success coming from enjoying or at least accepting the ongoing work, not fixating on the finish line.
• Others warn that pure process focus can lead to perfectionism, yak‑shaving, and never finishing; balance between process and concrete milestones is emphasized.

Gamification and Fun

• Framing chores and setbacks as “main quests” and “side quests” (inspired by Zelda, DnD, etc.) helps some reduce stress and stay engaged.
• Not everyone finds “quest” appealing; for some it connotes grinding or corporate gimmicks. The consensus: use whatever metaphor authentically sparks motivation.

Constraints, Privilege, and Feasibility

• Some push back on the idea that “aspirations make life spacious,” arguing many people have almost no slack time and that privilege and generational wealth heavily shape what’s possible.
• Others acknowledge structural limits but still see value in small, kaizen‑like steps and realistic “quests” within tight constraints.

Individual Differences and Mental Health

• ADHD and autism are frequently mentioned: complex systems like GTD can become their own distraction loops; simpler, emotionally engaging “quest” framing can help some people actually do things.
• Exercise, medication, accountability (including digital assistants), and social support are cited as important adjuncts to any system.

Critiques and Limitations

• Some readers find the piece mostly a relabeling with little concrete technique and note the author is also selling a course.
• Others say even a seemingly small linguistic shift (“quest” vs “goal”) produced a meaningful cognitive and emotional change for them.

Purpose and Motivation

• Project offers a minimal, open-source CUDA runtime that talks directly to Nvidia’s low-level RM (Resource Manager) interface via ioctls, bypassing the proprietary CUDA user-space stack.
• Goals cited:
  • Learn how the stack works and have a “simple, transparent” reference implementation.
  • Enable lighter, more debuggable environments and eventually help port CUDA-like APIs to other platforms (e.g., *BSD).
  • Challenge Nvidia’s dominance and licensing constraints, and provide an open stack for research and verification.

Technical Scope and Limitations

• Still very early; only a small fraction of the CUDA API is implemented. Several commenters say it must grow ~100× in coverage to be generally usable.
• It still requires Nvidia’s kernel driver (proprietary or the newer open modules). Firmware and GSP remain proprietary.
• CUDA binaries (ELF with SASS) are still needed; replacing ptxas (the proprietary PTX→SASS compiler) is described as “highly non-trivial” because Nvidia’s ISAs and latencies are undocumented and scheduling is complex.
• Some view it as a reference implementation for “run simple stuff” to separate driver vs. compiler vs. hardware bugs.

Legal, Licensing, and Trademark Issues

• Concern that using “CUDA” in the project name and API prefixes invites trademark trouble; discussion of likelihood-of-confusion tests and how far trademarks can reach across industries.
• Debate over whether this can be used to bypass Nvidia’s “no GeForce in datacenters” EULA clause by pairing consumer GPUs with the open kernel driver and AOT-compiled kernels. Applicability of overlapping Nvidia licenses is described as murky and potentially riskier for companies than individuals.

Alternatives and Broader Ecosystem

• Mention of related efforts: ZLUDA (CUDA on non-Nvidia hardware), tinygrad’s direct-ioctl runtimes for AMD and Nvidia, and other compiler stacks (Triton, Numba, Julia, JAX, etc.).
• Some argue Vulkan compute or OpenCL could have been the open standard, but Vulkan/SPIR-V semantics and tooling are seen as less suitable than CUDA, and OpenCL is viewed as effectively abandoned.

Debate Over Value

• Supporters: open stacks reduce lock-in, enable unsupported platforms, avoid vendor whims, and can be used even purely for testing correctness.
• Skeptics: as long as it only runs on Nvidia hardware and is incomplete, the practical benefit is limited; the real win would be a mature CUDA-like API on non-Nvidia GPUs.

RTO as Attrition Tool

• Many see mandated return-to-office (RTO) as a “silent layoff”: a way to cut headcount without severance, WARN notifications, or bad PR.
• RTO is described as targeting working parents, people with disabilities, and those with higher healthcare costs, while keeping the optics of “neutral” policy.
• Several note that the people most likely to quit are those with the best options and highest confidence in the market, not “dead weight,” so the company often loses strong performers.

Legal and Contract Issues

• Debate over whether RTO can be “constructive dismissal”:
  • One side: substantial change from remote to office (especially for hires made as remote) should qualify and at least protect unemployment claims.
  • Other side: office work is still the legal default; management can change strategy, and lawsuits are unlikely to succeed.
• Severance in the US is generally seen as discretionary; companies try to avoid “layoffs” in favor of performance-based firings or attrition.
• Some advice: insist on remote/hybrid terms in contracts if it matters.

Impact on Workers, Caregivers, and Diversity

• Commute is framed as an unpaid pay cut (time, transport, taxes, risk of accidents).
• RTO disproportionately harms caregivers (often mothers), those reliant on specific childcare/school locations, and immunocompromised workers still worried about Covid.
• Several argue RTO has undone years of diversity and “women in tech” efforts, revealing those initiatives as mostly symbolic when not backed by labor protections.

Productivity, Culture, and Management Motives

• Conflicting anecdotes:
  • Some say remote workers are less productive and contribute less to “culture,” making offshore hiring more attractive.
  • Others report equal or better productivity at home, fewer sick days, and note in-office distractions and meeting-room scarcity.
• Suggested motives beyond productivity: filling expensive long leases, supporting downtown businesses, anti-union tactics, and visible control over workers.

Stack Ranking and Performance Management

• Example of companies layering stack ranking on top of RTO to cull a fixed percentage annually via “underperformance” and PIPs, sidestepping classic layoff optics.
• Commenters highlight side effects: paranoia, backstabbing, hoarding knowledge, and “Hunger Games” dynamics that erode collaboration.

Worker Responses

• Common strategies: job-hunting while nominally complying, seeking fully remote employers, or pushing for explicit contract language.
• Some advocate noncompliance or unionization; others emphasize “vote with your feet” and reward remote-friendly companies.

Languages & tooling around Kubernetes

• For programmatic integration and controllers, Go is viewed as the de facto standard; Rust is mentioned as increasingly popular for operators.
• Many interactions are config‑centric: YAML manifests, Helm charts, Kustomize, and tools like Kyverno.
• Terraform and Pulumi are common for surrounding cloud infra; some use Terraform to drive Helm, though this can become unwieldy at scale.
• Alternative packaging/config tools (e.g., Timoni) are discussed but seen as less established.

Motivations for migrating from ECS to K8s

• Desire to reuse the broader CNCF ecosystem: Helm charts, etcd, and other “Kubernetes‑first” tools.
• Better support for stateful workloads (e.g., etcd) and storage primitives than ECS historically offered.
• Operational features: easier node cordoning/draining, pod rescheduling, health‑based restarts, and autoscaling (often via tools like KEDA).
• Platform standardization, better internal developer experience, and easier hiring on a widely known stack.
• Reduced perceived vendor lock‑in and potential for multi‑cloud / on‑prem and negotiation leverage with cloud providers.

Critiques of the rationale

• Several argue the ECS setup was simply mis‑designed: autoscaling, blue‑green deploys, and templates could have been built on ECS with less upheaval.
• Some see “we want Helm/etcd” as tool‑driven, not user‑ or business‑driven, with unclear ROI and large opportunity cost.
• Skepticism that multicloud or lock‑in mitigation actually yields measurable cost savings; data is rarely presented.
• Concern that migrations of this scale are often resume‑driven or fad‑driven “grand migrations.”

Helm, Terraform, and deployment patterns

• Helm is praised as the default distribution mechanism for many third‑party apps and for atomic rollbacks.
• Others strongly dislike Helm’s templated YAML, quoting maintainability, “indent hell,” and frequent need to fork charts.
• Terraform is seen as better for cloud infra than for K8s workloads due to state complexity and slow plans at scale.
• A common pattern: Terraform for cluster/infra, GitOps (ArgoCD/Flux) + Helm/Kustomize for app deployments.

Kubernetes vs ECS/Fargate and managed services

• Pro‑ECS/Fargate side: very low operational burden, good enough autoscaling, integrated ALB, CloudWatch, and no cluster upgrades; suits most “normal” apps and small teams.
• Pro‑K8s side: unified abstractions for discovery, scaling, rollouts, secrets/config, and storage across clouds and on‑prem; especially valuable with many services or hybrid/regulatory constraints.
• Some report K8s clusters (especially with many addons/operators) as fragile and upgrade‑heavy; others claim managed K8s (EKS/GKE/AKS) has become “not that hard” and is simpler than stitching bespoke tooling.

Complexity, overengineering, and scale

• Strong thread of frustration with industry‑wide complexity, microservice overuse, and HA “at any cost” without business justification.
• Others argue that once you need service discovery, autoscaling, HA, and multi‑team infrastructure, rolling your own on VMs/Ansible/Chef tends to be worse than K8s.
• Overall, consensus is split: K8s is powerful and appropriate for some orgs and products (Figma‑scale, multi‑tenant, on‑prem offerings), but easily overkill or a distraction for smaller, simpler systems.

Overall Reception and Use Cases

• Many are excited about the RP2350’s feature upgrades over RP2040: dual Cortex‑M33, dual RISC‑V cores, more RAM/flash options, extra GPIO, more PIO/DMA channels, secure boot, RNG, crypto accelerators, HSTX high‑speed serial.
• Consensus that Pico 2 remains a microcontroller board, not a desktop; unsuited to tasks like running Firefox or Vim as a primary dev machine. Full Raspberry Pi boards (Pi 4/5/400) are suggested for that, though some find even those slow for web development.
• PIO is highlighted as a major differentiator vs ESP32: programmable state machines offload tight‑timing I/O (VGA, PWM, custom protocols) from the CPU.

ARM + RISC‑V Dual Architecture

• Strong interest in how two architectures coexist. Clarified that both ARM and RISC‑V cores are present in silicon, selectable per core at boot via a register.
• Some surprise it didn’t increase die size measurably; explanation is that pad ring and layout constraints limited die shrink anyway.
• Debate on practicality of running one ARM and one RISC‑V core concurrently; use cases seen as unclear.

Connectivity and Comparison to ESP32

• Criticism that Pico 2 lacks onboard wireless and “isn’t competitive” with ESP32.
• Counterpoints: many embedded uses don’t need radios; a wireless Pico 2 W is announced for later; RP-series PIO and 5V‑tolerant I/O provide different strengths.
• Clarification that RP2040/RP2350 are MCUs; Pico W boards add a separate Wi‑Fi/BLE chip, unlike integrated ESP32.

USB, Power, and Battery Management

• Frustration over continued micro‑USB instead of USB‑C; defenders cite drop‑in form‑factor compatibility and existing cable stock.
• Technical discussion that proper USB‑C support needs CC resistors; cheap boards often omit them, causing C‑to‑C cable issues.
• On‑board switching regulator still needs external inductor/passives; only the controller is on-chip.

Memory, Displays, and Peripherals

• Enthusiasm that RP2350 supports external QSPI PSRAM with proper read/write mapping, unlike earlier “hacky” RAM extensions.
• Explanation that higher‑resolution TFTs need substantial RAM/bandwidth (e.g., for framebuffers and double buffering).
• HSTX block (8 high‑speed outputs) and higher PIO count viewed as useful for fast serial/video‑like interfaces.

Security and ADC Improvements

• Secure boot, encrypted boot, dual security contexts, and RNG/crypto are seen as enabling low‑cost secure enclaves or simple HSM‑like devices.
• ADC fixes remove known nonlinearity spikes; effective resolution is only slightly better (around +0.5 ENOB), which disappoints those hoping for a major ADC upgrade.

Environmental and “Board Hoarding” Discussion

• Several reflect on accumulating unused boards and e‑waste.
• One side argues personal Pi consumption is negligible vs larger impacts (kids, flying, cars); others say individual choices and reuse (donation, resale) still matter.
• Suggestions include donating old boards to makerspaces or selling on the used market; concern raised that secure‑boot locking could limit reuse if irreversible (status unclear).

Documentation and Datasheet Quality

• The RP2350 datasheet is widely praised as unusually clear, readable, and well‑structured, with good explanations of reset, power, and clocks.

Window management & tabbed stacking

• Noted feature: grouping multiple application windows into tabbed stacks at the WM/OS level rather than per‑app.
• Compared to existing stacking/tabbing in Pop!_OS’s current DE, KWin, i3, Fluxbox, BeOS, and Windows tools like FancyWM.
• Some see OS‑level handling of tabs, tiles, sidebars, and popups as a path to more consistent UX.
• Others worry about complexity and edge cases (e.g., IDE panels, spawned windows).

Goals, architecture, and differentiators

• Built as a new Rust‑based, Wayland‑native desktop environment, with heavy use of the iced GUI toolkit and a custom theme engine.
• Emphasis on modularity and branding so distros can create distinct looks/experiences without GNOME’s constraints.
• Integrated tiling and keyboard navigation are recurring selling points; several tiling‑WM users are interested if Cosmic can provide a “batteries‑included” DE with strong tiling.

Design, usability, and aesthetics

• Some praise the look and modern tech stack; others see “generic macOS/GNOME” styling with low contrast, heavy rounding, and large padding.
• Significant concern that buttons, scrollbars, and window focus are hard to see, echoing a broader trend of aesthetics over usability.
• Debate over the importance of “pixel‑perfect” design vs. accessibility, scaling, and reflowable layouts.
• Several commenters argue that good design requires specialized talent and that open‑source projects often lack sustained design leadership.

Comparison to other desktops & historical UIs

• Compared repeatedly to GNOME, KDE, MATE, XFCE; some claim existing DEs can already be configured to do most of what Cosmic shows.
• Some see it as “GNOME but more mac‑like”; others as “slightly restyled MATE,” a characterization others strongly dispute.
• References to historical UIs (BeOS, OS/2 Workplace Shell, classic Mac OS, ChromeOS) as examples of deeper or more daring UX ideas.

Installation & distro integration

• Installation guides exist for multiple distros, including Arch and NixOS; some report early experiments leading to black screens or fallbacks to existing DEs.
• Cosmic is positioned as a GNOME alternative, especially for distros wanting more customization without GNOME’s extension‑breakage issues.

Advanced workflow concepts

• One long subthread imagines “worksets” or contextual desktops: persistent, named collections of workspaces, apps, and layouts per activity (coding, research, kids, etc.), possibly shareable and syncable.
• KDE “Activities” is mentioned as conceptually similar, but no indication Cosmic currently provides this.

Overall sentiment

• Thread is mixed to negative on visuals but cautiously optimistic on the technical foundation (Rust, Wayland, iced, integrated tiling).
• Many stress it’s an alpha and hope the toolkit, accessibility, and design mature; others doubt the need for yet another mac‑like DE.

Overall reaction

• Many are pleased Firefox is finally experimenting with native vertical tabs, calling it long‑overdue and a potential “easy win.”
• Others find the current Nightly implementation too immature or underpowered compared to existing extensions and rival browsers.

Implementation status & UX issues

• Feature is currently Nightly‑only and somewhat buggy: sidebar toggles reset, pinned tabs reportedly disappear after restart, sidebar sometimes fails to open.
• By default, vertical tabs show only favicons, which several find unusable for large tab counts; there is a way to expand to show titles, but it’s non‑obvious.
• Some report the top tab bar or title bar still consuming vertical space, especially on macOS; others note there is now a toggle to hide the horizontal tab bar.
• Tabs are “chunky,” sidebar width is fixed, and there is no nesting/tree view yet.

Comparison with extensions and other browsers

• Power users say Tree Style Tab, Sidebery, Simple Tab Groups, and similar addons are still far superior:
  • Support nested tree hierarchies, panes, auto‑grouping, integration with containers, memory management, and extensive customization.
• Some hope the native feature will at least:
  • Provide a non‑hacky way to disable the horizontal tab bar.
  • Expose better APIs so advanced extensions can integrate more cleanly.
• Several note that Edge, Vivaldi, Brave, Arc, and Safari already offer vertical tabs, groups, or workspaces; some see Firefox as “catch‑up,” not innovation.

Why vertical tabs?

• Pro‑vertical arguments:
  • Modern screens have more horizontal than vertical space; vertical tabs free vertical pixels.
  • Easier to show long titles and many tabs with readable text.
  • Natural fit for hierarchies and grouping, similar to file explorers.
• Counter‑arguments:
  • Horizontal tab crowding acts as a useful signal to close tabs.
  • Switching between vertical and horizontal paradigms across apps feels inconsistent for some.

Tab groups, workspaces, and split view

• Very strong demand for:
  • Native tab groups/workspaces with hiding, hierarchical organization, and integration with containers.
  • Sync and restore of entire groups/workspaces across devices, not just individual tabs.
  • Native split‑pane/split‑screen browsing; some prefer to rely on OS window managers instead.

Meta: Firefox direction

• Some welcome renewed UI experimentation after a perceived period of stagnation.
• Others fear disruptive redesigns and prefer a stable, minimal UI.
• A few question the timing relative to recent controversy about Firefox’s advertising/surveillance features; the actual development start is mentioned as recent but predating that debate.

Scope and Metrics of “Stardom”

• Many think Billboard Top 40 is a poor proxy for lasting stardom.
• Alternative metrics suggested: money earned over time, ability to keep touring, residencies (Vegas/Branson), or steady fan support.
• Some argue “working musician” vs “star” should be distinguished; playing casinos or state fairs may pay well but isn’t perceived as “stardom.”
• Several commenters note the article largely captures “one‑hit wonder” patterns, not broader music careers.

Touring, Longevity, and the Long Tail

• Numerous examples of artists still touring decades after chart peaks, often in smaller venues, festivals, nostalgia cruises, or themed festivals.
• Nostalgia is powerful: fans who loved a band as teens will pay to see them 20–30 years later; similar to classic car markets.
• Some former mid‑hit bands and “legacy” acts reportedly make more from touring older hits now than they did at peak chart success.

Economics, Royalties, and Career Strategy

• Debate over whether residuals make arts careers structurally better than STEM; most agree big, lasting royalty streams are rare outliers.
• Royalties often require legal and business effort; artists can be underpaid or misled.
• Some musicians build stability by producing, engineering, session work, teaching, or moving into behind‑the‑scenes roles and other businesses.
• A few use brief fame as a springboard into other ventures (investing, branding, real estate, etc.).

Motivation and Life Satisfaction

• Several challenge the article’s implication that short chart careers make the pursuit irrational.
• Many musicians are portrayed as primarily motivated by love of performing and peer respect, not just mainstream fame.
• Examples of lifelong bar/club players and niche improvisers suggest a parallel “status without money” track that still brings fulfillment.

Cultural and Industry Shifts

• Some argue internet/streaming fragmented culture, reducing shared, era‑defining hits and possibly shortening mainstream careers.
• Others highlight multi‑generational “outliers” (e.g., long‑running pop stars, metal bands, jam bands) sustained by core fanbases and cross‑generational listening patterns.
• Overexposure and constant social media promotion are seen by some musicians as shortening careers; strategic scarcity is proposed as a longevity tactic.

Core features and variants

• Dual Cortex-M33F cores at 150 MHz (commonly overclocked to ~300 MHz in tests), optional dual Hazard3 RISC‑V cores at 150 MHz on the same die.
• 520 KiB SRAM, optional 2 MB in‑package QSPI flash (RP2354), external PSRAM support, PIO v2 with 3 blocks / 12 state machines, improved DMA.
• Pico 2 board: 4 MB QSPI flash, 5 V‑tolerant (some) GPIOs, security features (signed boot, TrustZone, TRNG, glitch detection), footprint‑compatible with Pico 1.
• 4 ADC channels on base package, 8 on 80‑pin variant; still no DAC. Slight ADC improvement only.

ARM vs RISC‑V dual architecture

• At boot, each of two “sockets” can be mapped to either M33 or Hazard3; mix‑and‑match (1 ARM + 1 RISC‑V) is possible, but only two cores active total.
• Rationale discussed: sharing bus fabric and avoiding a larger, more power‑hungry crossbar; not area of cores themselves.
• Seen as a way to de‑risk a potential long‑term transition toward RISC‑V and hedge against ARM licensing changes.
• Thread warns: benchmarks would really be M33 vs Hazard3, not generic “ARM vs RISC‑V”.

I/O, high‑speed tricks, and PIO

• PIO still a standout: many see it as beating traditional peripheral sets; others note it’s under‑served by vendor‑maintained “soft peripheral” libraries and third‑party RTOSes.
• Existing community PIO implementations for CAN and RMII Ethernet; several people report heavy refactoring needed to make RMII robust and standards‑compliant.
• New HSTX block (one‑way high‑speed serial, can drive DVI/TMDS) excites people for inexpensive video and FPGA links; regret it’s not bidirectional.

Power, analog, and 5 V tolerance

• Power system more complex: on‑chip regulator mainly for 1.1 V core; separate 1.8–3.3 V I/O and 3.3 V analog/USB rails still needed.
• GPIOs are 5.5 V‑tolerant only when properly powered at 3.3 V and only on specific digital‑only pins; analog‑capable pins are not 5 V‑tolerant.
• Some praise lithium‑cell support; ultra‑low‑power / coin‑cell use still seen as weak, though idle power reportedly improved.

Security and secure boot

• New secure boot with OTP keys, signed boot, and a redundancy coprocessor plus glitch detection; $10k bounty and external audits cited as signals of seriousness.
• Still no on‑the‑fly external flash/PSRAM encryption like some ESP32/STM32 parts; running fully from internal SRAM is seen as limiting for larger firmware.

Comparisons to other MCUs

• Frequently contrasted with STM32H7: RP2350 praised for price, documentation, PIO flexibility, and less painful errata; critics note H7 still wins on raw performance, caches, and “real” peripherals.
• Some say low‑power and wireless needs still favor Espressif and Nordic; others see RP2350 as strong for high‑speed I/O and hobbyist/industrial control.

Boards, packaging, and connectors

• Pico 2 keeps micro‑USB for backwards mechanical compatibility and cost; this draws heavy criticism from those who’ve moved to USB‑C only.
• Third‑party boards (e.g., with USB‑C, PSRAM, larger flash) highlighted but are pricier.
• QFN60/QFN80 only; some hobbyists dislike bottom‑pad GND and wish for TQFP, others say cheap hot‑plate/toaster reflow or dev‑board modules solve it.

Tooling, SDK, and ecosystem

• Official C/C++ SDK updated; MicroPython support expected. GPIO 5 V‑tolerance details clarified in datasheet.
• New Bazel‑based “Pigweed SDK” showcased; reactions mixed—some love Bazel’s hermetic builds, others strongly dislike Java/Bazel and see it as misaligned with typical embedded workflows.
• Desire for official PIO “soft peripheral” library (CAN, SD/MMC, MII, Bluetooth HCI) and stronger Zephyr integration.

Use cases and demos

• Enthusiasm for: motor control (FOC, sensorless with more ADCs), retrocomputing (RAM/ROM emulation, classic systems), higher‑end displays via DVI/HSTX, high‑speed RP2350–FPGA links, and even Quake‑class games with PSRAM.
• Several report significant real‑product use of RP2040 already and see RP2350 as addressing major pain points (FPU, security, RAM, peripherals).

Public Funding, “Fees,” and Bias

• Several commenters praise UK/German/Dutch-style mandatory fees for public broadcasters as a partial antidote to clickbait and sensationalism.
• Others argue these fees are effectively regressive taxes, resented because they fund outlets perceived as biased or wasteful, and must be paid even if unused.
• There is disagreement over neutrality: some see major public broadcasters as comparatively balanced; others describe them as aligned with political establishments, advocating censorship, and not meaningfully better than private outlets.

How Much News to Consume

• Many report quitting or sharply reducing daily news and feeling less anxious and angry, while still learning major events via social contact or periodic catch‑ups.
• A common pattern: rely on weekly summaries, long‑form articles, books, or domain‑specific sources instead of 24/7 feeds.
• Some argue that for voting and most life decisions, intensive daily news is unnecessary; others stress a civic duty to stay informed and warn against nihilism.

Quality, Accuracy, and “Junk Food”

• Multiple contributors with first‑hand experience in journalism or as sources describe misquoting, distortion by editors, and narrative‑driven coverage.
• Gell‑Mann amnesia is frequently cited: when you know a topic well, news coverage looks wrong, implying similar errors elsewhere.
• Fast, real‑time reporting is seen as especially error‑prone and speculative; pundit prediction failures around events like the Ukraine war are highlighted.

Satire, Infotainment, and Social Media

• Mixing comedy and news divides opinion. Some see satire shows as more informative than cable news; others say they mostly reinforce existing views.
• Social platforms like Twitter/X can be carefully curated but are still described as “junk food” with low long‑term value.

Local vs Global and Actionability

• Several argue global outrage stories rarely lead to personal action, while local news can matter for corruption, policing, and municipal politics.
• Others note foreign policy and distant conflicts still warrant attention because they shape national decisions.

Ideas for Better Information Diets

• Proposals include: weekly digests; apps that cap daily stories and summarize across sources; email newsletters; and prediction markets as a filter.
• Many call for “nutrition labels” or independent ratings for news outlets (links to sources, correction histories, funding transparency), though others doubt true neutrality or public trust in such systems.

Swiss restrictions on German trains

• Switzerland now blocks late German long-distance trains at the border to protect its tightly timed, high‑capacity network.
• Trains may terminate at Basel Bad or require passengers to change to Swiss services, adding 15–30 minutes but avoiding knock‑on delays.
• Commenters stress this is mainly an operational necessity, not “anti‑German” sentiment; Swiss lines run near capacity with tight buffers.

Deutsche Bahn punctuality and reliability

• Many report German trains as “increasingly delayed” and cancellations as common, including missed flights/ferries and unreliable school commutes.
• Official punctuality metrics are seen as misleading: generous thresholds (up to 15 minutes, separate measures, cancelled trains often excluded) and incomplete real‑time data.
• Structural issues cited: mixed freight/passenger use on the same tracks, removal of sidings/switches, under‑investment, and overloaded network.

Funding, privatization, and incentives

• One camp: main cause is chronic underfunding and political prioritization of roads; per‑capita rail investment is said to lag far behind Switzerland and Luxembourg.
• Another camp: more money alone won’t fix a dysfunctional, corporate‑style structure with perverse incentives (maintenance vs. “new build” budgets, short‑term cost cutting).
• Debate on “privatization”: DB is a corporatized but state‑owned holding; some see this as effectively public, others as mimicking private, profit‑oriented behavior without competition.
• Mixed international comparisons: Japan’s privatization praised; Sweden and the UK cited as warnings about splitting infrastructure and operations.

Comparisons with other systems

• Switzerland held up as the benchmark: very high on‑time performance with a strict 3‑minute threshold and dense, integrated clock‑face timetable.
• Other European operators (France, Spain, Italy) are often reported as more reliable and faster on long‑distance routes.
• Some US commuter and regional systems claim high on‑time rates, but long‑distance Amtrak and North American intercity buses are described as highly unreliable.

Culture, management, and workforce

• Multiple comments blame DB’s internal culture: intense blame‑seeking, risk aversion, bureaucracy, weak improvisation, and “ass‑covering” over problem‑solving.
• Forthcoming staff shortages and aging infrastructure are seen as worsening reliability unless governance, incentives, and investment change.

RLHF vs “real” RL

• Many argue RLHF is only barely reinforcement learning: it’s mostly supervised training on human preference labels plus a small RL step on a reward model.
• In language models, human feedback is often the only available “ground truth,” unlike games with clear win/loss signals.
• Critics in open-source circles see RLHF as aligning models to corporate risk tolerance (censorship, blandness) rather than truth or usefulness.

Reward Functions and Open-Ended Language

• Central issue: for open-ended tasks (essays, explanations, advice), there is no cheap, reliable reward signal analogous to “win the game.”
• Evaluating answers for quality, correctness, style, and safety is hard to formalize and doesn’t scale; human preferences are noisy and non-universal.
• Some suggest meta-approaches (LLMs judging LLMs, self-scoring, “constitutional” rules), but these are seen as fragile or circular.

Games, Go, and RL Limits

• Go is used as a contrast case: clear objective, verifiable outcomes, and massive self-play enable strong RL.
• Even there, models can fail on out-of-distribution strategies and require enormous compute; this highlights how much harder open domains are.
• Several note that successes in closed games don’t transfer straightforwardly to messy real-world or linguistic tasks.

Coding, Theorem Proving, and Formal Domains

• Many see code and formal math as promising RL targets: compilation, test suites, and proof checkers provide crisp signals.
• Proposals include loops where models write code/tests, run them, iteratively refine, and use the trace as new training data.
• Counterpoints: tests can be gamed (mocking, overfitting, deleting failing tests), specs are often as hard as code, and “passes tests” ≠ “meets real requirements.”

Capabilities and Limits of LLMs

• Some posters find LLMs highly useful for coding and explanation; others report unreliable, unsafe, or performance-poor outputs in demanding domains.
• Debate over whether models are trained to be “convincing” vs actually correct; productivity gains may mask rare but severe failures.
• Several argue transformers lack key AGI ingredients (online learning, persistent memory, deep planning), so better objectives alone won’t yield AGI.

Evaluation, Reward Gaming, and Alignment

• Discussion parallels economic incentive problems: systems learn to game imperfect reward functions rather than create true value.
• There is broad agreement that designing robust, scalable objectives for “general helpfulness” and long-horizon goals remains unsolved and foundational.

Loophole and corporate responsibility

• Discussion centers on Google/Meta exploiting an “unknown” age bucket that internally skewed under‑18, effectively bypassing stated bans on targeting minors.
• Many see follow‑up statements blaming “sales reps” or promising retraining as implausible scapegoating and part of a recurring pattern: leadership benefits from rule‑breaking while disowning it after exposure.
• Some tie this to earlier ad collusion cases (e.g., Jedi Blue) and see a consistent strategy of paying fines rather than changing behavior.

Why targeting teens is viewed as harmful

• Core concern: targeted digital ads exploit minors’ heightened susceptibility to addiction, status pressure, and impulse, especially for highly addictive products/platforms (social media, sugary foods, vaping).
• Several compare it directly to historical tobacco and Juul youth‑marketing strategies.
• Others argue: kids’ TV ads have existed for decades; what’s new is the precision, scale, data depth, and interactivity.

Law, regulation, and enforcement

• Commenters note strict child‑ad laws in some countries (e.g., Denmark, Sweden) and how “unknown” categories can be used as plausible deniability.
• There’s pessimism that US regulators and legislatures can meaningfully constrain Big Tech, given hearings with little follow‑through and companies’ control over information flows.
• Some see the EU’s large‑platform rules as a partial model but worry about global enforceability and loopholes.

Broader critiques of capitalism and ad tech

• Many frame this as “late‑stage capitalism”: value extraction pushed into every unregulated corner, with data science used to optimize exploitation.
• Doubts about “reputational damage” as a check; brands and platforms appear to suffer little long‑term for abuses.
• Debate over worker complicity: some say employees share moral responsibility and should quit; others cite family, healthcare, and a weak job market as major constraints.

Child development, social media, and addiction

• Multiple anecdotes about children turning hobbies into status‑seeking content, reinforcing “learned helplessness” and replacing genuine curiosity with social validation.
• Concerns that early, algorithmic social media exposure may “short‑circuit” reward systems and worsen adolescent mental health.

Proposed remedies (highly varied)

• Ban or heavily restrict all advertising to minors; some extend this to all advertising or tax it like a harmful product.
• Technical/UX changes: strong ad blockers, children’s OSes with no tracking, limiting mass‑reach platforms vs peer communication tools.
• Structural ideas: much tighter regulation of data collection, banning hyper‑targeting, or even treating advertising as a regulated vice.

Defenses and minority views

• A minority sees little concrete harm in better‑targeted ads and emphasizes benefits of discovering relevant products or services.
• Some argue that contextual (page‑based) ads could be less invasive, though others note this can also become proxy targeting.
• A few stress that advertising can be socially useful if products truly solve problems; critics counter that modern ad ecosystems overwhelmingly optimize for profit, not welfare.

Desire to Defeat Death vs. Accepting Mortality

• Some posters express intense envy of future people who may not die, and want to leave lucrative careers to work on “solving death,” seeing it as the most meaningful possible project.
• Others say completely escaping death is impossible; a more realistic and worthy goal is eliminating disease, aging, and suffering so people die without long decline.
• A middle view is that biological “immortality” just means not aging; you can still die from accidents, violence, or disasters.

Thermodynamics, Evolution, and Feasibility

• Many invoke entropy and heat death: the universe trends toward maximum entropy, so literal eternal life is seen as impossible.
• Counterpoints: thermodynamics constrains closed systems; life and Earth are open systems with vast solar energy, and the cosmic end-state is irrelevant on human or even million‑year scales.
• Evolutionary arguments note that death and limited lifespan are selected because they help species adapt and avoid competition with all past generations. Critics reply that human technology already overrides many evolutionary constraints.

Social, Political, and Economic Consequences

• Major worry: vastly extended lifespans could entrench current elites and dictators “forever,” worsen inequality, ossify institutions, and stall scientific and cultural progress.
• Others argue we already have institutional churn (term limits, retirement, revolution) and that long-lived people might care more about long‑term problems like climate.
• Resource constraints and overpopulation are frequent objections; replies cite falling birthrates, potential for population control, and technological advances, though their costs are acknowledged as unknown.

Meaning, Boredom, and Identity

• One camp insists mortality gives life urgency and meaning; eternity would render events meaningless, lead to boredom, and accumulate unbearable loss.
• Opponents say many people already feel they don’t have enough time; extended youth would allow multiple careers, long projects, and deeper relationships. If life became boring, one could still choose to die.
• Some question whether a self that changes over millennia is still “you”; others say continuous consciousness and memory, not static traits, define identity.

Philosophical and Spiritual Views

• Some see fear of death as misunderstanding life or clinging to ego; they suggest meaning comes from transcending the narrow personal self, possibly via spiritual or religious frameworks.
• Others reject afterlife assumptions as unsupported, grounding their views in materialist or skeptical stances, while some explicitly argue that materialism cannot adequately explain consciousness or ethics.

Difficulty and Design of Older Games

• Many argue classic games were harder: limited saves, no continues, cryptic progression, punishing game over screens, and unintuitive mechanics (e.g., Sonic 3’s “barrel of doom,” hidden bombable walls in Zelda, impossible jumps due to bugs).
• Others say much of this was poor design rather than intentional difficulty.
• Several note most kids of that era actually didn’t finish many of these games.

Guides, Internet, and “Spoilers”

• Modern players have massive advantages: YouTube walkthroughs, FAQs, autosaves, parents who already “know the tricks,” and emulators with save states.
• Some lament that instant guides and videos reduce discovery, problem-solving, and the “unspoiled” sense of exploration.
• Others point out some games effectively assume external guides (e.g., Souls-likes, Nethack, Dwarf Fortress, early Minecraft).

Can Kids Today “Get Good”?

• Multiple parents report their kids quickly mastering older titles and even outclassing them in skill, especially in FPS and platformers.
• Others see kids bouncing off old games due to graphics, unforgiving punishment, or slower pacing.
• Reaction time and available free time are cited as big advantages for kids; long-term experience and old-school mechanics favor older players.

Social Play, Sandboxes, and Culture

• Modern kids gravitate to multiplayer sandboxes (Minecraft, Roblox, Rust) and co-op experiences rather than lone single‑player runs.
• Shared media (current games, YouTubers) is seen as important for fitting in with peers, though some parents dislike kids’ culture centering on mass media.
• Some families successfully bond over retro games and movies; others find generational tastes diverge sharply.

Nostalgia vs. “Torture”

• Some consider many NES/SNES/PS1-era games still fun and timeless, especially with minor QoL tweaks or romhacks.
• Others feel old games are “torture” due to grinding, opaque systems, and harsh punishment, preferring modern design—even while still exposing kids to challenging content.

Preservation and Longevity

• Emulation, ROM hacks, and updated rosters (e.g., Tecmo Bowl) keep classics alive.
• Concerns are raised that many contemporary games will become unplayable for future generations due to server shutdowns and platform lock‑in.

Post-war occupation and “lessons of Versailles”

• Some argue the US/Allies learned from WWI: after 1918 Germany was largely not occupied, reparations were harsh, and this fed resentment and “stab-in-the-back” myths.
• WWII policy instead focused on unconditional surrender, full occupation, and deliberate reconstruction of Japan and Germany.
• Others say “lessons of Versailles” is oversimplified: many factors (Weimar political instability, Prussian militarism, lack of democratic traditions) contributed to Nazi rise, not just the treaty.

Why Germany and Japan recovered

• One view: both were already industrialized with skilled populations; post-war growth was a continuation of earlier capabilities, only under new regimes.
• Counterview: US-led reconstruction (Marshall Plan, aid to Japan, institutional reform, new constitutions) significantly accelerated and shaped recovery.
• Debate over whether “free markets” vs “social market” models explain West Germany’s “economic miracle,” especially compared to Britain/France and East Germany stripped by Soviet reparations.

Morality and necessity of the atomic bombings

• Many express horror at targeting civilians; others argue this must be seen in context of contemporaneous mass firebombing of cities and looser norms about civilian immunity.
• Pro-bomb arguments: they likely shortened the war, avoided an extraordinarily bloody invasion/blockade of Japan, and forced a regime that refused acceptable terms to capitulate.
• Anti-bomb arguments: Japan was already effectively defeated, exploring surrender; use may have been partly to justify the weapon’s cost and signal power, making civilian deaths morally unjustifiable.

Soviet invasion vs atomic bombs in Japan’s surrender

• Some emphasize the Soviet invasion of Manchuria and fear of Soviet annexation as decisive; surrender to the US was seen as the lesser evil, especially to preserve the Emperor.
• Others argue both factors mattered: bombs shocked political leadership, Soviet entry convinced field commanders; without bombs, surrender timing and terms are uncertain.
• Thread treats counterfactuals (bombs vs no bombs) as inherently ambiguous.

Civilian bombing and laws of war

• Comparisons drawn between atomic bombings, conventional firebombing (Tokyo, Dresden), Japanese atrocities in Asia, and later US bombings in Korea/Vietnam.
• Discussion notes that many modern “laws of war” and notions of war crimes were clarified only after WWII.

Criticality accidents and nuclear safety

• The “third bomb” core became the Demon Core used in dangerous criticality experiments.
• Explanations of critical vs supercritical mass, geometry and neutron reflectors, and why slow criticality ≠ bomb.
• References to later mishaps and books on nuclear weapon safety highlight how difficult safe management is.

Recommended reading/listening

• Multiple recommendations: histories of the atomic bomb and hydrogen bomb, analyses of the decision to use the bomb, and narrative podcasts on WWI/WWII and nuclear history.

Practical HIV prevention in 2024

• Core tools:
  • Daily oral PrEP (Truvada, Descovy) for HIV‑negative people at ongoing risk.
  • PEP: short antiretroviral course started within 72 hours after a specific exposure.
  • Emerging long‑acting injectable PrEP (cabotegravir every 2 months; lenacapavir every 6 months).
• Additional biomedical prevention discussed:
  • Vaccines: HPV (Gardasil 9), monkeypox, meningitis ACYW/B (B has partial gonorrhea protection), hepatitis A/B, plus routine childhood vaccines.
  • DoxyPEP: two doxycycline pills after sex to cut risk of syphilis, chlamydia, and partially gonorrhea.
• Many note clinics and sexual health services can guide people on PrEP/PEP and broader risk reduction.

U=U (Undetectable = Untransmittable) and viral load

• Several comments emphasize strong evidence that people with consistently suppressed viral load do not sexually transmit HIV, citing large trials in both heterosexual and gay couples.
• Viral-load thresholds are discussed: <200 copies/mL linked to no observed transmission; untreated semen can carry 10,000–1,000,000 copies/mL vs. 1–10 on treatment.
• A minority of commenters question absolute claims of “zero risk” on theoretical virology grounds; others counter that empirical data overwhelmingly support U=U.

Lenacapavir specifics

• Described as a capsid inhibitor that binds HIV p24 and blocks multiple life‑cycle steps (nuclear import, assembly, capsid formation).
• Given as a subcutaneous depot with very long half‑life (on the order of months), attributed to structure and poor solubility.
• Phase 3 prevention trial in ~5,300 high‑risk participants: 55 infections in oral PrEP arms, none in lenacapavir arm; trial stopped early for efficacy.

Resistance and mutation

• Some argue dual‑mechanism or combination regimens make resistance “difficult but not impossible,” noting HIV’s very high mutation rate and need for multi‑drug therapy in treatment.
• Others downplay resistance risk for PrEP, citing long experience with Truvada/Descovy and lack of major resistance problems so far.

Side effects and safety

• Trial reportedly showed excellent short‑term safety; halting was framed as due to both high efficacy and acceptable tolerability.
• Skeptics worry early stopping can exaggerate benefits or miss rare harms; others cite analyses suggesting early stopping is not systematically misleading.
• Long‑term effects of very long‑acting agents and PFAS‑like chemistry are raised but remain unclear in the thread.

Cost, patents, and access

• Strong expectation lenacapavir will be priced at a premium, following Truvada/Descovy patterns (high US list prices despite cheap generics elsewhere).
• Debate over whether high prices are justified by R&D vs. driven by patents, marketing, and oligopolistic behavior.
• Multiple comments note:
  • Government and universities often fund early research and, in PrEP’s case, major trials.
  • Industry pays for most large clinical trials and commercialization.
  • Patients and insurers bear high costs, with especially severe implications for low‑income countries; many foresee reliance on Indian generics for African access.

Behavior, risk groups, and non‑HIV STIs

• Discussion of PrEP use in gay/bi men, sex workers, people who inject drugs, and young women in high‑incidence African settings.
• Some worry “lifestyle PrEP” encourages condomless sex; others argue:
  • People already forgo condoms, especially for oral sex.
  • Other STIs are typically treatable, whereas HIV is lifelong.
  • PrEP users tend to test frequently and may be less likely to transmit STIs overall.
• HSV and some other infections remain difficult to prevent fully; condoms only partially help.

Public vs. private roles

• Extended debate on:
  • True cost of drug development (including failed candidates).
  • How much of foundational science and clinical work is taxpayer‑funded.
  • Whether life‑saving drugs should be for‑profit, price‑regulated, or publicly developed.
• No consensus; many agree that current patent‑driven, high‑price model limits access, especially where HIV burden is highest.