But personally, I would like to see improvements to smartphone linux desktop environments like Phosh/Plasma Mobile/Lomri for Raspberry Pi as this would enable anyone to plugin a GSM module, download some 3D printing smartphone designs, build themselves a nice and secure smartphone.
Sorry, I meant smartphone interface like Plasma mobile, Phosh, Lomri for Raspberry Pi; Desktop environment terminology as with Linux on desktops could be wrong.
Right now, you can use traditional desktop environment like LXDE/MATE with PostmarketOS on Raspberry Pi but I don't think there's a working smartphone interface for RPi with the projects you've linked[1].
Furthermore, Convergence feature of UBPorts (Ubuntu Touch) via Lomri helps our phone to be used in Desktop Mode. Here is my video demonstrating it[2].
Wouldn't be that still kinda limited to what Microsoft Store provides in terms of software for everyday use? Because from what I remember, that translation feature on Windows which minces x86 to ARM is still away from being finished.
I also wonder - which perhaps might sound bit naiive, if is there a chance that ARM will enter on PCs and we'll see combined architecture motherboards or at least some daughterboards with these processors; kinda similar to accelerator cards from Amigas.
Win32 is a C API. You don't need to emulate x86 for it. It's a recompile.
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.)
I disagree that the first point is major. amd64 has been a thing for a long time. Compilers and kernel implementations have also changed, so x86 windows has been a moving target as well. Will people need to test and possibly debug after their recompile? Sure. Will a lot of such code work fine on the first try? Also yes.
Curious if you have a source on the x64 part I can read up more about?
Mainly wondering if I buy an ARM Windows device today, is it just a matter of upgrading Windows somewhere down the line for x64 support? Or will I have to shell out for brand new hardware?
Certainly performance wise - better than expected, but gets down to what DX level the game is using, Rpi's not known for much graphics grunt. Though these two examples running well on the rpi4 with windows 10, better than you'd expect and kinda impressive.
I don't know much about it, so this has me curious. The specs say the BCM2711 has an integrated Videocore VI GPU. Are there just not drivers, or what about it makes it "not working"?
I have an old Windows mini PC, which is based on a single core Atom CPU. Clicking the Settings button will take multiple seconds to launch the Settings app. I wonder if Windows on the RPi will fare better.
RPi4 has up to 8 GB RAM. I think any RPi with anything better than one 32-bit LPDDR4 memory channel would fare better... at everything. I'd like to see at least a 64 bit wide memory channel if nothing else.
I wonder how well this runs in terms of CPU, i have a Macbook Pro and i don't hear the fans very often. Except when i run Windows 10, the fans frequently blast at the maximum level...
There's a reason for that, macOS loads a specific fan curve that prefers silence over performance, only kicking in a the last moment before the CPU overheats. This focus on silence also costs them in performance, but as long as the laptop is fast enough for most people, the raw performance probably doesn't matter to them.
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.
This sounds completely made up.
If you have more info than pure conjecture, please share.
I would wager the sensor drivers for Windows were written by apple.
"If it chooses to, Apple could resolve or mitigate the issue with a firmware update that kicks in the fans sooner"
Stuff like this is why I keep saying that Apple is a fashion company, not a tech company. Or more accurately, they're a company that makes technology fashionable.
But apparently fan noise isn't fashionable, so they try to eliminate it, even if it comes at the cost of performance in what is supposed to be a performance-oriented configuration.
Bootcamp is intentionally gimped by Apple. If your Mac has an GPU and an integrated GPU, OSX can switch between them while in use to lower power or heat when no acceleration is needed. Windows, however, will only ever see the GPU, blasting it on full power decreasing battery life and making the computer hot. The windows drivers for the trackpad are really, really bad. The fan control in Windows seem off the charts. So don't judge windows based on running it on a Macbook, I guess. It's an abysmal experience, unfortunately.
You really can't judge Windows performance by how it runs on a Macbook Pro. Try it on a Surface or a Lenovo Thinkpad or Yoga and it will be a much better experience. They just don't have access to the Mac's proprietary hardware fan and power management controllers.
That's because bootcamp "conveniently" doesn't give Windows the same level of control that MacOS gets when it comes to running the fans. Nothing related to actual cpu utilization.
No, but on native systems you don't get Bootcamp Utilities installed, which makes the two setups rather different stories. A choice was made not to give Windows reduced capabilities, despite making sure that Windows gets augmented to work with your specific machine's hardware.
The only time I've ever heard the fans on my Mac Mini is when I run Windows Update. The strange thing is even though it is stressing the machine it's still slow at updating.
Does anyone have more experience with Windows on IoT devices in general? I'm curious about this - it seems like it could be a real game changer in general for IoT. But if it is already available and not actually doing much game changing, I'd be curious to know why.
> it seems like it could be a real game changer in general for IoT.
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.
You might want to checkout https://prismos.dev
Full disclosure: This is a project I built addressing the exact same problems,
its open source and currently more focused on building an easy to approach platform for developers and students new to the hardware scene
I knew someone at my old makerspace who was using it for a final thesis project several years back, when it was just out a year or so.
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.
Embedded Windows has been a thing for a long time and has steadily become less and less relevant over the past decade or so, with many users slowly migrating away. It is more expensive and basically unsupported by Microsoft and hardware makers, while adding very little unique features. I've basically only encountered it in "We stop support for Windows" announcements, "Here's how to make migrating away from it a bit easier for your devs used to it" and "We need to migrate away from Windows, can you help?"
You occasionally see Windows on stuff that runs full-size PCs "embedded" into a device, but then typically just normal Windows nowadays.
> Embedded Windows has been a thing for a long time
Mostly in Windows CE palmtops, based on a miniaturized version of the actual Windows 9x interface. Not sure it's ever been a thing in real embedded workloads.
Well, considering if it's an embedded/utility device with a screen (that isn't a phone) there's a greater than 50% chance it's running some form of windows, I wouldn't consider that statement true at all.
-- edit below
For examples, the displays at restaurants are about 50-50 linux/windows... airport displays are > 50% and same for billboards... Bank ATMs are almost all Windows, which are all over the place.
-- edit 2
I don't think that linux doesn't have a place, and for non-display embedded devices is definitely the leader. I was mainly pointing that windows ce portables were not even the biggest point of windows embedded use, or even that it wasn't widespread.
To add to the list of people pointing out that you're mistaken, I'll add that Windows CE was used in Ford's first and second generation Sync vehicle infotainment systems. It was also the basis for one of the two SDKs for the Sega Dreamcast.
I find it interesting that so many people point out that some sort of Windows OS WAS used by vendor A, B, or C.
Yes, a lot of enterprises tried Windows in embedded use cases in the past. Presumably companies will keep trying it from time to time in the future too.
But the fact of the matter is that, as the usecases nature vendors migrate to Linux.
Also, saying that there were multiple parties trying to use Windows does not mean that Windows has significant market share in that domain.
How are other examples not a valid counterpoint to the claim that it was "mostly Windows CE palmtops"? They don't claim that it is still overly popular or not being replaced.
My experience in general with windows is that you need GUIs everywhere to configure stuff, whereas linux is text config first. I just deployed 20 pi's at work for a project and remote management on raspbian is fantastic. My BOM for the project is $300 and the previous system's BOM was $3k. Love raspbian.
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.
Sure. It mostly isn't a first class customer, however. We may never have "The Year of The Linux Desktop" because of this, but command line configuration in Linux is the first class use case.
I don't agree with the comment you responded to but all server tools for Windows are configured via Powershell, and the GUIs just use the PowerShell Apis.
They started migration back in server 2008 or 8r2 to support Headless/Azure.
The GUI is literally a second class citizen in Windows Server these days.
Fantastic. My experience is that when I have an issue on Windows my searches give me a ton of GUI screenshots, but in Linux I get text file edits and terminal commands. However I may be doing it wrong.
Well, if it's controllable through a group policy. Otherwise you'll quickly regress to myriads of registry key incantations. Some things take hours or days to figure out how to configure.
Will it take more time to setup and configure the Pi's than with the $3k system? If not, great! If so, then unless money for a hardware budget is the primary constraint, your time has to factor into the price as well.
Windows on IoT, no. Windows as a risk, yes. Apologies if this seems rant-ish, but the idea has touched a nerve.
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.
It's used in a lot of embedded scenarios... and will really depend on your use case. The raspberry pi will need a lot more/better hardware support if Windows is going to be a viable option. Video support is poor, onboard audio and lan aren't yet supported.
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.
Could you elaborate a bit on why do you think full Windows on IoT is a game changer...
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.
Yeah I also find this take confusing. The main USP for Windows is that it runs proprietary software which has been captured through vendor lock-in. Even if you are somebody who just likes windows for some reason, I'm not sure what the value-add would be for a machine with no UI
I am thinking about how a machine might expose a UI to an AR viewer of some kind. So, the scenario is: you throw on a pair of AR glasses and open the network-viewing app. I imagine being able to see UIs for thermostats, media players, audio equipment, etc. I suspect a Windows IoT device might get one closer to such a goal? Maybe not?
How would a windows device be closer to that goal? All you would need to make it work is some kind of standardized protocol for how IOT devices advertise data and controls.
The only thing Windows would "do better" would be adding layers of proprietary software and telemetry which would probably reduce performance and make it harder to work with.
> I'm not sure what the value-add would be for a machine with no UI
Educational lock-in. The RPI is a device for learning about computers. MS directly target the classroom at the moment, get people locked in early with online accounts, and then progress that into workplace familiarity.
I don't think employers want to spend the money to educate staff on using a Ubuntu-based desktop, even though that has a proven lower TCO.
Get them when they're in the class room. The best time to plant a tree is twenty years ago.
Does anyone have more experience with Windows on IoT devices in general?
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.
My opinion: I think it won't catch on as windows is too bloated and doesn't bring much advantage to the table. As a matter of fact i got a RPI just to have a standalone linux box.
Proton is an amazing project. I hope it will lead to more Linux Steam users, and consiquently more 1st party support, because I'm sure MS will do everything in their power to make Proton less effective and reliable than it is today over time.
> it seems like it could be a real game changer in general for IoT.
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.
Let's just say that unless you're under a non-technical (e.g., political) mandate to use an embedded version of Windows, I cannot think of a good reason to seriously consider it.
It's not much better/worse than any modern linux desktop distribution... My biggest issues with the linux side usually come down to dealing with the one off issues that seem to popup on major updates... and never, ever try to use brand new hardware for you daily driver with linux unless you are prepared to deal with said frustrations.
Very cool, although a win10 minipc would probably make far more sense for people who specifically need a tiny windows 10 computer, especially as they basically cost less than what a copy of windows 10 pro costs.
(A fully functional fanless atom x5-Z8350, 4GB ram, 64GB flash, Win10 pro x64 Mini-PC will set you back $139. A copy of Windows 10 pro x64 is $168...)
And I know, some folks might say "why not a lattepanda?" to which the response really is "because that costs three times as much". Sure, you don't get GPIO pins on a minipc, but given that you can just buy a $10 data acquisition module that connects via USB, and that you can talk to using UART... that's hardly a problem?
> Sure, you don't get GPIO pins on a minipc, but given that you can just buy a $10 data acquisition module that connects via USB, and that you can talk to using UART... that's hardly a problem?
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.
So, not exactly a problem for anyone who wants to use a raspi but also windows? If you need MHz of GPIO speed, you're basically in arduino land now, and raspi+win or a minipc+win doesn't make a whole lot of sense. But hey, you can you also just connect an arduino to the minipc and get the best of both worlds.
Of course you can, but this article is about folks who want to use Windows (for whatever reason). If you want to use "the raspi" as a controller, there is zero reason to look for a way to put Windows on a tiny board. A standard raspi already does what you need.
I got a copy of Windows 7 Ultimate for free from Microsoft as part of a developers conference. Then I upgraded to Windows 10 Pro for free. I bought some Windows 7 upgrades and 8.0 upgrades that convert to Windows 10 as well. Microsoft has a good upgrade policy and the upgrade versions are cheap. I bought some when Amazon had a sale on pre-orders of 8.0 upgrades.
I bought my Win10 Pro key from a grey market site for like $10, so I figure it's likely an illegally sold volume license copy. Yeah, I totally acknowledge that it could get voided, but I know several other people who have bought their Windows key from these types of sites, and none have ever had a problem.
As a customer, the question of the legality of the license key is not my concern.
I purchased it, Microsoft checked it, while knowing my IP address, and decided it was good to go. The fault is theirs: if they don't want volume keys to work outside some markets, add some limitation like geolocalization.
But personally, I would like to see improvements to smartphone linux desktop environments like Phosh/Plasma Mobile/Lomri for Raspberry Pi as this would enable anyone to plugin a GSM module, download some 3D printing smartphone designs, build themselves a nice and secure smartphone.