Linux Torvalds publicó el primer Linux 3.5 Release Candidate el pasado sábado en la noche, aunque el correo oficial no fue enviado hasta la tarde del domingo. Como es usual, el primer RC de la nueva versión señala el final del tiempo de la fase de mezcla en el repositorio para el comiendo del ciclo de desarrollo, durante el cual cercanamente los mayores cambios son hechos. A pesar de que muchos no lo creían, el conjunto de funciones que ofrece la versión Linux-3.5-rc1, debe ser casi idéntico al conjunto que se incluirá en la versión oficial, el cual se espera que sea liberado a finales de Julio o principios de Agosto.
Han pasado dos semanas desde que el kernel 3.4 fue liberado, y los desarrolladores del kernel no han perdido ni un ápice de tiempo y han integrado un grupo muy significativo de caraterísticas como uprobes (pruebas en el espacio de usuario). Esto puede ser usado por SystemMap y por la propia herramienta del kernel para el traceo de rendimiento, para el análisis del comportamiento en ejecución de programas confinados al espacio de los usuarios. Otras adiciones importantes al kernel 3.5 incluyen algunos parches a las funciones internas de logueo, contribuido por el mantenedor de Udev Kay Sievers, las cuales deben mejorar el análisis estructurado de los eventos de logs.
Los drivers para el Simple Kernel-based Mode Setting (KMS) para los chips de gráficos de ASpeed Technologies de la series 2000 y las series G200 de Matrox fueron agregados al Direct Rendering Manager (DRM), un driver KMS para el chip Cirrus que es emulado por Qemu también ha sido mezclado en esta versión. El driver permite que la resolución de pantalla sea configurada pero no se usa ninguna función de aceleración de los chips de gráficos. Esto, sin embargo, no es una pérdida total donde los dos primeros chips están incluídos, por el hecho de que ellos mayoritariamente tienden a ser usados por servidores. El driver DRM para Radeon debe proveer a los chips de gráficos modernos un mejor soporte para audio HDMI y se burlan un poco más del rendimiento que ofrece las GPUs Evergreen que son principalmente usadas por hardware de gráficos en las series Radeon HD 5000. Otras bases se colocaron también a soportar mejor las configuraciones de gráficos híbridos, en donde un chip gráfico más potente sólo se enciende cuando es necesario.
El kernel 3.5 ahora puedo usar también el estándar FireWire (originalmente creado por Apple y estandarizado en 1995 como la especificación IEEE 1394 High Performance Serial Bus) o el USB Attached SCSI Protocol (UASP) para servir como un objeto SCSI que pueda ser accedido por otros sistemas (“SCSI host” en la nomenclatura de SCSI); muchos sistemas producidos por Apple han tenido este tipo de “modo de objeto disco FireWire” desde hace algún tiempo ya. En esta versión también está la capacidad de funcionar como un objetivo SCSI usando el canal de fibra óptica de tipo HBAs desde las series 2400, 2500 y 2600.
El manejo de Writeback en el sistema de ficheros Btrfs también fue optimizado en esta versión, aunque el soporte para RAID 5 y 6 no fue agregado al sistema de ficheros por algunos errores de corrupción de archivos en el código actual. El sistema de ficheros Ext4 ahora puede agregar cheksums a sus metadatos para ayudar al reconocimiento de alteración de los datos. El sistema de red ahora incluye el planificador CODEL para la paqueteria para la gestiónd de la pila activa el cual es diseñado para ayudar al trabajo contra el problema del “bufferbloat”. La nueva característica de reparación de conexiones TCP debe prvenir problemas con tráfico de datos en la red después de que los contenedores han sido movidos a otro host.
The network subsystem now includes the CODEL active queue management packet scheduler which is designed to help work against the “bufferbloat” problem. The new TCP connection repair feature should prevent problems with network data traffic after containers have been moved to another host. Mientras tanto, el kernel ahora utiliza un mecanismo de filtro seccomp que filtra los comandos de función y agrega mejoras al manejor de espacio de usuarios para el aseguramiento de los contenedor de una mejor forma.
Para más detalles, pueden leer las notas oficiales de liberación de esta versión acá.
Como dice Taladrid: “Saquen usted sus propias conclusiones”
Comentarios ( 24 )
Nada nuevo que Windos no tenga
@Evangelion: Amigo si vas a decir cosas que no tengan NINGUNA IMPORTANCIA, por favor no opines…. y menos hables sin saber…. por favor que ha he visto bastante de tus comentarios y creeme que no son para nada instructivos, mas bien son para criticar sin base…
@Luis El objetivo que persiguo con el post es que los lectores fieles al blog como tú busquen que significa cada una de las cosas que puse en el mismo, pero como ya ves, no todos piensan igual.
@Evangelion ojalá y algún día, tengas la dicha de trabajar para Microsoft, para que cumplas tu sueño y sepas realmente cuáles son las bases de Windows, cuáles son sus APIs? cómo mejorarlas? y ser evangelizador de esa tecnología.
Yo realmente no tengo nada en contra de los de Redmond, sólo que opté por usar Software Libre y así seguiré.
Deberían tener un blog todos los detractores de Linux y el Software Libre, para que se sientan realizados y hablen de las tecnologías .Net, de LINQ, de Windows Communication Foundation, lo nuevo de SQL Server 2012, Windows Azure, que también son tecnologías muy usadas en la actualidad, y créanme, si ello llega a pasar, te aseguro que nosotros participaremos también, pero con comentarios interesantes y haciendo preguntas que les de a ustedes ganas de escribir nuevos posts para explicarnoslas.
Saludos
@marcos: Excelente respuesta. +100 para ti.
Caramba, que lo único que hace falta es que le metan algo como GTK al núcleo 🙂
¿En Nova se ha valorado la posibilidad de incluir la GUI en Linux?
@Luis Enrique Realmente no entiendo tu pregunta. Dentro del núcleo de Linux lo que se incluyen básicamente son drivers, módulos, subsistemas, pero no tienen sentido que incluyan APIs de este corte. El desarrollo del kernel no puede estar arraigado a librerías y sistemas como GTK o Qt, por el hecho de que no tiene sentido que formen parte del mismo.
Meter GTK en el núcleo sería una locura. Las partes de gráficos que van en el kernel son todo lo que tiene que ver con KMS (Kernel Mode Setting), que a la vez se sustenta sobre GEM (Graphic Execution Manager) y TTM (Translation Table Maps) que son subsistemas de manejo de memoria gráfica que provee el kernel para que los drivers, que corren en modo usuario, no necesiten manipular directamente la memoria gráfica que requiere privilegios superiores. Desde que Linux adoptó KMS han podido hacerse realidad algunos proyectos como, por ejemplo, Plymouth, y la transición de un modo gráfico a otro sin que la pantalla pestañee como ocurría en otros tiempos.
@Marcos y Dariem: 🙂 ninguna locura, es solo una modificación a la filosofía de Linux para mejorar el rendimiento de la interfaz gráfica. Aunque esta adopción supondría limitar* los objetos GUI, el modelo de programación de las aplicaciones gráficas y su rendimiento tendrían una mejora notable como pasa con Windows y MacOS logrando una solución más centrada en el usuario. Para implementarse Linux incluso tiene la ventaja de ser modular.
Como sea, no es una idea nueva ni mucho menos, de hecho Zack Smith intentó algo parecido con fbui hace bastante tiempo y acá: http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Embedded-Linux-Graphics-Quick-Reference-Guide/ pueden encontrar algunas ideas parecidas y otro montón bien grande que bien pudieran afinarse como módulos. Claro, lo de GTK fue una broma exagerando las posibilidades, pero sin dudas estandarizar el acceso a objetos gráficos desde el núcleo, como módulos seguramente, tendría varias ventajas para la programación de aplicaciones y su desempeño que es de lo que se trata.
La arquitectura de un S.O y de su núcleo es una cuestión totalmente manipulable. De hecho la gente de QNX podría decir que no tiene sentido que el núcleo incluya funciones de acceso al sistema de archivos y si fuéramos unos años más atrás encontraríamos comentarios “autorizados” sobre el error de incluir el stack tcp/ip en el núcleo. Pero la realidad y la necesidad se imponen, como el mismo Torvalds refirió en su famosa discusión con Tanembaum, lo que importa es el programa se ejecute y lo haga rápido.
* La limitación se refiere a estandarizar su manejo y muy probablemente cambiar algunos paradigmas en el manejo de las bibliotecas disponibles que dicho sea de paso, son demasiadas. Esto tiene varios vidrios de color para mirar
@Luis Enrique
Creo que una cosa como esa haría muy dependiente una cosa de la otra, entonces no me puedes programar aplicaciones en GTK tal porque el núcleo el GTK que tienen no es ese, entonces vendrían inventos de emulación.
El asunto es que al final la implementación sería acoplada y compleja. Yo digo no a esas cosas.
Yo creo que lo que habla luis no es descabellado, lo que me parece que cuando el dice Gtk se refiere a algo asi como dibujar componentes sobre el Framebuffer usando kms. Es decir que solo utilizando el kernel podamos obtener interfaces gráficas potentes sin necesidad del endemoniado X11. 100% de apoyo pa tu idea, implementaciones como esa que quieres ya se pueden ver en Android y muchos sistemas embebidos de televisores como los LG y algunos HDplayers.
@luis el vínculo que citas es de hace 10 años la mitad de las cosas que ahí se mencionan ya desaparecieron sin llegar a ningun resultado. Se me olvidó decirte que en Nova si nos gusta esa idea pero lamentablemente es irrealizable con los recursos que tenemos puesto que luego que tengas la interfaz gráfica embebida en el kernel hay que portar todas las aplicaciones para que funcionen sobre ese invento y no es factible.
A ver, que los veo muy acelerados: una cosa es meter GTK en el kernel, lo cuál es una locura, porque toda aplicación estaría corriendo en espacio privilegiado, y otra bien distinta es que el procesamiento básico de los gráficos se haga en el kernel. ¿Qué otra cosa si no son GEM y TTM? Eso ya está hecho. Lo de quitar Xorg es buena idea, porque es una capa en modo usuario innecesaria que infla demasiado el procesamiento gráfico, pero de ahí a meter el API que usan las aplicaciones en el kernel, ya eso es otra cosa (y bien salvaje, por cierto).
Bueno, Wayland no es precisamente lo que se está escribiendo como reemplazo para Xorg? Incluso, ya se están desarrollando backends tanto para GTK+ como para Qt.
Qt 5 en Wayland
GTK+ 3.4 Released: donde hablan acerca de la actualización del backend para Wayland:
Bueno, en Android pusieron una cosa llamada SGL, que supongo será algo parecido a Wayland, pero más simple.
@Dariem cuando se habla de incluir la GUI en el núcleo el objetivo es precisamente ejecutar tanto código de acceso INDIRECTO(el problemático) al hardware gráfico como sea posible en modo privilegiado, pero por supuesto que la API se mantiene en modo usuario. Estos accesos esencialmente son para hacer render de primitivas de objetos del sistema.
Jajajaja me cito:
“¿En Nova se ha valorado la posibilidad de incluir la GUI en Linux?”
“…lo de GTK fue una broma exagerando las posibilidades…”
Cuestión de gustos, valoraciones y tendencias, para mí sería genial tener un “linux gráfico”, aafirvida si entendió bien la idea. Por cierto, precisamente por el problema de la portabilidad y la compatibilidad escribí sobre comenzar como módulo del núcleo, para no obligar a su uso pero sí definir un estándar en el modelo de programación que asegure un rendimiento óptimo en la interfaz de usuario. Eso eventualmente, iría transformando los procedimientos actuales para manejo de interfaces gráficas en las distribuciones.
¡Ah! jeje precisamente, ese es un enlace viejísimo a cosas viejísimas, así que nada novedoso, salvaje ni alarmante en la “propuesta”.
Una observación. GEM y TTM son tecnologías para facilitar la gestión de la memoria y los contextos de ejecución en las tarjetas gráficas, que cada vez más son como otro PC. Como todo núcleo monolítico, Linux debe incluir buenos drivers para su manejo.
Pero eso no es exactamente la manipulación de primitivas GUI. Es como asumir que con el driver del teclado se pueden corregir faltas de ortografía. Un driver GEM es en realidad un gestor de memoria avanzado (¡NUMA en caso de GEM!) lo que acerca “sospechosamente” el manejo de buffers gráficos al núcleo y pensando como los locos, hace menos descabellada la vieja idea de un “núcleo gráfico”.
@Luis Enrique,
Sólo te digo una cosa: ningún sistema operativo tiene la biblioteca gráfica metida dentro del núcleo, incluso en las últimas versiones de Windows, a partir de Windows Vista, han hecho como en Linux, que los drivers corren en modo usuario y no en el kernel, y estamos hablando de los drivers, ni siquiera de las bibliotecas gráficas que corren sobre estos. El asunto es, que mantener cosas fuera del kernel es la mejor forma de evitar un cuelgue total del sistema (¿se acuerdan de los antiguos pantallazos azules de Windows y como han ido desapareciendo con el tiempo?). Es preferible que un bug “parta” a una aplicación y no que “parta” al sistema operativo completo, y de esta forma es mucho más fácil que el núcleo se recupere de un error en un driver defectuoso, que lo mande a reiniciar o lo que sea que tenga previsto para ese tipo de problemas, y no así si el código está corriendo en espacio privilegiado del propio núcleo. Y no creas que porque una cosa corra dentro del kernel va correr mejor o más rápido, en realidad todo depende de como el planificador de procesos maneje los recursos, lo que claro, si una primitiva de pintar debe pasar por 7 capas antes de llegar el hardware, por supuesto que será más lento que si sólo tiene que pasar por tres, y más aún si una de esas 7 capas es el X11, que es como un dragón de 7 cabezas.
@Luis Enrique, entonces creo que el próximo paso entonces es buscar un poco más de información acerca de estos temas. ¿Te parece? Y así poder escribir posts relacionados al tema. ¿Qué crees? Este tipo de discusiones fue el sentido principal del post, así aprendemos todos.
@Luis Enrique: tranquilo profe, que quienes le conocemos o tuvimos el privilegio de aprender a su lado, sabemos que usted es uno de esos talentos que cada día se desperdician en actividades ridículas en esta Universidad… A mi juicio pocas personas por aquí poseen los conocimientos y cultura que tiene usted principalmente de Sistemas Operativos, Arquitectura de Computadoras y Telecomunicaciones, claro está por solo citar algunos “skill” 😉 Es bueno que de vez en cuando aparezca por aquí, dejando alguna que otra idea.
Saludos 😉
Yo leo estas cosas y me doy cuenta de que el 97% de los graduados de informatica somos secrterios realmente
@Xerox
no, lo que sucede es que la informática es muy amplia …si te dedicas al desarrollo web, la ingeniería de software, diseño y un gran etc no es necesario conocer a fondo todas estas cosas …mi opinión muy personal
bueno el que quiera kernel con gui.. ese es su problema.. el kernel asi esta bien.
Al que le interese el tema puede crear una API a bajo nivel para escribir directamente en la memoria de video, mapeando la direccion de memoria correspondiente..
hace un tiempo escribi un programita para eso.. solo para ver si era posible acceder a las zonas prohibidas del kernel desde la arena de memoria del usuario.. y si es posible. Luego lo usaba para jugarle bromas pesadas a mis compañeros..que decian que la pc tenia problemas en el chipset gráfico.
al que le interese se lo puedo enviar
salu2
Recuerden que el kernel tiene que ser atómico, porque se encarga de un motón de cosas, no sólo de pintar….
Y cuando digo atómico no me refiero a que necesite energía nuclear, me refiero a la propiedad de atomicidad 🙂