FFmpeg es el marco multimedia líder

FFmpeg 7.0 «Dijkstra» ya fue liberado y en esta nueva versión se presentan una serie de mejoras significativas que abarcan desde la mejora de compatibilidad con diversos formatos, asi como la introduccion de nuevas funcionalidades, mejoras en codificadores, decodificadores, correcciones de errores y más.

En esta nueva versión que se presenta de FFmpeg 7.0 una de las novedades más destacadas es la implementación de la ejecución paralela de operaciones, esto permite realizar múltiples tareas simultáneamente, como desempaquetar/empaquetar contenedores de medios, decodificar, codificar y aplicar filtros.

Otra de las mejoras que se presenta en FFmpeg 7.0 son las de compatibilidad con formatos, y es que se destaca la introduccion del soporte para la codificación y decodificación de vídeo en formato MPEG-5 (EVC – Essential Video Coding) a través de la biblioteca externa libxevd.

Además, se han añadido desempaquetadores y empaquetadores de contenedores de medios para formatos como QOA (Quite OK Audio) este formato se utiliza para la transmisión de audio sin pérdida de calidad y se destaca por su rendimiento superior en comparación con otros formatos, pues se afirma que es tres veces más rápida que la decodificación en Ogg-Vorbis.

Tambien se destaca el soporte añadido para los desempaquetadores y empaquetadores para el formato IAMF (Immersive Audio Model and Format). Este formato está diseñado para distribuir sonido envolvente de manera efectiva, proporcionando un contenedor que incluye información adicional necesaria para el funcionamiento de algoritmos que reconstruyen escenarios sonoros y realizan mezclas de sonido.

Por otra parte, FFmpeg 7.0 incluye un decodificador experimental para el formato VVC (Versatile Video Coding), también conocido como H.266. Este nuevo decodificador representa un avance en la capacidad de FFmpeg para manejar la compresión de vídeo de última generación, facilitando la reproducción y manipulación de contenido en resoluciones desde SD hasta 8K, con soporte para HDR (High Dynamic Range) y vídeo panorámico en modo de 360 grados.

Además de estas mejoras en compatibilidad y funcionalidad, en FFmpeg 7.0 se ha implementado la capacidad de utilizar API D3D12VA (Direct 3D 12 Video Encoding) para la aceleración por hardware de la decodificación de varios formatos como H264, HEVC, VP9, AV1, MPEG-2 y VC1, mejorando el rendimiento y la eficiencia en sistemas compatibles con esta tecnología.

De los demás cambios que se destacan:

• Ahora es compatible con la decodificación acelerada por hardware utilizando las API Vulkan y libplacebo.
• Se ha añadido soporte para el protocolo URI de contenido utilizado en la plataforma Android.
• Los requisitos de compilación han aumentado; ahora se necesita un compilador que admita el estándar C11 para compilar FFmpeg.
• Para los codificadores basados en QSV (Intel Quick Sync Video), se ha cambiado el método de control de velocidad de bits predeterminado de VBR a CQP.
• Se ha introducido un nuevo desempaquetador para contenedores de medios DVD-Video, basado en las bibliotecas libdvdnav y libdvdread del proyecto VideoLAN.
• Ahora es posible transmitir metadatos en paquetes en la implementación del formato flv.
• Se ha agregado el codificador DXV DXT1 y el decodificador LEAD MCMP.
• Para los formatos MP4 e ISOBMFF, se ha implementado la inclusión de metadatos AVE.
• Se ha incorporado la compatibilidad con la tecnología AFGS1, utilizada en la especificación AV1 Film Grain, para mejorar la compresión de imágenes granuladas.
• Se ha añadido soporte para imágenes fijas en formatos HEIF y AVIF, así como imágenes fijas en mosaico.
• El perfil Dolby Vision ahora está disponible para el formato AV1.
• Por último, se proporciona soporte para reenviar metadatos HDR10 al codificar a través de las bibliotecas libx264, libx265 y libsvtav1.

Para quienes estén interesados en poder conocer más al respecto sobre este nuevo lanzamiento o conocer más sobre FFmpeg, pueden consultar los detalles en el siguiente enlace.

Descargar y obtener FFmpeg 7.0

Finalmente, para quienes quieran realizar la instalación o actualización de FFmpeg 7.0 deben saber que este paquete se encuentra en la mayoría de las distribuciones de Linux o si lo prefieren pueden descargar su código fuente para su compilación desde el siguiente enlace.

Y para realizar la instalación desde el código fuente, basta con ejecutar la secuencia de comandos ya conocidos:

./configure
make
make install

Para el caso de los que son usuarios de Ubuntu, Debian o cualquier otro derivado de estas distribuciones basta con abrir una terminal y en ella ejecutar el siguiente comando:

sudo apt install ffmpeg

Mientras que para el caso de Fedora el comando a ejecutar es el siguiente:

sudo dnf install ffmpeg

Y para el caso de los que son usuarios de Arch Linux, Manjaro o cualquier otro derivado de Arch Linux basta con ejecutar el siguiente comando:

sudo pacman -S ffmpeg

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

systemd es un conjunto de demonios de administración de sistema

Recientemente, los desarrolladores de systemd tuvieron una discusión en la cual se puso sobre la mesa el tema de la reducción de las dependencias de la biblioteca libsystemd (la biblioteca encargada de implementar servicios e interactuar con systemd). Esto debido a que actualmente se plantea una cierta preocupación sobre el aumento de dependencias de terceros en libsystemd que no son controladas por el proyecto y esto aumenta de la superficie de ataque. El iniciador de la discusión destaca que libsystemd carga varias bibliotecas críticas, como libzstd, liblz4 y libgcrypt, además de liblzma y glibc. Esto plantea problemas de seguridad significativos, especialmente si estas bibliotecas de terceros se ven comprometidas.

