Hacker News, Distilled

Smart meters: purposes and mixed results

• Rollouts in places like France, Ontario, Finland, UK, and US utilities mainly justified by:
  • Eliminating manual meter reads.
  • Enabling finer-grained settlement and tariff experiments.
  • Detecting theft, faults, and managing remote disconnect/throttling.
• Reported demand-shifting impacts are often small; auditors in Ontario questioned cost‑effectiveness.
• Some utilities (e.g., BC, Denmark, ConEd, UK) expose daily or sub‑hourly data to customers; others still show only monthly totals.

Dynamic pricing and user behavior

• Time‑of‑use and real‑time tariffs exist in many regions (Ontario, PNW, California, Nordics, UK):
  • Off‑peak can be dramatically cheaper (night EV rates, spot pricing with negative hours, UK Agile/Tracker).
• Thread splits on whether incentives are strong enough:
  • Some say people barely change habits unless price gaps are large or automated (EV charging, smart thermostats, heat pumps).
  • Others argue utilities under-use pricing levers or design tariffs that mainly raise peak revenue.
• EVs are repeatedly cited as the killer app for load shifting because charging is easy to schedule and dominates household usage.

Smart / controllable appliances and thermal storage

• Desire for “smart fridges” and other loads that pre‑cool, pre‑heat, or pre‑charge when power is cheap.
  • Existing examples: ice‑storage AC, smart fridges linked to utilities, water heaters and heat‑pump systems used as thermal batteries.
• Debate over feasibility and payoff:
  • Some see modest savings for fridges/freezers; others argue focus should be on water heating, HVAC, and EVs.
  • Disagreement on whether turning heating/AC or water heaters off for hours and then reheating saves net energy vs. maintaining setpoint; consensus that economics depend heavily on insulation and tariff shape.

Data access, DIY monitoring, and standards

• Many meters expose pulses, infrared or serial/HAN ports (P1, SML, Linky LED), enabling DIY logging via ESP8266/ESP32, Raspberry Pi, Home Assistant, InfluxDB/Grafana, etc.
• Commercial/consumer devices mentioned: Sense, Emporia Vue, iotawatt, Rainforest, HomeWizard, Glowmarkt, UK in‑home displays, Tesla/Powerwall dashboards.
• Frustration with:
  • Utilities blocking new HAN devices or encrypting data.
  • APIs restricted to legal entities or third‑party intermediaries; comparisons made to “open banking.”

Equity, privacy, and grid economics

• Concern that as self‑generation + batteries get cheaper, remaining grid costs will be pushed onto renters and low‑income users.
• Privacy worries around fine‑grained consumption revealing occupancy and behavior patterns.
• Some see smart metering and dynamic tariffs as essential to integrating renewables; others see them as primarily utility cost‑shifting and surveillance with limited consumer benefit so far.

Hardware choices for a “cheapest NAS”

• Many argue SBC-based NAS is fine but fiddly; others prefer used small form factor PCs (Dell/HP/Lenovo/NUC/thin clients) as more expandable, better supported, and often very cheap on the used market.
• Ex-corporate SFF desktops and thin clients are highlighted as sweet spots: $40–$200, low idle power, good connectivity, often enough for 1–2 drives plus NVMe.
• Some recommend dedicated NAS appliances (Synology/QNAP/TerraMaster) for people who value ease, monitoring, and vendor support over DIY savings.
• USB enclosures and DAS are discussed; reliability depends heavily on the USB–SATA bridge quality, and some brands are reported as failure-prone.

Performance, networking, and small files

• Several say 100 Mbps Ethernet is a real bottleneck; gigabit or 2.5 Gbps is preferred, especially for small-file workloads and Time Machine-like backups.
• Small files are dominated by latency, where faster links help even when bandwidth isn’t saturated.

ECC RAM, ZFS, and data integrity

• Strong debate over ECC:
  • One side: ECC is essential for any important data, especially with ZFS, to prevent RAM bit-flips corrupting on-disk data and checksums. Real anecdotes of silent corruption and bad memory are cited.
  • Other side: many have run ZFS/non-ECC for years without noticed issues; risks may be overstated for home use and most data (e.g., media) is not critical.
• Point made that backups solve different problems than ECC; silent corruption can propagate into all backups if not detected by checksums/scrubbing.

Backup strategies and cost

• For large home NASes (e.g., 28 TB), cloud backup is often expensive.
• Options discussed: B2, Wasabi, Glacier/Deep Archive, rsync.net, Interserver+borg, Storj, Hetzner storage boxes.
• Many conclude that for multi‑10‑TB datasets, a second NAS/backup server in another location is often more economical.
• Some use low‑tech rotation of external drives or a friend’s house NAS as offsite.

Access protocols and remote access

• Common local protocols: SMB/CIFS and NFS; also SFTP/SSHFS, WebDAV, Seafile, Syncthing.
• Remote access typically via VPN: Tailscale, WireGuard, ZeroTier, sometimes OpenVPN or Tor.
• Opinion that VPN is safer than exposing NAS ports directly; some rely on vendor “QuickConnect”-style relay services.

NAS vs just putting disks in PCs

• Some argue home “NAS” is cargo cult: often simpler and cheaper to put disks in existing desktops/laptops and share over the network.
• Counterpoints:
  • Laptops/phones/tablets dominate; they can’t easily host lots of disks.
  • Dedicated NAS avoids noise, uptime interruptions, and desktop reboots, and centralizes services like Plex, Docker apps, or Time Machine.

Expandability and storage layouts

• People ask for NAS systems where redundancy automatically adjusts as disks are added/removed; closest suggestions include Unraid, mergerfs+SnapRAID, Windows Storage Spaces, Greyhole.
• Note that automatic transition from mirrored to non‑mirrored as disks fill is generally seen as undesirable for anyone who truly cares about redundancy.

Power, reliability, and “cheap vs good”

• Low idle power is a recurring goal; SBCs and some mini‑PCs/NUCs can idle under ~10 W, but used desktops may be 20–50 W.
• Some emphasize that “cheapest” often ignores costs of power, time spent debugging flaky USB/SBC setups, and the higher risk of data loss without redundancy or robust hardware.

Scope of Anarchism and Its Definitions

