Blender es la suite de creación 3D gratuita y de código abierto

Después de casi tres meses del lanzamiento de la actual versión estable de Blender 4.0, el equipo de desarrollo dio a conocer hace poco las próximas actualizaciones en las cuales ha estado trabajando, siendo las versiones 4.1 (en estado beta) y 4.2 (en estado alfa).

La actualización de la información de la beta de Blender 4.1, nos muestra un poco de las mejoras significativas en las cuales el equipo Blender ha estado trabajando a tan solo unos cuantos meses de haber lanzado la versión 4.0.

Y no es por de meritar el trabajo que mencionan en tan poco tiempo, sino al contrario, pues es de aplaudir la mención de un aumento del 5% en el rendimiento en Linux, además del soporte para renderizado utilizando APU AMD Ryzen basadas en la arquitectura RDNA3.

Principales avances en la beta de Blender 4.1

En las notas de lanzamiento en la página de desarrolladores de Blender, se destacan ya los diversos cambios que se han realizado hasta el momento en esta beta de Blender 4.1 y entre las características notables se encuentra el soporte para OpenImageDenoise, una biblioteca abierta para filtros de eliminación de ruido de alto rendimiento en imágenes renderizadas mediante Ray Tracing. Esta funcionalidad es compatible con sistemas NVIDIA GeForce GTX 1600 y todas las series RTX, chips AMD basados en las arquitecturas RDNA2 y RDNA3, procesadores Intel Arc y la serie M de Apple (requiere MacOS 13 o posterior).

Además, Blender 4.1 Cycles ahora admite la renderización utilizando los chips gráficos integrados basados en RDNA3 de AMD, como los presentes en los modelos Ryzen 7000G y Ryzen 8000G y que se ha introducido la capacidad de desactivar la corrección del mapa de relieve, y se ha mejorado el rendimiento en un 5% en Linux y sus derivados.

Otra de las mejoras notables es en el modelado con el cambio en la opción «Suavizado automático». Ahora, en lugar de esta opción, se ha introducido un recurso de grupo de nodos modificadores. Esto significa que el estado base de las mallas es equivalente a tener activado «Auto Smooth» con un ángulo de 180 grados en versiones anteriores.

Por otra parte, se han agregado nuevos íconos para representar la división, unión e intercambio de áreas, se ha mejorado la indicación y retroalimentación del cursor del selector de color, se han realizado mejoras en el dibujo del marcador de animación y el redondeo de esquinas para menús y bloques emergentes y los editores de métodos de entrada (IME) ahora son compatibles con Wayland.

De las demás mejoras en Blender 4.1:

• Se agrega una configuración de «simplificación» de renderizado que permite desactivar el cálculo de esquinas de la cara y normales personalizadas en la ventana gráfica.
• Las teclas de forma ahora pueden bloquearse para protegerlas de ediciones accidentales en modo de escultura o edición.
• Las normales de las esquinas de las caras se almacenan en caché y se recalculan en menos casos.
• La creación de mapas de topología de malla utilizados en nodos de geometría y cálculo de normales está paralelizada y es hasta 5 veces más rápida.
• Se ha mejorado la calidad del menú y las sombras de los bloques emergentes.
• Ahora, el Image Editor permite rotar imágenes en incrementos de 90 grados.
• El Image Vectorscope tiene una apariencia actualizada y la capacidad de mostrar un alcance de luma o teñido.
• El operador Desagrupar ahora desagrupa todos los nodos del grupo seleccionados en lugar de solo el activo.
• Se ha mejorado la selección de sockets al crear enlaces de nodos para reducir la cantidad de clics erróneos.
• Se puede hacer doble clic en la colección Outliner para seleccionar todos los niños.
• Ahora se pueden aplicar modificadores desde el esquema.
• El modo Caminar ahora admite subida/bajada relativa.
• Se ha mejorado el resaltado de borde de malla y el contraste para superposiciones de texto.
• Se ha añadido texto sombreado para los atributos del Visor de nodos de geometría.

Para los interesados en poder dar un vistazo a las versiones alfa y beta ya están disponibles para pruebas descargando el software desde el siguiente enlace. Cabe mencionar que se espera que la versión final de Blender 4.1 se lance el 19 de marzo, mientras que la versión 4.2 de Blender su lanzamiento está previsto para el 16 de julio.

Si estás interesado en poder conocer más al respecto, pues consultar los detalles en el siguiente enlace.

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

