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?
Order by: Score:
App stores vs distros
by WorknMan on Sat 14th May 2011 16:54 UTC
WorknMan
Member since:
2005-11-13

Users will be able to install illegally applications outside the application store with the same ease (i.e without any technical know-how, think Aunt Tillie) with no external help for the "jailbreaking" process.


Users can already do this now with Android. You simply tick an option in settings and you can side-load the APK files. Of course, some apps still require root access for installation, but even most of those are available in the Android marketplace, so that's not exactly the same thing.

Installing applications outside of the application store will be completely legal and most users will have a mixture of applications (official and non-official).


As stated before, you can already do this on Android. You have to jailbreak to do this on iOS, but it is no longer illegal to do so in the US (thanks to the Library of Congress).

Basically users will select application stores as Linux users choose deb/rpm repositories (ability to use other ones apart from the "official" one).


You can already choose between multiple app stores on Android and iOS (though iOS still requires jailbreaking). On Android, there's the Amazon app store and on iOS, there's is Cydia (and probably a few more I don't know about).

As for the Linux distro repositories, they are not without their problems either. For example, if Android worked like most Linux distros do, each individual phone would have its own app store, and when a new app/version of an old app was released, you'd have volunteers for each phone to package up that app and make it available on the phone's app store. If you are an end user of the phone, you may find that the app you want is not on your app store, or is several versions behind what's current, so you've either got to try and figure out how to side-load it, or you just have to beg and plead to the distro gods to update your app..

On the other hand, I haven't messed with the whole Linux distro thing in years, so maybe it has gotten better over time than how I remember it. *shrug* My point is that each of these two models has its pros and cons, and maybe we can find the right balance over time.

One last thing to note is how the author talks about apps being removed from these app stores, but I have a hard time believing that if some big company was threatening a lawsuit because of some app that was on a Linux distro was infringing on their copyright (or whatever), those overseeing the repository wouldn't take it down in a heartbeat.

Edited 2011-05-14 16:56 UTC

Reply Score: 5

RE: App stores vs distros - jailbreaking
by jabbotts on Sat 14th May 2011 23:44 UTC in reply to "App stores vs distros"
jabbotts Member since:
2007-09-06

Having to jailbreak is the primary point. With Idevices, it's not just an option toggle (Android) or easy easter-egg standard across all devices running the OS (Maemo). The fact that one must jailbreak the device and potentially repeatedly with a new method every OS update sucks.

In terms of android, perhaps rooting is different from adding third party repositories. In terms of rooting, that used to be a different method per Android version and hardware version combination if it's not still. The issue isn't just the ability to add third party repositories but the ability to have complete access to one's own purchased property. Android also suffers from poor repository management. I'd much rather see a two or three teer vetting process like Debian's unstable/testing/stable or Maemo's development/testing/production methods.

"if Android worked like most Linux distros do, each individual phone would have its own app store"

Currently, repositories differ by distribution not device they happen to be on. Debian repositories don't care if they are accessed from my server, desktop, notebook or MID. Ubuntu is a fork of Debian and had to provide it's own repositories. Mint is a fork of Debian and it had to provide it's own repositories. Mandriva does not draw on Red Hat's repositories. These are all separate distributions managed by different organizations and should indeed draw on repositories also managed by those organizations. If you want to work within the distribution, you work within it's repositories and organizational structure. There are very good reasons why that is.

Repositories are a defining and competitive attribute of the distribution. Customer service, product quality control, available software.. all there. Does the distro have good quality control (Debian's three stages) or is it less competitive on that aspect (Gentoo's IRC Server incident). Versions of programs are not the latest and greatest (Debian Stable), consider a distribution that provides more bleeding edge with resulting less stability (Ubuntu forked from Debian Testing/Unstable branches). Competitive or defining attributes are not foreign to any other product category either; cars, tooth paste.. all got them.

Now, if Android where like traditional Linux based distributions any vendor shipping uncorrupted Android would draw on Android repositories regardless of what hardware branding it's installed on. If a device is branded as an "Android device" it should be able to easily take Google's core distribution firmware through a standard flashing process; let manufacturers provide a small separate blob image for device specific drivers if they must. Really, they should be providing the drivers back to the core distribution's kernel but the add-on blob is an acceptable compromise for the moment.

Vendor's who must fork Android into there own one-off version, as has been sadly popular, should indeed be providing there own repositories. They fork the distribution away from the parent distro, they accept the responsibility of managing there own repositories and loss of use of the "Android" branding. It may actually work out in the end user's favor by adding another bit of motivation to stick with Google's parent distribution rather than go it alone for branding or malware purposes (like Motorola's logic bomb modification).

In my time, I've not really seen packages pulled from a repository under threat of lagall action. The only example I can really think of is probably a decade old when Red Hat stopped including the mp3 codec and similar multi-media related packaged (RH3'ish?). It made the distro more appropriate for business use and I found Mandrake which was more appropriate for home use.

There are still distributions that deliver limited or poorly managed repositories and that's what makes other distributions preferable choices. Ubuntu draws on Debian's testing/unstable branches and makes poor security related choices about default configurations so I use a distro that better supports my preferences for stability and strong security related defaults. Want a phenomenal set of "control panel" type utilities; Mandriva's draketools make it a very attractive new user distribution (hopefully they've improved on the overall distribution management or the Magea folks do better).

In short though, if Android was like traditional distributions, it would probably be much improved over the current mess of fragmentation caused by what should be separate fork distributions continuing to claim branding of the parent distribution while delivering one-off modified versions.

