The right way to do this is to create an API or MCP or whatever catering to bots, and implement corresponding terms in your legal agreements (i.e. after approving a bot to interact with us, you're responsible for purchases it makes), along with some limits to prevent runaway shopping when Muse decides to binge.
Less friction = more shopping = more profits.
That used to be a concept companies like Amazon understood well. (As well as companies like Google in the context of web browsing and keeping it user-friendly as opposed to user-hostile).
If the bots mean customers are getting a better deal elsewhere, then you're doing something wrong elsewhere in your business model and need to go address that. Or eventually free market economics will, no matter how big an artificial moat you try to build.
maybe agentic commerce will finally realize the micro-payments based internet that crypto people had been wishing would happen for years? Should there be stablecoin based micropayments built into MCP to charge for agentic interactions to replace the micropayment of an ad into someones eyeballs?
The AIs are also providing the product suggestions, and it comes from what data they are given from their searches. I think they can put 2 and 2 together on how to make that happen with the right MCP response bodies.
As someone who doesn't have kids and was last in school decades ago....
Do those School Learning Management Systems tell you everyday what homework your kid is expected to complete? Do you feel such a granular degree of monitoring and direction has impacted your child's opportunity to build character, intrinsic responsibility and self-management skills?
When I was a kid, teachers gave out assignments, and the student was responsible for keeping track of them, staying on top of progress, and handing in by the deadline. If a problem arose that wasn't an isolated incident or resolvable directly between the student and teacher, the feedback would flow at a much higher level e.g. scheduled parent-teacher interviews or via a phone call.
And what do parents do who don't accept the terms and conditions of said educational platforms? (e.g. due to overly broad privacy clauses or one-sided indemnities and the like)
But nowadays kids are expected to check 2-4 platforms plus their notes and there is no guaranteed time when they know it will be there. It is like the worlds worst paid disfunctional work place and one of my kids schools literally uses teams for one third of their assignments. In word format so sometimes kids overwrite it.
If you don’t accept the terms your kids life is just even harder.
I don't fully understand the source of the "total bytes" constraint, but a major factor may be because HBM4 / HBM4E can only make use of the footprint directly above the processor/logic die (or in direct vicinity of its interconnect), while traditional DRAM can be placed further away where there's lots of real estate on the motherboard.
I gather a practical max ceiling today is a stack of 16 chips in height yielding 64GB?
These chips have a massive bus size of 2048 bits, instead of the 64 or 128 bits (dual channel) used by DDR5. That's what gives them their order-of-magnitude bandwidth speedup. But even though they technically pack in more capacity per square millimeter of motherboard, I gather they take up more space than older technologies once you account for the vias and interconnects to route all those signals.
Thanks for that, just went down an interesting rabbit hole. Many of us were hoping this re-tooling would eventually trickle some fast RAM down to DRAM-exhausted PCs, but given it would require a rearchitecture of the motherboard it's unlikely.
HBM4 has over 2048 signals to the processor’s PHY with tight signal integrity requirements that require the HBM stack to be < 0.5 mm from the processor die. That’s why HBM integration is done with interposers (soldered on the package). So, it’d be the CPU package that integrates it. Motherboard is too far away.
Kind of seems like we should be making chips with both. Big HBM stack on top as a sort of huge L5 cache like thing. And then a bunch of DRAM type sockets (like LPCAMM) around the exterior.
For chips with integrated CPU+GPU+NPU, it could be worth it tech-wise. The GPU and NPU can eat HBM bandwidth. For general purpose CPU code, the HBM would likely not be worth it. It's high bandwidth, but you trade latency, and general CPU code is branchy. Economics-wise, the HBM stacks alone will cost more than a consumer CPU (or APU).
[edit] The packaging needed to support HBM is also much more expensive too. If demand for current HBM applications tanks and the manufacturing lines need filled, then maybe. Currently, the price point would make it very very niche.
The RP2350 is Raspberry Pi’s dual-core microcontroller: each processor socket can select either an Arm Cortex-M33 or a RISC-V Hazard3 core at boot.
Does that mean there are four cores on the die? Is there crazy amounts of MUXing going on? Does the extra, semi-unused area give the chip a premium price tag? Or did I misinterpret this?
Yes, four cores in the chip. And yes, there's additional muxing, but I think that adds a fairly small amount of chip area compared with the crossbar. In addition to the two core slots, there are a lot of peripherals contending for single cycle bus access.
Yup, four cores. No crazy muxing needed because only one kind is ever active at a time and the other kind kept in reset, so there's no need to do any runtime arbitration - basically just a dumb switch on few dozen signals.
The bonus RISC-V cores take up basically zero additional die space: for the RP2350 the lower size bound is the space needed at the periphery for connections to the outside world, and (unlike something like SRAM and analog IP blocks) logic is not too difficult to rearrange or even compress.
This is the kind of thing that tends to start as an engineer joking about having enough spare space to fit in their toy RISC-V core, and then actually doing it. Run out of space during development? Just delete it, it's only an unexpected bonus feature after all. It causes issues during testing? Permanently fuse it off and nobody will notice it was ever there.
High-end chips are filled with dozens of "chicken bits" to gate off functionality they might not be able to get to work properly, so in a small company like Raspberry Pi it probably wouldn't be too hard to convince management to take the tiny additional risk in return for a significant PR possibility.
reply