Hacker News, Distilled

What Devin Is and How It Works

• Framed less as “Copilot-style autocomplete” and more as an autonomous assistant you assign projects to.
• Runs in a cloud VM (Linux, with shell, browser, file system, and internet) and can open docs, run code, debug, and create PRs.
• Asynchronous workflow: users often kick off multiple tasks, let it work, then review output and PRs later.

Comparison to Claude / ChatGPT / Cursor / Copilot

• Some say comparison to raw models (Claude 3.5, o1) is misleading because Devin’s value is in tools + workflow, not just code generation.
• Others insist comparison is valid: if it can’t solve problems that stump Claude/o1, the high price is hard to justify.
• Several want head‑to‑head, up‑to‑date benchmarks vs Claude 3.5/3.6 and o1 Pro; current public comparisons are viewed as outdated or incomplete.

Capabilities and Use Cases

• Reported strengths:
  • Large, complex refactors and migrations touching many files, beyond simple search/replace.
  • Multi-document writing projects (proposals, legal/feasibility docs, training materials).
  • API integrations and long-tail “annoying” debugging, especially with messy or poorly documented APIs.
• Can in principle work in any language since it reads compiler errors; mixed feedback on C/C++ quality.
• Can handle very large repos, but initial scanning and knowledge building can take hours to days.

Performance, Speed, and Resource Use

• Users note it used to be quite slow; recent updates reportedly 3–4x faster, but some still want a “speed/demo” mode.
• Uses credits (ACUs); rough guidance: small frontend task ≈ 1–2 ACUs; VM burns ACUs while actively working.

Pricing and Access

• Current visible offering: $500/month team tier with included credits; lower-cost $50 personal tier exists but is closed to new signups.
• Some want pay-as-you-go or cheaper, constrained tiers to experiment; $500 just to try is seen as a barrier.
• Complaints that pricing isn’t obvious early in the signup flow.

Data, Trust, and Legal Terms

• Questions about data handling, training on user code, and third-party model providers; answers in thread are partial/unclear.
• ToS clause granting broad license to customer data is debated; some see it as standard SaaS language, others as worrisome.
• A subset of commenters distrust the company due to earlier accusations of misleading marketing and the lack of independent benchmarks or public testing.

Developer Experience and Future of Work

• Some see Devin as a “superpower” that offloads repetitive maintenance and boilerplate.
• Others worry delegating complex integration and architecture work to a black box erodes deep understanding and craftsmanship.
• Questions arise about long-term impact on junior/mid-level developer roles; outlook is mixed and largely unresolved.

Naming and Branding Reactions

• Side discussion about using common first names (“Devin”, “Alexa”) as product names; some find it inconsiderate or cheesy, others don’t care.

Role of COVID vs longer trends

• Some argue the article over-attributes score drops to COVID; they note declines and widening gaps in US data already predated the pandemic.
• Others say COVID clearly worsened things: long closures, poor remote learning (especially for low‑income students), and lingering social/emotional effects.
• A minority raise possible neurological impacts from COVID infections (brain fog, subtle IQ loss), but others blame policy choices (lockdowns, de‑policing, broader stress) instead.

Literacy, pedagogy, and curriculum

• Several commenters worry more about falling literacy than math, tying it to cueing/“balanced literacy” approaches that research suggests underperform phonics.
• There’s debate over how widespread cueing was (NYC only vs nationwide) and whether recent shifts back to phonics will help.
• Some blame faddish K‑12 reforms (e.g., SF math sequencing, California’s new framework) and “equity over achievement” policies for lowering rigor, others call that overgeneralization.

Screens, tech, and attention

• One camp blames YouTube, TikTok, games, and smartphones for eroding attention and displacing reading and deep practice.
• Others see this as another moral panic; they argue tech is neutral and outcomes depend on incentives and supervision.
• Ed‑tech in classrooms (laptops, iReady, etc.) is widely seen as having underdelivered on learning gains and sometimes distracting.

Funding, inequality, and family environment

• Some insist underfunding and overworked teachers are core causes; others counter that high‑spending systems (NYC, Chicago) still perform poorly.
• Many see socioeconomic status, housing, parental time, and attitudes toward education as stronger predictors than raw funding.
• Motivation is repeatedly highlighted: kids see high achievers saddled with debt and stagnant wages, undermining the perceived payoff of schooling.

Privatization, charters, and vouchers

• One faction blames charter expansion and vouchers for draining public schools and concentrating high‑needs students in the remaining system.
• Others say some charters are scams or ideologically driven, but note others are more rigorous than nearby publics.
• There’s unresolved dispute over how much charters actually select or push out difficult/IEP students and how large their national impact is.

International comparisons & demographics

• US averages are mid‑pack, but several note US subgroup performance: white and Asian Americans compare well to European/East Asian peers, while lower‑SES and minority groups lag.
• This sparks heated debate over race vs income vs immigration status (Simpson’s paradox, changing composition) and whether disaggregated comparisons are meaningful or racially loaded.
• Some point to countries like Poland and Lithuania improving despite COVID, suggesting policy and socioeconomic context matter greatly.

Broader worries

• Commenters fear growing gaps between top and bottom students, adult skill declines, and a culture that increasingly devalues sustained effort and critical thinking.
• A few suggest earlier specialization and tracking; others warn it would cement inequality and miss late bloomers.

Motivation and Goals

• Limbo is a from-scratch Rust reimplementation of SQLite, not a C fork, with goals of:
  • Full SQL and file-format compatibility (at least initially).
  • Memory safety, async I/O, and WASM as first‑class targets.
  • Built‑in Deterministic Simulation Testing (DST), inspired by FoundationDB/TigerBeetle.
• Some see strong motivation for a memory‑safe SQLite‑compatible engine, especially given SQLite’s closed development model and proprietary “best” test suite.
• Others argue SQLite is already exceptionally high quality and the last C project that “needs” a rewrite; many worse C codebases exist.

Performance and Language Choice

• The blog cites a microbenchmark where Limbo is ~20% faster than SQLite on a trivial SELECT; critics say:
  • Single microbenchmarks on incomplete code are not meaningful.
  • Missing features and checks often explain early wins.
• Supporters counter that:
  • Matching or approaching SQLite performance this early shows no inherent Rust penalty.
  • Modern storage and CPUs make language and architecture choices more important than “I/O dominates anyway”.

