Hacker News, Distilled

Dynamo vs Battery Bike Lights

• Strong praise for hub dynamos for daily commuting: “just works,” no charging/forgetting, hard to steal, long-lived systems comparable to car lights.
• Counterpoint: modern lithium batteries offer far more energy per weight/cost; a small pack can power lights for many hours. For casual riders, batteries may be more rational.
• Pro‑dynamo arguments stress reliability and convenience over energy density: no removal/re‑mounting, no forgotten charging, fewer cheap lights breaking.
• Debate on drag: typical modern hub dynamos draw a few watts; several claim speed loss is negligible versus other drags (clothing, poor chain maintenance). Some note low efficiency figures (≈50–60%) but still find real‑world impact small.

Smart vs Dumb Hardware & App Dependence

• Broad hostility to “app for everything”: users want physical controls for core functions (bike lights, dishwashers, dryers, shredders, TVs).
• Many see app‑ification as rent‑seeking: subscriptions, “value‑add services,” captive advertising, vendor lock‑in; data sales viewed as secondary but present.
• VC funding is blamed for pushing recurring revenue models over traditional one‑time hardware sales.
• Some suggest classic alternatives: sell hardware + optional support, instead of subscriptions and lock‑ins.

Connected Bikes, Startups, and Bricking

• Multiple examples of e‑bike/“smart bike” systems becoming unusable: Copenhagen Wheel, certain Accell/Sparta bikes, VanMoof configuration/account issues.
• Custom proprietary parts and app‑locked functions (lights, unlocking) make used/second‑hand ownership risky.
• A few argue some VanMoof generations can be reset or unlocked without the app; early models appear more limited.

IoT Creep in Appliances and Vehicles

• Complaints about hidden essential functionality behind apps (dishwashers, dryers, Bosch examples), touchscreens on simple devices, and persistent cloud prompts.
• Concern that car features and telematics (including examples like 3G shutdown stranding Subaru modems) create future failure modes and geopolitical risks.
• Fears of embedded connectivity (eSIMs, mesh systems like Sidewalk) bypassing user attempts to keep devices offline.

Repair, De‑Smarting, and Regulation

• Some predict a future cottage industry for “de‑smarting” devices or pre‑dumbing new purchases, constrained by cost of labor and liability.
• Suggestions include: mandatory offline functionality for essential operations, clear labeling for internet dependence, open or documented protocols, and interoperability for e‑bike batteries/motors.
• Underlying theme: declining trust in manufacturers; “buyer beware” seen by some as insufficient without stronger consumer protections.

Overall reactions to the map

• Many find the map fun and broadly recognisable, especially for seeing their own “small” areas (e.g. Pompey, Coventry, Corby) explicitly labeled.
• Others argue it’s “badly out of date” and too coarse: dialects can change every ~20 miles, and many fine-grained distinctions are missing.
• Several people note that drawing hard borders is inherently misleading for what is really a continuum of speech varieties.

Perceived inaccuracies and omissions

• Southern England:
  • Cockney is seen as over-represented; commenters say traditional Cockney is rare now, with Multicultural London English/“roadman” speech much more common.
  • Kent, Sussex and Essex are described as a patchwork of estuary, older rural accents, and London spillover, not well captured by a single label.
• Midlands & North:
  • Coventry, Wigan/Oldham/Bolton, and parts of the West Midlands and North West are said to have distinct accents/dialects that the map flattens.
• Scotland & NI:
  • Complaints about “Grampian” instead of Doric, and about Scots/Doric being treated as outside scope; some insist Scots is a separate language.
  • Debate over whether Northern Irish English counts as “British English” vs. Hiberno-English.

Dialect, accent, class, and identity

• Repeated confusion and debate over “accent” vs “dialect” (just pronunciation vs vocabulary/grammar differences).
• Class is described as a key axis in England: people were actively taught “posher” speech; RP is said to be largely dead, replaced by Standard Southern British.
• Several stories of bullying or exclusion based on sounding “too posh” or “not from round here”; accents function as social and regional markers.
• Race and migration also shape patterns (e.g. MLE, Scottish inflows to Corby, Irish and Scottish influence in Northern England).

Change over time and media influence

• Many note dialect levelling: older local forms (rural Sussex, West Yorkshire, Shropshire, Norfolk, Ozark/Appalachian in the US) are fading.
• American media influence is blamed for shifts like “better→bedder”, “fall” for “autumn”, “zee” for “zed”, and flattened cosmopolitan accents.
• Others point out that local speech remains surprisingly resilient despite mass media; social media may be accelerating newer, non-local styles.

Comparisons and wished-for features

• Comparisons drawn to dense dialect continua in Italy and Germany, and to France where regional languages/accents were heavily suppressed.
• Multiple people wish for an interactive version with audio samples per region, and cross-links to related resources (e.g. rhyming slang, accent videos, academic work).

Reactivity model, laziness, and mental model

• Solid’s fine‑grained, “immediate” reactivity is widely praised as intuitive and easy to debug; many don’t want laziness added by default.
• Concern: lazy memos or push/pull propagation could violate “principle of least astonishment” (reading a value secretly triggering work) and resemble React’s concurrent mode complexity.
• The creator clarifies that laziness is being explored mostly for memos, not wholesale async semantics, and Solid already has Suspense. Some users are still uneasy but open to it if optional.

Ecosystem, libraries, and components

• Multiple users have built medium‑to‑large apps with Solid and found ecosystem “serviceable” for forms, remote state, tables, routing, and various primitives.
• Clear downsides: far fewer ready‑made component libraries than React; virtual lists, complex UI widgets, touch/animation/map/dataviz libs are thinner, sometimes under‑documented, and you hit edge cases faster.
• Integrating vanilla or “headless” JS libraries is reported to be straightforward, and some users build their own internal ecosystems over time.
• Solid Primitives is seen as high quality but perceived by some as stagnating. For heavy enterprise‑style data grids, nothing matches React+MUI’s breadth; SUID (MUI for Solid) exists but performance concerns are noted.

Comparisons with React, Vue, and Svelte

• Compared to React:
  • Similar JSX and “JS‑first” feel, but no virtual DOM: components run once and signals drive targeted DOM updates.
  • Many feel this fits their mental model better than “rerender everything unless memoized”, and avoids many React gotchas/hooks rules.
  • Others argue React’s problems often stem from mismanaged gotchas rather than the tool itself; large, well‑disciplined React apps can be very fast.
