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