• Commenters note there is no single agreed definition; “anarchism” is used so variably it borders on meaningless.
• Common threads offered: rejection of unjustified hierarchy; mutual aid; horizontal, voluntary cooperation; skepticism of both state and corporate power.
• Disputes arise over whether focusing on voluntary transactions leads to anarcho‑capitalism, how to treat private property, and whether anarchist communities could choose capitalist arrangements.

Practicality, Scale, and Historical Examples

• Critics argue anarchist structures work only in small groups, otherwise devolving into warlords, tribalism, or feudal city‑state dynamics.
• Supporters cite episodes in Spain, Indigenous/Zapatista zones, worker co‑ops, some online communities, and 12‑step groups as partial counterexamples.
• One side says Spain “worked” until crushed by major powers; the other replies that being easily crushed is itself evidence of unworkability in a hostile world.
• External predation and propaganda by centralized states are seen as key obstacles to any lasting large‑scale anarchism.

Authority, Democracy, and Worker Control

• A recurring principle: authority bears the burden of justification; unjustified authority should be dismantled.
• Many apply this primarily to corporations, described as unaccountable private dictatorships; they advocate worker‑run enterprises and stronger direct democracy (sometimes via digital “instant recall”).
• Others object that dismantling corporate power would itself require coercion and could breed new authoritarianism.
• There is a sharp debate over whether “choosing” to work under a boss is meaningful freedom or analogous to choosing slavery.

Terminology, Public Reception, and Strategy

• “Anarchism” is seen as rhetorically toxic; alternatives like “libertarian socialism,” “syndicalism,” or “social anarchism” are proposed but considered only partially helpful.
• Some argue that any movement whose goal is to reduce its own power is structurally disadvantaged against openly power‑seeking ideologies.

The Thinker, COVID, and Foreign Policy

• Several commenters admire the linguist’s work on media bias and US foreign policy.
• Others question his anarchist credentials, citing remarks on isolating the unvaccinated and perceived double standards toward communist vs Western crimes (Cambodia, Ukraine).
• Defenders reply that he consistently prioritizes criticizing his own state’s abuses and has explicitly condemned atrocities by non‑Western regimes.

Spanish Civil War, the Memoir, and Antifascism

• The book is valued as an eyewitness account of factional complexity and small‑scale humanity more than as pure theory.
• Disagreement over whether revolutionary left groups in Spain heroically pursued egalitarianism or disastrously undermined the anti‑fascist war effort.
• Extended side‑debate compares the historical harms of fascism vs communism, with no consensus.

Overall reception of the article

• Many agree the title is clickbait but the central idea is sound: naive boolean use leads to confusing APIs and hard-to-extend code.
• Others see the advice as too absolutist; booleans are fine in many places, and “never use booleans” could push beginners into needless complexity.

When booleans cause trouble

• Multiple boolean parameters (especially flags) degrade readability: foo(true, false, true) is hard to understand and easy to misorder.
• As features accrete, one flag becomes two, then three, etc., creating tangled conditionals and “boolean blindness.”
• Interdependent flags (e.g., arg3 only valid if arg1 is true) are hard to model safely with plain booleans.

Enums and richer types

• Enums (or sum types / tagged unions) make invalid states unrepresentable and document meaning explicitly.
• They upgrade better when a “two-state” assumption grows to more cases (e.g., multiple error reasons, more invoice types).
• Some worry about overhead: extra types, imports, and verbosity; others argue this is minor compared to debugging confusing flags.

Named / keyword parameters and options objects

• Many see named parameters / keyword arguments as the main cure: RaiseInvoice(taxInvoice: false, sendEmail: true).
• In languages without them, common patterns include:
  • Passing a single “options” struct/object.
  • Using language features like Python’s keyword-only args or JS/TS “options objects.”
• Some note you can’t force callers to use names, so APIs can still be misused.

Language-specific patterns and nuances

• JS/TS: options objects and string-literal unions are popular; opinions split on TypeScript enum vs union-of-strings.
• Python: Literal[...] and Enum plus type checkers; keyword-only params help.
• C/C++/Go: options structs and designated initializers used to simulate named args.
• Rust/Haskell/ML: strong enum/sum-type culture; related debates about Option<Enum> vs Enum with a Missing variant.

Broader design themes

• Core principle: model domain concepts explicitly instead of “just another bool.”
• Booleans remain appropriate for truly binary, obvious cases (e.g., “active/inactive”), but many argue even there, separate methods or small enums can be clearer.

Branch prediction and call/return behavior

• Several commenters note the core issue isn’t “fancy” prediction but violating basic assumptions: using mismatched call/return (BL/RET) breaks the return-address predictor’s shadow stack.
• This can cause large slowdowns and, on systems with architectural shadow call stacks, outright crashes.
• Some point out prior writeups of the same trap and highlight a simple fix: keep calls/returns balanced and, if you inline or restructure, replace RET with an ordinary branch (e.g., BR LR) so the predictor’s call/return pairing stays consistent.
• Others note that some modern x86 CPUs special-case common idioms like CALL + 0 to avoid polluting the return stack, so older “pessimizations” may no longer apply.

Hardware prediction vs explicit hints

• A tangent asks why CPUs guess branch/load behavior instead of letting programmers specify it.
• Replies argue that:
  • Extra hint instructions cost decode bandwidth and code size.
  • Most existing code predates sophisticated prediction, and hardware must accelerate unannotated binaries.
  • Capabilities differ across generations; Itanium/VLIW showed that relying on compilers for scheduling/general-purpose prediction failed commercially.
• High-level hints do exist (GCC/Clang likely/unlikely, C builtins, kernel macros), but:
  • They’re incomplete or wrong in many places.
  • Modern predictors often outperform explicit hints; extra hint instructions can even slow code.
• One detailed comment explains how an M1-like core must predict returns before decoding the RET, using a dedicated return-address stack.

Floating‑point summation, SIMD, and determinism

• Debate centers on why compilers don’t auto-vectorize float summations:
  • One side: summation is inherently approximate; any result within known error bounds is valid, so compilers should freely reorder and SIMD-ize for speed.
  • Other side: bit-for-bit reproducibility across builds, compilers, and CPUs is critical in many domains; implicit reordering breaks that and complicates debugging.
