I've been excited about this ever since they announced it a year ago, the thought of having "just a phone" instead of a phone, laptop and tablet is so awesome it's going to outclass everything.
The one thing I'm afraid of is how resource-intensive certain classes of software are. I tried a netbook over a year ago and wouldn't want that kind of performance except in emergencies, even today every single IDE I run is a slow piece of crap on last year's maxed out macbook air.
Its a nice idea but you're still going to need to put the money down for the specialist docking stations to turn this a laptop, tablet or a desktop, and you'll probably be stuck with the processing power and more importantly the IO of your phone for all of them.
I'm not sure the reality will turn out as good as the idea, at least not for several years yet. That'll give Canonical time to catch up to Microsoft, the latter of which isn't really popular because they've shown how easy it is to botch the idea.
Some IDE's are just better at doing similar things than others. VS2k10 intellisense is orders of magnitude faster/stable/* than implementations in other IDE's.
In all seriousness though, I do agree with this with the exception that the IDE needs to make room for the application you're writing. If it can use an extra core to provide smarter autocompletion or discover potential bugs, I'm all for it.
I spent the long NYE weekend in Washington, DC. On Friday night, my phone was stolen. This was, obviously, rather painful and distressing, not to mention inconvenient (being alone in the middle of a city I don't know very well, suddenly cut off from maps, yelp, wiki, etc.
Luckily, back at the hotel I had my laptop, from which I was able to remote wipe my phone, get contact info for my carrier to get service shut-off, and file an insurance claim to get a replacement phone.
The moral of this story: Beware of excessive convergence, and always have a Plan B.
Plan B is to make your profile independent of your hardware and just get a replacement, same thing I had to do when my laptop was stolen and smartphones were even dumber than me for letting my laptop get stolen. :(
I'm not nearly as excited for dockable PC/phone hybrids as I am for a phone running GNU free software.
In fact I'm already looking to replace my perfectly usable HTC phone for a Nexus so I can install the image Ubuntu is supposed to release in a few weeks.
I stopped using Ubuntu on my laptop because there are better alternatives out there. But I think Ubuntu can really shine as a mobile OS, and it will almost certainly be better than Android or iOS for my purposes.
For one thing, we've got Unix "apps" that have been maintained for 30 years, like vim and emacs. So in my mind, the software ecosystem is much better, even before launch.
Configurability is a huge plus for me. Could you imagine recompiling your phone's kernel? Configuring your phone with dotfiles? Serving webpages and email? Not everyone's cup of tea, and I hope there are more user-friendly options available, but having that power is enticing.
I'm looking forward to better multitasking, and multiple user accounts. Also a more open hardware ecosystem, such as USB and HDMI ports, docks, chargers, USB keyboards, maybe a laptop "shell" I can insert my phone into?
If we look at the "dockable PC" side of things, the developer tools are unparalleled.
And of course free software. CyanogenMod is pretty great already, and Busybox too, but I think a GNU presence will only help. Maybe I drank too much of RMS's koolaid.
I would love for my phone to be my primary computer, and just plug it into a mouse/keyboard/monitor whenever I need to do real work (the latter implies having full control of anythin I want to control, like I have now in Arch Linux).
Other than that, I don't really see the use case (for me personally) for most of what you're saying. I mean, vi/emacs are not useful on the phone, because it doesn't have a real keyboard. Since it doesn't have a real keyboard, I can't do real things with it, so there is no need for a lot of customization (e.g. with dotfiles).
A 5 dollar USB hub can be used as a dock, assuming the USB port can be a USB host (even the cheapest Android hardware usually can), and a hub lets you dock to a full-sized keyboard, mouse, and even external VGA/DVI.
One more reason for a proper bootloader (to dual boot a preset working interface) and/or a basic recovery ROM (like old Macs) that can always place phone calls.
I'm not saying it couldn't happen, but it seems unlikely. What are the odds that I'd need to call 911 and:
1) I'm alone
2) I'm not near my car (I carry an old flip phone in the glove compartment for emergencies)
3) I've messed up my phone sufficiently enough that 911 doesn't work but most other things work fine
> Configurability is a huge plus for me. Could you imagine recompiling your phone's kernel? Configuring your phone with dotfiles? Serving webpages and email? Not everyone's cup of tea, and I hope there are more user-friendly options available, but having that power is enticing.
I'm looking forward to better multitasking, and multiple user accounts. Also a more open hardware ecosystem, such as USB and HDMI ports, docks, chargers, USB keyboards, maybe a laptop "shell" I can insert my phone into?
FWIW, you can do all these on Android in some form or another.
We'll see about that. I mean will the manufacturers of Ubuntu phones and tablets open source their drivers? Seems pretty unlikely, although it would certainly be nice to see, and some of the chip makers have started making open source drivers for their chips lately. Will the concept of a locked bootloader ever exist on Ubuntu devices? I hope Mark never agrees to such a thing. Same with censorship/surveillance stuff built into their devices that get sold in China. I'd rather he didn't accept that business.
Sure, eventually. But Ubuntu is blazing the trail here, and that counts for a lot. Right now, the Android is the only Linux "distro" (actually a completely different OS from regular GNU/Linux) that runs on phones.
After Ubuntu, I can imagine a Debian phone, or an Arch phone, or even an LFS phone. But right now, I can't. (Unfortunately, I don't think Pat Volkerding can ever support a Slackware phone. So we'll see if I ever move away from Ubuntu on mobile. Right now that's all moot though because none of it exists yet.)
As long as we have some honest to god, native-C support I'll be pleasantly pleased. I'd rather be an android consumer rather than an android programmer, Dalvik just doesn't interest me at all.
Java. I'm not passionate about it at all and if I can't find the motivation to learn it then I'm not going to use it. The great thing about C is it's practically universal.
And the fact that you had no UI library in the NDK (this might have changed since 2.3) meant I was going nowhere with that on that front.
You still have to go through JNI and use Java/XML for the interface, but the NDK has been growing to encompass more and more with each release. (And in my opinion, keeping a standard way for making the actual UI users see is important for consistency. It's more difficult to enforce that with purely native apps.)
Android (and I think iOS?) both reserve the right to purge paused apps from memory if memory is needed (a paused app being an app that the user is not currently looking at). This seems well suited to phones, but leads to a totally different programming model whereby apps must be ready to persist their state and be deflated/reinflated/stopped without warning.
Will Ubuntu for Phones struggle to make good use of the phone memory if it doesn't use this technique? (I assume it just uses the desktop-PC model of 'a thing is running until its stopped, page to disk if necessary?')
edit: also, as people have pointed out, there are battery life implications
Perhaps Shuttleworth is counting on phones having more than a few gigs of RAM in the near future, making app suspension rather pointless if your concern is memory. (Rather, it is more useful to me in prolonging battery life.)
While this is important for memory, it is also really important for battery usage.
My experience with Android is that waking every second is enough to kill a phone's battery noticeably faster. I suspect most existing linux apps and frameworks are not good at saving CPU and battery enough to be on a phone. I would be happy to be proved wrong.
I mean that Android/iOS apps have to listen for 'pause' events and the like, and then pause themselves pronto and save all their state somewhere, and then (if needed) re-inflate themselves and pop back infront of the user as if nothing has happened. The smartphone App lifecycle and way state is managed is pretty different to a general PC application.
This technique already exists in Unix, and has for decades. SIGTERM is easy to deliver, can be caught trivially if needed, and its default action is generally exactly what you want (i.e. it kills the process -- on smartphones software generally needs to be tolerant of an unexpected shutdown anyway due to battery death, etc...).
This same argument was had in the MeeGo days. Putting a bunch of junk into the framework APIs to support this is just needless "feel good" complexity around a problem that's already solved. All that's needed is a component to make the decision to kill processes.
Thats somewhat similar. But iOS and Android apps are built to pause/sleep, which is somewhat different to a kill. A paused Android/iOS app might get killed, but it might also get un-paused, and then it has to carry on (in the users eyes) as if it was never interfered with at all.
If you want presistent state in your GUI app then yes, you have to have that in the app framework. Ubuntu for Phones is using a new (and so-far closed source!) Qt5-based framework, so I can't speak to their choice there. I suspect they've picked something sane, though.
This is, however, a tangent. The ability for an app to persist state and "start" in the last state the user saw has nothing to do with the OS's ability to kill an app to conserve memory. And note again that the requirement for an app to survive an unexpected failure (i.e. you can't expect to have been "paused" -- this is true on Android and iOS too!) is still there, there's nothing that extra layers of API will do to fix that.
> The ability for an app to persist state and "start" in the last state the user saw has nothing to do with the OS's ability to kill an app to conserve memory.
I'd say it does. Pausing apps (as opposed to killing them) is another way of conserving memory, and battery, while preserving usability.
But as you say perhaps Qt5 will handle this. Is the Ubuntu Phone restricted to only running Qt5 apps? I'm not clear on that.
As it happens, there's also SIGSTOP and SIGCONT. The responsibility to write the app correctly is always going to fall on the app developer. It's just that for phone apps, it's a lot more obvious that you need to. But it doesn't have to be that way, and frameworks to facilitate writing apps like this would be a totally userland proposition, just using traditional Unix signals that are rarely used today.
I think its important for the non-Embedded people to understand something: there is nothing in the iOS Systems Criticality design which wasn't already figured out, 20 years previously, in the history of computing. Nada.
iOS was, essentially, the consumer-computer-OS marketing people finally getting some proper engineering under their skin enough so that they could pretty it up and package it and sell it, $99 a pop, to all the teenager coders. The effort to get OSX and iOS suitable for such demanding environments as the teenage pocket just suddenly became an Embedded discipline, rather than the monolithic desktop phase. Of course iOS is now an Embedded OS; but OSX pretty much always should have been in the first place, albeit for the hardware gluttony of the 90's and so on. Nobody ever really used every single megabyte, productively, much space out there being maintained by the Desktop OS's is pure fat and cream, all things considered, from an Embedded OS perspective. Oh, you've got a pagefile that a daemon resizes for you if you need it .. luxury! :)
But in the embedded world, such a problem as purging unused apps, dealing with power models and load concerns and failover policies, and so on: solved, done deal, decades ago.
In the POSIX model, you have all the signals. A well-written program will receive them, know what they mean, and handle them. It takes very little work to set up signal handlers to recieve power events, or RAM-overrun/underuse events, from the kernel. The difference in the Embedded world is, most C-/or Assembly- coders were expected to know it, per the specs of the Embedded Application. Onboard computers for Rail-Transportation, for example, have had an operational - and safety-critical certified - power management model very similar to the way Apple treat the Phone Services, for decades.
Most pre-DOS computers had means of managing such things too. My old Magnum Pizzabox would tell me when the LPT lines went high/low, in case the lineprinter drawing current from it was suddenly, actually, on fire. (I kid, but then again, not really..)
And now what is happening is Ubuntu is getting an Embedded tattoo, too. An easy thing for Linux; Linux has been Embedded friendly, for a long time. (If you travel anywhere by Rail in Europe, the UAE, Canada, and many other countries, Linux is keeping your train on the track.. and has, for the last 10 years, been running big machines elsewhere, 24/hrs. day, 365, year after year, power on and frequently .. off ..)
One of the biggest criticisms levelled at android has been that the UI feels a little clunky and slow and that changes made by carriers and manufacturers usually make the experience worse.
If they can make this phone feel like an iPhone in terms of smoothness and keep a nice consistent feel then this might have a chance of being a premium choice over android.
The Verge played with the Ubuntu phone and while it's a dev release at this point, you can see from the video it's painfully slow on the latest hardware for UI things:
Too bad they aren't big like Microsoft, who can flat out pay people to port apps and run constant developer events, etc.. Heck, even BlackBerry has been constantly giving out phones and prizes and benefits to developers. Ubuntu just doesn't have the infrastructure to get the apps on to the platform, and the users want good apps. Even if you can port something from a Linux desktop version easily, it's still going to lack software.
> Canonical's secret sauce in selling carriers on Ubuntu might lie in helping them sell their own services to end users. Carriers "care about brand and we know how to accommodate that," Shuttleworth said. "They care about their own content and we've essentially put their content on an equal footing with content from the ecosystem. The handset manufacturer or operator that has music, films, or other types of content can promote their content to their users or other users directly in a way that doesn't feel like a bolt-on or a sideshow."
I do not want any content from my phone manufacturer, much less operator. From experience, this is almost exclusively overpriced crap, useless apps or branding.
I Think if somebody can make a phone os better than android, and more intuitive (easy for non-tech people).. not only that but have the capacity to enchant the mobile hardware players(good lobby push)
Android can be beaten away.. but not the same can be said about to IOS.. its all about brand.. its a tough fight..
But android market share, is not much about the consumers that want it because they need..(theres no sentimental decision about it) its about the device makers, making the decision for this share of the market..
if ubuntu can convince device makers to put that in their phones.. (with the help of some good apps, so theres no cultural shock).. i think people will not care much..
and for developer comunity, i think is better.. we need to get free from the centralized app market model from apple..
whoever delivers that is my friend :)
"Shuttleworth believes that Ubuntu will be more user-friendly for people who barely know how to use a smartphone."
An experience that is more user friendly than iOS and more user friendly than Windows Phone will be hard to do. Beating Android might be easier. Furthermore, very few people with money haven't already used a smartphone, so they'll be aiming for the market of people who have no money. Not exactly lucrative, and Android has distinct advantages there. Android can be cheaper than Ubuntu because they can monetize mobile advertising better.
In short, this effort will totally fail. There is no compelling reason to have a 5th player in the smartphone market, and given Ubuntu's track record with desktop UI, I don't think their effort in mobile will be terribly inspired.
63 comments
[ 2.9 ms ] story [ 109 ms ] threadThe one thing I'm afraid of is how resource-intensive certain classes of software are. I tried a netbook over a year ago and wouldn't want that kind of performance except in emergencies, even today every single IDE I run is a slow piece of crap on last year's maxed out macbook air.
I'm not sure the reality will turn out as good as the idea, at least not for several years yet. That'll give Canonical time to catch up to Microsoft, the latter of which isn't really popular because they've shown how easy it is to botch the idea.
If your IDE isn't using your whole hardware, it's probably not doing enough.
I spent the long NYE weekend in Washington, DC. On Friday night, my phone was stolen. This was, obviously, rather painful and distressing, not to mention inconvenient (being alone in the middle of a city I don't know very well, suddenly cut off from maps, yelp, wiki, etc.
Luckily, back at the hotel I had my laptop, from which I was able to remote wipe my phone, get contact info for my carrier to get service shut-off, and file an insurance claim to get a replacement phone.
The moral of this story: Beware of excessive convergence, and always have a Plan B.
I'm debating a yearly/bi yearly replaecment of a MBA instead of a bi yearly/triyearly replacement of the maxed out top of the line MBP.
How much is this going to hurt with two ACDs plugged into it?
This says they do.
How many Ubuntu TVs were sold?
This guy lives in a reality distortion field beyond belief.
2. In 2011, they sold 8-10 million, and in May said they were on track to reach 20 million in 2012. http://www.omgubuntu.co.uk/2012/05/ubuntu-to-ship-on-5-of-al...
3. In October of 2011, Dell started featuring Ubuntu in over 200 retail stores in China. http://blog.canonical.com/2011/10/27/retail-stores-in-china/
So it's entirely possible they could meet the 20m number.
In fact I'm already looking to replace my perfectly usable HTC phone for a Nexus so I can install the image Ubuntu is supposed to release in a few weeks.
I stopped using Ubuntu on my laptop because there are better alternatives out there. But I think Ubuntu can really shine as a mobile OS, and it will almost certainly be better than Android or iOS for my purposes.
Can you give specific examples? I'm genuinely curious.
Configurability is a huge plus for me. Could you imagine recompiling your phone's kernel? Configuring your phone with dotfiles? Serving webpages and email? Not everyone's cup of tea, and I hope there are more user-friendly options available, but having that power is enticing.
I'm looking forward to better multitasking, and multiple user accounts. Also a more open hardware ecosystem, such as USB and HDMI ports, docks, chargers, USB keyboards, maybe a laptop "shell" I can insert my phone into?
If we look at the "dockable PC" side of things, the developer tools are unparalleled.
And of course free software. CyanogenMod is pretty great already, and Busybox too, but I think a GNU presence will only help. Maybe I drank too much of RMS's koolaid.
Other than that, I don't really see the use case (for me personally) for most of what you're saying. I mean, vi/emacs are not useful on the phone, because it doesn't have a real keyboard. Since it doesn't have a real keyboard, I can't do real things with it, so there is no need for a lot of customization (e.g. with dotfiles).
Don't rely on your "hacking phone" for emergencies, at least until you can verify it will work.
1) I'm alone 2) I'm not near my car (I carry an old flip phone in the glove compartment for emergencies) 3) I've messed up my phone sufficiently enough that 911 doesn't work but most other things work fine
FWIW, you can do all these on Android in some form or another.
After Ubuntu, I can imagine a Debian phone, or an Arch phone, or even an LFS phone. But right now, I can't. (Unfortunately, I don't think Pat Volkerding can ever support a Slackware phone. So we'll see if I ever move away from Ubuntu on mobile. Right now that's all moot though because none of it exists yet.)
And the fact that you had no UI library in the NDK (this might have changed since 2.3) meant I was going nowhere with that on that front.
You still have to go through JNI and use Java/XML for the interface, but the NDK has been growing to encompass more and more with each release. (And in my opinion, keeping a standard way for making the actual UI users see is important for consistency. It's more difficult to enforce that with purely native apps.)
Will Ubuntu for Phones struggle to make good use of the phone memory if it doesn't use this technique? (I assume it just uses the desktop-PC model of 'a thing is running until its stopped, page to disk if necessary?')
edit: also, as people have pointed out, there are battery life implications
My experience with Android is that waking every second is enough to kill a phone's battery noticeably faster. I suspect most existing linux apps and frameworks are not good at saving CPU and battery enough to be on a phone. I would be happy to be proved wrong.
I think you meant battery usage.
(I'll delete this comment to reduce clutter after you edit...)
This same argument was had in the MeeGo days. Putting a bunch of junk into the framework APIs to support this is just needless "feel good" complexity around a problem that's already solved. All that's needed is a component to make the decision to kill processes.
This is, however, a tangent. The ability for an app to persist state and "start" in the last state the user saw has nothing to do with the OS's ability to kill an app to conserve memory. And note again that the requirement for an app to survive an unexpected failure (i.e. you can't expect to have been "paused" -- this is true on Android and iOS too!) is still there, there's nothing that extra layers of API will do to fix that.
I'd say it does. Pausing apps (as opposed to killing them) is another way of conserving memory, and battery, while preserving usability.
But as you say perhaps Qt5 will handle this. Is the Ubuntu Phone restricted to only running Qt5 apps? I'm not clear on that.
iOS was, essentially, the consumer-computer-OS marketing people finally getting some proper engineering under their skin enough so that they could pretty it up and package it and sell it, $99 a pop, to all the teenager coders. The effort to get OSX and iOS suitable for such demanding environments as the teenage pocket just suddenly became an Embedded discipline, rather than the monolithic desktop phase. Of course iOS is now an Embedded OS; but OSX pretty much always should have been in the first place, albeit for the hardware gluttony of the 90's and so on. Nobody ever really used every single megabyte, productively, much space out there being maintained by the Desktop OS's is pure fat and cream, all things considered, from an Embedded OS perspective. Oh, you've got a pagefile that a daemon resizes for you if you need it .. luxury! :)
But in the embedded world, such a problem as purging unused apps, dealing with power models and load concerns and failover policies, and so on: solved, done deal, decades ago.
In the POSIX model, you have all the signals. A well-written program will receive them, know what they mean, and handle them. It takes very little work to set up signal handlers to recieve power events, or RAM-overrun/underuse events, from the kernel. The difference in the Embedded world is, most C-/or Assembly- coders were expected to know it, per the specs of the Embedded Application. Onboard computers for Rail-Transportation, for example, have had an operational - and safety-critical certified - power management model very similar to the way Apple treat the Phone Services, for decades.
Most pre-DOS computers had means of managing such things too. My old Magnum Pizzabox would tell me when the LPT lines went high/low, in case the lineprinter drawing current from it was suddenly, actually, on fire. (I kid, but then again, not really..)
And now what is happening is Ubuntu is getting an Embedded tattoo, too. An easy thing for Linux; Linux has been Embedded friendly, for a long time. (If you travel anywhere by Rail in Europe, the UAE, Canada, and many other countries, Linux is keeping your train on the track.. and has, for the last 10 years, been running big machines elsewhere, 24/hrs. day, 365, year after year, power on and frequently .. off ..)
If they can make this phone feel like an iPhone in terms of smoothness and keep a nice consistent feel then this might have a chance of being a premium choice over android.
http://www.theverge.com/2013/1/2/3828266/ubuntu-phone-os-han...
I do not want any content from my phone manufacturer, much less operator. From experience, this is almost exclusively overpriced crap, useless apps or branding.
Unity and accompanied py-qt based stuff is crap being pushed.
I don't see why to expect something different form a repetition of the same "strategy" - pushing half-baking crap in a rush.
Android can be beaten away.. but not the same can be said about to IOS.. its all about brand.. its a tough fight..
But android market share, is not much about the consumers that want it because they need..(theres no sentimental decision about it) its about the device makers, making the decision for this share of the market..
if ubuntu can convince device makers to put that in their phones.. (with the help of some good apps, so theres no cultural shock).. i think people will not care much..
and for developer comunity, i think is better.. we need to get free from the centralized app market model from apple.. whoever delivers that is my friend :)
An experience that is more user friendly than iOS and more user friendly than Windows Phone will be hard to do. Beating Android might be easier. Furthermore, very few people with money haven't already used a smartphone, so they'll be aiming for the market of people who have no money. Not exactly lucrative, and Android has distinct advantages there. Android can be cheaper than Ubuntu because they can monetize mobile advertising better.
In short, this effort will totally fail. There is no compelling reason to have a 5th player in the smartphone market, and given Ubuntu's track record with desktop UI, I don't think their effort in mobile will be terribly inspired.