En Fedora, por ejemplo, más de 150 paquetes dependen de libsystemd, lo que aumenta la complejidad y los riesgos asociados. La propuesta para abordar esto implica dividir libsystemd en varias librerias separadas, cada una responsable de una API específica. Esto permitiría cargar dependencias de terceros solo cuando sean necesarias, reduciendo así la exposición a posibles vulnerabilidades en bibliotecas no controladas directamente por los desarrolladores de systemd.

Sin embargo, los desarrolladores de systemd argumentan que esta separación sería problemática debido a la interconexión de los controladores presentes en libsystemd. Consideran que la división requeriría mucho trabajo y podría resultar en una pérdida de eficiencia o la necesidad de duplicar el código, lo que contrarrestaría los beneficios de seguridad buscados.

En lugar de una separación completa, libsystemd ha optado por un enfoque más dinámico al cargar dinámicamente las bibliotecas liblzma, libzstd y liblz4 cuando sea necesario, utilizando la llamada dlopen(). Se planea implementar un cambio similar para libgcrypt en futuras versiones para abordar tanto las preocupaciones de seguridad como las necesidades de eficiencia y mantenibilidad del código.

Creo que la mayoría de estas dependencias no son necesarias para implementar funciones centrales de libsystemd, como las mencionadas anteriormente.

Este problema puede significar dividir libsystemd en múltiples bibliotecas que implementen diferentes API, una de las cuales, por ejemplo, libsystemd-core, solo dependería de libc, y otras bibliotecas más especializadas agregarían otras dependencias. Además, si algunas de las dependencias solo son necesarias para ciertos servicios systemd, mueva las dependencias a esos servicios.

El efecto final de esto debería ser reducir la superficie de ataque y mejorar la seguridad del sistema.

Durante la discusión hubo un punto el cual la mayoría de los desarrolladores criticaron, y es que mencionan que la decisión de cargar bibliotecas de terceros de forma implícita mediante dlopen() en libsystemd generaría un trabajo adicional debido a la complejidad añadida en el diagnóstico y la falta de visibilidad de los enlaces, además de que mencionan que esto complica la identificación de llamadas API de libsystemd que se conectan a funciones de bibliotecas externas, ya que no es obvio en el código. Esta nueva forma de carga, aunque no cambia la arquitectura subyacente, oculta los componentes externos de los mantenedores y usuarios.

Lenart Pottering expresó su desacuerdo con la idea de dividir libsystemd en varias bibliotecas debido a las complicaciones que esto conllevaría en el intercambio de código y el mantenimiento de la estabilidad de la API y los espacios de nombres. Dividir libsystemd requeriría exponer todos los controladores internos o compilarlos estáticamente por separado en cada biblioteca, lo que podría aumentar el tamaño debido a la duplicación de código o dificultar la gestión de la estabilidad y coherencia del sistema.

En lugar de la división, la estrategia de cargar bibliotecas externas solo cuando sea necesario se considera óptima, además de que para abordar la complejidad añadida en el diagnóstico, se propone agregar campos adicionales a los archivos ELF con información sobre las dependencias dinámicas cargadas, permitiendo que los depuradores procesen esta información y la muestren en la salida de herramientas como readelf. Esto proporcionaría una mayor transparencia y visibilidad sobre las dependencias dinámicas utilizadas por libsystemd, facilitando así el diagnóstico y la depuración de problemas relacionados con las bibliotecas externas cargadas dinámicamente.

Lenart recomendó a los desarrolladores de aplicaciones que, en lugar de vincularse directamente con libsystemd para una función específica, se implemente un controlador de protocolo a nivel de aplicación.

Esta estrategia de implementar controladores de protocolo a nivel de aplicación ofrece varias ventajas:

• Reduce la dependencia de libsystemd y evita la carga de bibliotecas externas cuando no son necesarias.
• Proporciona más flexibilidad y control sobre la funcionalidad específica requerida por la aplicación.
• Simplifica el diagnóstico y la depuración al tener un control más directo sobre la implementación de funciones específicas.
• En general, esta aproximación promueve la modularidad y la independencia de las aplicaciones, mejorando la flexibilidad y la eficiencia en el desarrollo y mantenimiento del software.

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/T2rRjcx
via IFTTT

Han pasado unos 15 meses desde el lanzamiento de la anterior versión mayor y ya tenemos aquí la nueva. Kodi Team ha lanzado – sí, la imagen de bienvenida es así de borrosa –  Kodi 21.0 Omega, y llega con una lista de novedades en la que destaca el soporte para FFmpeg 6.0. Ya está disponible la v7.0 de la famosa librería multimedia, pero, como es habitual en estos casos, se elige incluir algo más maduro y no software más nuevo que puede contener bugs.

Entre las novedades, una noticia: el equipo de desarrolladores decidió en marzo descontinuar el repositorio para Ubuntu. El motivo es que ese repositorio sólo es compatible con un grupo de distribuciones Linux, y Kodi Team va a centrar sus esfuerzos Linuxeros en desarrollar y mantener la versión flatpak. Es una decisión lógica que no gustará tanto a los usuarios de Ubuntu. Aunque los paquetes flatpak gustan, no deja de ser cierto que requieren dependencias que engordan el peso de una aplicación, por lo menos en las primeras instalaciones.

Novedades más destacadas de Kodi 21.0 Omega

