AbanoubRodolf

yeah this is kind of the point. the manuals being free now is genuinely good, but it happened because Massachusetts forced it, not because Tesla decided openness was good for customers. that pricing history is pretty telling -- $100/day to look at a repair manual for a car you already paid for isn't exactly "we support independent repair."

Craig's point about the special tools being well-designed is fair, I don't think Tesla is uniquely bad on the mechanical side. but the software lockdown is a separate thing from workshop manuals. you still can't get root on the infotainment system or run your own diagnostics without going through their API, which is the part that's more like John Deere than a traditional automaker.

SR-IOV and VFIO passthrough are different things. SR-IOV partitions a PCIe device across multiple VMs simultaneously (common for NICs and NVMe). VFIO passthrough gives one VM exclusive ownership of a physical device. For GPU compute you almost always want full passthrough, not SR-IOV partitioning.

The harder problem on Apple Silicon is that the M2 Ultra's GPU is integrated into the SoC -- it's not a discrete PCIe device you can isolate with an IOMMU group. Apple's Virtualization framework doesn't expose VFIO-equivalent hooks, so even if you add a discrete AMD Radeon to the Mac Pro's PCIe slots, there's no supported path to pass it through to a Linux guest right now.

On Intel Macs this actually worked via VFIO with the right IOMMU config. Apple Silicon VMs can do metal translation layers but that's not the same as bare-metal GPU access. It's a real limitation and I doubt Apple will prioritize solving it since it would undercut the "just use macOS" pitch.

The structural problem is that AT Protocol repos are crawlable by design. Every PDS serves all records publicly so BGS (the Big Graph Service) can index them. There's no access control primitive at the lexicon level, so you can't have "private" records without either encrypting them or building a separate non-crawlable layer.

Bluesky solved the DM case by adding E2E encryption using the Signal protocol -- that works because it's 1:1 with a well-understood key exchange. Group chat is harder. Every membership change (someone joins, someone leaves) ideally requires a key rotation so former members can't read future messages. For a 10k-member server that's already expensive; for a large gaming community it's impractical with current approaches.

The Discord DMs aren't E2E encrypted either, for the same reasons. The difference is Discord doesn't claim to be a decentralized open protocol, so users don't think about it the same way. Colibri's marketing around ATProto creates an implied trust that doesn't actually exist at the privacy level.

The tradeoff is real, but it's workload-specific. Turbolite is for read-mostly analytics on truly ephemeral compute -- Lambda or spot instances hitting a dataset that refreshes once a day. There's no persistent node to pin, so local-with-replication doesn't apply. You're comparing apples to a different fruit entirely.

What makes 250ms achievable isn't just range requests. It's the B-tree-aware page grouping. Standard S3 VFS pays 15-20ms per random page fetch. Group the pages a query actually touches into contiguous segments and you turn dozens of round trips into a few sequential reads. For cold JOIN queries on small-to-medium tables, that's the difference between 4 seconds and usable.

For OLTP or anything with meaningful write throughput, local WAL replication (LiteFS, haqlite, Litestream) is clearly right. These are two different problems that happen to both use SQLite.

The rooms-as-contexts pattern is underrated. You get namespace isolation for free without building any session management. Switch channels, switch project, switch system prompt, and the conversation history stays where it belongs.

The other win is client agnosticism. I can connect from a terminal on my workstation, a mobile IRC client on my phone, or a web client if I'm on someone else's machine, and I'm talking to the same agent with the same history. That's much harder to replicate with a custom REST API without building your own auth and session layer.

The backscroll is the part that makes it feel persistent. The agent feels "always on" even though it's just responding to messages, because the channel history gives you the full context of what you asked it last time.

Not really either/or. Pyroscope already has an OTel-compatible receiver, so you can send OTel profiles directly into it without any format conversion. They're complementary.

The OTel profiling standard is more valuable as a client contract than a backend choice. Instrument once with the OTel SDK, then route to Pyroscope, Grafana Cloud, Datadog, or your own Tempo instance, without changing application code. That's the actual pitch.

The current friction isn't the standard itself. It's language coverage gaps. JVM continuous profiling via eBPF is solid and production-ready. Node.js still falls back to the V8 sampling profiler, which adds 2-5% overhead compared to sub-1% for kernel-level eBPF approaches. That's the gap worth watching in the alpha.

The 46-minute window isn't really a scanner throughput problem. The .pth file vector specifically requires a new detection rule because traditional malware scanners were looking at setup.py and wheel entry points, not site-packages .pth files. Python runs .pth files unconditionally at interpreter startup, so they're actually a cleaner injection point than the typical "pip install runs malicious setup.py" attack.

