Steam Audio ofrece una solución de audio espacial avanzada para juegos y aplicaciones de realidad virtual

Valve dio a conocer hace poco, mediante una publicación de blog, el anuncio de la liberación del código fuente de Steam Audio SDK y todos los complementos relacionados, con lo cual ahora los desarrolladores tienen la libertad de adaptar Steam Audio a sus necesidades específicas y utilizar versiones modificadas en diversos productos, incluidos los comerciales, sin tener que abrir el código fuente de los cambios realizados.

Este movimiento no solo abre nuevas posibilidades para la comunidad de desarrolladores, sino que también invita a los interesados en el desarrollo de Steam Audio a participar activamente en el proyecto, pues ahora tienen la oportunidad de contribuir con sus propios cambios y mejoras al proyecto, lo que puede mejorar aún más la plataforma y adaptarla a una variedad de aplicaciones y escenarios.

Nos complace anunciar que con la última versión de Steam Audio , el código fuente completo del SDK de Steam Audio ahora está disponible como código abierto. Con este lanzamiento, nuestro objetivo es brindar más control a los desarrolladores, lo que conducirá a mejores experiencias para sus usuarios y, con suerte, contribuciones valiosas a la comunidad más amplia de desarrolladores que utilizan Steam Audio.

Esto se produce después de recibir muchos comentarios y contribuciones valiosos de la comunidad a los complementos que ya están disponibles como código abierto (Unity, Unreal y FMOD Studio), y queremos llevar esos mismos beneficios al SDK principal.

Se menciona que a pesar de esta apertura, Valve continuará apoyando y desarrollando Steam Audio como lo ha hecho hasta ahora, manteniendo su compromiso con la calidad y la innovación en el campo del audio. Además, Steam Audio seguirá siendo compatible con una amplia gama de plataformas, incluidas Linux, Windows, macOS, Android e iOS, lo que garantiza su accesibilidad y utilidad en una variedad de entornos de desarrollo y aplicaciones.

Para quienes desconocen de Steam Audio, deben saber que ofrece una serie de herramientas poderosas para trabajar con sonido envolvente 3D en diversas aplicaciones, incluidos los juegos de computadora y los sistemas de realidad virtual. Su capacidad para simular entornos sonoros realistas, teniendo en cuenta la posición del oyente, el movimiento de la cabeza, la distancia desde la fuente de sonido y otros factores, es fundamental para crear una experiencia de audio inmersiva y adaptativa.

Finalmente, cabe mencionar que el código está escrito en C++ y publicado bajo la licencia Apache 2.0 y si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/MHWAar1
via IFTTT

Skia es una biblioteca de gráficos 2D de código abierto

En el mundo del desarrollo de navegadores web y entornos de escritorio, la optimización y el rendimiento son una de las características más demandadas por parte de los usuarios y es que estos son aspectos críticos que influyen directamente en la experiencia del usuario y unos de los principales factores al momento de elegir un navegador web.

En este contexto, los equipos de desarrollo detrás de WPEWebKit y WebKitGTK (el motor de navegador utilizado en navegadores como Safari y Epiphany/GNOME Web), han incorporado la capacidad de utilizar la biblioteca Skia para el renderizado de gráficos 2D.

Durante los últimos años, los desarrolladores de WebKit han estado trabajando arduamente para mejorar el rendimiento gráfico de WebKitGTK y WPEWebKit. Aunque se han implementado características como el renderizado por subprocesos y VSync, y quedó claro que el renderizador 2D basado en CPU había alcanzado sus límites en términos de rendimiento y eficiencia. Se menciona que exploraron diversas opciones antes de optar por Skia. Los intentos de agregar capacidades de renderizado de GPU 2D a la biblioteca Cairo, utilizada por WebKitGTK, no tuvieron éxito debido a limitaciones en la arquitectura de la biblioteca. Además, un proyecto para desarrollar una biblioteca de renderizado personalizada se abandonó debido a las dificultades para lograr un equilibrio entre el rendimiento y la calidad del renderizado.

Hubo un intento de hacer que Cairo admitiera la renderización de GPU, lo que no funcionó particularmente bien debido a que la biblioteca estaba diseñada en torno a una operación con estado basada en el modelo PostScript, lo que resultó en una API conveniente y familiar, con una excelente calidad de salida, pero difícil de reorientar y con algunos casos de esquina particularmente lentos. Mientras tanto, otros motores web han trasladado más trabajo a la GPU, incluido el renderizado 2D, donde muchas operaciones son considerablemente más rápidas

Aunque la idea de utilizar Skia inicialmente fue rechazada debido a problemas con la estabilidad de la API, su uso como dependencia externa y la necesidad de mantener un módulo de terceros en WebKit, finalmente se consideró como la solución óptima para mejorar el rendimiento del renderizado gráfico en WebKitGTK.

Skia es una biblioteca de gráficos utilizada en varios productos de Google, como Chrome, Firefox, ChromeOS, Android y Flutter. Esta adición permite el renderizado con el uso de la GPU, lo que puede mejorar significativamente el rendimiento de la representación gráfica.