• Mejorada la representación de textos de etiquetas.
• Eliminada la declaración hacia adelante de FlatBufferBuilder.
• Subtítulos:
  • Añadido soporte a la colección de fuentes (.ttc).
  • Habilitado paréntesis bidi para subtítulos adaptados.
  • Evitar llamadas a métodos virtuales en destructor.
• Mejoras en el disipador de audio en webOS.
• Sincronización de traducciones de metadatos de addons.
• Gestión de Re pág/Av Pág, etc en ajustes.
• Mantener la posición de selección después del final de la reproducción / cambio de estado observado.
• Estuary:
  • Reiniciar temporizador 1110_seekbar en búsquedas.
  • También iniciar temporizador (con reset) en búsquedas.
  • Reiniciar temporizador mientras se muestre el osd.
• PVR.
  • Diálogo de configuración del temporizador: Establecer ciertos ajustes por defecto en el cambio de tipo de temporizador.
  • Tipos de temporizador dinámicos.
  • Corregir algunas advertencias CPPCheck y clang-tidy.
• Arreglar el filtro visto/no visto no funciona al crear reproducciones.
• Traducciones actualizadas.
• Arreglada la reproducción automática del siguiente vídeo no funciona desde el interior del diálogo de información de vídeo.

Por plataformas

• Windows:
  • Añadir DXVA Video Super Resolution upscaler.
  • DXVA: comprobar si los espacios de color HDR10 son compatibles con el procesador de vídeo.
  • Eliminar registro innecesario para Intel sin soporte de escalador de súper resolución.
  • HLG > PQ HDR Reproducción correcciones.
  • Desactivar el mapeo de tonos del procesador para AMD y HDR a HDR.
  • Añadir información del método de renderizado al OSD de depuración.
  • Refactorizar el código del procesador de vídeo.
  • Distinguir entre host/nativo descarga/herramientas para windows construir.
  • Eliminar solución para Video Super Resolución.
  • Probar el soporte del procesador de vídeo para la conversión SDR a SDR.
  • Actualizar libass a 0.17.1.
  • Añadir componente de registro «Gráficos» para Direct3D.
  • Hacer HiDPI más genérico/plataforma agnóstica.
  • Configuración para procesamiento de alta precisión / mapeo de tonos HDR.
  • Refactorizar DXGI_FORMAT a std::string para depurar información OSD.
  • Refactorizar Video Super Resolución.
  • Eliminar código no utilizado en DeviceResources.cpp.
  • Eliminar la duplicación de velocidad de fotogramas extra no utilizada para resoluciones entrelazadas en CVideoSyncD3D.
  • Corregido: mostrar 119.88Hz y futuras frecuencias de refresco más altas correctamente.
  • RetroPlayer: Arreglar colores azules/rosas en pantallas de 10 bits.
  • Refactorizar CProcessorHD/CEnumeratorHD para eliminar el acceso directo a las interfaces del enumerador D3D.
  • Arreglar el diálogo de confirmación que no se muestra al mover a pantalla completa.
• macOS:
  • Compatible con pantallas HiDPI (retina).
  • Apoyar movimiento a pantalla completa / Fijar pantalla perdida.
  • Ventana nativa por defecto.
  • Comprobar y actualizar la configuración del monitor al iniciar.
• Android:
  • Ajustar macros de acuerdo a la API que están apuntando.
  • Eliminar constantes innecesarias if y use MediaFormat.
  • Preferir el decodificador de Google raw a MediaTek en dispositivos viejos.
• Linux:
  • Añadido –audio-backend=.
  • Simplificada la configuración de la prioridad de los hilos.
  • Uso de XB_FMT como enum en los hilos.
  • Pipewire: Capturar excepciones en CPipewire::Create().

Ya disponible

Kodi 21.0 Omega se anunciará oficialmente pronto y ya se puede descargar desde su página web oficial, por lo menos para Windows. Los usuarios de Linux deberemos esperar un poco más de tiempo. Como hemos explicado, ahora la versión oficial es el paquete flatpak, y para que aparezca como opción tiene que pasar un proceso de revisión. En las próximas horas aparecerá también en los repositorios oficiales de algunas distribuciones Linux. El tiempo aproximado dependerá de la filosofía de actualizaciones de cada proyecto.

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

backdoor XZ

Sin dudas el caso del backdoor que fue detectado en la utilidad XZ, es uno de los casos que pasara a la historia de Linux y es que no es por nada, pero todo el trabajo realizado por Jia Tan es uno de los mejores ejemplos de ingeniería social aplicada, ya que el trabajo realizado sin dudas es de admirar por la cantidad de tiempo invertido, pues no hablamos de semanas o meses, al menos dos años.

Este caso ha llamado la atención de muchos y se han comenzado a realizar análisis de ingeniería inversa, los cuales según sus resultados preliminares revelan la presencia de un backdoor incrustado en liblzma como parte de una campaña para infiltrar el paquete XZ. Este backdoor está diseñado específicamente para afectar a sistemas x86_64 con el kernel de Linux y la biblioteca Glibc C, donde se aplica un parche adicional a sshd para vincularlo con libsystemd.

Los investigadores mencionan que inicialmente se creyó que el backdoor podría evadir la autenticación sshd y obtener acceso al sistema a través de SSH, pero al realizar un análisis más detallado se reveló que el backdoor permite la ejecución de código arbitrario en el sistema sin dejar rastros en los registros sshd.

La función RSA_public_decrypt es interceptada por el backdoor para verificar la firma del host usando la clave fija Ed448. Si la verificación es exitosa, se ejecuta el código transmitido por el host externo utilizando la función system() antes de que sshd restablezca los privilegios. Los datos del código a ejecutar se extraen del parámetro «N» pasado a la función RSA_public_decrypt y se verifican y descifran utilizando la clave predefinida ChaCha20.

