Hacker News, Distilled

LLMs and ffmpeg: complement or replacement?

• Many commenters now rely on LLMs to generate ffmpeg commands instead of searching Stack Overflow or manuals.
• LLMs are praised for turning natural-language tasks (“extract audio,” “make timelapse,” “remux with subtitles, clip 5–60s”) into working commands.
• Others report “overly complex” or incorrect commands (e.g., assuming unavailable codecs like libx264), stressing the need for human review and domain knowledge.
• Some argue LLMs are best for one-off tasks; anything going into a repo should still be reviewed by someone who understands codecs, containers, and filters.

Complexity, learning curve, and reference habits

• ffmpeg is widely seen as powerful but intimidating, with syntax that rarely “sticks” unless used daily.
• Several users maintain personal cheat-sheets, scripts, or shell histories to remember common patterns.
• Comparisons are made to regex and CSS: invaluable if used frequently, not worth fully memorizing if used sporadically.
• A few posts outline mental models: order-dependent CLI; key flags for inputs, codecs, stream mapping, filters, timing (-ss, -t).

Tools, wrappers, and GUIs

• Multiple helpers are shared: shell functions (helpme, please), CLI tools (llm cmd, gencmd, llmpeg), and small web GUIs that generate ffmpeg commands.
• Some prefer GUIs like Handbrake or LosslessCut for encoding and cutting, especially when visual inspection matters.
• Libraries like ffmpeg-python and ffmpy are used to construct pipelines programmatically; others prefer GStreamer for more explicit pipeline modeling.

Hardware acceleration and quality

• GPU encoders (e.g., NVENC, Videotoolbox) give big speedups for batch or real-time work but are repeatedly reported to produce lower quality or larger files than software encoders (e.g., x264) at the same bitrate.
• Hardware encoding is described as “good enough” for streaming/transcoding but not ideal for archival or high-quality outputs.

FFmpeg by Example site: value and critiques

• Many appreciate “X by Example”-style resources as LLM training fodder and human references.
• Critiques include: random top example, unclear ordering, a broken “print text file” example on newer ffmpeg versions, and an unfinished “try online” feature.
• Suggestions include better organization, updating outdated commands, adding more practical scenarios (splitting/concatenating, subtitle handling), and possibly an ai.txt to simplify LLM ingestion.

Release features and general reaction

• Major additions: online RAIDZ expansion, faster dedup, Direct IO (ARC bypass), optional JSON output, and much longer filename support.
• Many users see RAIDZ expansion as a long‑awaited, “huge” quality‑of‑life feature, especially for home/hobbyist NAS setups.

RAIDZ expansion: behavior and caveats

• Expansion adds disks to an existing RAIDZ vdev online while maintaining redundancy and being resumable.
• Old blocks retain their original data/parity ratio; only new writes use the wider layout. This can leave the pool less space‑efficient than a freshly created wider RAIDZ.
• Some consider this inefficiency minor and acceptable; others see it as a “huge caveat” for home users who grow arrays over time.
• Workarounds to “re-layout” data: delete snapshots and rewrite in place, or use zfs send/receive within the pool. Both lose reflink-based deduplication.
• You still cannot shrink a RAIDZ vdev or remove a RAIDZ top‑level vdev; expansion is one‑way.

Vdev removal and reshaping vs other systems

• ZFS can remove some top‑level vdevs (typically mirrors) by copying their contents into free space and redirecting reads, but not RAIDZ vdevs yet.
• Other stacks (Windows Storage Spaces, mdadm+LVM, btrfs, bcachefs) can add/remove devices and reshape arrays more flexibly, sometimes with automatic rebalance.
• Debate: traditional RAID reshape is easier but can handle corruption poorly; ZFS emphasizes correctness and edge‑case handling over flexibility.

Encryption and Direct IO

• New features are said to be mostly orthogonal to native encryption; known issues remain around non‑raw send/receive of encrypted datasets.
• A Linux kernel API change limiting access to SIMD instructions forced ZFS to provide its own equivalents; performance was impacted temporarily but encryption correctness was not.
• Direct IO is aimed at workloads with their own caching (e.g., databases on fast NVMe). It avoids extra copies through ARC and may significantly help synchronous IO.

Performance, caching, and NVMe

• ARC vs Linux page cache interaction is discussed; ZFS already flushes the lower‑level buffer cache to avoid double caching.
• Settings like txg timeout and vdev queue limits can strongly affect small synchronous write amplification and overall throughput.
• L2ARC now persists across reboots, making SSD caching more useful for desktops (e.g., Steam libraries).

Home/desktop usage and comparisons

• Many use ZFS at home for: end‑to‑end checksums and scrub, snapshots and easy rollbacks, send/receive backups (including to removable/offsite disks), compression, and encryption.
• Several emphasize that “enterprise disks”, ECC, huge RAM, or many‑disk arrays are not hard requirements, though ECC is considered beneficial for any filesystem.
• Compared to btrfs, commenters describe ZFS as more mature and predictable, especially for parity RAID; btrfs is often recommended only for single‑disk or RAID1.
• bcachefs is noted as promising but still missing key features (full erasure coding, send/receive, complete scrub) and not yet widely trusted for mission‑critical data.

Licensing and platform support

• CDDL/GPL incompatibility keeps ZFS out of the mainline Linux kernel; ZFS remains a separate module with some friction on fast‑moving distros.
• Relicensing is described as legally and practically difficult due to many contributors and Oracle’s limited involvement with OpenZFS.
• Windows and macOS ports of OpenZFS exist; Windows also offers Storage Spaces + ReFS as a partially ZFS‑like alternative, with different trade‑offs.

Perception and Media Coverage of Sikhs

• Several commenters notice a wave of very positive stories (Reddit, HN, wildfire relief) and wonder if it’s organic or reputation management.
• Others suggest recent alleged Indian state assassination/attempts on Sikh activists in Canada/US have increased Western curiosity and sympathy, motivating Sikhs to educate neighbors.
• In the UK and Ireland, Sikhs are described as long-visible with a generally positive reputation (e.g., police and soldiers wearing turbans).
• Some warn that short social‑media clips with flattering captions can be effective propaganda, potentially overstating “the Sikh community” role based on little evidence; others respond that named Sikh charities (e.g., Khalsa Aid) are indeed behind many efforts and that not all Sikhs are visually identifiable.

Langar: Practice, Purpose, and Lived Experience

