J'ai du mal à comprendre les formats exécutables Linux et les packages de distribution de logiciels. Il existe tellement de distributions différentes de Linux lui-même, et il semble que chaque progiciel a été compilé séparément pour chaque distribution. Pourquoi est-ce? Je comprends que certains "packages" sont faits pour être installés sur différentes distributions, mais le format exécutable du logiciel est-il différent?

Aussi, pourquoi de nombreux utilisateurs Linux préfèrent-ils les versions d'invite de commande des applications par rapport aux versions GUI? Je peux comprendre le besoin de petites empreintes, mais même les applications GUI peuvent avoir de petites empreintes si elles sont correctement codées.

Gestionnaires de packages et dépendances

La plupart des distributions Linux utilisent des gestionnaires de packages pour l'installation et la suppression de logiciels. Les gestionnaires de packages offrent certains avantages tels que la possibilité d'utiliser un référentiel central à partir duquel (presque) n'importe quel logiciel peut être téléchargé, l'organisation des logiciels en bundles pouvant être installés en tant que groupe cohérent, et les principaux avantages: automatique gestion des dépendances et suivi des modifications apportées aux packages afin de pouvoir les désinstaller.

Certains logiciels peuvent nécessiter certaines bibliothèques ou d'autres programmes pour effectuer des tâches qui seraient redondantes si elles étaient réimplémentées dans ce logiciel. Les packages permettent l'expression de ces dépendances.

Différences: formats et stratégies de package

Il existe plusieurs gestionnaires de packages différents. Chacun a été créé parce que ceux existants ne répondaient pas aux besoins de certaines personnes. Chaque gestionnaire de packages requiert des packages dans son propre format.

En outre, différentes distributions ont des exigences différentes du logiciel inclus. Il existe un certain nombre de logiciels qui peuvent avoir des capacités différentes selon les options qui sont données lors de sa compilation à partir du code source dans un exécutable de la machine. Certaines distributions veulent fournir des ensembles de fonctionnalités complets et une expérience riche tandis que d'autres veulent fournir une expérience aussi simple et simple que possible, et il y a tout le reste. De plus, la distribution peut décider de formater sa structure de répertoires différemment ou d'utiliser un système d'initialisation différent. Ils peuvent décider de regrouper le logiciel différemment: il peut y avoir un package appelé "dev-utils" dans deux distributions différentes, mais une version de celui-ci inclutyacctandis que l'autre ne le fait pas. En raison de ces différents besoins, les distributions choisissent de compiler le logiciel de différentes manières.

C'est pourquoi même si vous avez un package au format correct pour votre gestionnaire de packages, il peut ne pas fonctionner si le package était destiné à une distribution différente. Par exemple, ce package peut dépendre de yaccson installation, et il a exprimé cette dépendance en exigeant le package "dev-utils", mais votre "dev-utils" ne comprend pas yacc. Maintenant, un package est installé avec une dépendance non satisfaite.

Ce n'est pas vraiment un problème.

Une grande partie d'une distribution Linux consiste à maintenir un référentiel logiciel central. La distribution s'occupe de maintenir tout cela pour vous. Cela facilite en fait l'installation du logiciel. Vous utilisez généralement le gestionnaire de packages pour rechercher et sélectionner certains packages, puis lui dire de les installer; il s'occupe du reste pour vous. Le processus d'installation de logiciels Windows comprend la recherche de logiciels sur des sites Web tiers, la recherche du lien de téléchargement approprié, le téléchargement, la détection de virus et l'exécution d'un programme d'installation qui vous pose ensuite un tas de questions non pertinentes. Ce désordre n'est pas la norme sous Linux.

Le référentiel ne peut pas tout inclure

Maintenant, il peut y avoir des cas où un logiciel dont vous avez besoin ne se trouve pas dans le référentiel de votre distribution. Les packages fournis par un référentiel logiciel sont l'une des caractéristiques différenciantes des distributions. Lorsque vous ne trouvez pas le logiciel dont vous avez besoin dans les référentiels de votre distribution, il y a trois avenues possibles (en fait, deux plus un moyen de vraiment bousiller).

Dépôts communautaires

De nombreuses distributions ont des référentiels non officiels gérés par des personnes non associées à la distribution. Ubuntu les appelle PPA, Fedora les appelle Fedora People Repositories. Arch Linux n'a pas de nom spécifique pour les référentiels tiers , mais il a son AUR, qui est une collection de "recettes" pour les packages (note: il n'y a qu'un seul AUR). Vous pouvez d'abord essayer d'installer un package à partir de l'une de ces sources car il est facile de les désinstaller s'ils ne fonctionnent pas.

Compiler à partir de la source

