Hacker News, Distilled

Headline numbers and “average” vs reality

• Commenters note the study’s ~$513/week and slight increase in hours translates to roughly $13/hour before expenses, contradicting platform claims of “$30/hour on average.”
• There is extended criticism of using averages in highly skewed, power‑law distributions; median or bottom‑decile metrics are seen as more honest.
• Several argue platforms use creative accounting (e.g., counting only “active” time) to inflate hourly earnings.

Net earnings after costs

• Many emphasize that gross earnings ignore fuel, maintenance, insurance, depreciation, and self‑employment taxes; some estimate net as low as ~$10/hour or worse.
• Examples from the US and Norway suggest that, after costs, full‑time gig work can land well below local median wages and near or below minimum wage.
• Some say it only makes sense as “beer money,” not as a sustainable livelihood.

Flexibility vs pay and worker classification

• A recurring theme: flexibility (choosing when/where to work) is the main appeal; some drivers report being happy with autonomy despite low pay.
• Others counter that “make your own hours” is overstated, as real earnings cluster around peak demand times dictated by the platform/market.
• Debate over whether gig workers are truly independent contractors if they can’t set prices; some see them stuck with the worst of both worlds (no benefits, no rate control).

Broader economic and policy context

• Some blame legislation like Prop 22 for cementing low‑protection status; others point to stagnant minimum wage, rising living costs, and inequality.
• There is discussion of CPI understating real inflation (housing, food), further eroding gig incomes.
• One thread argues gig work may suppress pressure to raise minimum wage.

Automation, immigration, and platform dynamics

• In SF, riders report switching to robotaxis and expect human drivers to “fight over scraps” as automation spreads.
• Several claim large shares of delivery drivers may be undocumented or using borrowed accounts, potentially increasing labor supply and pushing down wages; others challenge the evidence and assumptions.
• Some see gig apps as part of a “sinkhole” in the labor market, externalizing risk onto workers while platforms and investors capture value, even if many platforms have historically run at a loss.

Normative takeaways

• Viewpoints range from “don’t be a gig worker” to “it fills a useful niche for those prioritizing flexibility.”
• Many agree the core problem is less the existence of gig work and more inadequate social safety nets, high costs, and weak protections for low‑wage workers.

Pledge/Unveil and Sandboxing

• Many felt pledge/unveil deserved more prominence, calling them standout innovations.
• Clarified threat model: not distrusting the program itself, but limiting damage if it’s compromised mid-run by tightening syscalls and filesystem access after startup.
• Some argued sandboxing should be configured externally (like Docker) rather than in-app; others countered that developers understand their program’s lifecycle better than admins.
• Linux analogues (seccomp, Landlock) and unikernel ports were discussed; there was some confusion then correction about who inspired whom.

Security Mitigations and External Assessments

• The isopenbsdsecu.re site was cited as a detailed, if harsh, assessment: critical in tone but explicitly praising malloc, atexit hardening, and pledge.
• Concerns raised there about outdated packages (e.g., Firefox, Tor) were rebutted as outdated FUD, with references to active maintenance.
• Newer mitigations mentioned: mimmutable/mseal, execute‑only memory, BTI/IBT, and random-data sections (e.g., for RETGUARD).
• Some worry execute‑only on ARM conflicts with PAN; others argue OpenBSD’s priorities differ and EPAN support is coming.

Daily Use, Performance, and Hardware Support

• Several run OpenBSD daily on ThinkPads and some Dells, reporting solid stability but weaker power management and battery life than Linux.
• Performance views differ: some call it “incredibly slow”, others say only disk I/O and browsers (without GPU accel) are notably slower; SMT is disabled by default for security.
• Major limitations noted: no Bluetooth stack (removed for quality/security reasons), no HDMI audio, fewer ports. For some, that disqualifies it as a laptop OS; others accept wired peripherals and see this as a deliberate trade-off.
• Used successfully as a home router/firewall (pf, CARP, HAProxy), with console-based administration; a few GUI frontends exist but are niche.

Funding, Licensing, and Open Source Economics

• Debate over whether large companies using OpenSSH “owe” OpenBSD funding: permissive licensing grants total freedom, but many see an ethical duty to contribute to a shared commons.
• Some argue capitalism structurally favors taking without giving; others say reciprocity should be encoded via copyleft or commercial licensing, not moral appeals.
• Broader argument: open source both depresses some categories of paid work (no one paid to re‑implement JPEG, kernels, databases) and enables higher-level work and new products.
• Burnout and underfunding (e.g., XZ, OpenSSL/Heartbleed) used as evidence that relying on volunteer labor has real security costs.

Languages, Implementation, and Kernel Architecture

• Critique: a “security-obsessed” OS still written in C inherits avoidable memory bugs; suggestion to move userland or more components to safer languages.
• Pushback centers on: Rust’s heavy toolchain, POSIX compatibility gaps, incomplete 1:1 replacements for core utilities, and OpenBSD’s “base builds base” rule; also portability to obscure architectures.
• Alternatives like Zig or OCaml were mentioned but seen as immature or unsuitable (e.g., GC in kernels).
• Kernel locking: the historic “giant lock” is being steadily removed; network stack still has work in progress but performance has improved notably.

Choosing and Using OpenBSD vs Other BSDs

• For newcomers, FreeBSD is described as closer to Linux, with broader hardware support, ZFS, better performance, and more ports.
• OpenBSD is framed as the “correctness and security first” BSD, with excellent man pages and a tightly integrated base system, but with deliberate feature omissions and rougher edges for desktop use.

Text vs. Icons: Which Is “Better”?

• Many argue text is fundamentally clearer: we’ve spent years learning words; icons are often app-specific, ambiguous, and slower to decode for anything beyond a tiny set of standard symbols (play, pause, close, search, trash).
• Others push back on “strictly superior”: some users recognize icons faster and they save horizontal space, especially on crowded UIs or mobile.
• Several note that icons are fine for a handful of common actions; beyond ~5–10 actions, unlabeled pictograms become “mystery meat navigation.”

Discoverability, Learning Curve, and Cognitive Load

• Users describe hunting through monochrome toolbars (macOS Markup, Pixelmator, Obsidian, JetBrains IDE redesign) and having to hover each icon and wait for a delayed tooltip.
• This creates ongoing friction, especially across many different apps each with 5–10 unique icons; people forget meanings between sessions.
• A proposed heuristic: a GUI is “good” if you can easily guide someone verbally (“click ‘Share Screen’”) rather than “the grey thing with an arrow.”
• Overly “intuitive” icon-only UIs often end up needing more explanation in popups, docs, or videos.

Best Practice: Combine Text and Icons, With Structure

• Many prefer text + icons: text explains; familiar icons act as visual anchors and speed scanning; both support different cognitive styles.
• Example praised: older Windows/Word menus using icons only on common commands, giving the menu a distinctive “shape.” Criticized: sidebars where every item has a similar vague icon, producing a blur.
• Grouping actions by topic and using icons selectively is seen as better than hiding “unimportant” actions or reordering menus, which breaks muscle memory.

Accessibility, Diversity, and Internationalization

• Visual limitations (low contrast, color blindness, large cursors) and age make icon-only UIs harder; labels also help screen readers.
• Color can aid recognition but cannot be the sole differentiator.
• Internationalization is cited for icons, but commenters note: icons themselves are culturally loaded and you need alt text/translations anyway; auto-translation makes simple labels cheap.
• Analogies to traffic signs: Europe leans icon-heavy due to language diversity; people are trained on those icons—software rarely gets that level of training.

Platform and Design Culture

• On phones, icon-only nav is sometimes accepted due to limited space; on desktop, commenters see little justification for removing labels and menu bars.
• Criticism falls on both “devs doing UX” and visually focused designers chasing aesthetics and trends (flat, monochrome, Chrome-style static toolbars) over guidelines and usability.
• Many want OS- or app-level toggles to choose icon-only, text-only, or both, plus search/command palettes for complex apps.

Ownership vs. License Language

• Many argue that showing “license to view” under a “Buy” button is deceptive; they want “Rent” or similarly explicit language.
• Several say the disclosure isn’t very informative: what matters are concrete rights (revocability, transfer, time limits, offline backup), not just the word “license.”
• Some contend that true “purchase” for digital goods should mean a perpetual, irrevocable, transferable license with DRM‑free files; others claim digital “ownership” is inherently different from physical.

Trust, Revocation, and Platform Power

• Users cite past removals of digital content (e.g., Kindle’s 1984 incident, shutdowns of ebook/music stores, Sony video removals) as proof that access can disappear despite payment.
• Amazon’s removal of the “download via USB” option is seen as tightening lock‑in and disqualifying it from “permanent offline” exemptions in new laws.
• A minority trust Amazon/Steam‑style platforms and are comfortable with account‑tied access; others explicitly distrust Amazon’s incentives and future behavior.

Piracy: Ethics, Legality, and Practice

• Many say Amazon’s licensing model “legitimizes” piracy or makes it the “lesser evil,” especially when no DRM‑free option exists.
• Counter‑arguments stress that piracy undermines authors’ livelihoods and that license terms, though disliked, don’t justify infringement.
• Some adopt hybrid ethics: buy a copy (ideally non‑Amazon) to support the author, then pirate or strip DRM for a usable archival copy.
• Technical discussion covers Calibre + DeDRM, jailbreaks, KOReader, torrenting with VPNs, and the DMCA’s anti‑circumvention rules (notably, fair use doesn’t clearly protect DRM removal).

Alternatives and Workarounds

• Strong interest in DRM‑free sources: Kobo (with DRM‑free labeling), some publishers’ own sites, Humble Bundle (often), Ebooks.com filters, Libro.fm for audiobooks, library apps (Libby), and piracy sites.
• Several are migrating from Kindle to Kobo, or at least bulk‑downloading and de‑DRMing their Kindle libraries before Amazon’s deadline.
• Others highlight library use, used/physical books, and open collections (Project Gutenberg, Standard Ebooks) to avoid these issues.

Impact on Authors and Publishers

• An author in the thread explains that Amazon royalties are often very low; buying directly from publishers or local bookstores yields more income for them.
• Libraries are generally portrayed as positive for authors (building readership) but more ambivalent for publishers.
• Some argue current IP and DRM regimes benefit large intermediaries more than authors, blocking a “Bandcamp for books”‑style market.

Current use of Dreamweaver today

• Several commenters still use Dreamweaver, but mostly in narrow roles:
  • Updating or maintaining legacy personal or client sites.
  • Using old perpetual versions (e.g., Dreamweaver 8) under Wine or on older systems.
  • As a convenient FTP client, template editor for WordPress, or for advanced multi-file find/replace and HTML table generation.
• There are anecdotes of institutional/legacy use:
  • A school library system on an air‑gapped Windows XP box using Dreamweaver + FileMaker.
  • Hearsay (explicitly unverified) that some government sites still depend on Dreamweaver licenses.

Perceptions of quality and role

• Strong disagreement over whether it was ever “professional”:
  • Some say it was essentially a toy, mostly for students and hobbyists, with poor code output and weak support for modern workflows.
  • Others report it being used as the primary tool in agencies and real jobs, including classic ASP, PHP/MySQL CRUD apps, SharePoint themes, and image maps, arguing it was powerful for its era.
• Consensus that today it’s ill‑suited for modern JS‑heavy frontends and that subscription pricing makes even less sense for small static sites.

Successors and modern alternatives

• For non‑technical users: Squarespace, Wix, and WordPress are seen as having absorbed Dreamweaver’s market (“edit button” over HTML editor).
• For designer‑dev workflows:
  • Webflow, Bootstrap Studio, Pinegrow, Wappler, Coda/Nova and various WYSIWYG/CMS tools are named as successors or partial replacements.
  • Some still use Seamonkey Composer, Kompozer, and older tools like HomeSite.
• One view is that Tailwind + code editors replaces the need for visual layout tools for many developers.

Nostalgia and learning impact

• Many learned HTML/CSS, MySQL, and early web dev through Dreamweaver (often pirated copies), reversing from WYSIWYG to source view; some credit it with starting their careers.
• Strong nostalgia for the broader Macromedia/Adobe era (Dreamweaver, Flash, Fireworks, ColdFusion, etc.) and the sense that tooling then made basic CRUD and page design simpler than today’s stacks.

Related tangents: Flash and HTML editors

• Flash’s demise sparks debate: some blame Apple’s iOS policy, others Adobe’s security/performance failures; some miss Flash’s capabilities, others are glad to see its ads and battery drain gone.
• Several note how hard it remains to build good WYSIWYG HTML editors, despite modern open‑source browser engines, and lament the poor HTML output of tools like Word and email clients such as Outlook.
• Speculation appears about a “new Dreamweaver” built around Figma, React components, and LLMs, but it’s seen as complex and commercially risky.

Secret Projects and “Marketing”

• Several comments note the irony that a “secret” program is releasing glossy photos, interpreting this as budget/PR signaling amid talk of defense cuts.
• Historical anecdote: past black programs (e.g., stealth work at Lockheed) supposedly lost contracts because their successes were too classified to market internally, illustrating the tension between secrecy and self-promotion.

Cultural Perception of Space Force

• Some associate “Space Force” with campy sci‑fi or Muppets skits; links to the satire TV series and parody songs.
• Others argue the service has legitimate strategic reasons to exist and was mocked largely due to its political origin, though that point is contested.
• One comment notes the TV show bears essentially no resemblance to Space Force’s real activities.

Why Such a High, Highly Elliptical Orbit?

• Suggested reasons:
  • Better survivability against anti-satellite (ASAT) weapons and surface-to-air missiles.
  • Ability to observe multiple orbital regimes and possibly geostationary assets.
  • “Free parking” and efficient testing of orbit changes, including orbital transitions and aerobraking.
  • Longer loiter time over certain regions, similar in concept (but not identical) to Molniya orbits.
  • Less predictable orbit, complicating tracking and targeting.