• Many recount positive first‑hand experiences of langar at gurdwaras, universities, and in city centers: free, good‑quality vegetarian meals, no questions asked, no proselytizing.
• Langar is framed as a practical expression of equality, historically challenging caste by seating everyone together. Some note it remains “revolutionary” when it crosses class lines, like a universal soup kitchen.
• Commenters emphasize scale and organization: thousands fed daily at major gurdwaras, largely via volunteer labor, with some automation.
• Cultural notes: you don’t need to attend worship to eat; head‑covering is required inside (which some find uncomfortable); not wasting food and washing dishes are considered important forms of service (sewa).

Comparisons with Other Religious Feeding Traditions

• Multiple participants compare langar with Hindu “prasad”/annadanam.
• One side claims similar practices predate Sikhism in Hinduism and are widespread; they cite large Hindu operations feeding tens or hundreds of thousands and NGOs like Akshaya Patra.
• Others argue prasad is usually a symbolic bite, not a full open meal; claim only a small fraction of temples offer food at langar‑like scale, and that Sikhism makes such service more central/mandatory.
• Separate comparisons highlight how some Christian charities attach evangelizing “strings,” while langar is experienced as service without conversion pressure.

Politics, Violence, and Diaspora Activism

• Discussion touches on Operation Blue Star, the Khalistan movement, and alleged Indian involvement in killings of Sikh separatists abroad.
• Some liken Sikhs to Kurds as minorities threatened in their homelands who therefore align strongly with Western states and present as “model immigrants.”
• Others push back, stressing differences in history, that armed Sikh insurgency is mostly past, and that diaspora separatism is a minority position distinct from everyday religious service.

Education and Public Awareness

• Several US commenters say Sikhism was barely or never covered in school; awareness came from family or local festivals, often limited to recognizing turbans.
• UK/Ireland posters describe Religious Education curricula that explicitly include Sikhism, and policy changes (e.g., uniforms) accommodating Sikh practices.
• One thread recalls post‑9/11 cases where Sikhs were attacked by people intending to target Muslims, illustrating widespread ignorance.

Attitudes Toward Idealizing Any Community

• Many comment on consistently positive personal experiences with Sikhs, sometimes calling them “the nicest” people they’ve met.
• Others caution against idealizing any group, citing Sikh political dysfunction in Punjab or broader human tendencies toward tribalism.
• Sikh commenters themselves stress theological emphasis on equality (“sarbat da bhala”), service, and moderation, while acknowledging internal political problems and a historical martial dimension.

Understanding the “DoubleClickjacking” Technique

• Core idea: get the user to commit to two clicks.
  • First click is on an overlaid fake UI (e.g., “double‑click here” / CAPTCHA / form button).
  • That overlay closes after the first click, so the second click lands on a sensitive button beneath (e.g., OAuth “Allow”).
• Variants discussed:
  • Doesn’t need literal “double‑click” wording; could be “click once, then confirm.”
  • Possible adaptation using keyboard+mouse (e.g., command-click listening to keydown).
  • Could be wrapped in rage‑click scenarios or clicker‑style CAPTCHAs.

How Common Is Double‑Clicking on the Web?

• One side: double‑clicking on websites is “extremely uncommon” and feels suspicious.
• Others strongly disagree, citing:
  • Less‑technical users who double‑click almost everything, often due to poor understanding of focus.
  • Habits transferred from desktop file explorers.
  • Frustration with slow UIs leading to repeated clicks.
  • Real uses like Google Drive folder navigation, text selection, and layout shifts on sites like YouTube.
• Worn or faulty mice that emit accidental double‑clicks are mentioned as another real‑world source.

Feasibility, Timing, and Preloading

• Concern: exploit seems to rely on near‑instant page loads.
• Counterpoints:
  • Attacker can preload target pages in background tabs.
  • The visible page can delay the “now click again” step until it detects the target is ready, e.g., via a loading spinner.
• Some viewers found the demo unclear and questioned whether it showed a real compromise or just normal auth flows.

Novelty and Relationship to Existing Attacks

• Multiple comments frame this as a variant of long‑known clickjacking/UI‑redressing tricks (bait‑and‑switch clicks, bouncing ads, etc.), not fundamentally new.
• Reference to prior clickjacking against major sites and related CAPTCHA‑style social engineering.

Proposed Mitigations

• Site/app level:
  • Disable critical buttons when the tab is hidden; re‑enable only after a short delay when visible/focused.
  • Add confirmations/CAPTCHAs for high‑risk actions.
  • Avoid taking actions immediately after layout shifts.
• Browser/UX level:
  • Suggestion to ignore clicks for a short time after focus changes or when UI elements newly appear or move.
  • Firefox dialogs delaying button activation cited as partial prior art, though some fear impact on power users.

Broader Security & UX Themes

• Criticism of popups/tabs being able to rearrange window layouts, though some argue this exists for legacy web‑app workflows.
• Several participants mitigate risk personally by disabling JavaScript by default, using NoScript/uBlock, or Firefox containers.
• Irony noted that the article page itself uses intrusive smooth scrolling/scrolljacking, which many find unusable or motion‑inducing.

Overall reaction

• Many commenters see the early results as predictable: make driving more expensive and some people stop, with visible reductions in gridlock and faster buses.
• Others are skeptical about fairness, measurement, and whether $9 is enough to change behavior meaningfully.

Perceived benefits

• Reported faster bus speeds and smoother traffic are seen as strong validation, especially for buses that used to be “at the behest of insane traffic.”
• Several expect a virtuous cycle: with fewer cars, cities can expand dedicated bus lanes, bike lanes, and frequency, further improving transit.
• Reduced congestion is linked to better air quality, pedestrian safety, and potentially faster emergency response.
• Some view congestion pricing as correctly “internalizing externalities,” shifting costs from urban residents to drivers, especially suburban commuters.

Equity and access concerns

• Critics argue this functions as a “commute tax” that richer drivers can absorb but poorer commuters and patients (e.g., daily cancer treatments) cannot.
• Public transport is often impractical for people with serious medical conditions; some call for explicit medical exemptions or free/discounted key bus routes funded by the tolls.
• Others counter that a modest fee that discourages only a small fraction of trips can substantially improve travel times for everyone, including low‑income transit users.

Data quality and measurement

• Questions about cherry‑picking bus routes (e.g., B39) for best‑case improvements; defenders frame them as “poster child” examples, not necessarily outliers.
• One commenter notes comparisons to a prior January may be distorted by layoffs; others reply that NYC employment is actually up.
• Weather (recent snow and cold) is flagged as a possible confounder.

Revenue and pricing structure

• Back‑of‑the‑envelope calculations in the thread suggest inconsistencies between reported reductions, trip counts, and projected $500M/year revenue.
• Explanations offered: different rates for personal cars, taxis, and trucks; discounts and caps; possible toll fraud; and political tendencies to misestimate tax revenue.
• Revenue is reported as earmarked for capital improvements (trains, elevators, infrastructure), not operating subsidies, which some see as a missed chance to directly offset burdens on poorer riders.

Road space, cars, and urban form

• Strong current runs against car‑centric design: claims that city land devoted to roads and parking is “massively subsidized” and inefficient, with calls to raise charges until private car use in dense cores is rare.
• Counterarguments emphasize that roads long predate cars, that cities rely on them for logistics and emergency access, and that even transit‑rich places (e.g., Dutch cities, Tokyo) have high car ownership because people value the convenience and privacy.
• Multiple detailed sub‑threads discuss how to serve deliveries and emergency vehicles with narrower streets, banned on‑street parking, wider sidewalks that can take an ambulance, bike lanes sized for emergency vehicles, and tram rights‑of‑way.

Political and practical feasibility

• Commenters note that similar schemes have stalled or been politically costly in places like San Francisco and Vancouver.
• Some argue congestion pricing only makes sense where public transit is already “decent”; others respond that such policies are also a tool to push mode shift and justify transit upgrades.

Alternative ideas and side notes

• A thought experiment proposes “air traffic control for cars”: real‑time block‑level movement permits to keep vehicle density below a threshold.
• There is debate over whether cities should eliminate parking lots in favor of remote storage for cars (especially self‑driving fleets), with concerns this could instead flood roads with circulating empty vehicles.
• Personal anecdotes in the thread point to noticeably quieter streets and more pleasant biking conditions since pricing started, but some wonder if effects will persist into summer.

License choice and “open source” labeling

• Repo is under Creative Commons Attribution–NonCommercial (CC BY‑NC), explicitly not an OSI-approved open-source license.
• Many argue this is “source-available,” not open source; CC licenses (especially NC) are seen as a poor fit for software.
• Some object to calling it “open source” in the README and original HN title; others say “open source” should mean simply “source is visible,” but are pushed back with OSI/FSF/DFSG definitions.
• Suggestions include relicensing under GPL/AGPL, EUPL, MIT, or Apache to align with FOSS norms, especially since the product is winding down.

Non-commercial clause and ambiguity

• NC terms are criticized as vague: unclear what counts as “commercial use,” particularly for internal use by for‑profit companies, SaaS hosting, or paid education.
• Some interpret NC as allowing internal deployment but forbidding selling access; others cite CC’s own guidance and a German court case to argue that most organizational use is commercial.
• Several commenters say they would avoid using this code in any serious context due to legal uncertainty and incompatibility with GPL and similar licenses.

Acquihire and competitive concerns

• Notion has acquired the Campsite team; many infer the NC license is to avoid enabling competitors while still publishing the code.
• This is seen as rational from Notion’s perspective but disappointing for those hoping for a true community fork.

Impact on users and trust in SaaS

• Former or potential customers feel “rug-pulled”: service shut down with a short migration window, then code released under a license that likely prohibits commercial self‑hosting.
• This fuels broader skepticism toward closed or VC‑backed SaaS and strengthens arguments for choosing real open-source tools upfront.

Educational value and codebase interest

• Despite licensing issues, several people appreciate access to a modern, production Rails codebase as a learning resource.
• Some say a read‑only repo might have matched that educational intent more clearly than accepting limited PRs.

Alternatives and general reflections

• Commenters recommend existing OSS chat/project tools (e.g., Zulip, Matrix/Element, Mattermost, Nextcloud Talk, IRC) as safer long‑term bets.
• There is debate over whether open source is really about “free labor” vs. mostly paid development, and whether the community’s expectations around reciprocity are reasonable.

Overall framing

• Many note that children riding transit alone used to be normal in Western cities too; the puzzle is why it stopped there rather than why it persists in Japan.
• Several see Japan as unusually safe and high‑trust, with broad social support for kids’ independence.

Safety, crime & fear

• One camp: real risks in Western cities (crime, abuse, erratic drivers, mentally ill homeless, “cultural diversity” lowering trust) justify parental caution.
• Counter‑camp: objective crime has fallen in many cities; what changed is fear and perception, not actual risk.
• Car danger (fast, distracted drivers) is cited as a bigger risk than kidnapping or assault on transit.

Parenting norms, CPS & social pressure

• Stories of parents arrested or investigated for letting kids walk or ride alone; fear of being reported to social services is a strong deterrent.
• Some argue expanded child‑protection bureaucracies target “easy cases” of independent kids rather than dangerous households.
• Several suspect rising parental workload and expectations (constant supervision, chauffeuring, enrichment) contribute to low birth rates and reduced child autonomy.

Child independence & development

• Multiple anecdotes: kids as young as 7–9 competently using public transit in various countries.
• View that independence is a skill built through experience, not age; gradual exposure (buy tickets, track stops, handle mistakes) is recommended.
• Commenters praise Japanese schooling ideals of autonomy, responsibility, and effort‑focused praise; seen as fostering internal motivation earlier.

Urban design, transit & infrastructure

• In Japan (and some European cities), transit is used by all ages, stations have staff, and kids’ fare cards link to parents, making mistakes recoverable.
• Suburban US built form (car dependence, hostile roads, fewer pedestrians) makes unsupervised mobility genuinely harder.

Media, culture & trust

• US mass media blamed for monetizing fear, eroding trust, and amplifying rare child‑abduction stories into pervasive anxiety.
• Alternative theory: in affluent societies with basic needs met, people channel surplus energy into hyper‑regulating minor risks (“Del Boca Vista” hypothesis).

Drugs, policing & justice (Japan comparisons)

• Some credit Japan’s safety to harsh drug enforcement, strong borders, and tight social/financial penalties for crime.
• Others emphasize zoning that allows abundant housing, cheap transit, universal/child healthcare, and lower poverty as more important than punitive “tough on crime.”
• US already has very high incarceration; several argue more punishment hasn’t delivered safety and worsens recidivism.

Miscellaneous

• A Japanese TV show featuring very young kids on solo errands is discussed as illustrative but heavily supervised behind the scenes.
• Side debate on the phrase “begs the question” highlights tension between prescriptive vs descriptive views of language.

Immediate impact of the outage

• All Git operations (including SSH) returned errors; many couldn’t pull, push, or run GitHub Actions.
• CI/CD pipelines halted, breaking builds and deployments; some releases and Yocto/embedded builds were blocked.
• Multiple people initially assumed local misconfiguration (SSH keys, OS upgrades) and wasted time debugging before checking status.

---

GitHub vs. Git; centralization debate

• Several point out that Git is distributed, but workflows have re‑centralized around GitHub for convenience (PRs, issues, CI, releases).
• Some argue users clearly prefer professionally run centralized services over complex decentralized setups.
• Others counter that this creates fragility and lock‑in; outages should motivate more resilient, distributed approaches.

---

Self‑hosting and alternatives

• Alternatives mentioned: GitLab, Gitea, Forgejo, GitHub Enterprise Server, on‑prem Bitbucket.
• Experiences vary: some report self‑hosted instances with better uptime than github.com; others say self‑hosting is heavier, more complex, and usually less reliable at scale.
• Mirrors and backups are discussed: useful for resilience, but can cause complexity/conflicts around PRs, CI, and integrations.
• Some are actively planning or executing moves away from GitHub; others see the outage as too minor to justify migration.

---

Reliability, uptime, and status communication

• GitHub’s availability is perceived by some as “not great lately,” with recurring outages or jankiness (slow UI, flaky Actions).
• Discussion of SLAs: public numbers like 99.9% vs. observed incidents; concern that different features can each be down without SLA violation.
• Status page wording (“degraded performance”) is seen as downplaying a full failure of git operations; skepticism that status pages are fully honest.

---

CI/CD lock‑in and disaster recovery

• Heavy reliance on GitHub Actions raises questions: how to deploy hotfixes if Actions or git hosting are down?
• Some advocate keeping build logic in scripts/Makefiles and using CI only as a runner to ease migration and local execution.
• Suggested DR patterns: secondary self‑hosted CI/VCS, periodic testing of backups, “escape hatches” for manual deployments—though many suspect such fallbacks are rarely battle‑tested.

---

Regulation, risk management, and audits

• In regulated industries, auditors now ask for concrete plans for extended outages or forced vendor exits.
• Self‑hosting is one answer but adds overhead; others propose external backups, standards‑based tooling, and documented runbooks for reconstructing services from distributed git clones.

---

Decentralized/federated tooling and issue tracking

• Various decentralized/federated options appear: radicle, ForgeFed/ActivityPub support in Forgejo/Gitea, and git‑native issue tools like git-bug.
• Debate over whether email/mailing lists count as a “distributed bug tracker”; consensus that Git itself lacks a built‑in issue tracker, but its ecosystem can approximate one.

---

Human reactions and culture

• Many treat it as a “developer snow day” and joke about going outside or playing games.
• Others report genuine anxiety (e.g., briefly thinking they’d been fired when SSH access failed).
• The outage reinforces how central GitHub has become to daily development workflows.

Productivity claims and the 80/20 argument

• Central debate: can “LLM writes 80%, human fixes 20%” really yield 5x productivity?
• Critics say work units aren’t equal; the last 20% often contains the hard parts and consumes most effort.
• Others note coding is only a fraction of an engineer’s time; even big coding speedups may only slightly improve overall productivity.
• Some report 2–4x speedups on side projects, in rare cases much more, but emphasize this is task‑dependent.

Verification, debugging, and code quality

• Strong concern that verifying LLM code is harder than writing it, because you must reconstruct intent and logic.
• Reading/debugging unfamiliar code is inherently high mental effort; swapping “writer” for “reviewer of AI output” is not an obvious win.
• Some argue LLMs, when used within their complexity limits, produce code at least as good as weak developers or Stack Overflow cargo‑culting.
• Many fear a wave of low‑quality “AI slop” that overwhelms review capacity and worsens long‑term maintainability.

Cheating, education vs workplace norms

• Heated sub‑thread on whether using LLMs is “cheating,” particularly in university settings where assessment of individual understanding matters.
• In professional contexts, several argue tool choice is morally neutral; only code quality and policy compliance matter.

Where LLMs help most

• Commonly cited wins: autocomplete, boilerplate, small self‑contained functions, test scaffolding, repetitive refactors, summarizing specs/standards, and learning unfamiliar stacks.
• As primary code authors for complex, cross‑file changes, models are seen as flaky and easily overconfident; extensive tests and careful scoping are required.

Maintenance, legacy code, and intent

• Worries that AI‑written code will be poorly understood, with no recorded prompts or intent, amplifying the usual “legacy archaeology” problem.
• Counterpoint: legacy human code is already hard to understand; what matters is good requirements, tests, and review, not who typed the lines.

Economic and labor implications

• Doubts that individual engineers will capture productivity gains; more likely: fewer engineers, same or higher expectations.
• Some see large future demand for consultants to clean up AI‑generated messes.

Tooling, context, and marketing angle

• Discussion around context windows, RAG, and search over large codebases; consensus that surfacing the right context is crucial.
• Several note the article is from 2023 and functions as promotional material for a code search/AI assistant product.

Effect on housing and prices

• Many argue foreign non-resident buyers add demand to a largely fixed housing stock, inevitably pushing up prices and reducing availability for locals.
• Others see this as marginal compared with bigger drivers: immigration, zoning and permitting bottlenecks, slow construction capacity, and “treat housing as an investment” policies.
• Anecdotes from Palma (Mallorca) and Spanish cities describe large shares of housing owned by foreigners/Airbnbs, big price jumps, and loss of local language and community cohesion.

Role of foreign buyers vs. supply constraints

• One camp: foreign demand is a meaningful distortion, especially for second homes, luxury/tourist areas, and speculative vacant units; limiting it is legitimate protection for residents.
• Opposing camp: the root problem is lack of supply (zoning, bureaucracy, slow permits, weak construction sector); blaming foreigners is politically easy but misdirected and risks lost investment.
• Some note foreign capital can fund renovation of abandoned stock and boost construction jobs, though this may compete with locals for labor and materials.

Design, scope, and legality

• Clarifications: discussion suggests the 100% tax targets new purchases by non‑EU non‑residents, not retroactive seizures, and sits within a wider Spanish housing package (rent caps incentives, prefab housing, etc.).
• Several commenters doubt it will pass in current form; others say even proposing it may chill foreign investment.
• A linked analysis claims such a discriminatory tax likely violates EU rules on free movement of capital; others say interpretation is contested.

