Portada
mis comunidades
otras secciones
#5:
#1 Aquí de lo que se trata es de aumentar ciertos requisitos a la hora de poder compilar el kernel porque han llegado a un punto donde c11 tiene una funcionalidad que realizarla con c89 es complicado y da pie a errores y de paso aprovechar para usar otras nuevas características que lo hacen más usable.
Sería el equivalente a decir: eh, compilemos con gcc 6, porque gcc 5.1 cada vez nos está restringiendo más lo que podemos hacer y además nos facilita mucho la vida con esto y esto y nos permite esto otro.
O sea: no se va a reescribir nada en completo, ni siquiera en profundidad. No es un cambio de ese tipo.
Sobre si es mejor o peor reescribir todo en rust... la respuesta es: ahora mismo la mano de obra principal domina C, ha trabajado toda su vida en C, gran parte del éxito del kernel de linux se basa en la portabilidad del C, la cantidad de lineas de código que hay escritas en C es abismal... luego portar todo a rust sería tirar por la ventana muchísimo trabajo y trabajadores a la basura (en experiencia, recursos y sobre todo en tiempo) y eso sólo para llegar al mismo sitio. Ventajas tiene, sin duda, pero cuando el núcleo de linux llegara a estar tan consolidado, estable y funcional como el actual, a saber todo lo que hubiera cambiado, evolucionado y mejorado en ese tiempo. Aparte de que muchas arquitecturas se quedarían fuera por no tener soporte de rust, y el hecho de que aún rust sólo es soportado por un único compilador, lo suyo sería que tuviera soporte para al menos dos (los chicos de gcc están en ello)
Por ahora, el soporte rust que se está introduciendo en el kernel es para drivers de dispositivos nuevos y específicos, que se sepan que no van a poder necesitarse en arquitecturas donde rust no está soportado y como pruebas de concepto y poco a poco se irá expandiendo a otras cosas (rust brilla mucho sobre todo a la hora de hacer parsers y manejar datos de fuentes no seguras, cosas ambas que se realizan en muchos drivers, así que ahí tiene mucho que aportar).
Sería el equivalente a decir: eh, compilemos con gcc 6, porque gcc 5.1 cada vez nos está restringiendo más lo que podemos hacer y además nos facilita mucho la vida con esto y esto y nos permite esto otro.
O sea: no se va a reescribir nada en completo, ni siquiera en profundidad. No es un cambio de ese tipo.
Sobre si es mejor o peor reescribir todo en rust... la respuesta es: ahora mismo la mano de obra principal domina C, ha trabajado toda su vida en C, gran parte del éxito del kernel de linux se basa en la portabilidad del C, la cantidad de lineas de código que hay escritas en C es abismal... luego portar todo a rust sería tirar por la ventana muchísimo trabajo y trabajadores a la basura (en experiencia, recursos y sobre todo en tiempo) y eso sólo para llegar al mismo sitio. Ventajas tiene, sin duda, pero cuando el núcleo de linux llegara a estar tan consolidado, estable y funcional como el actual, a saber todo lo que hubiera cambiado, evolucionado y mejorado en ese tiempo. Aparte de que muchas arquitecturas se quedarían fuera por no tener soporte de rust, y el hecho de que aún rust sólo es soportado por un único compilador, lo suyo sería que tuviera soporte para al menos dos (los chicos de gcc están en ello)
Por ahora, el soporte rust que se está introduciendo en el kernel es para drivers de dispositivos nuevos y específicos, que se sepan que no van a poder necesitarse en arquitecturas donde rust no está soportado y como pruebas de concepto y poco a poco se irá expandiendo a otras cosas (rust brilla mucho sobre todo a la hora de hacer parsers y manejar datos de fuentes no seguras, cosas ambas que se realizan en muchos drivers, así que ahí tiene mucho que aportar).
#4:
#1 En primer lugar, YA se permite usar Rust en el kernel: https://thenewstack.io/rust-in-the-linux-kernel-good-enough/
En segundo lugar, "pasar el núcleo a C moderno" sólo implica cambiar una opción de compilación, pero no hace falta cambiar ni una sola línea de las fuentes. Lo que ocurre es que, a partir de añadir esa opción de compilación, se podrán "utilizar cosas" que antes no se permitían. Hasta ahora el compilador asumía que el código era C89, y no se permitían cosas como definir una variable en la definición de un FOR, por ejemplo.
En segundo lugar, "pasar el núcleo a C moderno" sólo implica cambiar una opción de compilación, pero no hace falta cambiar ni una sola línea de las fuentes. Lo que ocurre es que, a partir de añadir esa opción de compilación, se podrán "utilizar cosas" que antes no se permitían. Hasta ahora el compilador asumía que el código era C89, y no se permitían cosas como definir una variable en la definición de un FOR, por ejemplo.
#17:
#13 OJO: a lo mejor lo que te fallaba era el enlazado. Por ejemplo, hasta que se estabilizó el formato de llamada de C++ en el GCC, si querías enlazar código C++ con una biblioteca C++ precompilada, ambos tenían que estar compilados con la misma versión de GCC, pues si no, no te garantizaban que funcionase (era uno de los problemas de Qt, y una de las varias razones por las que Gtk se escribió en C). Hoy en día está más que resuelto, por suerte, pero hace unos años aún daba dolores de cabeza.
La versión más moderna de C es la C2x ( https://en.wikipedia.org/wiki/C2x ). Sin embargo, decidieron quedarse en la C11 porque está bien soportada en la versión 5 de GCC, que es la más antigua con la que garantizan que se puede compilar el kernel. Si usasen un estándar más reciente obligarían a la gente a utilizar un compilador más moderno, y para algunos sistemas puede ser problemático.
La versión más moderna de C es la C2x ( https://en.wikipedia.org/wiki/C2x ). Sin embargo, decidieron quedarse en la C11 porque está bien soportada en la versión 5 de GCC, que es la más antigua con la que garantizan que se puede compilar el kernel. Si usasen un estándar más reciente obligarían a la gente a utilizar un compilador más moderno, y para algunos sistemas puede ser problemático.
#1:
¿Y no sería mejor pasarlo a Rust directamente?
Comentarios
¿Y no sería mejor pasarlo a Rust directamente?
#1 Supongo que es mucho más esfuerzo. Una reescritura completa.
#2 Contratamos becarios
#3 Lenguaje que promete ser seguro vs programadores sin experiencia escribiendo código que promete ser inseguro. ¿Quién ganará?
#6 el compilador (rustc)
#7 El compilador está diseñado para pillar una serie de errores, pero no puede pillarlos todos. Si fuera así, no habría bugs en ningún software...
#36 ya lo sé, pero no has entendido mi broma: me estaba imaginando una exageración en las que los programadores sin experiencia se dan por vencidos y no consiguen compilar nada, como si fuera una batalla de ajedrez contra la máquina.
Disclaimer: no creo que Rust tan complicado o imposible ni que prevenga bugs en la lógica de "negocio", era solo una broma.
#37 El compilador siempre ha sido el peor enemigo del programador. Es que hay que darle todo mascadito porque si no, todo el rato poniendo pegas...
#1 #2 Creo que se podria hacer por partes. Se pueden hacer partes en C y Rust que interacciones con entre ellas. Esta bien para hacer cosas nuevas que seran mas seguras que si se hicieran en C. Lo antiguo ya debe estar muy probado y vigilado.
#4 Pense que habria cosas que no cumplirian el standar nuevo, pero entiendo que el nuevo es compatible con el viejo, pero codigo nuevo, no tiene por que cumplir el standar viejo.
#5 Ya que se rehace el codigo, a lo mejor se podria hacer una reestructuracion porque despues haber hecho un codigo, uno se da cuenta que deberia haber hecho las cosas de otra forma y aveces rehacer el trabajo cuesta mucho. Pero si ya hay que rehacerlo por otro motivo es un momento para mejorarlo.
Tambien se puede esperar a que la IA colaboren en programar y aprendan convertir un lenguaje en otro o encontras y resolver problemas en el codigo.
#12 Que yo sepa, lo único que no soporta C99 en adelante es la vieja sintaxis de K&R, la que era
nombre_de_funcion(var1, var2, var3)
char *var1;
float var2, *var3;
y donde si alguna variable o retorno no tenía definido el tipo, era un INT.
Respecto a lo de hacer con RUST por partes, es justo lo que ya están haciendo desde hace unos meses.
Por otro lado, no se "rehace el código", sino que hay un par de cosas que ahora se pueden hacer más sencillas porque, por ejemplo, en C99 y adelante puedes definir variables casi donde te de la gana, en lugar de tener que hacerlo al principio del código. No se van a reescribir grandes trozos de código, sino, por lo que he leído, un par de macros.
#12 El problema no es simplemente "traducir c a otro lenguaje" el problema es que son muchos problemas:
- Hay muchas funcionalidades que tiran de preprocesador (hay un fuerte (ab)uso de macros y opciones compilación condicional entre otras cosas). Simplemente cambiar esto ya es un mundo en si mismo (y no, en rust se maneja de manera muy diferente; entre otras cosas, para evitar tener un precompilador en primer lugar).
- Convenciones de funcionamiento que pueden (y deben) cambiar drásticamente si usas otro lenguaje (evidentemente, usar c++ para programar a la c no es lo más adecuado, usar java para programar a la c es imposible y usar rust para programar a la c... es de chapuzas).
- La gestión de memoria cambiaría completamente (al menos si quieres usar rust por sus características de seguridad propias del lenguaje... usar rust para hacer todo en rust inseguro "no tiene sentido").
- La gestión de procesos cambia completamente (rust tiene en el lenguaje su propia forma de gestionar esto).
- La gestión del propio proyecto cambia completamente. Habría que repensar cómo montar toda la estructura del kernel, qué módulos, submódulos, etc. serían necesarios, cómo jerarquizar, etc.
Vamos, que realmente sería diseñar y programar un kernel nuevo. Terminas antes tomando uno que ya funcione (redox, por ejemplo) y creando capas de compatibilidad con linux.
#33 Además, acabaría todo oxidado y muy rústico
#39 El acero cortén se oxida a si mismo para protegerse, como forma de aislarse de los efectos de la intemperie; igual no es tan malo...
#40 No es tan evidente pero el aluminio y el titanio se oxida superficialmente y evita que se oxiden .
#1 En primer lugar, YA se permite usar Rust en el kernel: https://thenewstack.io/rust-in-the-linux-kernel-good-enough/
En segundo lugar, "pasar el núcleo a C moderno" sólo implica cambiar una opción de compilación, pero no hace falta cambiar ni una sola línea de las fuentes. Lo que ocurre es que, a partir de añadir esa opción de compilación, se podrán "utilizar cosas" que antes no se permitían. Hasta ahora el compilador asumía que el código era C89, y no se permitían cosas como definir una variable en la definición de un FOR, por ejemplo.
#4 Seguro? No sería la primera vez que me falla una compilación por usar una versión más moderna de la que se utilizó en el momento que se escribió el código.
Otra duda que tengo: la versión de C de 2011 es la más actual? Y si no es así, por qué quedarse en algo de hace 11 años?
#13 OJO: a lo mejor lo que te fallaba era el enlazado. Por ejemplo, hasta que se estabilizó el formato de llamada de C++ en el GCC, si querías enlazar código C++ con una biblioteca C++ precompilada, ambos tenían que estar compilados con la misma versión de GCC, pues si no, no te garantizaban que funcionase (era uno de los problemas de Qt, y una de las varias razones por las que Gtk se escribió en C). Hoy en día está más que resuelto, por suerte, pero hace unos años aún daba dolores de cabeza.
La versión más moderna de C es la C2x ( https://en.wikipedia.org/wiki/C2x ). Sin embargo, decidieron quedarse en la C11 porque está bien soportada en la versión 5 de GCC, que es la más antigua con la que garantizan que se puede compilar el kernel. Si usasen un estándar más reciente obligarían a la gente a utilizar un compilador más moderno, y para algunos sistemas puede ser problemático.
#13 Por experiencia, lo que comentas de tener fallos en versiones nuevas sí es bastante normal en C++, pero bastante raro en C.
A día de hoy el último estándar es C17, pero C23 está a punto de salir del horno con estos cambios: https://en.cppreference.com/w/c/23
#4 C89 forzaba a la declaración de variables al principio del método/región. Hasta hace no mucho trabajaba en un proyecto que para Windows se compilaba en VS2010 (que era C89) y cuando pasabas a probar a compilar en Windows siempre acababas con fallos de ese tipo que ir corrigiendo.
#15 Exacto. Es a lo que me refería con lo del FOR.
#19 Ahora ya hemos logrado migrar el toolchain de Windows y podemos usar C99, un estandar que solo es mas viejo que el mas joven del equipo, en vez de la mitad
#24 Es en serio, no es un candidato, Rust YA es un lenguaje aceptado en el kernel cc #4
#1 Aquí de lo que se trata es de aumentar ciertos requisitos a la hora de poder compilar el kernel porque han llegado a un punto donde c11 tiene una funcionalidad que realizarla con c89 es complicado y da pie a errores y de paso aprovechar para usar otras nuevas características que lo hacen más usable.
Sería el equivalente a decir: eh, compilemos con gcc 6, porque gcc 5.1 cada vez nos está restringiendo más lo que podemos hacer y además nos facilita mucho la vida con esto y esto y nos permite esto otro.
O sea: no se va a reescribir nada en completo, ni siquiera en profundidad. No es un cambio de ese tipo.
Sobre si es mejor o peor reescribir todo en rust... la respuesta es: ahora mismo la mano de obra principal domina C, ha trabajado toda su vida en C, gran parte del éxito del kernel de linux se basa en la portabilidad del C, la cantidad de lineas de código que hay escritas en C es abismal... luego portar todo a rust sería tirar por la ventana muchísimo trabajo y trabajadores a la basura (en experiencia, recursos y sobre todo en tiempo) y eso sólo para llegar al mismo sitio. Ventajas tiene, sin duda, pero cuando el núcleo de linux llegara a estar tan consolidado, estable y funcional como el actual, a saber todo lo que hubiera cambiado, evolucionado y mejorado en ese tiempo. Aparte de que muchas arquitecturas se quedarían fuera por no tener soporte de rust, y el hecho de que aún rust sólo es soportado por un único compilador, lo suyo sería que tuviera soporte para al menos dos (los chicos de gcc están en ello)
Por ahora, el soporte rust que se está introduciendo en el kernel es para drivers de dispositivos nuevos y específicos, que se sepan que no van a poder necesitarse en arquitecturas donde rust no está soportado y como pruebas de concepto y poco a poco se irá expandiendo a otras cosas (rust brilla mucho sobre todo a la hora de hacer parsers y manejar datos de fuentes no seguras, cosas ambas que se realizan en muchos drivers, así que ahí tiene mucho que aportar).
#5 Interesante comentario. En demasiadas ocasiones los problemas tecnológicos tienen un trasfondo más humano, derivado de tener a cientos de personas colaborando, que técnico.
#8 Simplemente no puedes cambiar 1000 colaboradores por otros (que igual no hay 1000 que tengan el nivel o conocimiento para poder colaborar en algo tan especializado y complejo) así de sopetón y por gusto. Sería un desastre para cualquier proyecto.
#5 no se va a reescribir nada en completo, ni siquiera en profundidad
Si todo va bien, claro. En un proyecto tan tremendamente inmenso no sería de extrañar que surgieran sorpresas o comportamientos inesperados. El propio Torvalds indica que no lo hicieron antes "because we had some odd problem with some ancient gcc versions that broke documented initializers".
https://lwn.net/ml/linux-kernel/CAHk-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbVFW3TA@mail.gmail.com/
#11 Claro, cualquier cambio tiene sus riesgos. Pero en algún momento llegas a un punto donde el beneficio del cambio a corto y largo plazo supera el dolor de realizarlo (que puede ser tan inmediato como corregir algún problemilla aquí o allí o algo que haya que pegarse mucho tiempo depurando hasta averiguar qué pasa y luego buscar soluciones o alternativas que pueden ser más o menos viables o que lleven a más cambios y más disruptivos. Nos enteraremos en breve...
#1 por que no abandonamos C por algo mejor?
Cien veces preguntado, y la respuesta no cambia.
https://daniel.haxx.se/blog/2017/03/27/curl-is-c/
Y curl es "pequeño" comparado con Linux.
#1 no
#1 Rust se ha aceptado como un lenguaje valido para el kernel, simplemente no lo necesitas en todas partes.
Tambien puede ser que portar C a una versión distinta es infinitamente mas facil que reescribir de cero en otro lenguaje (que ademas está pensado para multi hilo.)
#1 el código actual seguiría compilando con este cambio y tendrían la posibilidad de programar en C más moderno.
Reescribir el kernel que se usa actualmente en la mayoría de servidores del mundo, por nombrar solo una de las muchas implicaciones, me imagino que será bastante inviable.
Que use Google Translator, a ver que sale…
#9: O con el
AutoBICAutopilot de Github.#27 pues me quedo con vbscrpt
mejor a javascript, pyton o php
#16 Pues no, pero Rust si sería un buen candidato.
#18 no hablas en serio, verdad ?
#24 Pues hombre, sin ser un experto, parece ser tiene todas las papeletas para serlo en un futuro (tal vez no muy lejano).
#24 Rust ha sido pensado como lenguaje de implementación de sistemas operativos, precisamente.
javascript es una broma, que te puede dar un sueldo pero no pasa de chapuza.
python es más lento que el caballo del malo
php es más interpretado que python
#27 Y sin embargo PHP es muchísimo más rápido que Python.
#24 Ya se esta abriendo la ventana a Rust como segundo lenguaje del kernel. No para la parte mas nucleo pero si para drivers y otros subsistemas.