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