La biblioteca de gráficos IGL, ahora es de codigo abierto

Khronos dio a conocer hace poco mediante una publicación de blog que Meta (anteriormente conocido como la empresa Facebook) ha tomado la decisión de liberar el código de una nueva biblioteca de gráficos IGL (Biblioteca de gráficos intermedios), que proporciona una API universal de bajo nivel para controlar la GPU.

IGL se posiciona como una biblioteca de gráficos multiplataforma que proporciona a los desarrolladores un poderoso conjunto de herramientas para crear imágenes y gráficos de alta calidad en sus aplicaciones, ya sea un juego, una aplicación de modelado 3D o cualquier otro proyecto que requiera gráficos de primer nivel.

¡Meta se complace en anunciar el lanzamiento de nuestra nueva biblioteca de gráficos intermedios (IGL) de código abierto! En Meta, estamos comprometidos con la creación de estándares abiertos para gráficos 3D en asociación con la industria en general y el Grupo Khronos ^® . Después de meses de arduo trabajo y dedicación, estamos encantados de compartir nuestra última creación con la comunidad de desarrollo.

Se menciona que la API propuesta cubre la funcionalidad típica de GPU y le permite al desarrollador el poder crear aplicaciones multiplataforma que pueden ejecutarse sobre las API de gráficos OpenGL, Metal y Vulkan en sistemas Android, iOS, Linux, macOS y Windows.

La biblioteca también se puede usar para renderizar en la web mediante WebGL al compilar la aplicación en el código intermedio de WebAssembly. Para el renderizado, se proporcionan backends API para Metal 2+, OpenGL 2.x, OpenGL 3.1+, OpenGL ES 2.0+, Vulkan 1.1 y WebGL 2.0.

De las características clave que se destacan de IGL, se mencionan las siguientes:

• IGL es multiplataforma: como ya se menciono al inicio, IGL proporciona una biblioteca de shell, lo que permite a los desarrolladores el poder compilar y ejecutar en las plataformas más populares, incluidas Windows, Linux, Mac OS, iOS, Android y WebAssembly.
• Renderizado de alto rendimiento: IGL está optimizado para proporcionar un renderizado ultrarrápido, incluso cuando se trata de gráficos complejos y detallados.
• API fácil de usar: una API intuitiva y fácil de usar significa que IGL es simple y directo para trabajar. En lugar de introducir RHI como parte de la abstracción del motor de alto nivel o imitar una interfaz gráfica detrás de otra, IGL adopta un nuevo enfoque para abstraer RHI mediante la creación de una nueva interfaz moderna, que está cerca de Vulkan o WebGPU en la capa de abstracción, pero en general suficiente para evitar ser específico del motor.
• Sobrecarga mínima: IGL admite código de representación nativo nuevo o existente sin sobrecarga de interoperabilidad de lenguajes o la necesidad de otros tiempos de ejecución de lenguajes.
• Código abierto: IGL es completamente de código abierto y se puede utilizar para cualquier proyecto, comercial o de otro tipo, sin restricciones de licencia.

Si es un desarrollador de juegos con experiencia como si acaba de empezar con la programación de gráficos, nuestra biblioteca le ofrece las herramientas que necesita para crear imágenes sorprendentes en sus aplicaciones.

Como tal se destaca que la biblioteca es adecuada para desarrollar juegos, sistemas de modelado 3D y cualquier otro proyecto que requiera soporte de gráficos de alta calidad. El código IGL está optimizado para un rendimiento máximo incluso cuando se trabaja con modelos complejos y detallados.

La estructura de la API está diseñada teniendo en cuenta la facilidad de uso e implementa conceptos genéricos que comprenderán la mayoría de los desarrolladores familiarizados con una de las API de gráficos.

En términos de nivel de abstracción, IGL está cerca de Vulkan y WebGPU, pero al mismo tiempo, está libre de detalles vinculados a motores específicos. La biblioteca admite la conexión de extensiones, con las que puede integrar fácilmente funciones adicionales e implementar las necesidades emergentes no estándar de los desarrolladores.

Finalmente si estás interesado en poder conocer más al respecto, debes saber que el código de la biblioteca está escrito en C++ y se distribuye bajo la licencia MIT. Puedes consultar el código del proyecto en el siguiente enlace.

Puedes consultar los detalles de la nota en la publicación original en el siguiente enlace.

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

Hace unos meses, no recuerdo cuándo, circuló por Internet un meme que decía «Jenna Ortega tuvo que pasar» por X experiencia para prepararse para interpretar a Miércoles, de la familia Addams. La gracia estaba en añadir una experiencia dura que hizo que la joven y atractiva actriz se volviera lúgubre. Una de las experiencias duras que tuvo que pasar, según los memes, fue instalar Arch Linux sin hacer uso de ningún script, todo manual.

Y es que Arch Linux no es la distro más sencilla de instalar. Llega a tal punto que algunos de sus usuarios se vanaglorian de usar Arch Linux y no les hace gracia que exista Archinstall, que dicen que si necesitas algo así que elijas otra opción. Bueno, como el día en el que escribí el artículo sobre «Vuélvete a Windows», no todos los consejos que suenan mal son malos, y hay opciones con base Arch que tienen un instalador gráfico. Aquí va una lista con las 5 mejores opciones.

Las 5 mejores distros basadas en Arch con instalador

EndeavourOS: Arch Linux con instalador