Loopholes and enforcement

• Many expect workarounds: using EU shell companies, nominee directors, or quick citizenship/PR in other EU states.
• Some argue EU authorities often enforce the “spirit of the law” and could eventually crack down on obvious avoidance structures.

Alternatives and complements

• Frequently proposed: land value taxes, strong vacancy taxes, and heavy taxation on multiple homes or short‑term tourist rentals (Airbnb) rather than on nationality.
• Others emphasize liberalizing zoning, accelerating permits, and building more (including modular/prefab) as the only durable affordability fix, possibly alongside limits on speculative or non‑resident ownership.

What Snyk Did and Cursor’s Response

• Snyk researcher published several NPM packages named after Cursor’s bundled extensions.
• Packages contained minimal code but exfiltrated username, hostname, working directory and eventually full environment variables to a remote server.
• A Cursor developer states Cursor never published those extension names to any registry, did not commission Snyk, and considers the move “pretty irresponsible.”
• Snyk staff in the thread and in a linked blog position this as security research into dependency‑confusion attacks, claim no malicious intent, and say no vulnerable behavior was found.

Ethics, Legality, and “Security Research”

• Many argue this crosses from white‑hat into grey/black‑hat:
  • No authorization from Cursor.
  • Public ecosystem used as the testbed, potentially impacting any developer.
  • Exfiltrating full environment variables is seen as unnecessary for a PoC and likely illegal in some jurisdictions.
• Others note incentives in bug‑bounty culture: reports without demonstrable impact often get ignored or underpaid, pushing researchers to collect real secrets.
• Several emphasize that “offensive research” should be done in isolated test environments, not in production ecosystems.

Trust, Geopolitics, and Founders’ Backgrounds

• Multiple comments highlight that Snyk was founded by veterans of an Israeli intelligence unit.
• Some participants say this alone justifies avoiding their products (comparing to distrust of Chinese/Russian tech).
• Others argue that:
  • Many countries’ veterans work in infosec.
  • Individuals shouldn’t be judged solely by nationality or prior mandatory service.
• Thread devolves at points into broader debates about Israel, state surveillance, and boycotts of Israeli tech.

NPM, Dependency Confusion, and Supply Chain Risk

• Discussion revisits dependency‑confusion attacks and NPM’s global namespace problems.
• Suggestions:
  • Use scoped packages (@company/pkg), private registries, or internal mirrors.
  • Vendor dependencies into source control or maintain internal mirrors for auditing diffs.
• Broader concern that NPM and other ecosystems (Python, NuGet) are rife with malicious or low‑quality packages and that systematic protection is weak.

Developer Defenses and Workflow Changes

• Many advocate stronger isolation:
  • Per‑project VMs/containers, LXD/LXC, devcontainers, remote dev, or separate OS users.
  • Stricter handling of API keys and .env files; concern that tools like Cursor may transmit env files to servers.
• Some propose OS‑level controls (SELinux, namespaces) and rigorous auditing/monitoring of third‑party code as long‑term mitigations.

Role of Native vs React Native Developers

• Many agree with Shopify’s emphasis that strong native iOS/Android engineers are essential for good RN apps.
• Common view: RN is a tool for mobile devs to avoid writing two separate native apps, not a shortcut to avoid learning native or to “just reuse web devs.”
• Teams mixing native mobile and web/JS expertise are seen as higher quality but also more expensive; RN isn’t the “cheap” option some expect.

Maintenance, Tooling, and JS Ecosystem Concerns

• Several complain about dependency churn, fragile tooling, and frequent breaking changes in the JS/React/RN ecosystem.
• Others push back, claiming most core JS libs are stable and asking for concrete examples.
• Maintenance cost and staffing profile (team size, skills, ability to absorb churn) are called out as under-appreciated decision factors.

Performance and the “<500ms Screen Loads” Claim

• The “sub‑500ms (P75) screen loads” claim is heavily debated.
• Critics say 500ms is far from “blazing fast,” especially if that’s P75, implying poor tail latencies; compare to UX research suggesting ~100ms feels instant.
• Some argue it’s acceptable if it includes network round-trip, parsing, and rendering on mobile networks; others insist backend and DB latency should be far lower.
• There is disagreement over what “screen load” includes and how meaningful P75 is; several worry high p95/p99 values are being obscured.
• Some users report the Shopify app feels sluggish in practice, especially on Android; others say it feels “nice and speedy.”

Developer Experience and Productivity

• Hot reload and short feedback cycles are major reasons people like RN; long native compile times are seen as a serious drag on productivity.
• Some argue previous generations shipped fast native software without hot reload, while others say that ignores cognitive cost of constant context switching.

Cross‑Platform Alternatives (Expo, Flutter, Hotwire, etc.)

• Expo is praised for simplifying RN upgrades and native config via “continuous native generation,” though Shopify appears to be on bare RN.
• Flutter/Dart is frequently lauded for superior tooling and dev experience; critics note Flutter’s non-native widgets can feel “off.”
• Hotwire Native is mentioned positively as simpler and more stable for certain projects, contrasting with complex React maintenance.

User Experience and Quality Bar

• Many feel modern apps (web and RN) accept latency and jank that would have been unacceptable a decade ago.
• Some argue typical users care more about features and brand than raw speed; others see this as part of broader “enshittification.”
• Requests for basics like dark mode and better accessibility contrast with the engineering focus on frameworks and architecture.

Emerging Unionization & Worker Power

• Many welcome talk of unionizing JPMorgan staff, seeing it as a watershed if finance workers organize.
• Supporters say tech/finance workers were misled that unions kill high pay; now they see unstable jobs, layoffs, and want collective bargaining.
• Others suggest professional associations for “knowledge workers,” but pro‑union voices counter that without collective bargaining they lack leverage.
• Skeptics doubt unions can stop RTO or offshoring, but still see them as key to fighting unpaid overtime and arbitrary mandates.

RTO vs WFH: Productivity, Flexibility, and Life Quality

• A central theme: rigid 5‑day RTO is widely disliked; flexible hybrid (1–3 days in office) is seen as acceptable or ideal.
• WFH is framed as:
  • A “10%+ salary bump” via saved commute time and lower living costs.
  • Enabling parenting, sleep, errands, and community life that offices can’t compete with.
• Some say they are more productive and focused at home; others claim in‑office boosts their output, visibility, and social capital.
• Several argue the real value is flexibility, not pure remote.

