Tengo problemas para comprender los formatos ejecutables de Linux y los paquetes de distribución de software. Hay muchas distribuciones diferentes de Linux en sí, y parece que cada paquete de software se ha compilado por separado para cada distribución. ¿Por qué es esto? Entiendo que algunos "paquetes" están hechos para instalarse en diferentes distribuciones, pero ¿el formato ejecutable para el software es diferente?

Además, ¿por qué muchos usuarios de Linux prefieren las versiones del símbolo del sistema de las aplicaciones frente a las versiones de la GUI? Puedo entender la necesidad de pequeñas huellas, pero incluso las aplicaciones GUI pueden tener pequeñas huellas si están codificadas correctamente.

Administradores de paquetes y dependencias

La mayoría de las distribuciones de Linux usan administradores de paquetes para la instalación y eliminación de software. Los administradores de paquetes brindan algunos beneficios, como la posibilidad de utilizar un repositorio central desde el cual (casi) se puede descargar cualquier pieza de software, la organización de piezas de software en paquetes que se pueden instalar como un grupo cohesivo y los principales beneficios: automático manejo de dependencias y seguimiento de los cambios que hacen los paquetes para que puedan desinstalarse.

Ciertas piezas de software pueden requerir ciertas bibliotecas u otros programas para realizar tareas que serían redundantes si se volviera a implementar en esa pieza de software. Los paquetes permiten la expresión de estas dependencias.

Diferencias: formatos y estrategias de paquetes

Existen varios gestores de paquetes diferentes. Cada uno fue creado porque los existentes no satisfacían las necesidades de algunas personas. Cada administrador de paquetes requiere paquetes en su propio formato.

Además, diferentes distribuciones tienen diferentes requisitos del software que se incluye. Hay una serie de piezas de software que pueden tener capacidades diferentes dependiendo de las opciones que se dan cuando se compila desde el código fuente en un ejecutable de la máquina. Algunas distribuciones desean proporcionar conjuntos de funciones completas y una experiencia rica, mientras que otras quieren proporcionar una experiencia lo más simple y simple posible, y hay todo lo que hay en el medio. Además, la distribución puede decidir formatear su estructura de directorio de manera diferente o usar un sistema init diferente. Pueden decidir agrupar el software de manera diferente: puede haber un paquete llamado "dev-utils" en dos distribuciones diferentes, pero una versión de eso incluyeyaccmientras que el otro no. Debido a estas diferentes necesidades, las distribuciones eligen compilar el software de diferentes maneras.

Es por eso que incluso si tiene un paquete en el formato correcto para su administrador de paquetes, puede no funcionar si el paquete estaba destinado a una distribución diferente. Por ejemplo, ese paquete podría depender de yaccsu instalación, y expresó esa dependencia al requerir el paquete "dev-utils", pero sus "dev-utils" no incluyen yacc. Ahora hay un paquete instalado con una dependencia insatisfecha.

No es realmente un problema.

Una gran parte de ser una distribución de Linux es mantener un repositorio central de software. La distribución se encarga de mantener todo esto para usted. En realidad, esto hace que sea muy fácil instalar software. Por lo general, usa el administrador de paquetes para buscar y seleccionar algunos paquetes, luego le dice que los instale; se encarga del resto por ti. El proceso de instalación del software de Windows incluye la búsqueda de software en sitios web de terceros, tratando de localizar el enlace de descarga apropiado, descarga, verificación de virus y ejecutar un programa de instalación que luego le hace un montón de preguntas irrelevantes. Todo ese desastre no es el estándar en Linux.

El repositorio no puede incluir todo

Ahora, puede haber casos en los que una pieza de software que necesita no está en el repositorio de su distribución. Los paquetes suministrados por un repositorio de software son una de las características diferenciadoras de las distribuciones. Cuando no puede encontrar el software que necesita en los repositorios de su distribución, hay tres vías posibles (realmente, dos más una forma de realmente arruinar las cosas).

Repositorios comunitarios

Muchas distribuciones tienen repositorios no oficiales que son mantenidos por personas no asociadas con la distribución. Ubuntu los llama PPA, Fedora los llama Repositorios de Personas Fedora. Arch Linux no tiene un nombre específico para repositorios de terceros , pero tiene su AUR, que es una colección de "recetas" para paquetes (nota: solo hay un AUR). Primero puede intentar instalar un paquete de una de estas fuentes, ya que es fácil desinstalarlos si no funcionan.

Compilar desde la fuente