• Compared to Vue/Svelte:
  • All now converge on signal‑based, compiler‑assisted reactivity; several commenters say Solid’s ideas influenced newer Vue/Svelte designs.
  • Svelte/Vue offer SFC/template‑driven, HTML‑first DX and larger ecosystems; Solid offers plain JS/TS everywhere and less “magic”.
  • Preference splits strongly on JSX vs templates and on separation‑of‑concerns vs locality‑of‑behavior.

Maturity, 2.0, and DX rough edges

• Solid 2.0 is still in discussion; no firm release timeline.
• Some see the small, mostly single‑author core and relatively low commit count as a sign of focused design and low churn; others see high bus factor and smaller community as risk.
• Reported rough edges: weaker docs, alpha/immature devtools, some APIs to avoid (certain Suspense patterns, createUniqueId, occasional SolidStart routing slowness), and subtle reactivity gotchas (e.g., losing reactivity when destructuring props).
• Despite this, several users say Solid is a “joy” after a day of React, but acknowledge ecosystem gaps and maturity issues make it better suited to smaller or more experienced teams today.

Hardware quality and stagnation

• Several commenters argue Synology’s hardware has lagged for years: aging CPUs (e.g., 7‑year‑old Ryzen parts in “new” models), 1 Gbit networking on “Plus” units, no true NVMe volumes or NVMe‑only models, and removed USB/codec features.
• Others report their units (e.g., DS18xx series) as fast and reliable enough for typical SOHO workloads and appreciate the small, quiet, hot‑swap form factor.

Drive locking and vendor lock‑in

• The new policy for 2025 “Plus” models (only Synology‑branded drives with full performance/features; reduced functionality for others) is widely seen as the tipping point: “betrayal,” “enshittification,” and a deal‑breaker for many long‑time users.
• People object especially to:
  • Artificially degrading performance or disabling features (deduplication, lifespan analysis, auto‑firmware) with third‑party drives.
  • Obfuscating vendor/firmware info, which makes it harder to avoid same‑batch drives and correlated failures.
• A minority express some sympathy: vendors got burned by WD’s undisclosed SMR “NAS” drives and don’t want the support burden/blame. Many counter this justifies selling “known‑good” drives or showing warnings, not hard lock‑in.

Software ecosystem vs openness

• Synology’s DSM and apps are praised for “appliance‑like” reliability and ease: O365/Google backups, Hyper Backup, Active Backup, Synology Drive, simple photo backup, quick setup with almost no admin.
• Others say the first‑party apps have regressed (loss of HEVC, removal of Video Station, weak photo/gallery UX, slow Docker/kernel updates) and now rely mostly on Docker/SynoCommunity apps like Syncthing, Jellyfin, Immich.
• Many note that Synology’s only real moat is DSM; drive lock‑in undermines goodwill that made people recommend it at work as well as at home.

Alternatives and migration paths

• Strong interest in moving to:
  • TrueNAS (Core/Scale) on DIY or vendor hardware.
  • Unraid, Proxmox + ZFS/btrfs, OpenMediaVault, plain Debian/Ubuntu.
  • Ubiquiti’s UNAS, QNAP (sometimes with Debian), Ugreen, Terramaster DAS + mini‑PC, N100/NAS enclosures, used server boards.
• Some suggest treating the NAS as storage‑only (TrueNAS/UNAS) and running Plex/containers on a separate mini‑PC or NUC.

Broader sentiment

• Many long‑time Synology users say this single policy moves the brand from “default recommendation” to “avoid,” even if it doesn’t affect current boxes.
• There’s skepticism that chasing higher margins on drives will succeed: Synology risks alienating the tech‑savvy prosumers who historically amplified its reputation.

Project overview & participation

• Browser-based distributed project extends computational verification of the Goldbach conjecture slightly beyond the earlier bound of 4×10¹⁸, to about 4×10¹⁸ + 7×10¹³.
• Many commenters report contributing billions of checked numbers from desktops and phones; some note issues when running multiple tabs in one browser as work accounting doesn’t behave intuitively.

Language and wording discussions

• Several comments dissect the article’s phrase “no one has proven it mathematically up until now,” arguing it falsely implies a proof now exists.
• Consensus: use “no one has proved it mathematically” (or “has yet to be proved”), with some preference in mathematical writing for “proved” over “proven,” though not all agree this is prescriptively required.
• Nuances of “proved/proven/proofed” and similar irregular verbs are debated at length.

Verification and correctness concerns

• A major thread analyzes the protocol and finds the server only receives, per job, a single Goldbach decomposition (p, q) and some timing/client token with no strong cryptographic or mathematical guarantees.
• Commenters show it is easy to fake completed ranges or under-compute work without server detection; thus malicious or faulty clients could hide counterexamples.
• Suggested remedies include returning full decompositions with primality certificates, duplicating jobs among multiple clients, or more sophisticated cryptographic proofs.
• The project’s creator openly acknowledges that, given the open, no-login design, rigorous prevention of fake results is not currently solved.

Significance of the “world record”

• Many argue the extension is only ~0.000001–0.000002 of the previously verified range, likening it to placing a coin on a skyscraper and calling it a new tallest building.
• Others counter that strictly speaking, the largest verified bound is indeed a “world record,” but agree the “shatters world record” framing is overstated.
• Some criticize the claim as clickbait, especially given the verification gaps; others see it as harmless motivation for volunteers.

Performance, implementation, and UX

• WASM Go implementation is acknowledged as slower than native Go; prior 2012-era native code appears much faster for similar tasks.
• 64-bit integer arithmetic suffices for the current range.
• Many praise the smooth in-browser UX (e.g., live counterexample count), and some share nostalgic stories of writing Goldbach checkers as early programming exercises.

Overall sentiment

• Mix of enthusiasm for the idea and implementation with strong skepticism about mathematical rigor and the marketing language.

Conventions vs enforced structure

• The proposed pattern is praised for simplicity and debuggability but questioned on maintainability in large teams.
• Critics note it relies purely on convention, so nothing prevents divergence; class-based or framework-based APIs (e.g., UIKit-style) enforce structure and predictability.
• Others counter that all codebases ultimately depend on conventions; making developers consciously own those conventions can improve understanding, at the cost of discipline.

Manual DOM, micro-frameworks, and templating