Reply Score: 3

WorknMan Member since:
2005-11-13

Repositories are a defining and competitive attribute of the distribution. Customer service, product quality control, available software.. all there.


IMHO, that's a pretty bad way to differentiate distros, and a pretty bad reason to have so many different ones. If we're going to play this game, I'd rather see 3 different distros with very solid repositories, rather than 900. Or better yet, how about 1 distro with 1 repository? One of the points made in the article is that having a single app store exposes a single point of failure, but if each distro has its own repository, how is this any different? Sure, maybe you can edit your apt.sources file and add in a couple more, but do you really want to explain to my mom how to do that?

Versions of programs are not the latest and greatest (Debian Stable), consider a distribution that provides more bleeding edge with resulting less stability (Ubuntu forked from Debian Testing/Unstable branches).


Yeah, good luck explaining that to the average iPhone owners. This kind of bullshit is EXACTLY why Linux on the desktop never gained any significant marketshare.

If a device is branded as an "Android device" it should be able to easily take Google's core distribution firmware through a standard flashing process; let manufacturers provide a small separate blob image for device specific drivers if they must. Really, they should be providing the drivers back to the core distribution's kernel but the add-on blob is an acceptable compromise for the moment.


Agreed 100%.

Vendor's who must fork Android into there own one-off version, as has been sadly popular, should indeed be providing there own repositories. They fork the distribution away from the parent distro, they accept the responsibility of managing there own repositories and loss of use of the "Android" branding.


That is the way it works now, in fact. If you deviate too far from 'the standard', you lose the ability to call your product Android, and you lose access to the Android marketplace. Of course, some people would argue that it doesn't go far enough, and I'm one of those people.

Reply Score: 2

jabbotts Member since:
2007-09-06

The thing to realize is that the distribution is the consumer product not the kernel it happens to be based on or any other separate commodity parts it happens to be assembled from. Debian, Windows, Ubuntu, Mint, Red Hat, osX; all separate distributions at the product level which the consumer interacts with. A shelf of parts and bolts is not a product usable by an average driver until it's assembled into a car.

(now, to see if I can figure out the formatting tags)


IMHO, that's a pretty bad way to differentiate distros, and a pretty bad reason to have so many different ones. If we're going to play this game, I'd rather see 3 different distros with very solid repositories, rather than 900. Or better yet, how about 1 distro with 1 repository? One of the points made in the article is that having a single app store exposes a single point of failure, but if each distro has its own repository, how is this any different? Sure, maybe you can edit your apt.sources file and add in a couple more, but do you really want to explain to my mom how to do that?


I'd agree if the repository was the only attribute that differentiated a distribution from other's. What I said was that it's an attribute; that indicates that it is among other differentiating attributes. For example, how the overall project is managed, what it's production goals are, the cosmetics of the resulting distribution and so on.

Any why is choice suddenly a bad thing when we talk about Linux based distributions? Somehow we manage to choose a toothpaste or breakfast cereal in-spite of having more than three or one choice on the store shelf. Mint should not be allowed to exist because it's production goals differ from Canonical's? Canonical should never have been allowed to exist because it has choices which differ from Debian's? Why on would we want different products within a category focusing on the different needs of different consumers.. that's just madness.

Regarding one point of failure, is the difference between a single repository for one distribution (App store) and separate repositories for separate distributions not obvious? Um, because they are separate products from separate organizations making separate decisions and one is not directly related or comparable too the other?

Let's imagine a world where all Linux based distributions must draw on a single repository:

- how are differences in default config and system layout by different distributions managed?

- how are different distributions able to try out different package formats and managers when all must adhere to a single repository?

- when one of Gentoo's package managers skipped checking the UnrealIRCd source code from a secondary server against the known good MD5 hash from the primary server before packaging it for Gentoo they affected the security of a single distribution. As of yet, I've not seen reports that any other production version of a major distribution was affected. One single repository would have introduced this vulnerability into all distributions. Welcome to Windows, where would you like your 'sploit to go today?

Should Ford's dealerships to sell and support Toyota's cars too? I mean, this multiple dealerships for multiple car manufacturer's is just nuts isn't it?

In terms of adding and removing additional repositories; again, it's something that depends on the distribution. Why do you have her self-managing a distribution focused on more advanced users? Why don't you simply add the repository entry for her by physical presence or through a quick ssh login?

Even still, Debian's sources.list file is pretty easy to update but there's nothing stopping Debian or anyone else from providing repositories in a way that automates the addition. Maemo does just this actually. Third party applications can add there own repository to the list with user consent. Repository entries can also be added as a simple file download. One website provides a list of repositories; select the ones you want by checkbox and have them all setup at once. Don't blame the repository system for how a distribution manages addition/removal of entries. (yet another way distributions differentiate)


Versions of programs are not the latest and greatest (Debian Stable), consider a distribution that provides more bleeding edge with resulting less stability (Ubuntu forked from Debian Testing/Unstable branches).

Yeah, good luck explaining that to the average iPhone owners. This kind of bullshit is EXACTLY why Linux on the desktop never gained any significant marketshare.


First, why is one explaining Debian's repository setup to an Iphone user? Is understanding osX setup now required for Windows users?

Second, Debian focuses on security and stability over having the latest immature software version number. The offer an opt-in for non-free code. How is that bullshit? Products should not value goals related to there target use? If having the latest version number is your preference; pick a distribution that markets itself on being bleeding edge. Go play with Fedora where instability is considered a feature.

