I have a lot better things to do with my free time than futz around with office suites. I've got Google Docs that I can get to from pretty much any device and I've got MS Office on my laptop and iPhone. That seems fine for me though my use cases are admittedly pretty basic.
I'm curious how they'll "encourage" users to upgrade to the latest shiny if the slightly tarnished shiny is still up-to-date...
Same way Apple does. Add new features to the hardware and software which also results in higher requirements for the system. Your older systems are still up to date but they run slower and lack newer features but at least they don't have critical bugs.
0. If you don't believe vendor lock-in is a problem
That is not an answer. I said to demonstrate it is a problem smartphone users actually have, which you didn't do. Even if it exists, how would this stop those people from being locked in?
1. This is simply unnecessary. The implication you make is that some unnamed new platform features will become essential very quickly to a large number of new apps in the future.
No, not essential, but useful in a reasonable amount of time. HTML5 does not implement new features in a reasonable amount of time thus these will not be used in cross-platform applications so native apps will be written instead and this "standard app container" will not be used.
2. There's no reason to believe that 'native look at feel' is somehow essential outside core apps, where there are obvious benefits to that consistency.
If you have native core apps then people just get locked in to those, they don't want to lose their SMS or iMessage or Hangouts for example. Companies just add native apps to their platform and that locks users in, the "standard app container" fails again.
3. Thousands of developers already support it, there's no need to start from scratch.
All of these developers just wrap their apps in platform-specific containers for iOS, Android and Windows Phone so how is this "standard app container" solving the problem?
4. Again, the APIs we have now are sufficient for the majority of apps you find on any platforms You've got this odd 'all or nothing' mentality. There's room for native apps, despite the problems, and standards apps.
So what apps specifically are causing this "vendor lock-in" then? Demonstrate the problem with an example and then explain how this "standard app container" solves the problem because it's pretty clear you haven't thought this through.
5. This is several questions. 5.1 They come from thousands of developers, all around the world. Big and small companies and even individuals. 5.2 Some are driven by need, others by greed. Some just because they want to support the platform, some because they just like writing apps.
If developers can manage with the limitations of HTML5 then they just wrap a version in a native container for iOS, Android, Windows Phone and then just use the app container for FirefoxOS like they do now. Yet again the "standard app container" provides no benefit and isn't used.
6. Who knows? It depends a great deal on the feature. Though there may not be as much lag as you believe there to be. If you want a recent example, consider that there's already a draft for WebVR and experimental implementations from multiple vendors.
This is precisely the problem, you end up with a draft and a bunch of different implementations from different vendors that takes years to actually get into the standard. Can you give an example of a feature that has been added to the standard in a timely manner?
What's nice about the standard app package is that includes a list of required APIs, so you don't need to worry about older hardware without the new feature or a sluggish roll-out.
So what can platform vendors offer? This standard just sets a very low bar and everything else ends up as a native app and you get the same vendor lock-in.
You clearly haven't learned from all the previous examples - like Java - of "write once, run anywhere" and you're making exactly the same mistakes and then pretending that they don't matter. We have seen they matter, these cross-platform solutions have failed precisely because these things matter and you can't seem to learn from all the past failures. And in those cases there we no incumbent platform gatekeepers like you have to deal with now and cross-platform was a lot harder than it is now. Why can't you learn from these mistakes?
Like I said, I can't help you understand the problem if you deny that it even exists.
What I'm saying is the "problem" isn't anywhere near significant enough to outweigh the proposed solution's shortcomings.
So far your responses haven't answered these questions, if you think you have then just copy/paste the answers inline (this is next to no effort thanks to computers so you don't have to complain about that:P). For anybody who knows what they are talking about and understands the challenges involved these would be very easy questions to answer.
0. Demonstrate - objectively with facts - that this is a problem that smartphone users have. I don't think it is significant at all, you theorize that it is so are there case studies or some kind of evidence to support your theory? So far it's just hand-waving but if you have evidence I'd be interested to see it.
1. If it can't implement new features in a timely manner then developers will just write native apps. So how do you propose to change the standardization process for HTML5 to move at a pace comparable to that of the vendor's ability to deliver features on their platform?
2. Cross-platform applications do not have the native look and feel that users expect, part of the reason most desktop applications are not written in Java. How is this going to be resolved?
3. How do you convince developers to support it? It isn't on iOS, Android or Windows Phone and it's far more limited than those native environments so how do you solve the chicken and egg problem?
4. If this problem of people being "locked in" to a platform because of native apps then how does this solve that problem? Presumably all the native apps need to be re-written and that cannot happen until the HTML5 standard is feature comparable.
5. You talk of a vast app catalog that new OSes can tap into, where does this come from? What drives development? It needs to compete with all the existing Android and iOS applications and we know HTML5 is too limited to do that.
And a more open-ended one:
6. Do you think developers will just write native apps when a new feature is introduced? Or wait until the feature has gone through a standardization process, rolled out to existing platforms and then write a HTML5 version?
This is the problem, not a solution to the problem. See my earlier posts for more details.
The fact that doing so is so trivial is exactly the reason it is not a problem. This isn't a problem for vendors, it isn't a problem for developers and it isn't a problem for users. Even if users are stuck with iOS or Android and want to change but cannot because their native applications prevent it this doesn't change that at all.
Yes, that's one difference. (A very important difference, as I've explained far too many times.)
You haven't factored in the ease of which developers can already port existing HTML5 applications between platforms into your reasoning though. This is not a pain point so explain why vendors, developers and users want a solution to a problem that doesn't exist?
I understand what you are trying to say but you are proposing something that demonstrably vendors, developers and users (we have been down the WORA path before) do not need or want and the proposed benefit is for additional mobile platform vendors that don't yet exist and may not even exist to offer anything of value in future. There's no tangible value to this proposal.
There are also differences, for example, in the security model.
So what is the difference in the security model versus say running the HTML5 webapp in the iOS browser?
You ignore what I've written and flat-out deny the problems I put forward.
No I have addressed every "problem" you have put forward, the issue is they are "problems" only for "potential new mobile OS vendors" and the proposed solution is worse for existing vendors and it is worse for existing developers and users due to the functional limitations of HTML5. You still have failed to address how these functional limitations would be solved.
Why you have such strong opinions on the matter is beyond me, as it's clear that you're not interested in the subject at all.
I'm definitely interested in the subject. The "problem" you have outlined is only theoretical, in practice it doesn't exist. If you disagree then try and explain the tangible, concrete benefit this will have.
Consider that the major vendors need to adopt this and application developers need to adopt this. What is your argument to convince them to do so?
You honestly can't see the massive differences between those things?
In terms of functionality there is no difference, the difference is in the deployment and as a developer you can already wrap a HTML5 webapp in platform-specific containers for all the major platforms with next to no effort so defining a new container has no benefit. If there is a significant benefit here then why can't you explain it?
I can't help you.
Actually it appears you didn't understand what you were advocating for, hence your inability to articulate it.
Yes, standards bodies move very slowly, though I seriously hope that you're not arguing against the need for standards!
No, of course not. Standards are a good thing.
Though speaking of moving slowly, you haven't seen slow until you've seen how slowly change happens once a single vendor dominate the market through proprietary formats! Maybe you're too young to remember the dark days after the browser wars, when MS, the victor, decided that IE6 was it, and essentially stopped further development, grinding the web to a halt.
But we don't have that in the smartphone market, there are several major players and nobody is particularly beholden to any of them.
There's nothing stopping vendors from having their own native formats. They'd just also have to support the standard package as well, if they want to take advantage of that large and open marketplace.
But we already have that. All the operating systems have their own native formats and they all support HTML5 web apps. The standard package already exists and it's called the web, the platform is the browser and you can already use web store apps on all those operating systems through the browser.
What you're asking for is something we already have and have had for some time.
The issue is that right now the existing platform vendors introduce a new feature in their platform - without having to deal with committees and standards bodies that take an age to do anything - deliver it to developers who create applications for customers. Now your proposed system requires a standardized API across all platforms so how does a platform vendor go about delivering a new platform feature? I hope it isn't anything based on the HTML5 and CSS mess of platform-specific implementations of various standard and non-standard features which would negate your whole concept.
There are already standard APIs for interfacing with a number of different devices, with broad support across platforms.
Of course there are, but that couldn't be a much broader and generic statement in this context. I'm pointing out a few key ones for mobile application development and these are taking very long time to resolve which means vendors wanting to add features have a very laborious process ahead of them rather than just being able to incorporate a feature into their platform. You say it's a solved problem yet these things still don't exist.
What's important here is the standard app package that can be trivially implemented on various platforms.
The platforms exist to run applications, if the applications are compatible across all platforms then why do we need "various platforms"?
The question was whether it is a good license to advance free software or not. That was the argument.
And its use in the example in question was not for that purpose, in fact I can't think of any case where it has been used with the stated purpose of advancing the Free Software ideology.
No it doesn't. Linux as used in almost all cases is open source freely available software.
As are all the examples I listed. You argued that proprietary extensions make the system non-free which also invalidates almost all systems that use the Linux kernel.
X11 of course is the example that the GPL have used for 30 years since it was such a disaster.
It was only a disaster if you rewrite history to make the incorrect assumption that it the project had anything to do with free software except to provide a platform on which to base proprietary and/or free software. The free software camp have been whining about their own incompetence for 30 years because the proprietary camp created derived works from that platform and the free software camp did nothing.
The mobile space needs an open platform and, most importantly, an open app package standard that anyone can implement. Users benefit by being able to keep their apps even when switching platforms and new platforms benefit from a wealth of apps ready to go from day one.
What is it that the different platforms are providing then? The other issue that, AFAIK, there is no compatible standard for doing things like interfacing with fingerprint scanners, bluetooth, USB, NFC or audio/video capture. I understand there's various ways to go about some of these and there's a few different drafts for implementations particularly for the audio/video capture but still nothing standardized. This also means new features then need to wait for standardization before people can use them.
How it is supposed to work is the free product stays free, and gets so far ahead there isn't a competition at all.
But that's not the point of a reference implementation, it is created to make sure the protocol is used by everybody and that is why it is under a BSD license because it is was not about free software. If your concern is about the free software ideology then by all means create your own derivative of the original. The proprietary people did, the free software people didn't.
You don't know that. The GPL has a track record of preventing such things.
You don't know that they would have even bothered with X at all, your criticism is based on speculation and the incorrect assumption that the intention of the reference implementation had something to do with free software, which it didn't. The only thing it had in common is that the license is compatible, just as it is with proprietary software.
The objective metric is whether the in use in the broader ecosystem is free or not.
Then Linux fails that metric in almost all cases too.
Their claim is that it is a good free software license, where good is defined as advancing the interests of free software.
Show me that claim in the context of a "BSD license failure" then.
Anyway I've given you clear failure. You are pretending that failures aren't failures by redefining the criteria so that everything is success. That's just dishonest.
No, the dishonest one is you projecting your ideals onto the developers of software that clearly did not share those ideals. If they did they could just re-license to GPL or anybody could create a GPL derivative, add value and become the dominant implementation.
I don't think there's necessarily a problem with a FirefoxOS but it has to be something substantially different and disruptive, not just yet another Linux-based somethingOS for smart devices. If you want to do web apps for all platforms you can already do that, if you want to wrap them in a native platform-specific container and sell them through whatever app store you can do that too. This is also the same reason Windows Phone is doing so poorly in the market, it isn't necessarily a bad operating system, it's just not really any better or substantially different to the incumbent(s) of a mature market to have any hope to unseat them.
In response to me saying their phones arent targeted at the premium phone price point, whether it is their "premium offering" version is irrelevant, nobody cares about that.
No, it isn't. Nowhere did I write or imply that.
I said the 64GB model is their premium offering. You said it's "nuh-uh".
That's for the tasks common to most people, not representative of the entire scope of thing most people do with their computers. The corporate world probably makes up a significant portion of "most people" anyway so the categories listed above probably do apply. But it isn't just the professional market, also amateur developers, artists, photographers, audio producers, videographers, product designers (particularly the maker movement), gamers, etc...
I'd be interested to see where you get this perception that "most users" - however many this might be - just need a web browser.
The only way to get a sizable chunk of a market as mature as the desktop one is to be disruptive and innovative. You won't unseat an incumbent by just copying them and indeed in a market this mature the incumbent can't even unseat itself with products like Windows 8.
When the incumbent in a market can release the almost universally-panned Windows 8.x, charge money for it and still manage ~10 times the market share of all the free-of-charge desktop Linux distributions combined it might be time to review your strategy.
I said their premium model is +$50. You said it's not a premium phone. You just reiterated that it's not a premium phone. The fact of the matter is it's their premium offering.
Go back and read it again: "this isn't marketed at the premium price point".
Oh what a terrible problem! They sell two options, how awful!
The problem isn't with what they sell; the problem is with your argument.
I've already explained that it's not lucrative to offer SD cards slots on mainline-model phones.
Yet most of them do, it's only a few that don't. Your argument fails.
"Some" being all modern mainline phones
Wrong. Xperia Z3, Note 4, Note Edge, G Flex, HTC One, LG G4, ZenPhone. In fact the only mainstream ones that don't have them are the Galaxy S6, Nexus 6 and the iPhone.
And that's how it is supposed to work, the better product wins out.
But the years in between were lost. The damage it did to free systems may not have been fixable.
If those competing UNIX vendors had to contribute back then they likely would have used their own fully proprietary implementations to differentiate eachother anyway. Nothing ever stopped anybody from writing a GPL-licensed X implementation either.
So here we have your list. And virtually every example demonstrates the failure of the BSD licensing model. That's the problem a long proven track record of failure.
Aboslute garbage. None of those is a failure of the BSD licensing model, they are all successes of the BSD licensing model. You define failure as the existence of proprietary extensions, a definition devoted to your ideology rather than based on any objective metric. The GPL does not prevent this either, there is nothing to stop out-of-process extensions with GPL software and there are tons of proprietary drivers that get linked to the kernel through loadable modules that aren't in the source and GCC has even gotten to the point that they would rather have bad software than allow it to export the required data allowing proprietary applications like Apple's XCode to do proper static analysis and highlighting which is why Clang has been so successful.
There are may examples where that isn't true.
Then show them, my list is all the successes and you can't even come up with one failure.
You get a robust and snappy storage and website for communication at the cost of control over your life and privacy.
I think you need to get a grip with reality: using Facebook doesn't mean you have no privacy and no control of your life...unless of course your life is nothing outside of Facebook, but in that case a grip on reality is again what you need.
But ultimately we have X.Org and all those old UNIX systems pretty much died out. To the contrary there are a lot of hugely popular examples of success: Docker, OpenStack, OpenSSL, OpenSSH, Apache webserver, Hadoop, WebKit, zlib, postgres, OpenLDAP, Ruby, Clang, X.Org, etc...
One example from over 20 years ago is not particularly representative of anything and a far cry from "a long proven track record of failure", that is just absolute rubbish.
Well then "tablet mode" is a perfectly fine name for it - despite the fact that you might want that mode on a non-tablet or not want that mode on a tablet depending on your interaction method which is why the automatic switching is an opt-in option and not a default.
Your argument is: "premium shit costs like $500 and this costs $300, so their +$50 offer isn't a premium option."
No, if that is what you got from that then you obviously have some problem with basic English. What I said was:
"this isn't marketed at the premium price point"
And of course it isn't, it is substantially lower than the $600-$800 offerings at the top end.
The problem is they sell two options: the basic 16GB option and the premium 64GB option. The fact that their PREMIUM OPTION is cheaper than some Rolls Royce bullshit doesn't mean it's not a premium option.
Oh what a terrible problem! They sell two options, how awful!
The original argument was that availability of SD card slots would suppress the market value of in-phone storage.
Yes it's all a big conspiracy that all the phone makers - who are also competitors - are colluding on even though many of these phone makers offer phone models with and without SD card slots.
Why don't phones have SD storage?
Many of them do have SD storage, just not all of them. On some models they prefer not to have an exposed, mechanical and relatively bulky (if you're looking at the thinness of modern devices) mechanism for storage and instead use soldered memory to avoid these problems.
From what I understand, a significant chunk of the problem with mobile device "longevity" is that closed source drivers for the SoC's used in phones are typically provided by chipset vendors, and if the driver model used by the O/S ever changes then the SoC vendor needs to provide a newer set of drivers.
That's mostly it, the problem is that the Linux kernel binary interface is unstable so binary drivers that work in one version may not work in the next version and would often need to be modified and rebuilt against the newer kernel then distributed.
Slashdot Mirror
Everyone makes so much money on their free time.
I have a lot better things to do with my free time than futz around with office suites. I've got Google Docs that I can get to from pretty much any device and I've got MS Office on my laptop and iPhone. That seems fine for me though my use cases are admittedly pretty basic.
I'm curious how they'll "encourage" users to upgrade to the latest shiny if the slightly tarnished shiny is still up-to-date...
Same way Apple does. Add new features to the hardware and software which also results in higher requirements for the system. Your older systems are still up to date but they run slower and lack newer features but at least they don't have critical bugs.
0. If you don't believe vendor lock-in is a problem
That is not an answer. I said to demonstrate it is a problem smartphone users actually have, which you didn't do. Even if it exists, how would this stop those people from being locked in?
1. This is simply unnecessary. The implication you make is that some unnamed new platform features will become essential very quickly to a large number of new apps in the future.
No, not essential, but useful in a reasonable amount of time. HTML5 does not implement new features in a reasonable amount of time thus these will not be used in cross-platform applications so native apps will be written instead and this "standard app container" will not be used.
2. There's no reason to believe that 'native look at feel' is somehow essential outside core apps, where there are obvious benefits to that consistency.
If you have native core apps then people just get locked in to those, they don't want to lose their SMS or iMessage or Hangouts for example. Companies just add native apps to their platform and that locks users in, the "standard app container" fails again.
3. Thousands of developers already support it, there's no need to start from scratch.
All of these developers just wrap their apps in platform-specific containers for iOS, Android and Windows Phone so how is this "standard app container" solving the problem?
4. Again, the APIs we have now are sufficient for the majority of apps you find on any platforms You've got this odd 'all or nothing' mentality. There's room for native apps, despite the problems, and standards apps.
So what apps specifically are causing this "vendor lock-in" then? Demonstrate the problem with an example and then explain how this "standard app container" solves the problem because it's pretty clear you haven't thought this through.
5. This is several questions. 5.1 They come from thousands of developers, all around the world. Big and small companies and even individuals. 5.2 Some are driven by need, others by greed. Some just because they want to support the platform, some because they just like writing apps.
If developers can manage with the limitations of HTML5 then they just wrap a version in a native container for iOS, Android, Windows Phone and then just use the app container for FirefoxOS like they do now. Yet again the "standard app container" provides no benefit and isn't used.
6. Who knows? It depends a great deal on the feature. Though there may not be as much lag as you believe there to be. If you want a recent example, consider that there's already a draft for WebVR and experimental implementations from multiple vendors.
This is precisely the problem, you end up with a draft and a bunch of different implementations from different vendors that takes years to actually get into the standard. Can you give an example of a feature that has been added to the standard in a timely manner?
What's nice about the standard app package is that includes a list of required APIs, so you don't need to worry about older hardware without the new feature or a sluggish roll-out.
So what can platform vendors offer? This standard just sets a very low bar and everything else ends up as a native app and you get the same vendor lock-in.
You clearly haven't learned from all the previous examples - like Java - of "write once, run anywhere" and you're making exactly the same mistakes and then pretending that they don't matter. We have seen they matter, these cross-platform solutions have failed precisely because these things matter and you can't seem to learn from all the past failures. And in those cases there we no incumbent platform gatekeepers like you have to deal with now and cross-platform was a lot harder than it is now. Why can't you learn from these mistakes?
Like I said, I can't help you understand the problem if you deny that it even exists.
What I'm saying is the "problem" isn't anywhere near significant enough to outweigh the proposed solution's shortcomings.
So far your responses haven't answered these questions, if you think you have then just copy/paste the answers inline (this is next to no effort thanks to computers so you don't have to complain about that :P). For anybody who knows what they are talking about and understands the challenges involved these would be very easy questions to answer.
0. Demonstrate - objectively with facts - that this is a problem that smartphone users have. I don't think it is significant at all, you theorize that it is so are there case studies or some kind of evidence to support your theory? So far it's just hand-waving but if you have evidence I'd be interested to see it.
1. If it can't implement new features in a timely manner then developers will just write native apps. So how do you propose to change the standardization process for HTML5 to move at a pace comparable to that of the vendor's ability to deliver features on their platform?
2. Cross-platform applications do not have the native look and feel that users expect, part of the reason most desktop applications are not written in Java. How is this going to be resolved?
3. How do you convince developers to support it? It isn't on iOS, Android or Windows Phone and it's far more limited than those native environments so how do you solve the chicken and egg problem?
4. If this problem of people being "locked in" to a platform because of native apps then how does this solve that problem? Presumably all the native apps need to be re-written and that cannot happen until the HTML5 standard is feature comparable.
5. You talk of a vast app catalog that new OSes can tap into, where does this come from? What drives development? It needs to compete with all the existing Android and iOS applications and we know HTML5 is too limited to do that.
And a more open-ended one:
6. Do you think developers will just write native apps when a new feature is introduced? Or wait until the feature has gone through a standardization process, rolled out to existing platforms and then write a HTML5 version?
This is the problem, not a solution to the problem. See my earlier posts for more details.
The fact that doing so is so trivial is exactly the reason it is not a problem. This isn't a problem for vendors, it isn't a problem for developers and it isn't a problem for users. Even if users are stuck with iOS or Android and want to change but cannot because their native applications prevent it this doesn't change that at all.
Yes, that's one difference. (A very important difference, as I've explained far too many times.)
You haven't factored in the ease of which developers can already port existing HTML5 applications between platforms into your reasoning though. This is not a pain point so explain why vendors, developers and users want a solution to a problem that doesn't exist?
I understand what you are trying to say but you are proposing something that demonstrably vendors, developers and users (we have been down the WORA path before) do not need or want and the proposed benefit is for additional mobile platform vendors that don't yet exist and may not even exist to offer anything of value in future. There's no tangible value to this proposal.
There are also differences, for example, in the security model.
So what is the difference in the security model versus say running the HTML5 webapp in the iOS browser?
You ignore what I've written and flat-out deny the problems I put forward.
No I have addressed every "problem" you have put forward, the issue is they are "problems" only for "potential new mobile OS vendors" and the proposed solution is worse for existing vendors and it is worse for existing developers and users due to the functional limitations of HTML5. You still have failed to address how these functional limitations would be solved.
Why you have such strong opinions on the matter is beyond me, as it's clear that you're not interested in the subject at all.
I'm definitely interested in the subject. The "problem" you have outlined is only theoretical, in practice it doesn't exist. If you disagree then try and explain the tangible, concrete benefit this will have.
Consider that the major vendors need to adopt this and application developers need to adopt this. What is your argument to convince them to do so?
You honestly can't see the massive differences between those things?
In terms of functionality there is no difference, the difference is in the deployment and as a developer you can already wrap a HTML5 webapp in platform-specific containers for all the major platforms with next to no effort so defining a new container has no benefit. If there is a significant benefit here then why can't you explain it?
I can't help you.
Actually it appears you didn't understand what you were advocating for, hence your inability to articulate it.
Yes, standards bodies move very slowly, though I seriously hope that you're not arguing against the need for standards!
No, of course not. Standards are a good thing.
Though speaking of moving slowly, you haven't seen slow until you've seen how slowly change happens once a single vendor dominate the market through proprietary formats! Maybe you're too young to remember the dark days after the browser wars, when MS, the victor, decided that IE6 was it, and essentially stopped further development, grinding the web to a halt.
But we don't have that in the smartphone market, there are several major players and nobody is particularly beholden to any of them.
There's nothing stopping vendors from having their own native formats. They'd just also have to support the standard package as well, if they want to take advantage of that large and open marketplace.
But we already have that. All the operating systems have their own native formats and they all support HTML5 web apps. The standard package already exists and it's called the web, the platform is the browser and you can already use web store apps on all those operating systems through the browser.
What you're asking for is something we already have and have had for some time.
The issue is that right now the existing platform vendors introduce a new feature in their platform - without having to deal with committees and standards bodies that take an age to do anything - deliver it to developers who create applications for customers.
Now your proposed system requires a standardized API across all platforms so how does a platform vendor go about delivering a new platform feature? I hope it isn't anything based on the HTML5 and CSS mess of platform-specific implementations of various standard and non-standard features which would negate your whole concept.
There are already standard APIs for interfacing with a number of different devices, with broad support across platforms.
Of course there are, but that couldn't be a much broader and generic statement in this context. I'm pointing out a few key ones for mobile application development and these are taking very long time to resolve which means vendors wanting to add features have a very laborious process ahead of them rather than just being able to incorporate a feature into their platform. You say it's a solved problem yet these things still don't exist.
What's important here is the standard app package that can be trivially implemented on various platforms.
The platforms exist to run applications, if the applications are compatible across all platforms then why do we need "various platforms"?
The question was whether it is a good license to advance free software or not. That was the argument.
And its use in the example in question was not for that purpose, in fact I can't think of any case where it has been used with the stated purpose of advancing the Free Software ideology.
No it doesn't. Linux as used in almost all cases is open source freely available software.
As are all the examples I listed. You argued that proprietary extensions make the system non-free which also invalidates almost all systems that use the Linux kernel.
X11 of course is the example that the GPL have used for 30 years since it was such a disaster.
It was only a disaster if you rewrite history to make the incorrect assumption that it the project had anything to do with free software except to provide a platform on which to base proprietary and/or free software. The free software camp have been whining about their own incompetence for 30 years because the proprietary camp created derived works from that platform and the free software camp did nothing.
The mobile space needs an open platform and, most importantly, an open app package standard that anyone can implement. Users benefit by being able to keep their apps even when switching platforms and new platforms benefit from a wealth of apps ready to go from day one.
What is it that the different platforms are providing then? The other issue that, AFAIK, there is no compatible standard for doing things like interfacing with fingerprint scanners, bluetooth, USB, NFC or audio/video capture. I understand there's various ways to go about some of these and there's a few different drafts for implementations particularly for the audio/video capture but still nothing standardized. This also means new features then need to wait for standardization before people can use them.
How it is supposed to work is the free product stays free, and gets so far ahead there isn't a competition at all.
But that's not the point of a reference implementation, it is created to make sure the protocol is used by everybody and that is why it is under a BSD license because it is was not about free software. If your concern is about the free software ideology then by all means create your own derivative of the original. The proprietary people did, the free software people didn't.
You don't know that. The GPL has a track record of preventing such things.
You don't know that they would have even bothered with X at all, your criticism is based on speculation and the incorrect assumption that the intention of the reference implementation had something to do with free software, which it didn't. The only thing it had in common is that the license is compatible, just as it is with proprietary software.
The objective metric is whether the in use in the broader ecosystem is free or not.
Then Linux fails that metric in almost all cases too.
Their claim is that it is a good free software license, where good is defined as advancing the interests of free software.
Show me that claim in the context of a "BSD license failure" then.
Anyway I've given you clear failure. You are pretending that failures aren't failures by redefining the criteria so that everything is success. That's just dishonest.
No, the dishonest one is you projecting your ideals onto the developers of software that clearly did not share those ideals. If they did they could just re-license to GPL or anybody could create a GPL derivative, add value and become the dominant implementation.
I don't think there's necessarily a problem with a FirefoxOS but it has to be something substantially different and disruptive, not just yet another Linux-based somethingOS for smart devices. If you want to do web apps for all platforms you can already do that, if you want to wrap them in a native platform-specific container and sell them through whatever app store you can do that too. This is also the same reason Windows Phone is doing so poorly in the market, it isn't necessarily a bad operating system, it's just not really any better or substantially different to the incumbent(s) of a mature market to have any hope to unseat them.
I said it's a PREMIUM OFFERING.
In response to me saying their phones arent targeted at the premium phone price point, whether it is their "premium offering" version is irrelevant, nobody cares about that.
No, it isn't. Nowhere did I write or imply that.
I said the 64GB model is their premium offering. You said it's "nuh-uh".
Wrong, you failed reading comprehension.
Most people need a web browser.
That's for the tasks common to most people, not representative of the entire scope of thing most people do with their computers. The corporate world probably makes up a significant portion of "most people" anyway so the categories listed above probably do apply. But it isn't just the professional market, also amateur developers, artists, photographers, audio producers, videographers, product designers (particularly the maker movement), gamers, etc...
I'd be interested to see where you get this perception that "most users" - however many this might be - just need a web browser.
The only way to get a sizable chunk of a market as mature as the desktop one is to be disruptive and innovative. You won't unseat an incumbent by just copying them and indeed in a market this mature the incumbent can't even unseat itself with products like Windows 8.
When the incumbent in a market can release the almost universally-panned Windows 8.x, charge money for it and still manage ~10 times the market share of all the free-of-charge desktop Linux distributions combined it might be time to review your strategy.
I said their premium model is +$50. You said it's not a premium phone. You just reiterated that it's not a premium phone. The fact of the matter is it's their premium offering.
Go back and read it again: "this isn't marketed at the premium price point ".
Oh what a terrible problem! They sell two options, how awful!
The problem isn't with what they sell; the problem is with your argument.
Well no, you just said The problem is they sell two options. Maybe try and work out what you're trying to say before you type.
Your argument is they don't have a premium phone
No, it isn't. Nowhere did I write or imply that.
I've already explained that it's not lucrative to offer SD cards slots on mainline-model phones.
Yet most of them do, it's only a few that don't. Your argument fails.
"Some" being all modern mainline phones
Wrong. Xperia Z3, Note 4, Note Edge, G Flex, HTC One, LG G4, ZenPhone. In fact the only mainstream ones that don't have them are the Galaxy S6, Nexus 6 and the iPhone.
Ultimately they did. XFree86 outcompeted them.
And that's how it is supposed to work, the better product wins out.
But the years in between were lost. The damage it did to free systems may not have been fixable.
If those competing UNIX vendors had to contribute back then they likely would have used their own fully proprietary implementations to differentiate eachother anyway. Nothing ever stopped anybody from writing a GPL-licensed X implementation either.
So here we have your list. And virtually every example demonstrates the failure of the BSD licensing model. That's the problem a long proven track record of failure.
Aboslute garbage. None of those is a failure of the BSD licensing model, they are all successes of the BSD licensing model. You define failure as the existence of proprietary extensions, a definition devoted to your ideology rather than based on any objective metric. The GPL does not prevent this either, there is nothing to stop out-of-process extensions with GPL software and there are tons of proprietary drivers that get linked to the kernel through loadable modules that aren't in the source and GCC has even gotten to the point that they would rather have bad software than allow it to export the required data allowing proprietary applications like Apple's XCode to do proper static analysis and highlighting which is why Clang has been so successful.
There are may examples where that isn't true.
Then show them, my list is all the successes and you can't even come up with one failure.
Why doesn't the FSF just run an open server and allow iOS devices from across the world to point to this and not the Apple servers?
My guess is they wouldn't want to be seen to be supporting and encouraging the use of a proprietary platform.
You get a robust and snappy storage and website for communication at the cost of control over your life and privacy.
I think you need to get a grip with reality: using Facebook doesn't mean you have no privacy and no control of your life...unless of course your life is nothing outside of Facebook, but in that case a grip on reality is again what you need.
X11 was the typical example of BSD failure.
But ultimately we have X.Org and all those old UNIX systems pretty much died out. To the contrary there are a lot of hugely popular examples of success: Docker, OpenStack, OpenSSL, OpenSSH, Apache webserver, Hadoop, WebKit, zlib, postgres, OpenLDAP, Ruby, Clang, X.Org, etc...
One example from over 20 years ago is not particularly representative of anything and a far cry from "a long proven track record of failure", that is just absolute rubbish.
Well then "tablet mode" is a perfectly fine name for it - despite the fact that you might want that mode on a non-tablet or not want that mode on a tablet depending on your interaction method which is why the automatic switching is an opt-in option and not a default.
Your argument is: "premium shit costs like $500 and this costs $300, so their +$50 offer isn't a premium option."
No, if that is what you got from that then you obviously have some problem with basic English. What I said was:
"this isn't marketed at the premium price point"
And of course it isn't, it is substantially lower than the $600-$800 offerings at the top end.
The problem is they sell two options: the basic 16GB option and the premium 64GB option. The fact that their PREMIUM OPTION is cheaper than some Rolls Royce bullshit doesn't mean it's not a premium option.
Oh what a terrible problem! They sell two options, how awful!
The original argument was that availability of SD card slots would suppress the market value of in-phone storage.
Yes it's all a big conspiracy that all the phone makers - who are also competitors - are colluding on even though many of these phone makers offer phone models with and without SD card slots.
Why don't phones have SD storage?
Many of them do have SD storage, just not all of them. On some models they prefer not to have an exposed, mechanical and relatively bulky (if you're looking at the thinness of modern devices) mechanism for storage and instead use soldered memory to avoid these problems.
We're talking about the problem with mobile device "longevity".
From what I understand, a significant chunk of the problem with mobile device "longevity" is that closed source drivers for the SoC's used in phones are typically provided by chipset vendors, and if the driver model used by the O/S ever changes then the SoC vendor needs to provide a newer set of drivers.
That's mostly it, the problem is that the Linux kernel binary interface is unstable so binary drivers that work in one version may not work in the next version and would often need to be modified and rebuilt against the newer kernel then distributed.