Just discovered that Apache's mod_alias is no
better at enabling a website to be relocatable (no
dependency on absolute paths) than PHP's require()
was. The target URL has to be an absolute file path and
it's rather difficult to redirect the top-level URL.

bjf:
do a simple thought experiment. Pick 5 perpetual intermediate users at random, and see if they know what effect those options have. I certainly don't know, and I even have some
reasonable idea of what SSL is. Now imagine the
other 100 or so options, and 5 or so dialogs they plan to add,
plus all the others that will get added.

The Mozilla people have tried to please all the users before:
it was called Seamonkey, and it was a total UI disaster. Firebird appears to be heading
in the same direction.

If you can't understand the benefits of a "small core, lots of
powerful extensions" approach, I can only assume that you've never used Seamonkey, or you've no experience of the vast majority of browser users out there. Sys admins needing to configure a deployment of browsers, web developers, "more configured than thou" geeks, and such, are quite capable of
installing extensions, using about:config etc. There's absolutely no reason to imperil the default browser for normal users for these minorities.

So, I built a recent Firebird CVS build.
Until this point, I've been very impressed with the
focus on a simple shipped UI for the end user.

And then I find a new
advanced panel in the prefs. Full of meaningless
crap about SSL versions and the like.

A little prodding on IRC:

<mconnor> movement: the SSL prefs are the tip of the iceberg
<mconnor> all of the security prefs from seamonkey
<mconnor> will be in Firebird for 0.8
<mconnor> bury them in a dialog accessed from somewhere, and those who want to feel like "super secure hack proof l33td00ds" can tweak

Unfortunately it appears that you need two trees in order
to build ThunderBird as well. Not great given how large
the source is, and that the automated builds don't work
on RH8 (and don't include xft of course)

MichaelCrawford: while you are probably
correct that too much focus is placed on specific skills
by recruiters, you should not disregard the other side of
the coin.

Having specific experience can mean a lot. Entrenched experience of particular libraries and technologies is not
simply a matter of "learning the APIs". There is a whole
body of knowledge on top of that; things like:

o bugs and idiosyncracies, their root cause, and how to work
around them

All of these things are only picked up by heavy work
with the particular technologies, and *they count*. If you
have a fixed-term contract, who are you going to pick ?
The guy who is easily capable of learning all these things,
but will take weeks and weeks learning the stuff, or the
guy who is sickeningly familiar with the crap of the particular technology, and has a large body of ready
solutions in his head?

It is absolutely not as simple as "go with the guy with
the better general skills" ...