Hacker News Reader

Comment by josteink | Hacker News Reader

Honest question: Is this any different from on iOS? Are you allowed to create native code-generators on iOS?

If not, why do we all of a sudden care about this now?

When the Windows ARM port was announced, many people had hoped for general purpose ARM devices that could replace their cheap laptops. This is not the case, so people complain. Also, the fact that Apple does it doesn't mean it's right. People complain about the Apple situation all the time as well.

They can run Android on them, which is open (I'm typing this comment on a Samsung Galaxy Tab 10.1 w/ keyboard running a CM9 nightly build).

Or they can run real Linux distros ... Fedora, Debian, Ubuntu, Linaro are all excellent working distros for a variety of ARM devices. I have a Trim Server running Fedora 17 which is just one open source graphics driver away from being a nice general purpose low end desktop replacement.

They can't, Win8 ARM devices will have a locked bootloader according to the OEM recommandations sent by Microsoft.

Do "Win8 ARM devices" actually exist? Maybe there are a handful of them, but there are a huge number of ARM devices available right now to buy that don't have locked bootloaders (or are trivially breakable like most Android devices). Who cares about what Microsoft are doing in an already overcrowded market, bringing along a new OS that has no installed application base? There's no reason to imagine that Win8/ARM is going to become an important platform, just like WinNT/PowerPC and Alpha never went anywhere.

They don't really exist yet (in the general availability sense of existence), because no Win8 device really exists yet (Win8 hasn't gone gold). The point is that they will exist, and if manufacturers plan on supporting Win8, they'll have to put the bootloader locks on. Once a Win8 device, always a Win8 device. (Though I'm not convinced at this point that people won't be able to hack their ways around it).

Win8 itself doesn't exist as a product yet, though there are prototypes and previews. Likewise for prototype hardware.

But specs and requirements for both are now very firm, and comment on those (which is what we have here) is completely legit.

Because it sets a very worrying president for the future of computing. This Apple like level of control is the holy grail for monopolists like Microsoft.

They have no market share. Sure, not yet

Don't underestimate just how powerful a draw of having Office BUNLED with the OS will have. It's basically Mocrosoft using their dominant market position in Business software to buy market share for their new OSes.

My personal view : in three years time Microsoft will be the dominant player in the tablet market, closely followed by Apple. In 5 years, they'll have 80% of the market. And Office will no longer be bundled.

I must disagree. If history is any indicator, MS will fuck it up big time.

TBH I do hope they succeed, it will be good for Apple to have REAL competition. I think of Windows on ARM as "iMS" or the "WinPad"

Windows phone 8 will have the same kernel as Win8/ARM, so basically they're merging their mobile and desktop OSs. This will make it possible, among other things, to run a full desktop on your phone (i.e. via a dock with separate monitor/keyboard/mouse).

Are locked devices suddenly something that doesn't get hacked the next day?

You mean like the PS3?

>When the Windows ARM port was announced, many people had hoped for general purpose ARM devices that could replace their cheap laptops

AFAIK Microsoft never claimed this, so I don't see how the complaints are valid.

Also, many people here who are complaining that want to do this are unlikely to be running Windows on those devices and would prefer almost anything else, especially Ubuntu or Android.

The first public demo showed Office running on ARM. I don't think that Metro had been announced at the time.

Way to set expectations... mine at least.

And Office comes _bundled_ with Windows RT.

Microsoft are keen to position Windows 8 on ARM as "just like Windows 8 on x86," when in fact it is nothing of the sort.

> Is this any different from on iOS?

No.

> Are you allowed to create native code-generators on iOS?

Absolutely not (unless you jailbreak of course). In fact, due to this UIWebView are not JITed either and in-application browsers have significantly worse performances than the standalone Safari application or pinned "offline web applications": the latter two are "opted out" of sandbox restrictions and can generate executable code at runtime.

It is NOT significantly worse otherwise nobody would use it.

But lots of apps do use it e.g. Linkedin, Facebook, Reeder, Google Search, iCab Mobile etc and it is not noticeably worse.

Name dropping doesn't prove anything.

When they directly contravene the point "Nobody uses them", it does.

> It is NOT significantly worse

It's a fourfold difference (~2200ms versus ~9100ms on three runs of each) on synthetic benchmarks (Sunspider 0.9.1 on an iPhone 4S running iOS 5.1.1, UIWebView was tested through Instapaper 4.2), which I would call significantly worse.

> otherwise nobody would use it.

Performance is not everything: they are convenient especially given iOS's debatable story for switching between applications (especially back and forth between an application and a web browser).

> But lots of apps do use it e.g. Linkedin, Facebook, Reeder, Google Search, iCab Mobile etc and it is not noticeably worse.

It's "not noticeable"[0] for JS-light websites because... well the JIT is for javascript code, running JS slower doesn't matter if there's no JS code.

[0] it is most definitely noticeable, many sites — especially full-page non-mobile ones with ads shit — load significantly faster using Safari than using embedded UIWebView.

I just downloaded Facebook from the German App Store today and spent some time reading the reviews. The app averages at 2 stars and most people complain specifically about terrible performance. I can confirm this on an iPad 1, FWIW.

Hard numbers would be more interesting.

For Windows RT, is iOS the standard of comparison, or is Windows 8? We were excited that Windows for ARM was going to be a full OS, rather than a mobile one.

