Hacker News, Distilled

Power use, duty cycle, and interactivity

• 24 mA draw implies only ~10 hours on the suggested battery; several comments question whether LoRa devices can be made to last much longer.
• Others note LoRa receive current is not “free”; continuous listening drains batteries significantly, so real low-power designs require long sleep periods and event-driven wakeups.
• LoRaWAN-style devices work by letting battery nodes sleep most of the time and a mains‑powered gateway listen continuously; this tradeoff is harder in symmetric peer‑to‑peer chat.
• Some propose beacon-and-sync schemes to reduce duty cycle, but these run into legal duty-cycle limits (e.g. 1 % on 868 MHz in EU) and complexity.

Range capabilities and technical limits

• Reported real-world LoRa ranges vary from a few km in cities to 30–60 km line-of-sight, and over 100 km with a balloon.
• Range depends strongly on line-of-sight, modulation settings, and legal duty-cycle constraints; robust settings give low data rate but excellent sensitivity.
• LoRa is viewed as poor for heavily obstructed or underground use; through‑earth and bunker scenarios are better served by much lower frequencies and different modulations.

Regulation, licensing, and encryption

• LoRa in ISM bands faces duty-cycle and sometimes message-count limits; human chat is seen as “pushing it to the limits” of what it was designed for.
• GMRS/FRS and ham options are discussed extensively: licenses, type-acceptance, digital/data restrictions, time limits on digital bursts, and removable-antenna rules.
• Encrypted mesh systems (e.g. Meshtastic on 900–930 MHz) are fine on unlicensed bands but not on amateur allocations; enforcement is perceived as lax on encryption but stricter on power.

Hardware, UX, and design choices

• The choice of an ATtiny814 is debated: some praise its simplicity, robustness, peripherals, and adequacy for this narrow task; others argue modern ARM/RP microcontrollers offer far more capability for similar price.
• Old-school multi-tap numeric input is criticized for RSI and slowness; some wish for T9‑style prediction or a QWERTY keyboard.
• Confusion arises over power: one person complains about AAA-only and poor life, but others clarify this design supports LiPo via JST.

Alternatives, practicality, and use cases

• Suggested alternatives include Meshtastic T‑Decks, RAK base stations, GMRS text-capable handhelds, simple FRS radios, Wi‑Fi + SIP/IRC/Mumble setups, and even private GSM with SDR (not legal in most places).
• Some see Meshtastic and similar devices as solutions in search of a problem; others imagine strong use cases in camping, disaster backup, and youth “adventure” communication.
• Users highlight protocol challenges (collision avoidance, time-slicing, synchronization) when scaling beyond simple two‑node links.

Windows bloat, ads, and user-hostility

• Many commenters see modern Windows as actively hostile: adware in the OS, OneDrive/Xbox/Office nags, attempts to move home folders to OneDrive, and increasingly coercive OOBE flows that push Microsoft accounts and cloud backups, sometimes even bricking machines when account access is lost.
• Copilot, Recall, and AI-in-everything are viewed as “features nobody asked for” added to serve Microsoft’s revenue and lock-in goals, not user needs.
• Nostalgia is strong for Windows 2000 and 7, seen as peak “respect the user, get out of the way” OSs. Today’s Windows is described as a marketing platform rather than a neutral toolbox.

Debloating and power-user workarounds

• Power users report spending hours or days stripping Windows 10/11 via PowerShell, group policy, registry edits, and third‑party scripts (Win11Debloat, WinUtil, O&O tools).
• A few say once debloated, Win11 works well and stays out of the way, but note that settings can be reverted by updates and some components cannot be removed.
• LTSC and Tiny11 are praised as “real Windows again,” but seen as hard or improper to use for home users.

Alternatives: Linux, macOS, BSD

• Some have fully switched to Linux (often Mint, Ubuntu/Kubuntu, Debian, Arch), citing lack of telemetry, no ads, stable environments, and good enough gaming via Steam/Proton.
• Others push back: Linux desktop still has UX friction (sudo for common tasks, multi-user assumptions, config-file fragility, driver quirks, gaming edge cases). Distro fragmentation and inconsistent UX are recurring complaints.
• macOS is praised for hardware and cohesive design, but criticized for its own nags (iCloud, TV, services) and service upsells.
• A few look at BSD as a more reliable alternative; others argue for a hardware‑vendor Linux consortium, but note enterprise Windows integration as a huge barrier.

C# and the “Microsoft bloat” mindset

• A side thread argues Microsoft’s “add features forever” philosophy appears in C# too.
• Some decry added language features as mis‑prioritized versus long‑requested sum types; others say most additions are useful and that “bloat” just means “things I don’t use.”
• Various clumsy patterns for emulating sum types in C# are discussed and found unsatisfying.

Incentives, enshittification, and feature wishes

• Several link Windows’ trajectory to shareholder‑driven incentives and adtech; others contest the strict legal framing but agree incentives favor rent‑seeking over user experience.
• Desired OS improvements include: simpler audio device switching (partly solved in Win11), fully remappable shortcuts, movable taskbar, saner right‑click menus, multi‑monitor pinning, and fewer “dark pattern” dialogs.

Overall reception of the list

• Many see it as a useful grab-bag of gotchas and reminders, especially for people who already “almost know” these topics.
• Several argue it reads more like a personal notebook or stream-of-consciousness than a carefully vetted reference; some items are context-dependent or outright wrong.
• It’s considered better as a prompt to ask better questions than as a teaching resource for true beginners.

Manuals, tutorials, and learning

• Discussion distinguishes manuals (for people who know what they’re looking for) from tutorials/guides (for people learning from scratch).
• Unix-style manuals are praised as memory aids, not teaching tools.
• Some recall the early frustration of trying to learn Linux commands from man pages, then later relying on them constantly once experienced.

Regex and locale pitfalls

• Regex semantics differ by engine: e.g., a{,3} behaves differently in Python vs JavaScript.
• [a-z] is a recurring trap:
  • In some locales, it may not match all ASCII letters because collation order differs.
  • It also misses non-ASCII letters; \p{L} is suggested where supported.
  • [A-z] unintentionally includes extra ASCII symbols.
• Tools like regex101 and learning theoretical underpinnings are recommended.

CSS confusion and inconsistencies

• CSS is compared to C++: huge, evolving, and safer if you enforce a subset.
• Debate on enforcing a fixed set of CSS properties; example given of inconsistent use of margin vs gap.
• A concrete correction: min-width: auto only implies content-based min width in flex/grid; elsewhere it resolves to 0.
• Several people admit layout rules feel opaque; resources like Every Layout / CubeCSS are praised for making CSS coherent, but others say layout remains a “bazaar” of accumulated ideas.

Language semantics and documentation issues