Justo hoy hablábamos de un sistema inmutable, el Ubuntu Core Desktop, para confirmar que no llegará este abril y puede que tampoco durante 2024. Por su parte, Fedora ha anunciado Fedora Atomic Desktops, una nueva familia de spins que pretende aprovechar el tirón de Silverblue para ofrecer un grupo de opciones inmutables de la popular distribución Linux. En redes sociales, como Mastodon, usan la palabra «newish», lo que no es más que otra manera de decir que es nuevo… más o menos.

La base de la historia o el actor protagonista es Silverblue. En los últimos meses ha ganado en popularidad, y debido a ello otras spins han dado un paso al frente y han ofrecido una versión que implementa rpm-ostree. Según explican, se ha llegado a un punto en el que es difícil hablar de ellos al mismo tiempo. Por lo tanto, la decisión ha sido fácil: crear una nueva marca que servirá para hablar sobre el tema y los futuros spins «Atomic».

Fedora Atomic Desktops incluye viejos conocidos

El proyecto Atomic empezó hace ya 10 años, pero no fue hasta 2018 que se lanzó Fedora Atomic Workstation, una implementación de cliente de escritorio que más tarde se convertía en Silverblue. En 2021 llegó Kinoite, y ya más recientemente Sericea y Onyx. El catálogo de los Fedora Atomic Spins quedaría así:

• Fedora Silverblue.
• Fedora Kinoite.
• Fedora Sway Atomic (lo que era Fedora Sericea).
• Fedora Budgie Atomic (lo que era Fedora Onyx).

El motivo de haber creado una marca es porque se espera que se sumen más spins a la lista. En la actualidad hay 4 más que aún no tienen variante Atomic, entre las que destaca Vauxite con Xfce. También esperan que entre en la familia otras con Pantheon (escritorio de elementary OS) o COSMIC (de Pop!_OS).

Es bueno tener una marca para facilitar las conversaciones; sin ella, es difícil referirse a algo en concreto. Por otra parte, se gana en precisión:

«En tercer lugar, este bonito término de marca es también una forma más precisa de hablar de cómo funciona rpm-ostree. Los spins atómicos de Fedora no son realmente inmutables. Hay formas de evitar los aspectos de sólo lectura de la implementación aunque es mucho más difícil. La naturaleza del sistema operativo, donde las actualizaciones sólo se implementan cuando se construyen exitosamente y se puede hacer rollback o rebase entre sistemas centrales anfitriones, se describe mejor por atomicidad que por inmutabilidad. Atómico es también como muchos de los colaboradores que trabajan en rpm-ostree prefieren hablar de ello. Rebranding proporciona una oportunidad para cambiar el lenguaje que rodea a esta tecnología«.

Los spins más populares mantienen su nombre

La marca Atomic acompañará a lo nuevo que vaya llegando, pero Silverblue y Kinoite mantienen su nombre. No tendría mucho sentido cambiárselo a algo que ya es reconocible, y haciéndolo sólo se generaría confusión. ¿Os imagináis que lo cambian y alguien encuentra este artículo o uno de los muchos vídeos que hay por la red? El caso de Onyx y Sericea es diferente. Son opciones mucho más nuevas y no habrá tanta confusión.

En el el futuro, los nuevos spins Atomic recibirán el nombre de Fedora «DE-nombre Atomic», y por poner unos ejemplos, podrían llegar algún momento no muy lejano Fedora Deepin Atomic o Fedora Cinnamon Atomic.

Qué es un sistema rpm-ostree

En un sistema rpm-ostree como los de la familia Fedora Atomic Desktops, el sistema de archivos raíz se compone de árboles de archivos inmutables generados a partir de paquetes RPM. Estos árboles de archivos son solo lectura y se pueden actualizar de forma atómica mediante la aplicación de un nuevo árbol. Esto permite actualizaciones consistentes y reversibles del sistema, lo que es útil para entornos de producción y contenedores. Dicho de otro modo, parte importante de su filosofía es la inmutabilidad.

Por supuesto, estos spins coexistirán con las versiones normales, es decir, las que gestionan el software con RPM. La más reciente es Fedora 39 y llegó el pasado noviembre.

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

Logo de Xfce

Los desarrolladores de Xfce han actualizado su página con planes para agregar soporte para el protocolo Wayland. El plan ahora incluye la implementación inicial del soporte para Wayland en los componentes principales de la próxima versión importante de Xfce 4.20, manteniendo simultáneamente el soporte para X11, y es que anteriormente, hubo discusiones sobre mantener la compatibilidad con versiones anteriores de X11, pero ahora se ha decidido que el soporte para X11 no se suspenderá en el futuro.

En la actualización de información realizada, los desarrolladores de Xfce mencionan que la sesión basada en Wayland en Xfce 4.20 abordará el conjunto mínimo requerido de capacidades, con la intención de agregar gradualmente la funcionalidad que falta en futuras versiones. También se planea continuar perfeccionando el trabajo en un entorno basado en el protocolo Wayland en aplicaciones de usuario que ya han sido portadas.

