openSUSE simplifica la instalación de H.264 en el sistema

opensuse

Es un sistema operativo orientado a los usuarios de software libre y abierto al desarrollo de nuevas funciones por su comunidad

Hace poco se dio a conocer la noticia de qué desarrolladores de openSUSE han implementado un esquema para simplificar la instalación del códec de video H.264 en la distribución.

Esto se debe a que hace unos meses, el paquete de distribución también incluía paquetes con el códec de audio AAC (usando la biblioteca FDK AAC), que está aprobado como estándar ISO, definido en las especificaciones MPEG-2 y MPEG-4 y utilizado en muchos servicios de video.

El proyecto openSUSE se inspiró en los esfuerzos de Fedora para poner a disposición de sus usuarios los códecs OpenH264 y FDK AAC de Cisco. Los miembros se comunicaron con el equipo de código abierto de Cisco para hacer lo mismo con su base de usuarios.

Un obstáculo a superar es que la limitación actual para la redistribución gratuita de los códecs es de 100 000 usuarios, por lo que el miembro de la junta directiva Neal Gompa y el gerente de versiones Leap de openSUSE, Lubos Kocman, propusieron una forma de simplificar la instalación del códec en openSUSE .

El motivo de hacer un cambio en el proceso de la instalación del codec en el sistema, se debe a que la distribución de la tecnología de compresión de video H.264 requiere el pago de regalías a la organización MPEG-LA, pero si se utilizan librerías abiertas OpenH264, el códec puede usarse en productos de terceros sin pagar regalías, ya que Cisco, que desarrolla el proyecto OpenH26, es licenciatario de MPEG LA.

Cisco, cuyo proyecto openSUSE está muy agradecido por sus esfuerzos, acordó un enfoque sobre la redistribución de OpenH264 a través de una infraestructura propiedad de Cisco para los usuarios de openSUSE.

El matiz es que el derecho a usar tecnologías de compresión de video propietarias se transfiere solo para las compilaciones distribuidas por Cisco, por ejemplo, descargados del sitio web de Cisco, que no permite colocar paquetes con OpenH264 en el repositorio de openSUSE.

Para resolver este problema, se ha agregado un repositorio separado al kit de distribución, en el que se descarga la compilación binaria del códec del sitio web de Cisco (ciscobinary.openh264.org).

Al mismo tiempo, la compilación del códec está formado por los desarrolladores de openSUSE, certificado por la firma digital oficial de openSUSE y transferido a Cisco para su distribución, es decir la formación de todo el relleno del paquete sigue siendo responsabilidad de openSUSE y Cisco no puede realizar cambios ni reemplazar el paquete.

Se imaginó un flujo de trabajo de lanzamiento para OpenH264 y se manejó un enfoque de tres pasos a través de un conjunto de scripts en OpenSUSE Release Tools.

Un script de flujo de trabajo activa y envía a Cisco un correo electrónico con un archivo que contiene paquetes rpm OpenH264 a Cisco; crea una instantánea de los datos que luego se envían o «PUBLICAN» para la extracción manual de un binario de Cisco . El proceso garantiza que el proyecto siempre tenga un conjunto de archivos binarios relacionados en Open Build Service .

Uno de los mantenedores del proyecto multimedia:libs:cisco-openh264 crea y envía un archivo . El paquete se firma en OBS con la clave openSUSE, por lo que se puede verificar el origen del paquete. OBS publica los metadatos del repositorio en codecs.opensuse.org/openh264 .

El archivo debe contener solo paquetes con Cisco OpenH264 y complementos OpenH264 GStreamer relacionados. La adición de cualquier otro contenido fuera del acuerdo, especialmente otros códecs, bajo el acuerdo de Cisco daría lugar a una infracción.

Ya se han discutido las posibles mejoras para mejorar el flujo de trabajo existente, pero los esfuerzos iniciales están destinados a proporcionar openSUSE una experiencia más simplificada después de la instalación.

El repositorio openh264 estará habilitado de forma predeterminada para las nuevas instalaciones de openSUSE Tumbleweed en la próxima actualización iso, y también se agregará a la versión beta inicial de la rama openSUSE Leap 15.5.

