Three Monkeys, Three Typewriters, Two Days

It appears like you mistyped the (first) anchor's closing tag (</> instead of </a>)

Indeed. Fixed.

='( My poor GTK...

Good night, sweet prince.

The main failing I see is that we need to make major version upgrades easier. Significantly easier. There's work ongoing for this in Fedora, might land in the Fedora 9 timeframe.

Realistically though, I imagine enterprise OS vendors which ship Firefox are going to really want to readd conditional compilation against older GTK+. Mozilla doesn't have to do that patch, but my guess is that it will get written.

Colin, if major version upgrades didn't break so much stuff this would all be much less of an issue, indeed. Anything that gets us closer to that would be very much appreciated!

Hi bz, sorry about the crashing as I thought I had that covered:

http://mxr.mozilla.org/seamonkey/source/widget/src/gtk2/nsDeviceContextSpecG.cpp#492

I'll try and make a patch to fix that.

Michael, not sure how much it's worth worrying about it, to be honest. It's not that big a deal, so if it's too much pain to fix, don't bother. Printing not working is just as much of a showstopper for me using trunk builds as printing crashing, in any case.

How difficult would it be to develop inside of virtual machines? With Virtual Box, I can access the host file system from the client OS, and I can copy and paste between host and client. I'm sure other software like VMWare would have something similar.

James, developing in a VM isn't so bad. Performance testing, however, is all screwy in a VM. Disk access, display access, CPU access, all have different characteristics all of a sudden, and there is the (variable) overhead of a VM as well.

The box in question is the one I use for performance testing and my day-to-day browsing, and using a VM doesn't make that much sense for either task.

Not to mention that a VM is by definition slower than the host machine, and this is a P3-733 to start with.

Hey, this is your blog and you're entitled to your opinions and all. On top of that, I certainly thank you for your work on Mozilla.

Now, what I don't understand are all these rants on planet Mozilla about Linux and its infrastructure which are, after all, free software like Mozilla, you know, the kind you don't get from Apple.

Of course the user experience on OS X is a lot smoother, they don't have to support a gazillion of hardware and they can dictate policy top-down on their software stack since they control it all. That's always been very difficult on open platforms because people can't get their heads out of their project and see the big picture. Colin Walters just had a very good post about this[1].

[1] http://cgwalters.livejournal.com/12380.html

Besides the specific case you describe here could just as well happen on OS X. Suddenly one of Mozilla's developers checks in a feature dependent on a 10.5 only API. Hmm, now you are getting symbol look up failures there too simply because you're running bleeding edge software which is prone to have unfinished code in it. Go whine on the planet about how much OS X sucks, hurry!

Yea, go and use OS X. But you know what? When it breaks, go whine on Apple's hears and see if they listen to you.

Is the code for using the old print dialog still there? I presume it is since other OSes still can use it. If that is the case, why not have a pref or application switch that can enable that. I believe there are similar options for other dialogs -- like the file->open dialog.

Rui, you can view my comments as a rant, or you can view them as user feedback on the frustrations of actually using desktop Linux (as I have been since 1996). I understand the challenges involved quite well, thank you.

You're right that this specific case could happen on OS X. In does happen, in fact -- Gecko 1.9 dropped support for OS X 10.2 and 10.3 because it's using APIs that didn't get introduced until OS X 10.4. It might even be that the failure mode is just as bad (run along fine, then crash when the user tries to do something).

But in practice, the OS X APIs are a bit more mature than the Linux ones, and their support cycle is longer than most Linux distributions. Not only that, but even their hardware support cycle is longer in some cases, which is admittedly easier with more uniform hardware. My wife just upgraded to OS X 10.4 on her 7-year-old Mac, and it's all working fine. Both OS upgrades (OS 9 to OS X 10.2 and 10.2 to 10.4) went smoothly and without a hitch. My last Linux upgrade on a similarly aged machine (two years ago) made my sound card stop working. Note that this isn't the usual Linux issue (which I understand perfectly) of "no one's written a driver for this yet". There used to be a driver. It got dropped. Quite apart from that, it took me over a week of tweaking to fix the various things that got broken (locating various rpmnew/rpmsave files, etc, etc).

As for Apple ignoring feedback about things being broken, that would pretty much match my experience reporting Linux bugs to Fedora/RedHat, the kernel, and ALSA. So not much of a difference there, really.

I like Linux, I really do. But I have a lot less free time than I did as a college freshman, and the desire to have things "just work" is very strong.

I might try Ubuntu instead of OS X, of course. Maybe it'll be a lot better than Fedora. We'll see.

In my experience, Ubuntu has been a lot better than Fedora. I used Redhat and then Fedora from 5.2 through FC5, and one of the biggest frustrations with that OS was upgrade bustage, in particular video, audio, and networking.

Since switching to Ubuntu, I've upgraded thrice, from 6.06 to 6.10 to 7.04 to 7.10. And things have broken, particularly in the last upgrade (cupsd crashes, and Pidgin wouldn't show my contacts on startup until I disabled and reenabled my acounts), but nowhere near as frequently as they did with Fedora (exponentially less! ;-)).

But the general point is well-taken. Things do "just work" on Macs more often. Nevertheless, I still spend most of my time in an Ubuntu VM on my MacBook Pro, because it gives me the kind of window management that makes me more productive, which ironically is actually simpler and dumber than the management Mac OS X provides.

In particular, there are either one or two (with desktops) ways to switch windows with the keyboard on Linux, while there are two or three (with spaces) on Mac. And "maximize window" on Linux always means the same thing and doesn't violate Fitt's law around window edges.

So I'll stick with Linux, hope it stays on its trajectory of continuous linear improvement, and look forward to the tipping point.

Myk, that's great to hear; the upgrade pain is the thing that bites me the most on RedHat/Fedora! Maybe I'll try Ubuntu come summer.

Shouldn't the print.use_native_print_dialog preference resolve your issue with Linux print dialogs?

Bill, that pref does nothing other than take up space in memory, as far as I can tell. Certainly the GTK printing code doesn't pay attention to it.

It should probably just be removed so people don't get confused into thinking it has an effect...