¿Qué quiso decir Linus Torvalds con su cita sobre portabilidad? [cerrado]

En un debate con Andrew Tanenbaum sobre la arquitectura del sistema operativo microkernel vs. monolítico, Linus Torvalds dijo:

La portabilidad es para personas que no pueden escribir nuevos programas.

Que quiso decir con eso?

Como Linus escribe en el debate, es con la lengua en la mejilla (es decir, no debe tomarse demasiado en serio).

Luego, continúa explicando que si bien la portabilidad es algo bueno, también es una compensación; El código no portable puede ser mucho más simple. Es decir, en lugar de hacer que el código sea perfectamente portátil, simplemente hágalo simple y lo suficientemente portátil ("adhiérase a una API portátil"), y luego, si necesita ser portado, reescríbalo según sea necesario. Hacer que el código sea perfectamente portátil también puede verse como una forma de optimización prematura, a menudo más perjudicial que beneficioso.

Por supuesto, eso no es posible si no puedes escribir nuevos programas y tienes que seguir con el original :)

Creo que significa que cada programa debe escribirse específicamente para el hardware y el sistema operativo en el que se ejecuta.

Creo que lo que está manejando es que el código de propósito general que puede ejecutarse en varias plataformas es menos eficiente o más propenso a errores que el código escrito específicamente para una plataforma. Sin embargo, significa que cuando se desarrolla de esta manera, debe mantener varias líneas de código diferentes.

Cuando se escribió Linux por primera vez, usaba funciones disponibles solo en la CPU i386, que era bastante nueva y costosa en ese momento.

Eso es exactamente lo que hace Linux: solo usa un subconjunto más grande de las 386 características que otros núcleos parecen hacer. Por supuesto, esto hace que el núcleo sea inportable, pero también hace que el diseño sea mucho más simple. Una compensación aceptable, y que hizo posible Linux en primer lugar.

A medida que entramos en el siglo XXI, las características que hicieron único al i386 se volvieron totalmente convencionales, permitiendo que Linux se volviera muy portátil.

Como alguien que ha hecho mucho Java y que ha experimentado el fenómeno de "escribir una vez, depurar en todas partes" semanalmente durante años, puedo relacionarme completamente con esto.

Y Java es probablemente un ejemplo suave. Ni siquiera puedo empezar a imaginar por lo que pasan las personas que intentan mientras usan una base de código portátil en un lenguaje / kit de herramientas que ni siquiera fue diseñado para ser portátil en sí mismo.

En este momento en el trabajo, estamos investigando la idea de escribir una versión lite de uno de nuestros productos para dispositivos móviles. Investigué un poco sobre cómo hacer una versión portátil para J2ME y Android, que trata de compartir la mayor cantidad de código base posible (obviamente no puede ser completamente "portátil" per se, pero es una filosofía similar ) Es una pesadilla.

Entonces, sí, a veces es bueno poder pensar (y hacer) en términos del uso de las herramientas dadas para el trabajo dado. es decir, desarrollar libremente contra una única plataforma / entorno monolítico. Y simplemente escribiendo versiones separadas y limpias para cada uno.

Aunque algunas personas ven / tratan la portabilidad, siguiendo los estándares, etc., como moralmente superior, o algo en ese orden, lo que realmente se reduce a la economía.

Escribir código portátil tiene un costo en términos de esfuerzo para hacer que el código sea portátil y (a menudo) renunciar a algunas características que no están disponibles en todos los destinos.

El código no portátil tiene un costo en términos de esfuerzo para portar el código cuando / si le importa una nueva arquitectura, y (a menudo) renuncia a algunas características que no están (o no estaban) disponibles en el destino original.

El gran calificador allí es "cuando / si te importa una nueva arquitectura". Escribir código portátil requiere un esfuerzo inicial con la esperanza de una eventual recompensa de poder usar ese código en arquitecturas nuevas / diferentes con poco o ningún esfuerzo. El código no portátil le permite retrasar esa inversión en portado hasta que esté (al menos razonablemente) seguro de que realmente necesita portar a un objetivo particular.

