Slashdot Mirror


Mozilla Puts Tiger Out To Pasture

Barence writes "Mozilla is ready to exorcise support for Mac OS X 10.4 from Firefox's development code, closing the door on Apple's aging OS. The foundation stopped supporting 10.4, codenamed Tiger, in September 2009, but, according to Josh Aas, a Mozilla platform engineer, 'we left much of the code required to support that platform in the tree in case we wanted to reverse that decision." We had come to a point where we need to make a final decision and either restore 10.4 support or remove this (large) amount of 10.4 specific code,' he notes on the Mozilla developer planning forum."

8 of 440 comments (clear)

  1. Re:Wait, I don't undersand this... by carlhaagen · · Score: 5, Informative

    Apple moves at a completely different pace when it comes to updates and reworking their OS, compared to Microsoft. The PPC part is just one bit, but Leopard does run on PPC machines, so Firefox will still contain both PPC and x86 code for the OS X version. The problem is more that there were a lot of favorable improvements taking place in 10.5 almost coercing developers to make use of them, combined with lots of API-level stuff from the 10.4 selection going deprecated.

  2. exorcise? by Anonymous Coward · · Score: 3, Informative

    excise

  3. Re:Wait, I don't undersand this... by eihab · · Score: 4, Informative

    I'm not a Mac person so I don't keep track of every update, but why is it that OSX 10.4, a version which only came out in 2005 according to Wikipedia, has so much code that prevents Mozilla from trivially continuing to maintain compatibility in Firefox?

    According to the article:

    Adding 10.4 support back to mozilla-central would mean switching back
    to ATSUI from Core Text, switching back to gcc-4.0 from gcc-4.2, and
    doing a bit of porting work for code that has been added to the tree
    since we dropped support for 10.4. Other areas where 10.4 support
    consumes our time, makes our code more complex or error-prone, and/or
    limits our capabilities include complex text input (IME), out-of-
    process plugins, printing, native menus, and Core Animation.
    Furthermore, Apple's upcoming JavaPlugin2 will not support Mac OS X
    10.4.

    Sounds like OS X's API has evolved quite a bit in the last 5 years.

    The weird part in the article was when the Mozilla platform engineer said "Neither Safari nor Chrome have to deal with this". I don't know about Chrome but from Apple's website it looks like Tiger is still supported for Safari 4:

    Tiger System Requirements

    Mac OS X Tiger 10.4.11 and Security Update 2009-002 or later

    --
    If you can't mod them join them.
  4. Re:Nooo ! by bheer · · Score: 4, Informative

    Here's a taste of the changes between Tiger and Leopard/Snow Leopard. Even though Leopard->Snow Leopard was (relatively) incremental stabilization and refinement, remember that Leopard was a *big* upgrade.

    Adding 10.4 support back to mozilla-central would mean switching back to ATSUI from Core Text, switching back to gcc-4.0 from gcc-4.2, and doing a bit of porting work for code that has been added to the tree since we dropped support for 10.4. Other areas where 10.4 support consumes our time, makes our code more complex or error-prone, and/or limits our capabilities include complex text input (IME), out-of-process plugins, printing, native menus, and Core Animation. Furthermore, Apple's upcoming JavaPlugin2 will not support Mac OS X 10.4.

  5. Re:How can I upgrade? by jimicus · · Score: 5, Informative

    I called up my local Apple store with exactly this question. They said "Come in and buy a retail copy of 10.6, we'll burn you a disc with 10.5 on".

    YMMV.

  6. Re:Minor version by ColdWetDog · · Score: 4, Informative

    I'm surprised that so much version specific code is needed to support a minor release of the OS. Why is that?

    With Apple and OS X "point releases" (10.x) are not minor version changes. They include major shifts in APIs and decrements of complete frameworks (ie. Carbon to Cocoa). Apple operates on a different timing and structure scheme than Microsoft. Neither necessarily better or worse, but different.

    If your 10.2 machine works for your application and doesn't need any upgraded software for fulfill it's purpose in the grand scheme of things, just leave it alone.....

    --
    Faster! Faster! Faster would be better!
  7. Re:Nooo ! by smash · · Score: 4, Informative

    Usage stats for mozilla 3.6 show approximately 12% of mac users running 10.4.

    --
    I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
  8. Re:Nooo ! by BZ · · Score: 4, Informative

    > Mozilla should have a very clear policy about backwards compatibility and follow it to the
    > letter.

    The basic setup is:

    1) Once an OS vendor drops support for an OS, support for it will not be maintained unless
            it's really easy to do.
    2) Whether an OS is supported depends on whether there are resources to support it and on
            how many users are using it.

    It's not exactly a clear policy, but the important part is that support decisions are pretty complicated and involve a lot of factors.... it's not clear to me what a sane policy would be that would not lead to dropping support in some cases when there's no real reason to do it.

    > Until Apple actively does something to break the older "deprecated" code in Firefox,
    > they should support older OSes

    10.6 dropped ATSUI support. 10.4 doesn't have Core Text. So the only way to support both is to have codepaths to use both text rendering backends and switch at runtime. Does that count as "does something to break"? ;)

    Thing is, it's all software. Everything can be worked around. The question is the cost (to users, in the end, either in terms of money or in terms of things users want that don't happen).

    > and you deal with the slightly older APIs/compilers to serve your users

    Not that simple. You have to use gcc 4.0 if you're going to run on 10.4. So doing that serves the 10.4 users. But on 10.5 and 10.6, using gcc 4.2 gives a pretty significant across-the-board speedup. So to properly serve those users, you want to be using gcc 4.2. Where that leaves you is either underserving 10.5/10.6 users to better serve 10.4 users or vice versa (at which point relative numbers of users start to matter), or shipping separate binaries with the ensuing user confusion during downloading, etc. So there's not an obvious course of action here that best serves "the users". It's a matter of compromise.