It's not all sunshine and teddybears.
|
| Author | Content |
|---|---|
| r_a_trip Sep 07, 2009 4:49 AM EDT |
What Mr. Fields says about Appbundles is mostly true. They can be a convenient way of using software. However, he glosses over a few of the downsides of Application Bundels. It's not just the missing Application Menu link. The user is in control. It is true. The user controls everything about an Appbundle. Where he gets it, where he places it, when he updates it, when he deletes it. In other words, all management aspects (except bundle creation) of the software falls on the shoulders of the user. While this is a plus it is also a negative. The user will have to track which Appbundles he uses. When there are just a few Appbundles, this is fairly straightforward, but the effort becomes pretty daunting when there are over 50 Appbundles. It is not only knowing which Appbundles you have and where they are stored, but it is also tracking which bundles have new versions out. It is knowing where you can get the new versions and knowing that your download source is trustworthy. The Appbundle may run with user privileges, but that doesn't mean it can't do no harm. When an exploit is in the wild, the user needs to know of this. Know which Appbundles contain the flawed software and find the necesarry updates and replace the affected Appbundles. Maybe vulnerabilities are the biggest drawback with the use of Appbundles. Since they all come with their own set of common libraries and they lack central management, you have to track all of the bundles separately. While package management and repositories can be very rigid at times, they are very effective with replacement of a flawed common component. With Appbundles, you have to replace every bundle separately if there is a flaw. It might be possible to have every bundle have its own update notifier. It won't make it prettier though, having all applications nag you "when they feel like it". Application bundles are not the problem free way of using software as appbundles.org seems to be touting. |
| hkwint Sep 07, 2009 5:08 AM EDT |
Quoting:It might be possible to have every bundle have its own update notifier. It won't make it prettier though, having all applications nag you "when they feel like it". Indeed, that's how it's "solved" for Windows. What would be ideal is if AppBundles became a cross platform 'controlled' repository, but attempts like this have failed in the past before. Probably because of the reasons mentioned above. |
| claus Sep 07, 2009 6:33 AM EDT |
Quoting:It might be possible to have every bundle have its own update notifier. It won't make it prettier though, having all applications nag you "when they feel like it". It's also possible to have a system-wide update notifier that is controlled and configured by the user -- just like you do with the current system's update notifier. So, you could say: "Check for updates once a week." All you need is a sort of registry -- similar to the registries for application menues -- that the appbundle uses. This and the notifier could be provided by the launcher, since every appbundle seems to need the launcher, anyway, according to the site. For those who like to have a system-wide "Add/Remove" program: This is also possible. All you need is a central web API that the "Add/Remove" app uses. App developers could just notify the web instance about their new releases -- sort of like KDE-Apps or GNOMEfiles for app bundles -- and people will be able to install it without being required to visit the app's homepage. |
| jdixon Sep 07, 2009 8:54 AM EDT |
>> It won't make it prettier though, having all applications nag you "when they feel like it". > Indeed, that's how it's "solved" for Windows. Yep. > All you need is a sort of registry -- similar to the registries for application menues -- that the appbundle uses. Again, a Windows type solution. Do we really want to recreate all of Windows' problems on Linux? |
| hkwint Sep 07, 2009 9:24 AM EDT |
Quoting:Do we really want to recreate all of Windows' problems on Linux? Well, we want the benefits of the Windows system, the benefit being developers only need to package their app for one distro and then working on any distro. But we want that benefit without all the drawbacks. Almost impossible, I suggest. |
| claus Sep 07, 2009 10:49 AM EDT |
Quoting:Again, a Windows type solution. Not at all. Unless you consider everything that places a file in a pre-defined directory to be a "Windows type solution". Then, Linux has already lots of these. How do you think the "freedesktop" menu as used by KDE, GNOME, XFce and others works? |
| dinotrac Sep 07, 2009 11:42 AM EDT |
There is also the violence done to the idea of shared libraries and virtual memory management. Probably not so bad in these days of megagoogleuniversebytes of everything, but still violence. |
| r_a_trip Sep 07, 2009 2:46 PM EDT |
@Claus It could work, but every tracking of a bundle you do and the more you make things static as in location, the less Appbundles make sense. I think the problem should be tackled on the other end. The mess of deb/RPM needs to be fixed. Alien proves they are more similar than different. Come up with one merged variant across distributions. Call it UPF (Unified Package Format) or something like that and put it in the LSB. Then fix the mess of the libraries. Have a foundation manage the library versions with a fixed file-system layout and have them release the LFL (Linux Foundation Libraries) every two years. If distro's would track the LFL, then all distro's shipping with the LFL base in /lib would be able to run available UPF packages. LFL 2010, LFL 2012, LFL 2014, etc. Ah, one can dream. |
| jdixon Sep 07, 2009 4:37 PM EDT |
> ...the benefit being developers only need to package their app for one distro If the application is open source, then the distro's can package it themselves. This is only really a problem for closed source apps. Even Slackware, with it's limited base set of packages, has a huge set of third party packages available, and custom packages are easily assembled from source. > Not at all. It doesn't have to be, no, but the devil is in the details, and I'd not like to place a wager on the outcome. > How do you think the "freedesktop" menu as used by KDE, GNOME, XFce and others works?How do you think the "freedesktop" menu as used by KDE, GNOME, XFce and others works? Poorly, in my experience. :( > The mess of deb/RPM needs to be fixed. Not even that simple. An rpm package may not be usable acroos all distro's which use rpm (see SuSE/Fedora/Mandriva for examples). The same holds true for .deb. Then you have the source based distros and Slackware, plus a number of other even less commonly used packaging systems. It's not as simple as combining rpm and deb into a single packaging system. We've already had several tries at a universal package format, none of which have been remarkably successful. Of the packaging systems out there, deb seems to work the best, but it's not a panacea. |
| krisum Sep 08, 2009 12:33 AM EDT |
Actually all of these supposed *problems* are already fixed by things like autopackage. In fact autopackage utilizes the system libraries where possible and even though it still has the maintenance problem of having multiple copies of some shared libraries, it comes much closer to solving the problem than AppBundles will ever come -- IMO AppBundles will create more problems than solving. It even has workarounds for differences in libstdc++ or GTK libraries in different distros, and has a good mechanism for resolving binary ABI incompatibilities in general. |
| hkwint Sep 08, 2009 7:44 AM EDT |
Quoting:If the application is open source, then the distro's can package it themselves Again, they shouldn't have to do any packaging. The developer of some app should be able to package it, without any distro repackaging and possibly screwing it / distributing outdated software. "Packaging" for specific distro's shouldn't be necessary. How on earth can the developer of some app - let's say Firefox - do any bugtracking if every Linux distro sends files to different places and uses different patches and themes, and libraries? And worse, if all of them ship different versions, of which some are not even supported? In the ideal world, a package repository for some distro would just be symbolic links to the site were the software comes from. For example, "Firefox" would just link to the Mozilla download site. No reason to waste terabytes on duplicating the very same software for gazillion distro's. 'Distributing' / 'packaging' software is just another word for duplicating efforts / wasting time - and by doing so adding new errors and bugs - which doesn't make much sense. Ah, I have the right to dream I guess. If package repositories didn't exist, probably over 50% of distro's would lose their reason of existence. Quoting:Actually all of these supposed *problems* are already fixed by things like autopackage Indeed, but development halted for a while and uptake by projects isn't very large sadly. Kudos to Dutch tax service for providing autopackages, but they're an exception. |
| jdixon Sep 08, 2009 9:53 AM EDT |
> Actually all of these supposed *problems* are already fixed by things like autopackage. One of the ones I was thinking of, yes. > How on earth can the developer of some app - let's say Firefox - do any bugtracking if every Linux distro sends files to different places and uses different patches and themes, and libraries? And worse, if all of them ship different versions, of which some are not even supported? Barring "one distro to rule them all", that's what you're going to have. :( How do developers support Windows 3.1, Windows 95, Windows 98, Windows ME, Windows 2000, Windows XP, Vista, and soon to be Windows 7? The short answer is you don't. You pick and choose what you can afford to support. In general, for Linux that's Red Hat, Suse, and Debian/Ubuntu. The other distros then modify those packages as needed to make them work. But, as I already noted, with open source apps it's not a problem, as you can always build the packages from source. It's only really a problem for closed source apps. |
| bigg Sep 08, 2009 11:24 AM EDT |
On autopackage, there is plenty of criticism:
http://www.licquia.org/archives/2006/03/11/autopackage-goes-...
http://kitenet.net/~joey/blog/entry/autopackage_designed_by_...
http://devmanual.gentoo.org/ebuild-writing/functions/src_unp... And from what I've read, the autopackage devs essentially killed the project due to a lack of social skills. They were geniuses and everything done by anyone else is garbage. Maybe things have changed in the last two years, since these criticisms were posted. |
| claus Sep 08, 2009 12:21 PM EDT |
Quoting:Barring "one distro to rule them all", that's what you're going to have. This could also be said about the current system: Why should any average user care about other general desktop distributions except the one with the most applications and the most momentum? It's already been noted that many new users equate Ubuntu to be Linux. With a decentralized system, smaller distros have a better chance to create something interesting. And distros for special technical applications won't be bothered, at all. Quoting:On autopackage, there is plenty of criticism There's also plenty of criticism about the centralized systems: “PS. How cool is that: for Windows systems an application developer can make a single, tested application installer which people can use to install an application… and it will Just Work! Brilliant! If only we could do that on Linux… but alas, apparently that's too hard… ” – Marc Maurer, Abiword, http://uwog.net/news/?p=17 “The latest stable AbiWord 2.6.0 release was unveiled last month, two years after the software's last stable release. Feature-wise, the little cross-platform word processor has closed the gap with heavyweight OpenOffice.org Writer, but it suffers from the oldest Linux ill of all – it's a pain to install.” - http://www.linux.com/feature/131852 “Erin went to YouTube and searched for a Beatles video, and seemed to assume that it would work straight away. When it told her that she needed a plug-in she groaned, but clicked the link they gave her. It took her to the official Flash plug-in page, and gave her the option of downloading a gzipped tarball, an RPM or a YUM. […] Because she’s using Ubuntu, the RPM and the YUM are going to be of no use – not that she knows this. Erin tried the .tar.gz, and it downloaded to her home folder. It opened in the archive manager, and she extracted it to the default. Then, she was lost. She tried double-clicking the file, and Ubuntu just asked her what she’d like to do with it. The option “run” results in it crashing. No clue was given to her that she should open up a terminal and type ‘./flashplayer-installer’. To be fair, there are links to installation instructions, but the average person acclimatised to Windows is not expecting to have to read complex information before installing a program – all they need to do is double click it. Obviously her attempts with the RPM and the YUM went nowhere. Frustrated, Erin conceded defeat.” – http://contentconsumer.wordpress.com/2008/04/27/is-ubuntu-us... It's no surprise that distribution developers criticise Autopackage: They don't understand what it tried to accomplish and they fear to admit that their systems fail for a number of important use cases. |
| krisum Sep 08, 2009 5:01 PM EDT |
@bigg Interesting but I would not qualify those as really criticisms of autopackage per say. A few of those in Gentoo are simply because autopackage is not supposed to be a distro package format in any case. I do not see anything there to suggest that it cannot be forked, for example, if the devs are inflexible. At the very least I would suggest that devs of something like Appbundles take a look at what has already been done, try and absorb the knowledge there and try to address the unaddressed questions rather than starting from scratch (e.g. the FAQ of autopackage where it discusses why appfolders is inappropriate for most linux distros). |
| tracyanne Sep 08, 2009 5:02 PM EDT |
Quoting:Erin went to YouTube and searched for a Beatles video, and seemed to assume that it would work straight away. When it told her that she needed a plug-in she groaned, but clicked the link they gave her. And the plug in was only a couple of mouse clicks away, directly accessible from her machine. without the need to download anything herself. In point of fact the very same plug in must be installed on windows as well. *GROAN*, Oh well I'll follow the link anyway. |
| theboomboomcars Sep 08, 2009 8:59 PM EDT |
How is it the fault of Linux if adobe doesn't explain what the packages linked to are for? That would be like linking to different install files for different versions of windows without telling the user which executable is for what version of windows. Yep it's totally the fault of Ubuntu that adobe doesn't label things on their site. Though it seems that the last time I installed flash from the browser in Ubuntu it was installed from the repository... |
| jdixon Sep 09, 2009 6:05 AM EDT |
> ... Though it seems that the last time I installed flash from the browser in Ubuntu it was installed from the repository... Undoubtedly, since it's there. |
| claus Sep 09, 2009 10:28 AM EDT |
Quoting:How is it the fault of Linux if adobe doesn't explain what the packages linked to are for? Because it creates the need to have this sort of explanantion in the first place. Imaging Autopackage or the above format would be the de-facto standard for installation: Then, there would be no need to explain different versions. For there would be no need to have different versions for different distributions, in the first place. |
| hkwint Sep 09, 2009 3:21 PM EDT |
I'd like to add I've been trying to track the development of Klik2, but it's a bit silent the last two years. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!