Have you considered or evaluated a Windows-based Apache/PHP solution? Recently, I've even been able to compile mod_fastcgi under win32 for Apache 2.2...
As far as the thread-safe issue goes, [IMO] it has always been better to run Apache under a process-based MPM, as it's: 1) more secure, isolating 2) more stable
The common misconception of the performance penalty arises more from the lack of any further MPM configuration to the specific task and system.
Tardigrades [aka Water Bears], which live everywhere on this planet Earth, can... 1) resist storage in liquid nitrogen 2) survive in contact with mineral acids, organic solvents, and boiling water 3) survive in a a vacuum and under high pressure 4) withstand ionizing radiation of over 600,000 roentgens (500 roentgens would be fatal to a human)
Usually, you can get away with doing a build from source with some variation of --prefix=/usr/local/pkg, so as to not interfere with the native pkg.
That's how I ran my newer custom builds of Apache, PHP, MySQL, and OpenSSL under RH7 and RHEL3. It can get a bit tricky with OpenSSL, due to the runtime linker and some libs, but generally thats what/usr/local/ is there for [or at least that's what I have used it for].
I have not looked into building Python, but as long as you leave the env alone, and specify the path to python or use the correct shebang line, it probably would work out.
Slashdot Mirror
Have you considered or evaluated a Windows-based Apache/PHP solution? Recently, I've even been able to compile mod_fastcgi under win32 for Apache 2.2...
As far as the thread-safe issue goes, [IMO] it has always been better to run Apache under a process-based MPM, as it's:
1) more secure, isolating
2) more stable
The common misconception of the performance penalty arises more from the lack of any further MPM configuration to the specific task and system.
Don't worry about the government... http://www.google.com/psearch
XP's success is Vista's [initial] downfall. If it just works, and works well, why replace it.
Microsoft has a long history of putting out buggy software, release after release, to keep the users paying.
The people there are not stupid, I'm sure they have something planned that will turn this around.
I can't help but to think that this is just another Dell tactic designed to materialize a more lucrative contract with Microsoft...
1) plant the seed
2) rally the community
3) do a 180 and profit
I remember something similar with Dell, AMD, and Intel.
Fool me once, shame on you, fool me twice, shame on me?
Tardigrades [aka Water Bears], which live everywhere on this planet Earth, can...
1) resist storage in liquid nitrogen
2) survive in contact with mineral acids, organic solvents, and boiling water
3) survive in a a vacuum and under high pressure
4) withstand ionizing radiation of over 600,000 roentgens (500 roentgens would be fatal to a human)
Usually, you can get away with doing a build from source with some variation of --prefix=/usr/local/pkg, so as to not interfere with the native pkg.
That's how I ran my newer custom builds of Apache, PHP, MySQL, and OpenSSL under RH7 and RHEL3. It can get a bit tricky with OpenSSL, due to the runtime linker and some libs, but generally thats what /usr/local/ is there for [or at least that's what I have used it for].
I have not looked into building Python, but as long as you leave the env alone, and specify the path to python or use the correct shebang line, it probably would work out.
http://www.devside.net/guides/linux[Though these days, I just leave all that alone and use whatever comes with RH]