Antes de activar el repositorio predeterminado, para instalar componentes habilitados para H.264, el usuario simplemente necesita ejecutar:

sudo zypper ar http://codecs.opensuse.org/openh264/openSUSE_Leap repo-openh264
sudo zypper en gstreamer-1.20-plugin-openh264

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

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

DXVK 2.1 llega con correcciones y mas

DXVK

DXVK se puede usar para ejecutar aplicaciones y juegos 3D en Linux usando Wine

Se dio a conocer el lanzamiento de la nueva versión de DXVK 2.1 la cual llega solucionando problemas en algunos títulos de juego, asi como tambien la posibilidad de habilitar HDR, entre otras cosas más.

La nueva versión de DXVK requiere controladores compatibles con API Vulkan 1.3, como Mesa RADV 22.0, NVIDIA 510.47.03, Intel ANV 22.0 y AMDVLK. DXVK se puede usar para ejecutar aplicaciones y juegos 3D en Linux usando Wine, lo que sirve como una alternativa de mayor rendimiento a las implementaciones Direct3D 9/10/11 integradas de Wine que se ejecutan sobre OpenGL.

Principales novedades en DXVK 2.1

En la nueva versión que se presenta de DXVK 2.1 los sistemas compatibles con el espacio de color HDR10, es posible habilitar HDR configurando la variable de entorno DXVK_HDR=1 o especificando el parámetro dxgi.enableHDR=True en el archivo de configuración. Una vez que HDR está habilitado, los juegos pueden detectar y usar el espacio de color HDR10 si está instalado vkd3d-proton 2.8 o más reciente.

Cabe mencionar que de momento los principales entornos de usuario en Linux aún no son compatibles con HDR, pero la compatibilidad con HDR está disponible en el servidor compuesto de Gamescope y para habilitarlo, debe usar la opción «–hdr-enabled» (solo funciona en sistemas con GPU AMD cuando se usa Linux) kernel con josh-hdr parches -colorimetría).

Otro de los cambios que se destaca de la nueva versión es que la compilación de shaders fue mejorada. Para reducir el tartamudeo, el uso de bibliotecas de tuberías (pipeline) se ha extendido a tuberías con sombreadores de geometría y teselación, y cuando se usa MSAA, se usan características adicionales de la extensión Vulkan VK_EXT_extended_dynamic_state3.

Para los juegos más antiguos que admiten el suavizado de múltiples muestras (MSAA, Multi-Sample Anti-Aliasing), se agregaron las configuraciones d3d9.forceSampleRateShading y d3d11.forceSampleRateShading para habilitar el modo de sombreado de frecuencia de muestreo para todos los sombreadores, lo que le permite mejorar la calidad de las imágenes en los juegos.

El backend GLFW se ha agregado a las compilaciones de Linux, que se puede usar como una alternativa al backend SDL2.

Se mejoró la lógica de paso de comandos D3D11 para aproximar el comportamiento DXVK a los controladores nativos D3D11 y lograr un rendimiento más predecible

Problemas resueltos que aparecían en los juegos:

  • Ashes of the Singularity : regresión de rendimiento fija causada por una asignación de conjunto de descriptores subóptima.
  • Battlefield: Bad Company 2 : Parpadeo fijo
    Cardfight!! Vanguard : renderizado fijo
  • Gujian 3 : se corrigieron problemas de renderizado en algunas GPU.
  • Resident Evil 4 HD : se corrigió el uso no válido de Vulkan que causaba un bloqueo de GPU en RADV.
  • Saints Row: The Third : se solucionó un problema grave de rendimiento con la lluvia al usar el renderizador D3D9.
  • Sekiro: Shadows Die Twice : se corrigieron problemas de tartamudeo en las GPU de Nvidia.
  • Sonic Frontiers : se solucionó un error del juego que causaba que las sombras parpadearan cuando se conectaba a la GPU.
  • Supreme Commander: Forged Alliance : se corrigió un bloqueo después de cargar

Finalmente si estás interesado en conocer más al respecto sobre este nuevo lanzamiento, puedes consular los detalles en el siguiente enlace.

¿Cómo añadir el soporte de DXVK a Linux?

