Advertencia de Longrid: Has sido advertido, muchas cartas.

Durante mucho tiempo ha estado desarrollando un formato de distribución para aplicaciones que estaban "libres" de dependencias de todo el sistema. Ubuntu es muy, muy activo en la promoción de su complemento, gnome - flatpack. Ambos prometen paraíso y libertad de rpm / deb. Pensemos en el problema que quieren resolver y el precio que solicitan para solucionarlo.

Bibliotecas

Nadie en el mundo moderno puede escribir una aplicación sin usar el código de otra persona. Hay varias razones:

• Muchas bibliotecas son tan serias que escribir su funcionalidad desde cero es una tarea desalentadora. Ejemplos: soporte para unicode, renderizado de fuentes, matemática.
• Otras bibliotecas ofrecen un conjunto de funciones bastante modesto, pero están tan bien escritas que escribir al menos tan bien es casi imposible. Bibliotecas estándar de lenguajes de programación, diversas implementaciones de libc, etc.
• El costo de trabajar con el código de otra persona (al que se dedica esta sección) a menudo es más bajo que el costo de mantener su código. Es probable que la densidad de "errores por línea de código" sea comparable, y usted debe detectar sus propios errores. Es probable que las bibliotecas extranjeras (populares) sean depuradas y corregidas por las manos equivocadas.

La clave es que incluso si podemos escribir la funcionalidad de una sola biblioteca desde el principio, el número total de funciones necesarias (y dependencias) da un aumento casi exponencial en el número de tareas que deben resolverse, posponiendo el tiempo de inicio del trabajo en el código del programa en sí. en la distancia inalcanzable.

Un ejemplo para darse cuenta de la escala del drama: digamos que su aplicación toma dos líneas de entrada como argumentos opcionales y las muestra juntas después de la normalización. Si está escribiendo una aplicación industrial (una aplicación que se parece a una "real"), entonces:

• Necesita un analizador de línea de comando
• Que debe aceptar unicode
• Y quizás le dé al usuario una pista de que ha sellado el nombre del argumento
• Lo que requiere comparación fonética
• Y tal vez expresiones regulares
• En general, tendrá que admitir no solo Unicode sino también otros entornos locales, lo que requiere una biblioteca de soporte de entorno local y TODO lo que la gente crea en el contexto de entornos locales.
• La concatenación de cadenas con la normalización es otro uso de una biblioteca Unicode separada; usted mismo no implementa esto.
• Es probable que la visualización en la pantalla (ayuda de la línea de comandos, su resultado) requiera soporte para ncurses, una biblioteca que admite diferentes terminales (puede hacerlo con el modo de texto, pero las aplicaciones a menudo usan capacidades de color).
• Las pruebas implican el uso de un marco de prueba, posiblemente una biblioteca para moks.

Está claro que tal complejidad para la tarea de "dos líneas" es una ingeniería excesiva, pero tan pronto como comienzas a hacer algo más, la idea de "todo por ti mismo" comienza a ir más allá de los límites de lo observable y lo realizado.

¿Cuántas bibliotecas cree que son necesarias para garantizar que curl http (s): // ... funcione? Mucho Utilizará uno, pero las dependencias de sus dependencias son sus dependencias.

Copiar y vender VS enlace dinámico

Si bien el uso de bibliotecas es inevitable, el uso en sí mismo puede variar en la implementación. Tenga en cuenta que tenemos dos palabras importantes: "uso" e "implementación de uso". ¿Qué significa el uso? En su forma más grosera: la capacidad de llamar al código de la biblioteca cuando sea necesario. Y aquí están las implementaciones de esto:

