Windows on Raspberry

https://wiki.postmarketos.org/wiki/Devices

Microsoft botched this circa 2012 by only allowing store apps for the RT tablet but I think they reversed this. It was always a product decision rather than a technical one, though. (I don't know why exactly, but they didn't want to let people recompile old software.)

Windows doesn't about the thermal limits Apple put into place in their devices, so just treats it like a regular old laptop: boosting with fans turning whenever it needs to. However, it needs drivers to read the temperatures from the device and as far as I know, the Windows driver for reading those on Apple hardware aren't great (if they're available at all). This means Windows on a Mackintosh will always perform worse, because it doesn't have the same thermal information input as macOS has.

You occasionally see Windows on stuff that runs full-size PCs "embedded" into a device, but then typically just normal Windows nowadays.

It's somewhat cool, but will need much better hardware support, or higher end hardware depending on the purpose.

If you aren't targeting something with end-user interfaces or consistent display needs, Linux is generally a better bet, and you can pretty much use the same languages and tooling.

For embedding, about the only more painful use of linux is when you need a gui display, and even that can somewhat be worked around... testing and isolating updates is probably the larger cost multiplier vs. windows in terms of long term support.

The other piece is that there are 10 years of raspbian questions and answers on the internet. You have a problem, then someone else has hit it.

Could you explain why Windows could make things better? As I get more IOT things I have gone more and more basic and had great success. I’m not suggesting that flashing ESP32 chips is the way forward for everyone, but it certainly has its merits.

If the rough edges could be removed (imperfect flash software, the need for multiple guides, understanding pin layouts and my crap wiring) the basic method is great - name the chip, give an SSID and password, then tell it what sensors it has - flash. It’s a genuine 10 minutes before it’s in Home Assistant.

He was a very capable C# programmer, I think this was the reason for picking it. But over the course of the project he became really bitter and his opinion dropped considerably. Apparently many things that are super easy to do on raspbian were impossible or super hard on Windows IoT. Not regular computing stuff, but integrating with hardware. GPIO, I2C, that kind of stuff.. The kind of stuff that's Bread & Butter for IoT in other words ;)

I can't validate this as I've never really used it myself other than booting it once. But I valued his opinion highly.

As long as Microsoft insists on force-feeding OS updates without permission from either users or developers, Windows is a non-starter for embedded online devices that need to maintain any semblance of reliability. For better or worse, they have taken Windows out of that particular market.

I think it’ll drive up unit cost by few hundred dollars on top of tenfold degradation in experience, so my gut feeling is it’s completely disconnected from reality.

That said Microsoft seemed to think the way you think at least at one point, so you’re not alone at all, and it’s interesting where the misunderstanding come from.

IoT is generally something you should regard as a entrypoint into a network as much as desktops, servers, NAT broadband routers, APs are.

Flash and forget is a dangerous thing, and especially so if all you wanted was an IP connected thermostat.

If what you wanted was a thermostat with some sort of video output, then why not use an Arduino with a i2c serial ESP8622 or ESP32, or maybe an Orion Omega, note that the thermal output and voltage requirements increase. With smaller micro controllers and a serial connection you have mostly what you need, rather than a full-fat interface. The simplest solution is most likely the right one.

Don't include a GUI and all that other warm and fuzzy stuff of MS unless it is needed on what could be an entry point to a network or if the IoT is infrastructure.

There are things that could make IoT a very dependant piece of infrastructure. Suppose you deliver cargo. Suppose that some of the cargo is temperature dependent and you use a new IoT Rasp Pi 4 with Windows to control the refrigerator as your manager thinks money can be saved compared to old, in-person managed thermostats.

Fluorouracil, a chemotherapy treatment, MUST be kept at 5c +/- 3c, otherwise patient health and treatment can be compromised. It also has a short shelf life, if your goal was to know how long it has been in transit (simple BBE stickers are probably better, but your concern as a consumer could be forgery).

Something like IoT can help, and can hinder here, if you were to do end-to-end tracking of the supply chain, you could know it's whereabouts. If you were a malicious actor, you could do things like stuxnet, report that the thermostat is just fine, when really the shipment is at room temperature. Not that hard to imagine if you know where the shipments are from and your goal is to destabilise.

Is a good old-fashioned thermostat better here? Maybe. If you need to remotely control something, I'd prefer slightly harder to update in the field, Arduinos/ESP than the risk of it being an entry point to a network in the wild.

Many network infiltrations originate at the desktop. I'm classing Windows Server as desktop, because, well, it has a desktop out of the box. It is not a server OS. Real servers are not the entry point, despite their proximity to raw internet.

How so? IMO GNU/Linux is a very good IoT os, especially since the GPL compels companies to release firmware source so the community can patch the device after the company abandons it.

Cheaper on ebay. First sale doctrine covers you.

Bandwidth for USB GPIO: 8 kHz if you're lucky and there are no other devices on the same controller. Bandwidth for the direct GPIO: up to tens of MHz.

RPI's that windows, are not cool. They need cooling.