Hacker News Reader

Comment by wyldfire | Hacker News Reader

I look forward to learning more about this product. I love that we're moving non-x86 into mainstream consumer products like this (and not limited to low-end chromebooks, e.g.).

ARM SoCs lack the backward compatible x86 BIOS-style bootstrap. This is great because it's kinda crazy to think about booting into stuff like MBR, real mode, etc in 2017. But this is bad because without good standards it's really tricky to have a generic installer for another OS. Also, all or nearly all ARM SoCs have signed bootloaders. Great: less fear of a rootkit/virus hiding in my system. Awful: often used to protect subsidies or other business model hijinks; can't install an alternate OS.

View on HN

>Awful: often used to protect subsidies or other business model hijinks; can't install an alternate OS.

And there's the rub. Microsoft forbids manufacturers of ARM-based Windows devices from allowing customers to disable or customize secure boot.[0] I doubt they'll change that going forward.

>On an ARM system, it is forbidden to enable Custom Mode. Only Standard Mode may be enabled.

[0] https://docs.microsoft.com/en-us/windows-hardware/design/com...

Shim is signed with microsoft key, does it still require custom mode for booting?

Yes. Shim requires that your kernel is also signed, and also disables support for kernel modules.

And this shows why forcing that in shim was a bad idea. They should have made a version breaking the chain, and allowing to boot unsigned kernel.

No, this shows why (forcing) Secure Boot was a bad idea. Allowing Shim to load unsigned kernels would be equivalent to having it bypass SB in the first place, which Microsoft would presumably never sign.

Yeah, that's my biggest fear for this computer. I would snap up two or three in a heartbeat if I could put my favorite Linux distro on it.

My little 10" ARM chromebook has already left my more powerful laptop gathering dust. It seems like 'just a browser' at first glance, but it becomes so much more when you add a chroot which can launch X sessions into Chrome tabs. These Microsoft ARM machines are encouraging, since they should bring new entries into the ultraportable market, but I think I'll hold off until it's clear that we'll have options with regards to the software.

> My little 10" ARM chromebook has already left my more powerful laptop gathering dust. It seems like 'just a browser' at first glance, but it becomes so much more when you add a chroot which can launch X sessions into Chrome tabs.

So you claim running X sessions in Chrome tabs is better than running X directly?

Well...yes, sometimes.

You could run a WM in a chrome tab, but I prefer breaking out individual programs. Like, I can have KiCAD running in one tab, with the datasheets for parts I'm using in nearby tabs. Or I can just break an IDE out into its own window. It's a small screen, so having the whole browser window dedicated to the program is nice, and you can even use fullscreen mode and navigate with ctrl+[shift+]tab.

ChromeOS has a nice UI. Certainly much nicer than XFCE running in a browser tab.

> Like, I can have KiCAD running in one tab, with the datasheets for parts I'm using in nearby tabs.

To me this rather sounds like one should use another window manager than the default one that usual GNU/Linux distributions install if one has a small screen.

I'm no GNU/Linux wizard, but I somehow expect that such a window manager already exists.

It does, and it's called ChromeOS.

So you claim ChromeOS is a window manager?

I also use this setup.

In fact, ChromeOs acts as a Window Manager, because it deals with how each application is organized in the screen/ shown to the user; in this setup, no Chrome Apps are used (only programs from chroot are used)

tl;dr: It can be thought as a WM, although it isn't one

ChromeOS is an OS. It includes a window manager "Ash". Saying ChromeOS to imply its own native window manager (rather than a generic Linux one running in a chroot on ChromOS) makes sense in context. Or at least enough sense that your question seems more mocking than clarifying.

I mean, there are tiling window managers that are happy to tab windows; I use i3 and do this all the time. Bonus: tiling window managers are a great use of limited screen real estate even when showing multiple windows.

"Disabling Secure Boot must not be possible on ARM systems."

#20 in https://docs.microsoft.com/en-us/windows-hardware/design/com...

Digital restrictions management lockdowns prevent installing Linux.

There's nothing to stop any company from making its own laptops with ARM processors, designing them to run Linux, and pre-installing Linux. You could do it yourself. Maybe this is your chance to become rich and famous.

Not sure why your first thought is to ride on the back of Microsoft's work...

Having access to a large target market gives you advantageous pricing negotiation and support from SoC designers, board manufacturers, etc.

Sure, you could create a brand new electronics brand and try to market it. But it would be super expensive and take a long time to get off the ground.

Which simply avoids the issue I raised. How long has Linux been going?