• Podemos copiar el código que realiza las operaciones que necesitamos. En forma de código (copiar y pegar), como un módulo separado en un lenguaje de programación (archivo de objeto para lenguajes compilados), o como un módulo separado (para lenguajes interpretados). En algún lugar justo al lado está "copie el archivo fuente de la biblioteca a su directorio con la aplicación". ¿Qué problemas crea esto? El principal problema principal es que perdemos (para siempre) la conexión con el original. Incluso si el autor de la biblioteca original corrige el error, no lo sabremos. Además, si solo copiamos el código, la siguiente persona que trabaje en el programa ni siquiera podrá descubrir que este código es "ajeno". De hecho, cortamos el camino en la pregunta "escribir desde cero" y tomamos el de otra persona. Sin embargo, cortamos solo una parte, porque si hay errores en este código (pero no estarán allí , están allí ), entonces su corrección requerirá que el corrector vaya y comprenda la esencia del problema hasta el fondo. Incluso si la prueba requiere leer varios cientos de miles de líneas de código fuente y cientos de RFC (así como comentarios de que las implementaciones son diferentes a las RFC), no tenemos otra manera. El error clave en este lugar es que hemos perdido información de que este código es extraño. Tener comentarios en un archivo puede ayudar, pero requiere la participación activa y profunda de una persona, porque si escribimos en un comentario "tomado de libfoobar, src / lib / foo.c versión 364a51577f3782dbf8e5d2482ab941980357c492", entonces alguien tendrá que ver dónde se encuentra libfoobar, qué versión es y qué ha cambiado desde la versión anterior ". Para simplificar este proceso, necesitamos metainformación legible por máquina.
• Si acompañamos el "código de otra persona" con metainformación y usamos programas para administrar este código (en lugar de copiar y pegar), esto se llama venta , es decir inclusión controlada del código de otra persona en su código. Técnicamente, la venta puede ocurrir en la etapa del texto fuente, vinculando objetos a un archivo ejecutable, importando módulos (en intérpretes) desde la aplicación, o incluso vinculando dinámicamente con "su" versión de la biblioteca (más sobre esto más adelante).
• Finalmente, podemos realizar enlaces dinámicos en la etapa de inicio de la aplicación. Para los idiomas compilados, estos son so'hks comunes; para los idiomas interpretados, hay un módulo en la importación de todo el sistema. Si varias aplicaciones pueden importarlo, entonces esta es una biblioteca compartida. Si la aplicación "trajo su módulo", entonces la biblioteca es "propia", incluso si su interfaz implica una "biblioteca compartida". Por ejemplo, si una aplicación utiliza su "propia" versión de la misma, independientemente de si difiere de la general o no, entonces esto es vending. Y si el sistema se importa, entonces esta es una biblioteca compartida.

¿Cuál es la diferencia entre estos métodos? Daré breves argumentos; se han discutido muchas veces en muchos artículos. Cada uno de estos argumentos sigue siendo válido a pesar de la presencia de contraargumentos vecinos:

• Ahorro de memoria (RAM y disco) para so'sh, reduciendo el tamaño del sistema instalado. Cuantas más aplicaciones usen lo mismo, mayor será el ahorro de memoria. En consecuencia, por el contrario, cuanto más "sus" bibliotecas trae una aplicación, más "gorda" es.
• El debate sobre quién monitorea las vulnerabilidades es el sistema (que proporciona actualizaciones de la biblioteca) o el autor de la aplicación (que la actualiza a tiempo).
• Resolución de conflictos de dependencias (la venta resuelve este problema ya que las bibliotecas compartidas requieren atención y precisión de todos los participantes en el proceso, a veces creando dificultades insuperables), el mismo infierno legendario.
• Nuevas versiones de las bibliotecas: aparecen a pedido de los autores de la aplicación o por decisión de los autores de la distribución. En un caso, el autor puede aportar la nueva característica que necesita, en otro caso, la distribución puede aportar una mejora a la aplicación existente al admitir algo nuevo en la biblioteca (por ejemplo, las pantallas hidpi comenzaron a funcionar correctamente en todas las aplicaciones vinculadas dinámicamente a bibliotecas qt / gtk) .

Todos estos problemas se han tratado muchas veces antes. En cambio, quiero centrarme en los aspectos sociales de la cuenca hidrográfica "todo mío" y "todo común".

Contrato social y mantenedores de poder

Las bibliotecas compartidas son cooperación, poder y responsabilidad. Las personas que determinan qué bibliotecas compartidas están disponibles en el sistema operativo dictan a los fabricantes de software qué bibliotecas compartidas pueden usar. Una gran cantidad de software puede usar diferentes bibliotecas, y la indicación de qué versión exacta usar se deja a discreción del vinculador (para los idiomas compilados) o el controlador de archivos de dependencia (pip, bundler, etc.). Si todas las aplicaciones en la distribución se crean con los mismos requisitos, entonces aparece la gracia: si hay un error en alguna biblioteca, el responsable de esta biblioteca actualiza la versión y la corrección se aplica automáticamente a todas las aplicaciones. Incluso si la aplicación se lanza cada dos años, la corrección en el openssl condicional se aplicará dentro de una semana. Si en un sistema operativo particular se toma la decisión de abandonar el protocolo anterior, algunas modificaciones (por ejemplo, la interfaz de usuario), estos cambios también se aplicarán a todos. Look & feel en un estilo general que (quizás) puede ser cambiado por el usuario de una vez por todas. ¿No es esto gracia?

