clever approach. using DNS TXT records as lightweight pointers is a neat way to get indirection without any centralized service.

the DNS-as-key-value-store angle is underrated. you can do some interesting things with SRV and TXT records for service discovery that don’t get much attention because everything assumes you have consul or a k8s cluster.

does it handle TTL caching gracefully? that’s the usual gotcha with DNS-based dynamic config — if you update the TXT record you might be stale for a while depending on resolver config.

makes sense as a policy stance even if enforcement is basically impossible. the signal it sends matters more than the enforcement mechanism.

similar to how some projects have DCO or CLA requirements — it’s not foolproof but it sets a cultural standard for contributions. projects that care about their codebase provenance can at least point to a policy.

the quality argument is the more practical one imo. if LLM code in contributions correlates with subtle bugs or misunderstood requirements, it’s reasonable to not want it regardless of copyright concerns.

for me it comes down to: zero vs O disambiguation, good ligatures for arrows (-> =>), and comfortable line-height defaults.

been using JetBrains Mono for a while. the 1/l/I disambiguation is solid and the ligatures are not too aggressive. recently switched a few terminals to Monaspace Neon (from GitHub) which has this subtle texture that’s easier on my eyes for long sessions.

the thing i care about more than people realize: how it renders on low-DPI monitors. some fonts that look great on hidpi look terrible at 1080p with no subpixel rendering. JBM handles this better than most.

for self-study without the academic context, i’d lean toward “A Common-Sense Guide to Data Structures and Algorithms” by Jay Wengrow over CLRS. it’s a lot more approachable and uses multiple languages including Python.

CLRS is the canonical reference but it’s dense enough that it can stall beginners. the Wengrow book gets you actually implementing things quickly.

if you’re specifically targeting Rust, the rust book has decent coverage of ownership-related patterns that affect which data structures make sense to use there vs other languages.

my experience has been similar for complex tasks but the sweet spot for me is small, well-defined scripts where i can verify the output easily.

like: i needed to parse some music metadata and normalize it across a few formats. gave it a spec, it produced something that mostly worked. i spent maybe 20 minutes fixing edge cases instead of 3 hours writing it from scratch. that exchange of time is what sold me.

for 3d math where correctness is hard to verify at a glance, i wouldn’t trust it either. the tool is only as useful as your ability to test its output quickly.

been working on a couple of side projects related to music + web. one is a chord/tab aggregator site that’s mostly automated content generation, the other is some python tooling for music data analysis.

if anyone is into music data or content-heavy static sites i’m open to chatting about it. always more interesting to build alongside someone even if the projects stay separate.

the robots.txt angle is interesting. legally it’s not binding but practically violating it can affect how courts view your conduct (vs. good faith compliance).

for public data that’s already freely accessible with no login, the case law is actually more permissive than people think — especially in the US after the hiQ v. LinkedIn ruling. the EU is more restrictive.

the music data use case you mention: scraping metadata (song titles, artist names) is different from scraping audio. metadata is generally considered factual/non-copyrightable. audio is obviously protected.

personally i’ve built some music tools that aggregate public chord/tab data. the legal gray area is real but the risk profile is different depending on what you’re doing with it.

made a tiny script that scrapes setlists from a site and builds a chord practice queue for me. basically: input artist → get top songs → look up chords → generate a practice list sorted by difficulty.

it is maybe 80 lines including the argparse stuff. never bothered to clean it up but it still runs fine a year later.

for breaking out of tutorial hell: pick something you actually want. if you’re just solving a generic practice problem you won’t finish it. a dumb personal itch is worth 10 todo app clones.