4 ms·
> Samsung Smartthings hub that has to offload even simple things to the AWS cloud Doubly disappointing considering how much money Samsung has sunk into Joyent
by microcolonel 7y ago
> Samsung Smartthings hub that has to offload even simple things to the AWS cloud
Doubly disappointing considering how much money Samsung has sunk into Joyent (though maybe it's not the same division of Samsung, and that's why they don't use it).
> RISC-V could make the market for embedded chips competitive again. RISC-V scales even more than the 360 did since you can put in just the features you want, thus you might be able to build something which is high performance but doesn't waste a transistor on features you don't want.
Crucially, I think, it lacks any unusual or frivolous features, so it is virtually free of surprises. For example, it's little endian because little endian won (because it is better).
- PaulHoule 7y agoOn some level i don't mind aws, I have a bastion in us-east-2 and it is only 35ms away. Still, it adds to the Rube Goldberg aspect of my smart home that the route between my light switch and my light goes through Ohio. My practical beef is that if the net goes down, things stop working. Also it looks as if AMZN is cloning the SmartThings infrastructure, learning from the mistakes that SmartThings made earlier.
- MayeulC 7y agoThat's an interesting take on the subject. Personally, my "smart" appliances run on a closed Wi-Fi network, disconnected from the internet (the access point is a raspberry pi, which itself is connected to the rest of the network). I wouldn't trust any of these not to phone home, and everything can work offline if needs be. I tend to prefer open-source compatible solutions (such as broadlink devices with python-broadlink), but my understanding is that the Amazon ecosystem is a closed "walled garden" one. Are you confident enough in Amazon to trust that your products will continue working in the future? Are you really willing to lose your lights in case of an internet outage?
- MayeulC 7y ago> For example, it's little endian because little endian won (because it is better). Could you elaborate on this? My understanding is that Little Endian was introduced to enable some optimizations on low-level mathematical operations or fetch operations. However, as the block size for ram operations increased, together with the transistor count, it was IIRC shown (I can't find a reference) that there were little advantages in using one or the other (different optimizations being possible in either). I tend to prefer Big Endian, as it is closer to our numerical representation, and the network order. Saying that Little Endian has "won" could be justified if you only look at x86, but I wouldn't call that the whole story.
- microcolonel 7y agoI used to like big endian for the same reason (that it seems more similar to our written numeral conventions), but little endian allows you to narrow and widen integers with no operations, and without changing the pointer. That's why it's better in my view.