Microsoft will be offering tablets with the full Windows 8 via x86 tablets in addition to the ARM ones with Windows RT. In other words, there will be a full OS in direct competition with a crippled/mobile version, and they will look exactly the same.

In the end, consumers will buy Windows RT tablets, expecting Windows 8, only to realize that they can't run their preferred programs such as Firefox or Chrome, and Microsoft and Windows 8 on the whole will come out looking really bad.

Honest question: How do you miss the constant bitching about the walled garden of iOS? The endless articles complaining about the lack of emulators, development tools, and yes even browsers. There was even a period 2 years ago with dozens of articles about how Firefox would never be available for iOS.

The sudden care about Windows 8 now is because it's about to be released and developers are just now starting to work on it.

Yes, this is the exact same situation as on iOS.

But 1. the mobile app market was even more locked down before Apple entered it and 2. Apple is the media's darling.

Yes. Because the media very much cares about native code generators on ARM chipsets.

They sure seem to, for Windows RT. That was the point.

Or more accurately: "2. We've already had threads and threads of criticism for Apple over this subject. They're not changing and we've moved on."

The reason this is worth talking about re: Windows 8 ARM, is that people are optimistic they can still convince Microsoft to take a different approach.

Well, it'd be nice to see Microsoft try to make something that's an alternative to how iOS does things, for one.

For two, this part worries me: "Note that Windows 8 for x86/x64 has similar restrictions for applications distributed via their Windows Store."

I think that's actually a far bigger deal.

I think the pertinent question is, does .NET get to JIT? If so, you're right, same basic situation as iOS.

But if .NET doesn't get to JIT either, then you have the OS vendor's flagship language/platform being crippled by this policy. Apple doesn't support any managed language on iOS (Objective-C is purely compiled ahead of time), and so the lack of JIT doesn't hurt iOS apps developed with the officially supported language.

>...OS vendor's flagship language/platform being crippled by this policy

Are you referring to performance?

If so, WinRT supports C++.

http://msdn.microsoft.com/en-us/library/windows/apps/hh44156...

Yes, performance. And I never doubted that it supports C++, but the point is that it also officially supports C# which, if it can't be JITted, will take a nasty hit. iOS has no equivalent to C#, since the only officially supported languages are compiled ahead of time.

CLR works as it always has, i.e. uses JIT compilation.

Not necessarily- CLR could ngen on install.

I'd actually say this is most likely. You get a hit on install times but after that startup times get much better. Getting fast app launch times are incredibly important.

Another honest question, are alternative browsers allowed on Chromebooks running ChromeOS?

They're not disallowed, if that's what you mean. You flip a switch on the back in order to enable developer mode, and then you can do whatever you want with the machine. There are already a couple of Ubuntu releases for Chromebooks.

What about without flipping the switch?

What (security?) do you give up by moving to developer mode?

"Sure, if you install OS" is always the wrong answer to "Can you run X?"

The answer, apparently, is no, you cannot run Firefox with CromeOS. You can root the device and install it manually, but I'm not sure how well that works.

MS is doing the exact same thing as Apple with iOS Safari and Google with ChromeOS. Not sure why they're evil here, but oh well.

>You can root the device and install it manually

Some clarification is in order here. Flipping an explicitly provided and documented switch is not "rooting" the device. That carries the connotations of hacking around some form of enforced security getting in your way.

And yes you can install it manually without hacking the OS... It's just a form of Linux after all. Go bug Firefox and get them to offer a package that works with the OS if this is too much trouble.

Now, is your problem that they don't go out of their way to add compatability for random third party packages on a cloud based OS? You're not the target market, then :P

>Now, is your problem that they don't go out of their way to add compatability for random third party packages on a cloud based OS? You're not the target market, then :P

I'm not bothered by Google, Apple's, or MS' decision, really. It's just that answering "Can you run Firefox on ChromeOS" with "You can run Firefox on a Chromebook... if you run Ubuntu" just doesn't help anyone that actually wants to run ChromeOS.

Also, I'm aware that it's just flipping the switch. It's not, for example, the same steps you need to do to root a Kindle Fire, but it's still the same result: You still need root access to install(and possibly run) Firefox with ChromeOS.

I'm not sure what else you would expect though. The browser is the operating system in the case of ChromeOS. (It's even in the name!)

It would be like taking a system designed explicitly for Konqueror, for KDE, and all of the specific things that entails, and then turning around and wanting to reconfigure that system to use Dillo or Iceweasel or something else.

Yes, Nacl supports JIT. Mozilla could port Firefox to Nacl so it could run a Chromebook.

not without it's usual validation which makes it non trivial to implement.

> Mozilla could port Firefox to Nacl so it could run a Chromebook.

Not very well, though.

NaCl supports JIT, basically enough for Mono. But it does not support self-modifying arbitrary asm code, which is absolutely necessary for fast JS, PICs need that.

Also, NaCl increases code size significantly due to its sandboxing mechanism.

Finally, NaCl performance is good on x86 but less so on x86_64 and ARM, again due to how it sandboxes (on x86 there are some nice tricks that make it work better).

Finally, you would need to port to NaCl. It isn't trivial, you need to use the Pepper APIs.

So you could run Firefox, but it would need to run JS in the interpreter, it's code size would be very large and performance would be significantly slower than a true native app. It would not be a competitive browser on a Chromebook due to those large limitations. So practically speaking, Chromebooks do not allow other browsers.

Reply on news.ycombinator.com