Free is too expensive (Economist)

Free is too expensive (Economist)

Nevertheless, it is through them that apps have access to their dependencies, and then depend on them being present in the app store.

Have you ever actually used any appstore? Of course if someone will try to create app store which works this way it'll not work.

Applications are not supposed to depend on app store. At all. Yes, some of them include instructions which say “install package XXX before you can use this package”, but these are rare: developers know to the very bone that when you add any such dependency you risk alienating users.

For the most part application is standalone thing and it can be installed in isolation provided you have required version of Android. Some allow you to further install plugins - but this is handled by application itself, not by app store.

App store reliably solves dependencies problem - by refusing to support them at all. This approach is tested and it does scale. It uses more resources then distro packaging approach, but frankly in a world where entry-level phones have gigabytes of flash and entry-level laptops have hundreds of gigabytes of space on HDD this is not an issue.

If you build an Qt app for Android you will experience how this is used to pull in the Qt libraries.

Yes, I know. Qt abuses the system slightly. Time will tell if it'll work Ok for them or if people will complain too much.

Problem is that this model is much more fragile, since you leave it up to packagers to handle all dependencies. That model simply does not scale.

Somehow it scales pretty well on Web: all these Google Maps APIs, Facebook APIs and so on are supported by developers without distribution-appointed police officers and so far Web works.

I repeat, the devil is in the details, you are mixing the dependencies which is a back-bone of open development with ABI breakage. For meaningful discussion we will need to separate between the two.

I don't care about any back-bones. I care about the ability to build and deploy the program.

"This is what makes it possible to create a store with 500'000 applications faster then Linux could build one with 50'000 applications."

I beg to differ. There are far more linux applications than 50'000.

Yes. Show me one repo with at least this much - and you'll have a point.

Bring in all the ppa's of ubuntu, and you have something more comparable.

Nope. If you'll bring all the ppa's of ubuntu on one system then most likely result will be something crazy - I'll be surprised if the resulting system will even boot. PPAs are dangerous beasts. They conflict with each other, some of them can break your system even if they are used in isolation, etc. IOW: they push the burden on user. And the last thing user want is to play “private distro packager”.

Ubuntu has adapted their software center for proprietary applications, so it is finally offered, but admittedly still in it's infancy.

It's worse: it does not even address API stability seriously. The only thing it says:

 In order for your application to be distributed in the Software Centre it must:

• Be in one, self-contained directory when installed
• Be able to be installed into the /opt/<package-name> directory
• Be executable by all users from the /opt/<package-name> directory
• Write all configuration settings to ~/.config/<package-name> (This can be one file or a directory containing multiple configuration files)

Short, simple set of requirements, right? Well, let's start. Be in one, self-contained directory when installed. How can I do this when Ubuntu does not provide stable enough foundation for the development?

No, it doesn't, but it pretty much takes care of the ABI issues for most other standard libraries.

Rilly? SDL is not there, crypto (neither openssl nor gnutls) is not there, desktop integration (dock, notifications, etc) is not there, HTML widget is not included, etc. Just what kind of desktop application can I build using this foundation?

I did mention Gstreamer on the other hand.

Which is not in LSB either.

Pulseaudio is a server, so I am not sure exactly what grievance you have developing against it. Along with Gstreamer I can also add SDL.

My grievance is in the fact that nobody guarantees their availability. And if you'll take a look here you'll see that GStreamer is on the road to incompatible 1.0 version. When this happened with openssl Ubuntu immediately punted old version it to universe which effectively rendered all packages which used it out of “one, self-contained directory” category. SDL in the same boat. It looks like PulseAudio does not have plans to do this any time soon, but still, it's a gamble, not a stable platform with a stable ABI.

If you are happy with the approach taken by other platforms, i.e., using a fixed low performing high level language, you can do it in Python quite easily and expect it to provide your precious stable ABI to kingdom come.

Rilly? Can you gunrantee that two years from now KDE will not decide to switch to python3, for example?

In my book, linux has had a stable ABI.

Linux kernel has remarkably stable ABI. Linux desktop is a disaster. That's what we are discussing here.