• C# volatile semantics spark a detailed back-and-forth: docs and spec appear internally inconsistent; some read them as acquire–release, others highlight contradictory wording.
• Claims about Java, C#, JS, and Go string encodings are corrected:
  • Java’s string representation is now an implementation detail.
  • C# strings are fixed as UTF-16 char sequences and exposed as spans/pointers.
  • Go strings are just byte sequences, not inherently UTF-8.
• JS integer “max accuracy” is clarified as the “max safe integer” concept.

Null, Optional, and nested absence

• Returning null from methods that return Optional<T> is widely condemned.
• There’s skepticism about having Optional in a language that already has null, but others defend it as enabling clearer composition and nested optionals.
• Several concrete use cases for Optional<Optional<T>> are given (e.g., caches and REST/JSON where “not present”, “present but null”, and “present with value” are distinct).
• Comparisons are drawn to Python and Scala, noting how they handle nullable types and optionals more ergonomically.

Shell, files, and networking traps

• rm -rf $DIR/ with an unset DIR is highlighted as extremely dangerous; alternatives:
  • Omit the trailing slash so an empty $DIR yields no operands.
  • Use ${DIR:?message} to force an error if the variable is unset.
• TCP keepalive vs HTTP keep-alive is corrected:
  • Middleboxes (firewalls/NAT/conntrack) drop idle connections, not routers.
  • HTTP Keep-Alive controls HTTP-level reuse; only TCP keepalive sends packets to keep connections alive.
  • Mobile platforms may disable TCP keepalive even when app-level keepalives work.

Unicode, encoding, and text formats

• Han unification is contentious:
  • One side says it’s analogous to sharing an “A” between languages with different fonts and not a trap in itself.
  • Others argue the glyph differences are culturally significant; substituting the “wrong” variant can alienate users.
• Negative zero and its behavior in floating-point are elaborated (e.g., division yielding -∞ vs +∞).
• UTF-8 BOM is described as mostly legacy from UTF-16/32 endianness handling and rarely relevant today.
• YAML’s quirks (e.g., the “Norway problem”, disallowing tab indentation) and Bash’s errexit inconsistencies are referenced as classic traps.
• Line-ending issues (LF vs CRLF) remain painful on Windows; Git settings and .gitattributes are important for scripts.

Meta: what counts as a “trap”?

• Some items (e.g., vague “NumPy vs PyTorch differences”) are criticized as unhelpful without specifics.
• Others argue the biggest trap is building software no one (including the developer) really wants, though there’s pushback noting the value of scratching one’s own itch and exploring small, non-scaling ideas.

Overall reaction to VW’s horsepower subscription

• Many see this as blatant rent-seeking and “enshittification”: you buy the hardware, then must keep paying to use its full capability.
• Several say it puts VW on their personal “do not buy” list and reinforces existing distrust (e.g., after the emissions scandal).
• Others view it as annoying but not catastrophic: another form of trim-level differentiation, just implemented via software and pricing psychology.

EVs, software locks, and right to repair

• Debate on whether this is an “EV scam” or just general manufacturer greed: commenters note it’s technically just as feasible on ICE cars.
• EVs are seen as easier to lock down (everything is already software-controlled), making aftermarket modification and repair harder.
• Right-to-repair advocates argue this trend extends DMCA-style control to more car systems (wipers, batteries, etc.), not just power.

Economics, capitalism, and pricing logic

• Defenders argue: one hardware SKU is cheaper to build; software-limited variants let price-segment the market and maybe lower base prices.
• Critics respond that consumers end up paying for overbuilt hardware they can’t fully use, often also incurring higher insurance/taxes based on max-registered power.
• Broader macro discussion: “broken” supply–demand due to non-rational, poorly informed consumers, and markets that reward bad products that still sell.

Subscriptions vs one-time unlocks and leasing

• Many distinguish between:
  • One-time software unlocks (somewhat tolerated, especially for substantial features), and
  • Ongoing subscriptions for latent hardware (widely disliked).
• Some compare it to leasing a car; others note key differences: leases and loans end, while subscriptions can be repriced and conditions unilaterally changed.
• “Lifetime subscription” language is distrusted; people worry it’ll hinge on vague “lifetime of the car” or support windows.

Technical and regulatory angles

• Commenters note engine/EV power is already heavily ECU-controlled; many manufacturers share hardware across trims and detune via software.
• Some argue de-rating improves reliability and battery/engine longevity; others say the main driver is price discrimination, not engineering.
• Concerns that software locks complicate compliance with emissions, safety rules, and might create weird interactions with insurance and vehicle taxation.

Hacking, security, and consumer coping strategies

• Expectation of a growing “jailbreak your car” scene to bypass locks, with counter-worries about bricking, warranty loss, and remote disablement.
• Some plan to stick with older, simpler, or second-hand cars; others hope for “retro-simple” EVs without connectivity, telemetry, or subscriptions.

Responsibility for the treaty’s failure

• Many argue the outcome was predictable once oil-producing states had de facto veto power; they unsurprisingly blocked binding production cuts, phaseouts and disclosure.
• Others say the EU and rich countries weren’t serious: if they really wanted a deal, they could form their own treaty bloc and back it with tariffs and trade restrictions.
• Some frame it as systemic failure by the UN: “repulsive” maximalist drafts, consensus rules, and scheduling observers last are seen as bad process and poor negotiation.

Geopolitics and hypocrisy

• Discussion contrasts China criticizing Gulf producers while being the largest plastics products exporter; note that it mostly buys feedstock from petro-states (e.g. SABIC).
• Several comments accuse the West/EU of virtue signaling while still importing Russian gas, expanding petrochemicals, and offloading plastics production and waste abroad.
• Some see the whole exercise as scapegoating oil states instead of fixing domestic demand and waste.

Plastics: benefits vs harms

• One camp stresses plastics’ huge benefits: light, cheap, sterile, enabling modern medicine and cutting transport emissions versus heavier materials.
• Others emphasize systemic harms: microplastics, toxic additives, greenhouse gas emissions, siting of cracker plants in poor/communities of color, and plastics as a growth pillar for fossil fuels.

Waste management vs production cuts

• A major thread claims plastics aren’t a problem if properly binned, landfilled, recycled, or burned; the real issue is littering and failed waste systems in a handful of river basins and shipping.
• Counterarguments: global recycling is low, true recycling vs downcycling is muddled, incineration still burns fossil carbon and harms nearby communities, and even perfect disposal doesn’t address upstream impacts.

Global waste, blame, and responsibility

• Debate over rich countries exporting plastic waste to poorer nations:
  • One side: exports are meant for processing/landfill; river dumping is the importer’s failure.
  • The other: exporters “turn a blind eye,” knowing much will be mismanaged, so responsibility remains shared.

Treaties and bad faith

• Some say consensus-based treaties are mostly virtue signaling and easily ignored by powerful states.
• Others defend treaties with examples (ozone, tobacco, high seas) and argue “imperfect” isn’t “useless.”
• Disagreement over whether oil states are negotiating in “bad faith” or simply pursuing clear self-interest.

