Logo de SourceHut

Hace poco, los desarrolladores de la popular plataforma de desarrollo colaborativo «SourceHut» dieron a conocer un informe detallado sobre un incidente que resultó en una interrupción del servicio durante 7 días debido a un ataque DDoS prolongado, para el cual la infraestructura del proyecto no estaba preparada.

En su informe, detallan que durante la etapa inicial del ataque, los desarrolladores se vieron sorprendidos y no tuvieron tiempo suficiente para reaccionar y contrarrestar el problema en sus servidores, lo que llevó al bloqueo total del tráfico hacia los servidores de SourceHut por parte del proveedor ascendente.

Para quienes desconocen de la plataforma SourceHut, deben saber que esta se distingue por una interfaz única que se aparta de la apariencia de GitHub y GitLab, pero que se caracteriza por su simplicidad, velocidad y funcionamiento sin necesidad de JavaScript. SourceHut ofrece una amplia gama de funciones, incluyendo el trabajo con repositorios públicos y privados de Git y Mercurial, un sistema de control de acceso flexible, funcionalidad de wiki, generación de informes de errores, integración continua integrada, capacidades de chat, entre otras mas.

Sobre el ataque a SourceHut

Los desarrolladores mencionan que para garantizar la continuidad de SourceHut, se emplearon servidores distribuidos en tres centros de datos. El primero fue utilizado para la configuración de producción, el segundo para respaldo, y el tercero para realizar experimentos sobre la migración de la infraestructura a una implementación de servicio más escalable y resistente a fallos (dado que la versión de próxima generación de SourceHut estaba en desarrollo).

Aunque los servicios básicos se restauraron al tercer día, (algunos servicios permanecieron no disponibles del 10 al 17 de enero), se requirieron aproximadamente 9 horas para resolver el problema de acceso a los servidores en el centro de datos principal después del bloqueo inicial.

Sin embargo, los desarrolladores enfrentaron otra dificultad cuando, a la mañana siguiente, el ataque se intensificó y comenzó a afectar toda la subred, lo que llevó al proveedor a redirigir nuevamente el tráfico hacia la interfaz nula. Ante esta situación, los desarrolladores se vieron obligados a iniciar urgentemente la implementación de la infraestructura de SourceHut en otro centro de datos utilizando copias de seguridad. Solo después de 2 días lograron obtener una subred temporal para acceder a los servidores principales y continuar con la recuperación del servicio.

Para protegerse contra los ataques DDoS a nivel de red, se tomó la decisión de implementar un servidor intermedio en la red del proveedor de nube OVH, el cual proporcionaría protección contra este tipo de ataques. Todas las solicitudes se dirigirían inicialmente a este servidor y luego se reenviarían a la infraestructura de trabajo.

Sin embargo, durante la migración, surgieron dificultades inevitables, como errores en la restauración utilizando la utilidad rsync, problemas de configuración de red y dificultades con la redirección del tráfico, que debieron resolverse antes de que la protección DDoS en OVH estuviera completamente operativa. Durante este tiempo, los servidores en funcionamiento estaban expuestos al tráfico de ataques DDoS, lo que llevó al sistema de protección DDoS a identificar erróneamente los servidores como el origen del ataque.

A pesar de intentar contactar a Cloudflare y otros servicios de protección DDoS, el costo de la protección resultó prohibitivo. Sin embargo, los empleados de Cloudflare posteriormente ofrecieron protección gratuita como patrocinio para el proyecto SourceHut, aunque este ofrecimiento fue rechazado por los desarrolladores, que en ese momento ya habían avanzado considerablemente en la solución del problema por sí mismos.

Inicialmente, estaba previsto llevar a cabo la migración de la infraestructura de SourceHut de manera gradual durante un período de al menos un año, trasladando el proyecto a servidores en otro centro de datos. Sin embargo, debido a las circunstancias actuales, la migración tuvo que realizarse de manera urgente en un plazo de 7 días. Afortunadamente, todos los servicios de SourceHut fueron transferidos con éxito a otro centro de datos y la plataforma ha sido completamente restaurada.

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

Ayer, domingo en España, el equipo de desarrolladores que hay detrás del entorno gráfico que usan distribuciones como Ubuntu Budgie lanzó Budgie 10.9. Esta nueva versión ha llegado unos seis meses después de la versión anterior, y no parece tener una extensa lista de novedades. Es algo que se puede entender, ya que sí encontramos una muy importante, quizá no tanto en cuanto a funcionalidades, pero si en cuanto al tamaño de la misma.

En Budgie 10.9 se han hecho trabajo inicial para llevar algunos de sus componentes a Wayland, y es que se espera que en 2024 lancen una versión sólo para este protocolo gráfico, aunque también será posible seguir usando X11 si el usuario lo prefiere. En Linux todo es posible, si no de una manera, pues de otra.

