¿Por qué los programas no se distribuyen en formato compilado?

Pero dan instrucciones como

cd downloaded_program
./configure
make install

Esto crea el ELF que se necesita, y probablemente algunos archivos .so.

¿Por qué no ponerlos dentro de un archivo zip para descargar, como con las aplicaciones de Windows? ¿Hay alguna razón por la que deben ser compilados por el usuario?

Analicemos los factores ...

Análisis :

DEPENDENCIAS SEGÚN LA PLATAFORMA : Existen algunos problemas que surgen en un entorno en el que los desarrolladores crean y mantienen varias variantes específicas de la arquitectura de una aplicación:

• Se requieren diferentes códigos fuente para diferentes variantes: diferentes sistemas operativos basados ​​en UNIX pueden usar diferentes funciones para implementar la misma tarea (por ejemplo, strchr (3) frente a index (3)). Del mismo modo, puede ser necesario incluir diferentes archivos de encabezado para diferentes variantes (por ejemplo, string.h vs. strings.h).

• Se requieren diferentes procedimientos de compilación para diferentes variantes: los procedimientos de compilación para diferentes plataformas varían. Las diferencias pueden incluir detalles como ubicaciones del compilador, opciones del compilador y bibliotecas.

• Las compilaciones para diferentes variantes deben mantenerse separadas: dado que hay un solo árbol de origen, se debe tener cuidado para garantizar que los módulos de objetos y los ejecutables para una arquitectura no se confundan con los de otras arquitecturas. Por ejemplo, el editor de enlaces no debe intentar crear un ejecutable IRIX – 5 utilizando un módulo de objeto creado para SunOS – 4.

• Cada sistema operativo tiene su propio esquema de administración de enlaces y debe preparar el archivo ELF (formato ejecutable y de enlace) según lo necesite.

