Connect a display and you have full ubuntu. With today's smartphones already computationally competitive with your standard netbook, that alone is a massive value proposition to me. Add something like motorola's lapdock and there is 95% of all my computing needs met, all with a single, central data storage.

Hopefully porting from linux will be fairly straightforward too.. just a new UI support?, giving apps that work from desktop to mobile. Not to mention that is has most of the FFOS advantage too.

I wouldn't trivialise the effort required to create a touch-friendly UI, especially from an existing desktop application (with the expectations that go with it).

In fact, its already done: and right now, MOAI - and similar tools, just like it (Love2D, Cocos2D, &etc.) - are already out there, running on the existing OS's, and providing multi-touch interfaces that definitely compete with existing Frameworks/SDK's. There is little that Cocoa does, for the 2D gamer/mobile developer, that MOAI cannot do, also. (Granted: native interfaces are a weakness, but then again: non-native, truly cross-platform UI's are a STRENGTH in the face of the existing market)

By making this move, Canonical has just invalidated all the proprietary bullshit the average Objective-C developer has to contend with, in order to develop an app for the mobile platform. Same with Android - both Objective-C and Android investments have just been bumped down a few tens of points, in my opinion. Why bother learning proprietary locked-in crap, when you can pick a framework that will run easily on all of the platforms, including the up and coming new Ubuntu-Mobile?

Where once we have over-specialization and a slavish devotion to technocratic dogma from an oppressive regime (Apple, and in lesser yet still significant ways, Android too), we now have a real ability to choose our tools and standardize on the ones with which we most feel comfortable.

Make no mistake, this is a genius move. Not only do we have Mobile becoming Desktop becoming the Cloud, finally, but we have it with Open Tools, that no other company has the balls to produce.

Starting from an existing touch framework/application is not the problem.

"Porting" a desktop application to a touch application is not "just" (to quote polshaw) adding a new UI. There's a world of difference between a desktop GUI--esp. in the Linux world, where many apps are remarkably different due to the ecosystem--and a touch GUI. Touch target sizing, what information to get rid of (if any?), what to add, speed (arguably more important on a mobile device), hardware acceleration (read: being gentle on battery life & improving touch responsiveness)... it goes on.

The OS might have Ubuntu/Linux roots, but it doesn't automatically mean it gets a free ride to a great touch-friendly mobile app library.

I know the typical user isn't going to care, but I could see how it would be a big win for developers, and as we all know, "developers developers developers."

I didn't see this mentioned in the keynote. I was specifically looking for it and there were zero mentions?

It doesn't sound all that wonderful.

Desktop/mobile crossover might be better served with cloud-sync.

Except if I'm in a developing nation where I'm not guaranteed connectivity. (Don't scoff yet, because I'd say the US is in this category.)

Maybe this is going to be the mobile toolkit you’re talking about?..

Technically, you can probably ship something based on pure AOSP, but your competitors will have had pre-AOSP access to the code for multiple months and there are no guarantees that AOSP even works without Google's magic proprietary mojo. CyanogenMod had to develop the missing pieces when Google sent their C&D over the proprietary bits. I would suspect defensive things designed to make it more difficult for Amazon to leech AOSP are either present or coming soon particularly with the rumors that Amazon is working toward introducing a phone.

What do you mean by this? If you mean in the market, it can work. Amazon's devices are proof. If a manufacturer is shipping just AOSP, it needs to have a working complement to Google's suite of apps or it needs to have a different value proposition altogether.

> CyanogenMod had to develop the missing pieces when Google sent their C&D over the proprietary bits

What "missing bits"? They were shipping Google's suite of proprietary apps on top of their AOSP-based ROM and they stopped after the C&D.

Amazon has forked Android, but by doing so they aren't allowed to use any of Google's apps in their devices.

What it boils down to is that Google has a final approval over any Google-logo Android device. For phone OEMs, this looks like absolute and arbitrary control by Google, but, in reality, it's a three-way negotiation between the OEM, Google, and, in the US, the carrier controlling the channel for the product, with any one of them able to sink a product before it reaches the market.

Google has never seen fit to make licensing terms for Google's ecosystem apps (Maps, Play, etc.) transparent. That's a pretty sharp contrast with Android as an open source project, and even with the way Windows Mobile (not Windows Phone) was licensed.

So Android is open, on the one (AOSP) hand, and un-transparently proprietary on the other hand. That leaves an obvious market opening for a truly open OS. But, so far, Tizen, Open WebOS, or any other possible contenders have been insufficient and/or under-developed. Maybe Canonical will get it right.

Where did you see that? Are you sure you're not confusing it with the "Ubuntu for Android" project? That is a different project from this.

I don't think an Ubuntu phone will have anything to do with Android. It's its own OS, and you won't see it on all phones or anything like that - just on the "Ubuntu phones" that will be shipping starting with 2014. They might port it to some existing hardware like Galaxy Nexus for demo purposes, though, the way Mozilla did with Firefox OS on Galaxy S2.

> Ubuntu has already been adapted to run on chipsets using the ARM and Intel x86 architectures relevant for mobile devices, with the core system based around a typical Android Board Support Package (BSP). So chipset vendors and hardware manufacturers do not need to invest in or maintain new hardware support packages for Ubuntu on smartphones. In short, if you already make handsets that run Android, the work needed to adopt Ubuntu will be trivial.

Also I think since kernel 3.3 Android uses the exact same kernel as other Linux distros. The Android kernel got merged with the normal Linux kernel. So I don't see why it would be a problem for them to use the same kernel.

There has been a lot of great ARM work lately in mainline too but there are still quite a few drivers missing that you can't even get docs for (even with signing NDAs) so the drivers for mainline get written based on the BSP-ish kernel drivers which aren't always written the best.

It was mentioned in the keynote video, towards the very end ~21:00.

"As already teased and promised, today Canonical is taking the wraps off the mobile version of Ubuntu, which is built around the existing Android kernel and drivers, but doesn't use a Java Virtual Machine and promises to use "the full power of the phone.""

http://www.theverge.com/2013/1/2/3827922/ubuntu-phone-os-ann...

I got confused with all the simultaneous news articles so sorry about the "it says" part.