Ahora mismo, una de las mejores opciones para el que quiere usar Arch Linux y no morir en el intento es EndeavourOS. Es el sucesor de AntergOS, y acaba de cumplir 4 años. Usa el instalador Calamares, y en el proceso nos permite elegir algunos paquetes, como incluir un kernel LTS o diferentes entornos gráficos. Usa Xfce por defecto.

EndeavourOS cuenta con soporte especial de hardware, entre lo que encontramos drivers de NVIDIA e imágenes ARM. Por otra parte, la comunidad es activa, por lo que es relativamente sencillo encontrar documentación para solucionar cualquier problema con el que nos podamos encontrar. Para muchos, ofrece la experiencia más cercana a usar Arch Linux si éste tuviera un instalador con interfaz gráfica.

EndeavourOS.

ArcoLinux: buena experiencia con diferentes tamaños

ArcoLinux es otra buena opción que viene con un entorno gráfico preinstalado, pero es diferente a otras distros. Ofrece opciones como la XL, que incluye todo lo del proyecto; la XS, que es una variante tipo «mínima»; la D que no tiene escritorio y otras con un kernel diferente, entre los que encontramos, por ejemplo, el ZEN. El entorno gráfico por defecto también es Xfce.

ArcoLinux.

Garuda Linux: Arch Linux para gamers

Garuda Linux es una distro basada en Arch pensada para los jugones. Nos permite usar prácticamente cualquier entorno gráfico o gestor de ventanas, y por defecto usa BTRFS como sistema de archivos, lo que mejora el rendimiento. BTRFS es para algunos el sucesor de EXT4, no tanto por sus similitides, sino porque es lo que se terminará usando en el futuro. Si se cumple o no es algo que tendremos que ver con el tiempo.

Como distro para el gaming, cuenta con opciones como soporte para Steam y Lutris con GameMode y Gamemode-Tools. El diseño tras la instalación de cero es muy vistoso.

Garuda Linux. Imagen, web oficial de Garuda.

Archcraft: ¿te gustan las instalaciones mínimas?

Archcraft es una distribución muy minimalista y ligera que puede funcionar con menos de 500Mb de memoria, gracias a las aplicaciones ligeras. Proporciona bspwm, LXDE, Openbox y Xfce como escritorios y también cuenta con soporte integrado para AUR. El escritorio que usa por defecto es Openbox, que está a medio camino entre gestor de ventanas y escritorio al uso.

Manjaro: gestión con herramientas gráficas y más

Cierra la lista Manjaro, del que se dice mucho que «Manjaro is not Arch». No es Arch porque tiene su propia filosofía, pero la base sí es la misma. Manjaro Stable es lo que obtenemos tras la instalación de cero, pero se puede cambiar la rama a las opciones Testing y Unstable, estando más cerca de Arch la última.

Entre sus puntos fuertes cuenta con Pamac, su propia herramienta para instalar software que está en versión CLI (línea de comandos) y GUI (interfaz gráfica). Otro software propio es Manjaro Settings, desde donde se pueden gestionar los usuarios y paquetes de idioma, pero lo mejor de esta herramienta de configuración es que nos permite elegir cualquier kernel, si es mainline, LTS, RC o de tiempo real, y también instalar drivers de código abierto o privativo.

Manjaro.

Otras distros basadas en Arch Linux, las menciones especiales

Basada en Manjaro existe Mabox (artículo relacionado), una especie de edición de la comunidad, pero que no guarda relación con el proyecto. También hay existe BlackArch, que es la distro basada en Arch para el hacking ético. Merece la pena una mención, pero no es la mejor opción para los usuarios menos expertos.

¿Crees que hay una distro basada en Arch Linux que merezca la pena ser mencionada en este artículo?

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

Godot 4.1 llega con muchas características nuevas

Luego de cuatro meses de desarrollo se dio a conocer el lanzamiento de la nueva versión del motor de juegos Godot 4.1, en el cual soluciona más de 900 problemas desde la version 4.0 y en la cual se ha mejorado la estabilidad, el rendimiento y los flujos de trabajo, entre otras cosas mas.

Para quienes desconocen de Godot, deben saber que este motor admite un lenguaje de trabajo de lógica de juego fácil de aprender, un entorno de diseño de juego gráfico, un sistema de implementación de juego con un solo clic, ricas capacidades de simulación de física y animación, un depurador integrado y un sistema de detección de cuello de botella de rendimiento.

Principales novedades de Godot 4.1

En esta nueva versión que se presenta de Godot 4.1 se destaca que la interfaz gráfica ahora tiene la capacidad de separar la documentación y los editores de secuencias de comandos, incluido el editor de sombreadores, en ventanas flotantes separadas para moverlos a otras pantallas. Se recuerda el diseño de las ventanas de la interfaz, lo que le permite volver a la misma disposición de ventanas después de cerrar y volver a abrir el editor.

Otro de los cambios que se destaca, es que se han añadido nuevas texturas 3D con ruido visual (NoiseTexture3D) para controlar la densidad de la niebla volumétrica y hacerla menos saturada en determinados lugares, o simular partículas que afectan al viento.

Se ha rediseñado por completo el algoritmo para evitar colisiones cuando se usa la navegación con IA, que no se ajusta a una sola superficie y ahora se puede aplicar tanto en 2D como en 3D. Se proporciona la capacidad de priorizar y definir capas que definen quién debe evitar a quién.

Se utilizó un algoritmo basado en hashes rápidos para determinar los elementos del árbol de nodos, lo que permitió acelerar varias veces las operaciones de agregar y eliminar nodos, que son las más importantes para garantizar un alto rendimiento de los juegos complejos que manipulan activamente los nodos. El costo de esta optimización fue ralentizar ligeramente las operaciones de nodo que se usan con poca frecuencia y aumentar el consumo de memoria de la clase base Node en aproximadamente un 10 %.

