Linked by Kostis Kapelonis on Sat 14th May 2011 15:43 UTC
General Development Application stores are growing everywhere like mushrooms. While users have initially embraced application stores because of the ease they offer with application installation, developers have several complaints. Division of profits from paid application and ineffectiveness of the screening process are among the major issues. Are application stores the best distribution channel possible? Can they satisfy both developers and users?
Permalink for comment 473224
To read all comments associated with this story, please click here.
Member since:

And this list is not even including ROMs for Android 2.3 (Gingerbread). I have installed many of these roms, and some of them are as different as many Linux distros are from each other. So you can't on one hand claim that Android is like a single distro that all roms run on, and then on the other hand say that all Linux distros are like operating systems, and should be considered completely separate from each other.

This may have been my mistake for not being clear. I made the assumtion, given the talk about Android and major Linux distributions in relation to the repository software distribution model, that we where talking about Android firmware that actually ships on production devices not enthusiast community custom firmware. My bad.

Now, I think it's fantastic that the Hacker communtiy is producing custom firmware. For lack of ability to work with the core distribution, they've forked it into one-off distributions. You haven't added anything new here. They are indeed child forks; still no different from other Linux based distrubtions:

- They are based on Google's parent distribution not provided by Google as official flavors of the official Android distro. They are analogous to Mint derived from Ubuntu not Ubuntu, Kubuntu and Xubuntu which are all official Canonical produced flavors of the same overall Distribution.

- They do not get updates from Google's distribution. When a new version of Android is released, one is going to have to wait until the third party Hacker releases an updated custom firmware based on the newer official Android version.

- Google does not have ownership and decision making authority over those child forks and can not be held accountable for there risks or benefits. The third party Hackers producing them do not have ownership or decision making authority over the parent distribution and can only react after the fact to changes in the parent distribution.

- You can't install that Incredible custom firmware on other devices. It's still a one-off device specific distribution. You can't pop it onto any "Android" branded device and have it work now can you?

The benefit that they have is being produced out of the motivation to enable the end user rather than further a retail business strategy. When the device manufacturers ship a one-off child fork, they do so under the claim of "differentiation"; give it a different cosmetic look, include "value add" crapware, include custom functionality which is often user hostile "to protect the children" such as my previous mention of Motorola's logic bomb designed to brick the phone if the owner tries to install a custom firmware.

Because the primary design purpose of Android is to provide a sandbox for running java applets, the child forks tend to retain that ability and provided the enthusiast child forks don't break compatability; fair enough. Let the Hacker community have at it and do what they do best.

(to be clear; using "Hacker" in the correct sense not the mass media "inherently criminal" bullshit sense.)

If you go to the website of an Android app, it will say that 'this is an Android app'. If you go to a website of a Linux app, it will say 'this is a Linux app'. It doesn't say 'this is a Fedora app' or this is a Ubuntu app'. To further illustrate my example, consider Amarok:

Android and it's child forks are still primarily designed to provide the java sandbox with the intent of running Android branded apps. Not all Android apps run across all Android child forks though now do they. Sure, it'll say "this is an Android app" but it may also say "you need a newer version of Android" or "this app does not install and run on this device". The hardware and child fork that your isntalling the app on still makes a difference. I do hope that changes much more with the release of Ice Cream under the new consortium agreement.

Your Amarok example points to a program developed for multiple OS. They provide a Windows version, they provide an osX version and they work with Linux based distributions so that each can also include a version. You wanted to point at the website so let's actually look at the relevant page shall we?

"Linux Distributions, BSDs and other Unixes"
(k)ubuntu - one distro, two flavors, one distro, packaged in it's repositories
openSUSE - one distro, packaged in it's repositories
Fedora - one distro, packaged in it's repositories
Debian - one distro, packaged in it's repositories
Mandriva - one distro, packaged in it's repositories
Gentoo - one distro, packaged in it's repositories
Arch - one distro, packaged in it's repositories (sensing a theme yet?)
Ark - one distro, packaged in it's repositories
Pardus - one distro, packaged in it's repositories
NetBSD - one distro, packaged in it's repositories
Exherbo - one distro, packaged in it's repositories
Chakra - one distro, packaged in it's repositories

All seporate products, all provide a product specific pacakge in there repositories. Fedora is not going to be responsible for Debian's package and Debian is not responsible for Fedora's. Notice that they are all represented as seporate things to even though they share a common kernel name.

under "Other (FreeBSD, Solaris, etc.)"
FreeBSD - not packaged by Amarok but available in Ports
KateOS - not packaged by Amarok but available in distro repositories
Weasel - not packaged by Amarok but available in distro repositories
PCLinuxOS - not packaged by Amarok but available in distro repositories
Solaris 10 - not packaged by Amarok but can be compiled for Solaris from source code
Yoper - not packaged by Amarok, looks like it also can be compiled from source

"Other operating systems (not yet officially supported)"
Mac OS - again, it's in the Ports system not an officially packaged app download
Windows - no official package yet but it looks like has provided a few unofficial Windows builds

Thanks to Amarok being an open source product, it's easily available to whatever distribution (the product level the end user will interact with) chooses to include it and many do as demonstrated by the downloads directions for each on the page you singled out.

So you've successfully pointed out that Amarok, common to open source development values, is easily made available for many different OS distributions including several that happen to use the same OS kernel. That doesn't change the fact that (k)ubuntu and openSUSE are seporate products provided by seporate manufacturers though they happen to be assembled from similar commodity parts and happen to be in the same product category (desktop software platforms.. encase that wasn't clear). Canonical does not have authority over or responsability for openSUSE any more than the folks at openSUSE have authority over or are responsible for Canonical's distributions.

Again.. Ford and Toyota both produce products in the automobile category and both happen to include a combustion engine and lots of bolts among the other commodity parts in the assembly. They even provide a similar user interface and retain interoperability with the roads thanks to respectd industry interface standards. They are not the same product though. They are not both "engines" just because they both happen to be based around a combusion ention now are they?

Reply Parent Score: 3