Bonsoir,
Je fais parti d une equipe de 6 developpeurs info embarquée sur cible linux/arm9.
On developpe actuellement depuis Linux/x86 grace a une chaine de compilation croisée.
Un premier projet sur cette cible a été lancé il ya maintenant un an et demi et le choix de la distrib pour les développeurs avait été fait au hazard; c'est tombé sur Redhat 9.0.
Il faut noter que nous n'avons pas d'administrateur UNIX sous la main.
Il y a quelque mois un des développeur et moi meme aons éte mis sur un deuxième projet reprenant pas mal d'élements du premier, et avons migré vers Debian SID ( donc pas les memes libs, outils de conf, ihm etc...) afin de profiter notamment de kdevelop3 , des  outils d'install debian tel apt-get et des mises à jour.
Notre responsable commun en a assez d'avoir un parc hétéroclite de par la difficulté d'administration et l'impossibilité actuelle de génerer le noyau arm9 depuis Debian par un système de géneration développé en interne et basé sur des Imakefiles.
Il va bientot falloir choisir entre l'une des 2 distrib et nous avons besoin d'arguments pour l'une et l'autre, merci de nous y aider.
 
ps: actuellement 8 pcs sont sous Red Hat 9.0  

• 4 machines de developpeurs  
• 4 serveurs/machines intégration

5 sous Debian

• 2 pc developpeurs linux  
• 2 pc windows avec colinux  
• un serveur  

et 2 sous Fedora core 3  

• 2 machines de devel pour tester une migration "simple" de la RH9.

merci.

Entre Red Hat 9.0 et Debian Sid, je vote sans hésiter Debian Sid, pour la bonne et simple raison que Red Hat 9.0 est obsolète et n'est plus maintenue.
 
Si la même question se pose entre Fedora et Debian Sid, c'est plus compliqué ; les deux distributions sont de bonne facture et elles bénéficient d'un support et d'un développement actif.
 
Je dirais presque qu'il s'agit d'avantage d'une question de goût que d'efficacité :
- soit on préfère le style Red Hat (philosophie, outils, .rpm)
- soit on préfère le style Debian (philosophie, outils, .deb)

Fedora n'est a priori pas dans les choix qui nous sont possible.
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).
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 ?
LOrsque l'on va se faire auditer par les resposnsables qualités il faudra prouver que lòn peut tout regénérer à l identique.
 
Personnelement je me suis créé des projets sous kdevelop 3.2  et il est relativement dur de l'installer sous Red hat 9 ,qui plus est sans péter les librairies servant à la génération des binaires.  
Les autres développent sous emacs...
 
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.

Tu ne peux pas tester sur une machine de test, voir ce que ça donne avec une debian sid ?

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.
 
 

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).
 
 

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).
 
 

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.

je pense effectivement que sarge sera prise si on choisi la debian, c esst jsute que pour le moment, on a installé une SID...
Merci pour tes arguments.

c'est une raclé pour la fedora

D'autant que vous avez tout à fait la possibilité d'utiliser Debian Sarge et d'exécuter dessus Debian Sid en chroot  

Autre: Debian Sarge