DXVK se puede usar para ejecutar aplicaciones y juegos 3D en Linux usando Wine, actuando como una alternativa de mayor rendimiento a la implementación de Direct3D 11 integrada en Wine que se ejecuta sobre OpenGL.

DXVK requiere de la última versión estable de Wine para ejecutarse. Por lo que, si no cuentas con este instalado. Ahora solo tendremos que descargar el último paquete estable de DXVK, este lo encontramos en el siguiente enlace.

wget https://github.com/doitsujin/dxvk/releases/download/v2.1/dxvk-2.1.tar.gz

Después de haber realizado la descarga ahora vamos a descomprimir el paquete recién obtenido, esto lo pueden hacer con desde su entorno de escritorio o desde la misma terminal ejecutando en el siguiente comando:

tar -xzvf dxvk-2.1.tar.gz

Después accedemos a la carpeta con:

cd dxvk-2.1

Y ejecutamos el comando sh para ejecutar el script de instalación:

sudo sh setup-dxvk.sh install
setup-dxvk.sh install --without-dxgi

Cuando se instale DXVK en un prefijo de Wine. La ventaja es que se puede usar Wine vkd3d para juegos D3D12 y DXVK para juegos D3D11.

Además, la nueva secuencia de comandos permite instalar la dll como enlaces simbólicos, lo que facilita la actualización de DXVK para obtener más prefijos de Wine (puede hacerlo a través del comando –symlink).

Como verán la carpeta de DXVK contiene otras dos dll para 32 y 64 bits estas las vamos a colocar de acuerdo a las siguientes rutas.
En donde “usuario” lo remplazas por el nombre de usuario que utilizas en tu distribución de Linux.

Para 64 bits las colocamos en:

~/.wine/drive_c/windows/system32/

O

/home/”usuario”/.wine/drive_c/windows/system32/

Y para 32 bits en:

~/.wine/drive_c/windows/syswow64

O

/home/”usuario”/.wine/drive_c/windows/system32/

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

He vuelto a usar Ubuntu tras cuatro años y estas han sido mis impresiones

Mirando a Ubuntu desde KDE

Mi historia con Ubuntu siempre ha sido la de una relación de amor/odio. Cuando lo probé por primera vez, su diseño y sus problemas para gestionar el audio eran los problemas, pero el rendimiento, velocidad y fiabilidad eran otro mundo comparado con Windows. Años más tarde se pasaron a Unity y es cuando empecé a hacer un «distro hopping» que me hizo mudarme a KDE (Kubuntu y Manjaro). Ahora, tras cuatro años, he estado trabajando con Ubuntu otra vez.

Este artículo es uno de esos de opinión, aunque esta vez son más impresiones. Todo lo que incluye es lo que el autor siente al usar Ubuntu tras haber pasado mucho tiempo en KDE, y ya os adelanto que me siento un poco como en la imagen de cabecera. También tengo que decir que lo tratado aquí es la versión principal, la que usa GNOME como entorno gráfico.

Ubuntu tiene un diseño que (casi) siempre me ha gustado

El diseño de Ubuntu me gusta. No siempre lo ha hecho, ya que a mí no me gusta que el panel de las aplicaciones esté a la izquierda ni llegue de parte a parte, pero eso se puede modificar desde hace unas cuantas versiones, con lo que podemos tener un dock muy estético a la parte de abajo. Por otra parte, tiene en la parte de arriba otro panel, uno al que me acostumbré cuando usaba macOS y está muy bien.

Sé perfectamente que en KDE puedo poner un dock y un panel superior de manera rápida y sencilla, pero ya estaría modificando por mi cuenta bastante de cómo es por defecto, y os lo creáis o no, no me gusta retocar demasiado las cosas. Puedo ser el único usuario de Linux que piense algo así, pero no retoco nada por defecto a no ser que sea necesario. Las manías no las curan los médicos.

Gestos del panel táctil que funcionan…

… sin sacrificar nada. Ya hace mucho tiempo que Ubuntu usa Wayland por defecto, y ya ha avanzado mucho en este apartado. KDE también tiene gestos, pero no funciona demasiado bien en Wayland, por lo que termino usando X11 y no puedo usar los gestos del panel táctil (sin instalar nada extra).

Y los gestos son algo que yo catalogaría como necesario ya en 2023. Si deslizando tres dedos a izquierda o derecha nos permite cambiar a otro escritorio, casi casi podríamos decir que tenemos dos monitores. Por ejemplo, me permiten ver una clase/tutorial/información en un escritorio virtual y tener Visual Studio Code en otro. Lo que con dos monitores haría moviendo el cuello, con esta función lo consigo deslizando de un lado a otro.

Y como digo, sin sacrificar nada. Viene de serie y Wayland se comporta bien en Ubuntu y en GNOME en general.

Mucho mejor en autonomía

Cuando uso Windows en mi portátil desde un SSD externo, he comprobado que la batería aguanta más. Como es algo que hago poco, al volver a KDE sencillamente lo uso y cargo el portátil cuando me lo pide, pero eso es algo que me pasa menos usando Ubuntu. En KDE, mi batería aguantará no mucho más de 2 horas, pero usando Ubuntu se acerca a las 5 horas, más o menos lo que se prometía cuando lo compré. Sorprendente, pero es más o menos lo que aguanta en Windows, por lo que parece que es KDE el que tiene un problema de autonomía, por lo menos en mi hardware.

Hay gente que recomienda hacer algunos retoques para mejorar el rendimiento de KDE, entre los que está desactivar Baloo, y me imagino que este tipo de cambios harán que también mejore la autonomía, pero ya son cambios que hay que hacer a la instalación por defecto.

Instalación de software en Ubuntu

Este punto es válido para Ubuntu y todos los X-buntu. Prácticamente cualquier software que está para Linux está en los repositorios oficiales de Ubuntu o como paquete .deb desde la página del desarrollador. Por ejemplo, VSCode, Chrome o Vivaldi están como paquetes .deb, y además añaden el repositorio oficial tras la primera instalación. Pero no todo es tan fácil de instalar.

Un ejemplo es BIMP, un complemento para GIMP que permite convertir imágenes en lote. Se puede compilar, pero es más fácil instalarlo en Manjaro, que se puede hacer desde su tienda de software (Pamac) y AUR. Como no he querido instalar todo lo que se me pide desde la página oficial, he solventado ese problema tirando de Converseen… hasta que actualicé mi propio «ConverMedia» escrito en Python para que también me permitiera redimensionar imágenes.

Información y soporte

Esto es de lo mejor cuando se usa Ubuntu o cualquier derivado en general. Cuando hay algún problema, casi todas las soluciones que hay por la red hablan de Ubuntu. Así, hacer funcionar algo como MySQL o usar una versión concreta de Python para que funcione en Kodi está a una búsqueda de distancia. Cuando usamos otras distribuciones, bueno, si no sabemos hacer algo tenemos que buscar algo más.

Aplicaciones (ay, WebP…)

Sin intención de hacer un spoiler, esto es lo que probablemente me hará seguir en KDE, aunque pase más tiempo en Ubuntu del que he pasado en los últimos 4 años. Gwenview permite hacer algunas ediciones de imágenes, e incluso anotaciones, y el visor de Ubuntu sirve… pues para visualizar imágenes. Lo mismo podríamos decir de programas como Okular, Ark o Kate: lo de KDE ofrece más posibilidades en general. Claro está, puedo instalar todo eso en Ubuntu, pero también librerías y dependencias que estarán de más si no se usa mucho más software de KDE.

Algo que duele más, por defecto, ya bien entrados en la tercera década de los 2000, Ubuntu no se lleva bien con el formato WebP. Ni siquiera lo reconoce como «imagen» el visor de imágenes, por lo que al hacer doble clic sobre este tipo de archivos nos abrirá el navegador. Hay maneras de hacer que el visor soporte este tipo de imágenes, pero estamos en lo de siempre: hay que añadir un repositorio de terceros…

¿Me vuelvo a Ubuntu o me quedo en KDE?