Compatibility, Forking, and Features

• SQLite does not accept substantial external patches and uses a “cathedral” model; this is cited as a reason for independent reimplementations.
• Limbo/libSQL are seen as “hard” forks in spirit, since they plan MVCC and other semantics that likely break ABI/shared‑memory compatibility.
• There is interest in cleaning up SQLite “baggage” (loose typing, opt‑in foreign keys), but this conflicts with strict backward compatibility; tension here is unresolved.

Licensing and Openness

• SQLite is public domain; Limbo is MIT and explicitly not public domain.
• Debate centers on:
  • Whether public domain counts as “open source”.
  • Legal uncertainty of PD in some jurisdictions vs. clarity and attribution of MIT.
  • Ethics of creating more restrictively licensed derivatives of PD code.

Testing, Reliability, and Certification

• SQLite’s extensive proprietary test suite (aiming at 100% MC/DC coverage) is both admired and criticized:
  • Admired as a reliability model and revenue source (support, certification).
  • Criticized because forks cannot easily reach parity.
• Some note Rust’s safety guarantees change the calculus for needing that level of C‑oriented testing.

Maturity, Ecosystem, and Practical Concerns

• Limbo is very early; many SQL features are missing, and basic operations can still panic.
• Concerns raised:
  • Feature parity may take years; “first 90% vs second 90%” problem.
  • Binary size (Limbo ~6MB vs SQLite ~1.6MB) matters for embedded use.
  • Ecosystem fragmentation (SQLite, libSQL, DuckDB, etc.) adds cognitive load for users.

State of Local Journalism

• Many argue local news was hollowed out long before AI: chains bought papers, cut staff, filled sites with cheap content and clickbait.
• Local reporting is often described as a “charity” model funded by donors, family money, or cross-subsidized by lifestyle/recipe content.
• Enshitification feedback loop: more ads and lower quality → fewer readers → more cuts and consolidation → even worse quality.
• Some see local papers as effectively dead in many towns, with little coverage of councils, boards, or mayoral press conferences.

AI “Slop” and Reporting Capabilities

• Strong concern about AI-generated articles with fake bylines and invented experiences; described as identity theft and consumer fraud.
• Critics argue AI can’t do core reporting work: attending meetings, building relationships, hallway conversations, back-channel calls, on-the-ground investigation, nuanced fact-checking.
• Supporters see AI as a tool: auto-transcribing meetings, scanning records, summarizing hearings, preparing background and questions; humans would then do higher-level work.
• Disagreement over timelines: some dismiss “in five years AI replaces journalists” as hype; others argue that large parts of basic reporting and story-writing will inevitably be automated, whether in 5 or 20 years.

Information Quality and the Internet

• Fear that AI slop will be endlessly scraped, retrained on, and amplified, degrading future models and making the “dead internet theory” more plausible.
• Worry that a flood of plausible but wrong content will make real journalism harder for average readers to identify.
• Some note much “journalism” is already desk-bound reaction pieces or press-release rewrites, so AI substitution is economically attractive.

Accountability, Law, and Countermeasures

• One camp wants aggressive federal intervention: treating such operations as criminal enterprises, possibly even DNS-level blocking.
• Another emphasizes media literacy education over more law-enforcement powers.
• Suggested “poison the well” tactics: planting absurd fakes so plagiarist/AI slop sites degrade their own credibility.

Broader Tech and Hype Context

• Repeated comparisons to past hype cycles (crypto, NFTs, driverless cars); some see the same personalities moving from one “right around the corner” promise to the next.
• Others counter that automation of “low-value cognition” is as inevitable as earlier tech adoption, but warn that the main outcome in news may simply be cheaper, higher-volume garbage, not better journalism.

Return to Redis and New Vector Features

• Many welcome the original creator’s return to Redis and are excited about the new “vector sets” / vector search work.
• The proposed API is praised for simplicity and “learn in 120 seconds” design; some see it as a badly needed alternative to today’s complex vector DBs.
• A few disagree with the “vector set” design direction but appreciate that multiple forks allow experimentation toward “the better Redis.”

---

Redis vs. Valkey and the License Schism

• A major thread is whether to use Redis (now under RSAL/SSPL-style licenses) or Valkey (the open-source fork).
• Some treat Valkey as the “main line” continuation of the original BSD Redis, with Redis now a proprietary fork.
• Others argue the “real” Redis is defined by design and core team, not license; they’ll stick with the brand and its engineers.

---

Licensing, SSPL, and Trust

• Many are upset by the license change, calling it a “rug pull” that breaks an implicit social contract with contributors and users who expected BSD forever.
• Others counter that BSD/mit explicitly allows relicensing, and that contributors unhappy with this should have chosen copyleft and avoided CLAs.
• SSPL is seen by some as “almost AGPL + SaaS restriction”; by others as dangerously broad, hard to comply with, and legally ambiguous (e.g., requiring all “service source code” under SSPL, possibly conflicting with Linux/glibc, etc.).
• There’s concern about future changes and “booby-trap” licenses vs. the predictability of OSI-approved ones.

---

Cloud Providers and OSS Economics

• Strong disagreement on who is “the bad guy”:
  • One side: cloud providers parasitize OSS, commoditize it, and capture most revenue; restrictive licenses are a justified defense.
  • Other side: these projects built their popularity on permissive licenses and community work; changing rules after success harms trust and the broader OSS ecosystem.
• Valkey’s backing by major clouds and the Linux Foundation is seen both as:
  • A positive, sustainable way to keep an open fork healthy.
  • And as big tech using “community” branding to maintain their margins.

---

AI Tools (Claude vs. ChatGPT) and Developer Workflow

• Multiple commenters affirm Claude’s usefulness for coding, design, and even fiction editing, often preferring its style and lower “prompt wrangling” overhead to ChatGPT.
• Others report better results with ChatGPT for certain reasoning or math-heavy tasks.
• Several describe AI tools as huge productivity multipliers and as emotional “support” for solo devs.

---

Meta: Community, Contribution, and Future

• Some maintainers/contributors say they were not personally bothered by the relicensing and still see value in both Redis and Valkey.
• Others say the incident makes them more cautious about contributing to or depending on projects with CLAs or corporate control.
• Many express continued admiration for the technical work but plan to default to Valkey for future deployments.