Si vous ne trouvez pas un référentiel non officiel avec ce dont vous avez besoin, la compilation à partir de la source n'est pas difficile. Vous devez avoir installé le package de développement de votre distribution; cela inclut des éléments de base comme un compilateur, un éditeur de liens, un analyseur et d'autres outils qui sont généralement nécessaires pour la compilation de logiciels. Ensuite, vous trouvez le code source du projet (qui est presque toujours empaqueté dans un .tgzou .tbz(appelé "tarball"). Téléchargez-le dans son propre répertoire quelque part, extrayez-le (en utilisant tar -xf filename.tgz, et allez généralement dans le seul répertoire qu'il a créé. Dans ce répertoire peut être un fichier appelé READMEou INSTALL. S'il existe, allez-y et lisez-le. La plupart d'entre eux vous disent de faire la même chose. Les étapes suivantes sont effectuées sur une ligne de commande. Exécutez lset recherchez un fichier exécutable appeléconfigure. S'il existe, exécutez-le en faisant ./configure; cela peut parfois prendre quelques minutes. Cela exécute généralement des tests pour comprendre comment votre distribution a les choses configurées, et vous garantit que vous disposez des outils nécessaires pour compiler ce logiciel. La prochaine étape consiste à exécuter make. En fait, cela compile le logiciel, et cela prendra probablement un certain temps - de quelques minutes à quelques heures selon la taille du logiciel que vous compilez. Une fois cela fait, vous exécutez make install. Cela installe le logiciel, ce qui implique de copier les produits de la compilation aux endroits appropriés de votre système de fichiers. Après cela, le logiciel est disponible pour utilisation.

C'était une longue section, mais elle est résumée comme "README, ./configure, make, make install" . C'est la routine à retenir.

Installer un package à partir d'une autre distribution (ne faites pas cela)

Je liste ce seulement parce qu'elle est et alternative, mais il sera certainement pas bien finir. Il est possible d'installer des packages pour d'autres distributions, et vous pourriez avoir envie de le faire. Et bien non. Ne le faites pas avant d'avoir bien compris votre système. En fait, je ne vais pas mettre de commandes ici montrant comment le faire même si c'est possible. Si vous arrivez au point où il semble que ce soit la seule option, n'installez pas le package à l'aide du gestionnaire de packages; au lieu de cela, retirez les éléments du package et placez-les dans votre système manuellement, avec des notes sur ce que vous avez fait afin de pouvoir les annuler si nécessaire.

Le bit de ligne de commande

Certaines personnes préfèrent la ligne de commande pour les avantages qu'elle leur offre. Ceux-ci peuvent être résumés en trois choses:

• Automatisation simple
• Vitesse (par rapport à un clic partout dans un gui)
• Expressivité

Le plus grand d'entre eux est l'expressivité; il y a des choses qui peuvent être faites sur une ligne de commande qui ne sont pas possibles dans une interface graphique.

Enfin, les instructions de ligne de commande sont fréquemment données dans des forums utiles tels que celui-ci car il est beaucoup plus facile de transmettre les informations correctes que de donner des instructions de type «cliquez-ici-puis-là-puis-là».

Désolé pour la longue réponse. Si vous voulez du rapide et du sale, lisez simplement le résumé.

Sommaire

• Le format exécutable est le même.
• Il existe différents gestionnaires de packages qui ne sont pas compatibles, même si les programmes emballés le sont. (Vous pouvez voir un package comme un fichier d'installation comme des .msifichiers).
• Fondamentalement, différentes distributions / versions ont différentes versions des bibliothèques de base, et pour des raisons de cohérence et de stabilité, les applications doivent être construites sur ces versions. (Version Linux de l'enfer dll).
• Différentes distributions font les choses de manière légèrement différente, ce qui peut dans certains cas être un problème de compatibilité.
• La ligne de commande peut être plus rapide et la ligne de commande unix est bien meilleure que la ligne de commande Windows.

Gestionnaires de packages

Tout d'abord, les gestionnaires de packages. Le principal objectif d'un gestionnaire de packages est de maintenir une base de données des packages installés et des fichiers qui constituent ce package.

Les gestionnaires de packages permettent une installation facile des packages, et généralement également une suppression facile. Ils permettent également aux packages de spécifier divers scripts qui pourraient devoir être exécutés lors de l'installation / la suppression pour maintenir la cohérence du système (comme l'enregistrement du package dans une base de données liée au sous-système).

Différents gestionnaires de packages

Il existe différents gestionnaires de packages avec des forces et des faiblesses différentes. Les exemples sont rpm et le gestionnaire de paquets debian (fichiers .deb), mais il y en a d'autres. Ces gestionnaires de packages ont évidemment besoin de formats différents et ne sont donc pas compatibles.

Différentes distributions ou versions

Comme la majorité d'une distribution Linux est open source, il y a beaucoup plus de réutilisation de code que sur les systèmes Windows. Une application peut utiliser plusieurs bibliothèques pour différentes parties de ses fonctionnalités. Ces bibliothèques elles-mêmes le font souvent aussi, parfois la même bibliothèque.

Malheureusement, les bibliothèques existent dans différentes versions et certaines d'entre elles ne sont pas compatibles (en particulier la compatibilité binaire pour les exécutables précompilés). Plusieurs versions peuvent bien coexister sur les systèmes Unix (moins d'enfer dll de ce point de vue), mais dans la plupart des cas, l'utilisation de deux versions différentes d'une bibliothèque dans un programme en cours d'exécution demande des plantages.

Les distributions binaires mettent donc souvent à niveau leur propre version pour passer à de nouvelles versions de divers packages de base (dans d'autres cas, vous avez besoin de grosses mises à jour).

Différents autres fichiers

Les distributions diffèrent également par la façon dont se trouvent certains fichiers et la façon dont la configuration est gérée. Selon le package qui pourrait avoir un impact sur ce package.

Ligne de commande

Unix est principalement un système d'exploitation de station de travail et de serveur. Cela signifie qu'il est conçu pour les administrateurs système professionnels. L'automatisation est un élément important de la boîte à outils d'administration système et les scripts shell sont le moyen de le faire. Essayez d'ajouter un 0 à 1 000 premiers noms de fichier dans le gestionnaire de fichiers graphique.

Comme les administrateurs administrent souvent de nombreuses machines, ils doivent faire les mêmes choses sur un certain nombre de systèmes. En utilisant des outils comme ssh, il est extrêmement facile d'effectuer la tâche sur un certain nombre de systèmes en une seule fois, et attendez simplement de laisser l'ordinateur faire le travail.

La spécification, l'automatisation et la répétabilité précises rendent la ligne de commande bien meilleure que les outils graphiques pour les tâches d'administration. Unix a également un certain nombre de shells différents disponibles et cette compétition a créé des shells extrêmement puissants qui sont presque incomparables avec l'invite de commande Windows.

Microsoft l'a bien compris et propose PowerShell en remplacement de la ligne de commande.La dernière version du serveur Windows est principalement administrée par ligne de commande.

Les formats exécutables sont tous les mêmes dans toutes les distributions, mais les exécutables peuvent nécessiter des logiciels sous-jacents supplémentaires pour fonctionner correctement. Si vous regardez les distributions basées sur Redhat, le produit d'installation est un rpm, qui inclura toutes les exigences pour un logiciel donné et n'installera pas par défaut ce logiciel à moins que les exigences ne soient remplies. ( yumest une alternative àrpmet il est utilisé par certaines versions basées sur Redhat). Par définition, une interface graphique doit avoir une empreinte beaucoup plus grande qu'une interface d'invite de commandes. La philosophie sous-jacente d'UNIX est de tout simplifier pour qu'une tâche donnée fonctionne le plus efficacement possible. C'est pourquoi il y a tant d'utilitaires qui effectueront une seule tâche avec la sortie de cette tâche pouvant être chaînée à l'entrée d'une autre tâche pour faire autre chose.

Différentes distributions ont des prérequis d'installation différents. Cependant, il existe des RPM ou DEB (ou d'autres packages pour d'autres systèmes de gestion de paquets), qui fonctionnent pour plus d'une distribution. La philosophie de Linux rend les codes sources facilement disponibles. Lors de la compilation de votre propre logiciel, c'est à peu près la même routine sur toutes les distributions, et c'est toujours la même .tar.gzarchive que vous utilisez.

Les RPM compilés sont plus comme une partie du système; une application elle-même, en tant qu'entité autonome, est destinée à être distribuée et compilée sur chaque cible.

Votre deuxième question est quelque chose de complètement différent ... Eh bien, "beaucoup d'utilisateurs Linux" préfèrent les applications CLI pour de nombreuses raisons différentes, la faible empreinte mémoire n'est qu'une raison. Lorsque vous utilisez SSH, les applications CLI ont plus de sens, en particulier lorsque vous travaillez hors site sur des serveurs. Le plus souvent, ces serveurs n'ont pas d'environnements graphiques installés. Lors de l'exécution de programmes non démonisés, ils sont très faciles à abandonner. Ctrl- c, et le programme a disparu. En outre, de nombreux programmes se connectent à la console, il est donc plus facile de déboguer. Lors de la programmation, vous effectuez la majeure partie de la compilation dans la console. Cela a juste plus de sens pour un débogage de compilation rapide. C'est soit cela, soit la lecture des fichiers journaux, parfois, la lecture de la console est plus rapide.

Cambre. Ou FreeBSD, qui est développé dans son ensemble. (RHEL, SLES et similaires sont $ pris en charge dans leur ensemble.)

Utilisation d'un ordinateur portable: menthe

Piratage utilisable: Arch.

Piratage sadique: Genoo.

Piratage amusant: LFS.

Prise en charge (serveur): RHEL, Ubuntu LTS, FreeBSD (différent de Linux).