Gentoo Archives: gentoo-user

From: Grant <emailgrant@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] non-PHP webmail in portage?
Date: Mon, 12 Jan 2009 20:32:01
Message-Id: 49bf44f10901121228g27a0823ag6a35ee0e4d99e08d@mail.gmail.com
In Reply to: Re: [gentoo-user] non-PHP webmail in portage? by kashani
1 >>>> Does anyone know of a good (or OK) webmail client in portage that
2 >>>> doesn't use PHP? I use squirrelmail now but I have PHP installed only
3 >>>> for that and I think PHP slows apache2 down a bit.
4 >>>>
5 >>>> - Grant
6 >>>>
7 >>> I don't think you'll find anything faster except maybe written in C,
8 >>> which
9 >>> is doubtful. The only other language you might find webmail written in is
10 >>> Perl/CGI and that is definitely not faster in my experience. PHP is about
11 >>> as
12 >>> good as you will get IMHO.
13 >>
14 >> I actually don't mean to speed up squirrelmail and PHP. The main
15 >> function of that system is to run a website in perl, and I thought I
16 >> might be bogging down apache2 a bit just by opening it up to PHP
17 >> interpretation (-D PHP). Is that the case? It would also be nice not
18 >> to be exposed to PHP exploits. It just seems kind of silly to
19 >> maintain and run PHP just for webmail.
20 >>
21 >> - Grant
22 >>
23 >
24 > Adding -D PHP makes your memory footprint larger, but unless you're
25 > actually using PHP that's the only side affect of loading it. If you're
26
27 Maybe PHP isn't so bad then.
28
29 > concerned about security, make sure you're using the sushosin USE variable
30 > and keeping PHP and Squirrelmail up to date. Regardless of which language or
31 > mail package you use you're going to have to keep them updated.
32
33 A daily 'emerge --sync && emerge -avDuN world' is on my list of
34 favorite things to do.
35
36 > One other thing to think about is whether or not finding a Perl
37 > webmail system is going to make your life any easier. Say you do find one
38 > and it installs a ton of Perl modules like all Perl applications. Some of
39 > those will be updates of Perl modules that your actual site depends on which
40 > may or may not break the site. Now you've got two applications to QA when
41 > you update any Perl module that is a dependency of both.
42 >
43 > kashani
44
45 Thanks for the advice and it sounds like running PHP isn't so bad after all.
46
47 - Grant