Planes generales
Para Xfce 4.20, el plan es agregar soporte preliminar a Wayland a los componentes principales sin perder el soporte X11. Esto no significa que para el próximo lanzamiento importante una sesión de Xfce en Wayland ofrecerá todas las funciones existentes, pero esperamos que sea mínimamente utilizable. También tenemos la intención de seguir perfeccionando nuestras aplicaciones para que funcionen aceptablemente en Wayland (aquellas que ya funcionan o que se pueden hacer funcionar con poco esfuerzo).

Por la parte del escritorio, xfdesktop y el panel xfce4, se menciona que estas ya han sido portados a Wayland utilizando wlroots y continuarán siendo desarrollados como componentes lanzados de forma independiente, además de que el panel xfce4 ha sido probado con servidores compuestos Labwc y Wayfire, mientras que por la parte de los complementos de xfce4-panel la mayoría de ellos ya cuentan con el soporte para Wayland, pero se trabajara para que el panel sea un compositor Wayland hasta cierto punto, esto debido a que ya no puede usar GtkSocket/GtkPlug para ejecutar complementos como externos, ahora estos deben ejecutarse internamente (es decir como un solo proceso) por lo que la falla de un complemento hace que el panel falle.

Para abstraer el trabajo en Wayland y X11, se utiliza la biblioteca libxfce4windowing, que proporciona una capa de abstracción del subsistema de gráficos donde se implementan componentes de administración de ventanas (pantallas, ventanas, escritorios virtuales, etc.) que no están vinculados a un sistema de ventanas específico. La compatibilidad con X11 se implementa utilizando libwnck.

Ademas de ello se menciona que se ha llevado a cabo la portabilidad de los siguientes componentes a Wayland:

• exo
• libxfce4ui
• libxfce4util
• thunar
• xfce4-appfinder
• xfce4-settings
• xfconf
• xfce4-power-manager
• tumbler
• garcon
• thunar-volman
• xfce4-dev-tools

Sin embargo, la compatibilidad con Wayland aún no está disponible en el administrador de sesiones xfce4-session y en el administrador de ventanas xfwm4, aunque existe un port xfwm4 no oficial para trabajar con Wayland.

Las aplicaciones que han agregado soporte para Wayland incluyen: xfce4-terminal, mousepad, xfce4-notifyd, xfce4-taskmanager, xfce4-mixer, ristretto, catfish, xfburn, parole, xfmpc, xfce4-dict, gigolo y xfce4-panel-profiles.

Aunque no se espera que una sesión de Xfce en Wayland ofrezca todas las funciones existentes, se espera que sea mínimamente utilizable. Además, se planea continuar perfeccionando las aplicaciones para que funcionen aceptablemente en Wayland.

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

Aunque creo que no me equivoco cuando digo que la mayoría de usuarios de Linux preferimos tener todo el control sobre nuestro sistema operativo, también hay otro tipo de usuario que lo que quiere es sencillamente tener algo que funcione y poder usar ciertas aplicaciones. Para este tipo de persona existen cada vez más distribuciones inmutables, que son aquellas en las que podemos instalar software y hacer algunas modificaciones, pero mínimas para que no se rompa nada. Como ejemplos, SteamOS, como no, y Fedora Silverblue, a los que se le puede sumar Ubuntu Core Desktop.

El junio pasado tuvimos las primeras noticias sobre este proyecto, y pocos días después pudimos probar ese experimento. Poco más se supo hasta esta semana, cuando se ha confirmado que, aunque el plan inicial contaba con lanzar Ubuntu Core Desktop como parte de la familia Noble Numbat, al final no va a ser posible. El que esté esperando esta opción, tendrá que armarse de paciencia, ya que Tim Holmes-Mitra (vía OMG! Ubuntu!) dice que tampoco pueden dar ninguna fecha.

Ubuntu Core Desktop podría no llegar este año

«No se lanzará en 24.04 y, por desgracia, no puedo dar una fecha hasta que hayamos solucionado los problemas que necesitan resolución – queremos que la experiencia del usuario sea excelente y eso va a llevar tiempo«.

No se conocen los detalles sobre los problemas a los que se están enfrentando, pero tiene sentido que no quieran lanzar algo como esto si no ofrece una experiencia notable. Lo que ahora se conoce como Ubuntu Core Desktop está pensado para las personas que sólo quieren poder usar un sistema operativo sin quebraderos de cabeza, y se empezaría mal si la experiencia se ve mermada por los bugs.

