Once a week we'll be updating this thread with the latest FAQs.
Ubuntu Touch has seen lots of interest in the few weeks since the developer preview was announced, and many new folks are already contributing on a regular basis. As the project is quite new and moving at a quick pace, there surely are a lot of questions. The Touch team will take their time to answer whichever questions you might have, so let's hear them!
Submit Your Question!
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Submit more questions here: https://docs.google.com/forms/d/1B2GzH5Zh8EVEXboe_5E2HuJgSmDpBqPXH59LM50376c/viewform
---------------------------------------------------------------------------------------
The following Ubuntu Touch managers, engineers and contributors have helped answering these questions.
- pat: Pat McGowan
- dholbach: Daniel Holbach
- sergiusens: Sergio Schvezov
- mhall119: Michael Hall
- lool: Loïc Minier
- rsalveti: Ricardo Salveti
- mzanetti: Michael Zanetti
- dpm: David Planella
- john.pugh: John Pugh
- tespy: Tony Espy
There are more answers to come.
--------------------------------------------------------------------------------------
Is there any plan to make a final version of ubuntu touch for nexus series?
The 13.10 release will be the first official release for the four targeted Nexus devices. (pat)
Are there plan to merge works from Meego/Harmattan community? since both are deb based?
Any works from Meego or Mer that can be leveraged would be welcome, we constantly look for existing solutions.For example the File Manager app is using a QML plugin from Mer/Nemo, which is descended from Meego. (pat)
When will a 1-click install be available?
Early versions of this will be available in the 13.10 timeframe in the SDK, but will not initially include full support in the software center. (pat)
When will this be a wide release for more than nexus phones?
The release will be tested on the 4 nexus devices. Other devices require community devs to support them. (pat)
(edited) There were many many questions of the form “Will <my device> be supported too?”
You can see a list of devices where ports are in the works at https://wiki.ubuntu.com/Touch/Devices - click on any of the links to find out more about the state of the images in question.
If you should want to get involved in porting, this guide (https://wiki.ubuntu.com/Touch/Porting) might be of interest. (dholbach)
(edited) Many asked if running Android apps on Ubuntu Touch will be supported too.
We are currently evaluating the effort and approaches to enable Android developers to move their apps to Ubuntu easily. The goal would not be to run Android apps unchanged, but to allow developers to adapt them for the Ubuntu Touch User Experience and to minimize the overall porting effort. (pat)
How it will be possible to access mobile devices features like gps, sensors, camera in user apps? Any API for eg. QML or native code?
This is already available from the Qt level and work is underway to expose through QML. (pat)
Will the final product allow me to us "sudo" and "apt-get" just like a desktop computer?
It would in developer mode, at least for images installed out of the final public builds. (sergiusens)
Hi guys! I think you people are doing a great job and many thanks for that! However, I do have one question that I hope you could answer. Is there going to be an app store for Ubuntu Touch where apps can be downloaded or purchased?
Yes. There are several teams working on it and a first iteration will be available in October. (dholbach)
With the glut in games coming to Ubuntu via HIB and Steam portals, is there any ways or plans to support the recompiling of games to Arm so that one could run a game on their computer, pick it up on their tablet, and finish on the phone?
It would be up to the game developer to make this possible, however Ubuntu provides them a single ARM target that support multiple devices, supports OpenGL, and provides a cloud syncing service (U1/U1DB) that would make this all possible. (mhall119)
Does Ubuntu Touch use BlueZ or Bluedroid as the bluetooth stack If it uses Bluedroid, does it support BlueZ?
Bluez. (lool)
1. Will ubuntu touch support existing android applications?
2. Will it be possible for every device to run ubuntu touch like the desktop os supporting most configurations?
3. Will my device supported for future versions of the OS or a device per OS policy?
1- Ubuntu Touch is a very different product than Android, there are common things in the plumbing but that is about it.
2- The desktop world and the device world are very different, so in practice no.
3- For minor updates I would say yes, for major updates it would probably work like in the industry (I'm not a subject matter expert to answer this one). That said, the community can take core of making sure it is. (sergiusens)
What kind of app support will you likely have on the platform upon launch? Obviously you don't want to have a paltry amount like Windows Phone, but have you been able to persuade many developers into making apps for Ubuntu Touch as well as iOS, Android, Blackberry OS, and Windows Phone?
Our app developer outreach has gathered a lot of interested from open source developers, who are happy to start writing apps for our SDK before it's even reached a beta release. We have seen a large number of these apps being written for a wide variety of uses, and they have been helping us shape the SDK itself in return. Once the SDK reaches a stable release, we are confident it will provide an attractive platform for commercial and indie developers, and we expect to see a large number of existing apps ported. (mhall119)
I would like to know if the applications would be different from android ones. I mean we will need that popular developers to make their apps to ubuntu system?
Please see http://developer.ubuntu.com for the latest SDK and information. (pat)
if I have quick bug reports and suggestions and radical ideas, where would I send them or who would I talk to? With me being not a developer.
- Irc channel :#ubuntu-touch on freenode.
- The [email protected] mailing list, and
- submit bugs on launchpad at https://launchpad.net/ubuntu-touch-preview
1. Can the Existing native linux apps run on Ubuntu touch when compiled for use on Ubuntu Touch devices?
2. Can existing android apps be installed/used over Ubuntu Touch?
Existing native apps using a supported toolkit (Qt for now) will run, but unless they are designed to work well in a touch interface they may not be very useful on devices. Part of the Ubuntu SDK's focus is on making apps that can transition between desktop and touch interfaces in a way that makes them useable in both. (mhall119)
Why aren't their tabs in the browser?
i definetly rely on tabs.
Tabbed browsing support will be added in June. (pat)
Once Ubuntu Touch does roll out, will it coincide with the regular Ubuntu release cycle? For example, Ubuntu 13.10 will not only release for desktops, but will coincide in releasing for mobiles and tablets as well.
Thats correct, 13.10 will include the first release of Ubuntu Touch for phones and tablets, specifically working on the 4 reference nexus designs.
When will be ready so I could flash it on my Nexus 4?
https://wiki.ubuntu.com/Touch/ReleaseNotes should give you a good idea of where things with the preview stand right now. Check out https://bugs.launchpad.net/touch-preview-images/+bugs for even more detail.
Will Ubuntu desktop and Ubuntu Touch merge as one in the upcoming 13.10 release?
This is the goal for 14.04, there should be a preview available of Ubuntu Touch on desktops in 13.10. (mhall119)
By far the thing that excites me the most about Ubuntu Touch is the prospect of Desktop mode, could you explain it in a bit more detail?
The desktop shell (Unity 7) will be re-implemented in the same codebase as Ubuntu Touch (Unity 8), so that there will be one "Unity" that can change the way it looks and behaves depending on the kind of device it is running on. For app developers, the platform will be the same, the APIs will be the same, they won't need to maintain separate versions of their app. (mhall119)
When it will be available? Can Ubuntu sync Gmail contacts?
There is already a manual way to sync Google contacts, it just needs a GUI built around it. http://sergiusens.github.io/posts/google-contacts-on-ubuntu-touch.html (mhall119)
Is there a list of supported devices?
Please refer to https://wiki.ubuntu.com/Touch/Devices. (sergiusens)
Can we develop and run our own native apps? Will a GUI framework be provided that will make our apps look the same as the Ubuntu Touch UI?
Yes, native apps can be written in C++/Qt, or QML/Javascript. We provide a UI Toolkit with native widgets that you can use in your apps. (mhall119)
What does Ubuntu for phone and tablets have that neither Apple and Android havent got?
One platform for phone, tablet, desktop/laptop, TV and server. You only need to write and maintain one version of your app, and it will work on every Ubuntu device. (mhall119)
Why Java is not part of Ubuntu Touch? Will Java developers can get a chance to innovate for Ubuntu Touch?
If the question is regarding dalvik, it's because Ubuntu Touch is not really based out of Android but uses some of its bits. If it's regarding java, openjdk is available in the repositories although for GUI there is still no support, once Mir lands, that could change. (sergiusens)
What will you guys be doing in regards to privacy in order to avoid controversy like in 12.10?
The new Smart Scopes that have arrivedin 13.10 provide fine-grained control over which scopes are active, giving the user the ability to decide what sources are used by the Dash. We are also improving the way we let the user know that their searches may be using external sources to find results. (mhall119)
The last time I tried Ubuntu Touch, I could not make and install my own apps. Has Ubuntu Touch become developable?
Yes, you can visit http://developer.ubuntu.com to get the Ubuntu SDK and learn how to write your own Ubuntu Touch apps. (mhall119)
Would it be possible to have Ubuntu Touch use cloud storage to store apps, repos etc so that we can automatically sync our data across mobile and PCs?
You will have both Ubuntu One Files and Ubuntu One Database to sync your app's data between a user's devices. (mhal119)
Can we have an Android Runtime (like BB10 has) in a near future?
We are currently evaluating the effort and approaches to enable Android developers to move their apps to Ubuntu easily. The goal would not be to run Android apps unchanged, but to allow developers to adapt them for the Ubuntu Touch User Experience and to minimize the overall porting effort. (pat)
About the project Ubuntu for Android, Ubuntu Touch will provide in the future a desktop interface if plugged via hdmi, like Ubuntu for Android?
Yes, if your phone is capable you will be able to run Ubuntu Touch on it's touch screen, but then dock it to an external screen, and be presented with the Desktop shell. (mhall119)
What program is used for viewing, editing and creating Office documents (Word, Excel, PowerPoint)? Is it possible to run Android apps on it? Can I use it as a daily software for my Nexus 7?
There is a Document Viewer being developed that can currently display plain text and image files. We are evaluating the available libraries for displaying office documents, and plan to incorporate that functionality into this app. (mhall119)
Will we be able to access the ubuntu APT repositories on ubuntu touch and be able to install any packages that have been ported to the arm architecture OUT-OF-THE-BOX?
Yes, although we are exploring an alternate package format and delivery architecture for apps. (mhall119)
What's the point of throwing an Undeveloped OS (blueprints?) to the public so that they finish its development then charge everyone hundreds of dollars for an official device running the same OS?
Our engineers have not slowed down their development since we made everything open. Quite the contrary, development efforts within Canonical have only intensified. What we have done is given the opportunity to those who want to be involved in it a chance to do so. Not just in implementing blueprints that already existed, but to be a part of the process of drafting those blueprints as well. We currently have regular meetings between Canonical engineers and designers with community engineers and designers, who are working together to define everything from the platform's foundation and APIs all the way up to the final look of apps. (mhall119)
Can you install the same packages from the Ubuntu Repository for your PC on your Ubuntu Touch Device (as long as they are available for ARM of course)? Can these Desktop apps be used on the touch device itself, or only through the Unity Desktop via some sort of dock with a mouse/keyboard?
If the application uses a supported toolkit (just Qt at the moment) that allows it to run on SurfaceFlinger and Mir, it will be able to run on Ubuntu Touch. Our goal is to provide a single platform for app developers, which will allow a single codebase to run on all Ubuntu devices. (mhall119)
What kind of apps is it gonna "Support"? like all the Android Market apps? Or a completely new Market? Thanks in advance, really looking forward to Ubuntu Touch.
A new market based on the existing Ubuntu repositories and applications. (mhall119)
Will I be able to run games like Nexiuz and OpenArena on my Nexus 10 tablet?
Generally it's possible to support any game that works with OpenGL ES 2.0, but some porting work might be needed to enable support for Mir (instead of depending on X11 libs, for example). (rsalveti)
Are you planning to make sure the visual experience of Ubuntu Touch has no perceivable lag for the end user? How do you expect to accomplish this with HTML5 technology?
Yes, we plan to make the Ubuntu Touch experience as smooth as possible. Knowing the limitations of HTML5 (which we intend to fully support nevertheless), we are using/providing Qt/QML to write native apps that can get the most out of the phone's hardware. (mzanetti)
I would like to know if the applications would be different from android ones. I mean we will need that popular developers to make their apps to ubuntu system?
Please see developer.ubuntu.com for the latest SDK and information. (pat)
So what is the minimum hardware requirement(processor, kernel version,LDPI support) the OS will need?
The requirements for the entry level Ubuntu smartphone: 1Ghz dual core Cortex A9 processor, 1GB RAM preferred, OpenGL/ES supported graphics, 4GB to 8GB storage. (pat)
I'd like to know if it would be do-able to make an Ubuntu Touch fork which includes the Dalvik VM and support for running APKs.
If it's not, can you please elaborate a little bit on the technical reasons behind this limitation. If it is possible, I'd like to know how hard it might be. Would the Ubuntu part require much modification to run on top of a "vanilla" CyanogenMod?
Aside from that, I wanted to ask what are your plans in term of kernel version support for Ubuntu Touch. Are you planning on contributing to port newer versions of the Linux kernel to Android or will Touch follow the mainstream Android kernel releases?
Thanks a lot for your time, and for your work on this promising OS, really looking forward to be more involved in this new mobile ecosystem.
See the response regarding support of Anroid apps. We plan to track the Android kernels in the near term. This could change over time and will be driven by the needs of manufacturers.
On your site when it talks of support from valve and unity game engine does it mean for mobile or in terms of the desktop OS?
Currently both Valve and Unity Technologies support Ubuntu Desktop. (john.pugh)
can ubuntu touch be ported to armv6 tablet device with 1gigs of ram and 4 gb rom because at official site it is mentioned for armv7 devices??
ARMv6 is not supported anymore by Ubuntu since Karmic. Ubuntu currently targets the ARMv7 and above Application Processor family (Cortex A8, A9 and above). (rsalveti)
When will ubuntu touch be stable on the nexus 4?
It should be stable by the time 13.10 is released. (sergiusens)
will we see the ubuntu for android feature in the final realese for ubuntu touch?
These two projects are not related, while Ubuntu for Android runs on top of Android; Ubuntu Touch is its own operating system in itself reusing some components from Android to the point it's not even Android anymore. (sergiusens)
Will I be able to run any native ubuntu desktop application on a x86 (Intel Atom) Smartphone/Tablet running Ubuntu Touch?
We have not yet produced an x86 build of Ubuntu Touch but this is certainly possible. Ubuntu Touch will not provide support for X in its first release, but compatiility will be provided later to support the converged device use case. (pat)
sooooo...ubuntu touch for armv6?
ARMv6 is not supported anymore by Ubuntu since Karmic. Ubuntu currently targets the ARMv7 and above Application Processor family (Cortex A8, A9 and above). (rsalveti)
Can we port .apk's to touch? And what file extension ubuntu touch will use on it's apps if not apk? Also to get ubuntu work example on Gt-i9300 do we need source from samsung?
See the response regarding porting android apps. We will not use the apk extension, there will be a new extension for the new click packages which are based on debian package format. (pat)
hello ubuntu, when will the galaxy s3 i747 get ubuntu touch?
For the list of supported devices (also for WIP), please check https://wiki.ubuntu.com/Touch/Devices. (rsalveti)
Hello! Would it be possible to use desktop applications (e.g LibreOffice, Firefox, Audacity, Transmission), while utilizing the phone interface? Would it be possible to use terminal applications, just as in Ubuntu (e.g mc – midnight commander)? Is Ubuntu going to be based on Android (meaning that Ubuntu is just a chroot running atop of Android) or is Ubuntu going to be stand-alone? (i.e not using the Android kernel, not running atop of Android, utilizing Upstart, using Ubuntu kernel etc.) Would it be possible to turn on root access (preferably – with a tick in the settings) easily? Ubuntu Phone does differ from Android – Android doesn't let you make your phone a fully-fledged PC – Ubuntu does. I guess lots of people are looking forward to seeing PC-like functionality (i.e desktop apps, terminal apps, etc.) in Ubuntu Phone. So am I. Really looking forward to Ubuntu taking off! I hope these questions (and answers) will be in the FAQ. Thank for your time!
In the future it will be possible to use desktop apps and phone interface, this is the converged device support we are moving toward. There is a terminal app available now. There is work nearly completed to "flip" the current design. Ubuntu TOuch will boot into Ubuntu using upstart and Android components will reside in an LXC container. Not sure how easy it will be to turn on root but developers will have this. (pat)
why on devices like Xperia 2011 daily builds are not booting but MWC image is booting
hybris is the component that bridges the two components, the Android container and Ubuntu. It lives on both sides and needs to be in sync. While this may not be the case for all the devices, it is most likely that the Android side hasn't been updated with these changes; nor the platform-api which is also dual lived. (sergiusens)
Will it be available on devices which have bad sources like Exynos-based Samsung Devices?
The Nexus 10 (manta) is Exynos based and officially supported. (sergiusens)
Can we install it as a daily driver OS in any phone? For example, i have a Galaxy Note and its was ported, but its buggy, i cant make calls, the fonts looks ugly and the UI its overscaled
You should be able to install Ubuntu on any device to use daily as long as the port is marked as complete. As can be seen on the wiki for the Note II (https://wiki.ubuntu.com/Touch/Devices/n7100), the port is certainly not complete. (sergiusens)
Why CyanogenMod as base for Ubuntu Touch?
The choice on CyanogenMod was made based on how easy it was to use as a base when starting to work on a new device. (sergiusens)
When is the estimated release for a stable version of Ubuntu Touch with all the features working going to come out?
A functionally complete version will be available with 13.10. (pat)
Will you try to make a release for every phone or an driver package approach?
We will focus on a set of reference designs. (pat)
How will you incorporate software updates on the ubuntu platform? Currently Android goes through a seemingly tedious process( Source ---> OEM ---> Carrier---> Phone) where as IOS is significantly different ( Source ---> Phone). Will Ubuntu touch be closer to Androids method or Apples?
We hope to have an Ubuntu ecosystem that is not as fragmented as Android in terms of which updates are applied where and when. The model should be closer to Apple's, but this is not entirely within our control. (pat)
Will other GUI be avalaible (Gnome, KDE)?
None are planned, but the UI is customizable to some extent. (pat)
Ubuntu Touch will officially support Ubuntu Software Centre packages? Or a own software centre will be provided in the future?
Apps for Ubuntu Touch will be available from the software center. (pat)
When will CDMA/EvDO/LTE support be added for users in the US, China, India, Southeast Asia, and South America?
We do not have plans for CDMA support at this time, but would welcome this addition. THe Ofono stack does not currently provide for this. (tespy)
Will there be continued support for the Nexus lineup for the current crop and the future versions?
Yes. Future versions are tbd. (pat)
I would like to ask about the requirements for Ubuntu touch, it says on the Ubuntu QA section that the minimum is a 1ghz single core processor, I know it runs slow on all devices at the moment because it is still under development, however I also read in the ubuntu page that ubuntu touch will run faster than Android due to it taking advantage of everything possible. Android 4.2 jelly bean seems to run pretty slow and laggy, will Ubuntu touch (Which is build on top of an Android 4.2 kernel) run faster on such devices?
The current performance seems quite acceptable. The Qt stack we are using for the shell and apps is quite well optimized for these devices. We are continuing to enhance the app management, ui toolkit and core system stacks to improve performance. (pat)
How to develop a cell phone for my Ubuntu Touch?
Please take a look at https://wiki.ubuntu.com/Touch/Porting, where we post instructions for people to add support for additional devices. (rsalveti)
Will you give any support to PySide project (Python bindings for Qt)? The project was started by Nokia but currently it is not developping further and only Qt 4.x is supported. Python makes developing applications much easier compared to C++ while still allowing to use C/C++ libraries for performance critical parts. I have some applications ready that I would like to port to Ubuntu Touch but rewriting them from Python to C++ would take me too much time.
There is actually an upgrade of PyQt to work with Qt5. The beta has been around since March, and the final Qt5 release was reelased just now:http://www.riverbankcomputing.co.uk/news/pyqt-50. While we don't officially support that at the time being, it should be relatively easy to make it run on Ubuntu Touch. (mzanetti)
Ubuntu touch ported to Samsung Galaxy Tab 7.0 almost perfect. Wiki says the last missing feature is being worked by Ubuntu devs, after last piece completed will we see daily updates along with Nexus devices?
We hope to incorporate more community-driven ports as we go, which then will be published daily together with our Nexus based images (but you might still need to copy the proprietary binaries for a fully working image). (rsalveti)
I've seen that the files on http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/ are with a "flipped container", which gives us the ability to run Ubuntu Touch directly and run Android after that. Unflipped ones obviously need run Android because they run Ubuntu using chroot. Where we can boot directly into Ubuntu, is there any specific reason for us to run Android?
Even with the flipped container model we still need to run Android specific services, such as RILD and SensorService. Work is in progress to reduce the amount of Android dependencies. (rsalveti)
This is my first post to XDA.
I have been asking this question about various OS's in various forums, for past 18 months, and each time I ask it, the person who answers it spends a few iterations with me bending-over-backwards trying to avoid telling me what I want to know. I hope that this does not happen here.
I have a native C++ application. It currently runs on Linux desktop. It does many things that native C++ applications do, including sending raw Ethernet frames (mesh networking).
Obviously, if one of my customers tries to install this application on his/her Android device, there will be problems, and it won't work.
I am aware that a human being has the ability to root his/her phone.
I am aware that a human being has the ability to root his/her phone.
I am aware that a human being has the ability to root his/her phone.
Please do not send me a reply saying, "But your customer has the ability to root his/her phone!" :cyclops:
What I would like, is a smartphone, that is running Linux, that allows my customer to install a 100% Native C++ application, >>>WITHOUT<<< having to go through the process of rooting his/her phone. Ideally, the barrier-to-installation would be roughly equivalent to what s/he would experience on a desktop computer.
I am not concerned about the presence of X or any particular GUI subsystem, but I will definitely need access to all the normal system-level Linux primitives (multi-threading, asynchronous I/O, etc.)
Please do not send me a reply saying, You can ssh into the phone and install the app that way."
I would like to know if Ubuntu on smartphone allows a relatively naive user to install a 100% native C++ application that interfaces with the system-level primitives of Linux.
And finally, please note that I am not interested in finding a work-around to an engineering problem that I am having. I am trying to determine the maximum permissible degree of nativity of Ubuntu Touch applications when the application is to be installed by a naive user.
If Ubuntu touch does allow such native applications to be installed, I would be interested in getting an idea of the steps that a customer would take.
UT apps can be uploaded as a click app to the UbuntuOne store and then can be installed as easy as any Android app. You should be able to "sideload" click apps, but I never tried.
UT apps - that are not a web app - are written in native C++ using QT5/QML for UI.
UT apps are restricted by apparmour profiles, but that should not keep them from using multithreading or asynchronous I/O. You would have to test, if your specific requirements work.
There is only one way to answer all your questions: give it a try!
Sent from my TF300T using Tapatalk
f69m said:
UT apps can be uploaded as a click app to the UbuntuOne store and then can be installed as easy as any Android app. You should be able to "sideload" click apps, but I never tried.
UT apps - that are not a web app - are written in native C++ using QT5/QML for UI.
UT apps are restricted by apparmour profiles, but that should not keep them from using multithreading or asynchronous I/O. You would have to test, if your specific requirements work.
There is only one way to answer all your questions: give it a try!
Sent from my TF300T using Tapatalk
Click to expand...
Click to collapse
:good:
Yes, you would need to change the packaging system from debian archives to click packages but that shouldn't be too difficult. If you run into problems with the Ubuntu SDK in connection with C++, have a look at this bug report and the mentioned fixes: https://bugs.launchpad.net/ubuntu/+source/qtcreator/+bug/1215913
f69m said:
UT apps can be uploaded as a click app to the UbuntuOne store and then can be installed as easy as any Android app. You should be able to "sideload" click apps, but I never tried.
Click to expand...
Click to collapse
Any idea at all what the user would see when trying to sideload a click app. [I am trying to set my expectations before diving in.] Would the user download package to a directory, then click on it, or?
UT apps are restricted by apparmour profiles, but that should not keep them from using multithreading or asynchronous I/O. You would have to test, if your specific requirements work.
There is only one way to answer all your questions: give it a try!
Click to expand...
Click to collapse
OK, apparmour seems to be the focal point. I would be really interested (if any knows), how restrictive apparmour will be with a newly-purchased UT phone, and what control a naive user of that phone will have in allowing native C++ applications to run. I would check this myself, but I cannot do any significant coding (porting) until mid-March.
In particular, my app works with WiFi, and will need to interact with stock WiFi drivers (mac80211/etc.). I would like to know what I, and the user, can expect when s/he:
acquires my app from my web site
does something to install it (what would s/he do at this step?)
attempts to execute it (will apparmour block access to mac80211-like drivers)
RareHare said:
Any idea at all what the user would see when trying to sideload a click app. [I am trying to set my expectations before diving in.] Would the user download package to a directory, then click on it, or?
OK, apparmour seems to be the focal point. I would be really interested (if any knows), how restrictive apparmour will be with a newly-purchased UT phone, and what control a naive user of that phone will have in allowing native C++ applications to run. I would check this myself, but I cannot do any significant coding (porting) until mid-March.
In particular, my app works with WiFi, and will need to interact with stock WiFi drivers (mac80211/etc.). I would like to know what I, and the user, can expect when s/he:
acquires my app from my web site
does something to install it (what would s/he do at this step?)
attempts to execute it (will apparmour block access to mac80211-like drivers)
Click to expand...
Click to collapse
Applications should be installed from the Ubuntu app store. If you've just got the click package, you currently need to use the command line to install it:
Code:
sudo install <path to package>
sudo register --user=phablet <package name> <package version>
I hope that this will change though. (It's name is "click" package. )
RareHare said:
Any idea at all what the user would see when trying to sideload a click app. [I am trying to set my expectations before diving in.] Would the user download package to a directory, then click on it, or?
Click to expand...
Click to collapse
nikwen said:
Applications should be installed from the Ubuntu app store. If you've just got the click package, you currently need to use the command line to install it:
Click to expand...
Click to collapse
Technically it should be possible to install a click package just by clicking on a web link, if the web site serves a specific mime type, but this is not implemented.
Not sure about Canonical's policy on that, they might not like the idea. Otherwise they might implement it or at least accept a patch from a community developer.
RareHare said:
OK, apparmour seems to be the focal point. I would be really interested (if any knows), how restrictive apparmour will be with a newly-purchased UT phone, and what control a naive user of that phone will have in allowing native C++ applications to run. I would check this myself, but I cannot do any significant coding (porting) until mid-March.
Click to expand...
Click to collapse
Sorry, have not looked myself into the apparmour profiles too closely and don't have the time to do that right now.
However you can download a recent UT rootfs using the link below and have a look at the profiles yourself:
https://system-image.ubuntu.com/pool/ubuntu-cd4246419c888397c0d8debbd9f945219f40fc670220b7ac86753dc79eb73707.tar.xz
RareHare said:
In particular, my app works with WiFi, and will need to interact with stock WiFi drivers (mac80211/etc.).
Click to expand...
Click to collapse
I don't think this is possible with any current or future off-the-shelf phone. Any OS will provide an abstract API for WLAN and require root to talk to the drivers directly.
As you say requiring your customers to root the phone is not an option, this seems to leave only one way out: you need to split off the low-level code of your app into a generic and secure API and submit it to Ubuntu Touch. If it is accepted, your app can use the new API.
f69m said:
Technically it should be possible to install a click package just by clicking on a web link, if the web site serves a specific mime type, but this is not implemented.
Not sure about Canonical's policy on that, they might not like the idea. Otherwise they might implement it or at least accept a patch from a community developer.
Click to expand...
Click to collapse
Of course, it would technically be possible. Recently, I read a Google Plus post on that topic. Here's the link. (The interesting part is in the comments. Read all of them. )
They said that they'll offer those options in the future.
f69m said:
Technically it should be possible to install a click package just by clicking on a web link, if the web site serves a specific mime type, but this is not implemented.
Not sure about Canonical's policy on that, they might not like the idea. Otherwise they might implement it or at least accept a patch from a community developer.[
Sorry, have not looked myself into the apparmour profiles too closely and don't have the time to do that right now.
Click to expand...
Click to collapse
I am in the same situation myself - I do not have enough time to experiment with apparmour, so I'm asking Ubuntu so that I do not have to search/guess.:victory:
I don't think this is possible with any current or future off-the-shelf phone.
Click to expand...
Click to collapse
So it would seem.
Any OS will provide an abstract API for WLAN and require root to talk to the drivers directly.
As you say requiring your customers to root the phone is not an option, this seems to leave only one way out: you need to split off the low-level code of your app into a generic and secure API and submit it to Ubuntu Touch. If it is accepted, your app can use the new API.
Click to expand...
Click to collapse
Well, the low-level code, in my case, is the WiFi drivers. Also, I cannot imagine submitting a new API to Ubuntu Touch every-time a new model for accessing system-level primitives arrive. That would essentially loop Canonical into all of our engineering processes.
Your last comment actually is the crux of the issue. It points to a policy question, not a technical one, and one for which the answer is yes or no. I would imagine that, at this point, Canonical already knows the answer...
Principle:
There are numerous situations where it is good for a native application to not be sand-boxed, but have the same access to the Linux subsystems as a user would have on Ubuntu Desktop. There are situations where the owner of the phone would be sophisticated and comfortable enough that s/he can decide for himself/herself whether an application should be allowed root access to the phone. A fellow engineer called this the "welded-hood" principle:
Do people prefer buying cars that have the hoods welded-shut?
Many people might, but there are a significant number who would prefer not. As it turns out, an automobile can dangerous if the person opens the hood and starts working on things that s/he should not be touching (no pun intended). In the case of the fuel and braking system, it can even be lethal. But in the end, it was decided that, since we are all liberated adults, it is better to allow the customer freedom-of-choice.
What we have, right now, is a situation where the "hoods" on all mobile devices are essentially welded shut. I think that is unfortunate, because there is a huge latent demand for mobile devices that "still have their hoods", but if the user chooses to open the hood, with they key word here being easily, that would be his/her prerogative.
By the default, the system should be sand-boxed, but the user should have a facility that allows him/her access to install some native, system-level applications, easily, just as a user is allowed to tap-off her break fluid or bleed the fuel-line if she so desires, even though there are many warnings about what could happen if the application is installed. The "open-the-hood" operation would come with warnings that the user can choose to ignore, with resulting consequences.
Question:
Will Ubuntu Touch allow the owner of an Ubuntu Touch phone to side-load a native C++ application that interfaces with the various existing WiFi drivers in Linux, if the user decides for himself/herself, that it is OK for the application to interface with such drivers?
I have a feeling that the answer is no, but I am asking here to make sure.
RareHare said:
I am in the same situation myself - I do not have enough time to experiment with apparmour, so I'm asking Ubuntu so that I do not have to search/guess.:victory:
So it would seem.
Well, the low-level code, in my case, is the WiFi drivers. Also, I cannot imagine submitting a new API to Ubuntu Touch every-time a new model for accessing system-level primitives arrive. That would essentially loop Canonical into all of our engineering processes.
Your last comment actually is the crux of the issue. It points to a policy question, not a technical one, and one for which the answer is yes or no. I would imagine that, at this point, Canonical already knows the answer...
Principle:
There are numerous situations where it is good for a native application to not be sand-boxed, but have the same access to the Linux subsystems as a user would have on Ubuntu Desktop. There are situations where the owner of the phone would be sophisticated and comfortable enough that s/he can decide for himself/herself whether an application should be allowed root access to the phone. A fellow engineer called this the "welded-hood" principle:
Do people prefer buying cars that have the hoods welded-shut?
Many people might, but there are a significant number who would prefer not. As it turns out, an automobile can dangerous if the person opens the hood and starts working on things that s/he should not be touching (no pun intended). In the case of the fuel and braking system, it can even be lethal. But in the end, it was decided that, since we are all liberated adults, it is better to allow the customer freedom-of-choice.
What we have, right now, is a situation where the "hoods" on all mobile devices are essentially welded shut. I think that is unfortunate, because there is a huge latent demand for mobile devices that "still have their hoods", but if the user chooses to open the hood, with they key word here being easily, that would be his/her prerogative.
By the default, the system should be sand-boxed, but the user should have a facility that allows him/her access to install some native, system-level applications, easily, just as a user is allowed to tap-off her break fluid or bleed the fuel-line if she so desires, even though there are many warnings about what could happen if the application is installed. The "open-the-hood" operation would come with warnings that the user can choose to ignore, with resulting consequences.
Question:
Will Ubuntu Touch allow the owner of an Ubuntu Touch phone to side-load a native C++ application that interfaces with the various existing WiFi drivers in Linux, if the user decides for himself/herself, that it is OK for the application to interface with such drivers?
I have a feeling that the answer is no, but I am asking here to make sure.
Click to expand...
Click to collapse
Well, your comparison is not quite correct. On most phones, there is a way for an educated user to open the hood. This is usually referred to as rooting the phone. Some companies will give you a tool to unlock the bootloader and thus open the hood easily, for others it is a little harder. But any user has the freedom of choice to open the hood or leave it closed.
Now, what you are asking for is something completely different. You are asking for a closed-source "black box" app to get access to what is under the hood, without the user ever opening it. This would mean opening the door for all kinds of malware, and I sure hope this will not be allowed by Ubuntu Touch . Let an educated user open the hood and place the black box there, if he feels comfortable about it, but don't make it too easy. A user that is not willing or not able to open the hood himself should also not be required to understand the consequences of installing a black box app with root privileges.
And there is another thing to consider: Ubuntu is heading for convergence, meaning the same app runs fine on a phone, on a tablet and on a desktop. This means apps must be written against an abstract SDK and not have access to the actual hardware.
Well, I am afraid we have hit a dead end now, unless you are willing to disclose more details on the functionality of your app.
Sent from my TF300T using Tapatalk
83594455 676
And there is another thing to consider: Ubuntu is heading for convergence, meaning the same app runs fine on a phone, on a tablet and on a
desktop. This means apps must be written against an abstract SDK and not have access to the actual hardware.
Click to expand...
Click to collapse
I think my native, system-level app would not only run on all versions of Ubuntu, regardless of device, but most versions of Linux, on 100's of different hardware devices, without changes to my code. So actually, I would be accessing a standard Linux software interface.
Well, I am afraid we have hit a dead end now, unless you are willing to disclose more details on the functionality of your app.
Click to expand...
Click to collapse
Sure. I would like to send and receive raw 802.11 frames from user-space utilizing the various standard Linux 802.11 system-level API's for mesh networking. My application is entirely user-space, and would run on any stock Linux kernel. My field of work is wireless communication, so naturally, if someone were to offer me a mesh-networking packaging as an alternative, I could not use it - my goal is not to have a mesh network for mesh networking sake, but to create a mesh network using my own user-space algorithms. In other words, I really do need access to the 802.11 drivers.
You can run every system command from your app using C++: http://askubuntu.com/questions/288494/run-system-commands-from-qml-app
The sudo password is "phablet". You could also ask the user for it if it was changed. You can pass it like this:
Code:
echo phablet | sudo -S <my command>
That might help you.
You could also ask in the IRC channel for Ubuntu app development (search the internet and you'll find it). Some Canonical people as well as some awesome community members will surely answer your questions. (But tell us the result, please.)
nikwen said:
You can run every system command from your app using C++: http://askubuntu.com/questions/288494/run-system-commands-from-qml-app
The sudo password is "phablet". You could also ask the user for it if it was changed. You can pass it like this:
Code:
echo phablet | sudo -S <my command>
That might help you.
Click to expand...
Click to collapse
That works for the development images and community ports, but I am afraid if you buy a pre-configured UT phone (once they are available), sudo will not work. At least I would be surprised if a company would give full warranty for a device with working sudo.
Sent from my TF300T using Tapatalk
---------- Post added at 11:14 PM ---------- Previous post was at 11:02 PM ----------
RareHare said:
I think my native, system-level app would not only run on all versions of Ubuntu, regardless of device, but most versions of Linux, on 100's of different hardware devices, without changes to my code. So actually, I would be accessing a standard Linux software interface.
Sure. I would like to send and receive raw 802.11 frames from user-space utilizing the various standard Linux 802.11 system-level API's for mesh networking. My application is entirely user-space, and would run on any stock Linux kernel. My field of work is wireless communication, so naturally, if someone were to offer me a mesh-networking packaging as an alternative, I could not use it - my goal is not to have a mesh network for mesh networking sake, but to create a mesh network using my own user-space algorithms. In other words, I really do need access to the 802.11 drivers.
Click to expand...
Click to collapse
Hmm, never really used the user-space network link interface, but I believe it would be possible to grant the required capabilities to a click application.
You would have to figure out, exactly what capabilities your process needs to run this as a non-root user. Then the right place to ask for supporting this would be the Ubuntu Phone mailing list.
Just a Tip: You should present a very strong use case to get this kind of capabilities. The benefits of using your user-space algorithms should be plain, even to someone just scanning over your email.
Sent from my TF300T using Tapatalk
f69m said:
That works for the development images and community ports, but I am afraid if you buy a pre-configured UT phone (once they are available), sudo will not work. At least I would be surprised if a company would give full warranty for a device with working sudo.
Click to expand...
Click to collapse
When nikwen made the suggestion, I was happy for maybe 2-3 seconds, but then caught myself, because I suspected this.
[Notice how I am saving myself enormous amounts of time and frustration by avoiding downloading the SDK, opening my compiler tool-chain, and experimenting., and discovering all the things that you are telling me as we go along (especially about apparmour). Yes, I am very proud of myself for saving myself so much time by asking questions here. :angel:]
So my question still stands:
Under the assumption that my customers (doctors, scientists, etc.) are mature/sophisticated/responsible/whatever enough to know that the application that they are about to install on their smartphone (mine) is potentially very dangerous, but they are still interested in installing my app, and that they are uninterested in going through the manual process of rooting their phone or engaging in any other type of significant manual reconfiguration, what are my options?
Can Ubuntu Phone to be the OS-of-choice for this situation, or am I out-of-luck?
RareHare said:
Under the assumption that my customers (doctors, scientists, etc.) are mature/sophisticated/responsible/whatever enough to know that the application that they are about to install on their smartphone (mine) is potentially very dangerous, but they are still interested in installing my app, and that they are uninterested in going through the manual process of rooting their phone or engaging in any other type of significant manual reconfiguration, what are my options?
Can Ubuntu Phone to be the OS-of-choice for this situation, or am I out-of-luck?
Click to expand...
Click to collapse
Maybe my second answer and your post crossed? But anyhow, here are the steps you can take:
1) Figure out the minimum set of capabilities your process needs to run as a non-root user.
2) Write an email to the Ubuntu Phone mailing list, describing the required capabilities and a convincing use case that motivates the engineers to have a hard look into it.
Honestly, I think the chances are slim, given the kind of capabilities you probably need. But Ubuntu Touch is probably your best bet of all the OSs out there.
EDIT: Mind that Ubuntu Touch uses a read-only rootfs, with only some config files being writable (via bind mount) and apt/dpkg is not supported. Your app must be running as a click package as a non-root user, but I believe it is technically possible to elevate an app process with certain capabilities. It would be your job to convince Canonical to make the policy decision to support it and to make the effort of implementing it.
EDIT2 (you see, I am giving it some thought): Not sure, how your business plan looks like or if your app makes this approach feasible, but another option could be to open-source your basic algorithms and try to have them included into Ubuntu Touch. Then cash in on an app to make the features easily accessible.
f69m said:
That works for the development images and community ports, but I am afraid if you buy a pre-configured UT phone (once they are available), sudo will not work. At least I would be surprised if a company would give full warranty for a device with working sudo.
Sent from my TF300T using Tapatalk
---------- Post added at 11:14 PM ---------- Previous post was at 11:02 PM ----------
Hmm, never really used the user-space network link interface, but I believe it would be possible to grant the required capabilities to a click application.
You would have to figure out, exactly what capabilities your process needs to run this as a non-root user. Then the right place to ask for supporting this would be the Ubuntu Phone mailing list.
Just a Tip: You should present a very strong use case to get this kind of capabilities. The benefits of using your user-space algorithms should be plain, even to someone just scanning over your email.
Sent from my TF300T using Tapatalk
Click to expand...
Click to collapse
Hm...it would be a bit weird for me to justify the benefits my user-space algorithms to Canonical. My app is not an open-source app. I guess I should have mentioned that first. In any case, I can say that I am "experienced" in this field, and my colleagues, at least, are experts in the field, so if the question is whether I am mistaken in thinking I need this capability, the answer is probably no.
However, you do have me intrigued regarding the granting of capability for a click application. My guess is that this would have to happen within the context of Ubuntu Store and not any other way or?
I ask because it is not yet definite that we will choose Ubuntu Phone. That is what I am determining now. I would hate to get into a situation where we have to "work with" Canonical to get access to the Linux API that we need, which is why I was suggesting putting the decision into the hands of the user. I would also like to avoid "lobbying" Canonical for a feature. It would be more efficient for us if Canonical would simply tell us whether they are going to allow it or not, to what extent, and what would be involved.
Again, what we are asking for is pretty straightforward - access to the standard Linux WiFi drivers from user-space.
There's really not much more to it. I was hoping that, based upon the assumption that we actually need this, that Canonical would be able to give us an answer.
[P.S. Yes, our posts got crossed. ]
RareHare said:
Hm...it would be a bit weird for me to justify the benefits my user-space algorithms to Canonical. My app is not an open-source app. I guess I should have mentioned that first.
Click to expand...
Click to collapse
Well, I somehow guessed it would not be open source, and probably my EDIT2 to my last post (crossed again) is not an option. But make sure to read my first EDIT, it might have helpful information.
I think the question is not, if it is a benefit to Canonical directly, but if it is a benefit to potential users of Ubuntu Touch. The API support you need might be helpful for other applications too.
RareHare said:
However, you do have me intrigued regarding the granting of capability for a click application. My guess is that this would have to happen within the context of Ubuntu Store and not any other way or?
I ask because it is not yet definite that we will choose Ubuntu Phone. That is what I am determining now. I would hate to get into a situation where we have to "work with" Canonical to get access to the Linux API that we need, which is why I was suggesting putting the decision into the hands of the user. I would also like to avoid "lobbying" Canonical for a feature. It would be more efficient for us if Canonical would simply tell us whether they are going to allow it or not, to what extent, and what would be involved.
Click to expand...
Click to collapse
Any decision taken by the user must first be implemented by Canonical, or there is no way for the user to make that decision. Unfortunately, I am not an expert on UT app development and the UT SDK, working mostly on low-level things like porting UT to my own device. But, as an example, it should be possible to have an API that creates a sub-process with elevated capabilities (there might be a more elegant solution). Still Canonical will have to implement that and to do this, they need some kind of motivation. The motivation could be a good use case that shows potential for other applications or indeed "lobbying" them directly (which probably means to send them some money).
RareHare said:
Again, what we are asking for is pretty straightforward - access to the standard Linux WiFi drivers from user-space.
There's really not much more to it. I was hoping that, based upon the assumption that we actually need this, that Canonical would be able to give us an answer.
Click to expand...
Click to collapse
I have not really used those APIs, but I assume that the kernel capabilities needed for this are usually granted to the root user only. I am pretty certain that UT will not allow you to run a process as root, but as mentioned above, it should be possible to create a subprocess with certain elevated capabilities.
f69m said:
Well, I somehow guessed it would not be open source, and probably my EDIT2 to my last post (crossed again) is not an option. But make sure to read my first EDIT, it might have helpful information.
Click to expand...
Click to collapse
OK.
f69m said:
I think the question is not, if it is a benefit to Canonical directly, but if it is a benefit to potential users of Ubuntu Touch. The API support you need might be helpful for other applications too.
Click to expand...
Click to collapse
Well, the API that I need is definitely helpful for other applications. Namely, it is helpful to any application that already uses it. And there are many such applications that use the 802.11 WiFi drivers that come with Linux.
Any decision taken by the user must first be implemented by Canonical, or there is no way for the user to make that decision. Unfortunately, I am not an expert on UT app development and the UT SDK, working mostly on low-level things like porting UT to my own device. But, as an example, it should be possible to have an API that creates a sub-process with elevated capabilities (there might be a more elegant solution). Still Canonical will have to implement that and to do this, they need some kind of motivation. The motivation could be a good use case that shows potential for other applications or indeed "lobbying" them directly (which probably means to send them some money).
I have not really used those APIs, but I assume that the kernel capabilities needed for this are usually granted to the root user only. I am pretty certain that UT will not allow you to run a process as root, but as mentioned above, it should be possible to create a sub-process with certain elevated capabilities.
Click to expand...
Click to collapse
OK.
I am going to send an email to Canonical asking if they could articulate, clearly, in a manner that a Linux C/C++ software engineer can understand, their policy on native application development. Here's what it currently says on their Wiki:
Which applications do run on Ubuntu Touch?
Ubuntu Touch is primarily designed to support web apps, and native apps programmed in qml and javascript or C++. As it is a real linux, of course all non graphical applications run equally as on any other linux system. You can ssh to Ubuntu Touch and run any console based application.
X11 is not supported (so far) so all GUI standard applications will not run.
This is slightly confusing, because it gives the impression that, with the exception of X11, the run-time environment on Ubuntu Touch is equal to the run-time environment on Ubuntu Desktop.
Obviously, that is not true. Native applications on Ubuntu Touch are sand-boxed. My customer can run a console app on Ubuntu Desktop just fine, but on Ubuntu Touch, she cannot not - I guess she could if she rooted or re-flashed her phone, but that is not practical.
I think Canonical should make it clear that native C/C++ applications on Ubuntu Touch will be sand-boxed. Then they should articulate, clearly on their web site, just how that works, at least the part that they know so far.
The reason I feel this is necessary is that there are a lot of developers who read the press releases and see the words open source native C/C++, more open than Android, etc...and they get the impression that it is basically Ubuntu Desktop for small form-factor, but that is not quite true.
Spelling-out, explicitly, Canonical's native C/C++ strategy would save such developers a lot of time and hacking trying to figure out what is feasible and what is not.
To be fair, I just received feedback from a competitor to Ubuntu Touch, giving me assurances that the competing OS will allow the user/owner of the phone to determine whether any software should have root access, etc - basically, like the desktop version of the OS. I will send them an email asking them if they could make public what they have assured me in private.
These are things that should be crystal clear to C/C++ software developers long in advance before committing to a platform. I can only imagine the time that would have been lost if I had misinterpreted what Canonical wrote above, only to find out that there is nothing practical that my customer can do to install my application as easily as they would on Ubuntu Desktop because of the sandbox that cannot be easily turned-off.
RareHare said:
I think Canonical should make it clear that native C/C++ applications on Ubuntu Touch will be sand-boxed. Then they should articulate, clearly on their web site, just how that works, at least the part that they know so far.
Click to expand...
Click to collapse
Of course I can't speak for Canonical and I might be wrong, but I would really be surprised, if it was possibly to run applications as root on an off-the-shelf Ubuntu Touch device.
RareHare said:
To be fair, I just received feedback from a competitor to Ubuntu Touch, giving me assurances that the competing OS will allow the user/owner of the phone to determine whether any software should have root access, etc - basically, like the desktop version of the OS. I will send them an email asking them if they could make public what they have assured me in private.
Click to expand...
Click to collapse
Interesting, but then it might be a difference between the "reference" implementation and what is being delivered on an out-of-the-shelf phone. I can't belive a device vendor to take the risk of allowing root access and still providing full warranty. Most likely the user will have to accept a "no warranty" waiver to get root access, if that feature is not completly disabled by the device vendor. The same kind of holds for UT, as sudo works on the development images as mentioned previously.
EDIT: Make sure the feedback you received does refer to an actual device that is/will be available for sale and not to a development platform. Marketing wording can be tricky about simple issues like that,
RareHare said:
These are things that should be crystal clear to C/C++ software developers long in advance before committing to a platform. I can only imagine the time that would have been lost if I had misinterpreted what Canonical wrote above, only to find out that there is nothing practical that my customer can do to install my application as easily as they would on Ubuntu Desktop because of the sandbox that cannot be easily turned-off.
Click to expand...
Click to collapse
Agreed, but the same holds for any other platform.
f69m said:
Of course I can't speak for Canonical and I might be wrong, but I would really be surprised, if it was possibly to run applications as root on an off-the-shelf Ubuntu Touch device.
Interesting, but then it might be a difference between the "reference" implementation and what is being delivered on an out-of-the-shelf phone. I can't belive a device vendor to take the risk of allowing root access and still providing full warranty. Most likely the user will have to accept a "no warranty" waiver to get root access, if that feature is not completly disabled by the device vendor. The same kind of holds for UT, as sudo works on the development images as mentioned previously.
Agreed, but the same holds for any other platform.
Click to expand...
Click to collapse
I was very careful in asking the UT-competitor what their policy would be with regard to the subject of this thread, and they assured me that, when they say open, they really do mean open, as in open-like-the-desktop. However, just now, I found clues on the Internet what they said might not be quite true. So I just sent a grab-me-by-the-ears-while-you-are-speaking email asking them to be clear.
However, they have committed to allowing the user to install my application. They know that my application will open a device driver, and they said that it should work fine, that they would allow the user to do it, and that they had already intended to create a feature where the user gets to decide, after a WARNING, though they are not yet certain what this feature will be called. Note that they are not doing this for me alone. They are doing it, in general. In other words, they are doing what I proposed earlier: give the user the choice of whether to "use metal chainsaw".
As far as voiding the warranty goes...honestly, I do not think that will be a problem. As you know, I can write software that will wipe my hard disk clean on Windows, right now, put it up on my web site, and anyone in the world can download that software, and the most that will happen before they install my application is that they will get a brief warning. So the model for allowing the user to do foolish things has been with us for a while, and companies are still very profitable with this model, and despite viruses (I developed anti-virus algorithm that some of you use, btw), most people are happy with the level-of-control they get with their desktop devices. When Windows Vista tried to remove some of it, even moderate users were very angry, as you know.
I think that, especially for cell-phone carriers in the USA (Verizon, AT&T, Sprint)...the reason is not so much to protect the consumer, but to make sure that the user is not able...for example...to remove the bloatware that they put on the phone. It is more about controlling the customer experience for profit than for protection or being liable for damages.
The UT-competitor has probably figured out that there is a market for a truly open mobile platform, one where the decision of what happens to the device reverts to the owner of the device. They are probably counting on all the pent-up demand of C/C++/etc. native software developers who have been trying to escape the Android/Java iOS/* Sandbox, and not only that, the developers who are able to create revolutionary innovations if they had more access to the Linux API. My guess is that, once one OEM takes this path, the others will not have any choice but to follow, because there will be a free-for-all (no pun intended) in the development market. It will be messy, perhaps, but there will no longer be any restrictions on getting the most out of the device.
It will definitely be more efficient to decouple development from deliverance.
Well, sounds good, just hope that they will find an OEM that shares their views. I think Desktop/Windows is not a relevant reference, as nobody will send their PC back to Microsoft, if it is not working. And if you want to use official MS support you are paying dearly. On the other hand support/warranty is a huge concern for phone and tablet vendors.
Again, not being able to run a process as root on a UT device is my personal opinion and I am not speaking for Canonical or their partners.
EDIT: Do the "bad" operations you mentioned work on Windows 8 phone? I suppose not.
Sent from my TF300T using Tapatalk