La migración hacia Skia fue realizada por Igalia como parte de una iniciativa para optimizar el rendimiento de WebKitGTK para GNOME. Se menciona que el motivo principal detrás de esta migración fue alcanzar un límite en el proceso de optimización del rendimiento de renderizado 2D utilizando la CPU. Utilizar la GPU proporciona una capacidad adicional para mejorar el rendimiento de la representación gráfica.

El proceso de transición a Skia comenzó con pruebas internas en diciembre de 2023 y los resultados iniciales fueron impresionantes, ya que de primer momento se observaron mejoras significativas en el rendimiento, especialmente en el escritorio. A medida que avanzaban las pruebas, se hizo evidente que Skia no solo ofrecía un rendimiento superior, sino que también simplificaría el código y abriría la puerta a nuevas funcionalidades.

En febrero de 2024, tras un intenso período de desarrollo y pruebas, la implementación de Skia alcanzó un estado «upstreamable», lo que significa que estaba listo para ser integrado en WebKitGTK y WPEWebKit de manera pública, con lo cual la respuesta inicial de la comunidad de desarrolladores fue positiva, lo que marcó un hito importante en el proceso de transición.

El equipo se compromete a futuro a continuar mejorando la implementación de Skia en WebKitGTK y WPEWebKit, con planes de optimizar aún más el rendimiento y la eficiencia del renderizado de GPU. Aunque actualmente el enfoque está en el port WPE, se espera que otros ports, como GTK, también reciban soporte de Skia en el futuro.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlacé.

from Linux Adictos https://ift.tt/ZzJ7PTo
via IFTTT

Las vulnerabilidades afecta a los dispositivos Android, ChromeOS y Linux que se conectan a redes WiFi

Hace poco se dio a conocer la noticia de que fueron identificadas dos nuevas vulnerabilidades en los paquetes de software de código abierto Wifi de Linux que permiten a los atacantes engañar a las víctimas para que se conecten a redes clonadas (FakeAP imitando al original) e intercepten su tráfico.

Las vulnerabilidades descubiertas fueron detectadas en los paquetes IWD (Intel inet Wireless Daemon) y wpa_supplicant, los cuales se utilizan para gestionar la conexión de sistemas cliente Linux a redes inalámbricas.

Naturaleza de las vulnerabilidades : dos ataques de omisión de autenticación en redes WPA2/3 modernas: uno contra usuarios que se conectan a Enterprise WiFi y el otro contra redes WiFi domésticas existentes .

Impacto:

wpa_supplicant: permite a un atacante engañar a una víctima para que se conecte a un clon malicioso de una red WiFi empresarial y posteriormente interceptar su tráfico.

IWD: permite a un adversario obtener acceso no autorizado a una red WiFi doméstica protegida, exponiendo a los usuarios y dispositivos existentes a ataques.

En el caso de IWD, la vulnerabilidad (catalogada bajo CVE-2023-52161) se manifiesta únicamente cuando se habilita el modo de punto de acceso, que no es una configuración habitual para IWD, diseñado principalmente para conectarse a redes inalámbricas. Esta vulnerabilidad permite conectarse a un punto de acceso creado sin necesidad de conocer la contraseña, por ejemplo, cuando un usuario proporciona acceso a la red a través de su dispositivo (hotspot).

Se menciona que la vulnerabilidad se origina en la falta de verificación del orden de los pasos durante la negociación de la conexión inalámbrica. Esta negociación se basa en un canal de comunicación de 4 pasos al conectarse por primera vez a una red inalámbrica segura. El problema radica en que IWD acepta mensajes para cualquier etapa de esta negociación sin verificar si se ha completado la etapa anterior.

Por ejemplo, un atacante puede omitir el envío del mensaje de la segunda etapa y enviar directamente un mensaje de la cuarta etapa, evitando así la etapa en la que se verifica la autenticación. Al procesar este mensaje de la cuarta etapa sin la verificación adecuada, la clave PTK se establece en cero. Con esto, el atacante puede calcular el código MIC (Código de Integridad del Mensaje) utilizando un PTK nulo, y el IWD aceptará este código de verificación como válido.

Como resultado, el atacante completa esta negociación parcial de la conexión y obtiene acceso total a la red inalámbrica, ya que el punto de acceso recibirá las tramas que envíe cifradas con una clave PTK nula. Cabe mencionar que este problema fue solucionado en la versión 2.14 de IWD.

Por otro lado, en wpa_supplicant la vulnerabilidad (CVE-2023-52160) permite a un atacante atraer a un usuario a una red inalámbrica ficticia, actuando como un clon de la red a la que el usuario pretende conectarse. Esta falla en la implementación del protocolo PEAP permite al atacante omitir la segunda etapa de autenticación al conectar un dispositivo de usuario mal configurado, lo que facilita la creación de un clon falso de una red Wi-Fi confiable. Este problema afecta a redes con WPA2-Enterprise o WPA3-Enterprise que utilizan el protocolo PEAP.

Sobre esta vulnerabilidad se menciona que para llevar a cabo con éxito un ataque en wpa_supplicant, primero se deben cumplir algunas condiciones:

1. Verificación del certificado TLS del servidor deshabilitada: El usuario debe deshabilitar la verificación del certificado TLS del servidor en su configuración de wpa_supplicant. Esta es una configuración peligrosa que permite al atacante engañar al cliente para que se conecte a una red falsa.
2. Conocimiento del SSID de la red clonada: El atacante debe conocer el identificador de la red inalámbrica (SSID) de la red clonada. Esto le permite al atacante configurar una red falsa que imita la red legítima y engañar al cliente para que se conecte a ella.
3. Posicionamiento del atacante: El atacante debe estar dentro del alcance del adaptador inalámbrico de la víctima, pero fuera del alcance del punto de acceso de la red inalámbrica clonada. Esto significa que el atacante debe estar lo suficientemente cerca de la víctima para interceptar su tráfico, pero lo suficientemente lejos del punto de acceso legítimo para que el cliente elija la red falsa.
4. Tipo de red: El ataque es posible en redes que utilizan WPA2-Enterprise o WPA3-Enterprise que implementan el protocolo PEAP. Este protocolo se utiliza comúnmente en entornos empresariales y educativos para autenticar usuarios en redes inalámbricas seguras.

Los desarrolladores de wpa_supplicant consideran que el problema no es una vulnerabilidad, ya que solo se manifiesta en redes inalámbricas configuradas incorrectamente que utilizan autenticación EAP junto con PEAP sin verificar el certificado TLS del servidor. Para mitigar este problema, se ha lanzado un parche que añade un modo de paso obligatorio de la segunda fase de autenticación, además de comprobar el certificado TLS. Sin embargo, para abordar completamente la vulnerabilidad, los administradores de red deben configurar una cadena de confianza para verificar el certificado del servidor mediante el parámetro ca_cert.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/x2wPSMy
via IFTTT

Clem Lefebvre ha publicado el boletín de marzo de Linux Mint, correspondiente a lo que ha pasado en febrero de este 2024. En él no se ha hablado mucho del sistema operativo y se han tratado otros temas. El primero para lamentarse porque Google Adsense esté siendo cada vez más intrusivo, lo que les hace planterase hacer cambios o eliminar todos los anuncios en su página web. Luego han tratado otro tema más, en este caso una mala noticia de las que hacen bueno el refrán de que «no hay mal que por bien no venga».

HexChat lanzó su última versión en febrero. Fue una actualización que llegó para corregir errores y para despedirse de la comunidad. Linux Mint usa HexChat como cliente de IRC, y antes de eso usaba Xchat. Siempre han usado un cliente de este tipo de mensajería porque tienen incluido el servidor de soporte del proyecto, y allí se pueden resolver muchas dudas. Podrían hacerse cargo del desarrollo de HexChat como han hecho, por ejemplo, con Timeshift, pero sería demasiado trabajo y ya están mirando a un futuro con Jargonaut.

Linux Mint usaría Jargonaut como cliente IRC

HexChat estaba basado en GTK2 (vaya, yo que pensaba que sólo GIMP…), y deberían subirlo a GTK3, entre otras cosas, para que fuera compatible con HiDPI. Linux Mint necesita un cliente de IRC, y Jargonaut puede ser la apuesta ganadora. Aunque use IRC no será desarrollado como un cliente de IRC, y soportará pastebin e imgur vía DND, subir las especificaciones del sistema, problemas y muchas funciones que no están disponibles en un cliente IRC normal. Por otra parte, no permitirá unirse a canales ni usar comandos IRC.

Un cliente IRC que no es cliente IRC. Eso será.

Jargonaut será una XAPP, es decir, una aplicación de Linux Mint como el mencionado Timeshift u otras como Warpinator o el gestor de aplicaciones web. Quedarán especialmente en el sistema operativo con sabor a menta, pero se podrán usar en otras distribuciones. Probablemente la suban a Flathub cuando esté lista, aunque quizá no merezca la pena fuera de Linux Mint.

from Linux Adictos https://ift.tt/Z0oAVRN
via IFTTT

Hace unos instantes publicábamos la mala noticia de que Yuzu y Citra dejaban de existir por la demanda impuesta por Nintendo. En el mismo artículo hablábamos de aquello de ponerle puertas al campo, y de que ya había usuarios que habían subido los emuladores en forma de fork a otros repositorios para que se pudieran seguir usando los emuladores más populares para Switch y 3DS. Ahora me acabo de enterar de que existe suyu, el resurgir de las cenizas de Yuzu. Y ha resucitado riéndose.

Al leer el nombre ya he notado cierto tufillo a cachondeo. Supuestamente, «yuzu» se lee «yusu», por lo que he pensado «uno era yusu y el otro suyu…», pero no. O no del todo. Más abajo podemos leer que suyu se pronuncia como «sue-you», lo que al español se traduciría como «te denuncio» en el sentido de llevarte a los tribunales. Y es que en la descripción también leemos que no van a hacer dinero «principalmente para que Nintendo no nos denuncie jajaja«.

suyu está disponible en GitLab

El repositorio original lo abrió Crimson-Hawk en GitHub hace unas 14 horas, pero lo primero que leemos allí es que se han movido a GitLab. También han abierto un nuevo Discord, y es que parte del acuerdo de los desarrolladores de Yuzy/Citra era que eliminaran todo su rastro, incluidos chats de este tipo.

