From: Stanislav Malyshev on 24 Oct 2009 14:23 Hi! > A little notice about ZS in general, "community" or not: > > - it has nothing to do with php.net > - we don't support it (don't report bugs to bugs.php.net using it) I think it's a little overreaching. It has a lot to do with php.net - it's the same code, only compiled. And I don't think it makes any sense to refuse handling bugs in builds other than php.net build - we never did it and that never was a policy of bugs.php.net. So if there's a bug in PHP which manifests in ZS build (of course, without Zend extensions etc.) then it should be reported to bugs.php.net as bugs in all other builds do, and please do report it. -- Stanislav Malyshev, Zend Software Architect stas(a)zend.com http://www.zend.com/ (408)253-8829 MSN: stas(a)zend.com
From: Pierre Joye on 24 Oct 2009 14:58 On Sat, Oct 24, 2009 at 8:23 PM, Stanislav Malyshev <stas(a)zend.com> wrote: > Hi! > >> A little notice about ZS in general, "community" or not: >> >> - it has nothing to do with php.net >> - we don't support it (don't report bugs to bugs.php.net using it) > > I think it's a little overreaching. It has a lot to do with php.net - it's > the same code, only compiled. It is not as far as I can see and it does not use the same libs either on windows. > And I don't think it makes any sense to refuse > handling bugs in builds other than php.net build - we never did it and that > never was a policy of bugs.php.net. We always did. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org
From: Shahar Evron on 27 Oct 2009 12:51 I am very biased (full disc., I'm the technical PM of Zend Server) but let me try to answer some of this, and maybe some of the concerns that have been raised in this thread (and in other places). I'm trying to be as transparent as possible, maybe this will help you decide whether or not ZSCE is for you. Zend Server CE provides a stable and well preforming PHP setup on Windows. You can get that setup through other means of course, but this is our focus for Zend Server. I'd also say that up until now we are mostly focused on providing a production stack. Hence the opcode cache, FastCGI setup, etc. As for Oracle support, we bundle the Oracle client libraries (lite version actually) and compile oci8 and PDO_OCI against the 11g libraries to support the new DRCP feature. As for compatibility and non-standard build, this might imply several things and I can only guess what specific issues people are referring to, but if I'm guessing right, there are two differences between how we build PHP and the php.net binaries: * Usage of VC8 vs. VC9 or VC6 - Zend has been building on Windows with VC8 for a couple of years now (since Zend Core). This makes our PHP builds somewhat incompatible with VC6 built extension DLLs for PHP 5.2 (we know they mostly work, but there's definitely a difference), and completely incompatible with VC6 or VC9 builds on PHP 5.3 (because PHP simply won't load them). We are in the process of moving all our build system to use VC9 (yes, that's official) and in fact the PHP 5.3 builds of Zend Server 5.0 beta (not yet available in CE) are already on VC9. Eventually we will ship all our 5.3 builds on VC9. My note on this would be that if you need some custom extension which is not shipped by Zend Server, check first if it works or not - if you'll be using 5.3 than you'll have to wait for us to release VC9 based builds. If you have everything you need shipped with Zend Server, then I don't think there's real concern there - except for being able to report bugs to bugs.php.net which I will not get into, as I am not really a core developer and have no say here. Of course, if you report these bugs to Zend we will take them seriously :) * Zend does apply some patches to PHP which are not a part of official php.net releases. Those fall under two categories: 1. Patches already in the php.net SVN tree, but not released yet. We do this when we encounter some major bug or security issue in PHP and decide it's important enough for us to patch it in our own product. This is done very selectively and in any case the only patches applied are already in the PHP source tree - we simply backport them. 2. Patches that provide Zend Server specific functionality, such as fixes that help our own specific FastCGI infrastructure to work better. This is done in a very local and minimal manner, and shouldn't affect the behavior of your own PHP code. Again, I think the only concern here for you as an end user (and not a core PHP developer) is the fact that bugs reported through bugs.php.net might not be accepted. Again, I have no say to whether this is right or wrong, I am not a core developer and can't judge. As I said you can always report these bugs to Zend, we can triage and figure out if it's a PHP bug or a Zend induced bug, and fix accordingly (and push to php.net if relevant). Ok, I think I have said enough :) I'll be happy to answer more questions, on or off the list. Best regards, Shahar. Marcos R. Cardoso wrote: > Does anyone here have any opinion about Zend Server Community Edition? > > I'm doing some tests here and I'm intending to use it at the University > Library where I work. > > Any input about this web application would be nice. > > TIA, > -- Shahar Evron <shahar.e(a)zend.com> Product Manager Zend Technologies
From: Pierre Joye on 27 Oct 2009 15:38 hi, The only fact that you build 5.2 with VC8 means that you apply patches not present in php 5.2 (eventually in 5.3). About moving to VC9 for 5.3, given that we have moved to VC9 and everything is going well so far, that sounds like a logical move. But why would you provide your own binaries with random patches (not a judgement, only a statement) instead of using PHP binaries? Security? We do security releases when a librarie is affected. PHP itself has regular security releases as well. For example, Microsoft uses php.net's binaries for the Web Platform Installer (http://www.microsoft.com/web/). Other comments inline, On Tue, Oct 27, 2009 at 5:51 PM, Shahar Evron <shahar.e(a)zend.com> wrote: > 2. Patches that provide Zend Server specific functionality, such as > fixes that help our own specific FastCGI infrastructure to work better. > This is done in a very local and minimal manner, and shouldn't affect > the behavior of your own PHP code. Your own FastCGI to work better than what? > Again, I think the only concern here for you as an end user (and not a > core PHP developer) is the fact that bugs reported through bugs.php.net > might not be accepted. Again, I have no say to whether this is right or > wrong, I am not a core developer and can't judge. As I said you can > always report these bugs to Zend, we can triage and figure out if it's a > PHP bug or a Zend induced bug, and fix accordingly (and push to php.net > if relevant). As being both my concerns are to actually see a kind of fork of PHP, being presented as the only usable binary distributions for windows and other platforms (and for apache too). As with any distributors who apply custom patches, we do not support them. However these distributors usually have an issues tracker and ask their users to report issues there. If they meet a real php bug, it is then then reported in our tracker. That's common practice. We will indeed not reject obvious bugs only because the users use ZS. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org
From: Stanislav Malyshev on 27 Oct 2009 15:46 Hi! > As being both my concerns are to actually see a kind of fork of PHP, > being presented as the only usable binary distributions for windows > and other platforms (and for apache too). There's no any "fork" and nobody ever presented it as "the only usable binary distributions for windows". Applying patches between releases is how most of binary distros always worked (provided there are patches important for their clients which are not released yet) with a lot of opensource projects - incl. Redhat, etc. - and nobody ever thought of talking about "forking" anything. -- Stanislav Malyshev, Zend Software Architect stas(a)zend.com http://www.zend.com/ (408)253-8829 MSN: stas(a)zend.com
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: [PHP-WIN] [SOLVED] Windows Vista UAC Issue Next: Cambios de la cuenta de correos |