jbotdev

I think speed is actually going to be a bigger factor than cost. Even projects where “money is no object” often hit a wall with LLM response times.

Sure you can speed things up with parallel work under subagents, but as with parallelizing traditional computational tasks, there are diminishing gains.

I keep hearing people saying just change the way you work to trust long-running agents and multi-task more, because they’re too slow to work with interactively for many use cases. I think that’s painful in a world where we expect humans to still heavily guide and interact with agents for their day-to-day work.

I’m not sure an “objectively great” feature exists, because “great” is such a vague and subjective term.

I think it’s more productive to discuss it in terms of the use cases and who they benefit.

I get it, he’s trying to do everything in software (with the existing cameras), since software is “cheap” and can do anything in theory.

Unfortunately they keep showing how they’re in over their head with some of these features (like FSD). But it’s fine because their customers agree to keep beta testing while they figure things out on production cars.

Just like “this is the year of the Linux Desktop”?

I’d love to have an open non-profit alternative to Google’s productivity suite, but realistically it’s very hard to host those things outside a traditional for profit business. Building the open source software is the easy part, and has been done already. The hard parts are things like email deliverability, and getting people to pay for what’s typically a free ad-supported service.

Part of my point is the goal with such a system is usually to require less infra work/knowledge from your devs, but it backfires if you don’t invest enough in your abstraction.

The implicit goal of these abstractions is really to central knowledge and best practices around the underlying tech. Kubernetes itself is trying to free developers from understanding server management, but you could argue it’s not worth using directly vs. just teaching your devs how to manage VMs for the vast majority of organizations.

I don’t think you’re ever going to stop more and more layers of abstraction, so the best we can hope for is they’re done well. Otherwise you may as well go back to writing raw ethernet frames in assembly on bare metal.

It seems like they’ve gotten to the “holy grail” of deployment where developers don’t have to worry about infrastructure at all in theory.

I’ve seen many teams go for simple/leaky abstractions on top Kubernetes to provide a similar solution, which is tempting because it’s easy and flexible. The problem is then all your devs need to be trained in all the complexities of Kubernetes deployments anyway. Hopefully Uber abstracted away Kubernetes and Mesos enough to be worthwhile, and they have a great infra team to support the devs.

I think you’re confusing Progressive Web App (PWA) with Progressive Enhancement. PWA is basically a web app (typically an SPA) that behaves like a native app, as described in the MDN page they reference. Loading progressively such that the page is still useful without JS is Progressive Enhancement.

The post glossed over how exactly they detected session hijacking. They mentioned “This detection looks for suspicious sessions appearing without an authentication event that are consistent with session hijacking.”, but authentication obviously happened at some point, otherwise the session wouldn’t exist. I’m guessing this is a complicated way of saying the IP changed since login.

Of course the easiest solution is you shouldn’t voluntarily share HAR files for an active session.

It’s weird to complain about supporting AEG claiming they’re somehow the 2nd “monopoly” after LiveNation. You can only have one “monopoly” in a given industry, otherwise they’re both just close competitors.

Having a close second competitor is still a step in the right direction, even if you disagree with their business practices.