Ir al contenido

Buscar en La Comunidad

Mostrando resultados por etiquetas 'Wayland'.

  • Buscar Por Etiquetas

    Añade etiquetas separadas por comas.
  • Buscar Por Autor

Tipo de Contenido


Foros

  • Contacto con el staff
    • Novedades / Anuncios del foro
    • Sugerencias
    • Problemas relacionados con el foro
  • Zona general de charla
    • Presentaciones
    • Charla
    • Zona de Humor, Curiosidades y Otros
    • Mascotas Vagos
    • Noticias del Mundo
    • Tecnología
    • Ayuda y consultas de carácter general
  • Zona GNU/Linux
    • Ayuda, consultas y soporte GNU/Linux
    • Distribuciones GNU/Linux
    • Repositorios. Software GNU/Linux
    • Personalización
    • Raspberry Pi
    • Arduino
    • Manuales / Tutoriales / Guías GNU/Linux
    • Programación
    • Noticias GNU/Linux
    • Hablando de GNU/Linux
  • Zona Gaming
    • Juegos GNU/Linux
    • Noticias Gamer
    • Charla Gamer
  • Zona Móvil
    • Ayuda y soporte para dispositivos móviles
    • Apps Móviles
    • Manuales / Tutoriales / Guías Móviles
    • Roms para dispositivos Móviles
    • Noticias sobre dispositivos Móviles
    • Hablando sobre dispositivos Móviles
  • Zona Mozilla
    • Ayuda, consultas y soporte Mozilla
    • Aplicaciones Mozilla
    • Roms Firefox OS
    • Manuales / Tutoriales / Guías Mozilla
    • Noticias Mozilla
    • Hablando de Mozilla
  • Microsoft
    • Papelera del Foro

Encontrar resultados en...

Encontrar resutados que...


Fecha de Creación

  • Start

    Fin


Última Actualización

  • Start

    Fin


Filtrar por numero de...

Joined

  • Start

    Fin


Grupo


Página Web


Diaspora


Pump


GNU Social


Google +


Twitter


Facebook


Xmpp


Skype


Steam


Desura


MediaGoblin


Youtube


Vimeo


Picasa


Flickr


Email


Lugar


Intereses

Encontramos 29 resultados

  1. Maui es un ambicioso proyecto que pretende ofrecernos una nueva e innovadora distribución GNU/Linux con su propio entorno gráfico QT5 ligero y coherente llamado Hawaii, su propio sistema de paquetes pensado para hacer un uso muy bajo del ancho de banda y todo pensado para correr directamente sobre Wayland. Diseñada para que sea sencilla de usar y aprovechar las tecnologías más actuales, Maui, aunque aún en estado preliminar, se perfila como una de las apuestas más interesantes para el futuro. Capturas Descarga https://downloads.sourceforge.net/project/mauios/pre-alpha/maui-0.0.2-x86_64.iso Web http://www.maui-project.org/
  2. Hace ya varios años que Wayland, el protocolo de servidor gráfico que sustituirá al veterano X11, está "por llegar", pero sigue sin hacerlo y es que, aunque cada vez estamos más cerca y ya hay distribuciones que se atreven a incluirlo entre su paquetería, como alternativa o incluso, como servidor gráfico por defecto, aún hay muchos escollos en el camino que hay que solventar para que Wayland puede estar en el escritorio de todos los linuxeros. Entre las tareas pendientes están, como no podría ser de otra manera, la compatibilidad por parte de los distintos controladores gráficos y la adaptación de entornos gráficos, gestores de ventanas, compositores, etc al nuevo protocolo. En este sentido, desde hace más de un año viene desarrollándose y acalorado y enrevesado debate que dio origen con la presentación, por parte de Nvidia, de EGLStream. Por hacer un breve resumen, hasta ahora Wayland ha girado en torno al administrador genérico del buffer GBM, algo que Nvidia, ya por el año 2012 criticó, para un par de años más tarde presentar su alternativa, que es lo que ahora conocemos como EGLStreams. Esto no fue bien recibido por la comunidad, que ya sabemos de sobra que es de mecha corta y desde entonces el conflicto está en el aire. Lo irónico del caso es que, en esta ocasión, la empresa californiana, conocida por tener muy buen soporte pero también prácticas muy privativas, tiene razón. GBM, aún siendo software libre, es de carácter exclusivo y está atado estrictamente a los controladores mesa, mientras que EGLStream se basa en el estándar abierto EGL, es multisistema, multiplataforma y, por lo que hemos podido saber hasta el momento, en cuanto a eficiencia y capacidades técnicas también supone una mejora importante. La problemática reside, precisamente, en ese lapso de tiempo de 3-4 años desde que Nvidia hiciera públicas sus intenciones hasta que finalmente se materializaron, pues todo el trabajo se ha venido desarrollando pensando únicamente en GBM y un cambio a estas alturas significaría replantearse muchas cosas y modificar un gran número de líneas de código. Además, muchos temen que a falta de un consenso acaben teniendo que mantener simultáneamente dos métodos de manejo del buffer para cada compositor, con todo el esfuerzo que ello implica. E incluso hay quien sugiere reinventar GBM para ponerlo a la altura de las características de EGLStreams en lugar de modificar los compositores para que hagan uso de otro administrador del buffer. Aun sin haber llegado a una conclusión clara todavía, parece que Nvidia va ganado adeptos que consideran que apuntar a un estándar universal y abierto, además de más completo y eficiente, en torno a una nueva API desarrollada de manera conjunta, es el camino a seguir. Entre ellos está la gente de Gnome, que ya ha empezado a trabajar para adaptarse lo antes posible. Por si fuera poco y como reza el título de este tema, Nvidia sigue avanzando mientras la comunidad sigue debatiendo y en su última serie de controladores incluye nuevas librerías EGL para Wayland y una interfaz de plataforma externa para EGLStreams, de tal forma que manejo de buffer utilizando EGLStreams podría ser implementado de manera sencilla en cualquier sistema de ventanas sobre plataformas EGL de bajo nivel superpuestas. Concretamente sobre EGL_PLATFORM_DEVICE_EXT, utilizando extensiones EGLStream. Para rematar, nos brindan todo el código fuente de ambos, tanto de la interfaz de plataforma externa EGLStremas como de las librerías EGL para Wayland,incluyen nuevas extensiones Vulkan, sombreado multihilo GLSL y habilitan las optimizaciones OpenGL por defecto (con un sistema de autoajuste que las desactiva en caso de que no supongan una mejora del rendimiento) en el nuevo controlador 378.X. Casi nada... y de fondo la comunidad aún discutiendo:sweat: https://lists.freedesktop.org/archives/wayland-devel/2017-January/032722.html.
  3. Tras la XDC2016, el debate sobre el futuro de Wayland, GBM, EGLStreams y los controladores de Nvidia, sigue en el aire, pero las conversaciones continúan y vamos aclarando algunas cosas. Recordemos que la polémica surgió cuando Nvidia desarrolló una nueva línea de controladores gráficos pensados para explotar todas las bondades de Wayland, apoyándose en el estándar libre EGL, o más concretamente EGLStreams. Esto no sentó bien a la comunidad de desarrolladores, tanto de controladores libres como de entornos gráficos y administradores de ventanas, pues hasta ahora se habían centrado en desarrollar todo alrededor de GBM (Generic Buffer Management), "exclusivo" de los controladores MESA. La nueva aproximación "más abierta" de Nvidia implicaría o bien un giro raical en la dinámica con la que se venían desarrollando las aplicaciones gráficas para Wayland hasta ahora o un enfoque más conservador, duplicando esfuerzos y manteniendo GBM junto con EGLStreams simultáneamente. Mientras que por el otro lado, Nvidia se enfrentaría a tener que rediseñar sus controladores, con algunos problemas añadidos debido a conflictos legales entre licencias. En definitiva, un callejón sin salida para ambas partes, que deben ponerse de acuerdo para encontrar una nueva vía que dé solución al problema. James Jones ha hablado sobre esto en la conferencia que realizó en el XDC, en el que insiste, una vez más, que lo que pretende Nvidia es apostar por una solución agnóstica, tanto para fabricantes, kernels, sistemas de ventanas, a la vez que se ofrecería un escenario gráfico con optimización para optimización para cada fotograma representado. Está claro que se trata de un gran reto para Wayland en este momento, pero hay que mirar con un punto de vista mucho más amplio, buscando optimizar la asignación de memoria para todos los dispositivos. Y para ampliar un poco más esta idea, que a priori parece más que razonable, nos ha hablado de las posibles alternativas que existen en este momento. GBM Es la manera utilizada actualmente por los compositores Wayland. Proporciona asignación de buffer, arbitraje y handlers. La principal ventaja es, como no, que ya se encuentra implementado y lleva mucho tiempo de desarrollo y testeo. Las deficiencias que presenta en la presentación es que los procesos que maneja son estrictamente locales, se centra excesivamente en la GPU y el arbitraje es dentro del alcance de dispositivo Gralloc Es la aproximación del sistema Android.Proporciona asignación de buffer, arbitraje, handlers, además de sincronización y out-of-process handles, pero requiere otros componentes. Al igual que el anterior, ha sido ampliamente probado, es una especificación de uso de tiempo de asignación y soporte utilización no-gráfica. En cuanto a defectos tenemos un arbitraje limitado, gestión de estado de la superficie no explícita y partes privativas/cerradas. DMA-BUF Proivee handles y trabaja con dispositivos no-gráficos, pero no no existe una API centralizada de asignación del espacio de usuario, sólo funciona en GNU/Linux, no describe la disposición del contenido, carace de arbitraje y la especificación de uso de tiempo de asignación es limitada. Vulkan Aunque la API presenta multitud de beneficios evidentes, además de contar con asignación relativa de interfaces, manejo de estado y sincronización. Pero es graphics/compute/display-only cerente de cross-process/cross-API/cross-device handles o arbitraje. EGLStreams La alternativa impulsada por NVIDIA soporta asignación, handles, manejo de estado y sincronización. Está siendo probada, es portátil y con amplias/extensas capacidades integrales. El principal escollo del estandar abierto es que cada fabricante lo implementa a "su manera", no existe soporte multidispositivo, se asienta sobre EGL, hay un montón de encapsulación y su comportamiento puede variar en ciertas áreas. Con esto en mente, Jones espera que la comunidad de desarrolladores pueda enfocarse en concebir una API más óptima y minimalista, que sea portable, soporte más que únicamente GPUs, a la vez que garantice un buen rendimiento, soporte transiciones de diseño de imagen, maneje las capacidades de negociado de imagen del controlador y mucho más. En definitiva, una crear una API universal y completa para otros clientes y sistemas de ventanas, para una optima asignación de memoria/superficie. https://www.x.org/wiki/Events/XDC2016/Program/Unix_Device_Memory_Allocation.pdf
  4. Desde que se de la existencia de Wayland he tenido una pequeña obsesion por hacerlo funcionar con Enlightenment, mi escritorio predilecto para Debian, asi que aprovechando mi reciente tiempo libre decido ponerme manos a la obra Partiendo de la base de la guia de enlightenmente escrita por Shiba87, practicamente lo que he cambiado ha sido el codigo fuente y los parametros de compilacion, ademas de instalar los paquetes de wayland en el sistema. Basicamente quiero plasmar mi experiencia sobre este post para formar una especie de guia experimental, lo que me ha funcionado tal vez de error al resto de personas y etc, asi que agradeceria cualquier observacion o experiencia que podamos añadir Utilizo una tarjeta grafica integrada Intel HD4000 asi que me libro de problemas de drivers, a los de Nvidia y demas les aconsejaria cerrar los ojos y llevar casco Instalando librerias y 'cosas' Pasamos a la parte de obtencion del codigo fuente, al principio probe a compilar la version estable pero lo resumire en horas de trabajo en vano hasta que utilice los repos git El arranque ya a la carta de uno, yo tire de entrance como login manager y ha arrancado perfectamente, no se que tal tirara con autologin o con otro LM
  5. Aunque hace tiempo que me decidí por no sucumbir a polémicas a la hora de escribir, en este caso quiero hacer una excepción, porque es un tema que nos llega de cerca a muchos y que podría ser decisivo para el futuro de los entornos gráficos en GNU/Linux Hace muy poco, Nvidia liberó por fin una nueva serie de controladores que, no sólo nos traían Vulkan de manera estable y completamente funcional, sino que nos brindaban soporte para el servidor gráfico Wayland a través de EGL. Algo que llevábamos esperando desde hace ya mucho tiempo. Sin embargo, aunque en principio esta noticia sobre Nvidia suponía un salto importante a la hora de empezar a adoptar masivamente el servidor gráfico Wayland, dejando por fin "de lado" al veterano X11, junto a los controladores oficiales se han liberado una serie de parches de código abierto, que fueron enviados a la comunidad de desarrolladores de Wayland, que no han sido visto con buenos ojos por parte de los desarrolladores del servidor gráfico. Este código, pensado en principio para permitir que Weston, el compositor base de Wayland pueda correr sobre los controladores gráficos oficiales de Nvidia (privativos), ha sido rechazado. El origen de la polémica parece ser la implementación que ha hecho Nvidia, pues se valen directamente de EGL, haciendo uso de las extensiones EGLDevice y EGLStreams para manejar los buffers, mientras que la implementación oficial de Weston utiliza MESA GBM (Generic Buffer Manager). Si bien para algunos, incluida la propia Nvidia, esta aproximación supone un acercamiento más "agnóstico", en lugar de tener que desarrollar una versión alternativa de GBM para su línea de controladores, desde el otro lado sólo ven problemas con la alternativa propuesta por la californiana, al hacer uso de extensiones poco usuales o complicar/simplificar demasiado ciertos aspectos del renderizado. Aunque en principio esto no impide que entornos con compositores propios, como Enlightenment, Hawaii, Orbital, Orbment o incluso alguno de los más conocidos como KDE O Gnome, puedan dar soporte a Nvidia, implementándolo por cuenta propia en sus compositores, dentro del seno de Wayland y de cara al compositor Weston, por ahora las cosas están siendo discutidas de manera muy acalorada y no parece que veamos pronto ningún movimiento, al menos hasta que todos los pormenores hayan sido hablados y el código de Nvidia minuciosamente estudiado. https://lists.freedesktop.org/archives/wayland-devel/2016-March/027547.html
  6. Bueno andando por la web me encontre con este blog al que puse en mis marcadores de browser. Com vi una entrada que puede interesar a otros pues la pongo por aqui → Lo que se sigue es un copy paste del mismo blog por lo tanto hago una transcripción de las palabras del autor : Hasta ahora para dibujar ventanas en Linux usabamos X11. El protocolo X11 data de mediados de los 80. Esta escala temporal en el mundo de la informática es una barbaridad, por lo que alguien pensó que era hora de actualizarlo. Wayland va a ser la nueva forma que vamos a tener de dibujar ventanas en Linux. Viene incluido de serie en Ubuntu 16.04 y ya puede ser probado. Lo primero que hay que hacer es instalar los paquetes necesarios. Para ello se ejecuta: Una vez instaladas las dependencias necesarias, se procede a configurar Weston. Weston es la implementación por defecto de cómo debería ser un entorno de escritorio bajo Wayland. Con nuestro editor de texto favorito se va a crear el archivo “~/.config/weston.ini”: Ahora sí. Vamos a ejecutar Wayland. Para ello pulsamos la combinación de teclas “Ctr+Alt+F1”, entraremos en modo consola. Siempre podemos volver al modo gráfico con “Ctr+Alt+F7”. Nos autentificamos y escribimos en el terminal: Por ahora sólo podemos lanzar terminales, para poder ejecutar otras aplicaciones se abre un terminal dentro de Wayland y se debe escribir: Con esta configuración podemos lanzar aplicaciones desde ese terminal. Vamos a notar diferencia entre las aplicaciones GTK3, Qt5 y X11. Las aplicaciones GTK3 y Qt5 se ejecutarán en modo Wayland nativo. Para las X11 se creará una ventana dentro de Weston, al estilo que usan los Mac. Por ejemplo, se puede ejecutar LibreOffice con el comando “lowriter”. Se puede navegar por Internet con el comando “webbroser”. Weston trabaja mucho con las combinaciones del teclado, al estilo de Unity. Las más interesantes son: Ctr + Alt + borrar → Salir de Weston Super + tab → Cambiar de ventana Super + rueda del ratón → Zoom Super + Alt + rueda del ratón → Cambiar opacidad de la ventana Super + k → Cerrar ventana Super + s → Hacer captura de pantalla Super + r → Hacer un vídeo de la pantalla Toda la configuración de Weston se puede encontrar en el archivo “~/.config/weston.ini”. Para ver el manual de este archivo, se puede usar el comando “man weston.ini”. Aquí se cambian cosas como pueden ser la resolución de la pantalla, el idioma del teclado o la imagen de fondo. El consumo de RAM es bajo. Una sesión recién abierta de Weston consume 82 Mb. Comparando con X11, una sesión recién iniciada de Openbox consume 96 Mb. Para hacer esta prueba he parado lightdm usando el comando “service lightdm stop”. Como Weston es un gestor de ventanas ligero, por eso lo comparo con Openbox. He notado que se puede trabajar bajo Wayland, llegando a lanzar documentos de LibreOffice bajo Wayland y trabajar sin problemas. Pero la integración de las aplicaciones con Wayland está todavía muy verde. Supongo que con el tiempo esto se solucionará. De hecho, no he sido capaz de ejecutar Firefox, que suelta una extraña ventana de error. Las ventanas de las aplicaciones GTK3 y Qt5 tienen decoraciones diferentes. La decoración de la ventana también es diferente cuando se lanza una aplicación X11 pura o una aplicación de Weston pura. Por ahora me voy a quedar con X11, pero Wayland será una opción interesante cuando en un futuro se mejore la integración de las aplicaciones. ------------ Y eso es todo como siempre debeis visitar el contenido original aqui→ https://cartaslinux.wordpress.com/2016/07/02/probando-wayland-en-ubuntu-16-04/ La entrada menciona el uso de Ubuntu 16.04 asi que es una guia presente espero os sirva.
  7. Mucho se ha hecho de rogar, pero finalmente tenemos lo que tanto hemos esperado. Nvidia acaba de liberar una nueva serie de sus controladores oficiales que traen, como siempre, muchas novedades interesantes, pero es que esta vez son más que eso. La nueva serie 364 culmina lo que comenzó con la serie experimental 355 y nos brinda soporte oficial estable para la nueva API gráfica de Khronos, Vulkan, en su actual versión 1.0.6, además de completar el proceso de adopción de EGL introduciendo las primeras librerías que dan soporte completo al servidor gráfico Wayland. Se cambia el patrón de instalación para hacer uso de las librerías GLVND GLX en lugar de las librerías GLX antiguas Se añade soporte inicial para DRM KMS (Direct Rendering Manager Kernel Modesetting) Esto significa la inclusión de un nuevo módulo nvidia-drm.ko, que se inscribe tanto con soporte PRIME como DRM KMS Se añade soporte para numerosas extensiones EGL EGL_EXT_platform_waylandencargada de hacer que aplicaciones Wayland corran en la implementación EGL de Nvidia EGL_WL_bind_wayland_displayencargada de hacer que compositores Wayland corran en la implementación EGL de Nvidia EGL_EXT_device_drm EGL_EXT_output_drm EGL_EXT_stream_consumer_egloutputPara permitir que los compositores Wayland muestren su contenido a través de EGLDevice, EGLOutput y EGLstreams. Se añade la librería libnvidia-egl-wayland.so, que permite a los compositores Wayland el uso de EGLDevice, EGLOutput y EGLstreams para compartir el buffer de EGL con las aplicaciones Wayland Suporte estable para la API Vulkan 1.0 Se mejora la precisión de X colormap desde 8 bits significativos a 11 en GPUs Geforce Se añade una nueva característica RandR, CscMatrix, la cual especifica una matriz de conversión de espacio de color de 3x4. Esta matriz se aplica después de X colormap y antes de gamma ramp. Es compatible con GPUs GF119 o más recientes. Así mismo se mejora el manejo de X gamma ramp en GPUs GF119 o más recientes. RandR gamma ramp cuenta siempre con 1024 entradas y ahora se aplica al cursor, VDPAU capas de estaciones de trabajo como añadido a la ventana de root de las Xs. Los registros del controlador de Nvidia han sido rediseñados con el nuevo subsistema DRM de Linux para dar soporte a PRIME. Como consecuencia de esto, es necesario contar con Linux 3.13 o superior para instalar esta nueva serie de controladores. Se mejora la interacción de aplicaciones que utilizan el cursor de hardware mientras G-SYNC está activo. Se incluye también soporte para nuevas GPUs GeForce 920MX GeForce 930MX Y, por supuesto, numerosos parches y correcciones Sobra decir que al margen de la ingente cantidad de novedades y mejoras, tanto Wayland como Vulkan son dos cosas que llevábamos mucho tiempo esperando y que por fin tenemos a nuestro alcance para sacarle todo su potencial. Nos queda aún el sabor agridulce por la falta de soporte a gráficas Fermi, esperemos que finalmente de parecer, pero igualmente hay que reconocer que, si bien no como a todos nos gustaría, Nvidia sigue siendo única a la hora de ofrecer soporte a los linuxeros más exigentes.
  8. Lo que empezó como una pequeña broma linuxera, ha acabado por convertirse en una distribución hecha y derecha que nos permite seguir los avances del servidor gráfico Wayland y prácticamente todos los entornos gráficos que planean darle soporte. Al contrario que en ediciones anteriores y debido al desencanto de sus desarrolladores con su anterior distribución base, además de ciertos problemas legales, RebeccaBlackOS está ahora construida enteramente sobre Debian en su rama Testing. Otro de los cambios destacados ha sido la inclusión del instalador Calamares y el arranque EFI, así como todas las novedades referentes a Wayland Linux 4.3 (Debian) Instalador Calamares Librerías actualizadas Wayland Master Weston Master Toolkits y aplicaciones Wayland Wayland enabled Clutter Wayland enabled SDL Wayland enabled GTK Wayland enabled Qt Wayland enabled EFL/Elementary Wayland enabled FreeGLUT Wayland enabled GLFW Wayland enabled mpv Wayland enabled gstreamer KDE Frameworks Wayland programs Native Calligra Wayland programs Escritorios Wayland Weston's Example Desktop (selectable at login, and as a nested session from the application menu) Orbital (selectable at login, and as a nested session from the application menu) (NOT on this ISO) Hawaii (selectable at login, and as a nested session from the application menu) Papyros (selectable at login, and as a nested session from the application menu) Gnome-shell (selectable at login, and as a nested session from the application menu) Enlightenment E20+ (selectable at login, and as a nested session from the application menu, however XWayland applications don't work when nested) Orbment tiling Wayland DE (selectable at login, and as a nested session from the application menu)Use super+enter for terminal, and super+r for dmenu Sway tiling Wayland DE Otras características A graphical utility for configuring udev for weston multiseat/multi pointer A rudimentary but functional Wayland login manager written in Bash, that supports user switching and session selection. RDP enabled Weston Capturas Estamos en ello... Descarga AMD64 https://github.com/n3rdopolis/rebeccablackos/releases/download/2016-02-08/RebeccaBlackOS_amd64.iso i386 https://github.com/n3rdopolis/rebeccablackos/releases/download/2016-02-08/RebeccaBlackOS_i386.iso Web http://sourceforge.net/projects/rebeccablackos/ https://github.com/n3rdopolis/rebeccablackos/
  9. Como estaba planeado, según la nueva estrategia de desarrollo acelerado que adoptó el equipo de E hace un par de años, la última versión del entorno gráfico Enlightenment ha llegado hoy, día 1 de Diciembre, como un regalo de Navidad adelantado. Aunque la esencia del entorno se ha mantenido intacta, tal y como veníamos viendo desde E18, Enlightenment 0.20 ha sido "reconstruido" en gran parte, con el fin de mejorar aún más el soporte para el servidor gráfico Wayland, que se completó en la anterior E19 y además se han hecho grandes esfuerzos para mejorar la integración con FreeBSD, se ha introducido un nuevo administrador de pantalla, una nueva infraestructura para el mezclador de audio, los widgets internos han sido reemplazados por Elementary, ahora cuenta con un módulo propio de geolocalización y, por supuesto, todas las librerías de EFL, así como otros componentes han sido actualizados a la versión 1.16, también con grandes novedades y mejoras. Según dejan constancia las estadísticas de la página oficial, más de 50 desarrolladores han trabajado durante exactamente 441 días para crear un total de 1890 parches. ¡Casi nada! Aunque no está entre los entornos gráficos más populares y, si bien su ligereza y desempeño cautivan a muchos, su falta de aplicaciones hace que aún no se hayan atrevido a probarlo o no lo tengan en su escritorio del día a día, pero está claro que en varios frentes sigue siendo uno de los escritorios más punteros del momento y, aún siendo un proyecto tan modesto, sigue avanzado para, quizá algún día, llegar a convertirse en todo un referente en los escritorios linuxeros. https://phab.enlightenment.org/phame/live/3/post/e20_release/
  10. Nvidia sigue trabajando sin descanso para que sus controladores oficiales tengan pronto soporte completo para Wayland. Durante la serie anterior, la 355, ya dimos cuenta dew todas las mejoras en lo que respeta a EGL y la nueva forma de construir los módulos para el Kernel. Ahora, con la beta de la nueva serie 358 vemos otro paso más para acercarnos a Wayland. Esta vez se han centrado en la interconexión con DRM/KMS, añadiendo el nuevo módulo nvidia-nomodeset para trabajar en tandem con el módulo del kernel, usádolo como base para la interface mode-setting provista por el administrador de renderizado directo del kernel. lamentablemente y aunque son muy buenas noticias, esto sigue siendo un paso más y aún tendremos que esperar un poco más para que Wayland sea una pieza central de nuestra distribución GNU/Linux, al menos en el caso de utilizar una gráfica de Nvidia. Por supuesto, éste no ha sido el único cambio que vemos en los nuevos controladores: Se ha corregido una regresión que afectaba al rendimiento de OpenGL en configuraciones de X server sin monitor. Se ha corregido una fuga de memoria que se producía cuando se destruía una ventana GLX que seguía teniendo el contexto asociado. Se ha corregido un error que provocaba la creación de buffers de píxeles de EGL en el buffer frontal y el posterior en lugar de hacerlo únicamente en el posterior, como requiere EGL. Se ha añadido un nuevo módulo de kernel, nvidia-modeset.ko. Este nuevo componente del driver funciona en combinación con el módulo nvidia.ko para programar el motor de visualización de la GPU. nvidia-modeset.ko no proporciona ninguna funcionalidad visible para el usuario, ni interfaces con aplicaciones de terceros. Sin embargo, en una versión futura, este módulo servirá de base para la interfaz de configuración del modo de pantalla (modesetting) proporcionada por el gestor de renderizado directo (DRM) del kernel. Se han reducido los parpadeos y los retardos en las transiciones hacia o desde el modo G-SYNC. Como parte de este cambio, a partir de ahora los monitores que tengan indicadores de G-SYNC en la pantalla indicarán que se encuentran en modo G-SYNC. El indicador visual de G-SYNC en OpenGL puede activarse en nvidia-settings para señalar cuándo se está utilizando G-SYNC. El protocolo GLX de la siguiente extensión de OpenGL 3.0 ha pasado de ser un protocolo no oficial a ser un protocolo aprobado para ARB: GL_EXT_draw_buffers2 El protocolo GLX para los siguientes comandos de OpenGL 3.0: BindBufferRangeNV BindBufferBaseNV BeginTransformFeedbackNV EndTransformFeedbackNV GetTransformFeedbackVaryingEXT TransformFeedbackVaryingsEXT que forman parte de las siguientes extensiones: GL_NV_transform_feedback GL_EXT_transform_feedback ha pasado de ser un protocolo no oficial a ser un protocolo aprobado para ARB. Con los cambios anteriores, el protocolo GLX para OpenGL 3.0 ha pasado de ser un protocolo no oficial a tener la categoría de protocolo oficial para ARB. Se ha añadido un nuevo mecanismo de asignación de memoria para asignaciones de gran tamaño en el controlador de OpenGL. Este mecanismo permite liberar la memoria asignada al proceso cuando no se utiliza, lo que deja más espacio de direcciones virtuales disponible para la aplicación. Está activado de forma predeterminada en aplicaciones OpenGL de 32 bits con Linux 3.11+ y glibc 2.19+. La memoria asignada de esta manera consume espacio en /dev/shm. Esta función se inhabilita configurando la variable de entorno __GL_DevShmPageableAllocations con el valor 2. https://devtalk.nvidia.com/default/topic/884727/linux-solaris-and-freebsd-driver-358-09-beta-/?offset=1
  11. Hace muy poco hablamos del lanzamiento de la nueva serie de controladores privativos de Nvidia y de cómo iba a suponer un gran cambio en cuanto a cómo se compilan y construyen los módulos del kernel. Hay ha sido liberada la primera beta y, además de lo que ya sabíamos, con ella han llegado grandes novedades. El soporte a EGL está totalmente acabado y se añade como "experimental, lo que nos hace estar a un paso de poder disfrutar de Wayland con soporte oficial por parte de Nvidia. Además, ya se dejan ver algunas librerías "sospechosas" como puede ser libnvidia-egl-wayland.so. Las mejoras para vdpau ocupan el tercer lugar en la lista de novedades destacadas de esta serie: Se ha corregido un error por el que los datos de nivel de textura podían sobrescribir los del nivel inmediatamente inferior en vistas que no incluyesen el más alto de los dos niveles. Se ha corregido un error que podía provocar el bloqueo del panel de control de nvidia-settings al actualizar la disposición de pantallas. Se han corregido algunos informes erróneos sobre el soporte de las extensiones GLX: según los informes, era posible usar algunas extensiones para renderizado GLX indirecto, cuando en realidad solo se admiten para renderizado directo. Se ha añadido soporte para las siguientes extensiones de EGL:EGL_KHR_swap_buffers_with_damage EGL_NV_stream_consumer_gltexture_yuv Se ha sustituido el sistema de compilación de los módulos de kernel de NVIDIA y se han actualizado el paquete de instalación y el programa nvidia-installer de forma que utilicen el nuevo sistema de compilación y organización del código fuente de los módulos. Para obtener más información sobre el nuevo sistema de compilación y organización del código, consulta el archivo README en la dirección:ftp://download.nvidia.com/XFree86/packaging/linux/new-kbuild-for-355/ Se ha añadido a EGL soporte completo de OpenGL de forma experimental. Se ha marcado la opción DeleteUnusedDP12Displays como obsoleta.La versión 1.5.0 de la especificación de RandR (Resize and Rotate) de X contiene una nota por la que las salidas generadas de forma dinámica no se destruyen. Por tanto, esta opción ha quedado obsoleta y se suprimirá en futuras versiones del controlador. Se ha añadido soporte para los perfiles de VDPAU incorporados a VDPAU 0.9:VDP_DECODER_PROFILE_H264_BASELINE VDP_DECODER_PROFILE_H264_CONSTRAINED_BASELINE VDP_DECODER_PROFILE_H264_EXTENDED VDP_DECODER_PROFILE_H264_PROGRESSIVE_HIGH VDP_DECODER_PROFILE_H264_CONSTRAINED_HIGH Se ha corregido un error que impedía a más de una salida de RandR compartir modos añadidos por el usuario. Se ha corregido un error por el cual, al usar Xinerama, no se tenían en cuenta los intervalos de intercambio (swap) especificados en la aplicación para algunas pantallas. Se ha corregido un error por el que los modos de RandR suministrados por el usuario con combinaciones imposibles de los indicadores +HSync, -HSync, +VSync y -VSync dañaban la lista de modos. Se ha añadido la posibilidad de convertir un contexto de OpenGL (de la versión 3.0 adelante) en el contexto actual sin vincularlo a un objeto dibujable (drawable). https://devtalk.nvidia.com/default/topic/862392/unix-graphics-announcements-and-news/linux-solaris-and-freebsd-driver-355-06-beta-/
  12. RebeccaBlackOS, la distribución GNU/Linux que lleva el nombre de la artista que se hizo famosa por su amor por los viernes, ha crecido desde aquel día que apareció por la blogosfera linuxera como una especie de broma al nivel de Biebian o Hannah Montana linux, pero que se ha ganado un puesto de honor entre las distribuciones GNU/Linux al ser a día de hoy el Live que nos muestra de manera más clara de lo que el servidor gráfico wayland puede ofrecernos, manteniéndose siempre al día con los avances de éste y con muchos de los entornos gráficos que lo han acogido. Entre los entornos y compositores soportados e incluidos tenemos: Escritorio de ejemplo basado en Weston Orbital Hawaii Papyros Gnome-shell Enlightenment E19 Orbment tiling Wayland DE Versión preliminar de KDE (no del todo funcional) En cuanto a librerías, toolkits y aplicaciones: Clutter SDL GTK QT EFL/Elementary FreeGLUT GLFW mpv gstreamer Aplicaciones nativas de KDE Frameworks Suite ofimática Calligra Una forma simple sencilla y actualizada de probar Wayland y estar al tanto de sus avances en espera que no tardemos mucho más en verlo como servidor gráfico por defecto en nuestra distribución de cabecera. Capturas Descarga x86 http://sourceforge.net/projects/rebeccablackos/files/2015-06-05/RebeccaBlackOS_i386.iso x86_64 http://sourceforge.net/projects/rebeccablackos/files/2015-06-05/RebeccaBlackOS_amd64.iso Web http://sourceforge.net/projects/rebeccablackos
  13. Durante ACM ITS (ACM Interactive Tabletops and Surfaces) que se está celebrando en Dresden, Alemania, hemos podido conocer, de la mano de los desarrolladores de NEMO-UX un shell interactivo futurista apodado "NEMOSHELL" y cuyo corazón no es otro que el servidor gráfico Wayland El sistema de ventanas NEMOSHELL soporta múltiples dispositivos y usuarios al mismo tiempo, ya sean paneles táctiles, ratones o lo que sea. Por supuesto es capaz de lidiar con todo lo que pueda correr sobre Wayland y, para esos casos en los que no, está XWayland La inspiración de estos Koreanos, según ellos mismos admiten, son las películas de ciencia ficción y de su deseo de hacer realidad la experiencia de usuario que se muestra en ellas ha nacido su proyecto. Y creo que más que explicaciones y ya que estamos demasiado lejos como para sentirlo, lo suyo es que veamos de qué se trata y les aviso que mejor tener una fregona a mano
  14. El XDC2014 nos está dejando grandes cosas y una de ellas es la conferencia de Nvidia en donde por fin nos han dejado claros sus planes de futuro de cara al nuevo servidor gráfico Wayland. Andy Ritger hizo públicos en Bordeaux los futuros planes que tiene la empresa de cara al futuro centrándose en algo que hasta ahora había sido una gran incógnita a la par que un secreto a voces. Dichos planes parten de lo que ya venían incorporando las últimas versiones de sus controladores, el cada vez mejor soporte para EGL en detrimento de GLX. Actualmente trabajan en el soporte a la infraestructura KMS (Kernel Mode-Setting), permitiendo así que su implementación de EGL opere fuera de X11, además de proponer algunas extensiones avanzadas de EGL que podrían hacer la transición más fácil para todos. Los Blobs de Nvidia actualmente no están utilizando directamente la API KMS, pero su código de visualización está trabajando registrarse con DRM y para que su controlador para el kernel soporte el uso de KMS ioctls. Con esto, mientras hacen uso de su propia implementación de KMS permiten la compatibilidad con DDX, dejando vía libre a otros clientes KMS para utilizar directamente el controlador de Nvidia. Lo que está tomando tanto tiempo no es realmente esta parte sino el conseguir implementar todas estas mejor sin que eso afecte a otras de sus tecnologías como G-Sync, FrameLock, Stereo, o el renderizado SLI. La serie de controladores 346.xx y su implementación EGL, completamente funcional sin necesidad de X11, son la punta de la lanza, aunque aún tardaremos un tiempo en ver su versión personalizada de KMS terminada. Uno de los puntos a destacar es que mientras los controladores libres Mesa hacen uso de GBM (Generic Buffer Manager), Nvidia propone un enfoque más generalizado para lidiar con los buffers utilizando EGLStreams. Aunque sin una fecha clara, son noticias esperanzadoras y probablemente el empujón definitivo que necesitamos para dejar por fin atrás el vetusto X11 y empezar a pensar en servidores gráficos más acordes a las exigencias actuales. Wayland está a punto de llegar, y esta vez de verdad, no como lo que venimos oyendo desde hace unos años, así que dentro de poco nos tocará ponernos las pilas para lidiar con una nueva transición (y van...) que supondrá un gran paso adelante para el sistema del Ñu y el Pingüino http://www.x.org/wiki/Events/XDC2014/XDC2014RitgerEGLNonMesa/nvidia-and-compositors.pdf
  15. Los rumores finalmente han resultado ser ciertos. Aunque nos han tenido en vilo hasta el último minuto finalmente la versión final de Enlightenment 0.19 (E19) ha visto la luz... un día tarde. Aún con la demora, que teniendo en cuenta lo que suelen demorarse los lanzamientos de Enlightenment es casi como si hubiera salido antes de tiempo , E19 llega con muchísimas mejoras, un completo rediseño de su motor de composición y lo más destacado, soporte completo para Wayland actuando como su propio compositor para éste al margen de Weston (lo sé, lo sé, me repito más que el ajo ). Innumerables mejoras y detalles que nosllevaría toda la tarde enumerar pero sin perder la esencia "beauty at your fingerprints" que tanto nos ha cautivado a los que descubrimos este entorno hace tiempo y que seguro no dejará indiferentes a los que lo hagan ahora. E19 ha llegado, para sorprendernos, ilusionarmos y darle vida a nuestro escritorio como nunca antes lo había hecho... pero ahora mismo no puedo seguir de cháchara, tengo paquetes que compilar, entornos que instalar.... así que ya daré mi veredicto más tarde Eso sí, no se olviden que aunque aún no está puesta al día dado el reciente lanzamiento, los más aventureros tienen a mano la guía de personalización nunca escrita de Enlightenment https://phab.enlightenment.org/phame/live/3//post/e19_release/
  16. Así es, Enlightenment, que estuvo más de 10 años en desarrollo antes de ver su primera versión estable, ha anunciado la primera alpha del próximo E19, que llega incluso antes de lo esperado, recordemos que entre Enlightemnt 0.17 y 0.18, que salió el pasado Diciembre, transcurrió todo un año y ahora, apenas unos meses después ya estamos en vísperas de un nuevo lanzamiento. E19 incorpora numerosas mejoras, entre las que destacan un compositor que ha sido totalmente rescrito e incorporado en el núcleo del entorno. Además se ha potenciado el soporte para el servidor gráfico Wayland y ahora Enlightement funciona como su propio compositor para el mismo. El administrador de archivos también ha recibido mejoras, Gstreamer 1.0 es el encargado de la previsualización del contenido multimedia, se añade soporte para la extensión XPRESENT para eliminar la sobrecarga debida a la composición... Sin duda un gran lanzamiento de este proyecto que empezó como un modesto gestor de ventanas y que va camino de convertirse en uno de los entornos gráficos libres que habremos de tener muy en cuenta en el futuro. http://anzwix.com/a/Enlightenment/V019Alpha https://phab.enlightenment.org/phame/live/3/post/e19_alpha1_it_s_happening/
  17. Hace apenas una semana Wayland era propuesto para Fedora 21 y ya tenemos la confirmación: https://lists.fedoraproject.org/pipermail/devel/2014-May/199045.html La andadura de Wayland comienza por fin y Fedora 21 será la distribución mayor que, con Gnome 3.14, dará el primer paso para que el novedoso servidor gráfico sustituya por fin al vetusto X11 que tantos años nos ha acompañado. Ahora sólo queda saber ¿Tendrán Nvidia y AMD sus controladores listos para este acontecimiento que tendrá lugar en el último trimestre del año? https://fedoraproject.org/wiki/Changes/Wayland#Current_status
  18. Después de mucho tiempo de desarrollo podríamos estar ante la primera gran implementación de Wayland en una distribución "mayor" de GNU/Linux y, como no, no podía ser otra que Fedora. Aunque disponible a día de hoy en muchas distros de manera experimental y en algunas menos conocidas y más modestas a modo de prueba de concepto, el hecho de contar con Gnome 3.14 para la próxima versión de Fedora, cuya compatibilidad con el nuevo servidor gráfico para GNU/Linux que está muy adelantado en este sentido y los flecos que aún quedan también tratarán de solventarlos durante el desarrollo. En el mismo hilo de discusión también se deja claro que esto no significará el destierro de las Xs sino que éstas seguirán siendo una posibilidad más a la hora de iniciar sesión y trabajar de manera gráfica. No obstante, aún quedan algunas dudas importantes que resolver en lo que concierne a la compatibilidad de los controladores gráficos de las grandes compañías de Hardware, Nvidia y AMD, que si bien han hecho algunos movimientos en este sentido aún se encuentran lejos de ofrecer soporte completo para Wayland https://lists.fedoraproject.org/pipermail/devel/2014-April/198689.html https://fedoraproject.org/wiki/Changes/Wayland
  19. Nvidia sigue con buen ritmo sacando nuevas versiones de sus controladores privativos para GNU/Linux. En esta ocasión tenemos ya disponible la primera beta de la serie 337, la versión 337.12, que además de incluir soporte para las nuevas gráficas de la serie Geforce 800M y algunas nuevas gráficas de la anterior serie 700, sigue mejorando el soporte para EGL, que posteriormente dará paso al soporte completo para Wayland. Además, esta nueva serie permite jugar con las frecuencuias del reloj de la GPU y la Memoria de la tarjeta gráfica, algo que algunos recordarán de algunas versiones de antaño, pero adaptado a los nuevos tiempos y las series más recientes de tarjetas gráficas de la compañía. Y sí, están preparados para funcionar con las versiones más recientes de Linux sin necesidad de ningún tipo de parche Cambios destacados Se añade soporte para las siguientes GPUs:GeForce 830M GeForce 840M GeForce 845M GeForce GTX 850M GeForce GTX 860M GeForce GTX 870M GeForce GTX 880M GeForce GT 705 GeForce GT 720 Corregido un bug que podía causar cuelgues al trabajar con aplicaciones OpenGL en condiciones en las que hay poca memoria disponible. Actualizado la pantalla de configuración de nvidia-settings para identificar inequívocamente los monitores DisplayPort 1.2 mostrando la GUIDs de los mismos. Se corrige un bug que hacía que las opciones ECC se mostraran de manera incorrecta en nvidia-settings en sistemas multi-gpu. Se elimina la opción "OnDemandVBlankInterrupts" se las opciones de configuración de las Xs Se corrige un bug que impedía levantar varios servidores Xs simultáneamente en sistemas UEFI. Se añade la posibilidad de hacer over/under-clock para gráficas de las series 400 o superiores habilitando la opción "CoolBits" en la configuración de las Xs. Los requisitos mínimos para Nvidia-settings se elevan, siendo necesario GTK+ 2.4 en lugar de la versión 2.2 requerida hasta ahora. Se reduce la utilización de la CPU y la memoria de la GPU de los drivers EGL. Se añaden nuevas extensiones EGL:- EGL_EXT_buffer_age; - EGL_EXT_client_extensions; - EGL_EXT_platform_base; - EGL_EXT_platform_x11. La opción "Clone" ha sido renombrada a "SamePositionAs" en la configuración "MetaModeOrientation" de las Xs (únicamente se refiere a posición, no a resolución). Lista completa de cambios www.nvidia.com/download/driverResults.aspx/74888/es-Es Descarga Linux x86 http://us.download.nvidia.com/XFree86/Linux-x86/337.12/NVIDIA-Linux-x86-337.12.run Linux x86_64 http://us.download.nvidia.com/XFree86/Linux-x86_64/337.12/NVIDIA-Linux-x86_64-337.12.run Linux ARM_32 http://es.download.nvidia.com/XFree86/Linux-x86-ARM/337.12/NVIDIA-Linux-armv7l-gnueabihf-337.12.run FreeBSD x86 http://es.download.nvidia.com/XFree86/FreeBSD-x86/337.12/NVIDIA-FreeBSD-x86-337.12.tar.gz FreeBSD x86_64 http://es.download.nvidia.com/XFree86/FreeBSD-x86_64/337.12/NVIDIA-FreeBSD-x86_64-337.12.tar.gz Solaris x86/x86_64 http://es.download.nvidia.com/solaris/337.12/NVIDIA-Solaris-x86-337.12.run
  20. Justo un año después de la salida de la primera versión estable del entorno gráfico enlightenment 0.17 y que estuvo más de 10 años en desarrollo nos llega la versión 0.18 con sustanciales mejoras pero sin alejarse demasiado de la experiencia ofrecida por la anterior E17. El aumento de velocidad en el desarrollo de enlightement nos deja también noticias sobre la próxima E19 cuyo desarrollo empezaría inmediatamente y de la que podremos ver algunas de sus novedades a principios del año que viene cuando la versión 1.9 de las librerías EFL llegue hasta nosotros. Las novedades de E18 no son pocas y nos va a faltar tiempo para nombrarlas todas: Para empezar, las librerías propias de este entorno que llevan el nombre de EFL han sido actualizadas y mejoradas y ahora forman parte de un único paquete compacto que incluye numerosas novedades Soporte completo para Wayland 1.3 listo para usarlo en el día a día y que será llevado aún más allá para la versión 0.19, la que actuará como un compositor independiente para el servidor gráfico sin ninguna dependencia con Weston. Evas Generic Loader puede cargar (previsualizar) ahora documentos comunes valiéndose de Libreoffice además de archivos de audio, vídeo e imágenes. Por defecto, Evas trabajara en modo asíncrono, lo que significa reducción de la caída de frames y parpadeos, permitiendo al mismo tiempo hacer posible el uso de múltiples núcleos de la CPU Soporte para Audio a través de Ecore A través de EO, Ecore Audio hace es usado por Edje para proveer efectos de sonido a los temas de archivos. Mejoras en la integración con SytemD y udisks2 Se han integrado los temas internos a elementary El motor de composición del administrador de ventanas ha sido reconstruido y ahora forma parte del núcleo de Enlightenment, aportando mayor ligereza y estabilidad si cabe. Se han añadido nuevos módulos oficiales Teamwork Music-control - Control de la la biblioteca multimedia Bluez4 - Control de los opciones Bluetooth Appmenu - Control los menús de aplicaciones DBus Conf_comp - Control de las opciones del compositor Además, Terminology ha alcanzado la versión 0.4. Este nuevo y prometedor emulador de terminal de Enlightenment escrito desde cero usando las librerías EFL cuenta con interesantísimas características, algunas de ellas distan mucho de lo que cabría esperar de una terminal, pues van más allá de lo que solemos ver en este campo. Tomando prestada la frase de despedida del anuncio final sólo me queda decir que dejes de perder el tiempo y si aún estás leyendo esto, deja lo que tengas entre manos y empieza a descargar y disfrutar del nuevo Enlightenment 0.18. Los que no lo hayan hecho ya https://phab.enlightenment.org/phame/live/3/post/enlightenment_dr_0_18_0_release/
  21. Aunque fue algo que ya se comentó en el pasado XDC, Nvidia ha querido dejar claro su compromiso con EGL, necesario para el soporte del nuevo servidor gráfico Wayland, dando una breve aunque interesante conferencia al respecto durante el XDC2013 que se está celebrando ahora mismo en Portland. James Jones ha sido el maestro de ceremonias en esta ocasión y, si bien es un tema un poco pesado para los profanos en la materia (como un servidor ), para aquellos que tengan curiosidad y/o no tengan problemas con la lengua de Shakespeare, seguramente resulte muy interesante. Aparte del vídeo de la conferencia, podremos obtener el pdf con las diapositivas mostradas en la misma: www.x.org/wiki/Events/XDC2013/XDC2013JamesJonesEGLDevices/EGLDevice.pdf
  22. SolusOS, para aquellos que no la conozca, es una distribución que se propuso en un principio el objetivo de tener un sistema GNU/Linux con aspecto "Gnome Clásico", pero aprovechando las bondades de Gnome 3, bien pulido, sobre Debian Testing, además de incluir paquetes actualizados para ciertas aplicaciones/librerías en sus repositorios. Conforme ha ido avanzando su desarrollo la distribución ha ido evolucionando y, dada la trayectoria que ha seguido Gnome, ha pasado de querer ofrecer una experiencia Gnome "clásica" a intentar crear su propio entorno de escritorio Consort Desktop y mientras eso ocurre, a día de hoy ofrece XFCE como escritorio predeterminado en sus versiones preliminares, a la espera de poder ofrecer por fin Consort Destop. En lo que respecta a paquetería también han cambiado muchas cosas y actualmente se encuentra utilizando una adaptación del sistema de paquetería Pisi. Con Wayland a punto de llegar y con todos los entornos y distribuciones preparándose para tal acontecimiento, la gente tras SolusOS ha tomado una importante decisión, como ya hicieron otros entornos recientemente, y no es otra que abandonar definitivamente gtk y pasarse a QT. Los motivos, los mismos que ya hemos escuchado en más de una ocasión, mientras QT avanza como un Framework completo que permite realizar cualquier cosa, GTK, por el contrario, es sólo un Toolkit que requiere una gran cantidad de librerías para hacer cualquier cosa. Por supuesto también lo que todos ya sabemos que es que GTK2 está descontinuado y GTK3 no es una alternativa atractiva a la que migrar. El líder del proyecto,Ikey, en un hilo oficial en el foro de SOlusOS no sólo ha anunciado el cambio, sino que ha puesto un plazo de 3 semanas en las que será presentado el nuevo entorno independiente Consort Desktop, sobre QT5, con soporte para Wayland, compositor y login manager propios, indicadores de red y audio, soporte básico para extensiones/plugins y un tema consistente en el que encajen bien tanto aplicaciones QT como Gtk+ Además, se hace una pequeña mención hacia el proyecto Maui, con el que quizá, podrían llegar a colaborar aunque sus objetivos coinciden a la vez que divergen en muchos puntos, por lo que no podemos tomárnoslo como algo más allás de un simple comentario. http://forums.solusos.com/thread-4160-post-28329.html
  23. Durante el último año se han sucedido las novedades en torno al nuevo servidor gráfico que irrumpió en el panorama linuxero y que tanto ha dado de que hablar desde que fuera anunciado hace 2 años hasta su recientemente lanzada versión final, a la que han sucedido numerosas versiones que han añadido nuevas caractarísticas, corregido errores y nos acercan cada vez más a una adopción de esta nueva y prometedora tecnología que esperamos disfrutar muy pronto en nuestros sistemas GNU/Linux. Si bien casi todos los entornos gráficos se han puesto las pilas para dar soporte completo a Wayland lo antes posibles, la gente de Enlightenmente, con sus librerías EFL han apostado desde el principio por Wayland, cuyo soporte comenzó por E17, siguió con E18, que a día de hoy es el entorno más avanzado en este aspecto y ahora, prometen no sólo seguir en la misma línea, sino ir aún más allá con E19, que empezará a desarrollarse a partir de la salida de E18 que ocurrirá este mismo año. Para demostrar de lo que será capaz E19, del que ya sabemos que contará con su propio compositor para Wayland, ha nacido el "Proyecto Burrito", que será presentado durante la LinuxCon Europe que se celabrará en Octubre en Edinburgo. Supongo que se estará preguntanddo qué es el Proyecto burrito. Pues bien, se tratará de una demo técnica que nos sorprenderá con todo lo que es capaz de hacer Enlightenment y las grandes novedades que nos esperan para E19. Como es eviente que muchos están ansiosos y seguramente no puedan esperar hasta Octubre para saber de qué se trata exactamente, sus desarrolladores nos han dejado un boceto preliminar de lo que será mostrado durante la conferencia del LinuxCon Creo que sobran las palabras, se ve con bastante claridad hacia dónde va encaminado el proyecto http://e19releasemanager.wordpress.com/
  24. El popular Fork del extinto Gnome 2 quiere seguir en la brecha y durante la conferencia OpenSUSE realizada en Grecia han confirmado que dicho entorno gráfico contará con soporte para Wayland, systemd, librerías gtk3, Gstreamer 1.0 y otras novedades, que hasta ahora sólo iban a aparecer para Gnome 3 Para más detalles de lo que nos espera en la próxima versión 1.8, podemos consultar el roadmap e Mate en su wiki oficial: http://wiki.mate-desktop.org/roadmap
  25. No han pasado más que un par de horas desde que la versión 1.0 de Wayland ha sido lanzada y ya tenemos un nuevo proyecto a la vista, un nuevo compositor basado en QT llamado Green Island. El nombre de este compositor no es casual, pues ha sido desarrollado especialmente para la distribución GNU/Linux Maui. Esta distribución Hawaiiana busca evitar los sistemas de paquetes tradicionales, el sistema provee una imagen mínima de Linux, systemd, connman y otras aplicaciones base. El entorno de escritorio y sus dependencias son compiladas a partir de una serie de repositorios git. Las aplicaciones son instaladas mediante paquetes. Green Island cuenta con su propio Shell, pero podría cargar otros shells utilizando plugins, como puede ser el que alguien ha desarrollado específicamente para tablets. En palabras del autor, piensa que debería crearse un Shell diferente en función del dispositivo y/propósito al que esté destinado, aprovechando así las ventajas y peculiaridades del compositor. Green Island https://github.com/h...top/greenisland Maui project http://www.maui-project.org/
×
×
  • Crear Nuevo...