Fair point, I forget how utterly stupid businesses, particularly large businesses can get about boneheaded requirements that they mandate but do not use or do need, but could better solve it in a separate path rather than mandating it on what should be the 'wrong' product category.

Particularly surprising to forget since I'm basically continuously exposed to that in my job, but guess it eventually faded into the background of me not thinking explicitly about it anymore..

Problem with that is thinking it's vaguely new... This has been possible pretty much all along. The Cameyo demos I saw seemed underwhelming compared to almost every alternative I've seen...

Except it is a whole desktop, but with ability to request an app to maximize... It's kind of embarassingly bare bones for this level of claiming it makes ChromeOS just do Windows...

I certainly would agree with that direction, however this has been an option for an eternity and broadly hasn't moved the needle for Windows market share.

Once upon a time VirtualBox made an effort for this to work as a feature, and eventually dropped it in favor of just using Windows RDP to the same end. Doing it via a browser may be somewhat more convenient, but not fundamentally more accessible than RDP...

After watching a demo, I'd say this is in fact a step back from 'seamless' RDP, since you just get a web page with what looks like full-desktop RDP in it.

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...