• Several commenters share similar “views the hard way”: small helpers, template literals, or React.createElement-style helpers that build DOM directly.
• Benefits cited: performance, easy debugging, no build step, minimal abstractions, and “learning the platform.”
• Downsides: nested templates become hard to compose; full re-renders blow away focus and cursors; managing granular updates and selectors gets fiddly.

State management and DOM-as-source-of-truth

• One camp treats the DOM (textContent/value/checked) as the canonical state, using getters/setters on Web Components and avoiding separate JS state variables.
• Supporters say this avoids divergence between JS state and UI and keeps code concise.
• Critics argue it fails to scale: complex UIs with shared data, lists, and redundant views need separation of data and presentation; using DOM as state runs into issues with non-text state, browser extensions mutating DOM, and coordination across components.
• Others advocate a single centralized state object plus clear architectural patterns instead of scattering state across components.

Security and templating/XSS

• String-based HTML building with template literals is repeatedly called “begging for injection attacks.”
• Some rely on server-side sanitization; others argue this is unsafe or context-insensitive when the client generates HTML from JSON.
• There’s detailed debate distinguishing sanitizing (filtering) from escaping/encoding, and emphasizing context-aware escaping at render time or building DOM trees instead of raw HTML strings.

Reactive frameworks vs “vanilla”

• Many argue React-style reactivity is absolutely worth the complexity once UIs and dependency graphs grow, especially in teams.
• Others say most apps are small enough that reactive frameworks are overkill, and that the industry over-tilted to client-side rendering.
• There’s nostalgia for Backbone-like patterns and interest in modern lightweight tools (lit-html, signals, small micro-frameworks) that give some reactivity without full frameworks.

Web Components and ecosystem culture

• Web Components are proposed as a natural fit; some note the original repo predates broad support, but examples already use them.
• Broader complaints surface that frontend lacks the kind of “batteries-included” conventions backend ecosystems (e.g., PHP frameworks) provide, leading to endless reinvention and fractured patterns.

Rotation and cosmic isotropy

• Commenters note that a rotating universe would introduce a preferred axis and thus anisotropy, contradicting a core assumption of standard cosmology.
• Constraints from the CMB (especially dipole consistency with our velocity) are cited as strong evidence against large-scale anisotropy.
• The “axis of evil” in CMB data is mentioned; some argue it suggests a cosmic axis, others point to later analyses (e.g., 2016 WMAP/Planck comparison) finding no significant anisotropy. Disagreement remains in the thread about how compelling this “axis” actually is.

Center, axis, and reference frames

• Several people question what it even means for the universe or spacetime to rotate: rotate relative to what?
• Others counter that rotation is absolute (unlike linear motion) because it produces observable effects like centrifugal and Coriolis forces; no external reference is required.
• A rotating spacetime would imply a central axis and potentially undercut conservation laws derived from spatial symmetries, so it would be a major revision to modern physics and demands very strong evidence.

Black-hole interior and Gödel-inspired models

• The paper’s black-hole-interior and Gödel-inspired rotating cosmology prompts discussion of whether a rotating universe implies a center, whether we could be “inside” a black hole, and if so what “center” means (singularity lying in the future, not a spatial location).
• People link this to closed timelike curves in Gödel’s solution and note that the paper claims a rotation near the maximal value that still avoids CTCs at the horizon.

Finite vs infinite universe and Planck-scale digression

• Long sub-thread debates whether the universe is finite or infinite, emphasizing that “denser in the past” does not automatically mean “spatially small,” and that an infinite universe can expand.
• Another sub-thread argues over whether Planck length is a true minimum length or just a measurement limit, and how this interfaces with special relativity, QFT, and renormalization. Consensus: current theories break down near that scale; what really happens is unknown.

Galaxy spin anisotropy and evidence

• A previously publicized claim of preferred galaxy spin direction is raised as possible support for cosmic rotation.
• Other commenters say that work is widely viewed as cherry-picked and note papers titled along the lines of “no evidence for anisotropy in galaxy spin directions.”
• One participant asks for direct, paper-level rebuttals of that specific study; the response points to earlier null-result studies rather than a dedicated post hoc refutation.

Hubble tension and numerical plausibility

• One commenter performs rough “napkin math” and finds the paper’s implied angular velocity (~4×10⁻²⁰ rad/s) is only an order of magnitude below that which would give tangential speeds ~c at the observable edge.
• Another notes that this rough factor-of-10 proximity is in the same ballpark as the few-percent Hubble tension, suggesting it’s at least not obviously absurd, but this remains an informal numerical sanity check, not a consensus.

Subjectivity of “cozy” and how games relieve stress

• Commenters give a wide range of “comfort games,” from stereotypically cozy titles (A Short Hike, Stardew Valley, Animal Crossing, Dorfromantik, Unpacking, Tiny Glade, No Man’s Sky, Euro Truck Simulator, House Flipper, Walkabout Minigolf VR) to puzzlers and exploration games (Myst/Riven, The Witness, Monument Valley, Breath of the Wild, Mutazione).
• Others relax with what look like “un-cozy” games: Dark Souls, Elden Ring, Doom, Factorio, MTG Arena, Cyberpunk 2077, Warzone, Valheim, etc. For them, flow state, mastery, repetition, or escapist immersion—rather than aesthetics—reduces anxiety.
• Several note that even solitaire, simple web games, or old titles played without FOMO can be deeply soothing.

Stardew Valley as comfort vs. chore simulator

• Some describe Stardew as profoundly comforting: an idyllic world of predictable routines, controllable problems, and the ability to improve NPCs’ lives.
• Others experience it as stressful: time pressure, energy bars, crop calendars, “never-ending to‑do lists,” min-max spreadsheets, and fishing or collection mechanics that feel more like work.
• People highlight darker themes (corporations, homelessness, PTSD, war) and argue it still feels cozy because you’re empowered to help—though some just ignore the story and farm.

Hard games, flow, and coping with hardship

• Multiple anecdotes claim FromSoftware-style difficulty helped with depression, heartbreak, or layoffs: overcoming tough but “fair” challenges counters learned helplessness and provides structure.
• Comparisons are drawn to religious ritual or “risky play” as ways to shift mental focus and reclaim agency. Others argue soothing, low-threat activities are equally important.

Design of “cozy”: beyond genre and violence

• Several argue “cozy” is less about farming or cuteness and more about: low penalties, optional combat, gentle pacing, clear control, and the freedom to ignore systems you dislike.
• Others prefer cooperative or sandbox games over competitive ones, seeing standard adversarial multiplayer as inherently non-cozy. Some find cozy aesthetics uncanny or pointless and instead relax with horror or violent shooters.

