On Jun 17, 2009, at 8:54 AM, Les Mikesell <lesmikesell at gmail.com> 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