Ademas de ello, tambien se destaca que el backend de renderizado basado en la API de gráficos de Vulkan ahora incluye el almacenamiento en caché de los resultados de la compilación de canalizaciones de gráficos (pipeline), que complementa el almacenamiento en caché de sombreadores disponible anteriormente.

Tambien podremos encontrar en Godot 4.1 que se han propuesto varias soluciones para resolver el problema de colocar el modelo de atrás hacia adelante después de la importación: cambiando las direcciones de las cámaras delantera y trasera en el editor y agregando una bandera a la función look_at() para usar el espacio modelo como un guía para elegir una dirección.

Por otra parte, el lenguaje de secuencias de comandos GDScript implementa la capacidad de crear variables estáticas para compartir datos comunes de varias instancias de la misma secuencia de comandos, lo que elimina el uso de recursos y la carga automática. Para definir una variable estática, utilice la palabra clave estática antes de definir la variable al comienzo del script.

De los demás cambios que se destacan:

• Soporte rediseñado para la generación automática de documentación para clases nombradas.
• Se agregó la capacidad de especificar líneas de documentación junto a la definición de una variable o función, y no en la línea anterior.
• Se agregó soporte para crear nodos de sombreado y complementos de editor usando GDExtension.
• Se cerraron más de 900 informes de errores desde el lanzamiento de Godot 4.0
• Se agregó soporte para exportar matrices tipificadas y conjuntos de nodos asociados a la interfaz de inspección.
• Se agregó soporte experimental para el procesamiento de escenas de subprocesos múltiples.
• Se ha trabajado para abordar los problemas y limitaciones asociados con las descargas de subprocesos múltiples.
• Se han agregado opciones a la configuración del nodo para seleccionar el modo de procesamiento secuencial o paralelo.
• En el administrador de proyectos, para simplificar la navegación a través de una gran cantidad de proyectos, se agregó la capacidad de vincular etiquetas a proyectos y filtrar proyectos por etiquetas.
• El sistema de renderizado ha reelaborado la implementación del remolino de partículas que se usa en los juegos para crear los efectos de elementos dispersos.

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

Obtener Godot

Godot está disponible para descargar en esta página para Windows, Mac OS y Linux. También lo puede encontrar en Steam y itch.io.

El código del motor del juego, el entorno de desarrollo del juego y las herramientas de desarrollo relacionadas (motor de física, servidor de sonido, backends de renderizado 2D/3D, etc.) se distribuyen bajo la licencia MIT.

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

Las GPus de Imagination Technologies ya cuentan con el soporte de OpenGL 4.6

Hace poco se dio a conocer la noticia de que Imagination Technologies anuncio mediante una publicación de blog el soporte para la API de gráficos OpenGL 4.6 en sus GPU, implementado utilizando el controlador abierto Zink desarrollado en el repositorio del proyecto Mesa.

Se menciona que el soporte fue implementado de la mano de los desarrolladores de Collabora junto con los ingenieros de Imagination para realizar a implementación de Zink.

Collabora tuvo el placer de trabajar junto con los ingenieros de Imagination para hacer esto realidad, ¡y es muy gratificante poder mostrar ahora los resultados al mundo!

Los desarrolladores Collabora mencionan que esta es la primera vez que se ve que un proveedor de hardware confie en el controlador OpenGL-on-Vulkan Mesa lo suficiente como para eludir por completo un controlador OpenGL nativo y usarlo en un producto de envío.

Es maravilloso ver que Zink se puede usar de manera realista como un caballo de batalla, especialmente en una configuración de gráficos de alto rendimiento.

Sobre el controlador Zink, se menciona que este proporciona una implementación de OpenGL sobre Vulkan para habilitar OpenGL acelerado por hardware en dispositivos que solo admiten la API de Vulkan.

Se destaca que el rendimiento de Zink está cerca del rendimiento de las implementaciones nativas de OpenGL, lo que permite a los fabricantes de hardware no gastar recursos en implementar OpenGL en sus GPU y limitarse a admitir solo la API de Vulkan en ellas e implementar OpenGL a través de una capa. Imagination Technologies fue el primer fabricante en utilizar este esquema.

El soporte se ha logrado trabajando junto con los especialistas de código abierto en Collabora . Zink es una implementación de OpenGL® en capas, parte del proyecto Mesa de código abierto, que permite que el contenido de OpenGL® 4.6 se ejecute sobre un controlador Vulkan nativo. Para las GPU Imagination, esto es beneficioso para todos. Si bien OpenGL® ahora se usa con menos frecuencia por parte de los desarrolladores que prefieren las API más nuevas, como Vulkan y DirectX, debido a su popularidad anterior, existen numerosas aplicaciones heredadas que no funcionarían en el hardware de Imagination si no tuviéramos soporte a nivel de controlador. para su versión final. Brindar soporte para OpenGL® 4.6 a través de nuestros controladores Vulkan es una solución elegante que mantiene nuestra pila de gráficos simple.

Este proyecto ha sido uno de varios proyectos de código abierto de Imagination. Como empresa, valoramos la contribución que la tecnología de código abierto ofrece al ecosistema, lo que permite a los desarrolladores sobresalir en áreas específicas de diferenciación en lugar de reinventar la rueda cada vez.

La solución preparada se probó con éxito en el conjunto de pruebas CTS (Khronos Conformance Test Suite) y se encontró que era totalmente compatible con la especificación OpenGL 4.6. Este es el primer producto a base de zinc certificado oficialmente por Khronos.