I get stable and more secure but slightly older versions without imposing on your preference for the latest possible software version. You get the latest software version without imposing on my preference. We both get update patches. Because of multiple distributions and in some cases, multiple branches within a single distribution; we both win. Both our end user needs are covered; a feature of a healthy market with multiple products within a single category (ie. separate distributions providing there own repositories).

And here's the icing on top; I still get Firefox4 for my html5 requirements and the latest Metasploit with it's most up to date module additions. Both without having to decrease the stability of the rest of my system.

And this desktop market share you mention; would that be the one measured through retail channels which can only understate the true market share of Linux based distributions while overstating the Windows market share by counting Microsoft's licenses sold to stockpiles rather than actually active on end user owned machines? I thought we where talking about technically related attributes of the distribution repository model not retail market metrics.


That is the way it works now, ...


With Google's most recent announcement they've greatly reduced the scope within which a manufacturer can modify Android and still retain use of the brand name. I truly hope it has the desired affect of decreasing the fragmentation within it. It's a big step forward compared to the previous permitted scope of customization.

I'd like to see manufacturers feeding driver code back into the core Android image but can accept a driver bundle flashed in along side Google's firmware image.

I'd like to see more standardized settings management even while allowing different superficial layers for cosmetics. I hear the issue currently is a different way to talk a user through doing things on each different handset that may walk into an organization; sucks for IT support guys.

I'd like to see vendor specific "value add" crapware as an opt-in install rather than a default install the user must then opt-out of by unclean uninstall processes.

I think these things would improve the situation for Android users though my preference for having a more complete traditional distribution will probably keep me on Maemo and Meego provided future hardware is an upgrade from my N900. Stock Debian on a mobile device would probably trump all for me though; Same tool set on all my machines.. oh baby..

Reply Score: 3

WorknMan Member since:
2005-11-13

First, why is one explaining Debian's repository setup to an Iphone user? Is understanding osX setup now required for Windows users?

Second, Debian focuses on security and stability over having the latest immature software version number. The offer an opt-in for non-free code. How is that bullshit? Products should not value goals related to there target use? If having the latest version number is your preference; pick a distribution that markets itself on being bleeding edge. Go play with Fedora where instability is considered a feature.


If someone is considering using Linux as his primary OS, he's probably going to notice pretty quickly that there's more than one to choose from. And when explaining the difference between the different distros, you're going to have to explain what repositories are, and when doing that, you're going to lose 90% of the iPhone users, who know just enough about their iPhones that when they tap the little 'app store' icon, that's where to get new apps and games. Linux needs to work like that.

Of course, I'm sure you would say "it DOES work like that if you choose the right distro". Um, no it doesn't. Let's say Jane and Suzy are Linux users, one running Ubuntu and the other running Fedora. So, one says to the other, "Hey, I just downloaded this cool new game last night... you should check it out!" So the other one clicks on her 'apps store' icon, and the game is not there. Why? Because that particular game is not on her particular repository. THAT is why it is bullshit.

And although it's not nearly as bad as it is on Linux, this kind of thing happens on Android sometimes. When it happens on Android, it's called fragmentation, and is considered a bad thing. But when it happens on Linux, Linux evangelists call it choice, and consider it a good thing.

If you want to make Linux work like the iPhone currently does, you have to start making decisions for people (like selecting a distro) and set it up for them. thereby dictating which apps they're going to have access to, since most of them would never bother to try side-loading in the first place. You asked in your post, why is choice considered a bad thing? Because people don't like to think, and would rather have choices be made for them. And that is what Apple does. I'm not saying that is a good thing; I'm just saying that's the way it is.

Reply Score: 1

jabbotts Member since:
2007-09-06

I see. It's bullshit because you don't care to understand that distributions are separate products from separate organizations. Or maybe you do realize that but prefer to intentionally convolute other's understanding for some self satisfaction you derive from it.

I'll say it again; the Distribution is the Product not what kernel it may or may not be based on. If you install Debian with Hurd or a BSD kernel, it's still the Debian distribution. It doesn't magically stop being Debian because it isn't stacked on top of a Linux kernel. User's don't interact with a kernel, they interact with the distribution; the fully assembled product which happens to include an OS kernel of some form.

What's the difference between your example and Jane recommending a fantastic new game that Suzy can't run because it's not available for osX? If clearly separate distributions should all be one, we should be demanding that Microsoft and Apple merge into one organization and deliver a single OS then right?

We can't have Ford and Toyota confusing the end user by not delivering uniform vehicle specs under a single brand. Demand that those two companies also merge along with anyone else who dares produce a product in the automobile category.

Too much toothpaste to choose from.. what brand model fights tarter, the other whitens teeth. Obviously this can't stand.. demand that those products be merged rather than compete in the same product category.

No sir, the bullshit dictating that separate companies should not be allowed to produce competitive products because they happen to use similar parts in the assembly process.

Yes, when it happens on Android, it's called fragmentation. Fragmentation within the space of a single distribution is the same thing. Fragmentation of a product category produces competitive products under separate brands. It provides value to the end user through healthy market forces. Fragmentation within the space of a single brand dilutes that brand and removes value from the end user by resulting in conflicting products all claiming the same name.

The brand is not "Linux".. the brand is Red Hat or Mandriva or Debian or Ubuntu or Mint or Suse. They may or may not use "Linux" as there OS kernel and to the average user, that's not relevant. Do you really think average users care that Android's java runtime environment happens to sit on top of a Linux kernel? Do you really think Iphone average users care about the BSD back end running behind the runtime GUI the user interacts with? Not really. My wife only cares that she can


If you want to make Linux work like the iPhone currently does, you have to start making decisions for people (like selecting a distro) and set it up for them. thereby dictating which apps they're going to have access to, since most of them would never bother to try side-loading in the first place. You asked in your post, why is choice considered a bad thing? Because people don't like to think, and would rather have choices be made for them. And that is what Apple does. I'm not saying that is a good thing; I'm just saying that's the way it is.


"Linux" not really.. I'm not sure how one would make an OS kernel work like a full distribution being that it lacks the userland and interface which a full distribution stacks on top of a given OS kernel.

A distribution which happens to use the Linux kernel or any other applicable kernel.. sure thing. You've already got Android and Ios doing just that. Those are distributions. It's simply not up to the Linux kernel developers; it's up to the distribution providers who happen to target end users with a repository based software channel.

Folks who don't want to choose between distributions simply won't. They'll take whatever distribution a device happens to come pre-isntalled with. No one cares that Tomtom and Garmin units happen to have a Linux kernel under the hood; they simply use the GPS unit. Do Blackberry users really care what kernel runs on the devices? Nope, and yet it still provides add-on apps. But by your decree, anything that happens to use a Linux kernel should give up it's own development goals and merge into a single distribution. Does that include Android since it happens to use a modified Linux kernel or is it magically except?

Here's the key points:

- Fragmentation of the market by producing separate products under separate brand names is part of a healthy market and provides competitive forces which in turn benefit the end user.

- Fragmentation of a single brand within it's own product is a bad thing because it introduces instability and incompatibilities with no benefit to the end user.

- The Linux OS kernel is not the product, the distribution which may or may not use that kernel is. User's don't interact with a kernel, the interact with the resulting platform assembly which happens to include a kernel. One distribution manufacturer can not impose there product design decisions on another; just like any other product category.

- If it's acceptable for other product categories to have competition through separate products from separate entities. Why is it not acceptable for distributions which happen to use a Linux kernel? Should BSDs be merged into this one mega-Linux distro? Why do Windows and osX get to be separate products within the OS category?

Reply Score: 3

WorknMan Member since:
2005-11-13

I see. It's bullshit because you don't care to understand that distributions are separate products from separate organizations.


At last, one of them has finally understood.

Yes, when it happens on Android, it's called fragmentation. Fragmentation within the space of a single distribution is the same thing.


The following link is a list of custom ROMs for the Droid Incredible (the phone I own):

http://theincrediblelist.com/roms

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.

If you still want to argue that Android is just another Linux distro, consider this:

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:

At the very top, it says:

Amarok is a powerful music player for Linux and Unix, MacOS X and Windows with an intuitive interface.

So if you still want to ask why Linux distros shouldn't be considered as different operating systems (such as Windows or OSX), there's your answer.

Even if Android technically runs on top of Linux, Linux itself is a brand, just like Android or iOS. So you can't claim that all Linux distros are exempt from not needing a unified app store, because after all... they're Linux distros, just like roms that run on Android are Android roms.

On one hand, you're right when you say many products (such as TomTom or Garmin) run on the Linux kernel and are really different entities. But the 'marketing' for most (if not all) of these Linux distros clearly identify themselves as either being Linux or Linux-based, so why would it be wrong for someone to assume that all Linux-based distros should be able to use the same app store/repository, if we also assume that different variants of Android do?

Edited 2011-05-16 02:13 UTC

Reply Score: 2

jabbotts Member since:
2007-09-06


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?

http://amarok.kde.org/wiki/Download

"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 kollide.net 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 Score: 3

jabbotts Member since:
2007-09-06

Now, as for the "for Linux" marketing represntation by indavidual programs. Marketing is all about the ten second catchy sound bite not accuracy.

I've frequently pointed out that "for Linux based systems" or "for Linux based distributions" would be more accurate and just as sesynct since listing seven major distribution names in each marketing line would get tired quickly. You may also notice that it's extremely rare for me to say "Linux" alone when not talking about the kernel specifically and "Linux based distros" when talking about things that are actually common across multiple distributions; specific distribution names when talking about specific distributions. Typing "Linux based distributions" takes a half second longer to type but:

- it provides clarity by indicating that there is more than one seporate product which happens to use the Linux kernel when talking to new or less knowledable users. These seporate products may be interoperable and familiar from one to the other but they are destinctly seporate objects from seporate providers.

- it provides clarity by specifying what distribution is affected when talking about a bug, resulting vulnerability, specific program or other attribute related to a specific distribution. Canonical's configuration choices do not affect Debian or Red Hat so it's an attribute of Ubuntu not an attribute of Debian Stable or RHEL.

In short, it cuts through the bullshit of intentionally confusing seporate products into a single thing which really only benefits people more interested in disparaging what they don't like rather than discussing actual technological attributes it.

Now, where it does make sense to intentionally talk about "Linux" instead of specific distributions or "Linux based distributions" indicating the greater family of seporate products:

- when discussing kernel bugs or vulns that indeed affect a majority of distributions by result of that shared kernel version

- when discussing drivers which are included into the kernel as modules. Yes, hardware can be "Linux ready" because it's using industry standards, already provided a driver through kernel.org or provides a third party kernel module for installation.