El poder y la lucha por él.

... Esta gracia requiere que todas las aplicaciones puedan funcionar con la versión seleccionada de la biblioteca. Pero, ¿qué pasa si alguna aplicación quiere una función muy, muy nueva de la biblioteca, y todas las demás aplicaciones no quieren usarla, porque esto, por ejemplo, no es una versión LTS de la biblioteca, es decir? ¿No es lo suficientemente estable? Pero el kit de distribución puede negarse a cambiar a nuevas versiones "por principio", porque les prometimos a los usuarios solo correcciones de errores, y nuevas versiones solo en la próxima versión del sistema operativo, que (como) se lanzará en medio año. Y esto provoca resistencia por parte de los autores de la aplicación. ¿Quién eres para decirme con qué versiones debo trabajar? Soy autor, lo veo así. Necesito libfoobar 3.14-pre2 o anterior, no tu antiguo libfoobar aburrido 3.10.

... En este punto, el autor simplemente escribe en los requisitos de la aplicación libfoobar>=3.14-pre2 . El mantenedor toma y aplica parches a la solicitud, además de eliminar el código que dependía de esta biblioteca. Tal vez O simplemente se niega a aceptar una nueva versión con dicha dependencia hasta que esta dependencia (libfoobar 3.16) esté en la nueva versión de la distribución.

Si el autor realmente necesita que los usuarios usen la nueva versión (por ejemplo, porque el autor no quiere admitir la versión anterior), entonces busca soluciones alternativas para enviar la aplicación al usuario.

Lo mismo sucede cuando hay varias distribuciones, algunas más nuevas, otras más antiguas. Mantener distribuciones antiguas, probar con diferentes bibliotecas es difícil. Entonces, la opción "enviar con sus bibliotecas" aparece casi de inmediato.

Tragedia comunitaria

Esto crea los requisitos previos para el surgimiento de una tragedia comunitaria:

• Cada fabricante (autor del software) quiere enviar lo que necesita. Adaptarse a las reglas (versiones) de otras personas es una pérdida de tiempo y esfuerzo, sobre todo porque hay muchas distribuciones diferentes en el mundo
• Los usuarios quieren nuevas versiones.

Al mismo tiempo, cuantas más aplicaciones vengan con sus bibliotecas, menor será el uso de las bibliotecas del sistema. ¿Te acuerdas de Grace? Cuanto menos es "universal", menos es gracia. Si 5 bibliotecas diferentes usan una biblioteca compartida de otras 995, entonces el beneficio de esta biblioteca es 0.5%. Es una pena, sí. Además, perjudica a todos los usuarios, incluso a aquellos que, en principio, no tienen una gran necesidad de una nueva función, pero si la aplicación solo está disponible en forma expendedora, el usuario no tiene opciones.

Resulta que tenemos un extremo global: todas las aplicaciones usan solo bibliotecas compartidas (máxima gracia común, inconvenientes para los autores de aplicaciones individuales) o "cada una por sí misma" (una distribución gruesa con un montón de aplicaciones que pueden tener vulnerabilidades no detectadas pero ampliamente utilizadas, comiendo un montón de memoria, pero el autor de cada aplicación es conveniente).

Aquí es donde llegamos a la disputa rpm / deb VS snap / flatpack

¿Libertad o esclavitud?

Ubuntu aboga muy, muy fuertemente por Snap'y. GNOME confía en que el futuro está en los paquetes planos. Cada uno de ellos es un marco para aplicaciones profundamente individualistas. Todo tipo de electrones, que llevan consigo no solo el capó del compartimento del motor, sino también el sistema operativo del compartimento del motor. Propia libc, propia libssl, propia regexp, propia ncurses, etc. Solo el núcleo actúa como común, es decir de hecho, esta es la misma aplicación en contenedor, pero para el escritorio. Dé a cada uno su propio núcleo y obtendrá un dispositivo en forma de máquina virtual. Agregue los metadatos y obtendrá un contenedor Docker.

