LWN: Comments on "The problem of Firefox in Ubuntu Breezy"

Firefox extensions RPMS

cortana — Mon, 25 Sep 2006 18:20:56 +0000

Yeah, since 1.5 the system has been sane as you describe. In 1.0 and earlier, however, it was much nastier.

The problem of Firefox in Ubuntu Breezy

jzbiciak — Fri, 16 Jun 2006 15:23:58 +0000

Actually, interestingly, we hung onto Netscape 4.7 at work for a very, very long time. Long after Mozilla 1.0 released. Considering that 4.6 and 4.7 were just bugfix releases on 4.5, and 4.5 came out in 1998, that's a pretty long window, and I'd guess pretty typical of corporate environments.

I think it was around 2002 we finally started officially supporting Mozilla for internal web applications in a limited capacity.

Move to a portable app model

jzbiciak — Fri, 16 Jun 2006 12:28:35 +0000

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

mdz@debian.org — Wed, 14 Jun 2006 16:47:53 +0000

There are a number of reasons why that approach wouldn't work for Ubuntu, but they aren't relevant since it wouldn't solve the problem anyway. We can move to new upstream versions without resorting to using precompiled binaries; the issue is that this introduces new bugs, unexpectedly changes behaviour, and breaks configuration changes (such as extensions) for users who are using an otherwise stable product.

Firefox extensions RPMS

gerv — Fri, 09 Jun 2006 23:31:46 +0000

The model you propose is entirely possible; put an extension in the right place using your RPM or DEB, and Firefox will notice and initialise it.

If your distro hasn't packaged the hundreds of extensions on addons.mozilla.org this way, complain to them :-)

Gerv

Root of the problem is Mozilla.org is Windows centric

gerv — Fri, 09 Jun 2006 23:29:47 +0000

> 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

h2 — Fri, 09 Jun 2006 19:42:07 +0000

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.

Root of the problem is Mozilla.org is Windows centric

djao — Fri, 09 Jun 2006 17:34:30 +0000

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

louie — Fri, 09 Jun 2006 12:42:44 +0000

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.

Move to a portable app model

louie — Fri, 09 Jun 2006 12:40:14 +0000

"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

petegn — Fri, 09 Jun 2006 07:06:22 +0000

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 .

The problem of Firefox in Ubuntu Breezy

lacostej — Fri, 09 Jun 2006 05:12:40 +0000

The idea behing stable it to only publish security fixes (or extremely important new features).

Or when an application changes a lot, it becomes very very hard to backport every fix to various stable releases.

Mozilla decides to stop supporting old releases, in part because they don't have the man power to do that. I guess they would do it if they were paid to.

When Microsoft fixes a vulnerability for a package, they have to create and test the fix for various stable versions. Sometimes this applications have been used as basis for third party, so Microsoft doesn't even fully control the applications. Hence, sometimes, the time it takes to solve the problem.

Firefox extensions RPMS

jamesh — Fri, 09 Jun 2006 02:20:04 +0000

... so package the extensions as RPMs or DEBs. If you unzip an extension and place its contents in the right place (/usr/lib/firefox/extensions/$extension-uuid, iirc), firefox will pick it up next time it starts up. Sounds pretty easy to package to me.

Backporting

ncm — Thu, 08 Jun 2006 19:55:08 +0000

Agreed.

If a later version is incompatible with extensions meant for the older, it means they need to make the version number part of the package name. This is totally familiar usage as applied to libraries, and most Debian installations have several versions of many libraries installed.

The problem is that the older versions will be increasingly buggy and increasingly insecure. For many uses -- particularly corporate uses -- these don't matter at all. However, there should be a way to default to keeping the older versions from trying to connect outside the local domain; the proxy configuration might serve. Also, it should be possible to run both the old version and the new version simultaneously.

Root of the problem is Mozilla.org is Windows centric

tzafrir — Thu, 08 Jun 2006 18:57:04 +0000

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? )

The problem of Firefox in Ubuntu Breezy

tseaver — Thu, 08 Jun 2006 15:10:45 +0000