To get back to your specific given example; do you really think the majority of average users start from amarok.kde.org and work there way backwards into installing it? I honestly don't. My experience has been that most average users find Amarok or some other media manager installed by default and stick with it (ie. "don't want to think. Want vendor to make the choice for them" in your words). If not installed by default, most average users would find it in the package manager and install it from there. They may see it mentioned on chat forums or when talking to friends with "so, how do I install this?" followed by "check your add/remove software" or a specific simple command for the package manager. Heck, I'm an advanced user who infact chooses to install Amarok and this is the first time I've ever had reason to visit the Amarok webpage rather than simply pull it from my distribution's repository.

Generally, confusion over software and installation comes from this "Linux is all one product" crap that does not reflect reality (and fair enough for those who didn't know and are open to considering clarification; a more clear understanding is possible for them) and, users coming from a Windows background who have only ever seen software provided seporately from the Windows distribution. For them, again, clarity is possible; point them to the GUI package manager, let them use the browse or search functinos and it usually ends with "really, it's that easy.. and all this software is just there available for me to use?"

Lumping anyting that happens to use the Linux kernel together to misrepresent it as a single product from a single vendor supports someone's personal agenda and usually one based on bias except in the rare cases where the focus onf the topic actually applies across the majority of Linux based products in a category. Recognizing the difference between distributions when talking about seporate distributions regardless of what kernel they may or may not use supports clarity and understanding of the topic giving a solid basis for productive discussion.

Yet still, I don't get what this discussion of branding, marketing language and Android versus other Linux based distro stuff has to do with the original topic regarding benefits of a repository distribution model and that the "app store" is clearly just a branded repository system. It's not about proving general purpose Linux based distributions better or worse than the Android distribution. My only reason for mentioning it originally was to clarify that repositories are distribution specific and often one of many differentiating attributes of a given distribution along with pointing out that one organization does not have control over how another seporate organization chooses to manage it's repositories.

At this point, I really don't expect you to change your opinion and I don't see evidence to the contrary of my opinion so it seems we're at an empass and should agree to disagree. Hopefully reading through both sides of the thread allows other's to make a more informed decision about there own opinions and understanding of the topics.

Reply Score: 3

patrix
Member since:
2006-05-21

Repository:

- the OS/packaging group assembles the apps, compiles them, tests them, etc, and distributes them

App Store:

- the app developers submit their own apps to the app store

#1 is good for consistency (most of the times), while #2 is good for availability (users don't have to wait/hope/pray for the OS/repo people to package an app they want but isn't available).

Reply Score: 3

Vanders Member since:
2005-07-06

Repository:

- the OS/packaging group assembles the apps, compiles them, tests them, etc, and distributes them


For your distribution upstream repository, sure. There are lots of non-distribution repositories, though, and users can easily add those third party repositories. It's easy to build your own repository, too.

Reply Score: 3

emilsedgh Member since:
2007-06-21

In FOSS repository model, app developers could also 'become' a part of upstream.

Many software developers, also maintain packages of their own software on their distro of choice.

Reply Score: 2

jabbotts Member since:
2007-09-06

On the repository side, one can have the best of both worlds.

Debian's standard repositories for stability and consistency; Main, Contrib, Non-free.

Plus

Third party repositories for developer managed packages (availability); Webmin, Mondo Rescue, Firefox 4 (iceweasel 4) and so on.

Subversion or similar methods can provide developers with a way to ship distribution neutral programs also if it's something like Metasploit that benefits from having the latest additions and isn't targeted at user's who'd have any issue using svn or scripting it into a system wide update process.

In general, the first two options, distro and third party repositories, can easily cover average user needs.

I'd also suggest that App Store style repositories could stand to deliver more consistancy. Something between Apple's heavy handed but staff and business strategy limited system and Google's easy to exploit wide open system.

Reply Score: 3

toomuchtatose Member since:
2011-05-15

My opinion that multiple repositories (such as free, contrib, non-free) is non-consequential to the lay customers, the target Appstore is suppose to service.

Most "repository" related suggestions fail to take note that multiple repositories only serve to increase distro fragmentation and loss of customer mindshare. The is one of the reasons why Linux desktops for the masses fail to take off.

One also should not assume that commercial vendors and software developers are capable and ready to maintain multiple repositories (if they want to, in the first place).

As of now, application distribution is best provided via standardisation and formalised application store logic. Following the path of least resistance, customers with exceptional demands may get additional "application fixes" via manual sideloading or "informal" repositories (e.g. kinda like PPAs for ubuntu)

Reply Score: 2

jabbotts Member since:
2007-09-06

So consider a distribution like Maemo where additional repositories are setup automatically by applicable applications or easy "click here to add" links. Both you're points of concern are still covered. Availability is not exclusive to the app-store single repository model.

I also don't see how multiple repositories within a distribution causes grief since they appear as on consolidated library through the package manager. How should a distribution manage core and third party software? Because Debian favors libre source, it shouldn't provide any method for users to opt-in such as adding the non-free repositories? Doesn't that further limit the user rather than support them?

The distribution is what is garnering "mindshare" not it's repository branches. It's not a non-free repository plus stuff, it's a distribution which also provides a non-free repository. It's not a kernel plus stuff, it's a distribution which happens to use the Linux kernel.

Commercial vendors and developers also don't need to maintain distribution specific repositories. They have the option to work with distributions. They have the option to target parent distributions and let the child forks inherit the software. They can hire or sponsor package maintainers; probably cheaper than managing a repository server and packaging process per distribution. Work with the upstream where possible. Provide source code that distributions can build packages from. Heck, provide binaries that install cleanly across several distributions like Nvidia does.


As of now, application distribution is best provided via standardisation and formalised application store logic.


But that's exactly what the repository is providing. "App store" is just a re-branding of the same repository mechanism; a library of software installed, updated and uninstalled through a centralized manager. How software submission is managed, if one can add secondary repositories or if one can directly download and install individual packages does not change this.

Download from a Maemo repository. Add and download from a secondary repository. Have downloaded apps install there own repository. Install apps completely separate from a repository. It's already happening; the user can enjoy the best of both benefits (the distro management and the developer's latest update availability).

