hello    
 
tout est dans le titre, d'après vous le différence de perf vaut-elle la chandelle ?
 
quels risques encourent-on à faire cela ? je pense à l'embarqué notamment, quand je vois iOS5 fluide sur un iphone 4 à 800mhz et
Android 4.2 qui ramouille sur mon SIII quad core à 1.6Ghz je me dit que Google devrait peut être prendre exemple sur Apple.
 
merci de rester courtois  

hormis la question trolliphère de la comparaison incomparable....
/* no comment*/
 
la compilation locale est trjs quoi qu'il arrive plus efficace qu'un package tout fais bien évidement...  
 
MAIS dans disons 99.99% des cas c'est visible que sur quelques secondes/jours pour une application qui tourne H24....
 
donc le ressenti utilisateur c'est ça et pas autre chose qui est important ne change souvent pas.
 
là où la compilation a du sens c'est que souvent 5/6 applis simultanées peuvent se géner l'une l'autre et générer des attentes de ressources ou ce genre de choses tout simplement parce qu'elles ont un port ou un device en dur dans le binaire ou les librairies...
 
si chacune est compilée, avec un makefile efficace et surtout un ./configure lancé avec les bonnes options par l'admin, ce genre de "goulot d’étranglement" n'existe plus....
 
mais en gros pour un utilisateur lambda ou même l'amateur éclairé... ça n'a pas de sens...de se taper les compilations.

je te remercie pour ta réponse, et non ce n'était pas un troll (d'ailleurs il va falloir arrêter de traiter les gens de troll à chaque fois qu'on compare/demande quelque chose)

c'est le goblin_rieur  
Après je dirais sensiblement la même chose, tout dépendra en fait de ton utilisation... mais aussi de la disponibilité d'un package pour ta distribution !
Ainsi en contre-exemple de ce que dit goblin_rieur, akizan voulait installer la dernière version d'Apache2 sur son Ubuntu, pas de pot elle n'est pas encore dispo en tant que package (.deb à part ou inclus dans les serveurs de redistribution), seule l'installation par compilation est disponible.
 
De la même manière, sur une distribution comme Arch ou sur une plate-forme Arm, l'étape de compilation est quelque chose de très courant.

on peut convertir des paquets d'un type à l'autre si on veux pas se faire ch..r à compiler aussi  
 
genre alien par exemple pour convertir un .deb en .rpm ou inversement

Tiens, pour l'anecdote, j'ai souvent téléchargé des programmes qui imposaient d'être compilés avant d'être exécutés...

Ca n'a JAMAIS fonctionné. Mais JAMAIS. Et ce quel que soit la distribution ou la bécane. Pourtant j'ai toujours suivi à la lettre les informations du readme, mais non.

ben on est 2 mais moi c'est parce que je suis pas bon

Tu peux aussi avoir la dépendance de merde qui va manquer, et qui n'est pas indiquée dans la doc officiel du logiciel ou du driver.
J'ai eu le cas avec une imprimante, dont il n'en existait pendant un moment pas de version précompilée (libre ou propriétaire). Forcément quand il faut libc-dev-bin alors qu'en standard c'est libc-bin qui est utilisé, forcément ça ne va pas fonctionner
Et proposé pourtant par... le constructeur de l'imprimante. Mouais bah les Xerox ColorQube, j'en veux plus

Excellente idée d'utiliser Alien... quand le deb qu'il te sort est correctement lu par Debian derrière. Là je suis un peu comme taxalot, pour l'anecdote, Alien n'a jamais réussi à me transformer du paquet rpm en deb.

pour contrer, j'ai souvent téléchargé des programmes qui imposait d'être compilé...
et franchement très peu d'entre eux se sont avérés problématiques
pour tempérer, j'avoue qu'il faut regarder la sortie du make attentivement (qd ça marche pas) pour se rendre compte
qu'il manque une header (.h) dans le package x-dev.versiontralalatsointsoin qui n'est pas installé.