De acuerdo con los criterios de Khronos, si se certifica otra implementación basada en Zink, el propio controlador Zink, como capa universal, será reconocido oficialmente como compatible con OpenGL 4.6. La obtención de un certificado permite declarar oficialmente la compatibilidad con los estándares gráficos y utilizar las marcas comerciales de Khronos asociadas a ellos.

Entre otros trabajos, Imagination Technologies destaca el desarrollo de un conjunto abierto de controladores para sus GPU basados ​​en la arquitectura Rogue. El conjunto incluye un controlador DRM (Direct Rendering Manager) para el kernel de Linux, un controlador con una implementación inicial de Vulkan 1.0 y un conjunto de firmware para la GPU.

El controlador Vulkan ya se ha comprometido con la corriente principal de Mesa, y el controlador DRM se está preparando para incorporarse al kernel de Linux. En el futuro, se podrá agregar compatibilidad con Zink a este conjunto y estará disponible una pila de gráficos completamente abierta para hardware de Imagination compatible con OpenGL y Vulkan.

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

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

El objetivo de activar la telemetría es el recopilar algunos datos de interés, con la finalidad de realizar mejoras a futuro

Hace pocos días, se dio a conocer la noticia de que Aoife Moloney del equipo de ingeniería de la plataforma comunitaria de Fedora y Michael Catanzaro del navegador Epiphany de Red Hat y el desarrollador de WebKitGTK sugirieron incluir en Fedora Workstation 40 un mecanismo de recolección de telemetría que tenga en cuenta los intereses de los usuarios para garantizar la privacidad.

Sobre la sugerencia, se menciona que se propone habilitar la telemetría por defecto para nuevas instalaciones y deshabilitar la telemetría antes de la primera transmisión de datos. Por la parte de usuarios que realizan un upgrade desde una versión anterior, la telemetría está desactivada de forma predeterminada.

Se menciona la recopilación de telemetría no depende del envío ya que la recopilación se realiza de forma predeterminada y la entrega comienza solo después de que el usuario muestra una página con la configuración de privacidad.

En el asistente de configuración inicial, el control deslizante de habilitación de telemetría está habilitado de forma predeterminada y, si el usuario no lo ha configurado como inactivo, el envío de telemetría se activa después de cerrar la página con la configuración de privacidad.

Si el usuario ha deshabilitado el control deslizante, los datos ya acumulados se eliminan y se deshabilita la recopilación de más datos. En caso de que el usuario rechace la entrada al asistente de configuración inicial, en el configurador de GNOME, el control deslizante de telemetría estará deshabilitado de forma predeterminada (sin habilitarlo explícitamente, las métricas se seguirán recopilando, pero no se enviarán).

Se planea que el proceso de transferencia de telemetría sea lo más transparente posible para la auditoría, y las métricas recopiladas se regularán en un conjunto separado de reglas que describirán qué tipos de datos se pueden recopilar y cuáles no. La comunidad tendrá la capacidad de supervisar la recopilación de datos para garantizar que no haya abuso, confidencialidad y cumplimiento de las reglas aceptadas.

Para el envío de datos se utilizará la tecnología de “telemetría ética” de Azafea implementada en la distribución Endless. Azafea manipula datos agregados sin crear perfiles de usuarios individuales y sin recurrir a servicios externos (como Google Analytics), agregadores y repositorios. La recepción y procesamiento de la información será realizada por servidores en la infraestructura del proyecto Fedora. El código del componente de procesamiento de telemetría de Azafea es abierto y, si lo desea, los usuarios pueden implementar un servidor para recopilar telemetría en sus propias instalaciones, por ejemplo, para acumular estadísticas con métricas adicionales sobre el funcionamiento de los sistemas en redes locales.

Aún no se ha determinado una lista detallada de métricas aceptables para la recopilación y se formará más teniendo en cuenta la opinión de la comunidad. Uno de los propósitos de incluir la telemetría es que Red Hat analice cómo Fedora Workstation satisface las necesidades de los desarrolladores de la nube.

De la información que se planea recopilar, también se mencionan estadísticas sobre clics del mouse, consejos con recomendaciones para instalar software en el software GNOME, datos sobre la frecuencia de acceso a los paneles y configuraciones en el configurador, información sobre el tiempo de arranque, tipos de unidades (HDD o SSD), modelos de portátiles y la configuración regional seleccionada.

Del lado del usuario, para la acumulación y envío de telemetría se utilizará los paquetes eos-metrics (interfaz D-Bus para registro de eventos de aplicaciones y servicios), eos-event-recorder-daemon(un proceso en segundo plano para recopilar y enviar telemetría) y eos-metrics-instrumentation (componentes para recopilar métricas individuales).

Se espera que la información recopilada sobre los sistemas brinde la oportunidad de comprender mejor las preferencias de los usuarios y tenerlas en cuenta al tomar decisiones relacionadas con el desarrollo de la distribución, priorizando el desarrollo y mejorando la usabilidad.

La propuesta aún no ha sido revisada por el FESCo (Comité Directivo de Ingeniería de Fedora), que es responsable de la parte técnica del desarrollo de la distribución de Fedora. La propuesta también puede ser rechazada durante el proceso de revisión de la comunidad

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

Sourcegraph se utiliza para buscar, explorar y comprender el código

