On 18/09/2013 19:25, Daniel Convissor wrote:
> Allow me one last post to clarify. What I said is the cost in _this_
> case doesn't outweigh the advantages. As someone who writes a lot of
> open source (and proprietary) code that gets run on machines that I
> have no control over, implementing this
On 28/02/2013 13:54, Ilia Alshanetsky wrote:
> The major reason being is the lack of a stable, production ready op-code
> cache.
Am I crazy or APC not stable != a lack of a stable opcode cache. Whole
discussion thread has been assuming people don't use anything and or
there's nothing better than b
On 29/01/2013 09:03, Zeev Suraski wrote:
> I’m creating a new one,
> based on the apparent level of interest in ZTS. This isn’t an RFC to
> remove ZTS by any stretch, but I **am** a bit confused about why people are
> still using ZTS.
Personally because runkit sandbox requires it, amongst other e
On 28/11/2012 23:11, Mailing list wrote:
> - Users will get warnings on upgrading - it can not be hidden by
> hosters/distros etc.
Think you might be wildly underestimating the ability of both distros
and stuff like cPanel to patch the extension. Then again - I think
everybody might be.
--
PHP I
On 16/11/2012 08:55, Rasmus Lerdorf wrote:
> I still don't see the point of using E_DEPRECATED like this for an
> entire extension. And I think it will hurt more than it will help for an
> extension this heavily used. It is going to encourage people to simply
> turn off that warning because they wi