Mentorship, Collaboration, and Career Development

• Strong concern that fully remote environments make it harder to onboard and grow juniors, who benefit from ad‑hoc questions, whiteboarding, and observational learning.
• Others say structured remote mentoring, pair programming, and good onboarding can substitute, but acknowledge it’s harder on seniors.

Suspected Motives Behind RTO

• Explanations offered include:
  • Sunk costs in office real estate and recent billion‑dollar builds.
  • Tax incentives tied to headcount in cities.
  • Management preference for control, visibility, and “asses in seats.”
  • Using RTO as “soft layoffs” to reduce headcount and suppress wages.
• Some see broader pressure from cities and real‑estate interests to keep downtowns viable; others call this conspiratorial and insist execs simply (rightly or wrongly) believe RTO improves productivity.

Cities, Housing, and Commutes

• Many resent unpaid commute time, high urban rents, and being forced to live near expensive hubs.
• Some argue WFH could relieve housing crises by letting people live in cheaper regions; others worry that cities, services, and small businesses depend on centralized office workers.

Offshoring & Job Security

• A recurring fear: “If work can be done from home, it can be done from India.”
• Counterpoints:
  • Companies already offshore where they can; time zones, communication, and quality limit this.
  • Higher‑value work (ownership, product direction, critical thinking) is harder to replace with lower‑cost labor or AI.

Culture, Personality, and Office Design

• Extroverts and managers often value in‑person chats, spontaneous collaboration, and “being part of a team.”
• Many introverts and WFH fans say offices are noisy, poorly designed, and optimized for control rather than comfort.
• Several note that modern RTO often means commuting just to sit on Zoom calls, which they view as “the worst of all worlds.”

App update fallout

• Many owners say the new app made previously reliable systems nearly unusable: slow startup, missing speakers, failed playback, unresponsive or delayed volume/track changes, and frequent need to restart or reinstall.
• Some report being unable to set up or re‑set up older speakers at all, effectively “bricking” multi‑thousand‑dollar systems.
• A minority say the new app is faster and more stable for them, highlighting inconsistent behavior across networks and setups.
• Several users mostly avoid the app now, controlling speakers via AirPlay/Spotify Connect instead, or only using the app once for setup.

Legacy hardware, lock‑in, and trust

• Long‑time customers feel burned by:
  • S1 vs S2 split and dropped compatibility for some devices.
  • Past “recycle mode” that permanently bricked hardware for a discount.
  • New products (e.g., subs) not pairing with older, still‑supported bars.
• Many vow not to buy more Sonos, or tell friends not to, citing fear that future updates will strand expensive gear.

Technical and architectural criticisms

• Technical analysis (linked in thread) blames:
  • Moving local control from UPnP-style local APIs to encrypted, cloud‑mediated APIs and WebSockets, increasing latency and fragility, especially on flaky or high‑latency connections.
  • Replacing native UIs with JavaScript-based cross‑platform code.
  • Switching discovery mechanisms and relying heavily on mDNS.
• These changes are seen as prioritizing cloud control and potential subscription models over local-first reliability.

Alternatives and “dumb” setups

• Many recommend splitting “smart” from “audio”: passive speakers + amp + streamer (WiiM, Raspberry Pi/Snapcast, Logitech Media Server derivatives, Chromecast Audio/AirPort Express, Roon, Denon/HEOS, Bluesound, etc.).
• DIY and modular setups are praised for longevity, repairability, and avoiding vendor lock‑in, though acknowledged as more technical.

Business, UX, and leadership themes

• Commenters debate whether the CEO, board, or engineering leadership is most at fault; some see this as a classic case of enshittification and public‑company growth pressure.
• The debacle is frequently cited as a case study in:
  • Underestimating software/UX in a hardware company.
  • Shipping a massive architectural change without staged rollout or rollback path.
  • Sacrificing a once‑strong brand and loyal base for a risky platform pivot.

Affordability and price comparisons

• Many see $15 for 25 Mbps and especially $20 for 200 Mbps as extremely cheap relative to US market rates.
• Users report paying $65–$160/month for 75–400 Mbps in various US regions, contrasted with much cheaper, faster service in places like Prague and Japan.
• Consensus that many US prices—especially where there’s only one or two ISPs—are “gouging” relative to what’s technically and economically possible.

Is broadband a utility / natural monopoly?

• Strong argument that broadband behaves like a natural monopoly (high capex, right-of-way constraints, finite spectrum), similar to water or power.
• Others push back, claiming providers “can compete,” but critics respond that without last‑mile unbundling they usually don’t.
• Several comments say internet access is now essential infrastructure and should be regulated like a utility.

Mandated low‑income plans vs subsidies and vouchers

• Supporters: ISPs have taken public money for decades and operate de facto monopolies; forcing low‑income plans simply trims their margins and is appropriate.
• Skeptics: see this as market distortion and an unfunded mandate that will be passed on via higher prices to other customers and deter new entrants.
• Alternative proposals: direct vouchers or checks to households; explicit line‑item taxes to fund discounts; or taxing profits and subsidizing access transparently.

Municipal broadband and open access

• Multiple comments argue the real fix is municipal fiber or last‑mile networks with open access for competing ISPs.
• View that unfunded mandates risk entrenching incumbents, while city‑owned networks and co‑ops have shown they can offer gigabit for low prices.

Technical adequacy and quality

• Debate on whether 25 Mbps/200 Mbps is sufficient; some say 100 Mbps is plenty for streaming, others claim 200 Mbps is barely enough with certain providers.
• Reliability differences may stem from local network quality and home Wi‑Fi setups rather than raw plan speed.

Implementation details and risks

• Questions raised: definition of “low income,” treatment of Starlink and small ISPs, data caps, contract escape rights, service quality/latency, and build‑out obligations.
• Concern that capping price increases at 2% could cause underinvestment if inflation stays higher.
• Some worry providers will make these plans hard to find or unpleasant to use; others note the law includes taxes/fees in the capped price, which is seen as important.

Chemistry and Metabolism

• Many argue HFCS and sucrose are metabolically very similar: both end up as free glucose and fructose, and sucrose in acidic soda hydrolyzes before consumption.
• Key difference: typical HFCS in soda is ~55% fructose vs sucrose’s effective 50%; HFCS for baked goods can be ~42% fructose (less than sucrose).
• Some posters say this 5–8% difference is negligible; others counter that even small shifts in fructose load might affect long‑term metabolic regulation.
• Mechanistic points raised: fructose is processed mainly in the liver, can bypass key glycolysis regulation steps, and in high doses contributes to fatty liver and triglycerides.
• A meta‑analysis is cited suggesting HFCS raises inflammation marker CRP more than sucrose, but others argue overall evidence still focuses on total fructose/sugar intake, not source.

