Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That's an intriguing concept, but it seems like it would be a headache to implement, from a software perspective. Unless I'm mistaken, if you wanted this low-power chip to perform windows updates, you would need MS to provide an ARM compiled program to perform x86_64 updates. Or you'd need a third party to do it somehow, which sounds messy. The same would apply for anything else you wanted to do that's more complicated than putting files in fixed locations. I suppose it could be relatively easy to just do the downloads, and leave installations/updates for when the main chip kicks in.

And the fileserver concept is pretty neat. Rather than having a separate low power machine that you send files to, your main PC could act as a fileserver using separate software while fully powered or in low-power mode. I'd buy that, if only for the novelty.



It is a fascinating idea. I'm wondering if something like an ARM build of Windows 10 S could already support an ARM to x86_64 handoff with the main kernel/OS/UWP apps running immediately available in low power scenarios and where it might pass things of to Win32 on ARM emulation instead pass things to an x86_64 core? Then from there build out more hand-off capabilities for power hungry processes or performance-hungry apps (like Xbox Game Mode)?

To some extent, I would be surprised if there aren't teams at Microsoft exploring such crazy hybrid notions already, if at least for options for future Xbox or Surface hardware. Recalls to mind Microsoft already experimented with a notification platform of a low power CPU screen coupled to a Windows device way back in the Vista timeframe [1].

[1] https://en.wikipedia.org/wiki/Windows_SideShow


The fact that programs are shipped as machine code bytes has plagued computing since the beginning. Security issues and backwards compatibility shackles abound in this model.

The obvious solution to these sort of problems problems is to send programs in some intermediate or high level form, with compilers for local CPUs being part of the loading process. While some successful environments have already done this (notably OS/400, and the ever-up-and-coming Mill CPU), there's just still too much momentum in the popular OSes for the "simpler" binary model.


It would absolutely require some level of Windows/OS support.

While you could definitely allow apps to run arbitrary ARM code on it, I also think it would be quite feasible for the hardware or the OS to expose a simpler API as well with basic functions like 'queue download' that would simply take a protocol, a URL, and a disk location.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: