Hacker News, Distilled

Roku TV motion smoothing change

• Roku OS 13 on TCL/Hisense TVs reportedly enabled motion smoothing (“soap opera effect”) in a way some owners cannot fully disable.
• Many describe the effect as making films look like cheap video or soap operas, with unnatural camera pans and artifacts, especially in animation and fast motion.
• A smaller group says they like the smoother look, especially for sports and “true-to-life” content, and find default 24fps judder more distracting.
• Several note that other TVs offer interpolation as an optional, off‑by‑default setting; frustration centers on Roku’s forced behavior and lack of timely response or fix.

Smart TVs, updates, and control

• Many say they will never connect TVs to the internet, or block them at the router/VLAN level, to avoid forced updates, ads, and tracking.
• Some regret updating devices that were “good enough,” reporting bricks or lost functionality on TVs, printers, 3D printers, and headsets.
• Others counter that never updating is unrealistic for security‑critical software, but accept avoiding updates on “appliance” devices like TVs.

Privacy, data, and business models

• Strong distrust of ad‑subsidized platforms (Roku, Fire TV, Android TV). Users describe home screens being increasingly filled with ads and tracking toggles that default to on.
• Debate over whether Apple TV is materially better for privacy: some cite Apple’s hardware‑centric business model; others point to reports of Apple analytics and growing ad business.

Alternatives and setups

• Common pattern: buy any decent panel, never network it, and use a separate box (Apple TV, Nvidia Shield, Raspberry Pi + Kodi/Jellyfin, Chromecast).
• Some suggest computer monitors as “dumb TVs,” but note cost, size limits, HDR/eARC gaps, and lack of speakers.

Consumer protection and ownership

• Posters from some jurisdictions (e.g., Norway, Australia) argue that post‑purchase updates that materially worsen a product could be a legal defect (“not fit for purpose”).
• Others push back, saying the TV still “plays video” and laws shouldn’t guarantee freedom from dissatisfaction.
• Broader theme: users feel they don’t truly “own” smart TVs; vendors can unilaterally change behavior to serve advertisers or metrics (invoking “enshittification”).

Analogies to media “remastering”

• Several compare forced motion smoothing to loudness‑war remasters and streaming “remixed” or animated album art: technically “upgraded,” but artistically worse, often with originals removed.

Practical low-latency patterns & ring buffers

• Several comments discuss using the LMAX Disruptor pattern and SPSC ring buffers.
• Key implementation pitfalls noted: need for std::atomic for producer/consumer indices, correct memory ordering (acquire/release), avoiding returning pointers after freeing slots, and preventing false sharing between indices.
• Optimization tip: use power-of-two ring sizes and bitmasking instead of modulo; treat indices as ever-increasing sequence numbers.

C++ vs Rust and memory management

• One practitioner built a C++ stock exchange using a disruptor-style queue and is rewriting in Rust, citing easier memory management and dependencies for solo projects.
• Others warn that complex concurrent data structures are hard to get right in C++ and that Rust can be slower to iterate on designs due to the borrow checker, though fun to use.
• Debate over std::shared_ptr: some claim it “won’t slow anything down,” others emphasize it does have atomic/refcount overhead and should be used sparingly, often hidden behind APIs. unique_ptr and explicit ownership modeling are strongly advocated.

HFT architectures, OS, and hardware tricks

• Descriptions of production setups: colocation at exchanges, offloading TCP and network stack work to hardware, multicast logging, redundant hot-standby systems, and massive historical data replay for backtesting.
• Techniques include core pinning, isolating cores and caches, minimizing context switches, sometimes running networking in user space, and careful PCIe/NIC layout.
• FPGAs are widely used for ultra-low-latency tick-to-trade; for some flows they can act before a full packet is received. Software then handles slower, more complex logic.

Performance techniques & compiler behavior

• Discussion of compile-time vs runtime dispatch: static dispatch enables inlining and further optimizations, but excessive inlining can hurt instruction cache; measurement is essential.
• Mention of PGO, LTO, and branch prediction hints; some consider hints marginal or even counterproductive compared to PGO.
• General low-latency mindset: avoid allocations and copies in hot paths, keep data in cache, be paranoid and profile (e.g., callgrind).

Relation to other domains (Java, games, audio)

• Original LMAX was Java; with careful avoidance of allocation and GC, Java can be competitive, sometimes even disabling GC and rebooting daily.
• Parallels drawn to game dev and real-time audio: similar focus on cache locality and predictable latency, but HFT pushes much shorter timescales (micro/nanoseconds vs milliseconds).

Value, risks, and regulation of HFT

• Some view HFT as socially wasteful; others argue it narrows spreads, increases liquidity, and replaces a larger, less efficient human middleman industry.
• Debate over whether many strategies truly “provide liquidity” vs remove it, and over tactics that induce responses in other bots.
• Ideas floated: order-cancel taxes, time-quantized or randomized batch auctions; critics worry about unintended consequences and shadow/black markets.
• Several emphasize that regulators already constrain cancellation rates and that empirical data (from tagged exchange feeds) shows declining net liquidity costs over time, suggesting markets are becoming more efficient.

Evaluation of the paper and learning resources

• Some find the paper an “excellent intro,” especially given the scarcity of consolidated low-latency C++ material.
• Others criticize it as a trivial recap of well-known micro-optimizations, unrepresentative examples (e.g., 65µs “inner loops”), and possibly LLM-written prose.
• Alternative learning paths suggested: conference talks (esp. C++ and game dev), FPGA/HFT verification writeups, performance-oriented blogs, and a trading microstructure book (“Trades, Quotes and Prices”) for those interested in the market side.

Overview of the Offer

• Six‑month free trial of Affinity Photo, Designer, and Publisher seen as a strong way to get Adobe users to seriously test switching.
• Some users already own the suite and are very satisfied; others tried it and bounced back to Adobe or other tools.

Affinity vs. Adobe

• General consensus: Affinity apps are solid, cheaper, and “good enough” for many use cases, but Adobe remains ahead for high‑end professional workflows.
• Specific gaps noted:
  • Designer vs Illustrator: lacks image tracing, blend tools, advanced gradients, perspective tools, automation, curvature tool, robust shape replication.
  • Photo vs Photoshop: weaker advanced masking/brush workflows; confusing RAW “Develop Persona” and more destructive editing; missing support for Adobe XMP‑based edits.
  • Publisher vs InDesign: broadly comparable, but weaker multipage/layout/template tools and no scripting/plugin ecosystem.

