FYI: No JIT on Windows 8 for ARM
freelists.org
freelists.org
If not, why do we all of a sudden care about this now?
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 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.
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"
But specs and requirements for both are now very firm, and comment on those (which is what we have here) is completely legit.
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.
Way to set expectations... mine at least.
Edit: See also this: http://www.zdnet.com/blog/microsoft/microsoft-desktop-apps-w...
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.
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 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.
Hard numbers would be more interesting.
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.
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.
But 1. the mobile app market was even more locked down before Apple entered it and 2. Apple is the media's darling.
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.
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.
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.
Are you referring to performance?
If so, WinRT supports C++.
http://msdn.microsoft.com/en-us/library/windows/apps/hh44156...
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.
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.
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
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.
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.
What (security?) do you give up by moving to developer mode?
not without it's usual validation which makes it non trivial to implement.
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.
But if Windows dies, what then can replace it? Will we see another XP, except one that goes unreplaced? Microsoft making a U-Turn?
Or possibly, another Operating System? Android? Chrome OS? Ubuntu?
Whatever happens, Windows 8, its launch, and aftermath will certainly be interesting, "good" or not.
Most people buy a new PC every few years and it comes with some sort of OS and it looks different every time. Whether that was XP or Vista or 7 or 8, they won't know. And consequently, we can complain all we want, but if it comes pre-installed and IT departments like it, it will work.
Don't get me wrong, Microsoft will die eventually (just like we all do), but it will be a gradual, less painful process. Maybe this is one of their last serious stabs at something exciting. But they will die of obscurity, not concrete failure.
There are real alternatives today, including not upgrading. Microsoft may come to regret making Windows 7 as solid as it is.
Ten years is way too far in the future to place any bets.
WinXP + IE6 is still an option and it has been 10+ years already. If windows 8-9-10 sucks, then win7 can easily carry on for as long as hardware manufacturers keep shipping compatible drivers; and if windows 8-9-10 sucks, then they can easily do it for dozens of years.
I guess what I was trying to say was that Microsoft seems to be losing right now and they might just die in the somewhat near future. However, this will not be the direct consequence of a bad version of Windows or of people skipping a version. We have seen that before. People always complain about change, especially about changes in something they don't understand but have to use anyways. So people complaining about a new version of Windows is not interesting.
I see Ubuntu becoming more popular and more consumerized, with popular games arriving for it. I see ChromeOS and Android gaining a bit of laptop market share. I see Macs gaining more market share, too. Governments and enterprises will increasingly use Linux or cloud alternatives.
The point is, Windows will not have the monopoly it had for 15 years, and that's a great thing. We've been waiting for that for a very long time.
I'll take native development any day.
tl;dr: no.
I see this as another instance of the Windows Rule in effect: Skip every other release.
I will say I'm in the minority of people that likes the way Metro looks and acts even on the desktop. They'll get more apps come release time. Keep in mind, what we've all played with isn't even beta quality software.
You sure? They've had the Developer and Consumer preview out, yet they still have a practically empty store, and have been literally handing out checks to try and fill it.
Intel's halfassed efforts with the Atom really FUBAR'd the netbook. What a dog those computers are. The initial rabid enthusiasm that people had for Netbooks just set them up for a bad experience, which reinforced their prejudices against PCs predisposed them to flee to lag-free experiences like the iPad.
Of course, that's some mighty overhead for "just one" platform.
I don't mean to translate "mov eax, ecx" to the CLR bytecodes of "ecx = eax;", but targetting CLR as kind of a CPU in its own right (with whatever capabilities it has).
Just use a language has implementations that target native code or MSIL, problem solved.
A professional developer makes use of the best tool for the job, among the set of available ones.
The entire focus of WoA is pretty much Metro-style apps, with Office on the desktop as something on the aside, so why would it matter that another browser can't place itself into the desktop? But if other browsers are actually going to be disadvantaged backend-wise, then that's something to worry about.
> Now, we're basically getting iPads, but with bright cyan colors and a chronic inability to fit huge 128pt words on one page. "MUSI" "PICTUR" "SOCIA"
Looks like you're totally ignorant of the Metro UI design philosophy. Have you actually tried a Metro device or are you looking at screenshots?
This creates a catch-22, where corporations use Windows, so corporate software is written for Windows, and in turn, anyone who uses corporate software has to use Windows. If I send someone a .doc created in LibreOffice and they open it in Word, who knows what will change in the conversion. If part of your company goes open source, the entire company has to as well, for the sake of consistent performance.
We're talking about Windows RT here, which is targeted at portable ARM tablets with high battery life. Your legacy app won't run on ARM anyway.
Oh,is that why the iPad is such a big failure compared to Android tablets?
/s
Will Microsoft achieve success by doing all of the same things as Apple? How has that worked out for them thus far? Will that cargo-cult bring them iPad-like success?
Apple is doing a pretty good job of being Apple, and Microsoft has done a really bad job trying to be Apple. Microsoft is bringing all of the same disadvantages, but few of the advantages.
Microsoft has never been an innovator. Their strength has always been that by corporate standards they were on the side of openness, of choice of software running on commodity hardware that everybody could use.
If they start copying the vile behavior and not the design innovation, I think they'll end up on a downhill slide.
Mozilla is also 100% within their rights to complain that their implementation will be hampered in a way that IE will not be.
The whole situation reminds me of how Microsoft Office and other Microsoft apps got in trouble for using undocumented Windows APIs ( http://www.groklaw.net/articlebasic.php?story=20070208195343... ), except now they are upping the ante from undocumented to inaccessible.
* Windows RT CLR is a port of the full CLR, not the CF
There's always GCJ (http://gcc.gnu.org/java/)!
In the worst case you should be able to write a driver using the DDK (some drivers will absolutely need dynamic code) to circumvent the problem.
More likely there are things in the huge, in flux and poorly documented API that will let you do it.