I have no issues with paying for anything FLOSS related or GPL’d my issues with this #ubuntuedge campaign are;
1. It’s a mobile phone, I have no interest in mobile phones, the vast majority of the FOSS community mainly develop desktops and or servers so will potentially only have a cursory interest in a mobile phone. I honestly cannot fathom the excitement at this move away from what we have all been doing for the last 10 years to a totally different environment.
2. I’m totally against the form and method this campaign has taken. The business world already views FOSS as twelve year old bedroom hackers, and this just makes us look like a charity case. A company like Canonical should have funded this themselves, they should have arranged for 10,000 units to be built and sold them on a pre-order basis. Clearly Mark Shuttleworth actually has no faith in this concept at all as he was not prepared to gamble his money but more than happy to gamble with the Ubuntu communities money. Personally, IMO he should hang his head in shame for cynically playing on the fact that the loyal Ubuntu user base was obviously going to dip into their savings at a time when the world is in a recession and everyone is feeling the credit crunch.
3. It is painfully obvious that the vast majority of people including Ubuntu users actually have no idea about this campaign other than“They want $32 and you can have a phone.”I’ve seen over twenty posts both on G+ and Twitter from people who are convinced there is actually a phone that they can buy now! Why do they think that? Because of all the images of people holding a fake#ubuntuedge phone!
4. There is far too much vapour-ware from Canonical or bullshit if you prefer. It’s getting to the stage whereby I wish the whole pack of cards would come crashing down because it seems to me the only thing keeping Canonical going these days is hot air and bluster! As the old saying goes “when the money runs out you’d all better watch out!”
5. I have done sales for over 30 years now. I know sales I know marketing. Yes they’ve had some column inches over this but a mention on the BBC and a report in the Daily Telegraph does not pay the staffs wages! SALES pays the wages, MONEY pays the bills, hard CASH pays for development. I suspect there will be certain people will still be stupidly saying “Ah but look at the publicity we’re getting” while filling out their Job Seekers form!
This article is part of a series of blog posts covering the many different areas of work going on in Ubuntu right now. See the introduction post here that links to all the articles.
In this article I am going to discuss some improvements we making to significantly simply and speed up how app devs get their apps into Ubuntu.
You can think of an Ubuntu system as two layers of software:
When we started working on Ubuntu back in 2004 the system and the applications where closely intermingled. We basically synced the Debian archive with Ubuntu, applied a bunch of patches, and whatever was in the Debian and Ubuntu archives was available as applications.
There were some inherent problems with this approach:
With these issues we tried to remedy the problem by creating the Application Review Board; a community group who would review packages with a simplified criteria. Unfortunately, despite the best efforts of the ARB, they were never really set up for success due to the technical limitations in the platform.
The primary technical limitation the ARB faced is that the Ubuntu system has traditionally lacked sand-boxing to protect it from naughty applications doing something…well, naughty. This meant that every app they reviewed would need a full code review for every version submitted. So, an app developer could release 1.0 and then release 1.1 a few weeks later and this would require two full code reviews. Not only this, but Debian packages have something called maintainer scripts that can theoretically do anything as root, so the packaging needed checking too.
For a group of volunteers with a growing list of submitted apps the ARB quickly fell behind. This resulted in frustration all around – for the ARB, for app devs, and for those of us working to refine and improve Ubuntu.The New App Upload Process
So, the previous system had the following primary limitations:
We started building a new specification for the new process some time ago. My team wrote the initial spec with input from a range of teams, and this has formed the foundation for the work that is reaching maturity now. Let’s cover how it works.
There are three primary pieces to this work, click packages, sand-boxing, and uploading.Click Packages
Firstly, remember how earlier I mentioned two layers in an Ubuntu system:
The Debian packaging format provides a remarkable range of features that are really designed for the former, for building Operating Systems. For the latter, app devs who simply want to package their code into something that can be loaded by users, we have created a new, simplified format for packages. It is called the click package format.
Click packages are simple to create: when you have your project open in the Ubuntu SDK you can press a button to generate a click package. Done! Click packages also don’t include maintainer scripts: they are simply not needed for the vast majority of apps, so, that already removes a security risk and something that needs reviewing.
A key benefit of click packages also is that they don’t include full dependency resolution. Many of you will be familiar with running apt-get update on your system. Well, this syncs the list of packages from the archive and figures out all the dependencies and how they map out (e.g. knowing that GIMP requires GTK, which in turn requires X). This takes quite some time and doesn’t scale to thousands of packages that getting updated all the time.
With a click package the software simply depends on the Ubuntu SDK. This means we don’t need to worry about all that complex dependency resolution: we know the dependency, the Ubuntu SDK. Additional dependencies can simply be bundled into the package. Also, instead of maintaining a list of packages on the system…they are on a web service. You need a connection to download the package anyway, so why not ask a service which packages are available?Sand-boxing
With a simple and efficient package format all set we next have the issue of sand-boxing.
This is more work than you might imagine. The team identified a big list of sand-boxing requirements that were needed for us to be sure an app could be run without a code review. This is not only protecting the system from inappropriate calls, but also handling issues with other components (e.g. sniffing keyboard events in X apps).
Well, the awesome Ubuntu Security Team has been working on full sand-boxing throughout the system and most of this work has been completed. This has also influenced some other design decisions: as an example, Mir (our new display server) is designed to not expose the keyboard event sniffing issue X has faced.
The basic result of this work is that the security team have an app called evil app that does a series of naughty things, and the sand-boxing protects the system from such naughtyness.
With this sand-boxing in place it essentially mitigates the need for a full code review, which was the primary bottleneck previously. This combined with click packages not having maintainer scripts and complex dependency chains makes reviews much easier and more efficient.Uploading
The process for uploading an app to Ubuntu is going to remain largely the same as it works generally pretty well. As before you can select a package to upload, set information about the app, add screenshots and more and then it will hit a review queue before it appears to Ubuntu users.
The good news is that because the review only really require a check of permissions, meta-data, and a few other simple bits (thanks to click packages and sand-boxing), the review can be done in under 15 minutes as opposed to multi-day code reviews. This means apps should go in more quickly.
Once your app is in the archive you will be able to search for it across all Ubuntu devices. Currently all apps will be displayed, but we are adding features to only show apps that will work on that device (e.g. only show apps with a phone UI on the phone).Are We There Yet?
So where do we stand with all this goodness? Fortunately, we are getting close.
The click package format is largely complete and we have tools for creating click packages in the SDK and installing them on a system.
Much of the sand-boxing work has been largely completed, although one caveat is that because we are working on Mir as our new display server, we are not investing in fixing keyboard sniffing in X (which would be a huge amount of work). This means that we won’t release this system on the desktop until Mir is on by default (around 14.10). Our existing system will be in place until then.
The app upload piece is online and largely complete (although going through a series of reviews), and the scope for browsing new click packages is on the mobile images although isn’t quite yet hooked up.
You can see an early video demo of this working below:
Can’t see it? See it here!
Our goal is to have this full system in place for mobile in 13.10, and for desktop in 14.10. This will all make getting apps into Ubuntu quicker, easier, and more rewarding than ever before.
There is some really awesome work going on right now in Ubuntu, and much of it is fixing and resolving issues and bottlenecks that have been an issue in Ubuntu for many years. Not only are we building an awesome convergence platform and cloud orchestration story, but we are re-building much of the core foundations to make these efforts more successful.
One of the challenges we have with all this great work is that even though everything is out in the open, some folks don’t have a crisp summary of the different pieces. So, I am kicking off a blog series that will summarize many of these different efforts as they stand.
My goal is to provide a overall summary of the work (not a huge wall of text) and when we expect it to be completed. I will regularly update this first post with a link to all the articles as I write them, so folks can point people to this post which will link to them all.
Some time ago we announced Mir; a thin, efficient, multi form-factor display server that will form the foundation of Ubuntu moving forward across desktops, phones, tablets, and TVs.
Our goal has been clear that in Ubuntu 13.10 we will include Mir by default for cards that support it and fall back to X for cards that don’t (primarily those that require proprietary graphics drivers). In 14.04 we will deploy Mir but not provide the X fallback mode, and we are in active discussions with GPU manufacturers for them to support Mir in their drivers.
I wanted to provide an update on the progress we have been making with Mir.Mir is in Ubuntu 13.10
The Mir team have been working hard to get Mir ready and in the archive ready for Feature Freeze on the 29th August. I am pleased to report that Mir is now available in the Ubuntu 13.10 Saucy archive and available for use.
Now, there are a few caveats here:
Good progress is being across all fronts with Mir and we are on track for our Ubuntu 13.10 commitment. As part of this work we have also been providing weekly Mir engineering updates as part of our Weekly Ubuntu Update videocast, so you can get a clear weekly idea of current status.Mir in Ubuntu Touch
With the furious progress being made, we are expecting Mir to land in the daily Ubuntu Touch images in the next week. This means that those of you using Ubuntu Touch on your phones and tablets will have Mir running on your device soon. To get this, simply upgrade as normal.Test Mir in Ubuntu 13.10 Desktop
Anyone is able to run the development version of Ubuntu 13.10 by installing the latest daily ISO and although Mir isn’t switched on by default yet, it is available you can test it by running:sudo apt-get update sudo apt-get install mir-demos unity-system-compositor
Now to be clear: if Mir is working you should see no graphical difference from your normal system. Mir exists underneath your desktop environment, so you should just see your desktop as normal.
We are going to be kicking off a series of Mir testing campaigns in the coming weeks, but right now I would like to encourage you folks to install Mir and start your system as normal and test it is running with:ps ax | grep "unity"
You should see a line with unity-system-compositor listed. If you see this you are running Mir! If you see this and your desktop works as normal, this is considered a success.
If you have a proprietary graphics driver (e.g. some Nvidia/ATI cards) and you run the above command and don’t see a unity-system-compositor entry then the system correctly fell back to X and this is considered a success.
If the system doesn’t display graphics or you see a line with unity-system-compositor and you see significant performance or tearing issues, this is considered a failure.
I created this wiki page to track how Mir works on different graphics cards. Please add your graphics card (if it isn’t already covered) and whether Mir was a success or failure.
If you do have problems with Mir and want to start a normal X server, simply edit /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.conf and comment out the second and third lines:[SeatDefaults] #type=unity #unity-compositor-command=unity-system-compositor.sleep
Now restart LightDM and you are good to go. Uncomment these lines to go back to Mir.Mir Ecosystem
In the last few weeks we have been having some wonderful discussions with those who are actively interested in utilizing Mir. This has included:
Overall, Mir is making steady and consistent progress, but we need your help to test. Keep your eyes peeled for a number of testing initiatives moving forward. Thanks!