Novedades más destacadas de Budgie 10.9

• Applet de Bluetooth rediseñado. Ahora proporciona una función de desconexión directa para dispositivos emparejados, indicadores del porcentaje de la batería y la posibilidad de enviar archivos. Entre otras cosas, ya no depende de gnome-bluetooth y ahora se comunica directamente con BlueZ y UPower a través de D-Bus.
• Se ha realizado trabajo para llevar varios applets y componentes de Budgie Desktop a una librería compatible: libxfce4windowing. Es algo creado por XFCE que intenta presentar conceptos de ventanas (pantallas, espacios de trabajo, etc) de una manera independiente. Soporta X11 a través de libwnck y varios protocolos de Wayland. Ya usan libxfce4windowing el applet de mostrar el escritorio, el cambiador de pestañas y el applet de espacios de trabajo.
• Nuevo budgie-session, un fork de gnome-session diseñado para proporcionar un gestor de sesiones estables para Budgie 10.x. Concretamente, es un fork de GNOME Session 44.x, y soporta código de sesión relacionado con X11 y ConsoleKit para BSD.

Budgie 10.9 ya está disponible, pero sólo su código. Esto quiere decir que las distribuciones ya pueden cogerlo y empezar a trabajar con él, y que los más entendidos pueden instalarlo en su sistema, pero no es lo más recomendado para la mayoría de usuarios. De hecho, sus desarrolladores recomiendan usarlo en opciones como EndeavourOS o Fedora, entre otras. El próximo abril estará en Ubuntu Budgie 24.04.

Más información en las notas de este lanzamiento.

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

Arti es un proyecto para producir una implementación integrable de los protocolos de anonimato Tor en Rust

El equipo de desarrollo de Tor ha dado a conocer hace poco el lanzamiento de la nueva versión de Arti 1.1.12, que continúa mejorando el soporte para la ejecución de servicios onion con un progreso significativo.

Para quienes desconocen de Arti, deben saber que este es un proyecto para implementar los protocolos de anonimato Tor en el lenguaje de programación Rust. A diferencia de la implementación C, que primero se diseñó como un proxy SOCKS y luego se adaptó a otras necesidades, Arti se desarrolló inicialmente en forma de una biblioteca modular integrable que puede ser utilizada por varias aplicaciones.

Una de las características distintivas de Arti es que aprovecha toda la experiencia acumulada en el desarrollo previo de Tor. Esto significa que se evitan problemas arquitectónicos conocidos, lo que hace que el proyecto sea más modular y eficiente desde su concepción. A medida que el código Rust alcanza un nivel de madurez que puede reemplazar por completo la implementación en C, los desarrolladores tienen la intención de otorgar a Arti el estatus de implementación principal de Tor y dejar de mantener la versión en C.

Principales novedades de Arti 1.1.12

La versión Arti 1.1.12 se destaca por llevar la implementación de servicios onion al punto de estar listo para pruebas y experimentación, ya que se menciona qué se necesita más trabajo para lograr una seguridad equivalente a la implementación de C tor.

Al mismo tiempo, algunas características para garantizar la privacidad y protección de los servicios onion aún no están listas, como la autorización del cliente, la protección contra ataques DoS y el mecanismo para evitar la detección de nodos Vanguard Guard, por lo que aún no se recomienda su implementación para implementaciones de producción.

Además de ello, se destaca que se han realizado cambios importantes, como la refactorización del código del administrador de claves para prevenir la creación de especificadores de clave inválidos, se han añadido nuevas características, como la posibilidad de detener, iniciar o reconfigurar servicios onion mientras Arti está en ejecución.

El equipo también ha trabajado en mejorar la documentación, corrigiendo errores en el código y brindando una guía más clara sobre cómo ejecutar un servicio onion, se han solucionado problemas de rendimiento y se han realizado limpiezas en el código para optimizar su funcionamiento.

De los demás cambios que se destacan de esta nueva versión:

• Arti ahora admite el protocolo ntor_v3 de enlace de extensión de circuito, que permite a los clientes enviar parámetros de circuito a los relés en sus rutas.
• Se corrigió un conjunto de errores que causaban que los servicios onion cargaran demasiados descriptores.
• Se mejoraron los informes de errores en la carga de descriptores. Asi como también de la creación de un registro de reproducción de las solicitudes entrantes para evitar ataques de reproducción.
• Se implementó una API para que los servicios cebolla informen su estado.
• Se añadió documentación sobre cómo ejecutar un servicio onion en formato doc/OnionService.md.
• Esta documentación también registra áreas donde falta implementación y señala áreas donde el proceso actual tiene mala usabilidad.
• Se corrigió un error que ocurría al intentar crear un descriptor de servicio onion para un período de tiempo que aún no había comenzado.
• Varias mejoras en el manejo de errores del editor de descriptores.
• Se añadió una CLI para conocer la dirección .onion de un servicio determinado.
• Se refactorizo el código de reconfiguración de alto nivel para que envíe una configuración a cada uno de los conjuntos de módulos, en lugar de codificar una lista de funciones para llamar

