Slashdot videos: Now with more Slashdot!

It's a difficult question.

Can you side-load on an iPhone? Yes, you can. There are three ways:

(1) Jailbreak the device; some people are willing to do this. The preeminent reason is to work around carrier limitations on tethering/hotspotting to get around the fact that the carrier has unlimited data on some phone plans, but either does not permit, or has capped charges for, tethering/hotspotting through the phone, or through mobile hotspots. Other than a few applications to work around Apple/carrier agreements, or add functionality Apple doesn't/won't approve, this is not so big these days.

(2) Enroll the device as a developer device using a developer certificate. This allows you a limited number of devices, however, and isn't useful for wide scale distribution. It's a dead end.

(3) Enroll the device as an enterprise device. There are already Chinese "app stores" which do this; you enroll voluntarily, or the phone comes already enrolled when you purchase it from the vendor, and they install an enterprise cert, signed by Apple, which allows them to run their own distribution system. Typically, they pirate U.S. Apps, rewrap them, resign them, and then sell them on the cheap, giving no money back to the authors. In addition, there's often malware included with the applications sold this way. Apple hates it, and I have no doubt, there's active work on enterprise support to prevent this, going forward.

So side-loading isn't the biggest issue, since if there's a will, there's a way, and Android would also end up with methods similar to these thre to increase the difficult of, but not eliminate, side-loading.

The flip side of this is that, unless they do something, the pure *volume* of malware for Android will almost certainly kill their viability as an app platform eventually, even if it's not going to happen today or tomorrow.

The biggest problem with Android, with regard to apps, is that there are are too many targets.

Apple is in the process of screwing themselves over this way, for short term monetary gains that will likely not have long term value for them. At a minimum, a developer has to target 7 iOS platforms at this point in time - even if that ends up being wrapped up in a single distribution package, so it looks like a single thing in the App store. In addition, video content is split between 4:3 and 16:9 aspect ratios. Apple eats the transcoding costs and the duplicate CDN costs for these, but the decision to change the device means twice as much content has to be carried around.

But 7 is manageable, if you are targeting the same OS version, or an earlier but forward compatible OS version for all devices.

The Android ecosystem is the wild west, in comparison. And automatic updating of Android versions on older devices won't gloss over hardware differences in input methods, sensors, and so on.

So...

(1) Yes, there's room. If Samsung wanted to own this, they probably could, just by standardizing minimal feature set on their entire product line, and then forcing version updates on the carrier, or making sufficiently compelling new devices that the carrier doesn't think the version updates will impact their 18 month subscriber contractual lock-in model for doing business.

(2) The side-loading thing is not that big an issue. The Android App market isn't that big these days, and it's balkanized enough through device specifications and other capabilities that, everything else being equal, it's possible to create an 800lb Gorilla in the App store space, and have it stick. If Samsung wanted to do this themselves, they surely could do that too.

The problem with Samsung doing this, however, is that their laptop, tablet, and mobile phone divisions are -- in fact -- separate but affiliated companies, all with their own engineering teams, design teams, supplier contracts, and so on. So Samsung would have to change *themselves* to do this.

OK... the Amazon problem...

It's not a problem. Although they've certainly go a more or less portal-play going with their application and content for their Android devices -- all they had to do was default it to pointing at their servers, and most people don't change defaults, as we've seen by the search engine lawsuits against device vendors and against Chrome.

I think that this could be handled by having a master store signing signing certificate, and Google - or come consortium, including Samsung -- controlling the signing certificate. That may end up with, say, 5 "trusted stores", and the members of the consortium would all agree on some minimal feature set on the devices so developers could target a single base model, and they could agree to lockstep their version updates, etc., etc..

Or Google could do it for them, and swallow the bitter medicine on their behalf. Part of that would be the fact that the Google Android App store takes a 30% transaction fee, and they'd have to let the vendors whose certs were signed for them by Google, take all or most of that percentage. And that would lead to competition, which would have to happen in the consortium, for fees. Which could lead to RICO violations, unless they legally structured their price fixing agreement to be an emergent property, rather than an explicit agreement (i.e. it's a "natural" saddle point for the rules under which anyone can agree to operate, rather than an explicit agreement to price fix).

To get back to the original question now...

If all that were done -- and it'd cost Google considerably to do it -- then no, there's not a room for a third party.

If, on the other hand, the question really was...