Reply Score: 3

v.alexeev
Member since:
2008-02-05

Platform owners could not care less for outraged software engineers as longs as 20% of the apps brought in by major names bring in 80% profit.

On the cut — do the math, you're an engineer. Imagine you take the same cut off your app's selling price and do the shop and marketing on your own. Good luck with business development budget of 2% out of $0.99!

Do not forget why you are creating the app. It is not to show off, right? It is to serve a certain purpose for the end user, I assume.
Do not forget you aren't the only brilliant mind who can think of that particular app's idea. You really are not. Awesome app ideas and code hackers are dime a dozen now, look at all the app conferences.
Do not forget that in 99.(9)% of cases end users do not remember the name of the company or individual writing the app.
Do not forget that end users rarely, if ever, will give a praise to the author. But they will take every chance they have to vent their frustration with bad service. When was the last time you've sent a "thank you" letter to police chief for fantastic traffic cops' service? When did you rant last time over a beer when you got the ticket for speeding?

You will dictate the new app world order when you invent another platform that instantly catches 50M — 100M — 150M end users. Get over it. You weren't at the top of the hill when it happened. You may, next time.

Edited 2011-05-14 17:27 UTC

Reply Score: 6

JAlexoid Member since:
2009-05-19

30% is an OK cut. Considering that both Apple and Google are running all the infrastructure. And Apple needs to employ people to do the reviews.

In any case, anyone starting a business around sales of a mobile app is crazy. That train has left and has already been derailed.

Only mobile application development services is a making money these days. And even there, hope that some tel.co decides to bundle your app with a launch of their new phone or some company needs an app to support their marketing campaign.

Reply Score: 3

Alfman Member since:
2011-01-28

JAlexold,

"30% is an OK cut."

Although I agree with all your other points, 30% is certainly not a competitive rate.

I'd be willing to bet that large swaths of developers and users would gladly switch to alternate sources if they weren't bound by DRM (those that jailbreak do have underground sources, obviously). This is precisely why apple chose to go with a walled garden.

Reply Score: 1

JAlexoid Member since:
2009-05-19

Well it can't be competitive, when it's in a monopolistic market. But in reality, 30% is the rate that hit the sweet spot. Prior to that other online software outlets had a 40%-50% rates.

Reply Score: 2

Alfman Member since:
2011-01-28

JAlexoid?

"Well it can't be competitive, when it's in a monopolistic market. But in reality, 30% is the rate that hit the sweet spot. Prior to that other online software outlets had a 40%-50% rates."

Citation requested.

Edited 2011-05-16 14:35 UTC

Reply Score: 0

JAlexoid Member since:
2009-05-19

Sooo... How many NDA's do you wish me to break?

Reply Score: 2

_xmv Member since:
2008-12-09

Actually he/they were. Except he/they decided not to be evil and to make it free. And it was called a Linux distro.
Evilness = success. Thanks for the tip, although I knew that one already.

Reply Score: 3

v.alexeev Member since:
2008-02-05

Forget about evilness — it is real life, not a comic book.

If your success was to get karma then, well, you can make it free and earn respect. But do not whine when you are not getting valuables in return.
If your success was to make a profit you focus on very different things. AppStore owners ain't exactly charities, are they?

Reply Score: 1

App Store are one form of DRM
by dvhh on Sat 14th May 2011 18:02 UTC
dvhh
Member since:
2006-03-20

Although less obtrusive, they are one form of controlling the installation on one device by one user.
They mostly include every attribute of a DRM:
- deeply entrenched in the host system
- link a user to a licence (you buy a licence to use the app not the app itself)
And because they appear as transparent DRM, user accept them easily. However if the appstore retire from the market (that will eventually happen one day or another, because the onwer went down or the device is considered obsolete to run its evolution), the device user is on its own.

Reply Score: 3

"0install: the antidote to app-stores"
by Tom5 on Sat 14th May 2011 18:27 UTC
Tom5
Member since:
2005-09-17

Interesting. 0install recently switched to the tag-line "the antidote to app-stores":

http://0install.net

Still trying to work out whether users still see "app store" in a positive light or not.

Edited 2011-05-14 18:27 UTC

Reply Score: 2

Limitations are what make the platform
by RichterKuato on Sat 14th May 2011 19:09 UTC
RichterKuato
Member since:
2010-05-14

I don't think most users have problems with App Stores.
Just like most gamers don't have a problem with developers having to get licenses from console manufacturers. The problem is mostly from the developer's side.

Reply Score: 2

Alfman Member since:
2011-01-28

RichterKuato,

"I don't think most users have problems with App Stores."

First, I agree with you that (monopolistic) app stores are certainly irritating to developers, particularly when they force users into a single store via DRM.