Lightroom & Photo Management

• Affinity has no Lightroom‑style cataloging or non‑destructive multi‑image workflow.
• Develop Persona is non‑destructive but hidden/confusing and easy to break into destructive pixel layers.
• Several discuss alternatives: Capture One, DxO PhotoLab, RAWTherapee, Darktable, RAW Power, AfterShot, digiKam, Ansel; none are viewed as a perfect Lightroom replacement.

Automation, Plugins, and AI

• Major pain points: lack of scripting, plugin SDK, and batch/automated exports in Affinity; users resort to Krita scripting or other tools.
• Some Photoshop plugins work in Affinity Photo; compatibility is inconsistent.
• Affinity has some “smart” features (e.g., content‑aware fill) but no modern generative AI; some hope Canva backing will fund this.

Licensing, Subscriptions, and Canva

• Strong appreciation for Affinity’s low‑cost perpetual licenses and cross‑app file compatibility.
• Acquisition by Canva triggers fears of a future shift to subscriptions or “enshittification,” despite official statements that perpetual licenses will remain.
• Debate over long‑term risks of online activation vs. older offline activation.

Platform Support & UX

• No native Linux support; some report partial success via Wine.
• Mixed reports on stability and performance: some praise speed and smoothness; others complain of lag, rendering glitches, and long startup.
• Learning curve friction: Affinity often copies ~80–85% of Adobe workflows, but the remaining 15–20% behaves differently, frustrating experienced Adobe users.

Overview of the proposal

• Red Hat engineers propose “no more boot loader” (nmbl): use the Linux kernel itself (via EFI stub and UKI images) as the first-stage bootloader.
• Goal: avoid GRUB’s duplicated drivers, filesystem code, and complex scripting, which are seen as hard to maintain and a security liability.
• UEFI firmware loads a unified kernel image (kernel + initramfs + cmdline); a small initramfs userland presents a menu, does any needed logic, then either switch_root’s or kexec’s into the target system.

Perceived benefits

• Less duplicated code: reuse kernel’s mature drivers, filesystems, crypto, networking instead of re‑implementing them in GRUB or other loaders.
• Potentially fewer security bugs and faster fixes, since kernel code has many more eyes and established processes.
• Aligns with UKI / Secure Boot / measured boot workflows and simplifies signed‑boot chains.
• Embedded and specialized systems already often use similar “Linux as bootloader” patterns.

Concerns and criticisms

• Feels like “another Red Hat/systemd‑style churn”: fear of long-term ecosystem disruption, new tooling, and documentation gaps.
• kexec reliability: some hardware, GPUs, ACPI, and especially Apple Silicon are cited as problematic for robust kexec-based booting.
• Worry that complex pre‑boot logic (multi‑OS menus, network boot, ZFS/Btrfs snapshots) will just recreate another large, bug‑prone codebase inside initramfs.
• Skepticism about tying more of the boot chain to Secure Boot, TPM, and vendor keys; concerns about user lock‑in vs owner control.

Initramfs, modules, and filesystems

• Debate over whether we should instead aim for “no more initramfs” by compiling everything needed into the kernel or using a smarter loader (FreeBSD‑style).
• Out‑of‑tree modules (e.g., ZFS) and stacked storage (LUKS, LVM, RAID) make initramfs or equivalent almost unavoidable for generic distros.
• Some argue UEFI ESP plus kernel‑loaded modules from FAT is a simpler route than elaborate initramfs.

Multi‑boot and user experience

• Many users still rely on GRUB for:
  • Dual‑booting Linux/Windows or multiple Linux installs.
  • Selecting older kernels, single‑user mode, and recovery.
  • Booting other EFI tools (memtest, shells).
• UEFI boot menus are widely described as inconsistent, hard to reach, or feature‑poor; some see that as a blocker to “no bootloader” approaches.

Alternatives and existing practice

• Several existing projects already use “Linux as bootloader”: LinuxBoot, Petitboot, ZFSBootMenu, Oxide’s PHBL, custom kexec setups.
• Others are happy with simpler options: EFISTUB, systemd‑boot, rEFInd, or even LILO with no initramfs.
• Thread consensus: idea isn’t new; the value will depend on how well nmbl handles real hardware, multi‑boot, and complex storage without recreating GRUB‑level complexity.

Nature of the Protest

• Protesters in Barcelona used water pistols on people eating at central tourist spots (e.g., La Rambla, Taco Bell), telling them to go home.
• Many commenters see it as largely symbolic and minor (“just water”), but others note it can be considered assault and harassment.

Ethics of Targeting Tourists

• One side: Any protest that involves unwilling participants is immoral; tourists are peaceful and “minding their own business.”
• Others argue protests almost always inconvenience third parties, and locals feel they’re the ones being disturbed by overtourism.
• Some note it’s hard to know who is a tourist vs local; others say in core tourist zones it’s usually obvious from behavior and venue choice.

Housing, Airbnb, and Short-Term Rentals

• Strong theme: short-term rentals (Airbnb/VRBO) and cheap flights have dramatically increased visitor numbers and housing pressure.
• Blame is variously assigned to: platforms, landlords chasing higher returns, permissive zoning, and residents who treat housing as speculative assets.
• Common proposals: ban or heavily tax short-term rentals, cap their number via permits, or fully phase out touristic flats (Barcelona reportedly plans a 2028 ban).

Economic Role of Tourism

• Pro-tourism arguments: billions in spending, ~100k jobs, ~12% of Catalonia’s GDP; money circulates beyond direct tourism workers.
• Critics counter: benefits are concentrated in property owners, chains, and low-wage service jobs; many locals don’t work in tourism or can’t live where they work.
• Some frame it as a “resource curse” or monoculture risk: easy tourist money crowds out higher-value industries.

Why Mass Tourism Feels Worse Now

• Cited drivers: ultra-cheap flights, global rise in incomes, smartphone-enabled booking, and platforms rapidly converting housing into tourist stock.
• Volume is seen as the core issue: more people, same finite set of “must-see” places, turning city centers into “amusement parks.”

Tourism vs Immigration and Politics