Consumers and alternatives

• Multiple comments note how hard it is to avoid plastic in everyday products (e.g., dental floss, toothpaste, coffee makers).
• Niche attempts (metal containers, tooth tablets, wooden or animal-hair brushes) exist but face cost, durability, and usability tradeoffs.

Logging, Metrics, and Observability

• Strong agreement that pervasive logging of major business decisions and basic metrics pays off during incidents.
• Recommended pattern: log aggressively, but use aggressive filtering and short retention to control cost and noise.
• Observability value comes less from “having logs” and more from being able to filter, search, and correlate them.

State, Microservices, and Org Design

• Biggest pain is synchronizing multiple stateful systems, especially with bidirectional flows; a single source of truth is preferred.
• Monotonic or owned state (one clear owner, others as readers) is seen as safer than widely mutable shared state.
• Criticism of microservices used to mirror org charts rather than business/technical needs; this can “codify organizational inefficiency” and add needless network latency.
• Some argue architecture should follow business and processes, not team boundaries; others warn that doing architecture before processes emerge leads to overengineering.

Database Design: Booleans, Timestamps, Audits, and Soft Deletes

• Debate over the “never store booleans” meme. Many see timestamps/enums/integers as more future-proof for flags and status; others say booleans are fine when they truly model a binary outcome.
• Soft deletes are viewed by some as lazy substitutes for real auditing and often a source of complexity; others find them practical for recovery and “what changed when” analysis.
• Audit tables: disagreement whether they’re “dumb extra sources of truth” or simply immutable change logs alongside the primary tables. Consensus that you must be clear which layer is authoritative.

Joins, ORMs, and Where Logic Lives

• Default advice “let the DB do joins” is widely supported, but several describe real cases where app-side joins or denormalized JSON blobs were faster and simpler.
• ORMs are polarizing: they reduce CRUD boilerplate but can hide performance issues (N+1, oversized joins). Many advocate a mixed approach: ORM for simple stuff, raw SQL or views for complex queries.
• Views are broadly liked as stable, check-in-able abstractions; stored procedures are seen as powerful but often harmful to maintainability, tooling, versioning, and team understanding.

Schema Flexibility vs EAV/JSON

• Strong dislike for generic EAV (“keys/values”) and polymorphic “classifier” tables that obscure meaning and push complexity into application code.
• Preference for many explicit, human-readable tables and conventional relations; JSON/JSONB is accepted for genuinely open-ended or hard-to-schema data, but not as the default.

Caching, Replication, Queues, CQRS, Event Sourcing

• Using read replicas is endorsed, with recognition that replication lag must be handled (timestamps, “fill in in-memory,” or routing some reads to primary). Some find these workarounds fragile.
• Queues: many defend managed queues as simple and robust; skepticism toward rolling your own queue or misusing DB tables and cron where a queue fits naturally.
• CQRS gets mild shade in the article, but some note the recommended pattern of “one writer service, others read/emit events” is essentially CQRS-like.
• Event sourcing is praised by a few as conceptually solving many problems (events, auditing, distribution) but acknowledged as heavy and rarely justified for small projects.

Simplicity, Overengineering, and Interviews

• Strong cultural theme: good design is “boring,” underwhelming, and optimized for maintainability and safe change, not for intellectual impressiveness.
• Many lament that promotions, resumes, and system design interviews often reward complexity, leading to “LinkedIn-driven” or “resume-driven” architectures (microservices, K8s, exotic datastores) where a monolith + Postgres would suffice.
• Several commenters describe answering interview system-design questions with pragmatic simplicity and being penalized because interviewers wanted elaborate distributed designs.

Limits of Generic Advice and Context Dependence

• Some criticize the article for offering rules-of-thumb without clearly stating its context (traffic levels, team size, constraints), arguing that “good design” is only meaningful relative to requirements.
• Others defend it as a practical, mid-level catalogue of tradeoffs that sits between theory-heavy books and oversimplified “use Cassandra for a billion users” checklists.
• Broader systems thinking (humans, org design, socio-technical feedback loops) is noted as largely missing from the article and many “system design” discussions.

Trust in the New Domain

• Many readers initially found putty.software suspicious, especially in light of recent supply-chain incidents in other projects.
• Trust is largely anchored in the original chiark.greenend.org.uk site explicitly announcing the new domain.
• Some argue that if an attacker can alter the original site to add such an announcement, the project is already compromised, so this level of verification is about as good as it gets.

Mastodon and Identity Verification

• The author’s Mastodon post is used as additional confirmation, with discussion of the Fediverse rel="me" cross-linking mechanism.
• One side: rel="me" plus a verified link from the original homepage “proves” that the same entity controls both accounts/sites and is sufficiently strong for this context.
• Other side: it only proves that a link exists; if the site is hacked, it’s indistinguishable from a malicious edit and is too weak for software-supply-chain trust.

putty.org Controversy as Context

• Broad agreement that the move is driven by the long-running issue with putty.org, a domain not controlled by the PuTTY project.
• Historically, putty.org promoted a competing SSH client while leveraging PuTTY’s name; now it mainly hosts anti-vaccine content while still linking to the real PuTTY site.
• Some see this as classic domain squatting potentially addressable via (registered or unregistered) trademark; others note there is no registered mark.

New TLD and Perceived Legitimacy

• Several commenters find .software and other “new” TLDs inherently spammy, preferring .com/.net/.org or even “download/getputty”-style domains (though those also feel scammy to others).
• Concerns that nuTLD pricing or policy changes could later pressure the project.
• Debate over TLS certificates: DV certs from Let’s Encrypt are now standard; some lament that they offer little identity assurance, others note EV-style identity checks were weak in practice anyway.

Design, UX, and Nostalgia

• The old chiark site is widely described as charmingly spartan/1990s; some want that aesthetic preserved.
• The new page is seen as a minimal, slightly clumsy landing page (tiny blurry screenshots, extra click) but still simple and fast.
• Some suggest clearer “future home” wording and stronger, less confusing download cues.

Is PuTTY Still Needed?

• Many Windows users now rely on built-in OpenSSH and Windows Terminal (or WSL) and rarely need PuTTY for SSH.
• Nonetheless, PuTTY remains valued for serial connections, legacy systems, SSH tunneling, and features like CLI password passing.
• There’s some light joking about its perpetual pre-1.0 versioning and about the dated default font/UI, balanced by strong nostalgia from people for whom PuTTY was their first serious SSH tool.

SGX, TEEs, and Remote Attestation

• SGX is central to the design; supporters call it “battle-tested” and describe how enclaves generate private keys, get attested by Intel, and embed that attestation into TLS certificates so clients can verify MRENCLAVE and Intel’s CA chain.
• Critics note SGX is deprecated on consumer CPUs, has had multiple serious vulnerabilities, and may have had hardware keys leaked via physical attacks. Once a CPU’s seeds are exposed, its attestations can’t be trusted again.
• Several commenters question how a client can be sure the attested enclave is the same instance handling VPN traffic, or that a malicious host isn’t proxying signatures from a legitimate enclave.