El individualismo de las aplicaciones (autores de la aplicación) es comprensible, pero ¿quién representa el bien común? Una mejora local importante se compensa con una ligera degradación general de la distribución multiplicada por aplicaciones puramente. Si todos hacen mejoras locales por sí mismos, la cantidad de discapacidad se vuelve mayor que el beneficio de la cantidad de mejora.

Parecería que en este lugar los creadores de distribuciones deberían actuar como custodios de interés común. Sin embargo ...

Política

Ubuntu depende de Debian mucho más de lo que Canonical (la compañía Ubuntu) quisiera. El valor de Ubuntu no está en los esfuerzos de los mantenedores de Ubuntu, sino en un enorme repositorio de software proveniente de Debian en una forma en que todas las aplicaciones funcionan bien juntas a través de los esfuerzos de miles de mantenedores de los paquetes individuales que poseen la distribución de Debian. Además, Canonical agrega sus esfuerzos para pulir el resultado, y por eso algunos lo aman. Agregue un poco de marketing y un ciclo de vida fijo, que es del agrado de la empresa, y obtenemos un excelente producto.

... Lo que depende de la voluntad de miles de voluntarios en algún lugar.

Lo que no se adapta a casi ninguna empresa comercial. ¿Cómo romper esta adicción? Eso es correcto al hacer su propio paquete de aplicaciones. Cuantas más aplicaciones haya, menos ventajas tendrá en la empresa. Baste recordar la historia cuando un voto en Debian en systemd enterró al advenedizo, desarrollado por Canonical.

Pero mantenga varias decenas de miles de aplicaciones, algunas de las cuales son su propio espacio (erlang, go, perl, python, R, julia, etc.), y algunas son monstruos en el área temática correspondiente (navegadores, emacs, tex, marcapasos, etc.). trabajo pesado No es de extrañar que estos sean miles de mantenedores.

... Y hay una idea. Y, dejemos, los autores de la aplicación mantienen las aplicaciones. Démosles a todos una caja de arena, déjenlos cavar. Los autores obtienen libertad, Canonical: aplicaciones que no dependen de Debian y que al menos alguien mantiene de forma gratuita. Los usuarios obtienen ...

... aplicaciones que son gordas, pesadas, con actualizaciones irregulares y que pueden mantener fácilmente las vulnerabilidades sin corregir durante años ... Pero algunas de ellas son nuevas y brillantes.

Entonces, ¿qué sigue?

Imagina un mundo en el que todos llevan todo consigo ... ¿Sabes cómo se ve? Echa un vistazo a chefsdk. Se envía consigo mismo dentro de su postgresql (con sus dependencias), su rabbitmq (que depende de su erlang), además el chef-servidor también está en erlang, por lo que también tiene su propio erlang. De repente, tenemos dos erlangs y docenas de copias de las mismas bibliotecas dentro de la misma aplicación, ligeramente diferentes en la versión. Esta no es la opción final, ya que adentro, todavía hay bibliotecas comunes entre los componentes. Si los cortamos más, obtenemos varias docenas de copias de openssl y libc para una aplicación. Ni siquiera en su forma final, parece 600MB por aplicación.

... Que, por supuesto, es mucho más grande que la aplicación electrónica promedio ... Y 12 veces más que todo el servidor mariadb (¡todo el DBMS!), O krita o gimp (grandes aplicaciones de gráficos).

¿Y si todos serán así? Tengo 2000 paquetes instalados en mi computadora (sin contar -dev y lib) ... 2000 * 300 = 600GB (Para el tamaño promedio del resultado, tomé la mitad de chefsdk, porque no todos son tan terribles por dependencias). Ahora ocupan alrededor de 7 GB (incluidos recursos, como documentación, editores de texturas, plantillas CAD, etc.).

Si esto se convierte en 600 GB, ¿no es eso una pura tragedia de las comunidades? En cada momento, observamos la optimización local (y la solución de los inconvenientes de otra persona), pero en conjunto, la suma de estas optimizaciones locales reduce la optimización general del sistema. En mi opinión, más que la ganancia local de cada uno de los participantes.

Entiendo por qué Canonical empuja a presión. Entiendo esto y no lo apruebo.