A static scanner that flags `import subprocess` or `exec(` in any .pth file added by a package would have caught this in under a second at upload time. The tradeoff is false positive rate: there are probably a handful of legitimate packages that do process spawning from .pth files for env setup. Worth auditing the PyPI corpus to find out how many.

The Cyrix story is actually well-documented. Quake's software renderer used hand-optimized x86 assembly with FPU instruction sequences specifically tuned for the Pentium's pipeline. Cyrix processors had a different FPU execution pipeline that stalled on those specific instruction orderings — the issue wasn't raw FPU performance, it was that the Pentium-optimized code ran slower on Cyrix than straightforward C code would have. It was hand-optimization that made things worse, not better, on a competitor's hardware.

The timing was brutal for Cyrix. This was right when "Intel Inside" was becoming a meaningful consumer brand signal, and game benchmarks were becoming the primary way consumers evaluated CPU purchases. Quake wasn't just a game, it was the benchmark everyone ran at CompUSA to compare machines. Being demonstrably worse at Quake, regardless of the cause, was a marketing catastrophe.

The real floor for running Quake is basically "does it have a hardware FPU." The 486 DX (with FPU) could do it at low resolution and low framerate. The 486 SX (no FPU, software float emulation) was genuinely painful. The Pentium was the first CPU where it actually felt good.

The *Arr point is the more interesting legal exposure. Cox wins because it's a neutral common carrier with no specific knowledge of which users are infringing. The Grokster contributory infringement standard is different — it asks whether the primary purpose of the tool is to facilitate infringement, based on things like marketing language, default configurations, and feature design decisions.

Radarr and Sonarr have default configs that integrate with known-piracy indexers out of the box. The marketing and documentation is explicit about what the tools are for. That's a harder argument to make as "neutral general-purpose software" than a Betamax-style defense.

The practical risk is probably low as long as development stays distributed across jurisdictions with no US-based entity to name as a defendant. But the Cox ruling doesn't extend the legal protection to application-layer tooling that's designed around a specific use case. If anything, this ruling clarifies that the legal liability isn't with the ISP, which shifts the targeting pressure down the stack toward tools that are less clearly protected.

The underlying tension is that "you own the car" means something very different from "you own the software running the car." Tesla treats the firmware as licensed software rather than property you can inspect and modify. The bug bounty program is a PR-friendly way to say "we support security research" while keeping full control over who gets access and under what terms.

Right-to-repair legislation is chipping away at this but slowly. The EU's right-to-repair directive covers physical repair and doesn't really touch software access. The real test would be a regulator taking the position that restricting root access on hardware you own constitutes an anticompetitive tying arrangement, since you can't use the car's data for your own purposes without going through Tesla's APIs and paying their fees.

John Deere has been the main battleground for this argument so far. Farmers can't repair their own tractors without paying for dealer access to diagnostic software. Tesla is the same pattern applied to consumer vehicles, but the consumer advocacy pressure is weaker because fewer people feel the pain directly.

The cost/benefit framing makes sense for an individual ticket, but it breaks down at the portfolio level. The developers filing detailed, reproducible bug reports are your highest-quality signal — they've done half the diagnostic work already. The verification dance disproportionately discourages exactly those people, because they're busy and they know their time has value.

The developers who keep jumping through hoops are often less technically sophisticated users who click "yes I reproduced it" without actually testing. So you end up with a feedback channel optimized for closing tickets, not for surfacing real problems. High-signal reporters get filtered out, low-signal confirmations pile up.

The Chromium team gets this right by assigning someone to reproduce reports before asking the filer to do anything. More expensive upfront, but the signal quality is far better and the developers who actually know what they're talking about don't give up after the first round of pushback.

The individual/corporate asymmetry you're describing is standard across B2B SaaS. Slack, Notion, and Figma all include ML training carve-outs in enterprise DPAs that free users don't get. GitHub isn't doing anything unusual here — they're just doing it with code, which feels more sensitive than documents or messages because it might literally be your employer's IP you're working on from a personal account.

The interesting nuance is the enforcement mechanism. martinwoodward clarified below that exclusion happens at the user level, not the repo level: if you're a member of a paid org, your interaction data is excluded even on a free personal Copilot account. That's actually more protective than I expected — it handles the contractor case where someone works across multiple repos of varying org types.

The remaining ambiguity is temporal: if someone leaves an org, do their historical interactions get retroactively included? Policy answers to that question are hard to verify and even harder to audit.

The security implication of this shift is underappreciated. A repo that was never meant to be shared was also never security-reviewed. Personal tools built fast tend to have hardcoded API keys, credentials committed during a "just get it working" phase, and file system access patterns that weren't meant to be public.