El proyecto Sourcegraph, que desarrolla un motor para navegar a través de código fuente, refactorizar y buscar en código, a partir de la versión 5.1, abandonó el desarrollo bajo la licencia Apache 2.0 en favor de una licencia propietaria que prohíbe la replicación y venta, pero permite copiar y cambiar durante desarrollo y pruebas.

Para quienes desconocen de Sourcegraph, deben saber que esta es una herramienta de búsqueda de código e inteligencia de código que es compatible con todos los principales lenguajes de programación que indexa y analiza semánticamente grandes bases de código para que puedan buscarse en repositorios comerciales, de código abierto, locales y basados ​​en la nube Sourcegraph.

La búsqueda se puede implementar en varios repositorios y plataformas de alojamiento de código. La búsqueda puede ser literal, expresión regular o estructural. La sintaxis de búsqueda estructural tiene en cuenta el idioma y maneja las expresiones anidadas y las declaraciones de varias líneas mejor que las expresiones regulares.

Sourcegraph cambia de licencia

Originalmente, en las notas de la versión de Sourcegraph 5.1 indicaban que la edición abierta de Sourcegraph se había elsiminado a favor de la licencia de Sourcegraph Enterprise. Desde entonces, el texto ha cambiado para indicar que se han eliminado algunos de los productos de Sourcegraph y se han actualizado las licencias de los componentes relacionados con la búsqueda.

A partir de 5.1.0, el subconjunto de OSS limitado de Sourcegraph se eliminó y el código OSS de búsqueda de código se volvió a licenciar

Al mismo tiempo, componentes tales como complementos con entornos de desarrollo integrados y Cody AI Assistant quedaron en el repositorio bajo la licencia Apache 2.0, y su desarrollo continuó bajo una licencia abierta como parte del repositorio principal del proyecto propietario.

Sourcegraph también prometió publicar una publicación de blog explicando los motivos del cambio de licencia, citando la respuesta de un colaborador en su sistema de seguimiento de errores antes de esa publicación.

Cabe mencionar que el modelo de licencias de Sourcegraph seguirá centrándose en vender productos a empresas y ofrecer herramientas de código abierto a desarrolladores individuales. La edición de comunidad abierta de Sourcegraph no fue bien adoptada entre los desarrolladores, y el 99,9 % de las veces, los usuarios usaban una versión diferente de Sourcegraph Enterprise.

Ademas de que el mantenimiento en paralelo de dos productos relacionados, uno de los cuales no tiene demanda, se reconoce como inconveniente y un desperdicio de los recursos de los desarrolladores. Después de la renovación de la licencia, el código permaneció disponible públicamente (pero bajo una licencia propietaria), al igual que el proceso de desarrollo.

Los desarrolladores de Sourcegraph también seguirán involucrados en el desarrollo del motor de búsqueda de código abierto Zoekt y continuarán impulsando cambios en este proyecto. Como antes, las versiones gratuitas de Sourcegraph Enterprise están disponibles para desarrolladores individuales: con proyectos abiertos, puede usar el servicio en la nube sourcegraph.com de forma gratuita, y para trabajar con código cerrado, puede instalar Sourcegraph Enterprise en su servidor utilizando un plan de tarifas gratuito.

La edición comunitaria del asistente Cody AI, que ha sido solicitada por la comunidad, permanecerá bajo la licencia Apache 2.0. En su forma actual, el código de Cody permanece en el repositorio principal de Sourcegraph por ahora, pero pronto se moverá a un repositorio separado. El cambio también se puede considerar como la división de Sourcegraph en dos productos separados: un motor de búsqueda de código patentado y un asistente de codificación y codificación inteligente de código abierto (Cody).

El motor de Sourcegraph se puede utilizar como plataforma para revisar y navegar por el código fuente alojado en los repositorios de Git. Puede analizar llamadas a funciones arbitrarias y saltar a donde están definidas, ver otras llamadas a estas funciones en el código, ver el historial de cambios, discusiones relacionadas con funciones, documentación y mensajes de error. Sourcegraph también proporciona búsquedas de enlaces flexibles e información sobre herramientas para usar varios objetos.

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

Nginx Alias ​​​​Traversal sigue siendo un problema critico para muchos proyectos

Hace poco se dio a conocer la noticia de que algunos servidores con nginx siguen siendo vulnerables a la técnica «Nginx Alias ​​​​Traversal», que se propuso en la conferencia Blackhat en 2018 y permite el acceso a archivos y directorios ubicados fuera del directorio raíz especificado en la directiva «alias».

La esencia del problema es que los archivos para bloques con la directiva de alias se proporcionan adjuntando la ruta solicitada, después de hacerla coincidir con la máscara de la directiva de ubicación y cortando la parte de la ruta especificada en esta máscara.

El problema aparece solo en configuraciones con una directiva «alias», ya que en la configuración de Nginx, hay una directiva llamada ‘location’ que puede describir cómo se debe manejar el acceso a una URL en particular, y se usa a menudo para asignar direcciones URL a archivos en el servidor.

En el patrón que usa esta ubicación en combinación con el alias, es crítico cuando se cumplen las dos condiciones de ‘no poner una barra al final de la URL especificada por la ubicación’ y ‘poner una barra al final de la ruta especificada por el alias ‘ se cumplan. Se dice que la vulnerabilidad ocurrirá.

En la conferencia BlackHat 2018, Orange Tsai presentó su investigación sobre la ruptura de analizadores de URL. Entre otros hallazgos impresionantes, demostró una técnica descubierta en un desafío CTF de 2016 de HCTF, creado por @iaklis.

Para que la técnica sea aplicable, se deben cumplir las siguientes condiciones:

La locationdirectiva no debe tener una barra inclinada en su camino;
Una aliasdirectiva debe estar presente dentro del contexto de ubicación y debe terminar con una barra inclinada.

Para el ejemplo de una configuración vulnerable que se muestra arriba, un atacante puede solicitar el archivo «/img../test.txt» y esta solicitud coincidirá con la máscara especificada en la ubicación «/img», después de lo cual la cola restante «../ test.txt» se adjuntará a la ruta de la directiva de alias «/var/images/» y como resultado se solicitará el archivo «/var/images/../test.txt».

Por lo tanto, los atacantes pueden acceder a cualquier archivo en el directorio «/var», no solo a los archivos en «/var/images/», por ejemplo, para descargar el registro de nginx, puede enviar la solicitud «/img../log/nginx /acceso.log».

Un análisis de los repositorios en GitHub mostró que los errores en la configuración de nginx que conducen al problema aún se encuentran en proyectos reales.

Por ejemplo, se detectó la existencia de un problema en el backend del administrador de contraseñas de Bitwarden y podría usarse para acceder a todos los archivos en el directorio /etc/bitwarden (las solicitudes de /archivos adjuntos se emitieron desde /etc/bitwarden/attachments/), incluyendo la base de datos almacenada allí con contraseñas «vault.db», certificado y registros, para lo cual fue suficiente enviar solicitudes «vault.db», «identity.pfx», «api.log», etc.

Se menciona que la gravedad de esta vulnerabilidad puede fluctuar significativamente según el proyecto, desde un impacto insignificante hasta uno crítico. El grado de sus repercusiones está determinado principalmente por si el directorio expuesto contiene datos confidenciales que pueden facilitar ataques adicionales o resultar en la divulgación de información privada.

Como punto de partida en nuestra búsqueda de esta vulnerabilidad, elegimos explorar los repositorios populares de GitHub que mostraban este problema. Identificar esta vulnerabilidad específica en entornos con acceso al código fuente se vuelve significativamente más factible, principalmente debido a dos factores principales:

Detección: el uso de herramientas de análisis de código sencillas, como búsquedas de expresiones regulares, nos permite identificar de manera efectiva los archivos de configuración de Nginx potencialmente vulnerables dentro de estos proyectos.
Explotación: tener conocimiento del directorio de destino exacto al que se le ha asignado un alias nos permite configurar una instancia local, examinar los directorios con alias usando un shell local y determinar a qué archivos se puede acceder a través de la vulnerabilidad.

Cabe mencionar que el método también funcionó con Google HPC Toolkit, donde las solicitudes se redirigieron al directorio de interes para obtener una base de datos con una clave privada y credenciales, un atacante podría enviar consultas «secret_key» y «db.sqlite3».

Finalmente si estas interesado en poder conocer mas al respecto, puedes consultar los detalles en el siguiente enlace.

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

Aquí en LXA tenemos algunos artículos sobre Timeshift, una herramienta que sirve para hacer copias de seguridad de nuestro sistema operativo basado en Linux. En uno de ellos se explica qué es, y en otro cómo instalarlo en Linux. Ambos son artículos que podríamos etiquetar como de archivo, estando más actualizado el que nos habla del software y algo más obsoleto el de su instalación. Lo que no tenemos es un artículo que explique cómo usar el programa.

Como ya dijo mi compañero Isaac en su día, lo cierto es que Timeshift es un programa muy sencillo que básicamente es ir siempre hacia adelante, pero es comprensible hasta cierto punto ese temor que tienen algunos usuarios de zambullirse en cualquier charco que no conozcan. Por ese motivo, y porque acaban de publicar cómo actualizar a una nueva versión de Linux Mint y usar Timeshift es uno de los pasos recomendados, me he decidido a escribir este artículo.

Podría seguir el artículo hablando sobre cómo instalar Timeshift, pero me pasaría como a Joaquín y es probable que, pasados unos meses/años, ese apartado sólo sirva para confundir porque las cosas son diferentes. Yo sí puedo decir que en la actualidad está en los repositorios oficiales de Ubuntu o Manjaro, que ahora es parte del software de Linux Mint (es una XApp) y es el proyecto que lidera Clem Lefebvre quien se encarga de su mantenimiento. Si una distribución no ofrece el software en sus repositorios, la página de GitHub es esta, en la que se menciona que es una XApp. Los sistemas basados en Arch lo tienen en AUR.

Cómo usar Timeshift

Cómo hemos explicado, el uso de Timeshift es más bien ir hacia adelante una vez ya está instalado.

Siempre que lo abramos nos pedirá la contraseña, y tras introducirla podremos configurar cómo queremos que se hagan las copias.

Lo primero que veremos será el tipo de instantánea que queremos hacer. Haciendo clic en «Ayuda» veremos cómo es cada una. Tenemos que elegir lo que mejor se ajuste a nuestras necesidades. Leyendo como funciona cada una, parece que la opción BTRFS es más potente, pero tiene que usarse en una unidad formateada con ese formato.

Una vez dentro se verá algo como lo anterior, pero sin ninguna instantánea. El fondo de pantalla no os cambiará, tranquilos. A mí me ha cambiado porque he empezado con Linux Mint (para iniciar de cero) y luego he seguido en mi Manjaro. Para realizar la configuración haremos clic en su botón. Veremos algo como lo siguiente:

La primera pestaña es la del tipo de instantánea y es igual que la anterior, con la diferencia de que en esta ventana de configuración también podemos acceder al resto de parámetros.

La siguiente pestaña es la de la ubicación, es decir, dónde se harán las copias de seguridad. Seleccionamos la unidad en donde queremos las copias.