Psychological, social, and societal threads

• Games are framed as coping tools, not cures; underlying environments and stressors still matter. There’s discussion of anxiety theories (overactive threat vs. underused soothing systems, or need for tolerable risk).
• Some push a bleak view that life is inherently nightmarish; others counter with philosophical arguments about attitude, meaning, and helping others.
• Debate arises over games’ net societal impact, gender participation (with pushback against the claim that “few women play”), and comparisons to other leisure (books, TV, walking, sports).

Article UX and “cozy” media contradictions

• Many praise Reuters’ scrollytelling presentation as beautiful and calming; others find the scroll-hijacking, nonstandard navigation, and heavy visuals anxiety-inducing or inaccessible.
• A few note the irony of a soothing piece ending with links to grim geopolitical stories, and question whether “cozy escapism” is being promoted against a backdrop of worsening news.

What “hype” means and whether it’s inherently bad

• Some see hype as pure manipulation: a substitute for objective evaluation, used to push tech (cloud, AI, blockchain) into orgs regardless of fit, cost, or risk.
• Others argue hype is just the noisy exploratory phase of real innovation: lots of people trying lots of ideas, most failing, but some becoming foundational.
• Several note there’s now “anti‑hype hype”: railing against trendy tech is itself a way to signal sophistication without engaging specifics.

Is AI/LLM tech revolutionary or overblown?

• Pro‑AI commenters claim LLMs are “S‑tier” advances, comparable (or close) to PCs, the web, or smartphones: fast mass adoption, broad applicability, and major productivity gains (especially for coding and knowledge work).
• Skeptics argue that putting LLMs on that list now is premature; true revolutions are obvious only after they withstand time and become infrastructural.
• A recurring demand from doubters: concrete present‑day examples of businesses or workflows that are dramatically better than non‑AI competitors, not just projections about future models.

Capabilities, reliability, and appropriate use

• Supporters report big speedups in everyday tasks (writing, debugging, searching, explaining complex topics), describing LLMs as qualitatively different from search because they synthesize and adapt responses.
• Critics emphasize hallucinations, basic reasoning errors, and non‑determinism, arguing that tools you must constantly double‑check are unsuitable for many business processes.
• Some frame the divide as: people willing to accept probabilistic, fallible tools vs those who expect computers to be reliably correct.
• There’s consensus that LLMs work best where answers are hard to derive but easy to verify, or where they’re one component in a filtered/checkable pipeline.

Hype vs reality in industry and economy

• Multiple comments describe companies chasing AI “because we must” without clear problems to solve, echoing earlier VR, blockchain, and cloud migrations.
• AI is also seen as convenient cover for layoffs, hiring freezes, and rent‑extraction by large vendors, with little demonstrated net productivity so far.
• Environmental and resource costs (energy, water, datacenters) are raised as a serious downside given uncertain societal payoff.

Context from past hype cycles

• Comparisons are drawn to the internet, mobile, cloud, blockchain, VR, and “metaverse” booms.
• Cloud and smartphones are broadly acknowledged as real wins that were also heavily hyped; blockchain and NFTs are cited as mostly hype.
• Databases, GPUs, broadband, and other low‑glamour tech are held up as examples of under‑hyped but hugely impactful advances.

Data sources & coverage

• Commenters speculate records are scraped and aggregated from many disparate state, county, and federal systems, each with its own interface.
• For federal courts, people assume much of the content ultimately comes via PACER and RECAP / Free Law; court documents themselves are uncopyrightable once obtained.
• Users report that the site includes state, county, and even minor matters (traffic tickets, misdemeanors), not only federal cases.
• Several note substantial gaps: missing chancery courts, missing personal cases, and no hits for at least one very high‑profile criminal case.

PACER, costs, and access

• PACER normally charges per document/view but has a free tier for low‑volume users; law firms are said to be the ones mostly paying.
• RECAP users effectively subsidize free access by uploading documents they’ve already paid for.
• One commenter clarifies PACER gives access to actual PDFs, while some other tools expose only indexes unless you pay.

Previous security / “sealed” records incident

• Multiple people reference an earlier incident with the same site involving a government vendor whose court system lacked real access controls and relied on obscurity of URLs.
• “Sealed” files were not actually sealed; the situation is blamed on poor government contracting and vendor practices rather than the indexer.

Search features & UX

• Users like the full-text capability and speed but want:
  • Query parameters in URLs for sharing.
  • Structured queries (e.g., defendant=X, cause=Y).
  • Better filters (e.g., only full case texts, fewer patents) and sort options by filing date.
• Some note odd ranking behavior (Tennessee results dominating, patents crowding results).

Privacy, “right to be forgotten,” and jurisdiction

• Debate over whether a free public index could handle EU‑style erasure requests; some say this is why it likely focuses on US records.
• Several explain that in much of Europe:
  • Court records aren’t broadly searchable, names are often anonymized, and background checks require the subject’s cooperation.
  • GDPR “right to be forgotten” generally targets search engines, not deletion of court archives.
• Others argue that in the US, such a right conflicts with transparency and the public’s interest in remembering lawsuits; expungement is limited and does not bind third parties.

Misuse, background checks, and personal fallout

• Concern that hiring/background‑check SaaS might integrate this database, making old or minor records far more consequential.
• Some worry that making “authority gossip” so accessible is unhealthy, especially for family searches.
• Multiple anecdotes describe mistaken identity and records being attached to the wrong person over years, plus “spooky” near‑matches on names and biographical details.

Content quirks, patents, and tech

• The index includes patent records and citations, surprising some who discovered their work being referenced.
• People amuse themselves with odd phrase searches (“sandwich murder”) and the unexpected contexts that appear.
• Technical users identify Elasticsearch as the backend, with public API docs showing index mappings.

Limits of Batteries for Aviation and Shipping

• Many commenters agree that with current lithium-ion energy density (tens of times worse than jet fuel per kg), long‑haul aircraft and ocean‑going cargo ships are not realistically electrifiable.
• Fixed battery weight (unlike fuel that burns off) hurts aircraft efficiency and landing performance; some argue this alone keeps large electric airliners impractical.
• Electric VTOL and air taxis are seen as especially energy‑hungry (2.5–3× per mile vs conventional flight), further limiting range and economics.
• Some highlight that marine drag and constant high power demand make pure battery ships challenging beyond short routes.

