Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration

Posted Jan 26, 2011 6:36 UTC (Wed) by xav (guest, #18536)
Parent article: Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration

A common "app installer" looks to me just like a way of bypassing all the efforts distro put into distros packaging. Nowadays you have a coherent set of packages, with matching versions, security audit, and maintenance. With an "app installer" you're straight into Windows world with random spyware-laden apps installable with a simple click.
I don't think it's a progress for Free Software in general.

Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration

Posted Jan 26, 2011 6:59 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (13 responses)

That makes no sense. App installer is merely a abstraction layer over the native package manager.

Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration

Posted Jan 26, 2011 9:08 UTC (Wed) by xav (guest, #18536) [Link] (12 responses)

This has nothing to do with the technical side of installation. Let me try to explain my point of view to you:
- when running e.g. Debian, Ubuntu or Fedora, the end-user has an expectation of stability and security
- that's because the pool of package managers is known, they all talk together and respect a set of common rules, and are reactive to events (e.g. security alerts)
- and that's because the end-user is sort-of restricted in what it can install on its machine, that is packages from the distribution; only so-called power users will install alternative packages
- now you want anyone being able to set up a blinking webpage telling users "install that shiny new GonzoMediaPlayer to be able to watch football matches for free"
- there you are, your rock stable linux distribution is now down to a Windows machine, with anyone being able to distribute malware for any distribution, and unknowledgeable end-users' systems plagued with it

I see the fact that executables must go through a distro-specific packaging process first as a virtue, not a defect. Apparently not everyone agree.

Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration

Posted Jan 26, 2011 9:52 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (9 responses)

Clicking on a web page doesn't fundamentally change the process. It can just be a call to a repository. Besides, it is illusion to think that end users, especially desktop users just stick with the apps in the repository or that a single repository can provide everything a user wants. There are tons of apps or apps in the version that users want that are outside any mainstream Linux distribution repository. They go click and add random repositories all the time and that is really no different than clicking a random web page to install a app. If desktop Linux becomes mainstream, we are going to have to tackle the malware problem differently than trying to enforce a one repository rule.

Let's look at one aspect of the problem with the current model: If Firefox 4 releases tomorrow and I am using Windows or Mac OS X, I can install it immediately and in Linux, one usually has to upgrade their entire distribution. In Linux, there is no fundamental differentiation between system packages and even leaf applications. This is a problem that one has to solve and the current methods are awfully weak. The system admin point of view is great for servers but desktops need a different solution.

Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration

Posted Jan 26, 2011 10:08 UTC (Wed) by niner (subscriber, #26151) [Link] (1 responses)

What you describe already exists. It's openSUSE's One-click-install. You click a link and the handler subscribes you to the repository and installs the requested package along with it's dependencies. You can then select if you want to stay subscribed to that repository to for example receive future updates.

Makes staying up to date with for example Firefox trivial.

Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration

Posted Jan 26, 2011 10:36 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

I am aware of openSUSE's solution as well as others like Ubuntu's PPA etc but it has to be available for more than just one distribution. That is sort of the point of getting the different distributions together and hash out the problems and solutions.

Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration

Posted Jan 26, 2011 11:41 UTC (Wed) by nicooo (guest, #69134) [Link] (1 responses)

>Let's look at one aspect of the problem with the current model: If Firefox 4 releases tomorrow and I am using Windows or Mac OS X, I can install it immediately and in Linux, one usually has to upgrade their entire distribution.

Which model are you referring to? I'm using gentoo and this works fine. The nice thing about distributions is that there are different models.

Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration

Posted Jan 26, 2011 12:15 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

It thought it was obvious that I was referring to the mainstream distributions that are part of the discussion in the article. The problem with the different models is that it very much a pick your poison kind of thing. Gentoo isn't something one would recommend even if the users like having the latest applications.

one-click third-party software installs

Posted Jan 26, 2011 21:10 UTC (Wed) by jthill (subscriber, #56558) [Link]

I think it's plain this notion produces exactly the same sequence as what produces the Windows nightmare: anyone can construct a web page or email and put anything at all at the fetch URL. No.

Clicking on a web-page does fundamentally change the process. It's a little weird to newbies. It takes manually fiddling with system files, unless somebody's already made an update-sources.list protocol. imho that's just barely enough to stave off the Windows nightmare now.

Because installing third party software with apt means running root scripts directly from whatever's behind the flashy link, does it not?

I think a third-party install scheme that protects the system and the user has to be cooked up before considering this.

Say, for third-party-signed packages create a new user/group combo, that can be tied to an "origin" key that must also have signed the package-signing key. For unsigned packags just use "nobody" or "third-party" or something, they don't care enough they can go in the swamp.

Something to that effect, for sure:: you want to also protect these packages from each other.

Run the package scripts on the package's userid, with a special service to install links into the system hierarchy. Apps will also want some writable .config or .local or whatever it is now subdirectory, also prompt users to grant access. Put the app's per-user config one level down, .config/example/example-config, so metadata is inaccessible to the app. Log a copy of the outside-/opt actions to syslog, and show them to the user in like a three line text box with a that's all indicator. Offer "here's what's installed on your system. I've logged it to syslog. Want a copy?" <Save install log> <Thanks, I'm good>.

The access restrictions will stop most if not all of the Windows uninstall nightmare. Say add a product key in addition to the package key, then tag the directories with the responsible key. .config/opt/foo/.PRODUCT_ID_fingerprint doesn't match any installed package's fingerprint? It's stale. Make the tag file owned by root, the product's group, 744 so the user and app can verify, another service to update contents from newly-installed packages from the same origin. That's easily subvertible by the user

That, or convert everyone to kerberos...

Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration

Posted Jan 27, 2011 0:17 UTC (Thu) by garloff (subscriber, #319) [Link] (3 responses)

> If Firefox 4 releases tomorrow and I am using Windows or Mac OS X, I can
> install it immediately and in Linux, one usually has to upgrade their
> entire distribution.

You happen to not have spotted openSUSE Build Service yet.
It's dead simple to build packages for various distributions that you can simply drop in to older distros.

The main limiting factor here is that once you build on newer shared
infrastructure it becomes more tedious ... but the FFox4 example is one
where this works rather easily.

Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration

Posted Jan 27, 2011 0:23 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

I am aware of that as I have already indicated before but If I am a end user, I don't want to be building packages in any build service. That's just ridiculous. If it is not in my distribution repository then I just want to install Firefox 4 from a obvious place. mozilla.org would the most obvious location.

Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration

Posted Jan 27, 2011 0:27 UTC (Thu) by garloff (subscriber, #319) [Link] (1 responses)

Well, I don't suggest end users should build most of their software themselves. But someone can do it. Most obvious choice would be the
upstream community itself.

Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration

Posted Jan 27, 2011 1:57 UTC (Thu) by vonbrand (subscriber, #4458) [Link]

Upstream has enough work cut out for them just getting the base to work (and fix bugs), asking them to also track whatever a few hundred (eo even just a dozen "mainstream") distributions are up to is just over the top.

Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration

Posted Jan 26, 2011 14:11 UTC (Wed) by sorpigal (guest, #36106) [Link] (1 responses)

Distro package repositories are nice but cannot scale to "everything." A solution that doesn't devolve into the Windows mess is possible; I think this is a useful related discussion.

Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration

Posted Jan 27, 2011 2:28 UTC (Thu) by vonbrand (subscriber, #4458) [Link]

Part of the benefit of distribution repositories is exactly that they don't package everything: It is a way of filtering out crap.

Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration

Posted Jan 26, 2011 7:46 UTC (Wed) by skvidal (guest, #3094) [Link] (8 responses)

I think you're exactly right and from the grapevine I know this was raised.

Deep down a number of folks want an 'app store' just like osx has, of course.

And they want to be able to ship 'bundles' so they don't have to worry about things like dependencies at all.

What everyone fails to remember is how much of a godawful nightmare bundles are to maintain.

Chase down a zlib security bug through 1000 individually pkged versions of zlib in the bundles on your systems. It's a disaster area.

Everyone remember chasing down the timezone change 4 yrs ago in every copy of java that was littered all over your system? Think about that but for EVERY app and having to figure out if this is zlib 1.2.3 or actually 1.1.9.

Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration

Posted Jan 26, 2011 10:57 UTC (Wed) by mjthayer (guest, #39183) [Link] (7 responses)

> What everyone fails to remember is how much of a godawful nightmare bundles are to maintain.

> Chase down a zlib security bug through 1000 individually pkged versions of zlib in the bundles on your systems. It's a disaster area.

What I always wonder re this objection is why a bundle has to be done the same at source and binary levels. In the hope of clarifying that, imagine a Gentoo-like source distribution and a system of building bundles out of that which pulls all the necessary source packages, compiles them and bundles them. Then propagating the zlib security fix is as simple as (something like) "emerge bundleworld". That said, you can't put all dependencies in a bundle (well you can, but then it becomes a virtual machine appliance instead), and if you accept that anyway it might make sense to make things which are updated a lot for security (don't think zlib is in this category) into external dependencies to save re-downloading your whole system every week.

Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration

Posted Jan 26, 2011 12:05 UTC (Wed) by dgm (subscriber, #49227) [Link] (6 responses)

If you could do that it would mean you had proper dependencies before bundling. Why throw away all that information? Wouldn't it be better to just ship the packages unbundled and update as usual?

Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration

Posted Jan 26, 2011 13:02 UTC (Wed) by tzafrir (subscriber, #11501) [Link] (1 responses)

So Firefox should not bundle Xulrunner, and you should wait for Thunderbird to be ported to the new Xulrunner, or remove it from your system.

Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration

Posted Jan 27, 2011 2:26 UTC (Thu) by vonbrand (subscriber, #4458) [Link]

So you ask for collaboration between distributions to be gotten by fobidding upstream packages to collaborate and share pieces... way to go.

Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration

Posted Jan 26, 2011 13:02 UTC (Wed) by kleptog (subscriber, #1183) [Link] (1 responses)

I think the real problem is that the app developers know the dependencies but have no way of ensuring that they're installed. Even if you know the package name in a particular distribution, there's no guarantee the version you want even exists there (see endless versions of libssl for example).

Binary compatibility is really hard and most people don't bother. About the only library I know that pays any attention to it glibc, which goes to great lengths to ensure you get the symbol you linked against rather than whatever version is newest. Most libraries just increase the version number and ship it.

Many of the problems are solved. For example, we all more or less agree on the FHS so files end up in more or less the same place. LSB was in principle a great idea, but obsolete before it was done. What you need is something moves much faster.

Lets suppose that a few of the faster distributions (e.g. Mandriva, Ubuntu & Fedora) got together once a year and drew up a list of the 50 most common libraries and agreed on versions they would ship. Each distribution would be free to provide other versions, as long as that particular version would also ship. This might help (or not :) ).

Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration

Posted Jan 26, 2011 14:27 UTC (Wed) by sorpigal (guest, #36106) [Link]

This is the old "we need a common platform" argument and whether it's true or not doesn't seem to be important because we don't seem any closer, today, to actually doing it than we were ten years ago. I don't know that you can get cats to march in a line that straight and I think other solutions should be explored instead.

Creating platforms is a problem that has been up to now in the domain of the distribution. Most non-enterprise distributions don't actually worry about it at all, much less do it (except by chance). To have a third party dictate (or suggest) a platform to distributions is hard because (a) the distributions don't know what a platform is and (b) they won't like dancing to someone else's tune, especially if the advertised payoff is "More work for you but less work for people who are not you."

Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration

Posted Jan 26, 2011 14:34 UTC (Wed) by mjthayer (guest, #39183) [Link] (1 responses)

> If you could do that it would mean you had proper dependencies before bundling. Why throw away all that information? Wouldn't it be better to just ship the packages unbundled and update as usual?

This is just my answer, not an answer from a wise person who has thought much about the matter. Mainly, I would say, because it reduces complexity. A FLOSS-style binary distribution requires masses of testing to ensure that every component works well with every other. Using bundles with reduced dependencies reduces the testing burden on the maintainer, even before you worry about cross-distribution installation.

Then there is the traditional argument that bundling dependencies frees you from worrying what is or is not available on the user's distribution. You just bundle it yourself, test your package and are happy.

Plus my personal feeling is that the package database on a FLOSS system is always a potential place for things to go wrong. Thankfully I think this has only hit me once (or maybe twice), but if it does get corrupt you are in for a massive fixing (or re-installing) session that would be much less painful on a system mainly using bundles. And from a cleanliness point of view, it is much easier to have an overview of what a system mainly based on bundles has on it. I must admit that that last point is what I find most attractive about bundles - they give you much more of a feeling of being in control of your system while (by) structuring (if not reducing) its overall complexity.

Untz: Results of the App Installer meeting, and some thoughts on cross-distro collaboration

Posted Jan 27, 2011 2:17 UTC (Thu) by vonbrand (subscriber, #4458) [Link]

Bundles are either massive duplication (and innumerable opportunities for security (and other) bugs that get never fixed) or require something like the current dependency handling system, but on weapons-grade steroids (you'd have to track not only one set of dependencies, but potentially dependencies for each single package in the system separately). I just don't see anything but downsides.

Yes, the package database is a single point of failure for a Linux distribution. Yes, in the 15 or so years of Red Hat (and derivatives) use I did have my half dozen problems with broken RPM databases, but AFAIR just once there was no reasonable way to fix it without a full reinstall (and that was due to a disk problem, that thrashed the system regardless). Sure, fixing the database wasn't trivial; but the technology used has gotten way better over time, the last thrashed RPM database was quite some time back.