Desde la pestaña «Programar» programaremos las copias automáticas. Podemos elegir entre mensual, semanal, diaria, a cada hora o al iniciar el sistema operativo, y no son excluyentes. También podemos indicar el número que debe guardar de cada tipo de copia. Si ponemos que almacene 5 y se llega a ese tope, irá eliminando las más antiguas.

Desde Usuarios podremos indicar si se incluye en las copias el subvolumen @home.

Y por último, en Misc., en el momento de escribir este artículo podemos indicar cómo se muestra la fecha y la hora. Al hacer clic en Aceptar ya estará todo preparado. Si hemos indicado que haga copias automáticas, las hará como le hayamos indicado.

Botones de la pestaña principal

En la ventana principal tenemos los botones de:

• Crear: podemos crear una copia de seguridad manual cuando queramos.
• Restaurar: nos permitirá restaurar una copia de seguridad.
• Borrar: podremos borrar manualmente una copia.
• Examinar: nos abrirá un gestor de archivos para que podamos navegar por todo lo que contienen las diferentes copias.
• Configuración: es lo que hemos explicado más arriba.
• Asistente: iniciará el asistente de configuración.

Aunque todo es bastante sencillo, sí me gustaría explicar algo: las copias de seguridad se hacen iniciando un proceso, y en ocasiones no podremos, por ejemplo, apagar el equipo hasta que finalice o el mismo Timeshift haga lo necesario para parar la copia de seguridad. Puede que nunca lo notemos, pero es una posibilidad. Por otra parte, si no se hacen muchos cambios, las nuevas copias se hacen a partir de las anteriores, y examinar los cambios y añadirlos a una nueva copia puede ser cuestión de segundos.

Se use el software que se use, merece la pena tener siempre una copia de seguridad de nuestros archivos más importantes, y Timeshift es una de las opciones más sencillas y eficaces.

from Linux Adictos https://ift.tt/7IEv8fo
via IFTTT

Linux Mint 21.2 «Victoria» se puede descargar desde el pasado domingo. Para ser fieles a la verdad, se puede desde pocos días antes, pero el día 16 es cuando se hizo pública su disponibilidad. Cuando Clem Lefebvre o alguien de su equipo dice que hay disponible una nueva versión de Linux Mint, lo que está pasando es que ya se pueden descargar las nueva ISOs, pero aún no se puede actualizar. Ese momento llega días después.

Cuando he empezado a escribir este artículo aún no hacía ni una hora desde que la cuenta oficial de Linux Mint en Twitter había publicado el artículo con las instrucciones necesarias para actualizar a Linux Mint 21.2 «Victoria» desde versiones anteriores. El enlace es este, pero nosotros vamos a publicar la guía a nuestra manera y con capturas y texto en español; WordPress hará lo suyo y, como siempre, traducirá el artículo a otros muchos idiomas.

Cómo actualizar a Linux Mint 21.2

La siguiente guía no es más que un reflejo de la original. Hay pasos que se pueden omitir, pero todo lo explicado aquí es lo recomendado.

1. Crear una copia de seguridad. El proyecto recomienda usar Timeshift, herramienta que adoptaron hace unos años y que sirve justamente para hacer «snapshots» de nuestro sistema operativo. Para el que no entienda la palabra en inglés, son instantáneas o copias de seguridad, aunque si no usan «backup» es porque las «snapshot» no son exactamente lo mismo que un simple «respaldo». En este enlace explicamos cómo hacer copias con Timeshift.
2. Preparamos la actualización. Este paso es básicamente aplicar todas las actualizaciones que tengamos pendientes. Se puede hacer desde el centro de software o desde el terminal. Siendo una distro basada en Ubuntu, se puede usar sudo apt update && sudo apt upgrade. Finalizado el proceso, reiniciamos.
3. Actualizamos el sistema operativo. Esta parte, que es la importante, consta de algunos pasos propios.
   1. Si no salta automáticamente, vamos al menú de inicio, buscamos «gestor de actualizaciones» y hacemos clic en su icono del menú de inicio.

1. 2. Dentro del Gestor de actualizaciones, hacemos clic en «Recargar». Si aparece lo mismo que en la siguiente captura es porque nunca se había abierto el gestor; sólo hay que hacer clic en aceptar. No debe haber nada por actualizar. Si aparece algún paquete, lo actualizamos.

1. 3. Vamos al menú «Editar» y dentro a «Actualizar a Linux Mint 21.2 Victoria».

1. 4. Seguimos las instrucciones que aparecen en pantalla: en la primera ventana veremos un mensaje de introducción y sólo tenemos que hacer clic en «Siguiente»; en el segundo veremos las notas de esta versión; en el tercero hay un enlace para ver las novedades; en el cuarto hay una caja de verificación o checkbox que hay que marcar para poder continuar. Es el típico de que aceptamos los riesgos. Al hacer clic en «Aplicar» hay que poner la contraseña. Descargará los paquetes y los instalará; por último veremos lo que en la lista aparece como «Resumen», que básicamente es que el proceso ha finalizado con éxito.

1. 5. Reiniciamos para que todo surta efecto.

Disponible para 21 y 21.1

La primera frase de la guía indica que «ahora es posible actualizar Linux Mint 21 y 21.1 a 21.2«, por lo tanto, sólo están soportadas las versiones que empiecen por el número 21. Los usuarios que están en Linux Mint 20 o anteriores deben realizar el proceso tantas veces como sea necesario. Por ejemplo, los de Linux Mint 20 que quieran subir a 21.2 deben subir primero a la versión 21 que muestre el gestor de actualizaciones y luego a 21.2.