Market reaction and hype

• Some commenters watched Google’s stock jump on the news and asked if it was justified; others noted large single‑day stock moves are often weakly tied to fundamentals and hard to attribute.
• Several people compared quantum‑computing PR to fusion: many “breakthroughs,” few practical payoffs yet, and strong incentive to oversell to secure funding.

Verification and benchmarking

• Central concern: the Willow random‑circuit‑sampling (RCS) task is claimed to take ~10²⁵ years to classically simulate, but for the same reason it would also take ~10²⁵ years to directly verify the result classically.
• Many argue the field badly needs “supremacy‑style” experiments where quantum speedup exists but classical verification is cheap (e.g., factoring), and that current hardware can’t yet run such algorithms at scale.
• Some defend RCS as a natural benchmark close to the device’s native physics; others see it as a “toy problem” with no obvious use.

Device capabilities and limitations

• Willow uses superconducting qubits with surface‑code error correction. A key result is that larger codes (more physical qubits) now show improved logical error rates, a necessary precondition for scalable fault tolerance.
• The chip is theoretically universal (can implement general quantum gates), but error rates and coherence times are far too poor for long algorithms like Shor’s or Grover’s.
• Current devices are in the “noisy intermediate‑scale quantum” (NISQ) era: tens–hundreds of qubits, short-depth circuits, and severe noise constraints.

Algorithms and potential applications

• Skeptics claim that beyond Shor’s (factoring) and a few known algorithms, there’s little with clear, large, practical advantage; they note at least one well‑funded “quantum algorithms” startup has already failed.
• Others point to a substantial “algorithm zoo”: quantum chemistry, materials, optimization, and linear‑system solvers, while stressing that only a subset give super‑polynomial speedups and many need far larger, cleaner machines.
• There’s debate over whether classical deep learning will erode much of the hoped‑for advantage in simulation.

Cryptography and Bitcoin

• Consensus in the thread: Willow has no near‑term impact on deployed cryptography. It can’t factor nontrivial integers or attack real‑world RSA/ECC.
• Several comments estimate that practical cryptanalytic attacks would require on the order of millions of physical qubits and far better error correction.
• Some discussion on how centralized systems could migrate to post‑quantum crypto more easily than decentralized cryptocurrencies, and what quantum attacks would mean for Bitcoin mining and wallets.

Quantum interpretations and “many worlds”

• Large subthread on whether quantum computing supports the Everett/many‑worlds interpretation.
• One side argues that quantum algorithms can be seen as computations spread over “branches” that later interfere, which is naturally described by many‑worlds.
• Others counter that quantum computing is fully compatible with collapse‑style interpretations; it’s just linear algebra on wavefunctions, and no extra ontological baggage is needed.
• General agreement that this debate doesn’t change the experimental result and is largely philosophical.

Classical analogies and physical computation

• Several users compare the RCS benchmark to physical processes like sand piles, falling balls, or path integrals: nature “simulates itself” efficiently, while exact classical simulation explodes in cost.
• Clarification that simulating quantum many‑body systems is exponentially harder than simulating classical ones, which is exactly the niche where quantum computers are expected to help.

Community sentiment and accessibility

• Many software engineers report feeling “small” or overwhelmed by the physics and math; others respond that undergraduate linear algebra plus time is enough for a solid conceptual grasp.
• Numerous pointers are shared to textbooks, tutorials, simulators, and cloud‑hosted tooling so people can experiment with quantum programming without real hardware.
• Overall tone: respect for the technical achievement, combined with strong skepticism about immediate usefulness and timelines to real‑world impact.

Continuous latent reasoning vs token-space CoT

• Main idea: instead of generating explicit chain-of-thought (CoT) tokens, reuse the model’s internal “continuous thought” (last hidden state) across steps, so reasoning happens in latent space.
• This avoids “snapping” the hidden state to discrete tokens via the LM head, which is likened to lossy quantization.
• Some see this as “higher-resolution” internal reasoning and potentially more token-efficient than CoT; others note current gains appear mainly in efficiency, not dramatic quality jumps.

Last hidden state / embeddings

• Clarified as the final hidden representation after all residual layers, just before the classification head/softmax.
• Normally, this is projected to logits over the vocabulary; that projection compresses rich internal information into a single token distribution.
• Here, the last hidden state is fed back as if it were a token, evolving a continuous state instead of feeding back discrete tokens.
• There is debate over how “rich” this final vector really is; some say it is highly informative and already used in practice for classification/regression, others argue it’s optimized only for the next-token prediction and might be more compressed than assumed.

Training and architectural concerns

• This recurrent use of hidden states introduces sequential dependencies during training, reducing the usual transformer advantage of parallelizable, masked-token training.
• That makes training slower and more complex; whether the tradeoff is worth it is seen as task-dependent.
• Some worry about feeding a last-layer representation back into the first-layer space, since layers might encode different representations; others point out prior work (e.g., feedback mechanisms, tied embeddings, layer reordering) suggests this can work with sufficient finetuning.

Relation to human thought and language

• Several comments link this to humans “thinking in mentalese” or non-verbal modalities, with language as a lossy encoding of deeper concepts.
• Others emphasize that language still heavily shapes thought and that internal representations may be multi-modal and variable across individuals.

Safety, intelligence, and terminology

• Some see this as another step toward “true intelligence” and raise concerns about uncontrolled progress and potential danger.
• Others push back on anthropomorphic language (“thinking”, “reasoning”), arguing LLMs are sophisticated next-token predictors/compressors, not intelligent agents.
• There is a broader debate over whether brains are “just” computers in the Turing sense and whether that makes AGI largely a scaling/training problem.

Scale and nature of the memorization feat

• Many are astonished that someone could learn a full foreign Scrabble word list (tens to hundreds of thousands of forms) in about nine weeks.
• Rough back-of-envelope comparisons (hundreds of words per day) lead several commenters to call it “alien” or effectively impossible for normal people.
• Others note mitigating factors: large overlap between English, French, and Spanish vocabularies; shared Latin roots; patterned conjugations and derivations; and many related inflected forms.
• Nevertheless, consensus is that this remains an extreme outlier ability, likely rooted in exceptional memory and pattern-recognition rather than learnable technique alone.

