| |||||||||||||
Quotes of the weekQuotes of the weekPosted Mar 22, 2012 18:13 UTC (Thu) by khim (subscriber, #9252)In reply to: Quotes of the week by nim-nim Parent article: Quotes of the week
On all the other platforms, app writers have to follow strictly the deployment rules of the platform owner Wow. Just… wow. How many programs have you actually written for other platforms? Yes, there are extensive guidelines, but… they are optional. You only must follow them if you expect to receive some kind of promotion or approval (even so one of the programs which I've written was featured on microsoft.com about 10 years ago despite the fact that it violated tons of these requirements: it patched Windows kernel on-the-fly, for example). If the program works today then it's expected to work tomorrow. The infamous SimCity allocator is not an isolated incident. Remember SETVER.EXE? Or 16bit stubs? When Microsoft found out that a lot of installers for Windows XP are built with 16-bit stubs (in violation of all guidelines!) instead of issuing the memorandum with damnations for all the vendors it added large collection of 32-bit stubs to Windows x64 - they are transparently used instead of files from CDs. Sure, in some cases programs are still broken and need patches but the general rule is simple: if program is written for version X it must work for version X+1 and OS creator should do whatever it takes to ensure that. Vendors are involved in rare cases. On Linux they complain of the distro policing but are unable to police themselves Why should they? It's not their responsibility. Their responsibility is to create something to delight users, not something to delight OS creators. OS is just an obstacle, it should interfere with primary task as little as possible. Other platforms are more successful in great part because the platform owners don't give app authors the option to whine and drag their feet. Meaning… what exactly? It's Jobs' (or Bill's, or Larry's) way or the highway. Oh, you mean WP7? Sorry, but this idiotic, brain-dead fiasco happened long after departure of Bill. That's why market share of said pitiful OS now contends with market share of Linux desktop. As for the case when Android broke bunch of applications and it was not perceived as severe bug - I'd like to see that. Among successful platforms the one which does radical turns most often is MacOS - and that means that old applications (yes, even the ones which violate guidelines) are supported for five years (not for 10-15 like on Windows). This is one of the reasons for why it's less popular then Windows :) Compare with Linux where version X+1 can easily break applications written for version X without any regard or tools which try to ensure backward-compatibility (tools offered to end-users, mind you, not to developers… developers made working programs some years ago, now the ball in OS creator's court).
(Log in to post comments)
Quotes of the week Posted Mar 22, 2012 20:21 UTC (Thu) by anselm (subscriber, #2796) [Link] Wow. Just… wow. How many programs have you actually written for other platforms? Yes, there are extensive guidelines, but… they are optional. Tell that to the iOS app authors. Their programs may not end up in the app store because the people in charge don't like them for whatever reason, like being too similar to another program that Apple wrote. There's nothing »optional« about the guidelines there – either you comply, or you can go jump into a lake. Who do you propose should do that sort of enforcement in the Linux community?
Quotes of the week Posted Mar 22, 2012 20:35 UTC (Thu) by khim (subscriber, #9252) [Link] Tell that to the iOS app authors. They know that much better then me, I suspect. Their programs may not end up in the app store because the people in charge don't like them for whatever reason, like being too similar to another program that Apple wrote. Sure. Or they may end up in store even if they clearly violate rules. For example there are a lot of Unity-based games in AppStore - and Unity it built around Mono, which is big no-no according to Apple's rules. There's nothing »optional« about the guidelines there – either you comply, or you can go jump into a lake. Sorry, but no. The only rule here is: create something Apple will like. You may comply with all the formal rules and Apple will change them under you (see B&N and Kindle apps) or you can blatantly violate rules and Apple will keep your app in the store (see aforementioned Unity or any other ported app not written initially in the “approved” language). Who do you propose should do that sort of enforcement in the Linux community? Noone. There are other platforms which don't play Apple's power games which are more popular thus obviously these games are not needed for the success of the platform. Stable ABI which is supported for many years, on the other hand, is strict requirement.
Quotes of the week Posted Mar 22, 2012 22:59 UTC (Thu) by drag (subscriber, #31333) [Link]
The take away lesson here for Linux distributions from the example set forth of Apple iOS and Android is that they should exist to make it easier for software authors to reach out to end users and visa versa.
Sure Apple sucks and Google sucks and blah blah blah. But it's irrelevant to this discussion really.
The sole purpose of the OS to run applications. THAT IS IT. It is a abstraction layer that takes as much as the work away from writing applications as possible. This is to make applications cheaper to write, faster to write, and easier for users to use.
Package management is fantastic. Android uses it and iOS uses it far and away much more successfully then Debian/Gentoo/Redhat/etc etc. could ever dream of. They took the Linux example of distributions, software packaging, and using tools embedded into the OS to download and install software and successfully made it work on a scale that dwarfs all the effort of all the Linux distributions combined.
And they did it in a vastly shorter amount of time.
On my Debian system I did a rough count:
$ apt-cache pkgnames|grep -v dev|grep -v doc|grep -v lib|wc
So about 19610 packages or so. How many of those are actually useful programs as opposed to just some application divided up into 3 or 4 different packages?
Maybe 15000 actual individual applications?
With Apple iOS you have 500,000th program approved last year.
Android should be up to about 425,000 packages nowadays.
Even if I do include all the dev, lib, and doc packages that Debian offers me I still get less then 40,000. Nokia's OVI store does more then that and it's a package system for a dead operating system.
And, yeah sure, Apple has advantages and more money and all that crap, but they have built a system that is able to package and manage 100s of times more software then any Linux distribution can do, and with probably a fraction of the people that actually manage their repositories.
100x's of times more applications. 1000x's of times more users.
Debian is the biggest and the baddest Linux distribution there is in terms of actually being able to manage and package software and they are so clogged with such politics and bureaucratic processes that they can barely function and implement improvements. And bless them. I love them for the work they do, but it's a HUGE amount of work. It's a HUGE amount of work that every other Linux distribution has to completely duplicate in almost in it's entirety to just reach the same level. Just for the sake of doing the exact same thing in a slightly different manner with almost all the same software.
I don't necessarily want a half a million packages from Debian. Probably nobody really wants to just have massive numbers of packages like that, but they want lots and lots of good software for all sorts of different purposes.
But there is no way in hell that I could see Debian getting up to 150,000 or 200,000 individual applications. Their organization couldn't even come close to coping with it, and they are far more able and far more capable then any other Linux system out there.
Everything needs to be distributed when humanly possible. Duplicated work, duplicated effort is wasted effort. Packages should be built and signed by application developers. When Debian uses Gnome it should be the same Gnome packages that Gnome provides for Fedora or Redhat or whoever else. When they use Firefox they should be Mozilla's executables that they built themselves. Same way with Chrome, same way with all the other software. Vim from Vim, Emacs from Emacs. etc etc.
Distributions should gather the packages and mentor and provide guidelines for application developers and make it easy to manage the applications using proper package management tools for end users. This can't work now, but it can be made to work. Barriers that are present to distributed package system are big, but can be overcome.
If Linux is ever going to move past were it is right now it needs to happen.
Quotes of the week Posted Mar 22, 2012 23:52 UTC (Thu) by anselm (subscriber, #2796) [Link] 100x's of times more applications. 1000x's of times more users. Right. But how many of those 500,000 »applications« are really glorified web bookmarks? The problem is really that Linux is a culture of open source software. That is, most software is provided by its authors in source code – with an understanding that whoever wants it will have to go to the trouble of compiling it themselves, the way everyone did (and had to) when we were still using any one out of two dozen Unix variants in the 1980s. This used to be, and still is by many, considered a feature. Distributions came about for Linux because people thought it a good idea to save the public at large the hassle of having to find and compile everything themselves. Again, not necessarily a bad thing. However, the basic Linux ecosystem is still based on source code, which means that every application author feels free to use whatever library they fancy whose source code is available – and as it is usually not a big problem to recompile, or to provide several versions of the same library, if you're installing everything from sources anyway, this only becomes an issue if you're a distributor trying to keep your distribution stable for some time. With Windows and OS X and iOS and Android, this is much less of a problem in practice since the culture is traditionally based on binaries and casual recompilation is not an option. Also people tend to have to pay large sums of money for their software, and they reasonably expect that their software will keep running for a while (not that that always actually works out). This makes ABI stability a much more important proposition for the proprietary OS vendors. In effect, what you seem to be proposing is to establish a standardised Linux ABI that third-party app developers can write their code against and that will stay the same over an extended period of time. This has in fact been tried in the past under the auspices of the »Linux Standard Base«, or LSB, and didn't really get anywhere in practice. On the whole, those vendors who were into binary distribution tended to certify their software for RHEL and SLES instead, while most of the software from the community, which was only published in source code to begin with, ignored the issue altogether. Also there were various important areas where the authors of the standard didn't appear to be able to obtain a consensus, and that were left unspecified. This is a situation where a system like Windows or iOS, which is produced by one single company, is at a big advantage compared to something like Linux, where if Red Hat says »black« and SUSE says »white« there really isn't a lot one can do. It is clear that the status quo leaves something to be desired. It is not at all clear what ought to be done to provide an infrastructure that would actually be able to carry a significant number of third-party applications which would work across the major distributions. We have seen that something like LSB doesn't seem to cut it, both because it appears to be impossible to come up with an ABI standard that people will agree on and that is at the same time broad enough to cover what people actually need to write interesting programs, and because the application developers, by and large, do not appear to be all that interested in the first place. So what else can we do, or what could we do better? It is easy to complain that Linux is going to the dogs, but less so to come up with concrete, constructive proposals to fix this – especially since that sort of thing would need a vast amount of buy-in both from distribution makers and the community at large to get off the ground.
Quotes of the week Posted Mar 23, 2012 3:37 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
Linux has nice ABI where it matters - at the kernel system call level. It's excellent and comparable to quality with Windows ABI.
However, everything else is bad. The culture of having packages spread out across many directories ensures that application vendors have to either deal with inconsistencies of naming or say 'screw it, I'm packing everything above glibc'.
Then there's a problem of consistent naming and versioning. And then there's a problem of inability to install several versions of one package.
Quotes of the week Posted Mar 23, 2012 9:41 UTC (Fri) by anselm (subscriber, #2796) [Link] Please explain how being able to install several versions of the same package will deal with the problem of third-party app developers not knowing which distribution to target. (I was under the impression that Debian-based distributions, at least, have no particular problems with concurrent major versions of the same libraries being installed. This of course presupposes suitable discipline on the part of the upstream library providers as far as versioning is concerned. History shows us that, at least for some libraries, the record is less than stellar.) It would certainly be a good thing to have more cross-distribution standardisation for the benefit of third-party app developers but experience with the LSB effort tells us not to set our hopes too high. The only real way to fix this seems to be to essentially get rid of all Linux distributions but one, and you know how likely that is to happen. Finally, I would like the whining to stop and to hear some actual constructive suggestions.
Quotes of the week Posted Mar 23, 2012 11:17 UTC (Fri) by hummassa (subscriber, #307) [Link]
Debian-based distros do have somewhat consistent naming and versioning policy, at least...
Quotes of the week Posted Mar 23, 2012 14:14 UTC (Fri) by khim (subscriber, #9252) [Link] It would certainly be a good thing to have more cross-distribution standardisation for the benefit of third-party app developers but experience with the LSB effort tells us not to set our hopes too high. LSB was and is hopeless because it does not give well-rounded set of APIs. It does not explain how to add your application to “start menu” or show a notification message. As I've already explained it's still does not include audio API! And even if your application belongs to a tiny subset of applications which are buildable with LSB… Sure, you can create LSB-certified .rpm, but what's the next step? “Joe Average” (who will happily install anything to see the dancing pigs) is not yet on Linux and existing users are trained not to install random .rpm's from unknown source. LSB was and is waste of resources. It can probably be fixed, but I fear by now it's too late: desktop developers have abandoned UNIX (and Linux) long, long, long ago. Finally, I would like the whining to stop and to hear some actual constructive suggestions. Well, the high-level list is easy:
But then you need detailed follow-up. Something like this: Problem: distributions don't have a fixed release schedule thus it's not possible to introduce new ABIs (demanded by application developers) on timely basis. Problem: your new scheme will not be used by developers unless you promise millions of users and users will not install it if you'll not give them thousands of applications. Problem: applications designed for Android and/or Chrome look and feel “alien” on a Linux desktop. The recipe, in principle, is well-known, but for some reason is not followed. All the efforts try to enforce strict rules on developers before they have any developers and before they have any leverage over said developers! This will just not work for obvious reasons. Linux desktop had window of opportunity 10-15 years back when it was probably possible to create such an ecosystem (when Unix workstations were common and a lot of desktop developers had UNIX experience), but it was wasted because of “all the software must be in your repository” attitude. That's why I suggest using Google Play Store and/or Chrome Web Store to jumpstart the efforts.
Quotes of the week Posted Mar 24, 2012 12:45 UTC (Sat) by anselm (subscriber, #2796) [Link] Linux desktop had window of opportunity 10-15 years back when it was probably possible to create such an ecosystem (when Unix workstations were common and a lot of desktop developers had UNIX experience), but it was wasted because of “all the software must be in your repository” attitude. The problem at the time was that there was no widely accepted »look and feel« for Unix/Linux desktop applications (there was CDE/Motif, of course, but the development side of that wasn't freely available). The KDE project was the first credible attempt to provide a free desktop environment, but then of course the GNOME people absolutely had to come up with their own system because they positively could not stand the idea of a desktop environment based on C++ and Qt. From a standardisation POV it would have been great if that could have been avoided but that is unfortunately not the way the FLOSS community works. As far as the distributions are concerned, it is understandable why a distribution (e.g., Debian) puts a big emphasis on its own repositories. After all, users must trust packages they install with root privileges since most packages contain installation scripts that are executed as root. Hence the idea of pre-vetted package maintainers who are the only ones allowed to put stuff into a distribution's repository, and the idea of encouraging distribution users to rely on the distribution's repository as far as possible. By and large the distributions have done a reasonable job of not spreading packages with malicious code in installation scripts, which would be much more difficult to avoid if users were encouraged install any old package that they found on the Internet. A centralised »app store« for third-party Linux desktop apps would have to aspire to the same level of trust that most distributions enjoy today. Possibly the first thing a cross-distribution scheme for third-party desktop applications should sort out is how to install applications without giving root privileges to untrusted code. Desktop applications usually don't need to place files in /etc or integrate themselves into the boot sequence, so presumably do not actually require root for installation. The Android approach of giving each application its own UID/GID sounds reasonable here. During package installation the distribution would pick a UID/GID and provide a third-party app with a directory below /opt belonging to that UID/GID where it could install itself. There would have to be a way of making new apps show up in the relevant menus (or even /usr/local/bin) but that could be arranged without giving the package in question the ability to execute arbitrary stuff as root. An application could also bring along its own known-working versions of libraries and use LD_LIBRARY_PATH to arrange for them to be loaded (possibly with a way to prefer installed system libraries if these were appropriate), but there would have to be some standardisation to avoid a situation where each app came with its own full version of KDE or GNOME. This could be as straightforward as requiring a particular version of KDE's and/or GNOME's basic libraries to be available (after all, GNOME stuff can run under KDE and vice-versa) and getting the KDE and GNOME people to provide ABI backward compatibility with that version.
Quotes of the week Posted Mar 24, 2012 14:03 UTC (Sat) by khim (subscriber, #9252) [Link] The Android approach of giving each application its own UID/GID sounds reasonable here. Yes, it looks reasonable on first glance, but, unfortunately, in practice it's not enough. Linux kernel is too large and too bug-ridden. It's developers have not actually considered case where people will run potentially-hostile-code locally. Simple UID/GID separation is not robust enough. This means you need additional sandbox. There are many choices: seccomp or ptrace can be used to create adequate sandbox, NaCl offers even more robust one. This could be as straightforward as requiring a particular version of KDE's and/or GNOME's basic libraries to be available (after all, GNOME stuff can run under KDE and vice-versa) and getting the KDE and GNOME people to provide ABI backward compatibility with that version. Yeah, this should be possible, too. Will need some amount of upstream support, but should be doable. If you'll think about it then you'll understand that app stores are all the rage today because they offer two things simultaneously: Traditional distribution model offer only #1 while distribution repos offer only #2. It should be possible to create something like this but then you need to jumpstart it somehow (people will only use it if it'll offer something not available from regular Linux repository and developers will only bother with it when there will be enough users). That's why I recommend not start from scratch but to reuse (and later extend) format of one of the existing stores. P.S. Also note this magic combination existed for 10 years before Apple and Google created their offers. This is how webapps have come to prominence! The only problem with webapps was creation of them: yes, it's easy to deploy the webapp and it's easy to convince user to try one, but it's not easy to write it in the first place! That's why webapps are all the rage on desktop but “meh” on mobile. They are not needed there! And now we have this and this. What does it mean for the future of Linux desktop? Nothing good: pendulum is almost ready to go back and reverse the trend of previous decade WRT webapps. The trend which made Linux desktop somewhat viable in first place (after all if the only program you ever run is the webbrowser then you can as well use free OS to host it and save money). Think about it…
Quotes of the week Posted Mar 24, 2012 15:12 UTC (Sat) by anselm (subscriber, #2796) [Link] It should be possible to create something like this but then you need to jumpstart it somehow (people will only use it if it'll offer something not available from regular Linux repository and developers will only bother with it when there will be enough users). The problem with this is that the present model is obviously »good enough« for the existing Linux desktop users (otherwise they would presumably be using a Mac). It has the potential to make things better for future Linux desktop users but it needs to have considerable momentum to be able to entice these people away from whatever they are using now. It is really the third-party desktop app developers who should be pushing for something like this because they stand to save the most work – at least if they want to distribute binaries rather than source code (I don't hear the distributions complain so far). Right now any FLOSS applications that are of sufficient general interest are usually picked up and packaged by the distributions (at least the big ones such as openSUSE or Debian). So the »distribution-independent desktop app store« concept is of most interest to those applications
This of course raises the question whether we actually want a future that encourages uninteresting desktop apps (out of 500,000 apps in the iOS store, 490,000 or more are probably not all that interesting, either), non-FLOSS ones (I don't really have a problem with this but other people might) or ones that are developed really quickly, which is probably the category where the most people will be able to perceive a benefit. If third-party desktop app developers really believe that Linux distributions are hurting them by not pushing new versions of their apps out to users quickly enough, they ought to get organised behind the »distribution-independent app store« concept, together with the non-FLOSS developers and the developers of uninteresting apps. Don't expect anybody else to take the trouble. (Also incidentally, don't count on Google taking up the slack. Google already has a perfectly viable Linux-based ecosystem – Android – and is otherwise big on moving stuff into the cloud, which is what Chrome OS appears to be all about. As far as Google is concerned, the amount of Linux required on a PC is exactly the amount that is required to support a Chrome browser that can talk to the Internet. They have nothing to gain from unifying third-party Linux desktop app deployment.)
Quotes of the week Posted Mar 24, 2012 18:18 UTC (Sat) by khim (subscriber, #9252) [Link] It is really the third-party desktop app developers who should be pushing for something like this because they stand to save the most work – at least if they want to distribute binaries rather than source code. You forget that they have much easier alternative: just ignore UNIX/Linux mess and try to grab few more users from Windows/MacOS world. Remember the times when large companies produced desktop software for Linux? Remember the times when Linux seen AAA game titles (well, they usually were ported years later, but they were ported)? These times are gone. Small software houses still produce some software for Linux (including games), but if Linux desktop will shrink, not grow… well, they'll leave, too. Right now this is a fairly small proportion of all Linux desktop apps, and so the issue is really not about fixing a current problem but preparing the way for the future. Well, kinda. Have you been on FOSS-related conferences recently? If the fact that Linux desktop is dying is not a “current problem”, then yes, it's “preparing for the future”.
As Ingo wrote: - desktop Linux has started, in relative terms to the rest of the market, losing marketshare. I find it hard to believe how complacent Linux desktop developers are in the face of crisis, when even on Linux conferences there are plenty of MacBooks (and no, not all of them are using Linux - that's just a popular excuse). Well, no, they are not complacent. Not exactly. They react (new GNOME3's and Unity's UI, KDE4's social desktop features, etc) and try to make something appealing for Joe Average in the hope to attract new blood. These are noble aspirations, but without the ability to choose from bazillion applications Mr. Average will go to Apple and Microsoft instead (as I've already noted they finally have gotten their act together and are moving appstore concept to desktop). If third-party desktop app developers really believe that Linux distributions are hurting them by not pushing new versions of their apps out to users quickly enough, they ought to get organised behind the »distribution-independent app store« concept, together with the non-FLOSS developers and the developers of uninteresting apps. Why should they if there are much easier alternative: ignore Linux completely? That's what most of them did. Do we want to see the next Flash or the next Skype only produced for Windows and MacOS? Some desktop Linux developers will join Stallman and say “yes” - and I respect their choice, but some other still try to attract Joe Average to Linux. Without trying to do with support of third-party developers. Guys, come on: this goal is fundamentally incompatible with third-party vendors boycott of the Linux desktop. As far as Google is concerned, the amount of Linux required on a PC is exactly the amount that is required to support a Chrome browser that can talk to the Internet. Bingo. Note that Google is quite serious about ChromeOS. It's not clear if it'll manage to create thriving ecosystem, but at least they are trying. And since apps developed for it use well-known Linux goodies (GCC, GLibC, Qt, etc) it looks like logical successor to the traditional Linux desktop. They have nothing to gain from unifying third-party Linux desktop app deployment. Right. But you forget that ChromeOS is not all that popular right now. If you'll add all Linux desktop users to the list of potential users then suddenly the userbase for ChromeOS-compatible apps will grow considerably. This means that at this point of time it'll be in Google's interest to support such project. Google will definitely not start it (too much hassle, too little gain), but it may support it. If and when ChromeOS will grow beyond it's current nascent state this window of opportunity will close, too. The history will repeat Android's story where Google created thriving FOSS ecosystem in a form of Cyanogenmon (and other similar distributions) but at the same time basically killed all the FOSS projects based on traditional Linux's stack. If people are Ok with seeing the repeat of this story on desktop, then who I am to object? It's not my choice.
Quotes of the week Posted Mar 25, 2012 1:20 UTC (Sun) by nix (subscriber, #2304) [Link] Remember the times when Linux seen AAA game titles (well, they usually were ported years later, but they were ported)? These times are gone.I'm not getting into the general argument here, but the AAA game title ports were largely crap, and thanks largely to the Humble Indie Bundles and Ryan C. Gordon there've been more games ported to Linux in the last three or so years than ever before. (It probably helps that the developers have to make the games portable these days anyway, so they can run them on the iPad and on Android boxes.)
Quotes of the week Posted Mar 25, 2012 8:30 UTC (Sun) by khim (subscriber, #9252) [Link] And how many of these games are capable of creating buzz? Where are things like Call of Duty, GTA, Left 4 Dead, Mass Effect, Rage, or StarCraft? We are talking about Joe Average here, right? Sure, MacOS also suffers from the same effect (and for the same reason), but at least they get something (from the list above: Left 4 Dead, Rage and StarCraft support MacOS). What do Linux users have? World of Goo? Is it enough for social creature (and we are talking about social-oriented users here: why else will they need all these social features)? Humble Indie Bundles and Ryan C. Gordon are trying to replicate the same failed model distributions are using: some games were ported by developers but significant part was ported by a small group of people. This model does not scale. But it also shows (once again) that Linux users don't shun games - the game developers shun Linux. And they obviously do that because ROI is poor. Instead of trying to improve ROI for the developers (by reducing investment because it's hard to increase sales too much when you have so few users) linux people talk about how that's “as much developer's as the distribution loss” and about how “it's really the third-party desktop app developers who should be pushing for a change”. But it's cheaper for any third-party developer to just create half-dozen packages for popular distributions rather then try to create the whole Linux app store! And another note: if “community” want any control over said store it must do it itself. If some vendor will decide to build it and succeed then it'll be this vendor's game, not community's game. See Android or Steam.
Quotes of the week Posted Mar 25, 2012 11:05 UTC (Sun) by anselm (subscriber, #2796) [Link] And they obviously do that because ROI is poor. Instead of trying to improve ROI for the developers (by reducing investment because it's hard to increase sales too much when you have so few users) The obvious way of tackling this as far as the games are concerned would not be to try the Sisyphean task of establishing a distribution-independent third-party application deployment infrastructure, but to come up with a way to run Android games on generic Linux desktops. This takes the application developers out of the loop entirely, instead of having to convince them to support one more platform (even if it is just one), and is a more feasible project by orders of magnitude, mostly because it is basically technical rather than political in nature. linux people talk about how that's “as much developer's as the distribution loss” and about how “it's really the third-party desktop app developers who should be pushing for a change”. The distributions really don't have much incentive to bend over backwards in this case. If anything it should be the smaller distribution projects rather than the big community-type distributions which should support an »app store« because it means that they can save manpower by not having to maintain a package for everything. On the other hand, most of the smaller distributions are really spin-offs of large distributions that can ride piggy-back on those distributions' repositories, and these already tend to have everything that is of interest in the first place (the FLOSS stuff, anyway). But it's cheaper for any third-party developer to just create half-dozen packages for popular distributions rather then try to create the whole Linux app store! The Linux community is notoriously bad at coming up with standardised solutions (it has brought us a dozen main-stream Linux distributions, four desktop environments, and so on), and it would be folly to rely on the community to come up with »the Linux app store« because it will never happen – at best it will be »LSB all over again« with the predictable result. Especially since you'd need buy-in from the main Linux distributions, because otherwise any effort towards an app-store-based Linux will just be seen as »yet another distribution« and not change anything at all. It may be uncomfortable to you but if you want an environment for third-party Linux desktop apps you will have to go to the developers of those apps to figure out what they need, and it will have to be those developers who will have to see about making it actually happen. (If they're clever they'll band together to do it, and talk to the distributions, too.) This is the FLOSS tradition of »scratching one's own itch«. If the third-party developers don't feel the need to scratch then maybe they're not itching enough (yet?).
Quotes of the week Posted Mar 25, 2012 13:07 UTC (Sun) by khim (subscriber, #9252) [Link] The obvious way of tackling this as far as the games are concerned would not be to try the Sisyphean task of establishing a distribution-independent third-party application deployment infrastructure, but to come up with a way to run Android games on generic Linux desktops. In other word: the obvious way is to follow OS/2, FreeBSD and other such platforms on the road to the irrelevancy. Besides a lot of popular Android games use binary ARM libraries and/or fancy on-phone controls thus it's not easy to bring them to Linux desktop. How will you emulate phone tilt? The distributions really don't have much incentive to bend over backwards in this case. If they don't want to see more non-technical users, then no, they don't need that. If they are happy to slowly lose the existing users then they can continue as before. Especially since you'd need buy-in from the main Linux distributions, because otherwise any effort towards an app-store-based Linux will just be seen as »yet another distribution« and not change anything at all. You don't need app-store-based Linux. App store itself can easily be installable package for the mainstream Linux distribution or a few of them. It may be uncomfortable to you but if you want an environment for third-party Linux desktop apps you will have to go to the developers of those apps to figure out what they need We are doing this, yes. If they're clever they'll band together to do it, Well, they are doing this to some degree. and talk to the distributions, too. Why will they want that? Distributions are obstacles, you don't talk with obstacles, you sidestep and/or remove them. If the third-party developers don't feel the need to scratch then maybe they're not itching enough. Oh, they feel the need all right. The only problem: it's even harder to convince them to do anything together. The most realistic outcome is that someone will just take Linux, remove useless components (such as GNOME, KDE, X Windows System, etc) and create app-store for that. If it'll be Google then most probably it'll be Android-based or ChromeOS-based desktop, if it'll be someone else they may pick something else. But I doubt they will spent a lot of time trying to keep the system usable in parallel with traditional Linux desktop. I'm not sure I'd like such outcome, but looks like there are no choice. The community have spoken: refusal to make a choice is by itself a choice. I just hope it'll not regret it later.
Quotes of the week Posted Mar 26, 2012 11:37 UTC (Mon) by anselm (subscriber, #2796) [Link] Distributions are obstacles, you don't talk with obstacles, you sidestep and/or remove them. This would be a very stupid approach since you need the distributions to convince their users that the »app store« is a good idea. Remember that most existing Linux users are generally happy with what the distributions give them (or else they wouldn't be Linux users in the first place). Your only hope to get people to accept the »Linux app store« is by convincing distributions to stop including stuff that users can get from the app store, and to tell their users to get that stuff from the app store instead. There is no incentive for users of a distribution to get something from the app store if the distribution already comes with the same something but well-integrated into the rest of the distribution and with the distribution's own »seal of approval«. So you need to get distributions to buy the idea that by packaging stuff for the »app store« rather than just their own ecosystem they will save work (presumably because their users get to use stuff, that other people than them are packaging for the »app store«, that the distribution would otherwise have to package for their own users). This is going to appeal more to the smaller distributions with less manpower than the Debians and openSUSEs of the world. For these distributions, since they basically include every interesting FLOSS package already and have enough volunteers to package stuff, the selling point would probably be the convenient availability of non-FLOS software. In any case, not working with the distributions would be quite misguided, simply because approximately every single Linux user will be using one distribution or another just to get at the app store. That distribution may well be a basic get-at-the-app-store one (Chrome OS comes to mind) but the existence of such a distribution will not make Debian or Red Hat go away. The old saw, »If you can't beat'em, join'em« applies here as well.
Quotes of the week Posted Mar 26, 2012 14:36 UTC (Mon) by khim (subscriber, #9252) [Link] Remember that most existing Linux users are generally happy with what the distributions give them (or else they wouldn't be Linux users in the first place). Bingo! The problem: more and more of them are stopping being Linux users. Your only hope to get people to accept the »Linux app store« is by convincing distributions to stop including stuff that users can get from the app store, and to tell their users to get that stuff from the app store instead. Nope. Much simpler and easier way is to convince third-party developers to release goodies for your app store and not for general-purpose Linux. If you can not convince them then the whole thing will be a bust (Linux has huge problems with commercial software while FOSS is supported adequately by existing distributions). If you can then people will use your app store for the lack of choice. For these distributions, since they basically include every interesting FLOSS package already and have enough volunteers to package stuff, the selling point would probably be the convenient availability of non-FLOS software. Yup. If you'll convince enough third-party non-FOSS developers to participate in project then people will start using app store to get these apps. If some FOSS developers will start releasing their goodies via this scheme it'll be added bonus. In any case, not working with the distributions would be quite misguided, simply because approximately every single Linux user will be using one distribution or another just to get at the app store. Why are you so sure? You can just provide package for a few major distributions. You don't need to cooperate with distribution makers and play their politics for that. That distribution may well be a basic get-at-the-app-store one (Chrome OS comes to mind) but the existence of such a distribution will not make Debian or Red Hat go away. Right. It's not our goal to kill Debian or Red Hat. But since cooperation with them does not make our life easier…
Quotes of the week Posted Mar 29, 2012 20:01 UTC (Thu) by oak (subscriber, #2786) [Link]
Strange that nobody's mentioned the stuff that nowadays seem to be requirements for bootstrapping a new app store:
* DRM so that users cannot copy the proprietary apps * Secured devices so that DRM cannot be broken i.e. users don't get "root" * HW support for security and keys for signed content * Few millions (or at least hundreds of thousands) in cash to pay games houses etc put enough initial content to app store to bootstart it
Linux distros are too small fish to have the cash or connections for last, they would need to partner with manufacturers for the HW side and normal Linux users don't like DRM or not having full control of their OS at all.
So, I see iOS / Android style "app store" as highly unlikely for normal Linux desktop.
How well the Ubuntu app store is fairing?
Quotes of the week Posted Mar 25, 2012 12:21 UTC (Sun) by robert_s (subscriber, #42402) [Link]
I'm amazed this "discussion" has managed to get so far without someone mentioning the fundamental difference between distro packaging and "app store" packaging.
App stores have a flat packaging model and distributions have dependencies.
App stores only appear to work because they have no concept of one package depending on another. Introduce that and the "app developers do the packaging" model _will_ fall apart.
App stores have an "us and them" system, where the system itself is not subject to package control. Distributions on the other hand package manage everything from the gimp right down to gtk, glibc and the kernel, which all need to be packaged in a consistent & sane way for anything to work properly.
There is no "us and them" in linux distributions. It just wouldn't make sense.
I would like to see an app store try to cope with the idea of a 3rd party driver.
Quotes of the week Posted Mar 25, 2012 12:38 UTC (Sun) by khim (subscriber, #9252) [Link] I'm amazed this "discussion" has managed to get so far without someone mentioning the fundamental difference between distro packaging and "app store" packaging. Have you looked on message which started that discussion? App stores only appear to work because they have no concept of one package depending on another. Introduce that and the "app developers do the packaging" model _will_ fall apart. Nope. Packages bring all the dependences with them. They can even request user to install some prerequsites (in fact a lot of them do) and if there are few requirements everything works. The most popular packages can be moved from the store to the core of the system over time - this way you can always keep number of prerequisites to minimum and number of duplicated libraries on typical user's system sane. Distributions on the other hand package manage everything from the gimp right down to gtk, glibc and the kernel, Yes - and that's the problem. which all need to be packaged in a consistent & sane way for anything to work properly. No. Most packages are “leafs” (nothing depends on them) or “cut-out subtrees” (with one package - like GIMP - as the root of tree and bunch of packages which only depend on this one package). These packages don't need to be packaged in any special way (if GIMP has one set of rules, TeX another set of rules and Chrome a third set of rules then this is not a problem because the plugins for these programs are developed by different people which don't know and don't care about each other). The only requirement: they should not clobber files from other packages - and this is easy to achieve without adding these packages to the distribution and without trying to fix what's not broken.
Quotes of the week Posted Mar 26, 2012 8:31 UTC (Mon) by nim-nim (subscriber, #34454) [Link]
> No. Most packages are “leafs” (nothing depends on them) or “cut-out
> subtrees” (with one package - like GIMP - as the root of tree and bunch > of packages which only depend on this one package). These packages don't > need to be packaged in any special way (if GIMP has one set of rules, TeX > another set of rules and Chrome a third set of rules then this is not a > problem because the plugins for these programs are developed by different > people which don't know and don't care about each other).
It's amazing how uninformed you are.
Apart from chrome (which I don't know well enough to comment on) none of your other examples are leaves and the problems you handwave away do exist today.
Quotes of the week Posted Mar 26, 2012 9:27 UTC (Mon) by khim (subscriber, #9252) [Link] Apart from chrome (which I don't know well enough to comment on) none of your other examples are leaves They are… in a sane world. For example on Windows or MacOS. GIMP has his registry, TeX has TeXLive and Chrome has it's store. They all exist quite independently and don't really affect each other. and the problems you handwave away do exist today. …in Linux world. Distributions promised to do the impossible: to support applications which pick dependencies at random without thinking. And now they are chocking under the load. The Linux desktop world is crumbling because you can't depend on it: familiar applications can be changed without notice (see GNOME and KDE) or just disappear (things like the venerable XV or GnoCHM) unless user itself decides to play Atlas, too. The solution offered? Try harder, listen to user more, do more of the same. The definition of insanity is doing the same thing over and over and expecting different results - and this is exactly what linux distributions are doing. I'm not saying that app store model is perfect or that's panacea. No. But it works better then the distributions model and as long as Linux desktop will reject it it'll have the same 1% of the market. P.S. If you'll say that it's not a problem on Windows or MacOS but a problem on Linux because applications are created in different fashion then I'll agree: if you'll give the developer an easy way to use something s/he'll like it. S/he'll not like the fact that it's hard to actually deliver the final creation to users, but this will be later - and s/he can always try to beg overworked distributions to pick this app, too. For the app store to succeed you need to carefully cultivate ABI exposed to applications in these app stores. But this is not something impossible or unimaginable in FOSS world: GLibC and Xlib are doing this for more then ten years. P.P.S. Rhetorical question: if Android or ChromeOS (or may be some combination of these two) will indeed conquer the desktop will the people who clamored for “the year of Linux” be happy or sad? I guess we'll see in about 5-10 years…
Quotes of the week Posted Mar 26, 2012 11:03 UTC (Mon) by anselm (subscriber, #2796) [Link] For example on Windows or MacOS. GIMP has his registry, TeX has TeXLive and Chrome has it's store. They all exist quite independently and don't really affect each other. It turns out that there are various pieces of software that need TeX installed, or some sort of web browser. The usual Linux distributions handle this easily. Smartphones and the iPad generally don't run TeX and come with a web browser preinstalled, so the issue doesn't really come up. How, in your opinion, would an ecosystem based on an »app store« handle this? Having each such »app« include its own copy of TeX isn't feasible as TeX tends to be somewhat large (usually way larger than whatever »app« is using it). Asking users to make sure that they also install the TeX app is a step backwards from what distributions do today and makes it difficult to claim that the »app store« is really more convenient for users. So it seems you're back to explicit dependencies. Distributions promised to do the impossible: to support applications which pick dependencies at random without thinking. And now they are chocking under the load. The Linux desktop world is crumbling because you can't depend on it: familiar applications can be changed without notice (see GNOME and KDE) or just disappear (things like the venerable XV or GnoCHM) unless user itself decides to play Atlas, too. This is arguably not the distributions' fault. They are doing a great job packaging things like the Linux kernel or glibc where the upstream authors do care about backwards compatibility, and they usually do allow several (major) versions of a library to coexist, which ought to take care of the ABI evolution issue if the upstream library authors do their job properly. Blame the GNOME and KDE developers for apparent incompetence or misguidedness or the XV developers for finding more interesting things to do with their lives. You can really only fault the distributions for not releasing often enough (if you insist on always having the newest stuff on the day it comes out) and not wanting to distribute stuff that they aren't entitled to distribute. But it works better then the distributions model and as long as Linux desktop will reject it it'll have the same 1% of the market. The »app store« model works for iOS because it is the only model there is (on Android you can install stuff from elsewhere but it is enough of a hassle for most people not to bother). Apple (and to a lesser extent, Google) don't use this because they want to make life easy for everyone but because they want to keep control over what is available and also take their cut. As far as Linux is concerned, there is nothing wrong with the distributions model other than that there could be more ABI compatibility for the benefit of third-party app developers. LSB was supposed to sort that out but as we have seen was mostly a paper tiger. At the risk of sounding like a broken record, the reason why an app-store model works for iOS but will probably not fly for Linux is that, unlike Apple at the time, the Linux community has no Steve Jobs figure. In the Linux community, any app-store model will need to succeed on its merits, not because some autocrat decides that an app store is how software is going to be distributed. You may argue until you are blue in the face that Linux distributions don't actually work but the fact of the matter is that, for all practical purposes, all existing Linux users run one distribution or another. These distributions set a bar that is uncomfortably high to jump over if you're an app-store-based model – because whatever their shortcomings the distributions are pretty damn good at what they are doing, namely putting useful software in the hands of their users. So the »app store« will have to offer something that distributions don't, and that will have to be (as I wrote earlier) convenient installation of uninteresting, or very new, or non-FLOSS software, i.e., stuff that distributions won't touch, and that out of the 1% of Linux users, probably only a small percentage is really interested in to begin with. Your argument is that people who are not using Linux now will be enticed to switch to Linux based on such an app store, and it is an argument that I don't buy. I'm all in favour of more standardisation, and I think it would be great in many ways if there was an obvious »Linux« that new users could install to get started rather than the current mess of half a dozen reasonable choices, all with their different strengths and weaknesses. But I have also been around the Linux community long enough to be fairly sure that this isn't going to happen anytime soon. Linux could probably do with more of a market share on the desktop, but claiming that an »app store« for Linux will make all the difference there is cargo cult thinking – if you just flatten the grass enough and put on runway lights then the airplanes full of goodies will come to you.
Quotes of the week Posted Mar 26, 2012 13:49 UTC (Mon) by khim (subscriber, #9252) [Link] Asking users to make sure that they also install the TeX app is a step backwards from what distributions do today and makes it difficult to claim that the »app store« is really more convenient for users. YMMV. Distribution offers easy tracking of dependencies and loong delays between release of the application and the time when you can actually use it: months for regular distributions or years if you use LTS. App store offers instant availability (few days in case of pre-moderated app store, few minutes for post-moderated one) but yes, worse tracking of dependencies. Often no tracking at all (all existing app stores today). This is arguably not the distributions' fault. They are doing a great job packaging things like the Linux kernel or glibc where the upstream authors do care about backwards compatibility, and they usually do allow several (major) versions of a library to coexist, which ought to take care of the ABI evolution issue if the upstream library authors do their job properly. Blame the GNOME and KDE developers for apparent incompetence or misguidedness or the XV developers for finding more interesting things to do with their lives. You can really only fault the distributions for not releasing often enough (if you insist on always having the newest stuff on the day it comes out) and not wanting to distribute stuff that they aren't entitled to distribute. With my developer hat on I may care about it or not, with my user hat on I most definitely not care. I know that on MacOS and Windows “XXX vY.Z is released” means I can go and play with it (or buy it if it's not free) while on Linux it means I can only salivate on press-release (ok, I can try to pull bunch of packages from “unstable” with a risk to ruin my whole OS). Your argument is that people who are not using Linux now will be enticed to switch to Linux based on such an app store, and it is an argument that I don't buy. No. My argument is the opposite: if Linux will not offer such app store then people will not switch from MacOS and Windows to Linux and existing users will leave it, too. As I've said myself: I'm Linux user so far only because I strongly dislike MacBook's keyboard, but I will probably decide that I don't dislike it that much one of these days. And I was Linux user for more then 10 years.
Quotes of the week Posted Mar 26, 2012 14:50 UTC (Mon) by anselm (subscriber, #2796) [Link] My argument is the opposite: if Linux will not offer such app store then people will not switch from MacOS and Windows to Linux and existing users will leave it, too. As I've said myself: I'm Linux user so far only because I strongly dislike MacBook's keyboard, but I will probably decide that I don't dislike it that much one of these days. And I was Linux user for more then 10 years. I was a Linux user back when MCC-Interim was considered a cool distribution. That was when if you wanted Perl on your Linux machine, you had to compile it yourself. Perl 4, that is. Having got that out of the way, I agree that an »app store« would be nice to have for new users if it could be made to work. However, I don't think its absence is the only thing that is keeping MacOS or Windows users from switching to Linux. These people would still be thoroughly confused as to whether to install Ubuntu, or openSUSE, or Debian, or Mint, or Chrome OS, or any of the other distributions that market themselves to new Linux users. The single most useful thing that the Linux community could do to make Linux more attractive to new users would be to rally behind one single distribution (an existing one or a suitably assembled new one) and one single desktop environment in order to give people something they can identify with – rather than a confusing choice of roughly equivalent distributions and desktop environments that all do the same thing in subtly different ways. This incidentally would pretty much take care of the »app store« issue, too. However, this would basically be the same as all major Christian churches getting together to present an amalgamated version of their faith in order to convince Muslims, Jews, Buddhists, etc. to convert – and about as likely to come to pass, or succeed.
Quotes of the week Posted Mar 26, 2012 15:12 UTC (Mon) by dmarti (subscriber, #11625) [Link]
Web standards (plus NaCl for the hard parts) are _way_ closer to being an ISV-friendly platform than any of the Linux-native alternatives. Yes, the distribution still has to fill in the plumbing layers such as display and audio servers, but that's doable within the current system.
Quotes of the week Posted Mar 26, 2012 15:38 UTC (Mon) by khim (subscriber, #9252) [Link] Having got that out of the way, I agree that an »app store« would be nice to have for new users if it could be made to work. However, I don't think its absence is the only thing that is keeping MacOS or Windows users from switching to Linux. Of course not! That's one of the obstacles. As Joe puts it: Lack of the app store is one serious problem, but of course it's not the only one. Think of these barriers as an obstacle course that people have to run before you can count them as your customers. If you start out with a field of 1000 runners, about half of them will trip on the tires; half of the survivors won't be strong enough to jump the wall; half of those survivors will fall off the rope ladder into the mud, and so on, until only 1 or 2 people actually overcome all the hurdles. With 8 or 9 barriers, everybody will have one non-negotiable deal killer. These people would still be thoroughly confused as to whether to install Ubuntu, or openSUSE, or Debian, or Mint, or Chrome OS, or any of the other distributions that market themselves to new Linux users. Oh, yeah. That's another deal-breaker. Joe Average installs OS exactly zero times. Most of them don't even install service packs unless they are pushed really hard on them. This approach is fundamentally incompatible with distribution's way of life where the only way to get new applications is to install new version of OS. The problem here is that you usually need the new application (or rather: you need some feature only available a new version of the applications) when you absolutely can not deal with the hassle of full-OS upgrade (when you are on tight deadline and new to actually do something with said feature).
Quotes of the week Posted Mar 26, 2012 13:57 UTC (Mon) by dgm (subscriber, #49227) [Link]
> At the risk of sounding like a broken record, the reason why an app-store model works for iOS but will probably not fly for Linux is that, unlike Apple at the time, the Linux community has no Steve Jobs figure. In the Linux community, any app-store model will need to succeed on its merits, not because some autocrat decides that an app store is how software is going to be distributed.
Wait a minute. What does "will probably not fly for Linux" really mean? It means that the current community will probably not embrace the paradigm change. But Android (which is Linux, more or less) is succeeding with an app store approach. And many Linux users are also Android users, so the Linux community has already embraced, to a certain extent, the app store model. Your argument seems wrong to me.
Quotes of the week Posted Mar 26, 2012 14:27 UTC (Mon) by anselm (subscriber, #2796) [Link] Android is technically a kind of Linux system but I would argue that one precondition for being considered part of the »Linux community« is knowing that you're actually running Linux, which a large percentage of the »Android community« is unlikely to be aware of. Many other people are using Linux on other consumer electronics appliances (like FRITZ!Box routers or Sony TVs) but probably wouldn't self-identify as members of the »Linux community«, either. The difference between Android and Linux-as-we-know-it is that, unlike traditional Linux, Android does have a central authority in the shape of Google. Google has decreed that there will be an app store for Android and that it will be the prime method of getting content (not just apps, these days) onto Android devices, and there we are. For traditional Linux, not even Linus Torvalds, who is the closest thing to a universally respected figure that the community has to offer, has that sort of clout. (We can quibble about how it is possible, or, depending on your device, even mandatory, to use another supplier's app store in place of the Google one, but the idea is always that there is one single company in charge – whether that is Google, or Amazon, or Samsung, or what have you. We can also quibble about how it is possible to install stuff on Android devices from other places, or indeed by uploading APK files via USB, but again this is something that the vast majority of users is unlikely to be doing on a regular basis.)
Quotes of the week Posted Apr 2, 2012 9:06 UTC (Mon) by arief (guest, #58729) [Link]
I can feel the 'desperation' tone in this discussion. I too has been finding myself less and less involved with my linux installations, on my dual boot systems, I would mostly played in Windows (for work or gaming reasons), and only rarely go to linux (for checking new things out, occassional updates).
I guess, Linux as a base system is already quite 'final' and stable, and becoming a boring system. We do need to find a way to move it forward again.
Linus has been known to make such radical changes to the world.
Why not (t)asking him to make this radical change again? You know, making a one-true-linux-distribution that will work for _everybody_ and always an exciting place to play in ;-)
Quotes of the week Posted Mar 26, 2012 14:34 UTC (Mon) by dgm (subscriber, #49227) [Link]
> As far as Linux is concerned, there is nothing wrong with the distributions model other than that there could be more ABI compatibility for the benefit of third-party app developers. LSB was supposed to sort that out but as we have seen was mostly a paper tiger.
In my honest opinion, the problem is not that much ABI compatibility (even if it is) as API and ABI _confussion_. There are so many versions of everything, so many competing implementations, so many rogue libraries that are not seriously endorsed by anybody. The problem is that the pieces that make the system up are not designed, but evolved. This is great for library survival, but makes the life of the user much harder, because we have a system made of exceptions, or more exactly, a system where rules are _the_ exception.
The real problem with distributions, specially those based on Debian, is that they solve the problem of deciding what goes in by allowing _everything_ to go in. No choice is made, only minimal rules enforced, and thus the system is more complex than it needs to be. Complexity down the line (on the user side) is the price we pay for not choosing at the expert level (the distro).
I think the time has come for a different kind of distro. One that makes _good_ choices for their users, and thus, saves their users from the need to make them, exactly as Android does, and then sticks forever to those choices. Forever. For that reason, only mature libraries with a very strong commitment to compatibility could be chosen, and barring that, they would have be to be forked to preserve compatibility. So only a distro capable and willing to develop and maintain it's own APIs and ABIs could do that. It would be the antithesis of Debian. It would no longer be a mere distribution (as in a collection of packages) but a platform development organization.
I have seen steps taken into that direction. Ubuntu is currently developing more custom code than ever, but the Debian culture is somehow preventing the making of choices. Redhat has also been busy writing code for quite some time, but they lack interest in the desktop. Finally there's that GNOME OS initiative to define a set of APIs. Apparently Linux is heading into that direction, just very slowly.
Quotes of the week Posted Mar 26, 2012 19:24 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
Ubuntu started with the idea that they would only offer one option for everything, but user demand has shaped this over time.
Quotes of the week Posted Mar 26, 2012 8:28 UTC (Mon) by nim-nim (subscriber, #34454) [Link]
> App stores only appear to work because they have no concept of one
> package depending on another. Introduce that and the "app developers do > the packaging" model _will_ fall apart.
It's falling apart even without this. The ancestor of all app stores is the Firefox extension system, where Mozilla washed its hand of third-party code, and extensions developers had their wish (not think about systems or deployment problems, one file for every system, yadda, yadda).
As a result, Mozilla has to devote resources to frantically QA extensions because badly written extensions by big-name proprietary houses are killing its reputation
https://blog.mozilla.com/nnethercote/2012/02/16/mcafee-is...
and the same integration pressure distributions experiment is causing it to abandon the simple version matches that people dissing distros for over-engineering typically propose
And all that for small bits of code that barely deserve the application name.
Quotes of the week Posted Mar 26, 2012 8:59 UTC (Mon) by khim (subscriber, #9252) [Link] The ancestor of all app stores is the Firefox extension system, where Mozilla washed its hand of third-party code, and extensions developers had their wish (not think about systems or deployment problems, one file for every system, yadda, yadda). Mozilla decided to combine worst sides of distro-building (no stable ABI and no sandboxing) with worst sides (WRT stability: these are the best sides as far as third-party developers are concerned) if app store model (packages are created by developers themselves, there are no A&A, etc). No wonder it's falling apart! It was obvious from the very beginning that if you'll give access for the third-party code to the very guts of your system without any security checks then bad thing will happen. I'm surprised it lasted for so long. To make appstore work you either need a review process (like Apple is doing and Microsoft is planning to do) or you need compartmentalization and quotas. We are dealing with potentially malicious code here, folks! And all that for small bits of code that barely deserve the application name. And which are widely requested by user. Yes, from FOSS side it look ridiculous: what are these apps doing which is not possible with FOSS? The answer is: nothing much - but they are doing this today, not in some undetermined point in the future.
Quotes of the week Posted Mar 23, 2012 17:25 UTC (Fri) by jsanders (subscriber, #69784) [Link]
What would be nice is for some sort of multi-distribution "app store". The developer could upload some source and it would build it against a whole set of distributions. The app store would have some policy for how packages should be packaged.
The distributions could be in charge of the base system and the app store in charge of apps.
Unfortunately in linux, the libraries and apps are so fast moving and entwined, I'm not sure how this could work with distributions as diverse as RHEL and the latest ubuntu/fedora.
Quotes of the week Posted Mar 23, 2012 18:13 UTC (Fri) by khim (subscriber, #9252) [Link] The developer could upload some source and it would build it against a whole set of distributions. Very few developer will want to send their precious sources anywhere. When we debugged nasty bug in Unity 3D they only gave access to the sources to few select developers in our team and then only to a limited subset, some libraries were offered as binary only. The build required use of both Linux and MacOS¹ and of course the idea that they need to change it to support our nascent port was not even considered. Unfortunately in linux, the libraries and apps are so fast moving and entwined, I'm not sure how this could work with distributions as diverse as RHEL and the latest ubuntu/fedora. it's not a rocket science. The problem is not a speed of development. The problem is general attitude. As long as “you only need to recompile your program” is perceived as acceptable solution to anything Linux desktop will not go anywhere. It's possible to do: Linux kernel is developed by these rules as well as GLibC and X Window System. Even some higher-level libraries are developed in this fashion (namely GTK and Qt). But somehow DE developers feel they are special and may play by different rules. Which is crazy because they obviously develop something which needs such rules more then anything else on Linux desktop. ──────────
Quotes of the week Posted Mar 23, 2012 18:33 UTC (Fri) by dgm (subscriber, #49227) [Link] I'm not so sure about X11 and glibc. Look at this for an example. It's the instructions for installing Wordperfect 8 on Linux. It's a mess. I'm sure Wordperfect developers could have done it a little bit better, of course.
Quotes of the week Posted Mar 23, 2012 20:50 UTC (Fri) by khim (subscriber, #9252) [Link] Look at this for an example. And… what I'm supposed to see there? After unpacking (and reading the Readme file), you'll have to furnish the dynamic libraries WP 8.0 requires: ld-linux.so.1.9.*, libc5 (any version from 5.3.12 onwards) with matching libm.so.5.*, and a set of X11 backwards-compatibility libraries compiled for libc5 X11 clients (libXt.so.6, libX11.so.6, libXpm.so.4, libSM.so.6, and libICE.so.6). As you can see WP8 predates GLibC so what exactly this example is supposed to prove? I'm sure Wordperfect developers could have done it a little bit better, of course. I doubt it. Before GLibC 2.1 came along in the end of 2000th Linux ABI was a mess even on the lowest level. NPTL (introduced in March 2006) was also quite disruptive (formally it kept the interface stable, but it broke some non-POSIX-compatible tricks which program used with LinuxThreads). Still this is far cry from the rest of the Linux desktop.
Quotes of the week Posted Mar 25, 2012 23:45 UTC (Sun) by dgm (subscriber, #49227) [Link]
You're right. I wasn't aware of the libc5 to glibc 2 transition, it predates my first Linux usage, too. I have found by the way that while Ubuntu does not offer a lib5 version, Debian does. But there's no way to get a compatible xlib version, you need a specially patched one. The point is: no binary compatibility, you need to build your own base libraries. While I'm not sure, I'm pretty confident I could install WP8 on Windows without much hassle, even today.
Quotes of the week Posted Mar 26, 2012 6:57 UTC (Mon) by khim (subscriber, #9252) [Link] The point is: no binary compatibility, you need to build your own base libraries. Sure. If don't use GLibC then you don't benefit from it's excellent compatibility record. While I'm not sure, I'm pretty confident I could install WP8 on Windows without much hassle, even today. Not fully. WP8 for Windows includes some 16bit components and thus does not work in x64 version of Windows. But yes, Microsoft is significantly more serious about binary compatibility while in Linux it all ends with GLibC and X11R6 (again: previous versions are not binary compatible). You can not go back and fix former mess without time machine thus obviously I'm not claiming you can create stable ABI which will support all the program written before the introduction of said stable ABI: this is theoretically possible but practically unfeasible. But you can create stable ABI which support most of the programs (and all programs obeying the specs) written after the introduction of said stable ABI. This is what GLibC, XLib, GTK+ and few other libraries are doing, but what the rest of Linux desktop does not do.
Quotes of the week Posted Mar 23, 2012 13:10 UTC (Fri) by khim (subscriber, #9252) [Link] Right. But how many of those 500,000 »applications« are really glorified web bookmarks? Not a lot. There are huge number of dumb applications but these tend to be some screensavers or flashlights. But this is not the point, the point is that they are there, people can try then if they hear about them (they don't need to wait two years till new release of the distribution and they don't need to switch distributions if they don't like one particular program), etc. The problem is really that Linux is a culture of open source software. Sure, but for the last ten years, at least, Linux desktop desperately tries to attract user who can not build things from source. All these “streamlined interfaces” and “social features” are supposed to attract Joe Average and Mr. Average does not care for source availability all that much, be does care about the ability to use “latest and greatest” stuff his friends rave about. This has in fact been tried in the past under the auspices of the »Linux Standard Base«, or LSB, and didn't really get anywhere in practice. Heh. I've waited for this moment. Finally someone brought this abomination. It was always obvious that LSB is DOA. Instead of including features requested by application developers they include features which are “mature enough”. Who and what can create using this API? The latest version of LSB (released last year!) still does not include sound and video playback, for example. Can you imagine contemporary game without sound, for example? Note that games are Linux's Achilles heel (there is little hope to see wide selection of open-source games any time soon) thus obviously they must be considered top priority - yet they are completely ignored by LSB. LSB is useless on server because everyone just certifies for RHEL and it's pointless on desktop because it ignores requirements of desktop… is it any wonder it fails?
Quotes of the week Posted Mar 23, 2012 13:56 UTC (Fri) by anselm (subscriber, #2796) [Link] LSB is useless on server because everyone just certifies for RHEL and it's pointless on desktop because it ignores requirements of desktop… is it any wonder it fails? No. But that's what I said already. The problem is really that by now, the major distributions have had years of practice convincing themselves that whatever they do is the Right Thing. Watch how SUSE, for example, is pushing Btrfs as the default root file system so YaST will work better, or how Ubuntu is trying to re-invent the Linux desktop all on their own, every six months. During the course of the last 20 years the Linux community hasn't even managed to agree on one unified format for binary packages, which is a positively trivial exercise compared to coming up with a standardised and stable desktop ABI. Add to that the silly resistance that some people are putting up against obvious and badly needed advances like Systemd, and you will find that building consensus for a »LSB-NG« effort that will actually solve the problem of cross-distribution third-party app development is about as straightforward as negotiating lasting peace in the Middle East – a worthy goal to be sure but not achievable against the efforts of the major players. The only way to really address this for the benefit of »Joe Average«-type users, in order to present an ecosystem similar to that of Android, iOS, or the upcoming Windows and OS X versions, would be ruthless standardisation. The community would have to agree on one mainstream Linux distribution (niche distributions such as OpenWRT could stick around) with one desktop environment and a standardised API that would provide backwards compatibility on a level comparable to today's Linux kernel and glibc. While this would be an enticing idea in theory I can guarantee you that whatever you put forward will have the proponents of everything else up against you in an instant. Try to make GNOME the standard API, and the KDE, LXDE, … people will eat you alive. Try to make KDE the standard API, and the GNOME people will be the first to knock at your door with pikes and torches. Having several competing desktop environments was a great idea while it lasted, but the resulting fragmentation together with the cavalier attitude both the KDE and GNOME folks have towards ABI stability is now coming home to roost. The big problem is really that doing this would remove much of the flexibility that today's Linux users, however few in number they may be by comparison to the Windows/Mac/iOS/… users, like about the system, and there is a real danger of losing these people in the process. (An adage like »he who fights monsters must take care not to become a monster« comes to mind.) It is also not clear exactly who should spearhead such an effort. The distribution makers aren't going to do it any more than the turkeys will be voting for Christmas. The upstream projects don't tend to care since most of them are only releasing source code, anyway. The existing users don't have the leverage. The prospective users aren't interested. Who is left?
Quotes of the week Posted Mar 23, 2012 15:10 UTC (Fri) by khim (subscriber, #9252) [Link] It is also not clear exactly who should spearhead such an effort. The distribution makers aren't going to do it any more than the turkeys will be voting for Christmas. The upstream projects don't tend to care since most of them are only releasing source code, anyway. The existing users don't have the leverage. The prospective users aren't interested. Who is left? Google. The only problem: it's not interested in “spearheading the effort”. In fact it's not even interested in desktop. Yet. But eventually it'll expand there. I'm not sure if it'll start from tablets and we'll end up with some Android derivative or it'll start from ChromeOS and we'll have something browser-centric, but it'll not matter much: the end result will not be much-sought “consensus”, it'll be “desktop as Google envisioned it”. Or may be all efforts will fail and Linux desktop will die off completely. Both outcomes are probably not what “upstream projects” and “distribution makers” expect, but if they will not act soon they'll lose the opportunity.
Quotes of the week Posted Mar 23, 2012 15:59 UTC (Fri) by nim-nim (subscriber, #34454) [Link]
> During the course of the last 20 years the Linux community hasn't even
> managed to agree on one unified format for binary packages, which is a > positively trivial exercise compared to coming up with a standardised and > stable desktop ABI.
Let me correct that for you:
<rant>
During the course of the last 20 years the developers whining about Linux distributions have not managed to agree on a single deployment rule. When asked to fix their s* by distributions they complain that distributions propose slightly different solutions, do nothing, and then are offended that distros take upon themselves to do some damage control and that Linux users by and large use the distribution fixes instead of the genuine broken-by-design binaries that they self host. Not only they've been unable to agree on and write their own rules, but they've been unable to decide which pre-written distro ruleset to adopt.
They continue to beat the deb/rpm differences dead horse when every technical comparison in the past decade showed both formats were functionally equivalent and had the same requirements, they complain about distro patching that supposedly fragments the market when distros essentially reinvent the same fixes or trade the same patches (you could even find Linux distro patches in OpenSolaris when it was still alive), they complain about distro release dates when all major distros release about the same time nowadays to take GNOME/KDE into account, bug trackers are full of the same requests by users of different distributions and the response is always 'I could fix this but $otherdistro may demand something else' (replace $otherdistro by whatever distro which has not found the time to point out the problem yet).
Suse happily copied Fedora packaging guidelines on its own wiki because they were better than no rules (when Suse had not written its own rules yet), and comparing Debian/Fedora guidelines is a case of parallel evolution with very similar solutions.
Those developers could make distributions irrelevant in a blink by releasing software that didn't need massaging for mass deployment. Except that would mean tackling the issues distros solve today, would identify the same pain points distro point out now, and the whole point of the exercise is to postpone integration and avoid paying the technical debt of past mis-decisions.
In fact those developers quite often deny there is a need for integration and associated rules, justify this denial by pointing the supposedly minuscule Linux market share, and always forget to mention the even more abysmal market-share of their own not-integrated direct developer-to-user binaries. No, they prefer to compare to the Windows/OSX/Android/whatever ecosystem, and conveniently forget that those ecosystem have rules too, and that their owners are at least as directive as Linux distributions (the usual excuse is 'but $x does not ask for $y like Linux distributions', forgetting $x asks for $z when Linux distributions do not care about $z).
</rant>
Quotes of the week Posted Mar 23, 2012 17:48 UTC (Fri) by khim (subscriber, #9252) [Link] Those developers could make distributions irrelevant in a blink by releasing software that didn't need massaging for mass deployment. Wow. This is bold statement. I'll bite. Can you explain how to do that - even in principle? The requirements are obvious (nothing onerous - all platforms except Linux obey these rules without asking): Assume I'm doing a simple 3D game which need to play sound and some video (that's what most games do nowadays, after all). I don't see any way to do that thus your assertion that developers can “release software that didn't need massaging for mass deployment” looks quite a lie. Except that would mean tackling the issues distros solve today, would identify the same pain points distro point out now, and the whole point of the exercise is to postpone integration and avoid paying the technical debt of past mis-decisions. Exactly. This is not my piece of cake. Sure, I can assign some people to the task of supporting “Linux desktop mess”… but why will I want to do that when I can spend the same resources on PS3 or Android port with much better ROI? In fact those developers quite often deny there is a need for integration and associated rules, justify this denial by pointing the supposedly minuscule Linux market share, and always forget to mention the even more abysmal market-share of their own not-integrated direct developer-to-user binaries. Bullshit. Widely cited and quite plausible market share of Linux is 1-2%. This is 15-30 millions of users. I've participated in many projects which had (some still have) more users then that. Most of them were never ported to Linux, because, as was pointed above, it's pointless. No, they prefer to compare to the Windows/OSX/Android/whatever ecosystem, and conveniently forget that those ecosystem have rules too, and that their owners are at least as directive as Linux distributions. And what rules are these, please tell me? That you must think before you write and not do a crazy things (like assuming that “Program Files” is always “Program Files”?), isn't it? Well, this is covered in easy-to-follow documentation and all the examples obey them thus it's not such a big deal. The usual excuse is 'but $x does not ask for $y like Linux distributions', forgetting $x asks for $z when Linux distributions do not care about $z. Not forgetting. Not caring. You see, if $x is “Windows” then I'm ready to €N to implement $y. If $x is “Mac OS” then I'm ready to spend ≈0.1✕€N (well, I can spend ≈0.2✕€N and compensate with higher price if I feel that Mac OS users will be more generous then Windows users). But when Linux users come to me and ask to implement feature $z which is not required neither by Windows nor by MacOS and that will cost me ≈0.05✕€N, then the obvious answer is “are you nuts?… bring me as many users brings at least and then may be, just may be I'll think about it”. Beggars can't be choosers - and right now Linux desktop is as poor (by number of users) as they come. Later, when you'll have many-many Linux desktop user you may start adding new rules (like Google is doing with Google Play Store), but today… sorry, you have no such luxury. You do know know that a lot of programs (especially games) are ported to MacOS with a help of CrossOver for Redistribution because ≈0.1✕€N is not enough for native port, right? In comparison to that typical requirements of Linux distributions is not “onerous” or “crazy”. They are “beyond good and evil and well unto realms of terminally insane”.
Quotes of the week Posted Mar 23, 2012 18:32 UTC (Fri) by nim-nim (subscriber, #34454) [Link]
> The requirements are obvious
Requirements are always obvious to the complainer. What they are not necessarily is reasonable. You object to the way distributions have solved the deployment requirement. What you've not done is producing anything better. If you had you would have made distributions irrelevant, since their only raison d'être is distributing software better than you do.
> Beggars can't be choosers - and right now Linux desktop is as poor (by
Quite apart from being offensive, your statement is wrong. Linux distributions are not a free service. They're not begging. They help themselves and entities that help them back, and it worked quite well in the datacenter or embedded space (for everyone involved).
If desktop players such as you prefer dancing to the whims of Apple or Google or Microsoft, that's as much your loss as the distribution loss (in fact it's more of your loss because distributions depend more on the datacenter than on the desktop, and have proved resilient to third party vendors hostility).
Quotes of the week Posted Mar 23, 2012 20:36 UTC (Fri) by khim (subscriber, #9252) [Link] Requirements are always obvious to the complainer. What they are not necessarily is reasonable. These requirements were not changed from the desktop concept inception decades ago. Only Linux chooses to ignore it. Well, that's not our problem. What you've not done is producing anything better. Right now we don't yet have enough pieces to directly attack desktop so Linux developers have few years of opportunity - and it's not at all clear that we can offer something better then Windows and MacOS, but we are thinking about it, believe me. They help themselves and entities that help them back, and it worked quite well in the datacenter or embedded space (for everyone involved). Entities which own the datacenter and embedded world (RHEL in datacenter and Montavista, Wind River and other similar providers in embedded world) know that they must offer stable ABI (they break it with new releases but these are spaced years apart and their support time overlaps by significant margin). Only desktop distributions feel they are entitled for something else. If desktop players such as you prefer dancing to the whims of Apple or Google or Microsoft, that's as much your loss as the distribution loss. Contrary to Church of Emacs preachers “desktop players” don't like to dance to Apple, Google or Microsoft “whims” - they just want to help users (sometimes for a fee, in some cases gratis) and Linux users are not considered more important then Windows users (why should they?), the rest follows from said principle. Actually we even do more for Linux users then 1% market share implies, but to treat them 100 times more important then Windows users is out of the question. In fact it's more of your loss because distributions depend more on the datacenter than on the desktop, and have proved resilient to third party vendors hostility. And third party vendors proved more then resilent enough to Linux distribution's hostility. Hmm… there are exceptions, of course: few vendors which targeted Linux desktop niche and ignored Windows/MacOS/iOS/Android/etc (most of them are dead). Well… it's their loss, not ours.
Quotes of the week Posted Apr 11, 2012 13:44 UTC (Wed) by wookey (subscriber, #5501) [Link]
<blockquote>Right now we don't yet have enough pieces to directly attack desktop so Linux developers have few years of opportunity - and it's not at all clear that we can offer something better then Windows and MacOS, but we are thinking about it, believe me.</blockquote>
Who is 'we' here? I was following the discussion OK until this point.
All I will add to the discussion is that it is true that there is a lot of obscure software not available for Linux (e.g. building supplies companies calculators for number of fixings required per foot). This is annoying, but in a fairly minor way.
But the preditions of the death of Desktop Linux are overstated IMHO. I can't see any prospect of ever switching to anything else, and I expect I'm not the only one. Freedom is much more important to me than random bits of (mostly unimportant) software not available on my platform. I don't see that changing. And I'm very happy with the integration job my distro does. The userbase could shrink enormously and I'd still get the main benefits I came for. And actually I don't see a shrinking userbase at all, although that may be the circles I move in. Certainly usage is growing fast amongst developers at the large company I work for.
|
|||||||||||||