Para activar el backdoor en sshd, se utiliza el mecanismo estándar de intercambio de claves de host y responde únicamente a la clave preparada por el atacante y correspondiente a la clave fija predefinida Ed448. Si la verificación de la firma de la clave pública falla o si no se confirma la integridad de los datos de ejecución, el backdoor devuelve el control a las funciones SSH estándar.

La clave privada del atacante sigue siendo desconocida, lo que imposibilita la implementación de un código de verificación para activar el backdoor desde fuentes externas o para desarrollar un escáner que detecte hosts comprometidos en la red. Sin embargo, los investigadores han desarrollado un script que muestra cómo se puede sustituir una clave pública en un certificado OpenSSH transmitido por un cliente SSH, lo cual es procesado por la función RSA_public_decrypt interceptada por el backdoor

Además, los investigadores descubrieron la existencia de un mecanismo para neutralizar el backdoor (killswitch) en el sistema local mediante la configuración de una variable de entorno antes de iniciar sshd. También se ha realizado un análisis detallado de compilaciones de shell utilizadas para confundir el proceso de extracción de un archivo objeto con un backdoor y reemplazarlo en la biblioteca liblzma.

Durante la compilación del paquete XZ, se ejecutó un código desde el script «build-to-host.m4» que manipuló un archivo de prueba y realizó ciertas modificaciones en los caracteres y lo transformó en un archivo intacto, del cual se extrajo el script de shell. El script de shell resultante fue capaz de extraer gradualmente otro script de shell del contenido, omitiendo ciertas secuencias con los comandosy reemplazando caracteres.

Como resultado de este proceso, se creó un script de shell bastante complejo y extenso que extrajo directamente el archivo con el backdoor del archivo good-large_compressed.lzma, lo descifró y lo insertó en liblzma. Este script también incluía una implementación del mecanismo de complemento, que permitía la entrega de componentes ejecutables adicionales posteriormente al colocar nuevos archivos de prueba sin alterar good-large_compressed.lzma y bad-3-corrupt_lzma2.xz, mediante una búsqueda de firmas. El código también incorporaba un descifrador basado en el algoritmo RC4, implementado en el lenguaje AWK

Por otra parte, cabe mencionar que en base al incidente, se ha desarrollado un conjunto de herramientas llamado xzbot, que incluye:

• Un honeypot para crear servidores ficticios que simulan ser vulnerables para detectar intentos de conexión de atacantes.
• Un parche para reemplazar la clave pública en la puerta trasera dentro de liblzma.so con una propia (para conectarse a la puerta trasera usando la clave privada correspondiente).
• Una demostración para iniciar la ejecución de código en una puerta trasera modificada utilizando la clave privada correspondiente.

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/4AdSxh8
via IFTTT

Algo más pronto de lo habitual, que suele ser ya por la noche en España, WineHQ ha lanzado hace unos instantes WINE 9.6. Es una nueva versión de desarrollo las que lanzan cada dos semanas, y ha llegado quince días después de la anterior v9.5. Si atendemos a los números, podemos pensar que la mayoría de colaboradores se han tomado un descanso por la semana santa, ya que las cifras son de las más bajas que se recuerdan.

En total, la lista de cambios recoge «sólo» 162. Está por debajo de la media, que suele estar por encima de los 200 y en muchas ocasiones superando los 300. La lista de novedades más destacadas menciona que se ha añadido compatibilidad con funciones AVX avanzadas en contextos de registro, más efectos Direct2D. soporte para relleno RSA OAEP en BCrypt y corrección del modo interpretado en WIDL, a lo que se le suma el habitual punto de varios bugs corregidos (18).

Bugs corregidos en WINE 9.6

• Mozart 10/11: No se puede guardar gif jpg o tiff, png + bmp están vacíos, emf sólo parcial.
• Los botones del depurador TI-83 Plus Flash no son visibles.
• «Text Service and Input Languages» necesita función no implementada USER32.dll.LoadKeyboardLayoutEx llamada.
• SolidWorks 2016 se bloquea al iniciarse.
• ChessBase 14 – se bloquea nada más iniciarse.
• Trackmania Unlimiter 1.3.x para TrackMania United Forever 2.11.26 se bloquea en la pantalla de selección de cuenta (diferencias en el gestor de montón, suposiciones incorrectas del mod en las estructuras de datos internas del motor del juego).
• nProtect GameGuard Personal/Anti-Virus/Spyware 3.x/4.x se bloquea debido a que el módulo PE ‘winedevice’ no tiene tabla de exportación.
• nProtect Anti-Virus/Spyware 4.0 ‘tkpl2k64.sys’ se bloquea al no implementarse la función ‘fltmgr.sys.FltBuildDefaultSecurityDescriptor’.
• Múltiples aplicaciones de 32 bits fallan debido al manejo incorrecto de la clave ‘HKLM\Software\Classes’ en WINEPREFIX de 64 bits (clave compartida bajo Windows 7+ WOW64)(Autocad 2005).
• [Regresión] La novela visual Shin Koihime Eiyuutan se bloquea después de abrir la película.
• VrtuleTree llama a la función no implementada ntoskrnl.exe.ExGetPreviousMode.
• d2d1:d2d1 falla con frecuencia en GitLab CI.
• Nerf Arena Blast Demo sólo muestra una pantalla negra.
• Final Fantasy XI Online: El cursor del ratón/puntero se activa en momentos no deseados.
• Múltiples juegos tienen fallos de textura (Iron Harvest, The Hong Kong Massacre).
• configure establece incorrectamente el valor ac_cv_lib_soname_vulkan en macOS.
• wshom comprueba el tiempo de espera en Wine.
• CryptStringToBinary no añade CR antes de los bytes de relleno en algunos casos.

