Ya tenemos aquí la segunda actualización «mediana» de Nexus. Anunciado hace unos instantes, Kodi 20.2 ha llegado con corrección de errores y «backports», pero sin ninguna nueva función real. Las nuevas funciones llegan cuando cambian la primera cifra, y aunque en esta se ha subido al segunda, es más lo que se considera una actualización de punto que una mediana. No suelen lanzar actualizaciones más pequeñas en las que cambien el tercer número, aunque sí es posible que a veces veamos cómo se actualiza Kodi a una nueva «build» si es necesario arreglar algo más pronto.

Para los usuarios de Linux, Kodi 20.2 ha revertido un PR que corrige algunas configuraciones de Linux para utilizar la biblioteca más genérica (GL) en lugar de la biblioteca específica GLX. Entre el resto de novedades también hay algunas para Android, macOS/iOS y Windows en lo que se etiqueta como específico por plataformas. Lo que tenéis a continuación es una lista con las novedades más destacadas de Kodi 20.2.

Novedades más destacadas de Kodi 20.2

En Android, se ha corregido un bloqueo que tenía lugar cuando se estaban programando más de 100 trabajos en los canales de recomendaciones de Android TV, y para algunos dispositivos antiguos que tenían decodificadores MediaTek y de Google para algunos archivos multimedia, se puso una preferencia para usar el de Google.

En macOS/iOS se ha corregido el problema que hacía que el reconocimiento de voz no funcionara, y en Windows se ha corregido la reproducción HDR cuando el sistema ya estaba en modo HDR y un posible bloqueo para los usuarios de Xbox al utilizar sombreadores de píxeles y descodificación SW.

Entre lo general, tenemos:

• En el audio, se han actualizado varias correcciones relacionadas con E-AC3.
• En el tema Estuary, se ha corregido la pantalla Music Viz en un intento de alcanzar la perfección y se han aplicado colecciones en el reloj de la barra de búsqueda mientras se está buscando.
• Se ha aplicado una corrección de un fallo por agotamiento de memoria cuando se utilizan algunos emuladores.
• Muchas correcciones para construir Kodi con GCC13.
• En el PVR, se ha aplicado una corrección en la búsqueda guardada y otra para el último grupo abierto que no siempre se restauraba al iniciar Kodi.
• Python:
  • Se ha retroportado una corrección para el establecimiento de la imagen y el juego de información a través de infotags.
  • Se ha añadido GameInfo a la clase Player para permitir obtener/establecer datos GameInfoTag.
  • Se ha corregido un problema que afectaba principalmente a las plataformas Linux: la ruta utilizada al buscar módulos añadía las rutas de los scripts de Kodi al final de la lista y, por tanto, podía encontrar scripts/módulos Python del sistema en lugar de scripts/módulos específicos de Kodi.
• En el apartado del Video, se ha aplicado una corrección del estado visto/no visto que no se tiene en cuenta para los elementos no añadidos a la videoteca al crear listas de reproducción y otro para el estado visto/no visto en la ventana de la lista de reproducción.

Ya disponible en su página web

Kodi 20.2 ha llegado algo menos de cuatro meses después de 20.1, y ya se puede descargar desde su página web oficial. Los usuarios de Linux ya lo tenemos disponible en Flathub, y su llegada a los repositorios oficiales de las diferentes distribuciones Linux dependerá de la filosofía de las mismas.

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

Enciendes el ordenador, vas directo a instalar un paquete y… no puedes usar APT porque está bloqueado por las actualizaciones desatendidas. Disponibles desde hace años en las versiones más modernas de Ubuntu, el paquete unattended-upgrades puede ser importante para mejorar la seguridad de nuestro sistema, pero se ejecutará cuando él decida y no todos los momentos son igual de buenos. Además, tampoco son todas las instalaciones iguales, y hay algunas en las que puede ser buena idea desactivarlas.

Es probable que muchos usuarios de nivel bajo o medio ni se hayan dado cuenta su existencia. Hasta cierto punto, puede ser lógico: al iniciar el equipo o despertarlo de una suspensión, empezará su trabajo y, si hay algo importante que instalar, lo instalará. Si el equipo no es de recursos limitados y no intentamos instalar ningún paquete en ese momento, ni lo notaremos, pero es algo que se nota, y mucho, cuando el equipo es flojito.

Para qué sirve el paquete unattended-upgrades

El paquete de las actualizaciones desatendidas es algo que ya trató por encima mi compañero Diego hace algo más de dos años. Él mencionó que merece la pena instalarlo en un servidor, y no le faltó razón. El paquete unattended-upgrades instala las últimas actualizaciones de seguridad (entre otras) que estén disponibles, y viene instalado por defecto en Ubuntu desde hace varios años. Su intención es mantener el sistema operativo actualizado en lo más importante, pero Windows nos ha enseñado que no controlar las actualizaciones puede darnos más de un dolor de cabeza.

En mi opinión, merece la pena tenerlo activado en un equipo principal que además monta hardware algo solvente. Si tiene cierta potencia prácticamente no notaremos que se están instalando actualizaciones en segundo plano, pero si el aparato en el que trabajamos es uno con poca potencia que encendemos de vez en cuando, el trabajo puede impedirnos hacer lo que queremos durante muchos minutos. Además, si se nos ocurre forzar el apagado podemos llegar a ver el mensaje de que hay paquetes rotos y tenemos que tirar de sudo dpkg –configure -a para corregirlo.

Pasos a seguir para desactivar las actualizaciones desatendidas en Ubuntu

Si aún sabiendo que están diseñadas para mejorar la seguridad sabemos que es lo que queremos, se pueden desactivar abriendo un terminal, escribiendo sudo dpkg-reconfigure unattended-upgrades y, en la ventana que aparece, elegir no:

Si lo vemos necesario, se puede desinstalar el paquete con sudo apt remove unattended-upgrades.

¿Y cómo recibimos las actualizaciones de seguridad sin este paquete? Pues como ante de que existiera: actualizando manualmente. Únicamente hay que tener clara una cosa: las actualizaciones importantes se instalarán junto al resto de paquetes, lo que no es un problema más allá de que no se aplican los parches tan pronto en cuanto están disponibles.

Lo bueno es que uno puede decidir cuándo actualizar el sistema operativo y no trabajar lastrado en cualquier momento. ¿Que he acabado de usar Kodi o Retro Pie y sé que puedo permitirme perder tiempo con una potencial actualización pesada? Lanzo yo las actualizaciones. ¿Que me aparece el mensaje de que hay actualizaciones pendientes y me viene mejor en otro momento? Cierro su ventana.

Nuestra decisión, como siempre

Aunque existen por una razón, nosotros podemos tener otra para no querer que se ejecuten en nuestro sistema operativo. Lo bueno de Linux es que se puede modificar prácticamente todo, y la pelota suele estar en nuestro tejado. Cada uno es libre de decidir si es mejor no tocar nada o hacer una pequeña modificación para que el equipo no haga nada sin nuestro permiso.

Con respecto a este paquete, yo decido dependiendo de dónde lo tengo: en mis máquinas virtuales, en donde quiero hacer pruebas rápidas, y en el equipo que uso para mi entretenimiento las tengo desactivadas; no puedo esperar varios minutos para empezar a hacer lo que quiero. Pero en una instalación que tengo y que uso en mi equipo más potente ni lo noto, por lo que es mejor dejar las cosas como vienen por defecto y estar más protegido. Somos usuarios de Linux, y es nuestra decisión, como siempre.

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

Nitrux continua con la migración hacia Maui Shell

Se dio a conocer el lanzamiento de la nueva versión de Nitrux 2.9 con nombre clave «nu» que combina las últimas actualizaciones de software, correcciones de errores, mejoras de rendimiento y soporte de hardware listo para usar.

Para quienes desconocen de esta distribución, deben saber que está construida sobre la base del paquete Debian, las tecnologías KDE y el sistema de inicio OpenRC. Esta distribución se destaca por el desarrollo de su propio escritorio «NX», que es un complemento sobre el entorno KDE Plasma del usuario, además de que el proceso de instalación de aplicaciones está basado en el uso de paquetes AppImages.

El escritorio NX ofrece un estilo diferente, su propia implementación de la bandeja del sistema, el centro de notificaciones y varios plasmoides, como un configurador de conexión de red y un subprograma multimedia para control de volumen y control de reproducción de medios.

Principales novedades de Nitrux 2.9

En esta nueva versión que se presenta de Nitrux 2.9, llega con el kernel de Linux 6.3.9 con parches de Liquorix está habilitado de forma predeterminada, junto con las actualizaciones del entorno de escritorio y aplicaciones a KDE Plasma 5.27.6, KDE Frameworks 5.107.0 y KDE Gear 23.04.2. 

Por la parte de los cambios se destaca que se agregó el soporte para el sistema de instalación de programas Zero Install, que permite a los desarrolladores de aplicaciones organizar su distribución directamente desde sus sitios web, al tiempo que brinda funciones como la instalación automática de actualizaciones, el uso de un conjunto único de bibliotecas compartidas, procesamiento de dependencia y verificación del origen de los paquetes mediante firmas digitales.

Ademas de ello, tambien podremos encontrar que se agregaron los paquetes del sistema de imágenes e impresión HP Linux, el backend HP SANE para admitir el escaneo y la impresión todo-en-uno, asi como tambien la interfaz KCM de administración de permisos de Flatpak para cambiar los permisos otorgados a las aplicaciones de Flatpak.