Con mucha suerte, esos problemas se arreglan en los próximos meses y lanzan la nueva ISO en octubre, pero esto no está ni cerca de confirmarse. Ubuntu Core Desktop no pasará a ser la versión principal de Ubuntu, algo que podría preocupar a algunos usuarios del sistema de Canonical. Si no llega para 24.10, lo más probable es que tengamos versión inmutable de Ubuntu en abril de 2025.

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

El próximo 28 de febrero llegará Plasma 6.0, una actualización muy importante para el escritorio de KDE. Aunque yo no he experimentado fallos serios desde que subieron a Plasma 5, es posible que algo falle y plasmashell se cierre por completo. En ese momento veremos las aplicaciones, pero el panel inferior con Kickoff, por ejemplo, dejará de estar accesible. Ante un caso como el descrito o algo similar, ¿cómo podemos solucionarlo sin reiniciar el sistema operativo?

La mejor manera es hacerlo desde el terminal. El comando puede variar dependiendo de la versión de Plasma en la que estemos, y no era igual en KDE 4 que en Plasma 5. En la anterior versión del entorno gráfico se usaba el comando killall plasma-desktop && kstart plasma-desktop – ahí queda por si hay alguien que aún esté en esa versión -, pero a partir de la versión 5 se cambió el nombre del paquete a plasmashell. Los comandos quedarían así:

Reiniciar Plasma desde el terminal

Hay al menos dos maneras de reiniciar Plasma desde el terminal: con killall y con kquitapps5. El segundo no funcionará en Plasma 6, pero el primero es válido tanto para la v5.x como para la v6.x:

killall plasmashell && kstart plasmashell

El segundo quedaría así:

kquitapp5 plasmashell && kstart5 plasmashell

En el momento de escribir este artículo, por lo menos la orden kstart6 no existe, pero eso no significa necesariamente que no vaya a hacerlo nunca. Teniendo en cuenta que el primero funciona en ambas versiones, quizá merezca la pena recordar sólo ese.

Qué hacen estos comandos

• killal termina todos los procesos asociados con lo que le sigue, en este caso plasmashell.
• kquitapps5, o terminado en 6 si lo llegan a implementar, cierra la aplicación que le indicamos después, la misma que en el ejemplo anterior. Prácticamente hacen lo mismo, pero el primero es un comando de Linux y el segundo de KDE.
• kstart se usa para lanzar aplicaciones, y lo que hará es iniciar Plasma.

Todo junto y para resumir, lo que hacen estos comandos es cerrar Plasma, o terminar de cerrarlo del todo, y volverlo a abrir, lo que es reiniciar el entorno gráfico. Rápido y sencillo.

