Anyway, I think we get off-topic with discussions of those who
*knowingly* write insecure code, e.g. manually turning off secure
options to save effort.
Also think it is unnecessary _in the context of a related language
change_ to discuss whether users writing insecure code due to
ignorance of PHP's defaults is no excuse, a partial excuse, or a full
excuse.
All that matters is that the default options were being trusted in the
real world by real -- by job description, if not competence --
developers. If it needs to be fixed, we should fix it, but with no
extra grudges in the implementation.
When we bear a grudge against our own users for "forcing" a language
change we leave the doors open for punishing them with the
implementation of that change. This is my main argument with Daniel:
either we accept that we are breaking people's setups with a change
*regardless* of their ultimate responsibility for that change, or we
don't make the change.
Stating that it's dirt-simple to make such a change is a way of
punishing a subset of users who aren't any worse developers than the
rest, and perhaps most unfortunately it targets a minority of users
who already get the short end of the stick when it comes to
extensions, etc., and now will be told that their code is less secure
than their *nix counterparts' code -- even though the *nix side is
going to get more secure without doing a whit of work. I guess the
laissez-faire attitude about Windows users is what sticks in my craw,
like they get a bizarre hybrid of respect and disrespect with this
patch.
-- S.