Orbital Mechanics Discussion

• Thread dives into perigee/apogee burns, Oberth effect, in-plane vs out-of-plane maneuvers, and bi‑elliptic transfers.
• Highly elliptical orbits allow large orbital changes with relatively small delta‑V at specific points.
• X‑37B can reach this regime using powerful boosters (previously Atlas V; this mission on Falcon Heavy) and then adjust orbit; aerobraking at perigee can aid in returning to Earth.

ASAT Vulnerability Debate

• One side: if you can hit 8 km/s satellites in LEO, 11 km/s isn’t fundamentally different; challenge is geometry and launcher placement.
• Counter: faster targets shrink engagement windows, demand more interceptor energy or earlier detection, and impose tougher tracking accuracy; hitting them is measurably harder even if not impossible.
• Sub-debate over whether you must “match speed” vs just lead the target, with analogies to shooting birds and constraints of radar horizon.

Roles, Capabilities, and Heritage

• Speculated roles: on-orbit observation, flexible timing over targets, testing orbital maneuvers, possibly interacting with other satellites (inspection/repair/interference), though all such capabilities remain unconfirmed and mostly classified.
• Payload bay is small (entire craft ~29 ft), so not a shuttle-class lifter; comparison is made to modular shuttle payloads rather than huge telescopes.
• Visual design is linked to a lineage of lifting-body/glider concepts (X‑20 Dyna‑Soar, Shuttle, Buran) driven by similar aerodynamic/orbital constraints.
• Craft still carries USAF markings; comments note Space Force’s origin inside the Air Force and its current reliance on commercial launch providers.

Meaning of “Cold Storage” and Multisig

• Debate over whether this was truly “cold storage”: some argue if signers’ devices can be remotely compromised and UI manipulated, it’s not “cold” in any operational sense.
• Others stress cold storage refers to private keys being offline; coins always live on-chain. Keys can be on paper, air‑gapped devices, or hardware wallets.
• Multisig is framed as “M-of-N keys,” but its value collapses if all signers treat approvals as routine and don’t independently verify what they’re signing.

Operational Security (OpSec) Failures

• Many view this as a human/OpSec failure: signers effectively “just pressed yes,” defeating the point of multisig.
• Strong “safeties” for large amounts (in‑person ceremonies, special workflows, independent witnesses) were missing. Comparisons are made to root CA key-signing rituals and traditional bank controls.
• Others counter that since malware tampered with what signers saw, mere communication or more signers wouldn’t have helped unless procedures and devices were much more hardened.

Attack Surface and Technical Weak Points

• Commenters assume the Gnosis Safe contract and hardware wallets held up; the weak link was compromised Macs/Windows PCs driving the wallets.
• Attack pattern: pre‑infect endpoints, show benign transactions in the UI while actually signing a contract change that hands control of a vault, then drain it.
• Air‑gapping and offline signing are discussed, but people note Stuxnet‑style USB compromises and that air‑gaps only raise cost/latency, not eliminate risk.

Irreversibility, Scale, and System Design

• Irreversible crypto transfers are contrasted with fiat’s dispute/chargeback mechanisms. Some see irreversibility as a feature (like cash); others say it’s disastrous at this scale.
• Several argue the real issue is treating $1.5B like a single “bill”: in the physical world, moving that much cash or gold requires trucks and layers of process, inherently adding friction and detection.
• Suggestions: split funds across many wallets, have distinct keys/workflows for “big pot” vs routine ops, use many small transactions, or build reversible/settlement-period mechanisms into protocols.

Regulation, Maturity, and Nation-State Threats

• Many see crypto security/compliance as far behind traditional finance, where large thefts from major banks are “nearly impossible” due to audit, process, and reversibility.
• Others note that in regulated jurisdictions, larger crypto firms already resemble banks in compliance posture.
• Nation-state actors (especially North Korea) are assumed to be involved, with discussion that holding billions in bearer assets inherently puts you in their threat model.
• There’s frustration that cyber-attacks by states draw little geopolitical response compared to physical attacks, shifting the onus entirely onto private defenders.

Who Lost Money and What Now

• Depending on Bybit’s solvency: either the exchange eats the loss and tries to earn it back, or a collapse would push losses onto users.
• Historical precedent (other large exchange failures) leads some to expect partial recovery over time, but nothing is guaranteed.

Architecture focus: x86 vs RISC‑V/ARM

• Some dislike the tutorial’s x86 focus, arguing RISC‑V will eventually dominate; others counter that x86 and ARM still massively outgun RISC‑V in real hardware and performance.
• Several say ARM would have been a more pragmatic non‑x86 choice due to current market share.
• There is curiosity (and some skepticism) about how RISC‑V’s vector model maps to workloads like ffmpeg.

Handwritten assembly vs C/intrinsics/compilers

• Strong debate over the claim that asm can be “10x faster than C”:
  • Many say modern compilers are excellent and naive C vs expert asm is an unfair comparison.
  • Others insist that in tight DSP/codecs kernels, especially with SIMD, 2–10x gains over naïve scalar C are real.
• Several argue you can often get close enough with C + intrinsics or better memory layouts, and that algorithmic and cache-level improvements dwarf micro-optimizations for typical software.

SIMD, codecs, and performance-critical use cases

• Codecs and signal processing are highlighted as prime SIMD targets: “do this to every sample/pixel” maps perfectly to vectorization.
• Examples given of large wins (e.g., 30% less CPU for audio metering, big gains in AV1 decoder/encoder hotpaths).
• For extremely hot loops run trillions of times, even 10–50% differences between compiler SIMD and handwritten SIMD are considered worth the effort.

Portability, intrinsics, and tooling