Where Electric Propulsion Does Make Sense

• Several note existing or planned electric ferries, tugs, and short‑range tourist or commuter boats that already pencil out on cost and noise/emissions.
• Small training aircraft and very short‑haul routes are cited as feasible early niches for electric planes.
• Many emphasize that electric road vehicles (cars, scooters, e‑bikes) are already economically and technically competitive for most everyday use.

Alternative Fuels and Non‑Battery Options

• Strong interest in synthetic hydrocarbons, methanol‑to‑kerosene, ammonia, hydrogen, and biofuels as “drop‑in” or near‑drop‑in solutions for aviation and shipping, powered by cheap clean electricity.
• Skeptics argue e‑fuels are only 10–15% efficient “round‑trip” and would require enormous extra generation capacity; supporters counter with falling renewable costs.
• Wind‑assist and modern sail concepts for cargo ships, plus slow steaming, are discussed as partial decarbonization paths.
• Nuclear marine propulsion is seen as technically viable but hampered by capital cost, regulation, crew requirements, and security/political concerns.

Economics, Policy, and Infrastructure

• Several argue that aviation appears “cheap” because fuel is tax‑favored; adding fuel and CO₂ taxes would push more travel to rail, especially if high‑speed rail were expanded despite high upfront costs.
• Others stress that regulation and pricing (e.g., airport bans for fossil planes, special electricity tariffs) could rapidly change today’s economics.
• There’s debate over whether long‑distance flying will become an elite luxury vs remaining accessible via synthetic fuels and policy choices.

Critiques of the Article’s Claims and Framing

• Multiple commenters say the piece uses clickbait framing (“dirty secret”), straw‑mans no‑one’s position, and mixes up power vs energy and cost metrics.
• Specific numbers (e.g., $5/kWh scooter electricity, lifecycle cost per kWh, “70% of energy before the vehicle moves”) are challenged as off by factors of 10 or based on misapplied LCOE concepts.
• Some track cited references and find broken links, misattributed studies, or selective interpretations; in several back‑of‑the‑envelope recalculations, EVs come out cheaper and cleaner than portrayed.
• Critics also fault the author for lumping aviation and all marine vessels together, ignoring that short‑haul ferries and small boats have very different constraints from intercontinental jets or container ships.

Battery Technology Trajectory

• One side notes physical/chemical limits on lithium‑ion and estimates that matching jet fuel energy density would take many decades, if ever.
• Others point out that battery cost has plummeted, density has roughly doubled in a decade, and modest further gains plus new chemistries could steadily expand the set of viable electric niches—even if jumbo jets never go fully electric.

What Changed

• CPython’s hashlib/HMAC implementations are being switched from OpenSSL (and other ad‑hoc code) to HACL*, a formally verified cryptographic library.
• HACL* code is proved memory‑safe, functionally correct, and designed to avoid major timing/memory side channels.
• The change is a drop‑in: Python code using the standard crypto APIs doesn’t need modification.

Performance and Safety

• Main goal is safety; however, performance is also treated as a hard requirement for deployment.
• Reported performance for replaced algorithms is similar or better; Blake2 specifically became faster due to more optimized code and proper CPU feature detection.
• Some note that constant‑time, side‑channel‑resistant code can be slower, but prior code already aimed at this, so a big regression isn’t expected.

Formal Verification Debates

• Supporters emphasize that formal proofs in F* are machine‑checked and far stronger than tests or dynamic typing, likening them to “static types on steroids.”
• Skeptics argue large proofs (15k LOC of verified code) are likely to contain mistakes somewhere and that “verified” shouldn’t imply absolute trust; it reduces classes of bugs but doesn’t cover everything (e.g., algorithm choice, higher‑level protocol flaws).

Lines-of-Code and Dependency Concerns

• Some criticize “15,000 lines” as a boastful or poor metric; others say it’s just conveying scope/coverage and implementation complexity.
• Worry that Python now “depends on Microsoft” is countered by pointing out HACL*’s permissive licensing and the fact CPython vendors the generated C; there’s no runtime tie to Microsoft tooling.

Implementation Details

• Crypto primitives are written and verified in F*/Low*, then compiled to C with KaRaMeL; a paper is cited claiming the F*→C translation preserves semantics and side‑channel properties.
• During integration, a missing treatment of allocation failures in the original library was discovered and addressed, illustrating that verification has boundaries (it proves certain properties, not “everything”).

Python Versioning and Ecosystem Impact

• The new crypto backend lands in Python 3.14, not earlier maintained versions.
• Some argue it should be treated as a security hardening fix and backported; others note Python’s policy and the difficulty.
• Significant discussion highlights how many popular libraries lag on supporting new Python releases, and that minor Python versions frequently introduce breaking changes, creating friction and long upgrade delays.

Broader Cryptography and Society

• Tangential debate covers: modern crypto being “practically unbreakable” vs. risk of backdoors and implementation flaws, focus shifting from link‑level interception to endpoint compromise, and regulatory/attestation pressures limiting users’ ability to deploy secure software.

Open / Unclear Points

• Whether this work will expand stdlib features (e.g., streaming SHAKE output) remains unclear; related issues are currently closed as “not planned.”
• Reusability of the new streaming verification framework beyond hashes is raised but not substantively answered.

Scope of the ruling & what’s actually unconstitutional

• Commenters clarify this is about blanket cell-tower “tower dumps” (mass lists of all phones hitting a tower), not all use of phone data.
• Narrowly targeted requests (e.g., “was this specific number on this tower at this time?”) are seen as more likely to remain constitutional because they are particularized.
• The breadth is key: sweeping in data from large numbers of uninvolved people resembles a “general warrant” barred by the Fourth Amendment.

Good-faith exception vs. “fruit of the poisonous tree”

• Much debate centers on why evidence wasn’t suppressed despite being obtained via an unconstitutional warrant.
• Some explain the long-standing “good-faith exception”: if police fully disclose what they’re doing, get a warrant, and reasonably believe it lawful, courts often admit the evidence even if the warrant is later ruled invalid.
• Supporters say suppression is meant to deter intentional or reckless violations, not honest reliance on a judge’s mistake.
• Critics argue this neuters the exclusionary rule, incentivizes “constitutional crapshoots,” and creates a double standard where citizens can’t rely on ignorance but the state effectively can.

Police power, accountability, and judicial responsibility