«suyu, pronunciado sue-you, es la vida después de la muerte del emulador más popular, de código abierto, para Nintendo Switch, empezado por los creadores de Citra. Está escrito en C++ con la portabilidad en mente, y mantenemos builds para Windows, Linux y Android«.

Es probable que parte de su desarrollo esté en proceso, o esa es la impresión que da al ver su logotipo. También es posible que no hayan querido perder mucho tiempo en algo así por si Nintendo vuelve a las andadas.

No sabemos cómo acabará todo esto, pero sí podemos especular. Se esperaba que tras la muerte de estos emuladores salieran otros, pero no tan pronto. Si echamos una mirada atrás en el tiempo, a cuando para ver una película teníamos que usar software como aMule, y que los intentos por evitarlo lo único que han conseguido es que en la actualidad podamos verlo de manera más sencilla e incluso sin descargar nada, uno puede imaginar un futuro en el que al cortar dos cabezas aparezcan 14 más, como con Hydra.

ACTUALIZADO: al menos hay otra cabeza que ha crecido ya, aparte de los forks. Se llama nuzu.

El siguiente capítulo de esta serie ha llegado pronto, y habrá que esperar para ver como sigue. Coged palomitas.

from Linux Adictos https://ift.tt/EwmG54j
via IFTTT

Malas noticias para el mundo de los videojuegos. La emulación es un tema que puede generar y genera polémica. Por una parte, es la única manera de que, por poner un ejemplo, yo pueda jugar a títulos de Master System y Mega Drive, como Sonic o Cool Spot, juegos que tuve y ya no puedo jugar. En el otro lado tenemos casos como los de Yuzu y Citra, dos emuladores de consolas de Nintendo que siguen a la venta, y no sólo eso.

Fue noticia cuando «The Legend of Zelda: Tears of the Kingdom» llegó antes al PC que a la Switch. Es decir, pudimos jugarlo antes en un emulador que en la consola en donde, en teoría, debería vivir ese juego, sin posibilidad de jugarlo en otra plataforma. Esto ha sido la gota que ha colmado el vaso de Nintendo y lo ha usado en el juicio para eliminar de un plumazo a los emuladores Yuzu y Citra.

Nintendo y la piratería, historia de nunca acabar

Que Nintendo ha pasado y pasa mucho tiempo intentando que no podamos jugar ni al Super Mario Bros. si no es en una NES o en algún reboot propio no es nada nuevo. Pero una cosa es eso y la otra es lo que pasó con el último episodio de la saga Zelda: se habría descargado más de un millón de veces una semana antes del lanzamiento oficial. Yo, que no puedo engañar a nadie y a veces juego con RetroArch + ES-DE, veo ahí piratería en su máxima expresión.

Por un lado, es imposible que se te haya roto tu Switch y hayas comprado el nuevo juego. Lo primero, sí, posible, pero todo junto no: sin Switch no vas a comprar el juego. Tampoco se aplicaría otro punto positivo de la emulación, y es mantener una obra viva. No se puede devolver a la vida algo que ni siquiera ha nacido aún.

Así que todo esto ha sido la tormenta perfecta para Nintendo y lo ha aprovechado, lo que nos hace pensar en si no habrá sido el propio gigante de los videojuegos quien habría filtrado el juego para conseguir su objetivo.

Yuzu y Citra desaparecen de GitHub…

… y pronto lo harán sus páginas web y también sus páginas web. Cuando he empezado a escribir este artículo, al menos la página de Yuzu estaba accesible, pero ahora he intentado entrar a las páginas oficiales de Yuzu y Citra y ambas están «secuestradas» por un mismo mensaje. En él explican que Yuzu y Citra se van a descontinuar «con efecto inmediato».

Según sus palabras, empezaron de buena fe y siempre estuvieron en contra de la piratería, pero se han dado cuenta de que lo que han creado permite circunvalar las protecciones de Nintendo y eso se está usando para la piratería. Por lo tanto, deciden despedirse.

Otro de los problemas parece ser que sus creadores han estado ganando mucho dinero. Cuando la página de Yuzu estaba disponible, se podía ver que había disponible una versión «Early Access» de pago, y que con esto ganaban aproximadamente 30.000$ al mes.

Al final han aceptado dar por finalizado el proyecto y pagar una indemnización a de 2,4 millones de dólares a Nintendo. Es calderilla para una compañía de estas dimensiones, pero en realidad no es eso lo que han ganado. Lo que han conseguido es enviar un mensaje: cuidado con piratear juegos de Nintendo. Ahora la comunidad de videojuegos se lo tomará con más calma… o no.

Ya hay forks de los emuladores

Como ocurrió con youtube-dl en su día, poco tiempo después de la resolución judicial y de la desaparición de los emuladores ya hay forks de los mismos. No hay que olvidar que eran de código abierto y que cualquiera puede hacerlo, por lo que se pueden seguir descargando desde repositorios no oficiales. Y así seguirá.

Queda por ver cómo afecta todo esto a la emulación. Es posible que salga otro emulador que no se lucre y eso sea suficiente para que pueda seguir existiendo, que no tengamos ninguno nuevo hasta que las consolas dejen de fabricarse… habrá que ver.

Imagen: Montaje a partir de imagen generada con DALL-E

