Parece que se ha abierto una lucha entre desarrolladores de Linux por la inclusión de Rust en la programación de partes criticas de Linux. ¿Pensáis que es posible que empiecen a salir distribuciones hechas en parte con Rust y otras que no?
Estoy empezando a aprender Rust (Ya me he cansado de C#) y me parece un lenguaje interesante, aunque más difícil.
Más aún? Uff, espero que no!
Yo me fío de lo que diga el señor "marcan"
Si él dice que meter Rust en el Kernel es posible, pues seguro que es posible.
Lo dudo mucho. De todas formas, Redox (redox-os.org) lleva existiendo bastante tiempo y, lamentablemente, a casi nadie le interesa.
Si no es compatible con lo que hay ni tiene el mismo soporte que el actual dudo mucho que exista fragmentación. Y si lo es no veo como puede generar fragmentación si es transparente de cara al usuario.
Windows no sigue siendo la primera opción porque sea el mejor sistema operativo que el resto si no por todo el ecosistema que depende de él.
Lo que importa es el soporte de hardware y software y conseguir eso no es cosa de un par de días. El resto da un poco igual aunque Rust proporcione ventajas sobre C.
Desde hace tiempo que Linux está fragmentado el desarrollo
Hay algunos desarrolladores con mucho ego aunque saben mucho son dificiles de trabajar con esas personas en plan o piensas como ellos o te miran mal o te ponen mil peros para que luego existan mil forks de una app o de alguna feature porque el autor principal sigue con su erre con erre.
¿Al final? Quien pierde es el usuario final porque habrá funciones que tarden ver a la luz o solo existe de manera extraoficial
Luego en otros casos desarrolladores que no les importa la obsolescencia programada gitlab.freedesktop.org/xorg/xserver/-/me…requests/468 Rompiendo drivers gráficos porque cambian las variables randr
No creo. El problema fundamental es que mezclar lenguajes de programación es un cacao, como el agua y el aceite. Empiezas a duplicar cosas y llega un momento que pierdes agilidad y se vuelve todo más frágil a la hora de hacer cambios; el sistema de contribución de Linux es gente que envía parches con mejoras o arreglos a través de correos electrónicos. Hay una serie de encargados, cada uno de su sección y temática, que te responden al correo y después de dar unas cuantas vueltas y con algo de paciencia te dan el visto bueno y lo meten en la siguiente versión bajo su ala.
Normalmente una vez el controlador o el parche queda dentro de la versión oficial el mantenimiento queda de mano del encargado que lo metió, y la persona que lo creó sale corriendo y no le vuelves a ver el pelo, dejándole con el marrón durante muchos años, por eso son bastante exquisitos y puntillosos.
Mi opinión personal es que si hay que hacer experimentos intentando modernizar hay otros lenguajes que se adaptan mejor a espíritu de C, elegantes y menos complejos. Tipo Zig. A mí y a muchos otros programadores de C no nos gusta la sintaxis, la complejidad ni algunas decisiones del lenguaje impuesto. Es bastante más complicado que C++, algo feo, tarda mil años en compilar, quita bastante la sensación de control y flexibilidad, y todos estos lenguajes (incluido Zig) creo que están un poco en pañales. Otra cosa que tira para atrás es la asociación con el mundo de las criptomonedas, y algo de fanatismo ciego en una pequeña minoría ruidosa que se creen más listos que los que han hecho todo hasta ahora.
Al final creo que hay que ser pragmático y no minusvalorar la opinión de la gente que ha llevado Linux a lo que es, a veces se les trata a los encargados que quedan como algo obsoleto que hay que reemplazar y descatalogar. Esta gente son expertos en lo suyo, algunos llevan más de 30 años, y aunque a veces hay acidez y mala leche cruzada, hay que saber por qué una cosa es así antes de cambiarla o quitarla.
En lo que sí estoy de acuerdo con el blog de marcan que habéis puesto es en el tema de modernizar el sistema de contribución, que complica bastante la entrada incluso a gente que sabe de C y controladores. A mí me costó bastante que me hicieran caso a la hora de saber a quién enviar mis primeros parches (los CC de la lista de correo) y hacer que se percaten y te respondan, es verdad que luego es más fácil y que esto hace que no entre tanta morralla o spam.
GitHub es propietario y no lo van a utilizar ni de coña en el mundo del kernel, GitLab lo utilizan en X.org/freedesktop.org y es lento de narices y se arrepienten ahora que tienen que hacer mudanza.
Existen cosas tipo Gitea y Forgejo, pero no sé si admiten repositorios tan enormes como este sin causar problemas. Supongo que crearán algo a medida, como han creado Patchwork, syzkaller, herramientas de fuzzing, integrado Valgrind, las granjas de buildbots y otras cosas, tampoco están parados del todo. Hay cierta evolución entre los señores de barbas blancas.
Hola:
No creo que se fragmente.
De momento solo se están incrustando en drivers y alguna tarea "menor".
Es un hecho que ,si bien se es optimista con Rust , se está tomando con cautela.
Pero cuando llevas tantos años haciendo las cosas de una manera , cualquier cambio para explorar otras posibilidades siempre es visto con recelo y eso está bien.
Las ventajas de Rust las podemos resumir en menos errores en memoria por desbordamiento de búfer , escritura de código para multihilo y en teoría que sería mejor de mantener , esto último no lo tengo tan claro pero bueno.
La desventaja principal es que mientras existan o mejor dicho coexistan los dos lenguajes habrá que mantener una interfaz entre los dos lenguajes y eso no es insalvable , pero es una complicación más.
Es lo que tiene el futuro , veremos en que acaba.
Saludos.