Si está seguro por adelantado de que va a transferir a muchos objetivos, generalmente vale la pena invertir por adelantado para minimizar los costos de transferencia a largo plazo. Si no está seguro de cuánto (o incluso si) necesitará portar el código, escribir código no portátil permite minimizar el costo inicial, retrasar o incluso evitar por completo el costo de hacer que el código sea portátil.

Creo que también vale la pena señalar que he hablado de "portátil" y "no portátil" como si hubiera una división clara entre los dos. En realidad, eso no es cierto: la portabilidad es un continuo, que va desde completamente no portátil (por ejemplo, código de ensamblaje) hasta extremadamente portátil (por ejemplo, Info-zip), y en cualquier lugar intermedio.

Tanenbaum señala que gran parte de Linux está escrito de manera no modular para aprovechar la CPU 386, lo más avanzado en ese momento, en lugar de hacer que la interacción de la CPU sea un componente y, por lo tanto, sea fácilmente intercambiable. Tanenbaum esencialmente cree que el hecho de que el Kernel sea tan monolítico y vinculado a la CPU 386 hace que sea muy difícil,

• Port Linux en sí mismo a otra plataforma de CPU (obviamente incorrecta, AMD64, PowerPC, etc.)
• Programas de puerto escritos para Linux x86 a otra arquitectura de CPU (también incorrecta)

El campamento de Linux hace varios puntos, entre los cuales:

• Linux ofrece un sistema de archivos multiproceso como parte del diseño
• El microkernel, aunque interesante e intuitivo, no es muy eficiente.
• La adherencia a la API portátil hace que el problema de portabilidad sea más o menos molesto que un bloqueador.

Si desea escribir código portátil, debe escribir código portátil.

¿Qué quiero decir con eso?

El diseño debe reflejar el propósito. Si el lenguaje es C, por ejemplo, diséñalo de manera que el número mínimo de líneas de código necesite cambiar para que funcione. Esto a menudo significaría separar la pantalla del cálculo, lo cual es una buena filosofía de diseño de todos modos (MVC). La mayoría del código C se puede compilar en cualquier lugar, siempre que tenga acceso a un buen compilador. Aproveche eso y escriba lo más que pueda para ser genérico.

Por cierto, esta respuesta solo se aplicará a las aplicaciones. OS y embebidos son otro animal completamente.

Interprete esta afirmación "literalmente" tal como es.

En otra de las citas de Linus, dijo: "C ++ está tratando de resolver todos los problemas incorrectos. Las cosas que C ++ resuelve son cosas triviales, extensiones casi puramente sintácticas de C en lugar de solucionar algún problema profundo".

También en su biografía, "Just For Fun" linus, mientras citaba sobre microkernels, dijo que para un problema con complejidad 'n' si divide el problema en partes únicas '1 / n' ... entonces la complejidad total de desarrollar dicho sistema be 'n!' esto en sí mismo es un factor suficiente para no intentar tal cosa, y extraer la eficiencia de un sistema tan complejo sería muy difícil.

Hay que tener en cuenta el hecho de que durante esos debates, Linux era muy nuevo y era en gran medida un sistema operativo solo 386. Creo que si le preguntaras a Linus hoy, él tendría una opinión diferente. Tal vez no sea tan extremo como Tannenbaums, pero probablemente le dará un asentimiento a Hime y dirá que tenía razón en algunas cosas.

Linus y los otros desarrolladores del kernel pasaron por muchas dificultades para hacer que Linux fuera portátil, pero, de nuevo, es posible que Linux nunca hubiera existido si Linus hubiera tenido que hacerlo portátil para empezar.

Significa que las personas que pueden escribir buenos programas no necesitan que las cosas sean portátiles, porque pueden trabajar desde cero.

Los programadores menos talentosos quieren "importar" otros programas (portabilidad) al actual.