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