• Major downside of asm: per‑ISA implementations, sometimes multiple per microarchitecture. Projects maintain C fallbacks plus many asm variants (x86 SSSE3/AVX2/AVX‑512, ARM NEON, etc.).
• ffmpeg is described as philosophically preferring pure asm over intrinsics: better control, fewer surprises from compilers, but at cost of readability and portability.
• Some criticize heavy NASM macro abuse in ffmpeg’s asm as obscuring what the code actually does.
• Portable SIMD libraries (Highway, Eigen, simde, language‑level SIMD in Rust/Zig/C#) are discussed; consensus is they’re useful but can leave performance on the table for very tuned projects like ffmpeg/dav1d.

Learning, enjoyment, and pedagogy

• Many find the tutorial unusually approachable and welcome a focused SIMD/x86 resource.
• Multiple comments describe assembly as fun, enlightening for understanding hardware and compiler behavior, and valuable for debugging—even if rarely written professionally.

FFmpeg, docs, and ecosystem

• Some praise ffmpeg’s capabilities and hardware acceleration support; others recount painful experiences with its C API and documentation (dated examples, deprecations, confusing build system).
• GStreamer in Rust is mentioned as a more modern framework, but not a drop‑in ffmpeg replacement.

Auto‑vectorization, superoptimization, and LLMs

• Mixed experiences: some report compilers now auto‑vectorize well if code is written “compiler‑friendly”; others show simple cases where compilers still miss ideal SIMD idioms.
• Superoptimization and search‑based tuning are mentioned as promising for tiny kernels; LLMs are generally seen as not yet trustworthy for correct, optimal asm.

Value and drawbacks of comments

• Several posters see on-site comments as more curse than blessing: spam, toxicity, and performative behavior dominate.
• Some replace comments with email links or small mailing lists; interactions drop in quantity but improve in depth.
• Others insist comments should remain under site-owner control, including deletion and pre‑moderation, while critics argue that discourages participation.
• Hacker News itself is discussed as a “comment section” that works mainly due to heavy moderation and a focused, technical community, though some see quality declining over time.

Personal websites as art and “digital gardens”

• Many embrace personal sites as creative, idiosyncratic spaces: unconventional layouts, GIFs, ASCII art, playful themes (e.g., gardens, one‑joke sites).
• “Digital garden” metaphors recur: slowly evolving, meandering notes, with no obligation to attract traffic or monetize.
• Some explicitly reject optimization (speed, SEO, attention) in favor of craft, whim, and long-term personal satisfaction.

Centralization, discoverability, and capitalism

• One camp argues centralization “wins” on economics and discoverability: social platforms and a few big sites dominate.
• Others counter that discoverability only matters if you seek money or fame; for personal art, a tiny audience—or none—is acceptable.
• Several lament that search engines (especially Google) now surface content mills and SEO spam over high‑quality niche sites.
• There’s debate over whether social platforms actually offer meaningful discovery anymore or just lowest‑common‑denominator content.

Indie web, POSSE, and discovery tools

• The “POSSE” approach (Publish on your Own Site, Syndicate Elsewhere) is cited: own your content, share links on platforms.
• Old‑school methods—blogrolls, webrings, curated link lists—are praised as human, organic discoverability.
• Modern equivalents include curated directories and “small web” search/“surprise me” tools; some propose new curated aggregators with manual review.

Nostalgia for the early web & ISP hosting

• People reminisce about free ISP webspace, Angelfire/Geocities sites, webcam pages, and early fan sites that led to surprising real‑world connections.
• There’s recognition that many old sites were “one‑and‑done” visits and that personal pages could feel as disposable as today’s social posts.

Legal and moderation constraints

• UK and German posters mention regulation (Online Safety Act, DMCA, “Impressumspflicht”) as pressures against casual self‑hosting, especially with comments or perceived commercial intent.
• Workarounds (WHOIS privacy, PO boxes, foreign domains, static hosting) are discussed but not seen as universally simple.

Critiques and practical limitations

• Some complain that self‑hosted‑web advocates are becoming preachy; a personal site doesn’t equal a personality.
• RSS is both celebrated and criticized: great in principle, but can be dominated by a few noisy feeds and strips away page personality.
• Modern webdev complexity (SSL, responsive design, tooling) is seen as a barrier compared to the old “FTP + Notepad” era, skewing who actually builds personal sites.

Eroding Trust in the US as Ally

• Many see a qualitative break, not just another bad US administration: active siding with Russia over Ukraine, threats to cut Starlink, tariffs, and open talk of abandoning NATO are perceived as betrayal, worse than Iraq 2003 or Trump’s first term.
• Several note EU leaders now assume the US might not honor Article 5 for Poland/Baltics, or would only do so with extreme conditions. Trust damage is seen as long‑term and hard to reverse.

European Security Realignment

• Discussion of Europe rearming and reducing dependence on US defense:
  • Moves toward relying more on French/British nuclear umbrellas and possible nuclear sharing inside the EU.
  • Some argue Europe could deter Russia with its own conventional and nuclear capabilities and should push US troops out.
  • Others stress that currently NATO still rests heavily on US spending and capabilities.

Tariffs, Trade, and Economic “Bazookas”

• Many expect EU–US trade conflict: higher tariffs on US cars and possibly digital services; some point out the US is a huge exporter (including tech, aerospace, services) so EU retaliation could bite.
• EU commenters reference an “economic bazooka” of rapid sanctions against US firms if force is used against an EU state. Others think such sanctions wouldn’t deter a risk‑tolerant US leadership.
• Debate over tariffs: some Americans welcome them as re‑industrialization; others warn of higher prices, supply‑chain shocks, and harm to middle and lower classes.

Backlash Against US Tech Platforms

• A visible minority reports concrete steps: deleting Amazon and Google accounts, closing US cloud/S3, moving to European email, storage, and hosting; mirroring GitHub repos to Forgejo/Codeberg; switching from WhatsApp to Signal or EU services.
• EU SaaS and small companies describe actively de‑risking from US clouds and vendors, citing legal uncertainty around US surveillance and political weaponization of tech (Starlink as example).
• Others doubt big US platforms will feel much: most users won’t switch OSes or office stacks; integration and network effects are deep.

Tesla, FSD, and US Auto Perception

• Several expect Tesla FSD never to be approved in Europe, citing safety, regulation, and Musk’s camera‑only bet.
• European owners complain FSD is far from usable and was mis‑sold for years; some say Tesla’s brand is “destroyed” in Europe.
• Counterpoints note European Level 2/3 systems are certified and in some areas ahead of Tesla; others argue Europe “doesn’t want innovation” and over‑regulates.

European Tech Sovereignty and Regulation

• Strong current of “this is a wake‑up call”: reduce dependence on US tech stacks, invest in European clouds, LLMs, and search, and revive protocol‑based/open solutions.
• At the same time, commenters blame EU over‑regulation (e.g., AI Act, labor law) for stifling startups and pushing founders to the US.
• Some argue Europe has the talent (Linux, Python, MySQL, ASML, Airbus) but lacked geopolitical pressure; current crisis may finally catalyze integration and investment, or, pessimists say, just produce “more rules.”

How Broad Is the Backlash?

• Split views:
  • Tech‑ and politics‑aware circles in several countries are clearly re‑evaluating US tech, alliances, and investment; there are anecdotes of funds and pensions selling US big‑tech stocks and firms preferring non‑US partners.
  • Others insist most Europeans “don’t know and don’t care,” are focused on energy prices and daily life, and won’t abandon iPhones, Windows, or US social media.
• Several stress it’s early: hard to tell if this is a short‑term reaction or the start of a lasting decoupling.

US Domestic Perspective

• Multiple US commenters say the majority of Americans don’t care about Europe’s reaction and want to stop being “world police,” even at the cost of alliances and soft power.
• Some Americans are themselves divesting from US tech, criticizing “paperclip‑maximizing” corporations and authoritarian drift; others defend cuts and retrenchment as necessary fiscal discipline.
• There’s anxiety from both sides that rapid US policy whiplash (every 4 years) makes America an unreliable long‑term partner for technology and security.

Why HEXUS and Other Forums Are Closing

• Operators say the Online Safety Act (OSA) creates large compliance overhead: reading hundreds of pages of Ofcom guidance, doing “illegal content” and children’s risk assessments, maintaining complaints processes, naming a compliance contact, and potentially adding age verification.
• For HEXUS specifically, the company is dissolved, the forum was already in sunset / read‑only mode, and there’s “no one left” to do the work, so deletion is seen as the only realistic option.
• Some argue the forum was effectively dead anyway (very low recent activity), and the OSA is more a final push or a protest framing than the root cause.

How Broad Is the Law? Disagreement Over Scope and Cost

• One camp: the law is so vague and sweeping that any user‑generated content (UGC) site “that might hypothetically be used by someone in the UK” faces excessive, open‑ended risk and workload. Terms like “reasonable” and “proportionate” plus “foreign interference” and 17 categories of “illegal harms” are seen as weapons for selective enforcement.
• Other camp: Ofcom’s own guidance says small services with low risk mainly need what any serious forum already has—terms of service, a report/complaints tool, moderation that acts on illegal content once aware, and a named contact. Age checks apply mainly to porn. They see panic and misreading more than genuine burden.
• Several note that “large” services (7M+ monthly UK users) have far stricter duties; for small sites, proactive detection/AI filtering is not required.

Jurisdiction, Geo‑blocking, and Personal Risk

• Non‑UK operators discuss geoblocking the UK (including projects like lobste.rs); Ofcom has reportedly confirmed this is a valid compliance path.
• For UK‑based sites, geoblocking doesn’t help, and there’s extra fear over personal liability for a named “senior manager” and the possibility (however small) of cross‑border enforcement or extradition.
• Some suggest incorporation or selling the forum abroad; others respond that the corporate veil can be pierced, and personal liability clauses undermine this.

Archiving vs Deletion

• Many lament deletion of 2.6M historic posts; liken it to “burning down a library.”
• Counter‑view: OSA doesn’t target historic content per se; risk for a read‑only archive is probably minimal, so full deletion is unnecessary and more a form of protest or over‑cautiousness.
• Proposals include: making it read‑only, anonymizing users, donating to Internet Archive / Archive Team, or hosting under a non‑UK entity.

Broader Free‑Speech vs Safety Debate

• Long subthreads argue whether “online hate” and radicalization justify such regulation:
  • Critics see moral panic, regulatory capture favoring big platforms, and a slippery slope toward censorship of controversial but legitimate discussion (drugs, sex work, religion, geopolitics).
  • Supporters accept that some limits on speech and platform duties are needed to address bullying, CSAM, incitement, and coordinated disinformation, though many still find the OSA poorly drafted and communication from Ofcom confusing.
• Several commenters frame this as the end of the “old”, hobbyist‑friendly web and a shift toward heavily regulated, centralized platforms.

Policy “middle ground” and kernel governance

• Many see Torvalds’ stance as a pragmatic compromise: C maintainers don’t have to learn or review Rust, but also can’t veto Rust users of their APIs.
• Some argue calling this “middle ground” overstates it; they view it as simple common sense that API users can be in any language.
• Key clarification from several commenters: the disputed Rust DMA patches did not modify the C DMA layer at all; they were just new Rust users of an existing API.

C vs Rust in low‑level and embedded work

• Ongoing debate whether C has a permanent niche “closest to the metal” (bit‑banging, exotic hardware, very predictable codegen) or whether Rust/C++ can fully cover that space.
• Some embedded developers report Rust can do everything they did in C, but tooling and ecosystem are less mature.
• Others argue C’s predictability is overrated: UB and aggressive optimizers already make assembly output non‑obvious; for truly strict control you need inline asm regardless of language.

APIs, maintainers, and cross‑language boundaries

• One camp: maintainers should care only that their C API contract is correct and documented; how it’s used (language, use case) is not their business.
• Another camp: if Rust becomes a major or primary consumer of an API, ignoring Rust usage “as a policy” harms quality; at minimum, maintainers should show interest in how their APIs are consumed.
• Several note you can’t give meaningful feedback on Rust bindings without knowing Rust; thus the burden should sit with Rust maintainers to adapt to C APIs.

Multi‑language codebases and “golden rule” debate

• One view: “golden rule” is to minimize languages in a project to avoid silos and hiring/training pain; examples given of Scala/Java and Kotlin/React Native splits causing ownership chaos.
• Counterview: almost nobody works in single‑language backends; mixing C/Go/Python/SQL/etc. is normal and manageable if roles and boundaries are clear.
• Consensus tendency: adding a new language should be justified by clear benefits, but it’s not inherently pathological.

Culture, communication, and Torvalds’ style

• Several note Torvalds still gives very blunt feedback, but with somewhat softer phrasing than in the past; some think this firmness is necessary to keep kernel quality high.
• Others criticize past emails as personally harsh rather than merely “direct,” debating whether this is cultural (non‑Anglo directness) or simply unacceptable behavior.

Forking, freedom, and project identity

• A minority argues Rust advocates should fork a Rust‑heavy kernel instead of “imposing” Rust on C maintainers, invoking “freedom” in free software.
• Others respond that Rust developers are already part of the maintainer body, and that forking would squander scarce manpower; Linux itself wasn’t a Unix fork but an independent OS.
• Some predict no serious C‑only fork: most major contributors are paid by companies unlikely to back a split.

Tooling, build, and process

• Rust is already in parts of the kernel, so toolchain and build implications are seen as largely unchanged by this specific dispute.
• Mailing lists remain criticized as hard to read and participate in, despite being described (tongue‑in‑cheek) as part of a “well‑oiled engineering marvel.”

Shareholder profits vs real losses

• Several commenters argue price hikes and benefit cuts reflect a drive to maximize returns to investors, not purely underlying losses; they see this as a systemic problem in US capitalism.
• Others counter that not all price increases are “greed” (e.g., rising labor and material costs), and that competitive markets constrain arbitrary hikes.
• One commenter notes that paying dividends while reporting losses isn’t inherently fraudulent; dividends can come from retained earnings and losses can be localized to specific lines (e.g., Florida property).

Florida-specific regulation and political capture

• Multiple comments stress this is less a generic US issue and more about Florida’s regulatory design and capture.
• The state insurance office’s study being kept as a “draft” and not shown to lawmakers is cited as evidence of corruption.
• Some argue Republican leadership has blocked climate policy, corporate accountability, and tax increases needed to shore up infrastructure and risk pools.

Climate risk, uninsurability, and geography

• Many see Florida’s growing hurricane and flood risk as making traditional private insurance increasingly unsustainable; some predict large areas becoming effectively uninsurable.
• There is debate over whether better building codes and engineering can largely mitigate non‑flood damage, versus flooding being fundamentally city‑leveling.
• Comparisons to California stress that FL’s exposure (low elevation, long coastline, dense coastal development) is qualitatively worse.

Fraud, litigation, and local scams

• Several participants emphasize rampant fraud: roofers soliciting “free roofs” via storm claims, over‑priced contractors, and aggressive litigation.
• Others highlight insurers’ own “shady” behavior: sharp premium hikes, forcing frequent roof replacements, lowballing claims, and relying on customer ignorance.
• Florida’s previous rules around assignments of benefits and high litigation volumes are described as having driven many national carriers out; 2023 reforms tried to curb this.

Affiliate/sister companies and accounting games

• A key article detail many see under‑discussed: Florida‑only insurers allegedly create affiliated companies (MGAs, service entities) that bill the insurer for claims handling, underwriting, etc.
• This shifts profit out of the regulated carrier (which can appear marginal or loss‑making) into less‑regulated affiliates, potentially evading profit caps and scrutiny.
• Some note the report itself says many documents are marked “trade secret,” limiting public exposure of company‑specific behavior.

Public vs private insurance and who should pay

• One camp argues hurricane risk shouldn’t be a for‑profit line at all; they favor state/federal disaster funds and/or public insurance, with private insurers covering only routine risks.
• Critics warn that unlimited public backstops create moral hazard and force safer taxpayers to subsidize risky coastal building; they prefer charging full risk‑based rates to push people away from high‑risk areas or into stronger construction.
• There is acknowledgement that, in practice, the government already bails out large disasters and that Citizens (the state insurer of last resort) is expanding.

Democracy, voting, and blame

• Some insist Floridians are getting the government they voted for: low taxes, light regulation, and protection of insurers, with predictable consequences.
• Others push back that turnout is low and many residents did not vote for current leadership, but non‑voters are also held partly responsible.
• Thread devolves at points into broader partisan debate (lockdowns, vaccines, union power, “both parties are bad”) rather than staying on Florida insurance specifics.

DOGE’s Stated Mission vs. Perceived Real Agenda

• Supporters frame DOGE as long-overdue, “hatchet not scalpel” reform against massive federal waste, fraud, and misaligned priorities.
• Many others argue cuts are not primarily about efficiency or debt, but about ideological remaking of the state (Project 2025, “starve the beast”), weakening or capturing agencies that regulate key industries or protect disfavored groups.
• Several note DOGE’s own rhetoric about wanting bureaucrats to feel “traumatized,” interpreting this as deliberate institutional sabotage, not neutral efficiency work.

Data Quality, Ledger Errors, and Trust

• Thread agrees government data is messy; any new analytics effort will surface errors.
• Critics stress DOGE is misusing incomplete FPDS data as if it were a true ledger, leading to huge overstatements (e.g., misreading an $8M contract as $8B, claiming billions in “savings” where only tiny line-items were cut).
• Some see the error pattern as consistent with Musk/Trump’s history of exaggerated claims; others argue unproven fraud allegations should be treated as “unsubstantiated,” not automatically false.

Constitutionality and Separation of Powers

• Strong concern that DOGE is functionally impounding funds Congress appropriated, which multiple commenters say violates statute and Supreme Court precedent on the “power of the purse.”
• Debate over how far the executive can go in canceling contracts, freezing grants, or hollowing out agencies without explicit rescission approved by Congress.
• Some warn this effectively creates a de facto, non-overridable line-item veto and an unelected parallel budget authority.

What’s Being Cut, and at What Scale?

• Many point out that claimed DOGE cuts are at most fractions of a percent of total outlays, often aimed at research, foreign aid, public health, and “woke” or DEI-related programs.
• Critics highlight that these are mostly investment or soft-power programs (USAID, CDC capabilities, science datasets, EV infrastructure), likely to increase long-run costs and reduce global influence.
• Several note that at the same time, defense spending and high-end tax cuts are expanding, so deficit reduction claims ring hollow.

Government Waste vs. Corporate / Contractor Waste

• Multiple commenters with gov-contractor experience describe spectacular waste: multi‑million-dollar internal tools barely used, small user bases for expensive Palantir deployments, “inventory” apps that could be spreadsheets.
• Counterpoint: large private firms (banks, big tech, healthcare) are also deeply wasteful; inefficiency scales with organization size, not “public vs private.”
• Emerging view from some policy pieces cited: the real bloat is in the contractor ecosystem, not the civil service; paradoxical proposal is to hire more in‑house talent and cut large integrators/consultancies.

Debt, Taxes, and What Should Actually Change

• Long subthread on whether the US “spends too much” vs “taxes too little,” and on which categories should be touched: defense, Social Security/Medicare, welfare, or corporate taxes.
• Several note that most federal spending is transfers to elderly/poor and interest; cutting small discretionary items cannot materially fix debt dynamics.
• Others stress that tax policy (especially Bush/Trump cuts and low effective corporate rates) is at least as important as spending.

Impact on Institutions, Democracy, and Fascism Concerns

• Widespread worry that slashing inspectors general, neutral tech teams (e.g., USDS), scientific archives, and oversight databases (e.g., police misconduct) is about disabling accountability.
• Some explicitly connect DOGE tactics to “authoritarian populism” and classic fascist patterns: contempt for deliberation, glorifying disruptive action, loyalty vetting, and attacking “deep state” enemies.
• A minority push back that using words like “fascism” is overreach or partisan hyperbole.

HN Meta: Politics, Moderation, and Musk

• Multiple complaints that DOGE/Musk threads are heavily flagged or removed; moderators explain efforts to avoid repetition and flamewars, not to protect Musk.
• Some argue DOGE is highly “HN-relevant” as a live attempt to “hack” government systems, while others are fatigued by US‑politics dominating the front page.

Executive bonuses & layoffs

• Many see Meta’s executive bonus hikes after layoffs as emblematic of distorted executive labor markets: boards overpay “lottery ticket” CEOs while rank-and-file are squeezed.
• Some describe this as demoralizing and inefficient but still prefer market-driven correction; others argue markets have clearly failed and stronger regulation, worker protections, or co-ops are needed.
• Firsthand Meta accounts depict the latest layoffs as harsher than previous ones, with capable people labeled as poor performers due to external circumstances. Teams must now backfill at high cost and friction, while management grows more hostile and low-trust.

COVID economy, inflation & political anger

• One side claims lower- and middle-income real wages rose unusually fast during the COVID period and that government support was historically large; they’re puzzled by the intensity of the backlash.
• Critics question official inflation measures (especially housing), note uneven wage gains and job losses, and argue many people were not fully compensated.
• There’s debate over whether post-2020 anger was mainly economic or driven by identity, culture, and social media.
• Egg prices become shorthand for inflation: some see focus on groceries as a symbol of misplaced blame, others insist this attitude is out of touch because food price shocks hit ordinary people hardest.

PPP and pandemic relief

• Commenters report sharply different PPP experiences: some companies genuinely survived and preserved jobs; others stayed profitable and used PPP to effectively subsidize owners.
• Multiple participants highlight extensive fraud and luxury spending, yet still view PPP as a “suboptimal but net positive” wage backstop.

Minimum wage, cost of living & inequality

• There is disagreement over how many workers are truly at the federal minimum wage and how relevant it is versus higher state/municipal floors.
• Tipped minimum wage is heavily contested: some emphasize legal guarantees to reach full minimum; others point to lived reality of very low base pay and unstable tips.
• Several link executive rewards to rising income and wealth inequality, warn about unsustainable Gini levels, and argue that small wage gains amid soaring asset and housing prices feel like going backward.

Remote work, outsourcing & management culture

• One view: white-collar workers “spent” their brief leverage on remote work rather than pay or structural power, making themselves easier to offshore to cheaper regions.
• Others respond that outsourcing was always on the table; the real failure was lack of collective organization.
• Multiple comments frame current Big Tech behavior—stack ranking, RTO mandates, copycat layoffs, “low trust” micromanagement—as indistinguishable from old-line corporations; some say Big Tech’s rhetoric about agility and innovation is now obviously hollow.

Experiences of Programming at 50+

• Many commenters in their late 40s–70s say they still code professionally and/or as a hobby and enjoy it, some more than ever.
• Common pattern: they like IC roles, problem‑solving, mentoring, and “puzzle‑like” work, but strongly dislike late nights, fire drills, and pointless stress.
• Several say they’d quit immediately if stuck in mega‑corp, heavily politicized, or non‑technical roles; others left management to return to IC work.
• A few older devs feel burned out, physically and mentally, and want to step back to part‑time or hobbyist coding.

Environment, Agency, and “Toxicity”

• Whether programming feels toxic or joyful is repeatedly framed as “environment-dependent”:
  • Bad: misapplied agile, endless bug chases, 2am sprints, security theater, micromanaging managers, Jira‑driven time tracking, no domain understanding.
  • Good: autonomy, remote work, small teams, direct contact with users, time to understand domains, ability to say no to unrealistic demands.
• Several argue the real issue is lack of agency and poor communication with stakeholders, not programming itself.

Art, Constraints, and Craft vs Factory

• One camp: constraints (time, budget, legacy code) are inherent and even generative—like in art—so complaining is a sign of weaker engineers or perfectionism.
• Counterpoint: many constraints (ceremony, process, arbitrary deadlines) are unnecessary and stifling; once you’ve worked without them, they’re hard to accept.
• Some emphasize personal craft and long‑term “pet” systems where they can pursue their own standard of perfection.

Corporate Processes, Agile, and “Golden Age” Nostalgia

• Older devs recall 1990s–early‑2000s as a “hacker” era: smaller teams, more slack, less ceremony, more intrinsic motivation.
• They see later waves of agile/scrum and management theory as attempts to turn coding into a factory line, attracting people “just for the money” and diluting hacker culture.
• Others push back: agile was meant to reduce bureaucracy but was co‑opted; problems come from management culture, not methodology per se.

Work, Money, and Retirement Choices

• Many 50+ devs keep working because they enjoy it, but also due to financial needs or lifestyle expectations.
• FIRE and “one more year” dynamics appear: people trade hated but high‑paying mega‑corp roles for future independence.
• Some urge younger devs to avoid lifestyle inflation, cultivate options (small companies, self‑employment), and separate “coding for joy” from “coding for a paycheck.”

AI and Future of the Profession

• Several older devs are excited about AI tools removing drudgery and making mundane tasks fun again.
• Others worry about enshittification and commoditization, but most in the thread do not believe near‑term “prompt‑engineering only” doom.

Data hoarding vs selective saving

• Some argue compulsively saving web content is wasted effort and cognitive overhead; others say future searchability and option value make local copies invaluable.
• One camp trusts that “the internet never forgets” and prefers to let others bear storage costs; another reports an accelerating loss of semi‑obscure documents, especially government/organizational material.
• Older participants note that decades of archives were rarely revisited more than a few years back, suggesting diminishing returns; others counter that AI may make large personal archives newly useful.

Web archiving & the Internet Archive

• Several people rely on tools like SingleFile, Markdownload, or linkding to save full pages (HTML/webarchive/MHTML) rather than Markdown, especially for complex layouts, paywalled or app‑like sites.
• There’s appreciation but concern for the fragility and legal risks of the Internet Archive; some want multiple IA‑like projects or partial mirrors, even with degraded media quality.
• A recurring point: the ability to find and organize archives (full‑text search, tagging, annotations, vector search) matters more than the raw act of saving.

Why Markdown, and how people use it

• Many keep nearly everything textual in Markdown: notes, blog drafts, research, meeting minutes, even daily journals, often synced via Git, Nextcloud, or cloud drives.
• Advantages cited: plain text, tool portability, easy scripting (Pandoc, Python, Quarto), and the ability to rebuild new systems over the same files.
• Some are building personal “knowledge bases” or LLM corpora from scraped Markdown (bookmarks, GitHub stars, HN posts, transcripts).

Limitations, fragmentation, and readers

• Pain points: images and tables, math, diagrams, underlining, colored text, custom blocks, rich layout, and lack of standardized frontmatter.
• People debate CommonMark’s design (emphasis syntax, ambiguity, complexity of parsers) and the profusion of flavors (GitHub, Obsidian, MDX).
• A strong subthread complains about the scarcity of simple Markdown viewers (vs editors with preview) compared to ubiquitous PDF readers.

Alternatives and ecosystems

• Org‑mode is praised as a more holistic PKM system (tasks, time management, literate programming) but is seen as Emacs‑centric.
• Others advocate AsciiDoc, reStructuredText, MediaWiki markup, Typst, HTML, or even RTF for richer, WYSIWYG‑friendly, or more semantically precise documents.
• Consensus: use Markdown for most plain text; switch to richer formats when layout, semantics, or exact styling are essential.

Clojure’s core appeal

• Seen as the “third big Lisp” alongside Common Lisp and Scheme, but with a distinct philosophy: immutable data, simple core, functions over objects, and strong host interop (mainly JVM).
• REPL-driven, interactive development is repeatedly cited as the killer feature: change a small function, eval it into a long‑running system, and see effects immediately without full rebuilds.
• Immutability and simple data structures (maps, vectors, sets) are praised for reducing accidental complexity, easing reasoning, testing, and concurrency.

Immutability vs Static Typing

• Many argue they’ll “take immutability over types”: static types are seen as verbose, tightly coupling code to syntax and slowing expert developers.
• Others counter that static types are invaluable for reading and maintaining large, long‑lived codebases, especially when inheriting decade‑old systems.
• Clojure is strongly but dynamically typed; protocols, records, and types offer structure, but do not provide the same compile‑time guarantees as Java/Haskell/OCaml.
• Spec and Malli are used for runtime validation at boundaries; Typed Clojure exists but has not become mainstream. Some find the dynamic approach empowering, others find it fragile.

JVM, Performance, and REPL Tooling

• Fans praise the JVM as a fast, mature runtime with powerful stacktraces (“caused by” chains), huge library ecosystem, and good performance vs other dynamic languages.
• Critics dislike startup time (especially for scripts and serverless) and Java‑style stacktrace “barf” when errors occur, though tools like CIDER, clj‑kondo, FlowStorm, and Babashka mitigate this.
• Recent Clojure releases improved Java lambda interop, addressing a long‑standing friction point.

Ecosystem, Stability, and Datomic

• The core language is intentionally small and very stable; many libraries “just work” for years without changes. This stability is valued by long‑running businesses.
• Some perceive stagnation: clojure.spec remains alpha; Schema withered; Malli has become the de facto alternative.
• Datomic (and Datomic‑like DBs such as Datascript, Datalevin, XTDB, Rama) are seen by some as a natural extension of Clojure’s data philosophy; others view them as niche or unnecessary.

Tooling, Onboarding, and Frontend

• Historical churn in build tools (classpath, Leiningen, Boot, deps.edn, various CLJS stacks) confuses newcomers; many wish for a single, “boring” default like Cargo/Mix.
• ClojureScript + React has multiple viable stacks (re-frame, Fulcro, etc.), but the variety and documentation gaps make it hard to know the “right” modern path.

Community, Culture, and Jobs

• Multiple comments praise Clojure for enabling high‑leverage solo/very small teams and successful bootstrapped businesses.
• At the same time, there’s repeated concern about scarce job opportunities and rewrites to Go/Python/Java when key Clojure experts leave.
• Some perceive elitism, defensiveness, and “true believer” culture around Clojure and its leadership, which they believe harms broader adoption despite the language’s technical strengths.

Scope of the problem (beyond the article)

• Commenters report increasing “app-only” requirements for: parking, public transport, banking auth, school/daycare communication, medical portals, gyms, laundry, restaurant menus/ordering, airline boarding passes, and ticketing.
• Many note that almost all of these are just web apps wrapped in native shells, but access is locked behind app stores and phone OSes.
• People who split lives across countries run into geofenced app stores (banking, transit, McDonald’s, NHS, etc.), sometimes needing multiple phones/accounts.

Choice vs discrimination / is it “tyranny”?

• One camp: not having a smartphone is a personal choice; others shouldn’t bear higher costs to support “obsolete” options. Analogies: cars, credit cards, education credentials.
• Opposing view: this is effectively coercion, especially when applied to essential services (banking, health, schooling, parking where tickets are mandatory). “Choice” isn’t real if the alternative is exclusion.
• Several argue the rhetoric (“tyranny”) is hyperbolic but the underlying trend is genuinely harmful.

Banking and essential services

• Multiple reports of banks dropping web access or SMS in favor of app‑only 2FA, sometimes requiring Google/Apple stores, non‑rooted phones, or specific OSes.
• Some people can no longer manage accounts remotely (e.g., abroad, no smartphone, or alternative OS), or must travel to a branch that is itself disappearing or fee‑ridden.
• Suggestions: mandate TOTP/hardware tokens; require at least one non‑app channel for core banking. Skeptics doubt banks will do this without regulation.

Schools, healthcare, and families

• Parents describe needing multiple incompatible apps per child for communication, homework, lunch payments, attendance, etc. Apps change every year.
• A few successfully forced email/web alternatives, but only via persistent negotiation with principals and teachers.
• Health systems increasingly replace decent web portals with buggy, app‑only frontends; elderly patients and those with limited tech skills struggle, sometimes losing practical access to care.

Accessibility, disability, addiction

• Examples: people with brain damage, low income, vision/dexterity issues, cognitive overload, or religious objections to smartphones.
• Some avoid smartphones deliberately due to internet addiction; app‑only systems effectively punish this coping strategy.
• Commenters note that accessibility law covers disability but not “right to live offline” or “right to use a generic computer instead of a smartphone.”

Privacy, surveillance and pricing

• Many see app‑only discounts (fast food, supermarkets, transport) less as rewards and more as penalties for privacy‑conscious people; prices rise for everyone, then are “discounted” only to trackable users.
• Apps enable persistent location, behavioral tracking, and personalized pricing; some argue this is the real business goal, not “security” or UX.
• App‑store lock‑in (Apple/Google) is a separate but related concern: essential services increasingly require accepting their terms and surveillance.

Rural, poverty, and cost

• Some rural commenters report still being able to live mostly “pre‑smartphone,” others describe the opposite: app‑only bus tickets, parking, bank fees for in‑person service.
• While cheap phones and social tariffs exist in some countries, people point out hidden costs: rapid end of security updates, forced upgrades, data plans, and the extra cognitive load of managing many apps.

Role of government and regulation

• Strong support for requiring non‑app access for public and quasi‑public services: government portals, healthcare, schools, banking, core transport, parking.
• Cited examples: Swiss cantons voting a “right to live offline” / “digital integrity” into their constitutions, leading to choices like switching schools from Microsoft Office to LibreOffice.
• Others warn that mandating full offline equivalence (same price and convenience) could kill low‑cost, app‑only competitors and raise system‑wide costs; they favor baseline offline access, but accept some price differences.

Technical alternatives and workarounds

• Proposed compromises:
  • Proper mobile web apps + email/SMS;
  • Open standards (TOTP, FIDO keys) instead of proprietary authenticators;
  • Dedicated hardware tokens or QR‑scanning devices for people without smartphones.
• Some users resist by: refusing app‑only services, demanding paper or phone alternatives, using flip phones or de‑Googled Android, or simply walking away from restaurants, banks, or parking they can’t use without an app.

Focus on calculators vs AI hype

• Several commenters resonate with the idea of building “small, concrete tools” instead of AI agents.
• Some see manual coding skills (even at high level) as gaining leverage in the AI era: AI is a multiplier, not a replacement.
• A few explicitly contrast the joy of deterministic tools with the opacity and hype of current AI systems.

Low-level learning and determinism

• Multiple people mention learning or using assembly / reverse-engineering binaries as a hobby.
• Motivations: deeper understanding of machines, mental challenge, and a sense of robustness (“in case of societal collapse”).
• Some frame this as both a return to simplicity and a reaffirmation of human reasoning.

Ecosystem of calculators and similar tools

• Many share their own calculators (running pace, units, Redis sizing, Android converters, immigration tools).
• General sentiment: calculators are great “small projects” to learn, refresh math, and avoid doomscrolling.
• A few ask whether this is redundant given Wolfram Alpha and similar sites.

UX, accessibility, and feature feedback

• Detailed feedback on specific calculators:
  • BMI: better keyboard accessibility, real radio buttons, color contrast, feet/inches input, auto conversions, live recalculation, and mapping BMI categories to weight ranges.
  • Speed: add pace formats for running, swimming, rowing.
  • Unit/time: express values in mixed units (e.g., years/months/days, miles/yards/feet/inches).
  • Interest calculator: handling fractional years, days as a unit, and bug reports for 0.5-year inputs.
  • Basic calculator: scientific notation bugs and floating-point precision issues; some argue for exact arithmetic.
  • General: preserve state on back/forward, accept “$” and “%” in inputs, center layout, consistent naming, add bits/bandwidth units, right-align currency, improve keyboard-only operation.

Math discussions

• Multiple explanations of continuously compounded interest and its relation to limits and exponentials.
• Side discussion on dimensional analysis and amusing “uncanceled units.”
• Requests for better fraction support; suggestions to use Scheme, Python, or handheld calculators.

Security and reputation issues

• Some users report the site being blocked or flagged as phishing (OpenDNS, Sophos).
• There is confusion over TLS warnings, with the consensus that blocking infrastructure may be intercepting traffic.