[AlternC-dev] trying to temper the ruby choice ...

Retour à l'archive de la liste
Le site d'AlternC
Google Custom Search

Benjamin Sonntag benjamin at alternc.org
Mer 15 Aou 10:18:34 CEST 2007


Hi,

The Anarcat wrote:
> Hello!
>
> On Tue, Aug 14, 2007 at 05:35:30PM +0200, Benjamin Sonntag wrote:
>   
>
>> So we (Metaconsult) just started to think on a v2.0 that may be written
>> in php ... using a php framework
>> We didn't started to develop anything yet, but really want to discuss
>> this issue on this list ...
>> Do we want to produce a v2.0 as soon as possible ?
>>     
>
> My answer here would be "no". I want to produce a stable 1.0 as soon as
> possible and start working on small, disposable prototypes for a v2.0
> "some time soon" (which, considering my shrinking schedule, could mean
> anything from autumn to next summer).
>   

I will not start any code writing on 2.0 until the 1.0 is bug-free, and
until we know where and how we gonna go with this new version, and I am
ok with this.
Anyway, I don't think it's a good idea to ask Daniel to work on the
existing project if AlternD is gonna be a rewrite.
However, if you think that the learning curve to be able to help AlternC
1.0 debugging is not that hard for him (he is a good php developer), I
can ask him to look at 1.0 and help us with this. I have no fixed idea
on what we should do...

(a response will be gladly read)

>> It looks like some of the php frameworks available out there are really
>> good to implement quite clean MVC dev.
>>     
>
> I am sure that we'll need an existing framework, but I'm not sure that
> any PHP framework is going to cut it. I think that we should start by
> defining our needs and goals before choosing the technology we want to
> use, otherwise we'll always get drawn back to this (impossible) dillema.
>   
of course, and when I say that Zend Framework may be a good choice, it's
only a quick and dirty opinion : I just want to be sure that one
important criteria on the choice of the framework we will use will not
be forgotten : the stability and future of the chosen framework ...


>> * Quick framework comparison (the frameworks in this list are known to
>> be the best php frameworks in php)
>> http://www.phpit.net/demo/framework%20comparison/chart.php
>>
>> There may be some problem : if we use ruby, we may use it to handle
>> configuration files management and server-side treatments.
>> PHP will certainly not be the perfect language for this (shell scripts |
>> ruby scripts | php scripts | perl scripts may by use for system
>> administration scripts, but they are not equivalents ...) But it is
>> still possible with php.
>>     
>
> Yes, but it (php) sucks for this. As "ruby" in itself or any application
> we'll design from ground up.
>
> The idea was to join efforts with another community: AlternC is more
> than a "control panel", it is part of a more general "configuration
> management" problem. (In fact, I would say that v2.0 should be able to
> control an arbitrary number of services and easily be extended to
> provide SSH, FastCGI, WebDAV or other services to the users hosted on
> the platform.)
>
> In that perspective, we have the choice of reusing an existing piece of
> software to solve the configuration management problem (ie. puppet,
> cfengine, etc) or write our own. 
>   
I just talked about puppet with Nicolas (a big sysadmin) yesterday, and
we really agreed on this :

puppet (or cfengine) are not solving the configuration management issue
: they are just giving us some tools to handle those issues. It's a big
step though, but it still required a fairly big amount of work to really
solve this so big sysadmin issue ...

Puppet don't currently have a really good community sharing recipes, and
the developers are not really nice with patches coming from the
community : they have their idea on how things must be done, and this
may not help the adoption of puppet by system administrators (I may give
some example but I'm too lazy as for now...)

> I would strongly suggest avoiding writing our own, hence the suggestion
> of using puppet.
>
> Which doesn't mean that the web interface can't be written in PHP or any
> other language, actually. But I still think that the "thing" behind that
> manages those silly configuration files *will* have to be a solid
> configuration management engine, and I think it would not be wise to
> start that effort without considering the available frameworks there.
>   
Yes.

>   
>> If you think about it, yes, it means that puppet will certainly not be
>> used for this v2.0, but I also talked on puppet at the CCC Camp and the
>> guy who use it for years in a German university told me that puppet
>> learning curve is also huge, and that the developers don't want it to
>> get to far away from a certain point of view, which will undoubtedly be
>> problematic for AlternC (we are not maintaining many servers, but one
>> (or up to ten) machines with many services ...)
>>     
>
> I'm not sure I understand what you mean here: are you saying that Puppet
> is aimed at managing more servers than your typical AlternC
> installation?
>   
What I (hardly) try to explain here is a fear that puppet learning curve
and the work we have to do on recipes may be so huge that it prevent us
to make some good work in a reasonable amount of time ...
However, I still think that puppet is the only tool that can help us
resolving the config file problem, so it may be bad to do anything
without him.
(in fact it depends on the amount of work I feel like putting on new
AlternC version, and my opinion on puppet follows this variation ...
sometimes I like it for its power, sometimes I fear it for its hard
learning curve)


>>     [ Conclusion ]
>>
>> (regarding Daniel work)
>> If we go and do the v2.0 in PHP, Daniel will work on AlternC v2.0 most
>> of its time (at least 50% monthly), depending on the work he had on
>> Metaconsult, collaborating with other developers to obtain a v2.0
>> quickly. He will just follow the guidelines we give him. AlternC as an
>> organization may also help financially its work to make it go faster
>> (Daniel will, in this case, be 100% dedicated to the project) : in that
>> case we may discuss this point in IRC since most of the informations out
>> there may be confidential (how, how much, why & so on...)
>>     
>
> We definitly have to meet to discuss the financial details, that's for
> sure. As I understand, we do have some money to invest in AlternC, and
> that seemed to have stalled after my original "bounties" proposals:
>
> https://alternc.org/wiki/FondsDuLibre
>
> Now as for Daniel's work, I guess that it's up to you (Metaconsult) to
> choose how he will work, but it's nice to hear about it. :)
>   
yes, let's talk about it on IRC, just tell me there when you are
available and I will be there on time.

>> (regarding AlternC's future)
>> At the moment, I guess we should go to a v2.0 using php v5 and Mysql 5,
>> with MVC development & using something like Zend Framework, creating a
>> modularized web panel.
>>     
>  
> I'm not too hot on the Zend stuff, I'd rather go with Cake, Symphony,
> Seagull or ZooP, according to the comparison chart. We should also
> consider Drupal.
>
> That is for the frontend. For the backend, I'm still interested in
> working on Puppet or another configuration management engine:
>
> https://alternc.org/wiki/SystemConfiguration
>
> Otherwise, if we stick with PHP all the way, I'd rather look at what
> other projects are doing (syscp, ravencore and gplhost are all PHP-based,
> as far as I know, and are very complete software that we shouldn't try
> to reinvent for ourselves).
>
>   
Yes, but none of them looks nice regarding the usability, and many if
not all are completely written from scratch : they do not use any stuff
like puppet or a frontend framework.

In my opinion, in the modern web world, it's really a big drawback since
it prevents anyone to come and help easily, and also prevents a fluent
adaptation to new services and softwares.

That's also what AlternD should focus on

> In other words, for me, the only interest in AlternD is to get it to
> work on multiple machines easily, with solid config file management and
> easy extensibility. If we just rewrite AlternC in PHP5, we won't be
> anywhere closer to this, in my opinion.
>   
Yes, my point was not just to rewrite AlternC in PHP5, but really make
it the way we already talked about it as you write up there.

I just wanted to point out the problems with Ruby & Rails learning
curve, age, and real lack of competent developers in this field, that
will surely prevent us to develop easily a complete, usable, secured
frontend.


(Sorry for those long and complex answers, but we are really in front of
a big problem, let's take some time to discuss on it :) )


cu,

Benjamin Sonntag




Plus d'informations sur la liste de diffusion Dev