But you know what you really want. Full fledged linux experience with all the drivers backed by Google for 12 hr battery life. ChromeOS isn't even scratching the surface of how linux can maximize use of the hardware. I mean you expect to actually do productive work on tabs that load javascripts on an ARM machine?

This is lunacy. It will break compatibility with nearly all software out there. From games to productivity apps. Like the stuff I actually use a PC for.

> the new operating system will include x86 emulation, giving it the ability to run 32-bit Windows desktop applications unmodified.

a) only 32bit b) At what speed though? x86 emulation isn't trivial, and arm seems to be sufficiently different in architecture to incur a large translation overhead.

Microsoft has had videos out for a while of their x86 emulation. They have a demo of loading Photoshop CC, and it looks close to native speed, though I notice a bit of window refresh. Looks usable, but I'd like to see more demos.

https://www.youtube.com/watch?v=A_GlGglbu1U&t=80s

Not only that, but if you are making UWP packages (for the windows store? I'm not sure if they are standalone as well), you can ship both x86 and ARM binaries together. I'm probably butchering the details, but the presentation and accompanying HN discussion was interesting[1]. The video is pretty cool, as they demo real running x86 and ARM binaries on the same system, and explain some seriously cool stuff WRT x86 emulation.

1: https://news.ycombinator.com/item?id=14318406

But isn't Photoshop a prime example of a program you'd want to run in 64bit mode? Mo'ram mo'better?

I think Microsoft had been working on emulation for x86 on ARM.

Virtually all modern software vendors already write software for multiple platforms and are leaning more on cloud computing, so porting software to a new platform won't be the nightmare it used to be.

Adoption will depend on the killer features, which is currently "LTE" and "uses less power", neither of which PC users care about, so that's why this is doomed to fail.

As somebody that used a DEC Alpha running Windows NT and x86 applications thanks to FX!32 code translation back in the late 1990s, I think you're underestimating the usability of the code translation solution demoed by Microsoft et al. Sure, it may be Win32-only (at least for now) but if and when these platforms take off more UWP (sp?) applications will be released to take advantage of native performance. This is likely a very viable solution.

Productivity apps are almost never developed in assembly language. They are developed in some high level language, so for each of such language, assuming the Windows 10 APIs are the same (which they WILL be, no need to change them):

- Java

Java applications will not require any recompilations, they will run immediately because they run on a JVM

- C#/VB/F#

Those applications still will run right away because they run in the .NET CLR virtual machine.

- C++, C

These applications, considering they are already using the Windows APIs, should recompile with few changes.

Games, nowadays, are also developed using frameworks. They mostly depend on the GPU nowadays, and the GPU was never x86 architecture either, so no big change there.

Memory model and byte order is enough to add breakage to stuff written in all of those languages.

I believe Java and C# enforce specific byte orders to get around this issue, so I doubt you'll see a problem there unless interacting with C++ libraries.

Not if you're converting bytes into integers, for instance. E.g. https://msdn.microsoft.com/en-us/library/system.bitconverter... - it's arch specific.

Interesting, similar functions in the Java world are always big endian:

http://docs.oracle.com/javase/6/docs/api/java/math/BigIntege...

Seems like a rather poor decision on Microsoft's part. Fortunately rather few things interact with data this way anyways, most serialization formats are text based or include endian information.

> Java applications will not require any recompilations, they will run immediately because they run on a JVM

Except for the native libraries that they depend on.

Lunacy? Nah, the vast majority of software that regular people use is massively I/O bound. For the stuff that isn't (photoshop, e.g.), it will get ported. All of those non-photoshop apps will work just fine under emulation. Chrome and Edge will be ported, they'll work just fine.

I predict that this will have a negligible impact on PC games. They're CPU/memory/GPU bound and will not work well under emulation. They're not likely to get ported. But gamers are not the target market for this product.

In the end it's an hen and egg problem -- you need widespread adoption of the hardware to get software ported, but also widespread porting of the software to get the hardware adopted. And intel/amd will fight hard. As long as they can instill v fear that maybe the program I'm using, or the one I want to use next week/month/year won't run, people will flog to x86. It doesn't matter so much how real that problem is, it only needs to be perceived as a problem.

AFAIK Photoshop uses the GPU via DirectX, so it should work fine

Microsoft has already shown Photoshop running in the emulation and it boots OK. Don't know how much load it will carry but it will run.

> This is great because it's kinda crazy to think about booting into stuff like MBR, real mode, etc in 2017.

This doesn't happen on UEFI computers, unless you use the CSM.

doesn't UEFI resolve all that?

It does. Complicated in its own way, but better :)

Reply on news.ycombinator.com