Words as strings vs. language mastery

• Repeated emphasis that competitive Scrabble involves memorizing valid strings, not meanings or grammar.
• Knowing every acceptable form of a verb does not imply being able to speak or understand the language.
• Some argue that learning without semantics makes memorization harder; others counter that pure orthographic patterns plus regular suffix rules can be enough.
• The case is compared to large language models and to humans who “know” vast lists of tokens without deeper “understanding.”

Strategy beyond memorization

• Memorization is described as necessary but not sufficient. Strategy includes rack balancing, board control, tile-tracking, time pressure, and probabilistic vs perfect-information endgames.
• Short 2–3 letter words are considered crucial for board control and for challenging opponents’ plays; high-value tiles matter, but “bingo” stems of low-value letters are central.
• “Phonies” (fake words) are occasionally used as a tactic, especially against perceived weaker linguists, but top players can often spot and challenge them.

Language variants and metas

• Spanish and French Scrabble have different tile distributions, point values, and even digraph tiles, leading to distinct strategic “metas.”
• Mastering these differences, not just word lists, is seen as part of what makes the achievement impressive.

Optimization, aesthetics, and value judgments

• Some word-lovers dislike Scrabble and spelling bees, seeing them as memorization contests detached from meaningful language use.
• Others defend the game as rich, probabilistic, and not “over-optimized,” with upsets still common.
• A side debate questions whether dedicating such rare cognitive talent to Scrabble is a “waste,” with strong pushback that individuals owe their abilities to no one and can pursue niche excellence if they wish.

Medieval vs. Modern Use of Color

• Commenters stress that medieval material culture was often extremely bright and “gaudy,” in contrast to modern fiction’s gray, earth-toned portrayal.
• Modern design trends, especially in homes and cars, are described as shifting toward “greige,” black, white, and muted earth tones.
• Some argue that, despite more available pigments and screens, intense colors are now used more sparingly and are often coded as “cheap” (e.g., bright plastic toys) versus “premium” (wood grain, gunmetal, muted devices).

Restoration and Changing Aesthetics

• Examples of chapel restorations in Europe show that interiors once vividly painted (blue skies, flesh tones, red lips) had been assumed to be austere stone.
• Similar controversy surrounded cleaning the Sistine Chapel, where vibrant original colors clashed with modern expectations of dark, muted art.
• Disputes in restoration projects often pit those favoring “authentic” bright schemes against those preferring the somber look they are used to.

Economic and Environmental Factors

• Historically, textiles and pigments were costly, incentivizing vivid, conspicuous colors as status markers.
• One view: today’s expensive items (like high-end electronics and cars) signal status with minimal or neutral color, perhaps as “anti-conspicuous” consumption.
• Another view links ancient bright palettes to dim interiors and poor lighting, making strong colors more functional.

What Counts as a Color?

• Debate over whether white, gray, and black are “colors” or just illumination levels; counterpoint that in practice anything in a paint store is a color.
• Discussion of spectral vs. non-spectral colors (magenta, brown, purple), achromatic colors, and metamerism.
• Some argue color categories are partly cultural and partly constrained by human biology; color science is described as a deep rabbit hole.

Language, Culture, and Color Terms

• Many examples of languages partitioning color space differently (e.g., Japanese blue/green, Russian light vs. dark blue, pink vs. red, brown vs. orange).
• Several commenters emphasize that lack of a distinct word doesn’t imply lack of perception; it affects labeling and speed of discrimination, not basic vision.
• References to known patterns in how languages historically add color terms (often starting with light/dark, then red, etc.).

Ancient Perception of Blue

• Strong pushback against claims that Greeks/Romans “couldn’t see blue.”
• Evidence cited: widespread manufacture and use of Egyptian blue, ultramarine, azurite, blue glass, and indigo dyes.
• Explanation that ancient texts often used “the color of X” (e.g., a pigment, plant, or stone) instead of abstract color words; modern scholars once misread this as absence of color concepts.
• Clarification that in antiquity “cyan” referred to a pure blue, not modern “blue-green.”

Other Historical Color Notes

• Medieval heraldic colors map closely to a traditional seven-color scheme (white, yellow, red, green, blue, purple, black), with some fluidity (e.g., purple as a red variant).
• Noted that religious and literary traditions outside Europe (e.g., Hindu depictions of deities) have long, explicit uses of blue.
• Brief etymological aside: certain monastic habit colors underlie later words for drinks and animals (e.g., cappuccino, capuchin monkey).

Perceived ineffectiveness of DNT

• Many argue DNT “never worked”: it relied on voluntary compliance, most ad/analytics platforms ignored it, and it gave users a false sense of privacy.
• Some developers admit they simply forgot to support it; others say corporate support only happened when bundled into compliance tools.
• Several view its removal as sensible cleanup of a misleading, marginal feature.

Legal and regional aspects

• Others counter that DNT does matter legally in some jurisdictions:
  • German courts have ruled the DNT header is a valid GDPR opt‑out signal, binding on services like LinkedIn.
  • Some EU sites and tools (e.g., certain price comparison and analytics platforms) reportedly honored it and used it to suppress tracking or cookie prompts.
• Critics say Mozilla is acting as if only US law counts and ignoring existing EU/German rulings.

Global Privacy Control vs DNT

• Firefox now promotes Global Privacy Control (GPC) instead.
• Some think GPC is just a renamed DNT (Sec-GPC: 1 vs DNT: 1) with similar technical issues.
• Supporters say GPC has better legal alignment in places like California; skeptics argue sites that ignored DNT will also ignore GPC.
• It’s noted that GPC is narrower (often framed as “do not sell/share data” rather than “do not track”) and not clearly GDPR‑compliant.

Privacy, tracking, and fingerprinting

• Several note DNT added one more fingerprinting bit, ironically aiding tracking.
• Others argue uniqueness across sites is fine if the fingerprint changes per‑site and scripts are constrained.
• Many stress that technical anti‑tracking is an arms race; legal bans plus browser‑side blocking are both needed.

Views on Mozilla’s direction

• Some see the removal as minor and user‑friendly; others call it a loss of user agency and a “clown move” given recent legal wins for DNT.
• There is broader frustration that Mozilla is aligning with adtech and “privacy‑preserving attribution,” making Firefox harder to support.