• Side debate: whether immigration, especially from Africa, is a bigger housing driver than tourism; others rebut with numbers from the thread and call out xenophobic framing.
• Some say politicians and local elites who promoted Barcelona as a premium destination now deflect blame onto tourists, while frustrated residents misdirect their anger at visitors.

Terminal UX & Learning Curve

• Many see terminal input and copying/pasting as a major barrier, especially for beginners and Windows users; restricted server environments amplify frustration.
• Others report that standard Linux terminals (e.g., Ubuntu) feel “perfect” once familiar: arrows, tab, Ctrl+R/C/D/W, etc.
• Several long‑time users admit they only recently learned about readline shortcuts or didn’t know the term “readline” at all, highlighting poor discoverability.
• Some criticize the idea that it could take 15 years to learn Ctrl+A/E; others say that’s realistic if you never explicitly study terminal ergonomics.

Keybindings, Modes & Shell Features

• Emacs-style shortcuts (Ctrl+A/E/K/Y/T, etc.) are widely available in shells and even general macOS text fields.
• Vi mode in shells (set -o vi, zsh, ksh, etc.) has fans, but even dedicated Vim users sometimes prefer emacs-style bindings on the command line.
• Useful tricks discussed:
  • Ctrl+X Ctrl+E / Alt+e / v in vi mode / fc to edit the current or previous command in $EDITOR.
  • History search with Ctrl+R, stepping with Ctrl+O, and word/line deletion with Ctrl+W/Ctrl+U.
• Opinions diverge on modifying defaults vs memorizing shortcuts. Some prefer Home/End or arrow keys; others remap Caps Lock to Ctrl.

TTY Mechanics & Escape Sequences

• Several comments explain canonical (“cooked”) vs raw mode, fgets() behavior, line editing provided by the kernel TTY layer, and how programs like shells or TUIs override this.
• Tools like stty can reconfigure input behavior; stty sane/reset help recover from “mangled” terminals.
• There is discussion of ANSI/VT100 escape sequences, termios flags, and the messy diversity of terminal emulation and feature detection.

Copy/Paste & Terminal Behavior

• On Linux, the Ctrl‑Shift‑C/V convention is widely disliked by some, who prefer the Windows Terminal behavior where Ctrl‑C copies when text is selected and sends SIGINT otherwise.
• Others prefer “copy on select” plus middle‑click paste, or remap terminals (e.g., kitty, WezTerm, iTerm2) to more “natural” shortcuts.

CLI vs GUI, Linux Adoption & Alternatives

• One view: the terminal’s complexity “condemns” desktop Linux to low market share; most users just want appliance‑like systems and avoid terminals entirely.
• Counter‑view: most users on Windows/macOS also rarely touch the CLI; Linux’s main problem is OEM preinstall, not terminals.
• Several stress that CLIs are invaluable for recovery, debugging, scripting, and precise control, even if GUIs cover common tasks.
• Proposed alternatives include chat‑like or notebook‑style interfaces, richer structured terminals (e.g., Warp, IPython‑like shells, Plan 9/Oberon‑inspired UIs), and improved GUI tooling around system management.

Licensing & Readline

• The GPL license on GNU readline is seen by some as a UX hindrance (blocking non‑GPL programs from using it); others argue this was an intentional strategy to encourage GPL adoption and prevent one‑way extraction of value.

Command Discovery & Aids

• Users struggle with remembering commands and options; suggested aids include apropos, rich completion shells like fish, history search tools like fzf, personal notes/aliases, and even shell‑integrated LLM helpers.

Distinguishing persistence vs obstinacy

• Many commenters restate the core distinction:
  • Persistent: stubborn about the goal, flexible about methods, updates when presented with new information.
  • Obstinate: stubborn about a particular approach or belief, ignores counter‑evidence.
• Several give simple heuristics: “same response despite new info = obstinate; updated response with new info = persistent.”
• Some note it’s a spectrum and often only clear in hindsight whether someone was persistent or merely obstinate.

Mindset, personality, and cognition

• Multiple links drawn to “growth vs fixed mindset,” though some note growth‑mindset research hasn’t replicated strongly.
• Others map traits to Big Five/OCEAN dimensions (e.g., openness + low neuroticism + low agreeableness → productive persistence).
• One line of argument: obstinacy often comes from insecurity and identity; needing to be “right at every step” vs just solving the problem.
• Another view: obstinacy may stem from black‑and‑white thinking; difficulty with nuance and qualifiers like “often” or “it depends.”

Outcomes, luck, and labeling

• Some argue the persistent/obstinate distinction is largely post‑hoc: winners are called persistent, losers stubborn.
• Role of luck and selection bias is emphasized; “successful people do X” tropes are treated skeptically.
• Counterexamples raised (famous innovators with clearly irrational or obstinate beliefs) challenge a clean moral sorting.

Social perception and confidence

• Several note that in public or hierarchical settings, obstinate people often appear more confident and persuasive than receptive, thoughtful ones.
• There’s discussion of how audiences prefer simple, dominant performances over nuanced, conditional reasoning.

Concrete examples and applications

• E‑ink calendar founder asks if continuing is persistent or obstinate; replies focus on:
  • Distinguishing product vs marketing problems.
  • Considering family, finances, and planned risk.
  • Willingness to change framing, pricing, branding, channels.
• QA and safety‑critical domains are cited where “stubborn” insistence on quality is a feature, not a bug.
• Workplace anecdotes show how “being receptive” often matters more for reputation than whether suggestions are actually new.

Critiques of the essay and framing

• Some praise it as a clear, “return to form” piece with a useful conceptual distinction.
• Others see it as oversimplified, pseudo‑psychological taxonomy akin to pop‑management or self‑help.
• Several want more concrete negative examples and more guidance on the hardest issue: when a persistent person should actually quit.

Positioning vs Existing Build Tools

• 1JPM is pitched as a Maven/Gradle alternative that lives in a single Java file checked into the repo and run with java JPM.java, avoiding separate installation.
• Compared to bld and similar Java-based tools, differences noted:
  • 1JPM supports Java 8+, while some competitors target Java 17+.
  • It is literally a single file, which has both advantages (portability, auditability) and drawbacks (code size, feature limits).
• Some argue Maven/Gradle wrappers already solve versioning and install issues, so the value-add is limited for many teams.

Simplicity, Single-File Approach & Java-as-Config