Limits of What SGX Can Prove

• Multiple people stress SGX only protects what’s inside the enclave; the host OS and network stack can still:
  • Log decrypted traffic entering/leaving the enclave.
  • Correlate timing and packet flows (10ms batching is viewed as weak obfuscation).
  • Route each user through a dedicated enclave instance, defeating “mixing.”
• Therefore, the scheme does not eliminate the need to trust the operator about traffic correlation and external logging.

Trust Model: Intel, Operators, and “No Trust Required”

• “No trust required” messaging is heavily disputed:
  • You must trust Intel’s hardware, firmware, CA infrastructure, and willingness not to collude with governments or certify compromised configs.
  • SGX attestations only guarantee “blessed by Intel,” not mathematically provable non-tampering.
• Some argue this is still defense-in-depth and strictly better than standard VPNs; others see it as ideal honeypot material for well‑resourced adversaries.

Founders, Jurisdiction, and Legal Risk

• Many commenters focus on the founders’ previous high‑profile controversies (crypto exchange collapse, Freenode drama, prior VPN sale/merger) and say they won’t trust them with privacy, regardless of code.
• Operating in the US, touting constitutional protections, is seen by some as a feature (strong consumer law), and by others as a liability (NSLs, Five Eyes, Snowden-era surveillance).

Payments, Anonymity, and Alternatives

• Critiques of signup and crypto payment flows (email, name, ZIP prompts; bugs) contrast with praise for competitors that:
  • Accept Monero or cash-by-mail.
  • Run diskless/RAM-only servers, publish audits, or keep pricing simple.
• Some prefer simpler threat models: Mullvad/IVPN/Proton, OVPN’s physical hardening, self‑hosted WireGuard/Algo, or multi-party/relay schemes over TEEs.

State of Tech Hiring and Compensation

• Hiring is highly uneven: some see active recruiting from big tech and startups, others report near-total freezes, especially at larger firms.
• Many postings are suspected “ghost jobs”; companies interview but then cancel or repurpose roles.
• Applicant glut from recent layoffs makes it harder to stand out; experienced engineers can still get offers but with more effort.
• Juniors and early-career generalists are described as “screwed”; many anecdote about accepting 2018-level pay or leaving tech.
• Several people report a clear uptick in recruiter outreach and offers around July, sometimes linked (speculatively) to recent R&D tax-code changes.

AI, Productivity, and Offshoring

• Sharp disagreement on AI’s labor impact:
  • One view: future is low-wage devs + AI, with US devs squeezed out and remote/offshore teams taking over.
  • Counterview: AI amplifies high-skill, high-wage devs; juniors plus AI produce unchecked nonsense.
• Multiple anecdotes of consulting or debugging work lost to ChatGPT; others argue this doesn’t yet show up at macro scale.
• Debate over whether AI is actually cutting jobs vs being used as a narrative cover for cost-cutting driven by other factors.

Remote Work, WFH, and Global Labor Markets

• Some argue WFH made it far easier to replace NA-based engineers with cheaper overseas workers; RTO is framed by a few as a long-term job protection for locals.
• Others counter that large-scale offshoring predates COVID and WFH; remote tooling just made existing patterns smoother.
• Concerns that US/Canadian developers overestimated their unique value relative to similarly skilled workers abroad.

Tax Policy, Politics, and Tech Layoffs

• Long dispute over the 2017 change to Section 174 (capitalizing R&D, including software), its 2022 effective date, and whether it helped trigger layoffs.
• Participants argue over which party is more to blame for allowing it to bite and who actually “fixed” it in the latest big bill; accusations of bad faith on both sides.
• Some see the recent fix as meaningfully improving US hiring; others think ZIRP’s end, VC retrenchment, and overproduction of CS grads are more important.

Unemployment, Sectors, and Data Quality

• Several note that professional/business services and construction/manufacturing/banking show larger losses than “information”, so “as tech falters” is viewed as misleading.
• Some worry about political interference in federal statistics (including firing of the labor-statistics commissioner); others point to BLS methodology to defend reliability.
• Commentary that California’s revenue dependence on high-earning tech workers amplifies the budget impact of sector slowdowns.

Thailand’s Choice and Regional Context

• Commenters link Thailand’s move to being denied F‑35s due to U.S. concerns over its democratic backsliding and closeness to China; if forced into 4th‑gen, Gripen is seen as a logical pick over F‑16.
• The main near-term threats discussed are Cambodia border clashes and Myanmar; against those, any modern fighter would suffice. China is viewed as overwhelming regardless of platform.
• Some note the current deal is only for four aircraft, arguing it’s symbolically important but not transformative for Thailand’s ~100‑plane force.

Perceptions of U.S. Reliability and Foreign Policy

• A dominant theme is that the U.S. has become an unreliable and politically volatile supplier: sanctions, tariffs, arms cutoffs, and potential “remote kill switch” or maintenance leverage are cited as risks.
• Ukraine’s experience after the Budapest Memorandum, as well as U.S. behavior toward Thailand, Cambodia, and others, is used to argue alliances and security guarantees are not trustworthy.
• There’s debate whether this stems from “values-based” democracy promotion vs. pure power politics and hypocrisy, but both critics and realists converge on: buyers now factor U.S. domestic instability into procurement.

Broader Shift Away from U.S. Weapons and F‑35 Issues

• Several European decisions (Spain favoring Eurofighter, Swiss unease with F‑35 costs, Danish regret) are framed as part of a longer-term decoupling from U.S. systems, accelerated by Trump-era bullying and tariffs.
• The F‑35 is described as technologically impressive but expensive, maintenance-heavy, and politically entangling; its “hangar queen” reputation and reduced U.S. orders are noted.
• Switzerland’s fixed-price F‑35 deal and later U.S. price increase are cited as an example of cost and trust friction.

Gripen and Alternative Doctrine

• Gripen is praised for lower operating costs, strong air‑to‑air performance (Meteor missile, low wing loading), and especially for dispersed operations from short road runways with minimal ground support.
• This decentralized basing model is contrasted with large, vulnerable U.S.-style airbases; Ukraine’s drone strikes on Russian airfields are used as evidence that dispersal is increasingly valuable.
• Some highlight that many fighters can technically use roads, but Gripen and Swedish doctrine are built around fast, mobile, hard‑to-target operations.

Framing and Marketing

• Many see the feature as reframing censorship or content-policy refusals as “Claude chose to stop,” shifting blame from Anthropic’s rules to the model’s supposed agency.
• Several comments call this blatant anthropomorphizing and “cult-like” PR designed to make LLMs seem more intelligent, powerful, or morally weighty than they are, helping justify restrictions and hype.
• Others argue it’s mainly optics: the same behavior could be presented as “conversation blocked for policy reasons,” so talking about “model preferences” is spin.

Model Welfare and Consciousness

• Strong skepticism that current LLMs have any consciousness or feelings; many stress they are “just matrix multiplications” or “fancy autocomplete.”
• Some worry that if Anthropic talks about “distress” and “moral status” while still using the system as a tool, it implies a kind of accepted slavery if consciousness ever did emerge.
• A minority defend taking welfare seriously now as low‑cost precaution and philosophical groundwork, given uncertainty about future AI capabilities and lack of clear tests for consciousness.
• Long subthreads debate whether machine consciousness is even plausible, what consciousness is, whether emergent behavior counts, and how (or if) moral standing should apply to non‑biological systems.

Safety, Alignment, and Censorship

• Supporters see this as alignment and risk reduction: repeated, abusive attempts to extract harmful content (e.g., CSAM, terrorism, self‑harm, extreme abuse) can now be hard‑stopped, limiting jailbreaks and screenshots of “model says X.”
• Critics fear “think of the children” justifications will gradually expand into political or ideological control, with AI safety people becoming “digital hall monitors.”
• Some explicitly connect this to broader trends: online safety laws, age verification, encryption backdoors, and platform moderation used for consent manufacturing and state or corporate power.
• Others answer that all major hosted models already moderate; this is just another layer and doesn’t stop people from running uncensored local or open‑weights models.

User Experience and Technical Aspects

• Many question practical impact since users can edit an earlier message or branch the chat; some suspect that escape hatch might be removed later.
• Ending a conversation truncates how much “wearing down” can occur in a single context window; defenders frame this as defense‑in‑depth against persistent red‑teaming.
• UX complaints: users often don’t understand branching; false positives already happen (chemistry, “gene therapy,” harmless game code, recipe ingredients), and people fear losing long contexts “on a whim.”
• Several note other products already end chats or severely reset behavior when conversations go “weird,” so this is not unique—just more explicitly tied to “model welfare.”

Broader Ethical and Societal Concerns

• Some see energy spent on AI welfare as misplaced compared to human or animal welfare, especially alongside expectations of mass job displacement.
• Others argue norms around how people talk to AI matter because they can shape how people treat humans (e.g., practicing abuse on chatbots).
• A few interpret this as a preview of future debates: if models ever were plausibly conscious, issues of rights, slavery, and consent in AI work would become unavoidable.

Enthusiasm for native large-file support

• Many welcome large-file handling moving into core Git rather than external tools.
• Separate “large object remotes” and partial clones are seen as enabling broader use cases, including asset-heavy projects.

How Git already handles binaries

• Several comments stress that all Git objects are binary and packfiles already use binary deltas.
• The real pain is with files where small logical changes rewrite the whole binary (compressed, encrypted, some archives), inflating history.
• Another pain point: once a big file is committed, it lives forever in history unless you rewrite it.

Critique of Git LFS

• Criticisms: awkward opt‑in (extra install, hooks, .gitattributes), confusing pointer files, poor server UX, multiple auth prompts, and bad offline/sneakernet behavior.
• Migration tooling can rewrite history in surprising ways (e.g., .gitattributes “pollution” in older commits).
• Some argue “vendor lock‑in” is mostly about GitHub’s pricing and behavior, not the open LFS protocol itself; others say practically it does lock you in once used.

Partial clones & large object promisors

• --filter and promisors are seen as addressing history bloat by not downloading unused large blobs.
• Clarification: even with filters, the checked‑out working tree should be complete; only historical versions are lazily fetched.
• Skeptics worry about:
  • New flags on git clone that beginners won’t know.
  • Broken behavior if promisor storage is lost/migrated.
  • Server support being uneven; many forges don’t support partial clones yet.
• Debate over whether these should become safe defaults vs niche power‑user options.

Should Git manage large/binary assets?

• One camp: Git is a general SCM for whole projects; splitting code and assets (e.g., separate artifact store, submodules) is harmful to reproducibility and release tracking.
• Other camp: Git is fundamentally for text source; large binaries belong in Perforce/SVN/artifact stores; forcing Git into that role is a “square peg in a round hole”.
• Game and media developers report Git/LFS struggling at hundreds of GB–TB scales; Perforce or Plastic often fare better, despite weaker surrounding tooling.

Alternatives and ecosystem tools

• Mentioned tools: git‑annex, datalad, DVC, dud, Oxen, Xet, datamon, jj (future roadmap), DVC‑style indirection layers, artifact repos (Artifactory), and S3‑backed setups.
• git‑annex praised for private, multi‑remote, N‑copies workflows but considered too complex and not well suited for public multi‑user projects.
• DVC appreciated for decoupling data storage from Git history; complaints include hashing overhead and unlimited revision accumulation unless pruned.
• Several projects pitch themselves as “Git‑like but large‑file‑first”, often with chunking, dedupe, or custom backends.

Ideas for better large-file storage

• Proposals include:
  • Content‑defined chunking and dedup (borg/restic style) inside Git or a new SCM.
  • Prolly trees or similar structures for huge mutable blobs with efficient partial updates.
  • Format‑aware diff/merge (e.g., for Office docs, archives, JSON, scenes) or reversible text‑like representations.
• Some argue Git should instead focus on fixing shallow/partial clones and pruning policies so any repo can be an efficient mirror, without pointer schemes.

DX, defaults, and scale

• Repeated complaints that Git “fixes” issues by adding flags, not changing defaults; beginners are left exposed to poor UX (slow clones, obscure options).
• Others counter that Git’s decentralized model and local full history are core strengths and worth preserving, especially for offline and OSS workflows.
• Thread ends without consensus: many see the new features as a big step forward; others think a fundamentally new SCM may be needed for petabyte‑scale, asset‑heavy projects.

OpenBSD vs Linux Performance (General)

• Several comments argue Linux is usually significantly faster than OpenBSD (e.g. “3x faster”), attributing this to OpenBSD prioritizing security and simplicity over aggressive optimization.
• Others push back that “it depends” heavily on workload: Linux may be faster for many general workloads, but BSDs can excel in specific areas (e.g. some networking paths, historical RNG performance).
• One view is that OpenBSD is “lightweight/compact” but not “fast,” and not ideal for databases or fileservers; others disagree and note recent performance improvements and better SMP unlocking.

The Actual Benchmark: FD Table Growth and RCU

• The discussed benchmark stresses file descriptor (FD) allocation with two threads rapidly creating sockets.
• On Linux, the per-process FD table starts at 256 entries. When it needs to grow (256→512→1024), expand_fdtable() may call synchronize_rcu() if multiple threads share the file table.
• synchronize_rcu() waits for a full RCU grace period, introducing multi‑millisecond stalls and making FD allocation look very slow.
• A workaround in the test (dup2(0, 666)) pre-expands the table in single‑threaded context (refcount = 1), avoiding RCU and eliminating the slowdown.
• OpenBSD uses a simpler rwlock around FD table modification and no RCU here, so it doesn’t hit this pathological latency for this synthetic test. FreeBSD similarly doesn’t use RCU for this path.