Alternatives and proposed solutions

• Common advice: use Firefox or forks with uBlock Origin, NoScript/medium‑mode blocking, cookie auto‑deletion, or specialized consent‑auto‑denial tools.
• Several propose browser‑level consent and cookie handling, or even built‑in, standardized ad/tracker blocking instead of honor‑system headers.
• Broader debate emerges on ad‑funded vs subscription web models and whether aggressive adblocking is ethical or simply necessary self‑defense.

Business Model, Fees & Sustainability

• Product charges a flat $1/month for direct indexing with 0% expense ratio; many question whether this can support engineering, compliance, and support.
• Back-of-envelope math suggests needing well over 100k customers to break even; some suspect eventual fee hikes, sale to a larger institution, or reliance on less-visible revenue.
• Comparisons to existing low-cost options (Vanguard, Schwab, Fidelity, FZROX, 0.03–0.05% ETFs) show savings are often measured in a few basis points, which many see as too small to justify switching and added risk.
• Some argue they would gladly pay higher flat fees if that clearly funded a stable, independent business.

Revenue Sources: PFOF, Cash, Lending

• Thread heavily debates potential secondary revenues: payment for order flow (PFOF), securities lending, margin interest, and cash spread.
• Some see PFOF and stock lending as hidden fees and misaligned incentives; others (including market-making veterans) argue PFOF can improve execution for retail and is widely misunderstood.
• There is concern that an incentive to churn accounts (for PFOF or borrow fees) could conflict with optimal rebalancing and tax-loss harvesting behavior.

Trust, Custody & Fintech Risk

• Many are wary after recent fintech failures (Synapse/Yotta) and question what happens if the startup fails.
• Founder states: client accounts and securities are held in each customer’s name at Apex Clearing (a large custodian/broker-dealer); Double is an SEC-registered RIA, not a broker.
• Users can verify holdings directly via an Apex portal, which several view as materially safer than pooled “for benefit of” accounts.
• SIPC covers failures of Apex, not the advisor; if Double fails, assets should remain at Apex, but some still see residual operational/coordination risk.

Direct Indexing vs ETFs (Tax, Trading, Portability)

• Advantages discussed: granular customization (exclude employers, sectors, ESG filters, factor tilts), daily tax-loss harvesting, shareholder voting rights, and “index but except X” use cases.
• Concerns:
  • Trading costs and bid/ask spreads across many stocks vs a single liquid ETF; some argue ETF market makers already compress these costs.
  • Complexity at tax time (many lots), though others note summary 1099-B reporting makes it manageable.
  • Portability: leaving the service could leave investors with hundreds of positions and embedded tax consequences, creating de facto lock-in.

Target Market & Competition

• Existing direct-index and basket products from Fidelity, Schwab, M1, Wealthfront, etc. are cited; some note similar functionality at slightly higher but still low fees.
• Many “Boglehead”-style investors prefer to stay with large, “too big to fail” firms for life-savings, seeing this as more suitable for smaller or experimental allocations.
• Non-US users note it’s US-only; some argue EU-based US expats would greatly value compliant direct indexing.

Overall Impressions of Unexpected Keyboard

• Many commenters are impressed and switch to it from Hacker’s Keyboard or other Android keyboards.
• Praised especially for terminal/Termux use and SSH work; makes programming on a phone “not miserable.”
• Some non-programmer users reportedly type faster with it than with standard keyboards.
• A few find it “very innovative” but worry it demands more precision than they have.

Core Features & Interaction Model

• Key idea: multiple symbols per key, accessed by flicking/swiping toward key corners.
• Spacebar swipe for cursor movement is widely appreciated; some report vertical swipe or with modifiers for text selection.
• Compose key support and full modifier keys (Ctrl, Alt, etc.) are major draws, especially for terminal workflows and shortcuts like Ctrl‑A, Ctrl‑C, Ctrl‑D, Ctrl‑Z.
• Ability to create custom layouts (including niche scripts or symbols) is highlighted as a standout feature.
• There is a separate numpad layout, though some dislike that main numbers remain in a horizontal row.

Comparisons to Other Keyboards

• Frequently compared to Hacker’s Keyboard:
  • Unexpected is more modern, better maintained, and has easier access to symbols via swipes.
  • Hacker’s Keyboard is seen as slightly faster for some, but aging and less compatible with newer Android versions.
• Drawn parallels with alternative input systems like MessagEase, Thumb-Key, GKOS, KeyBee, FITALY, and Japanese “flick” input.
• Some users continue to rely on Gboard or FUTO for general texting due to swipe-typing and strong predictions.

Learning Curve, Precision & Usability

• Swiping on keys takes practice but becomes second nature for many.
• Others report accidental swipes producing accented characters or strange capitalization glitches.
• Some find text selection via gestures on other keyboards (long-press, context menus) slow and imprecise compared to modifier keys.

Missing or Desired Features

• Common requests: optional autocomplete, autocorrect, auto-capitalization, emoji search, configuration export/import, “double-space for period” shortcut, and an undo function.
• Some explicitly like the absence of autocorrect and predictive features, valuing determinism over “autocorrupt.”

Privacy & Ecosystem Context

• “Privacy-conscious” marketing resonates; several express general distrust of smartphone keyboards and input methods.
• In parallel, some recommend FUTO keyboard as another privacy-oriented option, though its prediction and swipe quality receive mixed reviews.

Initial reactions to phone-only development

• Many readers react with anxiety or disbelief; coding 25k lines on a touchscreen feels like “torture” to some.
• Others are impressed and inspired, especially given that the plugin is widely regarded as high quality.
• Several admit they struggle even with texting or short scripts on phones due to typos, missing words, and eye strain.

Tools, workflows, and ergonomics

• Common setups mentioned: Termux/Neovim/Vim, tmux, SSH (Termius, mosh, Eternal Terminal), and sometimes DeX or AR glasses to simulate a desktop.
• Vim/Neovim is seen as relatively phone-friendly because it relies less on modifier keys.
• Limited screen width and on-screen keyboard covering code are major pain points; foldables help somewhat.
• Some use special keyboards (Hacker’s Keyboard, AnySoftKeyboard, Thumb-Key, Penti, T9-style layouts). Others stick to defaults but rely heavily on completions and LSP/LLM support.
• A few users routinely do serious remote admin or side projects from phones/tablets and find it “slow but workable.”

Socioeconomic constraints and fundraiser

• The developer reportedly has no PC and codes on a phone out of necessity, not preference, while studying for medical entrance exams.
• Cultural pressure from parents toward medicine/engineering is discussed.
• Community members organized a fundraiser for a laptop; shipping hardware into Bangladesh/India is described as risky due to customs delays and informal “fees,” so buying locally with external funds is preferred.

Phones vs PCs and historical comparisons

• Older developers recall writing nontrivial software on calculators, 25×80 terminals, and early phones (T9, BlackBerry, Nokia Communicator, HP48).
• Some argue a modern phone is more powerful than 90s desktops; others emphasize comfort, keyboard quality, and screen size over raw power.

Careers: software vs medicine

• Long subthread compares software engineering and medicine: pay, job security, prestige, working conditions, burnout, and future-proofing.
• Consensus: both careers have serious downsides; doing either solely for status or parental pressure is questionable.

Security, privacy, and mobile UX

• On-screen keyboards are flagged as a security risk; some default keyboards reportedly transmit keystrokes for profiling.
• Discussion touches on blocking network access for keyboards and the difficulty of truly securing consumer phones.
• There is curiosity about programming languages/IDEs explicitly optimized for small screens; a few niche examples are mentioned, but no clear winner emerges.

What a Boltzmann Brain Implies

• A Boltzmann brain (BB) is a spontaneously formed brain with false memories in a high-entropy universe.
• If you were a BB, your perceptions would not be reliably connected to any external reality; continuity and stable laws would be accidental.
• Several commenters stress this makes BB scenarios epistemically self-undermining: the physics used to argue BB-dominance would itself be untrustworthy if we were BBs.

Simulation Hypothesis, Solipsism, and Rules

• Some compare BBs to extreme solipsism and to simulation arguments.
• Others distinguish simulations: a simulation still has consistent underlying rules, so senses can reliably track that rule-set, unlike a purely random BB environment.
• Nested simulations and “virtualized physics” are discussed, with debate over whether these ideas are falsifiable or just speculative.

Infinity, Probability, and Physical Constraints

• One camp: in an infinite spacetime with finite local states, every allowed configuration (including brains, iPhones, whole universes) occurs infinitely often.
• Opponents argue:
  • Infinity is not just “a very long time”; naive probability reasoning breaks on infinite domains.
  • Some states may be unreachable even with infinite evolution (analogy: “Gardens of Eden” in Conway’s Life).
  • Physical laws, conservation constraints, and entropy may make such configurations effectively impossible or unimaginably rare.
• There is back-and-forth over whether “non-zero probability + infinite time” guarantees occurrence.

Philosophical and Bayesian Responses

• A referenced Bayesian critique claims our coherent, long-running, structured observations are far more likely if we are ordinary observers (OOs) than BBs, because random BBs with stable “decorations” are vastly rarer than incoherent ones.
• Others challenge this, arguing that even rare “decorated BBs” might still outnumber OOs, and that some uses of Bayesian reasoning here seem to give absurd results.
• Several note that BBs are mainly useful as a reductio: if your cosmology predicts BBs vastly outnumber OOs, something in that cosmology (e.g., low-entropy initial conditions as mere fluctuation) is probably wrong.

Meaning, Practical Impact, and Attitudes

• Many see BBs as unfalsifiable and not action-guiding: even if true, you can’t do anything about it, so you should just live as if you’re not a BB.
• Others emphasize the thought experiment’s value in exposing limits of our assumptions about entropy, probability, and knowledge, while acknowledging it can quickly become nihilistic or “too silly” to worry about.

What Tree Calculus Is

• Formal system where every expression is an unlabeled ordered tree built from a single symbol t with application: E ::= t | E E.
• Semantics given by a handful of small-step rewrite rules on trees.
• Trees with 0, 1, or 2 children represent values; nodes with 3+ children represent computations to be reduced.
• Programs and data are the same kind of trees; booleans, pairs, lists, numbers, and strings are all encodings on top of this.

Relation to Other Calculi and Languages

• Closely related to combinatory logic, especially SK calculus; two of the rules correspond directly to K and S.
• Can encode SKI, fixed-point combinators, and thus is Turing-complete.
• Compared frequently to lambda calculus: similar expressive power but different primitives (trees + triage instead of lambdas + substitution).
• Compared to Lisp/Forth/APL/Prolog: like a homoiconic, reflective core calculus, but reflection happens on the raw program trees rather than quoted ASTs.

Intensionality, Reflection, and “Inversion”

• Key claimed feature: intensionality—programs can inspect and branch on their own tree structure, not just their extensional behavior.
• This enables “honest reflection”: self-evaluation, program analysis, optimization, serialization, and type-checking defined within the calculus, without an external quoting layer.
• “Invert function” demos impress some readers, but others note inversion must be partial (halting-problem limits) and similar capabilities exist in APL, Prolog, and other systems.

Usefulness and Performance

• Proposed uses: universal intermediate representation, configuration-as-code with first-class functions, self-hosted optimizers (e.g., stream fusion).
• Some see it as mainly of theoretical interest, analogous to unary counting or SKI: elegant but unwieldy.
• Concern about performance: e.g., thousands of reduction steps for simple tasks like lowercasing a string; counterpoint is that compiled patterns and JITs could mitigate this.

Website Design and Communication

• Many readers find the landing page confusing: marketing-style headings, dense academic text, but little plain explanation of “what this is.”
• Frequent requests for a “for dummies” intro, a one-sentence definition, and clear separation between the bare calculus and the sugared programming language.
• Several commenters emphasize that diagrams of the tree rules and visualizations greatly improve comprehension.

Learning Resources and Theory

• References shared to a detailed book, technical papers (including a typed version), and Coq proofs.
• Multiple community-made expositions and toy interpreters (OCaml, JS, Python, Scheme/Racket) help clarify the reduction rules and encodings.

Range of Side Projects & Incomes

