I fully anticipate there will be branding changes, like adding a '+' for rewards and consumers will learn fairly quickly that merchants frequently don't want to deal with the more expensive 'plus' transactions.

Can't blame them, your rewards points/cash back is just being charged to the merchant.

Or you just carry a couple of cards, one with no rewards that people will actually take, and maybe one or two with rewards that some merchants will still take.

The biggest thing to get right is some simple 'branding' so consumers actually know at a glance what cards might work or might not.

It's just bonkers that the credit card companies have basically made the merchants pay for the credit card companies to motivate cardholders to use the cards that merchants don't want them using in the first place. Those 'cash back' and 'rewards' represent some of cost of goods that a consumer can't really get away from without these measures.

It's right there in the summary, that merchant's would start being able to decline the credit cards with 'points' and 'cash back'. I presume this would come with some rebranding to be phased in, like 'Visa+' and 'Visa Business', with a lot of merchants refusing 'Visa+' just like they reject other high-fee cards.

Z-Wave v. Zigbee largely stemmed from some awkward licensing to implement Z-Wave.

I think the thing driving Matter-over-Thread seems to be a desire to have more commonality with IP stacks, notably Apple's Homekit not having the adoption Apple wanted and Apple deciding to maybe go with something that the device manufacturers will go for, but not wanting to have to have a totally different stack for dealing with Zigbee vs. wifi devices.

So here's Matter, based on IP, with endorsement of 'Thread' as one of the transports. Now talking to a Matter device over Wifi is pretty similar to talking to a Matter device over Thread, except Thread is not generally IP routing.

So Thread is an inherent mesh design, unlike Bluetooth or Wifi, and low power. Bluetooth kind of sucks for this application since it's peer to peer. Wifi somewhat better but it means you have to inject access points even if coverage could be had mesh-style, with a light switch serving as a perfectly viable relay while doing it's job otherwise. Also you have an actual shot of running a Thread radio on modest battery much longer than Wifi.

I think the woosh is directed the wrong way, the comment had an example of exactly and obviously useful data, so it has to be sarcastic.

"Matter-over-Thread" is actually a solid strategy compared to most 'cloud connected' wifi smart devices.

This is more akin to Zigbee/Z-Wave. It's a local, non-internet scheme for local communication and control. You can get a totally local air-gapped Matter over Thread setup running without internet. It's if you pick a cloud-connected thread border router when you get in trouble, but you can roll your own, e.g. with Home Assistant platform providing a way forward.

Elon just made a pertinent statement:
https://futurism.com/future-so...

Some possibilities:
-The agent buys the wrong thing and Amazon sees a substantially higher rate of returns or other bad customer feedback
-The agent buys one thing despite Amazon search results trying to push a different option
-Amazon's upsell for "you may also like" is tanked by the agentic purchaasing.

Don't worry, they are probably getting paid 300b by Oracle, 250b by microsoft, and 38b from Amazon so it all will work out nicely.

A lot of the deals lately seem to be company A and B pay each other X amount of money and pretend that is big revenue despite relatively little net money exchanging hands.

You could, in theory, have a context that is entirely within the sandbox and useful. Hence my comment about getting things in and out of the environment potentially negating many of the scenarios I can think of. But broadly speaking, if you had some local processing to do, you feed the environment a blob and the environment can now pretend it's a normal file as far as it is concerned, and then you can pull the blob out when done. WASM can't touch real stuff but you can feed it stuff within the reach of javascript which itself is still sandboxed, but specific network touch points and user indicated file touch points can be put in the reach of javascript.

So if you wanted to apply, in browser, some linux utility to a file, then the user has to indicate a file for operating on via browser, and that action allows javascript code to access that file, and with that granted it can load it into some memory that you've allocated for this purpose, and when done move the data back or wherever.

But the much needed sandbox does greatly complicate things and for some sorts of files the resource usage would be prohibitive in this scenario.

So I have had a few scenarios where I really didn't have any business moving data between the browser and a backend service and I would have just as soon done an operation client-side, but the ecosystem that was equipped to do the task wasn't exactly trivial to get to work in-browser. I could imagine some such use cases easier to port if a Linux instance could live transiently in browser runtime.

I've spent a fair amount if time trying to wrangle specific use cases into this scenario, but could imagine a 'lazier' way if a linux layer already abstracted away the browser runtime weirdness that many libraries aren't equipped to deal with naturally.

I think broadly speaking people that induce these requirements on my team are thinking the wrong things, and there's generally a smarter way to do it, but it does mean I get exposed to some weird use cases where a more traditional software interface is abstracting the browser-specific environment. Though I wager moving data in and out of the wasm may disrupt all the potential benefit...

I agree this is more like 'religion' than science, as it is not falsifiable, even if this 'proof' purports to do that. It's kind of a pointless exercise of no practical use, however...

But it isn't non-sensical. Because we would have no perspective to know about 'complexity' in absolute terms. We think quantum stuff is small and the speed of light is fast, but that's just because of what we possibly observe. If hypothetically a 3d engine were self aware, they may conclude that triangles are the impossibly smallest things, and some game engine limitations dictated some absolute limits to reality that the outside world sees as a significant simplification.

That's the thing, by definition in the hypothetical the computation device is *not* within the given universe that contains it. Again, if you look at some of these things like minecraft where they build logic devices, they are, in the scale of the target universe, impossibly huge because that's what the in-engine physics allow. So again, such a self-aware hypothetical would conclude that even a simple calculator has to be the size of a large building and mock the concept of a handheld device being able to simulate everything they observe despite us knowing that such a game engine is in fact on the easier side of things a handheld computer can do.

Which comes to another point, we have no absolute concept of time. If it takes the hypothetical higher order universe an hour to simulate a second of our universe, we'd be none the wiser. We do these sorts of things in simulation all the time, though we don't run it for long.

Also there's fact that we don't have any way of really *knowing* everything we think we remember and observe is substantially done at all. In Half Life in-universe they would perceive the phenomenon as some maddeningly complex physics stuff, because that's what the game engine presents. However we know that it's just "special effects". We think we have memory of many years and history of centuries, but a lot of games present themselves the same way, despite never actually *running* that material, just preloading the memory/history into the scenario. Any individual can only speak to what they see in that instant of time and can't know that there's really anything substantial directly behind them let alone light years away.

Trying to disprove is pretty much a waste because the goalposts can move freely.

Hey, if running on billions is good enough for Java, it's good enough for Chrome and Chrome-likes.

I think it was intended as a supremely milquetoast query that would have a search engine pretty much pop up a specific thing the user is after.

And the LLM first approach is *really* bad at that. If you are looking for an existing, canned piece of content, the LLM is a let down. A large chunk of what people want is an existing thing.

LLM as a readily available *option* for the sorts of inputs that it works with? Sure. As a replacement for internet search, not so much.

But the summary is misleading given the output from the calculator.

So the summary says 4k doesn't matter in the typical living room. Ok, if I look up a typical 4k living room set, the very cheap ones are about 43". I plug that into the calculator at 2m viewing distance (which seems pretty typical and it says 99% of people could tell that it wasn't full resolution.

So I look up 8k sets now and they seem to be more targeting 85" diagonal. Now don't know if I want to devote 85" to a TV, but plugging in 85" for a 4k shows it also is apparently distinguishable to 14% of the population.

Now if you have a 27" TV viewed from a couch, then absolutely none of this makes sense. But the screen sizes associated with the higher resolutions by their own calculator does make a perceptible difference, though subjectively I don't know that it should be reasonably be considered worth it.