De forma predeterminada en Nitrux 2.9, las nuevas instalaciones incluyen compatibilidad con el modo de rutas múltiples NVMe, que le permite configurar varias rutas físicas al dispositivo.

Se agregó la utilidad Zap para administrar aplicaciones en formato AppImages, el programa permite instalar aplicaciones del catálogo, monitorear actualizaciones y actualizar paquetes de AppImage ya instalados.

La biblioteca de componentes de la interfaz de usuario de MauiKit se actualizó a la versión 3.0, que incluye los componentes MauiKit Accounts, MauiKit FileBrowsing y MauiKit TextEditor. Basado en MauiKit 3.0, se ha creado la suite Maui Apps 3.0.0.

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

• Se han propuesto nuevas versiones del controlador AMD Vulkan 2023.Q2.3 y el controlador NVIDIA 535.54.03.
• Se agregó el sistema de bloqueo de anuncios dbab , que usa filtrado a nivel de DNS.
• Se agregaron nuevos módulos para el marco de gestión de métodos de entrada Fcitx5 : X.Org, Wayland, Lua y DBus.
• Uso mejorado de Fcitx5 para el control de métodos de entrada en aplicaciones basadas en GTK y Qt.
• La ejecución automática de Fcitx5 se proporciona cuando el usuario inicia sesión.
• Se agregó el configurador de método de entrada gráfico Mozc Setup.
• Los módulos de Maliit se incluyen con la implementación de métodos de entrada para GTK2 y GTK3.
• Se agregó una interfaz gráfica para configurar Plasma Firewall, que reemplazó al NX Firewall.
• La estructura incluye la utilidad Nuts (Nitrux Update Tool System), diseñada para actualizar la distribución y volver al estado anterior en caso de problemas.
• Se ha agregado al menú un elemento para la instalación rápida de Heroic Games Launcher (similar a los elementos ya existentes para Steam, Bottles e itch.io).
• Se agregaron las utilidades kexec-tools para ejecutar el kernel de Linux desde el contexto de un kernel que ya se está ejecutando.
• Se agregó VPN Wireguard.

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

Descargar la nueva versión de Nitrux

Si quieren descargar esta nueva versión de Nitrux 2.8.1, deberán de dirigirse a la página web oficial del proyecto en donde podrán obtener el enlace de descarga de la imagen del sistema y la cual podrán grabar en un USB con ayuda de Etcher. Nitrux está disponible para su descarga inmediata desde el siguiente enlace. 

Para aquellos que ya se encuentran sobre una versión anterior de la distribución, pueden hacer la actualización a la nueva versión, tecleando los siguientes comandos:

sudo apt update

sudo apt install --only-upgrade nitrux-repositories-config amdgpu-firmware-extra

sudo apt install -o Dpkg::Options::="--force-overwrite" linux-firmware/trixie

sudo apt dist-upgrade

sudo apt autoremove

sudo reboot

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

La próxima noticia importante sobre Linux Mint 21.2, de nombre en clave «Victoria», será la del lanzamiento de su versión estable. Está claro que pueden pasar más cosas, pero Clement Lefebvre suele publicar una nota mensual y la de este mes, correspondiente a Junio de 2023, ya ha visto la luz. Dentro de entre 1-3 semanas publicaremos que Linux Mint 21.2 ya está disponible, y probablemente alguna sorpresa que descubramos o nos cuenten en ese momento.

Como es habitual en los boletines de antes de un lanzamiento, el de este julio ha sido corto, tanto que cabe en su totalidad en un artículo como este. Clem y su equipo no pierden el tiempo cuando falta tan poco para una versión estable, y hoy se ha limitado a mencionar a la gente que está probando la BETA y que gracias a ellos ya se han identificado unos 60 bugs.

Linux Mint 21.2 llegará este julio

El mensaje completo dice que «Muchas gracias a todas las personas que están probando y encontrando bugs en la BETA. Hasta ahora hemos reunido 60 bugs. Muchos problemas fueron corregidos ya gracias a vuestro feedback«. El boletín lo completan los agradecimientos a los patrocinadores del proyecto.

Lefebvre no ha incluido nada más en su mensaje, por lo que no se conocen los plazos exactos. Similar a como lo hacen en Ubuntu, su versión BETA suele llegar entre 3 y 4 semanas antes que la versión estable, por lo que Linux Mint 21.2 debería llegar entre el 12 y el 26 de julio, habiendo incluido en ese plazo una semana de cortesía por si tienen algún problema que solucionar.

Lo hará en los tres escritorios en los que está disponible desde hace mucho, concretamente en Cinnamon 5.8, Xfce 4.18 y MATE 1.26. Cuando lancen la versión estable escribiremos un extenso artículo sobre toda la información relacionada a la v21.2 del Linux con sabor a menta.

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

No creo que haya tenido que ver, pero me siento observado (entiéndase que es una broma). Hace poco pensaba que Tube Converter no era un buen nombre para una aplicación cuyo punto fuerte es descargar vídeos y esta semana le han cambiado el nombre a Parabolic. Por otra parte, hace a penas una semana escribí sobre Nitter, un front-end alternativo para seguir qué estaba pasando en Twitter sin necesidad de una cuenta, y hace horas ha dejado de funcionar…

Ahora bien, aunque puede parecer otro de los movimientos extraños que está dando el «pájaro sin cabeza» que es ahora Twitter, si nos creemos lo que dice Elon Musk es algo temporal. El enlace en donde lo reconoce es este, y si no pongo el tweet incrustado es porque probablemente no se pueda ver hasta pasados unos días.

Twitter sólo para usuarios registrados

¿Pero qué es lo que está pasando y por qué? Lo que está pasando, como reza el titular, es que no se puede ver nada si no se tiene una cuenta y estamos identificados. Por lo tanto, software que usa una API alternativa y hace web scraping para obtener su información sólo ve un portazo en la nariz cada vez que intenta trabajar.

El por qué está menos claro. Elon Musk dice que es una medida de emergencia temporal, que «¡Les estaban saqueando tanto los datos que estaba degradando el servicio para los usuarios normales!«. Ya digo, no creo que yo haya tenido nada que ver, pero no sé si esto ha sido una orden del magnate para evitar que nadie pueda ver nada de su red sin su control. Como expliqué en el artículo sobre Nitter, llevamos tiempo en el que vemos 3-4 tweets de gente que seguimos y uno de publicidad, y esa publicidad no la vemos si accedemos desde servicios como el que ofrece Nitter.

Habrá que esperar para comprobar si es cierto que esto es sólo una medida de emergencia temporal o es algo más. Por el momento, lo único que sabemos es que el acceso está restringido.

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

Captura de la web de LibreOffice

La industria informática está experimentando profundos cambios. La, para muchos, inesperada irrupción de la Inteligencia Artificial en el uso cotidiano disparó nuevas posibilidades y, la tendencia a transformar casi todas las aplicaciones a la modalidad Software como un servicio parece imparable. En el artículo anterior nos preguntábamos si uno de los títulos más emblemáticos del código abierto va a estar a la altura de las circunstancias y, en este hablaremos más sobre el desafío de LibreOffice.

Durante años, el gran defecto del software libre y de código abierto es que se interesó más en la militancia que en la escritura de código. Se perdió demasiado tiempo en criticar los defectos del software privativo en lugar de enfocarse en crear virtudes propias más allá de las 4 libertades del software libre o los principios del open source.

Como resultado, los usuarios debíamos conformarnos con tener con meses o años de retraso las novedades que eran estándar en las versiones privativas.

Más sobre el desafío de LibreOffice

Respondiendo a la pregunta de un lector, no tengo absolutamente nada contra LibreOffice. El trabajo que hace The Document Foundation para que exista una suite ofimática de código abierto de calidad comercial (Cosa que nunca fue OpenOffice). Tampoco es desdeñable su trabajo de ingeniería inversa para conseguir compatibilidad con formatos de archivos discontinuados.

Sin embargo, sigue sin tener versión para móviles (Apenas un visor) y el repositorio de la versión online está congelado. Tampoco son capaces de hacer que funcione el guardado de documentos en Google Drive.

Cambio de paradigma

Cuando el reinado de Microsoft en la industria del software parecía inamovible, Google y Apple patearon el tablero. Por un lado, los dispositivos móviles dejaron de ser algo más que una herramienta para hacer llamadas telefónicas o hablar por teléfono. Por el otro Google Docs anuló la necesidad de miles de estudiantes y pequeñas empresas de piratear Microsoft Office.

La respuesta de Microsoft no fue exitosa desde el punto de vista de imponer su propio sistema operativo para móviles, aunque sus aplicaciones para Android e iOS son geniales. Su propia versión de suite ofimática en la nube, que trabaja en conjunto con la versión de escritorio, consiguió sacarle porción de mercado a la herramienta de Google.

La guerra va un paso más allá. Hace unos años Google lanzó Chromebooks, una serie de dispositivos que no necesitan un sistema operativo instalado, tan solo un navegador que se conecta a la nube y permite utilizar todas las aplicaciones de Google.

Recientemente se conocieron documentos internos de Microsoft que se presentaron como prueba en un juicio. De acuerdo a esos papeles, la firma tiene planes de ofrecer a los consumidores que no tengan equipos compatibles con Windows 11 utilizar una versión en la nube.  Esto significa literalmente que se podrá utilizar Windows y sus aplicaciones en cualquier equipo.

Además de la integración con herramientas de Inteligencia Artificial la idea es que cuando inicies sesión en tu ordenador, lo que se abra y lo que veas sea la sesión en la nube. La experiencia será la misma no importa qué uses ni donde estés.

Hace poco la firma presentó Copilot, un asistente de Windows 11 basado en Inteligencia Artificial que puede resumir el contenido que vemos en las aplicaciones que ejecutamos, explicarlo e incluso modificarlo.

Hay lectores que me han dicho varias veces que no les importa lo que hacen las empresas de software privativo y que yo y el resto de los usuarios deberíamos conformarnos con los que nos dan siendo felices con que se respeten las cuatro libertades o los principios del software libre.

Pero ¿Por qué?

El único obstáculo para que las herramientas de software libre y código abierto tengan las últimas prestaciones y, de hecho, sean las primeras en tenerlas es que se dedica más tiempo a las peleas internas que al desarrollo.

Me encantaría poder usar LibreOffice en cualquier dispositivo sin tener que instalarlo en cada uno de ellos o guardar una versión portable en un pendrive. la primera vez que pruebas las funciones de dictado o transcripción que tienen otras suites ofimáticas se hace adictivo y, no mencionemos lo de poder consultar referencias o generar una imagen a medida por IA sin tener que salir de la aplicación.

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

Red Hat Enterprise Linux es una distribucion de Linux que dirige sus productos principalmente para empresas

Poco después de la noticia sobre la restricción al acceso del código de Red Hat (noticia que compartimos aquí) y que distribuciones afectadas como Alma Linux y Rocky Linux dieran a conocer su postura ante la situacion informando a la comunidad sobre los cambios que se deberán de realizar en sus hojas de ruta.

Mike McGrath, vicepresidente de desarrollo de Fedora y CentOS en Red Hat, mediante una publicación de blog, ha dado a conocer la posición de la compañía sobre los recientes sucesos de dejar de publicar paquetes RHEL srpm en el repositorio git.centos.org y dejar el repositorio como la única fuente pública de código de paquete RHEL CentOS Stream.

Según McGrath, Red Hat opera de acuerdo con los requisitos de la licencia GPL, sigue siendo partidario de los procesos de desarrollo abiertos y continúa actuando por el bien de la comunidad abriendo su código e impulsando los cambios en sentido ascendente. El repositorio Git del proyecto CentOS Stream incluye las fuentes de todos los paquetes en los que se basan los lanzamientos de RHEL, y este repositorio está disponible para todos sin restricciones.

Nos han llamado malvados; Me llamaron un ejecutivo de IBM que se instaló para convertir Red Hat en código cerrado, y eso es solo lo «agradable». Así que aclaremos las cosas.

Al mismo tiempo, el desarrollo de CentOS Stream se lleva a cabo con cierto avance y no siempre las últimas versiones de los paquetes pueden coincidir con los paquetes de RHEL, pero todo el código está en el repositorio y se puede encontrar si se desea.

Si faltan cambios en CentOS Stream o se observan discrepancias, esta situación debe tratarse como un error que debe informarse y corregirse. Sin embargo, Red Hat no ve ningún valor en la reconstrucción de RHEL y no tiene la obligación de facilitar las cosas para las distribuciones que realizan reconstrucciones.

A pesar de lo que se dice actualmente sobre Red Hat, hacemos que nuestro arduo trabajo sea fácilmente accesible para quienes no son clientes. Red Hat usa y siempre usará un modelo de desarrollo de código abierto. Cuando encontramos un error o escribimos una característica, contribuimos con nuestro código aguas arriba. Esto beneficia a todos en la comunidad, no solo a Red Hat y a nuestros clientes.

No tomamos simplemente los paquetes upstream y los reconstruimos. En Red Hat, miles de personas dedican su tiempo a escribir código para habilitar nuevas funciones, corregir errores, integrar diferentes paquetes y luego respaldar ese trabajo durante mucho tiempo, algo que nuestros clientes y socios necesitan.

La insatisfacción de Red Hat se debe al hecho de que la empresa invierte mucho en el mantenimiento de paquetes a largo plazo, el desarrollo de nuevas funciones, las pruebas y el backporting de los cambios, y los creadores de reconstrucciones revenden el trabajo de otras personas sin participar en él y sin proporcionar nada a cambio.

Según Red Hat, la distribución de productos que son completamente duplicados de otros desarrollos y creados sobre la base de una reconstrucción simple, sin realizar sus propios cambios, representan una amenaza para las empresas de código abierto, así como para todo el ecosistema de código abierto, ya que pueden llevar el software de código abierto a un estado en el que estaba el montón de aficionados y piratas informáticos.

Según los desarrolladores de compilaciones alternativas de RHEL, como AlmaLinux y Rocky Linux, detener la publicación del código del paquete en git.centos.org dificultará la preparación de compilaciones de RHEL completamente compatibles con binarios e idénticas en comportamiento (en el nivel de error) dado que el repositorio de CentOS Stream no está sincronizado con RHEL, es posible que a los paquetes les falten algunos parches, algunos paquetes (por ejemplo, con el kernel) se publican con retraso, los números de versión de los paquetes en CentOS Stream y RHEL no siempre coinciden.

Además, la distribución RHEL se admite durante 10 años, mientras que CentOS Stream se actualiza durante 5 años. Las compilaciones alternativas de RHEL se presentan como un sistema de contrapesos, compensando el modelo comercial de Red Hat, que impone términos adicionales al suministrar aplicaciones bajo la GPL e ignora el derecho otorgado en la GPL a copias no restringidas del producto.

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

Si el año pasado me hubieran preguntado sobre que iba a escribir este año, sin dudas no pensaba que le iba a dedicar tanto de mi tiempo a hablar de suites ofimáticas. Ahora mi pregunta es si LibreOffice va a poder seguir el paso.

Más allá de la inclusión de herramientas de Inteligencia Artificial (Que veremos hasta en el Buscaminas) los diferentes proyectos han registrado un gran avance en otras áreas que están rompiendo las fronteras con otro tipo de programas como los editores de publicaciones de escritorio o los editores de video. ¿Podrá la suite ofimática de código abierto emblemática ofrecerrnos las mismas características?

¿LibreOffice va a poder seguir el paso?

Para responder a la pregunta del título resulta necesario entender qué es exactamente una suite ofimática, cómo fue evolucionando y cuáles fueron sus características

Los programas componentes de una suite ofimática son usualmente un procesador de textos, una planilla de cálculos, un programa de presentaciones y un gestor de base de datos.

Procesador de textos

El procesador de textos es un programa diseñado para crear, manipular, modificar, imprimir y guardar textos mecanografiados.

Es capaz de trabajar con los siguientes tipos de archivos:

• Texto plano: También conocido como texto sin formato, no incluye ninguna variación en el tamaño, tipo o forma de la tipografía. Tampoco se pueden insertar caracteres especiales.
• Texto enriquecido: En este tipo de texto ya podemos variar la tipografía, su tamaño, color y efectos como negrita, cursiva y subrayado.
• HTML: Este tipo de documentos es el que le indica al navegador cuál va a ser la estructura de la página web.
• Documentos nativos: Cada procesador de textos tiene su propio formato para la creación de textos. Este formato permite aprovechar todas las capacidades de creación y edición. La mayoría de los procesadores de textos del mercado puede trabajar de forma adecuada con los formatos cerrados y abiertos del mercado.
• XML: Es un lenguaje para el almacenamiento y compartición de datos mediante el uso de reglas. Estas reglas hacen que los documentos XML resulte legible tanto para humanos como para máquinas.
• PDF: Son las siglas en inglés de Formato de Documento Portable. Fue desarrollado por Adobe como una forma para compartir y presentar documentos sin tener que depender de determinado software, hardware o sistemas operativos. Originalmente, no fue pensado para la edición, aunque los modernos procesadores de textos permiten hacerlo.

La diferencia entre los procesadores de textos y los editores de textos es que los segundos solo pueden trabajar con texto plano.

Las funciones del procesador de textos son:

1. Dar formato al texto: Se puede cambiar el color, tamaño o tipo de fuente. Además, es posible destacar partes del texto con efectos como negrita, cursiva o subrayado.
2. Copiar, cortar y pegar: Cuando uno escribe un texto, muchas veces descubre que un párrafo no encaja, queda mejor en otro lugar o incluso en otro documento. Con un par de movimientos del ratón podemos hacerlo en cualquier procesador de textos.
3. Insertar archivos multimedia: Además de imágenes y gráficas de datos, los modernos procesadores de textos permiten agregar archivos de audio y video.
4. Chequeo de gramática y ortografía: La gramática es el conjunto de reglas que guían el uso del lenguaje. La ortografía regula el uso de las letras y los signos de puntuación. Aunque los procesadores de textos incluyen desde hace tiempo herramientas de control gramatical y ortográfico, las versiones más modernas lo hacen utilizando herramientas de Inteligencia Artificial.
5. Diagramación: Aunque en los viejos tiempos los procesadores incluían formas rudimentarias de estructurar el documento como la alineación, tabulado, uso de tablas o viñetas, los modernos pueden utilizar columnas, recuadros o textos ubicados en formas arbitrarias.
6. Búsqueda y reemplazo de texto: Otra capacidad que viene desde antes y resulta bastante autodescriptiva, Los modernos procesadores de textos permiten también la búsqueda de texto específico o alternativas de reemplazo usando sitios de referencia en Internet o herramientas de Inteligencia Artificial.
7. Trabajo colaborativo: Los procesadores de textos más modernos guardan los documentos en línea y permiten que varias personas trabajen en ellos al mismo tiempo, identificando cuál es el aporte de cada uno.

En el próximo artículo continuaremos analizando las características y evolución de los programas componentes de una suite ofimática para entender cuáles son los desafíos que enfrenta LibreOffice.

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

AlmaLinux y Rocky Linux responden a la reciente restricción de Red Hat

Hace poco, compartimos aquí en el blog la noticia de los cambios realizados por parte de Red Hat con relación al acceso al código (puedes consultar los detalles en la publicación aquí), en el cual básicamente restringe el acceso a codigo de RHEL afectando a terceros. Entre los principales problemas de la transición de AlmaLinux y Rocky Linux a CentOS Stream está la desincronización de la publicación de paquetes para RHEL y CentOS Stream.

Y es que como se menciono, el código del paquete RHEL ahora estará disponible públicamente solo a través del repositorio CentOS Stream, que sirve como base para futuras versiones de RHEL.

Sobre el caso, los proyectos AlmaLinux y Rocky Linux, que publican compilaciones compatibles con binarios de Red Hat Enterprise Linux, ya se han pronunciado al respecto y han emitido sus declaraciones con una hoja de ruta siguiendo la restricción de Red Hat del acceso público al código fuente de los paquetes RHEL.

En particular, no todas las fuentes de paquetes presentes en RHEL se migran a CentOS Stream al mismo tiempo, en el mismo orden y de la misma forma (es posible que a los paquetes publicados en CentOS Stream les falten algunos parches).

Las soluciones a corto y largo plazo para este cambio son algo que discutiremos en las próximas semanas. Dedicamos gran parte de nuestro tiempo hoy a profundizar para asegurarnos de que comprendimos la profundidad del problema y discutimos nuestras posibles opciones.

A corto plazo, trabajaremos con otros miembros del ecosistema RHEL para garantizar que continuamos brindando actualizaciones de seguridad con la velocidad y la estabilidad que nos caracterizan.

A largo plazo, trabajaremos con esos mismos socios y con nuestra comunidad para identificar el mejor camino a seguir para AlmaLinux como parte del ecosistema empresarial de Linux. Comparte Benny Vasquez, Presidente, Junta Directiva de la Fundación AlmaLinux OS

Por ejemplo, las actualizaciones relacionadas con la reparación de vulnerabilidades en paquetes con el kernel de Linux pueden publicarse en CentOS Stream con cierto retraso. Tampoco hay garantía de que los paquetes aparezcan en el repositorio de CentOS Stream en el momento del lanzamiento de RHEL o después.

Además, los números de versión de los paquetes en CentOS Stream y RHEL no siempre coinciden. El problema también surge con los términos de soporte: CentOS Stream se actualiza dentro de los 5 años posteriores al lanzamiento, y la vida útil completa de la distribución RHEL es de 10 años, es decir, CentOS Stream no puede ser una fuente de actualización para los últimos 5 años del ciclo de vida de una distribución.

Para los clientes, Red Hat ha dejado la posibilidad de descargar el código srpm de RHEL a través de una sección cerrada del sitio, que tiene un acuerdo de usuario adicional (EULA) que prohíbe la redistribución de RHEL. AlmaLinux y Rocky Linux usan paquetes srpm descargados del Portal de clientes de Red Hat con riesgos legales.

Si bien esta decisión cambia la automatización que usamos para construir Rocky Linux, ya hemos creado una mitigación a corto plazo y estamos desarrollando una estrategia a largo plazo. No habrá interrupciones ni cambios para ningún usuario, colaborador o socio de Rocky Linux.

AlmaLinux y Rocky Linux tienen la intención de continuar creando compilaciones que reproduzcan paquetes de Red Hat Enterprise Linux, sean totalmente compatibles con binarios, tengan un comportamiento idéntico (a nivel de errores) y se puedan usar como reemplazo de RHEL.

Las distribuciones tendrán que volver a trabajar en los procesos internos de generación de lanzamientos, pero nada cambiará para los usuarios y socios, los proyectos continuarán generando compilaciones rápidamente como antes. Para evitar la interrupción en la entrega de actualizaciones, ambos proyectos utilizarán primero una solución temporal, después de lo cual planean determinar una estrategia a largo plazo e implementar una solución a largo plazo más reflexiva, cuyas opciones aún se están discutiendo.

Como solución temporal, el proyecto AlmaLinux tiene la intención de cambiar al seguimiento de cambios desde el repositorio de CentOS Stream y también usar los repositorios de Oracle Linux para continuar generando actualizaciones de paquetes para corregir vulnerabilidades. Las actualizaciones generadas se revisarán y ajustarán más para garantizar la total compatibilidad con las actualizaciones de RHEL sin infringir los términos de la licencia de Red Hat.

