Dans ce cas il est intelligent de penser à passer sous Debian ; à terme Red Hat 9.0 ne sera de toute façon plus exploitable, il est préférable d'y penser avant l'échéance et de planifier une migration correctement. Se retrouver bloqué en plein développement en raison de problème de maintenance est catastrophique, il est logique d'établir au préalable un plan de suivi pour la plateforme avec laquelle on développe.
psebcopathe a écrit :
Le problème numéros 1 c'est l administration des machines car vu qu'elles n'ont pas les memes version de logiciel, les fichiers de conf sont souvent différents.
La Red Hat a servi de plateforme pendant 1 an est la plupart des developpeurs savent maintenant bien s en servir, et les outils de compilation ont été bien validés, ce qui n'est pas encore le cas sous Debian (creation du noyau linux arm).
|
Le passage à Debian n'est pas impossible : comparé à Red Hat 9.0, la prise en main des systèmes Debian est relativement rapide. Un autre avantage sont les nombreux outils Debian dédiés aux tâches de configuration et de maintenance (installation, déploiement, mise à jour, etc) : ceux-ci sont puissants, souples et robustes, ce qui permet d'administrer le système aisément tout en pouvant garder un contrôle total sur les opérations effectuées. La création de noyau GNU/Linux pour architecture arm ne devrait pas poser de problème : Debian fonctionne sur un très grand nombre d'architecture, et la création de noyau "maison" est grandement facilité avec l'outil kernel-package / make-kpkg (on peut créer ces propres noyaux à partir de n'importe quelle source souhaité et les compiler très simplement en binaire -au format .deb- ; il est possible de créer des noyaux génériques à partir d'une machine dédié et de les distribuer sur des machines cibles ensuite).
psebcopathe a écrit :
Par ailleurs si on passe sous Debian sera t'on vraiment capable de regénérer exactemant les memes binaires au bit près que ceux livrés au client il y a un an.
L'environnement de compilation a donc changé, faut t il dédier des PCs uniquement à ce but est-ce nécéssaire ?
|
Cet aspect là est en effet complexe, et risque certainement de poser problème ; il faut noter cependant qu'il n'est pas forcément spécifique à telle ou telle distribution, celui-ci pourrait se poser exactement de la même façon sous Red Hat 9.0. Un changement de compilateur et de nouvelles lib entraînent systématiquement une profonde modification de l'environnement de développement ; un même paquet créé avec deux compilateurs différents produira systématiquement deux binaires différents, il est donc impossible de regénérer les mêmes binaires lorsque l'environnement de développement a été modifié (compilateur, libs).
Il n'est pas obligatoire d'utiliser des machines spécifiques pour la compilation de binaire, on peut tout à fait effectuer cette opération dans des environnements chrootés (et ainsi de disposer de plusieurs compilateurs sur le même système).
psebcopathe a écrit :
Moi je suis pour des outils récents et ergonomiques , donc pour ceux présents dans la Debian SID, cependant il faudra aussi figer pour tous cette version à une date car on ne peux pas se permettre de faire évoluer tous les mois la distribution.
|
Avoir des outils récents mais figés est contradictoire, en général bénéficier d'outils récents implique des mises à jour régulières. S'il vous faut un environnement de développement figé, pourquoi vouloir opter pour Debian Sid (unstable) ? Ne vaudrait-il pas alors mieux réfléchir à opter de préférence pour Debian stable (ou future stable, Sarge) : elle offre un environnement extrêmement fiable et garantie d'avoir un environnement non soumis à de fréquents changements pouvant perturber la production.
---------------
THRAK (def.) : 1) A sudden and precise impact moving from intention, direction and commitment, in service of an aim. 2) 117 guitars almost striking the same chord simultaneously.
FORUM HardWare.fr