• Many comments express deep distrust of U.S. policing: comparisons to gangs, references to civil asset forfeiture, qualified immunity, and near-impunity for rights violations.
• Some argue judges who approve unconstitutional warrants face no real consequences, and that without accountability the Constitution becomes “optional” in practice.
• Others caution that punishing judges for later-overturned decisions would destabilize the legal system, given evolving precedent.

Interrogations, lying, and citizen behavior

• Long subthread on police deception: it’s generally lawful for officers to lie in interrogations (e.g., claiming a friend “already confessed”), and this is seen as abusive, especially toward innocents.
• Strong recurring advice: do not talk to police without a lawyer, even as a victim or witness, due to risk of being turned into a suspect.

Third-party data, geofencing, and future battles

• The ruling is viewed as one step in a larger fight over the “third-party doctrine” (whether data held by companies loses Fourth Amendment protection).
• Commenters note geofence and cell data were heavily used in other cases (e.g., Jan 6 investigations); some welcome limits, others worry about losing a powerful investigative tool.
• Concerns raised about parallel construction and paid data brokers as workarounds to warrant limits.

How to Argue with an “AI-Can-Do-It-All” CEO

• Many comments say appealing to “humans are valuable” won’t work; you must frame objections in terms of:
  • Profit risk, brand damage, and personal downside for leadership.
  • Concrete failure modes: hallucinations, legal exposure, outages, lost customers.
• Several suggest: don’t argue in the abstract; propose constrained experiments, A/B tests, and ROI comparisons rather than blanket rejection.

The 48‑Hour “Let AI Run It” Trial

• One camp supports a short, AI-only trial:
  • Let leadership “feel the pain” and see the mess; this becomes evidence humans are needed.
  • Assume the cleanup is manageable and worth the lesson.
• Another camp pushes back:
  • Deliberately creating “mess” is still damage and wasted resources.
  • Risks of “temporary” experiments becoming permanent or being extended (“48 hours wasn’t enough to evaluate”).
  • Emphasis on cost–risk–benefit analysis and prevention over stunt demos.

Limits and Dangers of AI in Sales and Support

• Multiple real-world examples: AI-written code and Copilot guidance causing production outages; AI support bots hallucinating features and promises (e.g., booking discounts, nonexistent product capabilities).
• Concern that LLMs optimize for being convincing, not correct:
  • They may manipulate or superficially “fix” issues rather than address root causes.
• Some propose narrow, tool-like use:
  • AI as search + routing + task creation, with strict constraints and human escalation.
  • No freeform promises, confirmations, or closing.

Human Sales, Relationships, and Ethics

• Stories of deals influenced by shared hobbies, strip clubs, VIP rooms, and flattery:
  • Some see this as evidence of cronyism/corruption and an argument for AI-led, more “objective” sales.
  • Others say interpersonal trust and relationship-building are integral to B2B sales and risk assessment, even if “less than ideal.”
• Observation that AI-generated “personalized” outreach is already flooding inboxes:
  • It feels dishonest and devalues the entire channel; recipients stop reading any of it.
  • Advice: do the opposite of what AI mass-automation does if you want to stand out.

Broader System Critiques and Role Reversal

• Several note the article’s mortgage/commission framing really indicts an economic system where one bad quarter = ruin, more than it indicts AI.
• Many sarcastically suggest replacing the CEO, shareholders, or CXOs with AI first:
  • Used to highlight power asymmetry and the selective enthusiasm for “replacement.”
• Some think the article’s ultimatum setup feels unrealistic or like “cope,” and aren’t convinced the specific roles described truly require humans.

QR Code Scanning & Platform Compatibility

• Many reports that iOS’s native camera says “No usable data found”; explanation that iOS camera won’t treat data: URIs as clickable targets even when the payload is tiny.
• Workarounds suggested:
  • Use a web-based QR decoder (e.g., upload the PNG and copy the decoded URI).
  • Use third‑party QR apps or desktop software that accept image input.
• Initially the game didn’t support mobile controls and was effectively desktop‑only; later, after size optimizations, limited touch support was added for Chromium-based mobile browsers.
• Several users saw a black screen on Firefox/iOS/Android; fixes were pushed and later reports say it works, though some browser quirks (focus, key mapping) remain.

Data URLs, Compression, and Size Golf

• The QR encodes a data:text/html (originally base64) payload; discussion on:
  • Using raw text data: URIs vs base64 to shave bytes.
  • Browser restrictions on top‑level data: navigation (bookmarks vs links).
  • Using DecompressionStream and tight HTML/JS trimming to free more space.
• A PR reduced payload size enough to add touch controls, better movement, and enemies.
• Side discussions reference similar micro‑demos, procedural games, and WASM-in-QR projects.

Security & Malware Concerns

• Multiple commenters worry about “running code from a QR code.”
• Others argue this is equivalent to opening any arbitrary URL with JavaScript; the real risk is malicious sites, not the QR format itself.
• Historical exploits via image/audio parsers are mentioned as examples of what’s possible if decoders are buggy.
• Some propose standard or UX improvements (e.g., enforcing human‑readable URL text matching the QR).

Design Choices, UX, and Aesthetics

• Debate over using image-rendering: pixelated: some prefer crisp pixels; the author prefers the blurrier, “retro” look.
• Criticism that a QR-based game not primarily targeting phones is a “design issue”; the author cites tight size budget for mobile UI but invites others to build variants with the compression tooling.
• Multiple requests for screenshots/GIFs instead of only a trailer; a GIF and gameplay media were later added, plus a hosted version to bypass scanning.

Technical & Conceptual Spin‑offs

• Explanations of QR capacity and 8‑bit mode enabling arbitrary binary data; examples include encoding RSA keys and prior “game-in-a-QR” work.
• Ideas floated: QR-embedded 3D print files, low-resource comms via QR over SSTV, self-contained P2P chat (blocked by browser limits), and even “LLM in a QR”–style experiments.

Interview Format and Credibility

• Several commenters found the piece hard to read because it’s essentially an unedited Zoom transcript, arguing that what works for a podcast doesn’t for text.
• Some questioned editorial sloppiness (e.g., name errors) and unclear institutional descriptions as early “red flags.”

Why College Towns Feel Different

• College towns work partly because most students don’t have cars, must live close to campus, and share similar schedules and life patterns in a compact area.
• This creates walkability and dense social life that’s hard to replicate when adults work in dispersed locations, have partners with different commutes, and default to cars.
• Downsides noted: transient populations, heavily worn student housing, and landlords with little incentive to maintain quality.

