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

Wasmer es un tiempo de ejecución de WebAssembly rápido y seguro que permite que los contenedores súper livianos se ejecuten en cualquier lugar

Hace pocos días se dio a conocer el lanzamiento de la nueva versión del proyecto Wasmer 4.0, en la cual se han añadido diversos cambios de los cuales se destaca por ejemplo la nueva arquitectura que permite conectar corredores personalizados, la estabilización de WASI, unificación de WAPM en Wasmer e integración de Wasmer Edge.

Para quienes desconocen de Wasmer, deben saber que es un runtime para ejecutar módulos WebAssembly que se pueden usar para crear aplicaciones universales que se pueden ejecutar en diferentes sistemas operativos, así como para la ejecución aislada de código no confiable.

La capacidad de ejecutar la misma aplicación en diferentes plataformas se proporciona al compilar el código en un código intermedio WebAssembly de bajo nivel que puede ejecutarse en cualquier sistema operativo o integrarse en programas en otros lenguajes de programación. Los programas son contenedores livianos que ejecutan pseudocódigo WebAssembly. Estos contenedores no están vinculados al sistema operativo y pueden incluir código escrito originalmente en cualquier lenguaje de programación.

Principales novedades de Wasmer 4.0

En esta nueva versión que se presenta de Wasmer 4.0, se destaca el soporte integrado para la plataforma de computación en la nube Wasmer Edge, que permite interactuar con Wasmer Edge directamente a través de la CLI de wasmer. Wasmer Edge es una plataforma descentralizada sin servidor que permite ejecutar aplicaciones en otros hosts en la red Edge.

La nueva plataforma combina la asequibilidad de Cloudflare Workers, la simplicidad de Heroku y la funcionalidad de AWS Lambda. La plataforma puede escalar desde un solo servidor hasta grandes clústeres distribuidos. En comparación con Cloudflare Workers y AWS Lambda, las aplicaciones que se ejecutan en Wasmer Edge pueden procesar solicitudes de servicios TCP arbitrarios, ejecutar cualquier aplicación HTTP, ejecutar aplicaciones en el navegador y en un teléfono inteligente.

En este momento, se pueden ejecutar sitios web estáticos, cualquier servidor Rust usando tokio (como Axum), aunque a futuro se planea soportar Flask, Django, WordPress, Ruby on Rails, Node, entre otros.

Otro de los cambios que se destaca de esta nueva versión de Wasmer 4.0, es que se agregó el soporte para la API de WASIX. WASIX es la estabilización a largo plazo y el soporte de WASI ABI existente, además de extensiones de llamada al sistema no invasivas adicionales que completan las brechas que faltan lo suficiente como para permitir que se compilen y utilicen aplicaciones reales, prácticas y útiles ahora. WASI amplía las características para una compatibilidad total con POSIX. Con WASIX, Wasmer puede ejecutar aplicaciones que utilizan subprocesos múltiples, sockets de red, procesos secundarios de bifurcación y otras funciones avanzadas.

Ademas de ello en Wasmer 4.0, tambien podremos encontrar que se ha implementado una nueva arquitectura de ejecución que permite ejecutar cualquier tipo de aplicación en WebAssembly y ampliar la ABI sin lanzar nuevas versiones de tiempo de ejecución. Actualmente, se admiten tres ejecutores: WASIX (compatibilidad con ABI WASIX), Emscripten (ejecutar programas compilados en Emscripten) y WCGI (permite crear scripts CGI en WebAssembly).

Por otra parte, tambien se destaca que la funcionalidad del administrador de paquetes WAPM se ha integrado, con lo cual ahora todos los comandos de la utilidad wapm para publicar y mantener paquetes están integrados en la CLI de wasmer. La finalidad de la integración es disminuir la carga significativa para el desarrollo y tambien que WAPM solo ha sido adoptado por Wasmer.

Finalmente, cabe mencionar que los programas se distribuyen en forma de módulos WebAssembly ordinarios, que se pueden administrar mediante el administrador de paquetes WAPM. Wasmer también está disponible como una biblioteca que se puede usar para incrustar código WebAssembly en programas Rust, C/C++, C#, D, Python, JavaScript, Go, PHP, Ruby, Elixir y Java.

El código del proyecto está escrito en Rust y se distribuye bajo la licencia MIT y puedes consultar más al respecto, en el siguiente enlace.

¿Como instalar Wasmer?

Para los interesados en poder instalar la nueva versión, solo deben de abrir una terminal y en ella deben teclear el siguiente comando:

curl https://get.wasmer.io -sSfL | sh

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