.barra {display: flex;justify-content: flex-end;height: 25px; background-color: #333;border-radius: 5px 5px 0 0;}.rojo, .naranja, .verde{width: 12px;height: 12px; position: relative;border-radius: 50%;top: 7px; margin: 0 3px;}.rojo{background-color: rgb(248, 82, 82); margin-right: 7px;}.naranja{background-color: rgb(252, 186, 63);}.verde{background-color: rgb(17, 187, 17);}.terminal{background-color: black !important; border-radius: 5px !important;}pre{font-family:monospace !important; padding: 0 10px 10px; line-height: 1.5em; overflow: auto; background-color: black !important; color: #0EE80E !important} code {background-color: black; padding: 2px 5px; border-radius: 3px; color: #0EE80E; font-family:monospace; white-space: nowrap;}

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

A finales de 2024, Nate Graham, de KDE, escribió un artículo que tituló «¿De verdad Wayland lo rompe todo?». En él nos explica, por resumir, que no es así, que no es culpa de Wayland que las cosas fallen. El protocolo está bien, y los fallos suelen experimentarse por el lado del otro programa. Esto podría llevarnos a un debate de todo, menos sencillo, pero por mi experiencia personal parece que es así. Mi única piedra en el pie se llama GIMP.

Vale, lo confieso: no todo va perfecto. Pero si funciona lo suficientemente bien como para que yo no use X11 más de una vez cada varios meses. Y en general es para probar y comprobar algunas cosas. Ahora mismo, mis únicas quejas sobre Wayland son los problemas con GIMP, los iconos de algunas aplicaciones… y creo que eso es todo.

Es que… GIMP sigue en GTK2

GTK son las siglas de GIMP Took Kit. Vamos, que es una biblioteca que empezó con el software que sigue en GTK2. GIMP 3 dará el salto a GTK3, pero no se sabe cuándo llegará. La versión más reciente es GIMP 2.10.36, y es el programa que más me fastidia. Para empezar, el icono no es compatible con el panel inferior de Plasma; si lo fijo, sólo sirve de lanzador, pero cuando se abre tengo dos iconos de GIMP, uno de ellos monocromático. Ya dentro del programa, el selector de colores me funciona desde la herramienta de texto, pero no en la del pincel o viceversa.

Son problemas molestos, pero lo peor para mí, que no sé si os habréis dado cuenta pero escribo en un blog, es abrir GIMP, editar una imagen, volver al navegador – base Chromium, da igual cuál – y, al pasar el cursor por el editor, ver como si estuviera arrastrando una imagen para subirla. Ya he aprendido a solucionarlo – arrastro una imagen de verdad y vuelve a su sitio -, pero no deja de ser un incordio.

Los iconos no siempre se ven en Wayland

El otro problema que no lo es tanto son los iconos de algunas aplicaciones. Por ejemplo, si tengo una aplicación en Python con interfaz en Qt, el icono de la aplicación en barra superior y gestor de tareas es el de Wayland, algo que también veo en otro software como GNOME Boxes.

Por lo tanto, ¿quién es el culpable de que algo no funcione? Aunque en mi caso podría decir que de los desarrolladores de aplicaciones, no todos están de acuerdo. Los de PCSX2 aseguran que el problema es de Wayland, y han llegado al punto de desactivar el soporte por defecto. Se quejan más de GNOME que de KDE, por lo que yo me inclino más a dejar la responsabilidad en el tejado de los desarrolladores, y, según esta queja, KDE está haciendo las cosas mejor que GNOME.

Lo que parece claro es que el futuro pasa por Wayland, e incluso GIMP terminará funcionando bien en este protocolo. Aún tendremos que esperar, pero merecerá la pena.

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

Linus Torvalds el padre de Linux

Linus Torvalds lanzó el domingo la tercera versión candidata del kernel Linux 6.8 (Linux 6.8-rc3). Pero antes de eso, en la lista de correo del kernel de Linux, hubo un acalorado debate entre Linus Torvalds y un colaborador del kernel de Google sobre los inodos en los sistemas de archivos de Linux.

Y es que muchos sabemos que Linus Torvalds no es alguien que se reserve sus comentarios y su temperamento es algo de temer, pues durante muchos años el padre de Linux no ha ganado fama solo por haber creado a Linux, sino que también es conocido por su estilo directo y a veces abrasivo que lanza sin pensarlo dos veces.

En esta ocasión, Linus Torvalds no dejo pasar la ocasión y criticó duramente y rechazó las propuestas del colaborador de Google, recordándole que el mundo ya no vive en los años 70 y que los sistemas de archivos han evolucionado mucho. El lenguaje fuerte y el tono utilizado por Linus Torvalds en su respuesta al colaborador recuerdan sus ataques frívolos pasados, por los que anteriormente se disculpó.

El debate se centró en el uso de «inodos» como identificadores únicos para los metadatos de un sistema de archivos. Un nodo de índice o inodo (contracción del inglés index y node) es un identificador único para un elemento específico de metadatos en un sistema de archivos. En otras palabras, un inodo es una estructura de datos que contiene información sobre un archivo o directorio almacenado en algún sistema de archivos. Los inodos han sido objeto de debate durante las últimas semanas, con intercambios «robustos» entre Linux Torvalds y un empleado de Google llamado Steven Rostedt.

“Irónicamente, una de las responsabilidades que pospuse para corregir eventsfs»Fue escribir esto sobre un grupo de apoyo para el agotamiento del personal de mantenimiento», dijo el empleado de Google. (El agotamiento de los mantenedores y contribuyentes es una gran preocupación en la comunidad de software libre y de código abierto. Las soluciones a este problema se debaten constantemente, pero las cosas no parecen estar avanzando. Esta situación amenaza la supervivencia de ciertos proyectos que podría acabar careciendo de contribuyentes.)

El debate comenzó en la lista de correo del kernel de Linux, donde se discutió la utilidad y la relevancia de los inodos como identificadores únicos para los metadatos de los archivos y directorios en los sistemas de archivos de Linux. Los inodos, una parte esencial de la estructura de los sistemas de archivos, han sido objeto de controversia en las últimas semanas.

«Dejen de complicar las cosas más de lo necesario». Y maldita sea, DEJA DE COPIAR FUNCIONES DE LA CAPA VFS. Fue una mala idea la última vez, y esta vez también es una muy mala idea. No soporto ese tipo de tonterías”. La principal crítica de Torvalds al enfoque de Rostedt es que el empleado de Google no entendió completamente el tema, lo que Rostedt reconoció más tarde. Pero mientras tanto, Torvalds lo había quemado de la siguiente manera: «copiaste esta función sin entender por qué hace lo que hace y, por lo tanto, tu código es basura».

En un intercambio de correos electrónicos, Torvalds expresó su frustración con el enfoque propuesto por el colaborador de Google, instándolo a comprender completamente el problema antes de proponer soluciones. Su crítica, aunque directa, refleja su compromiso con la excelencia técnica y su deseo de mantener los estándares de calidad del kernel Linux.

En la comunidad hay reacciones encontradas ante este enfrentamiento entre Torvalds y el empleado de Google. Torvalds es criticado por algunos, mientras que otros no ven ningún problema en estas declaraciones. Otro grupo intenta encontrar justificación a los comentarios del creador de Linux. «Torvalds es el punto focal de tantas cosas, supongo que es muy difícil ser educado y no agresivo», decían los comentarios.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles de las discusiones de la lista de correo sobre el kernel de Linux en los siguientes enlaces. Correo 1, Correo 2, Correo 3 y Correo 4

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

Logo de OPNsense

Se ha dado a conocer el lanzamiento de la nueva versión OPNsense 24.1 con nombre clave «Savvy Shark», versión en la cual se presenta las actualizaciones de OpenSSL 3, Suricata 7, varias conversiones MVC/API, una nueva función de configuración de ARP/NDP, la inclusión principal de los complementos os-firewall y os-wireguard, seguimiento CARP VHID para OpenVPN y WireGuard, servidor Kea DHCPv4 funcional con soporte HA y mucho más.

Para quienes desconocen de OPNsense, deben saber que es una bifurcación del proyecto pfSense, creado con el objetivo de formar un kit de distribución completamente abierto que pudiera tener funcionalidad a nivel de soluciones comerciales para el despliegue de firewalls y gateways de red.

A diferencia de pfSense, el proyecto se posiciona como no controlado por una sola empresa, ya que es desarrollado con la participación directa de la comunidad y tiene un proceso de desarrollo completamente transparente, además de brindar la oportunidad de utilizar cualquiera de sus desarrollos en productos de terceros, incluidos los comerciales.

Principales novedades de OPNsense 24.1  «Savvy Shark»

La versión 24.1 de OPNsense, apodada «Savvy Shark», continúa impulsando la innovación en el firewall de código abierto con varias actualizaciones y mejoras importantes. Aquí hay un resumen de las características y cambios más destacados:

1. OpenSSL 3 basado en ports: La nueva versión incluye OpenSSL 3, lo que proporciona mejoras en seguridad y rendimento. Esta version de OpenSSL 3.0 cuenta con el módulo FIPS y también OpenSSL ha cambiado a la licencia de Apache 2.0.

1. Suricata 7: Se ha actualizado Suricata a la versión 7, con soporte para el mecanismo de aislamiento de aplicaciones Landlock, que permite un proceso para crear entornos aislados seguros y  capacidad de detectar y guardar certificados TLS de clientes en el registro, entre otros.
2. Conversiones MVC/API: La página de descripción general y los componentes para configurar la puerta de enlace, NPTv6, ARP y NDP se transfirieron al marco MVC, lo que permitió implementar en ellos soporte para la gestión de API.
3. Nueva función de configuración de vecinos para ARP/NDP: Se ha agregado una nueva función que permite configurar vecinos para ARP/NDP de manera más eficiente.
4. Complementos os-firewall y os-wireguard: Se han incluido los complementos os-firewall y os-wireguard para mejorar la funcionalidad y seguridad del firewall.
5. Mejoras en OpenVPN y WireGuard: Se ha agregado soporte para seguimiento CARP VHID en conexiones OpenVPN y WireGuard. Además en OpenVPN ahora se permite la verificación OCSP opcional por instancia, también emite el nombre del dispositivo, se agregó una solución alternativa para redes net30/p2p menores que /29, asi como también una opción push «route-metric» opcional para instancias de servidor. El módulo WireGuard instalado de forma predeterminada utiliza el módulo de kernel FreeBSD 13.2 incluido y agregar soporte experimental para mapas de red.
6. Servidor Kea DHCPv4 funcional con soporte HA: Se ha mejorado el servidor Kea DHCPv4 para proporcionar soporte de alta disponibilidad (HA) y que permite administrar de forma centralizada la configuración de varios servidores DHCPv4 y DHCPv6.
7. Correcciones y actualizaciones menores: Se han realizado varias correcciones y actualizaciones de terceros para garantizar la confiabilidad y la seguridad del sistema.

Algunas de las correcciones y actualizaciones incluyen mejoras en el sistema, la interfaz de usuario, el firewall, WireGuard, DHCP, IPsec, OpenVPN, os-haproxy 4.2, os-nrpe actualizado a NRPE 4.1.x, os-postfix actualizado a Postfix 3.8.x, php 8.2.15, py-duckdb 0.9.2 y optimizaciones en el backend. Además, se han actualizado varios complementos y puertos para mantener el sistema actualizado y seguro.

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

Descargar la nueva versión de OPNsense 24.1  «Savvy Shark»

Si quieres obtener esta nueva versión solamente debes de dirigirte a su página web oficial y en la sección de descargas en donde podrás encontrar la imagen compilada en forma de LiveCD y una imagen del sistema para escribir en unidades Flash en el siguiente enlace.

El código fuente de los componentes de la distribución, así como las herramientas utilizadas para la construcción, se distribuyen bajo la licencia BSD.

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

Screenshot de Damn Small Linux 2024

Se ha dado a conocer el lanzamiento de la nueva versión de «Damn Small Linux 2024», la cual marca el regreso de esta distribución después de 12 años desde su última versión de prueba y 16 años desde la formación de la última versión estable. Diseñado específicamente para sistemas de bajo consumo y equipos obsoletos, esta nueva versión está en calidad alfa y está disponible en compilaciones para la arquitectura i386.

Para quienes desconocen de Damn Small Linux, deben saber que esta se posicionó como una distribución de Linux ligera y versátil que proporciona una solución eficiente y funcional para una variedad de escenarios de uso, especialmente aquellos que involucran hardware antiguo o recursos limitados.

Debido al estado de abandono que presento la distribucion durante casi 12 años, se pensó que el desarrollo del proyecto había muerto y la distribucion pasaría a la historia. Pero esto ha cambiado con el reciente lanzamiento de la nueva versión de «Damn Small Linux 2024» impulsada por la necesidad de una distribución Live compacta adecuada para sistemas heredados y de bajos recursos y como tal busca proporcionar una solución Live compacta que quepa en un CD estándar (menos de 700 MB) y que ofrezca entornos gráficos y dé consola adecuados para el trabajo diario.

Principales novedades de Damn Small Linux 2024

El lanzamiento de esta nueva versión de Damn Small Linux 2024 llega construido sobre la base de AntiX 23 Live, que a su vez se fundamenta en la base del paquete Debian, el renacimiento de Damn Small Linux proporcionan dos opciones de administradores de ventanas: Fluxbox y JWM.

Las características principales de Damn Small Linux incluyen:

1. Tamaño reducido: La distribución está diseñada para ser lo más pequeña posible, lo que significa que puede ejecutarse desde medios de almacenamiento muy limitados, como CD-ROMs, unidades USB o incluso tarjetas CompactFlash Con un tamaño de conjunto de arranque de 666 MB, esta versión es considerablemente más grande que su predecesora, que tenía un tamaño de solo 50 MB.
2. Eficiencia en recursos: Damn Small Linux está optimizada para ejecutarse en sistemas con recursos limitados de memoria RAM, CPU y espacio en disco. Esto la hace adecuada para revitalizar hardware antiguo o para dispositivos con requisitos de hardware mínimos.
3. Entorno gráfico: A pesar de su tamaño reducido, Damn Small Linux se envia con dos administradores de ventanas: Fluxbox y JWM. Ambos son livianos, bastante intuitivos y fáciles de usar
4. Conjunto de aplicaciones: con una variedad de aplicaciones útiles, Damn Small Linux 2024 cuenta con tres navegadores web «BadWolf, Dillo y Links2», los clientes de correo electrónico Sylpheed y Mutt, AbiWord como editor de texto, Gnumeric como procesador de hojas de cálculo y Zathura como visor de PDF. Para el contenido multimedia, se incluyen MPV y XMMS. La distribución también cuenta con mtPaint como editor gráfico, zzzFM como administrador de archivos, gFTP como cliente FTP/SFTP y Leafpad como editor de texto.
   Entre las aplicaciones de consola se encuentran Ranger como administrador de archivos, VisiData como procesador de hojas de cálculo, Tmux como multiplexor de terminal, Mutt como cliente de correo electrónico, Cmus como reproductor de música, CDW como programa de grabación de CD/DVD, SurfRaw como sistema de búsqueda, y los editores de texto Vim y Nano, así como los navegadores W3M y Links2.
5. Flexibilidad y personalización: A pesar de su pequeño tamaño, Damn Small Linux es altamente personalizable y se puede adaptar a las necesidades específicas del usuario. Los usuarios avanzados pueden agregar o quitar aplicaciones según sus preferencias y requisitos. Además de que utiliza el instalador básico de Calamares para la instalación y cuenta con soporte de escritorio LIVE.

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

Descargar y obtener Damn Small Linux 2024

Para los interesados en poder probar esta nueva alfa de Damn Small Linux 2024, deben saber que el tamaño de la imagen ISO es de 666 MB para ser precisos, poco menos para caber en un solo CD, que probablemente ya nadie utilice las unidades de CD para la instalacion de una distribucion.

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

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

Hace poco se dio a conocer información sobre una vulnerabilidad que afecta a la biblioteca C estándar Glibc, catalogada bajo «CVE-2023-6246» y una puntuación de 8.4 en la escala CVSS, fue identificada por investigadores de Qualys.

La vulnerabilidad CVE-2023-6246 permite la manipulación del inicio de aplicaciones SUID para ejecutar código con privilegios elevados y se origina en un desbordamiento de búfer en las funciones «vsyslog_internal()» utilizadas al llamar a las funciones «syslog()» y «vsyslog()».

Sobre CVE-2023-6246

Este problema se produce debido a un error al intentar generar un nombre de aplicación que es demasiado largo a través de la macro SYSLOG_HEADER. Al intentar expandir un búfer basado en un nombre largo, se produce un desbordamiento, lo que resulta en la escritura de datos en el búfer original de tamaño más pequeño.

Las vulnerabilidades identificadas en las funciones syslog y qsort de glibc resaltan un aspecto crítico de la seguridad del software: incluso los componentes más fundamentales y confiables no son inmunes a las fallas. Las ramificaciones de estas vulnerabilidades se extienden mucho más allá de los sistemas individuales y afectan a muchas aplicaciones y potencialmente a millones de usuarios en todo el mundo. Este artículo pretende arrojar luz sobre la naturaleza específica de estas vulnerabilidades, sus posibles impactos y las medidas adoptadas para mitigarlos.

Al organizar un ataque a través de la utilidad SU, un atacante puede cambiar el nombre del proceso cuando se inicia la aplicación reemplazando el valor argv[0], que se utiliza para obtener información sobre el nombre del programa al enviar al registro y lograr un control de sobrescritura de datos fuera del búfer asignado. Luego, el desbordamiento se puede utilizar para sobrescribir la estructura nss_module en la biblioteca nss para crear una biblioteca compartida y cargarla como root

El problema ha estado presente desde el lanzamiento de glibc 2.37, publicado en agosto de 2022, el cual incluyó un cambio para manejar la situación de intentar escribir mensajes demasiado grandes. La solución se actualizó a glibc 2.36 y a los paquetes de distribución con versiones anteriores de glibc porque abordaba la vulnerabilidad mientras se solucionaba una vulnerabilidad diferente y menos grave. Resultó que solucionar una vulnerabilidad no peligrosa provocó la aparición de un problema crítico. Es notable mencionar que en 1997 se informó de una vulnerabilidad similar en la función vsyslog() de la biblioteca libc 5.4.3.

El descubrimiento de vulnerabilidades en las funciones syslog y qsort de la biblioteca GNU C plantea importantes preocupaciones de seguridad. 

Los investigadores de Qualys que descubrieron la vulnerabilidad probaron varios sistemas de instalación populares basados en Linux y confirmaron que varios de ellos eran vulnerables, como Debian 12/13, Ubuntu 23.04/23.10 y Fedora 37-39.

Para demostrar la vulnerabilidad, los investigadores han desarrollado un exploit funcional que permite obtener derechos de root manipulando los argumentos de la línea de comando al ejecutar la utilidad SU. El exploit se demostró la capacidad de obtener derechos de root por parte de un usuario sin privilegios y se ejecuto bajo un entorno Fedora 38 completamente actualizado con todos los mecanismos de protección habilitados en la configuración predeterminada. La vulnerabilidad solo puede explotarse localmente, ya que requiere pasar más de 1024 bytes a través del parámetro argv[0] o el argumento ident a la función openlog().

Por la parte de la corrección de la vulnerabilidad, se menciona que ya se incluyó en el código base de Glibc y será parte de la actualización de Glibc 2.39, junto con las correcciones para dos vulnerabilidades más (CVE-2023-6779, CVE-2023-6780) que también afectan el código __vsyslog_internal() y provocan desbordamientos del buffer.

Además, Qualys advirtió sobre la identificación de un desbordamiento del buffer en la implementación de la función qsort(), que no fue clasificada por los desarrolladores de Glibc como una vulnerabilidad, ya que la explotación implica el uso de una función de comparación atípica como argumento al llamar a qsort, que devuelve la diferencia de los parámetros comparados.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar el estado de la vulnerabilidad en páginas: Debian, Ubuntu, SUSE, RHEL, Fedora, Arch Linux, Gentoo y Slackware

Fuente: https://blog.qualys.com

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