Lo recomendable sería subir a saltos lo más pequeños posibles, o dicho de otro modo actualizar cada seis meses. En el caso de que alguien prefiera quedarse más tiempo en una versión anterior, posible porque son todas LTS, lo único que hay que hacer es actualizar sólo los nuevos paquetes, olvidándose de la opción de Editar/Actualizar a Linux Mint X.

Para nuevas instalaciones, en nuestro artículo sobre la disponibilidad de Linux Mint 21.2 «Victoria» tenemos los enlaces para descargar las ISO, que recordamos que hay opciones Cinnamon, MATE y Xfce.

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

Ubuntu y todos sus sabores oficiales están disponibles en dos opciones: las normales o «interim» (provisionales) son las de ciclo normal, las que están soportadas durante 9 meses y se actualizan cada 6. Luego tenemos las LTS, que salen los abriles de los años pares, se actualizan cada dos años y están soportadas durante 5 o 3, dependiendo del sabor. Algo diferente pasa con Kubuntu, que las diferentes combinaciones nos permiten tener hasta 4 opciones diferentes.

Me gustaría explicar algo antes de seguir: aunque en este artículo vamos a hablar de Kubuntu, lo explicado aquí vale en su mayoría también para Ubuntu Studio y Lubuntu. Ubuntu Studio usa Plasma desde hace algunas versiones, y Lubuntu hace poco que ha creado su propio repositorio backports. A quien le interese más alguna de esas ediciones, a partir de aquí casi que podría sustituir la palabra Kubuntu por Lubuntu/Ubuntu Studio. Explicado esto, hay un Kubuntu para cada tipo de usuario.

Otra cosa que quisiera decir es que en el momento de escribir este artículo KDE lanza unas 3 versiones de Plasma al año, pero pronto lanzará 2, más o menos al mismo tiempo que GNOME y justo antes de las nuevas versiones de Ubuntu y Fedora.

Kubuntu LTS

La primera de las cuatro opciones es Kubuntu LTS. Es la opción más conservadora, la opción para los que prefieren software más probado y que recibirá más actualizaciones de mantenimiento. Salen cada dos años, y suelen usar una versión LTS de Plasma. No incluirá las últimas funciones, ni las últimas versiones de algunas aplicaciones, pero todo lo que hace lo hace de manera fiable.

LTS + Backports

Esta opción es un poco un unicornio, o bueno, no tanto, pero es que no es habitual. Hay ocasiones en las que KDE añade un repositorio backports especial para una versión LTS de Kubuntu concreta, y puede subir Plasma, Frameworks y Gear. Salvando las distancias, que pueden llegar a ser muchas, esto sería similar a lo que ofrece KDE neon: base LTS y el último software de KDE. Pero, insisto, no es normal que ofrezcan esta posibilidad ya que lo lógico es pensar que el que se queda en una versión LTS es porque no busca lo último de lo último.

Kubuntu Interim (ciclo normal)

Canonical se refiere a sus lanzamientos de ciclo normal como «interim», que se traduce al español como «provisional». Hay uno cada seis meses, en abril y octubre, y su soporte son esos seis meses más 3 de cortesía, para que nos dé tiempo a subir a la siguiente. En total, nueve meses de soporte.

Las versiones de ciclo normal llegan con el software de KDE que está disponible en el momento de la congelación de funciones, y suele usar, por ejemplo, las aplicaciones de diciembre más las tres actualizaciones correctivas en el lanzamiento de abril. El Plasma y Frameworks que incluyen es el que ha llegado a tiempo de la congelación, y no se actualiza aunque se haya lanzado una actualización de punto de la misma serie. Si se quiere software más nuevo, hay que esperar a la siguiente versión del sistema operativo.

Aquí me gustaría explicar algo sobre el cambio de ciclo de lanzamientos que llegará en cuanto Plasma 6 se estabilice. KDE lanzará esas dos versiones de Plasma al año, por lo que Kubuntu siempre tendrá la última versión del entorno gráfico de KDE, pero seguirá sin recibir actualizaciones de punto, a no ser que en Canonical cambien su filosofía. Es un dato importante porque hasta ese momento sí era habitual tener una versión de Plasma «pasada».

Interim + Backports

La última de las opciones es usar la última versión de Kubuntu y añadirle el repositorio backports. Es algo que se ha podido hacer desde ¿siempre?, pero esos dos lanzamientos de Plasma por año cambiarán un poco bastante las cosas. Si añadimos el backports ppa a una edición provisional de Kubuntu mientras KDE lanza tres versiones de Plasma al año y lanzan una nueva, Plasma dará un salto de versión, y esto no siempre puede dar el mejor de los resultados. Sin embargo, si ya estamos en la misma serie, lo único que se aplicará al entorno gráfico serán correcciones, por lo que es difícil que se experimenten fallos.

Por otra parte, y como antes de esos 2/año, Frameworks y Gear (apps) se actualizarán una vez al mes. Esta opción será la más actualizada de todas, superando al KDE neon propio del «equipo K», ya que usará el software más nuevo de KDE y la última base de Ubuntu, y seguiremos teniendo a Canonical detrás, para lo bueno y para lo malo. Esto último, lo del software más nuevo, podría no cumplirse siempre.

¿Cuál es tu opción preferida? ¿Prefieres la estabilidad de Kubuntu/Lubuntu/Ubuntu Studio LTS, la última versión con todo lo nuevo o algún punto intermedio?

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