• Examples show that reordering additions of very different magnitudes can flip results dramatically.
• Libraries and toolchains vary: some use SIMD by default only for integer sums or provide flags to trade speed vs reproducibility; fast-math flags are described as powerful but numerically risky.
• More advanced summation algorithms (pairwise, Kahan, superaccumulator/xsum) are mentioned as ways to improve or make results exact, at some performance cost.

Performance and software bloat

• Commenters marvel at the nanosecond-scale loop times relative to 1 MHz-era CPUs, but contrast this with how “slow” modern desktop software feels.
• There’s a recurring theme that developer productivity stacks (Electron, heavy frameworks) trade away large amounts of performance; some see this as rational (time-to-market), others as user-hostile.
• Progress indicators are seen as masking, not fixing, unnecessary latency in modern UIs.

Language and assembly style notes

• Some dislike dense C idioms with side effects (e.g., *p++), praising languages that forbid them for clarity.
• There’s discussion of addressing modes: AArch64’s post-indexing (ldr s1, [x0], #4) vs x86 string ops (lods/stos/movs), and how they express “load and increment” patterns.
• Minor nits include unit switching (µs vs ns) and a mid-article switch from C to Rust, which some found visually confusing but not conceptually important.

Braces vs Python’s Significant Whitespace

• Many participants dislike relying solely on indentation for structure; they find deep nesting hard to track and consider braces a clearer, redundant signal.
• Others argue indentation is perfectly readable for reasonably sized functions; very deep nesting is itself a design smell.
• Some like Python’s minimal syntax and say braces add visual noise and cognitive load.
• A recurring joke: Python already “supports” braces via comments (e.g., #{ / #}) and with fonts/linters they can behave like real block markers.

Editor Tooling, Indentation, and Formatters

• Pro‑whitespace commenters say modern editors solve most indentation pain:
  • Indent guides, showing whitespace, auto-format-on-save, and refactoring tools.
  • Python formatters (Black, Ruff) are praised for removing style bikeshedding; Go’s gofmt and Rust’s cargo fmt play similar roles.
• Critics point out tooling doesn’t always exist in web UIs (GitHub diffs, merge requests) and not everyone uses heavy IDEs.
• Some like adding explicit “pseudo‑braces” in comments plus tooling to cross-check indentation against them.

Semicolons, Statement Boundaries, and Expressions

• Many consider mandatory semicolons “noise” since line breaks are visually obvious; Go and Python’s approach (optional semicolons) is cited approvingly.
• Others defend semicolons as useful redundancy, especially with long, horizontally complex code or expression-oriented languages like Rust, where semicolons distinguish expressions from statements.
• JavaScript’s automatic semicolon insertion is criticized as error-prone; Go’s algorithm is seen as safer and simpler.

Alternative Syntaxes and AST‑Centric Editing

• Several comments wish syntax were a mere view over an AST:
  • Different users could see braces, indentation, or other notations while sharing one canonical structure.
  • This could enable semantic diffs and refactor-aware merges instead of text diffs.
• Objections:
  • Harder sharing (snippets, blogs), loss of simple text tooling (grep, sed), and risk of proprietary, non-human-readable formats.
  • Style debates would just move to editor-layer representations.
• Related projects are mentioned: Unison’s AST storage, Lisp/S-expression approaches, structural editors, projectional editing, and JVM/CIL decompilation as partial precedents.

Broader Views on Python

• Some see whitespace sensitivity as a minor annoyance relative to deeper issues (performance, async, scoping), others as a core readability win that encourages cleaner code.
• There is both affection for Python’s “executable pseudocode” feel and sharp criticism of its syntax decisions and ecosystem politics.
• Multiple people note they’d rather spend energy on tests, design, and tooling than on brace/whitespace debates at all.

Scope of Proton Docs / Drive Announcement

• New collaborative docs editor integrated into Proton Drive; supports .docx and .txt upload, export to several formats (.docx, .pdf, .txt, .md, HTML).
• Aimed as a private, E2EE alternative to Google Docs within Proton’s ecosystem.
• Non‑Proton recipients must create a (free or paid) Proton account to access shared docs, which some see as collaboration friction.
• Built on acquired Standard Notes tech and Lexical editor; not written entirely from scratch.

Ecosystem Strategy & “Half‑Baked” Concerns

• Many paying users say Proton keeps shipping new products (Docs, Drive, Pass, VPN) while core Mail/Calendar/Contacts/Drive remain incomplete or rough.
• Common asks: CalDAV/CardDAV support, better calendar integration with other providers, richer sharing in Drive, more stable and capable mobile apps (especially Android).
• Some fear Proton is chasing enterprise/GSuite‑style “full stack” at the cost of polish and reliability.

Comparisons with Alternatives

• Fastmail frequently cited as more mature for mail/calendar/contacts (DAV support, solid apps, strong spam handling) but lacks Proton’s built‑in encryption/VPN.
• Other alternatives mentioned: self‑hosted CalDAV/CardDAV (Radicale, Baïkal), CryptPad, Zoho, HedgeDoc, Nextcloud, Bitwarden, KeePassXC, OnlyOffice.
• Several users prefer splitting services (email, VPN, password manager, notes, docs) across different vendors to avoid “all eggs in one basket.”

Privacy, Encryption, and Legal Reality

• Debate over Proton’s “E2EE” marketing: many emails are not end‑to‑end encrypted unless both sides use PGP.
• Some see the marketing as overselling; others note Proton’s docs explain limits and argue expectations should be realistic.
• Proton has complied with lawful requests (e.g., handing over IP or recovery email); critics call this “snitching,” supporters reply that operating within the law is unavoidable.
• VPN’s usefulness is debated: from “mostly pointless” to “critical for avoiding ISP tracking and geoblocks.”

Open Source & Trust

• Clients (including Drive) are open source in a monorepo; server side is closed.
• Some criticize delayed code pushes and “open‑source washing,” others say open clients are mainly for verifiability, not cloning competitors.

Overall Sentiment

• Split between enthusiasm (“finally a private Docs alternative, good enough for daily use”) and skepticism (“80%‑baked clones; fix email/calendar/mobile first; hard to rival Google’s network effects”).

Russian disinformation and Western response

• Several comments argue Russian online influence doesn’t need to be credible, only disruptive “noise.”
• Some propose countering by exploiting separatist movements inside Russia; others call this irresponsible, escalatory, and contrary to stated Western values.
• Alternative “push back” strategies suggested: strong rule-of-law messaging, decisive military support for Ukraine, better sanctions on Russian industrial capacity, and credible deterrent postures.

Separatism and destabilizing Russia

• One view: Russia could be weakened by supporting internal separatism, especially in border regions.
• Strong pushback: this is seen as delusional (e.g., for St. Petersburg), unlikely to work in an authoritarian nuclear state, and dangerously destabilizing if nuclear weapons fragmented.
• Some argue the US deliberately avoids total Russian collapse, fearing chaos, terrorism, and a tighter Russia–China alignment.

Propaganda and moral equivalence

• Debate over whether “both sides use propaganda” is meaningful.
  • Some insist Russian efforts are vastly more aggressive and tied to physical aggression.
  • Others highlight extensive US/Western propaganda and information units and reject a simple “Russia uniquely bad” framing.
• Accusations of whataboutism appear when Western actions are raised in response to Russian misdeeds.

Ukraine war: goals, costs, and analogies

• Split views on US/EU support:
  • One camp: aid to Ukraine is cheap and effective for weakening a rival without Western casualties; territorial aggression must be punished to preserve global norms.
  • Another camp: it’s an Afghanistan-style quagmire, diverts resources from domestic issues (e.g., border security), and Ukraine “can’t win.”
• Some think the West aims for stalemate, not victory, to damage Russia without risking collapse.
• Disagreement whether the war could have been prevented by stronger pre‑invasion deterrent moves.

2014 Ukraine events and “coup” claims

• One participant asserts the US/EU staged a coup in 2014 and later suppressed documentation; others demand evidence and cite first‑hand accounts of genuine protests.
• Overall, the thread shows no consensus; claims of staging are marked as contested.

Russia’s system and long‑term trajectory

• Several posts describe Russia as deeply authoritarian, sustained by fear, propaganda, and historical patterns of passivity.
• Some see the war as self‑destructive for Russia (loss of skilled workers, demographic damage, infrastructure decay), possibly pushing it toward Chinese dependence.

Information integrity and AI fakes

• Beyond the article, users note TikTok‑style fully fabricated “news” clips mimicking real broadcasters, seen as a new level beyond selective framing.
• One comment points out confusing phrasing in the original BBC article’s early paragraphs, later reportedly revised.

Nature of the AI Email and Ethical Concerns

• Many classify the outreach as spam, regardless of AI use, because it is unsolicited sales email.
• Central objection is deception: pretending to be a genuine fan while being AI‑generated outreach is seen as dishonest “by design.”
• Some argue the problem is less “AI” and more that this is scaled lying to thousands of people.
• Others note that human‑written cold emails and recruiter spam have long used similar tactics; AI mainly increases volume and polish.

Effectiveness and Marketing Incentives

• Reported results (~1% signups from ~1,000 emails) are debated: some say that’s very good conversion, others say it’s survivorship bias and still fundamentally spam.
• Concern that as tools spread, everyone will copy the tactic, leading to an “arms race” for attention and further degrading channels like email and LinkedIn.
• A minority see upside: bad sales jobs may disappear, though others respond this won’t reduce spam, just shift profits to platforms and tool vendors.

Impact on Email, Trust, and the “Dead Internet” Feel

• Many already treat email as a dumpster: newsletters, HR blasts, automated notices, and spam dominate; personal mail has largely moved to chat apps for some.
• Fears that AI‑personalized spam will make inboxes and open forums feel “dead” or bot‑dominated, further eroding trust in online reviews, posts, and recommendations.
• Some expect adaptation: people will ignore almost all unsolicited contact, rely more on word‑of‑mouth and in‑person networks, or use strict whitelists.

Spam Fighting and Countermeasures

• Concern that AI lets spammers evade classical Bayesian filters and makes spam harder for humans to spot.
• Counter‑ideas:
  • Personal AI agents that read, classify, and sometimes reply to emails; “agents vs agents.”
  • Stricter technical and social filters: block unknown senders, reputation systems, “verified human” schemes, or cryptographic proofs.
  • Practical hygiene: plus‑addressing, custom domains with per‑site aliases, GitHub’s private commit emails.
• Some note email already has strong infrastructure (blocklists, reputation, ML filters); others warn individually tailored AI messages may still slip through.

Legal and Regulatory Angle

• EU/GDPR context: cold sales emails to individuals without consent are said to be illegal in some countries; B2B is murkier under “legitimate interest.”
• Enforcement is viewed as weak; unsolicited outreach continues despite formal illegality.

Broader AI Attitudes

• Split views:
  • Skeptics see LLMs as probabilistic text generators enabling more manipulation, scams, and low‑value content.
  • Supporters highlight real utility for coding, language tasks, and information summarization, and argue benefits can outweigh spam if managed well.

Perceived impact of AI vs. other software

• Some see AI/AI infra as the only area with “real impact”; others argue impact depends on goals (money, science, helping people, solving societal problems).
• Many suggest ignoring hype and improving non‑tech‑first industries (logistics, agriculture, real estate, energy, healthcare, etc.) where software is still primitive.
• Concern that if AI will make current software obsolete, nothing else feels worth building; counterpoint: there’s a long road until then and today’s tools can have real, if temporary, value.

Value and limitations of current AI use

• Concrete benefits cited: coding assistance, documentation, meeting summaries, legal drafting, data cleanup, and domain‑specific process automation.
• Skeptics question how much revenue will actually be captured (e.g., low per‑seat pricing, “chat wrapper” fatigue).
• Debate on whether tools like ChatGPT/Claude are “real products” vs. commoditized infrastructure with thin UX moats.

Why AI infra startups are hard

• Intense competition from hyperscale clouds and large incumbents (AWS, Azure, GCP, Databricks, Vercel, etc.).
• Enterprises often have pre‑committed cloud spend and strong biases for in‑house builds or marketplace vendors.
• Many infra startups offer easily replicable functionality (RAG, model hosting, fine‑tuning, generic “LLMOps”), which internal teams or a single engineer can reproduce.

Startup strategy: focus, moats, and niches

• Repeated advice: narrow scope aggressively (e.g., from “AI platform” to a specific modality, then to a specific vertical problem).
• Infra based solely on hosting open‑source models at higher prices is seen as non‑viable; price and scale advantages favor big players.
• Niche, vertical infra (e.g., tailored to specific trades or industries) is viewed as more promising but hard to penetrate.

Enterprise buying behavior and risk

• Large organizations resist new vendors due to legal/compliance friction and fear of startup failure.
• Marketplace integration with major clouds can unlock spend but is slow and bureaucratic.
• Some enterprises report ignoring outreach from AI infra startups, relying on existing cloud contracts and internal tools.

Hype cycle, analogies, and unmet needs

• Many liken the moment to past hype waves (XML, big data, crypto, NFTs, metaverse), expecting a “trough of disillusionment” before durable products emerge.
• “Selling shovels” only works when tools are differentiated and non‑trivial; otherwise it becomes a “shovel rush” with commodity margins.
• Genuine unsolved needs mentioned: robust data cleaning, custom benchmarks, improving small models’ reasoning, and human‑in‑the‑loop semi‑automation.

Humor, Analogies, and Real-World Swamps

• Commenters connect the “just keep loading it” idea to the Monty Python swamp-castle gag.
• A real analogue is the Lucin Cutoff causeway across the Great Salt Lake, where railroads kept dumping rock into soft sediments, first building trestles and eventually a solid rock causeway that has been repeatedly raised and strengthened.

Floating Bridges and Failures

• Several floating bridges are cited: Nordhordland (Norway) and three on Lake Washington (Seattle), including the world’s longest.
• A former bridge engineer notes one of Seattle’s floating bridges is now on the lake bottom and shares an anecdote about retrofitting.
• There’s light debate on “unsinkable” claims; Seattle’s record of sinking bridges is mentioned with irony, along with the famous Tacoma Narrows footage.

Foundations, Piles, and Geotechnical Complexity

• Deep gravel and talus layers show that “bedrock” can be extremely deep or impractical to reach; some viaducts are founded entirely in loose rock deposits.
• Discussion of pile types: end-bearing vs friction (side resistance). Strong layers can be sand, boulder fields, or other dense strata, not just bedrock.
• Driving piles inherently tests capacity; resistance observed during driving informs design, but some cases (very deep soft soils, caverns, pressurized strata) can be problematic.
• Various geologic hazards are referenced: salt mines and lakes catastrophically connecting, mud volcanoes/diapirs, and anhydrite layers that can swell when hydrated.
• Wood piles can last a long time in fully saturated ground; decay is worst near the air–soil interface. Examples include historically pile-built cities and modern fence-post protection.

Infrastructure Funding and Tolls

• Debate over stopping tolls once a bridge is “paid off” vs. continuing tolls to fund future replacement and maintenance.
• Concerns raised about political inability to preserve dedicated funds and about fairness between current vs future users.
• Some argue for intergenerational investment in infrastructure; others see long-term pre-funding as a step too far.

Structural Shapes and Naming

• Clarification that “I-beams” and “H-piles” are different profiles: piles have thicker webs and flanges for axial load, while wide-flange (W) and S sections are optimized for bending.
• Terminology (I vs H) and pronunciation are playfully debated.
• Explanation of beam anatomy (flanges and web) is shared, along with a graphic reference.

Other Engineering Curiosities and Resources

• Mention of submerged and intentionally submersible bridges, plus a misdesigned floating bridge that sank.
• Interest in a specific animation style used in the video, though the software remains unclear.
• A popular documentary and book on the Brooklyn Bridge are recommended.
• A Japanese company’s “silent” pile-driving tech and novel applications (e.g., lava barriers, underground bike storage) are highlighted.
• The Practical Engineering site’s RSS feed is discovered, and some readers praise the channel’s depth and clarity.

Overall reception

• Many commenters find the engine sound simulator surprisingly fun and satisfying, calling it “addictive” and “delightful.”
• Some say it closely resembles real cars they’ve owned, especially under certain RPM and gearing setups.
• Several mention kids enjoying it, with at least one 4‑year‑old reportedly captivated.

Interface & simulation behavior

• Multiple reports of UI bugs: broken tapping on controls, gear field text being erased, parameters blowing up to infinity/NaN (notably when tweaking “Theta”), and needing to reload after switching sounds.
• Safari issues are noted; a partial workaround is reloading, selecting a sound, and clicking in the window.
• Mobile usability is poor; users request on‑screen buttons and/or gyroscope control.
• Some complain braking is unrealistically strong versus acceleration, and that deceleration sounds (including overrun/backfires) are underrepresented.
• Users enjoy “money shift” behavior (high‑RPM downshift) but note the physics are exaggerated into “comically high” RPM.

Creative uses and extensions

• Ideas: embedding this in a Raspberry Pi for kids’ steering‑wheel toys or bicycles, adding malfunctions/fault sounds, simulating gas turbines, drones, airplane propellers, and even “PsyOps” misdirection audio.
• People are curious how to contribute new engine models and what the recording/processing pipeline is.

Comparisons to other engine sound projects

• Thread notes that this tool uses soundbanks rather than full physical engine simulation.
• Several references to more advanced or alternative simulators, games, and synth‑based approaches, often praised as more realistic or technically ambitious.

EV and artificial vehicle sounds debate

• Large subthread on EV low‑speed warning sounds: some love the futuristic “spaceship/UFO” character; others find many designs harsh, dissonant, or “nightmarish.”
• Specific manufacturer examples divide opinion: some tones are admired, others called obnoxiously loud, especially in reverse or in dense cities.
• There’s tension between safety for pedestrians (especially when cars are very quiet) and the desire to reduce urban noise pollution.

Noise, regulation, and social norms

• Strong criticism of intentionally loud exhausts and artificial pops/bangs; some want stricter enforcement of noise ordinances.
• Others note many modern performance cars produce these sounds stock, complicating enforcement.
• Debate over synthetic engine/exhaust sound systems: some see them as antisocial “fake loudness,” others as a controllable way to add character.
• Broader disagreement about the future: quiet EV cities vs. preserving emotional, even simulated, engine sound experiences.

Negative leap seconds and their impact

• Many think a negative leap second is less disruptive than positive ones: no repeated second, just a “missing” one that often looks like a system pause.
• Concerns remain: some UNIX timestamps would become invalid, and “UNIX time → UTC” would no longer be infallible; code that assumes every integer second is valid could break.
• Others argue positive leap seconds are far worse, since they can map one timestamp to two different UTC instants and cause “time going backwards” bugs.

Should we have leap seconds at all?

• Strong camp: abolish leap seconds for civil time.
  • Humans tolerate hour-level errors via time zones and DST; a few seconds or even minutes over centuries would be irrelevant.
  • Leap seconds are non‑predictable (announced ~6 months ahead), which makes long‑range calculations and offline systems awkward.
• Counter‑camp: UTC’s raison d’être is to track Earth rotation (UT1) within ~1s; without that, we already have TAI.
  • Some navigation/astronomy workflows assume UT1–UTC stays under 1s; they’d need a replacement broadcast signal if UTC stopped tracking UT1.

Alternatives proposed

• Use TAI (or TAI+constant offset) for all computing; treat civil/solar time as a pure formatting problem via a database (like tzdb).
• Stop adding leap seconds to UTC and let countries occasionally adjust time zones by 15–60 minutes when solar noon drifts too far.
• Regularize adjustments:
  • Fixed-date annual leap seconds (or smearing adjustments) so systems are “well exercised.”
  • Rare leap minutes/hours or once‑per‑century corrections with ceremonial treatment.
• Make leap seconds first‑class in time formats rather than an awkward special case.

Software, protocols, and monotonicity

• POSIX/UNIX time is criticized as a design mistake: it pretends days are always 86400 seconds and hides leap seconds, complicating precise intervals.
• Some protocols (GPS, PTP) sensibly just count SI seconds since an epoch; UTC conversion is separate.
• Real systems often violate “monotonic clock” promises; language libraries have had to paper over clocks going backwards.
• A recurring suggestion: internal clocks should be monotonic (TAI‑like), and all leap behavior should live in the conversion layer.

Time zones, DST, and real-world practice

• Many point out time zones and DST already introduce far larger irregularities (missing/duplicated hours, non‑integer offsets, frequent political changes).
• tzdb updates multiple times per year; this is seen as a proven mechanism for handling civil‑time changes, in contrast to rare leap seconds that few systems test well.

Professional cycling: elitist or accessible?

• Some argue the Tour-level arms race in nutrition, tech, and budgets makes it a “sport of the 0.0001%.”
• Others counter that anyone can start on a cheap or used bike; at non-elite levels fitness and training matter far more than equipment.
• Debate over cost: mid/high‑end bikes ($2k–$8k) are out of reach for many, but older/used bikes can be very cheap; comparison is made to even more expensive sports (golf, hockey, motorsports).

Equipment, tech, and standardization

• Multiple calls to “go back to basics” or standardize bikes and parts, similar to Olympic one‑design classes or Japan’s keirin.
• Pushback that this would kill sponsor revenue and stunt consumer innovation (disc brakes, carbon frames, electronic shifting).
• UCI minimum weight (6.8 kg) shapes design; teams sometimes add ballast or choose heavier aero setups.
• Discussion of steel vs carbon: steel beloved for ride feel but seen as commercially niche; carbon dominates due to performance and tunability.

Doping, anti‑doping, and fairness

• Consensus that doping has been common historically; disagreement on how prevalent it is now.
• Strong anti‑doping regime described: biological passports, whereabouts apps, surprise tests, and bans for missed tests.
• Some see the fight as partly “safety first” and essential to keep sport from becoming a pharmacology contest; others view anti‑doping across sports as inconsistent or “losing.”
• Debate over where to draw lines between PEDs, therapeutic drugs, and nutrition; WADA’s criteria (performance, health risk, “spirit of sport”) are cited.

Mechanical doping

• Claims that hidden motors are the new frontier; others say evidence at WorldTour level is extremely thin and inspections (x‑rays, systematic checks) make it nearly impossible today.
• Historical suspicion and a few lower‑level cases acknowledged; scale at the top remains disputed.

Nutrition and gut training

• Strong interest in modern fueling: personalized carb intake (up to ~120 g/hour), gut training, glucose monitoring in training (but banned in races).
• Riders aim to maximize absorbed carbs without GI distress, using gels, custom drinks, rice cakes, etc.; some experiment with DIY mixes (sugar, maltodextrin, electrolytes).
• Recognition that even small % gains in fueling can decide results when GC gaps are minutes over 80+ hours.

Logistics, lifestyle, and extremity of the event

• Admiration for the logistical complexity: food trucks, traveling ice, bespoke chefs, and mobile support fleets.
• Some nostalgia for older, more “spartan” eras (self‑repair, scrounging food), but most accept that modern support exists to highlight athleticism rather than randomness.
• Comments note the rigid diets, rare “treats,” and psychological toll; yet many remain awed that any human can complete a Grand Tour at all.

AI Demand: Real or Manufactured?

• Some argue consumer demand for AI is “artificial,” driven by businesses seeking cost-cutting and investor hype.
• Others point to chatbots, code-completion tools, and services like Character.AI and ChatGPT (rapid user growth, heavy usage when free) as evidence of strong consumer interest.
• Several commenters stress that people’s complaints about cluttered search, bad ads, and inbox overload implicitly request better automation, even if they don’t say “AI.”
• Skeptics counter that many current AI deployments (search answers, social feeds, hiring filters) actively worsen user experience.

Usefulness vs Hype of LLMs

• Pro‑AI voices report major productivity gains: code generation, editing, summarization, translation, and “weekend projects” largely written by LLMs.
• Critics highlight unreliability, hallucinations, and low willingness to pay, describing LLMs as “amazing but not necessarily useful” for tasks needing accuracy.
• Some liken AI hype to crypto; others to the dot‑com boom: real underlying tech plus many grifters and bad products.

Google’s Emissions Numbers & Headline Framing

• The 48% emissions increase is relative to 2019; year‑over‑year growth for 2023 is 13%.
• Several comments say the CNBC framing over-attributes this “surge” to AI; the underlying report cites rising data center electricity and supply chain emissions generally, with AI mentioned as a future challenge, not the sole past cause.
• Others respond that AI is clearly a key driver of growing data‑center intensity and thus central to Google’s climate problem.

Corporate Climate Commitments & Hypocrisy

• Commenters note tension between past “planet-friendly” branding and massive new AI capex increasing energy use.
• Comparisons are drawn to oil‑industry greenwashing and shifting responsibility onto consumers.

Energy, Water, and Infrastructure

• Some see current emissions as “meaningless” in the long run, expecting eventual nuclear/solar dominance; others call this fantasy given rising global coal use.
• Discussion highlights that data‑center impacts also include heavy freshwater usage, which is under‑reported compared to CO₂.
• Ideas mentioned: reusing waste heat and water from data centers, more efficient chips, thermal solar, and advanced desalination.

Broader Societal & Economic Context

• Debate over whether automation historically drives broad prosperity or primarily squeezes middle-skill jobs amid housing constraints and inequality.
• Some argue AI-driven labor saving is fundamentally beneficial; others worry it accelerates “enshittification” and weakens the middle class without structural reforms.

Strength of the Archaeological Evidence

• Some see the link between 12k-year-old sticks/hearths and 19th‑century ethnographic accounts as too tenuous; they invoke Occam’s razor (fatty sticks and small fires could be common behaviors).
• Others note specific details: tiny hearths too small for cooking/heating, sharpened ends deliberately charred and inserted in the fire, coated in human/animal fat, and multiple instances at the same site. They argue this pattern is distinctive, not random.
• Debate over whether two finds ~1,000 years apart plus one 19th‑century description justify a 12k‑year continuity claim, or if this is a “birthday paradox” coincidence among countless lost rituals.

Healing vs Cursing and Use of Human Fat

• Popular coverage presented the ritual as healing; readers who checked the Nature paper highlight passages describing harmful magic/cursing using fat-smeared objects linked to a victim.
• Some argue this misframing shows the limits of pop‑sci reporting.
• Human fat use prompts concern and curiosity; commenters mention ritual cannibalism, fat harvested from corpses, and historical uses of human/animal fat as grease or folk medicine.

Longevity and Fidelity of Oral Traditions

• Strong skepticism that complex oral traditions can remain intact for 12,000 years, citing everyday “telephone game” drift and even confusion in recent family histories.
• Counterpoints:
  • Cultures can build strong error‑correction: poetic meter, ritualized chanting systems (e.g., Vedic recitation), multi-party cross‑generation checking, and high social value placed on exact transmission.
  • Isolated groups with harsh environments (like inland Australia) may rely intensely on ancestral knowledge for survival, reinforcing conservatism in ritual and story.
• Disagreement on timescales: some say oral accuracy collapses after ~100 years; others point to multi‑century stability in liturgy, epics, and songs, acknowledging gradual evolution rather than perfect stasis.

Comparisons with Other Myths and Rituals

• Flood myths (Epic of Gilgamesh vs Genesis) discussed as an analogy for long-lived narratives; debate over whether similarities imply direct borrowing vs common deep ancestry in a shared cultural milieu.
• Broader idea: many religious and ideological systems preserve ancient narrative “cores” while details shift.

Ritual, Placebo, and Social Function

• Some assume the ritual persisted because it produced perceived benefits (placebo, psychotherapeutic, or social cohesion).
• Others note rituals can endure purely as tradition or as socially sanctioned outlets for aggression (e.g., cursing instead of direct violence).

Interview question and “I don’t know”

• Large subthread on whether “I don’t know” is acceptable in interviews.
• Some argue freezing or offering nothing is a strong negative; candidates should at least reason aloud, make a best attempt, or say “I don’t know, but I’d try X.”
• Others strongly prefer direct honesty and dislike performative guessing, especially for trivial facts easily looked up.
• Several note that interviews are not real work: being pushed for instant mental math under pressure tests performance-anxiety handling more than problem-solving.

Critiques of tech interview culture

• Many see trivia-like or irrelevant questions (e.g., counting bits, precise time units, CSV-library minutiae) as low-signal and ego-driven.
• Stories of hostile or demeaning interviewers (including founders/CEOs) are common; commenters frame these as red flags about company culture.
• Some emphasize interviews as conformity and “dance” tests that select for those who play the game, not necessarily the best engineers.
• Others defend such questions as quick, standardized ways to see how candidates tackle unfamiliar problems or approach limits of their knowledge.

Search engine project and competition with Google

• Mixed reception to building a Google competitor: some welcome more search diversity; others doubt viability against a monopoly and note most attempts fail.
• Several focus on ranking quality: examples show bizarre results for common queries, leading to criticism that ranking is currently “wrong.”
• The developer acknowledges ranking issues and ongoing work; curated rankings are mentioned as a training signal for learning-to-rank models, but cannot cover all queries.
• One commenter sketches a “web-spidering firehose” service as an alternative infrastructure for many downstream search/indexing products.

Clickbait, marketing, and post removal

• Multiple comments say the “Google rejected me” framing is clickbait for a 15-year-old event, primarily used as content marketing for the search engine.
• The author later takes the page down, stating it attracted the “wrong sort of attention” and didn’t promote the engine as intended.

Politics, ethics, and “evil”

• Brief but heated debate on whether Google’s work with Israel constitutes support for genocide, with opposing views and links to human-rights reporting.
• Longer philosophical tangent on what constitutes “evil” and how large systems can facilitate harmful outcomes; others push back as overly abstract or exaggerated.

Mesh and topology quality

• Many commenters focus on topology as the main weakness.
• Generated meshes are described as “blobby” with poor, unusable wireframes, similar to photogrammetry scans.
• Automatic retopology/remeshing tools (built into DCC apps or tools like Instant Meshes, TopoGun) are seen as helpful but far from solving production needs, especially for animation/rigging and thin features.
• Some argue that “fixing topology” is nearly solved in geometry processing; professionals in games/VFX strongly disagree, saying manual retopo is still standard.
• Meta’s paper is criticized for not addressing topology much; Rodin is cited as a contrasting model that claims “clean topology.”

Textures, detail, and VR constraints

• Textures are viewed as improved versus older work but still low-quality: blown-out highlights, odd colors, and “uncanny smoothness.”
• Many note the heavy reliance on fake surface detail via textures/normal maps rather than actual geometry.
• VR is said to be especially unforgiving: stereoscopic depth reveals goopy low-res geometry quickly, though others counter that current VR games already rely heavily on baked/normal-mapped detail and look fine at typical distances.
• Displacement mapping is discussed: useful mostly offline; real-time engines mostly rely on normal maps.

Image-to-3D and current tools

• Meta 3D Gen is primarily text → multi-view images → 3D reconstruction → mesh, not single-image-to-3D.
• Other systems mentioned: Rodin, AssetGen, Meshy, Luma Genie, Meshroom, MeshAnything.
• MeshAnything is praised for good low-poly topology but limited (~800 polys), so not yet suitable for high-detail assets.

Practical usefulness for artists and pipelines

• Several people who tried commercial text/image-to-3D services report results as “unusable garbage” for real pipelines: baked, tangled meshes, awkward UVs, and textures that don’t match normal workflows.
• For 3D printing/CNC, some think bad topology “doesn’t matter”; others say it absolutely does (holes, flipped normals, non-manifold geometry).
• Consensus: promising for background props, prototypes, or as rough starting points, but far from “game-ready” or “rig-ready” assets.

Research, hype, and trajectory

• Multiple comments stress the gap between flashy demos/papers and production reality, but also point out how quickly 2D generation improved, suggesting 3D may follow.
• There’s enthusiasm about lowering barriers for VR, games, and 3D printing, but skepticism that 3D gen AI will spread as fast or widely as 2D, given 3D’s complexity, format fragmentation, and higher integration costs.

Role of Figma AI and What Went Wrong

• Tool produced a weather app UI that closely mimicked Apple’s, including layout and distinctive visual elements, not just generic components.
• Later clarification in the thread: the system did not “train” generatively on designs, but assembled from a prebuilt design system containing full app templates (e.g., weather, fitness). This makes the resemblance to Apple’s app look more like direct copying than emergent behavior.
• Some see this as embarrassing “AI dumping” driven by deadlines and investor pressure rather than careful product design.

Is This Actually a Big Deal?

• One camp: weather UIs are already very similar; copying patterns and layouts is routine across OSS and commercial apps, so this is a “nothing-burger.”
• Another camp: this specific output is too derivative in both layout and style; if many teams start from these AI outputs, UI will become even more generic, and provenance will be impossible to track.

IP, Copyright, and Scale

• Many comments frame generative AI as an industrialized “rip-off engine,” exploiting others’ work and styles without credit or compensation.
• Concern that existing copyright law is hard to apply when users can unknowingly ship near-clones produced by AI tools.
• Others argue UI primitives (buttons, switches, patterns) shouldn’t receive stronger IP protection; overprotecting interfaces could harm interoperability and innovation.

AI, Creativity, and Value of Knowledge

• Debate on whether AI is creative or just remixing:
  • Some say humans also remix, but at small scale; AI operates at industrial scale, which changes the ethical and economic stakes.
  • Others insist humans generate genuinely new knowledge, whereas current models only mimic patterns from training data.
• Anxiety that mass AI content will devalue knowledge and creative work, especially distinctive visual styles.

Business Models, Data, and “Technofeudalism”

• Several comments describe AI companies as converting user data and behavior into sellable features; users are both customer and product.
• GenAI is framed as part of a broader “technofeudal” dynamic where everyone’s creative output becomes unpaid training data for large platforms.

AI Hype and Product Quality

• Pattern noted: companies rush out flashy AI features, then revoke or walk them back after public backlash or legal risk.
• Some still think Figma is one of the few places where generative UI tools could be genuinely useful, which is exactly why these issues surfaced so starkly.

Definitions and conventions

• Two main Busy Beaver functions discussed:
  • Σ(n): max number of 1s left on tape at halt.
  • S(n): max number of steps until halt.
• Notation conflicts: some use BB(n) for steps, others for marks. Recent work and publicity tends to use BB = steps.
• For 5-state, 2-symbol machines, current results: S(5) = 47,176,870 steps; Σ(5) = 4098 ones.

Nature of the BB(5) result and proof

• The 5-state, 2-symbol blank-tape halting problem is now completely classified.
• Proof is formalized in Coq (~19k lines). Earlier proofs and “deciders” existed but were fragmented and partly mistrusted.
• Coq formalization tightened confidence, especially for tricky non-halting machines that needed bespoke acceleration or long manual reasoning.

Limits, undecidability, and BB(6)+

• BB(6) is known to be at least absurdly large; a specific 6-state machine (“Antihydra”) behaves like a Collatz-type iteration and seems intractable without new mathematics.
• Related 2-state, 5-symbol “Hydra” machine and Mahler-style distribution conjectures are mentioned as barriers.
• General incompleteness results guarantee some BB(n) are unprovable in standard systems; concrete encodings give independence around n ≈ 700+, far above 5.
• Debate over whether BB(6) or BB(7) could already encode undecidable behavior; many find that unlikely but not impossible.

Behavior and structure of champion machines

• Observed output patterns for small champions often look fractal or self-similar (e.g., “bouncing” growth giving parabolic patterns).
• Two conjectural trends:
  • “Spaghetti code” conjecture: larger champions become increasingly chaotic.
  • “Clean code” conjecture: winners might have simple, structured programs but implement exotic mathematics.
• Some expect a mix of both; systematic trends might be too strong to be true, since they’d overly aid search.

Variants and combinatorics

• Other formulations: counting steps vs marks, lambda-calculus / Kolmogorov-style busy beavers, multi-symbol variants (e.g., 2 states / 4 symbols).
• Formula for number of n‑state, 2‑symbol TMs: (4(n+1))^(2n); with certain reductions, (4n+1)^(2n), giving ~17 trillion 5‑state machines.
• Determining exact halting percentages for 5‑state machines is nontrivial due to normal forms and multiplicities; unclear in thread.

Philosophy and value

• Some question practical payoff versus “more relevant” work.
• Responses emphasize:
  • Intrinsic curiosity and personal fulfillment.
  • Historical pattern where abstract theory later gains applications.
  • Role of Busy Beaver as a clean window into computability, the halting problem, proof complexity, and limits of formal systems.
• Discussion also touches on whether human insight could in principle transcend fixed formal systems for specific halting questions; views diverge.