Pues me quedo en Manjaro KDE. Y vuelvo a Ubuntu. Voy a usar las dos cosas. Sigo prefiriendo KDE porque me parece que sus aplicaciones y fluidez son mejores, y Manjaro porque siento que me va mejor, pero Ubuntu me ha dejado un buen sabor de boca que no sentía desde no sé ni cuando. También es cierto que en las últimas versiones han mejorado mucho el rendimiento y que el equipo en el que lo uso tiene 32GB de RAM y un procesador i7, pero va realmente bien. Quién sabe si al final dejaré a la chica con cara de Manjaro-Kubuntu-KDE y terminaré pidiéndole una cita a la de cara Ubuntu-GNOME.

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

La primera edad de oro. Breve historia de la Inteligencia Artificial 4

Las décadas del 50 y 60 fueron extraordinarias para el desarrollo de la inteligencia artificial.
Aunque la idea de crear seres artificiales que hicieran cosas solo reservadas para los humanos siempre estuvo entre nosotros, solo en el siglo XX pudo comenzar a hacerse realidad. Una serie de acontecimientos ocurridos en los siglos XIX y XX confluyeron para que entre fines de la década del cuarenta y principios de la del 70 se diera lo que podríamos denominar la primera edad de oro de la Inteligencia Artificial.

Claro que lo de primera es un atrevimiento por mi parte.  Si bien los historiadores coinciden que fue una edad de oro, todavía no está claro de si lo que estamos viviendo ahora es la segunda.

La primera edad de oro

Para que se diera el espectacular auge de las investigaciones sobre Inteligencia Artificial a partir de la finalización de la guerra, se dieron una serie de condiciones. Como vimos en el artículo anterior desde el siglo pasado había una metodología que permitía expresar el razonamiento humano en forma de símbolos y realizar operaciones con ellos.

Los trabajos de Turing, Shannon y von Neuman por su parte, permitieron la aparición de equipos capaz de ejecutar instrucciones complejas. Solo faltaba el software.

Las redes neuronales

En un primer momento los investigadores intentaron construir hardware que simulara la estructura del cerebro con componentes eléctricos que cumplían la función de las neuronas. Para entender el comportamiento de estas se utilizaba el análisis matemático.

Dos investigadores, McCulloch y Pitts, publicaron un artículo en 1943 en el que explicaban cómo podían construirse mecanismos que emularan el comportamiento del cerebro.  Hoy se sabe que parte de su enfoque estaba equivocado ya que ellos creían que eran las neuronas individuales las que tomaban decisiones a partir de la información obtenida por los sentidos y generaban respuestas (En realidad se necesitan millones de ellas interactuando) si presentaron un análisis matemático bastante acertado sobre cómo se produce la transmisión de información entre neuronas.

El siguiente gran aporte llegó en 1949 de la mano de un fisiólogo de una universidad canadiense. Donald O. Hebb propuso la idea de que las conexiones neuronales no son inmutables. Cada vez que aprendemos algo nuevo la estructura neuronal cambia para fijar ese conocimiento. La explicación es que cuando una neurona provoca de manera seguida la activación de otra aumenta su conductividad lo que hace que sea más probable que se produzcan más activaciones estableciendo nuevas rutas de conexiones neuronales.

El cambio al segundo enfoque (En lugar de imitar la configuración del cerebro simular el mecanismo que le permite llegar a un resultado) vino de la mano de un señor llamado Marvin Minsky.

Minsky era un verdadero hombre del Renacimiento que se interesaba en disciplinas tan diversas como la Zoología y la Física pasando por la Psicología y la Matemática. Con otros dos investigadores construyó una red neuronal que simulaba la forma en que una rata aprendía cómo salir de un laberinto.

Pronto se dio cuenta que si bien «la rata» aprendía de sus errores era incapaz de utilizar su conocimiento para evitar cometer otros nuevos. De ahí que la tesis para su doctorado en matemáticas fuera sobre cómo construir redes neuronales más complejas capaces de planificar por anticipado.

El cambio de paradigma se produce en 1955 cuando Minsky conoce a Ray Solomonoff que estaba trabajando en una teoría sobre la inferencia deductiva.  A partir de su conversación comenzó a pensar que estaba siguiendo e camino equivocado. Que en lugar de crear hardware que imitara la composición del cerebro, lo mejor era tratar de deducir la forma en que el cerebro actúa y traducirlo a símbolos y relaciones que puedan ser procesados por cualquier computadora.

En 1956 se reunieron diez de los investigadores (Casi todos los que había sobre el tema) en un taller de dos meses. Además de Minsky estuvo presente el arriba citado Ray Solomonoff.

Solomonoff, en contra de la opinión mayoritaria de sus colegas sostenía que el estudio sobre la capacidad de los ordenadores para resolver problemas debería hacerse con los menos complicados ya que esto simplificaría el análisis de los procesos mentales intervinientes.

Con el tiempo se demostró que era un buen consejo por otro motivo. Las tareas que nuestro cerebro hace en forma automática como reconocer un rostro o conducir un vehículo son muy difíciles de reproducir en orma de pograma informático.

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

Experian Glitch Exposing Credit Files Lasted 47 Days

On Dec. 23, 2022, KrebsOnSecurity alerted big-three consumer credit reporting bureau Experian that identity thieves had worked out how to bypass its security and access any consumer’s full credit report — armed with nothing more than a person’s name, address, date of birth, and Social Security number. Experian fixed the glitch, but remained silent about the incident for a month. This week, however, Experian acknowledged that the security failure persisted for nearly seven weeks, between Nov. 9, 2022 and Dec. 26, 2022.

The tip about the Experian weakness came from Jenya Kushnir, a security researcher living in Ukraine who said he discovered the method being used by identity thieves after spending time on Telegram chat channels dedicated to cybercrime.

Normally, Experian’s website will ask a series of multiple-choice questions about one’s financial history, as a way of validating the identity of the person requesting the credit report. But Kushnir said the crooks learned they could bypass those questions and trick Experian into giving them access to anyone’s credit report, just by editing the address displayed in the browser URL bar at a specific point in Experian’s identity verification process.

When I tested Kushnir’s instructions on my own identity at Experian, I found I was able to see my report even though Experian’s website told me it didn’t have enough information to validate my identity. A security researcher friend who tested it at Experian found she also could bypass Experian’s four or five multiple-choice security questions and go straight to her full credit report at Experian.

Experian acknowledged receipt of my Dec. 23 report four days later on Dec. 27, a day after Kushnir’s method stopped working on Experian’s website (the exploit worked as long as you came to Experian’s website via annualcreditreport.com — the site mandated to provide a free copy of your credit report from each of the major bureaus once a year).

Experian never did respond to official requests for comment on that story. But earlier this week, I received an otherwise unhelpful letter via snail mail from Experian (see image above), which stated that the weakness we reported persisted between Nov. 9, 2022 and Dec. 26, 2022.

“During this time period, we experienced an isolated technical issue where a security feature may not have functioned,” Experian explained.

It’s not entirely clear whether Experian sent me this paper notice because they legally had to, or if they felt I deserved a response in writing and thought maybe they’d kill two birds with one stone. But it’s pretty crazy that it took them a full month to notify me about the potential impact of a security failure that I notified them about.

It’s also a little nuts that Experian didn’t simply include a copy of my current credit report along with this letter, which is confusingly worded and reads like they suspect someone other than me may have been granted access to my credit report without any kind of screening or authorization.

After all, if I hadn’t authorized the request for my credit file that apparently prompted this letter (I had), that would mean the thieves already had my report. Shouldn’t I be granted the same visibility into my own credit file as them?

Instead, their woefully inadequate letter once again puts the onus on me to wait endlessly on hold for an Experian representative over the phone, or sign up for a free year’s worth of Experian monitoring my credit report.

As it stands, using Kushnir’s exploit was the only time I’ve ever been able to get Experian’s website to cough up a copy of my credit report. To make matters worse, a majority of the information in that credit report is not mine. So I’ve got that to look forward to.

If there is a silver lining here, I suppose that if I were Experian, I probably wouldn’t want to show Brian Krebs his credit file either. Because it’s clear this company has no idea who I really am. And in a weird, kind of sad way I guess, that makes me happy.

For thoughts on what you can do to minimize your victimization by and overall worth to the credit bureaus, see this section of the most recent Experian story.

from Krebs on Security https://ift.tt/eYX4A2b
via IFTTT