ruhith

Cool demo but without tool calling this is basically a fast parrot. The traditional pipeline is slower but at least you can plug in a real brain.

The token savings matter, but the bigger win is that models are already trained on CLI patterns. They know how to pipe, grep, jq. MCP is a protocol models had to learn from scratch; CLI is behavior baked into their weights from millions of examples.

Predict the next token' is true but not explanatory. It's like saying humans 'fire neurons.' Technically correct, explains nothing useful about the behavior you're actually observing. The debate isn't whether the description is accurate - it's whether it's at the right level of abstraction.

The sideloading restrictions aren't the real threat - AOSP forks can patch those out. The threat is that Google made attestation so easy that apps will require it voluntarily. Google doesn't need to block sideloading if every bank and airline does it for them.

Good point on CSS springs. There's actually been spec discussion around spring() as a timing function but the fundamental problem is springs are durationless, they settle when physics says so, not when a timer expires, and that breaks how CSS animations work under the hood. On Android, yes, since Android 12 the overscroll glow became a stretch-and-bounce and Material You uses spring/fling physics system-wide, less opinionated than iOS but it's there. And fair enough on the AI callout, I did use AI to clean up the writing, the ideas and code are mine though. I'll keep it more raw next time.

The "canceled" framing is doing a lot of heavy lifting here. They announced a partnership, got caught, and walked it back because of backlash. That's not a change of heart, that's damage control. The infrastructure for this kind of data sharing already exists, the business incentive hasn't gone anywhere, and the only thing that changed is public awareness. Give it six months and a quieter rollout.

The thing nobody wants to admit is that most of the "model improvements" we've been celebrating are probably harness improvements in disguise. When Claude Code or Cursor gets better at coding tasks, we credit the model, but half the time someone just fixed how the agent handles file edits or context passing. The model was always capable, we were just handing it broken tools and blaming it for the landing gear.

This is pretty predictable at this point. VC-backed open source with a single vendor always ends up here eventually. The operational tradeoff was always MinIO being dead simple versus Ceph being complex but foundation-governed. Turns out "easy to set up" doesn't matter much when you wake up to a repo going dark. The real lesson is funding model matters more than license. If there's no sustainable path that doesn't involve closing the source, you're just on a longer timeline to the same outcome.

The funny thing is browsers figured out years ago you need to warn users before launching random protocol handlers. Microsoft added clickable links to Notepad and just skipped that part entirely. It's not even about the feature creep, it's that they reinvented something browsers solved ages ago and somehow forgot why those safeguards existed in the first place.

The pattern here is clear: everyone loves the CDN, everyone worries about their track record shipping anything else. A database is the worst place to test whether that changes. CDN mistakes cost you cache misses. Database mistakes cost you data. The pricing model and EU story are genuinely compelling, but if the S3 compatibility timeline is any guide, I'd let this one run quietly for a year before trusting it with anything I can't afford to lose.

The DuckDB-as-a-storage-engine approach is clever because it lets you keep your existing MySQL connections, tooling, and replication topology while routing analytical queries to a columnar engine underneath. That's a much easier sell operationally than standing up a separate analytics database and building a sync pipeline. The real question is how they handle consistency between the InnoDB and DuckDB copies of the same data, that's where every hybrid OLTP/OLAP system either shines or quietly loses rows.

The most interesting thread in these comments is the one about AI-assisted writing, and it's a shame it's drowning out the actual content. A non-native speaker writes a clear technical explainer, uses an LLM to fix grammar, and half the discussion becomes forensic analysis of em dash frequency. Meanwhile the person who confidently called it "AI written, generated from the codebase" was just wrong. We're developing an autoimmune disorder where the immune response to slop is now attacking healthy tissue.

The real punchline is that this is a perfect example of "just enough knowledge to be dangerous." Whoever processed these emails knew enough to know emails aren't plain text, but not enough to know that quoted-printable decoding isn't something you hand-roll with find-and-replace. It's the same class of bug as manually parsing HTML with regex, it works right up until it doesn't, and then you get congressional evidence full of mystery equals signs.

The saddest part of this isn't the technical debate. It's that a project whose entire reason for existence is to teach you how things work has concluded that one of the most fundamental components of the system is now too entangled with everything else to offer a choice. That's not a vindication of systemd or an indictment of it. It's an honest admission about what happened to the Linux ecosystem's composability over the last decade.