Re: which programming language for server-side admin tasks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux