Quels sont les avantages de créer des outils / bibliothèques à partir de la source?

En construisant à partir de la source, gagnez-vous des avantages? Le code est-il mieux optimisé pour votre architecture matérielle? Est-il mieux optimisé en général?

Pourquoi quelqu'un choisirait-il de construire à partir de la source plutôt que d'utiliser un système de gestion de paquets comme APT / yum? S'il y a une sorte de gain d'optimisation, quand cela l'emporte-t-il sur l'avantage d'un système de gestion de paquets?

Vos deux choix ne s'excluent pas mutuellement. Vous pouvez personnaliser les sources d'un package ou même le packer vous-même.

Faheem Mitha

Réponses:

La construction à partir des sources fournit les options suivantes qui ne sont pas disponibles lors de l'utilisation d'une version à partir d'un gestionnaire de packages binaires.

La compilation à partir de la source vous permet de:

utiliser des optimisations spécifiques au processeur
utiliser la toute dernière version
découvrez comment la compilation et les liens fonctionnent (suggestion de @mattdm)
correction de bugs, travaux de développement
définir les options de compilation (par exemple inclure des fonctionnalités X dans vim)

Shawn J. Goff
la source

pour un utilisateur de bureau ordinaire, le gain en optimisations spécifiques au processeur vaut-il le coût de la complexité de la gestion manuelle des dépendances entre les logiciels? Est-ce comme un gain de 2% ou un doublement des performances?

Doug T.15

@Doug Pour les logiciels lourds, la différence peut être de 10 à 20%, pour les logiciels de bureau typiques, la différence est nulle. Si vous voulez essayer de compiler des logiciels à partir des sources, je recommanderais une distribution basée sur les sources (par exemple Gentoo). C'est une très mauvaise idée d'installer un logiciel à partir de la source (à part un logiciel tiers installé dans / opt) dans une distribution binaire.

Šimon Tóth

Je pense que les performances ne valent pas la peine de sortir des dépendances de votre gestionnaire de paquets. Cependant, il existe des systèmes de gestion de packages basés sur la source qui gardent une trace des dépendances et vous permettent de compiler à partir de la source. L'avantage répertorié ci-dessus que vous n'obtenez pas avec cela n'est que la «toute dernière version» - le gestionnaire de paquets a une version choisie qui fonctionnera avec le reste de la distribution.

Shawn J.Goff

La seule chose que j'ajouterais est: en savoir beaucoup plus sur ce qui se passe sous le capot. Cela peut valoir la peine en soi.

mattdm

J'ai fait cette chose très récemment.

J'ai compilé openssl-1.0.something à partir de la source sur un système Linux Slackware 11.0. Je voulais corriger la connexion par mot de passe pour faire une pause de 7 secondes sur une connexion échouée, afin de cibler ces devineurs de mots de passe chinois ssh ennuyeux.

J'ai compilé Apache httpd 2.2.17 sur le même système Slackware 11.0 car il était livré avec Apache 2.0.something, et je voulais utiliser un httpd.conf 2.2.x d'un autre système.

À bien y penser, j'ai également compilé Alpine 2.0 (client de messagerie, suivi de pin) pour le même système. Pourquoi Slackware 11.0? Il fonctionne sur une machine vers 2003 avec des graphiques Intel "Brookdale", et tout Slackware ultérieur ne prend tout simplement pas en charge les graphiques Intel mal documentés.

Sur une autre machine, j'ai retiré le support de puce sans fil TI ACX111 de github et compilé un nouveau pilote, me permettant d'utiliser une carte sans fil à 9 $.

Je recompile aussi habituellement les noyaux Linux pour les rendre spécifiques à la machine sur laquelle ils tournent.

Donc, dans mon cas, ce sont diverses raisons de personnalisation, de prise en charge matérielle et de "juste parce que".

Compte tenu de ce que nous savons de l'épidémiologie dans une population uniforme (http://www.usenix.org/publications/login/2005-12/openpdfs/geer.pdf), pourquoi tout le monde ne compile-t-il pas à partir de la source sur son propre système, quel que soit les options de compilation qu'ils choisissent? Cela créerait une population beaucoup plus résistante aux virus et aux vers.

Bruce Ediger
la source

Il existe des moyens plus simples de ralentir ces mécréants ssh-hammering ... recherchez la limitation de débit iptables. Cette solution a une applicabilité plus large et n'annule en outre pas votre garantie.

vonbrand

Généralement, Linux n'est pas accompagné d'une garantie. Slackware 11 a quelques années à ce stade. Vous posez la question avec FUD, en particulier, "la peur". "Oh non! Ne fais pas ça! Tu annuleras ta garantie!" Combien de fois peut-on se fier à une garantie? Très peu. Nous aimerions tous que quelqu'un prenne la responsabilité (surtout morale, mais surtout financière) de toutes nos actions, mais cela ne peut tout simplement pas se produire sans beaucoup de mauvaises conséquences pour les individus et la société. Je maintiens mon conseil, et plus encore: compilez vous-même la source et prenez toute la responsabilité. Ne blâmez personne d'autre.

Bruce Ediger

Oh, allez. Si c'est RHEL ou SLES (ou même Ubuntu LTS avec un contrat de support), il y a certainement une garantie à annuler. S'il s'agissait de Debian ou Fedora, un rapport de bogue pour votre OpenSSH piraté sera simplement fermé sans regarder deux fois.

vonbrand