• El compilador generará una compilación que es una secuencia de instrucciones , y arquitecturas distintas significan diferentes conjuntos de instrucciones ( Comparación de arquitecturas de conjuntos de instrucciones ). Por lo tanto, la salida del compilador es distinta para cada arquitectura (Ej: x86, x86-64, ARM, ARM64, IBM Power ISA, PowerPC, Motorola's 6800, MOS T 6502 y muchos otros )

SEGURIDAD :

• Si descarga un binario, no puede estar seguro de si hace lo que dice, pero puede intentar auditar el código fuente y usar un binario autocompilado en su sistema. A pesar de esto, el usuario Techmag hizo un buen comentario en su comentario, auditar el código requiere codificadores conocedores y competentes para evaluar el código y no es una garantía de seguridad.

MERCADO : En esta sección hay muchos factores, pero intentaré reanudarlo:

• No todas las empresas apuntan a llegar a todas las plataformas, depende del mercado y la popularidad de las plataformas y de lo que quieren vender.

• El software libre tiene el espíritu de hacer que el software esté lo más ampliamente disponible posible, pero no implica que el software esté diseñado para cada plataforma, sino que depende de la comunidad que lo respalde.

conclusión :

No todos los programas están diseñados para todas las plataformas. Proporcionar binarios para todas las arquitecturas y plataformas implica compilarlo, probarlo y mantenerlo para todas las plataformas. Eso es más trabajo que a veces es demasiado costoso y se puede evitar si el usuario lo compila en su propia plataforma. Además, el usuario sabrá lo que está ejecutando.

Existe una variedad de plataformas y entornos de software tanto * nix como otros , por lo que el software puede ejecutarse y permitirle crear una aplicación (o biblioteca para usar con aplicaciones) es la única forma realista de soportar muchas combinaciones de esos componentes como lo hace un "buen" elemento de software. Por supuesto, las licencias como la GPL requieren que el código fuente esté disponible , por lo que incluso si el software no funciona correctamente, generalmente es posible (aunque puede ser difícil comprender qué está mal y cómo solucionarlo) para el usuario o algún tercero para sumergirse y corregirlo incluso si el creador no quiere / no puede / ya no existe para hacerlo.

La distribución de software como código fuente también permite una verificación independiente de que el software hace lo que dice y no hace algo desagradable en lugar de o también, lo que a pesar de reducir el nivel de confianza que uno tiene que tener en el creador, ¡en realidad lo mejora!

Primero, su pregunta se basa en una premisa errónea. ¡Los programas se distribuyen en formato compilado!

La forma normal de instalar software en Ubuntu, como en la mayoría de las otras distribuciones de Linux, y más generalmente en la mayoría de las variantes de Unix, es instalar un paquete. En Ubuntu, abre el centro de software o algún otro administrador de paquetes y explora el software disponible. Cuando selecciona un paquete para la instalación, los binarios (si el paquete contiene un programa) se descargan e instalan en su máquina.

Por defecto, el administrador de paquetes le ofrece paquetes hechos por los encargados de la distribución. También puede encontrar fuentes de paquetes de terceros; Ubuntu ofrece PPA como una forma estandarizada para que terceros ofrezcan paquetes.

Descargar el software del autor en forma compilada es el último recurso. Solo necesita hacer eso si el software no es lo suficientemente popular como para ser empaquetado, o si realmente necesita la última versión que no ha sido empaquetada. La mayoría de la gente nunca necesita hacer esto.

Cuando el software no está empaquetado para una distribución, a menudo se distribuye en forma de fuente en lugar de en forma binaria. Hay dos razones principales por las que esto sucede a menudo en el mundo Linux, pero rara vez en el mundo Windows. Una razón es que la proporción de programas de código abierto en Linux es mucho mayor. Obviamente, si el código fuente de un programa no está disponible, la única forma de distribución es un binario. La otra razón es que el mundo de Linux es mucho más diverso. Se necesitan diferentes binarios para cada conjunto de versiones de biblioteca incompatibles, lo que a menudo significa diferentes binarios para cada versión de cada distribución. Windows "resuelve" esto haciendo que cada autor del paquete distribuya las bibliotecas que usan junto con el programa (consecuencia: su computadora almacena muchas copias de cada biblioteca, una por programa que lo usa; si se corrige un error en una biblioteca, cada programa que lo utiliza tiene que enviar una actualización) y al lanzar una nueva versión del sistema operativo solo cada tres años más o menos. Unix tiene mucha más diversidad y hábitos de corrección de errores mucho más oportunos, y resuelve los problemas de distribución de la biblioteca creando diferentes binarios para diferentes distribuciones.

Linux se ejecuta en más de una plataforma de CPU en particular. Si distribuye archivos ELF (o cualquier otro tipo de ejecutable sin procesar), existe la posibilidad de que algunas versiones de Linux no puedan ejecutar el software. En el espíritu de hacer que el software esté lo más disponible posible, se prefiere usar el código fuente. Por ejemplo, Linux se ejecuta en Sparc, Intel, AMD, ARM y otros tipos de procesadores.

Si el archivo ELF estaba dirigido específicamente a procesadores Intel, por ejemplo, entonces otros tipos de hardware no podrían ejecutar el software. ELF es independiente de la plataforma, pero el código que aloja debe ajustarse al código de máquina de una plataforma. Notará cuántas distribuciones tienen paquetes similares (por ejemplo, paquetes _386 y _586 cuando admite diferentes procesadores): debe instalar el archivo ELF correcto para obtener la operación correcta.

Del mismo modo, si decido crear una versión de Linux personalizada que use diferentes interrupciones, enlazadores, etc., entonces todavía necesito el código fuente para compilar el código. Incluso si el código fuente no tiene instrucciones de compilación específicas de la plataforma, cada plataforma es diferente y no puede ejecutar un ELF desde un sistema diferente.

La razón original para la distribución como fuente ciertamente fue la diversidad de plataformas; la comunidad de Linux ha continuado esa metodología tanto por eso como por razones nuevas, parcialmente políticas.

A diferencia de, por ejemplo, Windows, Linux históricamente nunca se ha molestado en mantener estable ninguna ABI (interfaz binaria de aplicación) durante largos períodos de tiempo, lo que se considera / se considera más la posibilidad de innovar en aspectos como formatos ejecutables, API de biblioteca y soporte para nuevas plataformas de hardware. importante.

Los sistemas operativos comerciales logran compatibilidad de aplicaciones a largo plazo al ser muy disciplinados con respecto a la innovación; Siempre se debe agregar una nueva característica / interfaz de software ADEMÁS a una anterior, lo que requiere que se mantengan dos cosas, y el precio de cambiar cualquier cosa después del lanzamiento debe considerarse muy alto. Alternativamente, puede aceptar el hecho de la obsolescencia de la aplicación planificada junto con cualquier persona que escriba software para su sistema operativo (esto no es insinuar a MS sino a otro proveedor de sistemas operativos).

El logro de una plataforma estable a largo plazo para el software distribuido en forma binaria solamente (fuera de una distribución de Linux dada) incluso sería considerado indeseable por algunos elementos de la comunidad de Linux. Como usuario sin complejos de ambas plataformas, no estoy diciendo que sea bueno o malo; es como es

En muchos casos (al menos en el mundo * nix), el código fuente es la versión más portátil del software. Tener la fuente garantiza que el software compartido funcionará en todas las plataformas que posiblemente lo admitan (lo que en muchos casos simplemente significa que cumple con POSIX). La publicación de archivos binarios solo garantiza la compatibilidad con las plataformas (tanto de software como de hardware) para las que se lanzan esos archivos binarios.

Tenga en cuenta que en Windows, los binarios son la forma más conveniente y portátil para compartir software. Dado que la compilación de la fuente no es parte del modelo habitual de distribución de software de Windows, Microsoft ha hecho grandes esfuerzos a lo largo de los años para garantizar que los binarios funcionen en múltiples versiones de su sistema operativo: http://www.joelonsoftware.com/articles/APIWar.html

La mayoría del software de Linux es software libre. Al distribuir el código fuente con algunas instrucciones de compilación en lugar de binarios, tiene la oportunidad de revisar o incluso editar el código fuente antes de compilarlo. De esta manera, puede estar muy seguro de lo que el programa realmente hace y de que no es dañino.

La razón principal por la que personalmente no me gusta obtener un ejecutable de un programa es porque me gusta comprobar primero qué está haciendo realmente el código fuente (principalmente porque me gusta mirar el código de los demás) pero sé de varios otros quienes también verifican el código fuente en busca de código malicioso.

Muchas respuestas han dicho que, en la mayoría de los casos, el software se distribuye en formato compilado. Estoy de acuerdo con esta suposición. Sin embargo, veo un caso en el que distribuir un software por su fuente es mejor que distribuirlo en formato compilado.

No estoy seguro de que sea cierto, pero imagino que al comienzo de Internet, debido a que el ancho de banda de la red era malo, a veces podría ser más rápido distribuir un software por su fuente que en formato compilado. Como las fuentes de código son solo texto plano, a menudo es más pequeño que el software en formato compilado. Por lo tanto, distribuir un software con código fuente parece ser una mejor manera de compartirlo, siempre que los usuarios puedan compilarlo.

Además del hecho de que hay muchos sistemas Unix que se ejecutan en muchas plataformas diferentes, solo considere los problemas que enfrenta el software de Windows a partir de este modo de distribución, a pesar de que realmente solo tienen que preocuparse por una versión de Windows y una plataforma (la PC )

Incluso con solo la PC de la que preocuparse, todavía hay dos arquitecturas: 32 bits y 64 bits. Si observa, la gran mayoría del software de Windows simplemente ignora los 64 bits y solo envía software de 32 bits, dejándolo con un software subóptimo si tiene un sistema de 64 bits. Luego hay bibliotecas. Un proveedor de software no quiere que obtenga errores extraños al intentar ejecutar su programa si no tiene la biblioteca adecuada ya instalada, por lo que solo incluyen la biblioteca con su programa (haciendo que la descarga sea más grande, incluso si ya tiene esta biblioteca) ) Un segundo programa hace lo mismo, pero con una versión diferente de la biblioteca. En el mejor de los casos, el programa B contiene una versión más nueva de la biblioteca que es compatible con versiones anteriores, por lo que si instala el programa B después deprograma A, las cosas funcionan, pero instalarlas en el orden inverso te deja con la versión anterior de la biblioteca y, por lo tanto, el programa B se rompe. Sin embargo, a menudo, el proveedor de la biblioteca realiza cambios que no son compatibles con versiones anteriores y no se molesta en cambiar el nombre de la biblioteca, por lo que no importa en qué orden instale los dos programas, el primero se interrumpirá. Esto se llama "dll hell".

Lamentablemente, para evitar esto, la mayoría del software de Windows ha recurrido al envío de todas sus bibliotecas en su propio directorio de programas en lugar de un directorio compartido, por lo que cada programa tiene todas sus propias bibliotecas privadas y nunca se compartirán entre sí, lo que anula todo punto de dlls en primer lugar y terminas usando mucho más RAM y espacio en disco y tiempo descargando todas las bibliotecas duplicadas.

Esta es la razón por la cual el software de código abierto se publica en forma de código fuente, y los proveedores de sistemas operativos han creado administradores de paquetes que resuelven los problemas de dependencia y descargan solo los archivos binarios precompilados que realmente necesita, sin duplicar las bibliotecas por todas partes. Esto también se ocupa del hecho de que hay muchos sistemas Unix diferentes que se ejecutan en muchas plataformas diferentes.