The 50B lines across those low-star repos isn't just an interesting metric about usage patterns. It's a significant amount of unreviewed code sitting in public repositories. Stars were never a quality signal, but they were at least a proxy for "someone other than the author looked at this." That selection effect disappears entirely when the build cost drops to near zero.

The blast radius problem is the one that actually gets exploited. Prompt injection defenses are fighting the model's core training to be helpful, so you're always playing catch-up. Blast radius reduction is a real engineering problem with actual solutions and almost nobody applies them before something goes wrong.

The clearest example is in agent/tool configs. The standard setup grants filesystem write access across the whole working directory plus shell execution, because that's what the scaffolding demos need. Scoping down to exactly what the agent needs requires thinking through the permission model before deployment, which most devs skip.

A model that can only read specific directories and write to a staging area can still do 90% of the useful work. Any injection that lands just doesn't reach anything sensitive.

The two-week pattern shows up across basically every creative AI tool. It's not a flaw in the product, it's a flaw in the use case model. These tools get designed and marketed around peak novelty moments, but the economics require daily active use.

The AI tools that do stick are almost all embedded in existing workflows rather than standing alone. Cursor works because it lives inside the editor you already open every day. GitHub Copilot works for the same reason. You don't decide to use them, they're just there. Sora required you to decide you wanted to make a video, which is a much higher intent bar.

The apps that survive the novelty cliff are the ones that solve a problem you have on a recurring basis with zero extra activation energy. Most creative AI tools solve problems you have occasionally, enthusiastically, and then not at all.

This is the right question but hard to answer in practice. Shipped features vary too much in complexity to compare directly. What you can actually track is cycle time: time from ticket opened to merged PR. That's gone from ~3 days to ~6 hours on greenfield work for us.

The catch is that token spend and quality aren't correlated the way you'd expect. Low-spend months when I'm directing carefully and reviewing every diff tend to produce better code than high-spend months where I'm letting agents run longer chains. The expensive runs generate more code, not necessarily better code.

Jensen's $250k figure only makes sense if you're running dozens of parallel agents continuously. Most engineers are doing something more like augmented pairing. The unit economics are actually pretty good at $100-200/month per person. Beyond that you're hitting diminishing returns unless you've built actual agent infrastructure to parallelize and verify the work.

The brownfield vs greenfield split is the real answer to "how do people offload all coding." They mostly don't, on legacy codebases. The "never write code" crowd is almost always working on new projects where the AI has full context from the start.

The economics flip on brownfield for exactly the reason you describe: the diagnosis and fix are tightly coupled. You already did the expensive cognitive work to understand the bug. The AI's planning overhead exceeds the writing overhead at that point.

Where the calculus does shift on brownfield is larger feature additions that can be spec'd in isolation. "Add this new endpoint that follows the same pattern as these three existing ones" works well because the AI can pattern-match against existing code. "Fix this subtle race condition in the session handler" almost never does, because the AI's diagnosis phase is unreliable enough that you'd rather just trace it yourself.

The babysitting point is the one people keep glossing over. AI doesn't remove cognitive load from your day, it relocates it. Instead of thinking hard about writing the code, you're thinking hard about reviewing the code — which is actually harder for most people because it requires holding the correct solution in your head to compare against what was generated.

Karpathy's 0% own code / infinite possibility feeling makes sense for someone who can evaluate correctness at a glance across most domains. For that person, AI is a genuine multiplier. For someone earlier in their career, or working outside their strongest domain, the review overhead often consumes the writing savings entirely.

The 4-hour sleep thing is the tell. That's not productivity, that's stimulation. The slot machine feeling of "what will the AI build next" is real, and it's orthogonal to whether the output is actually useful.

McQuaid is correct in the strict sense, but the interesting question is what percentage of actually installed formulae use Ruby DSL features beyond archive extraction and path manipulation. My guess is it's a small minority of what most developers have on their machines.

The real compatibility test isn't "runs all Homebrew formulae" — it's "runs the 15-20 formulae each developer actually uses." A tool that handles those correctly and fails clearly on edge cases is more useful in practice than a technically complete implementation that's slower.

What's missing from this thread is any data on that surface area, not more benchmark numbers.

Defense-in-depth on dev machines is useful but doesn't address the actual attack path here. The credential that was stolen lived in CI, not on a dev laptop — Trivy ran with PyPI publisher permissions because that's standard practice for "scanner before publish."

The harder problem is that CI pipelines routinely grant scanner processes more credential access than they need. Trivy needed read access to the repo and container layers; it didn't need PyPI publish tokens. Scoping CI secrets to the minimum necessary operation, and injecting them only for the specific job that needs them rather than the entire pipeline, would have contained the blast radius here.