"Does Microsoft have any hope in hell of breaking into this market at any point in the next 3-5 years, or are they going to be stuck at a 5% market share for Windows Phones?"

Microsoft could break into the market. And they could wield the App Store model that Apple currently wields, rather effectively.

But, as they do not build their own hardware, as Apple does, they'd need to do something similar to what I've described above. And for them, it'd be even more galling. But probably not as galling as it would end up being if either they or Google attaced the problem full wold (long term) be fore the carriers. 8-)

You mean change these things?

Carrier business model:

(1) Contractually obligate you for 2 years
(2) Entice you with "upgraded phone" every 18 months
(3) Prevent them upgrading their own phone and escaping carrier lock-in after 2 years
(4) Benefit from customer lock in
(5) Goto 2

Cell phone vendor business model:

(1) Bring a new phone to market
(2) Contract with a carrier/seller who considers it enough of an upgrade to entice an early re-up on a customer contract
(3) Start work on the next phone to sell more hardware
(4) Goto 1

Phone OS vendor business model:

(1) Continuously work on the OS
(2) Convince cell phone vendor to use OS
(3) Cell phone vendor takes snapshot of tree
(3)(a) Cell phone vendor productizes snapshot, because OS vendor could not produce a finished product to save their mother
(4) Goto 1

Admittedly, Google would *like* to change things, but at this point, it's really kind of too late; they should have started with lock-in to their own App store.

Apple doesn't have this problem because the next iPhone only has to compete with the previous iPhone, and Apple *actually* tends to improve the iPhone hardware in a less-than 18 month cycle (which keeps the carriers happy), and it doesn't have to fight with all the other cell phone vendors for mind share because, hey, where else are you going to run all those apps/listen to all that music/watch all those movies, that you've already paid for.

Apple has App-based lock-in, and 18 month upgrade cycle carrier satisfaction, and they sell both the hardware and the software, so there's no hardware company to push-back on software updates, and there's no PITA continuous development cycle that prevents software updates from being polished products to push back the other direction.

Google could *probably*, *eventually* fix things, if they were willing to swallow some incredibly bitter pills, and if they were to do profit-sharing of App revenue with the hardware vendors so that the hardware vendors for Android device were willing to be commoditized, but ... it would be an incredibly bitter pill, to have to change their development model away from waterfall, and it would be an incredibly bitter pill to lock down Apps and side-loading.

The surface of the craft can be a mirror.

No useful cooling? At hundreds of miles per hour of atmospheric passage? Hmmm. Not sure I can buy that. A few fins collinear with the forward-back axis of the craft and you'd have quite a bit of cooling.

>Yep, the date on the one I cited being 4 years more recent has nothing at all to do with it.

Still no acknowledgment that the companies have, in fact, disclosed what is in their fluids.

You are making a LOT of assumptions. All of these matter: Ability of the mirror to dissipate energy prior to ablation or meaningful distortion. Collimation of the beam. Reflectivity of the mirror at the laser frequency. Ability of the laser to stay on target, and for how long. Distance from the laser. Atmospheric clarity and particulate density. Atmospheric turbulence. Disruption from atmospheric heating.

It's just not as simple as you paint it.