Random Number Generation and Security Tradeoffs

• Some recall that historically OpenBSD’s /dev/urandom was dramatically faster than Linux’s blocking RNG behavior, especially before Linux moved to modern CSPRNGs (ChaCha20, etc.).
• Others note that /dev/random vs /dev/urandom semantics and security–speed tradeoffs matter, and that today both Linux and BSDs use CSPRNGs with continuous reseeding.

Benchmarking Techniques and Timing Sources

• There is debate over using different hardware and microbenchmarks; some call this “play” rather than serious benchmarking.
• Discussion covers timing tools: __rdtsc() vs gettimeofday/clock_gettime via vDSO, issues with TSC synchronization, frequency scaling, and when cycle vs wall‑clock measurements are appropriate.

OpenBSD Design Choices and Security Posture

• Comments mention OpenBSD’s kernel relinking at every boot (KARL) and relinking of core libraries/sshd for address randomization, trading boot time for attack complexity.
• Opinions differ on whether OpenBSD remains meaningfully “more secure” than Linux today or simply adopts different security strategies, constrained by smaller developer resources.

Website UX and Distractions

• A substantial subthread criticizes the page’s “asteroid/cannon” cursor game: moving bullets obscure text and hide the cursor, making the article unreadable for some and raising accessibility concerns.
• Others defend such playful UI as adding personality, but several readers resort to ad‑block filters, reader mode, or mirrors to read the content.

Rising Costs, Eurozone, and Quality of Life

• Several commenters note Croatia used to be a “no-brainer” value pre‑Covid and pre‑euro; now prices (especially housing) have risen faster than in much of the EU while quality of life is seen as flat.
• Others counter that similar or worse price inflation has happened in non‑euro or richer countries (Serbia, Netherlands, Germany), so the euro alone isn’t to blame.
• Debate on politics: some link cost-of-living pressure to a rightward shift; others say Croatia has long been culturally conservative and recent coverage exaggerates extremism.

Croatia vs Other Cities and Coasts

• Cost‑of‑living comparisons show cities like Split are still ~25% cheaper than Vienna, but several argue that gap is too small given Vienna’s much richer urban amenities.
• Others reply that “living standards” also include sea, islands, and climate; for people optimizing for coast and weather, Croatian cities remain competitive with Italy/Spain/Greece.
• Some say coastal Spain now offers better overall value for similar prices.

Tax Regime, Visa Rules, and FIRE Angle

• Key draw: Croatia’s digital nomad residence permit exempts foreign-earned income from local income tax; nomads are likened to semi‑permanent tourists bringing hard currency and paying consumption taxes.
• Croatia’s capital gains tax is 12% and waived after two years of holding; this, and similar regimes in nearby countries, is highlighted as attractive for FIRE/retirement.

Digital Nomads: Trend, Taxation, and Legitimacy

• One camp sees digital nomadism as a growing long‑term trend, accelerated by AI‑enabled solo businesses and many new DN visas worldwide.
• Another camp views it as transitional: governments will tighten visa and tax rules, and AI will help tax authorities detect undeclared remote work.
• Big debate over fairness: critics say nomads drive up rents, use infrastructure, and often avoid income tax; supporters stress they don’t consume local education/pensions, still pay indirect taxes, and can help smooth seasonal tourism.

Housing, Tourism, and Scale of Impact

• Some argue Croatia’s nomad numbers (~1,000 visas/year) are too small to matter nationally, especially amid population decline.
• Others respond that impact must be measured at city/neighborhood level: extra high‑paying renters in tourist hotspots can raise rents and real‑estate prices even if national numbers are low.

Remote Work Realities and Regulation

• Multiple comments note that post‑Covid many employers now require some on‑site presence; true “work from anywhere” jobs are rarer and often structured as contracting, not employment.
• German and broader EU rules are discussed: strict employment law, “fake contractor” enforcement, and bureaucracy make cross‑border hiring or contractor setups complex, limiting practical digital‑nomad options.

Croatia vs Poland and Eastern Europe

• A visitor from Poland finds Croatian prices roughly double Polish levels despite similar GDP per capita and worse visible infrastructure; others attribute this to Croatia’s strong tourism demand and coastal premium, unlike Poland.

Product concept & target users

• Web-based control plane that provisions full Kubernetes clusters into a user’s own Hetzner account; users pay Hetzner directly for resources.
• Focus is on simplicity and a GUI, plus one-click deployment of common add‑ons (ingress, Prometheus, Elasticsearch, databases, WordPress, etc.).
• Intended for developers/small companies who want Kubernetes benefits on Hetzner without deep ops expertise.

Comparison to existing tools & services

• Users compare it to kops, Talos, kube‑hetzner, hetzner‑k3s, and Terraform modules; those are seen as more DIY, lower-level, and sometimes complex.
• Edka’s differentiators mentioned: dashboard UX, pre-packaged apps, and potential commercial support.
• Several comments highlight Syself and other managed offerings on Hetzner that already provide production-ready, supported clusters (often without a UI).

Pricing and “free plan” debate

• Criticism that “€0 free plan” is misleading because control plane nodes still cost money from Hetzner; HA realistically needs 3 nodes.
• A point that Terraform-based setups can provide similar functionality without Edka’s subscription fee.

Security, secrets, and trust

• Security is described as shared responsibility: platform sec handled by Edka; cluster hardening left to the user. Internal pentests and best practices are mentioned, but product is still beta.
• AWS KMS is used to encrypt data stored in Vault, raising concern that this reintroduces AWS dependency in a “Hetzner” product.
• Multiple commenters question missing legal/imprint info and company registration; the creator responds with Spanish VAT and updates policies. Trust is a recurring theme.

Storage, encryption, and durability

• For PostgreSQL, Edka uses Hetzner’s CSI driver with persistent volumes. Some are unsure how trustworthy Hetzner’s storage is and expected something like Rook/Ceph.
• Discussion of encrypted disks: LUKS-based setups, Terraform modules enabling encryption by default, and Kubernetes storage solutions (OpenEBS, LocalZFS) with encryption support.

Bare metal vs cloud, scaling & automation

• Several users prefer Hetzner bare metal for performance and reliability; Edka currently targets cloud instances only.
• Desire for tooling that mixes bare metal and cloud nodes and supports autoscaling; Cluster API and CAPH are suggested for such use cases.
• Questions about programmatic scaling (autoscaling pods/nodes) arise; details remain unclear beyond “you control resources.”

Reliability, maturity & Hetzner’s own plans

