@Rataunderground Yo con esto me quiero cortar la polla el 90% de las veces. Leí que querían reprogramar el kernel al completo de Linux en Rust y unificarlo todo, pero que había voces [pollaviejas] en contra.
Esto lo explica muy bien el clásico: https://xkcd.com/927/
Cada vez que alguien inventa un estándar para unificarlo todo, típicamente lo único que consigue es agregar un nuevo estándar a la lista de estándares contradictorios ya existente.
La única forma de evitar esto sería adoptar uno ya existente, pero buena suerte convenciendo a los partidarios de los otros estándares.
En cualquier caso, cada vez que se cambian estándares, un montón de aplicaciones mueren, porque quien las mantiene no está por la labor de dedicarle la burrada de horas que necesitaría para ello.
No hay más que ver lo que pasa con Android, que como están cambiando cada dos por tres cómo va el tema de permisos, APIs y demás, a estas alturas tienen más software libre incompatible con las nuevas versiones que compatible. Y eso que es un SO relativamente joven.
En Linux, que es un ecosistema mucho menor, podría ser realmente catastrófico. No hay más que ver lo que fue el cambio a systemd y lo que está siendo el cambio a Wayland, y multiplicarlo por 100.
Ningún linuxero va a querer que se pare el desarrollo del kernel por tiempo indefinido hasta que se migre todo. Eso llevaría más de una década, puede que varias. Mataría a Linux.
Además, se dejaría por el camino la mayoría de drivers de hardware antiguo que hay. Que es lo que los linuxeros vienen echando en cara a Windows desde hace 2 décadas. Y no deja de ser un experimento, porque no existe un SO así hecho en Rust, con lo que no se sabe qué pegas puede haber.
La única forma racional de hacerlo es lo que están haciendo ahora: ir haciendo cosas nuevas en Rust, ir viendo cómo va, e ir cambiando lo demás según se pueda.
@jgg @Rataunderground ¿Y empezar todo de cero al tiempo que se continúa con el desarrollo del Linux normal?
@jgg @Rataunderground Sería más recursos a invertir, pero a la larga sería la solución correcta.
Lo de ir en paralelo significa que cada funcionalidad nueva implica doble esfuerzo, porque la tienes que hacer en lo nuevo y en lo viejo. Además, tienes que decidir cómo repartes esfuerzos; por ejemplo, si es mitad y mitad, el desarrollo de lo antiguo va a ir a la mitad de velocidad. Y eso es mucha ventaja para la competencia.
Llevo ya unos cuantos proyectos de "empezar todo de cero" y te puedo asegurar que es un tipo de proyecto que a los desarrolladores adoramos, porque es ilusionante, te crees que vas a arreglar todas las mierdas (sin darte cuenta de que estás metiendo otras nuevas, ojo).
Pero el coste es brutal, tanto en recursos como en impacto en el usuario.
Cuando alguien pone patas arriba el interfaz de una aplicación, saca una versión en la que se caen funcionalidades, se pide de golpe un hardware mucho más potente, surgen de golpe un montón de fallos en una aplicación, o una aplicación va languideciendo durante años mientras su desarrollador promete que pronto sacará una nueva versión que será la octava maravilla, suele ser porque alguien ha querido ir demasiado deprisa.
La forma buena de hacer esto, aunque sea más aburrida y pesada, es ir renovando el proyecto antiguo, y transformándolo poco a poco en el nuevo. Acabas en el mismo sitio, pero los usuarios no ven rupturas traumáticas, ni parones, ni funcionalidades rotas o aún no implementadas.
Y, ojo, a veces no queda otra que empezar de cero. Pero es algo que debe evitarse.
Tampoco te preocupes: en el fondo, Torvalds y compañía están haciendo exactamente la renovación por la que abogas (aunque no lo digan). Pero despacito y buena letra, que no es cuestión de arruinarlo todo por las prisas.