As for users, it can also be an irritation when other party dictates what you can and can't do with your own device.

Using apple as an example: it is one think to accept apple's terms for oneself, it is another to buy the line that apple's walled garden is in user's interests. There is no denying that apple is using DRM to eliminate competition and functionality.

Why can't we install our own apps? Why shouldn't we have java? Why shouldn't users be allowed to use open source apps? Why can't we run emulators? The answer, which is plain to anyone not under the RDF, is that apple is afraid that its customers would embrace other sources if they weren't blocked via DRM.

The jailbroken iphones, in spite of apple's disapproval, are evidence that demand does exist for software outside of apple's grasp.

Edited 2011-05-14 20:58 UTC

Reply Score: 2

viton Member since:
2005-08-09

an irritation when other party dictates what you can and can't do with your own device.

Please, stop spreading this mantra everythere.

Hardware is yours, but software is NOT. It is under license. Only if you write YOUR 100% OWN FIRMWARE, you may say what the entire working device is actually YOURS.

App Store ISN'T YOURS. Also the pirated software you installed is NOT YOURS.

Reply Score: 2

App stores...
by bert64 on Sat 14th May 2011 22:09 UTC
bert64
Member since:
2007-04-23

Finally another problem that gets serious over time is the amount of available applications. All the top spots are taken. Even if you have a great application, your marketing options on the application store are fairly limited. Well established applications will keep on selling even though better alternatives might exist.


This happens already, even without app stores... People already look for the popular apps and don't even consider looking for anything else. At least with a well designed app store model, the system could recommend similar apps. So you search for the popular one, see it costs $50 but there are some similar apps for $5 or free with decent reviews...


The interesting part about the app store, is that it proves at least one of the "linux is not ready" arguments wrong. Search for any such argument written more than a couple of years ago, and one of the points given against linux will invariably be that users cannot buy boxed software in physical stores for linux.
I have long held that the linux repository model is far superior, and that users would love it if only it was promoted properly... Now Apple have come along with a slightly cut down version of that model, promoted it heavily and it's been a huge success. Now think what *could* have been if the early linux netbooks had come with better linux distros, linked to decent software repositories and sufficient marketing to show people the benefits of them.

Reply Score: 2

RE: App stores...
by Alfman on Sat 14th May 2011 23:40 UTC in reply to "App stores..."
Alfman Member since:
2011-01-28

bert64,
"I have long held that the linux repository model is far superior, and that users would love it if only it was promoted properly... Now Apple have come along with a slightly cut down version of that model, promoted it heavily and it's been a huge success. Now think what *could* have been if the early linux netbooks had come with better linux distros, linked to decent software repositories and sufficient marketing to show people the benefits of them."

You make a lot of good points. However most consumers will follow the media hype rather than go with the best model.

The best model for consumers is clear. Owners should be free to install whatever they choose. They should be able to go to the app store of their choosing, or even download software directly from developers. Security should be accomplished via sandboxing rather than DRM.

Security configuration should be controlled by the owner, or a 3rd party "security delegate" of their choice. This delegate would set the security policies over individual applications. Unknown or malicious apps would be limited to the sandbox. The security delegate might even disable malicious apps. However since their control is elective and not imposed, this isn't a problem.


Owners who don't want to think about anything win.
Owners who want full control win.


Although this model is superior for consumers in just about every way. Vendors like apple don't want to sell devices which open themselves up to more competition.


Edit: Linux can come close, but I wish it had more out of the box sandboxing capabilities (without dedicated user accounts or virtualization).

Java web start was a good a good implementation of what I am talking about, at least before microsoft killed it.

Edited 2011-05-14 23:48 UTC

Reply Score: 3

HTML5/web apps
by Lennie on Sun 15th May 2011 00:48 UTC
Lennie
Member since:
2007-09-22

There are only 3, maybe 4 advantages to apps/appstores for smartphones:

1. obviously: distribution channel
2. native applications have some access to system-specific API's
3. immediately fits into the ecosystem (think UI-toolkit)
4. maybe performance

Creating apps based on webtechnology has these advantages:
1. your app code can be reused for different platforms, even websites or on the server (node.js anyone ?) A browser extension ? A new platform ? ChromeOS ? sure, no biggie.
2. your app can easily be scaled to different screensizes
3. you can still make use of the native API's with the use of appstore-friendly apps with an advanced-version of an embedded browser, like PhoneGap or similair
4. you don't have to wait for the app store, you can just update your code on a web-domain and the HTML5-application will automatically download an update as a whole. All files are downloaded and cached before the first time the application is started (if not installed already with PhoneGap or similair).

And most professional developers of apps and companies who let them build apps for them have already figured out: let's not develop our app 2 or 3 or 4 times, but let's base it on webtechnologies and just build it one time.

Some companies build business apps. With app-store policies from Apple it takes hours up to months to get updates through the system. If there is an issue for a customer, you can't wait that long. Especially if you can't get a good description of the issue, you'll have to go through the whole process again if it does not fix the problem.

Reply Score: 3

wiki app store
by Tanner on Sun 15th May 2011 14:07 UTC
Tanner
Member since:
2005-07-06

What about a wikipedia-like model of mantaining one single app store?

The userbase ratifies and manage the apps in one single place, let it be centralized or developed like a P2P under the hood, who knows...

Reply Score: 2

RE: wiki app store
by danieldk on Sun 15th May 2011 16:16 UTC in reply to "wiki app store"
danieldk Member since:
2005-11-18

