¿Qué hubiera pasado si Linux se hubiera escrito en Python, que es mucho más lento en comparación con C?

Answer 1

La velocidad no fue el único problema con la escritura de Linux en Python (o cualquier otra cosa). Disponibilidad e idoneidad son las áreas problemáticas.

Disponibilidad: cuando Linus comenzó a crear Linux, Python no era lo suficientemente estable como para hacer mucho. Linus anunció Linux en agosto de 1991 (Grupos de Google). Y según A Brief Timeline of Python, el primer lanzamiento público de python fue en febrero de 1991. Esta versión ni siquiera era beta. La primera versión beta salió en algún momento en 1992. Así que Python no estaba disponible para Linus cuando comenzó.

Idoneidad 1: Por supuesto, incluso si fuera lo suficientemente estable, Python no habría sido adecuado para el trabajo. Python es un lenguaje de script. Los lenguajes de secuencias de comandos son más adecuados para “soluciones rápidas (¿y sucias?”) O cuando la solución es más importante que el desarrollo. Más importante aún, dado que Python se interpreta, cualquier sistema operativo escrito en él no sería realmente un sistema operativo (el programa de nivel superior en el sistema) sino más bien una aplicación / máquina virtual. Por lo tanto, un ‘SO’ escrito en Python sería similar a Android (ver el apartado 1). Un núcleo real que aloja una VM para interpretar Python

Idoneidad 2: en segundo lugar, las partes más bajas del sistema operativo deben estar escritas en un lenguaje que proporcione acceso al hardware a un nivel más fino del que Python está diseñado / destinado. El ejemplo más obvio es que python no admite punteros. Eso sería un factor decisivo para la codificación del sistema operativo.

La respuesta basada en el escenario hipotético sigue:

Específico a la pregunta, el trabajo del kernel es no estar en el camino del usuario. Cualquier recurso que utilice el núcleo (CPU, memoria) es idealmente un desperdicio de recursos. Por eso tiene que ser rápido y compacto.

Entonces, si el núcleo era lento (porque estaba escrito en python), no habría sido un gran problema hasta que Linux fuera lo suficientemente grande / bueno como para ser ejecutado en sistemas de producción y no solo por aficionados. Entonces Linus (y otros que contribuyeron al núcleo) habrían hecho una gran cantidad de optimización. Primero habrían optimizado el código del núcleo mismo. Pero la optimización tiene sus límites. Entonces habrían tomado la optimización de Python (lenguaje y el intérprete). Pero, de nuevo, la optimización tiene sus límites. Así que puedo imaginar dos escenarios ortogonales aquí.

Caso 1: Linux se volvería a escribir en otro idioma.

La gente pasaría unos meses (¿años?) Reescribiendo el núcleo en el nuevo idioma. El tiempo real empleado dependerá del tamaño del núcleo, por supuesto. Eso habría dejado espacio abierto para que otro núcleo gane cuota de mercado sobre Linux y ahora tendríamos dos o más núcleos no tan buenos en el mercado.

Caso 2: Python se volvería a implementar .

Si el grupo de Linux decidiera seguir con Python, tendrían que renovar todo el lenguaje. (El mejor de los casos) se sentarían con / (el peor de los casos) divididos del grupo Python y volverían a implementar una gran cantidad de python. Incluso podrían diseñar un compilador para python. Entonces habría compilado el código de Python en el núcleo e interpretado el código de Python en el país de usuario. Python probablemente habría sido el lenguaje de scripting de shell predeterminado en este nuevo kernel de Linux y la gente de Python podría pedirnos que lo llamemos Python / Linux (Aparte 2) y no solo Linux: P.

Aparte 1

Android está construido en un kernel de Linux con una VM basada en Java en la parte superior. Por lo tanto, el Kernel se modifica (para optimizar el consumo de energía frente al rendimiento) del kernel de Linux, mientras que el país de usuario es de Android.

Aparte 2

GNU GCC y otras herramientas de GNU juegan un papel muy importante en el desarrollo de Linux. Sin GCC, Linux hubiera sido muy difícil comenzar. Linus parcheó el GCC para minx para hacer un compilador cruzado para Linux. Mejoraron estos parches hasta que las personas de GNU comenzaron a hacer GCC oficial para Linux. Es por eso que algunas personas insisten en que Linux debería llamarse GNU / Linux.

grupos de Google

Answer 2

Hay algunas implicaciones muy interesantes para ese escenario, comenzando con el hecho de que Python habría evolucionado a un lenguaje muy diferente y de bajo nivel.

El entorno de ejecución de Python es bastante diferente de los C, que pueden ir directamente al metal desnudo. Por ejemplo, un programador BASIC de la vieja escuela podría preguntar cómo hacer un PEEK; en C se trata de asignar un valor específico (la dirección de memoria absoluta) a un puntero y desreferenciarlo. Esto no es algo que desee hacer a menudo (o en absoluto en la mayoría de los entornos; es el tipo de cosas por las que un compilador probablemente debería emitir una advertencia), pero es posible que deba hacerlo de vez en cuando en los niveles más bajos de un kernel del sistema operativo, razón por la cual, tan trastornado como parece ser, C puede hacerlo. Python no puede, porque no hay ninguna razón en la tierra para que alguien que trabaje en los dominios con problemas que Python ha evolucionado para adaptarse alguna vez quiera. Por supuesto, es posible que Python Shoehorning entre un entorno de tan bajo nivel, pero el hecho de que Guido Van Rossum no lo haya hecho me indica que su comunidad no está interesada.

Es posible construir un sistema operativo como intérprete de Python sobre un microkernel, algo así como un viejo sistema de 8 bits cuyo BASIC REPL funciona como el shell de comandos. No habría nada de malo en esto, pero no es remotamente el sistema Posix lo que Linus estaba buscando. (Sin mencionar que todos sabemos lo que Linus piensa de los microkernels). Con la excepción de IBM AS / 400 (ahora i Systems), que es básicamente el mismo concepto en los esteroides con un DBMS incorporado, tales diseños comenzaron a parece un poco pintoresco en 1991. (Es por eso que una gran cantidad de usuarios de Commodore 64 ejecutaban GEOS como su controlador diario en ese momento).

A medida que avanza la velocidad, no sé si hubiera hecho una diferencia a largo plazo. Un compilador de Python de bajo nivel escrito correctamente que compiló en código máquina no habría sido significativamente diferente de GCC speedwise. Python podría haber recogido algunas de las peculiaridades menos entrañables de C si se hubiera expandido a ese dominio, pero lo dudo o Python! Linux habría sido especialmente exitoso de cualquier manera, por lo que probablemente no importaría mucho. Python y Linux han tenido éxito porque abordaron los problemas existentes en los dominios en los que evolucionaron. System! Python y Python! Linux habrían sido poco más que curiosidades técnicas sobre el mismo nivel que Modula-2.

Answer 3

Linux fue escrito alrededor del núcleo de Unix (ver los casos judiciales que siguieron). Unix se codificó originalmente en Assembler, pero las versiones posteriores (sistema operativo portátil) se escribieron principalmente en C, con Asm utilizado para ciertas áreas críticas de velocidad y aquellas que necesitaban estar más cerca del metal.

Por eso se usó C Linux. Si se hubiera utilizado Python, no habría utilizado el núcleo de Unix, por lo que no habría sido lo mismo en absoluto. Es realmente la cercanía a Unix y la disponibilidad gratuita de Linux lo que lo ha convertido en un éxito, hay cientos de sistemas operativos por ahí. Mi opinión es que nunca hubiera logrado la calificación sin Linux y, por lo tanto, C (Assembler también habría funcionado, por supuesto).