Apples to ostriches. WP7 (what everybody else is talking about) and WinMo (like your unlamented Fuze) do share *some* code, but then so do Windows ME and Windows XP (or Win7 for that matter). It's a totally different experience, though (moreso than on different PC Windows versions). WP7 does not, in parcticular, suffer the hangs and crashes so commonly reported in WinMo.
For the record, your info is (half a year) out of date. As of the Mango SDK release, WP7 now officially includes TCP and UDP sockets. Yes, it was idiotic of them to ship without those in the beginning, but they are available.
Unofficially, where I do most of my development, WP7 has a full WinSock stack, but you're not going to get those into the Marketplace. Apps using System.Net.Sockets will and have, though.
Some of it is marketing. Some of it is infrastructure. Some is employee costs (which, assuming competitive benefits and work conditions with the rest of the industry, are approximately three times the salary alone once everything is considered). I think a few hundred people is actually quite a reasonable estimate, and that's a very large chunk of that cash right there.
Generally, good point. One minor nitpick though: IE9 came out well before even the first previews of Win8. The Win8 preview uses a beta version of IE10, which will be released before Win8 is. Microsoft has (in the last year or two) increased the release speed of IE dramatically - not to the ludicrous break-neck pace of soemthing like Firefox, but to a speed significantly faster than major OS versions. The two appear to be completely de-coupled right now.
Additionally, the only real reason IE6 has lingered so much is people who can't install the upgrade - either because they're on a corporate machine and IT says "we only support IE6!" or because they're using pirated copies of Windows. Unless people are rejecting or blocking the update, it should have been automatically pushed long ago.
Agreed. I would really, *really* like to give The Big Bang Theory a try. A lot of my friends recommend it, and in transcriptions or summaries, a lot of it sounds fantastic.
Then I hear a laugh track, and I turn it off immediately. Who the hell wants to hear that?!?
Eh, I'm fairly impressed that a jetpack can fly in formation with any fixed-wing jet aircraft. Yeah, they're only a little above stall speed, but most manned aircraft even close to the size of that suit's wing can't reach 100 knots at all, much less 180.
As for the distance, remember that his suit has very little mass to withstand turbulence. Sure, it would be cool to show him nestled between the two planes or soemthing like that, but it would also be extremely dangerous, especially since if something went wrong he's already at max power and they're already at min, which limits the maneuvers either can make. Flying around them close enough to see the pilots is already one hell of an accomplishment.
According to TFA (crazy, right?) they're flying at "just above stall speed" and the jet-suit is at full throttle doing 120 - 180 MPH. So yeah, it's not like the jets couldn't have left him completley in the dust without really trying, but it's still damn impressive that he can keep up at all. I mean, that's a guy strapped to a bit of carbon fiber and metal, able to reach the (minimum) speed of stable flight for a fixed-wing jet aircraft.
It's actually a real problem at my former university (a State university, but with one of the top CS programs in the nation anyhow). The place I first heard about it was the exchange program. The Computer Science and Engineering department is one of many there - probably less than 2% of the undergraduates are in the program - and therefore only a small number of exchange students from that program are away at any given time. However, a huge number of the foreign exhange students who come to my university are in CS, and as a result the program has a problem where they end up with more students than they actually admit through the normal admissions process.
It's built into Windows Defender, which can be disabled fairly easily by any user with Administrator rights. Of course, Windows will scream at you if it doesn't detect anti-malware running, but I believe the installers for the popular third-party software already disable Defender during installation so it shouldn't be a problem.
The funny thing is, this kind of thing is exactly the reason *for* Secure Boot (the non-conspiracy one, not the one that Slashdot is typically talking about). If you're using UEFI and you can verify a chain of trust, then you don't have boot sector malware. The fact that boot sector malware is possible on Win8 if you're NOT USING UEFI (because you're using an MBR) is not only obvious, it's the problem that Secure Boot is supposed to prevent.
I wonder, among the peoople who tagged this "irony", how many actually ahve the right of it. The only irony in the situation is that Slashdot is so rabidly opposed to the idea that a headline which is factually incorrect (blatantly obviously so) is posted because it is compatible with the popular bias, despite having no basis in the technology that we nerds supposedly understand.
That all said, there are certainly valid concerns about Secure Boot. It's entirely possible that they outweigh the value of making malware like this impossible. You should know what you're up against when you argue your case, though.
It's not for shipping supplies back to the Earth so much as for providing things that spacecraft and space stations need, with a far shallower gravity well that they need to be lifted out of. Making liquid gases on Earth isn't actually very hard, relatively speaking (storing them outside of lab conditions is a bit trickier but still has been technologically possible for decades). Lifting those liquid gases into orbit is extremely hard, and both severely limits spacecraft payloads and increases the cost of any space mission. If this resupply depot can provide the needed materials for less than the cost of brining them out of Earth's gravity well, then they can be profitable and the entire space industry will benefit.
What "master gear maker" are you envisioning? This is the oldest known example of gears of this design, by a great many centuries. You might as well have said "give the design to a master clockmaker" as though that profession even existed during the millenium in question. Besides, "leftover" is right - it's extremely difficult to engineer a gear system of any complexity, much less at such a small scale, where there's no risk of the gears jamming. The tolerances required to make something like this are incredible.
In any case, FTFA:
It appeared to have an epicyclic, or planetary gear system in it - and those hadn't popped up anywhere else in history for another 1900 years or so.... In fact, it instantly became not only the world's earliest known use of planetary gears, but the first known mechanism that used clockwork gears at all. Various civilizations earlier than the Ancient Greeks had used wooden peg-in-hole gear systems to transfer motion, but this was an order of magnitude more complex than anything before it, and indeed anything for a millennium and a half after it.
Now that we've resolved your ignorance of the general technological level at the time this thing was made, do you understand how absolutely incredible it is?
Well, you could consider using a better compiler, or a better configuration for it. Many parts of compilation parallelize reasonably well, especially if you have a lot of source files. Some things will have dependencies on other parts (which limits parallelism) and some have dependencies on the entire previous stage (which severely limits or prevents it, for that stage).
Besides, unless you're just building a pure build machine (and I doubt it, if your compilation setup is so bad), multiple cores can help a lot in other places too. Things like background syntax checking and storing symbol information can be done in parallel with your workload. Looking up stuff online, or streaming music or even video, can be done without impacting the performance of your dev tools. Many web browsers themselves will get much faster (even Firefox to some degree, since it's multi-threaded even though it still uses a single process). There's plenty of places for heavy workloads to be spread across cores.
Granted, 16 cores is more worloads than I almost ever have, but software is also becoming increasingly parallel. My build system defaults to splitting the workload across 4 cores, some of my games can use 5 or 6 pretty well, and my computer can remain responsive for doing other things too.
Well, Microsoft does provide tools for creating a custom "deployment" of the OS that can include additional installations and slipstreamed patches. I've never used it myself - my very limited time in IT was some years ago and we just used the stock images - but I suspect it would allow you to combine IE10 into the Win7 installer.
I didn't realize IE10 was coming out so soon; I thought it would be more in parallel with Win8, which has approximately no hope in hell of being ready by March. If they want to release it sooner than that, though, that's great; it's a nice browser, and IE9 is already starting to show some age compared to the other (rapidly evolving, perhaps too rapidly in Firefox's case) browsers.
You know, those results would have made an interesting/. article in their own right. I'm amused that IE exactly brackets Firefox (158 more fails from FF8 to IE9, 158 fewer from Firefox to IE10). It's also interesting - and concerning - that Firefox's score doesn't seem to be improving. According to a commenter, even Firefox 10 nightlies still get the same score as Firefox 8. Meanwhile, Opera is racing from behind and will probably claim either first or second place. Of course, IE10 isn't even out yet - not even in beta, so far as I know (the Win8 preview is very much just a preview). They don't have much room for improvement left, but they could improve.
Until a handful of years ago, they didn't track the BSDs and such. Really, though, it makes sense to include them. Aside from the kernel, there's relatively little that actually draws a hard line between Linux and *BSD distributions. The priorities tend to be different, of course, but the range of priorities found in Linux distros completely encompasses the BSDs as well. If you look at the "what packages does each version have?" page for a BSD distro and compare it to a Linux distro, you'll find that most things - server software for sure, developer and admin software most likely, and often even desktop-user stuff like KDE and media players are available on both Linux and BSD. The only guaranteed difference is going to be in the kernel.
Besides, most people would certainly all Debian a "Linux distro" but they actually offer a FreeBSD kernel too. So long as the kernel understands the syscalls used, they're pretty interchangable. Hell, there's even an early version of an effort to port Debian to Microsoft['s Subystem for UNIX Applications in] Windows, though since the kernel isn't open source I doubt Distrowatch would track that.
How does Zypper compare? I've used a number of Linux distros (8?) but the only ones that I did any non-trivial command-line package management on were Ubuntu (.DEB, apt) and openSuse (.RPM, zypper). I'm not aware of any situation where either one worked much better tahn the other, but then, I wasn't trying tricks like overwriting the install directory or anything. I'd be curious to know what the people who have really worked the various methods think.
Actually, the CLI package management system I have the most experience with is pkg (not even sure where it originited, though it's use by netBSD today). I wouldn't call it streamlined but it gets the job donw quite nicely with automatic dependency resolution, and is more customizable than I've ever needed.
What employees? Say "No, it says right here on this piece of paper with your signature on it that I get these shares." When you go home that night, look up local wrongful-termination law and legal counsel, and start updating your CV. If they actually fire you, great - sic the lawyers on them, demand a couple years worth of salary and the current value of those shares (or else just a grant of that many shares, though I wonder how much this will affect their stock price...), and go vacation somewhere nice for a month after laughing your way from the courthouse to the bank.
Hell, if they actually fire you you may have a case for wrongful termination (CA is an at-will state, meaning they don't have to have a reason to fire you, but if they give one that violates a contractual agreement anyhow...). When determining compensation for a wrongful termination suit, you would certainly consider not just salary but also the value of unvested shares.
Sure, you probably have to answer "Yes" to "Have you ever been terminated for cause from a prior employer?" questions. On the other hand, you've got a lot of maney to live on while you find a less-douchy company to work for, and court papers to point to when a prospecting employer asks *why* you were fired.
Granted that this is Zynga and just generally assumed to be run by people with the morality of pond scum, I can't help but wonder if there's some term hidden in the employment contract that allows them to make demands like this? If not, it seems like a pretty blatant case of wrongful termination if they actually fire anybody, and it should be possible to sue for compensation, including the shares you didn't get to vest.
In any case, no matter how it comes out this pretty well cements the question of "under any circumstances, should you consider employment at Zynga?" as "No."
Unless you use it in desktop mode, of course - you know, the way you've always used Windows since at least 95 and arguably forever? Yeah, that's still there. It's not even hidden.It's a big button that says "Desktop" on it. If you launch a Desktop app, it takes you to the Desktop directly - no need to click on the Desktop button.
Also, it's still full multi-tasking (Alt+Tab works as well as ever, although the default behavior for "Metro" apps is to suspend when not in the foreground), you can display multiple "Metro" apps on the screen at once by tiling, and Win8 actually supports more features on multi-monitor.
When I use Win8, it looks like Win7 with a fancier Explorer, a weird Start button, a strange-looking Start menu that's visible for the fraction of a second it takes me to type a program name and hit Enter, and a taskbar that shows up on both monitors with only the apps for that monitor visible on each.
You know, your post would have a lot more credibility if you could spell "virtualization" correctly.
I was making a point about the validity, or lack thereof, of API-based trust boundaries (you know, what the whole article was about). It's entirely possible to make an API-based trust boundary in a language that doesn't support pointers. It's not possible in a language that does. You need something else to enforce your trust boundaries, or you need to accept that they will be vulnerable. Apple is taking the latter approach.
Now, if you want to discuss the former approach, there are some definite possibilities there. Hardware virtualiation for each app running on a smartphone is probably impractical today, though it's certainly a legitimate possibility. There's a great big flaw in the idea, though - the apps need access to some data that isn't in their sandbox (no matter how that sandbox is walled). A common example with phones is the ability to place a phone call. That means there has to be a communication channel between the virtualized client and the host. Every channel you add, and every message that you allow to be sent over that channel, is another potential chance for a security vulnerability.
Of course, those channels have to exist in every sandbox if it's going to be useful. A hypervisor really is one of the better options, aside from the tradeoff between hardware support and software performance. I doubt we'll see it happen soon, though - the OS does a pretty good job of process isolation with only moderate hardware support and relatively little performance cost (switching ring levels being cheap by the standards of a modern CPU). Even on PCs, with support for hardware virtualization and more RAM than most ever really need, widespread use of virtualization as a security boundary between apps used bey a specific user is still not happening. On a phone, with tighter hardware constraints and less hardware support, it's not happening at all.
It mostly comes down to using either apps from big names that are well-known and have a reputation to uphold, or using open-source apps. If I need an app that does neither, I can run it through a proxy and monitor what it connects to via my PC. Granted that the first approach isn't guaranteed, the second isn't guaranteed unless I both check the source and compile it myself for checking against the version in the app package, and the third is a hassle. It's possible, though - and I guarantee that the folks at Apple don't have the time or people to properly verify the apps either, nor do they seem to have the personal incentive to do it right.
In fact, if you're a switch from x86 focus to ARM focus then Mono makes even more sense. Like Java, the binaries use an architecture-agnostic bytecode (CIL, or Common Intermediate Language) which is JIT compiled at first execution, with optimizations speciic to the platform it runs on (well,.NET has those optimizations, I assume Mono does too). No need to recompile your apps when switching platforms, or store multiple copies of an app in the repository to account for different architectures.
Slashdot Mirror
Apples to ostriches. WP7 (what everybody else is talking about) and WinMo (like your unlamented Fuze) do share *some* code, but then so do Windows ME and Windows XP (or Win7 for that matter). It's a totally different experience, though (moreso than on different PC Windows versions). WP7 does not, in parcticular, suffer the hangs and crashes so commonly reported in WinMo.
For the record, your info is (half a year) out of date. As of the Mango SDK release, WP7 now officially includes TCP and UDP sockets. Yes, it was idiotic of them to ship without those in the beginning, but they are available.
Unofficially, where I do most of my development, WP7 has a full WinSock stack, but you're not going to get those into the Marketplace. Apps using System.Net.Sockets will and have, though.
Some of it is marketing. Some of it is infrastructure. Some is employee costs (which, assuming competitive benefits and work conditions with the rest of the industry, are approximately three times the salary alone once everything is considered). I think a few hundred people is actually quite a reasonable estimate, and that's a very large chunk of that cash right there.
Generally, good point. One minor nitpick though: IE9 came out well before even the first previews of Win8. The Win8 preview uses a beta version of IE10, which will be released before Win8 is. Microsoft has (in the last year or two) increased the release speed of IE dramatically - not to the ludicrous break-neck pace of soemthing like Firefox, but to a speed significantly faster than major OS versions. The two appear to be completely de-coupled right now.
Additionally, the only real reason IE6 has lingered so much is people who can't install the upgrade - either because they're on a corporate machine and IT says "we only support IE6!" or because they're using pirated copies of Windows. Unless people are rejecting or blocking the update, it should have been automatically pushed long ago.
Agreed. I would really, *really* like to give The Big Bang Theory a try. A lot of my friends recommend it, and in transcriptions or summaries, a lot of it sounds fantastic.
Then I hear a laugh track, and I turn it off immediately. Who the hell wants to hear that?!?
Eh, I'm fairly impressed that a jetpack can fly in formation with any fixed-wing jet aircraft. Yeah, they're only a little above stall speed, but most manned aircraft even close to the size of that suit's wing can't reach 100 knots at all, much less 180.
As for the distance, remember that his suit has very little mass to withstand turbulence. Sure, it would be cool to show him nestled between the two planes or soemthing like that, but it would also be extremely dangerous, especially since if something went wrong he's already at max power and they're already at min, which limits the maneuvers either can make. Flying around them close enough to see the pilots is already one hell of an accomplishment.
According to TFA (crazy, right?) they're flying at "just above stall speed" and the jet-suit is at full throttle doing 120 - 180 MPH. So yeah, it's not like the jets couldn't have left him completley in the dust without really trying, but it's still damn impressive that he can keep up at all. I mean, that's a guy strapped to a bit of carbon fiber and metal, able to reach the (minimum) speed of stable flight for a fixed-wing jet aircraft.
It's actually a real problem at my former university (a State university, but with one of the top CS programs in the nation anyhow). The place I first heard about it was the exchange program. The Computer Science and Engineering department is one of many there - probably less than 2% of the undergraduates are in the program - and therefore only a small number of exchange students from that program are away at any given time. However, a huge number of the foreign exhange students who come to my university are in CS, and as a result the program has a problem where they end up with more students than they actually admit through the normal admissions process.
It's built into Windows Defender, which can be disabled fairly easily by any user with Administrator rights. Of course, Windows will scream at you if it doesn't detect anti-malware running, but I believe the installers for the popular third-party software already disable Defender during installation so it shouldn't be a problem.
The funny thing is, this kind of thing is exactly the reason *for* Secure Boot (the non-conspiracy one, not the one that Slashdot is typically talking about). If you're using UEFI and you can verify a chain of trust, then you don't have boot sector malware. The fact that boot sector malware is possible on Win8 if you're NOT USING UEFI (because you're using an MBR) is not only obvious, it's the problem that Secure Boot is supposed to prevent.
I wonder, among the peoople who tagged this "irony", how many actually ahve the right of it. The only irony in the situation is that Slashdot is so rabidly opposed to the idea that a headline which is factually incorrect (blatantly obviously so) is posted because it is compatible with the popular bias, despite having no basis in the technology that we nerds supposedly understand.
That all said, there are certainly valid concerns about Secure Boot. It's entirely possible that they outweigh the value of making malware like this impossible. You should know what you're up against when you argue your case, though.
It's not for shipping supplies back to the Earth so much as for providing things that spacecraft and space stations need, with a far shallower gravity well that they need to be lifted out of. Making liquid gases on Earth isn't actually very hard, relatively speaking (storing them outside of lab conditions is a bit trickier but still has been technologically possible for decades). Lifting those liquid gases into orbit is extremely hard, and both severely limits spacecraft payloads and increases the cost of any space mission. If this resupply depot can provide the needed materials for less than the cost of brining them out of Earth's gravity well, then they can be profitable and the entire space industry will benefit.
What "master gear maker" are you envisioning? This is the oldest known example of gears of this design, by a great many centuries. You might as well have said "give the design to a master clockmaker" as though that profession even existed during the millenium in question. Besides, "leftover" is right - it's extremely difficult to engineer a gear system of any complexity, much less at such a small scale, where there's no risk of the gears jamming. The tolerances required to make something like this are incredible.
In any case, FTFA:
Now that we've resolved your ignorance of the general technological level at the time this thing was made, do you understand how absolutely incredible it is?
Well, you could consider using a better compiler, or a better configuration for it. Many parts of compilation parallelize reasonably well, especially if you have a lot of source files. Some things will have dependencies on other parts (which limits parallelism) and some have dependencies on the entire previous stage (which severely limits or prevents it, for that stage).
Besides, unless you're just building a pure build machine (and I doubt it, if your compilation setup is so bad), multiple cores can help a lot in other places too. Things like background syntax checking and storing symbol information can be done in parallel with your workload. Looking up stuff online, or streaming music or even video, can be done without impacting the performance of your dev tools. Many web browsers themselves will get much faster (even Firefox to some degree, since it's multi-threaded even though it still uses a single process). There's plenty of places for heavy workloads to be spread across cores.
Granted, 16 cores is more worloads than I almost ever have, but software is also becoming increasingly parallel. My build system defaults to splitting the workload across 4 cores, some of my games can use 5 or 6 pretty well, and my computer can remain responsive for doing other things too.
Well, Microsoft does provide tools for creating a custom "deployment" of the OS that can include additional installations and slipstreamed patches. I've never used it myself - my very limited time in IT was some years ago and we just used the stock images - but I suspect it would allow you to combine IE10 into the Win7 installer.
I didn't realize IE10 was coming out so soon; I thought it would be more in parallel with Win8, which has approximately no hope in hell of being ready by March. If they want to release it sooner than that, though, that's great; it's a nice browser, and IE9 is already starting to show some age compared to the other (rapidly evolving, perhaps too rapidly in Firefox's case) browsers.
You know, those results would have made an interesting /. article in their own right. I'm amused that IE exactly brackets Firefox (158 more fails from FF8 to IE9, 158 fewer from Firefox to IE10). It's also interesting - and concerning - that Firefox's score doesn't seem to be improving. According to a commenter, even Firefox 10 nightlies still get the same score as Firefox 8. Meanwhile, Opera is racing from behind and will probably claim either first or second place. Of course, IE10 isn't even out yet - not even in beta, so far as I know (the Win8 preview is very much just a preview). They don't have much room for improvement left, but they could improve.
Until a handful of years ago, they didn't track the BSDs and such. Really, though, it makes sense to include them. Aside from the kernel, there's relatively little that actually draws a hard line between Linux and *BSD distributions. The priorities tend to be different, of course, but the range of priorities found in Linux distros completely encompasses the BSDs as well. If you look at the "what packages does each version have?" page for a BSD distro and compare it to a Linux distro, you'll find that most things - server software for sure, developer and admin software most likely, and often even desktop-user stuff like KDE and media players are available on both Linux and BSD. The only guaranteed difference is going to be in the kernel.
Besides, most people would certainly all Debian a "Linux distro" but they actually offer a FreeBSD kernel too. So long as the kernel understands the syscalls used, they're pretty interchangable. Hell, there's even an early version of an effort to port Debian to Microsoft['s Subystem for UNIX Applications in] Windows, though since the kernel isn't open source I doubt Distrowatch would track that.
How does Zypper compare? I've used a number of Linux distros (8?) but the only ones that I did any non-trivial command-line package management on were Ubuntu (.DEB, apt) and openSuse (.RPM, zypper). I'm not aware of any situation where either one worked much better tahn the other, but then, I wasn't trying tricks like overwriting the install directory or anything. I'd be curious to know what the people who have really worked the various methods think.
Actually, the CLI package management system I have the most experience with is pkg (not even sure where it originited, though it's use by netBSD today). I wouldn't call it streamlined but it gets the job donw quite nicely with automatic dependency resolution, and is more customizable than I've ever needed.
What employees? Say "No, it says right here on this piece of paper with your signature on it that I get these shares." When you go home that night, look up local wrongful-termination law and legal counsel, and start updating your CV. If they actually fire you, great - sic the lawyers on them, demand a couple years worth of salary and the current value of those shares (or else just a grant of that many shares, though I wonder how much this will affect their stock price...), and go vacation somewhere nice for a month after laughing your way from the courthouse to the bank.
Hell, if they actually fire you you may have a case for wrongful termination (CA is an at-will state, meaning they don't have to have a reason to fire you, but if they give one that violates a contractual agreement anyhow...). When determining compensation for a wrongful termination suit, you would certainly consider not just salary but also the value of unvested shares.
Sure, you probably have to answer "Yes" to "Have you ever been terminated for cause from a prior employer?" questions. On the other hand, you've got a lot of maney to live on while you find a less-douchy company to work for, and court papers to point to when a prospecting employer asks *why* you were fired.
Granted that this is Zynga and just generally assumed to be run by people with the morality of pond scum, I can't help but wonder if there's some term hidden in the employment contract that allows them to make demands like this? If not, it seems like a pretty blatant case of wrongful termination if they actually fire anybody, and it should be possible to sue for compensation, including the shares you didn't get to vest.
In any case, no matter how it comes out this pretty well cements the question of "under any circumstances, should you consider employment at Zynga?" as "No."
Unless you use it in desktop mode, of course - you know, the way you've always used Windows since at least 95 and arguably forever? Yeah, that's still there. It's not even hidden.It's a big button that says "Desktop" on it. If you launch a Desktop app, it takes you to the Desktop directly - no need to click on the Desktop button.
Also, it's still full multi-tasking (Alt+Tab works as well as ever, although the default behavior for "Metro" apps is to suspend when not in the foreground), you can display multiple "Metro" apps on the screen at once by tiling, and Win8 actually supports more features on multi-monitor.
When I use Win8, it looks like Win7 with a fancier Explorer, a weird Start button, a strange-looking Start menu that's visible for the fraction of a second it takes me to type a program name and hit Enter, and a taskbar that shows up on both monitors with only the apps for that monitor visible on each.
You know, your post would have a lot more credibility if you could spell "virtualization" correctly.
I was making a point about the validity, or lack thereof, of API-based trust boundaries (you know, what the whole article was about). It's entirely possible to make an API-based trust boundary in a language that doesn't support pointers. It's not possible in a language that does. You need something else to enforce your trust boundaries, or you need to accept that they will be vulnerable. Apple is taking the latter approach.
Now, if you want to discuss the former approach, there are some definite possibilities there. Hardware virtualiation for each app running on a smartphone is probably impractical today, though it's certainly a legitimate possibility. There's a great big flaw in the idea, though - the apps need access to some data that isn't in their sandbox (no matter how that sandbox is walled). A common example with phones is the ability to place a phone call. That means there has to be a communication channel between the virtualized client and the host. Every channel you add, and every message that you allow to be sent over that channel, is another potential chance for a security vulnerability.
Of course, those channels have to exist in every sandbox if it's going to be useful. A hypervisor really is one of the better options, aside from the tradeoff between hardware support and software performance. I doubt we'll see it happen soon, though - the OS does a pretty good job of process isolation with only moderate hardware support and relatively little performance cost (switching ring levels being cheap by the standards of a modern CPU). Even on PCs, with support for hardware virtualization and more RAM than most ever really need, widespread use of virtualization as a security boundary between apps used bey a specific user is still not happening. On a phone, with tighter hardware constraints and less hardware support, it's not happening at all.
It mostly comes down to using either apps from big names that are well-known and have a reputation to uphold, or using open-source apps. If I need an app that does neither, I can run it through a proxy and monitor what it connects to via my PC. Granted that the first approach isn't guaranteed, the second isn't guaranteed unless I both check the source and compile it myself for checking against the version in the app package, and the third is a hassle. It's possible, though - and I guarantee that the folks at Apple don't have the time or people to properly verify the apps either, nor do they seem to have the personal incentive to do it right.
In fact, if you're a switch from x86 focus to ARM focus then Mono makes even more sense. Like Java, the binaries use an architecture-agnostic bytecode (CIL, or Common Intermediate Language) which is JIT compiled at first execution, with optimizations speciic to the platform it runs on (well, .NET has those optimizations, I assume Mono does too). No need to recompile your apps when switching platforms, or store multiple copies of an app in the repository to account for different architectures.
s/nothing/no executable code/
It's not terribly well-written, but the gist of it is fairly accurate.