LWN.net Logo

Move to a portable app model

Move to a portable app model

Posted Jun 7, 2006 21:10 UTC (Wed) by madscientist (subscriber, #16861)
In reply to: Move to a portable app model by nlee
Parent article: The problem of Firefox in Ubuntu Breezy

I don't think the concern with backporting FireFox really revolves around system dependencies. I think mainly it's because the model for stable releases in Ubuntu and Debian has always been to never upgrade to newer versions, but ONLY to backport fixes to existing versions. The very definition of "stable" to those distributions means no new major versions. It would be a major break in policy for them.


(Log in to post comments)

Move to a portable app model

Posted Jun 7, 2006 21:26 UTC (Wed) by nlee (guest, #730) [Link]

Maybe that is true. Firefox might be a special case however. For example is the Debian project willing to maintain the Firefox extensions library as well? Extensions also provide a vector for security, none of the new extensions work with 1.0.4

Regardless if the do decide to change policy on this one package, dependency are going to cause issues. There is a long list:
http://packages.debian.org/stable/web/mozilla-firefox
http://packages.debian.org/unstable/web/firefox

Move to a portable app model

Posted Jun 7, 2006 21:38 UTC (Wed) by madscientist (subscriber, #16861) [Link]

Well, the extensions library is actually a good example of why they don't want to upgrade (if it's included in the package): anyone who's written any extensions to the 1.0.8 FireFox for Debian stable will surely be P.O.d if a "security update" installs a major version upgrade of FireFox which breaks all of her work that depends on the older version. It's exactly these sorts of situations that the stable policy Debian/Ubuntu have are designed to guard against.

As for the prerequisites for the package, it's not a problem for a package to have a lot of prerequisites per se. It's only a problem if either of two things is true: (a) other packages depend on the to-be-replaced package, since that means they all must be upgraded as well. I don't think FF is in this category.

Or (b), the new version of the to-be-replaced package requires some new support libraries or it won't work anymore, since that means you have to upgrade all those prerequisites first. I'm pretty sure even FF 1.5 will build OK with the versions currently in Debian Stable/Ubuntu Breezy. You won't have to upgrade all those packages (and everything they depend on, etc.)

Move to a portable app model

Posted Jun 7, 2006 21:44 UTC (Wed) by h2 (guest, #27965) [Link]

Easy enough to test, install tarred firefox 1.5 on debian stable, if it runs fine, that's the answer. I might try that in the next few days to see, I've been wanting to do a debian stable or etch install anyway, might as well do both and see how that stuff works. My guess is firefox will install fine as a tarred thing, maybe not the deb, but that's easy to see too by a simple apt-get install firefox -s test.

The extension thing is another matter, but at some point you have to adapt yourself to that situation, every single new version, 1.5.3->1.5.4 for example, can break an extension, extension compatibility is tested every time you upgrade version no matter what.

Very few extension developers pay much attention to older versions, and it's up to them and only them to do that, there's no way anyone else could handle doing extension backward compatibility testing, that's not realistic, and won't happen. You're much better off using the latest firefox, with its glitches, especially if you use extensions heavily, but most people don't do that.

Move to a portable app model

Posted Jun 9, 2006 12:40 UTC (Fri) by louie (subscriber, #3285) [Link]

"Easy enough to test, install tarred firefox 1.5 on debian stable, if it runs fine, that's the answer."

hahahahaha. That's such a ... charmingly naive approach to QA. What about:
* the universe of plugins?
* epiphany/galeon?
* yelp?
* anything based on the Java SWT?

You have to test all of those too. And 'testing' something that depends on a browser is a hit or miss thing, given that a browser is so large.

All of the major distros are going to have to have a chat with moz.org at some point if they see themselves as seriously doing long-term desktop support, because it is clear that moz.org doesn't realize how deeply flawed their support policy is for those distros. Ubuntu is just the only one having this discussion in public right now.

Move to a portable app model

Posted Jun 9, 2006 19:42 UTC (Fri) by h2 (guest, #27965) [Link]

so how much are those distros contributing to mozilla to get that long term support? With the exception of debian, we are after all talking about for profit corporations here. So if they want that type of support, I suggest they get together and create a few staff positions at mozilla.com whose sole role is maintaining old mozilla/firefox versions.

If they don't want to pay for this, then their feelings on this question are fairly irrelevant. And what would that cost, tops? To maintain security patches for a handful of gecko based browsers? Probably one person could do it, so between redhat, suse, mandriva, etc, what are we talking about to get this desired security patch support? $10,000 a year? Maybe 20k if they hired two people?

This isn't very hard to do, if you need something done that nobody wants to do, pay someone to do it. And if you need it done, for reasons of corporate network stability, then pay for it. This isn't complicated.

If redhat/suse/mandriva can't afford to pay this pittance then they are in the wrong business and should contemplate entering into a new line of work, maybe ice cream sales or something.

Move to a portable app model

Posted Jun 16, 2006 12:28 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link]

Actually, as I see it, since the Mozilla folks get $$ every time someone searches at Google w/ their browser, I'd say the fact that distros choose to make Firefox their default browser is payment enough.

Move to a portable app model

Posted Jun 7, 2006 21:51 UTC (Wed) by nlee (guest, #730) [Link]

You make a very valid point. One response might be, how do we know any backport feature don't break the current set of firefox extensions in the debian archive?

It is a hard choice for Debian. The "unknown" security fixes in the latest and probably forth coming Firefox versions, make things very difficult. I guess this is one of the reasons I prefer Ubuntu for the desktop. They have a tight release cycle.

Move to a portable app model

Posted Jun 7, 2006 21:55 UTC (Wed) by h2 (guest, #27965) [Link]

Not to sidetrack, but this is why I prefer kanotix, it's a direct access to sid, usually not much more than a week goes by before I have the latest tbird or firefox, but at the cost of being in an unstable pool. And it's unstable, no doubt.

The same problems, by the way, exist for konqueror, kmail, to upgrade those you have to upgrade all of kde, so it's actually worse than firefox/tbird.

But significantly less people use those than firefox so it doesn't hit the news in this way.

Move to a portable app model

Posted Jun 8, 2006 12:16 UTC (Thu) by jond (subscriber, #37669) [Link]

The issue here is it now being impossible to separate out changes made upstream that are security fixes and those that aren't. afaik, the problem isn't the same for KDE, because they have a security policy more in-line with Debian's.

Move to a portable app model

Posted Jun 7, 2006 21:31 UTC (Wed) by h2 (guest, #27965) [Link]

"I think mainly it's because the model for stable releases in Ubuntu and Debian has always been to never upgrade to newer versions, but ONLY to backport fixes to existing versions."

Yes, this is discussed frequently, it's a big problem for debian, firefox/mozilla just doesn't play well in this environment. Part of the problem is that the biggest firefox installed base is windows, and windows firefox uses autoupdate now, since 1.5. This makes sense in windows, since it's the only way to get users to actually apply security patches in a timely manner, but the model does not work for linux stable stuff, like debian, ubuntu, or whatever.

Since the risk of having an insecure browser, the number two access point for insecurities, email being number one, far outweighs any questions about not upgrading version in a stable pool, debian etc will have to bend on this one long term, since having users use unsafe browsers is just not a very good idea.

It's not as big a deal as they make it sound, it's just a browser, it's not like you are installing a new gnome or kde desktop, a new apache, or whatever. It's a standalone application more or less, like thunderbird.

It's unfortunate that mozilla foundation moved in this direction, but that's life, unless they decide to change that, it's unlikely to get resolved to anyone's satisfaction, I know it drives the debian security guys up the wall.

Root of the problem is Mozilla.org is Windows centric

Posted Jun 7, 2006 21:58 UTC (Wed) by jmorris42 (subscriber, #2203) [Link]

> Yes, this is discussed frequently, it's a big problem for debian,
> firefox/mozilla just doesn't play well in this environment. Part of the
> problem is that the biggest firefox installed base is windows,

Exactly. Mozilla.org has never really cared about the needs of the UNIX/Linux ports, only about Windows. This has only grown worse since they became attached to the cashflow from Google.

Generalizing your statement I'd say Mozilla products doesn't play well in enterprise environments period. Enterprise users value stability, reliability and long well established service cycles over new shiny features. Note that Debian and Ubuntu aren't alone in being abandoned by Mozilla.org. See the annoucement yesterday that RHEL3 is dumping Mozilla for Seamonkey for the same loss of upstream errata problems.

Personally I think dumping Firefox from any stable release is something to consider given their stated positions on errata. Too bad there isn't any viable replacements. There is a lesson here about over dependence on a single point of failure, especially one that makes no bones about our preferred platform being an afterthought. Suspect they would just drop the Linux & UNIX ports to shut us up is they didn't know it would just cause a fork, or worse, a whole new browser project.

Or perhaps the idea in the original post should be looked into, having the major distros share the burden of doing their own security patches has merit. This would probably require Mozilla.org to at least be willing to share details on the security issues though.

Root of the problem is Mozilla.org is Windows centric

Posted Jun 7, 2006 22:25 UTC (Wed) by h2 (guest, #27965) [Link]

While not disagreeing with your points, it's also important to keep in mind that firefox basically singlehandedly kept the internet free. MS was VERY close to forcing us into an active x powered web, with MS created standards, vbscript, you name it. We went from there to the new msn search site being done in xhtml 1.0 strict, quite a leap in my opinion.

So I have to cut mozilla some slack in these areas.

The enterprise points are true, but will evolve over time I think, realistically, linux on the desktop is still at a very early phase in most parts of the world, despite many well publicized victories.

I know at least one major issue with 1.5 on linux came because the main developer worked on gnome, not kde. And it shows. Hopefully the portland stuff will standardize the external features like file dialogues etc to the desktop that is running it.

I also know that firefox and thunderbird made my switch from windows to linux much easier, since my most commonly used apps were there, with the same extensions and bookmarks etc, it wasn't nearly as big a jump as it would have been.

So it's improving.

Given the current cash flow of mozilla firefox, it might not be a bad idea to start putting some of those resources towards things like paying people do to really boring work like patching old versions. That's just not something most volunteers have any interest in doing.

Re the enterprise, also keep in mind, msie, while very well supported version to version over time, made massive jumps, from 3 to 4 to 5 to 5.5 to 6, in about 5 years. Each was a huge change, especially 4 and 6. It was only because MS believed that they had locked in the market that they stopped active development until competition from firefox forced them to reluctantly restart the ie team for ie 7. Which will also break a lot of compatibilities.

Given the speed of change of the web, and the fact that security vulnerabilities can and will be found, it might be that the stable distros and mozilla might need to bend a little bit towards each other.

Root of the problem is Mozilla.org is Windows centric

Posted Jun 7, 2006 22:45 UTC (Wed) by iabervon (subscriber, #722) [Link]

To be fair, the autoupdate of firefox actually works amazingly well on Linux. I'm running a copy of firefox that I downloaded and untarred in a random subdirectory of my home directory, and symlinked into ~/bin, and it's autoupdated (when I decided to take the update) multiple times, having detected by itself that a new version is available. I don't think I've seen any other software for any operating system that's been able to upgrade itself without being installed.

Mozilla doesn't play well with system updates, but it's essentially to the point where it's not necessary for systems to deal with it at all, since users could just take care of it independantly.

Root of the problem is Mozilla.org is Windows centric

Posted Jun 9, 2006 12:42 UTC (Fri) by louie (subscriber, #3285) [Link]

This would all be well and good *if nothing depended on firefox*. But from day one firefox has also been sold as a platform for people to develop on. And that will never happen in any large-scale way with their cavalier attitude towards API/ABI compatibility and upgrades.

Root of the problem is Mozilla.org is Windows centric

Posted Jun 8, 2006 1:25 UTC (Thu) by ronaldcole (guest, #1462) [Link]

RHEL3 should also either upgrade or dump their ancient and practically unusable SpamAssassin for the same reasons. Enterprise distros didn't seem to forsee the very real consequence of bitrot in their distros due to their "backport only" policies.

Root of the problem is Mozilla.org is Windows centric

Posted Jun 8, 2006 13:27 UTC (Thu) by arcticwolf (guest, #8341) [Link]

You don't seem to understand the purpose of enterprise distributions.

The whole *point* of these is that users (i.e., the companies using them, not the individual employees and end users) can be confident that things do not randomly change when they install updates for the distro.

Anyone who wants newer software versions can upgrade to a newer RHEL (or whatever); but those who'd rather stay with the versions they are already using and which they know work should not be forced to upgrade. New features and changes always have a chance to contain nasty surprises, and that's exactly what you don't want in these situations.

Root of the problem is Mozilla.org is Windows centric

Posted Jun 8, 2006 18:57 UTC (Thu) by tzafrir (subscriber, #11501) [Link]

However an ancient SpamAssassin is much less effective at killling spam. Upstream keeps changing the format of the database, so you can't use a recent rules set with an old SpamAssassin. Many spammers have already adapted to that old version.

I also wonder what about security holes in the version of Mozilla included in RHEL 2.1 (or is it actually Netscape 4? )

Root of the problem is Mozilla.org is Windows centric

Posted Jun 9, 2006 17:34 UTC (Fri) by djao (guest, #4263) [Link]

Nothing in the world is preventing you from upgrading to the DAG repository's spamassassin-3.1.2-1.el3.rf.i386.rpm, which, although distributed by a third party, is specifically designed to be compatible with RHEL3.

You can sync to the DAG repository using your choice of apt, yum, up2date, or just use plain command line rpm.

A stable distribution using a backport policy gives you the option of remaining with the previous version. This does not in any way prevent you from upgrading to a new version yourself -- you have the option of doing either. By contrast, a distribution which tracks the upstream releases does not give you that option. Many people much prefer having the ability to choose. This is the main reason why backport policies are popular.

If you don't like having the option of going either way, you are always free to choose (!) a distribution like gentoo or fedora that tracks upstream releases closely.

Root of the problem is Mozilla.org is Windows centric

Posted Jun 9, 2006 23:29 UTC (Fri) by gerv (subscriber, #3376) [Link]

> Exactly. Mozilla.org has never really cared about the needs of the
> UNIX/Linux ports, only about Windows.

That's demonstrably rubbish. Many of the developers use Linux, and it's a Tier 1 platform for us (along with Windows and Mac OS X) which gets full support and simultaneous release. And I don't see the supposed connection with Google which was implied by your cheap shot; perhaps you could elaborate?

> Mozilla products doesn't play well in enterprise environments period

That's not surprising; Firefox is not after the enterprise market. If enterprise distro makers want to use our codebase to make something for the enterprise, they can, but they may need to spend those lovely enterprise subscription fees on doing some work on it.

> See the annoucement yesterday that RHEL3 is dumping Mozilla for Seamonkey
> for the same loss of upstream errata problems.

This seems entirely reasonable to me. Mozilla is an end-of-lifed product; Seamonkey is the community continuation. Props to the Seamonkey folks for doing a professional enough job that RHEL have come knocking.

> This would probably require Mozilla.org to at least be willing to share
> details on the security issues though.

There are many distribution representatives on our security email lists, including people from Debian (don't know about Ubuntu off the top of my head, but I'd be surprised if they weren't). Applicants from other distros should contact Dan Veditz.

Gerv

Move to a portable app model

Posted Jun 9, 2006 7:06 UTC (Fri) by petegn (guest, #847) [Link]

well they got 2 choices ..

Run with the problem version or use a new version i can not see any great problem with that .

Stick with the systems ideals stick with the problem step outside the systems ideals solve the problem simply .

Pete .

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds