logo de Enlightenment

Hace poco se dio a conocer el lanzamiento de la nueva versión del gestor de ventanas «Enlightenment 0.26.0» la cual llega después de un año y medio de desarrollo con una gran cantidad de correcciones de errores, asi como también mejoras de soporte y más.

Para quienes desconocen del escritorio Enlightenment, deben saber que está formado por componentes como un administrador de archivos, un conjunto de widgets, un iniciador de aplicaciones y un conjunto de configuradores gráficos.

Enlightenment es muy flexible en el procesamiento: los configuradores gráficos no restringen al usuario en la configuración y le permiten configurar todos los aspectos del trabajo, proporcionando herramientas de alto nivel (cambio de diseño, configuración de escritorios virtuales, gestión de fuentes, resolución de pantalla, distribución del teclado, localización, etc.), así como las oportunidades de ajuste de bajo nivel (por ejemplo, puede configurar el almacenamiento en caché, la aceleración gráfica, el consumo de energía, la lógica del administrador de ventanas).

Principales novedades de Enlightenment 0.26

En esta nueva versión que se presenta de Enlightenment 0.26.0 el objetivo principal de los desarrolladores era aportar más estabilidad al escritorio para mejorar la experiencia del usuario, con lo cual se incorporaron algunas características nuevas de las cuales se destaca la adición de una configuración de Display Data Channel (DDC) para controlar la luz de fondo de la pantalla, además de que las vistas previas de tareas ahora son más grandes y se ha incluido una descripción general mejorada de las aplicaciones abiertas.

Otra de las mejoras implementadas es que EFM (el administrador de archivos) ahora cuenta con la capacidad de agregar acciones con archivos a través de archivos de escritorio, también se destaca que se agregó soporte para deshabilitar la activación del protector de pantalla a través de la API org.freedesktop.ScreenSaver y que se agregó un proceso de vigilancia para detectar bloqueos en el bucle de eventos principal.

Junto con el lanzamiento de Enlightenment 0.26 se lanzó la nueva versión de EFL 1.27 en la cual se introdujo la biblioteca Evas, para representar texto, imágenes y objetos en la pantalla, ha agregado soporte para cargar y guardar imágenes en formatos JXL y QOI.

En Eina se añadió la API para trabajar con rutas relativas y hashes sha1, mientras que en Ecore ha agregado la capacidad de forzar la ejecución de un archivo exe junto con su proceso principal en la plataforma Windows.

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

• Se agregó soporte para la API DBus proporcionada por el servicio logind systemd para bloquear y desbloquear sesiones
• Se agregó una opción para usar la extensión Randr X11 llamando a la utilidad xrandr, en lugar de llamar a través de la API.
• Se han realizado correcciones de compatibilidad con Wayland, pues ahora se proporciona una etiqueta en pantalla que indica la naturaleza experimental del soporte de Wayland.
• Para garantizar que se guarden los cambios de configuración, se habilita la nueva API de sincronización en disco proporcionada por la biblioteca Eet .
• Se agregó una opción para controlar la configuración del estado oculto de la ventana a través de la API NetWM (propiedad _NET_WM_STATE_HIDDEN).
• elm_cnp , una implementación del mecanismo de copiar y pegar del portapapeles, ha agregado soporte para listas de URL .
• Se agregó una llamada a Eet , una biblioteca de serialización y deserialización de datos, para sincronizar los cambios en el disco.
• Se agregó soporte para la biblioteca LibreSSL 3.5.x y se eliminó el soporte para GnuTLS.
• El conjunto de widgets Elemental requiere el uso de íconos estándar del tema.
• Los widgets permiten pegar desde el portapapeles en campos de contraseña.

Finalmente si quieres conocer más al respecto sobre este lanzamiento, puedes consultar el anuncio en el siguiente enlace. 

Obtener Enlightenment 0.26

Para quienes estén interesados en poder instalar esta nueva versión, deben saber que ya pueden encontrar esta nueva versión de Enlightenment y de EFL en los repositorios de su distribucion de Linux.

De igual manera, para los interesados en compilar el código fuente, pueden obtener los paquetes necesarios el siguiente enlace.

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

Logo de Debian

Los sistemas de 32 bits se están volviendo obsoletos y en los últimos años muchas distribuciones de Linux ya han acelerado el movimiento para eliminar el soporte para la arquitectura de 32 bits (i386) total o parcialmente y para el caso de Debian, esto podría ser ya una realidad.

Durante una reciente mini-DebConf en Cambridge, los desarrolladores de Debian discutieron la cuestión de la eliminación gradual del soporte para la arquitectura x86 de 32 bits (i386). Debian, que cuenta con la más amplia gama de soporte de hardware entre las distribuciones, pero parece que la cuenta atrás para el fin del soporte de i386 ha comenzado en serio.

Paul Gevers, del equipo de lanzamiento de Debian, fue quien dio a conocer él anunció en un mensaje titulado «Bits from the Release Team: Cambridge sprint update» en la lista de correo debian-devel-announce.

Sobre el anuncio se menciona en el que «el equipo del kernel, el equipo del instalador (di) y el equipo de imágenes finalizarán el soporte para i386 en un futuro próximo». La compañía planea dejar esto claro y continuará discutiendo el futuro manejo de la arquitectura i386 en el foro de usuarios. Actualmente hay dos propuestas:

En la medida en que todavía lo hacen, anticipamos que el Los equipos kernel, di e imágenes
dejarán de admitir i386 en un futuro próximo. Después de eso, hay dos
rutas para ejecutar i386:

1. como una opción multi-arch en un sistema AMD64
2. como un chroot i386 en otro sistema de arquitectura

No estamos planeando hacer de i386 una arquitectura parcial en el camino, Ubuntu
tiene una arquitectura i386 parcial, por lo que todo se compila de forma
predeterminada. Los mantenedores que deseen eliminar el soporte para i386 pueden hacerlo *después* de la coordinación con las dependencias inversas (de compilación) de su paquete, al igual que si eliminan el soporte para cualquier otra arquitectura. También nos gusta señalar que no nos oponemos a los cambios en la línea de base cuando estos cambios aterricen (es un asunto portuario).

Como tal, se menciona que dentro de los planes incluyen de Debian es seguir soportando la arquitectura x86-32 por un tiempo todavía, pero se tiene contemplado el cese de la formación de compilaciones de instalación oficiales y paquetes de kernel para sistemas x86 de 32 bits, pero la preservación de la presencia de un repositorio de paquetes y la capacidad de implementar entornos de 32 bits en contenedores aislados.

También está previsto continuar entregando un repositorio y herramientas multi-arch para garantizar que las aplicaciones de 32 bits se puedan crear y ejecutar en un entorno x86_64 de 64 bits.

Si se aprueba el plan, el momento indicado para implementarse probablemente será en el lanzamiento de Debian 13 “Trixie” (prevista para 2025) pero también podría ocurrir antes, aunque esto es muy poco probable, dado que prácticamente el próximo lanzamiento de Debian 13 es para el otro año.

De implementarse el plan, ya no se crearán más imágenes de la arquitectura, incluyendo la fase de apoyo normal, lo cual de manera indirecta también pasara a afectar a otras distribuciones derivadas de Debian que ofrecen el soporte para 32 bits y entre las principales distribuciones afectadas se encuentra Peppermint OS, Q4OS, SparkyLinux, antiX , MX Linux, entre otras.

Cabe mencionar que la mayoría de las distribuciones que aún continúan ofreciendo el soporte para la arquitectura i386, están enfocadas para equipos de bajos recursos y la eliminación del soporte puede ser un duro golpe para los usuarios de esta arquitectura.

Y es que, aunque se hable en términos de porcentaje y la cantidad de descargas de la edición i386 sea mínima, hay que recordar que aún hay comunidades en las cuales el uso de equipos informáticos, que para la mayoría de nosotros pueden parecer ya obsoletos, estos son lo único que pueden tener dadas las circunstancias sociales.

Pero bueno, ese es otro tema que puede abarcar una gran cantidad de puntos a tomar en cuenta, pero sería una excelente opción que los desarrolladores de Debian realicen una profunda evaluación sobre este plan y que en dado caso de que Debian 13 “Trixie” sea el punto de no retorno, todavía se puedan ofrecer mas de cuatro años antes de que cese del soporte.

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

Durante este fin de semana, ya tras las vacaciones navideñas en, creo, todo el mundo, Linus Torvalds lanzó Linux 6.7 estable. Llegó tras ocho Release Candidates, aunque la RC extra no tuvo que ver con el tamaño de la ventana de fusión, la más grande de la historia del kernel. Aunque no siempre se cumple, es habitual que el kernel que se desarrolla coincidiendo con el mes de diciembre necesite más tiempo de trabajo porque el ritmo es más bajo.

Entre las novedades que llegaron junto a Linux 6.7, hay mucho que puede llamar la atención o no, dependiendo de lo que le interese a cada uno. Y es que el kernel guarda más relación con el hardware que con el software, y si algo no se puede ver o nos afecta directamente, ojos que no ven, corazón al que no le importa. Lo que sí es cierto es que esta versión soporta mucho nuevo hardware.

Algunas de las novedades más destacadas de Linux 6.7

Linux 6.7 introduce soporte para los procesadores Arrow Lake en la utilidad Turbostat, el Intel Lunar Lake M en LPPS, mejora la carga del microcódigo de la CPU x86 y ha empezado a soportar un SoC Risv-V de 64 núcleos, entre otras adiciones. En cuanto a los gráficos, ya se considera estable el soporte para Intel Meteor Lake y se ha mejorado el de Xe 2 Lunar Lake. NVIDIA siempre es noticia, para lo bueno o para lo malo, y Linux 6.7 ha incluido compatibilidad con NVIDIA GSP en el controlador Nouveau para proporcionar compatibilidad inicial con la GeForce RTX 40, y mejorar de paso la compatibilidad opcional con el hardware de la serie RTX 20/30 al hacer uso de los vinarios NVIDIA GPU System Processor.

En cuanto a sistemas de archivos, Bcachefs se fusionó por fin como ese sistema de archivos nacido del código de la caché de bloques del núcleo de Linux, y ese trabajo se continuó con una mejora de rendimiento.

En el apartado de la seguridad, se desactivó el Intel IBRS cuando una CPU está fuera de línea para ayudar a ofrecer un mejor rendimiento en algunos casos, se hizo una limpieza extra a la mitigación de AMD Inception/SRSO y se incluyó una nueva opción make hardening.config para el kernel como valores por defecto sanos para construir un kernel reforzado en seguridad, entre otras.

Otras novedades

En cuanto a hardware general que no entraría en ningún apartado propio, se incluyó soporte de monitorización de sensores para más hardware de sobremesa, una nueva compatibilidad con hardware de red y mejora del rendimiento, nuevo soporte de hardware de sonido Intel y AMD, gestión nativa de errores de protocolo de enlace CXL, así como soporte para DisplayPort Alternate Mode 2.1 «DP Alt Mode 2.1» para el controlador USB Type-C.

También ha habido algunas eliminaciones, como el abandono de los controladores Ethernet QLGE y WiFi rtl8192u sin mantenimiento. Otros cambios incluyen:

• MM optimizaciones de rendimiento, así como un mejor manejo de UEFI memoria no aceptada.
• Más trabajo FUTEX2.
• Mejoras en el programador.
• Continuación del trabajo en printk threaded print como requisito para obtener soporte en tiempo real (PREEMPT_RT) mainlined.
• Se ha integrado más código Rust.

Ya disponible

Linux 6.7 se puede descargar desde hace algo más de un día, y está disponible en kernel.org. Desde allí se puede descargar su tarball, es decir, ese ese archivo con extensión .tar.gz que incluye lo que podríamos llamar binarios. Aunque se puede instalar manualmente, nosotros recomendamos esperar a que lo añadan los responsables de nuestra distribución Linux o usar herramientas como Mainline Kernels (antes Ukuu) para los usuarios de Ubuntu.

Por lo general, rara vez es urgente actualizar el kernel tan pronto en cuanto lo lanza Linus Torvalds, y él y su equipo de desarrolladores no recomiendan la adopción masiva hasta al menos lanzar una versión de mantenimiento, lo que coincidiría con Linux 6.7.1. Entre los motivos que nos pueden hacer sentir cierta urgencia podemos encontrar que el kernel que usamos en nuestro equipo no soporte parte de su hardware.

En cualquier caso, Linux 6.7 ya está disponible de manera oficial.

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

Logo de Debian

Hace pocos días se dieron a conocer los resultados de la votación general de los desarrolladores del proyecto Debian, en la que han emitido su posición respecto al proyecto de Ley de Resiliencia Cibernética (CRA) propuesto en la Unión Europea.

Ley de Resiliencia Cibernética tiene como objetivo establecer requisitos adicionales para los fabricantes de software, con el objetivo de mejorar la seguridad y la gestión de vulnerabilidades a lo largo del ciclo de vida del producto. Sin embargo, la comunidad de Debian expreso sus preocupaciones sobre el impacto potencial en el ecosistema de desarrollo de software de código abierto.

¿Que es Ley de Resiliencia Cibernética?

La Ley de Resiliencia Cibernética (CRA) es una legislación propuesta por la Comisión Europea que tiene como objetivo aumentar la ciberseguridad de los productos y servicios digitales en la Unión Europea.

La CRA establece una serie de requisitos para los fabricantes y proveedores de productos y servicios digitales, que deben cumplirse a lo largo de todo el ciclo de vida del producto o servicio y en caso de incumplimiento de los requisitos, está previsto introducir multas que pueden alcanzar los 15 millones de euros o el 2,5% de la facturación anual de la empresa.

Una vez que la legislación sea aprobada, se requerirá que los fabricantes faciliten la distribución de parches para abordar vulnerabilidades en sus productos. Además, deberán llevar a cabo evaluaciones de riesgos de seguridad antes de lanzar nuevos productos al mercado y realizar pruebas de seguridad. En particular, se implementarán auditorías externas obligatorias para sistemas críticos. Además, se espera que los fabricantes eliminen cualquier vulnerabilidad a lo largo de todo el ciclo de vida del producto y comuniquen incidentes de seguridad en un plazo máximo de 24 horas tras su descubrimiento a la agencia de ciberseguridad de la Unión Europea (ENISA).

Cabe mencionar que el impacto principal de la legislación recaerá en los productores de software comercial, pero existe la preocupación en la comunidad respecto a su posible efecto negativo en el ecosistema de desarrollo de software de código abierto.

Principales puntos de preocupación

Responsabilidad legal para Debian

El proyecto de ley introduce responsabilidad legal por el incumplimiento de los requisitos de seguridad, lo que va en contra de la responsabilidad social de Debian de distribuir software para cualquier propósito y sin restricciones. Al no rastrear la procedencia del código y distribuir software para cualquier propósito sin restricciones, Debian se enfrenta a riesgos legales al aplicar los requisitos establecidos en la CRA.

Posible retiro de código abierto

La CRA podría llevar a proyectos upstream a dejar de proporcionar su código por temor a sanciones. Esto también podría dificultar que la comunidad de código abierto comparta código, ya que los desarrolladores deberán considerar las implicaciones legales.

Impacto en el desarrollo de código abierto

La comunidad teme que la CRA pueda limitar el avance de proyectos de código abierto y obstaculizar el desarrollo internacional de software de código abierto. Las empresas que utilizan o contribuyen a proyectos de código abierto podrían ser responsables de problemas de seguridad, incluso si el código fue creado en otros países.

Riesgos legales para proyectos independientes

Proyectos independientes que incorporan código de fabricantes comerciales pueden enfrentar consecuencias legales inciertas ya que la responsabilidad legal introducida por la CRA podría afectar la transferencia de código entre proyectos comerciales y no comerciales.

Naturaleza cuestionable de los requisitos de informes

Los desarrolladores expresan dudas sobre la exigencia de informar problemas de seguridad a la Agencia Europea de Seguridad de las Redes y de la Información (ENISA) dentro de las 24 horas. Acumular información sobre vulnerabilidades no parcheadas en un solo lugar podría plantear riesgos significativos en caso de fuga de información.

Demandas y Propuestas

Exclusión del desarrollo de código abierto

Los desarrolladores de Debian piden que el desarrollo de código abierto se elimine por completo de la CRA y que la ley solo se aplique a productos finales.

Exención para comerciantes individuales y pequeñas empresas

Se propone que los requisitos de la CRA no se apliquen a comerciantes individuales y pequeñas empresas, ya que podrían no cumplir con todos los requisitos y podrían verse obligados a cerrar.

Reevaluación de los requisitos de informes

Los desarrolladores de Debian hacen un llamado a una reevaluación de la necesidad y naturaleza de los requisitos de informes de la CRA, considerando los posibles riesgos de seguridad asociados.

La declaración de los desarrolladores de Debian destaca la importancia de preservar la naturaleza abierta y colaborativa del desarrollo de software de código abierto en medio de las preocupaciones planteadas por la CRA propuesta.

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

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

Andaba yo probando editores Markdown, viendo de qué era capaz cada uno, de qué no, y una pregunta empezó a rondar por mi cabeza: ¿es siempre el mejor software el que más hace o el que llega más lejos? Un programa puede ser muy potente, pero si nos limita de algún modo, bueno, como decían en un anuncio, aunque no es exactamente lo mismo, la potencia sin control no sirve de nada.

Aquí en Linux Adictos, en donde la mayoría de lectores y editores usamos Linux, la primera pregunta que nos podemos hacer tras empezar a pensar en esto es si es mejor Linux o Windows. El sistema de Microsoft llega más lejos -como se demuestra con los juegos- mientras que con Linux podemos hacer más, algo que quedaría demostrado justamente en que no nos dejan jugar a algunos títulos porque es más fácil hacer trampas. Lo sé, no es el mejor ejemplo, pero creo que se entiende.

El mejor software depende de qué vamos a hacer con él

Eso del mejor software es algo que no tiene una única respuesta. Al final, yo digo que lo mejor en el apartado que sea es lo que mejor se adapta a nuestras necesidades, y para mí es mejor Linux porque cumple con mis expectativas. Todo me resulta más sencillo, el rendimiento es mejor y es lo que elijo usar.

Pero, ¿pensaría igual si todo mi trabajo guardara una relación estrecha con Windows? Creo que no. Si tuviera que desarrollar para Windows, por ejemplo, y usar programas privativos que sólo están para el sistema de Microsoft, probablemente terminaría rindiéndome a la evidencia. Pero es que un sistema operativo es un montón de software que por lo general usamos sólo para nosotros.

Para entender a qué me refiero con lo anterior, podemos explicarlo con WhatsApp o Telegram. WhatsApp es peor, pero, por lo menos en países como España, es la aplicación de mensajería más usada. ¿Para qué quiero yo todas las funciones de Telegram si no puedo usarlas con nadie? WhatsApp llega más lejos, por lo que, si me permite comunicarme con más gente, es mejor app de mensajería que Telegram.

La compatibilidad es algo a tener en cuenta

Volvamos al Markdown. Entre los editores que probé había algunos que sobresalían, pero eso no es siempre bueno. «¿Cómo?» se estará preguntando más de uno, y la respuesta la tenemos en la compatibilidad. El mejor ejemplo es Visual Studio Code, que además de lo que puede hacer por defecto puede instalar extensiones. El editor/visor Markdown de Visual Studio Code puede, con estas extensiones, crear diagramas UML e incluso mostrar gráficas, lo que le hace ser el mejor editor o uno de los mejores. El problema es que eso ya no es un editor Markdown, es algo más.

Y si lo que queremos es crear documentos .md, ese «mejor editor» no lo es tanto. Si yo creo un documento con diagramas UML y gráficas y lo comparto, quien recibe el documento debe ser capaz de visualizarlo, y su su visor no es compatible no verá parte del contenido.

Uso personal vs. uso compartido

Cuando era pequeño, yo quería una consola, y mi hermano mayor me dijo que iba a comprarme «la mejor». Yo le dije que quería una «peor» porque era la que tenían mis amigos y tendría más juegos, y al final aceptó a regañadientes. Después de eso tuve decenas de juegos disponibles, y su hubiera tenido «la mejor», en una semana habría terminado con todos y tendría que haberme gastado mucho más dinero. Un dato: eran de cartuchos, por si alguien está pensando en modificaciones y esas cosas.

Más recientemente elegí PlayStation porque ya conocía a un grupo de jugadores con los que podía pasar tiempo jugando al Call of Duty. Y siendo malo era un componente valioso del equipo, puesto que ellos se centraban en la acción y yo en ganar la «demolición. No sé por qué, pero veo relación: no sería tan malo si estando limitado hacía lo que se esperaba de mí.

Lo mismo cuando nos rendimos a WhatsApp o si alguien decide quedarse en Windows. Al final lo mejor es lo que mejor podemos usar. Lo contrario puede ser el típico coche de lujo que tenemos en el garaje. Si no lo vamos a usar…

Por suerte, Linux es de ese tipo de software del que podemos hacer un uso personal.

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