from Linux Adictos https://ift.tt/E1chGvq
via IFTTT

Agama, el nuevo instalador del proyecto SUSE

Los desarrolladores del proyecto openSUSE dieron a conocer hace pocos días información sobre la hoja de ruta para el desarrollo de su nuevo instalador llamado Agama (anteriormente D-Installer).

En la publicación se menciona que este nuevo instalador está siendo creado para reemplazar la interfaz de instalación clásica de SUSE y openSUSE y una de las características destacadas de Agama es su separación entre la interfaz de usuario y las partes internas de YaST.

Sobre Agama

El nuevo instalador en el que está trabajando openSUSE tiene como objetivo el utilizar varias interfaces, incluida una interfaz para gestionar la instalación a través de una interfaz web, otros de los objetivos del desarrollo de Agama que se mencionan son: la eliminación de las limitaciones existentes de la interfaz gráfica, la ampliación de la capacidad de utilizar la funcionalidad de YaST en otras aplicaciones y la liberación de ataduras a un lenguaje de programación (la API D-Bus permitirá la creación de complementos en diferentes idiomas) y fomentar la creación de entornos alternativos por parte de los miembros de la comunidad.

La interfaz básica de Agama para gestionar la instalación se construye utilizando tecnologías web e incluye un controlador que proporciona acceso a las llamadas D-Bus a través de HTTP, así como la propia interfaz web. Esta interfaz web está escrita en JavaScript utilizando el marco React y los componentes PatternFly. El servicio para enlazar la interfaz con D-Bus, así como el servidor HTTP integrado, están escritos en Ruby.

El equipo ha delineado una estrategia para este año y, a pesar de la fluidez de su desarrollo, el equipo está comprometido con un cronograma de lanzamiento constante para Agama con dos hitos importantes. El primero está previsto para mediados de abril y el otro hacia mediados de julio.

El hito de abril revolucionará la arquitectura de Agama. Se alejará de su dependencia de Cockpit hacia un marco más autónomo que se combina con una interfaz de usuario refinada que apunta a optimizar las configuraciones de almacenamiento.

El objetivo del segundo hito es mejorar la flexibilidad y las capacidades de Agama para instalaciones desatendidas, lo que busca posicionar a Agama como una formidable alternativa a AutoYaST .

En la etapa actual de desarrollo, el nuevo instalador ya proporciona las capacidades necesarias para resolver tareas como:

• Seleccionar un conjunto inicial de aplicaciones
• Capacidad de configurar una conexión de red idioma, teclado, zona horaria y configuración de localización
• Preparar un dispositivo de almacenamiento y particionarlo
• Agregar usuarios al sistema.

Para instalar paquetes, verificar equipos, particionar discos y realizar otras funciones necesarias para la instalación, Agama sigue utilizando las bibliotecas de YaST. Sobre estas bibliotecas, se implementan servicios de capa que abstraen el acceso a las mismas a través de una interfaz D-Bus unificada. El instalador emplea una arquitectura multiproceso que permite que la interfaz de usuario no se bloquee mientras se llevan a cabo otras tareas.

Se menciona que se han programado dos actualizaciones importantes de Agama para este año. La primera está prevista para mediados de abril y la segunda para mediados de julio. La actualización de julio se centrará en aumentar la flexibilidad y la funcionalidad asociadas con las instalaciones automatizadas y desatendidas. La actualización de abril se destaca por la interrupción del uso de los módulos ya preparados desarrollados por el proyecto Cockpit, en favor del uso de un marco más independiente y una interfaz de usuario modernizada.

Dejar de depender de Cockpit eliminará dependencias externas adicionales y eliminará las restricciones que han impedido la implementación de algunas ideas. Por ejemplo, Cockpit contiene componentes de lenguaje Python y C como dependencias, mientras que Agama utiliza lenguajes Ruby y Rust. Eliminar Cockpit también liberará a los desarrolladores de las limitaciones que encontraron al intentar implementar un modo de instalación automática y al rediseñar la interfaz de configuración de almacenamiento para lograr el equilibrio óptimo entre simplicidad para principiantes y funcionalidad para usuarios avanzados.

Para los interesados en poder probar el nuevo instalador Agama, se están creando compilaciones en vivo para las arquitecturas x86_64 y ARM64. Estas compilaciones admiten la instalación de una versión continuamente actualizada de openSUSE Tumbleweed, así como ediciones de SUSE ALP, openSUSE MicroOS y openSUSE MicroOS Desktop, construidas en contenedores aislados.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/FdCjzwk
via IFTTT

KDE lanzó el pasado miércoles aquello a lo que se refirieron como Mega-Lanzamiento KDE 6. Dejemos clara una cosa: KDE 6, con ese nombre, no existe en realidad, pero si lo usaron fue porque se lanzaron Plasma 6.0, Frameworks 6.0 y las aplicaciones de KDE que dependen del resto de seises, entre lo que se incluye Qt6. Hubo muchas novedades, incluyendo de aquellas que no se ven. No sólo se ha mejorado el rendimiento; también se han puesto los cimientos para cambios futuros que subirán el listón aún más alto.

Tal y como explican, Plasma 6.0 es «más duro, mejor, más rápido, más fuerte», lo que se podría decir usando otras palabras como que es mejor en todos los sentidos. Llegaron muchas novedades, algunas de ellas como nuevos ajustes por defecto, y en este artículo vamos a hablaros de los cambios más destacados que merece la pena tener en cuenta.

Mega-Lanzamiento KDE 6: sus nuevos ajustes por defecto

Sobre todo si se usa KDE neon, hay varios cambios por defecto que se notarán aquí y allá. Los archivos y carpetas ahora se seleccionan con un sólo clic y se abren con doble clic. Hasta ahora se abrían con un sólo clic, el comportamiento que prefieren la mayoría de desarrolladores de KDE, pero como la comunidad prefiere la otra opción y se decidieron a ponerlo así por defecto. Ellos volverán a cambiar este ajuste a como estaba antes, y nosotros podemos hacer lo mismo si así lo deseamos.

Otro cambio por defecto se verá menos, pero está presente y con gran protagonismo. Ahora se usa Wayland, pero es posible usar sesiones de X11 si no nos convence.

La modificación del conmutador de tareas creo que es algo que sí veremos con mejores ojos más usuarios. En Plasma 5, al presionar la combinación Alt + TAB aparecía por la izquierda una barra lateral con las tarjetas de las aplicaciones abiertas. A partir de Plasma 6.0 se mostrará una rejilla con las miniaturas. Como todo, esto se puede cambiar desde las preferencias del sistema.

El otro ajuste por defecto que creo que llamará la atención está en los paneles, que ahora flotan por defecto. El que estaremos viendo todo el tiempo, si no lo ocultamos, es el inferior, y también el lanzador de aplicaciones que flota doblemente, ya que está separado del panel inferior en sí.

En este punto ya hemos hablado de muchos de los cambios más destacados de los que llegaron con el Mega-Lanzamiento KDE 6, pero hay más.

El panel inferior inteligente

Nuevo de este lanzamiento combinado, ahora hay una opción de panel inferior inteligente. Su comportamiento le hace mostrarse cuando el escritorio está vacío o nada se pone encima, pero se oculta cuando una ventana lo toca. De esta manera se evita que esté siempre oculto, y creo que es la decisión correcta, ya que, por lo menos en mi caso, yo lo tengo que se oculte automáticamente, pero porque no quiero que se vea cuando tengo ventanas a pantalla completa. Lo que tampoco quiero es que esté oculto si no tengo nada en el escritorio, y esta opción sirve para estos casos.

La nueva vista general

La vista general de Plasma 5 no es que estuviera mal, pero la de Plasma 6 ha demostrado que podía ser mejor. Lo que tenemos ahora es algo más parecido a lo que muestra GNOME. Tiene dos posiciones, accesibles desde el teclado o con gestos en el panel táctil (sólo Wayland):

• En la primera se muestran todas las ventanas de un escritorio y todos los escritorios arriba.
• En la segunda (captura de arriba) veremos todos los escritorios uno al lado del otro.

La vuelta del cubo

El cubo (captura de cabecera) es algo que me encantó cuando probé Ubuntu por primera vez. Con el ratón, creo recordar, podía mostrar un cubo y pasar de un escritorio a otro. Estuvo en KDE hace un tiempo, lo eliminaron y ha vuelto junto a Plasma 6.0.

Lo malo es que no se puede acceder a él, por lo menos por defecto y sin realizar cambios, con gestos del panel táctil. Para sacarlo tenemos que presionar la combinación META + C, y para ir girándolo con META + Ctrl + flechas de navegación.

Nuevo tema Breeze

Breeze es el tema que usa Plasma por defecto, y han aprovechado para darle un lavado de cara. Con este cambio, sumado a todo lo que trae Qt6, se ha buscado ofrecer una imagen más moderna y clara.

Aplicaciones del Mega-Lanzamiento KDE 6

Un artículo que no pretende ser largo no tiene espacio para hablar de todo un grupo de aplicaciones que han recibido actualizaciones mayores con nuevas funciones. ¿Qué destacar aquí? Un par de las aplicaciones que están en todo sistema operativo con KDE:

Dolphin

Los ajustes de Dolphin recibieron un cuidado especial y fueron reorganizados para hacerlos más fáciles de navegar. Las mejoras de accesibilidad también están presentes en esta nueva versión. Los botones de la barra de herramientas y el espacio en disco de la barra de estado son ahora accesibles desde el teclado. Al hacer clic con el botón derecho en una carpeta, ahora aparece una opción para abrir la carpeta en una vista dividida.

Spectacle

Las funciones de grabación recientemente introducidas en Spectacle se han mejorado y ahora muestran un icono en la bandeja del sistema mientras se graba. Desde este icono podemos realizar diferentes acciones. Además de grabar toda la pantalla o la ventana de una aplicación, ahora también se puede grabar cualquier parte arbitraria de la pantalla. Es decir, podemos seleccionar qué porción grabar del mismo modo que podemos hacer capturas de sólo un área de la pantalla.

Prueba el Mega-Lanzamiento KDE 6 en KDE neon

