I don't know, which platform is the best to ask this question, maybe
this is.
I think that web development will be very important in the life of
Parrot and Perl 6. One of the most important (at least as a server
administrator) feature of PHP, is that you can lock the programs into a
directory by defining "open_basedir". If the application try to open a
file from a directory not defined in it, that there will be an
exception. It's very useful for a hosting company, that two client's
program cannot read each other.
After this short introduction, I would like to ask you, that if it will
be possible with Parrot? Or the language should provide this feature
creating a wrapper for the I/O layer? Do you have a plan for it?
Bye,
Andras
I think Parrot is the wrong place to solve this problem. It's better to be
handled by the languages themselves.
Nope, parrot's the right place to solve this
problem, otherwise the problem's not solved.
Security needs to be implemented by the platform
(which, in this case, would be parrot) if you
want it to work.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
I agree, that's why I sent this letter to this mailing list. Anyway, I
think this feature would be very useful for all the scripting languages
for CGI scripting and for mod_parrot, too (I'm missing this feature from
Perl 5), and maybe not just for the web, but for console and other type
of applications.
Let me mention an other feature related to this topic: disabling
built-in functions, because limiting file access by I/O is not enough,
if you can use system(), `` and other things.
An other question is, that how can you tell to the platform, to limit
these features, maybe non-modifiable environment variables and command
line parameters can be the ways of it.
Bye,
Andras
For that you need a full-blown quota and
privilege system. Luckily there are plans for
one. :)
As far as boxing a VM into a sub-directory, etc. UNIX (chroot) and VMS make
this a breeze since
the mechanisms are builtin to the OS, it is Windows where all the work has
to be done.
Maybe Windows has matured since the last time I looked at this sort of
thing, but most
sys admins I know still prefer to run their JVMs, app servers, etc. in a
UNIX environment
just for this reason.
Solaris 10 just took it to a new level with "zones" although there have
been similar patches
out there for BSD and Linux for a long time.
-Melvin
>>> An other question is, that how can you tell to the platform, to limit
>>> these features, maybe non-modifiable environment variables and
>>> command line parameters can be the ways of it.
>>
>> For that you need a full-blown quota and privilege system. Luckily
>> there are plans for one. :)
>
> As far as boxing a VM into a sub-directory, etc. UNIX (chroot) and VMS
> make this a breeze since
> the mechanisms are builtin to the OS, it is Windows where all the work
> has to be done.
I'm not a UNIX guru, but I don't know an easily installable solution for
the problem. I would like to run just one Apache, and would like to run
Perl as an Apache module. Chroot I think is not a solution for it.
Running the script as CGI or running as much Apaches as much client you
have is not a solution for me and for a lot of people. PHP offer an easy
way to solve this problem.
Perl was the most famous web development environment some year ago,
today PHP is that. I think one of the reasons is this. (Anyway, Parrot
and the Languages should work on all platforms, not just some - a lot of
people using Windows as development platform).
Bye,
Andras
It's important here to note that when I said
"platform" I meant "Parrot". (That was in there,
but it's worth being clear about) That is, the
platform is Parrot, not the OS parrot is running
on, and Parrot is responsible for any security
guarantees it makes. Now, it may make them by
using facilities the OS provides (which makes the
job easier) but it doesn't have to -- it can and
will do it with no OS help if need be.
>> I'm not a UNIX guru, but I don't know an easily installable solution
>> for the problem. I would like to run just one Apache, and would like
>> to run Perl as an Apache module. Chroot I think is not a solution for
>> it. Running the script as CGI or running as much Apaches as much
>> client you have is not a solution for me and for a lot of people. PHP
>> offer an easy way to solve this problem.
>
> You obviously are talking about a web hosting environment with multiple
> applications and customers.
Yes.
> I did not mean that chroot() was the solution, it is however part of the
> solution on the UNIX
> environment if you want proper security.
I agree, but it cannot solve the problem (a customer can read the
other's program), just using a lot of extra resources.
>> Perl was the most famous web development environment some year ago,
>> today PHP is that. I think one of
>
> I disagree. How do you support that blanket statement?
This is my experiment in Hungary about web development. PHP is the most
famous language, after it Java and .Net comes and Perl is after them.
Hosting companies have very few "Perl clients", and they don't like them.
We had a meeting (workshop, mini-conference) in Hungary a few months
ago, and we talked about the Perl vs. PHP thing. We think that people
choose PHP for web development 'cause it can be easily installed and you
get results in a short time, plus it's hard to setup a Perl environment
that's secure.
> I don't have any customers using PHP, they either use Java (some J2EE
> container, Oracle, BEA, Websphere, Tomcat) or they use Perl (CGI or
> mod-perl), etc.
I have just PHP customers. ;) :(
> I agree with your statement if you are talking about small web-site
> hosting. 30 bucks a month
> for a website and you host 100 sites on a single shared server. PHP has
> a large share of that market,
> but for medium to large complexity apps, specifically commercial
> enterprise apps, PHP has
> very little presence. The marketing dollars are all behind Java and .NET.
Totally agree.
> I guess it just goes to show we all swim in different ponds.
I think, you are right. ;)
> Anyway, I did not mean to start a tangent, I want to see PHP run well on
> Parrot so we can agree on that.
:)
Anyway, I'm not talking about PHP. I'm talking about how I think Parrot
and Perl 6 can be sucessful in the web development area.
Bye,
Andras
ps: And I'm finished it. ;)
>I'm not a UNIX guru, but I don't know an easily installable solution for
>the problem. I would like to run just one Apache, and would like to run
>Perl as an Apache module. Chroot I think is not a solution for it. Running
>the script as CGI or running as much Apaches as much client you have is
>not a solution for me and for a lot of people. PHP offer an easy way to
>solve this problem.
You obviously are talking about a web hosting environment with multiple
applications and customers.
I did not mean that chroot() was the solution, it is however part of the
solution on the UNIX
environment if you want proper security.
>Perl was the most famous web development environment some year ago, today
>PHP is that. I think one of
I disagree. How do you support that blanket statement?
I don't have any customers using PHP, they either use Java (some J2EE
container, Oracle, BEA, Websphere, Tomcat) or they use Perl (CGI or
mod-perl), etc.
I agree with your statement if you are talking about small web-site
hosting. 30 bucks a month
for a website and you host 100 sites on a single shared server. PHP has a
large share of that market,
but for medium to large complexity apps, specifically commercial enterprise
apps, PHP has
very little presence. The marketing dollars are all behind Java and .NET.
I guess it just goes to show we all swim in different ponds.
Anyway, I did not mean to start a tangent, I want to see PHP run well on
Parrot so we can
agree on that.
-Melvin
I politely request that we not have a Perl vs PHP popularity discussion here.