Best Of Tech #57

# RedHAT, crée le feuilleton de l’été ! 

par Thomas Broyer

C’était un peu le feuilleton du mois de juillet (alors que les scénaristes d’Hollywood sont en grève) : RedHat (IBM) a décidé de rendre les sources de sa distribution Enterprise Linux (RHEL) privées. C’est finalement un peu la suite logique d’un plan entamé il y a quelques temps déjà en arrêtant CentOS 8 pour ne plus avoir que CentOS Stream : CentOS était dérivé de RHEL, RHEL est désormais “dérivé” de CentOS Stream, et RedHat coupe maintenant l’accès public aux sources de RHEL, en dehors donc des clients (la plupart des logiciels sont sous license GPL, donc ceux qui ont accès aux binaires doivent avoir également accès aux sources). D’après cette analyse de John “maddog” Hall, IBM ne fait que protéger son business, citant de nombreux clients (apparemment) qui ne paient que pour quelques serveurs et utilisent les versions dérivées (CentOS auparavant, ou maintenant Rocky Linux ou Alma Linux) partout ailleurs.

Le “feuilleton du mois de juillet” a été la levée de boucliers d’une grande partie de la communauté open source (accusant IBM de vouloir se faire de l’argent sur le dos de projets libres), mais surtout les autres entreprises mettant leurs distributions de Linux en avant et prenant une posture de chevaliers blancs : SUSE qui annonce investir 10 millions de dollars pour créer un fork de RHEL, Oracle qui appelle IBM à dériver RHEL d’Oracle Linux pour économiser sur les salaires des développeurs RedHat ; ils finiront par créer ensemble en août, avec CIQ qui édite Rocky Linux, l’Open Enterprise Linux Association (OpenELA) qui vise à fournir les sources permettant de créer des distributions compatibles avec RHEL. Plus pragmatique, Alma Linux a décidé dès mi-juillet de se départir d’une compatibilité bug pour bug avec RHEL pour se concentrer sur une compatibilité binaire avec RHEL (un logiciel compilé pour RHEL devrait fonctionner sans modification sur Alma Linux).

À suivre…

# HTMX est un projet sans étape de build, pourquoi ? 

par Mathieu Sanchez

On trouve de plus en plus d’articles critiquant les différentes étapes de build qui peuvent nuire à un projet, par exemple la compilation typescript vers javascript.

Le contributeur au projet htmx, Alexander Petros, a rédigé un post expliquant les raisons de n’avoir aucune étape de build et ne pas faire appel à un système de modules (donc pas de import dans le code). Il détaille 

• la très forte compatibilité avec les vieux navigateurs
• la facilité de développement : le code écrit est le code exécuté
• la clarté du code : le projet n’est qu’un seul fichier javascript

Il reconnaît toutefois quelques défauts. L’utilisation de la modularité, par exemple, n’étant pas au cœur du projet, il peut être difficile d’étendre ou de surcharger les fonctionnalités. Il faut en passer par des extensions au projet, ce qui peut compliquer la tâche des développeurs contributeurs.

# Gitea, petit mais puissant ! 

par Valentin Marguerie 

Le monde des outils de gestion de versions basés sur Git est très vaste. Facile de s’y perdre, d’autant plus que chaque jour ou presque fleurit une nouvelle option open source.

Commencer comme un fork de Gogs, Gitea est un serveur Git qui présente l’avantage de s’appuyer sur les fonctionnalités présentes dans des outils éprouvés tels que GitHub ou GitLab comme la gestion intégrée des tickets ou le système de webhooks tout en mettant en avant la performance et l’expérience utilisateur. 

Facile à mettre en place, Gitea est compatible avec pléthore d’options pour son déploiement, en natif sur Windows ou Linux ou alors conteneurisé avec Docker et potentiellement un orchestrateur, il s’avère être d’une grande flexibilité pouvant s’adapter à de nombreuses architectures.

Niveau configuration, tout se passe par un simple fichier dans lequel on peut venir modifier une à une chaque option du gestionnaire. La documentation fournit un guide complet de toutes les options de configuration disponibles permettant ainsi à tout à chacun de personnaliser son installation.

Comme dit précédemment, Gitea met l’accent sur les performances. En effet, les minimas requis niveau matériel sont bien en deçà d’outils comparables, notamment GitLab. Niveau processeur comptez 1 cœur contre 4 recommandé pour GitLab et 1gb de ram contre 4 toujours pour GitLab. La différence est stratosphérique, ce qui permet de transformer presque n’importe quelle machine en serveur de gestion de version.

Toutefois tout n’est pas parfait, Gitea vient d’origine dans une version allégée de quelques fonctions pouvant s’avérer essentielles dans un cadre d’une utilisation professionnelle, notamment au niveau des outils CI/CD. Cela est néanmoins compensé par une compatibilité avec des services externes tels que les GitHub Actions (intégrées partiellement dans Gitea via les Gitea Actions).

La force de Gitea réside dans son côté open-source, et dans l’intégration de plugins tierces développés par la communauté. Il est ainsi possible de retrouver de nombreuses extensions permettant encore de personnaliser un peu plus son expérience sur la plateforme.

Ces atouts font de Gitea une option solide tant une utilisation personnelle, qu’en entreprise.