On Jun 17, 2009, at 8:54 AM, Les Mikesell <lesmikesell@xxxxxxxxx> wrote:
> Karanbir Singh wrote:
>> On 06/15/2009 05:31 PM, Rudi Ahlers wrote:
>>> What I meant was, PHP talks to PHP script engine, which talks to
>>> Apache,
>>> which then talks to system commands. - is there a quicker way of
>>> doing it?
>>
>> you might find that this is the fastest way of doing things in a
>> single
>> stack, if you dont have state movement. Have you looked at the
>> complexity of getting a java stack or a ruby stack up ( as a
>> comparison ) ?
>
> With java, you should be able to use the stock openjdk and tomcat5
> packages (finally!) and be all set so it is a matter of dropping war
> files in the right place. Even complex things like hudson or opengrok
> will 'just work' (and if you do any software development you should
> look
> at both).
>
> On the other hand the guy here using ruby doesn't think the packaged
> Centos stuff is usable. Realistically, it is hard to keep complex
> modular tools where you want to use at least some of the very latest
> parts in sync with what an enterprise distribution packages. That
> might
> be sort-of a plus for python if you can live with whatever version yum
> needs and pay attention to what is going to break when it does version
> changes.
That is the truth.
I wish the enterprise distros would "unbundle" the LAMP stack from the
core OS, it just moves too fast to include in a long-term support
program. They should make it a separately maintained but compatible
add-on feature set (make a separate repo of it), maybe with a stable
and current version branch.
I have always felt the distros include way too much in the core OS
which could be better off in an "extras" or even "contrib" repo.
Things like openoffice, firefox and the like don't need to be in the
OS distribution, but available to install the latest stable version
from the add-ons repo. Doesn't mean you can't include these on the
media, sure, just as a separate repo on the media.
It would be making, supporting and updating the core OS a magnitude
less complex and would put the burden of making sure the LAMP or add-
on packages are compatible with the core OS onto their respective
maintainers or groups, but with proper notification and testing cycles
it could be managed successfully.
I also think there should be a single version of an OS that stays more
current over time, not the bleeding edge but the stable edge. Instead
of backporting kernel features, make small point jumps along the way,
say from 2.6.18 to 2.6.20 when the latest is 2.6.26 and when the
latest is 2.6.30 move to 2.6.24 and so on.
I think I've wandered too far OT now...
-Ross
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