CIWS targeting is, as the acronym hints, "close in." You should think of the distance between the shooter (of anything) and the target as a lever. A tiny pivot at one end of the lever (the weapon's aim) translates to a "much" larger motion at the end of the lever (the point of impact.) Tolerances that will work at 100 yards aren't anywhere near close enough to work at many miles, or hundreds of miles in the case of missiles not aimed particularly at you (so you can be sure they will get close enough to hit.)

There are other issues. That truck was relatively close, between 1 and 2 miles ("more than a mile away"). To hit an ICBM at apogee, even it it goes right over you, you are going to have to spend a lot of energy on atmospheric heating, and you'll lose even more to atmospheric distortion. We're talking 300 to 700 times the distance, depending on exactly what "more than a mile away" actually means. But it is certain that 30 kw at the source will not equate to 30 kw at the target at those distances. So now the problem becomes more than "hit the target", it is also "stay on target for X time", and that assumes that enough energy can be delivered to overcome the missile skin's ability to dissipate it. Because if you can't do all those things, you can't hurt the missile.

Also, the odds of it going right over you kind of suck.

I"m pretty sure a regular mirror would not be employed.

But here's some hand-wavy math.

If a mirror reflects 99% of the light that hits it at the laser frequency (remember, there's only one frequency to be covered), and the light that hits it can heat proportional to 30 kw (however one figures that), then the mirror is absorbing a 300 watt equivalent and reflecting the rest unless the reflective surface fails.

If the reflective surface is highly heat conductive and the beam isn't all that tightly collimated, likely it won't flinch at all. Like any impact, the effect is all about how much energy you can shoehorn into the smallest possible area. If the beam is ~1/3 of an inch on target, then given 99% reflectivity, it's effectively 1 kw / square inch. If the beam is 1/30th of a square inch on target, it's 30 kw/square inch absorption after reflection. So it makes quite a difference. I think.

Anyone who works with lasers and mirrors, feel free to step in and correct or expand.

>In my experience it's not just a head tracking issue. Just the feeling of seeing your avatar walking around in the virtual world, while your real body is stationary, was enough to cause nausea in a lot of people.

Well. You shouldn't be seeing your own avatar. Other than that, there's nothing inherently sim sickness-causing about moving around a world. You could be a tank or an airplane or a person as far as your inner ear is concerned. What *does* cause a massive amount of nausea is when you are in a FPS and you're constantly snapping your neck around to see if someone is behind you, above you, besides you, etc. But that's not necessarily sim sickness - you'll get nausea in real life if you made the same head movements. You'll also wear our your neck muscles, which is another big issue... once VR headsets weigh past a certain amount, they cause neck problems.

>Actually most of what you describe is solved. the head tracking latency is a solved problem, or at least well understood what is required to remove it as a cause for sickness

Well. A problem can be (and is) well understood without necessarily having a good solution for it.

I recall talking to Michael Abrash about how we quasi-solved it back in the day when he asked about it a couple years ago. And he was working on VR for Valve. So maybe, yeah, they solved it. But at the time he thought it was pretty much impossible to do right.

1) is if the laser is in visible light or not. If you can't see the red dot source a mile off, you can't evade it.

Pretty sure if you "see the red dot a mile off", the location where your eye was is just the steaming, goo-surrounded beginning of a well-cauterized hole that completely transits your head. Assuming tight collimation. With a broader 30 kw beam, your head would explode (steam pressure), and with a really broad beam, you'd turn into a human crisp before you had time to think "Hey! Las..."

>In your experience would you say that people can adapt to sickness caused by VR over time? Does it vary?

For some people, yes. They get used to it.

For me, I actually got more nauseous over time. But we also moved between software products and switched the prediction software, which was also part of it.

The interesting thing is that the people who are most in tune with their bodies get the most sick. My boss had a friend who was a pole vaulter who put it on and got instantly sick. Whereas people who aren't really physical have an easier time with it on average.

Who said science and math cant be fun?

Congress comes to mind.

When Google originally offered the code, they offered to host it on Google's hosted infrastructure service for a year, at no charge, until the project got up on its feet. There were no takers.

This will probably be moderated down as well... however, yes, "providing the service" is *exactly* the problem, and it's *exactly* why Google cancelled the thing when the back end hosting infrastructure APIs changed out from under the (unmaintained) Reader codebase. The maintainers had moved onto other projects.

And while Google could have either brought them back (the ones who wanted to revisit their old code), or they could have put new hires on the porting problem, and gotten Reader back on its feet on the new hosting infrastructure, it wouldn't have solved the basic problem.

The basic problem is that there was no sustainable revenue model for the service. Google's Reader service allowed the use of any client that someone cared to write, and a heck of a lot of people wanted to write clients that excluded advertising as a means of supporting the costs of running the service. Which would be fine, if there were any way to charge for it, *other* than advertising, which didn't break the client/back-end-service model, which is what people *liked most* about Reader in the first place.

So Google didn't throw good money after bad, and no one else stepped up to throw good money after bad, and (possibly) figure out some other way to monetize the service, such as changing the over the wire representation such that advertising was indistinguishable from content. Which wouldn't have worked, since that would just trigger an arms race for clever advertising exclusionary filtering in the display services, instead of at the protocol level.

So you're right: "it is a problem of providing the service", and the specific problem is "no one wanted to pay to do that".

Perhaps this is fixable...

Could you maybe write:

"'Articles': What It Takes To Write an Article Not Light On Details"

?