• Several commenters like the “one file” aesthetic and the idea of using plain Java for builds, benefiting from IDE autocomplete, refactoring, and type safety.
• Others warn that using a full programming language for builds is what makes them fragile and overcomplicated in the first place.
• There is interest in tools that feel more intuitive than Gradle’s execution model, especially for small or occasional Java users.

Gradle vs Maven Debate

• Many describe Gradle as powerful but exceedingly complex, “magical,” and prone to fragile builds and backward-incompatible changes.
• Maven is praised for stability, predictable behavior, and easy static inspection, but criticized for weaker incremental builds and needing plugins or scripts for nonstandard workflows.
• Some see Gradle (and Bazel) as necessary for very complex, polyglot enterprise builds; others feel Maven plus plugins is enough.

Transitive Dependencies & Feature Gaps

• 1JPM initially lacked transitive dependency resolution; later comments mention an early implementation that may still be imperfect.
• Multiple commenters view transitive dependency handling as “table stakes” for any serious JVM build tool.
• Others argue transitive deps cause bloat and conflicts and would prefer simpler tools with more manual control.

Security and Declarative vs Imperative Builds

• Concern: to read basic project metadata in 1JPM (or Gradle-like tools), you must run arbitrary code, complicating security review and automated analysis.
• Counterpoints:
  • All build systems allow arbitrary code somewhere (e.g., plugins).
  • Maven’s declarative XML enables static parsing and plugin whitelisting, which is harder or impossible with Turing-complete scripts.

Ecosystem Fit and Alternatives

• Many doubt a new tool can rival decades of Maven/Gradle plugins but still welcome experimentation, especially for simple or personal projects.
• Related alternatives mentioned: bld, jeka, polyglot-maven, Ant, Makefiles, shell scripts plus dependency resolvers (e.g., coursier), and older single-file Java build scripts.

Overview of the Site and Videos

• The site shows real lifeguard rescues in crowded pools; viewers try to click on the drowning person before or after the lifeguard reacts.
• No fatalities are shown; clips end with successful rescues. Several commenters stress this for those worried about watching children die.
• Some find the videos extremely hard, especially due to low resolution and different vantage point than a real lifeguard. Others report getting much better over multiple viewings.

Recognizing Drowning Behavior

• Major takeaway: drowning is usually silent and subtle, not like movies.
• Typical signs mentioned:
  • Vertical “ladder-climbing” motion in the water.
  • Arms forward at the surface rather than waving for help.
  • Brief, incomplete breaths; little or no shouting or splashing.
  • Sometimes almost motionless, appearing “just still” or relaxed.
• Several personal anecdotes echo this: adults nearby did not notice, and even parents or siblings often missed it.

Emotional Impact and Parenting

• Many parents say the videos are emotionally hard to watch but feel the knowledge is worth it.
• Multiple stories of children nearly drowning in shallow water, within a few feet of attentive adults, reinforce how quickly and quietly it happens.
• Commenters emphasize that even “good swimmers” can drown when panicking or when another person grabs onto them.

Lifeguards, Risk, and Pool Practices

• Former lifeguards describe strong pattern recognition that persists for years, and how challenging busy or low-wealth pools can be.
• Some note lifeguards likely maintain mental lists of high‑risk swimmers (e.g., those depending on floatation devices).
• There is substantial debate over pool floatation toys:
  • Arguments against: they hide struggling children, encourage non‑swimmers into deep water, and create complex accidents.
  • Arguments for: they are fun, and responsibility should rest with parents and proper supervision.

Culture, Race, and Access to Swimming

• Multiple comments note that many drowning children in the videos are Black and link this to higher drowning rates reported elsewhere.
• Explanations discussed include culture, income, historical segregation, lack of public pools, and limited access to lessons.
• Some see this as a safety‑relevant statistic; others shift focus to broader education and infrastructure issues.

Swimming Education and Policy

• Several commenters argue basic swimming should be a universal life skill taught in school, citing countries where it is part of the curriculum.
• Others describe local practices (mandatory school swimming, life jackets for small kids, structured certification levels) and criticize how minimal or inconsistent such standards are in parts of the US and Canada.

Tool Design and Alternatives

• Some users are confused by the interface (unclear that you must click on the video, uncertain how scoring works).
• Suggestions include clearer on‑screen instructions and possibly using AI or computer vision to detect drowning as an assistive tool, though this is not discussed in depth.

Scope of the Reverse‑Engineering

• Many see this as exposing “security by obscurity,” not a real vulnerability:
  • You must already have a valid ticket and your own session/token.
  • It mainly frees users from the app/DRM requirement, doesn’t enable mass forgery.
• Others worry about DMCA / CFAA angles and coordinated disclosure norms, but several note:
  • DMCA anti‑circumvention typically concerns copyright, not access control to venues.
  • Recent court decisions narrowed CFAA for cases like this.

What the Rotating Barcodes Are Really For

• Strong view that SafeTix is primarily DRM and market control:
  • Prevents static PDF duplication and forces resale through Ticketmaster/AXS, where fees and minimum prices are enforced.
  • Locks out independent or “face‑value” resale and reinforces their resale monopoly.
• Supporters argue rotating codes genuinely reduce scams with duplicated printouts and screenshots.

Usability, Offline Access & Wallets

• Big pain point: dependence on live connectivity at crowded venues, where cell/Wi‑Fi often fail.
• System is designed to work offline if the ticket is opened or added to Apple/Google Wallet in advance; several note this is now better documented, but:
  • People forget, apps log out, or tickets are only released shortly before events.
  • Some report real‑world failures at gates and long delays.
• Many prefer printable or box‑office paper tickets; some avoid installing the app entirely.

Scalping, Pricing & Possible Alternatives

• Widespread agreement that scalping and underpriced face values drive much of this:
  • Tickets are routinely underpriced relative to demand; arbitrage is inevitable.
  • Ticketmaster and artists can capture resale margin via official resale and “platinum”/dynamic pricing.
• Proposed alternatives:
  • Non‑transferable, ID‑checked tickets with full‑price refunds via the primary seller.
  • Lotteries or Dutch‑auction/dynamic pricing to reach market‑clearing prices.
• Counter‑arguments: ID checks hurt privacy and throughput, disadvantage minors and people without easy ID; auction‑like systems may price out less wealthy fans.

Technical & Security Details

