Ubuntu In a Nutshell: App Upload Process

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:

  1. The System – the core Operating System includes the system software itself that is required to boot the device, bring up services (e.g. networking/bluetooth/sound), and display the user interface.
  2. The Applications – these are the applications that run on top of the system where you spend most of your time as a user.

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:

  • To get an app into Ubuntu you need to create a .deb file (a Debian package). Debian packages are really designed to be used by people who build Operating Systems, and not regular app developers.
  • This approach meant that you could write an app with any software toolkit/platform that was in the archive. Unfortunately this results in a really inconsistent end-user experience – we have tried our best to support GTK and Qt apps, but these apps look and work quite differently, and it spreads the development team thinl trying to cater to all tastes.
  • If an app developer wants to get an app into Ubuntu they have to either (a) be an Ubuntu developer with upload access or (b) convince a developer to get their app in. This doesn’t scale.

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:

  • Packaging was complicated.
  • No app sandboxing, so apps needed a full code review.
  • Maintainer scripts can do naughty things, so they needed a full review.
  • Apps took a long time to be reviewed due to the technical limitations above.

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:

  1. The System – the core Operating System includes the system software itself that is required to boot the device, bring up services (e.g. networking/bluetooth/sound), and display the user interface.
  2. The Applications – these are the applications that run on top of the system where you spend most of your time as a user.

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?


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.


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.

  • Winfried Maus

    So in a very short version, you are trying to bring developers to create sandboxed “setup.exe”-like installers of their applications. In theory, this is a good idea. In practice, you are at least 25 years late to the party and this will never work in fragmented Linux-land.


    Because what you are proposing will be perceived as yet-another-Ubuntu-only solution, which, let’s face it, is exactly what it is. It will depend on the Ubuntu SDK and thus won’t work on anything that’s not based upon Ubuntu. (And even if it would work, nobody outside the Ubuntu community will want to use it.)

    Canonical might have the largest user base, but you are far away from having the largest developer base. In the commercial world, developers have to go where the users are. In the Linux ecosystem, let’s face the ugly truth, developers couldn’t care less about “their” users.

    Seeing how “user-friendly” most Open Source “products” actually still are, usability still is not even an afterthought for most people who develop stuff for the gazillion different Linux platforms. As long as you are a technical user, that’s usually not a problem and you get a lot of powerful, free stuff in form of Lego bricks that you can use to build your own system. But as soon as you are a non-technical end user and want to do a bit more than just browsing the web with Firefox, the Linux experience quickly begins to suck royally when you do not have a sysadmin sitting on your lap all the time.

    If the developers actually cared about experience for technically illiterate end users, the situation would be different. If developers actually cared about enabling those end users with user friendly, yet feature rich software, this would also be different. Just imagine a version of Shotwell that would be a bit more than a glorified thumbnail viewer and that could actually compete with iPhoto – or, gasp!, Aperture! You want the right thing and the “click-installer” definitely is a proposal that leads in the right direction. But if you really want to get this thing off the ground, I think you only have two choices.

    One: Speak with all the other major distributions out there and define a COMMON standard TOGETHER with them. But we all know that the chances of success with that approach are close to zero, for whatever reason one can possibly imagine, beginning with simple jealousy of the success of Ubuntu over other distros to the simple fact that most developers just won’t care enough to make life simpler for their users or that they won’t care if their software adheres to some new Ubuntu standard or not, because they don’t use Ubuntu themselves.

    Option Two: Do it like Apple. Hire a force of developers and develop all the core applications for your platform yourself and become independent from the moods of the so-called “community”. Once you have established and demonstrated a quality standard and attracted a sufficient amount of end users, developers with a more commercial mindset will follow.

    Any platform is only as good as the application software that exists for it. That’s the reason why Linux never took off on the desktop: Almost all desktop apps that were written for Linux or were at least ported to Linux are inferior to their commercial competition, either because they lack features, are harder to use, buggier, did not receive enough quality control or all of those reasons together. I know that this assessment will make me the best-hated man around here. But this assessment does not come out of thin air, it is based upon years of constantly trying to actually –USE– Linux on the desktop as a DESKTOP OS, not just as a developer or hacking machine. Heck, I’ve read that even one of Canonical’s own graphics designers still uses Photoshop instead of Inkscape and GIMP, and from what I’ve read, she even did so live on a conference. I guess the lady had some reasons for it that go along with what I just said, and it simply shows in what poor state the Linux application ecosystem still is after more than two decades. It’s like Steve Jobs once said back in the early 1990s about OS/2: “People don’t use operating systems. People use application software.”

    Instead of burning your resources on stuff like “Mir” and an Amazon shopping lens that nobody really needed, maybe you guys should write some quality apps for a change.Enough ranting. Now I actually have to re-install an Ubuntu Server that we use as a public DNS server. If you guys would fix the stability of BIND, that would be a great thing. And also, if you guys finally realized that a server should not welcome you with “System restart required” every two or three days because you once again pushed some updates over the wire that require a reboot, that would even be more awesome. Over the years, you managed to turn Ubuntu Server LTS into a system that requires more reboots than Windows Server 2008 (which I only reboot once per month after a patch day). Really, you should talk with sys admins that actually are out there in the field using and MAINTAINING your stuff on a daily basis. While we’re at it, my Xubuntu machine at home also greets me with a “software updates available” icon on what almost feels like a daily basis. Your software update policy has become horribly annoying. So much so that Windows finally sucks less in comparison. And that’s saying a lot.

  • Anonymous

    What do you mean with “Additional dependencies can simply be bundled into the package” ?

    Does this mean my additional depency libraries are within my Click-package, which means they are statical linked ? This means if two different Click-packages have the same dependency would result in double space.

    Even worse if my Click-package requires a library as dependency which is bundeled in my Click-package, how it is guarenteed that the dependency always gets the latest security fixes ?

  • http://hude.blogfa.com/ Ali Najafi

    So useful. I’m waiting for next ones.

  • http://hude.blogfa.com/ Ali Najafi

    I have the same question. Does it mean a basic dependency package will be downloaded many times each time with a different app? Or I’m misunderstood?

  • http://hude.blogfa.com/ Ali Najafi

    I have another question if the rolling releases may effect the app uploading in order to make it possible for user to get the latest version of app in whatever version of OS?

  • CheeseBurg

    There are actually a lot of developers who want to use and develop for linux, the biggest issue for them is actually very simple: to much choice and complications. This is where the Ubuntu SDK and Click packages come into play. With these, our options are very focused and make development as easy as Android or OSX/iOS. As for getting more developers, all that is needed is a strong app ecosystem and large enough userbase. Canonical is working on a the new software center for Unity 8 which we should see in about a year while things the Valve’s Steam is slowly getting more linux users.

  • CheeseBurg

    In theory, click packages will allow applications and the OS to be updated separately. What this means is that your app can update anytime without needing to wait for the next Ubuntu release. This also means that a developer only has to upload an app once, compared to the current system where a developer would have to re-upload their app every 6 months for the new Ubuntu release.

  • Anonymous

    click packages can specify a framework they’re requiring. So that’d be something like “Ubuntu 13.10″. There might be more frameworks in the future, but that’s not being planned AFAIK. For the vast majority of cases the Ubuntu Platform API should take care of 95% what you might need. If you rely on other code, you will need to bundle it until it enters the Platform.

  • CheeseBurg

    This is THE Daniel Holbach, right?

    If so I am very interesting in the future of the software center. I have a couple question about the direction it is going in as well as some ideas that I think (and hope) are useful. How do I get in contact with the team. I am new to things like IRC and mailing list and etc..

  • http://www.mhall119.com/ Michael Hall

    Click packages are just very simplified Debian packages, and developers already make .debs that are specific to Ubuntu. All we’ve done is make it A) simpler to create them and B) simpler to review them when submitted to the Software Center.

  • http://www.mhall119.com/ Michael Hall

    Common libraries will be part of the Ubuntu platform and won’t need to be bundled with Click packages. Uncommon libraries will have to be bundled. If a specific library becomes common, and as a result is being bundled by multiple apps, then it’s a candidate for becoming part of the Ubuntu platform itself.

  • Anonymous

    So what exactly defines a common library ?

    E.g. Taglib (which is included in Ubuntu’s repo) is it a common library or an uncommon library ?

  • Anonymous

    Join https://launchpad.net/~ubuntu-appstore-developers and you can mail to the mailing list, or join us on #ubuntu-app-devel on irc.freenode.net

  • Anonymous

    Simple example: I develop an app which requires Taglib. Do I need to bundle the library in the package although it’s in Ubuntu’s repos ?

    What about security issues if apps bundle insecure and outdated libraries?

  • Anonymous

    Yes, if it’s not part of the framework, you’ll have to bundle it and it’s your responsibility to take care of it as an app author. As a user, you’ll get a big level of security through app confinement though, cf https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement and subsequent pages.

  • http://hude.blogfa.com/ Ali Najafi

    That sounds great!

  • Anonymous

    Because any dependency other then the ubuntu SDK needs to be bundled, that makes the ubuntu SDK useless for any existing app, or for wider linux adoption.

    It promotes excessive system bloat for any none ubuntu SDK application. Because all none ubuntu SDK dependencies end up being duplicated on the system for each application that needs it.

  • http://www.mhall119.com/ Michael Hall

    Keep in mind that Click packages are intended for use only by independent apps, not distro apps.

    Independent apps are more likely to either not have many external dependencies, or want to control what versions of those external dependencies it uses.

    For everything else, we will still have Debian packages with all their dependency resolution glory.

  • James

    This sounds like a step in the right direction, but it will not from what I can tell help solve the glaring application issue that has been a high priority bug on launchpad for over 3 years now.


    Sadly, little or no progress has been made, atleast that is how it looks from the outside. There never appears to be any updates from the maintainer of this bug.

    Currently Ubuntu is just terrible if you want a stable system with up to date applications. An LTS release of Ubuntu is so out of date within a year unless you can possibly/hopefully with both fingers crossed and the wind blowing in the right direction find a possibly insecure PPA or a downloadable deb package for an application you want. It is crazy to me that Canonical advocate users to stick with an LTS release but do not maintain up to date ‘distro’ software for the life cycle of the release.

    Both Windows and OSX offer at least 5 year support on the desktop, so as long as the advocated (LTS) Ubuntu release. Software released today will still quite happily install on old version. Using Windows XP as an example, it was released in 200, and can still support the vast majority of FLOSS applications that ship with Ubuntu, Libre Office, Firefox, Thunderbird etc.

    There needs to be a real emphasis to keep the LTS release more up to date, if developers advocate using a 9 month supported version they have no consideration for how an ‘average’ desktop user will use a computer. Average users don’t install operating systems they use applications and if these applications are out of date by years in some cases then they will not stick with Ubuntu. Period. This is a big issue for Linux on the desktop.

    As noted in the comments in the bug report application software can be separated from core operating system components. See how Bohdi are doing it:


    Make no mistake about it application sustainability throughout a release life cycle and easier updating is a very, very important issue that needs urgently addressing in Ubuntu if it is to ever pass the 1% desktop market share that it almost has.

  • Anonymous

    On Ubuntu Touch exactly this problem is solved: apps are upgraded separately from the platform.

  • James

    Daniel, I think we can certainly applaud that fact. It is brilliant too see that Ubuntu touch will work as ‘expected’ from day one. However, can you comment or do you have any knowledge regarding the use of the click packages (or other update process changes) on the desktop, which for the approx 20 million desktop users is the big concern now.

    Will the current ‘broken’ application update (or lack thereof) process be resolved so that we can have a stable and supported desktop but have up to date applications? This is a basic requirement for a usable desktop for the vast majority of Ubuntu users and again I’d like to emphasise a major reason Ubuntu is not getting more ‘traction’ on the desktop.

  • Anonymous

    The plan is to let Touch and Desktop converge over the next months.

  • http://guideme.blogspot.com/ Mike Frett

    As far as what OP posted. I pretty much agree. You’re talking about too much choice, and I have an issue with that. Apple and Windows users don’t have choice. If it wasn’t for the choices in Linux, I wouldn’t be able to choose XFCE, GNOME etc.

    I don’t see the problem with it really, Devs, especially in Steam have already made a choice, Ubuntu. System requirements in games require Ubuntu, that’s what’s officially supported. Game makers have made their choice as far as Steam goes.

    If you are targeting gamers and desktop users, Ubuntu is really the only choice. Don’t forget about it’s offspring, Xubuntu, Kubuntu etc. You are not forced to use Unity. This is a good thing, choice is a good thing.

    It would be nice though, if the Ubuntu team worked with all the major distros to find a better package manager. Because like Mir, it looks like an Ubuntu only solution. You guys at Canonical need to learn to play nice with others if you are going to get any cooperation from other communities. But the thing is, they may not even want this.

    What burns me up is when a question by a newbie is answered with commands to be typed into the CLI when a perfectly usable GUI is available. Real nice way to scare people off, old timers…get with the times.

    I’ll just be honest, there isn’t even a point for devs to bother with distros like Debian or Triquel. You can’t even use your hardware properly with those distros without jumping through hoops. No…devs who want desktop users have chosen already. They chose Ubuntu. That’s not to say a game designated for Ubuntu will not work on another distro, the community usually figures out ways to get things to work, that awesome.

    So all this nonsense about too many choices and being Ubuntu only is just that, nonsense. The targeted desktop OS here is Ubuntu guys, end of story really. You wouldn’t tell your Mom to install and use Slackware now would you? exactly.

  • CheeseBurg

    Think about it like this: I am a OSX developer. I want to bring my application that uses all of OSX features to Linux with the same level of deep integration.

    First question, what toolkit do I use? Possible answers: GTK, Qt, Efl, wxWindows, FLTK, FOX, freeglut, GNUstep, etc.

    Second Question, what a language should I program in? Options include: C, C++, C#/Mono, Python, Ruby, Vala, Genie, Ruby, QML, etc.

    Third question, how many desktops environments/window managers are there? Possible answers: Unity, Gnome, KDE, xfce, lxde, iceWM, Awesome, Cinnamon Mate, Gnome 2(still used by many distros), openbox, etc.

    Now if the goal is for deep integration that means I would have to write at the least a custom wrapper for every single DE with the toolkit and language they prefer. Also I would probably have to use their custom libraries: Gnome libraries for Gnome, KDE for KDE, Cinnamon for Cinnamon, etc. Why should I go through all that hassle and complexity for a group who puts less money in total than OSX on every singe Humble Indie Bundle?

    Speaking of games, making a game multi-platform is something totally different than an application. As a game dev myself I can verify this so you can’t compare the two. Plus for games you don’t use a SDK anyway, you normally use a toolkit like SDL or DirectX which are TOTALLY different beast compared to the Ubuntu, iOS, or Android SDK.

    Before this becomes a rant, let me say that for a LOT of developers, especially the cool ones who make moblie apps, there was way to much choices. Even the ones who made desktop apps complained. This is why the Ubuntu SDK was created. You don’t have to like it but you need to understand that choice for a user (you) and a developer(me) are totally different. I a lot of ways I like less choice because it means it is easier for me to make a better product or to find help from other successful developers.

  • Kristian Rink

    Good write-up. I generally like the idea as then and now I am annoyed, too, by seeing how messy even a desktop including KDE and GTK apps looks like (colors, icons, fonts, bookmarks, …), and indeed, compared to the iOS or Windows/.NET world, this is quite a burden to developers (too many fundamental decisions – framework – to be made without even getting started doing any work). Same about building .deb packages, this is quite a hurdle to take in order to get an application packaged if you’re new to that world, not even including sane dependency management and all that. From that point of view, I welcome that idea.

    Then again, however: I don’t want an “Ubuntu SDK”, honestly. All these issues, back to front, apply to each and any other Linux desktop distribution, too. I would way happier embrace such an approach if it was something completely “open”, built in consent with the rest of the Linux desktop community and then adopted to meet Ubuntus special needs. Unfortunately, right now I got bit of a feeling Ubuntu seems more and more into building “proprietary” (as in “(almost-)only-there-in-Ubuntu”) solutions that more and more make Ubuntu different to any other desktop system, both in good and in bad ways. For quite a while, knowing porting Linux desktop applications between RedHat, SuSE, Debian (and, later on, Ubuntu) is relatively easy definitely was a good thing. Now, it more and more seems Ubuntu might be sneaking out of that, ultimately ending in Ubuntu having a “proprietary” Ubuntu SDK, a partially “proprietary” package management on top of the .deb packages (Click Packages), maybe a “proprietary” display server (Mir), maybe a “proprietary” desktop environment (Unity) and so forth, resulting eventually even in other Linux desktops (XFCE, KDE, …) to be ported to / used on Ubuntu becoming more and more difficult. Maybe I am all too pessimistic about that, and the last couple of years with Ubuntu really have been fun (also because that “Linux-for-human-beings” thing), but at the moment I thoroughly hope Ubuntu folks won’t completely mess things up.

  • Sicofante

    “built in consent with the rest of the Linux desktop community”

    Yeah, it would be ready in no time, like in 10 years or so… The Linux desktop has proven one thing in the las 20 years: they’re completely incapable of reaching consensus on anything. If I recall correctly, that’s why Ubuntu forked from Debian in the first place.

    Ubuntu is right leaving all the discussions behind and going its own route. You know, Shuttleworth wants to see the results himself, not just expect his grandchildren will…

  • Sicofante

    I’m fully behind this initiative. It will finally bring app updates independent of system updates and LTS releases will finally start to make sense. I have one HUGE question though:

    Is there going to be any effort to make the Ubuntu SDK able to develop multiplatform apps?

    I can’t think of any sane commercial developer targeting Ubuntu alone. Any facility brought by Canonical to the SDK so that the app can be exported/uploaded to the Apple Mac Store and the Windows Store, would actually make a lot of sense for most ISVs. As a matter of fact, Ubuntu SDK might become the de facto crossplatform development IDE for many developers. Android can use Qt/QML apps as well, and I’ve heard somewhere even iOS might.

    Since the Ubuntu SDK is based on crossplatform components (and the best at that, btw: Qt and QML), it should be conceivable to design it around cross platform developing.

    Is this even on the roadmap?

  • Kristian Rink

    Of course, you are right, and half of me shares this point of view. Then again:


    This is an old (Windows 2000) advertisement Microsoft used at least in Germany to point out that an “open operating system doesn’t just have advantages”, because ultimately it ends up either “being fragmented and heterogenous” or “leaving you with way more choices than proprietary ones” (depending upon your point of view). I know quite some people including myself who consciously moved from Microsoft to the (GNU/)Linux world mainly because there is way more open-ness, way more freedom of things to choose from. Don’t like GNOME? Go KDE. Don’t like either of these? Use OpenBox of FVWM and plain X. But: No matter which path you decided to go, you always ended up being capable of running all the applications around, no matter whether built upon Qt/kdelibs, GTK+/gnome-libs, FLTK or plain xlib. Price to pay for this was/is consistency and integration of a desktop (KDE applications will look and feel strange in GNOME and vice versa), but that’s a decision of individual freedom. A logical approach would be to try making things integrate better without giving up on that freedom – make things interoperable, make applications communicate well with each other, come up with human interface guidelines that go beyond just a single desktop. A lot of goodness has happened here the last bunch of years (just comparing things like dbus and all to early KDE CORBA stuff or the infrastructure in GNOME), but I guess it’s sort of a slow process – of course, because there are way more people involved with it. Canonical, right now, is taking another route which, from this point of view, at least to me seems way more like the route Microsoft has gone in Windows – make a development platform that eliminates many of the “fragmentation mess” (which is someone elses freedom of choice) by providing one limited set of libraries, APIs, technologies as the “Ubuntu SDK” – which will not in this way be available for other distributions?!

    I am not sure whether it will matter, but I think that ultimately, such an approach might help Canonical while at the same time providing damage to the rest of the Linux desktop – and be it by allowing FUD to sneak in. I already am experiencing this, once in a while:

    “Whill standard Linux applications still run on Mir?” “Will Wayland applications run on Mir?” “Will I be able to build an application that seamlessly runs on Ubuntu, Debian and Fedora in near future, too?” … and the like.

    So far, things were pretty easy, given at the very least X11 and low-level Linux user land as the lowest common denominator, making sure any application built on that foundation runs on all platforms providing that foundation (which happened to be each and every Linux distribution around). That’s pretty much the “two-layer” thing Jono was outlining here, just on a pretty much lower level. I love Ubuntu because of its overall approach even though I don’t share all the Canonical decisions, just the way I am not using Unity and will remain an Xubuntu user for as long as possible. However, the very moment Canonical will massively introduce applications that repeat what Microsoft and Apple did before – binding an end user to Ubuntu rather than giving her/him the open-ness of choosing an open distribution as (s)he desires – Ubuntu will have lost another supporter, and I guess I’ll not be alone in this, even if I’d really be sorry to see this happen…

  • Aber Kled

    But that’s not even fucking true.

    No matter how you create your application I’ll be able to use it no matter the distro.

    Are you really implying that Qt is unavailable in GNOME?

    Or that GTK+3 isn’t there for KDE?

    Then how the fuck am I running FF w/ GTK on KDE right now, typing this response?

  • Aber Kled

    Oh I can’t wait until you guys distance yourself from the Linux community, “the old timers”, and then realize that you can’t maintain shit anymore because no one wants to help.

    You can’t force everyone to use Ubuntu. Why?


    The actual software developers who create most Linux software – that Canonical is trying to monetize – are not using Ubuntu.

    The real solution are STANDARDS.

    You know – the things that make Steam work perfectly fine on my Debian box.

    Ubuntu is not special. You’re dependent on the people you call “old timers” to actually make your shit work.

    Where would Mir be without Wayland? That’s right – FUCKING NOWHERE.

    And then Canonical just came along, piggy-backed off their success – and introduced incompatibilities with other distros!

    Good luck when no one will want to work on your g. stack!

    (Fun fact: Microsoft contributes more code back to the Linux community than Canonical. source: http://www.theinquirer.net/inquirer/news/2166123/microsoft-contributed-code-canonical-linux-2632)

  • CheeseBurg

    “level of deep integration”. I think you missed that point. First of FireFox only uses a wrapper and is not built in GTK. Second if you want to use the functionality of the Gnome desktop to the fullest, you need to use Gnome libraries but that means if you want to also want to use the full KDE functionality then you will need KDE libraries as well which will lead to 2 different applications OR one big badly written application.

    Also consider visually aesthetic of the application, do most GTK application look good on a Qt desktop and vice versa? Most of the professional designers I work with say no. In fact, I have done usablity testing with Linux in the past and many of those “average users” thought the same thing.

    Theses are important issues to developers, especially to Android, iOS, and OSX developers of GUI applications. I know because that is what they have personally told me. That is what they write about in their blogs about why they don’t like Linux development or what they say on their podcast. Listen to Michael Dominick from Coder Radio.

    It is easy as a Linux user to look past these issue because you love Linux but for most people who do not these are real issues and you can’t just invalidate them because you think they are silly. It seems like Canonical thinks these issues are real enough if they are developing an SDK AND design guides AND revamping their app store.

    P.S. I enjoy good debates and conversation and I can get emotional about the topic sometimes too but I still respect you and everyone else. Please watch your language. I have no problem admitting that I am wrong but harsh language will not to defend your point any better, it will only weaken it.

  • Sicofante

    You’re forgetting a tiny little bit of information that’s relevant when trying to compare Canonical with Microsoft or Apple: they develop FREE SOFTWARE. You’re free to use Unity wherever you like or fork it. You’re free to extend Ubuntu’s SDK if you will. Is it easy? It seems not, but you can’t ask that too. Canonical must make the best decisions to build THEIR open source desktop OS. It’s other people’s duty to adapt those tools to “the rest of the community” if that’s their will. If Canonical had to make every tool easy to port to other distros, it would take -again- just too much time.

    Why don’t they try and find consensus with other forces in the community? Because they have no obligation whatsoever and there are infinite examples of such “negotiations” being stuck forever. I wouldn’t go that route myself. Ever.

    I don’t buy the idea that any Linux app from anyone but Canonical will work flawlessly cross-distro. That’s simply not true. There’s not even consensus on how to administer different distros and the FHS is anything but “standard”. Why would Canonical be the saint in the community when others get every pass to do things their own way? Why is Arch package system not considered “proprietary”? Sure, I can use it on Ubuntu, but at what price? It definitely doesn’t fit with the general idea of Ubuntu, the same Unity doesn’t fit with the general idea of Arch.

    I’ll tell you why: Ubuntu is the big one on the desktop. So everyone must blame them.

    I’m a big critic of Canonical and Ubuntu. They make terribly wrong moves in design (Unity is NOT one of them, btw; it’s probably the best idea they had in their whole existence). They don’t care about outstanding bugs and they’re arrogant as hell. They don’t listen to their users. They don’t know how to make usability studies and extract wrong conclusions from them (the “dodge” affair was simply embarrassing.) The Edge campaign was a total disaster. They are governed by a whimsical dictator who’s probably responsible for most of these mistakes. And yet, with all of that on their shoulders, they make the only distro that makes sense for any serious prospects and if I ever leave Linux it won’t be for another distro, but back to Windows or OS X. (That’s just my opinion of course).

    I want a desktop backed by a company. Check. I want a desktop that focuses on their goals. Check. I want a desktop that uses cross-platform toolkits, especially those backed by a company (Qt. Great move.) Check, partially. I hope they listen this time and make a cross-platform SDK (targetting not only Ubuntu and Linux in general, but especially Windows and OS X).

    I don’t give a damn about the so called “community” (there’s an expression in Spanish: “jaula de grillos”, which literally translates to “cage full of crickets”; that’s how I see the “community”) I applaud Red Hat for making a serious business out of free software, even if it takes obfuscating the sources to make money. I applaud Canonical for trying to make a serious business out of consumer free software, even if it takes leaving the community behind and do it their own way. Remember: it’s FREE SOFTWARE. Don’t like it? Fork it.

    What will happen to apps when Mir is finally deployed? App developers will tell, but if I were them, I’d port my apps to the Ubuntu SDK ASAP to gain automatic exposure on tablets and phones for one. If the SDK is cross-platform (with a focus on Windows and OS X users), it would be a no-brainer to move there.

    Canonical might make the mistake of not targetting Windows and OS X developers with their SDK. They’re experts making mistakes. Let’s cross our fingers. But not following the “Linux community”? Best decision ever.

  • CheeseBurg

    I know there is work to bring the Ubuntu SDK to Windows and OSX so you can develop Ubuntu apps there but not sure if the SDK will become what your asking. It is possible that since the apps are made in QML/Qt, they are ready mulitplatform already just lacking in deep integration with the other OSs’ features.

  • CheeseBurg

    Click packages are open source so another project can use them. Same thing with Unity but that is a bit of a dependency nightmare from what I understand. I think other distros might use it or even use it’s design to make their own solution. I think Canonical gets a lot of flack for not giving to other projects which is understandable BUT they do not care if you just take their stuff and because it is open source, you can and make whatever changes you want for yourself.

  • Sicofante

    You “old timers” just live in a bubble. The world is not watching you closely. The general public doesn’t give a damn about the Linux infinite choices and Ubuntu is offering that ordinary people what you “old timers” haven’t been able to offer for two decades now (ironically, the other distros that target ordinary people are Ubuntu derivatives…)

    If you develop open source software, you are giving Canonical the right ot use and modify it at will, which is exactly what they’re doing for the benefit of many “new timers”. Why are you so outraged? If you don’t want this to happen, just release your software as closed source and give it only to the ones you choose.

    I find it really really hard to understand this hatred against Ubuntu, if it’s not just pure envy.

    (About your “fun fact”, you guys have been told a thousand times that code is not the -only- measure for contributions, but you still think that’s THE thing that counts. Since you can’t understand this basic idea, I’m not trying to explain it again.)

  • Sicofante
    I know there is work to bring the Ubuntu SDK to Windows and OSX so you can develop Ubuntu apps there”

    Actually this is the opposite I was asking for. I’d love Ubuntu to become my developer platform, but I obviously want to target other OSs (both desktop and mobile), i.e., make cross-platform development. I don’t quite see the point in porting USDK itself to Windows and OS X. Ubuntu is far from being a target Windows or OS X developers might be thinking of at this point… However, making USDK a cross-platform and cross-device development environment would entice a lot of developers towards Ubuntu as a development platform.

    I do understand cross-platform apps lack deep integration with the OSs targeted, and you usually would have to tweak them by hand to a certain extent. But that’s usually a compromise every cross-platform developer is willing to accept, no matter the SDK.

    What’s hard to swallow is using an SDK that will produce code for Ubuntu only. If I have understood it well, the USDK expects certain libraries to be present on the system for the Click packages to work. It’s just a guess, but this requirement won’t probably be met by Windows or OS X. So there should be workarounds (runtime environnents for each platform come to mind).

    Also, I understand the first iteration of the USDK won’t target cross-platform development, that’s why I’m asking if it’s on the roadmap, i.e., if it’s being designed with that feature in mind. A reply by Mr. Bacon would be highly appreciated.

  • Sicofante

    AFAIK, despite all the talk about Ubuntu Touch, that will be just the new Ubuntu. The same codebase and platform for all devices, It includes provisions for apps to adapt to each form factor. The app will know if it’s running on a phone, a tablet, a desktop or a TV, and adpat itself to it. This has been shown already on some videos (sorry I can’t find them right now).

    So while the PR focus is on touch/mobile at this moment, all the efforts should go along with the desktop automatically. (AFAIK, the merge into convergence is planned to happen by October 2014, i.e., 14.10.)

    Can we expect all apps to be developed with this SDK? Obiously not. Not at the beginning at first. I can’t see LibreOffice or Firefox being ported immediately to the converged model Ubuntu is aiming at. But since the benefits are huge (both apps would be automagically ready for tablets with no further effort), I don’t discard it either.

  • Sicofante
    This means if two different Click-packages have the same dependency would result in double space.

    I’ve read this concern a number of times. Why’s it such a big deal for some? It’s not like you’ll fill the users’ hard disk with libraries. OS X has been using this model for many many years. Have you ever heard an Apple user or developer complaining their disk is full of duplicate libraries?

    Comparatively, the shared libraries model stops applications from being updated until the whole system is updated. This renders the USC useless and forces users to mess around with PPAs -if they’re lucky enough one exists for their chosen app- and/or udpate the whole system every six months (making LTS releases mostly unusable after a year or so). The shared library might work for servers (I have no clue about servers), but is completely broken for desktops. Rolling releases are simply too risky for ordinary users. So the Click package model, obviously inspired by OS X, is a godsend for desktop Linux.

  • JayArby

    I’m glad there is a new clean package system in the works–this is definitely necessary and a good thing.

    But what worries me is the lack of dependency resolution. As a programmer, one of the most attractive things to me about developing on Linux (and Ubuntu/Debian specifically) is how easy it is to resolve dependencies. It sounds to me like this system in its current state is going to introduce the same dependency hell that plagues Windows. Might work fine for simple phone apps; but for the desktop, people are still going to be using all kinds of external libraries that require other external libraries ad infinitum.

    I know debs will still be available for that purpose, but that means the new packaging system isn’t truly a full replacement.

  • Aber Kled

    Old timers?

    What the fuck is that?

    People who know how to use GNU/Linux to its full extent? People who are using it to provide technical solutions? People who are building it?

    “I find it really really hard to understand this hatred against Ubuntu, if it’s not just pure envy.”

    OK, let me explain then.

    Ubuntu is deviating from the community and leeching instead of contributing back.

    The FOSS community used to be well integrated and worked on common standards – and Ubuntu is bastardizing all of it by reinventing the wheel and not contributing.

    They lied about Wayland just to make their own protocol which they can 100% control.

    They have EVERY right to do that – but I also have every right to point out what fucking destructive assholes they are.

    “Since you can’t understand this basic idea, I’m not trying to explain it again.”

    Then how is Canonical contributing?

    1. They aren’t pushing code (#1 one and the most important way of contributing to FOSS)

    2. They aren’t bringing in new users – in fact they are alienating them from the whole FOSS world by introducing retarded products such as Unity.

    GNOME 2 was the interface that brought in new people. Intuitive, simple, could look nice. After it was deprecated by GNOME 3 and much more importantly – Unity – only managed to lose users.

    On the other hand:

    1. Ubuntu/Canonical as I said aren’t even supporting the common protocols and standards.

    2. They introduced SPYWARE in their OS.

    3. They are doing their VERY BEST to not spread Linux awareness. They call it “the Ubuntu kernel” – not Linux – which is evil.

    4. With introduction of “Mir” – they will start pushing for Mir-exclusive drivers, once again harming the community where it hurts the most.

    Canonical + Ubuntu = cancer of FOSS

  • Sicofante

    The bubble…

  • Jennifer Swanson

    Ubuntu isnt the only distro on the market… Now while im not trying to bash ubuntu as they have done some good things.. This doesnt seem like one of them as it seems they are trying to break away from the linux model