Ubuntu touch not "marginalising" carriers.
At Melbourne mobile last night I participated in a Google Hangout with Ubuntu Phone product manager Richard Collins where he said some rather controversial things about Ubuntu Touch / Ubuntu Phone. Namely that it would succeed because it wouldn't "marginalise" the poor carriers out of customising their device and that access to the filesystem would be "up to the individual manufacturer". I'm curious to see if anyone has the same "what the hell" reaction I did to hear the Ubuntu brand and all it represents being pitched this way. Anyway, here's the link to the Google hangout - Interested to hear people's opinions. https://www.youtube.com/watch?v=90xcwK1sbQg - Noah
I think Ubuntu is committed to providing openness wherever possible, though I'm sure I would not have to look too far to find a contrary opinion. I think you will find that this is the commercial reality of dealing with mobile carriers. And they have always stated that they will allow vendors to customise the OS. On 19 Mar 2014 13:41, <noah.odonoghue@gmail.com> wrote:
At Melbourne mobile last night I participated in a Google Hangout with Ubuntu Phone product manager Richard Collins where he said some rather controversial things about Ubuntu Touch / Ubuntu Phone.
Namely that it would succeed because it wouldn't "marginalise" the poor carriers out of customising their device and that access to the filesystem would be "up to the individual manufacturer".
I'm curious to see if anyone has the same "what the hell" reaction I did to hear the Ubuntu brand and all it represents being pitched this way.
Anyway, here's the link to the Google hangout - Interested to hear people's opinions. https://www.youtube.com/watch?v=90xcwK1sbQg
- Noah
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
On 19/03/14 13:35, noah.odonoghue@gmail.com wrote:
Namely that it would succeed because it wouldn't "marginalise" the poor carriers out of customising their device and that access to the filesystem would be "up to the individual manufacturer".
Android sucks *precisely* because manufacturers customise the hell out of it. Poorly, at that.
On 19/03/14 15:38, Jeremy Visser wrote:
On 19/03/14 13:35, noah.odonoghue@gmail.com wrote:
Namely that it would succeed because it wouldn't "marginalise" the poor carriers out of customising their device and that access to the filesystem would be "up to the individual manufacturer".
Android sucks *precisely* because manufacturers customise the hell out of it. Poorly, at that.
Exactly. I (unsurprisingly[1]) run straight upstream Android on a Nexus 5. Until I picked up a Samsung Galaxy Camera as a toy in late 2012 I hadn't really tried to use a non-official Android, and was surprised at how different it was. One thing that's also quite irritating is people installing Cyanogen/whatever and espousing their favourite new features, and inevitably at least one is something that is actually part of upstream Android, just blocked or hidden by the manufacturer or carrier. 1: For those who don't know I work for Google as a Network Engineer in Sydney these days
Google has the market power and resources to provide this option though. Hopefully Canonical will be able to provide the equivalent too through the 'non-marginal' carriers. Android has plenty of other issues, though I think its the best available mobile option. Excepting the sailfish phone, which is way beyond my budget. http://jolla.com/ Also relevant: Tizen, which is Linux Foundation backed, is also allowing customisation by manufacturers and carriers. Hence why samsung is trying it out for their smartwatch. Just pre-empting anyone who wants to beat on Canonical for trying to navigate the commercial realities of the mobile device market =) On 19 March 2014 23:20, Julien Goodwin <luv-lists@studio442.com.au> wrote:
On 19/03/14 15:38, Jeremy Visser wrote:
On 19/03/14 13:35, noah.odonoghue@gmail.com wrote:
Namely that it would succeed because it wouldn't "marginalise" the poor carriers out of customising their device and that access to the filesystem would be "up to the individual manufacturer".
Android sucks *precisely* because manufacturers customise the hell out of it. Poorly, at that.
Exactly.
I (unsurprisingly[1]) run straight upstream Android on a Nexus 5. Until I picked up a Samsung Galaxy Camera as a toy in late 2012 I hadn't really tried to use a non-official Android, and was surprised at how different it was.
One thing that's also quite irritating is people installing Cyanogen/whatever and espousing their favourite new features, and inevitably at least one is something that is actually part of upstream Android, just blocked or hidden by the manufacturer or carrier.
1: For those who don't know I work for Google as a Network Engineer in Sydney these days _______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
On Wed, 19 Mar 2014 11:20:15 PM Julien Goodwin wrote:
One thing that's also quite irritating is people installing Cyanogen/whatever and espousing their favourite new features, and inevitably at least one is something that is actually part of upstream Android, just blocked or hidden by the manufacturer or carrier.
Or useful features "accidentally" released by Google and then removed again. https://lwn.net/Articles/577593/ cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
On Wed, 19 Mar 2014, noah.odonoghue@gmail.com wrote:
Namely that it would succeed because it wouldn't "marginalise" the poor carriers out of customising their device and that access to the filesystem would be "up to the individual manufacturer".
http://www.debian.org/social_contract Ubuntu is based on Debian. The Debian Social Contract has a section about no discrimination against fields of endeavor, that includes not preventing companies from making commercial devices based on Debian. There is nothing to prevent someone selling a locked down Debian system that prevents the user from accessing the filesystem as long as they make all the source code available. For a system that has no changed binaries the reseller can just refer users to the Debian web site to meet this clause. While locked down phones aren't appreciated by many Debian Developers we have no policy that prevents such things, and under Debian rules no DD can do anything about that. While actively supporting phone vendors in restricting their customers isn't a desirable thing (IMHO and probably most DDs agree) it's not unreasonable for a company to want to do this to make money. Canonical has a plan to become a profitable company. I think that having Canonical make money this way is a lot better than MS selling locked down Windows phones. For the Australian market it shouldn't matter so much as currently none of the Telcos are selling phones at good prices. For any phone that you want you can get it a lot cheaper from Kogan than from any bundled deal from a Telco. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Russell Coker wrote:
............snip
While locked down phones aren't appreciated by many Debian Developers we have no policy that prevents such things, and under Debian rules no DD can do anything about that.
While actively supporting phone vendors in restricting their customers isn't a desirable thing (IMHO and probably most DDs agree) it's not unreasonable for a company to want to do this to make money.
In the video, the issue of filesystem access, seemed to be more about the requirements of 'warranty insurance' ; than patentable devices ? regards Rohan McLeod
I don't understand how warranty is ever an issue with changing the software on your phones.. If it breaks, boot to recovery mode and flash back.. The OEM can provide a utility and instructions how to just like apple does with DFU mode and iTunes, and android does with easyboot.. The emergency recovery loader should always be in ROM (not flash) and allow you to recover easily. -Noah On Friday, March 21, 2014, Rohan McLeod <rhn@jeack.com.au> wrote:
Russell Coker wrote:
............snip
While locked down phones aren't appreciated by many Debian Developers we have no policy that prevents such things, and under Debian rules no DD can do anything about that.
While actively supporting phone vendors in restricting their customers isn't a desirable thing (IMHO and probably most DDs agree) it's not unreasonable for a company to want to do this to make money.
In the video, the issue of filesystem access, seemed to be more about the requirements of 'warranty insurance' ; than patentable devices ?
regards Rohan McLeod
_______________________________________________ luv-main mailing list luv-main@luv.asn.au <javascript:;> http://lists.luv.asn.au/listinfo/luv-main
Noah O'Donoghue wrote:
I don't understand how warranty is ever an issue with changing the software on your phones.. If it breaks, boot to recovery mode and flash back.. The OEM can provide a utility and instructions how to just like apple does with DFU mode and iTunes, and android does with easyboot The emergency recovery loader should always be in ROM (not flash) and allow you to recover easily.
Don't forget we are discussing the issue from the phone manufacturer's POV; perhaps warranty insurance requirements must preclude naive users from trashing the file system then making a warranty claim. I quite agree ' reflash to factory default' should satisfy warranty insurance requirements; but do they actually ? Insurance companies don't always see things the way the rest of us do . regards Rohan McLeod
Noah O'Donoghue wrote:
I don't understand how warranty is ever an issue with changing the software on your phones.. If it breaks, boot to recovery mode and flash back.. The OEM can provide a utility and instructions how to just like apple does with DFU mode and iTunes, and android does with easyboot The emergency recovery loader should always be in ROM (not flash) and allow you to recover easily.
Don't forget we are discussing the issue from the phone manufacturer's POV; perhaps warranty insurance requirements must preclude naive users from trashing the file system then making a warranty claim. I quite agree ' reflash to factory default' should satisfy warranty insurance requirements; but do they actually ? Insurance companies don't always see things the way the rest of us do .
If I buy a phone and use it for a short time for its intended purpose (eg not going to town with hacks and roots) and then it starts acting up, you can be sure I'll be on the phone to the warranty hotline, and you can be sure I won't take "Sir, can you please try resetting your device to factory defaults" as an acceptable response. The phone will get replaced, or I'll get a refund and go back to Android. I don't think any of you should demand anything less from a product you paid good money for. If it screwed up once it will do it again. That's why Telco's don't like you messing with "their" products, because you might screw it up and then make a warranty claim. All bets are off if you overclock it or test out the latest super-battery-life hack, but most people won't confess that to their warranty provider anyway... James
James Harper wrote:
Noah O'Donoghue wrote:
I don't understand how warranty is ever an issue with changing the software on your phones.. ....................snip Don't forget we are discussing the issue from the phone manufacturer's POV; ................snip If I buy a phone and use it for a short time forits intended purpose (eg not going to town with hacks and roots) and then it starts acting up, you can be sure I'll be on the phone to the warranty hotline, and you can be sure I won't take "Sir, can you please try resetting your device to factory defaults" as an acceptable response. The phone will get replaced, or I'll get a refund and go back to Android
James I don't disagree with any of that ; but the issue is why do phone manufacturers; need to restrict file system access ? - is it a warranty insurance issue; ie to do with support ? - is it to do with the 'patentability' of the device ie to do with the distinguishably of the device ? -something else ? regards Rohan McLeod
On 20/03/14 14:48, James Harper wrote:
If I buy a phone and use it for a short time for its intended purpose (eg not going to town with hacks and roots) and then it starts acting up, you can be sure I'll be on the phone to the warranty hotline, and you can be sure I won't take "Sir, can you please try resetting your device to factory defaults" as an acceptable response. The phone will get replaced, or I'll get a refund and go back to Android.
How about “Sir, can you please update to the latest firmware and try to reproduce the issue once more”? I would think that’s perfectly reasonable.
On Thu, 20 Mar 2014, James Harper <james.harper@bendigoit.com.au> wrote:
If I buy a phone and use it for a short time for its intended purpose (eg not going to town with hacks and roots) and then it starts acting up, you can be sure I'll be on the phone to the warranty hotline, and you can be sure I won't take "Sir, can you please try resetting your device to factory defaults" as an acceptable response. The phone will get replaced, or I'll get a refund and go back to Android.
I think that reseting to factory defaults is a reasonable requirement. I recently had a warranty issue with a Samsun Galaxy S3 I bought from Kogan, the camera had stopped working for no apparent reason. They asked me to do a reset to factory defaults before sending it back, given that I wasn't going to send a phone back without wiping my data and that they were going to bill me if it turned out not to be a hardware fault that seemed a reasonable thing to do anyway. Phones are so complex and tightly integrated that you can't be sure it's a hardware issue without resetting the configuration. It turned out that the Qi wireless charging device I had installed in that phone was the cause of the problem. As I had bought the Qi device from Kogan I asked for a refund of it's purchase price and they were happy to give that to me (it was cheaper for them than getting a phone back for service). So I ended up with a wiped phone without Qi support that works correctly. But it wasn't all bad, the phone was significantly faster after being wiped. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
"Noah O'Donoghue" <noah.odonoghue@gmail.com> writes:
I don't understand how warranty is ever an issue with changing the software on your phones.. If it breaks, boot to recovery mode and flash back..
\begin{pedantry} That assumes you don't also reflash the bootloader (e.g. because the vendor-provided one can't boot from removable media). If you reflash it with a new uboot and you've cocked that up, you could brick it. \end{pedantry}
Trent W. Buck <trentbuck@gmail.com> wrote:
"Noah O'Donoghue" <noah.odonoghue@gmail.com> writes:
I don't understand how warranty is ever an issue with changing the software on your phones.. If it breaks, boot to recovery mode and flash back..
\begin{pedantry}
That assumes you don't also reflash the bootloader (e.g. because the vendor-provided one can't boot from removable media). If you reflash it with a new uboot and you've cocked that up, you could brick it.
\end{pedantry}
How much extra would it cost manufacturers to design devices so that there's a backup boot loader in ROM which can't be overwritten?
On 21/03/14 10:10, Jason White wrote:
How much extra would it cost manufacturers to design devices so that there's a backup boot loader in ROM which can't be overwritten?
For many devices these days, "ROM" _is_ flash, perhaps with a write protect or security bit set. It isn't just a cost disadvantage to add a real ROM, it also wastes board space, and it means that a code error in the boot loader can't even be fixed with a factory recall. The problem isn't that hard. If a manufacturer really wants us to be able to change the software, they just provide a two stage loader; a simple one in a write protected area, to load in a more generic operating system loader that is user replaceable. This does take a little planning, because the manufacturer has to find a user accessible way to provide a code update, and a way to force the boot loader on initialization, eg by holding down some button combination and holding up your left arm in the air. Many devices work this way already; it isn't a significant increase in development cost. For example, I have a Linux based ereader which allows you to reflash it simply by powering up after inserting an SD card with an appropriately formatted binary. It is relatively foolproof, because the SD card is checked by the boot loader on startup, and there is no need to ever overwrite the original boot loader. The key point here though is that some manufacturers don't particularly want their users to change the software, and go out of their way to make it difficult. This leads to boot loader workarounds which might carry the risk of an unrecoverable state. But I do think that if a smartphone is being sold as a computing device, then we can reasonably expect to be able to run the software of our choice, otherwise it is a dumbphone. If the result of workarounds is a brickedphone, then I think that the seller should take at least some of the responsibility for deliberately making it difficult to change the software. If someone sold me a ceramic bowl, but the packaging was such that I couldn't unwrap the thing without a high risk of breaking it, then I wouldn't be happy. Likewise, I have no desire to buy a computing device for which installing different software carries a significant risk of bricking it. Glenn -- sks-keyservers.net 0x6d656d65
Jason White <jason@jasonjgw.net> writes:
That assumes you don't also reflash the bootloader (e.g. because the vendor-provided one can't boot from removable media). If you reflash it with a new uboot and you've cocked that up, you could brick it.
How much extra would it cost manufacturers to design devices so that there's a backup boot loader in ROM which can't be overwritten?
My tegra2 had such a thing. It wasn't fun to use, but OTOH I repeatedly bricked my uboot. PS: because the instructions said to build uboot on x86 with ARCH=arm, but I was building it natively so omitted ARCH=arm... which broke it. By the time I knew, I'd given up and was stuck with android bootloader...
PS: ISTR some of the later asus transformers had a different SBK for each device -- you needed to know it to reflash it[0]. So they set up a site where you could enter your S/N and they would tell you the SBK -- and they'd remember that the (software?) warranty was void for that S/N. Assuming they still honor hardware warranty, that seems like a reasonable compromise to me. [0] or to exploit a bug, like Apple users have to do.
participants (12)
-
Chris Samuel -
Glenn McIntosh -
James Harper -
Jason White -
Jeremy Visser -
Julien Goodwin -
Noah O'Donoghue -
noah.odonoghue＠gmail.com
-
Rohan McLeod -
Russell Coker -
thelionroars -
trentbuck＠gmail.com