Taste and Sensory Differences

• One camp: in controlled conditions sucrose vs HFCS at similar ratios should taste the same; calls for double‑blind evidence.
• Others report clear subjective differences (e.g., US vs Mexican/European Coke; “drier,” less viscous, different “nutty” or “sticky” character).
• Explanations offered: differing sodium content, bottle material (glass vs plastic), water chemistry, and regional recipe tweaks, not just sweetener type.

Health, Obesity, and Public Health

• Broad agreement that excess sugar (of any kind) in a sedentary population is harmful: obesity, diabetes, fatty liver.
• Disagreement on whether HFCS is uniquely worse vs just a cheap vehicle enabling higher sugar levels in processed foods.
• Comparisons to “seed oil” debates: some see HFCS‑specific demonization as a distraction from overall ultra‑processed, hyper‑palatable diets.

Economics, Policy, and Corn Politics

• US sugar import tariffs and sugar price supports keep cane sugar expensive; heavy corn subsidies make HFCS cheaper.
• Result: industry shifts to HFCS, consumers arguably lose both via taxes and reduced choice.
• Some argue sugar is so cheap that subsidies barely affect consumer behavior; others note even small cost changes drive manufacturer reformulation (e.g., UK sugar levy).
• USDA, Congress, and SNAP funding are intertwined with farm policy, limiting political appetite to challenge corn interests.

Culture, Behavior, and Exposure

• Many non‑US commenters find American food “insanely sweet,” including bread, sauces, and fast food.
• Early-life exposure (school breakfasts, cereals, juice, sweetened snacks) and the “bliss point” engineering of sugar‑fat‑salt combinations are blamed for shaping preferences and overeating.
• Convenience and portion size (large sodas, ubiquitous junk food) are seen as major drivers regardless of the specific sweetener.

Allergies and Individual Reactions

• A few describe genuine corn/HFCS allergies or intolerances (hives, vomiting, migraines) requiring strict avoidance despite ubiquity.
• Others report differing gut or dental sensations from HFCS‑sweetened drinks vs sucrose, though this is anecdotal and unexplained.

Scale and role of WordPress

• Commenters cite numbers like ~44–40% of websites using WordPress and ~79% of web using PHP.
• Many note that WordPress powers everything from tiny blogs to large news sites, largely because it’s cheap, ubiquitous, and accessible to non-technical users.
• The massive plugin/theme ecosystem and availability of freelancers are seen as core moats.

Current conflict and governance concerns

• Thread centers on the dispute between Automattic/WordPress leadership and WP Engine, including lawsuits, blocking access to wordpress.org infrastructure, and trademark/API issues.
• A major flashpoint: Automattic cutting sponsored WordPress core contributions from ~4,000 hours/week to ~45 to “match” WP Engine’s contributions.
• Many worry that a single individual effectively controls wordpress.org infrastructure, user accounts, and project direction, creating a dangerous single point of failure.

Forking vs staying

• Some predict or advocate a major fork once a credible group or sponsor (e.g., a large company or major host) steps up and provides governance and plugin-compatibility.
• Others argue inertia, existing plugins, and user ignorance of the drama mean WordPress itself will likely persist; a fork may fragment rather than replace it.
• Concern that without a canonical fork, plugin compatibility and critical mass become messy.

Alternatives and migration experiences

• Many report moving or planning to move away: Hugo, Zola, Jekyll, Astro, Pelican, Grav, Kirby, Statamic, MediaWiki, Dokuwiki, ProcessWire, Strapi, Ghost, Craft, Publii, various wikis and static-site–plus-CMS setups.
• Multiple first-person reports of relatively painless migrations to Hugo or other SSGs for blogs/portfolios, sometimes with export tools.
• Others note most nontechnical users will not manage git/Markdown/CI; WordPress.com, Squarespace, Shopify, Wix, etc. still win on ease and integrated plugins/e‑commerce.

Static sites vs dynamic CMS

• Strong enthusiasm for static sites: simpler, cheaper hosting (GitHub Pages, Cloudflare Pages, S3), smaller attack surface, easy backups via git.
• Counterpoint: static sites can still be hacked via server or account compromise; they’re safer but not “unhackable.”
• Critics note static setups don’t solve comments, forms, forums, or e‑commerce without third-party services (iframes, external SaaS, comment systems like isso).

Technical and architectural debates

• Multiple comments argue PHP’s ubiquity and cheap shared hosting (LAMP, mod_php/FastCGI) are why WordPress succeeded; no other language currently matches that deployment simplicity.
• Some wish for a “spiritual successor” to WordPress, possibly in Rust/other stacks, but others argue ecosystem timing and PHP hosting are the real moat.
• Comparisons to Drupal: Drupal’s backward-incompatible jump from 7 to 8 is cited as a cautionary tale; WordPress’s strict backward compatibility is valued despite architectural messiness.

Security, reliability, and operations

• Longstanding concerns: WordPress core plus a “wild west” plugin/theme ecosystem creates large attack surface; many mention hacked sites and SEO spam.
• Some use WordPress purely as an authoring tool and then statically export to avoid runtime PHP exposure.
• Hosted WordPress.com or specialized managed hosts are seen as safer than self-hosted installs for non-technical orgs.

Open-source economics and “freeloading”

• One camp sympathizes with Automattic: claims they’ve invested huge engineering effort (thousands of hours/week) in core while commercial hosts profit, contribute relatively little, and even sue.
• Another camp counters that open-source inherently allows others to profit; WordPress exists at its scale only because of unpaid community work and permissive licensing.
• Debate over who is “rent-seeking”: some accuse commercial hosts of extracting value from community; others argue using legal and infrastructure leverage against competitors fits that label better.

Leadership behavior and mental health speculation

• Many commenters describe recent leadership behavior as erratic, petty, or vindictive (account deactivations, public feuds, doxxing allegations, odd UI stunts like the “pineapple on pizza” checkbox).
• There is speculation about burnout, personality issues, drugs, or investor pressure; others push back that armchair diagnosis is inappropriate and that this may simply be a deliberate, if poorly executed, power/play-for-profit strategy.
• Net effect: trust in project governance is eroding; agencies and businesses depending heavily on WordPress are reassessing risk and contingency plans.

