Apple didn't ban Firefox, and nothing stopped Chrome, Opera, or any of the other hundreds of web browser apps from popping up. Let's be clear: Apple didn't ban web browsers on the app store, they banned Javascript engines that run arbitrary code, a pretty specific restriction, although one that admittedly has wide-ranging repercussions.
Google's (and most other developer's) solution of the problem was to just use Apple's layout and javascript engines and build their browsers around that. Opera's approach was to do the javascript and layout server-side and just do the rendering locally. I believe there was at least one browser that streamed the browser as video. Looking at the different web browsers available for iOS, there is a pretty wide range in user interface design and feature support. iCab Mobile adds gestures, Chrome adds incognito mode and unlimited tabs, etc.
For something like Chrome, which is a webkit browser anyhow, this isn't even a terribly big change. In fact, the only major issue is that Apple doesn't expose their JIT javascript engine to third parties, so third party browsers that rely on Apple's javascript engine suffer from rather poor javascript performance. Hopefully Apple will loosen that restriction.
Facebook and the Open Computer project are not the only people doing this, nor are they the first (although they do go deeper than others, even designing the motherboards themselves).
Two years or so before Open Compute was founded, BackBlaze opensourced their storage pods, which fit 45 hard disks in a custom 4U chassis (they gave away the 3D plans as well). Last year, they updated it to version 2.0, which lets them store 135 TB in 4U for a total purchase cost (in 2011) of $7,384.
Inspired by that (as in, they say they were), Netflix did the "Open Connect" appliance, which is supposed to be open, although I can't actually find the design suitable for case manufacture.
It's pretty clear from the article that his device does not permanently record anything, but simply has a ring buffer that stores the last short while for processing. The victim would not even have had images of his assailants if they had not broken his computer while assaulting him, freezing the ring buffer in place.
Ouya is definitely aiming for something smaller, sure. People underestimate what you can do with that sort of hardware when it's a fixed platform (the thing has almost as much power as a 360), but it's never going to be considered high-end hardware.
That's not to say that you can't do higher end similar hardware. You throw an eight-core Cortex A15 with an eight-core Mali-T658 at a problem, and you're going to have some decent performance. It'll use an unprecedented amount of power for an ARM SoC, but it's within spec. My basic point is that you can scale things up to a certain extent; such a system would already have several times more performance than a Vita, for example.
Because nobody ever ported a game between the XBox 360 (which uses a variant of DirectX) and the PS3 (whose PSGL graphics API is a variant of OpenGL ES) before, right? Many games these days are already running on multiplatform engines that get you the other platforms for free anyhow. Source has already been shown running on Linux, which means any Source game should be an easy port. Unreal runs on anything, and that seems to power most games. Any engine that runs on OS X can probably be adapted relatively easily to run on Linux, since you've already ported the graphics code at that point anyhow. As for the rest, well, every current major gaming platform already has a different environment, but we still see tons of cross-platform titles.
I have. It didn't save money, because of the enormous amount of rework involved. It was a huge disaster that thankfully put the senior management off outsourcing for good.
They didn't do it to save money anyhow, they did it because a big customer wanted a new product, and we didn't have the development resources to pull it off. They hired an Indian outsourcing firm get the extra development resources required. It was a nightmare, both for those of us on the local side of the dev team working directly with them, and for the management, whose decision came back to bite them. Even years later, we're still finding bits of facepalm sprinkled in the code of that project...
If I want to print a large volume of material, it will take a certain amount of time. If I want to get it faster than that, I need to pay extra for rush service.
There's the rub, though: if you just port a game from Android, you're still talking about a game targetting a very broad platform. You'll give up the advantages of traditional console development, eeking more performance out of the platform by exploiting every little bug and idiosyncracy (since you know they'll remain constant for the life of the platform), or just by making certain assumptions along the line of "method A is faster than method B, but A only works on this specific hardware while B works on some other platform"...
I believe Carmack once said something like, you can get twice the performance out of a console as compared to an identically specced PC, due to only having to support a single unchanging set of hardware. There's enough diversity in the Android ecosystem to make it more like a PC, I suspect. You've got CPUs with different architectures (Qualcomm Snapdragon versus ARM Cortex, or the optional bits like NEON) or even completely different instruction sets (ARM versus x86). You've got GPUs from a multitude of vendors (PowerVR, nVidia, ARM, etc) with varying add-on hardware (TI includes a 2D component, others don't). You've got varying amounts of RAM, of memory bandwidth, of display resolution, etc.
Pricepoint: tough to hit. A pandaboard (dual core A9 with 1GB of RAM) can be had under $200, but it's sold at a loss by TI (it's a TI OMAP dev board, so they subsidize it). You can eliminate a bunch of unecessary hardware from there, but $99 including a wireless controller is really iffy. It's possible they're getting a really good deal from nVidia for the SoC. Perhaps nVidia sees this as a way to get a whole lot of game development effort on Tegra, which helps them in the overall Android marketplace.
Free-to-play: if you look into it deeper, they're merely requiring that all games in their store have a free trial mode. That seems to be where the free-to-play claim comes from
Android: Not a buzzword, because it tells Android developers "Hey, port your Android game to our console, it's a near-trivial effort!" But yeah, there are a few buzzwords being thrown around
Multitude of unrelated screenshots: Not sure what you mean here. Did you mean the shots of SC2 and LoL? Those were supposed to demonstrate the TwitchTV app.
Easy rooting: You'd need to root it because it doesn't make sense to ship pre-rooted hardware to general users. It's a security/usability risk (malware, users accidentally messing stuff up, etc). You want to ship secured systems to everybody, and make it easy for them to circumvent it if they want to.
Pseudo-appeal to the non-mainstream: There certainly seems to be enough demand to sustain this as a niche product, but if they can get some mainstream console ports, they could break into the mainstream. Maybe they're counting on that.
Release in 10 months with $1 mil budget, comparison to Pandora: There are obviously prior investors. They got to the working prototype stage before even starting their kickstarter campaign. It seems to me that they're near completion on both the software and hardware levels, so they're not promising the entire project will be completed in 10 months, only that the remainder of the project willk be completed in 10 months. It should also be noted that the PandaBoard was a portable device, which is immensely more difficult in terms of hardware design than a console. For a console, you can design the PCB and a plastic case to put it inside, and it's pretty simple. The controller would be the tricky part.
To me, the pricepoint is the only rel sticking point.
A Tegra 3 isn't all that underpowered; it would fit inside the spectrum of current-gen consoles. Faster than a Wii, slower than a 360, but closer to the 360 than the Wii. With that much RAM, porting a 360 or PS3 game shouldn't be terribly difficult, except for the obvious differences in APIs.
I'd be curious about the relative performance of the CPUs of the two. The 360 has, for game use (one core is reserved for OS) a dual-core in-order-execution 3.2GHz PowerPC. The Tegra 3 is a quad-core out-of-order execution (up to) 1.6GHz Cortex A9. I'd expect the theoretical performance to be somewhat similar, especially since the A9 is OOE...
The Ouya has double the RAM too, but a bunch less memory bandwidth, so that balances out in many ways. I suspect that the major difference between the two would be the GPU.
Fighting games require some sort of control pad (they're not really practical on a keyboard), which really limits the potential market for a PC fighting game. Even for consumers who also own a console, no major console ships with a controller that works with a PC out of the box (PS3 requires third party custom drivers/software, 360 wireless controller requires special dongle, wiimote requires third party custom drivers/software).
Because that trains bad behaviour (obeying instructions to modify system settings in a hijacked browser). If the DNS simply shuts down (or had shut down from the start, as it should have), the user might not have learned good behaviour (by being told why the problem had occurred), but at least would not have learned bad behaviour.
There are always ways around that (HTTP tunnels, for example), but you'd need to verify if they violate batelco's terms of service. Or if you don't care about violating their terms of service.
My suggestion would have been that, rather than relying on a VPN service directly, get a VPS/dedicated server/colocated box in a trusted US datacenter, and run OpenVPN-AS (or something equally easy to manage) on it. Obviously, needing trickery such as an http tunnel would make that more difficult (you'd need to establish an HTTP tunnel first, and then connect the VPN client through it), but not impossible.
It wouldn't be the first time that somebody in Apple went and did something behind Jobs' back anticipating a change of heart. The story of the Sony/Alps situation for the original Mac floppy drive is probably the most famous example.
Jobs loved the new Sony 3.5" floppy drive format, and decided seven months before the Mac was supposed to ship that he wanted to use it... and he wanted that to happen via an Apple/Alps developed-from-scratch clone. The team thought this was insane, so while grudgingly going through the motions with Alps, they secretly continued working on integrating the Sony drive. They kept all the meetings/negotiations/hardware secret from Jobs, to the extent that they would hide the Sony engineer visiting Cupertino in a closet whenever Jobs was nearby. This obviously greatly confused the Sony engineer, but he went along with it.
Later, when Alps told Apple that they needed eighteen months to get the thing ready, the team revealed to Jobs that they had gone behind his back and kept the Sony deal alive, and he ended up thanking them for their little rebellion.
I'm not saying that this is the same situation here, only that what Jobs was convinced was the right approach and what the Apple engineers working on the internal SDK were convinced was the right approach may not have aligned. It's pretty well documented from multiple sources internal to Apple that Jobs was obstinately refusing to consider third-party apps. He didn't want other people messing with his perfection, and he didn't think his team had the bandwidth to figure out how to make it work (in terms of reliability and integration) on top of their existing workload.
I believe they let you add bookmarks to web stuff in the first iOS release that showed up as icons on the home screen, although that might have been added in a later release. If it was present in the original release, perhaps that caused some confusion.
This was true, but the underlying reason is that Jobs didn't WANT an SDK fit for third-party developers. He believed that they would taint the purity of the experience. People were really on Jobs' case about this inside Apple.
I'm definitely not mistaken. The app store and the ability to install third-party apps was only added in iOS 2. It was a controversial decision at the time, and a lot of noise was made in the press, with some claiming the iPhone wasn't a smartphone without third party app support. The Isaacson biography of Jobs goes deeper into this; even after the launch of the iPhone, Jobs resisted adding third-party app support, and only did so grudgingly.
A simple google search should verify this for you. For example, a simple search turns up this Macworld article from a few days ago that has some discussion on the original lack of third party app support:
People forget this now, but the iPhone did not support apps when it launched. Jobs didn't want third-party code on the iPhone, and tried to assuage the demand with web-based APIs for accessing phone hardware. App support was only added over a year later with iOS 2, coinciding with the launch of the iPhone 3G, as Apple and Jobs conceded to the inevitable.
He was referring to "your position" meaning "your country's position" referring to the US government's tendency to prefer buying domestic, and not including Canada in the definition of "domestic". Which is technically accurate, even if the US and Canada are in many ways a common market.
OK, if you'd like to define everybody who lives in the Americas as being American, what is your preferred term to refer to people living in the United States of America?
Slashdot Mirror
Apple didn't ban Firefox, and nothing stopped Chrome, Opera, or any of the other hundreds of web browser apps from popping up. Let's be clear: Apple didn't ban web browsers on the app store, they banned Javascript engines that run arbitrary code, a pretty specific restriction, although one that admittedly has wide-ranging repercussions.
Google's (and most other developer's) solution of the problem was to just use Apple's layout and javascript engines and build their browsers around that. Opera's approach was to do the javascript and layout server-side and just do the rendering locally. I believe there was at least one browser that streamed the browser as video. Looking at the different web browsers available for iOS, there is a pretty wide range in user interface design and feature support. iCab Mobile adds gestures, Chrome adds incognito mode and unlimited tabs, etc.
For something like Chrome, which is a webkit browser anyhow, this isn't even a terribly big change. In fact, the only major issue is that Apple doesn't expose their JIT javascript engine to third parties, so third party browsers that rely on Apple's javascript engine suffer from rather poor javascript performance. Hopefully Apple will loosen that restriction.
Facebook and the Open Computer project are not the only people doing this, nor are they the first (although they do go deeper than others, even designing the motherboards themselves).
Two years or so before Open Compute was founded, BackBlaze opensourced their storage pods, which fit 45 hard disks in a custom 4U chassis (they gave away the 3D plans as well). Last year, they updated it to version 2.0, which lets them store 135 TB in 4U for a total purchase cost (in 2011) of $7,384.
Inspired by that (as in, they say they were), Netflix did the "Open Connect" appliance, which is supposed to be open, although I can't actually find the design suitable for case manufacture.
It's pretty clear from the article that his device does not permanently record anything, but simply has a ring buffer that stores the last short while for processing. The victim would not even have had images of his assailants if they had not broken his computer while assaulting him, freezing the ring buffer in place.
Ouya is definitely aiming for something smaller, sure. People underestimate what you can do with that sort of hardware when it's a fixed platform (the thing has almost as much power as a 360), but it's never going to be considered high-end hardware.
That's not to say that you can't do higher end similar hardware. You throw an eight-core Cortex A15 with an eight-core Mali-T658 at a problem, and you're going to have some decent performance. It'll use an unprecedented amount of power for an ARM SoC, but it's within spec. My basic point is that you can scale things up to a certain extent; such a system would already have several times more performance than a Vita, for example.
Because nobody ever ported a game between the XBox 360 (which uses a variant of DirectX) and the PS3 (whose PSGL graphics API is a variant of OpenGL ES) before, right? Many games these days are already running on multiplatform engines that get you the other platforms for free anyhow. Source has already been shown running on Linux, which means any Source game should be an easy port. Unreal runs on anything, and that seems to power most games. Any engine that runs on OS X can probably be adapted relatively easily to run on Linux, since you've already ported the graphics code at that point anyhow. As for the rest, well, every current major gaming platform already has a different environment, but we still see tons of cross-platform titles.
That's more or less what Ouya is already trying to do, although scaled down a bit.
And if you throw enough money at the problem, you get bumped to the top of the queue, which gets you the "good and fast", but not cheap.
I have. It didn't save money, because of the enormous amount of rework involved. It was a huge disaster that thankfully put the senior management off outsourcing for good.
They didn't do it to save money anyhow, they did it because a big customer wanted a new product, and we didn't have the development resources to pull it off. They hired an Indian outsourcing firm get the extra development resources required. It was a nightmare, both for those of us on the local side of the dev team working directly with them, and for the management, whose decision came back to bite them. Even years later, we're still finding bits of facepalm sprinkled in the code of that project...
If I want to print a large volume of material, it will take a certain amount of time. If I want to get it faster than that, I need to pay extra for rush service.
There's the rub, though: if you just port a game from Android, you're still talking about a game targetting a very broad platform. You'll give up the advantages of traditional console development, eeking more performance out of the platform by exploiting every little bug and idiosyncracy (since you know they'll remain constant for the life of the platform), or just by making certain assumptions along the line of "method A is faster than method B, but A only works on this specific hardware while B works on some other platform"...
I believe Carmack once said something like, you can get twice the performance out of a console as compared to an identically specced PC, due to only having to support a single unchanging set of hardware. There's enough diversity in the Android ecosystem to make it more like a PC, I suspect. You've got CPUs with different architectures (Qualcomm Snapdragon versus ARM Cortex, or the optional bits like NEON) or even completely different instruction sets (ARM versus x86). You've got GPUs from a multitude of vendors (PowerVR, nVidia, ARM, etc) with varying add-on hardware (TI includes a 2D component, others don't). You've got varying amounts of RAM, of memory bandwidth, of display resolution, etc.
Pricepoint: tough to hit. A pandaboard (dual core A9 with 1GB of RAM) can be had under $200, but it's sold at a loss by TI (it's a TI OMAP dev board, so they subsidize it). You can eliminate a bunch of unecessary hardware from there, but $99 including a wireless controller is really iffy. It's possible they're getting a really good deal from nVidia for the SoC. Perhaps nVidia sees this as a way to get a whole lot of game development effort on Tegra, which helps them in the overall Android marketplace.
Free-to-play: if you look into it deeper, they're merely requiring that all games in their store have a free trial mode. That seems to be where the free-to-play claim comes from
Android: Not a buzzword, because it tells Android developers "Hey, port your Android game to our console, it's a near-trivial effort!" But yeah, there are a few buzzwords being thrown around
Multitude of unrelated screenshots: Not sure what you mean here. Did you mean the shots of SC2 and LoL? Those were supposed to demonstrate the TwitchTV app.
Easy rooting: You'd need to root it because it doesn't make sense to ship pre-rooted hardware to general users. It's a security/usability risk (malware, users accidentally messing stuff up, etc). You want to ship secured systems to everybody, and make it easy for them to circumvent it if they want to.
Pseudo-appeal to the non-mainstream: There certainly seems to be enough demand to sustain this as a niche product, but if they can get some mainstream console ports, they could break into the mainstream. Maybe they're counting on that.
Release in 10 months with $1 mil budget, comparison to Pandora: There are obviously prior investors. They got to the working prototype stage before even starting their kickstarter campaign. It seems to me that they're near completion on both the software and hardware levels, so they're not promising the entire project will be completed in 10 months, only that the remainder of the project willk be completed in 10 months. It should also be noted that the PandaBoard was a portable device, which is immensely more difficult in terms of hardware design than a console. For a console, you can design the PCB and a plastic case to put it inside, and it's pretty simple. The controller would be the tricky part.
To me, the pricepoint is the only rel sticking point.
A Tegra 3 isn't all that underpowered; it would fit inside the spectrum of current-gen consoles. Faster than a Wii, slower than a 360, but closer to the 360 than the Wii. With that much RAM, porting a 360 or PS3 game shouldn't be terribly difficult, except for the obvious differences in APIs.
I'd be curious about the relative performance of the CPUs of the two. The 360 has, for game use (one core is reserved for OS) a dual-core in-order-execution 3.2GHz PowerPC. The Tegra 3 is a quad-core out-of-order execution (up to) 1.6GHz Cortex A9. I'd expect the theoretical performance to be somewhat similar, especially since the A9 is OOE...
The Ouya has double the RAM too, but a bunch less memory bandwidth, so that balances out in many ways. I suspect that the major difference between the two would be the GPU.
Fighting games require some sort of control pad (they're not really practical on a keyboard), which really limits the potential market for a PC fighting game. Even for consumers who also own a console, no major console ships with a controller that works with a PC out of the box (PS3 requires third party custom drivers/software, 360 wireless controller requires special dongle, wiimote requires third party custom drivers/software).
Because that trains bad behaviour (obeying instructions to modify system settings in a hijacked browser). If the DNS simply shuts down (or had shut down from the start, as it should have), the user might not have learned good behaviour (by being told why the problem had occurred), but at least would not have learned bad behaviour.
They should have cut them off immediately, when there were 4 million PCs connecting to them. How are people supposed to learn?
Are those people not gamers? If they're gamers, the title is still accurate.
It's just a slowly ramping up beta, that's all. Everybody will get it eventually.
There are always ways around that (HTTP tunnels, for example), but you'd need to verify if they violate batelco's terms of service. Or if you don't care about violating their terms of service.
My suggestion would have been that, rather than relying on a VPN service directly, get a VPS/dedicated server/colocated box in a trusted US datacenter, and run OpenVPN-AS (or something equally easy to manage) on it. Obviously, needing trickery such as an http tunnel would make that more difficult (you'd need to establish an HTTP tunnel first, and then connect the VPN client through it), but not impossible.
Because if you've read the biography, the not-enough-bandwidth thing was one of his excuses, and not the core reason?
It wouldn't be the first time that somebody in Apple went and did something behind Jobs' back anticipating a change of heart. The story of the Sony/Alps situation for the original Mac floppy drive is probably the most famous example.
Jobs loved the new Sony 3.5" floppy drive format, and decided seven months before the Mac was supposed to ship that he wanted to use it... and he wanted that to happen via an Apple/Alps developed-from-scratch clone. The team thought this was insane, so while grudgingly going through the motions with Alps, they secretly continued working on integrating the Sony drive. They kept all the meetings/negotiations/hardware secret from Jobs, to the extent that they would hide the Sony engineer visiting Cupertino in a closet whenever Jobs was nearby. This obviously greatly confused the Sony engineer, but he went along with it.
Later, when Alps told Apple that they needed eighteen months to get the thing ready, the team revealed to Jobs that they had gone behind his back and kept the Sony deal alive, and he ended up thanking them for their little rebellion.
I'm not saying that this is the same situation here, only that what Jobs was convinced was the right approach and what the Apple engineers working on the internal SDK were convinced was the right approach may not have aligned. It's pretty well documented from multiple sources internal to Apple that Jobs was obstinately refusing to consider third-party apps. He didn't want other people messing with his perfection, and he didn't think his team had the bandwidth to figure out how to make it work (in terms of reliability and integration) on top of their existing workload.
I believe they let you add bookmarks to web stuff in the first iOS release that showed up as icons on the home screen, although that might have been added in a later release. If it was present in the original release, perhaps that caused some confusion.
This was true, but the underlying reason is that Jobs didn't WANT an SDK fit for third-party developers. He believed that they would taint the purity of the experience. People were really on Jobs' case about this inside Apple.
I'm definitely not mistaken. The app store and the ability to install third-party apps was only added in iOS 2. It was a controversial decision at the time, and a lot of noise was made in the press, with some claiming the iPhone wasn't a smartphone without third party app support. The Isaacson biography of Jobs goes deeper into this; even after the launch of the iPhone, Jobs resisted adding third-party app support, and only did so grudgingly.
A simple google search should verify this for you. For example, a simple search turns up this Macworld article from a few days ago that has some discussion on the original lack of third party app support:
http://www.macworld.com/article/1164706/the_iphone_five_years_later_.html
Or this article that covers the launch of the app-store and third party apps fourteen months after the iPhone launched:
http://www.macworld.com/article/1132402/appstore.html
People forget this now, but the iPhone did not support apps when it launched. Jobs didn't want third-party code on the iPhone, and tried to assuage the demand with web-based APIs for accessing phone hardware. App support was only added over a year later with iOS 2, coinciding with the launch of the iPhone 3G, as Apple and Jobs conceded to the inevitable.
He was referring to "your position" meaning "your country's position" referring to the US government's tendency to prefer buying domestic, and not including Canada in the definition of "domestic". Which is technically accurate, even if the US and Canada are in many ways a common market.
OK, if you'd like to define everybody who lives in the Americas as being American, what is your preferred term to refer to people living in the United States of America?