En entreprise, j'ai pendant longtemps utiliser le couple OCS/GLPI qui était parfait mais je trouvais cà un peu galère avec perl ou même pour debugguer l'application même si le site est bien documenté.
Tu ne dirais pas ça uniquement parce que tu ne connais pas le langage Perl ?
Par contre lorsque j'ai testé H-inventory il y a un installeur automatique donc bon à part certains modules pear à installer , j'ai trouvé cà plus rapidement abordable.
Le projet Oreon a lui aussi sorti sa pléthore de modules PEAR pour sa version 1.3 (sans même parler de PHP5). Ceci souffre d'un manque total de réalité par rapport aux environnements de production. On n'a pas encore PHP5 sous debian (non, ne me parle même pas d'utiliser un backport) et la plupart des modules PEAR n'existent pas.
Ensuite, les modules Perl pour le projet OCS existent déjà sous forme de paquets et j'aurais davantage confiance en certains modules Perl de CPAN qu'en la plupart des modules PEAR.
Et pour les clients, pas de dépendances à installer.
Avec des scripts écrits en bash, encore heureux mais en es-tu vraiment sûr ?
Le script bash pour linux fait appel à un script Perl (d'ailleurs fourni avec l'archive) et celui-ci fait appel aux modules SOAP::Lite et MIME::Base64 (respectivement fournis sous Debian par les paquets libsoap-lite-perl et perl). On ne peut donc pas dire qu'il n'y a pas de dépendances. Et à propos, je n'ai pas vu l'utilisation de dmidecode (utilisé par les agents d'OCSInventory-NG), les informations fournies ne seraient-elles pas pertinentes ?
Et même pour debugguer le serveur ce n'est que du php , par contre OCS le serveur de communication en perl j'ai eu beaucoup plus de mal à mettre les mains dedans.
Ce n'est pas une question de langage : quand un projet est mal codé, il est mal codé. Le PHP n'apportera rien de plus que le Perl à la compréhension. Et des projets mal ficelés en PHP, j'en ai déjà vu plein...
[^] # Re: OCSInventory
Posté par Raphaël SurcouF (site web personnel) . En réponse à la dépêche H-inventory : Un nouvel Asset Manager OpenSource. Évalué à 2.
Tu ne dirais pas ça uniquement parce que tu ne connais pas le langage Perl ?
Le projet Oreon a lui aussi sorti sa pléthore de modules PEAR pour sa version 1.3 (sans même parler de PHP5). Ceci souffre d'un manque total de réalité par rapport aux environnements de production. On n'a pas encore PHP5 sous debian (non, ne me parle même pas d'utiliser un backport) et la plupart des modules PEAR n'existent pas.
Ensuite, les modules Perl pour le projet OCS existent déjà sous forme de paquets et j'aurais davantage confiance en certains modules Perl de CPAN qu'en la plupart des modules PEAR.
Avec des scripts écrits en bash, encore heureux mais en es-tu vraiment sûr ?
Le script bash pour linux fait appel à un script Perl (d'ailleurs fourni avec l'archive) et celui-ci fait appel aux modules SOAP::Lite et MIME::Base64 (respectivement fournis sous Debian par les paquets libsoap-lite-perl et perl). On ne peut donc pas dire qu'il n'y a pas de dépendances. Et à propos, je n'ai pas vu l'utilisation de dmidecode (utilisé par les agents d'OCSInventory-NG), les informations fournies ne seraient-elles pas pertinentes ?
Ce n'est pas une question de langage : quand un projet est mal codé, il est mal codé. Le PHP n'apportera rien de plus que le Perl à la compréhension. Et des projets mal ficelés en PHP, j'en ai déjà vu plein...