• Core design: TOTP‑like rotating code seeded with a per‑ticket secret, implemented client‑side in JavaScript.
• Client‑side implementation plus exposed JSON APIs made reverse‑engineering straightforward.
• Suggestions for “v2”: move secrets to platform secure storage / trusted computing, but:
  • On open devices, determined users can still extract secrets.
  • Offline constraints and security goals directly conflict.

Monopoly & Ethics

• Many blame Ticketmaster/Live Nation’s venue exclusivity and vertical integration (venues, promotion, ticketing, resale) for abusive fees and UX.
• Debate over developer responsibility:
  • Some argue working on systems that exclude or exploit users is unethical.
  • Others emphasize economic reality and place primary blame on executives, artists who accept these deals, and regulators who allowed the monopoly.

Thought‑terminating clichés & curiosity

• Several commenters link “bullshit jobs,” “signaling,” and “enshittification” to thought‑terminating clichés that shut down inquiry.
• Concern: labeling something as signaling or bullshit lets people avoid understanding complex motives, structures, or tradeoffs.
• Others argue these concepts still have analytical value if used carefully, not as blanket dismissals.
• Debate over whether people have any obligation to be curious; some see curiosity as essential to good work and life, others see it as optional and secondary to pay.

What counts as a “bullshit job”?

• Confusion and disagreement on definitions; many feel people project their own frustration or ignorance onto other roles.
• Distinction raised between:
  • “Shit” jobs: unpleasant but clearly useful (e.g., food service, cleaning).
  • “Bullshit” jobs: roles perceived by incumbents as pointless, or that solve problems created by the system itself.
• Self‑reports are seen by some as authoritative (“they know their job is useless”), by others as often mistaken.

Concrete examples & edge cases

• Food service: some insist it’s non‑bullshit because value to customers is obvious; others feel replaceable by customer self‑service or tech and thus useless.
• Actuaries: defended as clearly necessary, though others note many system‑generated roles (e.g., tax lawyers, complex medical billing) would vanish under different institutional arrangements and so are “bullshit” in a systemic sense.
• Medical billing and tax optimization are cited as archetypal jobs created by bad system design, not intrinsic human needs.

Twitter/X, FAANG, and overstaffing

• Musk’s 80% layoff at Twitter is used as evidence both for and against widespread bullshit jobs:
  • One side: service still runs, so many roles were unnecessary.
  • Other side: technical uptime is not the same as business health; ad sales, moderation, UX, and reliability have degraded.
• Broader point: many tech orgs can “keep the lights on” with far fewer engineers if they stop building new features.
• FAANG hiring/layoffs, “use your budget or lose it,” and headcount as a status symbol fuel claims of empire‑building and make‑work roles.

Unions, strikes, and worker value

• Transit and other public workers’ ability to shut down cities is cited as proof their jobs aren’t bullshit.
• Counterpoint: that power comes from unionized employment structure, not intrinsic job traits.
• Disagreement over whether unions effectively protect workers; some share anecdotes of harmful or pointless strikes and weak apprenticeship/benefit structures, others argue unions still improve long‑run compensation and security.

Reception of the book vs. the critique article

• Many commenters think the critique article badly misreads or strawmans the book, ignoring its nuance and empirical work.
• Others find the book itself economically naïve or incurious about standard explanations for firm behavior.
• Several recommend reading the original essay/book directly; skepticism expressed toward secondary takes that discourage engaging with the primary text.

Overall sentiment

• Many agree Python packaging is fragmented and confusing compared to ecosystems like Rust’s Cargo or PHP’s Composer.
• Some argue the situation “used to be simple” with just pip, and that successive tooling changes normalized breaking changes.
• Others push back: for many day‑to‑day projects, basic tools still work fine.

pip + venv vs “modern” tools

• A sizable group reports long‑term success with pip + venv (+ sometimes pip-tools or pyenv), treating venvs as disposable and using requirements.in + compiled requirements.txt.
• Critics say this workflow often fails teams in practice: missing locks, drifting transitive deps, production‑only failures, and extra homegrown scripts.
• There’s debate on whether “just nuke the venv and reinstall” is acceptable or wasteful and fragile.

Poetry, PDM, Hatch, uv, Rye, etc.

• Poetry has many fans for lockfiles, reproducibility, multi‑Python support, and overall ergonomics; detractors cite instability, breaking changes, and performance issues.
• PDM gets praise for being PEP‑compliant, playing well with pyproject.toml, and providing in‑project venvs.
• pip-tools is liked as a minimal layer for generating fully pinned requirements, though some dislike its own dependency bloat.
• uv is described as extremely fast and “transformative”; some already pair it with other tools, others think it’s not yet “prime time.”
• Rye is seen as a promising meta‑tool now using uv under the hood; it’s characterized as young but sane and fast.
• Hatch is mentioned positively but under‑explored in the thread.

Conda, Nix, and scientific/ML use

• Conda is called “best for ML” by some, but others share horror stories of ultra‑slow solving, broken envs, confusing channel priority, and invasive installs.
• A few strongly prefer Nix (sometimes via wrappers) as the “be‑all‑and‑end‑all” for reliable Python environments and non‑Python deps.

Reproducibility, security, and dependency graphs

• Strong consensus that pinning full dependency trees and using lockfiles is essential for long‑term reproducibility; simply “pull latest” is widely criticized.
• Concerns about frequent breaking changes, accumulating CVEs, and complex dependency graphs (including real-world cycles).
• Some advocate vendoring wheels into version control to avoid supply‑chain surprises.

Ecosystem design & philosophy

• Frustration that Python’s “one obvious way” ideal hasn’t held for packaging: multiple build backends, pyproject.toml variants, and shifting “official” tools (distutils removal, build/install, etc.).
• Comparisons with Cargo, npm, Composer, Docker, and even Deno highlight trade‑offs between single binary builds, global vs local deps, and language vs OS package managers.

Coal Phase-Out and Natural Gas Shift

• Alberta’s grid is now coal-free, but most commenters note it has largely shifted to natural gas (“methane”) rather than to low-carbon sources.
• Some generation is also backed up by oil-derived fuels in peak situations, though others dispute how widespread that is.
• Several people see this as a modest improvement (less CO₂ and particulates than coal) but not a real decarbonization.

Emissions Debate: Gas vs Coal and Methane Leakage

• Multiple comments stress that methane leaks can make gas power much worse in CO₂-equivalent terms if leakage rates are high.
• One side argues leaks are small and flaring is common, so gas remains substantially better than coal per kWh.
• Others cite studies suggesting ~5–10% leakage of gross production is plausible, which would erode or eliminate the climate advantage.
• There is skepticism about industry self-reported leak data.

Alberta Politics and Renewable Policy

• The provincial government is described as strongly aligned with oil and gas and hostile to renewables.
• A 7‑month pause on new renewables and subsequent “viewscape” and land-use restrictions reportedly killed or scared off large solar and wind investments.
• Commenters say Alberta previously had minimal red tape for grid-scale solar; that advantage is seen as squandered.

Renewables Potential, Grid, and Storage

• Alberta is said to have the best combined wind and solar resources in Canada and access to hydro-heavy British Columbia via interties.
• Some argue Alberta could reach ~70% renewables without significant storage, purely via overbuild and geographic diversity.
• Others emphasize winter peaks (e.g., −30°C evenings) and low winter sun, arguing storage and/or dispatchable backup (gas, possibly hydrogen, pumped hydro, etc.) remain essential.
• There is debate over the practicality and cost of long-duration storage (batteries vs pumped hydro vs underground hydrogen).

Economic Role of Oil Sands and Other Sectors

• Oil sands are described as extremely carbon-intensive (about 2.2× conventional oil per barrel) and responsible for significant petcoke exports burned abroad.
• Estimates in the thread: tar sands ~1.7% of Canada’s GDP but roughly one-third of Alberta’s; mining/oil/gas ~8% of national GDP.
• Several comments push back on the idea that “Canada’s economy is wholly dependent” on tar sands, noting large roles for manufacturing, services, and real estate.

Global Context and Fairness Arguments

• Some Canadians express frustration that India and China are still increasing coal use.
• Others counter that Canada’s per-capita and historical emissions are far higher; China and India are poorer, still industrializing, and rapidly building renewables.
• Several argue rich countries should both decarbonize faster at home and help finance clean energy in developing nations.

Xpra Use Cases and Features

• Used to run remote X11 applications as if local, with persistent sessions that can be detached and reattached (e.g., long‑running browser on a headless box, apps in VMs, “newer than distro” software in a headless VM).
• Seen as a way to approximate Qubes-like compartmentalization using VMs plus Xpra, though likely less secure; individual features can be disabled for untrusted servers.
• Appreciated for seamless window integration compared to full remote desktops like Chrome Remote Desktop.
• Provides an HTML5 client for running remote apps in a browser.
• Has tooling like run_scaled for scaling X11 apps, though some distros ship older Xpra versions missing this.

HiDPI, DPI, and Mixed-Resolution Issues

• One complaint is lack of HiDPI support; others argue DPI should be handled by X clients/servers, not Xpra itself.
• More detailed responses note Xpra acts as both server and client, so it must manage DPI; if misconfigured, apps assume 96 DPI and look wrong on hi‑res displays.
• Mixed DPI (laptop + low‑DPI external monitor) remains tricky; X11’s RANDR can expose per‑monitor DPI, but not all toolkits (notably some GTK versions) use it properly.
• Some mention Xpra needing a patched dummy X driver for correct DPI handling, and that distro packages may lag.

Security Considerations

• Over SSH, main risk highlighted is passing passwords on the command line; SSH keys with agents are recommended.
• X11 itself is described as fundamentally insecure (any client can spy on/inject into others), whereas Xpra can provide a more controlled boundary than plain X forwarding.
• A detailed security document is referenced for deeper analysis.

SSH Integration and UX

• The GUI’s SSH support is criticized as weak; defaulting to Paramiko breaks existing OpenSSH setups (jump hosts, identities, multiplexing) unless --ssh=ssh is used.
• Defenders argue Paramiko enables integrated GUI prompts, better cross‑platform handling, and richer error reporting than spawning ssh as a subprocess.
• Workarounds include wrapper scripts, per‑session config files, or changing global/user Xpra config to restore OpenSSH as default, though some see this as too complex and emphasize that defaults matter.

Comparisons and Alternatives

• Xpra is compared with many remote solutions: NoMachine, x2go (NX v3), NICE DCV, RustDesk, MeshCentral, xrdp, KRDP, gamescope, winswitch, and others.
• NoMachine and NICE DCV are praised for “local feel” and performance; Xpra is still valued for per‑window remoting and persistence.
• GPU‑accelerated encoding (e.g., NVENC) with client GPU decoding is noted as transformative for latency and perceived performance; some use Xpra in such setups.

X11 vs. Wayland Meta‑Discussion

• One branch argues that on Linux, native Wayland + waypipe is preferable to Xpra if all systems are Wayland‑based; Xpra remains useful for X11 and cross‑platform.
• Broader debate covers:
  • Whether X11 is truly “deprecated” or just “finished but still maintained.”
  • Wayland’s long, contentious rollout, initial lack of essential features (screen sharing, remote desktop, window positioning, non‑integer scaling, proper video/game support), and proliferation of compositor‑specific extensions.
  • Security and architecture trade‑offs: X11’s “mechanism, not policy” and easy compositing vs. its lack of isolation; Wayland’s stricter policy and sandboxing but more bikeshedding and fragmentation.
  • Ongoing gaps in Wayland for accessibility (screen readers), video capture/cameras, and certain gaming/Vulkan use cases, with some suggesting Xorg still works better in practice.

Other Side Topics

• Some users use rsync or Syncthing to sync entire Firefox profiles instead of relying on Firefox Sync, as a crude but effective way to keep browser state aligned across machines.
• Fragmentation in Linux remote desktop and graphics stacks is seen by some as a sign of a flexible ecosystem, by others as churn and lack of long‑term interface design.

Automatic Downloads vs. User Consent

• Many see silent downloads and execution of binaries/LSPs (language servers) as a serious violation of user trust, especially for untrusted code.
• Others argue prompts for each tool would be unbearable and prefer a smooth, “it just works” experience.
• Several suggest middle-ground options: one-time global choice (“yes/no and remember”), per-workspace trust, install-time setting, or compile-time configuration for distro builds.

Security, Supply Chain, and Trust Boundaries

• Key concern: opening a project with malicious npm packages or language tools could execute arbitrary code without the user realizing.
• Comparisons are drawn to supply‑chain attacks (e.g., xz) and the lack of guarantees that GitHub releases match source.
• Some argue that everyone already draws a trust line (OS packages, Vim plugins, VS Code extensions), while others insist defaults must be “offline by default” or tightly controlled.
• Corporate and high‑sensitivity environments especially object to unvetted network access and automatic installs.

Comparisons to VS Code and Other Editors

• VS Code is criticized for popup “spam,” telemetry, and network‑unrestricted extensions, but also praised for explicit consent prompts and workspace trust.
• Some like that Zed previously had strong built‑in language support without extra setup; others already disable LSPs entirely or rely on AI autocomplete.
• Several users cite alternatives: Vim/Neovim (with Mason/ALE), JetBrains IDEs, Sublime, Kate, and distro‑managed tools.

Zed Team’s Explanation and Future Plans

• A Zed co‑founder explains current language support: built‑in, pre-bundled extensions, and user-installable extensions.
• States that auto-downloads are currently vetted and sourced from known projects, but agrees consent is needed and plans to:
  • Add prompts before installing executables.
  • Eventually move all language support to installable extensions for user choice.
• Some appreciate the transparency and pace of development; others respond that “small team / pre-1.0 / free” does not justify weakening security or privacy.

Perceived Softness of the Plea Deal

• Many see the plea as a “slap on the wrist”: $240M fine (0.3% of annual revenue) and a monitor, with no trial and no executives jailed.
• Comparison to other cases (VW diesel, financial crisis, Alex Jones, McDonald’s coffee) leads commenters to say lethal corporate misconduct is punished far less than non-lethal or individual misconduct.
• Some note the plea avoids discovery and public airing of internal documents that might reveal deeper problems.

Corporate vs Individual Accountability

• Strong sentiment that “companies don’t commit crimes; people do” and that focusing on corporate guilt lets executives and boards escape consequences.
• Others counter that limited liability is core to modern capitalism and entrepreneurship, and automatic personal liability for all corporate crimes would be a “perversion of justice” and economically damaging.
• There’s extensive debate over whether CEOs and boards should face strict criminal liability for systemic safety failures, even if they claim ignorance.
• Existing frameworks like Sarbanes-Oxley, RICO, and “willful blindness” are discussed as analogues but seen as weakly enforced.

Regulators, Culture, and Systemic Factors

• Commenters blame a long-term shift from engineering-first to profit-first culture at Boeing, with incentives to cut safety and testing.
• FAA/NTSB and self-certification are criticized; some say U.S. regulators treated crashes in developing countries and foreign carriers less urgently.
• Others argue pilot training standards outside the U.S. and airline maintenance also contributed, though many reject this as victim-blaming or racially biased.

Proposed Reforms and Punishments

• Ideas include:
  • Much larger fines tied to revenue/market cap, potentially wiping out shareholders.
  • Nationalization, breakup, or forced leadership/board replacement.
  • Debarment from government contracts or aggressive use of procurement bans.
  • Personal criminal liability for executives for safety-critical design cultures, up to very long sentences or, in some countries, capital punishment.
  • Stronger whistleblower protection and shifting accountability from the “corporate person” back to human decision-makers.

Economic and National Security Constraints

• Many doubt the U.S. will meaningfully punish Boeing due to its defense role, jobs, export importance, and the duopoly with Airbus.
• Some argue this is effectively “too big to fail/jail” and amounts to economic blackmail; others warn that extreme sanctions could damage the wider economy and aerospace safety if mishandled.

Do edges get blunt and does it matter?

• Most agree metal edges do dull from snow, ice, grit, rocks, and handling.
• On hardpack and ice, sharp edges can make the difference between “scary vs fun” or “impossible vs controllable,” especially for carving and racing.
• Some skiers report little to no subjective difference even after tunes, especially on softer snow or at moderate speeds.
• There’s debate whether fine-tuning angles vs simple “fresh sharpness” is what’s really felt.

Conditions, terrain, and skier skill

• Edges matter far more on icy groomers, in the Northeast/“ice coast,” on man‑made or water‑injected race surfaces, and in steep ski mountaineering terrain.
• In powder, soft snow, or for slow “slide turns,” edge sharpness matters less.
• High‑level carvers and racers are very sensitive to bevels and sharpness; many casual and intermediate skiers skid rather than carve and may benefit from slightly duller, more forgiving edges.
• Park skiers often deliberately detune edges; halfpipe and high‑speed park riding may still want some grip.

Tuning practices and frequency

• Racers and race parents: edges and wax every few runs to every couple of days; very specific bevels (e.g., 0–0.75° base, 2–4° side).
• Recreational: from “once per season or less” to light daily touch‑ups with stones; consensus that frequent heavy filing shortens ski life.
• Backcountry: some see sharp edges as critical on steep icy slopes; others mostly tour in soft snow and rarely edge.

Home tuning vs shop services

• Simple maintenance with diamond and gummy stones is seen as manageable and effective once base/side angles are set.
• Full base grinds and angle changes are harder; some report “destroying” skis at home and prefer $40 shop tunes.
• Shops can also mis-tune (wrong angles), and repeated machine tunes consume base and edge material.

Wax, base structure, and other factors

• Many say edges and boots matter more for control than wax; wax and base structure matter for speed and preventing base drying.
• Structure and proper brushing after waxing can affect glide more than wax type in many cases.
• Fluorinated race waxes were effective but raise PFAS health concerns; now banned in FIS races.

Safety and other topics

• Binding release checks are highlighted as critical, especially on older gear.
• Some criticize the article for weak methodology and overemphasis on corrosion vs mechanical wear; others see it as useful for illustrating that polishing can restore edges without full grinds.
• Open/unclear: precise wear rate of edges under different conditions; how much of perceived difference is skill vs equipment.

Why fund Ladybird instead of Firefox?

• Many commenters are frustrated that there’s no way to directly fund Firefox development; donations go to the Mozilla Foundation, which doesn’t develop Firefox and explicitly funds advocacy and research instead.
• Paying for Mozilla side products (VPN, Pocket, etc.) is seen as an imprecise signal; users can’t ensure money goes to the browser rather than new “distraction” projects.
• Several argue Google’s search deal (and large revenue share) makes Mozilla structurally dependent on its main competitor and reluctant to accept user-directed funding.
• Some see Firefox as mismanaged and distracted by side projects and branding efforts, yet still the only major non–ad company browser.

Ladybird vs Servo and other alternatives

• A strong contingent urges funding Servo instead: Rust-based, rendering-engine only, actively developed, and currently underfunded compared to the hype and money around Ladybird.
• Some suggest an ideal future where Ladybird uses and helps fund Servo as its engine.
• Others point to hardened Chromium derivatives (e.g., ungoogled-chromium) as another practical option.

Language, memory safety, and browser design

• Large subthread debates C/C++ vs Rust for browsers.
• Concerns: browsers are massive attack surfaces; C/C++ memory bugs dominate serious vulnerabilities in existing engines.
• Counterpoints: OSes and current browsers are mostly C/C++; modern C++ with RAII is “good enough”; Rust and GC integration are complex; unsafe Rust may erode guarantees.
• Ladybird’s FAQ says C++ was inherited from SerenityOS and that a migration to a “successor language” is planned, with prototypes in multiple languages.
• Some see choosing C++ in 2024 as a red flag; others view it as pragmatic given tooling, expertise, and existing code.

Feasibility and timelines of a new engine

• Many are skeptical a from-scratch, standards-compliant browser can catch up; existing engines are the result of decades of work by hundreds of engineers.
• Others argue a clean-slate, independent implementation is exactly what the web needs and that if it proves impossible, that’s evidence the standards surface has grown too large.

Mozilla’s broader role and ads

• Debate over whether Mozilla is now primarily an ad-tech and subscription vendor rather than a browser steward.
• Some point to Mozilla’s own writing about the necessity of ad-funded “free” content; others note Firefox still supports strong ad-blocking.
• Several argue user donations, even if smaller than Google money, would at least align incentives with users instead of advertisers.

Corporate vanity gTLD gold rush & ROI

• Many see the 2010s gTLD wave as an “enterprise gold rush”: big brands wanted .brand domains after seeing examples like .google or .mcdonalds.
• Over time, companies realized the ROI was poor and let many gTLDs lapse, leaving “ghost town” namespaces.
• Some argue it was defensive: better to own your .brand so no one else can, even if you rarely use it.

Costs, budgeting, and opportunity cost

• Application fee cited as ~$185k plus ~$15k/quarter ongoing, viewed as trivial for large enterprises but significant for smaller firms.
• Debate over whether such spending is justified versus better uses of marketing/security budgets.
• Side discussion uses car makers’ per-vehicle profit to show how easily large firms can absorb these fees.

Perceived value and real-world usage

• Many commenters rarely see these TLDs in the wild; when they do, it’s often SEO spam.
• Some feel gTLDs look like typos or scams and are especially bad for email; several report real services rejecting newer TLDs as invalid.
• A minority argues being a registry (not just a registrant) gives stronger, long-term control over critical domains and IP.

Technical and security considerations

• Thread covers DNS hierarchy, search domains, and why unlimited/flat TLDs might stress infrastructure and break assumptions.
• Security concerns around confusing TLDs like .zip and potential abuse of hostnames that look like filenames or local hosts.
• Dotless domains (e.g., using only the TLD) are largely forbidden by ICANN; browsers/search behavior further limits them.
• Libraries must constantly update from IANA and the Public Suffix List; some teams automate this due to frequent changes.

ICANN policies and governance criticism

• ICANN is criticized as turning new gTLDs into a “money grab” and doing little about TLD- and domain-squatting.
• Amazon and others are said to be “holding TLDs hostage” with little incentive to release them.
• ICANN’s process is described as bureaucratic and slow, with mailing lists full of procedural bickering.
• Linked ICANN PDFs reportedly use weak “black box” redactions that are trivially removable.

Specific examples and anecdotes

• Instances of both abandoned (.sncf, .wed issues) and active (.fage) branded TLDs.
• Internationalized TLDs via Punycode (Chinese, Arabic) are discussed.
• Nerdy side notes include extremely short email addresses at ccTLDs and internal “go”-style hostnames using search domains.

Article style and argument quality

• Many enjoyed the essay’s “sparkling” prose and found it one of the best things they’d read recently.
• Others saw it as over-dramatic, meandering, or nihilistic, with weak or unsubstantiated arguments wrapped in flashy rhetoric.
• Some dissected specific claims (e.g., “easier to imagine the end of the world than the end of the internet”) as confused, poorly defined, or attacking strawmen.

Is the internet “over” or just changing?

• One camp: the “old internet” spirit has largely died; public spaces feel enshittified, commercialized, and numbing.
• Counterpoint: the internet itself isn’t ending; it’s evolving. Private chats, Discords, niche forums, and small blogs now host much of the interesting activity.
• Several argue the essay mistakes decline of public social media and open-web spaces for the death of “being online.”

Nostalgia for the old web vs the “small web”

• Many long-time users miss the 90s/early-2000s era: smaller, geekier communities, more shared cultural references, easier sense of belonging.
• Others note that tastes and shared references naturally change with generations; some of the nostalgia is just aging.
• Multiple links and projects are shared around “small web” / IndieWeb-style discovery, personal blogs, and non-commercial search engines as proof that the old spirit persists off the mainstream platforms.

Commercialization, engagement, and burnout

• Strong consensus that ad-driven business models and growth-at-all-costs incentives have degraded user experience: recommendation slop, manipulative design, content optimized for metrics not value.
• Some frame this as a business-cycle arms race: early high-ROI phase → overcrowding → scams/manipulation → user burnout and pullback.
• Several describe personal disengagement from big platforms, smartphones, or algorithmic feeds, citing mental health, privacy, and reputational concerns.

Public vs private, openness vs fragmentation

• Shift observed from open forums and blogs to semi-private silos (Discord, Slack, Telegram).
• Pros: higher signal-to-noise, easier moderation, more safety.
• Cons: knowledge becomes fragmented and non-searchable; undermines early promises of an open, globally accessible web.
• Debate over whether smaller, semi-gated communities betray or actually preserve the original ideals.

AI, spam, and future trajectories

• Some note the essay predated the current AI wave; others cite newer essays and videos connecting AI to accelerated spam and “dead internet” dynamics.
• Opinions split between AI as another tool to fight enshittification (e.g., better filtering) and as a force that will flood the web with synthetic content and make public spaces unusable.