One issue even for the "enterprise" case (and particularly given
Dapper's 5 year support commitment) is that the browser itself
is a *platform* for other enterprise applications; the typical
"version freeze" / stability requirement is in very sharp tension
with those applications' needs.

Who today could rely on only what was in Netscape 4, for instance,
which was the "stable" browser 5 years ago? As a Breezy user, I was
running an on-the-side Firefox 1.5 version, for instance, because I
needed support for newer Web standards, etc. not present in 1.0.8.

Ubunut *does* bundle many of the "major" extensions as .deb files,
which presumably means that the decision to backport the browser
would include backporting the packaged extensions. Users with non-packaged
extensions in their profiles will get those extensions disabled,
typically, until a compatible upgrade is found.

Ergo, +1 for backporting 1.5.0.4 to Breezy.

Search bar

tjc — Thu, 08 Jun 2006 14:15:52 +0000

Hey, I like the search bar at the bottom!

I had 0.9.3 configured to use vi keystrokes, so I could search with "/" and "n" without the dialog window getting in the way.

I have configured the search bar to use "/", but "n" doesn't work (and I find "F3" to be very Windows-like), and it seems to have focus problems which I have not been able to pin down. Sometimes I press "/" and start typing, the search bar doesn't pop, and the text goes to /dev/null, or some other useless place. I have to grab the mouse and click on the client area, and start over. I'm wondering if this is somehow related to using "focus follows pointer" on my window manager...

Root of the problem is Mozilla.org is Windows centric

arcticwolf — Thu, 08 Jun 2006 13:27:41 +0000

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.

The problem of Firefox in Ubuntu Breezy

tao — Thu, 08 Jun 2006 12:51:04 +0000

Well, if x.y.1 -> x.y.2 actually is a minor update that only fixes security problems (or horrible crashes, dataloss, etc), then we *do* accept new minor versions. The problem with Firefox, the Linux kernel, etc, is that the diff from x.y.1 to x.y.2 is BIG, and involves a lot more things than just fixes for bugs.

Maybe if you had to work on a distribution with 15000 packages and try to keep them all in sync, you'd understand the necessity of avoiding major changes in stable releases...

Search bar

jond — Thu, 08 Jun 2006 12:20:36 +0000

Agreed regarding the search bar. Also, because the pop-up was specified in a particular fashion (some kind-of window ownership relation I forget the details of) with something like the ion window manager it was impossible to move the pop-up window out of the way of whatever it was obscuring.

Move to a portable app model

jond — Thu, 08 Jun 2006 12:16:34 +0000

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.

The problem of Firefox in Ubuntu Breezy

jpetso — Thu, 08 Jun 2006 11:01:20 +0000

This issue shows again how broken that whole "freeze the versions"
concept actually is.

It's a shame that those distros don't even update minor versions
(x.y.1 -> x.y.2) and instead patch everything themselves. I'm actually
surprised that this problem has been able to be ignored for so long, but
sooner or later it has to come up. You can't seriously maintain security
updates for longer than the mainline applications do, and then you're
supposed to upgrade to the next major version, because the previous one
is outdated, unmaintained and plain obsolete anyways.

Security updates for multiple years may be a good idea for server
software and the base system, but it's not viable for desktop
applications. IMHO the users should just bite the bullet and cope with
the implications of a major upgrade. It should not be up to the distro to
maintain what is no longer maintained.

This is my only major gripe against binary distros like (K)Ubuntu. I mean
hey, Gentoo can also provide a stable branch while continuously updating
their software, why can't any of the binary distros do something similar?
Damn those stability gurus.

The problem of Firefox in Ubuntu Breezy

nix — Thu, 08 Jun 2006 10:44:55 +0000

Konqueror extensions (KParts) are C++ (although of course you can write most of them in any language GCC can handle and specifically any language there are KParts bindings for).

It wouldn't be too terribly difficult to write a scripting language KPart, but there are security concerns: Konqueror can do anything KDE can do...

The problem of Firefox in Ubuntu Breezy

jschrod — Thu, 08 Jun 2006 09:18:05 +0000

How about using SeaMonkey? It's what I do, because the Firefox developers obviously target a user group where I'm not in. One can always just install the Browser component, if one wants a smaller installation.

Cheers, Joachim

Firefox extensions RPMS

Richard_J_Neill — Thu, 08 Jun 2006 03:04:12 +0000

The real problem is that firefox uses a stupid extension model. There are some terrific firefox extensions available. However, I want to use my package manager to control them!

Each extension should be in a RPM (or deb), located in a central repository, and, installed system wide, and updated by the distro. In this case, the issue would vanish.

Search bar

Mithrandir — Thu, 08 Jun 2006 02:11:33 +0000

Most of the destabilisation I've noticed seems to be related to upgrades not playing so nicely with your old profile. If you're seeing a lot of crashes often you can improve things by moving away your old profile directory (in .mozilla/firefox on my box), then opening firefox to create a new profile, then copying back the important stuff from your old profile.

Firefox still won't be completely stable, but it helps.

Root of the problem is Mozilla.org is Windows centric

ronaldcole — Thu, 08 Jun 2006 01:25:24 +0000

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.

The problem of Firefox in Ubuntu Breezy

man_ls — Wed, 07 Jun 2006 23:00:11 +0000

I don't. Why? They publish the OS and the applications, so I don't see how it relates to the original posting.

Look at Red Hat, RHEL, and Mozilla...

barryn — Wed, 07 Jun 2006 22:55:55 +0000

Red Hat has been dealing with this conundrum longer, in the form of RHEL and Mozilla. It may be instructive to look at their history in this regard.

RHEL 2.1 shipped with Mozilla 1.0.1. It was updated to 1.0.2, then 1.4.x, then 1.7.xx. It's currently at 1.7.13. RHEL 3 and 4 started with newer Mozilla releases, but they have also been upgraded likewise.

The Red Hat policy AFAIK is to avoid upgrading to newer upstream versions whenever possible, so I guess Red Hat *really* found it way too hard to keep backporting Mozilla fixes.

It will be interesting to see what Red Hat does with Firefox in RHEL 4; that is currently at 1.0.8, like Ubuntu Breezy.

Root of the problem is Mozilla.org is Windows centric

iabervon — Wed, 07 Jun 2006 22:45:33 +0000

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

h2 — Wed, 07 Jun 2006 22:25:44 +0000

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

jmorris42 — Wed, 07 Jun 2006 21:58:34 +0000

> 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.

Search bar

corbet — Wed, 07 Jun 2006 21:56:12 +0000

Hey, I like the search bar at the bottom! I can finally search for stuff without the dialog blocking what I was trying to find...

Crashes are a pain, though; Firefox has seemed a bit wobbly for a while now.

Move to a portable app model

h2 — Wed, 07 Jun 2006 21:55:32 +0000

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

nlee — Wed, 07 Jun 2006 21:51:09 +0000

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.

The problem of Firefox in Ubuntu Breezy

tjc — Wed, 07 Jun 2006 21:50:51 +0000

In some ways version 0.9.3 was the high-water mark for Firefox (except for the security issues, of course). IIRC that was last release without that damnable search bar on the bottom of the window, and it didn't seem to crash too much.

The problem of Firefox in Ubuntu Breezy

h2 — Wed, 07 Jun 2006 21:50:31 +0000

I use a lot of extensions, i depend on them for development, konqueror as a base is better I think than firefox as a base, but the extensions just can't be matched, that's because konqueror extensions have to be done in c or c++, can't remember which, they don't have an extension scripting language like firefox has. Currently only adblock is ported. Which is great, but it's not good enough, sadly.

Konqueror really benefited from the applewebkit upgrades of safari in khtml, no doubt about that, it's very solid now.

I don't know where you got that idea about firefox vs MSIE, that's just some MS spin you fell for, firefox does not have active x, which is a core access to the OS. Firefox will never have that, so firefox will never have that deep level vulnerability. Firefox has vulnerabilities, and if you read them carefully, most are not very serious, not like somebody tricking active x to install a rootkit into windows. No firefox user I have switched from MSIE has experienced ANY spyware infections. All MSIE users have these, no matter what MS does to try to stop it. XP SP 2 did not succeed in securing it, nothing MS has done has succeeded, because MSIE is insecure by design, it can never resolve that issue as long as active x exists.

The problem of Firefox in Ubuntu Breezy

lacostej — Wed, 07 Jun 2006 21:48:40 +0000

I think that now people will understand why it sometimes takes time for Microsoft to get a patch out.

Move to a portable app model

h2 — Wed, 07 Jun 2006 21:44:20 +0000

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.

The problem of Firefox in Ubuntu Breezy

cventers — Wed, 07 Jun 2006 21:40:31 +0000

I feel you. But I do great without extensions, so I use Konqueror
exclusively.

I could swear that Konqueror history sped up in 3.5.3, but maybe it was
just subliminal. In any case, Konqueror's history has always been
_faster_ for me than Firefox's (as well as Konqueror's rendering and
startup), so Firefox eating boatloads more memory seems silly (not to
mention the disturbing appearance that all the early claims of Firefox
being more secure than Internet Explorer appear, to my eyes anyway,
completely false).

One of the nice things about the KDE4/Qt4 efforts is that we're likely to
see apps like Konqueror ported over to Windows. I don't personally care
since I don't use the proprietary OS, but having an open source browser
as awesome as Konq available on Windows means more mainstream competition
for Firefox, which will hopefully force them to get their act together.