• Some report Hetzner cloud provisioning flakiness (stuck deployments, recent issues with deletions and websockets), while others have multi‑year 100% uptime clusters.
• Edka’s HN launch surfaces real-world issues (rate limiting, cluster creation failures during a Hetzner incident), underscoring its beta status.
• Multiple people note Hetzner is rumored to be working on its own managed Kubernetes, but timing is unknown; opinions vary on whether they’ll deliver a good product.

Role and Limits of Anubis / PoW

• Commenters stress Anubis was never a “bot detector” so much as a rate/cost limiter for abusive traffic, especially from rotating residential IPs that defeat IP-based throttling.
• It works by requiring a SHA-256 proof-of-work once per client/session and issuing a JWT; scrapers can then amortize the cost over many requests, so large crawlers are only mildly inconvenienced.
• Several note that if a normal browser can run the JS, a headless browser can too. The move from curl/Go clients to full Chromium was seen as inevitable.
• Some argue PoW is “security theater”: the cost per page is orders of magnitude too low relative to AI companies’ compute, especially given optimization and batching.

Economics and Alternatives (402, Micropayments, “Useful Work”)

• Many propose “402 Payment Required”–style schemes or Cloudflare-like pay-per-crawl/x402, to directly charge AI crawlers and shift costs back onto them; concerns include fees, taxes, exclusion of low-income users, and stronger DRM/copyright incentives.
• Ideas include memory-hard PoW (Argon2, scrypt), per-resource hashes, and tying challenges to limited request quotas, but there’s skepticism that any tuning can meaningfully burden data centers without punishing users.
• Some suggest embedding “useful work” (cryptomining, protein folding) in PoW; others strongly oppose normalizing web cryptominers and note that making work simultaneously useful, verifiable, and low-latency is unsolved.

Impact of AI Crawlers on the Open Web

• Several operators of forges and personal sites report massive, robots.txt-ignoring scraping that hammers expensive endpoints (e.g., git blame, logs) and drives up bandwidth/CDN bills or causes slowdowns/DoS.
• Others say they see little such traffic and suspect this is mainly a problem for highly visible or code-heavy sites.
• There is worry about non-commercial sites disappearing or retreating into private/overlay networks, geoblocking, or paywalls, contributing to web “balkanization.”

Legal, Ethical, and Normative Arguments

• One camp: public web content is fair game for crawling unless it causes clear harm (e.g., takes sites down); mandatory robots.txt compliance or anti-crawling laws risk DRM-like regimes.
• The other camp: ignoring robots.txt and overwhelming small hosts is abusive, and there should be legal penalties (e.g., treating circumvention of systems like Anubis as bypassing “digital locks” under DMCA-style statutes).
• Debate hinges on whether publishing for humans implies consent to large-scale machine reuse and on the difficulty of cross-border enforcement.

Critiques of Anubis and Broader Arms Race

• Criticisms: Anubis harms UX (JS dependence, delays), breaks archiving and indexing unless carefully configured, and doesn’t truly stop determined AI crawlers—only the “dumbest” bots.
• Supporters counter that even partial filtering and raising marginal costs is valuable for donation-funded services that just want to avoid being overrun.
• Some prefer alternative tactics: serving LLM-generated junk or honeypot link mazes to waste crawler resources or poison training data; others experiment with IPv6-only sites, with mixed reports on effectiveness.

User attitudes toward Steam and competitors

• Many commenters say they “love” Steam or at least see it as the “least bad” option, often preferring it even at higher prices and refusing to use rival launchers except when forced.
• Steam is praised for features beyond a store: cloud saves, Workshop mods, Steam Deck support, offline-friendliness, and a generous, low-friction refund policy.
• Rival platforms (Epic, Origin, Uplay, Battle.net) are widely criticized as clunky, intrusive, or “scummy,” with special dislike for dark patterns, extra launchers, and weak Linux support.
• GOG is liked for being DRM‑free, but its catalog, tooling, and Linux integration are seen as weaker; some still prioritize GOG when possible.

Monopoly, ownership, and Valve’s future

• Several note Steam’s near‑monopoly and “cult” around its founder; they worry what happens when leadership changes or if private equity gets involved.
• Others argue Valve has earned goodwill by not aggressively abusing its position, likening it to Costco: very profitable yet broadly liked.
• There’s unease about not truly “owning” games and the broader shift from physical media to locked ecosystems.

Linux support and DRM

• Valve’s investment in Proton and the Steam Deck is seen as transformative for Linux gaming; many Linux users consciously reward Steam with loyalty.
• Some argue Proton’s Windows-compatibility undermines native Linux ports; others counter that a stable Proton runtime is superior to fragile, unmaintained native ports.
• DRM and third‑party launchers on Steam are disliked; users want better ways to filter those out.

Payment processors, censorship, and alternatives

• Many see Visa/Mastercard/PayPal as the real censors, using brand protection, chargeback risk, and delegated legal enforcement to pressure Steam.
• Debate splits between those framing this as ethics/morality (pornography, underage access) vs. those insisting it’s purely risk and business.
• Some describe all electronic payments as inherently involving credit and multi‑party risk; others push back and call for more cash‑like rails.
• There is strong support for treating payment systems as public infrastructure with clear rules, breaking card duopolies, and expanding alternatives like SEPA, iDeal, and future EU‑wide systems.

Crypto, wallets, and workarounds

• Suggestions include crypto payments or prepaid wallets to “shield” content from card censorship.
• Others note Steam previously tried Bitcoin and dropped it over fees/finality issues; crypto also brings AML and money‑laundering liabilities and can just move the chokepoint to fiat off‑ramps.
• General skepticism that crypto meaningfully solves a fundamentally political/regulatory problem.

Content boundaries and slippery slope

• The delisted titles are described as rape/incest porn games; some say they never belonged on Steam, others point to hypocrisy given tolerated murder/violence in mainstream games.
• Several worry about the precedent: once payment networks enforce subjective lines on legal content, future boundaries may broaden.
• Comparisons are made to books and films with similar themes; some question why interactive porn is singled out.

Regulatory and ecosystem consequences

• Some argue only platform owners, users, or democratically accountable governments should decide legal content limits—not payment intermediaries.
• Others accept that corporations will avoid controversy and legal exposure, even if that effectively outsources censorship.
• A few note piracy gains relative appeal: no age checks, no payment blocks.
• Underneath is a recurring theme: concentration of power—both in Steam and in payment networks—creates brittle choke points for speech and commerce.

Supply, Prices, and Perception

• Many commenters argue basic supply–demand still applies: more units → lower or slower-growing prices, especially once vacancy rises materially.
• Others counter that people reasonably don’t see this locally: they observe constant building plus rising prices and conclude development “doesn’t work.”
• Several note that in hot metros, new supply mostly slows price increases rather than causing visible nominal drops, which feels like “no benefit” to voters already squeezed.

Investors, Corporations, and Speculation

• One camp says “big financial companies buying everything” is a myth: corporate/PE ownership is a small slice nationally; most landlords are individuals or small investors.
• The opposing camp stresses local effects: in some regions, investor purchases reportedly hit ~20–25% of sales, starter homes get snapped up, and algorithmic rent-setting (e.g., RealPage) feels like cartel behavior.
• Disagreement over whether converting owned homes to rentals is problematic: one side says rentals are still shelter; the other says this sustains high prices and shifts power to rent-seekers.

Zoning, Regulation, and NIMBY Dynamics

• Broad agreement that red tape, minimum lot sizes, and single‑family zoning push costs up and bias the system toward large, well-capitalized builders.
• Homeowners and local politics are seen as central obstacles: residents block density to protect property values, traffic, neighborhood “character,” and to (selectively) limit in‑migration.
• Some emphasize voter “folk economics”: blaming developers/landlords rather than land-use rules, and associating development with higher prices.

“Luxury” Construction and Filtering

• A recurring misunderstanding: people see only high-end new units and ask why we aren’t building “cheap” homes.
• Pro‑supply commenters invoke “filtering”: rich households move into new expensive units, freeing cheaper older stock down the ladder.
• Skeptics respond that this chain is broken by investors holding old units as rentals/second homes and by large houses replacing low‑rent rooming houses or small multiplexes.

Vacancy, Demand, and Market Structure

• Some claim lots of dark units and call for vacancy taxes or forced divestiture; others cite low reported vacancy and argue “empty homes crisis” is overstated and often based on bad anecdotal methods (e.g., counting lights at night).
• Demand is described as highly inelastic (everyone needs shelter) but elastic in space: more sq ft per person, conversion of duplexes to single‑family, and induced demand in attractive cities can absorb new supply for a long time.

Finance, Wealth, and Policy Disputes

• Commenters highlight cheap credit, investor leverage, and tax treatment (capital gains, 1031‑like behavior, homeowner subsidies) as major drivers of prices.
• Some want strong regulation: limits on investor ownership, rent control, vacancy taxes, or even recognizing housing as a human right with legal teeth.
• Others argue the priority should be massive upzoning and public or incentivized high‑density building, plus targeted support for the bottom 10–20% whom markets won’t house affordably on their own.

AI, LLMs & Occult Humor

• Many comments spin the digitized collection into sci‑fi/horror premises: AI trained on grimoires summoning or banishing demons, “GPT-666,” AI necromancy of historical occultists, or AI vs. demons as a war scenario.
• Occult–AI analogies are popular: programming as alchemy, prompt engineering as demon evocation, and SEO / black-box ranking systems as “occult” information practices.
• Several people link this to existing fiction (Lovecraft, Laundry Files, Evil Dead, Buffy, Anathem) and joke that current AIs are already trained on these texts.

Scholarly & Historical Interest in the Occult

• Some highlight serious academic resources (YouTube lectures, podcasts, historians) and argue that occult literature is key to understanding early science, hermeticism, and the Renaissance.
• Occult philosophy is framed by some as “early natural philosophy” and a humanist core of European thought, closely tied to Neo-Latin scholarship and largely untranslated corpora.
• Specific authors and works (Agrippa, Ficino, alchemical and Rosicrucian traditions) are recommended as starting points.

Debates on What “Occult” Means & Whether It’s Dangerous

• One view: occult is essentially pre‑modern social psychology, propaganda, or narrative technology—“spellcasting” as psychological manipulation.
• Another view: occult practice is a broad domain (theurgic vs thaumaturgic) and historically a tool of marginalized people, not mainly state control.
• A more spiritual stance insists that real black magic and demons exist and are harmful, urging caution, while skeptics invoke stage-magic debunkers and dismiss such claims as incoherent.
• There’s extended back‑and‑forth tying occult, religion, mysticism, and modern ideological “belief systems” together as structurally similar.

Occult Texts as Training Data for LLMs

• Some argue occult texts would be “useless or detrimental” for models; others say they’re valuable for intellectual diversity and understanding Renaissance thought.
• It’s noted that many such texts are already online and likely scraped; specialized “occult LLMs” and religious AIs are mentioned.
• Speculation arises about AI accidentally “conjuring demons,” with one commenter reinterpreting “demons” as self‑sustaining harmful information loops (e.g., addictions, destructive patterns).

Access, Downloads & Use Cases

• Several users are frustrated that the library’s viewer doesn’t offer straightforward bulk download; workarounds (dezoom tools, scripts, Internet Archive approaches) are shared.
• People want local copies for preservation, research, translation, and RAG/GM tools.
• Others are excited about using the scans as inspiration and props for tabletop RPGs and as a source of high‑quality historical occult artwork.

Summarization, “context,” and novelty

• Much debate centers on the article’s claim that LLMs only “shorten” text, while human summaries add outside context.
• Several commenters report LLMs giving strong summaries of truly unseen material (e.g., private scripts, documents after the training cutoff), arguing they do more than compress.
• Others counter that these texts are rarely structurally novel; models are leveraging patterns from vast prior data (“mastering canon” rather than meaning).
• Some say the article conflates two notions of “context”: training data vs. real-world semantic understanding.

Pattern-matching vs understanding and generalization

• A common view: LLMs are sophisticated regressors over huge corpora, excellent at interpolation but fragile with genuinely novel, unstructured, or out-of-distribution material.
• Critics argue humans also fail on overly novel exams or puzzles, but still generalize better given far less data.
• There’s interest in giving models richer “embodied” or simulated experience (e.g., physics/blockworld) to improve generalization.

Anthropomorphism and the “Timmy Trap”

• Many agree the core warning is valid: people instinctively anthropomorphize fluent systems, over-ascribing agency, emotion, or understanding.
• Examples include players bonding with fictional game objects, or users treating chatbots as friends, therapists, or moral agents.
• Some insist anthropomorphizing is harmless or even useful; others see it as dangerous when tools are used in high‑stakes domains (law, hiring, medicine).

What is “intelligence”?

• A long subthread disputes statements like “LLMs aren’t intelligent” without a clear definition.
• Positions range from:
  • Intelligence as results-oriented (passing Olympiad problems, planning, code synthesis).
  • Intelligence as requiring agency, long‑term adaptation in the real world, or self‑aware reasoning.
  • Intelligence as a fuzzy social construct with shifting goalposts (“duck test” concerns).
• Some note that humans themselves are mostly pattern-replayers; novelty and creativity are hard to define even for us.

Capabilities, failures, and practical impact

• Many emphasize that, regardless of labels, LLMs already outperform average humans on many text tasks (translation, coding snippets, explanation) and can automate large swaths of routine knowledge work.
• Others stress their brittleness: hallucinations, inability to distinguish fact from fiction, lack of persistent learning, and weird edge‑case failures.
• Several see the real issue not as misjudging model “intelligence,” but misusing them as if they were reliable, responsible agents rather than powerful but alien tools.