Una solución alternativa para Rocky Linux es crear un repositorio adicional para controlar las actualizaciones no sincronizadas, obtener los paquetes srpm asociados con las actualizaciones faltantes mediante una solución alternativa y manualmente cárguelos en el repositorio de ensayo. Al principio, planean recibir paquetes a través de una suscripción a RHEL. En el camino, planean realizar un análisis legal del modelo propuesto y la posibilidad de colocar paquetes srpm en su repositorio sin cambiar la marca.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en los siguientes enlaces.

Anuncio de AlmaLinux: https://almalinux.org

Anuncio de Rocky Linux: https://rockylinux.org

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

Red Hat Enterprise Linux es una distribucion de Linux que dirige sus productos principalmente para empresas

Hace poco Red Hat dio a conocer mediante una publicación de blog un cambio en el enfoque de la publicación de las fuentes de los paquetes para su distribución «Red Hat Enterprise Linux», con lo cual básicamente da a conocer que a partir de ahora ya no publicará el código del paquete en el repositorio Git de git.centos.org.

Mediante este anunció, Red Hat informa a la comunidad que la única fuente pública para los paquetes RHEL ahora será el repositorio CentOS Stream, con lo cual desde la publicación del anuncio, los clientes y socios de Red Hat aún podrán descargar el código de los paquetes correspondientes a las versiones de RHEL a través del portal de clientes de la empresa, cuyo acceso requiere una cuenta.

Hay que recordar que hace dos años, Red Hat decidió redirigir sus inversiones en CentOS a otra versión llamada CentOS Stream. Este último existe desde septiembre de 2019 y sirve como «una muestra de lo que vendrá en Red Hat Enterprise Linux», como una versión de prueba previa para probar las funciones que estarán presentes en RHEL dentro de un año.

Red Hat menciona que el motivo de dicho cambio es con la finalidad de «promover la evolución de CentOS Stream», pero sin tomar en cuenta las afectaciones que esto conlleva a los diversos proyectos que dependen de la base de estos paquetes.

En su publicación de blog Mike McGrath, vicepresidente de ingeniería de plataformas centrales en Red Hat, comparte lo siguiente:

A medida que crece la comunidad de CentOS Stream y el mundo del software empresarial aborda nuevas dinámicas, queremos afinar nuestro enfoque en CentOS Stream como la columna vertebral de la innovación empresarial de Linux. Seguimos invirtiendo y aumentando nuestro compromiso con CentOS Stream. CentOS Stream ahora será el único repositorio para los lanzamientos públicos de código fuente relacionados con RHEL. Para los clientes y socios de Red Hat, el código fuente permanecerá disponible a través del Portal de clientes de Red Hat.

Para ser claros, este cambio no significa ningún cambio en CentOS Project, CentOS Stream o la disponibilidad de fuente para CentOS Stream o CentOS SIG.

Se menciona que para los proyectos CentOS y CentOS Stream, el nuevo modelo de distribución de fuente no generará cambios notables, pero las distribuciones de terceros como AlmaLinux, Rocky Linux, Oracle Linux y EuroLinux, creadas mediante la reconstrucción de paquetes RHEL, tendrán que repensar significativamente sus procesos de desarrollo u obtener acceso mediante soluciones alternativas para empaquetar el código de las versiones de RHEL.

La esencia de los cambios es que el codigo fuente de los paquetes para las versiones ya publicadas se publicaron en git.centos.org, y el código del paquete para las versiones que aún no se han publicado se está desarrollando en el repositorio de CentOS Stream, es decir CentOS Stream actúa como una base continuamente actualizada para el desarrollo de RHEL, que no es totalmente compatible con RHEL en binario (CentOS Stream se puede considerar como compilaciones nocturnas de prueba de RHEL).

¿Por qué hacer este cambio?

Antes de CentOS Stream, Red Hat envió fuentes públicas de RHEL a git.centos.org. Cuando CentOS Project cambió para centrarse en CentOS Stream, mantuvimos estos repositorios a pesar de que CentOS Linux ya no se construía aguas abajo de RHEL. El compromiso en torno a CentOS Stream, los niveles de ingeniería de inversión y las nuevas prioridades que estamos abordando para clientes y socios ahora hacen que el mantenimiento de repositorios separados y redundantes sea ineficiente. El código fuente más reciente seguirá estando disponible a través de CentOS Stream.

El cese de la publicación de paquetes en git.centos.org se debe al hecho de que la distribución CentOS se ha transformado en CentOS Stream y ya no se crea a partir de la fuente de los paquetes RHEL. CentOS Stream se presenta como un proyecto recomendado y prioritario, y mantener repositorios separados se considera ineficiente.

Cabe mencionar que esta última decisión de Red Hat ha provocado reacciones en los foros con respecto a las diversas bifurcaciones de CentOS. Como hace dos años, la gente habla de traición y violación de los términos de la licencia GPL, algo de lo que ya se ha promovido la SFC (puedes consultar la publicación de ello en este enlace).

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