Needing that much horsepower for a screen or single application is a sign that anything requiring Windows should be automatically disqualified.

I used to feel the same way about kiosks, POS terminals, etc. but… if you have an organization whose bread & butter is C# desktop apps and Windows development and they’re looking for, say, qty 10 units, you’ll have a really hard time justifying the training and NRE costs to do anything but Windows.

I 100% agree that it’s not the technically optimal solution. But don’t discount the idea that, given an existing set of people and skills, it can definitely be the local optima organizationally.

Yup, exactly this. I tried deploying such system on low powered ARM systems that could technically do it. It was a nightmare from a support and compatibility standpoint. Also the vendor would support the hardware for significantly less time than Intel would support their NUCs.

The maybe dozen NUC's I needed were not a very substantial hardware cost. You bought a Celeron NUC and they just worked even if you didn't have the most experienced staff supporting them or the best software running on them.

If you're going to be deploying a thousand such systems, sure, of course you shouldn't use NUCs.

> If you're going to be deploying a thousand such systems, sure, of course you shouldn't use NUCs.

I'd probably argue that, barring specific requirements that these might not cover, the NXP i.MX6/7/8 would probably be my default for something like this in volume. ~Motorola~/~Freescale~/NXP have been incredibly great stewards of the platform and provide significant lifetime guarantees for their parts (like 10+ years often). Plus you can generally run mainline kernels on them unless you're doing something special that requires something from their vendor branch.

For just running a screen not only is Windows a massive waste in terms of resources and costs, but so is a NUC. A Raspberry Pi (equivalent) is more than sufficient.

Depends on what the screen is doing. We deployed a system with multiple Raspberry Pi's running Chrome in kiosk mode, each driving a TV showing different data.

For one of them we had to switch from a Raspberry Pi to a small NUC to display a page with 3-6 videos running. The pi could show 1 or 2 videos but with all 6 going, it was very stuttery playback.

I'm actually surprised it handles two videos without issue... It's a good option a lot of the time. When the scalping got bad, I started using the cheaper intel boxes, smaller than NUC but more powerful than rpi and included a case and enough storage.

thanks for not reading my comment as I clearly said many apps do not have ARM or Linux compatibility

There is exactly zero reason for an app whose only purpose is to be shown on a screen to be Windows or x86 specific. It can be due to obsolete development practices or obscure vendor requirements, but still..

The main reason is that hiring a bunch of new developers will be 100x more expensive than spending a little extra on a Windows/x86 machine.

Sure the are...

1. LoB apps need to be run not just on a computer that only shows a screen, but in other contexts, there is no reason to develop a whole new app just for that purpose.

2. Developers who are only used to working with Win API's like WPF, DotNet, etc. or other frameworks that are windows only Why would we want to employ whole new dev team just to maintain that app separate from the apps that run on our Laptops and normal computers

3. Management Tools. If my entire fleet of computers is managed by ConfigMgr and controlled by Group Policy and Compliance Setting why would I want to spin up a completely separate management system like Ansible or something just to control these machines when I could have them integrated into my existing tool set of which my helpdesk and everyone else is trained to use?

I can probably come up with 5 or 10 more reasons