Todo esto aún tardará un tiempo en llegar a la mayoría de distribuciones Linux, pero KDE neon lo tiene disponible desde el mismo miércoles. La mejor manera de probarlo es descargar su última ISO estable, grabarla en un USB e iniciar una Live Session. También puede hacerse en una máquina virtual, pero el rendimiento no es todo lo bueno que cabría esperar y podemos llevarnos una mala impresión que para nada tiene que ver con Plasma 6.

kbd {color: white; background-color: #353535; padding:3px 5px; border-radius: 7px; border: 4px double white;}

from Linux Adictos https://ift.tt/dPIFZYK
via IFTTT

Hace mucho tiempo que existe en navegadores basados en Chromium una flag que lo que hace es algo así como lo que ofrece la extensión Dark Reader. ¿Y qué es eso? Básicamente mostrar todas las páginas web en un modo oscuro aunque no ofrezcan esa opción. Vivaldi 6.6 ha añadido una opción que activa la flag nativa de Chromium para obtener el mismo resultado, pero ¿merece la pena en la actualidad la navegación oscura forzada?

Es difícil responder a algo que a mí personalmente me provoca sentimientos encontrados. No puedo – o no debo – poner capturas del editor de WordPress, pero sería el mejor ejemplo de lo que me hace querer usar la navegación oscura forzada. No tiene ningún elemento «raro» y el resultado es casi perfecto. Los fondos muestran diferentes tonos de gris oscuro, el texto es blanco y los enlaces de un azul un poco más claro que el del tema por defecto. Fijándome, puedo poner una captura parcial, y quedaría así:

En esa misma imagen se ven también algunas de las cosas a mejorar.

El problema de las imágenes en la navegación oscura forzada

Más adelante explicaremos o intentaremos explicar cómo funciona esta opción, pero aquí vamos a hablar de los problemas, de esas cositas que no quedan bien para nada. No he añadido ninguna flecha a la captura, pero ¿veis ese muñequito que hay a la izquierda del botón de «Relacionado»? El original no es así; se ha forzado la inversión de colores y muestra algo como no debería.

En un problema que se unas veces se ve y otras no. Una de las opciones debería respetar las imágenes, y falla estrepitosamente con algunas. Mirando con las herramientas del desarrollador, ese muñequito en concreto es una imagen en formato SVG, pero se muestra a través de un background-image de CSS. Por lo tanto, el navegador no está detectando que es una imagen, sino más bien texto, y los textos, según entiende, tienen que invertir su color.

Por lo tanto, las imágenes se respetarán siempre y cuando estén en un formato que deje claro que son unas imágenes. ¿Tiene solución de cara al futuro? Creo que sí, pero no es muy sencilla. Pasa por analizar los atributos e incluso reglas CSS y ver si en ellos hay algún tipo de imagen. Pero no es tan sencillo como confiar sólo en etiquetas img. Lo que no entiendo tanto es lo que pasa en Mastodon. Las imágenes de los perfiles se ven todas invertidas, y ahí sí están en una etiqueta img. No tengo dudas de que eso mejorará en el futuro, pero actualmente está así.

Otros problemas

Uno de los cambios cosméticos que hace todo esto es que los textos en colores diferentes al negro se muestran en un tono más claro. Eso es lo que hace que los enlaces de la captura anterior se vean bien; en el color azul normal se vería peor. Lo que en un principio parece buena idea, no siempre queda tan bien, y esto es más difícil de solucionar. Una solución sencilla corre por parte del usuario: acostumbrarse, y creo que es posible.

Hay un último problema, y es cómo sabe esta opción si tiene que actuar o no. Los diseñadores de páginas web hacen su trabajo pensando en cómo se verá al final. Son muchas las páginas que no tienen en cuenta las preferencias de colores que elegimos los usuarios. Para hacerlo bien y controlar nuestras preferencias hay que añadir dos paletas de colores, una para cuando elegimos el tema claro y otra para cuando elegimos el tema oscuro. Funciona de la siguiente manera:

1. Se diseña una página web tal y como se cree que quedará mejor.
2. Tras terminar, o en algún otro punto, ya que no hay una regla escrita para esto, se crea la opción para la paleta de colores que no hemos usado en el diseño original. Por ejemplo, si yo he decidido que las letras serán negras sobre fondo blanco en su opción por defecto, debo añadir mediante la media query «@media (prefers-color-scheme: dark)» los cambios necesarios para cuando un usuario elige el tema oscuro.

@media (prefers-color-scheme: dark), la solución… que depende de otros

Esa consulta multimedia puede solucionar muchos problemas. El navegador ve que hay una opción diseñada para temas oscuros, y, por lo que parece, ya no entra en juego la navegación oscura forzada. Sencillamente deja lo que se diseñó.

El problema aquí es que esa línea de código no se usa en muchos casos incluso si el diseño ya tiene fondos oscuros y textos claros. Claro, cuando el navegador entiende que está en un tema claro, que en realidad no es así, y trata de cambiar los colores de un tema oscuro por otro, estropicio al canto.

Cómo usar la navegación oscura forzada en Chromium

En navegadores basados en Chromium, esta opción está en chrome://flags (los navegadoras pueden cambiar «chrome» por «brave», «vivaldi» y demás) buscando «dark». La opción aparece como «Auto Dark Mode for Web Contents», y se puede activar con diferentes opciones. La que parece funcionar mejor es «Enabled with selective image inversion», lo que invertirá todo lo que no sean imágenes. Ofrece los resultados explicados aquí, y aunque esperamos que mejore en el futuro… hoy por hoy no es perfecto.

Y yo aquí estoy con mis sentimientos encontrados. Por una parte, me encanta, pero cuando va bien. Por otra, lo de mas imágenes es un problema. Ahora mismo voy activando y desactivando la opción, pero si llega el momento en el que estos pequeños problemas desaparecen, yo lo tengo claro. Me paso al lado oscuro.

from Linux Adictos https://ift.tt/rcXiTea
via IFTTT

Hace unas horas, Nate Graham, de KDE y famoso principalmente por publicar cada semana las novedades que ha habido en el proyecto en el que colabora, lo ha confirmado. En realidad era un secreto a voces, pero hay parte de la comunidad Linux que no lo sabía. KDE 4 era un desastre, llegando a tal punto de ser el responsable de que se piense que lo que empezó como Kool Desktop Environment esté lleno de bugs. Ahora, con Plasma 6.0 ya disponible, puede quedar aquello atrás.

Graham espera que «esto ayude a desterrar esos dolorosos recuerdos de KDE 4 que ya tienen 16 años«. Según dice, estamos ante un nuevo KDE, y eso quedaría demostrado con la información que ha ido recogiendo de la comunidad, con los comentarios, el feedback directo e indirecto, ya que se ha zambullido en redes sociales para ver qué pensaban de verdad los que lo han probado ya. Y lo curioso es que las valoraciones son mayoritariamente positivas, y eso que prácticamente sólo se ha podido usar en KDE neon y es aquí donde peor han salido las cosas.

Plasma 6.0: más duro, mejor, más rápido, más fuerte

Graham lo explica así:

«El martes pasado salió el Mega-Lanzamiento de KDE, y me alegra informar de que fue bien. Las impresiones iniciales parecen ser abrumadoramente positivas. He estado haciendo un triaje de errores extra y un seguimiento de las redes sociales desde entonces para ver si había algún problema importante, y hasta ahora las cosas se ven muy bien en el frente de errores también. Creo que nuestros 3 meses de control de calidad han merecido la pena. Enhorabuena a todos por un trabajo bien hecho. Esperemos que esto ayude a desterrar esos dolorosos recuerdos de hace 16 años de KDE 4. Ahora es un nuevo KDE. Más duro, mejor, más rápido, ¡más fuerte!«.

Hubo más problemas en KDE neon, pero no han dado detalles al respecto. Sí se sabe que han lanzado una segunda actualización para arreglarlo y se recomienda actualizar en cuanto sea posible.

Aún así, parece poco teniendo en cuenta que nos entregaron una punto-cero con tantos cambios como los que incluye Plasma 6.0. Los retoques no están sólo en lo que se ve, en partes como la nueva vista general o los paneles flotantes; además, también construido los cimientos para cambios que llegarán más adelante.

¿Qué pasó en KDE 4 y por qué esa mala fama?

KDE 4 llegó en 2008. Habían pasado 10 años desde el lanzamiento de KDE 1, pero seguía en pañales. Fue una reescritura completa… y no salió todo lo bien que les habría gustado. Tenía sus luces y sus sombras, siendo las luces cosas como la fluidez y las sombras se veían en forma de errores.

Yo lo probé en Kubuntu en 2016, cuando buscaba cualquier cosa que no fuera Unity. Recuerdo bien lo que sentí: en la Live Session todo era perfecto, y eso me hizo instalarlo en mi viejo portátil. Una vez iniciado el sistema, el escritorio era fluido y personalizable, y me recordaba al GNOME 2.x que usaba antes en Ubuntu, pero mejorado.

El pozo de mi gozo lo pusieron esos bugs que mermaban la experiencia de usuario. Pensaba que había algún problema de compatibilidad con mi portátil, pero el hecho era que yo no podía usarlo. Y fue entonces cuando KDE empezó a coger fama de buggy.

Y entonces llegó Plasma 5

Durante ese mismo 2016 llegó Plasma 5, ya con el cambio de nombre que se mantiene hasta hoy. En ese punto se empezó a encontrar el rumbo a seguir, el buen camino, y la madurez fue llegando. En mi caso concreto, yo le dí otra oportunidad en 2019, y los problemas del pasado ya se habían solucionado. Así que me quedé en KDE.

Han pasado 5 años desde aquel momento, y el tiempo no ha pasado en balde. Ahora ya tenemos disponible Plasma 6.0, y en KDE están convencidos de que la madurez es ahora total. Se ha llegado al punto de que esperan lanzar sólo dos versiones mayores al año porque no son necesarios tantos cambios y tan rápido.

KDE 4 hizo mucho daño al proyecto, por lo de la mala fama, pero decisiones como las de Valve con la Steam Deck, Manjaro con su consola, o Ubuntu Studio y EndeavourOS, que se han decantado por defecto por Plasma, parecen indicar que se está revirtiendo la situación. Que siga así.

from Linux Adictos https://ift.tt/k4S2Oyv
via IFTTT