AI replacing mid‑level engineers

• Many are skeptical that current AI can truly replace mid‑level engineers, especially in large, messy codebases with years of technical debt and poor documentation.
• Others argue that most enterprise software is simple CRUD and highly automatable; they see AI as capable of junior/mid‑level work already in many web contexts.
• Some interpret the claim as “AI makes each engineer 5–10x more productive,” not “one AI fully replaces one human.”

Nature of software work

• Several comments stress that “writing code” is a small, easy part of the job.
• Core work is: clarifying requirements with stakeholders, understanding legacy systems, managing dependencies and infrastructure, and debugging non‑obvious, cross‑system issues.
• AI is seen as helpful for boilerplate, unit tests, and code search, but far weaker at deep system understanding.

Impact on jobs and career ladders

• Concern that automating mid‑level tasks will hollow out the pipeline: fewer juniors hired, harder to train future seniors.
• Comparisons are made to other fields with long training pipelines (e.g., medicine) as a possible model, but it’s unclear how this will play out in software.
• Some think we’ll end up with far fewer engineers overall, all “above average,” directing fleets of AI agents.

Code quality, reliability, and security

• Reports of AI‑generated bug reports being hallucinated spam, and AI code introducing incidents and vulnerabilities.
• Some expect a boom for companies specializing in debugging, incident response, and “AI mistake fixing.”
• Anticipation of new roles: AI code reviewers, reliability engineers, “AI babysitters.”

Economic and ethical framing

• Multiple comments tie this to capitalism’s drive to cut labor costs and externalize harm, predicting a “race to the bottom” in working conditions.
• Others argue productivity gains usually lead to more work, not fewer workers, though possibly with worse bargaining power and pay.

Perception of Meta and AI hype

• Significant skepticism that claims aren’t just stock‑boosting hype, likened to the earlier “metaverse” pivot.
• Some note Meta’s history of big, mixed‑success bets; others argue founder‑CEOs may be visionary but still heavily incentivized to oversell.

Overall thread vibe

• Highly polarized: many advocate quitting X, others defend staying, some reject all social media.
• Site in question was “hugged to death”; users link to archived snapshots.

Reasons to quit X

• Feed quality: culture-war bait, crypto scams, outrage, heavy algorithmic “For You” interference.
• Ads and paid reach: complaints about pay‑for‑attention, blue‑check boosting, and reduced organic reach, especially when posting links.
• API and access changes: third‑party clients broken; non‑logged‑in access restricted.
• Political/personal concerns: X described by some as a far‑right echo chamber and propaganda tool, with particular criticism of current ownership’s politics and use of the platform to influence policy.
• Mental health and time: addictive design, doomscrolling, and liberation reported after quitting.

Arguments for staying on X

• Still seen by some as the broadest, most diverse “town square,” especially for sports and certain industries/regions.
• Users report success with heavy curation and tools to create high signal‑to‑noise feeds.
• Some view criticism of X as partisan or media‑driven, and praise its “free speech” direction.

Alternatives: Bluesky, Mastodon, others

• Bluesky:
  • Praised for Twitter‑like UX, no ads, fewer trolls, better self‑moderation (custom feeds, blocklists, moderation lists).
  • Runs on AT Protocol; some see potential for an ecosystem of interoperable apps and multiple relays.
  • Criticized as left‑leaning, an echo chamber, or “heavily censored”; others dispute this and highlight user‑controlled filtering.
  • Tools exist to help migrate follow graphs from X.
• Mastodon:
  • Feels calmer, more niche and engaged; UI and federation considered harder but manageable.
  • Some prefer its “vibe” over Bluesky’s “old Twitter” feel.
• Other: mentions of Nostr, Telegram, Facebook, TikTok→Xiaohongshu migration; none seen as perfect.

Echo chambers, moderation, and censorship

• Recurrent fear that “let’s quit X” movements just reseat people into ideologically sorted echo chambers.
• Disagreement over which platforms are biased or censoring which side; each side accuses the other of bad‑faith claims.
• Some argue unmoderated spaces inevitably devolve into extremism; others want maximal user‑side filtering instead of centralized control.

Deeper structural critiques

• Several claim the core problem is the short‑form, megaphone‑style format itself: it rewards outrage, team sports politics, and shallow takes.
• View that any Twitter‑like clone (Bluesky, etc.) will eventually replicate the same pathologies once it scales.

Motivations for Blogging

• Many see personal blogs as primarily for themselves: to clarify thinking, learn deeply, reflect, and maintain a “public notebook” or diary.
• Writing is framed as mental exercise and skill-building; explaining topics forces deeper understanding and exposes gaps.
• Several treat blogs as life or project journals they frequently consult later, sometimes finding their own posts via search.

Career, Brand, and Professional Benefits

• Blogs can serve as portfolios: evidence of technical skill, writing ability, and that you’re a real human in an LLM era.
• Some report tangible outcomes: job offers, consulting, speaking invitations, book work, clients, and easier interviews.
• Others say posts—even HN front-page ones—rarely translated into jobs or significant opportunities.
• Skepticism about “personal brand” culture is strong; many see explicit brand-building as exhausting, inauthentic, or low ROI unless you enjoy it or have a clear niche.

Audience, Distribution, and Traffic

• Common distribution: search engines, RSS, posting to HN/Reddit, link-sharing on social media, newsletters, and email.
• A number of writers ignore analytics and “finding readers” entirely; they’re content with small or unknown audiences.
• Others invest in SEO, repurposing content across platforms, POSSE (publish on own site, syndicate elsewhere), and mailing lists.
• There’s concern about algorithmic feeds downranking external links and the difficulty of organic discovery in 2025.

Content Types and Value

• Posts range from highly technical how‑tos and reverse‑engineering writeups to personal travel logs, essays, fiction, and reflections.
• Very specific, problem-solving posts often attract long-tail search traffic and appreciative emails years later.
• Many believe human, opinionated, non-SEO-optimized writing stands out amid AI/SEO “slop,” even if reach is limited.

Platforms, Ownership, and Landscape

• Strong support for owning one’s own space on the web (self-hosted or simple static sites) versus depending on centralized platforms that can change policies.
• Some prefer the simplicity and built-in distribution of platforms like Substack; others use alternative protocols (Gemini, Gopher).
• While traffic is generally harder to get than in the early blogging era, several argue that precisely because fewer people blog now, consistent, high-quality personal sites can still be influential.