Dépêches Linuxfr

Dépêches Linuxfr

  1. Bonjour !

    Nous, l'équipe de développement de YunoHost, sommes heureux d'annoncer la publication de YunoHost 11, basée sur Debian Bullseye !

    Qu'est-ce que YunoHost ?
    YunoHost est un système d'exploitation qui vise à simplifier autant que possible l'administration d'un serveur pour ainsi démocratiser l'auto-hébergement tout en restant fiable, sécurisé, éthique et léger.

    portail YunoHost

    Pour quoi faire ? Administrer sa propre machine, c'est héberger soi-même ses données personnelles, celles de ses amis et de sa famille, en fournissant des services en ligne sans se reposer sur des entités privées.

    Par exemple, avec l’interface web simple et épurée de YunoHost, vous pouvez, pêle-mêle :

    • tenir un site internet avec Wordpress,

    • gérer vos boîtes mail avec Snappymail,

    • avoir un cloud à la maison avec Nextcloud,

    • vous lancer dans la domotique avec HomeAssistant,

    • jouer à des jeux rétro avec Retroarch,

    • ou encore organiser des visios avec Jitsi.

    Nous venons de passer la barre des 400 applications dont 200 applications de très bonne qualité dans le catalogue des apps.

    Comme toujours, nous avons beaucoup de fonctionnalités en cours de développement (environ 50 demandes d’ajout de code sur notre forge de code rien que sur le noyau au moment d’écrire ces lignes).
    Tandis que YunoHost 11.0 est axé sur l’adaptation à Debian Bullseye, les versions 11.1 et 11.2 devraient apporter des fonctionnalités très attendues par les utilisateur·ices, telles que :

    • 🌍 la mise à disposition des paramètres « globaux » de YunoHost depuis l’administrateur Web

    • 🔑 la possibilité de définir un mot de passe de récupération pour les domaines nohost.me / noho.st / ynh.fr

    • 👥 support pour plusieurs administrateurs (ouvrant la voie à l’authentification multifacteurs)

    • 📦 pour les packagers d’applications : un nouveau format simplifié de packaging d’applications (ouvrant la voie à une interface utilisateur améliorée pour le catalogue d’applications)

    • 🌀 sous le capot, une refonte du SSO/portail (ouvrant la voie à l’auto-enregistrement des utilisateurs, à la récupération des mots de passe des utilisateurs, à la création de portails personnalisés…)

    • ✨ et comme toujours, diverses améliorations de l’ergonomie de l’interface

    …et bien plus encore !

    Quant à cette version 11.0, les diverses améliorations et refontes de l’architecture sont souvent liées à la transition à Debian Bullseye 11. Celles-ci comprennent :
    - une meilleure intégration avec la gestion des versions de Debian et moins de modifications de la configuration standard
    - l’utilisation par défaut de Python 3.9, PHP 7.4 et PostgreSQL 13
    - une refonte de l’architecture du code
    - un mécanisme de mises à jour automatiques plus intelligent qui permet une meilleure expérience utilisateur
    - des améliorations de la sécurité, empêchant les utilisateurs de voir quels programmes d’autres personnes utilisent sur la machine

    Webadmin YunoHost

    Commentaires : voir le flux Atom ouvrir dans le navigateur

  2. Unvanquished est l’un des rares jeux qui combinent à la fois le mode FPS (First Person Shooter : Tir à la première personne en vue subjective) et le mode RTS (Real-Time Strategy : Stratégie en temps réel) en équipe.

    Chaque joueur peut choisir une faction : Aliens ou Humains. L’objectif étant d’annihiler la faction opposée. Les deux factions se jouent différemment, et c’est l’un des intérêts de Unvanquished.

    Malgré la différence importante de gameplay entre les deux équipes, certains mécanismes sont communs, avec notamment la possibilité de construire qui implique de ne pas avoir de capacité de combat importante. Vaincre des ennemis fournit des crédits qui peuvent être dépensés en améliorations pour le joueur, et la progression de l’équipe permet de débloquer des options de bâtiments et d’améliorations personnelles.

    Une nouvelle version est sortie, la 0.53, et nous allons vous présenter ci-après dans les grandes lignes les changements les plus importants.

    Unvanquished 0.53 - Splash screen

    Sommaire

    Deux factions : les Aliens et les Humains

    La faction humaine est particulièrement vulnérable au début, mais la grande majorité de leurs armes permet le combat à distance, et ils sont tous équipés d’une arme de poing, le blaster, qui est certes faible mais dispose de munitions infinies.
    Le port d’une armure est particulièrement recommandé, dès que possible. L’une de ces armures, la battlesuit, est l’armure la plus résistante, mais ne permet pas le port d’équipements dorsaux (le jetpack qui permet de voler et le radar qui permet de localiser et mettre en évidence des ennemis, partageant l’information avec l’équipe) et réduit drastiquement la mobilité des humains (fatigue accrue, impossibilité de courir sur les murs, taille plus imposante). L’armure moyenne permet de conserver une grande mobilité et d’avoir ces équipements additionnels.
    Les humains peuvent construire des bâtiments robustes, mais peu variés, dont ils peuvent accélérer l’auto-réparation avec le Kit de construction.

    Un humain en battlesuit avec le chaingun
    Un humain en tenue de combat avec le chaingun

    La faction alien se spécialise quant à elle dans le combat au corps à corps, bien que certaines de ses formes avancées disposent de quelques attaques à courte distance (les Dragoons et les Grangers peuvent cracher, le Marauder peut émettre de puissants arcs électriques).
    Afin de trouver et atteindre leur cible, les aliens disposent tous du sens alien qui leur permet de repérer ennemis et alliés au travers des murs, ainsi que de mécaniques de déplacements qui varient selon la forme : le Dretch, le Mantis, ainsi que les Grangers peuvent marcher sur les murs, le Mantis ainsi que les Dragoons (rien à voir avec les dragons européens ou chinois!) peuvent se propulser dans les airs, les Marauders peuvent rebondir sur les murs, et les Tyrants ont la faculté de charger.
    Leurs formes, tailles et bâtiments sont aussi variés que leurs capacités de déplacement.

    Alors que la faction Humaine est relativement simple à prendre en main, les différentes formes d’Aliens se jouent très différemment, et nécessitent un apprentissage pour chaque forme. Entre des mains expertes, les Aliens sont la faction la plus redoutable, et en particulier le Dragoon Avancé (Advanced Dragoon).

    Un dragoon prêt à bondir

    Un dragoon prêt à bondir

    Tout comme les personnages des factions, les bâtiments correspondants sont très différents. Les Humains bénéficient de bâtiments qui vont pouvoir attaquer à distance, en particulier le lance-roquettes (Rocket Pod), alors que la faction des Aliens ne peut compter que sur le nid de frelons (Hives) pour l’attaque à distance, qui est plutôt une forme de défense et sera utilisé à l’intérieur pour piéger un espace sans exposer le nid, vulnérable. Toutes les constructions Aliens sont vulnérables aux feux, et ne devraient pas être construites au sol ou trop serrées.

    Un joueur débutant sera plus à l’aise avec la faction humaine. Avec le SMG (arme de base) puis équipé d’une armure dès que possible, il pourra défendre la base et se joindre à un groupe pour faire ses premiers pas. Les joueurs débutants ne devraient pas s’aventurer seuls. Il est important de rentrer à la base dès que la situation commence à s’envenimer (trop de blessures, groupe diminué, manque de munitions, etc.). Notez que les Humains bénéficient d’un Medikit, gratuit, qui leur permet de récupérer lentement de la santé et de lutter contre le poison inoculé par les Aliens. Le Medikit se récupère à la Station de Soin (Medistation).

    Que ce soit dans la faction humaine ou celle des aliens, vous pouvez facilement vous mettre à dos les membres de votre équipe en construisant, voir en déposant à foison des Drill/Leech ! En effet, la destruction des bâtiments par les ennemis leur donne des points qui leur permettront de devenir plus dangereux. Le placement inadéquat d’une construction peut facilement faire basculer la partie en défaveur de l’équipe.

    La documentation !

    Le Wiki fournit des astuces avec des captures d’écrans : wiki.unvanquished.net/wiki/Gameplay
    Et pour ceux qui veulent essayer rapidement : wiki.unvanquished.net/wiki/Get_started_easy

    Il y a eu beaucoup de changements entre la version 0.52 et 0.53. Le plus visible étant que les bots sont moins stupides, en fonction de leur degré de compétence (qui était déjà réglable, mais ce réglage a un plus fort impact maintenant). D’autre part, les variantes pour les cartes et le mode PvE (Joueurs humains contre bots, acronyme très utilisé notamment dans le milieu des mmorpg : Player versus Enemy) apportent plus de diversité à la monotonie des cartes.

    Plusieurs contributeurs ont porté d’anciennes cartes de Tremulous et les ont adaptées pour Unvanquished. Ces trésors rappelleront de bons souvenirs à certains. Ces cartes ne sont pas encore sur les serveurs officiels, mais sont disponibles sur d’autres.

    Installation et lancement

    La méthode recommandée pour installer Unvanquished est notre lanceur (parfois nommé updater), il se charge de télécharger, installer, mettre à jour, configurer le système et lancer le jeu. La configuration du système consiste à enregistrer le schéma d’url permettant de joindre une partie en cliquant sur un lien dans une page web ou dans le chat (ou tout autre moyen). Pour certains systèmes, le launcher s’assure aussi que le système d’exploitation autorise l’exécution du jeu.

    Les nouvelles d’Unvanquished 0.53

    En dehors des versions mineures, ceci est notre seconde bêta. Cela fait un an que nous sommes entrés dans la phase de bêta. Le projet Unvanquished a eu 10 ans le 29 févier 2022 !

    Notre chat a migré depuis Freenode vers Libera. Libera, Matrix et Discord sont reliés entre eux, ce qui permet aux utilisateurs des différents services de ne pas être isolés, voir notre page Chat.

    Deux nouveaux développeurs nous ont rejoint officiellement ; ils contribuaient déjà et font désormais partie de l’équipe : afontain et bmorel.

    Cette version est le fruit d’un travail assez important, et — comme avec les icebergs — la majeure partie n’est pas visible. Énormément de refonte et de documentation de code a été faite pour rendre les choses plus simples pour les prochains candidats à la contribution.
    En chiffres, cela donnait environ, en juillet 2022 :

    • 573 modifications pour le code du jeu (exclut donc les données qui sont dans un dépôt séparé, mais inclut les synchronisations), 248 fichiers modifiés (pour environ 420 fichiers), ~14 KLoC (milliers de lignes de code) ajoutées et ~11.5 KLoC supprimées, pour environ 144.4 KLoC au total.
    • 291 commits dans le moteur, 179 fichiers modifiés, ~4 KLoC ajoutées et ~6,2 KLoC supprimées, pour environ 156 KLoC.

    Les gros changements bien visibles

    La carte Parpax a été profondément remaniée par Viech, l’expérience de jeu est désormais très différente !

    La carte Parpax mise à jour
    La carte Parpax mise à jour

    Un serveur nommé « Nightly Experimental Server » a été mis en place par afontain, il reconstruit automatiquement les branches master du code et des données pour permettre de tester la majorité des changements sans attendre une nouvelle version (certains changements nécessitent malheureusement une rupture de compatibilité et ne peuvent y être testés, ceux-ci sont dans une branche à part, tandis que la branche master conserve sa compatibilité avec la dernière version du moteur publiée).
    Les données (cartes, etc.) sont reconstruites en utilisant Urcheon.

    Les gros bugs qui tachent

    Au moment d’apparaître en jeu il n’est plus possible d’entrer en collision avec un autre joueur qui se tiendrait sur un œuf ou un telenode. Il était déjà prévu que ça ne se produise pas, mais il restait quelques cas rares où cela se produisait, ce qui bloquait les joueurs !

    Les serveurs de jeu ne disparaissent plus dans la liste ! Les serveurs maîtres de jeux qui sont temporairement inatteignables sont réinterrogés après un certain délai au lieu d’être oubliés pour toujours, cela empêche de voir son serveur retiré de la liste parce qu’un problème réseau est temporairement apparu une fois entre le serveur maître et le serveur de jeu. Le code d’origine était pensé pour les limitations des réseaux des années 90 (il y avait même encore des contournements pour des limitations de Windows 95 !) et donc cette partie a été réécrite.

    Il subsiste un problème qui affecte uniquement les utilisateurs de connexion internet 4G Free Mobile (probablement dû à une restriction côté opérateur) et qui empêche de lister les serveurs de jeu (même s’ils sont correctement enregistrés sur le serveur maître). En attendant un correctif, ces utilisateurs peuvent utiliser notre liste de serveurs en ligne ou glander^W discuter sur IRC où un robot annonce régulièrement les serveurs peuplés. Le bug qui empêchait de se connecter à un serveur depuis la page du site une fois que le jeu avait déjà été lancé a aussi été corrigé !

    Le son du jetpack n’est plus audible à travers toute la carte (c’était un bug), pareil pour le son du bouton de l’ascenseur de la carte Spacetracks ! Pour la petite histoire, les sons positionnels doivent être mono…

    Les changements des interactions et de l’environnement du jeu

    Le mécanisme du lance-flammes a été modifié pour réduire le déséquilibre de puissance, les dégâts les plus efficaces sont les dégâts indirects (par le feu généré), et il faut plus de temps pour allumer un feu : on ne peut plus vraiment peindre le sol de flammes en courant, le lance-flammes devient donc surtout une arme d’attaque de base alien qui demande de la coordination alors qu’avant un seul joueur humain avec un lance-flammes pouvait mettre en échec une équipe entière d’aliens.

    Avant, on pouvait facilement créer un tapis de flammes:
    Flammes au sol

    Les blobs aliens (granger, dragoon, trapper) font désormais une taille de 5 au lieu de 0, ce qui rend leur usage moins élitiste. Les blobs sont des sortes de crachats que jettent certaines créatures ou constructions pour blesser, immobiliser, ralentir, éteindre des feux…

    Trappeurs (1), Épines projetées (2) et Tubes d’acides (3) en action:
    Trappeurs et Tubes d’acide en action

    Le rayon d’extinction de feu du crachat du granger avancé a été augmentée de 20 à 64 (environ 3 m dans le jeu).

    La portée d’utilisation des constructions (comme l’armurerie) est désormais la même pour les joueurs et les bots (et les joueurs qui utilisaient des raccourcis claviers), elle est donc plus courte.

    Le joueur alien est automatiquement écarté du mur pour avoir assez de place pour évoluer au lieu d’avoir un message frustrant qui dit qu’il faut bouger !

    Le canon lucifer vibre quand il charge ! En fait c’était déjà implémenté mais ça ne marchait pas ! Merci à bmorel d’avoir corrigé ça, parmi plein d’autres bugs.

    Le drill peut désormais recharger les armes à énergie ce qui permet de recharger ces armes dans des bases avancées. Cela rend plus intéressant de dépenser de l’argent dans une arme à énergie en sachant qu’elle peut être rechargée sans revenir à la base principale. Cela étend les stratégies possibles comme le fait de préférer dépenser du crédit personnel dans une arme à énergie plutôt que de dépenser les points de construction de l’équipe dans la construction d’une armurerie dans une base avancée. Le répétiteur avait cette fonctionnalité avant mais quand il a été remplacé par l’extracteur (Drill) cette fonctionnalité n’a pas été transférée (par accident), ce qui était donc une régression.

    Il devient possible de rejoindre la même équipe que d’autres joueurs même si le ratio joueur/bot est déséquilibré tant que l’équipe adverse n’est composée que de bots, tout en forçant l’équilibrage des équipes dès lors qu’il y a de vrais joueurs dans chacune des équipes. Cela permet à des joueurs de décider en début de partie de combattre ensemble contre des bots plutôt que d’être contraints à se battre l’un contre l’autre. Un vétéran peut ainsi choisir d’accompagner un nouveau venu plutôt que de le massacrer et le dégoûter du jeu (sans même en faire exprès, parfois).

    Un humain avec un pistolet laser près d'un Drill

    Un humain avec un pistolet laser près d’un Drill

    Améliorations de l’interface et des mécaniques du jeu

    Les icônes de l’inventaire ont été agrandies.

    En cas de course rapide, l’interface l’indique avec une icône spécifique. C’est particulièrement utile pour les joueurs qui utilisent le mode de bascule à la place de l’appui de la touche pour la course rapide. Spéciale dédicace à Bob Vador pour ce travail sur les pictogrammes.

    L’indicateur de mode de course

    L’indicateur de mode de course

    La capacité en oxygène est indiquée dans l’interface lorsque le personnage est sous l’eau. C’est aussi valable pour les Aliens.

    L’indication de la réserve d’oxygène

    L’indication de la réserve d’oxygène

    Les messages de chargement de carte ont été rétablis. Ce sont principalement des messages humoristiques, mais ils indiquent la progression du chargement, et certains messages sont utiles pour l’utilisateur, comme le message qui indique que les shaders GLSL sont en train d’être compilés.

    Messages de chargement des cartes

    Messages de chargement des cartes

    Il est toujours possible de voter quand on est seul dans un jeu.

    Les instructions de tutoriel pour la vie faible et le manque de munitions sont affichées en orange pour être mieux remarquées par le joueur.

    La description du battlesuit est désormais correcte et mentionne sa capacité à s’accroupir, celle du chaingun aussi et mentionne que le recul est plus faible quand on porte une battlesuit. La description et le tutoriel du granger avancé ont également été complétées pour mentionner la capacité d’immobiliser un ennemi et éteindre des feux.

    Lorsqu’un bâtiment est placé, la projection holographique est affichée en jaune à la place du rouge lorsque le bâtiment ne peut pas être construit pour des raisons autres que celles liées à l’emplacement. Par exemple quand le Réacteur ou l’Overmind sont encore en cours de déploiement.

    Le système de traduction du jeu a été ré-implémenté et couvre également les interfaces réalisées avec RmlUI, mais pour le moment les traductions n’ont pas été réalisées (et celles existantes sont fortement obsolètes). Les traductions ayant été délaissées pendant très longtemps le jeu n’est pas considéré comme traduit, mais il redevient possible de le traduire.

    La musique sur l’écran d’accueil peut à nouveau être coupée en modifiant la variable 'audio.volume.music'.

    Le maximum de FPS (même une fois débloqué) a été plafonné à 333 pour éviter des bugs (au-delà, ça peut générer des bugs à cause d’un manque de précision puisque les frames sont comptées en millisecondes). Les benchmarks basés sur la fonction 'timedemo' ne sont pas affectés par ces bugs et donc non-plafonnés.

    Le code d’initialisation OpenGL a été refait et les messages de diagnostic sont désormais plus utiles pour comprendre ce qui se passe quand ça ne fonctionne pas (merci à papap pour les tests !). La compilation des shaders GLSL qui ne sont pas nécessaires pour le menu principal est retardée au premier lancement d’une partie. Quand le joueur utilise un matériel peu performant, cela lui permet d’accéder très rapidement au menu pour désactiver des options au lieu d’attendre longtemps que le moteur compile des shaders que l’utilisateur compte désactiver de toute façon.

    Message d’erreur pour l’absence de OpenGL

     Message d’erreur pour l’absence d’OpenGL

    Le bug de rendu qui affectait les utilisateurs de cartes Intel UHD sous Linux et certains utilisateurs avec des cartes graphiques Nvidia a été corrigé. Si vous observez des zones noires, vous devez désactiver les lumières dynamiques (dynamic lighting), puis les réactiver à nouveau.

    Toutes les variables cvars de la logique de jeu (préfixes cg_ et g_) ont maintenant une description et une information sur le type.

    les Bots

    Un énorme travail sur les bots a été fait par bmorel !

    Les bots humains peuvent désormais utiliser des grenades, peuvent patrouiller autour des médistations en attendant qu’elles se libèrent au lieu de faire la queue, peuvent acheter un pulse rifle au lieu d’un canon lucifer pour défendre s’ils sont proches du réacteur (moyen basique mais efficace de faire en sorte que le bot détecte qu’il est dans la base et utilise une arme qui ne va pas faire trop de dommages collatéraux à sa propre base…), alternent l’usage du lance-flammes et du pulse-rifle…
    Ils vont aussi essayer de s’équiper (gilet pare-balles ou battlesuit, radar) avant de réparer une base. Les humains vont défendre leur base s’ils voient un ennemi pendant qu’ils se guérissent (mais encore faut-il qu’ils le voient !).

    Les bots aliens évoluent uniquement s’ils ont assez de santé pour ne pas gaspiller leurs points d’évolutions et enrichir l’adversaire. Leur comportement par défaut est maintenant d’évoluer avant de se battre, ce qui fait qu’ils sont plus efficaces pour défendre leur base et enrichissent aussi moins les humains de cette manière.

    Le code d’achat des bots a été réécrit, les bots humains peuvent acheter n’importe quelle combinaison d’équipements autorisés.

    Les bots essaient de fuir plus rapidement, en courant pour les humains, en sautant (jump), bondissant (pounce) ou chargeant pour les aliens. Le déclenchement de leur fuite est moins prévisible, dépend à la fois de leur compétence (skill) et de leur distance d’avec les points de guérison, ce qui leur permet parfois de se rebiffer s’ils sont attaqués au mauvais moment, mauvais endroit. Leur attaque (rush) dépend de combien d’argent ils ont, leur compétence, et ce qu’ils pourraient s’acheter. Certains problèmes de bots qui n’arrivent pas à accéder à l’armurerie ont été contournés dans certains cas, ça peut encore se produire mais moins souvent.

    Ils vont aussi aller se refaire une santé même s’ils ne sont plus en dessous de 50 %, selon leur niveau d’aptitude et la distance du point de remise en forme.

    Sur la carte Chasm les bots ne trouvaient pas l’armurerie dans la configuration par défaut. Ce problème est causé par les bâtiments qui génèrent des blocages de navmesh quand ils sont assez gros. Du coup, quand un bâtiment est dans une enclave (comme dans la configuration par défaut de Chasm) aucun chemin ne peut être trouvé. bmorel a été obligé de faire un hack dégueulasse (dixit) parce qu’il ne savait pas exactement pourquoi il y avait ce problème. Le contournement fait que parfois les bots se heurtent sur leurs propres constructions, mais c’est acceptable parce qu’ils savent se débloquer dans ce genre de situation, et que cela ne devrait plus arriver dans la prochaine mouture.

    Pour les administrateurs de serveurs

    L’option pour paramétrer le « tir ami » (friendly fire) est désormais configurée par faction, et réduit de moitié par défaut pour les aliens pour rendre les dégâts d’équipe moins dévastateurs pour cette équipe. Les possesseurs de serveurs peuvent modifier ces paramètres avec g_friendlyFireAlienMultiplier et g_friendlyFireHumanMultiplier.

    Des permissions additionnelles ont été données aux administrateurs qui ne sont pas des opérateurs de serveur. Le niveau 4 (« senior admins ») peut désormais utiliser les commandes pause, buildlog, revert, et bot. Les niveaux 2 et 3 (« junior admins » and « team managers ») peuvent désormais utiliser la commande bot. Pour que ce changement prenne effet sur un serveur préexistant, il faut malheureusement sauvegarder le fichier <homepath>/game/admin.dat, le supprimer, démarrer et éteindre le serveur, et insérer à nouveau vos administrateurs serveurs dans le fichier.

    Le fichier autogen_server.cfg n’est plus exécuté au démarrage du serveur.

    Les fichiers démo ont été renommés pour permettre un triage des fichiers par date et heure.

    GeoIP n’est plus utilisé. Cette bibliothèque était utilisée par le serveur de jeu pour connaître d’où se connectaient les clients.

    Changements de cvar:

    • Les cvars logs.logLevel.* ont été renommées en logs.level.* ;
    • g_autoPause est désormais désactivée par défaut, puisque cela gèle les joueurs mais n’empêche pas le temps de s’écouler. Cela met donc en jeu d’une façon qui casse le système de momentum et de point de construction :
    • De nombreuses commandes et cvars obsolètes ou cassées ont été abandonnées, le plus souvent parce qu’elles n’avaient tout simplement jamais été implémentées. Notamment g_botKickVotesAllowed et g_botKickVotesAllowedThisMap ont été remplacées par g_disabledVoteCalls.
    • 23 cvars inutilisées ont été retirées du code du jeu.
    • Les délais de suicide (commande /kill) peuvent désormais être ajustées avec la cvar g_killDelay.
    • g_teamForceBalance a un nouveau paramètre. Quand cette cvar est mise à « 2 », le serveur va désormais permettre à tous les joueurs de rejoindre la même équipe tant que l’autre équipe n’a que des bots.

    La documentation des cvars a aussi été améliorée: toutes les cvars qui ont un impact en jeu ont désormais un texte explicatif. Cela signifie que vous pouvez utiliser la commande /listCvars pour y trouver de l’inspiration.

    Intelligence artificielle

    Les options pour contrôler les comportements des bots qui n’avaient pas été implémentées (toggle rush, toggle heal, group size, toggle build…) ont été retirées, et des options pour leur permettre ou les empêcher d’acheter un équipement donné ou une classe ont été ajoutées et intégrées à l’interface.

    Il est aussi possible d’ajuster le nombre (en pourcentage) de radars que les bots veulent avoir dans leur équipe.

    Il est possible de changer l’habileté (skill) par défaut des bots, ce qui signifie qu’il n’est plus nécessaire d’ajouter systématiquement l’option d’habileté en ajoutant les bots si vous voulez des jeux plus faciles ou plus difficiles.

    Il n’est plus possible pour les bots d’avoir une habileté de niveau 10, puisque cela cassait beaucoup leur visée.

    Il n’est plus nécessaire de créer un fichier .dpk pour fournir des « behavior tree  » ou des « _navmesh » personnalisées. Ces fichiers peuvent être personnalisés en plaçant une version modifiée dans le sous-dossier game/ du dossier utilisateur (homepath).

    Pour les modeurs et les contributeurs

    libRocket, la bibliothèque d’interface graphique utilisée pour implémenter pratiquement toute l’interface graphique utilisateur (GUI) et le HUD était abandonnée depuis longtemps par ses auteurs, nous avons terminé la migration vers RmlUi. Cette dernière est un fork maintenu de libRocket avec quelques nouvelles fonctionnalités. Cela devrait permettre d’implémenter des HUD/GUI plus agréables, par exemple, des contours de caractère pour rendre le texte plus lisible dans les zones très claires.

    Le mécanisme de traduction a été réimplémenté et inclut les éléments GUI/HUD. Les anciennes traductions n’ont pas été utilisées, car elles sont pour la plupart obsolètes (d’où cette mise à jour dans la section « pour les contributeurs »).

    De nombreux fichiers liés au gameplay ont été déplacés de divers dépôts vers unvanquished_src.dpkdir pour en faciliter la maintenance.

    Suppression de nobuildsurface, noalienbuildsurface et nohumanbuildsurface rendus obsolètes par le contentparm nobuild (les surfaces héritent de la propriété du contenu).

    Outils de débogage : cg_drawBBOX affiche la zone d’effet des flammes au sol (en plus des boîtes englobantes du joueur et de la construction). cg_drawDebugDistance affiche une sphère autour du joueur de la taille sélectionnée pour se faire une idée des distances.

    Affichage de la sphère de distance avec l’outil de debug

    Affichage de la sphère de distance avec l’outil de debug

    Zone d’effet des flammes au sol avec l’outil de debug

    Zone d’effet des flammes au sol avec l’outil de debug

    Les fichiers .arena ne sont désormais plus utilisés pendant l’affichage de la liste des cartes pour éviter des ralentissements.

    La commande /give permet maintenant de donner de la vitesse à une équipe spécifique.

    Les bots peuvent désormais cibler directement le bâtiment ennemi ou allié le plus proche, des nœuds d’arborescence de comportement inversé ont été ajoutés et divers autres changements. Une page de documentation sur le travail en cours sur le mécanisme de l'arbre de comportement et sur l’API est disponible dans le wiki.

    La commande /testmodel permet de tester des modèles avec squelette.

    La nouvelle cvar cg_lazyLoadModels peut être utilisée pour accélérer le chargement de gamelogic pendant /devmap.

    Pour améliorer la compatibilité avec les cartes Tremulous, le flag solid sur env_afx_gravity / trigger_gravity est supprimé automatiquement. Il est donc maintenant possible d’entrer dans une zone avec une gravité modifiée, celle-ci aurait été traitée comme des murs dans la version 0.52.1. De même, trigger_class et trigger_equipement devraient maintenant fonctionner comme ils le faisaient dans Tremulous.

    Les paquets de carte doivent avoir un nom commençant par map-<nom_de_carte> et contenir un fichier maps/<nom de carte>.bsp.

    Les paquets peuvent utiliser des fichiers DELETED (comme DEPS) pour ignorer des fichiers de leurs parents, qui peuvent être utilisés pour créer des paquets partiels supprimant des éléments du jeu officiel.

    C++14 est désormais autorisé dans Daemon et la base de code est plus compatible avec la détection de failles addressSanitizer.

    La compilation est plus facile à configurer grâce à des valeurs par défaut plus saines et à des descriptions d’options améliorées.

    Capacités de benchmark

    Pour les benchmarkers et ceux qui écrivent des logiciels de benchmark et veulent un benchmark Unvanquished, une « démo » (un fichier qui enregistre les positions et actions d’une partie en vue d’être réaffichés) est fournie à cette intention ici. Décompressez le fichier .dm_86, enregistrez-le dans le dossier <homepath>/demos/ et exécutez cette commande :

    daemon -set demo.timedemo on -set common.shutdownOnDrop on +demo_play unvanquished-benchmark_0.53.0
    

    Le jeu va démarrer, jouer la démo et quitter automatiquement. Quelques statistiques de ce genre peuvent alors être trouvées dans le fichier <homepath>/daemon.log :

    6199 frames, 12.9s: 479.6 fps 
    Demo completed
    

    Le fichier démo fourni est spécifique à une version du jeu donc vous voudrez probablement télécharger le nouveau fichier démo quand une nouvelle version du jeu est publiée. Ce genre de fichier démo est fiable pour comparer la performance de divers matériels et logiciels en utilisant la même version du jeu, pas pour comparer la performance du même jeu au fur et à mesure de ses versions.

    Mise à jour 0.53.1 et nouveau lanceur

    Rapidement après la sortie de la version 0.53 certains joueurs ont commencé à remonter un bug pour le moins gênant et qui était resté sous-marin jusqu’alors : parfois le jeu se déconnectait du serveur après avoir réalisé une action (écrire dans le chat du jeu, ouvrir un menu). Ce qui était encore plus gênant était que le bug n’était pas reproductible quand le jeu était compilé en bibliothèque dynamique ou exécutable natif pour être exécuté dans un débuggeur. Et pour ajouter à l’inquiétude, le système breakpad devant générer des « crashdump » lorsque le code est compilé au format nexe (binaire indépendant du système d’exploitation pour la machine virtuelle NaCl) ne générait pas de crashdump pour ce crash précis (mais uniquement dans ce cas précis). Mais après une enquête demandant donc de relever de sacré défis, le bug a été identifié dans le « Garbage collector » Lua de la bibliothèque RmlUi, bug qui semble être déjà présent dans LibRocket que nous utilisions mais qui ne se manifestait pas. L’équipe Unvanquished a donc investigué en vitesse et publié une version 0.53.1 dans les 4 jours (le jeu affiche toujours la version 0.53.0 dans les menus car seul un petit composant a été modifié, c’est normal).

    Au passage une nouvelle version du lanceur a été publiée qui corrige un bug pas bloquant mais gênant : à la fin de la mise à jour de 0.52.1 vers 0.53.0 un message d’erreur s’affichait et il fallait redémarrer le lanceur pour qu’il termine l’installation et lance le jeu comme il faut… Il semble que le lanceur était confus que la nouvelle version du moteur soit plus petite que la version précédente…

    Plus de détails se trouvent dans un billet de blog dédié (en anglais).

    Conclusion

    Il nous reste beaucoup de travail à réaliser : beaucoup d’améliorations de l’IA sont encore possibles, il nous reste à mettre à jour la version de la lib de GUI/HUD que nous utilisons, ainsi que de développer de meilleures GUI et, plus important, nous avons l’espoir de remplacer notre intégration NaCl vieillissante avec Wasm, ce qui devrait nous permettre de prendre en charge plus d’architectures de matériel comme les systèmes ARM.

    Nous savons aussi que les mécanismes et l’environnement dans le jeu ne sont pas parfaits, mais nous croyons que nous avons grandement amélioré l’expérience de jeu cette année de développements et de contributions intenses. Si vous rencontrez une difficulté ou quelque chose dont vous voudriez discuter à propos du jeu, de son environnement, n’hésitez pas à venir en parler avec nous, que ce soit via notre forum, l’outil de suivi ou encore via les messageries instantanées quand vous serez lassés de guerroyer.

    Nous espérons que vous apprécierez cette version autant que nous.

    Unvanquished a désormais plus de 10 ans ! Nous publierons dans les prochains jours une rétrospective détaillée de notre histoire. Restez à l’écoute !

    Commentaires : voir le flux Atom ouvrir dans le navigateur

  3. En pleine torpeur estivale, il n’est pas trop tard pour vous plonger dans vos numéros doubles des sorties de l’été, à défaut de plonger dans la mer ou la piscine. Voici donc un petit tour subjectif et parti{e,a}l de la presse-papier sortie depuis fin juin, début juillet, celle que vous pouvez encore trouver dans vos kiosques à journaux préférés.

    Image une de Journal

    Les nouveautés de cet été 2022 :

    • GNU/Linux Magazine France no 258 plonge déjà dans le méta-verse ;
    • Linux Pratique no 132 sécurise les serveurs à l'aide de la foule ;
    • MISC magazine no 122 adopte le DevSecOps ;
    • Hackable no 43 économise l’énergie ;
    • Planète Linux no 127, moins sérieux, joue sous Linux pendant ses vacances ;
    • MagPi no25 décortique les atouts du Raspberry PI.

    Et toujours disponibles :

    • La fournée des Linux Identity Set et Pack no 52 et 51 respectivement, qui recyclent trois à quatre de leurs précédents magazines, chacun liés à une distribution plus ou moins récente, avec leur lot de DVD double face…

    Les sommaires des numéros sortis cet été 2022

    Mosaïque des couvertures GLMF 258 Mosaïque des couvertures LP132 Mosaïque des couvertures PL127
    Mosaïque des couvertures MISC122 Mosaïque des couvertures HK43 Mosaïque des couvertures MagPI 23

    GNU/Linux Magazine numéro 258

    Au sommaire de ce numéro de juillet - août 2022 :

    • Pourquoi utilise-t-on GNU/Linux ? Vraiment ?
    • Créer un Escape Game VR avec Godot ;
    • DaC ou pas DaC : comment vont vos diagrammes ?
    • Tests unitaires avec Jest ;
    • Découverte et prise en main de Kivy ;
    • Le namespace cgroup ne sera pas le dernier de la lignée.

    Linux Pratique numéro 132

    Au sommaire de ce numéro de juillet - août 2022 :

    • Une Arch Linux à la croisée de la puissance, du fonctionnel et de l’esthétique : Garuda ;
    • Ressuscitez vos machines virtuelles défaillantes ;
    • Sauvegardes avec PostgreSQL ;
    • Détecter et bloquer les attaques avec CrowdSec, l’IPS/IDS communautaire ;
    • Présenter avec Marp ;
    • La migration de Drupal 7 : vers Symfony ou l’au‑delà ?
    • Introduction aux tests d’intégration pour Ansible avec Molecule.

    MISC Magazine numéro 122

    Au sommaire de ce numéro de juillet - août 2022 :

    • Utilisation malveillante de l’API d’accessibilité sur Android ;
    • Collecte d’informations pour une opération Red Team ;
    • Investiguons dans Kubernetes ;
    • Dossier : Adopter le DevSecOps ;
      • Principes d’organisation du DevSecOps ;
      • Les indicateurs dans le DevSecOps ;
      • Retour d’expérience sur la mise en œuvre du DevSecOps ;
    • L’attaque des logs ;
    • Un défi laid : retour sur la conception d’un challenge de reverse ;
    • Le Threat Hunting avec osquery et fleet.

    Hackable numéro 43

    Au sommaire de ce numéro de juillet - août 2022 :

    • Intercorrélation par transformée de Fourier rapide sur microcontrôleur sous FreeRTOS, et les pointeurs de pointeurs ;
    • Linux sur STM32F746 avec Buildroot : une bien mauvaise idée ;
    • Réduisez la consommation de vos montages ;
    • Exécution d’anciennes applications binaires sur un GNU/Linux récent : l’exemple Quartus II ;
    • Instrumentez votre analyseur logique avec libsigrok ;
    • Brancher un téléphone à cadran sur une box : conversion du codage décimal par impulsion en codage Dual Tone Multi Frequency (DTMF) ;
    • Verilator, le simulateur Verilog le plus rapide du monde.

    Planète Linux numéro 127

    Au sommaire de ce numéro de juin - juillet 2022 :

    • L'actualité Linux du moment ;
    • Android-x86 9.0 r2  ;
    • Nitrux 2.1.1 ;
    • NixOS 21.11 ;
    • Fedora Linux 36 ;
    • M.A.O Découvrez Reaper ;
    • 9 jeux pour Linux ;
    • Chiffrer ses données ;
    • Comparatif : Visualiser l’occupation des disques durs ;
    • Comparatif : Séparer les instruments d’une chanson ;
    • Détecter une intrusion SSH ?
    • Cloner sa partition avec FSArchiver ;
    • Prise en main de Scribus ;
    • Micro Facturier pour les auto-entrepreneurs ;
    • Plusieurs distributions sur une seule avec Distrobox ;
    • Tourner une vidéo avec OBS Studio ;
    • Des logiciels pour tout faire ;
    • Astuces : Améliorez votre expérience Linux ;
    • C'est quoi un NFT ?

    MagPi numéro 25

    Au sommaire de ce numéro de juillet - août 2022 :

    • Coup de projecteur A
      • Les atouts cachés du Raspberry Pi ;
      • Petit bain d’électronique ;
    • Projets
      • Raspberry Pi 3 géant ;
      • Bornes d’arcade Fancy Octopus ;
      • Générateur de formes d’onde arbitraires ;
      • Pica et Dot (petits robots) ;
      • Badge de conversion de la parole en texte  ;
      • Cassette ZX Spectrum ;
      • Droïde Kimberlina ;
      • Radio à remonter le temps ;
      • M4All (microscope) ;
    • Tutoriels
      • Initiez-vous à l’électronique ;
      • Trombine en LEGO® animée par IA ;
      • Fabrication d’un jeu de quiz ;
      • Apprenez le langage assembleur ARM, 1ʳᵉ partie ;
      • Station audionumérique ;
      • CDP Studio, 1ʳᵉ partie : déclencher des effets avec des LED ;
    • Coup de projecteur B
      • Astrophotographie avec Raspberry Pi ;
    • Interview
      • Interview : Liz Upton ;
      • Interview : Mike Cook ;
    • Banc d’essai
      • Boîtier Argon EON ;
      • Kit HAT météo + capteurs météo ;
      • Badger 2040.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

  4. Cette revue de presse sur Internet fait partie du travail de veille mené par l’April dans le cadre de son action de défense et de promotion du logiciel libre. Les positions exposées dans les articles sont celles de leurs auteurs et ne rejoignent pas forcément celles de l’April.

    [Numerama] Quels sont les logiciels libres que l'État conseille en 2022?

    ✍ Julien Lausson, le vendredi 5 août 2022.

    La direction interministérielle du numérique et Etalab actualisent la liste des logiciels libres recommandés par État. Il y en a 287.

    [Le Monde Informatique] Sous pression, GitLab recule sur la suppression des dépôts inactifs

    ✍ Jacques Cheminat, le vendredi 5 août 2022.

    GitLab a fait machine arrière sur sa politique de suppression automatique des projets inactifs pour les utilisateurs d'un compte gratuit. La médiatisation de l'affaire et la colère de la communauté auront eu raison de cette stratégie.

    [Le Monde Informatique] L'histoire derrière gLinux, la discrète distribution de Google

    ✍ Steven J. Vaughan-Nichols, le lundi 1 août 2022.

    Le système d'exploitation Google le plus connu est Chrome OS. Mais le géant américain utilise en son sein sa propre distribution Linux pour postes de travail : gLinux. Sa principale caractéristique : réduire le labeur et le stress des équipes en charge de son déploiement et de son exploitation.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

  5. LinuxFr.org propose des dépêches et articles, soumis par tout un chacun, puis revus et corrigés par l’équipe de modération avant publication. C’est la partie la plus visible de LinuxFr.org, ce sont les dépêches qui sont le plus lues et suivies, sur le site, via Atom/RSS, ou bien via partage par messagerie instantanée, par courriel, ou encore via médias sociaux.

    Bannière LinuxFr.org

    Ce que l’on sait moins, c’est que LinuxFr.org vous propose également de publier directement vos propres articles, sans validation a priori de lʼéquipe de modération. Ceux-ci s’appellent des journaux. Voici un florilège d’une dizaine de ces journaux parmi les mieux notés par les utilisateurs et les utilisatrices… qui notent. Lumière sur ceux du mois de juillet passé.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

  6. Ceci est une invitation au voyage, dans le temps et dans l’espace. On commencera aux débuts de l’informatique, tels que les situe Terry Pratchett dans Le Huitième Sortilège, ou même avant, c’est difficile de savoir. On fera un tour en Chine, en Corée, à Mayence, à Venise, à Bayeux, à Paris, bien sûr, pour arriver là où tout a commencé (ou presque) : à Plovdiv en juillet de cette année. Oh, bien sûr, il sera question du caractère d’Ysabeau, mais aussi, mais surtout de l’écriture.

    En voiture, le Chemin de fer Transimpressux va bientôt partir.

    Train jaune

    Sommaire

    Préambule

    L’histoire n’est pas un fleuve tranquille et n’a pas un début et une fin qui passe dans un ordre purement linéaire, celle de l’écriture ne fait pas exception. C’est pourquoi la partie historique de la dépêche dont l’un des angles est de placer l’écriture numérique (électronique, etc.) dans un contexte historique n’est pas découpée en tranches temporelles. Et cela pas uniquement parce que l’histoire est mouvante, mais aussi parce que cela n’aurait pas trop de sens.

    Du très lourd à l’immatériel : trois types de supports et trois évolutions majeures

    Quand on se penche un tant soit peu sur l’histoire de l’écriture, on se rend compte rapidement qu’un type de support et un type outil d’écriture n’en remplace pas un autre, mais qu’ils s’ajoutent les uns aux autres et continuent à coexister.

    Des supports lourds et résistants

    Au commencement était le support dur : pierre, argile, bois, métal, etc. En fait, on n’en sait rien. Mais les supports durs comme la pierre étant très résistants, ce sont les supports les plus anciens de l’écrit qui nous soient parvenus. Évidemment, ce ne sont pas des supports très pratiques à utiliser, c’est lourd, (la pierre de Rosette pèse 762 kg pour « seulement » 112,3 cm de haut, 75,7 de large et 28,4 d’épaisseur, et en plus il en manque un bout) et, quand l’écriture est gravée, ce qui est un processus lent, il est très difficile de corriger. La preuve sur cette tombe du cimetière du Père-Lachaise à Paris.

    Rature

    Un peu de souplesse pour délier les plumes et les pinceaux

    C’est avec les supports « souples », première évolution majeure, papyrus, papier, parchemin, et même tissu que l’écrit et l’écriture ont pu réellement s’émanciper. Ces supports et leurs outils d’écriture, pinceau, calame, plume, et même aiguilles, voire navettes pour le tissu rendent l’accès à l’écriture plus facile, et surtout plus mobile, mais plus difficile à conserver. Il reste tout de même de beaux, et bons, témoignages du tissu comme support de l’écriture. L’exemple le plus connu étant sans doute la tapisserie de Bayeux, un genre de bande dessinée.

    Petit aparté, on a retrouvé récemment une pièce qui est, vraisemblablement, la fin de cette très longue broderie. Elle est, visiblement, légèrement postérieure au reste de la « tapisserie » et a été, semble-t-il, confiée à un autre atelier de broderie.
    Manchot de Bayeux
    Le texte aurait dû être brodé avec deux fils au lieu de trois et surtout pas à main levée.

    Plus sérieusement, pour en revenir aux supports de l’écrit. Dans la sphère européenne, tout au moins, au Moyen Âge, les premiers supports de l’écrit sur parchemin ont été le rotulus qui fait dérouler le texte dans le sens vertical et le volumen qui les fait défiler à l’horizontale. Il est possible que cette dernière façon de lire le texte en permettant, de facto, de faire des séparations de « page » a pu préparer l’avènement du codex, à savoir des pages reliées sans lequel l’imprimerie n’aurait pas pu se développer. Aujourd’hui, on retrouve, dans la langue française, des traces du volumen appliqué au livre dans le mot volume qui consiste en la séparation « intellectuelle » d’un ouvrage voulue par l’auteur ou l’autrice. On peut, de ce fait, publier un livre très long en plusieurs volumes ou réunir en un seul plusieurs tomes d’un même livre.

    Rotulus et volumen

    Il est aussi intéressant de constater que les sites web ont, d’une certaine manière, actualisé les notions de rotulus et de volumen et qu’aujourd’hui, les pages qui défilent sans fin peuvent être l’équivalent numérique du rotulus. Mieux, Wikipédia, sur sa page sur la tapisserie de Bayeux, permet, quand on clique sur cette image pour l’agrandir, de naviguer dedans avec la souris en « mode volumen ».

    L’imprimerie, seconde évolution majeure

    Évolution majeure parce que l’imprimerie permet la reproduction de l’écrit et sa diffusion et, de facto, le développement de l’écriture, l’imprimerie est, à notre connaissance, née en Chine entre 300 et 600 de notre ère. Les Chinois avaient recours à la xylographie, puis aux caractères mobiles en bois ou en terre cuite. En Corée, vers 1200 de notre ère, les techniques d’impression ont commencé à se développer et sont passées aux caractères mobiles en métal au début du XIIIe siècle. Le plus ancien ouvrage imprimé avec des caractères mobiles métalliques, du bronze en l’espèce, que l’on connaît est le Chiksimgyong (ou Jikji), un traité bouddhique que l’on peut télécharger sur le site de la BNF Gallica. Il a été imprimé en 1377.

    En Europe, l’imprimerie avec des caractères mobiles aurait commencé à se développer à partir de Mayence, vers 1445-1450, insufflée par Gutenberg qui n’a rien inventé de nouveau, mais, qui a considérablement amélioré les techniques existantes avec la fabrication des caractères en alliage de plomb (pas cher et ne nécessitant pas de grande température pour fondre) et d’antimoine, la conception d’une nouvelle presse d’imprimerie et de nouvelles formules d’encre.

    Venise figurait parmi les importants foyers de développement de l’imprimerie. Il convient de le relever parce qu’on lui doit le caractère romain1 (celui qu’on utilise actuellement) dessiné par Nicolas Jenson un imprimeur et probablement espion français venu s’installer à Venise après un passage à Mayence. Jenson met au point son style de caractère vers 1470. Le créateur du Times New Roman, Stanley Morison, aurait donné à sa police le nom de « New Roman » en hommage au caractère romain de Jenson. La ville de Venise, à la même époque, est aussi le foyer qui a vu l’italique naître, un style de lettre plus lisible en petite taille et occupant moins d’espace, permettant ainsi l’impression de livres de petits formats (les in-octavo). Elle a été inventée par Alde Manuce au tout début du 16e siècle.

    L’Italie n’était pas la seule terre où l’imprimerie s’est développée à partir du 15e siècle, en France, Claude Garamont va développer vers 1550, un caractère, le Garamond (oui, avec un d) qui va connaître de nombreux descendants et s’imposer très largement. Claude Garamont a été considéré, dans la sphère typographique, comme « le plus grand des graveurs et fondeurs de caractères de tous les temps ».

    L’avènement de l’écriture électronique, la troisième évolution majeure

    Et oui, on saute directement de la Renaissance à quasiment la dernière décennie (ou aux deux dernières) du vingtième siècle quand les ordinateurs sont devenus personnels et ont commencé à vraiment envahir les bureaux et les foyers. Au début, heureusement, cela a changé depuis, les imprimantes personnelles ne pouvaient imprimer que selon les caractères dont elles étaient dotées. Le nombre (et le type) de polices de caractères qu’elles offraient était un critère d’achat.

    Avec l’écriture électronique, numérique, informatique, digitale (barrez les qualificatifs qui ne vous vont pas), puis internet, l’écrit s’affranchit du matériel. Il peut évoluer, changer de forme, être diffusé à un large public sans passer par un intermédiaire spécialisé et tout de suite immédiatement. Il n’est plus figé pour l’éternité et peut être amendable et enrichi à l’infini (bon on ne parle pas des contenus de LinuxFr.org). Mieux, il peut plus facilement être communiqué à des personnes qui ne peuvent pas les lire avec leurs yeux sans qu’il soit nécessaire de faire des éditions, lourdes et coûteuses, spécifiques.

    Mais, évidemment, a contrario des supports matériels, l’accès à l’écrit n’est plus « naturel » et il nécessite un intermédiaire.

    Un point sur les polices et le droit d’auteur

    Qu’en est-il du droit d’auteur en matières de polices de caractères ? Un petit tour qui ne se veut absolument pas exhaustif, notamment sur la question des licences où ne seront évoquées que la licence Adobe, essentiellement parce qu’elle est sans doute l’une de celle les plus utilisées dans le secteur du graphisme, et les deux licences libres Apache et SIL OLF.

    Applicable ou non ?

    Le droit d’auteur ne s’est pas toujours appliqué aux fontes. Ainsi ; en 2001, selon le site Planète typographie, le Bureau américain des copyrights (US Copyright Office) refusait de protéger officiellement les polices de caractères. Lesquelles avaient été protégées de 1911 à 1976, date à laquelle il y a eu une révision du droit du copyright (Copyright Revision Act). Actuellement, ce qui est le fruit du travail de l’Association TYPographique Internationale (Atypi), le droit de protection intellectuelle s’applique, mais, pour la France, sur une durée de vingt-cinq ans. La police doit être :

    • vraiment nouvelle,
    • innovante,
    • personnelle.

    Critères qui excluent les variantes d’une police plus ancienne.

    Les licences

    Grosso modo, quand on utilise une police non libre, on n’a le droit de l’utiliser que sur un poste de travail, ou, sur le nombre de postes en conformité avec le droit d’auteur ou la licence. Également, on ne peut pas utiliser n’importe quelle police pour faire un logo, ni, évidemment, une fonte dessinée à l’usage exclusif d’une entreprise ou de tout autre commanditaire d’ailleurs. On se souvient des débuts fracassants de la Hadopi et de son logo qui utilisait une police créée pour France Telecom.

    La licence Adobe est liée à l’abonnement. Elle interdit beaucoup de choses (les interdictions font 3 408 signes !) et se réserve le droit de « demander des preuves de votre conformité aux présentes Conditions supplémentaires », le client devant accepter de leur « fournir celles-ci dans un délai de trente (30) jours à compter de la réception » de la demande d’Adobe.

    La licence Apache qui est l’une des deux licences les plus utilisées, à ma connaissance, par les fonderies qui fabriquent des fontes libres n’est pas spécifique à ce secteur. Elle autorise la modification et la distribution du code (et donc des polices dans le cas d’espèce) tout en rendant obligatoire le maintien du copyright lors des modifications.

    La licence SIL OFL (lien en anglais), OFL pour Open Font Licence est une licence spécifique pour les polices de caractère. Ses objectifs sont clairement définis :

    • permettre à d’autres personnes de participer aux projets de création de caractères,
    • permettre à d’autres personnes de répondre aux besoins pour lesquelles les fonderies n’ont pas les ressources nécessaires (notamment la connaissance des glyphes nécessaires à une langue),
    • partager les connaissances et les expériences dans le domaine des systèmes d’écriture et transmettre les outils,
    • donner à la communauté les moyens de répondre à ses besoins en matières de caractères.

    La licence OFL (parfois appelée seulement SIL), permet d’utiliser, d’étudier, de modifier et de redistribuer les polices qui sont sous cette licence à condition qu’elles ne soient pas vendues seules, mais elles peuvent être regroupées, intégrées, redistribuées et/ou vendues avec n’importe quel logiciel, à condition que leurs noms ne soient pas utilisés par des œuvres dérivées. Les fontes et leurs dérivées ne peuvent toutefois pas être distribuées sous un autre type de licence.

    L’obligation pour les fontes de rester sous cette licence ne s’applique pas au document qui utilise les polices ou leurs dérivés.

    Les autres licences libres étant, d’après le Floss Manuals « Fontes libres », susceptibles de pouvoir s’appliquer au secteur.

    Mais que vient faire Ysabeau dans tout ça ?

    Ysabeau est une collection de fontes dessinée et développée par Christian Thalmann de Catharsis Fonts sous licence SIL OFL. Selon son auteur, Ysabeau combine :

    la forme des lettres traditionnelles et extrêmement lisibles hérité de Garamond avec la netteté d’une police sans empattement à faible contraste, ce qui la rend bien adaptée aussi bien au texte qu’à l’affichage.

    En clair, une police faite pour la titraille (ensemble des éléments entrant dans la composition d'un titre) comme pour le reste du texte qui s'affiche et s’imprime bien. Ce qui n’est pas toujours si évident.

    Il y a trois versions d’Ysabeau (la police de caractères) :

    • Ysabeau,
    • Ysabeau SC, qui est une version à petites capitales (Small Caps), tout à fait adéquate pour la titraille,
    • Ysabeau infant dont le zéro est un vrai zéro et pas un o minuscule et dont, notamment, le dessin du « a » est différent.

    Les p et le q minuscules sont visiblement différents et pas le même glyphe retourné. Il en va de même pour le b et le d minuscules. Elle propose en outre des fonctionnalités intéressantes, comme, par exemple les ligatures historiques. Pour ce qui est de sa parenté avec Garamond je vous laisse juge. Ci-dessous, les trois variantes d’Ysabeau avec une Garamond.

    Ysabeau et Garamond

    Personnellement, je trouve qu’elle est très proche de LinuxBiolinum G.

    Ysabeau et LinuxBiolinum G

    Christian Thalmann est aussi l’auteur de la très élégante police Cormorant plus visiblement, à mon avis, inspirée de Garamond.

    C’est une dépêche ysabélienne donc…

    Donc, deux ou trois astuces pour vos documents s’ils vous paraissent un peu tristounets. Vous ne les améliorerez pas par magie en changeant d’outil de production, surtout si vous ne connaissez pas du tout l’outil et les notions essentielles en typographie.

    Aérer

    Le gris typographique, à savoir le rapport du texte, noir, sur la page, blanche est une notion essentielle. Il n’y a pas de règle précise parce que ça dépend du texte, mais un ensemble de facteurs sur lesquels veiller :

    • un bon réglage des marges, elles ne doivent pas forcément être identiques sur les quatre côtés, notamment si vous avez des en-têtes et des pieds de page, dans LibreOffice, les marges du haut et du bas de la page sont la distance du texte par rapport au bord de la feuille (en-tête et pied de page inclus),
    • des espacements entre les paragraphes, plutôt plus grand au-dessus et une valeur un peu plus petite en dessous, ne pas garder les valeurs par défaut la plupart du temps,
    • paramétrer des interlignes plus grands que la simple ligne, dans LibreOffice par exemple entre 120 et 125 %,
    • au besoin mais cela peut dépendre, on peut envisager de modifier l’espacement entre les caractères (dans LibreOffice c’est dans la position des caractères).

    Changer de caractère

    Le choix de la police est, évidemment, fondamental. Le simple changement de la police de caractères peut modifier considérablement, en bien ou en mal, l’allure de vos documents.

    La seule véritable règle à adopter est d’avoir des titres et des intertitres visuellement bien différenciés du reste du texte. Cela peut passer, outre par les blancs entre les paragraphes, par :

    • une police de labeur et une de titraille, dans ce cas, il est préférable d’opter pour une paire police empattée et police bâtons, afin d’éviter des assortiments malencontreux, on peut même choisir des familles de polices qui ont des versions avec et sans empattements : DeJaVu (ou DejaVu LGC) ou Noto par exemple,
    • une seule famille de caractères mais des titres en petites capitales, personnellement, j’aurais bien du mal à apparier Linux Libertine G, Luciole, Garamond ou encore Jost* avec une autre police,
    • adopter Ysabeau, non seulement elle a bon caractères, mais elle propose aussi une version en petites capitales.

    Enluminer vos titres de chapitre, voire, vos pages

    On peut faire, effectivement, du très laid comme du superbe, du très ancien comme du très moderne. Cela dit, on n’est pas obligé de faire moche.

    Il se trouve que depuis les versions 7.2 LibreOffice permet d’avoir des arrière-plans qui débordent sur les marges. Et, un arrière-plan ce n’est pas forcément un dessin qui va prendre toute la page.

    Ainsi dans ce document enluminé d’arabesques à fleurons, l’encadrement du titre principal est un arrière-plan, les intertitres (Titre 1) ont un arrière-plan (placé en haut) et une ligne horizontale paramétrée elle aussi avec un arrière-plan donne l’illusion que le texte est encadré de fioritures. Et évidemment, vous avez compris comment le pied de page est fabriqué.
    Enluminure

    Mais on peut aussi ajouter simplement une couleur d’arrière-plan aux titres de chapitre.

    Dans la fabrique de la dépêche

    Pour cette dépêche outre les liens in-texte et hors texte, j’ai lu, consulté entre autres :

    • La Venise de livres, 1469-1530 de Catherine Kikuchi, Champvallon 2018, ISBN 979-10-267-0702-8, il existe en version papier (que je suggère) et en PDF qui est une horreur sur le point technique, il a été composé comme à l’époque traitée par le livre, plat sans table des matières cliquables ni lien d’appels de notes, c’est dommage parce que c’est un livre fort intéressant et agréable à lire qui traite plus des gens que des techniques ce qui le rend précieux,
    • Le Document à la lumière du numérique, de Roger T. Pédauque, C & F éditions, mars 2011, ISBN 2-915825-11-4, il y a des passages un peu datés mais ça reste une analyse intéressante du statut du document, analyse menée par une équipe pluridisciplinaire (de divers domaines des sciences),
    • Typographie et civilisation, un site, malheureusement plus mis à jour mais qui est une mine sur le sujet avec des textes bien référencés et sourcés. Un certain nombre des sources auxquelles j’ai accédé sur la typographie et l’imprimerie sont malheureusement assez anciennes et plus mises à jour. Et c’est d’autant plus regrettable que les sites plus récents m’ont eu tout l’air de délivrer la même soupe commerciale. C’est là qu’on voit une évolution très triste du web.

    Il a fallu aussi que je fabrique deux-trois trucs :

    • si c’est plutôt le point de Bayeux qui vous intéresse,
    • si ce sont les enluminures, le train ou les différences entre les rotulus et les volumen, rendez-vous, ben dans mes pictos et dessins ou sur open-clipart, je vous laisse deviner sous quel nom (il y a des indices dans la dépêche),
    • et, évidemment, si on peut dire, il y a le tutoriel sur des enluminures sans stress avec Writer, que j’ai rédigé en préparation de cette dépêche.

    Postambule

    Ce mot n’existe pas et c’est bien dommage.

    Ce voyage a plus ou moins commencé dans la plus ancienne ville d’Europe encore peuplée, Plovdiv qui accueillait en même temps une exposition de typographie de son école d’art Prof. Asen Diamandiev et un touriste de passage à qui l’exposition qui présentait des travaux d’élèves dont une très élégante affiche en Ysabeau, a, on se demande bien pourquoi, fait penser à LinuxFr.org. C’est donc à Plovdiv2 qu’il se termine.

    Le Chemin de fer Transimpressux espère que vous avez fait un bon voyage et serait heureux de vous revoir très prochainement pour poursuivre cette excursion qui se poursuivra notamment au Tibet, dans l’Europe médiévale et en Terre du milieu.


    1. Les caractères utilisés jusque-là étaient du gothique. 

    2. Plovdiv où l’auteure de la dépêche n’a, hélas, jamais mis les pieds. 

    Commentaires : voir le flux Atom ouvrir dans le navigateur

  7. Calendrier Web, regroupant des événements liés au Libre (logiciel, salon, atelier, install party, conférence), annoncés par leurs organisateurs. Voici un récapitulatif de la semaine à venir. Le détail de chacun de ces 2 événements (France: 1, internet: 1) est en seconde partie de dépêche.

    [internet Chambéry] Mapathon Missing Maps - Le lundi 8 août 2022 de 18h00 à 20h00.

    Un mapathon c’est quoi ? C’est un atelier en ligne de cartographie solidaire et participative en soutien aux organisations humanitaires et/ou de développement.

    CartONG organise ce mapathon dans le cadre du projet Missing Maps visant à cartographier toutes les zones encore invisibles sur les cartes, qui permettent par la suite aux communautés locales et acteurs et actrices de l’humanitaire et du développement de pouvoir agir plus efficacement en cas de crise ou initier des projets de développement local.

    Avec quel outil  La plateforme de cartographie libre et contributive OpenStreetMap (OSM, le «Wikipédia des cartes») où tout le monde peut participer à la cartographie de n’importe quelle zone de la planète: il suffit d’un ordinateur, d’une souris et d’une connexion internet ! Aucune connaissance en cartographie ou en informatique n’est requise.

    Grâce à la couverture globale d’images satellites disponibles aujourd’hui, il est possible de tracer facilement routes, bâtiments ou cours d’eau, autant d’informations très utiles pour les organisations humanitaires et de développement sur le terrain.

    Pas besoin d’être un·e expert·e, c’est convivial et accessible à tout le monde!

    Pour s’inscrire : https://www.eventbrite.ca/e/billets-en-ligne-mapathons-missing-maps-2022-2023-133090064967

    [FR Lyon] Hadoly: permanence du chaton Lyonnais - Le mercredi 10 août 2022 de 19h00 à 21h00.

    La permanence (mensuelle) d’Hadoly (Hébergeur Associatif Décentralisé et Ouvert à LYon), chaton lyonnais, est l’occasion d’échanger avec les membres de l’asso sur les services et moyens mis à disposition des adhérents afin de se libérer des GAFAM tout en grignotant et en en buvant un coup (n’hésitez pas à apporter quelque chose).

    !!! COVID: écrire au contact pour obtenir les modalités de la réunion en présentiel et/ou visio, merci !!!

    Nous partageons du mail, du cloud, et d’autres services, le tout basé exclusivement sur des logiciels libres avec le respect de la neutralité du net et de la vie privée.

    Et en plus l’hébergement est physiquement local !

    Commentaires : voir le flux Atom ouvrir dans le navigateur

  8. La troisième version du document « Introduction à la programmation en Bash » (IUT de Rodez) vient de paraître. Elle est principalement destinée aux étudiants de niveau Licence.

    Contexte

    Il s’agit de la troisième révision du cours donné par Eric Sanchis à l’IUT de Rodez.

    Cursus

    L’IUT de Rodez, dans l’Aveyron, est un site délocalisé de l’Université Toulouse 1 Capitole. Il délivre un Bachelor Universitaire de Technologie (BUT) au bout de deux années d’études, soit quatre semestres validés.

    Il est possible ensuite, toujours à l’IUT de Rodez, de prolonger les études d’une année pour atteindre le niveau Licence dans le cursus LMD (Licence-Master-Doctorat).

    « Introduction à la programmation en Bash » est le support de cours du BUT Informatique.

    Auteur

    Eric Sanchis est Associate Professor à l’université de Laval au Québec depuis 2012. Il est aussi Maître de conférences en informatique à l’IUT Rodez où il enseigne depuis 1992, et y est membre permanent de l’équipe de recherche ARAL.

    Ce cours, dispensé depuis 2007, en est à sa troisième édition.

    Contenu

    Bien, que contient cette ressource ? Qu’y trouve-t-on pas ou pas ?

    Essentiel

    Il est mentionné au point 1.1.3.

    Toutefois, afin de rendre l’étude de bash plus aisée, nous n’aborderons pas sa syntaxe de manière exhaustive ; en particulier, lorsqu’il existera plusieurs syntaxes pour mettre en œuvre la même fonctionnalité, seule la syntaxe la plus lisible sera présentée, parfois au détriment de la portabilité vers les autres shells ou de la compatibilité POSIX.

    Ainsi, on trouvera la forme foo $(bar baz) fuu et non foo `bar baz` fuu
    De même, il est directement question en 10.2.2 de [[ sans jamais évoquer le plus portable [ mais plus limité.
    Ce choix assumé devrait permettre d’apprendre rapidement bash quand on vient d’autres langages de scripting.

    Progressif

    La table des matières montre un avancement progressif, et assez didactique.
    Les chapitres 2 et 3 traitent de l’expansion de la ligne de commande.
    Le chapitre 4 embrasse toute la problématique des méta-caractères et des expressions génériques.
    Le chapitre suivant discute des redirections et tubes qui font l’autre force des shell unixiens.
    Ensuite, on enchaîne sur les groupements de commandes et tout ce qui est relatif aux codes de retour.
    Les chapitres 9, 11 et 12, traitent respectivement : des chaînes de caractères, des expressions arithmétiques, et des tableaux.
    Les structures de contrôle du langage de programmation sont abordées aux chapitres 8 (pour case et while) et 10 (pour for et if)
    Les deux derniers chapitres évoquent les alias et les fonctions.

    Illustré

    Les différents concepts évoqués sont accompagnés d’exemples que l’on peut reproduire.
    Pour ne rien gâcher, il y a quelques exercices intéressants.

    Critiques

    Comme ce n’est pas une dépêche purement publicitaire, vous aurez bien entendu droit aux avis de l’équipe de rédaction.

    D’abord, bash 5… Les exemples ont été en effet testés avec la version 5.1, mais il n’y à rien qui soit spécifique aux versions 4.x ou 5.x ! Pour les gourous du bash qui espéraient trouver quelque plus, il faudra passer son chemin.

    Comme déjà dit, ce tutoriel va à l’essentiel en privilégiant les formes les plus lisibles. C’est une bonne chose de ne pas évoquer, quand c’est possible, les ésotérismes du shell…
    Par contre, la présentation des exemples peut dérouter quand il y a des commentaires. On trouve par exemple (en 11.7)

    declare -i x    # affiche les dix chiffres
    for (( x=0 ; x<10 ; x++ ))
    do
      echo $x
    done
    

    et aussi des trucs comme (en 2.1.1)

    $ x=coucou  y=bonjour       => la variable x contient la chaîne de caractères coucou
    $               => la variable y contient la chaîne bonjour
    

    Le contrat initial de favoriser une seule forme (en 1.1.3.) est rompu à la fin (en 14.10.) avec l’évocation de source et .

    Le contenu est disponible en deux versions : une web (cf. lien) découpée en plusieurs pages avec liens de navigation (précédant/sommaire/suivant), et un PDF téléchargeable.
    La version PDF utilise une étrange coloration syntaxique sans fond tandis que la version web n’utilise qu’un fond uni et du texte en noir, uni pour les exemples avec des variations de graisse et inclinaison dans le texte d’explication.
    Enfin, seule la version PDF comporte des exercices, ainsi que des références complémentaires

    Malgré tout cela, c’est une bonne ressource complète en français qui est plus simple que le mythique ABS (listé parmi les références de l’auteur.)

    NdM : cette dépêche a été soumise par l’auteur du cours, mais sous une forme tellement succincte qu’elle ne pouvait pas passer sous les fourches caudines de la modération qui a, cependant, trouvé le sujet intéressant. Gil Cot l’a quasiment entièrement récrite en l’enrichissant considérablement, notamment avec « le point de vue de la rédaction ». Il a mérité au passage les plus chaleureux remerciements de la modération.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

  9. Le projet Haiku (au départ nommé OpenBeOS) a démarré officiellement le 18 août 2001 avec le premier message sur la liste de diffusion : Ok, let's start (OK, allons-y).

    L’idée était de donner une suite à BeOS, un système d’exploitation non libre développé par Be Inc. Au début de l’année précédente, Be avait annoncé la mise en téléchargement gratuit de son système BeOS et un changement de stratégie pour se concentrer sur les « Internet appliances », ce qu’on appellerait aujourd’hui l’Internet des objets. Un certain nombre d’utilisateurs et de développeurs de BeOS ne souhaitaient pas voir ce système disparaître, et se sont rassemblés pour essayer d’y donner suite.

    21 ans plus tard, le projet est toujours là et la version 1 approche petit à petit. La troisième version beta a été publiée l'été dernier, et la beta 4 ne devrait pas tarder à arriver.

    Sommaire

    Il est difficile de lister tous les changements et évolutions qui ont eu lieu depuis la version beta3 publiée l'année dernière. Et une grande partie de la liste serait de toutes façons assez laborieuse à lire. Il y a eu plus de 280 tickets fermés, sans compter les changements qui n'ont pas fait l'objet d'un ticket de suivi.

    La liste ci-dessous est donc loin d'être exhaustive et donne seulement un petit apperçu des nouveautés.

    Améliorations de la libbe

    La libbe est la bibliothèque qui contient la majorité de l'API C++ de Haiku.

    On y trouve principalement des nouveautés dans la partie concernant les interfaces graphiques :

    • Il est désormais possible d'afficher du texte souligné, c'est utilisé par exemple dans AboutSystem pour mettre en valeur les liens hypertextes.
    • Il est possible de demander au serveur graphique de calculer la taille d'un rectangle permettant de contenir n'importe quel caractère d'une police donnée. Par exemple la table de caractères utilise cela pour dimensionner l'espace réservé aux caractères affichés.
    • Il est également possible de trier les items d'un menu après les avoir ajoutés dans le menu. Par exemple, le menu permettant d'afficher la liste des réseaux Wifi utilise cette possibilité pour afficher les réseaux avec le meilleur signal en premier. Auparavant, il fallait pour cela à chaque fois supprimer puis reconstruire le menu.

    D'autre part, l'API pour l'accès au réseau (HTTP, FTP) est à nouveau en cours de réécriture, les versions précédentes sont trop complexes à utiliser sans apporter grand chose au niveau des performances (au contraire).

    Un bug assez gênant a été éradiqué. Il concernait la façon dont certaines applications sont lancées. Sous Haiku il y a deux principales façons de lancer une application. Soit, à la façon Unix, comme un processus "enfant" d'une autre application en cours d'exécution (par exemple avec fork() et exec(), mais diverses fonctions permettent d'atteindre le même résultat). Dans ce cas, l'application nouvellement lancée hérite des variables d'environnement de son processus parent. Soit, à la façon BeOS, par exemple en utilisant BRoster::Launch(). Dans ce cas, sous BeOS, l'application est lancée sans dépendre d'une application parente spécifique. Cependant, dans Haiku, elle est rattachée à la session en cours de l'utilisateur et démarrée par l'instance correspondante du launch_daemon (cela fait partie du travail en cours pour pouvoir avoir plusieurs utilisateurs sur le même système).

    Dans ce deuxième cas, un problème dans l'implémentation de ces fonctions faisait que l'application lancée se retrouvait avec un environnement totalement vide. Ce cas se présentait par exemple pour les applications lancées via un raccourci clavier, ou encore à partir du lanceur QuickLaunch. Cela conduisait à toutes sortes de problèmes étranges avec les applications lancées par ce moyen, et ce bug s'est retrouvé parmi ceux évalués comme les plus importants par les utilisateurs de Haiku. Il est maintenant corrigé et ces applications sont lancées avec l'environnement par défaut qu'elles étaient en droit d'attendre.

    Du côté du package kit qui permet de gérer les paquets logiciels au format HPKG, la possibilité de compresser ces derniers au format Zstd a été ajoutée et est maintenant utilisée par défaut. Cela permet un gain de vitesse sur la décompression des paquets tout en obtenant une meilleure compression. Il reste des possibilités d'amélioration cependant, car la compression des paquets est faite par blocs de quelques kibi-octets afin de permettre l'accès non séquentiel au contenu. Chaque bloc étant compressé séparément, il ne peut pas référencer des données présentes dans les blocs précédents. Il est possible avec Zstd de faire cela plus efficacement, en construisant lors de la compression un dictionnaire qui peut ensuite être référencé pour la décompression de tous les blocs.

    Enfin, on peut signaler l'ajout d'un translateur pour les images AVIF parmi ceux fournis par défaut avec le translation kit. Ce format d'image peut donc être utilisé dès maintenant par n'importe quelle application utilisant les translateurs.

    Amélioration de la pile réseau

    Haiku utilisait jusqu'à présent certains pilotes de cartes réseau de FreeBSD, à l'aide d'une couche de compatibilité (cette approche a également été adoptée par la suite par le système temps réel RTEMS). Cependant, ces dernières années, les pilotes de FreeBSD sont de moins en moins bien maintenus, et actuellement les développeurs de FreeBSD préfèrent utiliser eux-même une couche de compatibilité avec Linux, qui semble complexe à mettre au point et à maintenir. En réalité, une partie des corrections sur les pilotes Wifi de FreeBSD proviennent de problèmes identifiés par les utilisateurs de Haiku et corrigés par ses développeurs.

    Haiku s'est donc mis en quête d'un autre endroit où trouver des pilotes facilement réutilisables. La solution est venue de OpenBSD, dont la pile réseau est similaire (mais pas identique) à celle de FreeBSD. La couche de compatibilité de Haiku est maintenant compatible avec ces deux systèmes, et de plus, les pilotes Wifi de OpenBSD sont compatibles avec le Wifi haut débit (802.11ac). Haiku est donc le troisième système libre après Linux et OpenBSD à pouvoir utiliser cette technologie.

    La compatibilité avec les pilotes de FreeBSD a également été étendue pour pouvoir réutiliser les pilotes pour les adaptateurs Wifi connectés en USB (en plus de ceux connectés en PCI). Cela fournit une solution pour les machines dont l'adaptateur Wifi interne n'est pas encore compatible avec les drivers de Haiku.

    Enfin, un nouveau pilote natif a été ajouté, pour les périphériques compatibles MS-RNDIS. C'est par exemple le cas du partage de connexion via USB des téléphones Android, qui peut donc maintenant être utilisé avec Haiku.

    Ce n'est pas tout : en plus des pilotes, des corrections à d'autres niveaux dans la pile réseau permettent d'utiliser des "Jumbo frames" (trames Ethernet jusqu'à 9000 octets, utilisées par exemple pour l'Ethernet Gigabit). Il y avait également des problèmes dans la gestion des délais dans le client DHCP, qui conduisait à inonder le réseau de requêtes et à considérer toute tentative de réponse du serveur comme obsolète.

    Enfin, il est de nouveau possible de démarrer Haiku depuis le réseau, en chargeant le noyau en PXE puis en montant un système de fichier mis à disposition par remote_disk_server.

    Pilotes graphiques et affichage

    Du côté de l'affichage, c'est surtout le pilote pour les cartes graphiques Intel qui a reçu l'attention des développeurs cette année pour assurer la compatibilité avec les nouvelles générations de processeurs graphiques de cette marque. Cela a été l'occasion de corriger également des problèmes et des fonctionnalités manquantes pour les cartes plus anciennes, par exemple le contrôle du rétro-éclairage sur les PC portables fonctionne sur un plus grand nombre de machines.

    Dans ce pilote et aussi celui pour les cartes Radeon, le travail se poursuit pour arriver à afficher une image sur les écrans utilisant un connecteur DisplayPort. La configuration du protocole DisplayPort est relativement complexe, avec de nombreuses étapes à franchir avant d'obtenir une configuration complète.

    Le pilote VESA peut maintenant patcher le BIOS VESA des cartes graphiques pour y injecter des modes vidéo personalisés. Cependant, cela ne fonctionne pas sur les cartes nVidia et AMD modernes, ce qui limite beaucoup l'utilisation de cette fonctionalité. Ce code ne sera peut-être pas conservé car il y a aussi un risque de "planter" le BIOS de la carte graphique, or le pilote VESA est celui normalement utilisé pour un mode "sans échec". Il faudra donc au moins protéger ce code par une option du fichier de configuration du noyau, et peut-être le désactiver par défaut.

    Les pilotes VESA et framebuffer ont été séparés proprement. Ils avaient été fusionnés parce que le serveur applicatif app_server ne pouvait avoir qu'un seul pilote "de secours", mais ce problème a depuis été corrigé. Il n'y avait donc plus de raison de faire cohabiter le code spécifique à VESA avec le code pour les framebuffers dans le même pilote, ce qui était la source de nombreux bugs.

    À un niveau beaucoup plus haut, le travail continue pour exploiter correctement les écrans à haute densité de pixels. Les bordures de fenêtres s'adaptent maintenant pour ne pas être ridiculement petites. La police de caractères du debugger noyau dispose maintenant d'une version agrandie pour ces écrans.

    Périphériques d'entrée-sortie

    Le pilote USB HID comprend maintenant les claviers utilisant le "N-key rollover". Les claviers classiques utilisent un buffer de 8 octets qui permet d'indiquer au maximum 8 touches enfoncées, en indiquant le numéro de chacune d'entre elles. C'est insuffisant en particulier pour l'utilisation dans les jeux vidéos, il existe donc des claviers dit "N-key rollover" qui utilisent un protocole différent, et envoient un tableau de bits dont chacun correspond à une touche du clavier. Cela prend un petit peu plus de bande passante sur l'USB (14 octets au lieu de 8) mais permet d'avoir n'importe quelle combinaison de touches.

    Le pilote HID de Haiku n'était pas capable de décoder la réponse envoyée par ces claviers correctement, et la plupart des touches ne fonctionnaient pas. Le problème est maintenant corrigé. De plus, le code de gestion du HID a été retravaillé afin de pouvoir le partager entre les pilotes USB, mais aussi I2C et Bluetooth qui sont encore en chantier et utilisent les mêmes formats de donnéees.

    Le pilote PS/2 a reçu quelques corrections pour éviter une réinitialisation du clavier lors de la détection de la présence d'un contrôleur PS/2 avec "active multiplexing" Synaptics. Le code a également été retravaillé pour déplacer une grosse partie de la gestion des touchpads en espace utilisateur, ce qui rendra plus facile les évolutions sur cette partie du code et l'ajout des touchpads Elantech. De plus, ce code pourra aussi être réutilisé pour les nouveaux touchpads connectés en I2C plutôt qu'en PS/2.

    Du côté des ports série, le code de gestion des TTY a été retravaillé pour intégrer les évolutions faites dans une copie de ce code utilisée uniquement pour le Terminal. Ceci a permis d'identifier un problème dans la gestion des locks entre les différents morceaux de code interragissant avec le TTY, qui pouvait dans certains cas (assez facile à reproduire) bloquer l'exécution, ou pire, faire planter le noyau. Ces problèmes sont maintenant tous corrigés.

    Toujours pour les ports série, un nouveau pilote pour les composants USB série CH340 de l'entreprise chinoise WCH est maintenant disponible (en plus des composants de chez Prolific, FTDI, Silicon Image, et du standard USB-ACM qui est utilisé par exemple pour les modems 3G). Le CH340 se trouve par exemple sur certaines cartes Arduino.

    Autres pilotes

    La pile USB a reçu encore de nombreuses corrections et elle est à peu près complète pour l'USB2 et l'USB3. Il reste probablement encore des problèmes avec les transferts isochrones, ce qui empêche de finaliser les pilotes pour l'audio USB et pour les webcams. Pour ces dernières, une solution de contournement est disponible : une application Android permet de transformer un téléphone en caméra IP, qui peut être ensuite utilisée dans Haiku.

    Il y a eu également quelques évolutions du côté du PCI, en particulier avec la gestion des "BARs" 64bits dans la plupart des pilotes. Il reste encore du travail, par exemple pour résoudre le bug numéro 3, ouvert il y a 17 ans, et qui a été partiellement résolu pour les architectures RISC-V et ARM64, mais pas encore pour x86 et x86_64, car il est plus complexe de traiter les différents mécanismes historiques sur les machines compatible PC en plus du mécanisme moderne utilisant ACPI.

    Ces progrès sur le PCI deviennent plus importants d'une part parce que le firmware des ordinateurs modernes ne propose plus forcément de faire l'initialisation nécessaire (c'était le cas autrefois pour assurer la compatibilité avec MS-DOS) et d'autre part parce qu'il n'est plus garanti que tous les devices PCI sont présents lors du démarrage du système. Ça n'est en fait plus le cas depuis pas mal de temps, par exemple avec les cartes ExpressCard, mais c'est de plus en plus courant d'avoir des bus et des périphériques PCI apparaissant (et même disparaissant !) après le démarrage de la machine. On rencontre ce cas de figure avec certaines stations d'accueil pour PC portables, et aussi avec les ports Thunderbolt (aussi appelé USB4) qui est en fait un port PCI avec un connecteur USB-C.

    Portage sur de nouvelles architectures

    La version RISC-V de Haiku était déjà annoncée dans la dépêche anniversaire de l'année dernière, elle était alors encore en chantier. La plupart des corrections ont été intégrées dans le dépôt Git de Haiku et cette version est maintenant installable à partir des "nightly builds" (elle est encore considérée "expérimentale").

    Le travail de X512, le principal développeur de cette version, a été récompensé par Haiku inc qui lui a offert une carte mère pour une machine avec un processeur RISC-V, lui permettant de travailler sur du matériel réel (après avoir fait une première partie du portage en utilisant QEMU et d'autres émulateurs de machines RISC-V).

    L'intégration de ce travail a permis de revoir le code de certaines parties de Haiku qui étaient problématiques pour des machines autres que x86. Cela a débloqué la situation pour les versions ARM 32 et 64bits qui sont, sur certains points, assez proches de ce qu'on trouve sur les machines RISC-V. En particulier, la découverte du matériel disponible à partir soit d'un FDT, soit de tables ACPI, est maintenant fonctionnelle. Il est probable que la version ARM de Haiku deviennent très bientôt utilisable.

    On peut enfin mentionner la disponibilité d'un chargeur de démarrage EFI 32bit pour les machines x86. Il a été développé principalement en préparation de la version ARM 32bit, mais il peut être utile sur les quelques machines qui n'ont ni BIOS, ni EFI 64bit (les premiers modèles de machines Apple x86, et certaines tablettes par exemple).

    Pour la version ARM, une première tentative avait démarré il y a plusieurs années en essayant d'utiliser une API fournie par u-boot pour, par exemple, envoyer des messages vers un port série ou vers l'écran. Cependant, cette API n'était pas toujours disponible sur les machines ciblées. Il fallait donc que le bootloader stage2 se débrouille "tout seul", avec uniquement le FDT comme point de départ pour trouver et initialiser le matériel.

    En effet, Haiku dispose d'un chargeur de démarrage en 2 étapes : la première est soit un chargeur minimaliste (par exemple sur x86), soit un bootloader existant (tel que uboot ou un firmware UEFI). Le deuxième niveau est un bootloader spécifique à Haiku et qui est plus complexe. Il permet d'afficher un menu de démarrage dans lequel on peut configurer différentes options (mode sans échec, …), choisir une version de Haiku à démarrer, désactiver des pilotes problématiques, et ainsi de suite. Ce bootloader est également responsable de l'initialisation de la MMU avant de passer la main au noyau, et même d'afficher l'écran de démarrage.

    Pour un fonctionnement confortable, ce chargeur a donc besoin d'accéder à pas mal de matériel : écran en mode framebuffer, clavier, ou à défaut un port série. Sur PC, cela peut être fait en utilisant le BIOS ou EFI, et sur les versions PowerPC ou Sparc de Haiku, c'est le firmware OpenBoot ou OpenFirmware qui joue ce rôle. Rien de tel n'était possible avec u-boot.

    Cette situation est maintenant résolue puisque u-boot implémente aujourd'hui la spécification EFI. Il est donc possible de réutiliser le code écrit pour les processeurs x86_64 pour la version ARM. Tout le code pour tenter de démarrer à partir d'un u-boot simple sans EFI a été supprimé… enfin presque. Il reste une plateforme PowerPC (la carte Sam440ex) sur laquelle u-boot ne fournit pas l'API UEFI. En effet, le fabricant de cette carte a fait un fork de u-boot dans lequel il a changé énomément de choses sans raison, et ce travail ne sera jamais intégré avec une version mise à jour de u-boot. Il faudra donc trouver une autre solution pour cette carte.

    Systèmes de fichiers et périphériques de stockage

    Haiku essaie d'être interopérable avec les autres systèmes d'exploitation. Pour cette raison, il est capable au moins de lire, et parfois d'écrire, un assez grand nombre de systèmes de fichiers.

    FAT16/FAT32

    Le nom de volume des partitions formattées en FAT par mkfs n'était pas initialisé correctement, c'est maintenant chose faite. Au passage, l'outil mkdos a été supprimé (il faut utiliser mkfs comme pour tous les autres systèmes de fichiers).

    NTFS

    Le pilote NTFS a reçu une grosse mise à jour (en fait c'est plutôt une réécriture) pour être synchronisé avec la dernière version de NTFS-3G. Le pilote existant avait d'abord été développé pour BeOS et n'avait été que partiellement adapté pour Haiku. Cela a permis de corriger de nombreux bugs, et l'intégration de nouvelles versions de NTFS-3G sera beaucoup plus simple.

    EXT4

    Ajout des dernières fonctionnalités développées dans EXT4 pour pouvoir continuer à utiliser les partitions créées par les nouvelles versions de Linux.

    Ajout de la gestion des "spare files" (fichiers dont le contenu comporte des "trous" qui ne sont pas stockés sur le système de fichiers).

    XFS

    XFS est un des systèmes de fichiers disponibles pour Linux. Il est populaire parmi les développeurs de Haiku en raison de son assez bon support des attributs étendus, qui permet la compilation croisée de Haiku depuis Linux sans avoir besoin d'une couche d'émulation des attributs étendus comme c'est le cas avec EXT4.

    Mashijams, un des 4 étudiants participant au Google Summer of Code pour Haiku cette année, est en train d'ajouter au pilote XFS la lecture du système de fichier XFS version 5. Actuellement seule la version 4 était disponible.

    UserlandFS

    UserlandFS permet d'exécuter des systèmes de fichiers en espace utilisateur. Au départ c'était un outil de debug pour aider au développement de nouveaux systèmes de fichiers, mais il a depuis trouvé d'autres usages.

    UserlandFS expose 3 API : la première est compatible avec les systèmes de fichiers écrits pour le noyau de Haiku, la deuxième pour celui de BeOS, et la troisième est compatible avec libfuse (l'équivalent de UserlandFS sous Linux).

    C'est cette dernière API qui a reçu une importante mise à jour pour être compatible avec la version 2.9.9 de libfuse, et ajouter les API "lowlevel" exposées par cette dernière. En particulier cela permet d'utiliser android-file-transfer-linux pour monter un téléphone Android utilisant le protocole MTP comme un support de stockage classique.

    WebSearchFS

    Historiquement appelé GoogleFS, ce système de fichier répond au queries, une fonctionalité qui permet normalement de trouver des fichiers à partir de leurs attributs étendus, qui peuvent être indexés de façon similaire à une base de données. Cependant, plutôt que de chercher dans des fichiers locaux, ce système de fichier va effectuer une recherche sur Internet et exposer les résultats sous forme de fichiers marque-pages qui peuvent ensuite être ouverts avec un navigateur web.

    Le scrapping des résultats de recherche de Google est devenu beaucoup trop compliqué, le système de fichiers a été modifié pour se baser sur la version html de DuckDuckGo qui fournit des réponses beaucoup plus faciles à digérer.

    Cache

    Les systèmes de fichiers implémentés pour Haiku doivent s'interfacer avec le "file cache" afin de stocker en RAM les informations sur les fichiers et limiter les accès disque inutiles.

    Cet interfaçage a été complété pour les pilotes btrfs, exfat, et ext4.

    "trim"

    Sur les SSD, il est possible de fournir au contrôleur de disque une liste des secteurs non utilisés par le système de fichiers. Le contrôleur peut alors effacer ces secteurs et les utiliser au mieux pour le "wear leveling" de la mémoire (répartition des écritures sur tous les secteurs du disque).

    Dans Haiku, cela peut être fait à l'aide de la commande fstrim, pour l'instant uniquement pour le système de fichiers BFS.

    Différentes corrections ont permis de finaliser l'implémentation pour les contrôleurs SATA, puis peu de temps après, le code nécessaire a été ajouté au pilote NVMe. Cela s'ajoute aux possibilités existantes d'utiliser fstrim: sur un RAMdisk pour libérer de la RAM pour d'autres usages, et sur les cartes SD connectées au travers d'un contrôleur SDHCI (standard défini par la SD association pour interfacer un lecteur de cartes SD sur un bus PCI).

    Autres changements

    Cela a également été l'occasion de corriger différents problèmes dans le pilote NVMe, qui est maintenant plus rapide et compatible avec la très grande majorité des disques disponibles.

    Les derniers problèmes au niveau du stockage concernaient les disques de très grande capacité (plus de 232 secteurs soit 2Tio). Ces problèmes ont enfin été corrigés à différents niveaux (USB, BFS) et tout fonctionne maintenant sans problème.

    Compatibilité POSIX et C11

    Les API de localisation de POSIX n'étaient pas toutes présentes, celles qui manquaient ont été ajoutées.

    La gestion des "weak symbols" a été corrigée. Il s'agit d'une particularité des fichiers ELF qui peut être utilisée de deux façons :

    • On peut exporter une fonction en indiquant que le symbole exporté est "faible". Dans ce cas, si une autre bibliothèque ou exécutable fournit une autre fonction avec le même nom, cette deuxième version est utilisée.
    • On peut aussi utiliser un marqueur "faible" sur un symbole importé (c'est à dire, par exemple, une fonction qu'on veut appeler). Dans ce cas, si la fonction est présente quelque part, le symbole pointera dessus.

    Il y avait un gros problème dans ce deuxième cas si la fonction concernée n'est pas définie : le symbole aurait du prendre la valeur 0, mais il était laissé non initialisé et le résultat était un crash lorsque le code essayait d'appeler une fonction qui n'existait pas.

    La nouvelle version C11 du langage C (publiée en 2011 comme son nom l'indique) nécessite des changements dans la bibliothèque standard. Par exemple, une nouvelle APIs pour les threads (qui est simplement implémentée par une surcouche de l'API pthread, en réutilisant le code écrit à cet effet par FreeBSD), ou encore la fonction timespec_get.

    Haiku est un peu en retard sur l'implémentation de C11, mais pas sur l'implémentation de POSIX puisque les travaux pour la prochaine version ont déjà commencé. Le groupe d'Austin, qui se charge de faire évoluer la spécification POSIX, a déjà standardisé une liste de nouvelles fonctions qui feront partie de la version "Issue 8" de la spécification POSIX. De plus, il est possible de suivre les discussions sur cette spécification à travers l'outil de suivi des bugs du groupe.

    Certaines des fonctions proposées (strlcpy par exemple) étaient déjà implémentées depuis longtemps par Haiku (et par les systèmes *BSD). Dans ce cas il faut simplement vérifier que le comportement correspond précisément à ce qui est décrit, et dans le cas de Haiku, éventuellement déplacer les fonctions concernées de la libbsd vers la libroot et mettre à jour les fichiers d'en-tête pour activer ces fonctions dans les cas où elles doivent l'être.

    Dans d'autres cas, les fonctions standardisées n'étaient pas encore présentes dans Haiku et ont du être ajoutées. C'est le cas par exemple de ppoll, de qsort_r, et des fonctions permettant de spécifier quelle horloge il faut utiliser pour les timeouts sur l'acquisition d'un mutex ou d'une condition variable.

    Enfin, l'outil strace (qui ne fait pas partie du standard POSIX) a reçu plusieurs mises à jour pour correctement afficher les paramètres de certains appels systèmes.

    Applications

    Après avoir avancé sur la version RISC-V de Haiku, X512 ne s'est pas arrêté là, et il a réussi à faire fonctionner Wine. Pour l'instant, seules les applications Windows 64bit peuvent être exécutées.

    Waddlesplash, quant à lui, souhaitait plutôt utiliser des applications disponibles sous Linux. Comme Haiku n'a pas de serveur X (ni Wayland), cela rend l'utilisation de certains toolkits graphiques sous Haiku un peu compliquée. Sa solution a été d'écrire une bibliothèque fournissant une API compatible avec Xlib, mais qui utilise l'app_server de Haiku pour l'affichage. Cela permet de faire fonctionner facilement les applications utilisant, par exemple, GTK ou python-tk (ou tcl-tk), ainsi que les applications utilisant directement la Xlib.

    Cette approche fonctionne plutôt bien, mais X11 n'est pas vraiment une technologie d'avenir. X512 est donc en train de se pencher sur la possibilité d'une approche similaire pour les toolkits et applications utilisant libwayland-client, et quelques captures d'écran d'applications GTK4 fonctionnant sous Haiku circulent déjà.

    Cela dit il ne faut pas oublier les applications natives! C'est pourquoi Harshit Sharma (étudiant participant au Google Summer of Code) améliore l'application Agenda avec une refonte de son interface et l'ajout de nouvelles fonctionnalités de synchronisation et de gestion des rendez-vous.

    Dans la prochaine version de Haiku on trouvera aussi des améliorations sur le gestionnaire de paquets HaikuDepot (affichage de la taille des paquets installés, affichage de la date de publication des mises à jour de logiciels); un bouton "Enregistrer sous" qui fonctionne correctement dans la visionneuse d'images; un bouton pour éjecter un CD en cours de lecture depuis le lecteur média; l'affichage de la fréquence des processeurs dans ActivityMonitor; plusieurs petits changements dans les applications impliquées dans le premier démarrage et l'installation de Haiku; ou encore une amélioration de l'affichage des octets dans l'éditeur hexadécimal DiskProbe.

    Une autre nouveauté importante est l'affichage de vignettes pour les images dans Tracker (l'explorateur de fichiers). Ces vignettes sont bien sûr stockées dans les attributs étendus de chaque fichier, ainsi, si on copie le fichier (même d'une machine vers une autre) il n'est pas nécessaire de regénérer la vignette. Tracker est capable de générer les vignettes pour des images mais il est possible pour chaque application qui enregistre un fichier, quel que soit le format, de générer sa propre vignette si c'est utile.

    Le navigateur web WebPositive remonte maintenant dans son User-Agent l'architecture CPU utilisée. Ainsi vous pourrez facilement tracer les deux personnes qui utilisent Haiku avec un processeur RISC-V si vous êtes un GAFAM et que ce genre d'information vous intéresse.

    Le navigateur a reçu de nombreuses autres corrections, par exemple pour utiliser les CSS sombres si le système est configuré avec un thème sombre, ou encore la possibilité de glisser un onglet vers une fenêtre du Tracker pour créer un fichier marque-page.

    Il devrait également recevoir une mise à jour du moteur WebKit pendant la procédure de publication de la beta 4 (cela ne peut pas être fait avant car la nouvelle version de WebKit a besoin de fonctionnalités qui ne sont pas disponibles dans la beta3, et l'infrastructure de compilation des paquets ne permet pas de facilement maintenir deux versions en parallèle).

    Pour terminer, et pour les gens qui préfèrent éviter les interfaces graphiques, quelles qu'elles soient : le Terminal n'est pas oublié ! On peut maintenant configurer la couleur par défaut des 16 couleurs ANSI prédéfinies. De nombreuses séquences d'échappement ont été améliorées, par exemple pour permettre aux applications en console de changer la couleur du curseur, de changer la définition des 256 couleurs personnalisables y compris en utilisant des espaces de couleurs autre que le RGB, et plusieurs petits problèmes de compatibilité ont été résolus.

    Et parmi les changements sur les applications en ligne de commande, pkgman peut maintenant afficher un avertissement s'il est contraint, pour résoudre des dépendances, de réinstaller une version plus ancienne d'un paquet.

    Système de build

    Haiku est désormais compilé avec gcc 11.2 et bientôt 11.3. Le noyau est compilé avec ce compilateur, y compris pour la version x86 32-bits de Haiku qui est la seule à utiliser encore gcc2 pour certaines parties du système afin d'assurer la compatibilité binaire avec les applications écrites pour BeOS. Il n'était déjà plus possible depuis plusieurs années d'utiliser les pilotes écrits pour BeOS, et personne ne s'en est plaint. Continuer à compiler le noyau avec gcc2 était donc inutile.

    Certaines règles de compilation ont été nettoyées pour retirer des scripts de link inutiles et des flags de compilation incorrects. Ceci simplifie le portage vers d'autres architectures.

    Dominic Martinez participe au Google Summer of Code pour terminer le développement de Ham, un projet commencé il y a une dizaine d'années pour remplacer Jam.

    Jam est l'outil utilisé pour compiler Haiku, il est inspiré de Make mais en essayant de définir des règles réutilisables (par exemple "comment fabriquer un fichier .o à partir d'un fichier .c") plutôt que des règles spécifiques pour chaque fichier. Jam n'est plus maintenu par Perforce, et le code de l'outil n'est pas assez propre pour pouvoir facilement le faire évoluer nous-même. Ham ("jambon", en anglais) va donc remplacer Jam ("confiture") pour compiler Haiku. Il sera compatible non seulement avec la version de Jam utilisée par Haiku, mais aussi avec la version originalement développée par Perforce, et avec B2, un autre fork de Jam maintenu par le projet Boost.

    Ham sera non seulement un outil en ligne de commande, mais aussi une bibliothèque qui pourra être intégrée dans un IDE ou autre outil graphique de gestion de compilation.

    Enfin, pour accompagner Ham, une mise à jour du Jamfile engine a été mise à disposition des développeurs d'applications. Il s'agit d'un ensemble de règles utilisables dans un projet utilisant Jam pour facilement compiler une application (ou une bibliothèque ou un add-on) pour Haiku. Cependant, le Jamfile engine dans sa version actuelle est loin d'être satisfaisant et il sera probablement complètement réécrit.

    D'autre part, le travail de fond pour compiler l'intégralité de Haiku sans aucun warning du compilateur se poursuit. Chaque nouvelle version de gcc apporte son nouveau lot de problèmes à corriger. Malheureusement, une bonne partie d'entre eux vient de code tiers qui n'est pas maintenu par l'équipe de Haiku. Parfois les modifications peuvent être envoyées aux auteurs originaux, mais ce n'est pas toujours le cas.

    La prochaine version, c'est pour quand?

    Il y a encore 14 tickets dans la liste de choses à faire pour la beta4, dont quatre sont en priorité "bloquante" et un en priorité "critique". Votre aide est la bienvenue si vous pensez pouvoir aider à résoudre l'un de ces problèmes. Les autres tickets listés pourront être repoussés vers la prochaine version (après tout, ce n'est qu'une version beta et il y en aura d'autres).

    Un petit résumé de ces 5 tickets à résoudre :

    #17256

    Un travail en cours pour cacher par défaut tous les symboles exportés par la bibliothèque statique libshared. Cette bibliothèque contient des API expérimentales pour lesquelles il n'y a pas de garantie de compatibilité lors des mises à jour de Haiku. Cependant, une grande partie du code est dans ce cas, et cette bibliothèque est utilisée à peu près partout, y compris dans d'autres bibliothèques de Haiku.

    Suite à une erreur de configuration de l'éditeur de lien, une bibliothèque partagée qui est liée avec la libshared finit par ré-exporter une partie de cette API expérimentale. Et comme c'est le cas depuis un certain temps, quelques applications ont fini par utiliser les fonctions ainsi ré-exportées. Il faut donc identifier et corriger ces applications avant de corriger le problème dans Haiku.

    #17595

    Sur certaines machines équipées de CPU Intel de 11ème génération, par exemple les PC portables modulaires de la marque Framework, Haiku détecte une fréquence d'horloge de plusieurs dizaines de GHz, ce qui est bien sur incorrect. Cela conduit à un système fortement ralenti, à moins que ce soit le ralentissement du système qui cause la mauvaise détection.

    Toutes les machines utilisant ces CPU ne sont pas concernées et pour l'instant les développeurs de Haiku n'ont pas trouvé d'ou le problème pourrait venir.

    #17633

    Une régression sur le pilote VESA qui empêche le système de démarrer sur au moins une machine. Comme cela a été mentionné plus haut dans le paragraphe sur le pilote VESA, l'approche la plus simple est de désactiver le patching du BIOS pour ajouter des résolutions d'écran personnalisées.

    Le correctif est en cours de relecture.

    #17829

    Une mise à jour de FFmpeg. Elle ne pose pas de problème pour Haiku, mais tous les paquets de Haikuports qui dépendent de FFmpeg vont devoir être recompilés. Comme ces paquets vont aussi être recompilés en préparation de la release, c'est une bonne idée de faire ces deux mises à jour simultanément.

    #17208

    Il s'agit d'une fuite mémoire assez importante, a priori liée à l'utilisation d'un réseau où il y a beaucoup de trafic multicast. La principale difficulté pour investiguer ce problème est de connecter un réseau aussi chargé à la machine d'un développeur, à un moment ou il est disposé à se lancer dans une investigation (pas au milieu d'un hall de gare ou d'aéroport avec un Wifi public en correspondance entre 2 trajets, par exemple).

    Et la version 1, alors?

    Après plus de 20 ans, on peut se demander si le projet avance vraiment. Le meilleur outil de suivi pour mesurer cela est la feuille de route sur l'outil de suivi de tickets Trac.

    L'objectif de départ pour la version 1 de Haiku était initialement de fournir un remplacement complet, composant par composant, de la dernière version officielle de BeOS R5 (5.0.3), plus la mise à jour "Bone" qui remplaçait la pile réseau de BeOS implémentée entièrement dans l'espace utilisateur par une implémentation plus classique intégrée dans le noyau.

    Ces objectifs ont été revus en 2010, après la sortie de la version alpha1, avec un sondage de la communauté d'utilisateurs et des développeurs pour voir s'il fallait ajouter d'autres objectifs. L'époque était plutôt optimiste et pas mal de choses ont donc été ajoutées : le Wifi, la possibilité d'installer des mises à jour du système, etc.

    Tous ces objectifs ont été atteints, ce qui a permis d'entrer en phase "beta", phase dans laquelle on se consacre à la correction de bugs et à l'amélioration des performances.

    Ces deux dernières années, du tri a été fait dans les tickets pour mieux définir ceux qui sont vraiment indispensables à la version 1. De plus, les tickets résolus sont maintenant déplacés dans le jalon correspondant à la prochaine version publiée.

    Cela permet de voir que la version beta 4 (un peu plus d'un an de travail) contient plus de 270 corrections par rapport à la version précédente. Et d'autre part qu'il ne reste que 641 tickets ouverts avant d'arriver à la version R1. Si aucun bug n'est découvert d'ici là, il faudrait donc encore 3 ou 4 ans de travail pour arriver à publier une version 1 (ce n'est bien sûr qu'une estimation très imprécise).

    Cependant, tous les développeurs ne sont pas concentrés exclusivement sur la correction de bugs et les autres tâches ennuyeuses conduisant à la version R1. De nouvelles fonctionnalités continuent d'être développées et l'écriture de pilotes pour du matériel récent demande aussi beaucoup de temps.

    Financement

    Pour progresser plus vite, il faut augmenter le nombre de contributeurs, ou bien le temps qu'ils peuvent consacrer au projet. Pour cette deuxième solution, une solution en ce moment est d'embaucher un développeur (Waddlesplash) 32 heures par semaine ce qui le dispense d'avoir un travail rémunéré en plus de ses activités sur Haiku. Le paiement proposé est en dessous du prix du marché pour un développeur avec son niveau d'expérience. On en parlait l'automne dernier sur LinuxFr.org.

    Ce n'est pas la première fois que Haiku embauche un développeur à plein temps. Le précédent contrat le plus long a duré près d'un an, c'était PulkoMandy qui avait travaillé en 2014, entre autres choses, sur la mise à jour du moteur WebKit pour le navigateur web de Haiku. Depuis 2015 il n'y avait pas eu d'autre contrat aussi ambitieux, mais Haiku inc a continué de recevoir des donations ainsi qu'une compensation financière pour sa participation au Google Summer of Code. ce qui lui a permis d'accumuler des réserves de trésorerie suffisantes pour pouvoir proposer à nouveau un contrat à long terme.

    Cependant, sans une augmentation importante des finances de l'association, ce contrat ne pourra durer qu'un an ou deux, après quoi l'association sera à court d'argent. L'objectif est donc de réussir à attirer de nouveaux donateurs, et il faudrait quadrupler leur nombre pour avoir une situation durable avec un employé. Dans ce cadre, plusieurs choses ont été mises en place :

    • Une boutique sur le site Freewear permettant d'acheter des vêtements et autres goodies aux couleurs de Haiku, avec un pourcentage des ventes reversé à l'association,
    • Un compte Liberapay qui permet de recevoir des dons via Stripe, et donc avec des virements SEPA (compliqués à mettre en place sur un compte en banque Américain),
    • L'ouverture des dons via Github sponsors, option la plus intéressante car il n'y a aucun frais des opérateurs de paiement (c'est Microsoft qui paie).
    • Une meilleure communication de l'association sur son budget et ses besoins financiers

    L'association essaie également de convertir ses Bitcoins (donations reçues il y a longtemps alors que les cryptomonnaies n'avaient que peu de valeur) en vrai argent, cependant, pour l'instant, des problèmes administratifs avec l'opérateur Coinbase empêchent cette transaction (débloquer les fonds nécessiterait de payer des taxes personellement pour l'un des membres de l'association).

    Le rapport financier 2021 donne quelques chiffres :

    • L'association a reçu environ 24000$ de dons (c'est mieux que l'année précédente, seulement 17000$)
    • Elle a dépensé environ 17000$ dont 13000$ pour rémunérer Waddlesplash pour 300 heures (réparties sur 4 mois en fin d'année)
    • Les réserves sont de 111000$, plus environ 172000$ en cryptomonnaies (mais ces dernières ont perdu beaucoup de valeur depuis)

    L'objectif pour 2022 est de continuer à augmenter les dons reçus. Les dépenses vont également augmenter puisque Waddlesplash travaille pendant l'année complète. Le budget 2022 sera donc probablement déficitaire. Il faudra atteindre 80000$ de dons par an pour pouvoir rémunérer Waddlesplash de façon permanente. Puis continuer à augmenter ce chiffre pour embaucher un.e deuxième développeur.se par la suite?

    Statistiques de contribution

    Statistiques pour Haiku
    Statistiques pour HaikuPorts

    L'an dernier, Haiku comptait 305 contributeurs. Cette année il y en a 324. Ce sont donc 19 personnes qui ont proposé pour la première fois cette année un patch ou un changement qui a été intégré dans le code.

    L'année 2021 a été la moins active pour le projet depuis le début de l'utilisation de Subversion (par la suite le projet a migré à Git en conservant l'historique Subversion), avec seulement 1106 commits. Il n'y a eu que 51 personnes qui ont contribué au moins un changement en 2021, ce qui est peu.

    Cependant, le projet HaikuPorts (qui contient les "recettes" permettant de compiler des logiciels pour Haiku se porte beaucoup mieux : le nombre de commits se maintient, et le nombre de contributeurs pendant l'année 2021 est de 72, battant le record de l'année précédente (70). HaikuPorts commence à recevoir des contributions de développeurs qui mettent à jour ou empaquettent leurs propres logiciels.

    Il y a actuellement 3172 logiciels empaquetés dans HaikuPorts, dont 1357 nécessitent encore un patch qui n'a pas été intégré par les développeurs des logiciels concernés (ils n'ont pas forcément tous étés soumis aux projets upstream par l'équipe de Haikuports).

    Il y a 25 nouveaux contributeurs pour Haikuports cette année (on passe de 250 à 275 personnes ayant contribué au moins un patch).

    Aussi bien dans Haiku que dans HaikuPorts, de nouveaux contributeurs ont fait leur apparition dans le top 6 annuel des contributeurs les plus actifs.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

  10. Après AlmaLinux, c'est au tour de Rocky Linux de sortir la version 9.0 de son clone de Red Hat Enterprise Linux (RHEL), la célèbre distribution commerciale destinée aux professionnels et aux entreprises.

    Introduction

    La riposte communautaire initiée par Gregory Kurtzer (fondateur de CentOS) continue avec Rocky Linux 9.
    Cette nouvelle version sera supportée jusqu'au 31 mai 2032, tandis que la version Rocky Linux 8 continuera d'être supportée jusqu'au 31 mai 2029.

    Logo Rocky Linux 9

    La version

    Rocky Linux 9 est livré avec GNOME 40.

    Améliorations graphiques

    • Les logiciels peuvent être exécutés sur une carte graphique séparée en faisant un clic droit et en sélectionnant l'option appropriée.
    • La possibilité de couper le son des notifications en sélectionnant Ne pas déranger, qui apparaîtra comme un bouton séparé dans la notification.
    • Chaque écran peut utiliser un taux de rafraîchissement différent
    • Le programme Activités vous permet de regrouper les icônes des applications dans des dossiers en utilisant la méthode du glisser-déposer.
    • Mise à l'échelle fractionnée de l'affichage

    Améliorations du système de fichiers

    • XFS prend désormais en charge les opérations d'accès direct (DAX), ce qui permet d'accéder directement à la mémoire persistante adressable par octet et d'éviter la latence liée à l'utilisation des conventions traditionnelles d'E/S par bloc.
    • NFS introduit l'option de montage "eager write" pour aider à réduire la latence.

    Les outils de compilation

    • Rocky Linux 9 dispose d'un grand nombre des dernières versions de moteurs d'exécution et compilateurs, notamment GCC 11.2.1, LLVM (13.0.1), Rust (1.58.1) et Go (1.17.1), binutils (2.35).

    • Python 3.9 sera pris en charge pendant tout le cycle de vie de Rocky Linux 9 et est livré avec de nombreuses nouvelles fonctionnalités, notamment des timestamps tenant compte des fuseaux horaires, de nouvelles méthodes de préfixe et de suffixe de chaîne, des opérations d'union de dictionnaire, des analyseurs syntaxiques performants et des améliorations du multitraitement.

    • Node.js 16 comprend une mise à niveau du moteur V8 vers la version 9.2, une nouvelle API Timer Promises, une nouvelle API web streams, et la prise en charge de la version 7.20.3 du gestionnaire de paquets npm. Node.js est désormais compatible avec OpenSSL 3.0.

    • Ruby 3.0.3 apporte plusieurs améliorations de performance, ainsi que des corrections de bogues et de sécurité. Parmi les améliorations importantes, citons la concurrence et le parallélisme, l'analyse statique, le filtrage avec les expressions case/in, le filtrage sur une ligne et le filtrage par recherche.

    • Perl 5.32 fournit des corrections de bogues et des améliorations, notamment la version 13 d'Unicode, un nouvel opérateur infixe expérimental et des vérifications de fonctionnalités plus rapides.

    • PHP 8.0 apporte des corrections de bogues et des améliorations, notamment l'utilisation de la syntaxe des métadonnées structurées, des arguments nouvellement nommés qui sont indépendants de l'ordre, et des performances améliorées pour la compilation Just-In-Time.

    Sécurité

    L'authentification de l'utilisateur root avec un mot de passe via SSH a été désactivée par défaut.
    OpenSSL 3.0 ajoute un concept de fournisseur, un nouveau schéma de gestion des versions et un HTTPS amélioré. Les utilitaires intégrés ont été recompilés pour utiliser OpenSSL 3. Le nouveau module FIPS d'OpenSSL 3.0 empêche l'utilisation d'algorithmes non FIPS, tandis que l'indicateur FIPS peut être activé dans le noyau sans qu'il soit nécessaire de passer OpenSSL en mode FIPS.

    Surveillance du système

    La console web Cockpit dispose d'une page améliorée de mesure des performances qui permet d'identifier les causes des pics d'utilisation des ressources CPU, mémoire, disque et réseau.

    Un support commercial

    Sur le site de Rocky Linux, deux sociétés fournissent un support commercial :

    Structure de Rocky Linux

    La Rocky Enterprise Software Foundation (RESF) est une société d'intérêt public (Public Benefit Corporation, PBC) constituée dans le Delaware (numéro de dossier 4429978). La RESF a été fondée et est détenue par Gregory Kurtzer. Elle est soutenue par un comité consultatif composé de personnes de confiance et de chefs d'équipe de la communauté Rocky Linux.

    Conclusion

    L'avenir nous dira si cette distribution va survivre dans le temps.

    Commentaires : voir le flux Atom ouvrir dans le navigateur