Car-Centric Culture vs Walkable Urbanism

• One camp argues US car-dependence is culturally entrenched but also economically and infrastructurally unsustainable, citing high vehicle costs, maintenance burdens, and failing rural road systems.
• Others counter that cars are affordable if you avoid luxury models, that gravel roads to shrinking towns aren’t a “failure,” and that people rationally choose cars and suburbs.
• Some see mitigation (better design, protected bike lanes, safer crossings) as possible; others say even modest changes face fierce political resistance.
• There’s debate whether US has a true “housing shortage” vs a distribution and jobs-location problem; both sides cite data.

Suburbs, Life Stages, and Alternatives

• Many say dense, walkable college life suits young people, while older adults with kids want space, quiet, and perceive suburbs as “paradise,” not “hell.”
• Others note suburbs need not be car-dependent; European examples show suburban buses and rail can work if land use allows.
• Multiple commenters stress that retrofitting US sprawl for transit would require massive rebuilding; expectations of “1,000 Amsterdams” are seen as unrealistic.

Culture, Noise, and Place

• A tangent on loud music at Puerto Rican beaches sparks debate about cultural relativism versus overgeneralizing “local culture.”
• Some locals and travelers describe pervasive noise (music, vehicles) as a serious quality-of-life issue, not just a quirky cultural trait.

Housing, Density, and Homelessness

• Strong arguments that restrictive zoning and opposition to new housing (“vocal minorities”) directly produce homelessness and extreme rents, especially in places like San Francisco.
• Others respond that more units alone won’t solve visible street disorder without parallel enforcement and social services.
• There’s nostalgia for historic SROs/boarding houses as a lost “safety valve” between normal housing and street homelessness, while others recall them as miserable but still better than sleeping outside.

Nature of College Towns as Enclaves

• Some view modern universities as semi-closed “all-inclusive resorts” with their own services and police, partly insulating students from wider urban problems and possibly dampening activism.
• Others prefer more integrated models where campus and city fabric grow together.

Commercial vs Open Source ASN.1 Tooling

• Several comments contrast OSS Nokalva’s commercial suite with open‑source tools (OpenSSL’s ASN.1, libtasn1, asn1c, Heimdal, etc.).
• Commercial tools are valued for SLAs, timely bugfixes, robustness on huge specs (e.g., 3GPP), and full support for ASN.1 Value Notation and non‑crypto domains (telco, banking, biometrics).
• Open source tools are seen as buggy or incomplete for complex specs and sometimes require patching; licenses of commercial compilers often block open‑source redistribution of generated code.
• Others argue alternatives like Protobuf/FlatBuffers avoid ASN.1 entirely, which is why many choose them when they can.

Language Ecosystems and Specific Libraries

• Erlang’s ASN.1 implementation is praised; Java users discuss now‑missing or archived tools and hunt for maintained compilers/libraries.
• Java options (asn1bean, BeanIt, JAC ASN.1, older IBM tools) are mentioned, with mixed completeness and age.
• JavaScript’s asn1js is cited as effective for browser‑based PKI.
• Rust’s rasn library gets attention for broad codec support (BER/CER/DER/PER/APER/OER/COER/JER/XER), performance claims (especially OER), and an in‑progress compiler to generate Rust bindings from ASN.1.

Telecom, UPER, and 3GPP Challenges

• UPER is described as significantly harder than DER and prevalent in telecom; commenters claim no open tool reliably handles 100% of real‑world UPER/3GPP specs.
• Problems include massive, complex ASN.1 modules, tricky constraints, information object classes, and specs shipped as DOCX/PDF.
• Commercial compilers are said to keep up with new 3GPP revisions faster than open tools, easing device and vendor interoperability.

ASN.1 vs Other Serialization Formats

• Some urge new protocol designers to at least study ASN.1 instead of “reinventing” formats like Protobuf, which is characterized as a simpler, incompatible re‑take on TLV ideas.
• Others push back, citing ASN.1’s perceived complexity and large “surface area” versus simpler IDLs.
• Historical anecdotes describe why DER was chosen for PKI (determinism and canonical encoding) and compare ASN.1 to XDR, DCE/RPC, XML, JSON.

Canonical Encodings and Signing

• One thread recounts signatures breaking after a MsgPack library change; switching to ASN.1 DER fixed this by providing canonical encodings.
• Cryptography‑focused replies emphasize signing raw byte strings and treating encodings as untrusted; canonical formats like DER can be the chosen byte representation but are not strictly required if protocols are designed carefully.

Native Code vs Pure Python

• Some miss “pure Python” libraries for portability and ease of installation; others argue modern wheels and tooling have reduced that pain.
• There’s debate over Python’s pattern of pushing performance‑critical paths into native code (C, C++, Rust). Critics dislike needing multiple language skills; defenders say users don’t need to “master” the native language to benefit.
• For cryptographic workloads, many see native code as unavoidable for speed and certification reasons.

Security, Parsers, and Specification Quality

• Parser differential attacks on ASN.1 are noted as an under‑appreciated problem; a stronger, more consistent implementation is welcomed.
• Discussion references ASN.1‑related CVEs, with the claim that most issues stem from poor implementations (e.g., OID handling, length calculations), not inherent flaws in ASN.1 itself.
• Formal, machine‑readable specifications (ASN.1, extensibility markers, information object classes) are defended as reducing ambiguity and long‑term errors, at the cost of more sophisticated tooling.

Project Origins and Funding

• The new Python ASN.1 work is funded via a Linux Foundation security initiative backed by major cloud vendors.
• Commenters clarify the idea came from the Python cryptography ecosystem and was then pitched to the funding program, not imposed top‑down.
• Some hope that, alongside this Rust‑backed approach, pure‑Python options will remain available for users who prioritize portability over performance.

Reactions to IBM’s RTO and “near-customer” mandates

• Many see the sales-location and cloud RTO rules as a de facto layoff tool and way to shrink expensive US headcount without formal redundancies, especially for older, rooted workers.
• Some note that being near customers makes sense for field sales, but forcing time in IBM offices when teams and clients are elsewhere is seen as pure control theater.
• Reports of poor office conditions (stale equipment, no desks, more distractions) reinforce that this isn’t about productivity.
• Others doubt the article’s “DEI purge” framing and see the headline as rage-bait compared to the actual memo content.

Remote vs Office Work: Does It Work?