Si no puede encontrar un repositorio no oficial con lo que necesita, compilar desde la fuente no es difícil. Necesita tener instalado el paquete de desarrollo de su distribución; Esto incluye cosas básicas como un compilador, un enlazador, un analizador y otras herramientas que generalmente se necesitan para compilar software. Luego encontrará el código fuente del proyecto (que casi siempre se empaqueta en un .tgzo .tbz(llamado "tarball"). Descárguelo en su propio directorio en algún lugar, extráigalo (usando tar -xf filename.tgz, y generalmente vaya al único directorio que creó). ese directorio puede ser un archivo llamado READMEo INSTALL. Si existe, continúe y léalo; la mayoría de ellos le dicen que haga lo mismo. Los siguientes pasos se realizan en una línea de comando. Ejecute lsy busque un archivo ejecutable llamadoconfigure. Si existe, ejecútelo haciendo ./configure; Puede tomar un par de minutos a veces. Por lo general, ejecuta algunas pruebas para determinar cómo su distribución tiene configuradas las cosas, y se asegura de que tenga las herramientas necesarias para compilar este software. El siguiente paso es correr make. En realidad, esto compila el software, y es probable que tome algo de tiempo, desde unos minutos hasta horas, dependiendo del tamaño del software que está compilando. Una vez hecho eso, corres make install. Esto instala el software, que implica copiar los productos de la compilación en los lugares apropiados de su sistema de archivos. Después de eso, el software está disponible para su uso.

Esta fue una sección larga, pero se resume como "README, ./configure, make, make install" . Esa es la rutina para recordar.

Instale un paquete desde otra distribución (no haga esto)

Enumero esto solo porque es una alternativa, pero es casi seguro que no terminará bien. Es posible instalar paquetes para otras distribuciones, y es posible que desee hacerlo. Pues no lo hagas. No lo haga hasta que comprenda muy bien su sistema. De hecho, no voy a poner ningún comando aquí que muestre cómo hacerlo, aunque sea posible. Si llega a ese punto donde parece que esta es la única opción, no instale el paquete usando el administrador de paquetes; en su lugar, extraiga las cosas del paquete y colóquelas en su sistema manualmente, junto con notas sobre lo que ha hecho para que pueda deshacerlo si es necesario.

El bit de línea de comando

Algunas personas prefieren la línea de comando por las ventajas que les brinda. Estos se pueden resumir en tres cosas:

• Facilidad de automatización.
• Velocidad (en comparación con hacer clic en todo el lugar en una interfaz gráfica de usuario)
• Expresividad

El más grande de estos es la expresividad; Hay cosas que se pueden hacer en una línea de comandos que no son posibles en una interfaz gráfica.

Finalmente, las instrucciones de la línea de comandos se dan con frecuencia en foros útiles como este porque es mucho más fácil transmitir la información correcta que dar instrucciones de tipo "haga clic aquí-luego-allí-luego-allí".

Perdón por la larga respuesta. Si quieres lo rápido y sucio, solo lee el resumen.

Resumen

• El formato ejecutable es el mismo.
• Existen diferentes gestores de paquetes que no son compatibles, incluso si los programas empaquetados lo son. (Puede ver un paquete como un archivo de instalación como .msiarchivos).
• Básicamente, las diferentes distribuciones / versiones tienen diferentes versiones de las bibliotecas principales, y por razones de coherencia y estabilidad, las aplicaciones deben construirse contra esas versiones. (Versión de Linux de dll hell).
• Las diferentes distribuciones hacen las cosas de maneras ligeramente diferentes, y eso en algunos casos puede ser un problema de compatibilidad.
• La línea de comando puede ser más rápida, y la línea de comando de Unix es mucho mejor que la línea de comando de Windows.

Administradores de paquetes

En primer lugar, los gestores de paquetes. El propósito principal de un administrador de paquetes es mantener una base de datos de paquetes instalados y los archivos que constituyen ese paquete.

Los administradores de paquetes permiten una fácil instalación de paquetes y, en general, también una fácil extracción. También permiten que los paquetes especifiquen varios scripts que pueden necesitar ejecutarse durante la instalación / eliminación para mantener la coherencia del sistema (como registrar el paquete en alguna base de datos relacionada con el subsistema).

Diferentes gestores de paquetes

Hay varios gestores de paquetes diferentes con diferentes fortalezas y debilidades. Ejemplos son rpm y el administrador de paquetes de Debian (archivos .deb), pero hay otros. Estos gestores de paquetes obviamente necesitan diferentes formatos y, por lo tanto, no son compatibles.

Diferentes distribuciones o versiones

Como la mayoría de una distribución de Linux es de código abierto, hay mucha más reutilización de código que en los sistemas Windows. Una aplicación puede usar varias bibliotecas para varias partes de su funcionalidad. Esas bibliotecas mismas a menudo también lo hacen, a veces la misma biblioteca.

Desafortunadamente, las bibliotecas existen en diferentes versiones y algunas de ellas no son compatibles (especialmente compatibilidad binaria para ejecutables precompilados). Varias versiones pueden coexistir muy bien en sistemas Unix (menos dll desde esa perspectiva), pero en la mayoría de los casos el uso de dos versiones diferentes de una biblioteca en un programa en ejecución requiere bloqueos.

Por lo tanto, las distribuciones binarias a menudo actualizan su propia versión para pasar a nuevas versiones de varios paquetes principales (en otros casos necesita grandes actualizaciones).

Diferentes otros archivos

Las distribuciones también difieren en la forma en que se ubican los archivos particulares y en cómo se gestiona la configuración. Dependiendo del paquete que podría tener un impacto en ese paquete.

Línea de comando

Unix es principalmente una estación de trabajo y un sistema operativo de servidor. Esto significa que está diseñado teniendo en cuenta a los administradores de sistemas profesionales. La automatización es una parte importante de la caja de herramientas de administración del sistema y los scripts de shell son la forma de hacerlo. Intente agregar un nombre de archivo de 0 a 1000 en el administrador de archivos gráfico.

Como los administradores a menudo administran muchas máquinas, necesitan hacer lo mismo en varios sistemas. Usando herramientas como ssh, es extremadamente fácil realizar la tarea en varios sistemas de una sola vez, y solo espere a que la computadora haga el trabajo.

La especificación precisa, la automatización y la repetibilidad hacen que la línea de comandos tenga un potencial mucho mejor que las herramientas gráficas para las tareas de administración. Unix también tiene varios shells diferentes disponibles y esta competencia ha creado shells extremadamente poderosos que son casi incomparables con el símbolo del sistema de Windows.

Microsoft realmente lo ha entendido bien, y ofrece powershell como reemplazo de la línea de comandos, además de que la última versión del servidor de Windows se administra principalmente mediante la línea de comandos.

Los formatos ejecutables son todos iguales en todas las distribuciones, pero los ejecutables pueden requerir software subyacente adicional para funcionar correctamente. Si observa las distribuciones basadas en Redhat, el producto de instalación es un rpm, que incluirá todos los requisitos para una determinada pieza de software, y no lo instalará por defecto a menos que se cumplan los requisitos. ( yumes una alternativa arpmy es utilizado por algunas versiones basadas en Redhat). Por definición, una GUI debe tener una huella mucho mayor que una interfaz de símbolo del sistema. La filosofía subyacente de UNIX es simplificar todo para que una tarea determinada funcione de la manera más eficiente posible. Es por eso que hay tantas utilidades que realizarán una sola tarea con la salida de esa tarea pudiendo encadenarse a la entrada de otra tarea para hacer otra cosa.

Las diferentes distribuciones tienen diferentes requisitos previos de instalación. Sin embargo, hay RPM o DEB (u otros paquetes para otros sistemas de administración de paquetes), que funcionan para más de una distribución. La filosofía de Linux hace que los códigos fuente estén fácilmente disponibles. Al compilar su propio software, es casi la misma rutina en todas las distribuciones, y siempre es el mismo .tar.gzarchivo que usa.

Los RPM compilados son más como parte del sistema; una aplicación en sí, como entidad independiente, debe distribuirse y compilarse en cada destino.

Su segunda pregunta es algo completamente diferente ... Bueno, "muchos usuarios de Linux" prefieren las aplicaciones CLI por muchas razones diferentes, la huella de memoria pequeña es solo una de las razones. Cuando se usa SSH, las aplicaciones CLI tienen más sentido, especialmente cuando se trabaja fuera del sitio en servidores. La mayoría de las veces, esos servidores no tienen instalados entornos gráficos. Cuando se ejecutan programas no demonizados, son muy fáciles de abortar. Ctrl- c, y el programa se fue. Además, muchos programas inician sesión en la consola, por lo que es más fácil de depurar. Al programar, estás haciendo la mayor parte de la compilación en la consola. Simplemente tiene más sentido para la depuración rápida de compilación. Es eso o leer archivos de registro, a veces, leer la consola es más rápido.

Arco. O FreeBSD, que se desarrolla como un todo. (RHEL, SLES y similares son $ upported en su conjunto).

Uso del portátil: menta

Hackabilidad utilizable: Arch.

Hackabilidad sádica: Genoo.

Hackability divertido: LFS.

Compatibilidad (servidor): RHEL, Ubuntu LTS, FreeBSD (diferente de Linux).