Lista traducida con DeepL.

WINE 9.6 ya está disponible y se puede descargar desde el siguiente botón. En su página de descargas hay también información sobre cómo instalar esta y otras versiones en sistemas operativos Linux y otros como macOS e incluso Android.

Dentro de dos semanas llegará WINE 9.7 con cientos de retoques para seguir preparando la versión estable de 2024.

.boton {color: white; background-color: grey; padding: 20px; font-size: 2rem; text-decoration: none; border-radius: 10px; position: relative; top: 15px; border: 4px solid #555;}.boton:hover {box-shadow:1px 1px 2.5px black !important;}

from Linux Adictos https://ift.tt/96AhWlJ
via IFTTT

En Plasma 6, KDE hizo un gran número de cambios y muchos de ellos se ven a simple vista. Por ejemplo, lo primero que notamos al entrar a un sistema operativo con la nueva versión del escritorio es que el panel está despegado de los bordes. Y si hacemos clic en el menú de inicio, Kickoff, el lanzador de aplicaciones, también flota sobre el panel. Plasma es muy personalizable y todo esto se puede desactivar, pero así es por defecto desde febrero.

Windows 11 también introdujo cambios estéticos cuando llegó en 2021. Como en Plasma 6, hay uno que se nota al entrar al sistema operativo, pero no es que el panel flote. Lo que se ve al entrar en Windows 11 es que los iconos del panel inferior están en el centro. Ya cuando se hace clic sobre el menú de inicio vemos que su «Kickoff» también flota. Si eres usuario de KDE, ya estás en Plasma 6 y quieres ver lo mismo, salvando las distancias, esto es lo que debes hacer.

Plasma 6 con un poquito de Windows 11

Los pasos a seguir son sencillos:

1. Hacemos clic derecho sobre el panel inferior y luego sobre «Entrar en el modo edición». Eso es lo que pone en Plasma 6.0, y si se lee este artículo pasados unos meses puede haber un texto diferente.

2. Hacemos clic sobre «Añadir separador» dos veces, lo que lo desajustará todo, pero ahora lo arreglamos. Donde los añade exactamente es algo que depende de la distribución y la versión de Plasma. En este ejemplo añade una a cada lado.

3. Lo único que hay que hacer es un clic sobre uno de los espaciadores y arrastrarlo al lado derecho de los iconos del panel inferior. Aquí hay que tener cuidado de ponerlo en su sitio; si no, podemos ponerlo en la bandeja del sistema y no es lo que buscamos.

Hay claras diferencias con respecto a lo que vemos en Windows 11. Por una parte, no se puede hacer que el panel inferior esté pegado a los bordes y Kickoff flotando; hay que elegir. Y la segunda es que en la actualidad Kickoff está centrado sobre su icono, no sobre el panel. Eso no era así en Plasma 5 y probablemente, o eso espero, lo arreglen en el futuro. Una solución es poner el cursor en el borde derecho y alargar Kickoff para centrarlo a ojo.

Como siempre, en Linux decidimos nosotros

El resultado es el que tenéis en la captura de cabecera. El sistema operativo es openSuse Tumbleweed, uno de los primeros en subir a Plasma 6, y el paso de desactivar el panel flotante no es necesario porque por defecto lo han dejado como en Plasma 5. Por cierto, esto se puede hacer también en esta versión del escritorio, aunque la posición de las opciones es diferente.

Y así se puede tener Plasma 6 con cierto aire a Windows 11. Es una posibilidad, y como siempre digo, con Linux somos los usuarios los que decidimos cómo queremos tener las cosas.

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

Los servicios de música en streaming son espectaculares para los amantes de la música. Por el precio de un disco al mes, nos permiten escuchar casi toda la música del mundo. Entre los más importantes destacan sobre todo dos: Spotify y Apple Music. El primero se puede usar en todas partes, mientras que el segundo sólo en aparatos de Apple y desde un navegador web con soporte para Widevine. Entonces, ¿por qué alguien como yo elije la propuesta de la manzana?

Hace ya aproximadamente 9 años desde que dejé de piratear música. Era 2015, los de Cupertino acababan de lanzar Apple Music y yo escribía también en otros blogs de esta misma red con temática de la manzana. El precio, para alguien que siempre está escuchando música, no era caro, por lo que me lancé. Aquí ya hay un motivo, y es que es lo primero que usé en su versión de pago.

Spotify está en todas partes, pero de aquella manera

Spotify está en todas partas. Se puede instalar en una PlayStation 3+ o Xbox, Windows, macOS, «Linux», véanse las comillas… está para todo. Pero esas comillas las he puesto por algo.

Tal y como explican en la página de descargas de Spotify para Linux, no existe una aplicación oficial y «la experiencia puede ser diferente de nuestros clientes de escritorio de Spotify, como Windows y macOS». El motivo es que es una aplicación basada en Electron que bien podríamos crearnos nosotros usando bash o algo parecido.

Así que sí, está en todas partes, la compañía ofrece «algo» para Linux, pero no es una aplicación nativa y completa.

El sonido envolvente de Apple Music

Esto no es algo que me haga quedarme en Apple Music, no en una actualidad en donde no está muy extendido, pero suma. El servicio de música de la manzana soporta Dolby, y escuchar los discos compatibles con unos auriculares también compatibles está otro nivel.

Algunos AirPods permiten hacer uso del audio espacial, y el sonido puede moverse – no es obligado – junto a nuestra cabeza. Por ejemplo, si tenemos el punto de referencia en frente y giramos la cabeza a la izquierda, el auricular izquierdo bajará el volumen. Si miramos arriba, la música sonará por abajo.

Se podría decir que esto es una «pijada» y que lo que importa es la calidad del sonido, pero es que escucharlo en surround es como pasar del mono al estéreo. Si un disco está bien producido, la diferencia es brutal. Para los audiofilos, no está de más mencionar que Spotify no ofrece sonido sin pérdida.

Apple Music está mejor organizado

Este sería el mejor resumen: Apple Music es mejor servicio de música. Tanto las aplicaciones como la versión web están centradas en la música, y la interfaz es como la mejor app de este tipo, bien organizada. Es una perfecta biblioteca musical.

Echad un vistazo a la captura de cabecera y a la siguiente. Apple Music tiene una sección en donde está todo lo disponible, con unos apartados generales, la biblioteca con artistas, canciones, etc y listas de reproducción, a la derecha, en el caso de los artistas, todos los artistas y más a la derecha la música de cada uno. Spotify, por su parte, tiene el apartado general y luego uno con nuestra biblioteca. Muchos estarán pensando «lo mismo, ¿no?». No.

Para empezar, al entrar en la biblioteca todo está desordenado y hay que hacer clic en una opción para que se organice. Si no se selecciona nada, por lo menos en mi caso, aparecen las canciones favoritas y los recientes. Si filtramos por artista, también lo ordena por reciente, y a mí eso no me parece lo mejor. Se puede poner por orden alfabético, pero haciendo clics de más. Por cierto, esto a mí no me funcionaba hasta hace nada, por lo que el desorden era un gran problema.

Cuando entramos a un artista, Ad Infinitum en el ejemplo, Spotify muestra «su página» no «mi página sobre el artista». Es decir, me muestra TODO de ese artista, no lo que forma parte de mi biblioteca. Si alguien me dice que hay un botón como el de filtrar de Amazon Music del que hablaremos más adelante, yo no lo he visto y le estaría dando más razón a mi argumento.

El sistema de añadir música

Cómo se añade música es otro tema a tener en cuenta. Se usa un sistema de «Favoritos» con corazones que a mí no me gusta. No es el único, ya que Amazon lo hace igual. A mí todo esto me deja muy confuso. Apple Music lo añade con el símbolo de suma (+) y tiene un apartado de Favoritos aparte. Es decir, un botón con pinta de añadir añade. Lógico.

¿Y que hay del resto de servicios?

De lo que yo he probado, y teniendo en cuenta tanto el catálogo como la calidad del sonido, creo que sólo hay tres alternativas posibles. Dos las estamos tratando ya en este artículo, y la tercera es Amazon Music. Junto a Apple Music, es la que ofrece mayor catálogo y tampoco tiene aplicación para Linux. Tiene para Windows, macOS, Android y iPhone/iPadOS.

En cuanto a organización, que es de lo que más me importa a mí, está a medio camino entre lo que ofrece Sopotify y Apple. Cuando entramos en un artista nos muestra su página completa, pero podemos filtrar por «Mi música» y ya veremos nuestra propia página del artista. La interfaz de escritorio se parece mucho a una aplicación musical, no como Spotify que pretende ser un todo-en-uno que crea confusión para los que sólo queremos escuchar música.

Buena organización, catálogo, calidad de sonido… y sólo música

En resumen, empecé con Apple Music en un momento en el que tenía más aparatos de Apple y me he mantenido porque la aplicación es de música y sólo música, el extenso catálogo y la calidad del sonido cuando uso buenos auriculares. También por el demérito de la competencia, con el diseño de Spotify a la cabeza, del que se han quejado muchos, incluso en la blogosfera hispana.

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

Últimamente estoy leyendo noticias y viendo muchos vídeos sobre Distrobox, esa especie de Linux Susbystem for Linux que nos permite instalar software de una distribución en otra. En ocasiones he llegado a leer como se asegura que es el fin del distro-hopping, pero ¿es realmente para tanto? En mi opinión, no, y voy a explicar los motivos por los que creo que esa obsesión por probar opciones no cambiará.

El distro-hopping es básicamente ir pasando de una distribución Linux a otra esperando que la siguiente sea la buena. Lo que hay que tener en cuenta es por qué hacemos distro-hopping, y si uno de los motivos es porque en una distribución podemos instalar más software que en otra. Aunque sea retocando mucho, lo que se puede hacer con un sistema con base Linux se puede hacer con otro, por eso, y aquí tengo que dejar claro que esta es mi opinión, las cosas seguirán igual.

Distrobox permite usar software de una distribución en otra…

… poco más. Hay muchas opciones con base Linux y son todas diferentes entre sí. Creo que el principal motivo por el cual abandonamos una distribución es porque nos falla o hay algo que no termina de gustarnos. Por ejemplo, algo de hardware, como el WiFi, que no funciona en nuestro ordenador o el entorno gráfico que creemos que no es lo que buscamos.

Yo hice mucho distro-hopping cuando Ubuntu se pasó a Unity, y mis primeros destinos fueron justamente otros -buntus. Pasé por Xubuntu, Lubuntu, Kubuntu, Linux Mint, Elementary, más tarde Ubuntu MATE… y todos ellos tenían disponible exactamente el mismo software. Yo buscaba un escritorio relativamente bonito y que no pesara un quintal como Unity, con lo que Distrobox no me habría arreglado nada.

Eso sí, nos permite elegir lo que más nos gusta sin perder nada

Lo que sí hace Distrobox es que no echemos nada en falta. El mejor ejemplo que me viene a la cabeza es SteamOS: por defecto es inmutable, y en teoría sólo se puede instalar software popular de Flathub. Si añadimos una imagen de Ubuntu, podremos instalar y usar sin problemas el Kodi de sus repositorios, FFmpeg o Imagemagick. También podemos navegar por la red e instalar cualquier DEB que encontremos, con lo que la Steam Deck pasaría a tener un sistema al 90-95% igual que uno Linux tradicional. O cuando en el pasado Kodi fallaba por la versión de Python, Distrobox habría facilitado las cosas.

Pero lo que no hace Distrobox es incluir un kernel que le vaya mejor a nuestro equipo. De hecho, una de las funciones que tiene es que todos los sistemas operativos de los contenedores usan el mismo kernel que el anfitrión.

Otros ejemplos de elegir lo que más nos gusta sin perdernos nada incluirían estar en Debian Stable e instalar las últimas versiones de GIMP o LibreOffice sin instalar otro sistema, o tener AUR en Linux Mint. También podemos aprovechar todas las herramientas de Kali Linux y hacer pentesting sin tener que usar una Live Session. Todo desde nuestro sistema favorito.

Sin hacer nada complicado, podemos tener un sistema operativo más conservador y cualquier software que exista en Linux o justo lo contrario, y esa es la magia que hace Distrobox. Pero magia no es igual a milagro.

El sistema operativo siempre será el mismo

El sistema operativo siempre va a ser el mismo, y aunque hay maneras de virtualizar el entorno gráfico, este también será siempre igual. Si nos gusta Fedora, con GNOME, y hay algo que no encaja entre su sistema operativo o entorno gráfico y nuestro aparato, Distrobox no lo va a arreglar. Sí es posible que una aplicación en otro formato nos vaya mejor, pero esto estaría solucionando un problema menor, no uno más importante.

Así que no, Distrobox no es el fin del distro-hopping. Es una herramienta que va a disminuir los picores que nos hacen dar un salto, pero no los eliminará si son fuertes. Además, con lo inconformistas que somos algunos, lo raro es que llevemos años en la misma distro…

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

Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas

Hace poco se dio a conocer el descubrimiento de una vulnerabilidad (ya catalogada bajo CVE-2024-28085) bastante particular, y es que el fallo que se encuentra en la utilidad wall del paquete util-linux, permite a un atacante manipular secuencias de escape para afectar las terminales de otros usuarios.

Esta vulnerabilidad llama la atención de muchos, ya que básicamente permite realizar phishing, dado que la utilidad está diseñada para enviar mensajes a terminales, esta vulnerabilidad se aprovecha para engañar y obtener información de otros terminales.

El problema radica en que la utilidad wall bloquea las secuencias de escape en el flujo de entrada, pero no en los argumentos de la línea de comando, lo que posibilita que un atacante utilice secuencias de escape en las terminales de otros usuarios.

Por ejemplo, al ejecutar wall utilizando secuencias de escape que permiten mover el cursor, borrar y reemplazar contenido en la pantalla, un atacante puede simular una solicitud de contraseña de sudo en la terminal de otro usuario. Si el usuario no detecta esta manipulación y proporciona su contraseña, esta aparecerá en el historial de comandos como un comando inexistente (debido a que la contraseña se ingresó directamente en la línea de comandos en lugar de un comando válido).

Cuando se emite una advertencia de que no se encontró el comando ingresado, muchas distribuciones ejecutan el controlador /usr/lib/command-not-found. Este controlador intenta identificar el paquete que contiene el comando faltante y proporciona una pista sobre si se puede instalar. Sin embargo, hay un problema: al iniciar el controlador de command-not-found, se le pasa un comando inexistente como parámetro de la línea de comando. Esto es visible al visualizar los procesos en el sistema, lo que podría ser aprovechado por un atacante para monitorear los procesos en ejecución y determinar la contraseña ingresada por la víctima en la línea de comandos.

Para inducir a un usuario a ingresar una contraseña en respuesta a un mensaje sudo falso, se ha propuesto un truco. Este truco implica rastrear el inicio real de la utilidad sudo en la lista de procesos, esperar a que se complete y realizar un ataque a través de «wall» inmediatamente después. Al manipular las secuencias de escape, un atacante puede reemplazar el mensaje después de la ejecución real de sudo con un mensaje falso de reingreso de contraseña. La víctima podría pensar que cometió un error al ingresar la contraseña y volver a ingresarla, revelando así la contraseña en los argumentos del controlador de «command-not-found».

Algunas personas no han entendido bien en qué escenarios esto podría usarse para atacar a otro usuario. No necesitamos atacar sudo, podemos atacar en cualquier lugar donde el usuario ingrese su contraseña, un ejemplo basico es después de que un usuario inicia sesión usando OpenSSH.

Para llevar a cabo un ataque exitoso, es necesario configurar el modo «mesg» en «y», que viene configurado de forma predeterminada en sistemas como Ubuntu, Debian y CentOS/RHEL. El ataque se ha demostrado con éxito en Ubuntu 22.04 utilizando gnome-terminal en su configuración predeterminada. Sin embargo, en Debian, el ataque es más difícil debido a que el controlador «command-not-found» no está habilitado por defecto. En cuanto a CentOS/RHEL, el ataque no funciona, ya que la utilidad wall se instala sin el indicador setgid y no tiene acceso a las terminales de otros usuarios. Si se utiliza Windows-Terminal, el ataque se puede modificar para cambiar el contenido del portapapeles.

Esta vulnerabilidad ha estado presente en el paquete util-linux desde 2013, luego de que la versión 2.24 introdujera la capacidad de especificar un mensaje en la línea de comando del muro, pero olvidó limpiar las secuencias de escape. Una solución para esta vulnerabilidad se ha incluido en el lanzamiento más reciente de util-linux 2.40, que se publicó ayer. Es importante mencionar que al intentar corregir la vulnerabilidad en la versión util-linux 2.39, se identificó otra vulnerabilidad similar que permite la sustitución de caracteres de control mediante la manipulación de las configuraciones regionales.

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/AJKiZDd
via IFTTT

Valkey, el fork de la Fundación Linux de Redis

El cambio de licencia de Redis ha generado un gran movimiento por parte de la comunidad open source, y es que aunque pareciera que el cambio «superficialmente» solo afectaba a los proyectos comerciales, tal parece que distintos proyectos se ven afectados por el hecho de que hay una incompatibilidad de su proyecto con las licencias que manejan.

Y es que hace poco la Fundación Linux, dio a conocer hace poco el lanzamiento del proyecto Valkey, el cual está destinado a seguir avanzando en el desarrollo de Redis DBMS, una base de datos de código abierto distribuida bajo la licencia BSD.

El equipo de Valkey está integrado por destacados desarrolladores como Madelyn Olson, antigua responsable de Redis en Amazon; Ping Xie, desarrollador de Redis en Google y otros desarrolladores de renombre.

Sobre Valkey

Valkey es una bifurcación de Redis que se originó como respuesta a un cambio en la política de licencias de Redis Ltd, la empresa detrás del desarrollo de Redis. A partir de Redis 7.4, la empresa decidió cesar la incorporación de nuevas funciones bajo la licencia BSD, optando por distribuir el código del proyecto bajo dos licencias propietarias: RSALv2 y SSPLv1. Estas nuevas licencias imponen restricciones adicionales, especialmente en lo que respecta al uso gratuito del producto para servicios en la nube.

Valkey está diseñado para ser compatible con sistemas operativos como Linux, macOS, OpenBSD, NetBSD y FreeBSD y se menciona que sus planes de desarrollo abarcan la implementación de un mecanismo más robusto para la migración de slots, mejoras significativas en la escalabilidad, mayor estabilidad en las configuraciones de clúster, rendimiento optimizado en entornos multiproceso, soporte para activadores, introducción de nuevos comandos y la implementación de búsquedas vectoriales.

“Valkey es un esfuerzo impresionante realizado por colaboradores de larga data en la comunidad de Redis para defender los principios de código abierto en los que se fundó el proyecto. Aplaudo su compromiso con una verdadera colaboración y espero con interés las innovaciones que aportan a la comunidad tecnológica en general como un proyecto en la Fundación Linux”, dijo Jim Zemlin, Director Ejecutivo de la Fundación Linux. 

Cabe mencionar que con el lanzamiento dé Valkey, este se convierte en el tercer open fork de Redis, ya que en días anteriores habíamos compartido aquí en el blog la noticia del fork creado por el fundador del entorno de usuario Sway y del lenguaje de programación Hare, Redict, un fork de Redis 7.2.4 que se distribuirá bajo la licencia LGPLv3. Además, desde 2019, Snapchat ha estado trabajando en el desarrollo de KeyDB, otro fork de Redis basado en la versión 5. KeyDB se destaca por su adopción de una arquitectura multiproceso, implementando métodos más eficientes de gestión de memoria y ofreciendo características adicionales como replicación activa, almacenamiento optimizado en Flash, y soporte para configuración separada de la vida útil de las claves secundarias.

Ademas de ello, se menciona que este proyecto será gestionado por la Fundación Linux en una plataforma independiente, contando con la participación activa de una comunidad de desarrolladores y empresas comprometidas en preservar la naturaleza de código abierto de Redis. Importantes empresas como Amazon Web Services (AWS), Google Cloud, Oracle, Ericsson y Snap se han sumado a esta iniciativa.

Finalmente y como comentario personal, me gustaría mencionar que los movimientos dé la comunidad por sustituir un proyecto (producto) nos muestra la rapidez con la que se puede responder, pero como comento de «manera personal» el hecho de hacerlo porque ahora el proyecto ha respondido a los abusos de proyectos comerciales y se está dejando de lado el apoyo, si deja mucho que pensar (claro no es un movimiento 100% noble, pero al final es eso, es poner un alto al abuso).

Y el que vean mal (cof, cof, Fedora…) que un proyecto quiere que todos esos proyectos que si generan una ganancia sin dar nada a cambio (o muy poco) vuelve a poner sobre la mesa el tema que muchos desarrolladores mencionan y es el de una licencia open source que obligue a los proyectos comerciales ya séa a dar una parte de sus ingresos a los proyectos open source que utilizan para sus productos o realizar la contribución en especie (destinando desarrolladores a contribuir en el proyecto).

Para entender un poco, es importante tomar en cuenta que las diferencias fundamentales entre RSALv2 y SSPLv1 radican en que SSPLv1 se basa en la licencia copyleft AGPLv3, mientras que RSALv2 se fundamenta en la licencia BSD permisiva. Bajo la licencia RSALv2, se permite usar, modificar, distribuir e integrar el código en aplicaciones, salvo en el caso de aplicaciones comerciales o servicios de pago administrados en la nube (aunque se permite su uso gratuito para servicios internos; la restricción se aplica únicamente a servicios pagos que brinden acceso a Redis). Por otro lado, la licencia SSPLv1 incluye el requisito de que, bajo esa misma licencia, se entregue no solo el código de la aplicación en sí, sino también el código fuente de todos los componentes implicados en la prestación del servicio en la nube.

Fuente: https://www.linuxfoundation.org

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