• Experiences are sharply mixed. Some companies found WFH clearly didn’t work (especially for new teams/juniors, onboarding, weak management, open-plan offices), and quietly reversed course.
• Others report fully remote engineering and consulting working extremely well, with strong onboarding and processes, and view RTO as management fashion or stealth cost-cutting.
• Fraud and interview cheating in fully remote hiring are raised as real issues; some anticipate more in-person interview checkpoints.
• Several argue the real divide is by role, seniority, and personality (introvert/extravert), not one-size-fits-all policies.

Stealth Layoffs, Offshoring, and Age Bias

• Commenters link RTO and relocation demands to IBM’s long history of “resource actions” and age discrimination (“dinobabies”), now combined with visible hiring growth in India and new labs there.
• Forcing moves or long commutes is described as a legal way to induce older, better-paid staff to resign.

DEI Rollback, Politics, and IBM’s History

• Many see IBM aligning opportunistically with the current US administration’s anti-DEI stance to protect federal contracts.
• Others say this is mostly gutting DEI programs (outreach, HBCU events, internal teams), not explicitly firing “DEI hires” – but worry it will function that way in practice.
• IBM’s historic complicity with the Third Reich and later unethical behavior is invoked as evidence that profit routinely trumps ethics.

Broader DEI and Meritocracy Debate

• Thread contains a long, conflicted debate:
  • One side: DEI = racist quotas, undermines individual equality, should be replaced by race-blind, poverty-focused mobility efforts.
  • Other side: structural racism and bias (including in hiring and education) remain; DEI is an imperfect but necessary corrective and opportunity pipeline.
• Disagreements center on: whether diversity improves performance; whether current evidence for that is strong; and whether focusing on race vs class is fair or counterproductive.

Legal and Enforcement Concerns

• Some argue explicit “DEI purges” or DEI-based terminations would be straightforward discrimination cases—if agencies and courts actually enforced the law.
• Others point out tactics like forced relocations create “constructive dismissal,” but proving discriminatory intent is hard, especially with weakened labor enforcement.

What actually went wrong in the story

• Commenters reconstruct the incident as a stack of failures:
  • Health insurer only exposes critical info (in‑network hospitals) via a mobile app.
  • The app is region-locked to the UAE app store.
  • The author’s Apple account region conflicted with this, so installation was blocked.
  • In an emergency, this added time, stress, and risk.

Who is to blame: Apple vs insurer vs healthcare system

• One camp says the insurer and healthcare setup are primary culprits:
  • In-network rules for emergencies are “nuts.”
  • Requiring an app instead of phone/web for life-or-death decisions is seen as negligent.
• Another camp argues Apple shares blame by enforcing region locks and not allowing straightforward sideloading.
• A third group insists Apple is just implementing developers’ wishes; the insurer chose app-only access and geo-restrictions.

Geo-locking, region restrictions, and side-loading

• Multiple reports of region-locked banking, ISP, and telco apps causing problems while traveling.
• Android users highlight that they can usually bypass store restrictions via APK download; iOS users cannot.
• Some consider any platform-level support for geofencing “working against the user”; others say legal/compliance demands make it necessary.

Apps-only access for critical services

• Strong criticism of “app-only” banking and insurance, especially when websites are crippled or funnel mobile users into QR-code app downloads.
• Several note that even in the EU and US, some banks or credit cards are now app-only or app-preferential.

Broader concerns about walled gardens and corporate power

• Some see this as emblematic of how corporations have turned mobile into a fragmented, region-bound, fragile ecosystem.
• Others zoom out to a civil-liberties frame: restrictions on what you can run on a device you own, and geo enforcement by private companies.
• There is meta-debate over whether people underplay corporate responsibility by deflecting blame to “the way things are” or governments.

Android vs iOS and safety beyond healthcare

• Multiple commenters recount navigation and hiking incidents where app failures, updates, or connectivity caused dangerous situations.
• Consensus emerges that phones are powerful but unreliable for safety-critical tasks; redundancy (paper maps, phone numbers, backups) is advised.

Cloud migration and technical modernization

• arXiv is moving from Cornell-hosted VMs to Google Cloud, with a “Cloud Edition” plan: containerizing services, introducing Kubernetes/Cloud Run, asynchronous processing, better monitoring/logging, and replacing remaining Perl/PHP backend code.
• Some see this as a normal technical-debt cleanup and capacity upgrade, driven by increased load (especially from AI crawlers), growing submissions, and spam/AI-generated papers.
• Others argue they could have stayed on self-managed containers (e.g., k3s, Docker Swarm) or just used a CDN, and that k8s adds unnecessary complexity.

Cost, vendor lock-in, and corporate influence

• Multiple comments worry about:
  • Cloud bills ballooning beyond the roughly $88k/year arXiv previously budgeted for servers.
  • Gradual dependence on provider-specific services making “moving back” infeasible once old infrastructure and knowledge decay.
  • “Capitalist capture of the commons” and another public-good service becoming dependent on a mega-corporation.
• It’s noted that Google is a gold sponsor; some suspect GCP credits and co-marketing as part of the deal. Opinions differ on whether that’s benign sponsorship or a risky subsidy.

Privacy, control, and censorship

• Some fear reduced privacy: Google could observe who reads which papers, though others point out Google already sees much via search and tracking.
• A strong thread focuses on sanctions and access: experiences are shared of GCP traffic to Iran being silently dropped; dispute exists over whether Google or Iran is doing the blocking, but historically GCP has blocked sanctioned countries for some services.
• Commenters argue this will likely worsen access for users in Iran and similar countries, with debate over whether such blocking is “ideal” or a loss for global science.

arXiv as public infrastructure and alternatives

• Several see arXiv as de facto public/scientific infrastructure and would prefer:
  • A consortium of international academic libraries or a nonprofit governance model.
  • Federated or distributed architectures where anyone can mirror/clone the corpus; centralized operators become curators rather than single points of failure.
• Others counter that networking, power, and hosting have long depended on corporations, and that using GCP doesn’t automatically hand control of content to Google.

UI, tooling, and hiring side threads

• UX opinions split: some want a modernized interface; many like the lean, “ASCII-style” UI for speed and clarity.
• There’s discussion of the Perl+LaTeX-heavy stack and confirmation that LaTeX remains dominant in many math-heavy fields, often via tools like Overleaf.
• Commenters note US-only hiring, Cornell’s hiring pause, and debate remote/on-call models, but it’s unclear how much these constraints will delay the migration.