does this exist for CentOS 4 ?
OK - next level of question then...
taking a wild swing, I set up /etc/yum.repos/kde-redhat.repo and for S&G's, I ran the obligatory 'yum update' to see what would happen.
It's an aggressive update to be sure.
KDE 3.5.0 (and all the dependent stuff such as qt) but also samba and openoffice.
Is anyone reporting happiness / contentment with their repo enabled and their updates installed?
Craig
Craig White wrote:
does this exist for CentOS 4 ?
OK - next level of question then...
taking a wild swing, I set up /etc/yum.repos/kde-redhat.repo and for S&G's, I ran the obligatory 'yum update' to see what would happen.
It's an aggressive update to be sure.
KDE 3.5.0 (and all the dependent stuff such as qt) but also samba and openoffice.
Is anyone reporting happiness / contentment with their repo enabled and their updates installed?
Maybe a question better taken to the kde-redhat list at https://lists.sourceforge.net/lists/listinfo/kde-redhat-users
- K
does this exist for CentOS 4 ?
Yes, the EL4 repository works fine on CentOS4.
taking a wild swing, I set up /etc/yum.repos/kde-redhat.repo and for S&G's, I ran the obligatory 'yum update' to see what would happen.
It's an aggressive update to be sure.
Yes, it is.
KDE 3.5.0 (and all the dependent stuff such as qt) but also samba and openoffice.
Is anyone reporting happiness / contentment with their repo enabled and their updates installed?
I use it daily on multiple machines; I have a twin need for the stability of CentOS (update-wise) on one hand, but the features of the later Kstars (part of the 'edutainment' kdeedu package) on the other. Kstars for KDE 3.4 and above has telescope control; see my .sig for why that might be important to me.
The 3.5 update didn't really break much. However, you will have difficulty with things that use the kdesu utility, since, at least with the latest updates, su is asking a second question (about the security context) and that hangs kdesu hard (I'm sure there's a config somewhere that will eliminate the security context question, but it hasn't been important enough yet for me to look for it). Those things include the superuser mode konsole, the superuser mode konqueror, the administrator mode KDE print manager, etc. K3b, on the other hand, works perfectly.
The updates ARE quite large; a major version increase (or even a minor KDE version increase) can weigh a couple hundred meg; if it includes an update to openoffice.org (the KDE integration has to be rebuilt for each new KDE version) double the size.
It is worth it to me; I use it, and like it, on my daily use notebook, which boots into CentOS about 99% of the time. But it will triple your updates bandwidth usage, on average.
Mixing with Dag or ATrpms or Karanbir's Extras is hit and miss, though, afterwards, particularly for KDE programs, since those repos are built against the stock CentOS KDE 3.3.
KDE 3.5 is slower, unfortunately, so you don't want to do this on an old machine; the machine needs to be recent and needs to have more than 256MB RAM for sure. On one machine, going from 256MB to 512MB doubled its apparent speed; the further increase to 1GB added another 33% or so on some tasks.
YMMV.
On Fri, 2006-01-20 at 08:31 -0500, Lamar Owen wrote:
does this exist for CentOS 4 ?
Yes, the EL4 repository works fine on CentOS4.
taking a wild swing, I set up /etc/yum.repos/kde-redhat.repo and for S&G's, I ran the obligatory 'yum update' to see what would happen.
It's an aggressive update to be sure.
Yes, it is.
KDE 3.5.0 (and all the dependent stuff such as qt) but also samba and openoffice.
Is anyone reporting happiness / contentment with their repo enabled and their updates installed?
I use it daily on multiple machines; I have a twin need for the stability of CentOS (update-wise) on one hand, but the features of the later Kstars (part of the 'edutainment' kdeedu package) on the other. Kstars for KDE 3.4 and above has telescope control; see my .sig for why that might be important to me.
The 3.5 update didn't really break much. However, you will have difficulty with things that use the kdesu utility, since, at least with the latest updates, su is asking a second question (about the security context) and that hangs kdesu hard (I'm sure there's a config somewhere that will eliminate the security context question, but it hasn't been important enough yet for me to look for it). Those things include the superuser mode konsole, the superuser mode konqueror, the administrator mode KDE print manager, etc. K3b, on the other hand, works perfectly.
The updates ARE quite large; a major version increase (or even a minor KDE version increase) can weigh a couple hundred meg; if it includes an update to openoffice.org (the KDE integration has to be rebuilt for each new KDE version) double the size.
It is worth it to me; I use it, and like it, on my daily use notebook, which boots into CentOS about 99% of the time. But it will triple your updates bandwidth usage, on average.
Mixing with Dag or ATrpms or Karanbir's Extras is hit and miss, though, afterwards, particularly for KDE programs, since those repos are built against the stock CentOS KDE 3.3.
KDE 3.5 is slower, unfortunately, so you don't want to do this on an old machine; the machine needs to be recent and needs to have more than 256MB RAM for sure. On one machine, going from 256MB to 512MB doubled its apparent speed; the further increase to 1GB added another 33% or so on some tasks.
YMMV.
---- thanks that's sort of what I needed to know. My usage is probably inverse of yours since this is for a server/ruby-on-rails development system and I am primarily interested in kdewebdev aka Quanta.
Yesterday, I was using Bluefish editor remotely via X and it worked well so much of the updates are somewhat unimportant but apparently this is the only reasonable way I can conceive of getting a usable Quanta plus on that system. This also seems to do little to improve server stability.
I suppose it would be smarter to just NFS mount the path used for rONr code and have Quanta on the Fedora desktop system but that has it's own tackiness to it.
Thanks
Craig
On Friday 20 January 2006 14:20, Craig White wrote:
I suppose it would be smarter to just NFS mount the path used for rONr code and have Quanta on the Fedora desktop system but that has it's own tackiness to it.
Why not simply use sftp or similar for access to the files you need to edit. Quanta will happily work with projects and/or individual files over sftp as well as a host of other protocols. I use it exclusively to edit web projects on Centos servers from my Fedora desktop with all the files located remotely. KIO automatically downloads any file I select to edit from the project and re-uploads the changes when I save. Never been a problem and it's far more responsive than remote X.
Lamar Owen wrote:
does this exist for CentOS 4 ?
Yes, the EL4 repository works fine on CentOS4.
taking a wild swing, I set up /etc/yum.repos/kde-redhat.repo and for S&G's, I ran the obligatory 'yum update' to see what would happen.
It's an aggressive update to be sure.
Yes, it is.
KDE 3.5.0 (and all the dependent stuff such as qt) but also samba and openoffice.
Is anyone reporting happiness / contentment with their repo enabled and their updates installed?
I use it daily on multiple machines; I have a twin need for the stability of CentOS (update-wise) on one hand, but the features of the later Kstars (part of the 'edutainment' kdeedu package) on the other. Kstars for KDE 3.4 and above has telescope control; see my .sig for why that might be important to me.
The 3.5 update didn't really break much. However, you will have difficulty with things that use the kdesu utility, since, at least with the latest updates, su is asking a second question (about the security context) and that hangs kdesu hard
Ack. I'll have to look into that.
KDE 3.5 is slower, unfortunately, so you don't want to do this on an old machine; the machine needs to be recent and needs to have more than 256MB RAM for sure. On one machine, going from 256MB to 512MB doubled its apparent speed; the further increase to 1GB added another 33% or so on some tasks.
Provided ample RAM, I've personally found kde 3.5 to be subjectively faster (partly due to pkg optimization tweaking).
-- Rex
On Saturday 21 January 2006 09:52, Rex Dieter wrote:
Lamar Owen wrote:
The 3.5 update didn't really break much. However, you will have difficulty with things that use the kdesu utility, since, at least with the latest updates, su is asking a second question (about the security context) and that hangs kdesu hard
Ack. I'll have to look into that.
Many thanks... and many thanks for the redhat EL4 packages, too.
KDE 3.5 is slower, unfortunately, so you don't want to do this on an old machine; the machine needs to be recent and needs to have more than 256MB RAM for sure. On one machine, going from 256MB to 512MB doubled its apparent speed; the further increase to 1GB added another 33% or so on some tasks.
Provided ample RAM, I've personally found kde 3.5 to be subjectively faster (partly due to pkg optimization tweaking).
Kmail for one definitely feels slower, and the startup time IS longer. This on a Pentium M 1.7GHz laptop with 1GB RAM and a pretty fast 60GB hard drive. I say this having used the previous KDE's on CentOS through the KDE-Redhat repository, 3.3, 3.4 and now 3.5. I literally started using 3.4's kmail one morning, shutdown kmail, yum updated, restarted machine, brought up KDE, and it felt slower. Started Kontact/kmail, and it too felt slower, although not by much. Of course, there might have been speedups since those initial public 3.5 packages that I haven't noticed.
Lamar Owen wrote:
KDE 3.5 is slower, unfortunately, so you don't want to do this on an old machine; the machine needs to be recent and needs to have more than 256MB
...
Provided ample RAM, I've personally found kde 3.5 to be subjectively faster (partly due to pkg optimization tweaking).
Kmail for one definitely feels slower, and the startup time IS longer.
...
it felt slower. Started Kontact/kmail, and it too felt slower, although
OK, I'll give you that kmail is slower. However, I still have to say that KDE(3.5), in general, is (should be) faster.
-- Rex
On Monday 23 January 2006 09:43, Rex Dieter wrote:
Lamar Owen wrote:
KDE 3.5 is slower, unfortunately, so you don't want to do this on an old machine; the machine needs to be recent and needs to have more than 256MB
Kmail for one definitely feels slower, and the startup time IS longer.
OK, I'll give you that kmail is slower. However, I still have to say that KDE(3.5), in general, is (should be) faster.
Yeah, much of the rest feels about the same speed as before.
I'll have to say, and I'm not one to complain much, but there are times that Kmail is dog slow; I am capable of >50 wpm typing speed, and there are many times that Kmail is one or more full lines behind showing me what's being typed. It is infrequent; like, right now, it's not happening, but when it does happen (typically after backspacing or some other editing operation) it is very slow. Problem exists for me at least with all Kmail since KDE 3.3's and distributed with CentOS 4. Again, 1GB RAM, Pentium M 1.7GHz, not a slow machine.
Lamar Owen wrote:
I'll have to say, and I'm not one to complain much, but there are times that Kmail is dog slow; I am capable of >50 wpm typing speed, and there are many times that Kmail is one or more full lines behind showing me what's being typed.
You may want to disable the spellcheck-as-you-type feature.
-- Rex
On Sat, 2006-01-21 at 08:52 -0600, Rex Dieter wrote:
Lamar Owen wrote:
does this exist for CentOS 4 ?
Yes, the EL4 repository works fine on CentOS4.
taking a wild swing, I set up /etc/yum.repos/kde-redhat.repo and for S&G's, I ran the obligatory 'yum update' to see what would happen.
It's an aggressive update to be sure.
Yes, it is.
KDE 3.5.0 (and all the dependent stuff such as qt) but also samba and openoffice.
Is anyone reporting happiness / contentment with their repo enabled and their updates installed?
I use it daily on multiple machines; I have a twin need for the stability of CentOS (update-wise) on one hand, but the features of the later Kstars (part of the 'edutainment' kdeedu package) on the other. Kstars for KDE 3.4 and above has telescope control; see my .sig for why that might be important to me.
The 3.5 update didn't really break much. However, you will have difficulty with things that use the kdesu utility, since, at least with the latest updates, su is asking a second question (about the security context) and that hangs kdesu hard
Ack. I'll have to look into that.
KDE 3.5 is slower, unfortunately, so you don't want to do this on an old machine; the machine needs to be recent and needs to have more than 256MB RAM for sure. On one machine, going from 256MB to 512MB doubled its apparent speed; the further increase to 1GB added another 33% or so on some tasks.
Provided ample RAM, I've personally found kde 3.5 to be subjectively faster (partly due to pkg optimization tweaking).
---- I've been unable to install anything lacking the public key for the repo.
I tried (from kde-redhat.sourceforge.net)
# rpm -ivh http://kde-redhat.sourceforge.net/gpg-pubkey-ff6382fa-3e1ab2ca Retrieving http://kde-redhat.sourceforge.net/gpg-pubkey-ff6382fa-3e1ab2ca Retrieving http://kde-redhat.sf.net/ error: skipping http://kde-redhat.sf.net/ - transfer failed - Unknown or unexpected error
and I'm stumped
Craig
Craig White wrote:
On Sat, 2006-01-21 at 08:52 -0600, Rex Dieter wrote:
Lamar Owen wrote:
does this exist for CentOS 4 ?
Yes, the EL4 repository works fine on CentOS4.
taking a wild swing, I set up /etc/yum.repos/kde-redhat.repo and for S&G's, I ran the obligatory 'yum update' to see what would happen.
It's an aggressive update to be sure.
Yes, it is.
KDE 3.5.0 (and all the dependent stuff such as qt) but also samba and openoffice.
Is anyone reporting happiness / contentment with their repo enabled and their updates installed?
I use it daily on multiple machines; I have a twin need for the stability of CentOS (update-wise) on one hand, but the features of the later Kstars (part of the 'edutainment' kdeedu package) on the other. Kstars for KDE 3.4 and above has telescope control; see my .sig for why that might be important to me.
The 3.5 update didn't really break much. However, you will have difficulty with things that use the kdesu utility, since, at least with the latest updates, su is asking a second question (about the security context) and that hangs kdesu hard
Ack. I'll have to look into that.
KDE 3.5 is slower, unfortunately, so you don't want to do this on an old machine; the machine needs to be recent and needs to have more than 256MB RAM for sure. On one machine, going from 256MB to 512MB doubled its apparent speed; the further increase to 1GB added another 33% or so on some tasks.
Provided ample RAM, I've personally found kde 3.5 to be subjectively faster (partly due to pkg optimization tweaking).
I've been unable to install anything lacking the public key for the repo.
I tried (from kde-redhat.sourceforge.net)
# rpm -ivh http://kde-redhat.sourceforge.net/gpg-pubkey-ff6382fa-3e1ab2ca Retrieving http://kde-redhat.sourceforge.net/gpg-pubkey-ff6382fa-3e1ab2ca Retrieving http://kde-redhat.sf.net/ error: skipping http://kde-redhat.sf.net/ - transfer failed - Unknown or unexpected error
rpm --import the gpg key, not install it.
On Tue, 2006-01-24 at 11:36 +0000, Karanbir Singh wrote:
Craig White wrote:
On Sat, 2006-01-21 at 08:52 -0600, Rex Dieter wrote:
Lamar Owen wrote:
does this exist for CentOS 4 ?
Yes, the EL4 repository works fine on CentOS4.
taking a wild swing, I set up /etc/yum.repos/kde-redhat.repo and for S&G's, I ran the obligatory 'yum update' to see what would happen.
It's an aggressive update to be sure.
Yes, it is.
KDE 3.5.0 (and all the dependent stuff such as qt) but also samba and openoffice.
Is anyone reporting happiness / contentment with their repo enabled and their updates installed?
I use it daily on multiple machines; I have a twin need for the stability of CentOS (update-wise) on one hand, but the features of the later Kstars (part of the 'edutainment' kdeedu package) on the other. Kstars for KDE 3.4 and above has telescope control; see my .sig for why that might be important to me.
The 3.5 update didn't really break much. However, you will have difficulty with things that use the kdesu utility, since, at least with the latest updates, su is asking a second question (about the security context) and that hangs kdesu hard
Ack. I'll have to look into that.
KDE 3.5 is slower, unfortunately, so you don't want to do this on an old machine; the machine needs to be recent and needs to have more than 256MB RAM for sure. On one machine, going from 256MB to 512MB doubled its apparent speed; the further increase to 1GB added another 33% or so on some tasks.
Provided ample RAM, I've personally found kde 3.5 to be subjectively faster (partly due to pkg optimization tweaking).
I've been unable to install anything lacking the public key for the repo.
I tried (from kde-redhat.sourceforge.net)
# rpm -ivh http://kde-redhat.sourceforge.net/gpg-pubkey-ff6382fa-3e1ab2ca Retrieving http://kde-redhat.sourceforge.net/gpg-pubkey-ff6382fa-3e1ab2ca Retrieving http://kde-redhat.sf.net/ error: skipping http://kde-redhat.sf.net/ - transfer failed - Unknown or unexpected error
rpm --import the gpg key, not install it.
---- duh ;-)
I was pre-occupied with freenx and didn't spend any time on it - of course you're right and I wasn't thinking.
Thanks
Craig
Craig White wrote:
I've been unable to install anything lacking the public key for the repo.
I tried (from kde-redhat.sourceforge.net)
# rpm -ivh http://kde-redhat.sourceforge.net/gpg-pubkey-ff6382fa-3e1ab2ca Retrieving http://kde-redhat.sourceforge.net/gpg-pubkey-ff6382fa-3e1ab2ca Retrieving http://kde-redhat.sf.net/ error: skipping http://kde-redhat.sf.net/ - transfer failed - Unknown or unexpected error
and I'm stumped
Hint: use 'rpm --import' instead of 'rpm -i' (-:
-- Rex
On Tue, 2006-01-24 at 07:55 -0600, Rex Dieter wrote:
Craig White wrote:
I've been unable to install anything lacking the public key for the repo.
I tried (from kde-redhat.sourceforge.net)
# rpm -ivh http://kde-redhat.sourceforge.net/gpg-pubkey-ff6382fa-3e1ab2ca Retrieving http://kde-redhat.sourceforge.net/gpg-pubkey-ff6382fa-3e1ab2ca Retrieving http://kde-redhat.sf.net/ error: skipping http://kde-redhat.sf.net/ - transfer failed - Unknown or unexpected error
and I'm stumped
Hint: use 'rpm --import' instead of 'rpm -i' (-:
---- this all works pretty well, I was able to install tidy and kdewebdev - thanks.
I have one issue and it's a nutbreaker though...
I cannot deal with the 'Enable icon mouseover effects' which appears to be a default option in this setup (KDE 3.5) via freenx as it is incredibly painful. I tried to access it via...
Start -> Settings -> Desktop -> Panels or Kcontrol and I get a blank window and all I can see is 'Defaults' 'Help' 'Apply' 'Reset' buttons and no options as I see in the same on my FC-4 KDE 3.5 where I notice that it was off.
This is an issue...I'll poke around in my home directory.
Thanks
Craig
Craig White wrote:
I have one issue and it's a nutbreaker though...
Ouch. (-:
Start -> Settings -> Desktop -> Panels or Kcontrol and I get a blank window and all I can see is 'Defaults' 'Help' 'Apply' 'Reset' buttons and no options as I see in the same on my FC-4 KDE 3.5 where I notice that it was off.
This is an issue...I'll poke around in my home directory.
Try deleting,renaming ~/.local ~/.config Run in a konsole: $ kbuildsyscoca
Else, try rebooting (it'll cleanup crud left behind in /tmp /and/or /var/tmp)
-- Rex
On Tue, 2006-01-24 at 12:09 -0600, Rex Dieter wrote:
Craig White wrote:
I have one issue and it's a nutbreaker though...
Ouch. (-:
Start -> Settings -> Desktop -> Panels or Kcontrol and I get a blank window and all I can see is 'Defaults' 'Help' 'Apply' 'Reset' buttons and no options as I see in the same on my FC-4 KDE 3.5 where I notice that it was off.
This is an issue...I'll poke around in my home directory.
Try deleting,renaming ~/.local ~/.config Run in a konsole: $ kbuildsyscoca
---- awesome - that fixed the panels and that allowed me to shut off the 'enable mouseover' effect and life is great!
Thanks
Craig
hi! It seems like everytime I turn around lately, I'm opening up another can of worms and I sure don't like what I just read.
this book: Setting Up Lamp (Getting Linux, Apache, MySQL, and PHP Working Together) Sybex/Wiley ISBN 0-7821-4337-7
Page 197 to quote "Which Version of Apache to Use": Choosing your Apache version is something that should be taken from the correct perspective. Apache 1.3 is proven to be stable and, most importantly, compatible with PHP. Apache 2.0 is stable; however, there have been multiple problems with PHP compatibility. Making Apache 2.0 and PHP work together is as predictable as flipping a coin. You will never know for sure whether the configuration will work properly and you might be faced with in-depth troubleshooting and problem solving trying to find out why they will not cooperate.
From our standpoint, we really hope that Apache 2.0 and PHP cooperate
sooner rather than later because the features of Apache 2.0 look very promising. For this book, we will be going with the tried and true concept and use the Apache 1.3 series to avoid any heartache you might have due to different configurations and luck of the draw. ....end of quote...
wow...this book is copyrighted(2004) if that makes any difference. I sure don't like the idea of going backwards w/Apache, since, although I don't use php but w/standard xhtml/css it has shown me no problems at all and I just don't like to even think in terms of doing what they suggest. But I want to hear from y'all on this. Do y'all find that these problems between Apache 2.0 and PHP are really that prominent as they have stated? Or, maybe I am wishful thinking here but I am hoping that some will reply that they have no problems whatsoever using the 2 together...instead...just go to this website and there is a good tutorial on this subject. lol
thx in advance,
John Rose
I use the two together. Just the default YUM installs worked great for me. The only problems I have had have actually been in the PHP coding in the website itself... but for the most part using the default YUM installs, everything seems OK to me =)
James
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of rado Sent: February 1, 2006 12:34 PM To: centos Subject: [CentOS] Apache 2.x and php???
hi! It seems like everytime I turn around lately, I'm opening up another can of worms and I sure don't like what I just read.
this book: Setting Up Lamp (Getting Linux, Apache, MySQL, and PHP Working Together) Sybex/Wiley ISBN 0-7821-4337-7
Page 197 to quote "Which Version of Apache to Use": Choosing your Apache version is something that should be taken from the correct perspective. Apache 1.3 is proven to be stable and, most importantly, compatible with PHP. Apache 2.0 is stable; however, there have been multiple problems with PHP compatibility. Making Apache 2.0 and PHP work together is as predictable as flipping a coin. You will never know for sure whether the configuration will work properly and you might be faced with in-depth troubleshooting and problem solving trying to find out why they will not cooperate.
From our standpoint, we really hope that Apache 2.0 and PHP cooperate
sooner rather than later because the features of Apache 2.0 look very promising. For this book, we will be going with the tried and true concept and use the Apache 1.3 series to avoid any heartache you might have due to different configurations and luck of the draw. ....end of quote...
wow...this book is copyrighted(2004) if that makes any difference. I sure don't like the idea of going backwards w/Apache, since, although I don't use php but w/standard xhtml/css it has shown me no problems at all and I just don't like to even think in terms of doing what they suggest. But I want to hear from y'all on this. Do y'all find that these problems between Apache 2.0 and PHP are really that prominent as they have stated? Or, maybe I am wishful thinking here but I am hoping that some will reply that they have no problems whatsoever using the 2 together...instead...just go to this website and there is a good tutorial on this subject. lol
thx in advance,
John Rose
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
rado spake the following on 2/1/2006 11:34 AM:
hi! It seems like everytime I turn around lately, I'm opening up another can of worms and I sure don't like what I just read.
this book: Setting Up Lamp (Getting Linux, Apache, MySQL, and PHP Working Together) Sybex/Wiley ISBN 0-7821-4337-7
Page 197 to quote "Which Version of Apache to Use": Choosing your Apache version is something that should be taken from the correct perspective. Apache 1.3 is proven to be stable and, most importantly, compatible with PHP. Apache 2.0 is stable; however, there have been multiple problems with PHP compatibility. Making Apache 2.0 and PHP work together is as predictable as flipping a coin. You will never know for sure whether the configuration will work properly and you might be faced with in-depth troubleshooting and problem solving trying to find out why they will not cooperate.
From our standpoint, we really hope that Apache 2.0 and PHP cooperate
sooner rather than later because the features of Apache 2.0 look very promising. For this book, we will be going with the tried and true concept and use the Apache 1.3 series to avoid any heartache you might have due to different configurations and luck of the draw. ....end of quote...
wow...this book is copyrighted(2004) if that makes any difference. I sure don't like the idea of going backwards w/Apache, since, although I don't use php but w/standard xhtml/css it has shown me no problems at all and I just don't like to even think in terms of doing what they suggest. But I want to hear from y'all on this. Do y'all find that these problems between Apache 2.0 and PHP are really that prominent as they have stated? Or, maybe I am wishful thinking here but I am hoping that some will reply that they have no problems whatsoever using the 2 together...instead...just go to this website and there is a good tutorial on this subject. lol
thx in advance,
John Rose
If the book was copyrighted in 2004, it could have been written in the mid to latter part of 2003, and those statements would have been very true THEN. Now here we are in 2006, and those statements seem laughable. I think it is more accurate that the author was more confident in his skills with the 1.3 version of apache. People naturally avoid change, if possible.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org]On Behalf Of rado Sent: Wednesday, February 01, 2006 2:34 PM To: centos Subject: [CentOS] Apache 2.x and php???
hi! It seems like everytime I turn around lately, I'm opening up another can of worms and I sure don't like what I just read.
this book: Setting Up Lamp (Getting Linux, Apache, MySQL, and PHP Working Together) Sybex/Wiley ISBN 0-7821-4337-7
Page 197 to quote "Which Version of Apache to Use": Choosing your Apache version is something that should be taken from the correct perspective. Apache 1.3 is proven to be stable and, most importantly, compatible with PHP. Apache 2.0 is stable; however, there have been multiple problems with PHP compatibility. Making Apache 2.0 and PHP work together is as predictable as flipping a coin. You will never know for sure whether the configuration will work properly and you might be faced with in-depth troubleshooting and problem solving trying to find out why they will not cooperate.
~~ snip ~~
My suggestion would be to find a fireplace and start a fire with that book. We use Apache 2.0 and PHP for some fairly extensive intranet based applications. Problems have only been a issue with the PHP coding, not the interaction of PHP and Apache. Both are rock solid.
Andrew
Page 197 to quote "Which Version of Apache to Use": Choosing your Apache version is something that should be taken from the correct perspective. Apache 1.3 is proven to be stable and, most importantly, compatible with PHP. Apache 2.0 is stable; however, there have been multiple problems with PHP compatibility. Making Apache 2.0 and PHP work together is as predictable as flipping a coin. You will never know for sure whether the configuration will work properly and you might be faced with in-depth troubleshooting and problem solving trying to find out why they will not cooperate.
From our standpoint, we really hope that Apache 2.0 and PHP cooperate
sooner rather than later because the features of Apache 2.0 look very promising. For this book, we will be going with the tried and true concept and use the Apache 1.3 series to avoid any heartache you might have due to different configurations and luck of the draw. ....end of quote...
wow...this book is copyrighted(2004) if that makes any difference. I sure don't like the idea of going backwards w/Apache, since, although I don't use php but w/standard xhtml/css it has shown me no problems at all and I just don't like to even think in terms of doing what they suggest. But I want to hear from y'all on this. Do y'all find that these problems between Apache 2.0 and PHP are really that prominent as they have stated? Or, maybe I am wishful thinking here but I am hoping that some will reply that they have no problems whatsoever using the 2 together...instead...just go to this website and there is a good tutorial on this subject. lol
thx in advance,
One of our primary portals just crossed 42,000 users, moving about 6GB of traffic a day on average, all with apache2 and php. 0 problems attributable to php or apache.
If in CentOS distro is Apache2 and PHP, so for me it means that this is stable system :)
Besides book is rather old. If we talk about Apache2.
Regards. -- ____________________________________________________________________ D o m i n i k S k ł a d a n o w s k i
My understanding is that it is not recommended to run PHP with Apache 2 - unless Apache 2 is run in prefork mode. This is because many popular PHP libraries are not thread safe (although PHP itself is.) The stock CentOS Apache is in prefork mode I believe and that is why there are no problems.
Apache prefork:
http://httpd.apache.org/docs/2.0/mod/prefork.html
PHP manual warning about Apache 2 in threaded mode:
http://www.php.net/manual/en/ faq.installation.php#faq.installation.apache2
On Feb 1, 2006, at 2:34 PM, rado wrote:
hi! It seems like everytime I turn around lately, I'm opening up another can of worms and I sure don't like what I just read.
this book: Setting Up Lamp (Getting Linux, Apache, MySQL, and PHP Working Together) Sybex/Wiley ISBN 0-7821-4337-7
Page 197 to quote "Which Version of Apache to Use": Choosing your Apache version is something that should be taken from the correct perspective. Apache 1.3 is proven to be stable and, most importantly, compatible with PHP. Apache 2.0 is stable; however, there have been multiple problems with PHP compatibility. Making Apache 2.0 and PHP work together is as predictable as flipping a coin. You will never know for sure whether the configuration will work properly and you might be faced with in-depth troubleshooting and problem solving trying to find out why they will not cooperate.
From our standpoint, we really hope that Apache 2.0 and PHP cooperate
sooner rather than later because the features of Apache 2.0 look very promising. For this book, we will be going with the tried and true concept and use the Apache 1.3 series to avoid any heartache you might have due to different configurations and luck of the draw. ....end of quote...
wow...this book is copyrighted(2004) if that makes any difference. I sure don't like the idea of going backwards w/Apache, since, although I don't use php but w/standard xhtml/css it has shown me no problems at all and I just don't like to even think in terms of doing what they suggest. But I want to hear from y'all on this. Do y'all find that these problems between Apache 2.0 and PHP are really that prominent as they have stated? Or, maybe I am wishful thinking here but I am hoping that some will reply that they have no problems whatsoever using the 2 together...instead...just go to this website and there is a good tutorial on this subject. lol
thx in advance,
John Rose
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
wow...that fast and I think there were 7 replies... sure thx to all of you! y'all made me feel that I was right bout the way I felt about it.
ummm I'm not gonna burn the book as of yet cuz it's all I got! but I do hope I can just move on...follow the directions and we'll all live happily ever after!
thx John Rose
On Wed, 2006-02-01 at 15:50 -0500, jim@datamantic.com wrote:
My understanding is that it is not recommended to run PHP with Apache 2 - unless Apache 2 is run in prefork mode. This is because many popular PHP libraries are not thread safe (although PHP itself is.) The stock CentOS Apache is in prefork mode I believe and that is why there are no problems.
Apache prefork:
http://httpd.apache.org/docs/2.0/mod/prefork.html
PHP manual warning about Apache 2 in threaded mode:
http://www.php.net/manual/en/ faq.installation.php#faq.installation.apache2
That is true ... the centos apache is defaulted that way.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Johnny Hughes Sent: February 1, 2006 2:12 PM To: CentOS ML Subject: Re: [CentOS] Apache 2.x and php???
On Wed, 2006-02-01 at 15:50 -0500, jim@datamantic.com wrote:
My understanding is that it is not recommended to run PHP with Apache 2 - unless Apache 2 is run in prefork mode. This is because many popular PHP libraries are not thread safe (although PHP itself is.) The stock CentOS Apache is in prefork mode I believe and that is why there are no problems.
Apache prefork:
http://httpd.apache.org/docs/2.0/mod/prefork.html
PHP manual warning about Apache 2 in threaded mode:
http://www.php.net/manual/en/ faq.installation.php#faq.installation.apache2
That is true ... the centos apache is defaulted that way.
Is that any different from the YUM install? Or does YUM also default to prefork?
James
On Feb 1, 2006, at 4:15 PM, James Gagnon wrote:
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Johnny Hughes Sent: February 1, 2006 2:12 PM To: CentOS ML Subject: Re: [CentOS] Apache 2.x and php???
On Wed, 2006-02-01 at 15:50 -0500, jim@datamantic.com wrote:
My understanding is that it is not recommended to run PHP with Apache 2 - unless Apache 2 is run in prefork mode. This is because many popular PHP libraries are not thread safe (although PHP itself is.) The stock CentOS Apache is in prefork mode I believe and that is why there are no problems.
Apache prefork:
http://httpd.apache.org/docs/2.0/mod/prefork.html
PHP manual warning about Apache 2 in threaded mode:
http://www.php.net/manual/en/ faq.installation.php#faq.installation.apache2
That is true ... the centos apache is defaulted that way.
Is that any different from the YUM install? Or does YUM also default to prefork?
James
Yum is the same.
-
Andrew Cotter -
Craig White -
Dominik Składanowski -
James Gagnon -
Jim Perrin -
jim＠datamantic.com -
Johnny Hughes -
Karanbir Singh -
Lamar Owen -
rado -
Rex Dieter -
Rob Hall -
Scott Silva