Maybe this could be a new take on "a modern pocket calculator has far more computing power than the moon landing systems in '69". A modern lavalamp has as much computing power as my mid 90s desktop PC.
You also say you are "playing video games on my playstation" which doesn't make much technical sense, so clearly appeals to common idioms aren't without problems.
In any case, the argument is that the mini console they built is no longer a lamp, not that you can't play games on a console.
Ehhhh. Those things are meant to plug right in. I've never had to solder together my own breakout board and carrier board to hook a Playstation up to a TV while breaking the Playstation's main features in the process. That lightbulb is completely disassembled and won't function as a lightbulb anymore. And nothing they added was plug-n-play.
Edit: It's still a fun and cool project. But more like running Doom on hardware salvaged from an IKEA lamp.
Still the original Doom features are all there, except multiplayer. They also restored some missing graphics features of the GBA port, like z-depth lighting.
Yes 4MB vs 108kB is more impressive than 256k vs 108k, but cutting in half the memory requirements is still notewhorty.
I think that the goal of the project is not "Doom running on a 40-Cortex M4" (actually an 80 M33...), which is pretty easy I guess, but "Doom running with only 108 kB of RAM", while keeping all the features (which is pretty hard, I guess). I recall that I had to bend over backwards to get it running on my 386 with only 4MB RAM.
The game is cheating a little bit, since it loads a lot of read-only data from external SPI flash memory, and all the code is in the internal 1MB flash. On your 386, everything including the OS had to fit on that 4MB RAM.
It also doesn't have quite all the features. No music, and no screen wipe effect (I worked on a memory constrained Doom port myself, and that silly little effect is incredibly memory intensive since you need two full copies of the frame buffer)
I think it's fair to say they're playing Doom on the lamp (and even more impressively, it's not a whole lamp, but just a light bulb!). They use an external keyboard, monitor, speakers, and storage for the game data, but the processor and RAM are from the original bulb.
If someone said "I'm playing Doom on my PC" in 1993, they would also have been using an external keyboard, monitor, and speakers. And the game would have shipped on external storage (floppy disks).
Maybe in your language, but looking at my English dictionary it clearly says a lamp is a device for jibing light consisting of a bulb, holder and shade.
Historically a lamp would consist of the wick, oil and holder.
From wikipedia (Electric light): " In technical usage, a replaceable component that produces light from electricity is called a lamp."
EDIT: Yes, later in the same page: "Lamps are commonly called light bulbs;"
"In technical usage" means that this level of nitpicking isn't really accurate. When you say "they ran doom on a lamp" that isn't a piece of scientific literature. It's just conversational English and as such using the common dictionary definition of the word lamp as opposed to a technical definition is entirely appropriate.
Thanks for the reference. I’ve pondered this for many years in the context of sports teams. If you can replace all the players, owners, coaches, logo, stadium, etc.. what are you really a fan of?
Back in the 80s/90s there were some questionable ports of TeX do unlikely hardware. Perhaps the most egregious of these was TeX running on a Cray supercomputer. Time on these machines was metered heavily. I can't imagine anyone actually used it for formatting papers. I had a dream of doing a hand port of TeX to 6502 assembly to see if I could get it running on a 128K Apple //e. I envisioned heavy use of bank switching to enable code to jump back and forth between the two 64KB banks which could only be switched in predefined blocks as I recall (the page 1/2 text/lores blocks, page 1/2 hires blocks, the high 16k and I think the low 48k that wasn't part of the lores/hires blocks but it's a long time since I played with that hardware.
By today's standard Doom doesn't need much processing power.
You could probably find exactly the right chip that only has exactly just as many bits of RAM as you need for the lamp's functionality. But that would probably be more expensive to develop and chip than just using standard parts?
Even more radical: I suspect with a bit of cleverness you could probably do everything the lamp needs to do with some relays and transistors. But today, that would be more expensive.
You could do something very basic with discrete components for controlling wireless lighting systems but system starts to get out of hand when you need to have a bunch of lights nearby. It's much cheaper, simpler, and smaller to reduce it down to a chip and move to a digital RF system. I've got a bunch of RF controlled outlets in my house but it's just about the dumbest system you can buy. It's on par with the typical remote garage door opener. You can program the on/off buttons on the remote for each outlet but that's as far as it goes. I'd like to be able to remotely control them away from home or be able to give each light or outlet its own schedule and that requires either a central controller or each device having network access for network time and remote control.
Interestingly, a friend rented a house in college once that had a system of low voltage light switches that ran back to a cabinet filled with relays that controlled light switches and outlets. No major benefit to the user other than a control panel in the master bedroom that lets you control the exterior and some interior lights. It was a neat system but definitely outdated. I'd imagine a retrofit would be to drop all of the relays for solid state and provide a networked controller to monitor status and provide remote control.
It doesn't need it, its just that chips that can run doom are the dirt cheap bottom tier chips now. Rather than making some custom chip only just powerful enough to run the lamp software. You may as well just stick a generic one in.
These IKEA smart bulbs cost about $9 so yes, it is cost effective.
Chips that can run Doom, though, are just about at the low end for internet-connected devices. You can't run an IoT stack on that $.03 thing. The chip in the bulb is exactly in the right ballpark for the application. You do need a fairly beefy chip to run multiple network protocols efficiently.
There is no network stack on the ikea bulbs. They only support local communication via zigbee. No IP/TCP/etc. Its the gateway device that does wifi/networking.
ZigBee is a network protocol with a network stack. Just because it isn't TCP/IP does not mean it's not a network. It has addressing, routing and routing tables, fragmentation and reassembly, discovery, error detection, packet retransmission, and everything else you'd expect from a functional network protocol.
The ikea bulbs are actually pretty good malware wise. The bulbs do not connect to the internet, they use zigbee to communicate with a remote. Which can either be a dumb offline remote or the gateway device. The gateway also does not connect to the internet, it is local network only and can be hooked up to the Apple/Google/Amazon systems for internet access.
If you had to design an IoT bulb, this is the ideal setup.
> The gateway also does not connect to the internet, it is local network only and can be hooked up to the Apple/Google/Amazon systems for internet access.
In other words, it does connect to the internet, it also sits on the LAN to give attackers access to all your other devices, AND it sits on Zigbee to give attackers access to those as well.
No, it can be commandedfrom the Internet - big difference. It never has a direct connection to the Internet and even that is entirely optional and a hard opt-in (buying more hardware).
And if you have attackers on your LAN, you're at the point where controlling your lightbulb is the least of your problems. As for Zigbee, go on, present your alternative - I'm all ears!
As far as I know only Apple does the local network stuff. If a device is Alexa or Google Home compatible, it talks directly to some cloud service from the manufacturer on the Internet which then talks to Google or Amazon. So it connects directly to the internet, and moreover there is the additional attack/privacy surface of the manufacturer's cloud service.
Source: I run a HomeAssistant local IoT hub and to integrate it with Google Home I had to give it a public hostname and sign up as an IoT vendor with Google to register it as a developer/testing mode service (if I were a real vendor it would be one cloud hub for all my customers, it wouldn't be Google to individual homes, it's just that in my case there is only one user and the server is at my house).
We're still talking about the light bulbs, aren't we? Bulb --Zigbee--> Zigbee Gateway --WiFi/eth--> LAN. If further integration is desired, an Internet gateway can be used (could be a Google/Apple/Amazon box thing, but could also be a Pi with HomeAssistant!). How that gateway connects to the Internet is up to it - but at no point is either the lightbulb or its LAN gateway in any way connected to the Internet. Therefore, neither the bulb nor the gateway pose a direct security or privacy risk. All the security is offloaded to the gateway and you are entirely free to chose the vendor of your Internet gateway or indeed opt for none at all (and possibly use a VPN if external access is desired)
foobar33333 said "The gateway also does not connect to the internet", which cannot be true, because connecting to the internet to speak to a manufacturer-provided cloud service that then speaks to Google is required to integrate with Google Home. That's how it works. The IKEA gateway has to talk to an IKEA cloud service. If you think otherwise, please link to the Google Home docs that explain how that could possibly work, because I can't find them.
Here's how you hook up Home Assistant to Google cloud. As you can see, turning it into a cloud service from Google's POV is required. You can either use Home Assistant Cloud (see? cloud service) or set up your own single-user cloud integration (which is what I do), turning your "local" server into a cloud service (with public IP and SSL cert and domain and everything) and registering yourself as an IoT vendor in their developer console, pointing at your "cloud" service URL.
There is no way to keep the entire system local and have the Google Home devices only access it locally, without any cloud infrastructure. The commands flow from Google Home devices, to Google's cloud, to the vendor's cloud, to the vendor's devices.
Bulb --> Zigbee --> Zigbee Gateway --> WiFi/eth --> LAN --> Your router --> WAN --> IKEA cloud --> Google cloud --> WAN --> Your router --> LAN --> WiFi --> Google Home device.
If that sounds stupid, congrats, this is why they call it the internet of shit.
See, I have in fact set this up in the past, although not with IKEA lamps, but some other cheap Zigbee-compatible ones. The Zigbee-LAN gateway (along with all the other WiFi devices) sat on its own VLAN with no Internet access at all and a HomeAssistant box had access to both the IoT VLAN and the main one (that had Internet access). The HomeAssistant instance was configured with a dev account to work with Google's crap, but the devices themselves only ever talked to it, not Google or any vendor-provided server.
EDIT: Perhaps the terminology got somewhat twisted around here: when I talked about the LAN gateway, I meant specifically the thing that does Zigbee-LAN "translation". Now, that same physical box might also have the capability to work as a Zigbee-Alexa or Zigbee-Google transaltor, which would require a vendor server as you said, but those options are, well, optional. You can certainly disable them and use something like HASS or openHAB as the bridge to whatever cloud service you wish. Same way that my home router has a built-in VPN feature, but I don't use it because I run a VPN server on my NAS instead.
Of course, if you set up Home Assistant you can firewall them off the internet. That's how I do it too, with an IoT VLAN. It's not how these devices are intended to work, and not how they work if you just follow the manufacturer's instructions for Google/Alexa integration. You're replacing the vendor's cloud service with Home Assistant, effectively.
For example, I had to work out that in order to get Broadlink devices to stop rebooting every 3 minutes because they can't contact their cloud crap you have to broadcast a keepalive message on the LAN (it normally comes from their cloud connection, but their message handler also accepts it locally, and thankfully that's enough to reset the watchdog). This involved decompiling their firmware. I think that patch finally got merged into Home Assistant recently.
My point is that this is not the intended use for these devices. Normal people are going to put the gateways on the internet and enable the Google integration; in fact, it's quite likely that they will sign in to some IKEA cloud service as soon as you put the gateways on a network with outgoing internet connectivity, even before you enable the integration.
This is why HomeKit is superior: when you’re in your home, it doesn’t need WAN to function. The connection would be Bulb —> Zigbee —> Zigbee Gateway —> Wifi —> iPhone.
When you’re away from home, iCloud will be used, and no IoT vendor systems come into play. This means that all IoT devices can be kept offline and limited to your LAN. The connection would be Bulb —> Zigbee —> Zigbee Gateway —> Hone Hub (Apple TV or iPad or HomePod) —> WAN —> iCloud —> WAN —> iPhone.
>If a device is Alexa or Google Home compatible, it talks directly to some cloud service
This is how some IoT devices work. As far as I can tell. IKEA has no servers or infrastructure for their devices. And the Apple/Google hubs manage everything for them.
IKEA has to have servers for their devices to integrate with Google Home and Alexa. That's how those systems work. Only Apple offers direct local connectivity as far as I know.
These days Google Home has local fulfillment, but that seems to only be offered as an addition to cloud fulfillment. It always has a cloud fallback path.
Here's how you hook up Home Assistant to Google cloud. As you can see, turning it into a cloud service from Google's POV is required. You can either use Home Assistant Cloud (see? cloud service) or set up your own single-user cloud integration (which is what I do), turning your "local" server into a cloud service (with public IP and SSL cert and domain and everything) and registering yourself as an IoT vendor in their developer console, pointing at your "cloud" service URL.
There is no way to keep the entire system local and have the Google Home devices only access it locally, without any cloud infrastructure. The commands flow from Google Home devices, to Google's cloud, to the vendor's cloud, to the vendor's devices. There is a bypass path these days for local access, but it is always in addition to the cloud path, and only an optimization.
I don't know how the IKEA hardware works. However it is not true that Alexa has to talk to a cloud service to integrate with all IoT devices.
I know this because I run some local Raspberry PIs that pretend to be WeMo devices and I'm able to control them without any cloud connections from the PIs. The echo discovers the WeMo devices via upnp.
This has been a thing for quite a while[0].
I believe you are correct that Google Home has no local network device control.
The IoT device can certainly work like that. The comment is specifically talking about Google Assistant support, which as HomeAssistant users have experienced, does require cloud server access even if this seems unnecessary in cases when the devices are only being controlled within a local network.
> No, it can be commanded from the Internet - big difference.
Big difference from what?
You do realize that the vast majority of remotely exploitable security vulnerabilities are in software which can be commanded from the Internet, right?
Source?? I'm quite certain that it's much harder to exploit something that you can't even send a TCP packet to. If the device is only directly connected to the hub (amazon/google/apple box) and the hub is only connected to the cloud service, how would you even send a payload to the device, even if an exploit existed?
You could exploit the cloud service directly and gain control of the device, but that's like stealing the security guard's master keys - you can't call that a vulnerability in the door lock, can you?
There are 2 layers of relay devices in between. And the only one with direct internet access is a device you already have on the internet and is developed by the top brains and maintained for many years to come unlike your average smart bulb directly hooked to the internet with minimal security.
If you buy the dumb remote, you get a useful smart light setup with no internet or even local network connectivity. Its useful because you can turn a room full of lamps on at once or adjust their color.
The processing power needed to run a decent internet connected device with typical software stacks these days is about the same as the processing power needed to run Doom.
The system-on-chip is the MGM210L which needed to be powerful enough to run multiple wireless protocols (Zigbee, Thread, Bluetooth), so the lamp can be controlled by any of these. These are very complex protocols. The Thread spec for example is hundreds of pages. I did a formal security review of it on behalf of Google back in 2015. Bluetooth is even more complex. RF signal processing, packet structure, state machine, crypto, logical services, etc.
The software complexity of these protocols is greater than the complexity of a rudimentary 3D game like Doom, so it's expected that whatever chip can run these protocols can also run Doom.
It's burst processing. You do actually need high processing speeds for short periods of time to implement network protocols like these effectively. Think cryptography, reliability, etc. The CPU isn't doing anything most of the time, but it makes a big difference if it can get the job done in 500μs instead of 5ms when there is something to do (like process a packet).
Also, higher clock speed = lower power consumption. It sounds counterintuitive, but getting the job done quickly so you can go back to low power mode sooner actually saves power, even if the instantaneous power draw while processing is higher.
Nearly all cryptography on MCUs is hardware based. It would have otherwise be completely impossible to do timing sensitive crypto work like WiFi, or BT.
The WiFi, or BT protocol stacks themselves are however almost always in software on MCUs simply because nobody would bother making a separate ASIC IP for that which will be outdated by the next standard errata.
Symmetric cryptography is often hardware based, but asymmetric crypto rarely is. The latter is commonly used for pairing/key exchanges, and would be painfully slow on a slow MCU.
I would have thought they'd have specialized chip hardware already to deal with these, but maybe I don't know enough about that kinda thing. Pretty sure it'd have specialized hardware and/or instructions to deal with the cryptographic aspects though.
Since Ikea update the firmware of the trådlös units quite often and has security updates in the changelog I would guess... yes
They also mentions improvement of stability and performance towards different protocols in the changelogs.
Actually Thread is alive and kicking! It has a lot of momentum at the moment. But if it gets displaced, IMHO it's going to be by WiFi Ha-Low or successors.
That just means little more than "who bought or used the spec at some point." It has little bearing on contemporary real-world commercialization of the thread protocol.
Maybe not in your country(?) In the US there are quite a few commercial systems built on Thread: Apple HomePod mini, Google Nest security system, etc. Don't get me wrong: we are still very early in real-world deployments. It was just 2 years ago that the consortium/Google released the open source OpenThread which is when momentum really picked up.
>> The software complexity of these protocols is greater than the complexity of a rudimentary 3D game like Doom
That's unfortunate. Protocols, particularly those used for security should be a simple as possible. I know it's a hard problem and people tend to use what is available rather than solving the hard problem.
It is a IoT thingy with wireless connection which puts it in category where certain factors combine.
* Cost effective solution for lightbulb would be not having it wireless connection at all instead of having less powerful MCU. So it being IoT already means that target audience doesn't care about the price that much.
* It uses of the shelf FCC certfied wireless module with embedded antenna. For product designer it makes sense using a ready module because it avoids need to do RF design and the certification.It also simplifies the design if you run your user application inside the wireless module instead of having an additional MCU communicating with wireless module.
Such modules tend to have medium to high end MCUs.
Why do wireless modules need such processing power?
* 2.4 Ghz Antenna has certain size requirements so the size constraints for rest of the system aren't too tight.
* Wireless circuitry puts the module in certain price category, it makes sense to have the MCU in similar price category. Wireless certification is a pain, so there will be less product variants for wireless modules compared to something like 8bit micro controller which come in wide variety of memory, size and IO configurations. If you have single product variant better have slightly more powerful MCU part making it suitable for wider range of applications.
* The wireless communication part itself has certain amount of memory and computing requirements. Might as well split the resource budget on the same order of magnitude for wireless part and user application. N kB of memory for wireless and N kB for user application instead of N and 0.001N especially if the first part can easily vary by 10% or more due to bugfixes and compiler changes. Similarly there are basic speed requirements for digital logic buffering the bits from the analog RF part and doing the checksums.
* Modern silicon manufacturing technologies allow easily running at few tens of MHz so if the SOC has memory in the range of 30-500KB and isn't targeting ultra low power category it is probably capable of running at that speed.
These are always awesome and I never stop being impressed by what folks can do.
What's left in the world for "DOOM running on ____"?
Here's my idea:
Could we do this with a drone swarm? And have players still control DOOM guy somehow? I'm imagining sitting on the beach at night and someone is playing a level while everyone looks up at the sky at a massive "screen".
The current world record for drones is ~1300, 320*200 resolution has 50 times more pixels than drones. Therefore you need is powerfull 8-bit color drones and someone to design good edge representation. or just have massive fleet for better resolution.
Just because pigeons can deliver messages doesn't mean it's turing complete. Although they could be used in data transfer. I've never seen anybody suggest that RFC1149 is Turning Complete, anyway.
Game of Life is totally Turing Complete though, so it's already proven that you can indeed run Doom on it.
Too easy. At first I was imagining some amazing drone dance, but then I realized that it would be just a wireless screen with horrible battery endurance.
Supposedly the guy (Palmer) who created the commercial gba version had done a tech demo for gbc, but Carmack decided it was too stripped down and proposed a commander keen port for gbc at the time instead. Gba came out a couple of years later and was powerful enough.
Years ago, I saw someone implemented a vector display using a powerful visible-light laser on a gimbal, instead of an electron gun with magnetic deflection.
Then they used it to play Tetris on passing clouds.
I mean maybe? I don't think it's that consiquential for hobbyists as the lack of microcontrollers or other components. For instance, I can electroplate quite a few different substrates if I want to cut my own boards. Also after years of doing this, I have so much proto crap I'm probably good till the next pandemic but probably only have a couple unused Teensys and maybe an arduino or two laying around. I don't see the supply chain ever springing back to what it was. We are in a whole new world of scarcity for at least a few years IMO. Which I'm not that upset about at all really. It's inconvenient and possibly dangerous but I think the reorganization will create resilience in our supply chains and also the lack of gear will encourage people to do very interesting things with stuff that would be considered trash in 2019 and we need more of that. E-Waste is a huge problem.
> I don't see the supply chain ever springing back to what it was. We are in a whole new world of scarcity for at least a few years IMO.
The current issues are driven by the automotive industry having screwed up and shitcoin miners snatching up GPUs. Neither is going to be a long term issue.
I doubt it. PCBs are much more of a commodity than chips. You can make passable PCBs at home without a crazy amount of effort, and you can definitely get to professional-grade PCBs with some effort.
Constrained resources often lead to exceptionally brilliant software. It’s as if resource constraints inspire a form of discipline and frugality that’s demanded from us. We become acutely aware of it, and reprimand our brains from complacency. From Apollo program to today’s Internet-of-Shit, somewhere we lost our ability to focus and bloated ourselves with sugar-high of processing power and memory. Just because it exists, and is cheap, doesn’t mean it’s good for you.
Constraints is the mother of all creativity. Like Andy Dufresne and the the rock hammer, how about I give you nothing, could you possibly dig your way out?
This one is fake for me too since they had to add a screen and other stuff. Meh, I prefer my Doom runs on X to mean that X wasn't modified or beefed up.
I always like the fact that the average musical birthday card, popular in the 90s had more compute capacity than the computer in the Apollo command module.
Do people really think the Apollo computer is more powerful? And have any evidence? I'd be surprised if you can get a microcontroller with as little processing power these days.
I think the downvotes come because you keep saying that music cards use microcontroles, when they do not.
Music cards use dedicated chips, they are not general purpose, and they don’t really do much computation aside from a few counters. AFAIK.
Now, in DIY tutorials they show microcontrollers, because they are easier to obtain, but it doesn’t mean that they are used in the commercial products.
I realise they don't use microcontrollers, but the Apollo Guidance Computer only had ~12,000 transistors[1].
The cheapest, smallest (15s storage) "chip corder" (which is what these cards use) has GPIO, SPI, the ability to trigger different messages etc. There's no way this is under 12,000 transistors![2]
Those ICs don't have any compute capacity at all. They're an analog oscillator driving an address counter connected to an OTP ROM whose data pins go into a DAC.
Thank you, I think I am just gonna quit my work now and spend the day thinking about it walking around and being anxious too. Sometimes it takes a while to understand how far we have come with miniaturization of tech.
Ubiquitous spyware in everything we interact with, in order to make ads, on average, 5% more efficient—juuuuust enough more efficient that having a stream of massive-scale spyware data is necessary to compete in the ad sales market. Totally a good trade-off, making all the world's computing adversarial so ads work slightly better.
The concept of digital advertisement was unknown to Humans in ST universe until Ferengis brought an example to Federation Starbase Deep Space 9 in 2372, so that’s one divergence between our universe and Star Trek version of it.
Off topic, but Deep Space 9 was not a federation starbase. It was a Bajorian Republic station under Federation administration following the Cardassian withdrawal.
There's an idea for a series: a space opera with a cutting edge analytics-enhanced Ferengi ship where "it's continuing mission is to explore strange new ad streams, to fleece out new life and new civilisations, to boldly trade where no one has gone before".
I really did go without Star Trek! I had some small exposure to Star Wars, but what really grabbed my attention was the Neuromancer novel, and later the Matrix film series. Of course I'm cherry-picking my experience but it's a valid observation of yours that while I'm a technologist through and through, I often focus at its ugly side.
Such a shame the current writers of the franchise apparently didn't, either. Which is depriving current and recent generations of kids of that optimistic ideal.
(Yes, Discovery season 3 is a thing I know about.)
Star Trek was always a spherical cow as far as futures go. I'm not saying that it's not useful as an inspiration (socially, technologically and as emotional support), but realistically humans will pursue profit until we get a UBI system in place.
Optimistic. It's a small step from those to compulsory "social credit" - like money, but worse - and other more or less overt forms of thought control and behaviour modification.
I think we already have those, even without Ubiquitous computing. Hell, we had them even before we had any computing whatsoever. Sure they are more efficient now (what isn't) but they always existed...
Older ads were far less powerful. They also couldn't embed themselves into your everyday life so much. "Hey Google, ..."/"Alexa, ..."/"Siri, ..." is an exercise in brand reinforcement every time you want to ask your smart assistant about something. At one point, I creeped myself out by realising that my first instinct is to call out "Hey Google" when I need something, even if I'm away from my Google Home.
> our light bubs have more powerful computers than the first computer many of us once owned
Mine don't, and I first owned an AtariST with a 68000 CPU.
These are "smart bulbs". We are still in the .com bubble of IoT, so there are going to be a lot of silly things we can run Doom on for a while until it dies down. Lights don't need computers to operate, but that doesn't stop people trying to add "features" to lights with computers.
A problem with this from my point of view is that while hardware engineers did an incredible job increasing the processing power of our thinking rocks, us software devs did a tremendous job of squandering 90% of it away. Of course there also are market incentives for doing so (time to market, dev costs etc...).
Empirically it seems that software simply doesn't scale as well as hardware does. I feel like this overhead would make "smart dust" impractical.
Or I guess I could put it that way: one hand hand you could be impressed that a modern light bulb can run Doom, on the other you could be alarmed that you need a Doom-capable computer to run a modern light bulb.
The problem is that the extreme effort to optimise hardware pays off for everyone, the extreme effort to optimise "random software project" rarely does (unless random software project is a compiler/kernel of course).
The trick is that you probably don't need all, or even most, of that power to run the light. Sure the Zigbee protocol is _probably_ being done via software, and not a dedicated chip, but even then. The big thing is that this chip is most likely so cheap, especially in bulk, that it doesn't make sense to get the "cheaper" variant, even if that was still available. This is kind of supported by the "new" Trådfri having an updated chip, even though the Trådfri line never changed it's capabilities, it was probably cheaper to get the new more powerful chip and/or they could no longer get the old one with a five year supply guarantee.
In a similar vein, from memory the i3, i5 & i7 chip is absolutely identical in every physical way from a manufacturing point of view, except that the less powerful chips have cores / features disabled.
I have to wonder why this is done. I know it must make sense or it wouldn't be done, I just don't understand it.
If you're intentionally disabling functionality in order to sell at a lower cost, you're not actually saving any money because you still have to manufacture the thing. It also (I assume) opens up a risk to someone finding out how to "jailbreak" the extra cores and now you can buy an i7 for the price of an i3. Is the cost of having three different manufacturing processes so large that it's not worth switching? Is the extra revenue from having three different versions of the same physical chip enough to justify the jailbreak risk?
I think of you Google price discrimination or similar economic terms you get some explanations for this.
If you just have one price, you cut out people who can't afford it and people who can afford to pay more get away with more of the surplus.
If you have several prices and create just enough difference in the product that it doesn't change the expense much, you can suck dry every class of user.
Exactly, it is not an economics trick for if companies could only supply a certain level of the market it might not even be profitable to produce. It is just economics...
We are talking about chips here so not the same bottle of soap with different labels, I'd call that a trick.
It's called 'market segmentation'. It's why there are different brands of soap powder from the same manufacturer even though they are all essentially the same.
This is done with cores/memory banks that didn’t pass QC. For example, a 6 core CPU and an 8 core CPU might have the same die as a 12 core CPU, but 6/4 cores, respectively, were defective, so they get disabled. I don’t think they’re crippling fully functional hardware.
“When AMD produces a Phenom II die if part of the L3 is bad, it gets disabled and is sold as an 800 series chip. If one of the cores is bad, it gets disabled and is sold as a 700 series chip. If everything is in working order, then we've got a 900.”
Specifically regarding Phenom II, I have a 550 Black Edition still plugging away, serving different roles over the years, and I was able to successfully unlock and run the two locked-out cores (via a BIOS option). It's never skipped a beat at stock clock. It could be that there was an oversupply of quad-cores, or perhaps (since it was a Black Edition part marketed to overclockers) the extra cores failed when overclocked. I know I wasn't able to have both overclock and four cores, but I considered the extra cores more important, since it was already a reasonably fast chip for its day.
It's likely the latter (that it couldn't work when overclocked with all cores). The market for those is to allow overclocking, so if it can't do any overclocking with all cores AMD likely wouldn't want to sell it as a 4-core Black Edition, since it'd probably just get returned.
I imagine there is some trade off to be made between increasingly surgical disabling of components and avoiding a menagerie of franken-SKUs. Presumably the fault rate is low enough that tolerating a single GPU core drop takes care of enough imperfect parts.
Perhaps there is fault tolerance hidden elsewhere, e.g. the neural engine might have 17 physical cores and one is always disabled. Although this seems unlikely as it would probably waste more silicon than it would save.
That's because there is a huge variance in the quality of chips produced because the process isn't 100% precise.
So the best chips which have the least errors in the manufacturing process are sold as top tier. The ones which have more mistakes in them get their defective parts disabled and then get sold as lower tier ones
This is done because your production yield is not 100%.
So instead of throwing away every produced component which doesn't achieve the target of your 100%-product, you "soft-lock" the components with 80~99% performance into a 80%-product category, and the ones with 60~80% into a 60%-product.
This way you increase the total yield-rate, and produce less waste.
The counter-intuitive waste happens when the demand for the 60%-product is exceeding your "natural" supply of 60%-output, so you have to start to "soft-lock" some of your "80%-product" production to the 60%-grade to fulfill demand...
But do these production defects really meet the demand of the lower tiers? Also how is it possible to predict the number of defects in advance so that they can make useful promises to distributors?
I'm curious about this as well. It seems inevitable that some batches will be "too good" to satisfy demand of low end chips.
Either they just accept the fluctuations in order to maximize output of high end chips, or they would have to cripple fully functional ones to maintain a predictable supply. Interesting business.
It's not primarily about using defective chips (but that's a nice side effect). As a process becomes mature, yield rates become very high and there wouldn't be enough defective chips to meet demand for a lower tier, so good chips are binned into those tiers anyway.
The primary purpose is market segmentation: extracting value from customers who would pay more while not giving up sales to more price sensitive clients who nevertheless pay more than the marginal cost of production.
That makes sense, thanks. I wonder if it would be possible to de-bin one of the lower end ones, assuming it is a binned version of a fully functional higher tier chip. Or perhaps they completely destroy the offlined cores/features.
Well eventually as yields improve you start handicapping perfectly valid chips to main market segmentation.
I cannot say this for certain in CPUs but I know in other electronics with PCBs that this is how it is done. Sometimes lower-end SKUs are made by opening a higher-end one and cutting a wire or a trace.
This tends to be the case later on in a product's production run, as the manufacturer has fine tuned the process and worked out most of the kinks, the pass-rate of finished items increases.
At this point, yes they may lock down perfectly good high end CPUs to a midrange model spec to meet a production quota.
The term for this is "binning", and the explanation is wholly innocent. Manufacturing silicon chips is not an exact process, and there will be some rate of defects.
After manufacture, they test the individual components of their chips. These chips are designed in such a way that once they identify parts of a chip that are defective, they can disconnect that part of the chip and the others still work. (I believe they physically cut stuff with lasers but my knowledge is out of date). This process can also includes "burning in" information on the chip itself, like setting bits in on-die ROMs, so that if your OS asks your CPU for its model number it can respond appropriately.
Interesting side note: The same thing happens when manufacturing even basic electronic components like resistors. All the resistors that are within 1% of the target resistance get sold as "±1%" resistors, which means it's pretty likely that if you buy the cheaper "±5%" resistors and test them, you'll find two clusters around -5% and +5% and very few at the target value.
> The same thing happens when manufacturing even basic electronic components like resistors.
EEVblog did some tests[1][2] some time ago on ±1% resistors, and found that while his samples were fairly Gaussian and within the spec, the ones from his second batch were consistently low. That is, none were above the rated value.
So yeah, don't assume a perfect Gaussian distribution when using resistors.
No manufacturing process is perfect, so you just sort, label and price the output accordingly. This is fairly normal practice. LEDs, vegetables, even eggs...
What doesn’t scale well is John Carmack (and those of similar devotion).
And yes, I’m aware that there are also those with the chops, who are not permitted by their money masters (or alternately by their master, money) to write performant software.
Those “money masters” are responding to market conditions. If the market demanded greater efficiency (eg. Through climate policy for example), we would quickly see a change in priorities.
So basically we need a climate tax on software to fix the problem. Putting the tax directly at energy would not cause much optimization in software in my opinion. I don't believe software development has a culture than can take on responsibility of its actions, neither in energy usage nor in security, which all leads back to programmers not being an engineer kind of worker but more like an author/writer. Hardware engineers on the other hand can and often do take responsibility. All in all I don't have any hope of software developers being up to the task if it landed in their lap to fix this so if we wanted their hand forced the tax needs to be directly on software instead of hardware or energy. I don't believe this is mainly market driven as the market is unlikely to be able to fix it. It's at least as much a culture problem.
Yeah, doom advanced the state of the art by maybe a decade(?). Instead of needing a silicon graphics workstation or a Graphics accelerator, it allows a generation of kids to play on any hardware.
If you want to know how the world would be like without video game programmers, just like at internal corporate software and how slow it is.
How many other advances are we tossing away because people don’t know how to optimize and code for speed and fun!
I think of John Carmack as the software equivalent of Roger Bannister, he of the first 4 minute mile. Yes, he is absolutely incredible, but once that magic is revealed to the world, it shows what is achievable and people can follow in his footsteps.
Of course, I'm over here with my poky 6 minute mile...
My guess is, that in the future, we'll have computers writing some highly optimized software for certain things. I'm not saying all of use software people will be replaced 100% but some stuff will be replaced by automation.
Will the specifications for the software also be machine-generated?
If the specifications are human-generated, then they're just a form of high-level source code, and your prediction boils down to future programming languages simultaneously improving programmer productivity and reducing resource usage. That's not a controversial prediction.
If I understand you correctly, I think you're correct that over time, we'll see an increase at the abstraction level at which most programming is done. I think the effort put into making compilers better at optimizing will largely follow market demand, which is a bit harder to predict.
One interesting direction is the Halide[0] domain-specific language for image/matrix/tensor transformations. The programs have 2 parts: a high-level description, and a set of program transformations that don't affect results, but make performance tradeoffs to tune the generated code for particular devices. The Halide site has links to some papers on applying machine learning to the tuning and optimization side of things.
I can imagine a more general purpose language along these lines, maybe in the form of a bunch of declarative rules that are semantically (though perhaps not syntactically) Prolog-like, plus a bunch of transformations that are effectively very high-level optimization passes before the compiler ever starts looking at traditional inlining, code motion, etc. optimizations.
At some point, maybe most programmers will just be writing machine learning objective functions, but at present, we don't have good engineering practice for writing safe and reliable objective functions. Given some of the degenerate examples of machine learning generating out-of-the-box solutions with objective functions (throwing pancakes to maximize the time before they hit the ground, tall robots that fall over to get their center of mass moving quickly, etc.), we're a long way from just handing a machine broad objectives and giving it broad leeway to write whatever code it deems best.
I suspect in the medium-term, we'll see a 3-way divergence in programming: (1) safety/security-critical programs generated from proofs (see Curry-Howard correspondence, and how the seL4 microkernel was developed) (2) performance-critical programs that are very intensive in terms of human expert time and (3) lots of cookie-cutter apps and websites being generated via machine learning from vague human-provided (under-)specifications.
No, Google's AI is floorplanning[0] (basically routing and layout) human-designed logic in 6 hours. That headline is misleading.
It's kind of like having a compiler will billions of optimization flags and using AI to select a pretty near-optimal set of flags for a particular human-generated source file. We wouldn't call the output an AI-designed program, even though such AI would be really helpful.
Google is using AI as a heuristic for decently fast approximate solutions to the floorplanning problem, where (IIRC) optimal solutions are NP-hard.
It's an important step forward, and presumably a big time saver, but they're nowhere near giving the AI an instruction set spec or examples of inputs and outputs ad having the AI generate the logic.
In the scheme of things, this is short term. Market incentives for pushing performance are currently minor, but will have increasing influence over the next decade. Factors such As processing power hitting physical limits and energy prices as a result of climate policy will force engineers to build more efficient systems.
I do not think we will see "processing power hitting physical limits" anytime soon. Moore's Law is not dead yet, it is a good question if it ever will be dead. As Jim Keller says, the only thing that is certain is number of people saying Moore's law is dead doubles every 18 months.
Yes, it has to die. In this universe things can only grow indefinitely by less than an n^3 factor, because that's as fast as the lightcone of any event grows. Exponential growth, no matter how small the factor, will eventually outgrow n^3.
Once we attain the limits of what we can do in 2 dimensions, we aren't that many exponential growth events from what we can achieve in 3. Or once we achieve the limits of silicon technology, we aren't that many exponential growth events from the limits of photonics or quantum or any other possible computing substrate. Unless we somehow unlock the secret of how to use things smaller than atoms to compute, and can keep shrinking those, we're not getting very much farther on a smooth exponential curve.
Sure, it has to die eventually, but the key phrase is anytime soon. But do we have any evidence it will during our lifetime? Or even our great-great-great-great-great-great-grand-child's lifetime?
Eh...for single-threaded processing, I'd say Moore's Law is dead and has been dead for more than a couple CPU generations now.
What we're seeing now is massive parallelism, which means if your task is embarrassingly parallel, then Moore's Law is very much alive and well. Otherwise, no.
Moore's law is a statement about transistor count on an integrated circuit - there is no "Moore's law for single threaded processing". And transistor counts continue to double.
I'll choose instead to be amazed that Doom-capable computers are now inexpensive and ubiquitous enough that it makes total financial sense to use one in a light bulb!
More seriously, I see this argument all the time: that we are just squandering our advances in hardware by making comparably more inefficient software! Considering that efficiency used to be thought of on the level of minimizing drum rotations and such: the whole point is that we're now working at a much higher level of abstraction, and so we're able to build things that would not have been possible to build before. I for one am extremely grateful that I don't have to think about the speed of a drum rotating, or build web applications as spiders' nests of CGI scripts.
Are there modern websites and applications that are needlessly bloated, slow, and inefficient? Certainly - but even those would have been impossible to build a few decades ago, and I think we shouldn't lose sight of that.
I get your point, but putting these 2 thoughts together:
> we are just squandering our advances in hardware by making comparably more inefficient software
> we're able to build things that would not have been possible to build before
We get that not only are we able to build things that weren't possible before, but we can build things that are more inefficient than was possible before.
We can expect in the future to see new levels of inefficiencies as hardware developments give us more to waste.
Without something to balance this out, we should expect to see our text editors get more and more bloated in cool and innovative ways in the future.
It makes me think of fuel efficiency standards in cars.
I dunno...this attitude scares me a bit, that you would just shrug away wasted CPU cycles and accept the low performance.
CPUs are getting faster, and yet paradoxically, performance is worse, especially in the world of web browsers.
The original DOOM ran at 30 fps in 320x200, which meant it rendered 1,920,000 pixels per second with only a 33 Mhz CPU. That's less than 18 clock cycles per pixel, and even that's assuming no CPU time spent on game logic. If DOOM were written today with a software renderer written in C#, Python, or JS, I'd be surprised if it could get anywhere near that level of clocks/pixel.
These days, the basic Windows Calculator consumes more RAM than Windows 98, and that's just inexcusable.
What's "low performance"? Humans measure tasks on human timescales. If you ask an embedded computer to do something, and it finishes doing that something in 100ms vs 10ms vs 1us, it literally doesn't matter which one of those timescales it happened on, because those are all below the threshold of human latency-awareness. If it isn't doing the thing a million times in a loop (where we'd start to take notice of the speed at which it's doing it), why would anyone ever optimize anything past that threshold of human awareness?
Also keep in mind that the smaller chips get, the more power-efficient they become; so it can actually cost less in terms of both wall-clock time and watt-hours consumed, to execute a billion instructions on a modern device, than it did to execute a thousand instructions on a 1990s device. No matter how inefficient the software, hardware is just that good.
> These days, the basic Windows Calculator consumes more RAM than Windows 98
The Windows Calculator loads a large framework (UWP) that gets shared by anything else that loads that same framework. That's 99% of its resident size. (One might liken this to DOS applications depending on DOS — you wouldn't consider this to be part of the app's working-set size, would you?)
Also, it supports things Windows 98 didn't (anywhere, not just in its calculator), like runtime-dynamically-switchable numeric-format i18n, theming (dark mode transition!) and DPI (dragging the window from your hi-DPI laptop to a low-DPI external monitor); and extensive accessibility + IME input.
I think the other comment has a point though: these frameworks are definitely powerful, but they have no right to be as large as they actually are. Nowadays, we're blowing people's minds by showing 10x or 100x speedups in code by rewriting portions in lower-level languages; and we're still not even close to how optimized things used to be.
I think the more amicable solution here is to just have higher standards. I might not have given up on Windows (and UWP) if it didn't have such a big overhead. My Windows PC would idle using 3 or 4 gigs of memory: my Linux box struggles to break 1.
Have you tried to load UWP apps on a machine with less memory? I believe that part of what's going on there is framework-level shared, memory-pressure reclaimable caching.
On a machine that doesn't have as much memory, the frameworks don't "use" as much memory. (I would note that Windows IoT Core has a minimum spec of 256MB of RAM, and runs [headless] UWP apps just fine! Which in turn goes up to only 512MB RAM for GUI UWP apps.)
Really, it's better to not think of reclaimable memory as being "in use" at all. It's just like memory that the OS kernel is using for disk-page caching; it's different in kind to "reserved" memory, in that it can all be discarded at a moment's notice if another app actually tries to malloc(2) that memory for its stack/heap.
That's well and good - when your program is the only software running, such as an a dedicated SBC. You can carefully and completely manage the cycles in such a case. Very few people would claim software bloat doesn't otherwise affect people. Heck the software developers of that same embedded software wish their tools were faster.
> No matter how inefficient the software, hardware is just that good.
Hardware is amazing. Yet, software keeps eating all the hardware placed in front of it.
I mean, I agree, but the argument here was specifically about whether you're "wasting" a powerful CPU by putting it in the role of an embedded microcontroller, if the powerful CPU is only 'needed' because of software bloat, and you could theoretically get away with a much-less-powerful microcontroller if you wrote lower-level, tighter code.
And my point was that, by every measure, there's no point to worrying about this particular distinction: the more-powerful CPU + the more-bloated code has the same BOM cost, the same wattage, the same latency, etc. as the microcontroller + less-bloated code. (Plus, the platform SDK for the more-powerful CPU is likely a more modern/high-level one, and so has lower CapEx in developer-time required to build it.) So who cares?
Apps running on multitasking OSes should indeed be more optimized — if nothing else, for the sake of being able to run more apps at once. But keep in mind that "embedded software engineer" and "application software engineer" are different disciplines. Being cross that application software engineers should be doing something but aren't, shouldn't translate to a whole-industry condemnation of bloat, when other verticals don't have those same concerns/requirements. It's like demanding the same change of both civil and automotive engineers — there's almost nothing in common between their requirements.
I think I would be more willing to embrace this sort of tech if there computing resources were easily accessible to hack on.
If I could easily upload my code to this smart bulb and leverage it either for creative or practical endeavors then I wouldn't necessarily consider it wasted potential.
But here you have this bloated tech that you can't even easily leverage to your advantage.
I do agree with the general point that the progress we've made over the past few decades is mind blowing, and we shouldn't forget how lucky we are to experience it first hand. We're at a key moment of the evolution of humankind, for better or worse.
I'm tired of the bloated software take. Hardware is meant to be used. Without these abstractions most software would be practically impossible to create. Without software solving more problems what's the point of the hardware?
Of course can good abstractions and tools help to make software possible that were practically impossible before. But there is also a tendency to add abstraction layers of questionable value. An Electron-based UI to copy a disk image to an usb stick comes to my mind, e.g. Certainly it is possible to create a GUI for a file to disk copy operation without two JavaScript engines, an html/css renderer, lot's of network code, etc. This is just a silly example, I know. But this happens all the time. That phenomenon isn't even new. Anybody, remember when the first end-user internet providers would all distribute their own software to dial in? In my experience, most problems with the internet access at that time could be fixed by getting rid of that software and entering the phone number and dial-in credentials in their corresponding Windows dialog windows.
>An Electron-based UI to copy a disk image to an usb stick comes to my mind
Subjective. Questionable to you. Nobody is bloating dd
There is definitely bloated software but it's not a huge issue. If it were, then the customer would care. If the customer cares the business would care.
I don’t think the Point of N Ghz + 8 gb ram hardware is for me to sit and stare at a spinning mouse pointer while waiting for the explorer to change to another directory.
I'd like to see the DOOM engine written entirely in Python without using any GPU rendering besides the frame buffer.
DOOM ran in 320x200 at 30 fps on a 33 Mhz CPU, which gives it less than 18 clock cycles per pixel rendered. I doubt Python could get anywhere close to that.
Reading up upon some of the absolute ugly and unmaintainable hacks that software writers had to rely upon two decades back to fit things into the hardware, I am honestly quite glad the æra of that type of programming is now past us.
It was certainly impressive, but it was aso a case of often design having to give way to such hacks, such as the fact that many older first person shooter games had to have their entire level design work around the idea that the engines could not support two walkable surfaces vertically above each other for performance reasons or the famous Duke Nukem 3D “mirror” hack.
> you could be alarmed that you need a Doom-capable computer to run a modern light bulb.
An ESP8266 microcontroller can be bought in low quantity for less than a dollar. I means sure any cost reduction at scale is meaningful, but at that point I don't think the silicon is the expensive part at that point. It just doesn't make sense to give WIFI devices anything less than that performance, the gains in silicon space will be meaningless and you'll spend more managing that than anything.
>A problem with this from my point of view is that while hardware engineers did an incredible job increasing the processing power of our thinking rocks, us software devs did a tremendous job of squandering 90% of it away.
That works both ways though. The highly qualified software devs did indeed squander some of it away.
But I'm a rather bad dev that writes really inefficient code (because it's not my primary concern, I'm not a programmer, I just need custom software that does the things I need done that can't be done by software other people write).
All this overpowered hardware allows my code to work very well.
I've been in situations where I could pick between "learn to program properly and optimize my code" or "throw more hardware at it" and throwing more hardware at it was definitely the faster and more efficient approach in my case.
Most web apps/websites aren't a whole lot more sophisticated than they were in the days of Netscape Navigator 3.0. They show text and pictures, accept form submissions and resize the viewport when I change the window size. Yet today they seem to require multi gigahertz CPUs to do anything acceptably fast. Yes there are a few that were not possible back then. Most though can't justify their resource consumption. Neither on the client nor on the server side.
I remember reading about some circuit where they replaced an 555 timer whose job was to generate a PWM signal with a fully featured microcontroller, because it was cheaper that way.
While I'm a great fan of ubiquitous tech/computing in general, I must also say that it feels weird applying firmware updates to light bulbs.
However, you want to stay safe these days, so it's better to keep up to date, right?
Unfortunately, my experience has been that Ikea will push out a firmware update, and then I don't discover it until the outside lights fail to turn on or off at their appointed time and have to be rebooted. Yes, we live in an age when you can reboot a light bulb.
Very much to their credit, though, the Trådfri hub doesn't depend on a cloud service just to operate. If that ever happens, thus endeth my foray into smart lighting. I've put my foot down: if it needs Somebody Else's Computer to function, I don't want it.
Given how computation is more and more energy efficient and requires near zero material to build, will there be a day that we consider computing cycles a priori a bad thing? Maybe there will be an argument about how terrible it is to have smart dust by those who consider it to be a new form of pollution and toxicity.
I believe there is a point at which we will be emulating silicon so fast that we will be able to realize true Single Instruction Set computing.
Such a machine would be nowhere near as efficient as a CISC computer in terms of work per clock cycle, but what if our "silicon" in the future can run an almost arbitrary frequency? We would be able to emulate any instruction set natively in real time. The perfect FPGA.
Fake News (Just a little bit). I was just thinking about using unmodified lamp as a Linux Terminal. I learned morse in the army in 70's. I already had a lamp which morsed time of day, but it was annoying, because morse numbers are so long.
318 comments
[ 3.2 ms ] story [ 262 ms ] thread"If you replace all the parts of a ship is it still the same ship?".
This project is equivalent to "Doom running on 40-MHz Cortex M4 found in Ikea lamps".
Good work nevertheless!
Still, we say "I'm playing Doom on my playstation".
In any case, the argument is that the mini console they built is no longer a lamp, not that you can't play games on a console.
Edit: It's still a fun and cool project. But more like running Doom on hardware salvaged from an IKEA lamp.
So the OP is not entirely wrong: they ported a game played on a 16.8Mhz system with 256kb of RAM to a 80Mhz with 108Kb of RAM.
The writeup explicitly says «we could trade off some computing power of the 80Mhz Cortex M33 to save memory»
It also doesn't have quite all the features. No music, and no screen wipe effect (I worked on a memory constrained Doom port myself, and that silly little effect is incredibly memory intensive since you need two full copies of the frame buffer)
If someone said "I'm playing Doom on my PC" in 1993, they would also have been using an external keyboard, monitor, and speakers. And the game would have shipped on external storage (floppy disks).
Historically a lamp would consist of the wick, oil and holder.
https://www.youtube.com/watch?v=KFDlVgBMomQ
You could probably find exactly the right chip that only has exactly just as many bits of RAM as you need for the lamp's functionality. But that would probably be more expensive to develop and chip than just using standard parts?
Even more radical: I suspect with a bit of cleverness you could probably do everything the lamp needs to do with some relays and transistors. But today, that would be more expensive.
Compare https://www.youtube.com/watch?v=NmGaXEmfTIo for the latter approach.
Interestingly, a friend rented a house in college once that had a system of low voltage light switches that ran back to a cabinet filled with relays that controlled light switches and outlets. No major benefit to the user other than a control panel in the master bedroom that lets you control the exterior and some interior lights. It was a neat system but definitely outdated. I'd imagine a retrofit would be to drop all of the relays for solid state and provide a networked controller to monitor status and provide remote control.
These IKEA smart bulbs cost about $9 so yes, it is cost effective.
https://hackaday.com/2019/04/26/making-a-three-cent-microcon...
Chips that can run Doom, though, are just about at the low end for internet-connected devices. You can't run an IoT stack on that $.03 thing. The chip in the bulb is exactly in the right ballpark for the application. You do need a fairly beefy chip to run multiple network protocols efficiently.
Plus how else will malware people run their stuff?
If you had to design an IoT bulb, this is the ideal setup.
In other words, it does connect to the internet, it also sits on the LAN to give attackers access to all your other devices, AND it sits on Zigbee to give attackers access to those as well.
And if you have attackers on your LAN, you're at the point where controlling your lightbulb is the least of your problems. As for Zigbee, go on, present your alternative - I'm all ears!
Source: I run a HomeAssistant local IoT hub and to integrate it with Google Home I had to give it a public hostname and sign up as an IoT vendor with Google to register it as a developer/testing mode service (if I were a real vendor it would be one cloud hub for all my customers, it wouldn't be Google to individual homes, it's just that in my case there is only one user and the server is at my house).
Here's how you hook up Home Assistant to Google cloud. As you can see, turning it into a cloud service from Google's POV is required. You can either use Home Assistant Cloud (see? cloud service) or set up your own single-user cloud integration (which is what I do), turning your "local" server into a cloud service (with public IP and SSL cert and domain and everything) and registering yourself as an IoT vendor in their developer console, pointing at your "cloud" service URL.
https://www.home-assistant.io/integrations/google_assistant/
There is no way to keep the entire system local and have the Google Home devices only access it locally, without any cloud infrastructure. The commands flow from Google Home devices, to Google's cloud, to the vendor's cloud, to the vendor's devices.
Bulb --> Zigbee --> Zigbee Gateway --> WiFi/eth --> LAN --> Your router --> WAN --> IKEA cloud --> Google cloud --> WAN --> Your router --> LAN --> WiFi --> Google Home device.
If that sounds stupid, congrats, this is why they call it the internet of shit.
EDIT: Perhaps the terminology got somewhat twisted around here: when I talked about the LAN gateway, I meant specifically the thing that does Zigbee-LAN "translation". Now, that same physical box might also have the capability to work as a Zigbee-Alexa or Zigbee-Google transaltor, which would require a vendor server as you said, but those options are, well, optional. You can certainly disable them and use something like HASS or openHAB as the bridge to whatever cloud service you wish. Same way that my home router has a built-in VPN feature, but I don't use it because I run a VPN server on my NAS instead.
For example, I had to work out that in order to get Broadlink devices to stop rebooting every 3 minutes because they can't contact their cloud crap you have to broadcast a keepalive message on the LAN (it normally comes from their cloud connection, but their message handler also accepts it locally, and thankfully that's enough to reset the watchdog). This involved decompiling their firmware. I think that patch finally got merged into Home Assistant recently.
My point is that this is not the intended use for these devices. Normal people are going to put the gateways on the internet and enable the Google integration; in fact, it's quite likely that they will sign in to some IKEA cloud service as soon as you put the gateways on a network with outgoing internet connectivity, even before you enable the integration.
When you’re away from home, iCloud will be used, and no IoT vendor systems come into play. This means that all IoT devices can be kept offline and limited to your LAN. The connection would be Bulb —> Zigbee —> Zigbee Gateway —> Hone Hub (Apple TV or iPad or HomePod) —> WAN —> iCloud —> WAN —> iPhone.
> Hone Hub (Apple TV or iPad or HomePod) —> WAN
This is how some IoT devices work. As far as I can tell. IKEA has no servers or infrastructure for their devices. And the Apple/Google hubs manage everything for them.
These days Google Home has local fulfillment, but that seems to only be offered as an addition to cloud fulfillment. It always has a cloud fallback path.
Here's how you hook up Home Assistant to Google cloud. As you can see, turning it into a cloud service from Google's POV is required. You can either use Home Assistant Cloud (see? cloud service) or set up your own single-user cloud integration (which is what I do), turning your "local" server into a cloud service (with public IP and SSL cert and domain and everything) and registering yourself as an IoT vendor in their developer console, pointing at your "cloud" service URL.
https://www.home-assistant.io/integrations/google_assistant/
There is no way to keep the entire system local and have the Google Home devices only access it locally, without any cloud infrastructure. The commands flow from Google Home devices, to Google's cloud, to the vendor's cloud, to the vendor's devices. There is a bypass path these days for local access, but it is always in addition to the cloud path, and only an optimization.
I know this because I run some local Raspberry PIs that pretend to be WeMo devices and I'm able to control them without any cloud connections from the PIs. The echo discovers the WeMo devices via upnp.
This has been a thing for quite a while[0].
I believe you are correct that Google Home has no local network device control.
[0]: https://hackaday.com/2015/07/16/how-to-make-amazon-echo-cont...
Big difference from what?
You do realize that the vast majority of remotely exploitable security vulnerabilities are in software which can be commanded from the Internet, right?
You could exploit the cloud service directly and gain control of the device, but that's like stealing the security guard's master keys - you can't call that a vulnerability in the door lock, can you?
If you buy the dumb remote, you get a useful smart light setup with no internet or even local network connectivity. Its useful because you can turn a room full of lamps on at once or adjust their color.
The software complexity of these protocols is greater than the complexity of a rudimentary 3D game like Doom, so it's expected that whatever chip can run these protocols can also run Doom.
Datasheet of MGM210L for the curious: https://www.silabs.com/documents/public/data-sheets/mgm210l-...
Also, higher clock speed = lower power consumption. It sounds counterintuitive, but getting the job done quickly so you can go back to low power mode sooner actually saves power, even if the instantaneous power draw while processing is higher.
The WiFi, or BT protocol stacks themselves are however almost always in software on MCUs simply because nobody would bother making a separate ASIC IP for that which will be outdated by the next standard errata.
The real reason is it reduces the cost (and duration) of iterating in the development phase.
The chip is SoC with Arm core, FP, Crypto Acceleration, DSP extensions and FPU unit plus radio parts.
And this also assured it being dead on arrival.
Tuya on other hand is just in every retail outlet, it's just people don't know that Tuya is under the bonnet.
They literally have more talkshops per months than devices released.
That's unfortunate. Protocols, particularly those used for security should be a simple as possible. I know it's a hard problem and people tend to use what is available rather than solving the hard problem.
* Cost effective solution for lightbulb would be not having it wireless connection at all instead of having less powerful MCU. So it being IoT already means that target audience doesn't care about the price that much. * It uses of the shelf FCC certfied wireless module with embedded antenna. For product designer it makes sense using a ready module because it avoids need to do RF design and the certification.It also simplifies the design if you run your user application inside the wireless module instead of having an additional MCU communicating with wireless module. Such modules tend to have medium to high end MCUs.
Why do wireless modules need such processing power?
* 2.4 Ghz Antenna has certain size requirements so the size constraints for rest of the system aren't too tight. * Wireless circuitry puts the module in certain price category, it makes sense to have the MCU in similar price category. Wireless certification is a pain, so there will be less product variants for wireless modules compared to something like 8bit micro controller which come in wide variety of memory, size and IO configurations. If you have single product variant better have slightly more powerful MCU part making it suitable for wider range of applications. * The wireless communication part itself has certain amount of memory and computing requirements. Might as well split the resource budget on the same order of magnitude for wireless part and user application. N kB of memory for wireless and N kB for user application instead of N and 0.001N especially if the first part can easily vary by 10% or more due to bugfixes and compiler changes. Similarly there are basic speed requirements for digital logic buffering the bits from the analog RF part and doing the checksums. * Modern silicon manufacturing technologies allow easily running at few tens of MHz so if the SOC has memory in the range of 30-500KB and isn't targeting ultra low power category it is probably capable of running at that speed.
What's left in the world for "DOOM running on ____"?
Here's my idea:
Could we do this with a drone swarm? And have players still control DOOM guy somehow? I'm imagining sitting on the beach at night and someone is playing a level while everyone looks up at the sky at a massive "screen".
https://www.airlineratings.com/news/art-sky-check-spectacula...
Now, to figure out how to pump in the soundtrack ...
[0] https://datatracker.ietf.org/doc/html/rfc1149
[1] https://datatracker.ietf.org/doc/html/rfc2549
[2] https://datatracker.ietf.org/doc/html/rfc6214
DOOM in Game of Life.
DOOM as a Boltzmann brain (might take a while before that's implemented, but I bet it'll happen eventually)
Game of Life is totally Turing Complete though, so it's already proven that you can indeed run Doom on it.
See project Blinkenlights from the early 2000 (not Doom, but still video games). https://en.wikipedia.org/wiki/Project_Blinkenlights
Supposedly the guy (Palmer) who created the commercial gba version had done a tech demo for gbc, but Carmack decided it was too stripped down and proposed a commander keen port for gbc at the time instead. Gba came out a couple of years later and was powerful enough.
Then they used it to play Tetris on passing clouds.
https://www.smbc-comics.com/comic/2011-02-17
Nice work!
The current issues are driven by the automotive industry having screwed up and shitcoin miners snatching up GPUs. Neither is going to be a long term issue.
He added external memory (an 8MB W25Q64).
Amazing clock speed for a lamp. I guess they need it to get the OS started quickly...
https://www.smbc-comics.com/comic/2011-02-17
It has more CPU perf than my first computer, and costs 1000 times less at the same time.
The progress of semiconductor industry is fantastical.
This perspective makes scifi stuff like "smart dust" seem a lot more feasible. Ubiquitous computing, what will it bring us?
These are around 20 MIPS. The Apollo guidence computer had around 1 MIPS.
It seems likely they are using something similar. It's difficult to find a cheaper chip, broadly available chip these days.
You can find Z80 clones, but even they are generally upgraded and therefore more powerful than the Apollo computer.
Do people really think the Apollo computer is more powerful? And have any evidence? I'd be surprised if you can get a microcontroller with as little processing power these days.
Music cards use dedicated chips, they are not general purpose, and they don’t really do much computation aside from a few counters. AFAIK.
Now, in DIY tutorials they show microcontrollers, because they are easier to obtain, but it doesn’t mean that they are used in the commercial products.
The cheapest, smallest (15s storage) "chip corder" (which is what these cards use) has GPIO, SPI, the ability to trigger different messages etc. There's no way this is under 12,000 transistors![2]
[1] https://en.wikipedia.org/wiki/Transistor_count#Transistor_co...
[2] https://www.datasheets.com/en/part-details/isd2115ayyi-nuvot...
Ads, obviously.
Ads, propaganda and surveillance.
I believe it is creeping back in now. But it can be done.
The main adversary will be the cookie monster.
https://en.wikipedia.org/wiki/The_Game_(Star_Trek%3A_The_Nex...
I do enjoy Dark sci-fi also every now and then but I generally like my heroes to be scientists, explorers, to solve ethical questions.
(Yes, Discovery season 3 is a thing I know about.)
The only thing more disturbing and sad about this is how much consumer demand there is and will be for deception, misinformation, and manipulation.
Mine don't, and I first owned an AtariST with a 68000 CPU.
These are "smart bulbs". We are still in the .com bubble of IoT, so there are going to be a lot of silly things we can run Doom on for a while until it dies down. Lights don't need computers to operate, but that doesn't stop people trying to add "features" to lights with computers.
Empirically it seems that software simply doesn't scale as well as hardware does. I feel like this overhead would make "smart dust" impractical.
Or I guess I could put it that way: one hand hand you could be impressed that a modern light bulb can run Doom, on the other you could be alarmed that you need a Doom-capable computer to run a modern light bulb.
So the RoI is just different.
The trick is that you probably don't need all, or even most, of that power to run the light. Sure the Zigbee protocol is _probably_ being done via software, and not a dedicated chip, but even then. The big thing is that this chip is most likely so cheap, especially in bulk, that it doesn't make sense to get the "cheaper" variant, even if that was still available. This is kind of supported by the "new" Trådfri having an updated chip, even though the Trådfri line never changed it's capabilities, it was probably cheaper to get the new more powerful chip and/or they could no longer get the old one with a five year supply guarantee.
If you're intentionally disabling functionality in order to sell at a lower cost, you're not actually saving any money because you still have to manufacture the thing. It also (I assume) opens up a risk to someone finding out how to "jailbreak" the extra cores and now you can buy an i7 for the price of an i3. Is the cost of having three different manufacturing processes so large that it's not worth switching? Is the extra revenue from having three different versions of the same physical chip enough to justify the jailbreak risk?
If you just have one price, you cut out people who can't afford it and people who can afford to pay more get away with more of the surplus.
If you have several prices and create just enough difference in the product that it doesn't change the expense much, you can suck dry every class of user.
Bit of an MBA trick.
We are talking about chips here so not the same bottle of soap with different labels, I'd call that a trick.
Instead of assuming, it's easy enough to confirm that CPU binning is real.
See here: http://isca09.cs.columbia.edu/pres/09.pdf
Also here: https://www.anandtech.com/show/2721
“When AMD produces a Phenom II die if part of the L3 is bad, it gets disabled and is sold as an 800 series chip. If one of the cores is bad, it gets disabled and is sold as a 700 series chip. If everything is in working order, then we've got a 900.”
Hmm, but what if 3 cores are defective? If that can happen(?), then it seems one extra functional core is disabled to get to an even core number.
Apple's M1 GPUs are the first where I've seen the choice between 7 and 8 cores (as opposed to 6/8 or 4/8).
It gets sold as a coaster
https://www.amazon.com/Keychain-Ryzen-Threadripper-Computer-...
https://www.amazon.com/Keychain-Intel-Core-Computer-Chain/dp...
Perhaps there is fault tolerance hidden elsewhere, e.g. the neural engine might have 17 physical cores and one is always disabled. Although this seems unlikely as it would probably waste more silicon than it would save.
So the best chips which have the least errors in the manufacturing process are sold as top tier. The ones which have more mistakes in them get their defective parts disabled and then get sold as lower tier ones
Either they just accept the fluctuations in order to maximize output of high end chips, or they would have to cripple fully functional ones to maintain a predictable supply. Interesting business.
The primary purpose is market segmentation: extracting value from customers who would pay more while not giving up sales to more price sensitive clients who nevertheless pay more than the marginal cost of production.
I cannot say this for certain in CPUs but I know in other electronics with PCBs that this is how it is done. Sometimes lower-end SKUs are made by opening a higher-end one and cutting a wire or a trace.
The real reason IMHO, is to have a larger range of product prices so you can cater for specific audiences.
It seems people are confusing cost with price. Those two things are orthogonal.
At this point, yes they may lock down perfectly good high end CPUs to a midrange model spec to meet a production quota.
After manufacture, they test the individual components of their chips. These chips are designed in such a way that once they identify parts of a chip that are defective, they can disconnect that part of the chip and the others still work. (I believe they physically cut stuff with lasers but my knowledge is out of date). This process can also includes "burning in" information on the chip itself, like setting bits in on-die ROMs, so that if your OS asks your CPU for its model number it can respond appropriately.
Interesting side note: The same thing happens when manufacturing even basic electronic components like resistors. All the resistors that are within 1% of the target resistance get sold as "±1%" resistors, which means it's pretty likely that if you buy the cheaper "±5%" resistors and test them, you'll find two clusters around -5% and +5% and very few at the target value.
EEVblog did some tests[1][2] some time ago on ±1% resistors, and found that while his samples were fairly Gaussian and within the spec, the ones from his second batch were consistently low. That is, none were above the rated value.
So yeah, don't assume a perfect Gaussian distribution when using resistors.
[1]: https://www.youtube.com/watch?v=1WAhTdWErrU
[2]: https://www.youtube.com/watch?v=kSmiDzbVt_U
And yes, I’m aware that there are also those with the chops, who are not permitted by their money masters (or alternately by their master, money) to write performant software.
If you want to know how the world would be like without video game programmers, just like at internal corporate software and how slow it is.
How many other advances are we tossing away because people don’t know how to optimize and code for speed and fun!
Of course, I'm over here with my poky 6 minute mile...
That's my prediction.
If the specifications are human-generated, then they're just a form of high-level source code, and your prediction boils down to future programming languages simultaneously improving programmer productivity and reducing resource usage. That's not a controversial prediction.
If I understand you correctly, I think you're correct that over time, we'll see an increase at the abstraction level at which most programming is done. I think the effort put into making compilers better at optimizing will largely follow market demand, which is a bit harder to predict.
One interesting direction is the Halide[0] domain-specific language for image/matrix/tensor transformations. The programs have 2 parts: a high-level description, and a set of program transformations that don't affect results, but make performance tradeoffs to tune the generated code for particular devices. The Halide site has links to some papers on applying machine learning to the tuning and optimization side of things.
I can imagine a more general purpose language along these lines, maybe in the form of a bunch of declarative rules that are semantically (though perhaps not syntactically) Prolog-like, plus a bunch of transformations that are effectively very high-level optimization passes before the compiler ever starts looking at traditional inlining, code motion, etc. optimizations.
At some point, maybe most programmers will just be writing machine learning objective functions, but at present, we don't have good engineering practice for writing safe and reliable objective functions. Given some of the degenerate examples of machine learning generating out-of-the-box solutions with objective functions (throwing pancakes to maximize the time before they hit the ground, tall robots that fall over to get their center of mass moving quickly, etc.), we're a long way from just handing a machine broad objectives and giving it broad leeway to write whatever code it deems best.
I suspect in the medium-term, we'll see a 3-way divergence in programming: (1) safety/security-critical programs generated from proofs (see Curry-Howard correspondence, and how the seL4 microkernel was developed) (2) performance-critical programs that are very intensive in terms of human expert time and (3) lots of cookie-cutter apps and websites being generated via machine learning from vague human-provided (under-)specifications.
[0] https://halide-lang.org/
No, Google's AI is floorplanning[0] (basically routing and layout) human-designed logic in 6 hours. That headline is misleading.
It's kind of like having a compiler will billions of optimization flags and using AI to select a pretty near-optimal set of flags for a particular human-generated source file. We wouldn't call the output an AI-designed program, even though such AI would be really helpful.
Google is using AI as a heuristic for decently fast approximate solutions to the floorplanning problem, where (IIRC) optimal solutions are NP-hard.
It's an important step forward, and presumably a big time saver, but they're nowhere near giving the AI an instruction set spec or examples of inputs and outputs ad having the AI generate the logic.
[0] https://en.wikipedia.org/wiki/Floorplan_(microelectronics)
There is no reason to optimize the language that programmers work in when such optimizations can better be done on the generated machine code.
https://eecs.berkeley.edu/research/colloquium/190918
Once we attain the limits of what we can do in 2 dimensions, we aren't that many exponential growth events from what we can achieve in 3. Or once we achieve the limits of silicon technology, we aren't that many exponential growth events from the limits of photonics or quantum or any other possible computing substrate. Unless we somehow unlock the secret of how to use things smaller than atoms to compute, and can keep shrinking those, we're not getting very much farther on a smooth exponential curve.
What we're seeing now is massive parallelism, which means if your task is embarrassingly parallel, then Moore's Law is very much alive and well. Otherwise, no.
One of my favorite dad jokes is that if Smart Water was so smart, why did it get trapped in a bottle?
More seriously, I see this argument all the time: that we are just squandering our advances in hardware by making comparably more inefficient software! Considering that efficiency used to be thought of on the level of minimizing drum rotations and such: the whole point is that we're now working at a much higher level of abstraction, and so we're able to build things that would not have been possible to build before. I for one am extremely grateful that I don't have to think about the speed of a drum rotating, or build web applications as spiders' nests of CGI scripts.
Are there modern websites and applications that are needlessly bloated, slow, and inefficient? Certainly - but even those would have been impossible to build a few decades ago, and I think we shouldn't lose sight of that.
> we are just squandering our advances in hardware by making comparably more inefficient software
> we're able to build things that would not have been possible to build before
We get that not only are we able to build things that weren't possible before, but we can build things that are more inefficient than was possible before.
We can expect in the future to see new levels of inefficiencies as hardware developments give us more to waste.
Without something to balance this out, we should expect to see our text editors get more and more bloated in cool and innovative ways in the future.
It makes me think of fuel efficiency standards in cars.
CPUs are getting faster, and yet paradoxically, performance is worse, especially in the world of web browsers.
The original DOOM ran at 30 fps in 320x200, which meant it rendered 1,920,000 pixels per second with only a 33 Mhz CPU. That's less than 18 clock cycles per pixel, and even that's assuming no CPU time spent on game logic. If DOOM were written today with a software renderer written in C#, Python, or JS, I'd be surprised if it could get anywhere near that level of clocks/pixel.
These days, the basic Windows Calculator consumes more RAM than Windows 98, and that's just inexcusable.
Also keep in mind that the smaller chips get, the more power-efficient they become; so it can actually cost less in terms of both wall-clock time and watt-hours consumed, to execute a billion instructions on a modern device, than it did to execute a thousand instructions on a 1990s device. No matter how inefficient the software, hardware is just that good.
> These days, the basic Windows Calculator consumes more RAM than Windows 98
The Windows Calculator loads a large framework (UWP) that gets shared by anything else that loads that same framework. That's 99% of its resident size. (One might liken this to DOS applications depending on DOS — you wouldn't consider this to be part of the app's working-set size, would you?)
Also, it supports things Windows 98 didn't (anywhere, not just in its calculator), like runtime-dynamically-switchable numeric-format i18n, theming (dark mode transition!) and DPI (dragging the window from your hi-DPI laptop to a low-DPI external monitor); and extensive accessibility + IME input.
I think the more amicable solution here is to just have higher standards. I might not have given up on Windows (and UWP) if it didn't have such a big overhead. My Windows PC would idle using 3 or 4 gigs of memory: my Linux box struggles to break 1.
On a machine that doesn't have as much memory, the frameworks don't "use" as much memory. (I would note that Windows IoT Core has a minimum spec of 256MB of RAM, and runs [headless] UWP apps just fine! Which in turn goes up to only 512MB RAM for GUI UWP apps.)
Really, it's better to not think of reclaimable memory as being "in use" at all. It's just like memory that the OS kernel is using for disk-page caching; it's different in kind to "reserved" memory, in that it can all be discarded at a moment's notice if another app actually tries to malloc(2) that memory for its stack/heap.
> No matter how inefficient the software, hardware is just that good.
Hardware is amazing. Yet, software keeps eating all the hardware placed in front of it.
And my point was that, by every measure, there's no point to worrying about this particular distinction: the more-powerful CPU + the more-bloated code has the same BOM cost, the same wattage, the same latency, etc. as the microcontroller + less-bloated code. (Plus, the platform SDK for the more-powerful CPU is likely a more modern/high-level one, and so has lower CapEx in developer-time required to build it.) So who cares?
Apps running on multitasking OSes should indeed be more optimized — if nothing else, for the sake of being able to run more apps at once. But keep in mind that "embedded software engineer" and "application software engineer" are different disciplines. Being cross that application software engineers should be doing something but aren't, shouldn't translate to a whole-industry condemnation of bloat, when other verticals don't have those same concerns/requirements. It's like demanding the same change of both civil and automotive engineers — there's almost nothing in common between their requirements.
If I could easily upload my code to this smart bulb and leverage it either for creative or practical endeavors then I wouldn't necessarily consider it wasted potential.
But here you have this bloated tech that you can't even easily leverage to your advantage.
I do agree with the general point that the progress we've made over the past few decades is mind blowing, and we shouldn't forget how lucky we are to experience it first hand. We're at a key moment of the evolution of humankind, for better or worse.
Subjective. Questionable to you. Nobody is bloating dd
There is definitely bloated software but it's not a huge issue. If it were, then the customer would care. If the customer cares the business would care.
What is the minimal computer you can both compile and run Doom on?
That would be WebGL and Javascript, I presume?
I tried running a Quake port in that vein, but sadly none of the computers I own were able to play it without stuttering.
DOOM ran in 320x200 at 30 fps on a 33 Mhz CPU, which gives it less than 18 clock cycles per pixel rendered. I doubt Python could get anywhere close to that.
It was certainly impressive, but it was aso a case of often design having to give way to such hacks, such as the fact that many older first person shooter games had to have their entire level design work around the idea that the engines could not support two walkable surfaces vertically above each other for performance reasons or the famous Duke Nukem 3D “mirror” hack.
An ESP8266 microcontroller can be bought in low quantity for less than a dollar. I means sure any cost reduction at scale is meaningful, but at that point I don't think the silicon is the expensive part at that point. It just doesn't make sense to give WIFI devices anything less than that performance, the gains in silicon space will be meaningless and you'll spend more managing that than anything.
That works both ways though. The highly qualified software devs did indeed squander some of it away.
But I'm a rather bad dev that writes really inefficient code (because it's not my primary concern, I'm not a programmer, I just need custom software that does the things I need done that can't be done by software other people write).
All this overpowered hardware allows my code to work very well.
I've been in situations where I could pick between "learn to program properly and optimize my code" or "throw more hardware at it" and throwing more hardware at it was definitely the faster and more efficient approach in my case.
"A few" is underselling it somewhat. I would posit that >95% of popular modern websites contain functionality that was not plausible in 1996.
The person operating the console only has to click an option or fill in some text field, same as 20 years ago. But today, with added slowness.
Knowing the amazing advances in hardware in the meantime, this hurts me.
Very much to their credit, though, the Trådfri hub doesn't depend on a cloud service just to operate. If that ever happens, thus endeth my foray into smart lighting. I've put my foot down: if it needs Somebody Else's Computer to function, I don't want it.
Ads.
Oh, and spying/tracking.
The future sucks.
Such a machine would be nowhere near as efficient as a CISC computer in terms of work per clock cycle, but what if our "silicon" in the future can run an almost arbitrary frequency? We would be able to emulate any instruction set natively in real time. The perfect FPGA.
What now, you might ask. Well, RGB brain implants running Quake, of course.