Results 1 to 12 of 12
  1. #1

    Opinions of Hosts on PHP and Perl

    Now I don't want to start a debate about which is a better language. I don't care about which you prefer as a coder, but rather as a host.

    Which one do you prefer your clients use, why?

    What do you feel has led up to your current opinions, controls panels you use, articles, your customers?

    Have you banned either language from your servers in part or in whole, why?
    Advanced Forum Hosting
    http://www.boardnation.com
    Easily build a community today!

  2. #2
    I have always rathered my clients use PHP.. it seems to stop all those Permission error problems that seem to pop up all too often.. in fact youve probably seem them yourself "500 Internal server error"... sigh

    I have heard reports that Perl can use more CPU resources than php... but thats very inconclusive.

    Never banned any of the languages but have banned a few scripts based on Perl.. mainly Perl message boards.

  3. #3
    Join Date
    Jul 2002
    Location
    Kuwait
    Posts
    10,573
    same here i always recommend php, and always stay away from jsp since it load the box and so many problems if running cpanel+whm
    Bashar Al-Abdulhadi - KuwaitNET Internet Services Serving customers since 1997
    Kuwait's First Webhosting and Domain Registration provider - an ICANN Accredited Registrar

    Twitter: Bashar Al-Abdulhadi

  4. #4
    PHP seems to be preferred, it is a bit more modern than Perl, so it is supposed to be more efficient.

  5. #5
    I prefer PHP for myself. However, there is one problem with PHP to which I have (so far) not found a satisfactory solution.

    PHP scripts must be world readable (unless using phpsuexec), which means mysql login info is readable by anyone else on the same box.

  6. #6
    Join Date
    Jun 2003
    Location
    Proud She-Geek
    Posts
    1,722
    PHP - usually much easier to troubleshoot.
    <?php echo "Signature here"; ?>

  7. #7
    Join Date
    Jun 2003
    Location
    Bay Area
    Posts
    218

    jsp!!!

    I ONLY allow jsp/servlet stuff for a few reasons: don't like apache/do like tomcat. Since I like java better than any other language, I find it easier to troubleshoot other people's stuff and mod the server. Also, REAL jsp hosting will be attractive to more advanced users who don't do a google search for really+neat+message+board+online and want to run what it turns up on my servers, so there are fewer lame support requests, etc... In fact, the only trouble customers I have are those who used php until for some reason they signed on with me. There are lots of problems with the tomcat way, most of which can be taken care of with stuff like cerb and screwing witht he server (mainly issues surrounding not being able to change effective uid).


    I think in the end it is all about what you feel more comfortable with yourself, 'cause that way you're more helpful to customers and working with your server isn't as much of a chore.
    -- My software isn't buggy; it develops random features --

  8. #8
    Join Date
    Oct 2002
    Location
    North America
    Posts
    1,229
    You have to find a good middle ground between what your clients want, and what you can safely and competently admin. If you are familiar with the potential problems with PHP and know how to put up blocks to safeguard your clients / your operations, then great. If, however, you're just installing PHP without knowing what vulnerabilities it can cause, you could be asking for trouble.

    It's a bit like asking: which is the more secure server-operating system, some flavor of Linux or some flavor of Windows? Answer: it all depends on the skill level / familiarity level of the sysadmin maintaining the servers.
    Lesli Schauf, TLM Network
    Linux and Windows Hosting: Scribehost

  9. #9
    Join Date
    Sep 2001
    Location
    Seattle, WA
    Posts
    3,084
    PHP is easier for a lot of reasons -- often it's built into apache (less overhead -- no forking), no permission issues (all apache has to do is read it, not execute it).

    Of course, a mildly bad programmer can make a horrific mistake thanks to some very, very odd choices on the part of the designers of the PHP language and leave huge gaping security holes in their programs.
    Jim Reardon - jim/amusive.com

  10. #10
    Greetings:

    I'm Peter Abraham from our team (also the main poster here at WHT and several other places if that matters).

    Our company is small, so everyone wears many hats including me.

    One of the hats I wear is developer; and I actually use both Perl and PHP.

    I found the option to use both helpful, personally, as I will use Perl for glue work (aka cron jobs, stuff on the system level) and PHP for the GUI.

    Our clients appreciate both offerings; and while clients tend to use one or the other, it helps to offer both.

    Thank you.
    ---
    Peter M. Abraham
    LinkedIn Profile

  11. #11
    Peter,

    Since you're company specializes in server security, perhaps you have found an effective way to keep login information secure on a shared server (e.g., user/password info in a PHP script). Any help in this area would be really appreciated.

    The most effective method I've found is to use the php_value directive in my httpd.conf file.

  12. #12
    Greetings Matthew:

    We don't have a way to enforce customer programming practices.

    However:

    1. We use mod_security which helps from an overall security perspective.

    2. If your server is set up to allow customers to have a "home" directory outside of the Web area accessible by the Web server, then you can have one conifguration file by which you use to store the data.

    3. If you remember to name such files prefixed with a "." (dot), then you also increase the safety as well in terms of file visibility.

    4. We don't allow shared hosing customers SSH access; so that also helps.

    Thank you.
    ---
    Peter M. Abraham
    LinkedIn Profile

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •