The food delivery vehicle was on the pedestrian path where the pedestrian wanted to be. Why didn’t it turn around and go another way? That is what peole do when sidewalks are jammed up by whatever event might be happening. Was she following it around and blocking it from every direction? Making contact in any way? Go back across the street and get on with it.
These things are pretty big and Philly sidewalks are narrow enough with just regular pedestrian traffic. Incidentally, I’ve only seen these things in relatively high-foot traffic areas too. This is just tech companies seeing what they can get away with, as usual.
You might support it if you were a food delivery worker, or someone else whose jobs are at immediate risk from automation. Or if you had any empathy for those people.
That can be said about any job that gets automated, ever. Unless you as the one bringing along more efficiency are willing to share the fruits of that increased efficiency with the people you're displacing, they will demand you halt progress, yes. It's shocking, but most people aren't very fond of becoming homeless or starving. There's a world where efficiency gains benefit us more evenly, but it's not the one we live in. So of course the best play for the common worker being automated away with nowhere else to go is to reject it as much as possible.
A job is bullshit if it's wasting resources duplicating the work of a machine without good reason. Replacing excavators with teams of shovelers would be a bullshit job, but the same job wouldn't have been bullshit before excavators.
This is largely a myth. Both unauthorized ACH debits and debit card payments can be disputed, and accountholders have a legal right to do so (Reg E) just like they have for credit cards (Reg Z).
The only difference is that you're potentially out your own money, but with credit cards you're also out of credit until the dispute is resolved, and you can have multiple debit cards and checking accounts just like you can have multiple credit cards as a backup.
The fact that someone has "a legal right to do" something does not mean that realising that right in practice is fast, easy, or even possible.
I'd rather not be in the situation where I have to realise my "legal right" to ACH chargeback — which will involve hurdles, wasted time, and probably also legal fees — by not giving anyone the authorisation to perform ACH pulls in the first place. Cash works best for this — you're never out of more than what you hand over — but Apple Pay gives me similar protections.
> The fact that someone has "a legal right to do" something does not mean that realising that right in practice is fast, easy, or even possible.
The legal right to have unauthorized payments returned is ultimately backstopped by law. This is the case for both credit and debit cards. That (and scheme rules) is the reason you don't have to shop for the "most chargeback friendly card" or similar.
> Apple Pay gives me similar protections.
How does Apple Pay factor in here? It's just a different way of using your existing credit and debit cards, with exactly the same dispute protections.
In theory; in practice, one reliably and repeatably works, and the other I'm not sure (and not willing to find out.) I've had some experience with stolen checks; while the money has been ultimately returned to me, it was a major hassle, and cost me several sleepless nights.
> How does Apple Pay factor in here?
Apple Pay gives the merchant a generated CC number (per-card, per-device) with a generated one-time security code (for every single purchase.) If the merchant is breached, all the hackers are getting is a generated CC number and a (expired after single use) security code, so they can't charge my Apple Pay card at all — and of course not my real card (which has never been exposed to the merchant to begin with.) The easiest and fastest chargeback is when there is no charge!
> one reliably and repeatably works, and the other I'm not sure (and not willing to find out.)
But that's exactly my point! People perceive credit cards as safer and don't try anything else, so the perception remains prominent.
It's just a regular trust bootstrapping problem that could only be solved by powerful market players breaking the cycle, and it seems like there isn't really appetite for that in the US.
> Apple Pay gives the merchant a generated CC number (per-card, per-device)[...]
Ah, yes, it does generally protect you from merchant data breaches. But your original point, "you're never out of more than what you hand over", is not quite true – the original merchant can post some subsequent charges on Apple Pay as well without you having to accept anything on your phone.
> trust bootstrapping problem that could only be solved
Onus of proof is on you that it needs to be solved, as the alternative exists and is working well. Think of it this way: I have my trust in US dollar (because everybody else has it too); maybe I could give the same trust in Swiss franc, or Emirati dirham, or South African rand — but why would I? US dollar already gives me everything I need.
> it does generally protect you from merchant data breaches
And from rogue merchants, too.
> the original merchant can post some subsequent charges
This has never happened to me; however my original point is that Apple Pay gives me better protections than regular CC, and it was given as a response to your point of "exactly the same dispute protections". Apple Pay is better since using it leads to fewer disputes in the first place; once the dispute is happening, the protections might be the same.
> Onus of proof is on you that it needs to be solved, as the alternative exists and is working well.
They are incredibly expensive. I think that part should be solved.
One obstacle on the way there is this perception that everything else is worse in terms of risk to consumers. A lot gets bundled up in the US to yield this common perception of "credit cards good, everything else bad".
>> > the original merchant can post some subsequent charges
> This has never happened to me;
I've rented cars, paid gym subscriptions etc. with Apple Pay. I can assure you merchant initiated charges are possible.
It doesn't have to be malicious. Some bug in their software causes them to withdraw all the money in that account, and you're SOL until that gets fixed. The amount of hassle on your end when they're not even going notice isn't worth the convenience, imo.
Even just assuming it's actually that easy and fast (I have my doubts), so for two weeks you have no money. All your bills to get paid don't get paid. You can't pay for food or anything. Hopefully it didn't happen when rent was due.
That doesn't sound like a huge PITA to you that could just be avoided by not giving them that access in the first place?
> All your bills to get paid don't get paid. You can't pay for food or anything. Hopefully it didn't happen when rent was due.
What's the difference between that and somebody's only credit card getting maxed out by fraudsters? They also can't use it until they receive a provisional credit by their bank.
If your point is that a credit card separates rent from other payments, nothing is stopping you from having multiple checking accounts either.
Your bank's fraud department and your credit card's fraud department are different teams and because credit card fraud is a much more well known problem, that department is better and more quickly able to deal with the problem. In my world view, anyway.
I don't doubt that that's the case in many banks, and there are probably also huge differences across banks, just like with other aspects of customer support.
The takeaway for me would be "don't bank with a customer-hostile bank", though, not "hope that the credit card department of your bank is better than the average of the bank".
It's obvious pretty quick that you use the prediction line to inform what to do on the next pass, and you have to time it. It would be too easy if it was just "wait for the projection to point at the other player and hit fire".
Being able to shoot the other player is a minor quibble for this kind of web minigame. It's still fun and interesting.
this guy gets it! as I mentioned in another post, yes the trajectory line is instantaneous, and you need to rely on your internal electrical meat estimator to predict how that trajectory evolves.
AI is a threat if you're a messy codebase, an unsolved math problem, or cancer. Otherwise you only have an improved quality of living to look forward to IMO.
Why would I ever do that to myself? My experience with Codex/GPT is fantastic, while my impression of Claude/Opus is that it's longwinded, patronizing, token-inefficient, stops to ask stupid questions every other minute, overcomplicates simple tasks, often poor engineering overall. I don't use it but this is what I see my partner run into who has access to both and compares them often. She has the same assessment.
Cuz OpenAI has been secretly downgrading models on many accounts, including mine lately. I paid $200 a month since like gpt-5.4, and since Astra released I found the model is somehow acting strange, it is until I checked X I have discovered that OAI is giving Luna level models when I am requesting Sol/Astra, or some piece of s** that is even worse than Luna. I basically had to ran every session with a Pelican test to determine if that session is safe. So I just spun up my Claude $20 and figured that now I can get all the work done just with Opus 5. Let me show you a pelican, by "gpt-6-sol". Cutting usages is one thing, but secretly downgrading models to a level that is not reliable anymore is the last straw. I am not saying other frontier labs (I am talking about you Anthropic) isn't doing this, but their version of downgraded/quantized/reduced effort model is at least usable, probably just slightly dumber, OAI's differences is day and night. https://imgur.com/a/PDbYdOQ
Somehow this just hasn't happened to me. I use Astra on high all day for fairly intensive game dev tasks, sometimes cranked up depending on the task.
I have heard ultra thinking might delegate to worse agents for some of its sub-tasks, but I don't use that much anymore since Astra came out. Just high seems good enough to throw most laundry lists at.
It feels goalpost-movey to downplay exploring a large search space efficiently in regards to "intelligence". If we dug into a human genius's brain and found it was somehow trying out a million ways to solve a a problem at once, no one would seriously suggest the person isn't actually intelligent.
And our brains must something like that at some physical level. You can't have a "turtles all the way down" of reasoning - the building blocks must be simpler. It must reduce to something like pathfinding and brute force at some point, weighted by factors in the system and maybe some randomness.
We have a romantic view of intelligence, perhaps stemming from intuition within the context of scientific discovery. Given enough intelligence, and enough context, a brilliant person can have a stroke of inspiration that allows them to make a major leap (a-la General Relativity or Fermats last theorem). We haven't seen THAT same capacity from a machine, but we see the more ordinary, unsexy grinding type of progress that represents 99.9% of scientific reality.
I would find it very interesting to train a model on information only available prior to the discovery of e.g. relativity or calculus and see if it can invent it. My intuition is that modern frontiers absolutely could. Not to take away from their brilliance, but Newton and Einstein were brilliant people who also happened to be in the perfect place at the perfect time - there's not so much "low hanging (i.e. approachable by one brilliant individual) but immensely valuable fruit" anymore.
Is there truly anything new under the sun? Hasn't all of existence alway been here? All math, all physics? We could have merely discovered it. Intuition might be nothing more than combinations of what already exists rather than some sort of divine insight that unlocks previously unknowable mysteries.
Agreed. I don't believe intuition and creativity would be more than pattern recognition, remixing ideas, and trial and error combined with a kind of "genetic algorithm" approach if you deconstructed them into what the brain is actually doing.
Bluetooth is slow. The transport is 3Mbps at max, if you subtract all the headers from different layers, you may have like 1.5-2Mbps practical transfer speed.
And harm a lot too, you phone can't deep sleep since it has to wake up periodically to process data from bluetooth stack. Combined with slow transfer speed, that gonna eat your battery like nothing.
Playing audio over bluetooth also wakes things periodically, but it uses almost no power. With a similarly competent design photo transfer should be very battery efficient.
No, most(if not all) bluetooth controller has audio offload, basically the cpu does not involve(or very little) when transfering data from storage to radio.
Don't you mean yes bluetooth controllers have audio offload? "similarly competent design" means you do the exact same thing in the other direction. Instead of rarely waking up the CPU to coordinate sending, you rarely wake it up to coordinate receiving.
You would often not have wifi available, and you wouldn't want to have to type in wifi passwords to your camera all the time. But your phone will almost always be nearby and persistent bluetooth is easy.
Problem is they have to disconnect from the current wifi ap to connect to the cameras ap which is inconvenient and means there can’t be a constant connection.
Wifi NAN could be used to solve this problem but I’ve not seen anything using it. Apple only just added support last year though.
I tried fd but it seems to ignore so much that it's basically useless. If I wanted `git ls-files|grep` I would `git ls-files|grep`
yells at cloud
..it's probably ok actually and I should give it a real go, but I'm too used to find and even have a keybinding in my ~/.inputrc to insert a find + where loop
"\e\C-f": "find . -type f -print0|while read -rd '' f; do ; done\e-b\C-b\C-b\C-b\C-b\C-b\C-b"
(yes I know about -exec; I find the loop easier to work with)
Humans have been hand-crafting artisanal test cases of equal banality for years, often to meet some metric no one is verifying deeper than an automated report etc. I'm more inclined to believe the null hypothesis here, that the formula doesn't need any change and the signal is still equally valid. If anything changed, the signal is probably more useful now, since you'll never catch a good AI writing test cases that do literally nothing except call a function in a try catch with an empty catch block. (Models may have done that a few years ago but I haven't witnessed that behavior in a long time.) I've witnessed myriad examples of this in pre-AI production code.
As a programming lead on a hobbyist video game project, we're reaping massive rewards being in category #1. I keep the architecture and important details in check while letting frontier models go ham. As alluded, it's a video game, not a life support system, so bugs are low-impact. But even better, the defect rate is actually the lowest it's ever been. Insidious bugs baked in by years of accumulated human error are trivial for Sol or Astra to untangle. This is the best time to be alive so far if you enjoy hobby game dev.
I've found the same, the rate of bugs has dropped pretty dramatically after switching to ai generated code. I think it's partly because ai will write 1000s of lines of unit tests without complaining. I also have a github workflow where claude runs the /code-review command on every PR.
In the world of web apps, I find the agent's ability to write good e2e tests to be a real game changer. Turns out with enough rigor you can write pretty stable mostly not flaky e2e tests. And even flaky ones are fixed quickly due to a fuck ton of assertions at every step.
Test code looks like a mess, even more than the usual LLM code. takes a while to let it go. Test report looks beautiful though.
When the test code "looks like a mess", how do you get assurance it is testing the right properties?
Like you, I've found that LLMs can improve test coverage by decreasing the amount of developer time spent writing tests. But generally, it takes a lot of manual work to set up the initial testing framework, and even then, a lot of vigilance to ensure that what is actually tested corresponds to the description of the test.
I feel weirdly stuck on both sides of this. I haven't been in a full-time "code writing" roles for years, so my own personal usage of LLMs for anything is roughly nil right now, just because I continue to be able to get done all tasks I wanted to get done in the time I have using tools and techniques I already had available, and have seen little need to adopt new ones. The exceptions have been around things like using the text interface for diagramming tools to at least get the initial scaffolding set up without having to learn the specific quirks of that tool, then spending maybe an hour or two at the end to clean up and make it look nice and ensure it's actually coherent and has no mistakes. This is a task I have to do maybe two or three times a month, so it isn't a huge win, but it's not nothing.
But that's digression. The short of it is I've seen enough to convince me these tools may as well be magic and a whole lot of tasks that break down into "produce media content of some sort" that has a well-defined goal and definition of correctness will be permanently sped up by automation. This includes a lot of software writing. At the same time, I shared the skepticism of estimates of economic impact and irrevocably changing the larger world. I'm a lot closer to the business side of the house these days, working with customers and prospective customers to identify use cases, reference architectures, pain points, feature requests, and bring this back to the development teams to attempt using real-world experience like this to inform how we design products. It's not product management as I'm focused more often on the nitty gritty technical details, not high-level user experience or roadmaps. But it gives me a great avenue into seeing what causes organizations to actually buy and/or adopt new software products, and the rate at which they can do that.
And frankly, it isn't moving the needle much. They have the same budgets they always had, so they're not buying more, and our business is growing, but no faster or better than it grew before agentic coding became a thing. I always wonder because it seems the glowing success stories on Hacker News come in one of three varieties. It's the solo indie dev, usually targeting mobile app stores, who churns out dozens of roughly "will compile and doesn't immediately crash at runtime" apps in the time it used to take to complete one. It's the hobbyist, making software only they and maybe their immediate friends will ever use. Or it's startups, whose monetization model isn't monetization at all; it's just having something shiny to show investors in order to convince those with loose money to give enough to you personally that you can build up a nest egg whether or not your product ultimately ends up ever having a single paying customer.
In my own business, a multi-decade, mature but not hyperscale company selling overwhelmingly self-hosted enterprise open source software, I can see the impacts on output. We have the same major products with the same release cadence. Each point release averages more new features than they used to, but also more regressions. It's overall a mixed bag. Non-technical product management staff is able to contribute code. We have a ton of new internal tools that nobody uses but they're there now. On the customer side, those that hinge decisions on wanting features that didn't exist yet are benefiting from getting those. Those that already had the features they want are losing from the greater rate at which regressions get through. The net business impact seems to be things have definitely changed qualitatively, but in purely financial quantitative terms, things are about the same as they were before. More code being committed to various git forges, but same headcount, same revenue, same margins, and same market cap.
reply