• Very wide mix: dev tools (Kubernetes UI, API mocking, uptime monitoring, scraping APIs, VPNs), consumer apps (fitness, note‑taking, plant care, language learning, job tools), games, AI utilities, newsletters, books/courses, plugins, and niche websites.
• Many non‑software projects too: laser‑cut wall art, jewelry, rolling trays, 3D printing, Airbnb cabins, egg farming, festival payment systems, puzzle magazines, historical maps, escape rooms, etc.
• Revenue spans from just crossing $500/mo to several thousand, and in a few cases full‑time incomes or low six‑figure businesses.

Common Success Patterns

• “Scratch your own itch” is repeated: built to solve a personal pain (docs, festival payments, head tracking, job search, resume automation, etc.).
• Narrow, “unsexy” niches with recurring demand (janitorial leads, checks by mail, local SEO, industrial cleaning, dividend tracking) are often profitable.
• Many projects are years old, compounding slowly via word‑of‑mouth, SEO, and organic search rather than big launches.
• Several open‑source tools fund development via cloud add‑ons, enterprise plugins, donations, or support contracts.

Marketing & Distribution Challenges

• Discoverability is a major pain point, especially for physical products and indie apps; conventions and Meta/Google ads help some, others lean on Reddit/HN/communities.
• Landing page design is hard for many; people share workflows: start from templates (Tailwind UI, bought themes), copy good sites, or hire designers.
• Some rely almost entirely on referrals and existing networks; others experiment with ads that often barely break even.

Pricing, Value, and Customers

• Debate over “expensive” dev tools (e.g., $99 Kubernetes UI): one camp says only paying customers matter; others note price can be “too high for them” without being objectively wrong.
• Mix of models: subscriptions, one‑time licenses, freemium upgrades, usage‑based pricing, sponsorships, affiliate links, and ad‑supported PWAs.
• Enterprise buyers introduce POs, compliance, and longer cycles; small‑to‑mid customers often happily self‑serve on the website.

Ethical / Social Concerns

• Strong reactions to:
  • AI tools for cheating technical interviews and coding tests; some applaud “breaking a bad system,” others fear escalating surveillance.
  • AI chatbots impersonating OnlyFans models; some see harmless companionship, others call it exploitative and sad.
  • Gambling‑adjacent projects (poker, sports‑betting analysis) and privacy issues with location‑based apps.
• Thread acknowledges a “broken” hiring and loneliness landscape but disagrees on individual responsibility vs “hate the game, not the player”.

Tech & Architecture Notes

• Frequent stacks: Next.js/React/Tailwind, Tauri/Electron, Elixir/Phoenix, Django/Wagtail, Lambda + Postgres, CRDTs and SQLite in the browser, Puppeteer‑based scraping, mobile apps with native or Expo.
• Many highlight over‑engineering regrets (complex serverless setups) vs simple monoliths; others praise Lambda for spiky festival loads.

Lessons and Meta‑Reflections

• Survivorship bias is noted explicitly: this thread shows successes, not the graveyard of failed projects.
• Still, multiple posters say: shipping many small things materially increases odds of at least one modest win.
• A recurring theme: tech is the easy part; sales, support, logistics, and staying motivated over years are what make or break these side incomes.

AI and the Music/“Creative” Industry

• Some see generative AI as accelerating a flood of low-effort music and art, eroding opportunities for human creators while platforms profit.
• Others frame AI as “just another tool” that is overhyped but not fundamentally different from previous technologies.
• Strong distrust of “AI-washing”: companies renaming or rebranding basic software as “AI” and selling nonexistent capabilities.

Streaming Economics and Musician Pay

• Many argue streaming underpays artists and reinforces winner-take-all dynamics (huge shares going to a few stars).
• Proposed solutions include new taxes on streaming revenue and user-centric payout models; critics say this treats symptoms and misuses taxation instead of fixing bargaining power and contracts.
• Some suggest non-transferable copyrights and shorter terms to rebalance power toward creators and the public domain.

Live Performances vs Recorded Music

• One camp says the future (and mostly the past) of musician income is live shows and merch; recordings are mainly marketing.
• Others counter that touring is grueling, oversaturated, and often not very profitable except for top-tier acts and niche working bands.
• Debate over whether we should accept that “most artists will always be poor” vs. pushing for broader support (e.g., basic income, subsidies).

Copyright, Labels, and Power

• Labels are portrayed both as exploitative intermediaries and as valuable marketers/distributors who turn songs into scalable businesses.
• There’s disagreement over whether labels “serve musicians” or primarily extract value via lopsided contracts and concentrated market power.
• Some advocate weakening or abolishing copyright altogether; others note that major stars and rights holders will fight that fiercely.

Internet Archive, Great 78 Project, and Preservation

• Concern that the lawsuit over old recordings could bankrupt the Internet Archive and permanently erase unique digitized 78s, some from physically disintegrated media.
• Tension between libraries’ preservation mission and rights holders’ desire to control or even suppress back catalogs.
• Some criticize IA’s legal risk-taking (e.g., past “emergency” lending) as strategically reckless; others see it as necessary civil disobedience.

Artistic Variants and “Multiple Edits”

• Several participants like alternate takes, live versions, remixes, and commentary tracks, arguing they keep songs fresh.
• Others note practical constraints: studio time cost, chart rules, and listener attachment to a single “canonical” version.
• Some imagine future AI-driven recordings that subtly vary each play, raising both excitement and unease.

Paradoxical findings on treats vs beverages

• Thread centers on the study’s headline result: sweetened beverages correlate with higher CVD risk, while low intake of “treats” (pastries, ice cream, chocolate, sweets) correlates with higher risk.
• Some commenters jokingly celebrate this as validation of pastry/ice-cream habits, but most treat it as suspicious or confounded.

Reverse causality and confounding

• Strong theme: people with existing disease or known high risk may drastically cut treats and sugar, overpopulating the “lowest intake” category.
• Even after exclusion of previously diagnosed individuals, commenters note this doesn’t remove those aware of high risk (family history, abnormal labs).
• Others point out that very low intake of many substances often reflects underlying ill health in observational studies (e.g., alcohol).

Cultural and cohort specifics (Sweden)

• Swedish practices like “fika” (social coffee + pastry) and once‑weekly candy (“Saturday candy”) may make treats a proxy for social integration rather than unhealthy lifestyle.
• Some argue Swedish diet and food culture have become more Americanized and ultra‑processed since the 1990s–2000s, complicating interpretation over time.

Sugar type, medium, and metabolism

• Long debate over whether HFCS is worse than sucrose; some say composition is similar, others emphasize fructose metabolism and potential harms.
• Several note that “medium matters”: soda is fast-absorbed sugar water, while pastries/ice cream pair sugar with fat and/or fiber, slowing absorption and altering glycemic response.
• Distinction made between added sugars and naturally occurring sugars in whole fruit (with fiber and micronutrients).

Methodological limits of the study

• Critiques of food‑frequency questionnaires: recall bias, social desirability (“moralizing” food), poor quantity estimates, old baseline data.
• Concerns about unmeasured confounders (body fat %, sodium, overall diet quality, social factors) and that results may not generalize beyond this Swedish cohort.

Broader views on sugar and health

• Many still favor minimizing added sugar for reasons beyond CVD (energy stability, dental health, liver effects, metabolic disease).
• Others caution against over-focusing on sugar type vs overall dietary pattern and ultra‑processed foods.

Calories, weight, and metabolism

• Side debate on “calories in vs calories out” versus more complex influences (medications, aging, microbiome, macronutrient composition).
• Some insist energy balance fully governs weight; others stress that different foods with the same labeled calories can have different metabolic and satiety effects.

Practical diet observations

• Several share strategies of removing “hidden” sugar (e.g., in peanut butter, mayonnaise), preferring minimally processed foods.
• Discussion of how ubiquitous sugary, ultra‑processed options (school meals, offices, highways) make low‑sugar eating difficult in practice.

Incident overview

• Discussion centers on Funko’s “brand protection” partner triggering a takedown that briefly removed itch.io’s domain and then, bizarrely, contacted the founder’s mother (likely from old WHOIS data).
• A specific subpage allegedly imitated the “Funko Fusion” site; the page and account were removed after initial complaints, but the domain was later put on hold by the registrar.

Funko, BrandShield, and responsibility

• Funko’s public statement: they respect indie games, only intended a takedown of a specific page, and blame a partner and “service providers” for the full-domain outage.
• BrandShield’s statement similarly claims they requested only a URL-level takedown, not the entire domain, and shifts blame to providers; they also urge platforms to improve “self‑regulation.”
• Multiple commenters argue these statements are misleading: a registrar cannot act on a single URL, so contacting the registrar for “fraud/phishing” is effectively a domain-level attack.
• Many insist that Funko remains responsible for actions taken by its contracted agent and should face reputational consequences if it keeps the relationship.

Registrar conduct

• Significant criticism is directed at the registrar (iwantmyname) for disabling a long‑standing, reputable domain without contacting the registrant or properly closing the abuse ticket.
• Some note that fraud complaints are treated more urgently than copyright complaints, but argue that this makes false fraud reports especially dangerous and legally risky for registrars.

Systemic issues: DMCA, brand enforcement, and abuse

• Commenters liken “brand protection” outfits to debt collectors: mass-complaint operations using fear and overreach, often with little follow‑through.
• Concern that AI‑driven enforcement and misclassified complaints (fraud instead of copyright) will worsen over‑takedowns and chill independent creators.
• Broader critique that copyright and platform policies function as “techno‑feudalism,” where large firms can cheaply weaponize takedowns while small creators lack recourse.

Power, governance, and side discussions

• Extended tangents discuss abuse of power generally, calls for harsher penalties (e.g., income-based fines), and alternative governance models like sortition/lottocracy and “democratic technocracy.”
• Many see this episode as emblematic of unaccountable corporate power and misaligned incentives across enforcement vendors, platforms, and registrars.
• Thread includes dark humor, mockery of Funko and BrandShield, and personal anecdotes about authority figures “calling your mom” as a punishment tactic.

Overall reaction to the article

• Many found the piece extremely long, dense, and indirect; some gave up partway and felt it obfuscated or “gaslit” rather than clarified.
• Others praised it as one of the author’s best: a systems‑level explanation of banking regulation, risk, and incentives rather than a yes/no verdict on “debanking.”
• Several readers thought the article downplays viewpoint discrimination; others stressed it was descriptive, not an endorsement of current practices.

Prevalence and causes of debanking

• Multiple anecdotes of accounts closed or refused across Europe, UK, US, Japan, and Singapore: refugees, expats, people tied to sanctioned or “high‑risk” nationalities, porn‑adjacent and gun‑adjacent businesses, crypto employees, and Muslim charities.
• Some argue debanking of asset‑owning middle and upper‑middle classes is “almost everyone”; others demand evidence and say they know no one affected.
• Disagreement whether most closures are truly political vs. driven by compliance costs, AML risk, and regulators’ pressure.

Crypto, banks, and risk

• Strong debate over whether “Operation Choke Point 2.0” is real:
  • One side: crypto firms are systematically cut off for political/ideological reasons and labeled “politically exposed.”
  • Other side: banks rationally avoid crypto because of high liquidity, capital, AML, and fraud risks, with too little profit to compensate.
• A bank founder describes regulators forcing 100% liquidity for crypto‑linked deposits, making such relationships marginal or loss‑making.

AML/KYC effectiveness and costs

• Many commenters say AML/KYC frequently harms ordinary users and small businesses (delays, closures, heavy paperwork), especially migrants and cross‑border workers.
• Several claim AML is costly, barely catches real launderers, and functions as a political control tool; some call it unconstitutional “thoughtcrime” and want full repeal.
• Others counter that AML/KYC is crucial for “follow the money” investigations and easier prosecutions, even if it doesn’t “stop” laundering outright.

Payments, censorship, and culture

• Repeated examples of card networks pressuring Japanese sites and bookstores over legal erotic/otaku content; accusations of US cultural norms being exported via payments.
• Counter‑arguments: card networks are private firms not obliged to serve all legal content; societies routinely ostracize legal but distasteful speech or products.

Rights, regulation, and SAR secrecy

• Some advocate treating basic banking like a utility/common carrier, with a legal right to an account and only court‑ordered exclusions. EU/UK “basic account” rules cited but described as limited, especially for businesses.
• Strong concern over Suspicious Activity Reports: banks must file them secretly and cannot tell customers if a SAR led to debanking. Critics see this as opaque, quasi‑punitive, and ripe for abuse; defenders note it’s intended to avoid tipping off criminals, but acknowledge the civil‑liberties trade‑off.