Finalmente, cabe mencionar que estos avances representan un paso adelante en la implementación de servicios onion, el equipo de desarrollo sigue comprometido con la mejora continua y la incorporación de características adicionales para garantizar la seguridad y la eficiencia de la plataforma.

Por último, es importante tener en cuenta que los desarrolladores advierten que la implementación aun está catalogada como experimental y la experiencia del usuario aún no cumple con todas las expectativas.

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

El pasado noviembre, aquellos que jugamos a títulos de PSP en un PC o móvil y queremos guardar un progreso general de lo que hacemos recibimos una buena noticia: el emulador por excelencia para juegos de la PlayStation Portable recibía soporte para RetroAchievements, entre otras cosas. Este fin de semana hemos tenido otro lanzamiento, y PPSSPP 1.17 introduce una novedad que había sido muy demandada por la comunidad: el soporte para un tipo de archivo que permitirá ahorrar espacio del disco duro.

Los juegos de PSP no son como los de las consolas clásicas (Nintendo, Master System, Super Nintendo…) ni recreativas. Los más pesados son algunos de los últimos, que hay alguno como Metal Slug que ronda o supera los 20mb. Pero los de PSP suelen pesar mucho más, habiendo algunos que rondan los 2GB. Si se tienen 10 así, las matemáticas nos dirán que el almacenamiento ocupará 20GB, pero será menos si en vez de ISO usamos el formato comprimido CSO. Lo que había pedido la comunidad es que se añadiera soporte para el formato CHD, y esa es la novedad más destacada del PPSSPP 1.17 que ha visto la luz este fin de semana.

Qué es el formato CHD que soporta ahora PPSSPP 1.17

CHD es un formato de compresión de discos que originalmente se usaba para comprimir discos duros de juegos de recreativas como MAME, pero más recientemente se ha empezado a usar para almacenar información de ISOs. La PSP, la consola, siempre ha soportado CSO, que es un formato de compresión sin pérdida y funciona en hardware real -la consola, vamos-, y el emulador permite usar este otro formato.

El motivo de añadir soporte para CHD es que comprime aún más las ISO, pero el equipo de desarrolladores de PPSSPP no se habría decidido de no ser por la cantidad de veces que se lo han pedido sus usuarios. Aunque no es mi caso, porque lo desconocía, hay gente familiarizada con herramientas para comprimir las imágenes que ya lo hacen en CHD, y lo más sencillo para estas personas es seguir usando lo que conocen y como mejor lo hace. Entre ello, comprimir en CHD.

Otras novedades

PPSSPP 1.17 llega con otras novedades, como la posibilidad de inscribirse para recibir betas automáticamente en Android. Hasta ahora, quien quisiera probar las versiones preliminares tenía que instalar las APK que proporcionan, pero ahora pueden hacerlo desde la aplicación, lo que es más sencillo y seguro.

Entre el resto de novedades, también hay corrección de errores:

• Se han corregido varios cuelgues y bloqueos graves que podían producirse al salir de la aplicación, especialmente desde la pantalla de pausa.
• Se han solucionado varios problemas de renderizado y se ha optimizado el rendimiento de renderizado.
• PPSSPP ahora registra el tiempo total jugado por partida. Se puede comprobar en la pantalla de información de cada partida (pulsando prolongadamente el icono).
• Algunas nuevas características de la interfaz de usuario, como la posibilidad de mantener el juego en marcha tras la superposición del menú de pausa.
• Muchas correcciones de entrada, especialmente en torno a la gestión de la zona muerta para el stick analógico y el control de inclinación.
• Se han corregido muchos errores relacionados con la sustitución de texturas.
• La latencia de entrada se ha mejorado mucho en la versión SDL con Vulkan. Se recomienda no usar OpenGL en Linux si se puede evitar.
• Para RetroAchievements, renombrado el modo Desafío al modo Hardcore y lo hizo el valor predeterminado, como es estándar.

Descargar PPSSPP 1.17

PPSSPP 1.17 está disponible en la página de descargas del proyecto, para Windows, macOS, Android, iOS, Quest y Pico. Lo que vemos allí para Linux es el enlace a la versión Flatpak, pero también es posible instalarlo desde los repositorios oficiales de algunas distribuciones Linux (si tras la instalación veis dos versiones -Qt y SDL- sencillamente usad la que mejor os vaya). En este último caso, hay que esperar a que suban los nuevos paquetes, y el tiempo dependerá de la filosofía de cada proyecto. Los usuarios que tengan la versión de la Google Play (Android) la recibirán en aproximadamente una semana.

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

