It also occurred to me that with Nokia's history as a rubber manufacturer they're bound to have made rubber rafts at some point (which would indeed be called `jolla').
No-one said the whole point of the phone is HTML5 apps. The reviewer thinks HTML5 apps are the future, that's all. Native Sailfish apps are Qt based; with android apps as a secondary thing, presumably to kick-start the platform while they try to build an ecosystem. (Which makes sense, developers won't come unless people are using it but people won't use it if there are no apps.)
Yeah, that's probably a fair point. It wasn't clear until I looked at the architecture diagram, though.
Native Sailfish apps are Qt based; with android apps as a secondary thing, presumably to kick-start the platform while they try to build an ecosystem. (Which makes sense, developers won't come unless people are using it but people won't use it if there are no apps.)
I'm guessing that was Blackberry's strategy too. Didn't work for them - be interesting to see how well it works here.
Technically no vendor can offer something exceptionally different from hardware point of view. Bazillion megapixels, bazillion megaherz, bazillion cores and etc. - nobody cares about that. It takes decent pictures - good enough. It is not camera with lens replacement anyway. It works reasonably fast - good enough, I take it. Replaceable parts(1) - meh I don't care unless I can attach lens but then it is mirrorless camera not smartphone. It doesn't have my favorite app (twitter, vine, endomondo, hangouts, skype... name whatever else is important for you) - I don't need it.
Basically software ate hardware. Now let's talk about software. Development tools for Android are good enough but far from perfect. iOS tools are better, Qt tools are better (at least for me), Windows tools are better, HTML tools are better. The only important advantage Android has its openness. iOS lose because of that (2), Blackberry lose because of that and Windows will lose because of that (IMHO). Jolla are much more open here but are they open enough? Does it matter anymore? Firefox OS is in much better position as a lot of people have explored using HTML for apps and writing app for Firefox OS is basically packaging it and you have app. Most probably you don't need to write app at all if you already have responsive design website.
Android problem - it is dependent on Google very much and it is both good and bad. It is good for users as they get good experience, it is bad as they are getting closed into Google's world and I doubt that it is good thing.
My question is: what next smartphone OS should offer to be considered winning?
1) Replaceable parts are still good thing if it will create market where you can buy cheaper parts to replace broken ones or outdated ones.
2) iOS market share in the world is low but pretty good in USA. So I'm using "lose" very loosely.
Just checking ... you know why Microsoft has won so many wars? Embrace, Extend, Extinguish.
You could almost always upgrade to Microsoft without losing your old data and programs. CP/M programs could be ran virtually unmodified on DOS. Lotus documents could be opened in Office. But if anything used special Microsoft-only features them the customer would need to keep using Microsoft products.
Assuming customers will only upgrade to a new system that can run their old programs, and open their old documents, then eventually they'd all end up stuck with Microsoft.
Obviously, not every customer is like that, and iOS customers won't have a reason to switch, but it's not a terrible strategy.
Offering Android means that users can upgrade from an Android phone. Offering Qt means that users will get trapped (at least, until there's enough users that Android makers start trying to fight back, but that's a good problem to have).
Just checking if I got it right: Google with Android is successfully using Microsoft strategy.
In that case Firefox OS is in the best position to compete against Android. FxOS phones can be very cheap as well. But is that enough to make it next big thing in smartphone's market?
> Technically no vendor can offer something exceptionally different from hardware point of view.
Just because vendors are falling over themselves to makes Iphone clones, doesn't mean there's no other way.
Personally, the whole current smartphone scene leaves me cold, because no-one is making hardware for me. I want a small, robust phone I can put in my pocket and forget about. Something with a big fragile screen is completely useless to me. I don't really care what software it's running - if I have to leave it at home because I'm afraid of breaking the screen, then the software is irrelevant.
Huh? There are thousands and thousands of devices just like that. They don't make the news though because they're boring and cheap. Head past your nearest phone shop and you can find a huge variety of those kind of phones at incredibly low prices ($20 prepaid kind of prices).
I recall recording software onto audio tape from radio broadcasts, I think it was a regular BBC radio show. (If anyone remembers I'd love a reminder of the details.)
That's interesting. As you say, it's a no-brainer. I wonder if some kind of micropayment market in functions could be pulled off... The kind of thing Ted Nelson or Jaron Lanier talk about, only for small pieces of reusable code rather than small pieces of reusable text.
That's true. But money in that micropayment sense might not be entirely insane (assuming the whole micropayment model isn't entirely insane to begin with). The idea (as I understand it) is that you'd get a tiny wee payment every time someone quoted your work; so why not every time someone quoted your code? In the context of some Xanadu-like system, wouldn't that make sense?
But (I think) he means as a product, not a service (i.e. for bounties, only the asker pays, so it's a service; though it's true that everyone else benefits too).
I like this idea. The big problem, as always, is the boundary or interface of the module/component. (1). The buyer has to specify it, which is usually the difficult bit and writing it is usually easy. (2). For a market, you need to find modules that many people need, that people can search for and find, and that are difficult enough to implement that people would buy rather than build.
Maybe it's possible, for things that seem one-off or too specialized to a person, if you reduced friction enough, in a SO way. They've solved the search problem.
I guess an example would be a square-root function. I wouldn't know how to code it, I'd have to look it up, test and debug. It would take at least hours, I'd think. Of course, it's such a useful one, it's already done. That's the fate of all generally useful functions. The exceptions are new ones and niche ones.
I guess you could just add a little "debugged code" box for SO, and the person keeps coming back to it, to support it. This might be a useful addition; but I think you're right that money would spoil it. However... if you imagine a spectrum from one-liner to massive library, there's probably some level where the amount of work would make it reasonable to pay.
Conclusion: to see the value in the idea, leave money out (build something people want). How would you modify SO, or start a new one, to provide this value, or reusable functions/code snippets?
Matt Cutts (Google SEO) fondly referred to this site as "Expert-SexChange" at Wordpress Conference in San Francisco in 2009! Google it. The video is funny!
But it makes me wonder when exactly we start to call something over-engineered. The same function will be implemented differently depending what you are going to feed into it i.e. if the numbers are sufficiently large then you need to worry about integer overflow etc. Probably a function definition should be considered incomplete without pre/post conditions.
One could imagine incorporating the component store into the app store, where developers could get a cut of app profits for providing components while the app store is responsible for all the bookkeeping. Think 5 cents/app sale micropayments, but that includes all apps on the store that want to use your component.
Used to use my own wee C prog that just passed the alert unparsed to libnotify; currently using a modified version of this far superior shell script (which I can't take any credit for):
https://github.com/Bruce-Connor/alpine-osd-notify/blob/maste...
(You have to set newmail-fifo-path in your pinerc.)
Or I could be completely overreading this...