It is to prone to the injection of malware. Most Linux distributions work with trusted application maintainers. Such barriers are put into place to avoid that random people can violate the security of the system. The packages come from a trusted source.

The difference with Wikipedia is, that it does not hurt too much if nonsense persists on a Wikipedia page for an hour, a day, or even a week. If you have to rely on such information, you can do extra fact checking. Having malware for such a period can be detrimental to a huge amount of systems. An 99.9% of the users do not have the time or knowledge to check the validity of software, even more when it is only available in binary format.

Reply Score: 3

Comment by Luminair
by Luminair on Mon 16th May 2011 03:13 UTC
Luminair
Member since:
2007-03-30

we know the end game of mobile app stores because we know the end game of desktop app stores. the end game is that download.com doesn't make 30%. lets start with that

Reply Score: 2

Security in the application
by wocowboy on Mon 16th May 2011 10:40 UTC
wocowboy
Member since:
2006-06-01

The author touched on security only in his discussion of the Application Store itself, never mentioning the subject of security in how it relates to the applications themselves. Apple is fanatical about making sure the apps that pass through App Store work as they are supposed to, do not contain malware or viruses of any sort, and that they do not pose any risk to the customer's phone or computer. This policy has caused many apps to be rejected and brought great hue & cry from developers who have been lauded on this site as well as others, when in reality they should be facing serious questioning as to why their app contained said malware in the first place.

The Android system has none of this protection built into its app store per se. The Android Market does not vet apps for all the above mentioned bad stuff, they make a point that it is open to all, come and sell your product, we will not test your app for viruses or malware at all. I don't know if the Amazon App Store does it or not, but there is absolutely NO assurance to the customer that ANY app they get from a website or file-sharing site has been tested and can be guaranteed that it will not brick their phone or send information about themselves unknown to them, the instant they install it on their phone or computer. This is a VERY serious risk that is not even addressed once in this article, and is in my opinion the very top reason the Apple App Stores are so successful.

There have been Android apps that have had viruses and malware in them already, that have caused problems with people's phones. To my knowledge there has never been an iPhone app that contained malware.

Edited 2011-05-16 10:50 UTC

Reply Score: 1

RE: Security in the application
by patrix on Mon 16th May 2011 14:40 UTC in reply to "Security in the application"
patrix Member since:
2006-05-21

yes there have been some iphone app store apps that contained malware.

As for Android, they require your permission (granted at installation time) to access any bit of data or functionality, the problem being that most people don't bother understanding the permissions, and that most of the cases of Android malware have come from third-party sources rather than the android market - ie, sources where software was pirated, cracked (to be free rather than pay 0.99$ or whatever), and injected with malware... and installed at a user's risk and peril!

Reply Score: 1

Comment by EULA
by EULA on Tue 17th May 2011 03:13 UTC
EULA
Member since:
2011-05-17

This article is little more than rehashed anti-Apple freetard fluff. Let's start with this gem:

"While this decade seems to be based on distributed systems/clouds and open standards, the application store is essentially a step backwards."

You seem to have completely misunderstood the "cloud" trend; it is, in its most basic sense, the delivery of content and services to users via a thin client (such as a Web browser). The delivery process itself is opaque; this is why the complex nature of the Internet has been condensed into a picture of a cloud. This is why the details behind Google's data centers are kept secret.

Just because the front-end of the cloud architecture is based on open standards does not mean that the market must be vast, diverse, and decentralized. On the contrary, it is already quite clear that only a handful will dominate -- among them Facebook, Google, Apple, and Amazon -- with that number only shrinking as time goes on.

For all of the innovation pioneered by Linux package managers, it was irrelevant in the consumer space precisely because it was limited to a tiny sliver of Linux users. The fact is that Apple was the first company to turn the concept of a centralized software distribution channel into a significant commercial success.

Is this centralization a cause for concern? No more so than it is in the case of Facebook and Google, both of whom collect untold amounts of data about you and are explicitly in the business of selling that data to advertisers. How is it that Apple is always singled out from the rest? Is it because it has greater public visibility? Is it because nerds consistently turn a blind eye to Eric Schmidt's flagrant disregard for personal privacy?

Honestly, whining about the App Store is probably the last thing that should be on your mind as a technology writer. No one is saying that the process is perfect, and it will inevitably get better over time, but one aspect that will not change is centralization. It's not an Apple problem; it's an industry problem. You either start calling everyone out on it, or you go back to analyzing the newest Linux process scheduler.

With the exception of the last one, your "predictions" are laughable.

P.S. Suggesting that iOS users are under an imminent malware threat is either pure delusion or intellectual dishonesty. Write something when you have real evidence, rather than uninformed speculation and scare tactics.

P.P.S. If you really need your porn fix on iOS, you have the entire OPEN Web at your fingertips.

Reply Score: 1

Fanboyism
by renox on Tue 17th May 2011 08:28 UTC
renox
Member since:
2005-07-06

Sigh, the author of this articles suffer from a bad case of Linux-fanboyism..

It's simple really: app-store only matter once you convinced an user to have a platform (PC, PDA, smartphone) which can use this app-store.

Linux-distributions have interested only a small number of users on the PC, so who cares that they had an 'app-store' first?
Only the tiny number of Linux users.
So apparently these Linux distribution 'app-store' weren't enough to drive a big number of people to use Linux instead of Microsoft..

Reply Score: 2