«Un nuevo kernel ha llegado, por lo que era momento de refrescar nuestra ISO de Galileo con la versión Galileo Neo 2024-01-25«. Así empieza la nota de lanzamiento de EndeavourOS Galileo Neo, una nueva ISO de lo que para muchos es el mejor ejemplo de un Arch Linux si éste tuviera instalador gráfico. No es necesario que haya una nueva versión del kernel para que lancen una revisión de EndeavourOS, pero sí es buen momento como afirma Bryan.

EndeavourOS Galileo Neo no llega con nuevas funciones, y está aquí para ponerse al día. Entre los paquetes que han actualizado, además del kernel, esta ISO incluye la última versión de Firefox, el instalador Calamares más reciente y otras actualizaciones como la del driver de NVIDIA. Pero lo más importante en este lanzamiento es la corrección de bugs.

Novedades más destacadas de EndeavourOS Galileo Neo

• Linux kernel 6.7.1.arch1-1.
• Calamares 23.11.1.4-1.
• Firefox 122.0-1.
• Mesa 1:23.3.3-1.
• Xorg-server 21.1.11-1.
• Nvidia-dkms 545.29.1.06-1.
• Bugs corregidos:
  • Varias correcciones para el script Bash que causaba problemas al ejecutar sesiones Wayland cuando se seleccionaba la opción de instalación offline de KDE Plasma.
  • Arreglado el problema que causaba efectos molestos y composición en el Entorno Plasma Live con máquinas que ejecutaban gráficos Intel heredados.
  • Eliminado el paquete de controladores heredados r8168 que se instalaba automáticamente cuando se seleccionaba el kernel LTS de Linux en Calamares.
  • Resuelto el problema para que el instalador recupere los paquetes con nombres antiguos cuando se seleccionaba la opción de instalación en línea de KDE Plasma.
  • Cuando se produce un error de instalación, Calamares ahora desmonta correctamente el dispositivo de destino y se puede utilizar inmediatamente de nuevo para otra sesión de instalación, en lugar de reiniciar la ISO para iniciar una nueva sesión.

Como siempre en estos casos, recordar que EndeavourOS Galileo Neo no es una nueva versión de las que pueden hacer que nos planteemos instalar de cero. Su modelo de desarrollo es Rolling Release, y todo lo que incluye Galileo Neo está ya disponible como actualización en las instalaciones existentes. Para nuevas instalaciones, la imagen ISO se puede descargar desde los servidores qeu facilitan en su página de descargas.

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

El pasado 17 de enero, hace justo 10 días, WineHQ lanzó WINE 9.0, la nueva versión estable de este software que permite usar aplicaciones de Windows en otros sistemas operativos. El lanzamiento marcó el final del ciclo del desarrollo que inició un año antes, y hace unas horas se ha dado comienzo a uno nuevo. La versión que nos entregaron, WINE 9.1, no es estable, sino la primera del WINE 10 que, si no hay cambios en los próximos 12 meses, llegará a principios de 2025.

Si alguien tiene dudas con respecto a la numeración, hoy ha llegado ese WINE 9.1 que es la primera versión de desarrollo de WINE 10, y la primera actualización de mantenimiento de la actual versión será un WINE 9.0.1 que llegará cuando lo consideren oportuno. Si hay algún otro lanzamiento para corregir errores, éstos llevarán la numeración 9.0.2, 9.0.3, etc. El cambio del primer decimal tiene lugar en las versiones de desarrollo que preparan la siguiente estable.

Bugs corregidos en WINE 9.1

WINE 9.1 ha llegado con un total de 270 cambios, con la siguiente lista de 42 bugs corregidos. Entre lo destacado, hay un número de mejoras en los métodos de entrada, se ha mejorado el soporte para claves Diffie-Hellman y mejor detección del teclado Dvorak, a lo que se le une el habitual punto de correcciones varias.

La lista de bugs corregidos incluye:

Dentro de dos semanas debería llegar v9.2, dentro de cuatro v9.3 y seguiremos así hasta finales de año, momento en el que lanzarán las Release Candidates y ya después WINE 10.0. WINE 9.1 ya está disponible y se puede descargar desde el siguiente botón.

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

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

Nate Graham, desarrollador de control de calidad del proyecto KDE, dio a conocer hace poco un informe sobre los progresos para el lanzamiento de KDE 6 (programado para el 28 de febrero) y en el cual informa que se ha bifurcado el código base de KDE Plasma 6.0 y KDE Gears 6.0 en un repositorio separado, y la rama principal ha comenzado a acumular cambios para KDE Plasma 6.1 y KDE Gears 24.05.

Entre las actualizaciones incluidas en la rama principal que aparecerán en KDE Plasma 6.1 y KDE Gears 24.05, se destacan los siguientes cambios.

En el administrador de archivos Dolphin, ahora se permite guardar automáticamente las ventanas y pestañas abiertas, cuyo estado se restaura en caso de apagado de emergencia o reinicio del sistema.

Se ha añadido la capacidad de controlar la visualización de la papelera de reciclaje y los archivos de respaldo junto con los archivos ocultos. Además, se implementó el soporte para separar el contenido de una vista dividida en una ventana separada.

En el visor de documentos Okula, se ha agregado el soporte para mostrar menús desplegables utilizados en ciertos tipos de documentos PDF. Se ha añadido la visualización del número de canal inalámbrico, además de la frecuencia, al subprograma con información sobre los parámetros de la red.

El sistema de captura de pantalla proporciona sustituciones adicionales para su uso en nombres de archivos de captura de pantalla y screencast, como `<UnixTime>` para la sustitución de hora de época y <h>/<hh>` para la sustitución de reloj de 12 horas.

Por la parte de los cambios trasladados a KDE 6.0, se menciona que:

• Se han solucionado problemas con la aparición de artefactos visuales en aplicaciones basadas en QtQuick al configurar valores de escala no enteros (escala fraccionaria).
  Se ha mejorado la velocidad de búsqueda de archivos de configuración utilizados en aplicaciones típicas de KDE entre un 13 y un 16 %.
• La barra de herramientas global del modo de edición de Plasma ahora tiene un botón «Agregar panel» al panel de edición global (Modo de edición) para facilitar la adición de paneles, lo que ha permitido eliminar los botones «Agregar widgets» y «Agregar paneles» del menú contextual.
• En el cuadro de diálogo de selección de pantalla o ventana, ahora es suficiente con un solo clic del mouse para seleccionar elementos, a menos que el modo de selección múltiple esté activado, en cuyo caso se muestran casillas de verificación especiales junto a los elementos y se puede usar un doble clic para completar la selección.
• Además, se ha agregado una nueva regla «Capa de ventana» en lugar de la regla «Tipo de ventana» que no funciona con Wayland.
• KWin también ha mejorado la recuperación de configuraciones en configuraciones multipantalla si algunas pantallas carecen de datos EDID.
• Se mejoró la velocidad de varias búsquedas de archivos de configuración que se utilizan con mucha frecuencia en el software KDE entre un 13 y un 16 %

Y finalmente, por la parte de las correcciones de errores, se destacan los siguientes:

• En KF5 se solucionó un problema al mover o copiar una gran cantidad de archivos que podía causar que algunos de ellos se omitieran (y potencialmente se perdieran) después de omitir carpetas duplicadas
• Powerdevil ya no falla al iniciar sesión cuando se utiliza la biblioteca ddcutil-2.0.0 y ciertos monitores compatibles con DDC
• Se solucionó un problema que causaba que las carpetas dentro de recursos compartidos/montajes de red no fueran expandibles en la vista
• Se trabajó para que los fallos visuales en las aplicaciones QtQuick se minimizaran cuando se utiliza un factor de escala fraccionario, aunque se menciona que aún quedan algunos detalles por pulir el texto y los contornos/sombras de las ventanas.
• Se hizo que KWin fuera más robusto al restaurar la configuración para disposiciones de pantallas múltiples cuando a alguna de las pantallas le faltan sus EDID
• La regla de ventana “Window Type”, que no funcionaba en Wayland, ha sido reemplazada por una nueva regla de “Window Layer” que funciona mejor para los fines para los que la gente normalmente la usa.

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

Se ha vuelto a proponer él usó de C++ en Linux

Tal parece que la introduccion de Rust como segundo lenguaje de programación en el Kernel de Linux ha representado uno de los cambios más importantes que ha tenido Linux y no hablando en el ámbito de características y funcionalidades, sino que ha marcado un punto de partida muy importante en el cómo Linus torvalds y el equipo de desarrollo han dado un paso significativo hacia la modernización de Linux para bien.

Esto se puede notar, ya que hace poco, en las listas de correo del kernel de Linux se ha reavivado una discusión que fue iniciada hace seis años, presentando en broma un 1 de abril del 2018.

Y es que nuevamente se ha vuelto a poner sobre la mesa el asunto sobre «la viabilidad de adoptar el código C++ moderno en el kernel de Linux», yendo más allá del tradicional uso del lenguaje C con fragmentos de ensamblador y la promoción del lenguaje Rust.

La propuesta inicial fue lanzada en el 2018, por un ingeniero de Red Hat a modo de broma por la ya conocida celebración de april’s fool, en la cual muchos aprovechan para crear bromas a la comunidad y en ese momento fue asi, ya que supuestamente había lanzado un conjunto de 45 parches que incluían el uso de plantillas, herencia de clases y sobrecarga de funciones de C++.

En mi opinión, C++ 14 es la versión “mínima” que tiene un soporte de metaprogramación razonable y tiene la mayoría sin los tipos de versiones anteriores (C++ 11 tenía la mayoría, pero C++ 14 completa algunas piezas clave faltantes). Sin embargo, en mi opinión, C++20 es realmente el mayor cambio de juego; Aunque las versiones anteriores podían ejecutar muchos hacks de SFINAE, también daban mensajes de error absolutamente inútiles.

Hacemos mucha metaprogramación en el kernel de Linux, implementada mediante trucos de macros a menudo realmente horribles. Estos también son prácticamente imposibles de depurar. Tomemos el ejemplo de los hacks de tipo uaccess.h, algunos de los cuales diseñé y escribí. En C++, diferentes conversiones y declaraciones de casos se pueden dividir en instancias de plantilla separadas y, con un poco de ingenio, también se pueden aplicar estrictamente cosas como los punteros de espacio de usuario versus los punteros de espacio de usuario del kernel, así como los punteros de espacio de usuario ya marcados, versus aquellos que no lo son, sin mencionar el fácil manejo del caso de tipos de espacio de usuario de 32 bits en un kernel de 64 bits y la aplicación de la conversión endian.

Ahora, casi después de 6 años de ello, Hans Peter Anvin, un desarrollador clave del kernel de Intel y creador de proyectos como syslinux, klibc y LANANA, ha retomado la iniciativa de continuar la discusión. Según Anvin, desde 1999, los lenguajes C y C++ han experimentado avances significativos en su desarrollo, y el lenguaje C++ ha demostrado ser más adecuado que C para el desarrollo del kernel de sistemas operativos.

Anvin menciona que las funciones que antes requerían extensiones específicas de GCC, ahora pueden implementarse fácilmente en C++ estándar, y en muchos casos, el uso de C++ mejorará la infraestructura sin necesidad de cambiar completamente el código.

Además de ello, se propone utilizar al menos la especificación C++ 14, que incluye herramientas de metaprogramación, y se alienta el uso de la especificación C++ 20, que introduce soporte para conceptos que pueden reducir la incidencia de errores.

Se argumenta que C++ es más preferible que Rust, ya que este último difiere significativamente en sintaxis del lenguaje C, es poco común para los desarrolladores actuales del kernel y no permite la reescritura gradual del código. En el caso del lenguaje C++, es posible traducir partes del código del lenguaje C gradualmente, similar a cómo se puede compilar el código C como C++.

Si bien, el kernel de Linux es principalmente código C con varias partes escritas en ensamblador y un trabajo creciente en torno al soporte de Rust en el kernel de Linux, todavía no está claro si hay suficiente peso para que esto sea una realidad, sobre la posibilidad de ver el código C del kernel de Linux convertido a C++ en el futuro.

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

El equipo de lanzamiento de openSUSE confirma que habrá un sucesor de Leap 15

Los desarrolladores del proyecto openSUSE dieron a conocer, mediante una publicación, el inicio de los trabajos para realizar la transición de openSUSE Leap hacia la base de ALP, ya que según la hoja de ruta openSUSE Leap 15.6 (que se lanzará en junio) será la última versión de openSUSE Leap de la rama 15.x y también la última en su forma actual.

Se menciona que los motivos del cambio de planes es por el deseo de realizar ya la transición a la nueva plataforma tecnológica ALP, una plataforma que divide la base de la distribución en partes, donde la distribución principal actúa como un «sistema operativo anfitrión» simplificado, y las aplicaciones y componentes del espacio de usuario se ejecutan en contenedores o máquinas virtuales aislados entre sí y que el enfoque principal de Leap 16 está en los servicios comerciales y en la nube, enfatizando la contenedorización.

La transición a Leap 16 no es solo un paso adelante numérico, sino que simboliza un importante camino hacia adelante en tecnología y experiencias de usuario. El futuro de openSUSE Leap se basa en el concepto innovador de la plataforma Linux adaptable de SUSE.

La plataforma Linux adaptable impulsa las soluciones openSUSE Leap, Leap Micro y SUSE de próxima generación. Hace que las distribuciones sean más adaptables y adecuadas para cargas de trabajo nativas de la nube, al mismo tiempo que es capaz de manejar un rápido ritmo de innovación.

No hay planes de eliminar la opción clásica (no inmutable) de Leap; Tanto las variantes de instalación no inmutables como las inmutables están disponibles para Leap 15 y están planificadas para Leap 16. Esta seguirá siendo la forma preferida para que las personas implementen Leap.

Algunas características destacadas y cambios planeados para openSUSE Leap 16 incluyen:

1. Plataforma ALP: La adopción de la plataforma ALP, que se basa en SLE Micro, un producto de SUSE Linux Enterprise basado en desarrollos del proyecto MicroOS. Esta plataforma se centra en la modularidad y en ejecutar aplicaciones y componentes en entornos aislados.
2. Gestión centralizada: Se proporcionarán sistemas de gestión de configuración Salt (preinstalado) y Ansible (opcional) para la gestión centralizada.
3. Contenedores y máquinas virtuales; El entorno utilizará contenedores y máquinas virtuales para ejecutar aplicaciones y componentes, proporcionando un mayor aislamiento entre ellos.
4. Cifrado de disco:El uso predeterminado de cifrado de disco completo (FDE) con la capacidad de almacenar claves en el Trusted Platform Module (TPM).
5. Montaje de la partición root: La partición root se montará en modo de solo lectura y no cambiará durante la operación.
6. Mecanismo de instalación atómica de actualizaciones: Se implementará un mecanismo para la instalación atómica de actualizaciones basado en el uso de un administrador de paquetes estándar y un mecanismo de instantáneas en el sistema de archivos Btrfs.
7. Cambio de modelo de desarrollo: El desarrollo de openSUSE Leap 16 continuará utilizando el modelo de desarrollo de repositorio openSUSE Factory, buscando un equilibrio entre las nuevas tecnologías ALP, el sistema operativo tradicional Linux y las iniciativas de integración de paquetes comunitarios.
8. Componentes: Entre los componentes del sistema colocados en contenedores se encuentran yast2, podman, k3s, cockpit, GDM (GNOME Display Manager) y KVM. Las herramientas Podman y K3s (Kubernetes) están disponibles para ejecutar contenedores aislados
9. self-healing: Para mantener la capacidad de supervivencia del sistema, el último estado estable se registra mediante instantáneas de Btrfs (si se detectan anomalías después de aplicar actualizaciones o cambiar la configuración, el sistema se transfiere automáticamente al estado anterior).

Cabe mencionar que openSUSE Leap 16 se espera para el año 2025, y hasta entonces, openSUSE Leap 15.6 probablemente será la última versión clásica del proyecto, pero si por alguna razón el desarrollo de openSUSE Leap 16 se retrasa, los desarrolladores menciona que es posible extender el ciclo de vida de openSUSE Leap 15.6 o lanzar una versión adicional de openSUSE Leap 15.7. El desarrollo de openSUSE Leap 16 planea continuar utilizando el modelo de desarrollo de repositorio openSUSE Factory y lograr un equilibrio óptimo entre las nuevas tecnologías ALP, el sistema operativo tradicional Linux y las iniciativas de integración de paquetes comunitarios.

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

Firefox es un popular navegador web

Mozilla dio a conocer la noticia de que la nueva versión de su navegador web «Firefox 122» ya fue liberada y en Firefox 122 podremos encontrar diversas novedades significativas, asi como también mejoras de soporte, correcciones y más.

Por la parte de las correcciones de errores, Firefox 122 integra la solución de 15 vulnerabilidades, de las cuales 5 están marcadas como peligrosas y 8 vulnerabilidades son causadas por problemas de memoria, como desbordamientos de búfer y acceso a áreas de memoria ya liberadas.

Principales novedades de Firefox 122

En esta nueva versión de Firefox 122, se destaca que se han introducido mejoras significativas en las capacidades de visualización de recomendaciones al ingresarlas en la barra de direcciones del navegador. Ahora, algunos motores de búsqueda tienen la capacidad de mostrar imágenes y descripciones de texto junto con las sugerencias de búsqueda. Al buscar información relacionada con el desarrollo web, las recomendaciones incluyen enlaces directos a la documentación en MDN proporcionando a los usuarios acceso rápido a recursos esenciales.

Otra de las novedades que se destaca de Firefox 122 es el proceso de creación de paquetes deb listos para Ubuntu, Debian y Linux Mint. Estos paquetes están diseñados para ser compatibles con las versiones convencionales de Firefox disponibles para Debian y Ubuntu, y se ofrecen en formato «.tar.bz2» para su descarga. Estos paquetes generados incluyen optimizaciones adicionales y marcadores para mejorar la seguridad durante la instalación. Además, se ha añadido un archivo .desktop en el paquete para facilitar la creación de accesos directos en el escritorio y en el menú de distribución. Las instrucciones detalladas para instalar Firefox desde el repositorio APT de Mozilla están disponibles para simplificar el proceso de implementación.

Además de ello, se destaca que se ha implementado una nueva capa de protección contra la fuga de información sobre enlaces visitados anteriormente a través del análisis de color de píxeles mediante filtros que utilizan el parámetro currentColor.

Por otra parte, en Firefox 122 en las compilaciones para macOS, se ha integrado el soporte para la tecnología Passkey (usada solo en iCloud Keychain), que permite al usuario autenticarse sin contraseñas utilizando identificadores biométricos como huellas dactilares o reconocimiento facial.

En el modo de navegación privada, a los scripts se les dio la capacidad de guardar datos a través de la API de caché para unificar el comportamiento en los modos privado y regular (la diferencia existente podría usarse para determinar el comportamiento del usuario en el modo privado).

En la versión de Android, se ha incorporado nuevas funcionalidades orientadas a mejorar la privacidad del usuario y brindar mayores opciones de configuración, pues se destaca la introducción del mecanismo GPC (Global Privacy Control), el cual reemplaza el encabezado «DNT» (Do Not Track). Esta característica permite informar a los sitios web que la venta de datos personales y su utilización para rastrear preferencias o movimientos entre sitios está prohibida.

Adicionalmente, se ha añadido la posibilidad de configurar Firefox como el visor de PDF predeterminado en dispositivos Android. Esta opción proporciona a los usuarios un mayor control sobre la gestión de documentos PDF directamente desde el navegador.

Y con el objetivo de mejorar la protección contra la identificación pasiva del usuario, se ha modificado el encabezado User-Agent. Ahora, este encabezado siempre se configura en «Android 10», independientemente de la versión real de la plataforma. Esta medida contribuye a fortalecer la privacidad del usuario al limitar la información que podría ser utilizada para identificar de manera no deseada a los usuarios en línea.

En Web Developer Tools, en el modo de inspección, al editar un selector o propiedades, presionar Enter se confirma la entrada y se establece el enfoque en el elemento correspondiente, en lugar de desplazar el enfoque al siguiente campo de entrada (puedes utilizar la tecla Tab para desplazar el enfoque al siguiente campo).

Por la parte de las mejoras para desarrolladores:

• Está permitido utilizar el elemento <hr> dentro de un elemento <select> para insertar delimitadores en listas generadas a partir del elemento <select>.
• Se agregó la capacidad de usar el método showPicker con elementos <select> para llamar mediante programación la implementación del menú desplegable proporcionada por el navegador.
• Se proporcionan reglas para saltos de línea al mostrar texto en páginas web para cumplir con el estándar Unicode. Los idiomas asiáticos como el japonés y el chino ahora admiten hacer doble clic en el texto para resaltar palabras completas.
• Se incluye la propiedad CSS offset-position , que especifica la posición inicial del elemento y normalmente se usa junto con la propiedad offset-path para definir la ruta de los objetos de animación.
• La propiedad CSS offset-path ahora admite la función ray() , que especifica el segmento de línea que sigue el elemento animado, así como los valores de forma básica y cuadro de coordenadas .
• Se agregó soporte para las funciones rect() y xywh() a las propiedades CSS clip-path y offset-path para crear formas básicas.
• Se agregó soporte para animar el atributo SVG viewBox usando el lenguaje SMIL (lenguaje de integración multimedia sincronizado), diseñado para animar elementos SVG.
  Calidad mejorada de la traducción de páginas utilizando el sistema de traducción automática integrado.
• Se han resuelto los problemas con la desaparición de páginas traducidas y los widgets interactivos que no funcionan.
• Para mejorar la protección contra ataques XSS y mejorar la portabilidad entre navegadores, SVGUseElement ha dejado de admitir la URL «data:».
• Se habilitó el manejo del token de finalización » webautn «. En los cuadros de diálogo de autocompletar de formularios, se ha implementado una interfaz para conectarse mediante Passkey

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

¿Como instalar o actualizar la nueva versión de Firefox en Linux?

Los usuarios de Firefox que no hayan desactivado las actualizaciones automáticas recibirán la actualización automáticamente. Aquellos que no quieran esperar a que eso suceda pueden seleccionar Menú> Ayuda> Acerca de Firefox después del lanzamiento oficial para iniciar una actualización manual del navegador web.

La pantalla que se abre muestra la versión actualmente instalada del navegador web y ejecuta una búsqueda de actualizaciones, siempre que la funcionalidad esté habilitada.

Otra opción para actualizar, es si eres usuario de Ubuntu, Linux Mint o algún otro derivado de Ubuntu, puedes instalar o actualizar a esta nueva versión con ayuda del PPA del navegador.

Este lo pueden añadir al sistema abriendo una terminal y ejecutando en ella el siguiente comando:

sudo add-apt-repository ppa:ubuntu-mozilla-security/ppa -y

sudo apt-get update

sudo apt install firefox

También puedes optar por realizar la instalación siguiendo las instrucciones que proporciona Mozilla.

Para el caso de los usuarios de Arch Linux y derivados, basta con ejecutar en una terminal:

sudo pacman -Syu

O para instalar con:

sudo pacman -S firefox

Finalmente, pueden obtener el navegador con el último método de instalación que fue añadido «Flatpak». Para ello deben contar con el soporte para este tipo de paquetes.

La instalación se hace tecleando:

flatpak install flathub org.mozilla.firefox

Para el resto de las distribuciones de Linux, pueden descargar los paquetes binarios desde el siguiente enlace.

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